-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Frame separation fails when an error frame occurs before a normal frame. #8
Comments
Hi @Guswib The command you are sending looks correct to me. Do you get similar behavior when sending other commands? |
Yes, all commands result in the initial error frame. Discarding this initial frame, all values are reasonable. Thanks for the link to the library. I tried it out and I get the following response(see below). 12:15:50.031 -> readAveragedMeasuredValue:----------------------- |
I tested another device. The same issues persist.... |
Hm, this is most probably an issue with the connection where some frames or parts of it are getting lost and not the sensor itself. What is your exact setup and what Arduino are you using? |
I have recreated the exact setup that is shown in the example, while using a arduino Mega. |
Hi, I have a MCF SFC6xxxx device using RS485
When I sending the command following command to the device:
0x7E, 0x0, 0x0, 0x1, 0x1, 0xFD, 0x7E
It sends back:
0x7E, 0xFE, 0xFF, 0xF9, 0xF9, 0xFD, 0x7E, 0x7E, 0x0, 0x0, 0x0, 0x4, 0x0, 0x0, 0x0, 0x0, 0xFB, 0x7E
which are two frames following each other. The first frame seems to be a error response, while the second frame seems to be the normal response.
The function "SensirionShdlcCommunication::receiveFrame" fails to split the two frames and I only get a timeout. If I read 7 bytes from the RX-stream before executing the SensirionShdlcCommunication::receiveFrame, I get a expected response.
So, the issue is the initial error frame. It might be due to that the 4th byte in the frame, i.e the "length", is not 0, which should be the case for a error frame. So, the reading of incoming bytes passes over the end-of-frame byte instead of breaking.
The text was updated successfully, but these errors were encountered: