PLC & Go

Introduction

PLC & Go is a Microchip application note designed to help users quickly start with Power Line Communications (PLC). It implements a basic low data rate PLC application (up to 200 kbps) using OFDM modulation, supporting both point-to-point and multi-point communications.

The PLC & Go application facilitates a chat-like communication between two or more end points using Microchip PLC modem boards. In this setup, PCs are connected via a serial interface (USB, UART) to Microchip evaluation boards acting as PLC modems. Each end point can transmit messages, which are then received by other end points in the network. The application allows users to configure various PLC parameters, including modulation type, modulation scheme, and transmission band (if the evaluation board supports multiple bands).

The PLC & Go chat application is built upon the physical layer (PHY) of advanced PLC standards like PRIME and G3-PLC. It leverages the speed, robustness, and frequency band profiles defined by these PHY layers. For simplicity, it omits advanced networking features found in the MAC layers of PRIME and G3-PLC, as these are not required for the basic point-to-point or point-to-multipoint communication scenarios described in this note. Microchip offers full PRIME and G3-PLC solutions; more information is available on the Microchip website and the PRIME Alliance and G3-PLC Alliance websites.

Table 1 summarizes the Microchip evaluation kits compatible with PLC & Go, along with their supported communication profiles and band-plans.

Table 1. Microchip Evaluation Kits and Supported Frequency Bands

Notes:

1. The hardware of the PL360G55CF-EK board supports multiple bandplans. The PLC & Go example uses the CENELEC-A bandplan by default.

Microchip PLC Solution Overview

Microchip's PLC solution is flexible, offering designs optimized for various frequency sub-bands below 500 kHz. Users can select a band based on application restrictions and desired communication performance, which can be influenced by different types of noise sources in the PLC channel.

Figure 1 illustrates the frequency band profiles provided by G3-PLC and PRIME, adhering to European (CENELEC), North American (FCC), and Japanese (ARIB) regulations.

Figure 1. FCC, ARIB and CENELEC Limits vs PRIME and G3-PLC Bands

Textual description of Figure 1: A chart depicting frequency band profiles. It shows the CENELEC band (3-148.5 kHz) with G3-PLC CEN-A and CEN-B channels, the FCC band (10-490 kHz) with G3-PLC FCC and PRIME channels (CH3-CH8), and the ARIB band (10-450 kHz) with G3-PLC ARIB and PRIME channels. The chart indicates the frequency ranges and the channels used by G3-PLC and PRIME within these regulatory bands.

Target applications for this technology include home and building automation, smart lighting, equipment control over DC lines, solar energy systems, and alarm systems.

1. Application Example

Microchip's PLC & Go demonstrates a point-to-multi-point chat application built on the PHY layer of state-of-the-art PLC protocols such as PRIME and G3-PLC.

This application example is part of the Microchip PLC software deliverables, available for download from the Microchip website. The phy_plc_and_go application can be used with Microchip G3-PLC stack version 1.4.1 or later, and Microchip PRIME v1.4 stack version 14.03.02 or later, on any Microchip platform implementing the PL360 device as a PLC modem.

The example assumes a host device (e.g., a PC) connected via a serial interface (USB, UART) to a Microchip evaluation kit functioning as a PLC modem.

Figure 1-1 provides an overview of the minimum hardware and firmware resources required to run PLC & Go. The example utilizes two PL360G55CF-EK evaluation kits as PLC modems. Each PL360G55CF-EK board features a SAMG55 microcontroller running the "PLC & Go" application and a PL360 modem for power line communications, handling the selected PLC physical (PHY) layer.

Figure 1-1. PLC & Go Block Diagram for PL360G55CF-EK Boards

Textual description of Figure 1-1: A block diagram illustrating the PLC & Go setup. It shows a PC connected via USB to a PL360G55CF-EK evaluation board. The board internally comprises a SAMG55 microcontroller (host) running application tasks (app_console_task, app_phy_ctl_task), a Host controller, SPI interface, PHY firmware, and the PL360 PLC modem. The PC communicates with the evaluation board via a serial interface (UART). The diagram also shows the connection to the power mains.

The PLC & Go application exchanges data with the PC through a serial port using a terminal emulator. Figure 1-2 shows an example using TeraTerm. The serial port settings are: 921600 bps, 8 data bits, no parity, 1 stop bit, and flow control.

Upon opening the serial port, the PLC & Go application displays information about the hardware platform and firmware. It then waits for a message to be sent, which occurs upon receiving a carriage return character or reaching the maximum PLC data message length. Sending the ASCII character 0x13 (CTRL+S) opens a configuration menu.

The PLC & Go application enables users to:

• Configure modulation type and modulation scheme.
• Configure the transmission band (if the Microchip evaluation board supports multiple bands).

