question

Hi @softwarecrash

If the code that you have is almost completely a copy of the reference frame handler, then the

bool hexRxEvent(uint8_t c) 

function should return true when c == '\n'. This will reset the frameHandler state to IDLE and following frames should be parsed again.

Kind regards,

Thiemo van Engelen

Hi @softwarecrash

So the problem is indeed that the hexRxEvent should not always return true, but only when c == '\n'. With your current (that always return true), all characters of the hex message are added to the checksum. By only returning true when c == '\n', it stays in the RECORD_HEX state while the hex message is still going on and only leaves the frame handler in the proper state for the start of the text frame.

Kind regards,

Thiemo van Engelen

@Thiemo van Engelen (Victron Energy staff)

thank you for your answer,

so i double checked the example code and mine, badly in the example code the hexRxEvent() function is not described, so i added a simple switch to it to stay in the hex_record state until a newline is income, but without change.

bool VeDirectFrameHandler::hexRxEvent(uint8_t inbyte)
{
    if (inbyte == '\n')
    {
        return true;
    }
    else
    {
        return false;
    }
}

the hex data was ignored or dripped, but the checksum was calculated with some extra characters.

so without the hex data it works like a charm, but the new device append without asking on every frame a hex message.

can you provide a example that work, or a hint what i must modify that the hex data ignored and not calculated with the checksum?

thank you

Hi @softwarecrash

The attached code works on a VE.Can SmartSolar 150/100, which has the same behavior with respect to hex messages.

There was also an error in your code:

for (int j = 0; j <= veEnd; j++)

This should be:

for (int j = 0; j < veEnd; j++)

This change then also requires changes in the part below it that copies new names. Here it should allow veEnd to go beyond the max index and check before copying if this is the case. (I did not yet do this in my code)

With kind regards,

Thiemo van Engelen

vedirectframehandler.zip

hi @Thiemo van Engelen (Victron Energy staff)

thank you for the atached code, i have tryed it. but the behavior is the same, it result in a wrong checksum, so i think in the checksum part it grab ord add more than the checksum byte.

with a mppt device that only send the text message, all okay, but with device was attach a async hex message at every text message it result in a checksum error.

for test i have wrote a short emulator that send two different text messages, but the calculated checksum value is the same for both messages, so i cant find what goes wrong with the calculation of this. or add or missing the start line after hex?

Hi @softwarecrash

We have provided code that works in our setup and we cannot debug your code. That is something you have to do yourself. The only thing we can do is check whether the received data is as expected if you provide a (binary) dump of the data you receive from the MPPT. So the bytes receives from the MPPT during a period of time that spans multiple text and hex frames.

Kind regards,

Thiemo van Engelen

Hi @Thiemo van Engelen (Victron Energy staff)

You are right, your code works perfect!

funny note, it doenst work with the one 150/70... the one test device have some fault, maybe logic level issue, the other works great with the source.

thank you verry much for your support and help!