Firejo
Member
It's been a very long time since I've had to access these brain cells, but if memory serves my correctly (and that's a big "if"), the reason a word protocol (format is a better word) mismatch will give "sometimes correct, sometimes incorrect" responses has to do with the error checking. Error checking relies on some values being "known" with one of those values being the number of bits making up the packet of data. When the word protocol does not match between devices, the bits won't line up with regards to how the packet is assembled.
With regards to why short answers have errors and long ones (sometimes) don't, short answers will take up the entire transmission packet and if the word format is wrong bits will be out of place and the error checking will reject the packet (I.E. framing error). If the answer is long, then it will require two packets with the second packet having "fill" characters. Depending on what is in the data packet, adding those fill characters can cause the error checking sum to be correct even though the word format is wrong (I.E. no framing error). One of the things to be careful with this scenario is that even though the packet appears correct, sometimes they aren't, they just don't show an error. Having said that, sometimes the "payload" is correct even though the word format is wrong.
Again, It's been a very long times since I've had to dig this deep into serial data issues and it's possible I'm not remembering the details correctly however the concept is sound and I've seen the results EStufC is seeing many times (long ago). Each time I would see it it was almost always a baud rate or word format mismatch. The only other possibility that comes to mind is an actual protocol mismatch I.E. Modbus RTU to Modbus ASCII (for example). I have seen that one once or twice as well and depending on the equipment involved you sometimes can get communications between them (albeit very poor communications).
With regards to why short answers have errors and long ones (sometimes) don't, short answers will take up the entire transmission packet and if the word format is wrong bits will be out of place and the error checking will reject the packet (I.E. framing error). If the answer is long, then it will require two packets with the second packet having "fill" characters. Depending on what is in the data packet, adding those fill characters can cause the error checking sum to be correct even though the word format is wrong (I.E. no framing error). One of the things to be careful with this scenario is that even though the packet appears correct, sometimes they aren't, they just don't show an error. Having said that, sometimes the "payload" is correct even though the word format is wrong.
Again, It's been a very long times since I've had to dig this deep into serial data issues and it's possible I'm not remembering the details correctly however the concept is sound and I've seen the results EStufC is seeing many times (long ago). Each time I would see it it was almost always a baud rate or word format mismatch. The only other possibility that comes to mind is an actual protocol mismatch I.E. Modbus RTU to Modbus ASCII (for example). I have seen that one once or twice as well and depending on the equipment involved you sometimes can get communications between them (albeit very poor communications).