Problem Communicating with Energy Monitor

Hardware
1

Hello,

I am running into an issue communicating with a Current Monitoring Controller (XB2CMAC6XXXA_DLCT27CL20-20-amp)
I query the module every 15 seconds with the following command:
0xAA 0x0E 0xBC 0x32 0x0A 0x54 0x92 0x6A 0x01 0x01 0x06 0x00 0x00 0x04 0x55 0x13 0x74

Everything works great, except that every 2 to 4 hours after continuos polling (could not find a pattern here), the module responds with the follwing response:

0xAA 0x13 0x00 0x31 0xBF 0x00 0x04 0xF2 0x00 0x03 0x2E 0x00 0x28 0x21 0x00 0x05 0xC9 0x00 0x00 0x00 0x2E 0xAA
Basically, the module is replacing byte 22 (Fusion API Checksum (8-Bit Sum of Bytes 3-21)) with a Fusion API Frame Header.

If I send a new command after I receive this response, the response to that new command is sent by the module to the host computer withoute the “Fusion API Frame Header”. Exampple:
0x13 0x00 0x31 0xCC 0x00 0x05 0x01 0x00 0x03 0x2D 0x00 0x27 0x27 0x00 0x05 0xBF 0x00 0x00 0x00 0x45 0x4

What I have tried once I recieve the initial wrong response with the Fusion API Frame Header at the end of the message:

  1. I’ve tried to close and re-open the connection before sending a new command.
  2. I’ve tried waiting up to 10 hours before sending a new command.
  3. I’ve tried sending the “meassuring” command (decimal 1 in byte 9) or the “device information” command (decimal 2 in byte 9)

But, in all tests, once I recieve the initial wrong response with the Fusion API Frame Header at the end of the message, if I send a new command, the response to that second comand is received without the 0xAA Api Frame Header.

Also in all cases, once that response to the second message is received without the 0xAA header, the module responds as expected for the following 2-4 hours.

So, just to clarify the message flow:
[OPEN COM PORT]
“device information”
→ 0xAA 0x0E 0xBC 0x32 0x0A 0x54 0x92 0x6A 0x02 0x00 0x00 0x00 0x00 0xFE 0x55 0x07 0x5C
← 0xAA 0x07 0x04 0x14 0x06 0x01 0x00 0x00 0x1F 0xEF

“meassuring command”
→ 0xAA 0x0E 0xBC 0x32 0x0A 0x54 0x92 0x6A 0x01 0x01 0x06 0x00 0x00 0x04 0x55 0x13 0x74
← 0xAA 0x13 0x00 0x1A 0x4E 0x00 0x04 0xF9 0x00 0x05 0x56 0x00 0x06 0x1B 0x00 0x0B 0xF5 0x00 0x00 0x00 0xE1 0x7F

[after 2 to 4 hours of looping]
→ 0xAA 0x0E 0xBC 0x32 0x0A 0x54 0x92 0x6A 0x01 0x01 0x06 0x00 0x00 0x04 0x55 0x13 0x74
[received message with header at the end instead of Fusion API Checksum]
← 0xAA 0x13 0x00 0x31 0xBF 0x00 0x04 0xF2 0x00 0x03 0x2E 0x00 0x28 0x21 0x00 0x05 0xC9 0x00 0x00 0x00 0x2E 0xAA

→ 0xAA 0x0E 0xBC 0x32 0x0A 0x54 0x92 0x6A 0x01 0x01 0x06 0x00 0x00 0x04 0x55 0x13 0x74
[received non-header message]
← 0x13 0x00 0x31 0xCC 0x00 0x05 0x01 0x00 0x03 0x2D 0x00 0x27 0x27 0x00 0x05 0xBF 0x00 0x00 0x00 0x45 0x4

[loop again for 2 to 4 hours]
→ 0xAA 0x0E 0xBC 0x32 0x0A 0x54 0x92 0x6A 0x01 0x01 0x06 0x00 0x00 0x04 0x55 0x13 0x74
← 0xAA 0x13 0x00 0x1A 0x4E 0x00 0x04 0xF9 0x00 0x05 0x56 0x00 0x06 0x1B 0x00 0x0B 0xF5 0x00 0x00 0x00 0xE1 0x7F

2

So the response from the board in question is:
0xAA 0x13 0x00 0x31 0xBF 0x00 0x04 0xF2 0x00 0x03 0x2E 0x00 0x28 0x21 0x00 0x05 0xC9 0x00 0x00 0x00 0x2E 0xAA

