question

ptss avatar image
ptss asked

VE.Direct MPPT 75/10 high amount of checksum errors / corrupt checksum packets

MTTP 75/10 latest firmware version FW 161 connected via a 5v FTDI cable getting about 25 bad packets every ~200 good packets. The corruption appears to always be in the checksum field not random like noise. Baud is 19200, tested with custom software & also happens with simple Com Terminal app.

Is there a known issue with how checksums are being calculated in this version of FW?
Anyone else experiencing this? Since it is always on the checksum field I'm pretty doubtful this is a comms issue?

1698982526055.png

1698982445855.png

VE.Directcommunication protocol
1698982445855.png (124.6 KiB)
1698982526055.png (31.4 KiB)
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

6 Answers
Thiemo van Engelen (Victron Energy staff) avatar image
Thiemo van Engelen (Victron Energy staff) answered ·

Hi @PTSS

In the screen shot above, there is a VE.Direct Hex message directly after the checksum byte of the VE.Direct Text block. Could it be that this disrupts the checksum calculation code that you are using or that the code cannot handle the VE.Direct Hex message?

Kind regards,

Thiemo van Engelen

2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

ptss avatar image
ptss answered ·

Thankyou!!!

This makes sense now! I have read about the HEX messages, but was not clear on what to expect.

So because the software is not sending any commands to the MTTP, after x amount of time it starts to send HEX messages with the Text Stream!

So I just need to detect (possibly the ':' as that's used for sending commands) the HEX Msg and ignore it!


Thankyou!

2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

ptss avatar image
ptss answered ·

OK so I am handling the HEX message and skipping over the HEX string and ignoring it/strip it and next packet after is calculating a correct checksum.

But still getting fairly high BAD CHECKSUMs, and each 'bad' packet seems to be a checksum of '63' or '?'

Odd....... does '?' possibly mean checksum unknown???1699059703834.png1699059674995.png

1699059668309.png

1699059691212.png


1699059668309.png (122.5 KiB)
1699059674995.png (123.4 KiB)
1699059691212.png (123.3 KiB)
1699059703834.png (124.6 KiB)
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Thiemo van Engelen (Victron Energy staff) avatar image
Thiemo van Engelen (Victron Energy staff) answered ·
Hi @PTSS

I believe the ? is just the result of the printing. The character is probably a non-ASCII character which cannot be printed to it just prints '?'. Or it could be a result of how the serial port is opened/read (binary vs text).

Kind regards,

Thiemo van Engelen


2 comments
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

ptss avatar image ptss commented ·

Ta, it is definitely a '?' as ASCII 63 each time I see in debug.

Issue seems to get worse the longer its left on from power-up, or factory reset.

No-one else seeing this?


Latest Firmware..

0 Likes 0 ·

Hi @PTSS

I am not questioning that the debug shows a ? (ASCII 63). I am questioning whether the original character that was received via the serial port is actually that character. The checksum can be byte value, even non printable ones. I am wondering whether these non printable characters are transformed to a '?' either while reading from the serial port or when printing them.

Kind regards,

Thiemo van Engelen

1 Like 1 ·
ptss avatar image
ptss answered ·

Yes the actually byte code being received for check sum is #63 and that is ASCII for a '?'

So yes what is being received is what's is displayed, a printable ASCII '?'

2 comments
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Hi @PTSS

Then I think that the code / library that is opening and reading from the serial port is already doing some conversion and replacing the no-readable characters by a ?. The code that is running in the screen shots with the logging, is that somewhere available online? If not, can you paste some code snippets?

Kind regards,

Thiemo van Engelen

0 Likes 0 ·
ptss avatar image ptss Thiemo van Engelen (Victron Energy staff) ♦ commented ·
Thanks for reply! I will try and put something together.


Is the random HEX data TX calculated as part of the checksum or ignored. As there is no mention in the Docs about this I have found. I'm ignoring it (from memory).

0 Likes 0 ·
ptss avatar image
ptss answered ·

Apologies!!!!!!!

Dotnet C# System.IO.SerialPort ReadLine() defaults to ASCII encoding by default!
So any chars received outside of #127 is replace by ASCII code #63 '?'

SerialPort Docs

Setting encoding to Latin1 (0x00<==>0xFF) range is fix or handle stream buffer directly to get bytes out without encoding stripping anything.

Now getting all good packets & checksums

[Can be closed]
TY!

1 comment
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Hi @PTSS

Good to hear that everything is solved now.

Kind regards,

Thiemo van Engelen

0 Likes 0 ·

Related Resources

VE.Direct protocol FAQ

Additional resources still need to be added for this topic