I've been struggling with a similar problem for the last couple of days. It only seems to happen with quite complex instruments (for me Ka50 PVI800, lots of buttons, LEDs, 7 seg displays etc)
Only occurs over RS485, not serial
I think I've tracked it down to a slight issue in the Arduino lib, specifically DcsBiosNgRS485Slave.cpp.inc. (not DcsBiosNgRS485Master.cpp.inc thanks doubleup)
case RX_WAIT_DATA:
rxtx_len--;
if (rx_datatype == RXDATA_DCSBIOS_EXPORT) {
parser.processCharISR©;
}
if (rxtx_len == 0) {
state = RX_WAIT_CHECKSUM;
}
The rx ISR has a section where a new byte is sent off to be processed. However, the ISR is reentrant, meaning that if a new byte is received before the previous one is processed, that too is added to the process queue.
The problem is that when the end of the message occurs, and the various export stream listeners are busy updating, the CRC byte can be received. And because the checking for the end of message relies on processCharISR returning, so it can check the rxtx_len and set to state to RX_WAIT_CHECKSUM, (it hasn't yet, still busy), the CRC also gets sent off to processCharISR, and the end of message is missed. rxtx_len is now 255, so now the next 255 'random' bytes get added to the incoming stream, resulting in some very weird updates.
The solution is to check and set the state correctly before processing the byte. ie swap the order of the 2 if statements in the RX_WAIT_DATA case.
case RX_WAIT_DATA:
rxtx_len--;
if (rxtx_len == 0) {
state = RX_WAIT_CHECKSUM;
}
if (rx_datatype == RXDATA_DCSBIOS_EXPORT) {
parser.processCharISR©;
}
Now, when the checksum byte comes in, it's correctly handled, even if processCharISR and processChar haven't finished yet.
This does the trick with RS485 for me. It's now rock solid. Perhaps try the above and see if it helps?