A Comprehensive Guide to the KQ-130 PLC

Introduction and Background

When designing a communication system for an underwater ROV (Remotely Operated Vehicle), the physical layer of the communication model becomes a critical element of the design problem. For radio waves to penetrate water at a practical depth, say at least a few meters, the wavelength must be below the VLF spectrum (< 30 KHz). This disqualifies the entire domain of commercial wireless solutions including Wi-Fi and BLE and leaving only conducted mediums as available options. (As an aside, if wireless communication is a hard requirement for an underwater ROV, a buoy antenna is something to consider. In our case this was ultimately vetoed due to other constraints.)

In this application, the ROV had a requirement to be supplied with grid / mains power. It was thus imminently practical to consider using power-line communication (PLC) as a method of communication between the ROV and host controller to substantially reduce unit cost. An additional note about this application was the particular sensitivity to cost and schedule, inviting a commercial off-the-shelf (COTS) solution in the form of a module as a preference to an implementation using a discrete IC which would add complexity to circuit design, increasing cost and extending schedule.

The KQ-130 module was discovered as a viable option. (If you can recommend any others, please leave a comment!) This module appears to be manufactured in China and is not available through common US distribution channels. It is also quite aged by now, with some examples dating back to 2006. Thus supply, availability, price, and lead time are highly variable. Given its age, it could potentially be at the end of its component life-cycle. Lastly, the module lacks design documentation for how it operates and its various limitations, as well as design guidelines. Those that exist appear to be poorly translated and often conflict with one another. For all of these reasons, this module is not recommended for use in production, especially for mid-high volume designs.

With all that said, the risk was acceptable in this case because the goal was to build a proof-of-concept prototype that wasn’t intended for production at volume. So the project moved forward with this module in the prototype design. The purpose of this post is to close the documentation gap between this module and the design engineer by sharing what I learned about how this module works and its limitations. Hopefully this removes some of the uncertainty around using this component for their own projects.

Hardware Specifications

Module Ratings

Supply Voltage:	5V
Current Consumption:	300mA (Tx), 12mA (Rx)
Mains / Grid Compatibility:	110 / 220 VAC; 50 to 60 Hz
Operating Temperature Range:	-25 C to 70 C
UART Logic Levels:	TTL

Pin Description

Pin Number / Name	Functional Description
1 / AC Mains	Connect to grid / mains line / hot.1
2 / AC Mains	Connect to grid / mains neutral.1
3 / TX Power	Connect to +5VDC. May be left disconnected for receive-only operation.2
4 / GND	Connect to GND reference of +5V supply, and Tx/Rx UART nets.
5 / +5V	Device power, connect to +5VDC.
6 / Rx	Data input to KQ130 module, connect to Tx of interfaced UART.
7 / Tx	Data output from KQ130 module, connect to Rx of interfaced UART.
8 / Mode	Please see Mode Pin section for detailed information about how to configure this pin.
9 / nReset	Active-low reset signal. Leave floating for operation, pull to 0V for reset. If switching the state of the mode pin without power cycle, the nReset pin must be toggled. Approximate time to boot after reset toggled = 45 seconds.3

1 – The line and neutral may be swapped without affecting functionality. This was tested and verified.
2 – The device can still receive data with this pin left disconnected. This was tested and verified.
3 – It took approximately 45 seconds for a latency test response after receiver reset is toggled.

Operation

This module operates through a UART interface with the parameters listed below. When modules are connected on the same AC power grid, they act as modems which translate the UART data into a carrier wave that then gets received by other modules on the same grid. When the carrier wave is received, it will automatically demodulate and write the data to the interfaced UART. Writing a byte to the Rx pin of one module will transmit that byte to the Tx pins on all modules connected to the same grid. There are some caveats to this description which will be described in later sections, but this is the basic functionality.

UART Configuration

Baud Rate:	9600
Word Length:	8 Bits
Stop Bits:	1 Bit
Parity:	No Parity
Flow Control:	No Flow Control

Mode Pin

Length / Payload Mode (Mode = 0 / GND)

When the mode pin is connected to GND, the module operates in a length / payload mode. While idle, no data is exchanged between modules on the same grid. It therefore behaves very closely to a standard UART. However, there is one caveat: using this mode does require the UART protocol to include the payload size as the first transmitted byte. The value of the first transmitted byte contains the number of bytes that will follow, up to 250. Here is an example of a valid transmission.

In the above example, the first byte in the sequence is 10, indicating that payload which follows will contain 10 data bytes. The bytes in the sequence from 2-11 are those 10 data bytes and contain the user-defined payload. Note that the entire packet is written to the KQ-130 at the once.

There are two types of errors that can occur in this mode. One error is where the user payload is smaller than the first byte. In this event, junk data will be received in place of the missing data. Here is an example of such a transmission. In the below example, the last byte in the sequence (marked N/A) was not actually transmitted, but it was “received” – this byte is junk data.

Another type of error is where the user payload is larger than the first byte. In this event, the extra data byte is lost. Here is an example of an invalid transmission of this type. In this example, the last byte was written to the KQ-130, so it was “transmitted”, but it will not be received by the other KQ-130’s on the grid.

Please see the design considerations section for information on how to develop a protocol which can handle these types of errors.

Streaming Mode (Mode = 1 / Floating)

When the mode pin is left floating (there is an on-board pull-up that pulls it up to 5V), the module operates in constant streaming mode. In this streaming mode, the receiver sensitivity of the modem produces a constant stream of junk data while the transmitter is idle. In this mode it is necessary to utilize a preamble in each transmission in order to be able to parse the byte stream to identify where the transmitted data begins. Here is an example of a byte sequence received.

