Skip to content
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

Open
Guswib opened this issue Oct 7, 2024 · 5 comments
Assignees

Comments

@Guswib
Copy link
Contributor

Guswib commented Oct 7, 2024

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.

@sdmueller
Copy link

Hi @Guswib

The command you are sending looks correct to me.

Do you get similar behavior when sending other commands?
And what happens if you use the SFx6xxx specific library here: https://github.com/Sensirion/arduino-uart-sfx6xxx
It uses this library.

@sdmueller sdmueller self-assigned this Oct 10, 2024
@Guswib
Copy link
Contributor Author

Guswib commented Oct 11, 2024

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).
I also added the "getSetpoint", and some more printouts. As you can see, I get a lot of error messages, but not always. For example, I can see that I can set the setPoint. So, it seems that the device send this error frame for some strange reason.

12:15:50.031 -> readAveragedMeasuredValue:-----------------------
12:15:50.031 -> Error trying to execute readAveragedMeasuredValue(): Wrong command in return frame
12:15:51.041 -> SetPoint:-----------------------
12:15:51.041 -> Error trying to execute getSetpoint(): Checksum is wrong
12:15:51.082 -> readAveragedMeasuredValue:-----------------------
12:15:51.082 -> averagedMeasuredValue: -0.00
12:15:52.061 -> SetPoint:-----------------------
12:15:52.061 -> Error trying to execute getSetpoint(): Not enough space in buffer
12:15:52.104 -> readAveragedMeasuredValue:-----------------------
12:15:52.104 -> Error trying to execute readAveragedMeasuredValue(): Wrong command in return frame
12:15:53.112 -> SetPoint:-----------------------
12:15:53.112 -> Error trying to execute getSetpoint(): Checksum is wrong
12:15:53.112 -> readAveragedMeasuredValue:-----------------------
12:15:53.112 -> averagedMeasuredValue: -0.00
12:15:54.110 -> SetPoint:-----------------------
12:15:54.110 -> Error trying to execute getSetpoint(): Not enough space in buffer
12:15:54.110 -> readAveragedMeasuredValue:-----------------------

@Guswib
Copy link
Contributor Author

Guswib commented Oct 11, 2024

I tested another device. The same issues persist....

@sdmueller
Copy link

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?

@Guswib
Copy link
Contributor Author

Guswib commented Nov 2, 2024

I have recreated the exact setup that is shown in the example, while using a arduino Mega.
p.s. I have created a pull request to fix the issue with the error frame.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants