This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

EVM430-I2040S: Serial communication protocol

Part Number: EVM430-I2040S
Other Parts Discussed in Thread: CC3200, MSP430I2041

As the title states, I'm using the EVM430-i2040SUBMTR EVM.

I'll be connecting a host microcontroller (specifically, the CC3200) to this board to use it in a project.

This EVM simplifies the project because we do not need to design/program the metrology of the MSP430i2041 since the board comes pre programmed with demo firmware that measures parameters (voltage, current, power, PF, frequency etc.) and sends it to the metering demo software on the computer.

I've read through the documentation of the EVM (SLAA638 & SLAU587) and am attempting to decode the protocol  so that I can send commands & read the measured parameters from the CC3200.

I connected the EVM to a load and used a serial port sniffer tool to capture the commands the TI demo program was sending to the EVM, and the response packets the EVM was sending back to the demo program (on the PC).

I managed to capture upstream & downstream packets and decoded them using the formats given in SLAU587 (Chapter 4 - "Serial Communication Commands"). The packet formats, values in the headers and lengths match what I expect based on the documentation, but I can't get meaningful readings for the actual measured parameters: Voltage, Current, Power etc.

For example:

The EVM sent the computer this:

FE FE FE FE 68 99 99 99 99 99 99 68 23 22 61 80 7C 92 03 00 F4 21 1F 00 15 48 07 00 CF FC FF FF D4 49 07 00 FA D8 BD 13 FA 2D 00 00 53 F2 E1 FF 10 16

Based on the documentation, this is a response to a preceding packet "HOST_CMD_GET_READINGS_PHASE_n"

I tried decoding the values after "FE FE FE FE 68 99 99 99 99 99 99 68 23 22" since this is the header + length (0x22 = 34, which is correct).

61 80  - these two bytes (offsets 0 & 1) are RSPH & RSPL

7C 92 03 00 - Offset 2, Width S32 (Signed 32?) = Voltage in mV        In BIN = 01111100100100100000001100000000, as a signed 32bit int: 2089943808 mV?

F4 21 1F 00 - Offset 6, Width S32 (Signed 32?) = Current in μA         In BIN = 11110100001000010001111100000000,  as a signed 32bit int: -199155968 μA ?

15 48 07 00 - Offset 10, Width S32 (Signed 32?) = Active power in mW        Similarly.....

CF FC FF FF - Offset 14, Width S32 (Signed 32?) = Reactive power in mW

D4 49 07 00 - Offset 18, Width S32 (Signed 32?) = Apparent power in mW

FA D8 - Offset 22 Width S16 (Signed 16?) = Power factor in 0.001          Decimal (Signed 16bit) = -1320 (I noticed that all readings have FA D8, almost no variation here)

BD 13 - Offset 24, Width S16 (Signed 16?) = Frequency in 0.01 Hz             BIN = 1011110100010011, signed 16b = -17133   unsgined int =  48403. SLAU587 says 0.01Hz, which would make it 48403*0.01 = 484.03Hz

FA 2D 00 00 - Offset 26, Width S32 (Signed 32?) = Voltage Channel DC Offset

53 F2 E1 FF - Offset 30, Width S32 (Signed 32?) = Current Channel DC Offset

10 16 - Checkum + End Byte

As I mentioned previously, these were captured using a serial sniffer, so the TI demo tool was running simultaneously and displaying what seemed to be readings that were accurate:

The serial sniffer is in the background, and had received packet 2582 when I captured the screenshot. (The packet I used as an example is packet 2566).

