Figure 3: Data communication flow with a case of repetition
As each firmware layer adds its own information to the original frame, 100 bytes of user data from the application engine become more than double that at the power line level. This is mainly because of the FEC redundancy added to each byte as soon as it arrives at a target node. Network traffic is therefore reduced if the power line is not overly noisy because the FEC algorithm can adjust the corrupted information.
Each frame also contains the target address, the source address, and other parameters. These might include a flag byte indicating the network model (the flag indicates if the repetition has to be ignored for this frame, or if the acknowledge is awaited), a frame ID to avoid multiple repetitions of the same frame, the CRC (CRC16) bytes, the modem preamble, header and postamble byte.
Another implemented mechanism related to repetitions is ‘hopping.’ The hop level is one of the user-defined PLM parameters and is employed to assign a certain hierarchy in the repetition. If a frame has to be repeated but the hop level is lower than the one stored in the PLM parameter, the frame is not forwarded. Normally, the hierarchy is set depending on the distance and the ambient noise condition. The closer the repetition-enabled node is to the concentrator, the higher the hop level, and in this way, the traffic of insignificant repetitions is reduced.
Network grouping is another feature that can be implemented by the user. If it is, the first two bytes of any frame address, which is 6 bytes long, are considered the group address. Each frame with a group address different from the assigned group is ignored. In this way it is possible that more than a network can share the same power line without interacting with each other.
The current firmware implementation is unique for any kind of device, master, slave, or repeater. The PLM stack is able to understand when the master, slave, or repeater state machine has to be executed, depending on the data context.
A dedicated graphic user interface (GUI) is available in order to test or manually manage the street lighting features. Using the GUI, the user is able to set all the PLM parameters, to operate on each lamp and directly address the target node or perform broadcast operations such as switching on/off/dimming the lamp, or to get all the lamp parameters (lamp status, lamp power, bus voltage). The GUI runs on a PC and communicates with each node via the RS232 interface. After the programming phase, where each node is set with a unique address, a local database is created and stored in the PC. All the installed nodes are shown in the appropriated list boxes of the GUI.
Figure 4: “Remote controller over PLM communication” graphic user interface.
In the HID section, the user can perform all the manual operations on each lamp connected to the node shown in the list box or perform broadcast operations simply by enabling the broadcast check box.
A dedicated section of the GUI, as shown in Figure 4, allows the user to set up a profile of on/off/dimming operations for a given node, associating a time clock to each lamp. Each occasion the stored clock time is reached, the node executes the associated operation on the lamp. Up to six steps can be stored and executed in the user data memory of the PLM.
A log window is used to verify the result of each completed operation by using the interface, modem results, and errors.