Additionally, the application provides details on transmitted messages (length) and received messages (modulation type and scheme, signal quality), which can be viewed in the terminal emulator on the PC.

1.1 Initialization

In the phy_plc_and_go project, PLC initialization is handled by calling the phy_ctl_pl360_init() function within main(). This function configures the ATPL360 descriptor and initiates the loading and initialization of the PL360 firmware binary.

1.1.1 PLC Hardware Initialization

Hardware for PLC communication is initialized by the atpl360_init() function, which requires a HAL wrapper as a parameter. The HAL wrapper provides functions to interface with the hardware, located in sam/services/plc/pplc_if/atpl360/pplc_if.c.

The phy_ctl_pl360_init() function sets up the necessary callbacks for event management. These include:

• data_indication: Managed by _handler_data_ind() to process received PLC messages.
• data_confirm: Managed by _handler_dat_cfm() to process the results of sending a PLC message.
• exception_event: Managed by _handler_exception_event() for handling exceptions.
• Add-on events are not used in this example.

The PL360 device is enabled by loading its binary firmware using the _pl360_enable() function.

1.2 Event Handling

To manage pending events from the PL360, the atpl360_handle_events() function is called within the main loop, typically inside phy_ctl_process().

The phy_ctl_process() function handles PL360 exceptions and checks for pending events. It includes logic for clearing exception flags and reconfiguring parameters if an exception occurs. It also calls _setup_tx_parameters() to configure G3-PLC transmission parameters.

Note: An exception is expected during initialization after loading the firmware binary due to a PL360 reset.

1.3 Transmission

To transmit a message in the PLC & Go application, the phy_ctl_send_msg() function is called with a pointer to the data buffer and the data length. The message length is included in the first two bytes of the data buffer for reception.

Messages transmitted by the PL360 require a header containing transmission parameters. These, along with the data, are stored in the sx_tx_msg structure, detailed in Section 2.

The _setup_tx_parameters() function configures transmission parameters and determines the maximum PSDU length. For G3-PLC, this length depends on modulation, Reed-Solomon configuration, tone mask, and tone map, managed via PIBs like ATPL360_REG_MAX_PSDU_LEN_PARAMS and ATPL360_REG_MAX_PSDU_LEN. For PRIME, the values are defined directly.

After configuration, phy_ctl_send_msg() prepares the data, stores it in sx_tx_msg.puc_data_buf, and sets the length in sx_tx_msg.us_data_len. The sx_atpl360_desc.send_data() function then transmits the message.

G3-PLC requires padding and CRC, which can be enabled via ATPL360_REG_CRC_TX_RX_CAPABILITY. PRIME does not require padding, and CRC checking is handled by API functions.

A TX data confirm event is triggered upon sending, managed by the data_confirm callback.

1.4 Reception

Received PLC messages are processed by the _handler_data_ind() callback function, which receives a rx_msg_t structure containing message data. This structure includes details like reception time, frame duration, RSSI, data length, modulation type, and signal quality metrics.

The callback checks CRC validation, extracts signal data, and passes the content to the application function app_console_handle_rx_msg() via the phy_ctl_rx_msg() callback. The application function then displays the message content and signal quality on the host console.

1.5 Modifications

The PLC & Go example can be customized for point-to-point applications. Additional periodical tasks can be integrated into the main while() loop. The PHY controller module process should run as fast as possible, typically within the main loop. A 1 ms timer (TC_1MS_Handler()) is available for periodic tasks, and new flags can be added for custom timing requirements.

Transmission parameters, set during initialization, can be modified dynamically. The example demonstrates changing modulation parameters. The data_indication handler can be adapted to pass more or fewer parameters to the upper layer as needed.

2. Transmission of PLC Messages

2.1 Transmission in G3-PLC

Transmission messages are constructed using the tx_msg data structure defined in atpl360_comm.h. This structure includes fields for the data buffer pointer (puc_data_buf), transmission time (ul_tx_time), data length (us_data_len), preemphasis settings, tone map, transmission mode (uc_tx_mode), transmission power (uc_tx_power), modulation type (uc_mod_type), modulation scheme (uc_mod_scheme), phase detector counter (uc_pdc), Reed-Solomon blocks (uc_2_rs_blocks), and delimiter type (uc_delimiter_type).

Key transmission parameters include:

• uc_tx_mode: Defines how the message is sent (e.g., TX_MODE_ABSOLUTE, TX_MODE_RELATIVE, TX_MODE_FORCED).
• uc_tx_power: Sets signal attenuation.
• uc_mod_type: Specifies the modulation type (e.g., MOD_TYPE_BPSK, MOD_TYPE_QPSK).
• uc_mod_scheme: Defines the modulation scheme (e.g., MOD_SCHEME_DIFFERENTIAL, MOD_SCHEME_COHERENT).
• uc_delimiter_type: Specifies the delimiter type used in the header (e.g., DT_SOF_NO_RESP, DT_SOF_RESP).