In this example, the N/A sequence bytes are the junk data, and the 1-5 sequence bytes are the transmitted bytes. The transmitted data begins with the 3-byte preamble 0x5A, 0x5A, 0x5A and this is how it is identified as the start of a valid byte stream. It is followed by a length byte identifying the number of bytes to be read after the length byte, and then the final byte of the packet. Of course this is just an example. The critical requirement in using this mode is to build your protocol in such a way where the start and end of the valid byte stream are identified clearly.

When selecting your preamble byte(s), it is useful to understand the distribution of noise as it is not evenly distributed among all possible values. A large amount of noise was collected by configuring a KQ-130 in streaming mode, and leaving it idle for a long duration. Next, the data was grouped by Hamming Weight and plotted as shown below.

The noise profile heavily favors data bytes with larger quantities of ‘1’ bits. It is therefore advisable to use preamble bytes with a comparatively low Hamming Weight.

Characterization of Performance

Maximum Packet Size

With the mode pin set to 0, the theoretical maximum would be 255 due to the maximum size of the length byte. However, since we have no specification of the buffer size of the KQ-130, I decided to test this experimentally to determine the practical limit. The maximum reliable packet size is 250 bytes (for both modes), not including the length byte, meaning the first packet byte can be 250, with 250 bytes following it (251 total, but 250 effective). Note that if you decide to test this for yourself, you might find that sometimes 251 goes through but not reliably so. I hammered at it with 250 byte packets for quite some time without issue, but 251 causes junk data to be received as the first byte very frequently. Mode = 1 has the same size restriction even though the length is not specified.

Latency

Data Rate = 108.2 bits / second
One-Way Latency = 391.3 ms + (73.95 ms/byte * N)
where N is the packet size in bytes

The test information is included below.

To test this I setup a Raspberry Pi Model 3 B as the master transmitter, and an STM32L475 as the receiver configured to echo the received packets. Before adding the KQ-130 modules I tested a baseline latency using a direct connection between the devices. This was designed to predict the time taken to send and receive the raw data as well as all the driver and processing operations involved, thus when the KQ-130 latency is measured, we can correct for these factors. Here is a flowchart of the process as well as the base results:

Insert graphic here showing process flow and measurement points.

Next I added the KQ-130s in between. The round-trip latency was measured using the same method as before.

The results show excellent linearity – the latency is perfectly proportional to the packet size. This equation can be used as a predictive model of additional latency due to KQ-130 modulation and demodulation. The user application can (hopefully) be tested to establish a baseline latency with the UART prior to adding the module and then superimpose this model to predict total latency. It is also reasonable to divide the model by two in order to estimate one-way latency as this model performs two rounds of the same sequence by the same hardware.

Note: the latency test results above were obtained using Mode = 0. In order to ensure that the operating mode does not affect data speed, a similar test was performed using Mode = 1. The results were just about identical, thus the predictive model above can be used regardless of operating mode.

Sequential Packet Transmission Delay

In the event that a transmitter needs to send two sequential packets, it is important to characterize the time delay required from writing the first packet to the KQ-130 to writing the second packet. First, it was discovered that the delay between these packets depends on the packet size. To characterize this, the test setup from the latency test was used, but the firmware on the receiver was updated to acknowledge two sequential and identical packets. On the transmitter side, the same packet was sent with a variable delay between UART writes to the KQ-130. The minimum reliable delay between packets was measured to be almost exactly one half of the round-trip latency previously measured. Therefore the one-way latency characteristic can be used to calculate the delay between sequential packet transmissions.

Power Consumption

This was tested using a USB port as a power source, so the voltage sag was also measured to more accurately calculate total power consumption.

Quiescent and During Rx = 11.1 mA (@ 5.126 V)
During Tx = 181 – 190 mA (@ 4.67 V)

Additional Resources

Schematic Symbol and PCB Footprint

I have created a schematic symbol, PCB footprint, and 3D model for this module. They are admittedly basic but sufficient to use in a PCB design project. The library is compatible with CircuitStudio / Altium. The 3D model was created using FreeCAD. All files are available here.

Design Tips

Hardware Considerations

Ensure that your power supply has sufficient load regulation to power the KQ130 in transmit mode without affecting any other devices on the 5V rail.

It is recommended to operate this device in Mode 0 (Length / Payload Mode). This greatly simplifies the communications protocol development and also keeps the UART Rx quiet without the need to constantly parse bytes in search of a preamble.

Protocol Development

If using the device in mode 0, then a TLV protocol is an excellent choice because the “L” (length) is built into the KQ130 interface requirements. The first byte of a message is required to contain the value of the total number of bytes in the message. The second byte can be the message type and the third byte can be the message payload.

In our application, the message header defined the message type and designated recipient’s ID, which is very useful if multiple KQ130 Rx devices are on the same grid and need to operate independently.

Furthermore, adding a CRC-7 byte at the end of the message helps prevent communication errors. An example data format is provided below.

Conclusion

This module ended up being very easy to implement in a prototype / proof of concept design stage, especially for the price. Once the initial uncertainty of how it operates was cleared up with these characterization tests, implementing a communication solution was very exciting! There’s few better feelings to an engineer than when something just works. I hope that some of this information has been helpful to you. If you have any questions, feedback, or general comments, please leave one below or contact me directly at vlad@qharmonics.com.

Cheers!
-Vlad