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.

PLC-Lite Questions



Hi Team,

Currently using PLC over 48-V. 

I have some specific questions regarding PLC and PLC-Lite:

1.)  I'd like to have enough information to determine BOM cost per node.

2.)  Can this solution be implemented on a 48V, 500 Watt power line system?

3.) Anticipated Star topology from the 48V supply.  Approximately 12 nodes at a distance of 500 feet.  Would PLC work for this topology?

4.) Is there documentation on PLC-Lite protocol other than the "Host Message Protocol Specifications?"

5.) What is the Maximum Transmission Unit for a PLC-Lite power line packet?

Thank you,

Mauricio Solis

  • Hi Richard,

    Below are my answers.
    1.) I'd like to have enough information to determine BOM cost per node.
    [IHK] The BOM is inside in the HW directory in the package.

    2.) Can this solution be implemented on a 48V, 500 Watt power line system?
    [IHK] Yes, it can be implemented. Our solution is independent of voltages if the high voltage coupling capacitor is carefully chosen.

    3.) Anticipated Star topology from the 48V supply. Approximately 12 nodes at a distance of 500 feet. Would PLC work for this topology?
    [IHK] Yes, I think it will work with this distance because 500 ft is considered as short distance.

    4.) Is there documentation on PLC-Lite protocol other than the "Host Message Protocol Specifications?"
    [IHK] There are other documents in the package. Please take a look at the folder "./Documentation/"

    5.) What is the Maximum Transmission Unit for a PLC-Lite power line packet?
    [IHK] Do you mean how many bytes it can transmit for PLC-Lite? For PLC-Lite, it is 100 bytes.

    Regards,
    Il Han
  • One additional question. Is there a PCLite "modem image" available? In other words an image we can use that does not require us to write any custom code on the C2000, but just allows us to communicate from our processor via serial port to the C2000 running the PCLite Stack.
  • Hi Steve,

    Yes, that's correct. Thanks.

    Wonsoo

  • Hello,
    A few follow on questions to the above:
    1. Is the referenced "Modem" image the plc_lite.hex included with this package: www.ti.com/.../TI-PLC-PLCLITE

    2. The eval kit ecosystem involves two PLC development boards, and the host computer. The host computer runs the Zero Configuration GUI. Does the GUI format messages according to the Host Msg document when it transmits to the dev board? Or, is there another framing header on top?

    3. The Host message specification included with the package at 1 states: "The contents of the DATA_TRANSFER are determined by the current device mode (see GET_SYSTEM_INFO)." for a DATA_TRANSFER message. The GET_SYSTEM_INFO section only describes two Mode types, but does not elaborate on the contents of the data message. Is there additional documentation describing these contents?

    3a. Empirically, there is additional data between the Header described in the Host Msg Spec and the actual payload as referenced in the same specification, is this additional data documented anywhere. Example, to send the word "test", one sees:
    00 00 24 00 22 ca 00 00 03 00 a0 aa 00 00 00 00
    00 00 00 00 00 00 01 00 00 00 01 00 00 00 04 00
    00 00 00 00 74 65 73 74

    Where bytes 0-3 are the message header, and bytes 36-39 are the payload "test". I assume bytes 30-35 represent the content referenced in the host message specification, but what are bytes 4-29 (all ranges inclusive)?

    Thanks,
    -Jason
  • Hi Jason,

    1. You can use either .hex or .out, which are identical with different binary format. If you are using F28035 device, please check out the binary under F2803x folder.


    2. The host message spec covers all the necessary messages to bring up your application.

    3. Sorry for missing the information. We are updating the information in the host message spec. In the meantime, please refer to the following information for "Data". We are giving full flexibility on the framing via configurable options.
    - The following example shows the "Data" format. Depending on the configuration via LOAD_SYSTEM_CONFIG, you can manage your Data format.
    - If you don't want to filter any incoming data (via disable MAC Rx address filter), you can just fill out application data without address fields and RX wil accept all the incoming data.
    - If you want to filter incoming data (via enabling MAC RX address filter), you can enable the MAC Rx address filter, set the desired address length, and add Address 1/2/3 to be acceptable by the RX. The idea behind here to allow 3 addresses is to provide unicast/multicast/broadcast addressing options. 

    3a. Here is parsing information for the data. This is received data from the line.

    00 00 24 00: message header (00: message type: data, 00: oringiator (this is RX), 0x24: message size)
    22 ca 00 00: CRCs 
    03 00 : Data transfer indication
    a0 aa 00 00 00 00 00 00 00 00 00 00 01 00 00 00 01 00 00 00 04 00 00 00 00 00 74 65 73 74: This is data. I believe that this is all application-specific header (not-related to the PLCLite). We've added some application header for message tranfer and file transfer examples, which is not required in your application.

  • Thank you for the information. If I understand correctly, I should be able to construct a message and omit the "application specific data" but still use the plc_lite.hex image, correct?

    I am attempting to the above, but need a missing reference for the CRC calculation. The specification states "See Error! Reference source not found.Error! Reference source not found. in the appendix for CRC details". So an appendix related to the CRC seems to be missing. Can you point me to a reference implementation or provide the source for the implementation used by PLC-Lite?

    *Note: I attempted the above message without a CRC and it did not work.
  • TI_PLCLite_Host_ Msg.pdfYes, that's correct.

    Please, refer to the section 2.3 in the attached document. The CRC is recommended for your actual development but if this is only for testing purpose you can simply fill out all zeros in the CRC portion and then the firmware will ignore the CRC.

    Thanks.

    Wonsoo

  • Thank you for the updated document!

    (note that the version I referenced is what is bundled with the current software, so other users may have the same issue)

    Regarding your comment,"The CRC is recommended for your actual development but if this is only for testing purpose you can simply fill out all zeros in the CRC portion and then the firmware will ignore the CRC."

    I observe different behavior. Using the latest eval kit software, the firmware does appear to expect a CRC for the message header. I attempted to send the above message without a CRC and the receiver did not get the message. I tried a new message without a CRC and it too failed. Once I calculated the CRC for the header both messages worked as expected.
  • Probably my explanation was not clear. I meant that you need to keep the header/payload CRC sub-fields but with all zero values. Did you fail to get response with this? Removing the CRC sub-fields from the message will cause error (no response because the message is incomplete).

    Thanks.
    Wonsoo
  • I think your explanation was clear, it is our results that differ. I did indeed keep the CRC fields, populating them with zeros instead of the CRC, and the receiver did not receive the message.
  • Wonsoo,
    Thanks so much for your help with these PLC-Lite questions. I have another question regarding the "modem" imaged referenced earlier, which I'll assume to be the plc_lite.hex included with the eval kit software.

    Can the C2000 application code (i.e. the plc_lite.hex) be updated through the serial port from a host? The eval kit references using a JTAG protocol, but are there other options, or would this require special application code on the C2000?

    Note that the application image need not be .hex and might be an image better suited for serial updating. My main concern is whether updating the application on the C2000 from a host requires special programming or whether it is already built in to the PLC-Lite firmware stack.
  • No, the PLCLite supports the JTAG option only. If this is really required feature, you might consider another TI PLC product such as G3-PLC or PRIME (www.ti.com/.../TIDM-SOMPLC-F28PLC84).

    Thanks.
    Wonsoo
  • Ok. Is the source code for the plc_lite modem image something that can be made available/licensed assuming appropriate documentation (NDAs, whatever is appropriate, etc) are in place? For example, if our application wished to leverage one of the unused IO pins on the C2000, or even implement the previously mentioned application updating?
  • It has been some time, is there any reply to the above question?  Is the PLCLite modem image source code something that can be made available?

  • No as of now the source code is not available to be customized.
  • Does example source code exist to assist and accelerate customers in developing PLC-Lite solutions?  If no source exists, is object code with documented APIs available, perhaps under licensing agreements?

    If yes is not an answer to any of the above, what is the expectation, that customers design their own PLC-Lite software from scratch?