After data and parameters are prepared, the send_data() function is used for transmission. G3-PLC requires padding and CRC, managed by ATPL360_REG_CRC_TX_RX_CAPABILITY. A TX data confirm event is triggered upon sending, reported via the data_confirm callback, which returns transmission status codes like TX_RESULT_SUCCESS or TX_RESULT_INV_LENGTH.

2.2 Transmission in PRIME

Transmission messages in PRIME also use the tx_msg data structure. This structure includes fields such as transmission time (ul_tx_time), data length (us_data_len), attenuation level (uc_att_level), modulation scheme (uc_scheme), receiver disable flag (uc_disable_rx), modulation type (uc_mod_type), transmission mode (uc_tx_mode), and buffer ID (uc_buffer_id).

Key PRIME transmission parameters:

• uc_scheme: Modulation scheme (e.g., MOD_SCHEME_DBPSK, MOD_SCHEME_DQPSK_C).
• uc_mod_type: Modulation type (e.g., MODE_TYPE_A, MODE_TYPE_B).
• uc_tx_mode: Transmission mode (e.g., TX_MODE_ABSOLUTE, TX_MODE_RELATIVE).
• uc_buffer_id: Selects between TX_BUFFER_0 and TX_BUFFER_1.

The send_data() function is used for transmission. A TX data confirm event is triggered, reported via the data_confirm callback, providing transmission status codes similar to G3-PLC.

3. Reception of PLC Messages

3.1 Reception in G3-PLC

When the PL360 receives a message, an RX data indication event is triggered and managed by the data_indication callback (_handler_data_ind). This callback receives a rx_msg_t structure containing detailed information about the received message, including:

• Reception time (ul_rx_time)
• Frame duration (ul_frame_duration)
• Received Signal Strength Indicator (us_rssi)
• Length of received frame (us_data_len)
• Phase difference (uc_zct_diff)
• Corrected errors (uc_rs_corrected_errors)
• Modulation type (uc_mod_type) and scheme (uc_mod_scheme)
• AGC parameters (ul_agc_factor, us_agc_fine, ss_agc_offset_meas, uc_agc_active, uc_agc_pga_value)
• SNR values (ss_snr_fch, ss_snr_pay, uc_payload_snr_worst_carrier, etc.)
• Link Quality Indicator (uc_lqi)
• CRC verification result (uc_crc_ok)
• Tone map (puc_tone_map) and carrier SNR (puc_carrier_snr)
• Pointer to the data buffer (puc_data_buf)

3.2 Reception in PRIME

In PRIME, received messages trigger an RX data indication event, handled by the data_indication callback (_handler_data_ind). This callback receives a rx_msg_t structure with PRIME-specific fields:

• Accumulated Error Vector Magnitude for header/payload (ul_evm_header_acum, ul_evm_payload_acum)
• Error Vector Magnitude for header/payload (us_evm_header, us_evm_payload)
• Reception time (ul_rx_time)
• Data length (us_data_len)
• Modulation scheme (uc_scheme) and type (uc_mod_type)
• Header type (uc_header_type)
• Average RSSI (uc_rssi_avg) and CNIR (uc_cinr_avg, uc_cinr_min)
• Soft BER (uc_ber_soft, uc_ber_soft_max)
• Noise/impulse percentages (uc_nar_bnd_percent, uc_imp_percent)
• Pointer to the data buffer (puc_data_buf)

The uc_header_type can be PHY_HT_GENERIC, PHY_HT_PROMOTION, or PHY_HT_BEACON.

4. PHY Controller

The PHY controller is a C library (app_phy_ctl.c and app_phy_ctl.h) that provides a simplified API for point-to-point or point-to-multipoint PLC applications using the PL360 modem. It manages events from the PL360 device through functions and callbacks.

4.1 G3-PLC PHY Controller

The API includes callback functions organized in a phy_ctl_callbacks_t structure, such as phy_ctl_data_confirm (for transmission results), phy_ctl_rx_msg (for received messages), phy_ctl_rx_msg_discarded (for corrupted messages), and phy_ctl_update_tx_configuration (for updated transmission parameters).

The phy_ctl_pl360_init() function loads the PL360 firmware and initializes callbacks, requiring an initial working band identifier (e.g., ATPL360_WB_CENELEC_A, ATPL360_WB_FCC). The phy_ctl_set_callbacks() function sets up these callbacks, and phy_ctl_process() handles pending PLC events.

