Opta RS485 bug: last byte of any frame is modified (CRC always wrong)

Official Hardware Opta
21

You’re absolutely right — in the end it was time‑related. The reason I initially thought it wasn’t is because I did try adding delays manually, but at that moment my test setup wasn’t clean enough to reveal the real issue.

Later I realized two things:

  • flush() is mandatory, otherwise the delay doesn’t actually protect the last byte.
  • The Opta cuts DE too early unless the delay is applied inside the RS485 driver (via setDelays()), not just with a manual delayMicroseconds().

So your suggestion was correct — I just didn’t have the right conditions for it to work at the time. Once I combined flush() + the proper post‑delay, everything worked exactly as expected.

And honestly, I also wanted to understand the why behind the behavior, not just patch it. Now it finally makes sense.

Thanks again for pointing me in the right direction. :+1:

22

You are welcome. Please update your post related to this on other topic.