If you take a look at this packet you will see a header byte of AA followed by 13. The 13(hex) indicates the length of the payload in this packet is: 19 bytes long, so the rest of the packet payload is:
0x00 0x31 0xBF 0x00 0x04 0xF2 0x00 0x03 0x2E 0x00 0x28 0x21 0x00 0x05 0xC9 0x00 0x00 0x00
The next byte after the payload 0x2E is the checksum. The 0xAA at the end is the first byte of the next packet.

My assumption is your software is written to simply read in all bytes available on the socket/port. I do not recommend this. I recommend checking to see if there are bytes available in the loop. If there are see if it is a 0xAA byte, if so then read the next byte which indicates the length of the packet, then read in that many bytes +1 for the check sum, and then output that full packet to the rest of the application.

For one reason or another you are getting two consecutive packets in. This is more than likely just due to the structure of the routines sending/receiving data from the board.

3

Travis,

My software is written to constantly read bytes from the port and divide packets by the 0xAA delimiter. Once it finds the delimiter, it calculates the length of the message based on byte 2 (19 bytes in this case).

If you look at the documentation found here:

This command…
0xAA 0x13 0x00 0x31 0xBF 0x00 0x04 0xF2 0x00 0x03 0x2E 0x00 0x28 0x21 0x00 0x05 0xC9 0x00 0x00 0x00 0x2E 0xAA
… is supposed to be 22 bytes in length, which it is. But byte 21 (in this case 0x2E) is supposed be the checksum of Bytes 3 through 20, and byte 22 (in this case 0xAA) is supposed to be checksum of bytes 3 to 21.
Given that the last byte (byte 22) is a header byte (0xAA) it seems the message is missing a byte.

More specifically, Byte 21 (0x2E) seems to be the correct i2C checksum, but the “Fusion API Checksum” seems to be missing in the message.

Am I approaching this in a wrong way?

4

Travis,

Just to add to the conversation and to clarify, once I receive a message like this:
0xAA 0x13 0x00 0x31 0xBF 0x00 0x04 0xF2 0x00 0x03 0x2E 0x00 0x28 0x21 0x00 0x05 0xC9 0x00 0x00 0x00 0x2E 0xAA

… there are no further bytes to be read on the buffer. But if my software issues a new command, the response to that command has no 0xAA header. It is not that the last byte (0xAA) is the header of a new message. It is the last available byte in the buffer until a new command is sent to he board.

5

As best I can tell the byte array shown above should never happen. it appears a byte is missing from the packet somehow.

I’m not sure if this is a bug in firmware or a malfunction of the software receiving the packets. It’s hard to say for sure.

6

Travis,

All I can say is that the software on my end has been used to constantly communicate with a wide array of NCD modules for the past 10 years without any problems. I don’t see how my software would replace the last byte of a message with a 0xAA and then remove the header from the next message received…

In case you are interested, I offer myself to run a software of yours against the board if you see any value in confirming if this is a board issue or not.

As for me, I’ve already written a compensation function for every time I receive a package that includes the 0xAA in the checksum position, which is not ideal but gets the job done.

Cris.-

7

Did you try base station?
In the base station, you can view the bytes it’s sending to read current.

8

Hello Bhaskar.

While I understand that Travis cannot be sure if this is a bug in firmware or a malfunction of the software receiving the packets, there is no doubt in my mind that the problem is not my software.
I’ve been using it to communicate with NCD boards reliably for the past 10 years, and I can already view the bytes coming in and out the port. I did not post on the board until I could be absolutely sure that this was not a problem on my end.

I was just offering my help in case you want/need to confirm that this is not a problem on my software’s end but for me, looking at Base Station bytes would not give me any new insights.

I could leave base station running for a couple of hours until the error occurs, but I would also not be sure at what behavior I should look from Base Station to confirm that the wrong packet format actually takes place.

Cris.-

9

Just to add, and to make triple sure, this is an example of the exact, raw bytes received via the TCP socket in response to a “sensor read” command. Again, this is one every couple of hours, it is not constant.

After the last 0xAA there are no more bytes available to read:

0xAA 0x13 0x00 0x16 0x3C 0x00 0x02 0x6E 0x00 0x02 0x1C 0x00 0x06 0xC1 0x00 0x0B 0x37 0x00 0x00 0x00 0xE9 0xAA

The response to the next command (either a Sensor Read or a Board Init) will arrive without the leading 0xAA

Cris.-