The phy_ctl_send_msg() function sends messages via PLC, taking a buffer pointer and message length. It returns a status code indicating the transmission result (e.g., TX_RESULT_PROCESS, TX_RESULT_INV_LENGTH).

4.2 PRIME PHY Controller

Similar to G3-PLC, the PRIME PHY controller uses a phy_ctl_callbacks_t structure for callbacks like phy_ctl_data_confirm, phy_ctl_rx_msg_crc_ok, phy_ctl_rx_msg_bad_crc, and phy_ctl_update_tx_configuration.

The phy_ctl_pl360_init() function loads the PL360 firmware and initializes callbacks, requiring an initial frequency working channel number. phy_ctl_set_callbacks() sets up these callbacks, and phy_ctl_process() manages pending events. The phy_ctl_send_msg() function sends messages and returns a status code.

Functions are available to get/set modulation scheme and channel.

5. Appendix A. PHY Layer

The PHY layer manages frame transmission and reception, running firmware on the PL360 device. It triggers data indication and data confirm events to upper layers via the host controller. The PHY layer API provides functions for transmitting frames, performing periodic tasks, and accessing the PHY Information Base (PIB) for parameter management.

5.1 PL360 Configuration

PLC projects require initial configuration via Physical Information Bases (PIBs). Microchip PLC stacks use symbolic constants (e.g., ATPL360_WB for band selection) and management primitives (dynamically modifiable parameters like impedance detection).

5.2 PL360 Host Controller

The PL360 Host Controller API in the host microcontroller serves as the interface to the PL360 device. Initialization involves:

1. Calling atpl360_init() to initialize the controller descriptor.
2. Setting controller callbacks for events like Data indication, Data confirm, Add-on event, and Exception event.
3. Enabling the controller with atpl360_enable().
4. Handling PL360 events by periodically calling atpl360_handle_events().

The atpl360_init() function initializes hardware and configures the controller descriptor, setting up interrupt handlers, SPI service, and add-on interfaces. The descriptor provides access functions like set_callbacks, send_data, get_config, set_config, and send_addons_cmd.

A HAL wrapper structure defines hardware and software dependencies.

The setcallbacks() function configures event handlers for data_confirm, data_indication, addons_event, and exception_event.

The atpl360_enable() function transfers the firmware binary from flash memory to the PL360 device and starts its execution. It requires the binary's memory address and size.

The atpl360_handle_events() function checks for PLC events (PHY parameters, transmission/reception completion, exceptions) and triggers the corresponding host controller callbacks.

6. Appendix B. Porting Platform

When porting the PLC & Go example to unsupported platforms, consider the following:

• Flash Memory: Ensure sufficient free flash memory for the PL360 firmware binary.
• SPI Bus: Communication uses SPI. The platform must support 8-bit and 16-bit SPI modes. Recommended speeds are 12 MHz (FCC) and 8 MHz (CENELEC-A/B).
• Minimum Pinout: Required pins include SPI communication, a Reset line, and an External Interrupt line for event notification. Carrier Detect (PRIME only) and TST line (low-power modes only) may also be needed.
• Source Code Files: Hardware-related files are located in /sam/services/plc/pplc_if/atpl360/ and /common/components/plc/atpl360/.
• Memory: The SAMG55 platform requires over 4 KB ROM and 3 KB RAM for hardware-related files.

7. Revision History

7.1 Rev A - 02/2020

Document: First issue.

Microchip Resources

The Microchip Website

Microchip offers online support at http://www.microchip.com/, providing access to datasheets, errata, application notes, sample programs, design resources, user guides, software releases, and archived software.

General Technical Support

Includes FAQs, technical support requests, online discussion groups, and a Microchip design partner program listing.

Business of Microchip

Features product selectors, ordering guides, press releases, seminar listings, and sales office information.

Product Change Notification Service

Subscribers receive email notifications for product changes, updates, revisions, or errata. Register at http://www.microchip.com/pcn.

Customer Support

Assistance is available through distributors, local sales offices, Embedded Solutions Engineers (ESE), and technical support. Technical support is also accessible via http://www.microchip.com/support.

Microchip Devices Code Protection Feature

Microchip devices meet datasheet specifications and are designed for security. Code protection is continuously evolving.

Legal Notice

Information provided is for convenience and may be superseded. Users are responsible for ensuring their applications meet specifications. Microchip disclaims all warranties and liabilities related to the information and its use. Use in life support/safety applications is at the buyer's risk.

Trademarks

A comprehensive list of Microchip's registered trademarks and service marks is provided.

Quality Management System

Information is available at http://www.microchip.com/quality.

Worldwide Sales and Service

Contact information for Microchip's sales and service offices worldwide is provided, categorized by region (Americas, Asia/Pacific, Europe).