tldr; could you help me decode the values of voltage, current, power etc. in the packet to the actual values that are displayed by the demo GUI?

 

  • Adding a few packets that were sent to the PC before the screenshot was taken:

    2172: (HOST_CMD_GET_EXTRA_READINGS_PHASE_n because xx xx 23 22 69 80 xx xx is this type)
    FE FE FE FE 68 99 99 99 99 99 99 68 23 22 69 80 88 4A 07 00 22 01 00 00 28 93 03 00 3D 1E 1F 00 0F 01 51 02 00 00 00 00 00 00 00 00 00 00 00 00 2B 16

    2238: (HOST_CMD_GET_READINGS_PHASE_n because xx xx 23 22 61 80 xx xx is this type)
    FE FE FE FE 68 99 99 99 99 99 99 68 23 22 61 80 0F 93 03 00 CF 25 1F 00 24 4A 07 00 43 FB FF FF E7 4B 07 00 FA D8 CA 13 FD 2D 00 00 DC EB E1 FF AE 16

    2254: (HOST_CMD_GET_EXTRA_READINGS_PHASE_n)
    FE FE FE FE 68 99 99 99 99 99 99 68 23 22 69 80 5F 48 07 00 FB 03 00 00 B9 92 03 00 40 1A 1F 00 26 01 27 02 00 00 00 00 00 00 00 00 00 00 00 00
    57 16

    2320: (HOST_CMD_GET_READINGS_PHASE_n)
    FE FE FE FE 68 99 99 99 99 99 99 68 23 22 61 80 12 93 03 00 C1 24 1F 00 EE 49 07 00 D1 FA FF FF AE 4B 07 00 FA D8 C8 13 FF 2D 00 00 65 F9 E1 FF 56 16

    2336: (HOST_CMD_GET_EXTRA_READINGS_PHASE_n)
    FE FE FE FE 68 99 99 99 99 99 99 68 23 22 69 80 35 47 07 00 13 F5 FF FF 88 92 03 00 40 17 1F 00 28 01 36 02 00 00 00 00 00 00 00 00 00 00 00 00 11 16

    2402: (HOST_CMD_GET_READINGS_PHASE_n)
    FE FE FE FE 68 99 99 99 99 99 99 68 23 22 61 80 E8 92 03 00 D1 23 1F 00 63 49 07 00 EB FC FF FF 20 4B 07 00 FA D8 B8 13 FC 2D 00 00 EC EF E1 FF A7 16

    2418: (HOST_CMD_GET_EXTRA_READINGS_PHASE_n)
    FE FE FE FE 68 99 99 99 99 99 99 68 23 22 69 80 43 46 07 00 DF F0 FF FF 39 92 03 00 E6 14 1F 00 4D 01 52 02 00 00 00 00 00 00 00 00 00 00 00 00 7A 16

    2484: (HOST_CMD_GET_READINGS_PHASE_n)
    FE FE FE FE 68 99 99 99 99 99 99 68 23 22 61 80 58 92 03 00 98 1F 1F 00 3D 47 07 00 07 FC FF FF FD 48 07 00 FA D8 BA 13 F9 2D 00 00 D0 EC E1 FF 88 16

    2500: (HOST_CMD_GET_EXTRA_READINGS_PHASE_n)c
    FE FE FE FE 68 99 99 99 99 99 99 68 23 22 69 80 94 45 07 00 77 F8 FF FF 0C 92 03 00 AD 12 1F 00 3B 01 43 02 00 00 00 00 00 00 00 00 00 00 00 00 E1 16

    The TI demo tool displays readings that seem realistic using the same packets, so I'd like to know exactly how the tool decodes the packets.
  • Hi,

    Looking through the hex values that you saw and the values in the TI sniffer window, I believe the issue here is that the bytes are being transmitted in little endian format. So, you should see the values that you expected if you flip the bytes and then redo your conversion to decimal values. For example, for the voltage in for first example, 7C 92 03 00 should be flipped to 00 03 92 7C, which is equal to 234108, which is 234.108V, which makes sense with what you showed with the TI sniffer.

    Hope this helps,
    Nathan
  • Yes, that seems to solve my issue. All the readings make sense now.

    I still have a question about power factor:

    The TI demo tool displays "0.999L" for new unity PF readings (actually slightly leading since active power reads 1429W, Reactive = -2.419W for Apparent = 1430W). The values in the packets around that instant translate were "D8 FA", which is -9990 after translating S16 HEX to decimal. 

    When using a resistive-inductive load, the TI tools displays PF as "0.804C" ,with Active power = 283.468W, Reactive= 208.868W & Apparent = 352.479W. The values in the serial packets are "1f 63" (consecutive packets have "1F 67", 1F 68"). 

    "1F 63" translates to 8035. The user manual states PF is in 0.0001, but 8035 * 0.00001 = 0.8035 seems more likely

    • Does the TI tool display "L" for capacitive tools and "C" for inductive? (Seems to be opposite of what it should be based on my test results)
    • Is the conversion factor 0.00001 instead of 0.0001 (as stated in the manual)?

  • Hi,

    I think the reason you are seeing "C" for the resistive-inductive load is that your power factor value is less than 1. I believe that if your value is less than 1 then you will see the opposite indicator of what you are expecting. This is really just a matter of notation, and I don't think there is any issue between your test results and what you are expecting.

    As for the conversion factor, 0.0001 * 8035 = 0.8035. I think your math was just off by a factor of 10.

    Regards,
    Nathan
  • Sorry; typo:

    SLAU 587 states "Power factor in 0.001", but 8035*0.001 = 8.035

    I meant to ask whether it is 0.0001 (which gives 0.835) instead of 0.001 (which the manual uses). [I incorrectly added an extra zero to both numbers in the previous post].

  • Hi,

    Thank you for clarifying that. Based on what you are seeing, yes it looks like it should say 0.0001. I will look into seeing if that document needs to be changed, but, for your purposes, I think you can just assume 0.0001.

    Regards,
    Nathan

**Attention** This is a public forum