I have a 712 which is connected via the Victron USB cable to an RPi to read all the message data. Until the latest firmware upgrade this worked perfectly. The s/w on the RPi synchronises to the frames and performs the sum check. Until the firmware upgrade I was getting no sum check failures at all.
Now about 33% of the frames are corrupt in that the sum check fails.
Any advice on this would be appreciated.
Thanks,
Colin.
Hi, please check the data you are receiving. What is wrong with it?
A test program has shown only partial frames, from H15 or H16 on the historic frame.
Hi again, could you post the plain output of the frames you are seeing?
The frame data is not displayed so it's difficult to see what is wrong with it. Frames that fail the sum check are discarded so I don't get to see the data they contain.
Failure rate is pretty consistent at 33%. Has any data been introduced that maybe isn't included in the checksum value?
Colin.
My code was reading two frames at a time, the current data values frame and the historic data values frame. Having got the two frames it processed them and then waited 10 seconds to start reading data again. Obviously my code has to resynchronise by looking for cheacksum data value and starting the frame at the next byte.
This was working fine before the 4.01 firmware upgrade.
I have discovered that if I remove the 10 second delay I can read frames reliably again.
Have you changed the way you manage your output buffer? I assume it is a circular buffer with a read and a write pointer. If when the buffer gets full you're now allowing the write pointer to overtake the read pointer this could explain the issue I'm seeing. For proper data integrity when the buffer becomes full, I would expect the read pointer to be kept ahead of the write pointer.
I've found my immediate problem. Although my code was synching to the start of a name/value pair, it was not in fact synching to the start of a frame. So every ten seconds the sum check was being performed on an incomplete frame, i.e. the first frame it tried to read. The subsequent two frames, historic and current, were being read fine as they were being read in quick succession after the initial failed frame. Hence the 66% success rate.
What I now don't understand is how it ever worked. My code had 100% reliability reading frames before the firmware update. But I cannot now see how it could have found the start of a frame since it wasn't looking for one.
Hi! I dont understand how it can have ever worked either; but I’m glad it does now.
Thanks for confirming that it works now; I’ll consider this case closed.
