MSP430AFE253: Issue with serial communication protocol to show the Voltage and etc. (Chinese protocol - DL/T645)

Part Number: MSP430AFE253

Here is a test report for MSP430AFE253.

www.ti.com/.../slaa488.pdf

On the page 22 of this document we will have "GUI Read Out Metering Parameter" which say by sending 6100 you will receive Phase one information out of the energy meter.

I've wrote a code with Win32 Console APP. in C++ to Read/Write the serial port. 6100 or technically 61 hex and 00 hex are the digits that I need to send toward the meter, right? But for some reasons this my meter is not responding!

Am I doing something wrong?

The GUI (given by the following link) on the other hand, is getting all the voltages from all phases: 0x61 0x62 0x63. 

  www.ti.com/.../slaa488.zip

Therefore, this tells me that I am not sending the right character to the serial port and perhaps missing other characters!

Can you please advise?

  • Hello,

    I'm looking into your question and will respond shortly.

    Regards,

    James

    MSP Customer Applications

  • In reply to James Evans:

    Thank you James,

    To be more specific and detailed here is what I send according to the pdf file.

    char   lpBuffer[15] = { 0x68, 0x99,0x99,0x99,0x99,0x99,0x99,0x68,0x23,0x06,0x61,0x00,0x01,0x00,0x16};

    In my meter, I can see only the last character (0x16)

    I believe that there must be something missing in here!

  • In reply to CaEngineer:

    Hello,

    Thank you for the additional details and especially for the exact packet that you're trying to send.

    First, looking at the SLAA488 Test Report document, there seems to be a discrepancy for the nR/W (Notify Command Direction) byte. In Section A.2 on page 21, it says that 0x80 denotes a command from GUI to F4481, 0x00 denotes F4481 feedback to GUI. However, in Section A.2.1 on page 22, the command from GUI to F4481 uses 0x00, and the command from F4481 to GUI uses 0x80. Perhaps this byte represents where the next command will come from instead of the present command? I'm not really sure, since I don't have the hardware to test this on.

    Since you're sending this command from the PC to the F4481, I see that you're using 0x00. I don't think this is the main issue, but you could try using 0x80 instead and see if that works. If it does, I'll need to submit feedback to have the document updated accordingly.

    More importantly, I think that there are two other issues that are preventing this command from working properly.

    1. First, you're setting the Length byte as 0x06 when you're only sending one byte of data, 0x01. Try changing the Length byte to 0x01.
    2. Next, you've set the CS (checksum) byte to 0x00. This byte equates the algorithm sum of the Packet_body (from 0 to len+9). Here, the checksum would be calculated across the H_CMD byte (0x61), the nR/W byte (0x00 or 0x80, see my comments about this above), and the Data byte(s) (0x00). Try changing the CS byte to the checksum.

    Perhaps, you could put a logic analyzer on the UART lines to sniff what the packets from the GUI look like too.

    Hopefully this helps.

    Regards,

    James

    MSP Customer Application

  • In reply to James Evans:

    James,

    So far I corrected my array according to what you said.

    char lpBuffer[15] = { 0x68, 0x99,0x99,0x99,0x99,0x99,0x99,0x68,0x23,0x01,0x61,0x80,0x01,0x00,0x16};

    However, I don't get the checksum part.
  • In reply to CaEngineer:

    Can please advise the data and sum?

    H CMD: 0x61  Voltage phase 1
    nR/W: 0x80 as you said
    Data: ??
    Sum: ??
  • In reply to CaEngineer:

    Would you mind if you type the whole array for me please? I am totally confused!
  • In reply to CaEngineer:

    I'd definitely recommend searching online for the DL/T645 Multi-function watt-hour meter communication protocol documentation. It talks about the protocol structure and framework in great detail. After looking through these, I found that 0x00 denotes Master to Slave direction and 0x80 denotes Slave to Master direction. Let's keep the nR/W byte as 0x00 for now.

    Now, the checksum is calculated over all the bytes in the Packet_body field. Basically, the checksum is the sum of all bytes, then mod by 256. So, let's try this packet.

    char lpBuffer[14] = {0x68,0x99,0x99,0x99,0x99,0x99,0x99,0x68,0x23,0x02,0x61,0x00,0x61,0x16};

    I removed the single data byte 0x01 from before, which didn't seem to be necessary. Also, I changed the Length byte to 0x02 because we're using the H_CMD and nR/W bytes. Lastly, (0x61 + 0x00) mod 256 equals 0x61 for the CS byte.

    Regards,

    James

    MSP Customer Applications

  • In reply to James Evans:

    James,

    I searched a lot about this chinese protocol. There is only two sources availablr. One is TI and the other one a Chinese Website. But unfortunately there is no good example avilable.

    I will test your code on Tues. as I am not at work right now and we are off for 3 days unfortunately! Thank you for your help. I appreciate that. It is not easy to get a hold of someone who is really savvy about this. I will keep you posted for sure.

  • In reply to CaEngineer:

    1 year ago, I used energy library code and rebuilt it to see if I can recreate the executeable file for the gui to develope it using Cygwin. That failed as changing in one file needed changes in other files at thecsame time which was really confusing. After all, dlt645 was a mysterious protocol to understand how it works. Hopefully I will get back to you with good news!
  • In reply to James Evans:

    James Evans

    char lpBuffer[14] = {0x68,0x99,0x99,0x99,0x99,0x99,0x99,0x68,0x23,0x02,0x61,0x00,0x61,0x16};

    James,

    I just tested your code, unfortunately it did not get back to me with any characters!

    0x61 is supposed to give me phase 1 readings.

    What else do you recommend me to try?