PROJECTE FINAL DE CARRERA

Disseny d’un dispositiu de baix cost per a la

transmissió de dades a través de línies de
potència
(Design of a low-cost device for data
transmission over power lines)

Estudis: Enginyeria Electrònica

Autor: Josep Maria Ortega César
Director/a: Manuel Domínguez Pumar

Any: 2017
Design of a low-cost device for data transmission over power lines 3/181

Table of Contents
Resum del Projecte............................................................................................................................9
Resumen del Proyecto.....................................................................................................................10
Abstract.............................................................................................................................................11
1 Introduction...................................................................................................................................12
1.1 Context.................................................................................................................................12
1.2 Objectives.............................................................................................................................13
1.3 Solution proposed.................................................................................................................14
1.4 Main challenges....................................................................................................................15
1.5 Document structure..............................................................................................................16
1.6 Document styles...................................................................................................................17
2 Background....................................................................................................................................18
2.1 Power Line Communications (PLC)....................................................................................18
2.2 AFE031................................................................................................................................20
2.2.1 Main features............................................................................................................20
2.2.2 AFE031 blocks and pins..........................................................................................21
2.3 BeagleBone Black (BBB)....................................................................................................24
2.4 Arduino.................................................................................................................................26
2.5 Raspberry Pi.........................................................................................................................27
3 Implementation..............................................................................................................................28
3.1 Overview..............................................................................................................................28
3.2 Technical specifications.......................................................................................................29
3.3 The SUPERVISOR unit.......................................................................................................30
3.3.1 Overview..................................................................................................................30
3.3.2 Justification for the BeagleBone Black choice........................................................30
3.3.3 Justification for the AFE031 choice.........................................................................30
3.3.4 Design notes and limitations....................................................................................31
3.3.5 PlcCape versions......................................................................................................32
3.3.6 PlcCape-v1...............................................................................................................33
3.3.6.1 Overview....................................................................................................33
3.3.6.2 Schematics.................................................................................................33
3.3.6.3 Printed Circuit Board.................................................................................36
3.3.6.4 Bill of Materials.........................................................................................37
3.3.6.5 Final cape...................................................................................................38
3.3.6.6 Probing points............................................................................................38
3.3.6.7 AC coupling auxiliary module...................................................................39
3.3.7 PlcCape-v2...............................................................................................................41
3.3.7.1 Overview....................................................................................................41
3.3.7.2 Schematics.................................................................................................42
3.3.7.3 Printed Circuit Board.................................................................................46
3.3.7.4 Bill of Materials.........................................................................................46
3.3.7.5 Final cape...................................................................................................48
3.3.7.6 Probing points............................................................................................48
3.3.7.7 TX_F_OUT bridge.....................................................................................49
3.3.7.8 Future improvements.................................................................................49
4/181 Design of a low-cost device for data transmission over power lines

3.4 The REPORTING device.....................................................................................................50

3.4.1 Simple transmitter with Arduino..............................................................................50
3.4.2 Temperature sensing device with Arduino...............................................................54
3.4.3 Sensing and transmitting device with Arduino........................................................57
3.4.4 Push-Pull amplifier..................................................................................................60
3.4.4.1 Overview....................................................................................................60
3.4.4.2 Dual voltage power supply........................................................................61
3.4.4.3 Single voltage power supply......................................................................65
3.4.4.4 Voltage divider and low-pass filter............................................................67
3.4.4.5 LED monitoring.........................................................................................70
3.4.4.6 Common scenarios.....................................................................................70
3.4.4.7 Implementation on a breadboard...............................................................72
3.5 PlcCape SOFTWARE framework........................................................................................73
3.5.1 Overview..................................................................................................................73
3.5.2 Changes....................................................................................................................73
3.5.3 Future improvements...............................................................................................74
3.5.4 Third-party libraries.................................................................................................75
3.5.4.1 FFTW3.......................................................................................................75
3.5.4.2 GTK+/Cairo...............................................................................................75
3.5.4.3 Libxml2......................................................................................................76
3.5.5 Eclipse environment.................................................................................................77
3.5.6 Emulator...................................................................................................................80
3.5.7 Applications.............................................................................................................81
3.5.7.1 plc-cape-oscilloscope.................................................................................81
3.5.7.2 plc-cape-freq-response...............................................................................85
3.5.7.3 plc-cape-lab................................................................................................88
3.5.8 Plugins......................................................................................................................90
3.5.8.1 encoder-wav...............................................................................................91
3.5.8.2 encoder-morse............................................................................................92
3.5.8.3 decoder-morse............................................................................................93
3.5.9 Multiplatform test with the Raspberry Pi.................................................................94
4 Analysis & results..........................................................................................................................96
4.1 Overview..............................................................................................................................96
4.2 Considerations......................................................................................................................97
4.2.1 230VAC measurements............................................................................................97
4.2.2 RX filtering..............................................................................................................97
4.2.3 Wearing of PlcCape boards......................................................................................98
4.3 PlcCape TX chain.................................................................................................................98
4.3.1 TX_PGA_OUT vs. TX_F_OUT..............................................................................99
4.3.2 Sampling rate effects..............................................................................................102
4.3.3 TX_F_OUT, PA_IN and PA_OUT........................................................................103
4.3.4 PlcCape-v1 and Push-Pull amplifier stage.............................................................104
4.4 PlcCape RX chain..............................................................................................................109
4.4.1 Auto-loop with a direct bridge...............................................................................109
4.4.2 Auto-loop through the Push-Pull amplifier............................................................113
4.4.3 PlcCape RX chain characterization........................................................................117
4.5 Arduino and Push-Pull amplifier........................................................................................124
4.5.1 Voltage divider.......................................................................................................125
4.5.2 Frequency response................................................................................................127
Design of a low-cost device for data transmission over power lines 5/181

4.5.3 Load impedance.....................................................................................................128

4.6 Data communication over an unpowered line....................................................................131
4.6.1 BBB to BBB...........................................................................................................131
4.6.1.1 OOK encoding.........................................................................................132
4.6.1.2 PWM encoding........................................................................................134
4.6.1.3 Morse encoding........................................................................................134
4.6.2 Arduino to BBB.....................................................................................................135
4.7 Analysis of the 230VAC mains..........................................................................................138
4.7.1 AC coupling module validation.............................................................................138
4.7.2 AC to PlcCape........................................................................................................140
4.8 Data communication through the 230VAC line.................................................................144
4.9 Final system integration.....................................................................................................154
5 Conclusions..................................................................................................................................159
5.1 Feasibility...........................................................................................................................159
5.2 Reusability..........................................................................................................................160
5.3 Weak points and future improvements...............................................................................161
6 Annex I. Tools...............................................................................................................................163
7 Annex II. LTspice - How to add third party models.................................................................165
8 Annex III. PlcCape board SPI analysis.....................................................................................166
8.1 Clock and data....................................................................................................................166
8.2 Chip Select.........................................................................................................................168
9 Annex IV. AFE031 Calibration modes.......................................................................................170
9.1 TX_PGA loop.....................................................................................................................171
9.2 TX_PGA + TX_LPF loop..................................................................................................173
9.3 TX_PGA + RX_LPF + RX_PGA2 loop............................................................................177
10 Bibliography...............................................................................................................................180
10.1 PlcCape framework............................................................................................................180
10.2 BeagleBone Black..............................................................................................................180
10.3 Arduino...............................................................................................................................180
10.4 Raspberry Pi.......................................................................................................................180
10.5 PLC.....................................................................................................................................180
10.6 AFE31................................................................................................................................181
10.7 Push-Pull............................................................................................................................181
10.8 Open source libraries..........................................................................................................181
6/181 Design of a low-cost device for data transmission over power lines

Figures
Figure 1. Proposed system for the REPORTING device.................................................................................14
Figure 2. Proposed system for the SUPERVISOR unit...................................................................................14
Figure 3. Proposed system with concrete modules.........................................................................................15
Figure 4. AFE031 Main features.....................................................................................................................20
Figure 5. AFE031 blocks and pins..................................................................................................................21
Figure 6. BeagleBone Black components.......................................................................................................24
Figure 7. BeagleBone Black connectors P8 & P9...........................................................................................25
Figure 8. Arduino Leonardo............................................................................................................................26
Figure 9. Raspberry Pi 3 Model-B..................................................................................................................27
Figure 10. Raspberry Pi Zero W.....................................................................................................................27
Figure 11. PlcCape-v1 SCH P9 connector......................................................................................................33
Figure 12. PlcCape-v1 SCH AFE031 core circuitry.......................................................................................34
Figure 13. PlcCape-v1 SCH JP1 connector....................................................................................................35
Figure 14. PlcCape-v1 SCH Power supplies...................................................................................................35
Figure 15. PlcCape-v1 PCB Top.....................................................................................................................36
Figure 16. PlcCape-v1 PCB Bottom...............................................................................................................36
Figure 17. PlcCape-v1 board - Top.................................................................................................................36
Figure 18. PlcCape-v1 board - Bottom...........................................................................................................36
Figure 19. PlcCape-v1 mounted board............................................................................................................38
Figure 20. PlcCape-v1 + AC coupling module + BBB...................................................................................38
Figure 21. PlcCape-v1 probing points............................................................................................................38
Figure 22. Auxiliary AC coupling module - Schematic..................................................................................39
Figure 23. Auxiliary AC coupling module - Top.............................................................................................39
Figure 24. Auxiliary AC coupling module - Bottom.......................................................................................39
Figure 25. Auxiliary AC coupling module connections..................................................................................40
Figure 26. PlcCape-v2 SCH P9 connector......................................................................................................42
Figure 27. PlcCape-v1 vs. PlcCape-v2 in the interfacing with the BBB.........................................................43
Figure 28. PlcCape-v2 SCH AFE031 core circuitry.......................................................................................43
Figure 29. PlcCape-v2 SCH AC coupling block.............................................................................................44
Figure 30. PlcCape-v2 SCH Zero Crossing block...........................................................................................44
Figure 31. PlcCape-v2 SCH LED monitoring block.......................................................................................45
Figure 32. PlcCape-v2 SCH Auxiliary connector...........................................................................................45
Figure 33. PlcCape-v2 SCH Power supplies...................................................................................................45
Figure 34. PlcCape-v2 PCB Top.....................................................................................................................46
Figure 35. PlcCape-v2 PCB Bottom...............................................................................................................46
Figure 36. PlcCape-v2 board - Top.................................................................................................................46
Figure 37. PlcCape-v2 board - Bottom...........................................................................................................46
Figure 38. PlcCape-v2 mounted board............................................................................................................48
Figure 39. PlcCape-v2 probing points............................................................................................................48
Figure 40. PlcCape-v2 TX_F_OUT bridge.....................................................................................................49
Figure 41. Arduino Leonardo - Simple transmitter test...................................................................................50
Figure 42. Arduino shield - Schematic............................................................................................................54
Figure 43. Arduino shield - Routing...............................................................................................................54
Figure 44. Arduino shield - Top......................................................................................................................55
Figure 45. Arduino shield - Bottom................................................................................................................55
Figure 46. Arduino shield - Test......................................................................................................................56
Figure 47. The temperature REPORTER device.............................................................................................59
Figure 48. Push-Pull amplifier - Basic circuit.................................................................................................61
Figure 49. Push-Pull amplifier - Basic circuit - SPICE analysis.....................................................................62
Figure 50. Push-Pull amplifier - Single power supply....................................................................................65
Figure 51. Push-Pull amplifier - Single power supply - SPICE analysis.........................................................65
Figure 52. Push-Pull amplifier - Voltage divider.............................................................................................67
Design of a low-cost device for data transmission over power lines 7/181

Figure 53. ATmega32U4 - I/O Pin Output Voltage vs. Source Current (Vcc = 5V)........................................67
Figure 54. Push-Pull amplifier - Voltage divider - SPICE analysis.................................................................68
Figure 55. Push-Pull amplifier - LED monitoring...........................................................................................70
Figure 56. Push-Pull amplifier - Final proposal - SPICE analysis..................................................................72
Figure 57. Push-Pull amplifier - Implementation on a breadboard.................................................................72
Figure 58. Eclipse IDE - Screenshot...............................................................................................................77
Figure 59. Eclipse IDE - Linked Folders........................................................................................................79
Figure 60. plc-cape-oscilloscope - Screenshot................................................................................................81
Figure 61. plc-cape-oscilloscope - Example of a SVG capture.......................................................................82
Figure 62. plc-cape-oscilloscope - Screenshot of a remote SSH session from Ubuntu...................................84
Figure 63. plc-cape-lab - Screenshot of a remote SSH session from Ubuntu..................................................84
Figure 64. plc-cape-lab - Screenshot...............................................................................................................90
Figure 65. encoder-wav - Test with a passive buzzer connected to PlcCape-v2..............................................91
Figure 66. RPI interoperability - Testing environment....................................................................................94
Figure 67. RPI interoperability - Screenshot of plc-cape-lab when playing a tone.........................................95
Figure 68. TX chain analysis - PlcCape - Testing environment......................................................................99
Figure 69. TX chain analysis - PlcCape to Push-Pull - Testing environment................................................104
Figure 70. RX chain analysis - TX_F_OUT to TXRX bridge.......................................................................109
Figure 71. RX chain analysis - PlcCape to Push-Pull without voltage divider..............................................113
Figure 72. RX chain analysis - PlcCape to Push-Pull with voltage divider...................................................113
Figure 73. RX chain analysis - PlcCape + Push-Pull + PlcCape - Testing environment...............................117
Figure 74. RX chain analysis - plc-cape-lab at transmission.........................................................................118
Figure 75. RX chain analysis - plc-cape-lab at reception..............................................................................118
Figure 76. RX chain analysis - TX_F_OUT on an isolated PlcCape-v2.......................................................118
Figure 77. Arduino to Push-Pull amplifier - Testing environment................................................................124
Figure 78. Arduino to Push-Pull amplifier - Testing environment with a low impedance.............................129
Figure 79. PlcCape to PlcCape communication - Testing environment........................................................131
Figure 80. PlcCape to PlcCape communication - plc-cape-lab at transmission.............................................132
Figure 81. PlcCape to PlcCape communication - plc-cape-lab at reception..................................................132
Figure 82. Arduino to PlcCape communication - Testing environment.........................................................135
Figure 83. Arduino to PlcCape communication - plc-cape-lab at reception..................................................136
Figure 84. AC coupling module - Testing environment................................................................................138
Figure 85. AC to PlcCape - Testing environment..........................................................................................140
Figure 86. AC to PlcCape - Testing environment with a laptop....................................................................141
Figure 87. 230VAC communication - The REPORTING device at transmission.........................................144
Figure 88. 230VAC communication - The SUPERVISOR unit at reception.................................................144
Figure 89. 230VAC communication - Transmitter configuration..................................................................146
Figure 90. 230VAC communication - Receiver configuration......................................................................146
Figure 91. 230VAC communication - plc-cape-lab capture from the laptop.................................................152
Figure 92. Final system - Push-Pull output probing......................................................................................154
Figure 93. Final system at TX - The REPORTING device...........................................................................155
Figure 94. Final system at RX - The SUPERVISOR unit.............................................................................155
Figure 95. Final system - ADC data captured from the 230VAC..................................................................156
Figure 96. Final system - Demodulated data from 230VAC.........................................................................156
Figure 97. Final system - ADC data captured from the 230VAC (voltage divider at TX skipped)................157
Figure 98. Final system - Demodulated data from the 230VAC (voltage divider at TX skipped).................157
Figure 99. Final system - ADC data captured from unpowered mains..........................................................158
Figure 100. Final system - Demodulated data from the mains when unpowered..........................................158
Figure 101. System proposal.........................................................................................................................159
Figure 102. ImageConditioner tool - Main screenshot..................................................................................164
8/181 Design of a low-cost device for data transmission over power lines

Tables
Table 1. Main project objectives.....................................................................................................................13
Table 2. Summary of topics covered per chapter............................................................................................16
Table 3. Document styles................................................................................................................................17
Table 4. Embedded pictures formats...............................................................................................................17
Table 5. CENELEC bands..............................................................................................................................19
Table 6. AFE031 main blocks.........................................................................................................................22
Table 7. AFE031 pins and signals...................................................................................................................23
Table 8: Summary of topics covered in the 'Implementation' chapter.............................................................28
Table 9. Main requirements............................................................................................................................29
Table 10. PlcCape-v1 Bill of Materials...........................................................................................................37
Table 11. PlcCape-v2 vs PlcCape-v1 modifications........................................................................................41
Table 12. PlcCape-v2 Bill of Materials...........................................................................................................47
Table 13. Changes in the software framework................................................................................................74
Table 14. Future improvements in the software framework............................................................................74
Table 15. Summary of tests performed...........................................................................................................96
Table 16. Signals involved in the PlcCape TX Chain.....................................................................................98
Table 17. Tools used in this project...............................................................................................................163
Design of a low-cost device for data transmission over power lines 9/181

Resum del Projecte

En aquest projecte es proposa un sistema per a comunicar dades entre dos dispositius a través de la xarxa
elèctrica (230VAC en Europa) d'una forma simple, assequible i oberta.

En termes generals, aquest camp d’estudi es coneix com a Comunicació per Línies de Potència (PLC).

Un dels principals reptes del projecte és el procés de modulació/desmodulació requerit per a encabir les
dades dintre de la banda de freqüències permesa. Amb aquesta finalitat, s'utilitza una modulació simple de
tipus On-Off-Keying (OOK) amb una portadora de 110 kHz.

El capítol dedicat a les proves se centra en la comunicació entre endolls d’un habitatge, però el concepte es
pot aplicar també al camp de la indústria per a la supervisió de màquines des d'una ubicació remota dintre de
la planta d’una fàbrica.

El projecte es divideix en tres àrees principals de desenvolupament:

1. Disseny d'un circuit auxiliar (cape) per a la plataforma BeagleBone Black (BBB). El dispositiu
resultant funciona com a unitat de SUPERVISIÓ que gestiona els dispositius intel·ligents connectats
a la línia de potència. El nucli del circuit auxiliar és un sistema frontal analògic (AFE)
específicament dissenyat per a PLC, l’integrat AFE031, que inclou un DAC d’alta velocitat controlat
mitjançant un bus SPI. Per a la recepció de dades, el sistema es basa en un ADC inclòs en el
microcontrolador de la BBB.

2. Desenvolupament d’eines software per a la unitat de supervisió (com un oscil·loscopi o un

analitzador de resposta en freqüència). Es fan servir en la fase d’anàlisis. El codi font (alliberat
sota llicència GPL-3.0) es basa en Debian Wheezy, una distribució Linux compatible amb la BBB.

3. Disseny d’un circuit auxiliar (shield) per a la plataforma Arduino. El conjunt funciona com a
dispositiu intel·ligent de NOTIFICACIÓ periòdica. Com a exemple pràctic, el circuit mesura la
temperatura ambient, la mostra en un LCD de 2x16 i envia les dades per la línia d’alimentació en
OOK.

Aquest document té dos capítols principals:

• Una descripció completa del disseny electrònic i del codi font.

• Una exposició detallada de totes les proves efectuades, amb dos propòsits principals:

◦ Caracteritzar i validar l’electrònica i el codi font desenvolupats.

◦ Posar en relleu els principals problemes trobats en la comunicació a través de la línia elèctrica
per a esbossar una guia amb propostes de millora.
10/181 Design of a low-cost device for data transmission over power lines

Resumen del Proyecto

En este proyecto se propone un sistema para comunicar datos entre dos dispositivos a través de la red
eléctrica (230VAC en Europa) de una forma simple, asequible y abierta.

En términos generales, este campo de estudio se conoce como Comunicación por Líneas de Potencia (PLC).

Uno de los principales retos del proyecto es el proceso de modulación/desmodulación requerido para alojar
los datos en la banda de frecuencias permitida. Con este fin, se usa una modulación simple de tipo On-Off-
Keying (OOK) con una portadora de 110 kHz.

El capítulo dedicado a las pruebas se centra en la comunicación entre enchufes de una vivienda, pero el
concepto se puede aplicar también en el campo de la industria para la supervisión de máquinas desde una
ubicación remota dentro de la planta de una fábrica.

El proyecto se divide en tres áreas principales de desarrollo:

1. Diseño de un circuito auxiliar (cape) para la plataforma BeagleBone Black (BBB). El

dispositivo resultante funciona como unidad de SUPERVISIÓN que gestiona los dispositivos
inteligentes conectados a la línea de potencia. El núcleo del circuito auxiliar es un sistema frontal
analógico (AFE) específicamente diseñado para PLC, el integrado AFE031, que incluye un DAC de
alta velocidad controlado por un bus SPI. Para la recepción de datos, el sistema se basa en el ADC
incluido en el microcontrolador de la BBB.

2. Desarrollo de herramientas software para la unidad de supervisión (como un osciloscopio o un

analizador de respuesta en frecuencia). Se utilizan en la fase de análisis. El código fuente (liberado
bajo licencia GPL-3.0) se basa en Debian Wheezy, una distribución Linux compatible con la BBB.

3. Diseño de un circuito auxiliar (shield) para la plataforma Arduino. El conjunto funciona como
dispositivo inteligente de NOTIFICACIÓN periódica. A modo de ejemplo, el circuito mide la
temperatura ambiente, la muestra en un LCD de 2x16 y envía los datos por la línea de alimentación
en OOK.

Este documento tiene dos capítulos principales:

• Una descripción completa del diseño electrónico y del código fuente.

• Una exposición detallada de todas las pruebas efectuadas, con dos propósitos principales:

◦ Caracterizar y validar la electrónica y el código fuente desarrollados.

◦ Poner de relieve los principales problemas encontrados en la comunicación a través de la línea

eléctrica para esbozar una guía con propuestas de mejora.
Design of a low-cost device for data transmission over power lines 11/181

Abstract

This project proposes a system to communicate data between two devices through the electrical network
(230VAC in Europe) in an easy, affordable and open way (DIY-oriented).

In generic terms, this topic is known as Power Line Communications (PLC).

One of the main challenges of the project is the modulation/demodulation process required to accommodate
the data into the allowed frequency band. For that purpose, a simple On-Off-Keying (OOK) modulation with
a 110 kHz carrier is used.

The chapter dedicated to the tests is focused on the communication between electrical outlets at home, but
the concept can also be applied to the industrial scope to monitor machinery from a remote location within
the factory floor.

The project is divided into three main development areas:

1. Design of an auxiliary board (cape) for the BeagleBone Black platform (BBB). The resulting
device works as a SUPERVISOR unit that manages the smart devices connected to the power line.
The core of the cape is an Analog Front End (AFE) specifically designed for PLC, the AFE031,
which includes a high-speed DAC operated by SPI. For data reception, the system relies on the ADC
embedded in the microcontroller of the BBB.

2. Development of some software tools in the supervisor unit (as an oscilloscope and a frequency-
response analyzer). They are used in the analysis phase. The source code (released under a
GPL-3.0 license) is based on Debian Wheezy, a Linux-based distribution compatible with the BBB.

3. Design of an auxiliary board (shield) for the Arduino platform. The resulting assembly works as
a smart device for periodic REPORTING. As a practical example, the shield senses the ambient
temperature, displays it in a 2x16 LCD, and sends the data through the mains in OOK.

This documentation has two main chapters:

• A complete description of the electronic and software design.

• A detailed exposition of all the tests done, with two main purposes in mind:

◦ Characterize and validate the electronics and the software developed.

◦ Highlight the main issues faced in the communication through the mains and propose some
guidelines for future evolutions.
12/181 Design of a low-cost device for data transmission over power lines

1 Introduction
1.1 Context
In today's modern society, smartphones have become indispensable. Time in which they were just used to
call contacts or send messages is over. Now we use them for much more things: we can read emails, consult
the news, surf the web, check our finances, do procedures with the administration, etc.

Nowadays, there is also a trend that is growing fast: the remote communication with any device from an
internet-connected-widget, the so called Internet Of Things (IoT).

On one hand, and due to the currently available inexpensive technology, devices are becoming smarter
each day. On the other, smartphones provide means to comfortable establish remote connections from
everywhere.

The remote control of devices is not new. At domestic scope, in home automated installations (aka Smart
Home or Home Automation), heaters can be remotely turned on before coming back to home, lighting points
can be controlled from the sofa, shutters can be automatically closed at night or on-demand, etc. But the
success and massive adoption of smartphones is opening this field to a myriad of new applications:
security warnings sent to the phone in case of anomalous events (excessive power consumption, water or gas
leakage, smoke/fire detection…), real-time temperature supervision to activate the heating depending on our
preferences at a given time, webcam monitoring, etc.

And this trend is also growing in the industrial scope. Plant supervisors need to get in real time the
maximum details of the ongoing production. They need to know if a machine in the production line is raising
some warning or if it is stopped because a failure. In the typical implementation there are visible or audible
notification means (traffics lights, horns) requiring the maintenance staff go where the problem is reported in
order to have more details. A more effective approach might be receiving a detailed report in the smartphone
in order to allow maintenance staff to optimize the actions to be done depending on the active faults and the
priorities.

Smart devices usually communicate with a central server through wireless technologies (Wi-Fi, Bluetooth,
ZigBee...) or through a wired Ethernet LAN. Both methods have pros and cons. For example, the extensive
use of Wi-Fi networks is leading to a more crowded shared band each day (specially due to video-based
content), requiring more complex designs for proper management. Furthermore, there are limitations and
regulations regarding the allowed RF power to avoid the abuse of the precious shared band.

In this project I am going to cover a different system: the data communication from a low-cost device to a
supervisor unit through the power line, in particular, through the 230VAC 50Hz mains at home.

PLC, which stands for Power Line Communications, is an old hugely analyzed topic. Plenty of PLC devices
can be found in the market. The added value of this project comes from the customization possibilities, the
DIY approach (Do It Yourself) and the Open Source design (licensed here under GPLv3). The system I am
proposing here can easily be built by any person with a basic electronic background.

This project (which is focused on electronics) is the continuation of the work started in
PlcCapeSoftwareFramework.pdf[1] (which was focused on software). In conjunction they constitute an
introductory framework to Power Line Communications.
Design of a low-cost device for data transmission over power lines 13/181

1.2 Objectives
The following table describes the main objectives of this project:

Principle Details

The main target is to develop a system for communication of data over the
power line. This means that:
Fulfill main PLC
▪ It must be able to modulate the data in the authorized CENELEC-B band,
requirements
which comprises the frequency range between 95 kHz and 125 kHz.
▪ It must couple low-voltage signals to the high-voltage in the AC line.

Develop a system allowing for maximum customization in order to be able to

optimize costs by adapting it to a specific scenario:
Customizable ▪ It must be focused on applications requiring low sporadic traffic.
and versatile ▪ It must accept the use of low-cost simple devices.
▪ It must give the possibility of balancing between complexity and cost (in
software and hardware).

Instead of developing a whole platform, the devices should be based on one of

Cost-effective the popular mini-PCs easily available today, as Raspberry Pi, BeagleBone
Black or Arduino.

Design an environment that may be reused in other applications.

Reusable Note that a reusable framework impacts in cost too: sharing components for
different applications allows for bigger orders on those components, reducing
this way the unitary cost.

The proposed solution must be able to communicate with different kind of

devices: temperature sensors, presence detectors, etc.
Adaptable and The way to add a new device to our network should be as simple as possible
scalable (ideally Plug And Play).
For the software development, try to minimize the complexity of the
portability to other platforms.

This project should give a simple overview of the PLC technology, just as an
introductory step to it (I am also a newbie on).
Focused on The project must fit in the DIY and open source principles. For example, a
experimentation simple low-cost device (with just the strictly required features for a specific
and learning test) is sometimes preferred to a powerful full-featured and more expensive
product. Have in mind that DIY is tied to experimentation and thus, prone to
electronic damage. So, low-cost is a highly appreciated characteristic.
Table 1. Main project objectives
14/181 Design of a low-cost device for data transmission over power lines

1.3 Solution proposed

The proposal consists of two different devices for each side of the communication (TX vs. RX).

At transmission, a low-cost REPORTING device based on the Arduino platform will sense and transmit the
temperature to a central unit through the mains.
Figure 1. Proposed system for the REPORTING device

TEMPERATURE OOK LOW-PASS LINE COUPLING 230VAC

AMPLIFIER
SENSING MODULATION FILTER INTERFACE LINE

AC coupling
Arduino + Shield Push-Pull amplifier
module

At reception, a central SUPERVISOR unit based on the BeagleBone Black (BBB) will be in charge of
managing the connected devices. This involves the design of a BBB-cape (an auxiliary stackable board) with
an Analog Fron End (AFE). For that purpose, I am going to use the AFE031 integrated circuit, ideally suited
for PLC customized communications.
Figure 2. Proposed system for the SUPERVISOR unit

LINE 230VAC
SPI SPI DAC TX_PGA TX_LPF PA COUPLING
INTERFACE LINE

ADC RX_PGA1 RX_LPF RX_PGA2 RX_BPF

AFE031
BeagleBone
Black PlcCape

This is the meaning of the acronyms used:

TX/RX Transmitter/Receiver

SPI Serial Peripheral Interface bus

DAC/ADC Digital-To-Analog Converter / Analog-To-Digital Converter

PGA/PA Programmable Gain Amplifier/Power Amplifier

LPF/BPF Low-pass filter/Band-pass filter

The coupling circuitry will superpose the modulated data (within the authorized CENELEC-B band) to the
230VAC 50Hz electrical energy.

Note that the Line Coupling Interface will allow establishing communication between both devices through
the AC mains but will also work over a direct unpowered couple of wires (a safer way for initial tests).
Design of a low-cost device for data transmission over power lines 15/181

If we replace the blocks above by real photos of the developed modules for this project (to have a better idea
of the proposed system), we will have this:
Figure 3. Proposed system with concrete modules

In the above figure we can see:

• the Arduino-based device which senses and reports the data (here the temperature) wrapped in an
OOK modulation with a 110 kHz carrier

• a Push-Pull amplifier used to supply more current than the provided by the Arduino pins

• the AC Coupling module superposing the low-voltage signal to the high-voltage electrical energy

• the 230VAC transmission line carrying both, the 230VAC 50Hz energy and the data at 110 kHz

• the PlcCape (with the integrated coupling module) stacked on a BBB working in reception mode

The first development stage of the whole PlcCape project[1] was focused on the development of the
software framework running in the SUPERVISOR unit (the BBB).

This second development stage of the PlcCape project focuses on:

• the electronic design of the cape that will expand the functionality of the BeagleBone Black

• the electronic development and basic firmware of the low-cost Arduino-based device

• the evolution of the plc-cape software started in the first phase of the PlcCape project, with new
applications, plugins, features, improvements and bug corrections

• the detailed analysis of all the involved boards and the results in different configurations, with
the aim of acquiring a deep and complete knowledge of all the units composing the system and thus,
point the way for future evolutions

1.4 Main challenges

Due to the chosen implementation, this project involves these specific challenges:

• Learn how the different platforms used in this project (BBB and Arduino) work

• Acquire full knowledge on the AFE031

• Use free software for the electronic design (Eagle) and the electronic analysis (Spice-based tools)

• Use Eclipse as a full-featured free IDE for the software development

• Learn how to develop GUIs based on third party libraries (as GTK/Cairo) with the aim of creating a
mini-oscilloscope tool to help in the analysis of the ADC captured data
16/181 Design of a low-cost device for data transmission over power lines

1.5 Document structure

This document covers the following topics in five chapters:

Chapter Topics covered

Introduction
Context, objectives, proposal, challenges and document structure
Page 12

Basic notions on Power Line Communications (PLC)

Main features of the Analog Front End chip used, the AFE031
Background Some notions about the different electronic platforms used in this project:
Page 18 ▪ Main details of the BeagleBone Black platform
▪ Main details of the Arduino Leonardo board
▪ Generic view of the Raspberry Pi platform

Details about the electronic development:

▪ Technical specifications
▪ The SUPERVISOR unit (based on BBB)
▪ The REPORTING device (based on Arduino)
Implementation Details about the software development:
Page 28 ▪ The Eclipse environment
▪ Emulation mode
▪ New applications
▪ New plugins
▪ An example of portability to the Raspberry Pi

Detailed description of a series of experiments with the aim of validating the

proper operation of all the devices involved:
▪ Tests in the SUPERVISOR unit to deeply analyze all the interesting
signals in the transmission and reception chains of the PlcCape
Analysis & results
▪ Tests in the different modules composing the REPORTING device
Page 96
▪ Communication tests over an unpowered line and over the 230VAC
mains
▪ Evaluation of the final complete system by sending and receiving data
from different 230VAC wall outlets

Final conclusions about:

Conclusions ▪ the whole system feasibility
Page 159 ▪ the reusability of the system for other purposes
▪ future improvements for the next iteration in the development
Table 2. Summary of topics covered per chapter
Design of a low-cost device for data transmission over power lines 17/181

1.6 Document styles

The following styles have been used depending on the category of the documented entity:

Category Style

main.c
int main(int argc, char *argv[])
Source code {
printf("Hello world\n");
}

test.sh
Other file content #!/bin/bash
@echo Hello World

Linux console or Octave # echo Hello world

commands
[…]
Quotes, citations, fragments
This is a fragment of text from somewhere
of existing documentation […]

Cross-links to other parts in

This is a link to this Style table
the document

References to Bibliography This is a reference to one bibliographic reference [1]

Table 3. Document styles

It is worth dedicating a small section to the types of pictures used in this document to make the most of them:

Format Comments

Lossy compression format ideal for photos. Do Copy/Paste from the PDF to get the
JPG original image size (usually bigger than the displayed one in the PDF).
Example: Figure 38. PlcCape-v2 mounted board.

Loss-less compression format ideal for graphic content as diagrams, charts, graphs,
PNG drawings, etc. Do Copy/Paste from the PDF to get the original image size.
Example: Figure 26. PlcCape-v2 SCH P9 connector.

Object-oriented format. You can zoom it in and get an accurate magnification of the
composing objects (as vectors) instead of a pixel-based expansion. This is the format
SVG exported by the plc-cape-oscilloscope tool.
Example: Figure 61. plc-cape-oscilloscope - Example of a SVG capture.

Object-oriented proprietary format on Windows OSes. It gives similar results to SVG. It

WMF has been used in the captures from the LTspice tool (circuit designs, plots, etc).
Example: Figure 48. Push-Pull amplifier - Basic circuit

Table 4. Embedded pictures formats

18/181 Design of a low-cost device for data transmission over power lines

2 Background
2.1 Power Line Communications (PLC)
PLC covers the topics concerning the transmission of data superposed to the electrical energy through the
same line1.

It is a well known technology but not widely used because it has been superseded by the wireless
alternatives. But, the massive usage of the shared radio spectrum (to even reproduce HD video) is giving it a
new chance. Electronic stores are now plenty of PLC devices for data transmission at high speeds at home as
an alternative to the crowded radio band. For example, HomgePlug-based-devices can reach speeds greater
than 100 Mbps.

In the PLC domain, there is also a part dedicated to the transmission of data in the narrow low-frequency
band, with much lower baud rates, but ideally suited for some applications where the involved data consists
of small sporadic packets. We can find examples of use cases in Home Automation (aka Smart Home) or in
the Industrial scope.

COMPARISON WITH WIRELESS

Wi-Fi and Bluetooth (to mention the most popular) have evident advantages over PLC communications:

• The network can be accessed from everywhere in the covered area. PLC requires an electrical outlet.
Note however that any device will always require some amount of power (in addition to the WiFi
consumption) which usually comes from a power outlet (some low-consumption devices can be
operated through batteries but they will require a recharging from time-to-time).

• The wireless associated circuitry is inexpensive because the massive production of WiFi/BT
modules. PLC is not so common, and therefore, a bit more expensive.

But PLC has also some advantages that can make this technology more suitable for specific scenarios:

• PLC can reach higher distances by increasing the transmitted power. In WiFi we have strict
regulations in the maximum power to be radiated for the proper use of the shared radio spectrum.

• PLC can involve lower deployment costs because the reusability of the existing wires for power
distribution and data communication.

• As we are the owners of our electrical private network, we can customize the transmission protocol
pondering over cost and complexity.

• The isolation of electrical networks provides an additional security layer. While WiFi/BT
transmissions can be easily sniffed and thus require strong security protocols, PLC adds a physical
security level: an attacker needs a physical access point to our electrical network wires.

• PLC could also be a good alternative in industry: machines in the factory floor may report data to a
central server without requiring dedicated wires (expensive) or radio-waves (requiring repeaters to
cover the required distance or to cross huge concrete walls).

1 More detailed information about PLC can be found in PlcCapeSoftwareFramework.pdf [1]. Here I only highlights the
most important aspects
Design of a low-cost device for data transmission over power lines 19/181

CHALLENGES

But PLC involves important challenges to have in mind:

• Transmitters must be ready to deliver relatively high currents to deal with the typical low
instantaneous impedance of the devices connected to the power supply network

• Power lines are not specifically designed for data transmission. Long wires are neither shielded nor
twisted. So, they can both, easily capture interferences from the environment, or easily radiate
energy.

• We must also consider the attenuation (due to the length of the wires), the reactance and other
effects.

• Power lines can also be quite noisy depending on the quality of the power supplies of the appliances
connected to.

CENELEC BANDS

CENELEC is the European Committee for Electrotechnical Standardization [15]. This organization has
regulated the way the low-frequency band can be used in power supply networks in the European Region:

CENELEC
Frequency Frequency Range Description
Band

Band A 9 kHz to 95 kHz Reserved for energy providers, mainly for telemetry

Band B 95 kHz to 125 kHz Available for customers use. No protocol defined

Band C 125 kHz to 140 kHz Available for customers use. Protocols must implement CSMA

Band D 140 kHz to 148.5 kHz Available for customers use. No protocol defined
Table 5. CENELEC bands

This project is based on the CENELEC-B band.

20/181 Design of a low-cost device for data transmission over power lines

2.2 AFE031
The AFE031[16] is the core of the PlcCape board. It is an integrated circuit that includes most of the required
modules to build a communication system based on PLC.

The typical configuration is based on a powerful master CPU which generates the waveform of the
modulated data and sends it sample by sample to the DAC of the AFE031 through a SPI bus.

The specific reasons for the selection of this integrated circuit among others are given in the section 3.3.3
Justification for the AFE031 choice.

2.2.1 Main features

For the main features find following an extract of the datasheet [17]:
Figure 4. AFE031 Main features
Design of a low-cost device for data transmission over power lines 21/181

For this project the most interesting features provided by the AFE031 are:

• A high Speed Digitial-to-Analog Converter (DAC) up to 1.5 Msps, for innumerable customization
possibilities in data modulation.

• A Programmable Gain Amplifier (PGA) at transmission for some extra flexibility on the voltage
level of the generated signal.

• A couple of PGAs at reception to adjust the level of the signal before being captured by the ADC.

• A couple of low pass filters (LPF) to attenuate frequency content (interferences, noise, etc.) out of
the band of interest (CENELEC).

• A Power Amplifier (PA) to deliver enough current to drive low impedance values in the AC line.

• Multiple accessible points. This opens the customization possibilities. For example, we can replace
the integrated blocks (PGA, LPF, PA...) with our own versions.

2.2.2 AFE031 blocks and pins

From the PlcCape design perspective, a key point is the pinout of the AFE031 and the meaning of the
composing blocks and signals (which is given in two tables in the following pages) 2:
Figure 5. AFE031 blocks and pins

2 The information in this section is a direct clone of the corresponding section in PlcCapeSoftwareFramework.pdf[1]
22/181 Design of a low-cost device for data transmission over power lines

The AFE031 comes in a mini 48-pin QFN package. That is good for miniaturization but it is something
tricky for manual soldering. It also makes the thermal dissipation a challenge, as it is based on a bottom pad
that must be soldered to a ground plane, which is impossible when using a manual solder.

Block Description

Receives and routes two type of data:

SPI • 8-bit based commands: to enable/disable the different blocks and configure them
• 10-bits based samples: real-time data to be sent to the DAC

Generates the analog voltages (from 0 to 3.3V) corresponding to the digital samples coming
DAC
from the SPI block

Transmission (Tx) Programmable Gain Amplifier (PGA) for better output control. It allows
TxPGA
four programmable gains: 0.250, 0.500, 0.707, 1.000 (in V/V units)

Transmission Low Pass Filter (LPF). It filters the input signal at Tx_F_IN1 (usually the
output from the TxPGA) with a configurable cut-off frequency: 95kHz for CENELEC A,
Tx Filter 145kHz for CENELC B/C/D.
The output goes from 0 to VDD. The maximum continuous DC current for both sourcing
and sinking is about 25mA.

Amplifies the voltage of the input signal (limited to the voltage supply VDD <= 5.5V) to the
higher levels of another external power supply (PA_VS from +7V to +24V).
Power
The PA offers a nominal gain of 6.5 V/V.
Amplifier
The PA is able to deliver 1.5A.
This project is designed for a +15V power supply

First Programmable Gain Amplifier in the reception chain, before the integrated low-pass
RxPGA_1 filter.
If provides four programmable gains: 0.25, 0.50, 1.00, 2.00 (in V/V units)

It is a filter in the reception chain intended to remove the unwanted signals out of the
Rx Filter CENELEC band. The cut-off frequency is affected by the parametrization of the CENELEC
mode (A vs B/C/D)

Second Programmable Gain Amplifier in the reception chain, after the low-pass filter.
RxPGA_2
It provides four programmable gains: 1, 4, 16, 64 (in V/V units)

This block can be used for simple implementations of communications that use amplitude
Two-Wire shift keying (ASK) with on-off keying (OOK) modulation.
Rx/Tx It is not used in this project because this functionality is already covered by the DAC-based
implementation.

Zero Crossing module to easily detect the AC phase edges and thus allow a better use of the
channel:
Zero
• some protocols can relay on it for synchronization purposes
Crossing
• the data can be transmitted near the zero-pass-region where the consumption of
connected machines or appliances may be lower
Table 6. AFE031 main blocks
Design of a low-cost device for data transmission over power lines 23/181

Block Pin name Description

SCLK Serial clock indicating when DI and DO are valid

DI Serial data sent from the BBB to the AFE031 (commands or DAC samples)

SPI Serial data sent back from the AFE031 to the BBB in response to BBB
DO
commands

Chip Select (Negated) used by the AFE031 as a strobe signal indicating the
CSN
end of a 10-bits DAC sample

Analog samples after the SPI to DAC conversion + TxPGA attenuation. This
TX_PGA_OUT
signal has a “step-shape” because the constant level between DAC samples

TX In this project the TX_PGA_OUT is directly routed to Tx_F_IN1. This leads

TX_F_OUT to be the result of applying the low-pass TxFilter to the
Tx_F_OUT
TX_PGA_OUT signal. The effect of this is a smother signal removing part
of the DAC-quantification shape

It is the input to the Power Amplifier. The PA requires the signal to do not
PA_IN have a DC component. To achieve this the TX_F_OUT traverses a
decoupling capacitor
PA
This is the output of the Power Amplifier which magnifies the input signal
PA_OUT
using the PA_VS power supply

Input signal coming from the AC decoupling stage + the external pass-band
Rx_PGA1_IN filter. A decoupling capacitor is also required to allow the AFE031 biasing
the level of the received AC signal

Output signal of the RxPGA_1 block. It is the RX_PGA1_IN after some

Rx_PGA1_OUT
programmable amplification factor.
= Rx_F_IN
This signal is directly connected to the input of the RxFilter (RX_F_IN)

Rx_F_OUT Rx_F_IN filtered signal in either CENELEC A or B/C/D band

RX
Input to the RxPGA_2 block. It is the RX_F_OUT after a decoupling
Rx_PGA2_IN
capacitor to allow the AFE031 for proper internal biasing of the AC signal

Rx_PGA2_OUT Output of the RxPGA_2 block after the last programmable amplification

Signal sent to the ADC of the BBB.

ADCIN
It comes from Rx_PGA2_OUT after a voltage resistor divider to adjust the
(not in the AFE
levels (from 0 to 3.3V) to the range of the ADC in the BBB (absolute max
but in the BBB)
value 1.8V)

Low-level “clone” of the 230VAC line for Zero Cross detection. The
ZC_IN1 230VAC can be converted to a low-level clone through high-impedance
ZC resistors or through an optocoupler

ZC_OUT1 Digital signal indicating the zero-crossing points

Table 7. AFE031 pins and signals
24/181 Design of a low-cost device for data transmission over power lines

2.3 BeagleBone Black (BBB)

The BeagleBone Black platform (http://beagleboard.org/support/bone101) can be considered an inexpensive
mini-PC having the most typical blocks of a full-featured desktop-PC:
Figure 6. BeagleBone Black components

These are its main features (extracted from http://beagleboard.org/black):

What is BeagleBone Black?
BeagleBone Black is a low-cost, community-supported development platform for developers and hobbyists. Boot Linux
in under 10 seconds and get started on development in less than 5 minutes with just a single USB cable.
Processor: AM335x 1GHz ARM® Cortex-A8
· 512MB DDR3 RAM
· 4GB 8-bit eMMC on-board flash storage
· 3D graphics accelerator
· NEON floating-point accelerator
· 2x PRU 32-bit microcontrollers
Connectivity
· USB client for power & communications
· USB host
· Ethernet
· HDMI
· 2x 46 pin headers
Software Compatibility
· Debian
· Android
· Ubuntu
· Cloud9 IDE on Node.js w/ BoneScript library
· plus much more
Design of a low-cost device for data transmission over power lines 25/181

The BeagleBone Black conception allows the addition of stackable boards (called capes) through two
headers giving access to the generic purpose pins provided by the main SOC of the BBB, the SITARA
AM3358 from Texas Instruments.

This is a brief summary about capes (extracted from http://beagleboard.org/cape):

What are capes?

The capes are products of the BeagleBoard.org community, which means they were designed by developers just like
you and, although a variety of capes exist today, we can’t wait to see what cool new cape concepts come next. You
have the chance to put your thinking cap on and tell us what we’ve missed by conceptualizing and designing your own
cape plug-in board! Register your idea today.

There are now over available 100 cape designs for display (DVI-D, HDMI, VGA, LCD, etc.), motor control, prototyping
and power supply (battery, solar, etc.) – among other functionalities – with more on the way. What will you create?

Some cape examples can be found in http://elinux.org/Beagleboard:BeagleBone_Capes.

The most important point in the design of a BBB cape is the interface with the platform, which is carried out
through the P8 and P9 connectors:
Figure 7. BeagleBone Black connectors P8 & P9

This project proposes a BBB-cape design for the SUPERVISOR unit (instead of developing a whole system
from scratch) to take advantage of the BBB functionality and the underlying Linux operating system.
26/181 Design of a low-cost device for data transmission over power lines

2.4 Arduino
Arduino is an open-source platform based on inexpensive, multipurpose, and easy-to-use hardware, that suits
medium complexity projects very well.

The Arduino ecosystem consists of:

• different board models to choose (depending on required features and cost)

• an IDE to program the sketches (scripts with the firmware). It relies on a custom language, Wire,
which is based on C and C++ but with some specific syntax

• auxiliary shields (stackable boards) that connect to the expansion headers and extend the
functionality of the platform

In this project I have chosen the Arduino framework for the REPORTING device because its popularity and
omnipresence, which lead to lower prices, readability and lots of reusable accessories.

I have used the Arduino Leonardo model because it is cheap and provides enough functionality to fulfill the
requirements. The main features concerning this project are:

• 5 V based logic, which can be supplied from the 2.1 Figure 8. Arduino Leonardo

mm power jack, the micro USB connector, or the Vin

pin

• 20 I/O. 7 can be used as PWM output

• DC Current per I/O Pin: 40 mA

• 8-bit CPU at 16 MHz (ATmega32u4)

• Flash Memory: 32 KB

• SRAM: 2.5 KB

• EEPROM: 1 KB

For more details go to the official website [8]. The schematics are also freely available online [9].

The Arduino Leonardo is similar to the Arduino Uno. The main difference is that the Leonardo includes
improved USB support which allows the board to simulate a HID device (as a mouse or a keyboard). This
feature is not used in this project, but the difference in cost is minor and it may be worth having it for other
future uses.

In this project I have used the PWM functionality to generate a square wave carrier of 110 kHz which is used
to modulate the data to be transmitted.
Design of a low-cost device for data transmission over power lines 27/181

2.5 Raspberry Pi
The Raspberry is a mini-PC similar to the BeagleBone Black but lacking an ADC. It is cheaper and more
popular. Its HDMI output and 3.5mm audio jack makes it ideal to be used as a low-cost (yet highly
customizable) media center to play content like HD videos (e.g. with the distribution https://libreelec.tv).

Here is a summary of the main features (from https://www.raspberrypi.org/products/raspberry-pi-3-model-b):

The Raspberry Pi 3 is the third generation Raspberry Pi. It replaced the Raspberry Pi 2 Model B in February 2016.
Compared to the Raspberry Pi 2 it has:
· A 1.2GHz 64-bit quad-core ARMv8 CPU Figure 9. Raspberry Pi 3 Model-B

· 802.11n Wireless LAN

· Bluetooth 4.1
· Bluetooth Low Energy (BLE)
Like the Pi 2, it also has:
· 1GB RAM
· 4 USB ports
· 40 GPIO pins
· Full HDMI port
· Ethernet port
· Combined 3.5mm audio jack and composite video
· Camera interface (CSI)
· Display interface (DSI)
· Micro SD card slot (now push-pull rather than push-push)
· VideoCore IV 3D graphics core
The Raspberry Pi 3 has an identical form factor to the previous Pi 2 (and Pi 1 Model B+) and has complete
compatibility with Raspberry Pi 1 and 2.
We recommend the Raspberry Pi 3 Model B for use in schools, or for any general use. Those wishing to embed their
Pi in a project may prefer the Pi Zero or Model A+, which are more useful for embedded projects, and projects which
require very low power.

There are different Pi versions. There is even one specific version for the connected home, the Raspberry Pi
Zero W. A clear summary of its purpose can be found in the Raspberry Pi website 3:
Today is Raspberry Pi’s fifth birthday: it’s five years since we launched the Figure 10. Raspberry Pi Zero W
original Raspberry Pi, selling a hundred thousand units in the first day, and
setting us on the road to a lifetime total (so far) of over twelve million units.
To celebrate, we’re announcing a new product: meet Raspberry Pi Zero W,
a new variant of Raspberry Pi Zero with wireless LAN and Bluetooth,
priced at only $10.

In this project I have used the RPI just as an example of portability of

the plc-cape software framework. As the RPI does not have an ADC
(a very useful block integrated in the BBB), I have limited the tests to produce audio output. And instead of
using a custom driver for this purpose (as done for the PlcCape), I have used the standard ALSA sound
system. For more details see the chapter 3.5.9 Multiplatform test with the Raspberry Pi.

3 Extract from https://www.raspberrypi.org/blog/raspberry-pi-zero-w-joins-family, posted the 28th Feb 2017

Photo from https://www.raspberrypi.org/blog/pi-for-the-connected-home
28/181 Design of a low-cost device for data transmission over power lines

3 Implementation
3.1 Overview
For the effective communication through the power line, in the most simplistic approach, we need to design
the electronics of a transmitter, the electronics of a receiver and some software/firmware for the logics
behind. This chapter will cover these areas:

Area Topics covered

Technical
Main requirements for the complete communication system.
specifications

Design of the BBB cape for the SUPERVISOR unit.

The BBB cape in this project has been called PlcCape (PLC stands for Power
The Line Communications). In conjunction with the BBB they constitute a device
SUPERVISOR able to transmit and receive commands through the AC line.
unit
This chapter includes the detailed description of two versions of the cape:
• PlcCape Version 1 is mainly aimed for testing.
• PlcCape Version 2 is the final candidate board.

Design of an Arduino shield for the REPORTING device.

For the reporting device the target is to build a simple low-cost only-
transmitting device which may be used as a template for other similar devices.
For that purpose I have relied on the Arduino platform.
The chapter covers:
The • How to generate a modulated signal with an Arduino Leonardo module.
REPORTING • The design of a simple Arduino shield that measures the ambient
device temperature and displays it on a 2x16 LCD.
• The integration of both functions: measurement + reporting through a
modulated signal.
• The usage of a very basic Push-Pull amplifier as an intermediate stage
between the reporting device and the AC line, to be able to deliver
enough current in low impedance conditions.

Evolutions of the existing software framework.

The existing framework is described in PlcCapeSoftwareFramework.pdf[1].
This chapter covers specifically:
• A new application, plc-cape-oscilloscope, to comfortably analyze the
PlcCape
received signals from the AC line and captured by the ADC of the BBB.
SOFTWARE
It is a kind of software-based oscilloscope.
framework
• A new application, plc-cape-freq-response, to comfortably get the
frequency response of a TX-RX loop.
• Improvements on the plc-cape-lab application.
• Improvements on other areas as new plugins, an emulator, etc.
Table 8: Summary of topics covered in the 'Implementation' chapter
Design of a low-cost device for data transmission over power lines 29/181

3.2 Technical specifications

In the below table there is a summary of the main requirements per block:

SUPERVISOR UNIT and REPORTING DEVICE

Output stage They must be behind a transformer to couple the signal with the AC line.

It must be alternating with no DC component and with a maximum value of

Output voltage 12 VPP. If possible, use a lower voltage (< 5 VPP) for simpler electronics and
lower cost.

The output stage at transmitting must be able to deal with low impedance
Output current
conditions in the AC line, in the order of the 100 Ω.

Frequency band 95 kHz to 125 kHz (CENELEC-B).

It is not a key factor. The target of the system is the communication of data
Baud rate
through short and sporadic packets.

SUPERVISOR UNIT

The SUPERVISOR unit must be able to transmit and receive data and with
different modulation schemes in order to communicate with several kind of
TX and RX devices.
versatility
It must be highly programmable to simplify the adaptation to different scenarios
and customizations.

Cost It should be affordable for a student or hobbyist.

REPORTING DEVICE

It must be able to TX in one of the modulation schemes supported by the

TX simplicity
SUPERVISOR.

It should be inexpensive in order many devices can be added to the network in

Cost
an affordable way.

SOFTWARE IN THE SUPERVISOR UNIT

It must be based on an operating system providing enough functionality to

cover all the possible demands: different modulation schemes, development of
Versatility helpful tools, customizations, statistics, etc.
It must support real-time interactive tools, like a mini-graphical software-based
oscilloscope to get in real time the samples captured by the ADC.
Table 9. Main requirements
30/181 Design of a low-cost device for data transmission over power lines

3.3 The SUPERVISOR unit

3.3.1 Overview
Our communication system is composed of a central unit (the SUPERVISOR) that should be able to transmit
and receive data over power lines. The central unit must be powerful enough to process the data and allow
smart and flexible interaction with.

The electrical energy distributed through the mains is based on a low frequency alternating current with high
voltage (230 VAC 50 Hz in Europe). We can use higher frequencies to transmit low-voltage coupled data.

The proposal for the SUPERVISOR unit is to develop a cape (an auxiliary board) compatible with the
BeagleBone Black. The cape (that I have named PlcCape) will add the extra functionality not available in
that platform and required for Power Line Communications (PLC), like the Analog Front End (AFE) and the
coupling layer.

To meet the versatility goals of this project I have looked for an integrated circuit with a DAC (Digital-To-
Analog Converter). This way we should be able to implement different modulation schemes by software
(more or less complex depending on the specific scenario and the requirements). For the core of the PlcCape
I have chosen the AFE031 chip from Texas Instruments[16].

3.3.2 Justification for the BeagleBone Black choice

The use of the BeagleBone Black is suitable for this project because:

• Being a popular platform, it is inexpensive and easy to reach.

• It is multipurpose and featured with most common blocks (SPI, DMA, GPIO, ADC…).

• It has high performance (~1 GHz).

• There is a lot of documentation and support available on the Internet.

• It is compatible with Linux-based distributions (Debian, Ubuntu, Ångström, etc.). We can benefit
from all the already existing functionality offered by the OS and the pre-installed packages.

• Being Linux-based, a lot of third party open software is available, as for example the GTK+/Cairo
framework in the GUIs area, or the FFTW library in the Engineering domain.

• Thanks to the open nature of Linux, the drivers can be customized to maximize the performance in
specific conditions.

• The pluggable and stackable conception of capes is a synonym of modularity and scalability.

• The use of a cape as an intermediary between the BBB and the “hostile” environment provides with
some kind of isolation: if the incoming signals exceed the supported levels, they can damage the
cape but probably will not reach the BBB. That is, the cape acts as a first shield or barrier stage that
protects the BBB.

3.3.3 Justification for the AFE031 choice

The AFE031 front-end is specially versatile because it includes a DAC to generate the output instead of just
providing the final modulated and encoded signal (as other chips do). The drawback is that modulation and
demodulation requires specific software to be developed. Additionally, this approach involves more
computational effort compared to the solution based on an all-integrated modem chip.
Design of a low-cost device for data transmission over power lines 31/181

The AFE031 has been chosen because:

• On the one hand, its DAC allows the implementation of very basic custom modulation schemes,
one of the goals of this project. For example, to emit short sporadic packets of data, we can use a
simple OOK modulation scheme (transmission speed would not be a decision criteria here).

• On the other hand, its DAC allows the implementation of more complex modulation schemes for
increased throughput (at the expense of more computational effort).

• Being able to implement any modulation scheme, the interoperability with other devices can be
carried out easily.

• Having full control on the modulation scheme allow us for the implementation of different error
control mechanisms: parity, checksum, CRC, ECC, etc. It also allows for different protocols:
master-slaves with turns, event-based, based on assigning predefined time slots or frequency carriers,
etc.

• The AFE031 is specifically targeted to power line communications within the CENELEC bands.

• Being an inexpensive chip and requiring few extra components, it is a cost-effective solution for a
Power Line Communications module.

• By integrating into the AFE031 the main blocks required (DAC, Power Amplifier, Programmable
Gain Amplifiers, Filters…), it simplifies the miniaturization of the board.

• It can be easily connected to the BeagleBone Black via its SPI bus.

• It is reusable for other purposes due to its extensive pin-out (48-pins) which gives access to the
different signals involved in the TX and RX paths.

In the AFE031 documentation[18] we have a good summary of the main features offered by the chip:
The AFE031 is the industry's first and most flexible analog front-end designed specifically to meet the rigorous
demands of power-line communication applications. Using the AFE031 saves design time, increases reliability, and
reduces risk. The AFE031 can connect to virtually all microprocessors. The device can be driven with both digital or
analog inputs; it conditions and filters the signals, and then transmits the signals to the power line through the
integrated power amplifier. The integrated, low-noise receiver can be configured to provide either attenuation or gain,
depending upon the signal and noise levels on the power line and drives the analog-to-digital converter found in most
microcontrollers. The AFE031 can work with multiple signal types, including FSK, SFSK, or OFDM. With proper line-
coupling circuit design, the AFE031 can be used in a wide variety of applications that range from dc busses to MV (7.2
kV) transmission lines.

Finally, just a mention to the different versions of this Analog Front End:

• There is an old version, the AFE030, a bit cheaper but with fewer features.

• There is a new version, the AFE032, which provides a better filtering by using an internal DSP. It is
not fully compatible at pin level with the AFE031. Thus, it will imply some adaptations in the PCB.

In this project I have used the AFE031 because it was the version with the largest availability in the main
distributors.

3.3.4 Design notes and limitations

The design of the PlcCape is based on the circuit proposed in the Application Note of the AFE031 [16]. I have
adapted it to the layout of BBB capes.
32/181 Design of a low-cost device for data transmission over power lines

I have not included an EEPROM for identification purposes (which is a recommend practice when building
commercial capes) because I did not have enough room, nor time for. This results in a simpler cape but
special care should be taken if we stack it with others.

For the schematics and the PCB routing I have used EAGLE 7.5 which offers a free license for developing
boards of reduced dimensions4:
Download free version of EAGLE

* PCB design software for students, makers, and professionals.

* Includes 2 schematic sheets, 2 signal layers, and 80 cm2 board area.

* Available for Windows, Mac, and Linux.

The PlcCape fits within these limitations.

For the schematic and the PCB layout of the BBB cape headers I have downloaded the Adafruit library
adafruit.lbr[6].

I have downloaded the layout of the AFE031 with a specific tool, UltraLibrarian (see 6 Annex I. Tools).

For some SMD components I have created custom PCB footprints because I neither found an exact match on
the pre-installed libraries, nor found a suitable installable package.

Finally, we also need to consider other specific limitations tied to the manufacturing process of the board
prototypes at the laboratory:

• The vias (through-hole connections from the top layer to the bottom layer) are not metalized. That
means that the connection between top and bottom layers must be done manually filling them with
solder paste. Therefore, we should minimize the use of vias to simplify the manual soldering phase.

• The no metalization of the vias imposes another constraint too: on through-hole components, only
the “back” layer must be used as the “front” layer (where the component package is exposed) is
likely going to be inaccessible.

• The minim resolution of the PCB traces is 0.2 mm.

For the pinout of the AFE031 and the corresponding signal meanings, take a look at 2.2.2 AFE031 blocks
and pins. For the interfacing with the BBB (pins in the connection headers), take a look at 2.3 BeagleBone
Black (BBB).

3.3.5 PlcCape versions

I have developed two versions of the PlcCape during the evolution of this project:

• PlcCape-v1: targeted to have an initial contact with the PLC technology. It includes many easily
accessible test points. The AC coupling block (transformer + protection + AC phase detection) is
implemented in an auxiliary board due to space constraints and also for modularity (it allows isolated
tests with it, it can be reused on different configurations, etc)

• PlcCape-v2: conceived to be the first final version. It contains all the required circuitry, including
the AC coupling block. It has fewer test points and they are more difficult to reach. Pluggable
connectors have been added to simplify the interfacing with the external power supply and with the
Power Line. It embeds some LEDs to simplify monitoring and troubleshooting.

4 See www.cadsoft.de/freeware.htm or http://www.autodesk.com/products/eagle/free-download

Design of a low-cost device for data transmission over power lines 33/181

3.3.6 PlcCape-v1
3.3.6.1 Overview
The main target of the first version of the PlcCape board is to test the functionality of the core integrated
circuit, the AFE031. For that purpose the board has been designed with many easily accessible probing
points on the most interesting signals. Some DIP sockets have been also included to simplify the
experimentation phase with through-hole components.

3.3.6.2 Schematics
To simplify the reading, this section is divided in four areas:

Expansion header Description of the connection interface between the BBB and the PlcCape

AFE031 Core AFE031 and surrounding logic providing the core functionality of the cape

Connection interface between the PlcCape and the AC coupling auxiliary

Auxiliary header
board (containing the coupling transformer and the AC protection)

Power supply
Connections and capacitors in the power supply network
network

EXPANSION HEADER

The expansion header connects the BBB to the PlcCape through the P9 connector. This is a summary of the
pins and signals involved:

Figure 11. PlcCape-v1 SCH P9 connector

OUTPUTS (BBB-to-PlcCape)
DIN [SPI] Serial Data
SCLK [SPI] Serial Clock
CSN [SPI] Chip Select Negated
DAC DIN flag: commands or
DAC samples
SD AFE shutdown

INPUTS (PlcCape-to-BBB)
DOUT [SPI] Serial Data
(responses)
INT INTerrupt event
TX_FLAG TX block is ready
RX_FLAG RX block is ready
ADCIN Analog data
ZC_OUT Zero crossing of AC
34/181 Design of a low-cost device for data transmission over power lines

AFE031 CORE

Find following the schematic diagram of the PlcCape core:

Figure 12. PlcCape-v1 SCH AFE031 core circuitry

The 48-pins AFE031 integrated circuit is in the center of the picture:

• At top left we can see the SPI bus lines and associated pull-ups (R1 to R4).

• At bottom left there is the connection from the AFE031 RX chain to the ADC of the BBB (ADCIN).
Note that at the BBB-side the ADC voltage must not exceed 1.8 V (to avoid irreversible damage).
That is why I have placed a ½ voltage resistor divider (R14 and R15): the AFE031 output can go
from 0 to 3.3 V; after the ½ divider the signal is attenuated to a maximum of 1.65 V.

For a future version, we should use a more accurate and repeatable divider to avoid surprises with
the tolerance of the resistors. It would also be interesting to add some protection diode to avoid that
glitches over 1.8V reach the ADC of the BBB.

• At top right you can find the output of the Power Amplifier stage of the AFE031 (L3, D2, D3, R11,
C12).

• At bottom right we have a first band-pass filtering stage in the RX chain composed of a forth-order
passive RLC network (C11, L2, R12, R13, C8, L1, C7) which is in charge of eliminating frequency
content out of the band of interest. Its purpose is to do a first cleaning of the signal before reaching
the RX chain of the AFE031.

NOTE: the values specified in the above schematic for the RLC passive network correspond to the
CENELEC-A band. See 4.2.2 RX filtering for more details.

Remarks:

• You can find a SMD jumper in SJ2 to connect GND to GNDA. This is a trick in EAGLE to have two
different ground paths (I wanted GNDA to be routed with wider traces because they have to support
higher currents). In the physical board we have to put solder paste on it to interconnect both GNDs.
Design of a low-cost device for data transmission over power lines 35/181

AUXILIARY HEADER

The auxiliary header (JP1) is mainly intended to connect the TXRX signal with the coupling board:

TXRX Analog signal to be sent to (or received from) the AC

Figure 13. PlcCape-v1 SCH
(in and out) coupling circuit
JP1 connector
ZC_IN Low-level voltage version of the AC wave in order the
(input) Zero Crossing block in the AFE031 can detect its phase

V+ & GNDA Power Supply for the Power Amplifier block in the
AFE031. It accepts voltages from 7 V to 24 V,
(input) according to the datasheet[17]

+5V & GND Power Supply for the 5 V logic. This is connected to
(in or out) the external power supply rail (2.1mm jack)

Note that the +5V pin can be used for two purposes (due to the direct connection with the 2.1mm jack):

• to supply 5 V through this pin instead of using the 2.1mm jack

• to get the 5 V from an external power supply connected to the 2.1mm jack (and thus, be able to
comfortably power other 5 V based circuits)

Note, however, that if the BBB is powered through the USB, there is no voltage in the +5V pin. In fact, if
you look at the Figure 11 you will see that the P9 connector in the BBB offers two 5V pins:

• VDD_5V: directly connected to the power rail of the 2.1mm jack

• SYS_5V (not used in this project): which comes from the USB

For more details see the section 8.6 Cape Power of the reference manual[3]. Here an extract:
VDD_5V is the main power supply from the DC input jack. This voltage is not present when the board is powered via
USB. The amount of current supplied by this rail is dependent upon the amount of current available. Based on the
board design, this rail is limited to 1A per pin from the main board.

The SYS_5V rail is the main rail for the regulators on the main board. When powered from a DC supply or USB, this
rail will be 5V. The available current from this rail depends on the current available from the USB and DC external
supplies.

POWER SUPPLY NETWORK

Finally, find below the schematic diagram corresponding to the power supplies:
Figure 14. PlcCape-v1 SCH Power supplies

For the 3V3 power rail (coming from a LDO on the BBB), I have just added the typical capacitors.

For the power supply that feeds the Power Amplifier in the AFE031, I have also added a diode (assuming a
+15 V power supply) to protect the logic against glitches (as recommended in the AFE031 technical note [16]).
36/181 Design of a low-cost device for data transmission over power lines

3.3.6.3 Printed Circuit Board

For the routing I have configured the EAGLE application for a minimum resolution of 0.2mm and with
wider traces for the lines carrying more current (around the Power Amplifier).

I have executed a tentative auto-routing operation to have an initial proposal from the tool, and then adjusted
the traces and vias manually having in mind these considerations:

• The components will be manually soldered. So, space them enough.

• The vias need to be filled with solder paste (and with a mini wire to help in the process) because the
manufacturing equipment at the laboratory makes the hole but it does not place the metallic link
between top and bottom layers. So, try to minimize vias usage.

• In through-hole components, it would be difficult (or even impossible) to solder the pin-hole area in
the package-side. So, do not route any trace on the package-side of a pin-hole.

• The vias arranged under the AFE031 (the small square in the center of the board) are for better heat
dissipation[19]. We must fill these vias before soldering the AFE031 to set the link between top and
bottom layers. Otherwise, we would lose a connection to GND which will force us to make a
bridging patch somewhere else.
Figure 15. PlcCape-v1 PCB Top Figure 16. PlcCape-v1 PCB Bottom

This is the result of the manufactured board with the AFE031 core already soldered in the center:
Figure 17. PlcCape-v1 board - Top Figure 18. PlcCape-v1 board - Bottom
Design of a low-cost device for data transmission over power lines 37/181

3.3.6.4 Bill of Materials

This is the list of components required to build the PlcCape-v1 board:

Qty Value Device Package Parts

1 DIL4 DIL04 IC3
1 DIL6 DIL06 IC2
1 DIL8 DIL08 IC1
1 PINHD-1X2 1X02 JP2
1 100n C-EUC1206 C1206 C13
7 10K R-EU_M0805 M0805 R1, R2, R3, R4, R5, R6, R11
5 10n C-EUC0805 C0805 C1, C5, C7, C9, C18
1 10n C-EUC1206 C1206 C14
1 10u C-EUC0805 C0805 C17
2 10u C-EUC1206 C1206 C12, C15
2 150 R-EU_M0805 M0805 R12, R13
2 1N5819 1N5819HW-7-FJMO SOD-123[JMO] D2, D3
1 1SMB5934BT3G ZENER-DIODESMB SMB D1
1 1X6 PINHD-1X6 1X06 JP1
2 1k R-EU_M0805 M0805 R14, R15
2 1u C-EUC0805 C0805 C2, C10
1 1u CBC3225T1R0MR IND_TAIYO_CBC3225 L3
1 1x5 TESTPIN6 TESTPIN6 TP4
1 22n C-EUC0805 C0805 C8
1 270p C-EUC0805 C0805 C4
1 330 R-EU_M0805 M0805 R8
1 330u CBC2518T331K IND_TAIYO_CBC2518 L2
3 33K R-EU_M0805 M0805 R7, R9, R10
1 33n C-EUC0805 C0805 C11
1 3n3 C-EUC1206 C1206 C6
1 470u CBC2518T331K IND_TAIYO_CBC2518 L1
1 47u C-EUC1206 C1206 C16
1 560p C-EUC0805 C0805 C3
1 AFE031_RGZ_48 AFE031_RGZ_48 RGZ48_4P1X4P1 U2
BEAGLEBONE_OUT
1 BEAGLEBONE_OUTLINE BEAGLEBONE_SHIELD U1
LINE
3 PTR1B1,27 PTR1B1,27 B1,27 TP1, TP2, TP3
2 SJ SJ SJ SJ1, SJ2
Table 10. PlcCape-v1 Bill of Materials

Remarks:

• IND_TAIYO_CBC2518 and IND_TAIYO_CBC3225 are footprints imported from the manufacturer

page.

• SOD-123[JMO] is a customized footprint for the 1N5819 SMD diodes. I modified an existing one
by increasing the contact area to simplify the manual soldering process.
38/181 Design of a low-cost device for data transmission over power lines

3.3.6.5 Final cape

The final cape after soldering all the components is shown below:
Figure 19. PlcCape-v1 mounted board Figure 20. PlcCape-v1 + AC coupling module + BBB

At left there is a top view of the PlcCape-v1.

At right we have the PlcCape-v1 with the auxiliary coupling module attached, and the whole plugged into a
BBB.

I have soldered all the pins in the P9 header (even the not used ones) for simplicity. In the P8 header, though,
I have only soldered four pins (in the borders) for lesser insertion/extraction force, yet good enough for
proper placement and mechanical stability.

3.3.6.6 Probing points

In the next figure I have indicated the probing points for the signals of interest:
Figure 21. PlcCape-v1 probing points

In green there are the easily accessible probing points (through a female pole); in yellow, the SMD-based
ones (requiring the oscilloscope probe to be manually held during the measurement).
Design of a low-cost device for data transmission over power lines 39/181

3.3.6.7 AC coupling auxiliary module

The circuitry related to the coupling with the power line has been designed in an auxiliary mini-board
attachable to the PlcCape-v1. This is the schematic diagram for:
Figure 22. Auxiliary AC coupling module - Schematic

In the AC coupling module I have also added a ZC_IN line providing a low-voltage version of the AC wave,
intended for Zero Crossing detection. The given circuit (R2, R3, R4, D1, D2) converts the 230VAC sine
wave (~650VPP) to a ~3 VPP square waveform. Note that the X5 pole must be fed with 3.3V for this to work.
As this opens a direct path from the 230VAC to the digital logic, a jumper has been added (JP2) to isolate it
when not used (just as a safety measure). The Zero Crossing detection has neither been used nor evaluated in
this project because I have been short of time.

As it is a simple circuit, I have made it in a perfboard:

Figure 23. Auxiliary AC coupling module - Top Figure 24. Auxiliary AC coupling module - Bottom

The connections in perfboards are usually carried out with short thin wires. Here, I have done the
connections directly with solder paste to make them easier to track.
40/181 Design of a low-cost device for data transmission over power lines

The mapping between the schematic and the top side of the perfboard is shown in the right figure:

GNDA Connection points for the 15 V power supply that will Figure 25. Auxiliary AC coupling
V+ feed the Power Amplifier block in the AFE031. module connections

Pins for the 5 V supply. They come from the power rail
tied to the 2.1mm jack in the BBB. Thus, these pins can
be used in two ways:
▪ to get the 5 V from an external supply connected to
5V the BBB through the 2.1mm jack
GND ▪ to supply the BBB with 5 V coming from an external
supply connected to these pins (5V and GND)
Note that these pins are not used by the AC Coupling
module. They have been included in the board just for
comfortable access to the 5 V.

AC_L
They form the connection point with the AC line.
AC_N

To end the chapter, it is worth having a quick look at the JP1 jumper because it offers different configurations
that can be used to simplify the interconnection between modules. By looking at the circuit as it is presented
in Figure 25 we would have these possibilities:

• Jumper on middle and right pins (JP1.2 & JP1.3): this is the standard configuration when using
the module attached to the PlcCape board. It enables the AC coupling transformer and protective
components. The TXRX signal (on the pin 2 of the H1 header) is coupled/decoupled to the signal
present in the AC pins (AC_L and AC_N). There is an example of this configuration in Figure 73.
RX chain analysis - PlcCape + Push-Pull + PlcCape - Testing environment.

• Jumper on middle and left pins (JP1.2 & JP1.1): this allows testing the TXRX line over a simple
resistor placed in the X4 connector.

• Jumper establishing a short-circuit among the three pins (JP1.1 & JP1.2 & JP1.3): this
configuration is suitable for connecting the coupling board to other external modules. It enables the
AC coupling block but also the X4 connector in the top side, allowing a comfortable connection of
an external TXRX through it (instead of using the pin 2 in the H1 header in the bottom side, which
has a more difficult access). An example of this configuration can be found in Figure 84. AC
coupling module - Testing environment.
Design of a low-cost device for data transmission over power lines 41/181

3.3.7 PlcCape-v2
3.3.7.1 Overview
The PlcCape-v1 board was focused on testing.

The PlcCape-v2 is aimed at becoming a first final candidate. For that matter it is required to:

• integrate all the mandatory components in the board (including the coupling part) and remove the
unnecessary blocks from PlcCape-v1

• add some means to notify about current activity status

• add a customizable generic purpose output (to optionally connect relays, buzzers, etc.)

• provide screw-based connectors to simplify the connection through wires

• include some probing points (just the essentials) for easy testing and checking

• correct some design flaws of PlcCape-v1

The above objectives turn into these concrete modifications (with regard to PlcCape-v1):

AC coupling The circuitry related to the AC coupling module will be integrated in the
module cape instead of requiring an auxiliary board.

Two low power LEDs will be used to notify about TX and RX status.
LEDs One medium power LED will be used to indicate the proper operation of the
Power Amplifier voltage (if provided). For the 5 V supply, we will rely on
the existing LEDs in the BBB.

Generic-purpose A generic-purpose transistor-based output will be added. A low power LED

output will indicate when the output is enabled.

Three screw-based connectors will be required:

▪ a connection for the 230VAC line
▪ a connection for the 15 V external supply feeding the Power Amplifier
▪ an optional connection to have easy access to the output of the AFE031
Connectors (PA_OUT) before reaching the AC coupling block (which will be
disabled through a jumper). The target of this configuration is to allow
reusing the PlcCape functionality (DAC generation + Power Amplifier)
for other purposes which do not require the AC coupling block, like
audio output, custom wave generation, etc.

Three testing points will be preserved: TP1 (AFE031 temperature), TP2

Probing points
(TX_PGA_OUT) and TP3 (RX_F_IN).

The meaning of DIN and DOUT in the SPI bus will be toggled in order to
follow the standard default convention.
Corrections
The size of the ground area surrounding the AFE031 QFN package must be
expanded as much as possible for better thermal dissipation [19]

Table 11. PlcCape-v2 vs PlcCape-v1 modifications

42/181 Design of a low-cost device for data transmission over power lines

3.3.7.2 Schematics
The schematics of PlcCape-v2 are divided in these functional areas:

Description of the connection interface between the BBB and the PlcCape.
Expansion headers
The differences with PlcCape-v1 will be highlighted.

Core AFE031 and surrounding logic providing the core functionality of the cape.

AC coupling Block that couples the low-level logic with the high-voltage in the AC line.

Zero-crossing block Detection of the zero-crossing instants of the 230VAC 50Hz wave.

LEDs and generic LEDs to notify about current activity.

purpose output An optional generic purpose output to drive other devices (like relays).

Header to have easy access to the power supplies and the generic purpose
Auxiliary header
output.

Power supply
Connections and capacitors in the power supply networks.
network

EXPANSION HEADERS

These are the pins used from the P9 header in the BBB:
Figure 26. PlcCape-v2 SCH P9 connector
Design of a low-cost device for data transmission over power lines 43/181

The following figure shows in red the main differences with PlcCape-v1:
Figure 27. PlcCape-v1 vs. PlcCape-v2 in the interfacing with the BBB

• DIN and DOUT are reversed to be coherent with the standard SPI criteria.

• INT signal has been moved from SPI1_CS0 to GPIO1_17 to let SPI1 free for other possible future
uses or for an additional stacked cape.

• A new block of pins (GEN_OUT, TX_OUT and RX_OUT) has been reserved for the generic-purpose
output and for LED control

CORE

The core logic surrounding the AFE031 is almost identical to the one in PlcCape-v1:
Figure 28. PlcCape-v2 SCH AFE031 core circuitry
44/181 Design of a low-cost device for data transmission over power lines

AC COUPLING

This block is in charge of coupling the low-voltage signal generated by the AFE031 (TXRX) to the high AC
voltage present in the mains:
Figure 29. PlcCape-v2 SCH AC coupling block

ZERO CROSSING

This block generates, in ZC_IN, a low-voltage square version (3.3 V PP) of the AC sinusoid (230VAC). It will
reach the AFE031 and be used to detect when the AC voltage crosses zero. In future applications we might
use it as a synchronization mechanism.
Figure 30. PlcCape-v2 SCH Zero Crossing block

Due to time constraints I have not tested this block. In fact, I have not even soldered it. It is something to be
evaluated in a future iteration.

LEDs and GENERIC PURPOSE OUTPUT

In PlcCape-v2 I have added a couple of LEDs to notify about TX and RX activity. Low power LEDs have
been used because they will be directly driven by BBB output pins, which have limited current sourcing
capabilities.
Design of a low-cost device for data transmission over power lines 45/181

I have also added a transistor-based open-collector multipurpose output to connect optional devices like a
relay, buzzer, horn, or similar. I have included a low power LED to notify about the current status of the
output.
Figure 31. PlcCape-v2 SCH LED monitoring block

AUXILIARY HEADER

The auxiliary header provides easy access to the low power supplies used by the cape (3.3 V and 5 V). There
is also a pin reserved for the generic purpose output.
Figure 32. PlcCape-v2 SCH Auxiliary connector

For the +5V power supply, it applies the same considerations as in PlcCape-v1 (see the section Auxiliary
Header in 3.3.6.2 Schematics): +5V is connected to the 2.1mm jack rail (external power supply); if the BBB
is powered via USB, this line will not have any voltage.

The +3V3, however, is always working because it comes from an LDO regulator in the BBB, as indicated in
the section 8.6 Cape Power of the Reference Manual[3].

POWER SUPPLY NETWORK

The power supply network is the same as in PlcCape-v1 except for an extra LED that has been added to
indicate whether the 15 V voltage is present.
Figure 33. PlcCape-v2 SCH Power supplies
46/181 Design of a low-cost device for data transmission over power lines

3.3.7.3 Printed Circuit Board

The below figures show the routing of the PlcCape-v2 prior to the auto expansion of the ground layer
executed by the EAGLE tool:
Figure 34. PlcCape-v2 PCB Top Figure 35. PlcCape-v2 PCB Bottom

And this is the resulting board with the AFE031 already soldered:
Figure 36. PlcCape-v2 board - Top Figure 37. PlcCape-v2 board - Bottom

In the bottom layer we can clearly see the large ground area surrounding the AFE031 and the solder paste
dispensed to the vias, for better thermal dissipation.

3.3.7.4 Bill of Materials

Qty Value Device Package Parts
1 100n C-EUC1206 C1206 C13
R1, R2, R3, R4, R5,
9 10K R-EU_M0805 M0805
R6, R11, R19, R27
1 10k R-EU_M0805 M0805 R22
4 10n C-EUC0805 C0805 C5, C7, C18, C19
1 10u C-EUC0805 C0805 C17
4 10u C-EUC1206 C1206 C12, C14, C15, C16
2 150R R-EU_M0805 M0805 R12, R13
1 15u L-RADIAL RADIAL-9.5MM-5MM L4
Design of a low-cost device for data transmission over power lines 47/181

Qty Value Device Package Parts

3 1K R-EU_M0805 M0805 R18, R23, R24
1 1K5 R-EU_M0805 M0805 R17
2 1N5819 1N5819HW-7-FJMO SOD-123[JMO] D2, D3
1 1SMB5930B ZENER-DIODESMB SMB D1
2 1k R-EU_M0805 M0805 R14, R15
1 1n C-EUC0805 C0805 C1
1 1u C-EUC0805 C0805 C10
1 1u CBC3225T1R0MR-W IND_TAIYO_CBC3225[W] L3
1 20020107 20020107 20020107-D021 X3
1 22n C-EUC0805 C0805 C8
1 270p C-EUC0805 C0805 C4
1 330R R-EU_M0805 M0805 R8
3 330k R-EU_M0805 M0805 R21, R25, R26
1 330u CBC2518T331K-W IND_TAIYO_CBC2518[W] L2
3 33K R-EU_M0805 M0805 R7, R9, R10
1 33n C-EUC0805 C0805 C11
1 3n3 C-EUC1206 C1206 C6
1 470n C-EU150-072X183 C150-072X183 C20
1 470u CBC2518T331K-W IND_TAIYO_CBC2518[W] L1
1 4R7 R-EU_M0805 M0805 R16
1 560p C-EUC0805 C0805 C3
5
1 750510476JMO 750510476JMO EE13/7/4_THT_H_9PIN_(5662)[JMO] T1
1 AFE031_RGZ_48 AFE031_RGZ_48 RGZ48_4P1X4P1 U1
1 BC817-25SMD BC817-25SMD SOT23-BEC Q1
1 BEAGLEBONE_OUTLINE BEAGLEBONE_OUTLINE BEAGLEBONE_SHIELD CAPE1
1 COUPLING PINHD-1X2 1X02 JP3
2 CTB932VD CTB932VD CTB932VD/2 X1, X2
1 GREEN LEDSML0805 SML0805 LED3
1 ORANGE LEDSML0805 SML0805 LED1
1 P6SMBJ7.5CA SCHOTTKY-DIODESMD SMB D4
2 PTR1B1,27 PTR1B1,27 B1,27 TP2, TP3
1 PWR PINHD-1X4 1X04 JP1
1 RED LEDSML0805 SML0805 LED2
1 R_ISET PINHD-1X2 1X02 JP2
1 SJ SJ SJ SJ2
1 TCMT1600 TCMT1600 MINI-FLAT-4 OK1
1 TMOV20RP300E TMOV20RP300E TMOV20RP300E R20
1 TSENSE PINHD-1X1 1X01 TP1
1 YELLOW LEDSML0805 SML0805 LED4
Table 12. PlcCape-v2 Bill of Materials

The most expensive components in the board are6:

• AFE031_RGZ_48: 4.83€ (unitary cost), 2.37€ (1000+)

• 750510476 transformer: 5.33 € (unitary cost), 3.87€ (500+)

5 I have manually edited the footprint for the transformer. I have used the JMO suffix to indicate it.
6 Prices consulted on 24-Apr-2017 at http://www.mouser.es
48/181 Design of a low-cost device for data transmission over power lines

3.3.7.5 Final cape

This is the look of the final PlcCape-v2 with all the components mounted:
Figure 38. PlcCape-v2 mounted board

3.3.7.6 Probing points

These are the probing points for the most interesting signals:
Figure 39. PlcCape-v2 probing points

The meaning of the background colors in the labels is:

• in green, the easily accessible probing points (through female poles or screw connectors)

• in yellow, the SMD-based ones (requiring the probe to be manually held during the measurement)

• in red, the screw connector for the 230VAC (special care must be taken if measuring there!)
Design of a low-cost device for data transmission over power lines 49/181

3.3.7.7 TX_F_OUT bridge

Unfortunately, during the testing phase, I damaged the AFE031 Power Amplifier stage of my PlcCape-v2
because I stressed it when connected to the 230VAC mains. I guess the root cause was a combination of a too
low impedance in the line, a too large voltage swing at the AFE031 output, and a bad thermal dissipation.

Figure 40. PlcCape-v2 TX_F_OUT bridge I did not have time to prepare a new board.
Instead, I patched it in order to make the
TX_F_OUT easily available. In particular, I put
a bridge (black mini-wire) bringing the
TX_F_OUT to the non-functional PA_OUT trace.
I removed L3 to open the path with the AFE031
PA_OUT pin and thus, avoid any undesirable
loop.

As the PA_OUT was available through the screw

connector X2-1, then, after this patch, we had
TX_F_OUT there.

So, I lost the PA functionality but I gained an

easy connection to TX_F_OUT, which is as interesting as PA_OUT when just low currents are required.

In fact, if we need extra current we can easily connect an external amplifier, which can also be an interesting
alternative (or complement) to the internal PA on some scenarios. For example, an external current amplifier
could be designed to source higher currents. Moreover, the thermal dissipation design could be simpler
compared to the thermal constraints of the miniaturized AFE031. We will see an example of a very basic
external amplifier in the 3.4.4 Push-Pull amplifier chapter.

Some drawbacks of the external amplifier approach are:

• It would generally be more expensive because the extra components required.

• It will imply a bigger board due to the room required for the dedicated Power Amplifier stage.

In any case, the Power Amplifier is not required for the specific scenarios covered in this project, where the
transmitter (the REPORTER device) will be an Arduino-based system with a dedicated amplifier module.
The PlcCape and its AFE will work in the receiver side (the SUPERVISOR unit).

3.3.7.8 Future improvements

During the development of this project, I have found some basic short-term improvements that should be
considered for a future version of the board:

• For safety, change the type or size of the AC connectors to make them incompatible with the low-
voltage ones, in order to avoid dangerous mistakes. In fact, in the current board, they already have a
different size, but the difference is so small that they can be wrongly plugged by applying little force.

• Improve miniaturization and integration to give room for other components (as an EEPROM, more
testing points, some button, etc.): use SMD resistor arrays instead of multiple isolated SMD resistors
(specially useful on pull-ups); use a two-layer board with intermediate ground planes for shorter
routing paths (and hence, closer components), etc.

• Use double side headers (in P8 and P9) to allow stacking other BBB capes on top of the PlcCape.
50/181 Design of a low-cost device for data transmission over power lines

3.4 The REPORTING device

One of the goals of this project is to provide a framework that allows the use of simple and low-cost
reporting devices through the power line.

For simplicity in the development I have opted to be based on an existing system. I have chosen the Arduino
platform because:

• It is an easy-to-use platform thanks to its programming IDE.

• It is very popular and thus, easy-to-reach from multiple providers.

• It is inexpensive.

• It is multipurpose and reusable (the same board can be used for specific purposes through shields).

I have chosen the Arduino Leonardo model because:

• Through its PWM subsystem, it is able to generate simple OOK modulated data (On-Off Keying 7)
with the carrier frequency required for this project (110 kHz)

• It has enough Input/Output functionality to deal with different kind of sensors.

Contrary to the SUPERVISOR unit, the REPORTING device only needs to send data. And for the OOK
modulation we do not need a DAC. We can use a square wave signal and apply some basic filtering to reduce
the level of the harmonics. This will bring the resulting carrier closer to a sinusoidal shape.

3.4.1 Simple transmitter with Arduino

For this test I am going to use an Arduino Leonardo powered through the USB. I will use the output 13 for
the signal to be transmitted:
Figure 41. Arduino Leonardo - Simple transmitter test

In the programming side, I have developed a simple sketch to periodically send a Hi word wrapped in an
OOK modulation at 110 kHz:

7 More information on https://en.wikipedia.org/wiki/On-off_keying

Design of a low-cost device for data transmission over power lines 51/181

SendModulatedMsg.ino
/**
* PURPOSE:
* Send a message periodically using a square carrier of a specified frequency (around 100kHz)
* The modulated signal is forwarded to pin13
*
* TARGET MODEL:
* Arduino Leonardo
* It relies on FastPWM (High Speed TIMER4)
*
* NOTES:
* FastPWM-part based on code from:
* http://r6500.blogspot.com.es/2014/12/fast-pwm-on-arduino-leonardo.html
*
* LICENSE:
* Copyright (C) 2017 Jose Maria Ortega
* Distributed under the GNU GPLv3. For full terms see the file LICENSE
*/

#define PWM_BASE 96000000L

#define PWM13 OCR4A

#define DELAY_BETWEEN_MESSAGES_MS 1000

#define DELAY_BETWEEN_SYMBOLS_MS 5
#define SYMBOLS_LENGTH_MS 1

// Examples of frequency ranges using a 96M/2 clock base (PLLFRQ = 0x4)

// Double the reported values if PLLFRQ configured for divider = 1
// clock_base_divider_one -> Base = 48 MHz
// Min freq div 0 = 48M/256 = 187.5 kHz
// Max freq div 0 = 48M/1 = 48 MHz
// Min freq div 6 = 48M/256/2^6 = (Min freq div 0)/64 = 2929.7 Hz
// Max freq div 6 = 48M/2^6 = 750 kHz
// clock_base_divider_one_half -> Base = 32 MHz
// Min freq div 0 = 32M/256 = 125 kHz
// Min freq div 6 = 32M/256/64 = 1953.1 Hz
// clock_base_divider_two -> Base = 24 MHz
// Min freq div 0 = 24M/256 = 93.75k Hz
// Min freq div 6 = 24M/256/64 = 1464.8 Hz
enum clock_base_divider_enum : byte {
clock_base_divider_one = 0,
clock_base_divider_one_half,
clock_base_divider_two
};

unsigned char pwm13_dutty_half;

// NOTE: For some apparently strange reason Arduino IDE 1.6.4 doesn't allow me to use
// 'clock_base_divider_enum' in the function prototype. Patch: use 'byte' instead
unsigned char configure_pwm13(byte clock_base_divider, unsigned char timer_divider_pow,
long required_freq)
{
TCCR4A = 0;
TCCR4B = timer_divider_pow+1;
TCCR4C = 0;
TCCR4D = 0;

long freq_clock = PWM_BASE;

// When the Arduino IDE uploads new firmware it seems to modify the 4-low-bits PLLFRQ0..3,
// corresponding to PDIV0..3. That value doubles the PLL frequency compared to the initial value
// when re-powering the board (PDIV = 0x4). The effect is that the PWM frequency after firmware
// uploading doubles the PWM frequency after re-powering (note however that using the Reset button
// keeps PDIV). To avoid this, we should force 'PLLFRQ = 0x4' instead of just masking the
// PostScaler with 'PLLFRQ &= 0xCF'
PLLFRQ = 0x4;

// The 'PLLFRQ = 0x4' divides by 2 the max freq

freq_clock /= 2;

switch(clock_base_divider)
{
case clock_base_divider_one:
PLLFRQ |= 0x10;
break;
52/181 Design of a low-cost device for data transmission over power lines

case clock_base_divider_one_half:
PLLFRQ |= 0x20;
freq_clock = freq_clock/3*2;
break;
case clock_base_divider_two:
PLLFRQ |= 0x30;
freq_clock /= 2;
break;
}

// Terminal count for Timer 4 PWM

long counter_counts;
// If required frequency under minimum or over maximum adjust to these
if (required_freq > 0)
{
counter_counts = freq_clock/(1 << timer_divider_pow)/required_freq;
if (counter_counts < 1)
counter_counts = 1;
else if (counter_counts > 255)
counter_counts = 255;
}
else
{
counter_counts = 255;
}
OCR4C = (unsigned char)counter_counts;
// By default switch the PWM generation off
OCR4A = 0;

// Set PWM to D13 (Timer4 A)

// Set Output Mode C7
DDRC |= 1 << 7;
// Activate channel A
TCCR4A = 0x82;

// Sets the value to be used on PWM13 to configure a 50% dutty cycle wave with the new
// configuration
// NOTE: For an exact 50% dutty cycle OCR4C must be odd
pwm13_dutty_half = (OCR4C-1)/2;
}

void setup()
{
// For 110kHz freq a suitable configuration may be:
// 'clock_base_divider_one_half' and 'timer_divider_pow' = 1 ->
// Base freq (with PLLFRQ=0x4) = 48M/1.5/2^1 = 16M
// Min Freq[Threshold counter=256] = 16M/256 = 62.5 kHz
// Freq[255] = 16M/255 = 62.75 kHz
// Freq[139] = 115.10 kHz
// Freq[140] = 114.29 kHz
// Freq[141] = 113.48 kHz
// Freq[128] = 125 kHz
// Freq[1] = 16 MHz
// So, we have an acceptable granulatiry around 110kHz and can achieve
// interesting lower frequencies for testing (here 62.5 kHz)
configure_pwm13(clock_base_divider_one_half, 1, 110000);
}

void send_message(unsigned char *msg, unsigned int msg_length)

{
int index_msg;
for (index_msg = 0; index_msg < msg_length; index_msg++)
{
// One start symbol
PWM13 = pwm13_dutty_half;
delay(SYMBOLS_LENGTH_MS);
// Message symbols
int bit_count;
unsigned char c = msg[index_msg];
for (bit_count = 8; bit_count > 0; bit_count--, c <<= 1)
{
PWM13 = (c & 0x80) ? pwm13_dutty_half : 0;
delay(SYMBOLS_LENGTH_MS);
}
PWM13 = 0;
delay(DELAY_BETWEEN_SYMBOLS_MS);
Design of a low-cost device for data transmission over power lines 53/181

}
}

void loop()
{
unsigned char message[] = "Hi";
send_message(message, sizeof(message)-1);
delay(DELAY_BETWEEN_MESSAGES_MS);
}

This is the result when probing the pin 13 with the oscilloscope:

‘Hi’ encoding. 5 ms/div Carrier details. 10 us/div

In the capture at left, we can clearly identify the bits of each character (have in mind that there is always one
additional start bit):
• H = 0x48 = 0b01001000

• i = 0x69 = 0b01101001

Each bit has a width of 1 ms. We can also observe a gap of 5 ms between characters, which is defined in the
sketch by DELAY_BETWEEN_SYMBOLS_MS.

In the capture at right (zoomed to 10us/div), we confirm that the frequency of the carrier is 110 kHz.
54/181 Design of a low-cost device for data transmission over power lines

3.4.2 Temperature sensing device with Arduino

To prove that Arduino is a suitable low-cost platform that allows implementing more complex devices, we
are going to cover, in this chapter, the integration of two typical electronic devices: a temperature sensor and
an LCD display. For that purpose, I have built a mini Arduino shield. You can find the schematic below.
Figure 42. Arduino shield - Schematic

To get the temperature, I have used a popular

sensor, the DS18B20. It accepts the OneWire
protocol which is already available for Arduino
through third-party libraries.

I have also added a small 2x16 LCD to

demonstrate how easy it is to integrate some
typical electronic devices into the Arduino
platform. In this project the LCD displays the
current temperature in real time (every 500 ms).

Note that, in the schematic, I have used the

Arduino Uno block (from the adafruit.lbr) in place
of the Arduino Leonardo one (which was not
present in my EAGLE libraries). This does not
pose a problem because the Leonardo has the
same connectors and layout as the Uno.

A possible simple PCB routing for this shield is proposed in the below figure.
Figure 43. Arduino shield - Routing

The potentiometer must be accessible because it allows

to manually configure the contrast of the LCD.

For the temperature sensor, note that the DS18B20 is

not directly plugged into the X2 connector (1x3) but
through a mini-adapter that I got from the 37-in-1-
sensors-kit[11].
Design of a low-cost device for data transmission over power lines 55/181

The routing is so simple that the shield can be done in a perfboard:

Figure 44. Arduino shield - Top Figure 45. Arduino shield - Bottom

This is the sketch to get the temperature and display it on the LCD every 500ms:

TestTemperatureSensorLcd.ino
/**
* PURPOSE:
* Get the temperature from a OneWire-based sensor (e.g. DS18B20) and display it in the LCD
*
* TARGET SYSTEM:
* Arduino Leonardo + Custom "Temperature & LCD shield"
*
* NOTES:
* For the LCD part I’ve been based on the public domain code at:
* https://www.arduino.cc/en/Tutorial/LiquidCrystalDisplay
*
* For the OneWire part there is plenty of information in Internet like this one:
* https://create.arduino.cc/projecthub/everth-villamil-ruiz/temperature-sensor-ds18b20-3decfc
*
* LICENSE:
* Copyright (C) 2017 Jose Maria Ortega
* Distributed under the GNU GPLv3. For full terms see the file LICENSE
*/

#include <LiquidCrystal.h>

// initialize the library with the numbers of the interface pins

LiquidCrystal lcd(12, 11, 3, 4, 5, 6);

#include <OneWire.h>
56/181 Design of a low-cost device for data transmission over power lines

#include <DallasTemperature.h>

// Data wire is plugged into pin 2 on the Arduino

#define ONE_WIRE_BUS 2

// Setup a oneWire instance to communicate with any OneWire devices

// (not just Maxim/Dallas temperature ICs)
OneWire oneWire(ONE_WIRE_BUS);

// Pass our oneWire reference to Dallas Temperature.

DallasTemperature sensors(&oneWire);

#define DELAY_BETWEEN_MEASURES_MS 500

void setup()
{
sensors.begin();
// set up the LCD's number of columns and rows:
lcd.begin(16, 2);
// Print a message to the LCD.
lcd.print("15/2/2017 +--.--");
lcd.setCursor(0,1);
lcd.print("Jose M. Ortega");
lcd.display();
}

void loop()
{
// Send the command to get temperatures
sensors.requestTemperatures();
float tempC = sensors.getTempCByIndex(0);
lcd.setCursor(11,0);
lcd.print(tempC);
delay(DELAY_BETWEEN_MEASURES_MS);
}

With the Arduino IDE I have uploaded the new firmware to the Arduino Leonardo and verified that it works
as expected:
Figure 46. Arduino shield - Test

For this test I have used a USB Power Bank as the power source. We will use this battery-powered
configuration on some tests in the section 4.8 Data communication through the 230VAC line.
Design of a low-cost device for data transmission over power lines 57/181

3.4.3 Sensing and transmitting device with Arduino

Now it is time to combine both capabilities together: sense temperature and transmit it using an OOK
modulation.

To do so, I have just added, to the sketch in the previous section (3.4.2), the fragment of the code that enables
the transmission of modulated data through the pin 13 (in 3.4.1).

This is the final sketch that periodically reports the temperature, wrapped in an OOK modulation:

Lcd_Ds18b20_ModulatedData.ino
/**
* PURPOSE:
* Get the temperature from a OneWire-based sensor (e.g. DS18B20), display it in a LCD
* and send the temperature data through the pin 13 in an OOK modulation
*
* TARGET SYSTEM:
* Arduino Leonardo + Custom "Temperature & LCD shield"
*
* NOTES:
* For the LCD part I’ve been based on the public domain code at:
* https://www.arduino.cc/en/Tutorial/LiquidCrystalDisplay
*
* For the OneWire part there is plenty of information in Internet like this one:
* https://create.arduino.cc/projecthub/everth-villamil-ruiz/temperature-sensor-ds18b20-3decfc
*
* Code tested with Arduino IDE 1.6.4
*
* LICENSE:
* Copyright (C) 2017 Jose Maria Ortega
* Distributed under the GNU GPLv3. For full terms see the file LICENSE
*/

#include <LiquidCrystal.h>
#include <OneWire.h>
#include <DallasTemperature.h>

#define ONE_WIRE_BUS 2

#define PWM_BASE 96000000

#define PWM13 OCR4A

#define DELAY_BETWEEN_MESSAGES_MS 1000

#define DELAY_BETWEEN_SYMBOLS_MS 5
#define SYMBOLS_LENGTH_MS 1

enum clock_base_divider_enum : byte {

clock_base_divider_one = 0,
clock_base_divider_one_half,
clock_base_divider_two
};

LiquidCrystal lcd(12, 11, 3, 4, 5, 6);

OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature sensors(&oneWire);
unsigned char pwm13_dutty_half;
unsigned int frame_counter = 1;

unsigned char configure_pwm13(byte clock_base_divider, unsigned char timer_divider_pow,

long required_freq)
{
TCCR4A = 0;
TCCR4B = timer_divider_pow+1;
TCCR4C = 0;
TCCR4D = 0;
PLLFRQ = 0x4;
long freq_clock = PWM_BASE/2;
switch(clock_base_divider)
{
case clock_base_divider_one:
PLLFRQ |= 0x10;
58/181 Design of a low-cost device for data transmission over power lines

break;
case clock_base_divider_one_half:
PLLFRQ |= 0x20;
freq_clock = freq_clock/3*2;
break;
case clock_base_divider_two:
PLLFRQ |= 0x30;
freq_clock /= 2;
break;
}
long counter_counts;
if (required_freq > 0)
{
counter_counts = freq_clock/(1 << timer_divider_pow)/required_freq;
if (counter_counts < 1)
counter_counts = 1;
else if (counter_counts > 255)
counter_counts = 255;
}
else
{
counter_counts = 255;
}
OCR4C = (unsigned char)counter_counts;
OCR4A = 0;
DDRC |= 1 << 7;
TCCR4A = 0x82;
pwm13_dutty_half = (OCR4C-1)/2;
}

void send_message(char *msg, unsigned int msg_length)

{
int index_msg;
for (index_msg = 0; index_msg < msg_length; index_msg++)
{
PWM13 = pwm13_dutty_half;
delay(SYMBOLS_LENGTH_MS);
int bit_count;
char c = msg[index_msg];
for (bit_count = 8; bit_count > 0; bit_count--, c <<= 1)
{
PWM13 = (c & 0x80) ? pwm13_dutty_half : 0;
delay(SYMBOLS_LENGTH_MS);
}
PWM13 = 0;
delay(DELAY_BETWEEN_SYMBOLS_MS);
}
}

void setup()
{
configure_pwm13(clock_base_divider_one_half, 1, 110000);
sensors.begin();
lcd.begin(16, 2);
lcd.print("20/2/2017 +--.--");
lcd.setCursor(0,1);
lcd.print("Jose M. Ortega");
lcd.display();
}

void loop()
{
sensors.requestTemperatures();
float tempC = sensors.getTempCByIndex(0);
lcd.setCursor(11,0);
lcd.print(tempC);
// NOTE:
// To convert a float to a char array we could use, in theory, this code:
// int chars = snprintf(frame, sizeof(frame), "T=%.2f", tempC);
// However it shows 'T=?'. That's because only the light version of printf is included, without
// float management. If we want to use it we should add these flags to the compiler line:
// '-Wl,-u,vfprintf -lprintf_flt'
// ALTERNATIVE: Use the function 'dtostrf'
// More info:
// https://totaki.com/poesiabinaria/2011/12/utilizar-float-con-sprintf-y-derivados-en-arduino/
// http://www.atmel.com/webdoc/AVRLibcReferenceManual/ch20s10s02.html
Design of a low-cost device for data transmission over power lines 59/181

// http://playground.arduino.cc/Main/FloatToString
char frame[16];
int chars = snprintf(frame, sizeof(frame), "%d:", frame_counter++);
// Convert float to string with 2-digits precision
dtostrf(tempC, 0, 2, frame+chars);
chars = strlen(frame);
frame[chars++] = '\n';
send_message(frame, chars);
delay(DELAY_BETWEEN_MESSAGES_MS);
}

Now, the OOK wrapped temperature is available through the pin 13 (the blue wire in the below figure):
Figure 47. The temperature REPORTER device

With the oscilloscope we can check the OOK encoding of the message (<counter>: <temperature>):

Temperature data in OOK encoding. 20 ms/div Carrier details. 10 us/div

We cannot connect the pin 13 directly to the mains (through the AC coupler module) because the Arduino
Leonardo can only source 40 mA in its outputs, which is not enough to deal with the typical impedance on
the AC line.

For that purpose we will use a basic Push-Pull amplifier.

60/181 Design of a low-cost device for data transmission over power lines

3.4.4 Push-Pull amplifier

3.4.4.1 Overview
The current provided by the Arduino pins are not enough to be injected into the 230VAC line in suitable
conditions. We need a power amplifier to source enough current to deal with potential low impedance
conditions in the mains.

The goal of this section is not to build a high featured amplifier, but a basic, simple and low-cost amplifier
stage with the minimum components required to carry out the communication over the 230VAC line.

For that, I have relied on a Push-Pull amplifier topology[22][23] which ideally works as a voltage follower.
The proposed circuit is a very basic stage, good enough for the tests but not reliable enough for a robust
communication. I have preferred the use of discrete components over integrated circuits (like the Power
Amplifier in the AFE031, or the LM386 in the audio scope) because individual components give more
customization possibilities to a particular scenario. Furthermore, its usage can reveal (as we will see) some
important effects and considerations involved in the transmission that might otherwise pass unnoticed.

The proposed Push-Pull amplifier belongs to the Class B category. It does not produce voltage output when
the input is idle (therefore, does not waste power in the transistors when idle). For our REPORTING device
this characteristic is essential because data packets are only sent sporadically.

In the following sections I am going to detail the modifications done from a basic Push-Pull topology to the
final version of the circuit to cover the needs of this project. I will include some analysis with a SPICE-based
tool. This analysis may be useful to improve the stage in future iterations while keeping circuit simplicity
and cost.

The main requirements are:

• It must follow the principles of a voltage follower. Some attenuation is tolerated, though.

• Some distortion is accepted whenever the signal can be properly demodulated at the receiver side.

• It should be able to source currents close to 1 A.

• It must be based on 5 V to reuse the power supply that serves other electronics (as the Arduino
board). This is required to reduce the overall size and cost of the proposal.

To analyze the different versions of the circuits proposed I have used the LTspice tool (see 6 Annex I. Tools).

For a more realistic simulation I have downloaded the models of the BJT transistors that I have used in the
tests, a NPN TIP122 and its dual PNP TIP127 (see 7 Annex II. LTspice - How to add third party models). I
have chosen those transistors just because they are able to manage high currents, because are popular and
because I had them available. In future versions we should fine-tune the choice of the transistors depending
on the exact requirements for a given scenario.

In the SPICE analysis I have measured:

• the output voltage, to confirm the voltage follower operation

• the current at the collector of the transistors, to detect possible wrong behaviors

• the power delivered by the power supply to feed the load and the internal amplifier operation
Design of a low-cost device for data transmission over power lines 61/181

3.4.4.2 Dual voltage power supply

We start first with the most simplistic approach, a basic Push-Pull circuit with a dual voltage power supply
(± 2.5 V).
Figure 48. Push-Pull amplifier - Basic circuit In this configuration we can clearly identify the Push-
vs1
Pull transistors and a polarizing network composed of a
Ra1 couple of resistors (Ra1 and Ra2) and diodes (Da1 and
Vs1 1k
2.5V Qa1 Da2).
vqa1b
tip122
Da1 .inc TIP122.LIB For the resistors I have chosen medium values (1 kΩ)
1N4148 as a compromise between input impedance and
vi vo load-effect:
Vi
Da2
1N4148 • Lower resistors are better to minimize the
variations of the voltage gain depending on the
vqa2b Qa2
tip127 output load.
.inc TIP127.LIB
Ra2 Ro
• Higher resistors result in a higher input
1k 10k
impedance (good for an amplifier) but provide
vs2
lower current to the base of the transistors,
which can lead them to not reach the limit
Vs2
-2.5V required to keep the voltage follower
.tran 110u functionality.

In conclusion, the polarizing resistors should be “proportional” to the expected load impedance: for higher
impedance values, polarizing resistors can be higher.

I have configured a SPICE analysis to measure different variables. In the following pages I am going to
enclose the graphs related to those variables for different configurations:

Alias Graph legend Color Comments

The input voltage: a sinusoid between -1 V and 1 V (2 VPP) with a

frequency of 111 kHz. I have limited it to 10 cycles and configured
Dark- a delay of 10 us to appreciate the initial and final transients.
Vi V(vi)
green
In SPICE terms: Vi vi 0 SINE(0 1 111k 10u 0 0 10)
This signal is close to the one we want to inject into the power line

Dark-
Vo V(vo) The output voltage, which should ideally follow the input
red

Iq1 The current ingoing into the Qa1 and Qa2 collectors. The target is
Ix(QaN:C) Blue to check that both transistors properly balance the delivered
Iq2 powered (each working on the corresponding half cycle)

V(vs1)*I(Vs1) + Power delivered (notice the negative sign in the graphs) by the
Ps Green
V(vs2)*I(Vs2) power supplies

Po V(vo)*I(Ro) Red Power consumed by the load

Note: In the graphs, these variables appear in inverted order (from bottom-to top).
62/181 Design of a low-cost device for data transmission over power lines

These are the results we get for our first basic circuit:
Figure 49. Push-Pull amplifier - Basic circuit - SPICE analysis
V(vo)*I(Ro)
90µW

45µW

0µW
V(vs1)*I(Vs1)+V(vs2)*I(Vs2)
-9.730mW

-9.765mW

-9.800mW
-Ix(Qa2:C)
160µA

60µA

-40µA
Ix(Qa1:C)
160µA

60µA

-40µA
V(vo)
1.0V

0.0V

-1.0V
V(vi)
1.0V

0.0V

-1.0V
0µs 10µs 20µs 30µs 40µs 50µs 60µs 70µs 80µs 90µs 100µs 110µs

From this first analysis we can conclude that, for a load of 10 kΩ:

• The output voltage Vo follows well the input voltage Vi.

• Both transistors (Qa1 and Qa2) properly balance the sunk and sourced current per half cycle.

• In the power scope, Po and Ps have a sinusoidal shape that doubles the frequency of the input signal.

For the power graphs, besides looking at the shape of the waveform and get P MAX and PMIN, it is also useful to
get the Power Average (PAVG), which is defined as the mean of the product of instantaneous voltage and
current. We can obtain it from two different ways:

• On the one hand, we can get PAVG by directly averaging the Po or Ps graphs. For a periodic and
symmetrical waveform (as the sinusoidal wave), the average is just the middle point of the wave.

• On the other hand, for a purely resistive load, we can conveniently use the root-mean-square 8 on
voltage or current to calculate it: PAVG = IRMS2·R = VRMS2/R. If we are dealing with sinusoidal
waveforms, we can quickly calculate the RMS value from the amplitude: IRMS = IP/√2, VRMS = VP/√2.

Looking at the above graphs we see that our Vo has an amplitude close to 1 V, which would mean a
VO_RMS = 1/√2 = 0.71 V. Considering the impedance of the load (10 kΩ), this would result in a
PO_AVG = 0.712/10k = 50 μW (it would be slightly lower if considering the small voltage drop in Vo).

If we look at the V(vo)*I(Ro) graph (the Po in light red), the middle value is close to 45 μW.

Looking at the power delivered by the power supply (the Ps in light green), we see that the middle value is
9.765 mW. This power includes the 45 μW consumed by the load but also the energy wasted by the
polarizing resistors and some leaking on the transistors.
8 A more extensive explanation about RMS can be found in https://en.wikipedia.org/wiki/Root_mean_square
Design of a low-cost device for data transmission over power lines 63/181

We can now check with lower impedance values at Ro to see how the amplifier behaves. I have miniaturized
the graphs to simplify the reading, focusing on the axes values and the rough shapes of the involved waves:

Ro = 5 kΩ Ro = 1 kΩ
V(vo)*I(Ro) V(vo)*I(Ro)
150µW 330µW
0µW 0µW
V(vs1)*I(Vs1)+V(vs2)*I(Vs2) V(vs1)*I(Vs1)+V(vs2)*I(Vs2)
-9.73mW -9.5mW
-9.88mW -10.8mW
-Ix(Qa2:C) -Ix(Qa2:C)
180µA 540µA
-60µA -120µA
Ix(Qa1:C) Ix(Qa1:C)
200µA 540µA
-60µA -120µA
V(vo) V(vo)
1.0V 600mV
-1.0V -600mV
V(vi) V(vi)
1.0V 1.0V

-1.0V -1.0V
0µs 20µs 40µs 60µs 80µs 100µs 0µs 20µs 40µs 60µs 80µs 100µs

Ro = 100 Ω Ro = 10 Ω
V(vo)*I(Ro) V(vo)*I(Ro)
2.2mW 16mW
0.0mW 0mW
V(vs1)*I(Vs1)+V(vs2)*I(Vs2) V(vs1)*I(Vs1)+V(vs2)*I(Vs2)
-9mW 0mW
-21mW -110mW
-Ix(Qa2:C) -Ix(Qa2:C)
5.0mA 40mA
-0.5mA -4mA
Ix(Qa1:C) Ix(Qa1:C)
5.0mA 40mA
-0.5mA -4mA
V(vo) V(vo)
540mV 400mV
-540mV -400mV
V(vi) V(vi)
1.0V 1.0V

-1.0V -1.0V
0µs 20µs 40µs 60µs 80µs 100µs 0µs 20µs 40µs 60µs 80µs 100µs

We can draw some conclusions:

• For a high impedance (>= 5 kΩ), Vo is close to Vi, as expected. However, for lower impedance
values, Vo decreases with Ro. In other words, our amplifier as an attenuation that depends on the
load. This makes the basic Push-Pull stage to work as a voltage follower only if within a reasonable
impedance range. A very interesting improvement to overcome this issue would be to add a feedback
loop with an operational amplifier, as mentioned in the bibliography[22].

• For low impedance values (<= 100 Ω), Vo suffers noticeable distortion when crossing 0 V. It is due
to a time gap where both, PNP and NPN, are OFF.

• Concerning the delivered power (Ps), we see that in idle mode (when Vi = 0 V) the amplifier always
consumes around 9.8 mW, mainly due to the current in the polarizing resistor network. Effectively,
assuming a voltage drop of 0.3 V in the diodes, we would have a power consumption there of about
(5-2·0.3)2/2k = 9.7 mW.
64/181 Design of a low-cost device for data transmission over power lines

• Concerning the relation between Ps and Po, we can see that the power supplies need to deliver much
more power than the consumed by the load. So, our amplifier is quite inefficient:

◦ For a high Ro (in the kΩ range), Po is < 1 mW. The power consumed by the polarizing network
(close to 10 mW) is much more significant.

◦ For a low Ro, as 10 Ω, we have instantaneous peaks at Ps of about 110 mW for Po peaks of
16 mW. The difference between both is dissipated by the transistors in the form of heat. In
particular, the collector current (Iq1 or Iq2) reaches peaks of 40 mA for a Vo of 400 mV. That
means a peak of instantaneous power in the transistor of 40mA * (2.5 - 400mV) = 84 mW. Thus,
the power dissipated at the transistor is due to the effort it must do to drop 2.5 V to 0.4 V.

We can repeat the same measures by doubling the input, from the previous 2 V PP to 4 VPP:

Vi = 4 VPP. Ro = 100 Ω Vi = 4 VPP. Ro = 10 Ω

V(vo)*I(Ro) V(vo)*I(Ro)
16mW 130mW
0mW 0mW
V(vs1)*I(Vs1)+V(vs2)*I(Vs2) V(vs1)*I(Vs1)+V(vs2)*I(Vs2)
-9mW 0mW
-42mW -300mW
-Ix(Qa2:C) -Ix(Qa2:C)
13mA 120mA
-1mA -10mA
Ix(Qa1:C) Ix(Qa1:C)
13mA 120mA
-1mA -10mA
V(vo) V(vo)
1.4V 1.2V
-1.4V -1.2V
V(vi) V(vi)
2.0V 2.0V

-2.0V -2.0V
0µs 20µs 40µs 60µs 80µs 100µs 0µs 20µs 40µs 60µs 80µs 100µs

In these graphs we can observe that the ratio of power supplied versus consumed by the load is much better
now because the lower voltage drop required at the transistors. For example, for Ro = 100 Ω:

• With Vi = 4 VPP the power peak ratio is 42mW/16mW = 2.6.

• With Vi = 2 VPP the power peak ratio was 21mW/2.2mW = 9.5.

Finally, and just for reference, find following a test with a very low impedance (1Ω) for Vi = 2 V PP and 4 VPP:

Vi=2 Vpp. Ro = 1 Ω Vi=4 Vpp. Ro = 1 Ω

V(vo)*I(Ro) V(vo)*I(Ro)
90mW 700mW
0mW 0mW
V(vs1)*I(Vs1)+V(vs2)*I(Vs2) V(vs1)*I(Vs1)+V(vs2)*I(Vs2)
0mW 0.0W
-770mW -2.2W
-Ix(Qa2:C) -Ix(Qa2:C)
300mA 880mA
-30mA -80mA
Ix(Qa1:C) Ix(Qa1:C)
300mA 800mA
-30mA -80mA
V(vo) V(vo)
300mV 0.8V
-300mV -1.0V
V(vi) V(vi)
1.0V 2.0V

-1.0V -2.0V
0µs 20µs 40µs 60µs 80µs 100µs 0µs 20µs 40µs 60µs 80µs 100µs
Design of a low-cost device for data transmission over power lines 65/181

3.4.4.3 Single voltage power supply

For this project, it is required that the power amplifier be based on a single voltage power supply of 5 V. To
do so, I have added some capacitors:
Figure 50. Push-Pull amplifier - Single power supply
vs

Ra1
Vs 1k Now Vi represents an AC signal having a DC
5V vqa1b Qa1 component, which will be removed by the Cd
tip122
capacitor.
Da1 .inc TIP122.LIB

Cd 1N4148 Ca In particular, for the analysis I have used a Vi

vi vcd vo
Vi vqo signal of 4 VPP centered on Vs/2 = 2.5 V:
1µ Da2 10µ
1N4148 Vi vi 0 SINE(2.5 2 111k 10u 0 0 10)

vqa2b Qa2 At the output, a Ca capacitor is added before the

tip127 Ro load to remove the DC component of the
.inc TIP127.LIB
Ra2 Ro output signal.
1k 10k

.tran 110u

Repeating the same analysis carried out in the previous section give us this:
Figure 51. Push-Pull amplifier - Single power supply - SPICE analysis
V(vo)*I(Ro)
300µW

150µW

0µW
V(vs)*I(Vs)
0mW

-10mW

-20mW
-Ix(Qa2:C)
280µA

60µA

-160µA
Ix(Qa1:C)
280µA

80µA

-120µA
V(vo)
2.0V

0.0V

-2.0V
V(vi)
6.0V

3.0V

0.0V
0µs 10µs 20µs 30µs 40µs 50µs 60µs 70µs 80µs 90µs 100µs 110µs
66/181 Design of a low-cost device for data transmission over power lines

And for different Ro:

Ro = 1 kΩ Ro = 100 Ω
V(vo)*I(Ro) V(vo)*I(Ro)
1.8mW 16mW
0.0mW 0mW
V(vs)*I(Vs) V(vs)*I(Vs)
-6mW -5mW
-20mW -65mW
-Ix(Qa2:C) -Ix(Qa2:C)
1.3mA 13mA
-0.2mA -1mA
Ix(Qa1:C) Ix(Qa1:C)
1.3mA 13mA
-0.2mA -1mA
V(vo) V(vo)
1.5V 1.4V
-1.5V -1.4V
V(vi) V(vi)
4.8V 4.8V

0.4V 0.4V
0µs 20µs 40µs 60µs 80µs 100µs 0µs 20µs 40µs 60µs 80µs 100µs

Ro = 10 Ω Ro = 1 Ω
V(vo)*I(Ro) V(vo)*I(Ro)
130mW 800mW
0mW 0mW
V(vs)*I(Vs) V(vs)*I(Vs)
0mW 0.0W
-550mW -4.4W
-Ix(Qa2:C) -Ix(Qa2:C)
120mA 900mA
-10mA -90mA
Ix(Qa1:C) Ix(Qa1:C)
110mA 880mA
-10mA -80mA
V(vo) V(vo)
1.2V 1.0V
-1.2V -1.0V
V(vi) V(vi)
4.8V 4.8V

0.4V 0.4V
0µs 20µs 40µs 60µs 80µs 100µs 0µs 20µs 40µs 60µs 80µs 100µs

We see that results are similar to the double-voltage-supply case. The main difference is in the delivered
power (Ps): peaks are higher but have half the frequency compared to the single-supply case. That is due to
the effect of capacitors in storing energy. The average value is similar.

If we focus on the case Ro = 100 Ω, we see that in both cases the Vo has the same level (close to 1.4 V PP) and
the current crossing the collector of the transistors is also the same (13mA peak). All the graphs are very
similar except for the power supplied by Vs:

• In double-voltage-supply, it was a sinusoidal shape of 222 kHz between 9 mW and 42 mW.

• In single-voltage-supply with capacitors, it is a different shape, with a periodicity of 111 kHz and
reaching peaks up to 65 mW.
Design of a low-cost device for data transmission over power lines 67/181

3.4.4.4 Voltage divider and low-pass filter

The target here is to add an interfacing stage intended for the Arduino board. The first goal is to attenuate the
signal at the Arduino output pins (square wave from 0 V to 5 V) to a suitable level to be injected into the
mains. The second goal is to reduce the harmonic content of the square waveform.

VOLTAGE DIVIDER

The simplest option to attenuate a signal is through a resistive voltage divider (I have also included a Cr
capacitor to remove the DC component in a first stage, much faster than Cd does):
Figure 52. Push-Pull amplifier - Voltage divider
vs
Ri
vi vri Ra1
Vi Vs 1k
50 Cr 5V vqa1b Qa1
0.1µ tip122
Da1 .inc TIP122.LIB
vrr1

1N4148 Ca
vcd vo
Rr1 vqo
150 Da2 10µ
1N4148
Cd
vrr2 vqa2b Qa2
1µ tip127
Rr2 Cf .inc TIP127.LIB
Ra2 Ro
330 1p 1k 10k
.tran 110u

One important drawback of the resistive divider is the load-effect: Rr1 and Rr2 must be much lower than the
input impedance of the next stage to do not be affected by it. A better approach here might be adding an
intermediate stage with a high input impedance (like a voltage follower with an operational amplifier). But
for this project, where the main objective is to evaluate the feasibility of the proposed system, some load-
effect can be tolerated.

The input impedance of our Push-Pull amplifier is low, so we need to use low values for Rr1 and Rr2. The
lowest limit for these resistors comes from the maximum current the I/O pins of the Arduino Leonardo can
source (40 mA). The decision rule here is more the protection against load-effects than power consumption.
In fact, power consumption at I/O pins is not a key factor here because, for this project, the output is enabled
only at sporadic transmissions of short data Figure 53. ATmega32U4 - I/O Pin Output Voltage vs.
packets. Source Current (Vcc = 5V)

In the SPICE circuit I have added Ri to have in

consideration the output impedance of theI/O
pins.

For the Arduino case we can find the value of Ri

by taking a look at the Electrical Characteristics
of the Atmega CPU. Find at right the Figure 30-
20 of the Atmega datasheet[10] at page 402, giving
the relation between Output Voltage and Source
Current.
68/181 Design of a low-cost device for data transmission over power lines

If we assume a Ro connected to the output pin of the Arduino, the output voltage would be:

Ro Vcc⋅Ro Vcc Vo
Vo=Vcc → Ri+ Ro= → Ri=Ro( −1)→Ro=Ri
Ri+ Ro Vo Vo Vcc−Vo
On the other hand, we can express Ro as a function of Io:

Vcc Vcc Vcc

Io= → Ri+ Ro= → Ro= −Ri
Ri+ Ro Io Io
Putting both equations together gives this:

Vo Vcc Vo Vcc Vcc Vcc Vcc−Vo

Ri = −Ri →Ri ( +1)= →Ri = → Ri=
Vcc−Vo Io Vcc−Vo Io Vcc−Vo Io Io
We can now get some points from the previous graph and estimate the Ri with that formula. For example at
25ºC the output voltage is:

• 4.9V at 2mA → Ri = (5-4.9)/2mA = 50 Ω

• 4.2V at 20mA → Ri = (5-4.2)/20mA = 40 Ω

We can see that the output impedance of the I/O pin (Ri here) depends on the current delivered (besides the
temperature). For our analysis I am going to use the typical 50 Ω value.

In the physical implementation of this circuit I will place a potentiometer in Rr2. Rr1 will limit the maximum
output current. With a Rr1 = 150 Ω and assuming the worst case in the potentiometer (Rr2 = 0), we have a
IMAX = 5V/(150+50) = 25mA, which is below the maximum current the Arduino I/O pin can deliver (40 mA).

For Vi we use now a 5 V square waveform (the Arduino output): Vi vi 0 PULSE(0 5 10u 0 0 4.5u 9u 10).

A simulation of the current circuit results in these graphs:

Figure 54. Push-Pull amplifier - Voltage divider - SPICE analysis
V(vrr2)
2.8V

0.6V

-1.6V
V(vo)*I(Ro)
440µW

220µW

0µW
V(vs)*I(Vs)
2mW

-9mW

-20mW
-Ix(Qa2:C)
800µA

50µA

-700µA
Ix(Qa1:C)
1.4mA

0.3mA

-0.8mA
V(vo)
2.4V

0.4V

-1.6V
V(vi)
5.4V

2.4V

-0.6V
0µs 10µs 20µs 30µs 40µs 50µs 60µs 70µs 80µs 90µs 100µs 110µs
Design of a low-cost device for data transmission over power lines 69/181

At the top, I have added the graph corresponding to the voltage after the resistive divider, in order to check
that the output (vo) continues to follow the input (vrr2).

Looking at V(vrr2) we can see that with a Rr2 = 330 Ω, we turn the 0 to 5 V from the Arduino I/O pin into
approximately -1.4 V to 1.4 V (after a transient). In these conditions the output (Vo) goes from -1 V to 1 V,
which fits with our target of injecting a 2 VPP signal to the AC line.

LOW-PASS FILTER

To end this chapter, I am going to discuss the inclusion of the Cf capacitor into the circuit.

The Arduino board generates square waves. In order to reduce the harmonic content and avoid injecting other
frequencies to the power line (which could interfere other existing systems), a low-pass filter is
recommended. The most basic form of a low-pass filter is the Cf capacitor.

Through experimentation I have found that a proper and easily available capacitance to filter signals greater
than 100kHz could be Cf = 6.8 nF. To confirm it, I have done a simulation of Vi vs. Vo with more cycles and
calculated the FFT:

Cf = 1 pF Cf = 6.8 nF
V(vo)*I(Ro) V(vo)*I(Ro)
440µW 330µW

220µW 165µW

0µW 0µW
V(vs)*I(Vs) V(vs)*I(Vs)
2mW
-2mW
-6mW
-9mW -10mW
-14mW
-20mW -18mW
V(vo) V(vo)
2.4V 1.8V
1.6V
0.8V
0.2V
0.0V
-0.8V
-1.6V -1.5V
V(vi) V(vi)
5.4V 5.0V
4.2V 4.0V
3.0V 3.0V
1.8V 2.0V
0.6V 1.0V
-0.6V 0.0V
0µs 20µs 40µs 60µs 80µs 100µs 120µs 140µs 160µs 180µs 200µs 0µs 20µs 40µs 60µs 80µs 100µs 120µs 140µs 160µs 180µs 200µs

Cf = 1 pF. FFT of V(vo) Cf = 6.8 nF. FFT of V(vo)

V(vo) V(vo)
800mV 700mV

720mV 630mV

640mV 560mV

560mV 490mV

480mV 420mV

400mV 350mV

320mV 280mV

240mV 210mV

160mV 140mV

80mV 70mV

0mV 0mV
0KHz 50KHz 100KHz 150KHz 200KHz 250KHz 300KHz 350KHz 400KHz 450KHz 500KHz 0KHz 50KHz 100KHz 150KHz 200KHz 250KHz 300KHz 350KHz 400KHz 450KHz 500KHz

The top of the scale of the FFT graph at left is 800 mV, while it is 700 mV at right. So, a first side effect of
the capacitor is that it slightly attenuates the main signal. I have scaled the graphs this way to be able to
visually compare the ratio of the harmonics, at 222 kHz, 333 kHz, 444 kHz, etc. We can see that the ratio
between the peaks of the harmonics and the main signal is lesser with the Cf = 6.8 pF. We can also appreciate
the softening effect of the filter in the Vo graph at the top-right figure.

For a narrower and more selective filtering, we should consider designing it with a greater order (with extra
capacitors and inductors).
70/181 Design of a low-cost device for data transmission over power lines

3.4.4.5 LED monitoring

As a final feature, I have added a LED to indicate activity.
Figure 55. Push-Pull amplifier - LED monitoring
vs
Ri
vi vri Ra1 Rm1
Vi Vs 1k
50 Cr 390
5V vqa1b Qa1
tip122
0.1µ

vdm
.inc TIP122.LIB
Da1
vrr1

1N4148 Ca Dm1
vcd vo QTLP690C
Rr1 vqo

vqmc
150 Da2 10µ
1N4148
Cd Rm2
vqmb Qm1
vrr2 vqa2b Qa2 BC547C
1µ tip127 10k
Cf .inc TIP127.LIB
Rr2 Ra2 Ro
330 6.8nF 1k 10k
.tran 210u

The LED is mainly intended for debugging and testing purposes:

• It notifies that a transmission is in progress.

• It indicates that the Vo voltage is high enough, which also means that the load impedance is not too
low. More in detail, we have already seen that our Push-Pull amplifier is highly dependent on the
load: for low impedance values, Vo decreases significantly. If Vo is below the threshold to turn on
the base-emitter junction of the Qm1, the LED will not flash. This way, the LED can be used as a
way to roughly check the load impedance.

3.4.4.6 Common scenarios

In this section we are going to check the whole circuit for different positions of the voltage divider
potentiometer (Rr2), and with two Ro values for a couple of typical consumption scenarios at home
(refrigerator, TV, microwave, etc.):

• Ro = 200 Ω → In 230VAC (RMS) this would mean a PAVG = 2302/200 = 265 W

• Ro = 50 Ω → In 230VAC (RMS) this would mean a PAVG = 2302/50 = 1058 W

The consumption of a refrigerator or a TV is usually below 100 W. The consumption of a microwave could
be around the 1000 W.

Note however that, as we will see in the chapter 4.8 Data communication through the 230VAC line, in the
real tests, sometimes we have a much lower instantaneous impedance (at least, for the 110 kHz frequency),
resulting in significant voltage drops at the Push-Pull amplifier output.
Design of a low-cost device for data transmission over power lines 71/181

Rr2 = 50 Ω. Ro = 200 Ω Rr2 = 50 Ω. Ro = 50 Ω

V(vo)*I(Ro) V(vo)*I(Ro)
770µW 2.2mW
385µW 1.1mW
0µW 0.0mW
V(vs)*I(Vs) V(vs)*I(Vs)
-7.8mW -6mW
-11.1mW -23mW
-14.4mW -39mW
V(vo) V(vo)
400mV 360mV
100mV 140mV
-200mV -80mV
V(vrr2) V(vrr2)
900mV 900mV
150mV 150mV
-600mV -600mV
V(vi) V(vi)
5.0V 5.0V
2.5V 2.5V
0.0V 0.0V
0µs 40µs 80µs 120µs 160µs 200µs 0µs 40µs 80µs 120µs 160µs 200µs

Rr2 = 150 Ω. Ro = 200 Ω Rr2 = 150 Ω. Ro = 50 Ω

V(vo)*I(Ro) V(vo)*I(Ro)
6.0mW 22mW
3.0mW 11mW
0.0mW 0mW
V(vs)*I(Vs) V(vs)*I(Vs)
-6mW 0mW
-39mW -75mW
-72mW -150mW
V(vo) V(vo)
1.2V 1.1V
0.3V 0.3V
-0.6V -0.5V
V(vrr2) V(vrr2)
1.8V 1.8V
0.3V 0.3V
-1.2V -1.2V
V(vi) V(vi)
5.0V 5.0V
2.5V 2.3V
0.0V -0.5V
0µs 40µs 80µs 120µs 160µs 200µs 0µs 40µs 80µs 120µs 160µs 200µs

Rr2 = 1 kΩ. Ro = 200 Ω Rr2 = 1 kΩ. Ro = 50 Ω

V(vo)*I(Ro) V(vo)*I(Ro)
8.8mW 30mW
4.4mW 15mW
0.0mW 0mW
V(vs)*I(Vs) V(vs)*I(Vs)
-7mW 0mW
-42mW -90mW
-77mW -180mW
V(vo) V(vo)
1.4V 1.4V
0.1V 0.1V
-1.2V -1.2V
V(vrr2) V(vrr2)
3.2V 3.2V
0.8V 0.8V
-1.6V -1.6V
V(vi) V(vi)
5.0V 5.0V
2.5V 2.5V
0.0V 0.0V
0µs 40µs 80µs 120µs 160µs 200µs 0µs 40µs 80µs 120µs 160µs 200µs

In the above graphs we can see that the Rr2 potentiometer is a valid way to adjusts the Vo output. Note
however, that it has a modest effect for values higher than 150 Ω and a rapid effect below that (e.g. at 50 Ω
there is no significant output).
72/181 Design of a low-cost device for data transmission over power lines

Just for reference, find following a last simulation for Rr2 = 1 kΩ at a very low impedance, Ro = 10 Ω:
Figure 56. Push-Pull amplifier - Final proposal - SPICE analysis
V(vo)*I(Ro)
130mW
65mW
0mW
V(vs)*I(Vs)
0mW
-300mW
-600mW
V(vo)
1.2V
0.0V
-1.2V
V(vrr2)
3.2V
0.8V
-1.6V
V(vi)
5.0V
2.3V
-0.5V
0µs 40µs 80µs 120µs 160µs 200µs

An interesting conclusion of these tests is that we do not need to dedicate efforts to thermal dissipation (extra
heat sinks are not required). If, for example, we look at the scenario Rr2 = 1 kΩ and Ro = 50 Ω (i.e., low
impedance in the AC line), we see that the power delivered by the power supply and mostly consumed by the
load and the transistors, is easily manageable (< 100 mW).

3.4.4.7 Implementation on a breadboard

For evaluation purposes, it is always interesting to have connectable modules so that we can test different
scenarios with them.

For the Push-Pull amplifier I have used a breadboard. This way, we can also easily change components and
experiment with.
Figure 57. Push-Pull amplifier - Implementation on a breadboard
For Rr2 I have used 1 kΩ potentiometer to be
able to easily adjust the level of the output
voltage (vo).

At the right picture we have four wires:

• red and black, for the power-supply (vs)

• blue, for the input (vri)

• green, for the output (vo)

Note: in the photo, in vo, there are two resistors in

parallel that I have been using to test different
load conditions.
Design of a low-cost device for data transmission over power lines 73/181

3.5 PlcCape SOFTWARE framework

3.5.1 Overview
The software that runs in the SUPERVISOR unit (Linux-based) is the continuation of the software
framework developed during the first stage of the project [1]. It has been improved with new features to help
in the analysis phase.

The new software has been identified with the version 0.2. Both versions are available in GitHub:

plc-cape v0.1 [Sep-2016] https://github.com/jose77105/plc-cape/releases/tag/v0.1

plc-cape v0.2 [Mai-2017] https://github.com/jose77105/plc-cape/releases/tag/v0.2

Differences v0.2 vs. v0.1 https://github.com/jose77105/plc-cape/compare/v0.1...v0.2

3.5.2 Changes
Find following a summary of the changes introduced on v0.2:

NEW APPLICATIONS

plc-cape-oscilloscope Application in C++ that displays, in real time, the ADC captured data.

plc-cape-freq-response Application that obtains the frequency response of a TX-to-RX loop.

NEW PLUGINS

encoder-wav Reads a WAV file and populates the output buffer with proper samples.

encoder-morse Implements the Morse encoding/decoding scheme.

decoder-morse

NEW FEATURES

The whole framework can now be executed on a desktop-PC by

emulating the DAC and the ADC with the speaker and the microphone.
Emulator The emulator can help in the development phase because in the desktop-
PC we can benefit from a faster CPU and more powerful tools (as the
Eclipse IDE).

In the new version of the main plc-cape-lab applications the different

running configurations (profiles) are defined in an easily editable XML
XML profiles
file instead of hard-coding them in the source code (which was the
approach in v0.1).

The plugin engine has been improved for better modularization. Now
plugins can declare the custom settings they accept so that the plc-cape-
Plugin-based settings
lab application is able to dynamically display them on the configuration
menus.
74/181 Design of a low-cost device for data transmission over power lines

IMPROVEMENTS & BUG FIXING

Some internal operations have been optimized and refactored.

plc-cape-lab
The main menu has been improved.

Some encoder and decoder plugins have been reviewed for a more robust
Plugins
execution.

The customized ADC driver of v0.1 had a serious inconvenience: it reported a

kernel warning at every occurrence of a FIFO overrun or underflow. Since the
reporting of each kernel warning takes significant time, a FIFO warning led to a
cascade of FIFO warnings that often hung the whole Linux system. To fix this, a
ADC driver
contention mechanism has been implemented on v0.2. Now, FIFO warnings are
reported at a maximum rate of 1 Hz (1 warning per second). This single
modification results in a much more stable ADC driver: overrun or underflow
errors are still raised but the application is able to recover from.

Substantial code refactoring has been carried out for better usability and simpler
Refactoring
maintenance.
Table 13. Changes in the software framework

Note that the introduction of a C++ project into the framework (the plc-cape-oscilloscope) has required some
changes in the public headers for the proper coexistence of both type of projects (plain-C and C++):

#ifndef MY_PUBLIC_HEADER_H
#define MY_PUBLIC_HEADER_H
#ifdef __cplusplus
extern "C" {
#endif
// ... HEADER DECLARATIONS ...
#ifdef __cplusplus
}
#endif
#endif /* MY_PUBLIC_HEADER_H */

3.5.3 Future improvements

There are some topics that should be covered as soon as possible in the next software version:

Switch from It seems (to be confirmed) that the ARM processor of the BBB has native
float types to support to double types. Using float just adds some extra instructions which are
double required to adapt them to double before reaching the Floating Point Unit.

In the current custom driver, the ADC is always configured with a capturing rate
of 200 ksps. Due to the Nyquist theorem and the undersampling effect (aliasing),
ADC
a signal at 105 kHz and another one at 95 kHz are indistinguishable from the
configurable
ADC perspective. In order to properly process the CENELEC-B band (from 95
sampling rate
kHz to 125 kHz) we should be able to configure the ADC sampling rate. For
example, at 180 ksps the “symmetry axis” will move from 100 kHz to 90 kHz.

Current ADC driver is based on interrupts and ISRs to move back and forth the
ADC FIFO by
ADC data from FIFO to RAM. A DMA approach will be more stable and will
DMA
reduce CPU load.
Table 14. Future improvements in the software framework
Design of a low-cost device for data transmission over power lines 75/181

3.5.4 Third-party libraries

The new code implemented in v0.2 has new dependencies to some third-party libraries that did not come
installed in the off-the-shelf Debian image of my BBB (which corresponded to Debian Wheezy 7.8 with a
customized BBB kernel 3.8.13-bone70). In particular we require the development versions of: FFTW3 for
Fourier Transforms, GTK for a GUI, and Libxml2 for XML-format parsing.

3.5.4.1 FFTW3
The plc-cape-oscilloscope and plc-cape-freq-response applications use the GNU Fast Fourier Transform
package fftw3[24] to get the representation of the captured signal in the frequency domain.

The binary of the library (libfftw3) comes installed in the off-the-shelf Debian image but this is not the case
for the corresponding developer package (libfftw3-dev). So we need to do it explicitly:

# dpkg-query -W -f='${binary:Package;-20} ${Version}\t${binary:Summary}\n' | grep fftw

libfftw3-3:armhf 3.3.2-3.1 Library for computing Fast Fourier Transforms

# apt-get install fftw3-dev

Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'libfftw3-dev' instead of 'fftw3-dev'
The following extra packages will be installed:
libfftw3-bin
The following NEW packages will be installed:
libfftw3-bin libfftw3-dev
0 upgraded, 2 newly installed, 0 to remove and 170 not upgraded.
Need to get 1409 kB of archives.
After this operation, 4607 kB of additional disk space will be used.
Do you want to continue [Y/n]? Y
Get:1 http://ftp.us.debian.org/debian/ wheezy/main libfftw3-bin armhf 3.3.2-3.1 [198 kB]
...
Setting up libfftw3-bin (3.3.2-3.1) ...
Setting up libfftw3-dev:armhf (3.3.2-3.1) ...

# dpkg-query -W -f='${binary:Package;-20} ${Version}\t${binary:Summary}\n' | grep fftw

libfftw3-3:armhf 3.3.2-3.1 Library for computing Fast Fourier Transforms
libfftw3-bin 3.3.2-3.1 Library for computing Fast Fourier Transforms - Tools
libfftw3-dev:armhf 3.3.2-3.1 Library for computing Fast Fourier Transforms - development

3.5.4.2 GTK+/Cairo
The plc-cape-oscilloscope tool represents the ADC captured data in real time through a GUI (Graphical User
Interface). There are different frameworks available for that purpose, as GTK or Qt. I have chosen the GTK
due to its popularity and because it is lighter and faster than Qt.

Official documentation is available online [25], [26].

As in the FFTW3 case, the developer versions of the libraries (libgtk-3-dev) are not included by default:

# dpkg-query -W -f='${binary:Package;-20} ${Version}\t${binary:Summary}\n' | grep libgtk

libgtk-3-0:armhf 3.4.2-7 GTK+ graphical user interface library
libgtk-3-bin 3.4.2-7 programs for the GTK+ graphical user interface library
libgtk-3-common 3.4.2-7 common files for the GTK+ graphical user interface library
libgtk2.0-0:armhf 2.24.10-2 GTK+ graphical user interface library
libgtk2.0-bin 2.24.10-2 programs for the GTK+ graphical user interface library
libgtk2.0-common 2.24.10-2 common files for the GTK+ graphical user interface library
libgtk2.0-dev 2.24.10-2 development files for the GTK+ library

Use apt-get to install them:

# apt-get install libgtk-3-dev

Reading package lists... Done
76/181 Design of a low-cost device for data transmission over power lines

Building dependency tree

Reading state information... Done
The following extra packages will be installed:
gir1.2-gtk-3.0 libgtk-3-0 libgtk-3-bin libgtk-3-common
Suggested packages:
libgtk-3-doc
The following NEW packages will be installed:
gir1.2-gtk-3.0 libgtk-3-dev
The following packages will be upgraded:
libgtk-3-0 libgtk-3-bin libgtk-3-common
3 upgraded, 2 newly installed, 0 to remove and 170 not upgraded.
Need to get 5189 kB of archives.
After this operation, 7700 kB of additional disk space will be used.
Do you want to continue [Y/n]? Y
Get:1 http://ftp.us.debian.org/debian/ wheezy/main libgtk-3-bin armhf 3.4.2-7+deb7u1 [55.2 kB]
[...]
Setting up libgtk-3-dev (3.4.2-7+deb7u1) ...

We can check the proper installation of libgtk-3-dev with dpkg-query:

# dpkg-query -W -f='${binary:Package;-20} ${Version}\t${binary:Summary}\n' | grep libgtk

libgtk-3-0:armhf 3.4.2-7+deb7u1 GTK+ graphical user interface library
libgtk-3-bin 3.4.2-7+deb7u1 programs for the GTK+ graphical user interface library
libgtk-3-common 3.4.2-7+deb7u1 common files for the GTK+ graphical user interface library
libgtk-3-dev 3.4.2-7+deb7u1 development files for the GTK+ library
libgtk2.0-0:armhf 2.24.10-2 GTK+ graphical user interface library
libgtk2.0-bin 2.24.10-2 programs for the GTK+ graphical user interface library
libgtk2.0-common 2.24.10-2 common files for the GTK+ graphical user interface library
libgtk2.0-dev 2.24.10-2 development files for the GTK+ library

Just a note about portability across different platforms: the GTK version in the BBB is typically lower than
in a desktop-PC. For example, I have GTK 3.4 in my BBB and 3.10 in my Ubuntu. As a result, sometimes
we can face some different behaviors depending on the target platform. In such cases (if no alternative is
found) I have added conditional compilation clauses based on the __arm__ or the GDK_VERSION_3_10
definitions:

GtkWidget *Application::create_toolbar_box(void)
{
// In my BBB I need to create the toolbar with GTK_ORIENTATION_VERTICAL to be properly shown
// TODO: Analyze why this patch is required
#ifdef __arm__
GtkWidget *box = gtk_box_new(GTK_ORIENTATION_VERTICAL, 0);
#else
GtkWidget *box = gtk_box_new(GTK_ORIENTATION_HORIZONTAL, 0);
#endif
...

3.5.4.3 Libxml2
In the 0.2 version of the framework, the plc-cape-lab application loads the profiles from an XML file. The
plc-cape-oscilloscope tool also loads the initial settings from an XML file. For that purpose I have relied on
the libxml2 library[27]. To install it, use apt-get install libxml2-dev, like in previous sections.

This library is distributed under a MIT License9. Note that this type of license is more permissive than the
GPL, and therefore MIT-based libraries can be used in GPL projects without conflict 10:
Many of the most common free software licenses, especially the permissive licenses, such as the original MIT/X
license, BSD licenses (in the three-clause and two-clause forms, though not the original four-clause form), MPL 2.0,
and LGPL, are GPL-compatible. That is, their code can be combined with a program under the GPL without conflict
and the new combination would have the GPL applied to the whole (not the other license).

9 License terms in http://www.opensource.org/licenses/mit-license.html

10 Fragment extracted from https://en.wikipedia.org/wiki/License_compatibility#GPL_compatibility
Design of a low-cost device for data transmission over power lines 77/181

3.5.5 Eclipse environment

In plc-cape v0.1 the binaries were built through direct on-board compilation, just executing make on the
BBB[1]. This is a practical way that simplifies the compilation on different platforms.

In plc-cape v0.2 this procedure continues to be the way to generate the native binaries for the embedded
platform. However, the new version offers a new interesting feature, the Emulator, which allows the
execution of the whole framework in a desktop-PC (usually based on x86 or amd64 architectures). To build
the native binaries for the desktop-PC, we have two ways:

• We can use make from a terminal, as done for the BBB.

• We can rely on a new Eclipse-based environment which seamlessly coexists with the direct-
compilation environment.

The benefits of the Eclipse environment are huge:

• The Eclipse IDE offers a comfortable and more efficient method to build the executables from a
powerful desktop-PC. In fact, with the proper configuration, it can also be used to build executables
for the BBB (cross-compilation).

• In the debugging phase, a GUI is much more comfortable than direct interaction with GDB.

• Eclipse provides very interesting features for faster development compared to simple editors. For
example: auto-completion, on-the-fly preprocessing for early error detection, code-style auto-
formatting, refactoring functionality, automatic dependency generation, etc.

This is a typical screenshot of the Eclipse IDE:

Figure 58. Eclipse IDE - Screenshot
78/181 Design of a low-cost device for data transmission over power lines

For the sake of simple maintenance, these guidelines have been followed:

• In order to keep the main plc-cape tree structure as clean as possible, the Eclipse IDE files have
been placed in a separate tree. This preserves the independence of the plc-cape tree over third-
party tools (like the Eclipse IDE itself). Moreover, in this configuration, the intermediate files
created during the building process are also placed in the separate tree.

• Eclipse allows for different building strategies: manual make, auto-make, etc. For simple
maintenance and best efficiency, the auto-make option has been chosen. This means that we have
two variations for each project: the Eclipse-based and the make-based. This involves some
synchronization effort. For example, when adding a new library reference to a project, it must be
done at both, the Eclipse project and the direct makefile.

The main benefit of Eclipse-based makefiles versus manually-managed is that Eclipse tracks with
exactitude all the dependencies such that only the strictly affected files are used in the rebuilding
process. On the contrary, in manually-managed-makefiles I have specified rough dependencies to
folders instead of files for a simpler maintenance, resulting, sometimes, in unnecessary rebuilds (this
is not a true problem but just an inefficiency, so we can live with. The maintenance simplicity of this
method is worth the extra compilation time).

• To minimize the synchronization effort, the Eclipse projects have been created using the linked
folders feature. With it, the Eclipse projects are automatically synchronized when new files are
added or modified, even when these actions are carried out outside the IDE.

• In some occasions I have also used a file shared between both types of projects. For example, I have
added a file makefile.targets when some resource files (like *.ui, *.cfg, etc.) need to be copied to the
output folder. In both cases (Eclipse compilation vs direct make), the building process automatically
executes the corresponding actions declared there.

• For simpler maintenance, the binaries that result from the compilation process are placed in separate
folders depending on the target (BBB vs desktop-PC).

• For resource location, relative paths based on global environment variables have been used instead
of absolute paths. This simplifies future project reorganizations.

To put in place the out-of-tree compilation strategy[1] in Eclipse, I have first configured my Ubuntu operating
system:

1. I have defined DEV_SRC_DIR and DEV_BIN_DIR as global OS environment variables (with the
export command). They point to the folders where the source code and the binaries reside.

To make these variables permanently available I have added the export commands to the user’s
profile in ~/.profile:

$ cat ~/.profile
# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.
[...]
# Global support to DEV environment variables
export DEV_SRC_DIR=/media/x
export DEV_BIN_DIR=/media/y
Design of a low-cost device for data transmission over power lines 79/181

2. I have then restarted the user’s session (to make the changes effective) and checked that my new DEV
variables are in the global environment:

$ env | grep DEV

DEV_SRC_DIR=/media/x
DEV_BIN_DIR=/media/y

Now, we can create an out-of-tree project from Eclipse following these steps:
Figure 59. Eclipse IDE - Linked Folders

1. Select the option Create an empty C project. The

location of it will determine the location of the
Eclipse settings files for the project (.cproject,
.project, makefile.targets) and the location of the
Debug and Release folders with the final binaries
and intermediate files.

2. The key-point for the out-of-tree strategy comes

here. Select the new created project and do New
Folder… (see the figure at right). Use a generic
name (like src) and in the Advanced panel select
Link to alternate location (Linked Folder). For the
path, specify the location of the project using
DEV_SRC_DIR (for instance,
DEV_SRC_DIR/applications/plc-cape-lab).

As already commented, the main advantage of using Linked Folders is that when we update the source
folder with new files (from Eclipse or from elsewhere), Eclipse automatically synchronizes the folder.
This allows working in both, the desktop-based PC environment or the embedded environment, in a very
comfortable way.
80/181 Design of a low-cost device for data transmission over power lines

3.5.6 Emulator
The version 0.1 of the plc-cape framework is tied to the BeagleBone Black. We could compile the source
code in a desktop-PC (with a simple make) and get functional binaries (except for the customized drivers on
SPI and ADC). However, the compiled applications will complain at starting because they expect the
customized drivers to be running (and the associated peripherals to be present).

The version 0.2 introduces an emulation mode that allows the applications to be executed in a desktop-PC. It
is based on the ALSA engine[28] (apt-get install libasound2-dev) and is implemented this way:

• To simulate the DAC operation at TX, the ALSA playing engine is used. As a result, the emulator
produces audible sounds (if the signals are generated in the audible band, 20 Hz to 20 kHz).

• To simulate the ADC operation at RX, the ALSA recording engine is used. A microphone can be
used to capture samples and test some real effects which are also present in the communication
through the power line, like distortions, attenuation, noise…

• To simulate the TX-RX loop in the AFE031 Calibration modes (see 9 Annex IV. AFE031
Calibration modes), an internal pipe is used. This involves memory operations only:

◦ at TX the samples are sent to the pipe

◦ at RX the samples are recovered from the pipe

The emulation is implemented in a library used by any plc-cape-based application. This way, all the
developed applications can be executed in the desktop-PC with some degree of useful simulation. For
example:

• plc-cape-lab can be used to generate tones, reproduce WAVs, generate and interpret Morse code, etc.

• plc-cape-oscilloscope can be used to analyze in real-time the data captured by a microphone

• plc-cape-freq-response can be used to check the frequency response of a speaker + microphone

arrangement

To simplify the execution of the emulator, an auto-detection mechanism has been implemented which checks
for the presence of a true BBB: if it is not found, the emulation mode is automatically entered.

Note that in x86 Emulation we are compiling the source code against different versions of the third-party
libraries. We are also using a different version of the gcc compiler. Therefore, the final x86-based application
may exhibit slight differences with the ARM-based one. As an example, the plc-cape-oscilloscope tool has a
different GUI look depending on the target (see 3.5.7.1 plc-cape-oscilloscope for some screenshots).

Using the emulator has interesting benefits over the direct development in the BBB:

• Due to the powerful processors in desktop-PCs, source code is compiled faster.

• In emulation, the debugging phase is more comfortable and responsive because the binaries are
executed locally instead of requiring a remote connection with the target platform.

• By having different testing targets (BBB versus Emulation), we can discover more bugs.

• The emulator avoids the need to have a physical board. This can be very helpful in early
development stages, when the hardware may be yet unavailable.

• The emulator can be used for demo or training purposes.

Design of a low-cost device for data transmission over power lines 81/181

3.5.7 Applications
A couple of new executables (plc-cape-oscilloscope and plc-cape-freq-response) have been added to help in
the full characterization of the system.

3.5.7.1 plc-cape-oscilloscope

Target plc-cape-oscilloscope
Purpose Build a tool that works as a cheap oscilloscope on the BBB to easily and quickly
check the data captured by the ADC
Details It simplifies the task of analyzing the received data without requiring an external
oscilloscope. Moreover, this tools exposes what the ADC of the BBB really gets,
which can be different from the corresponding analog signal.
For example: when measuring a 110 kHz sinusoid with external equipment, we
measure a real frequency of 110 kHz but when measuring it with the 'plc-cape-
oscilloscope' tool we get a signal of 90 kHz, which is the aliased version due to the
max sampling rate of the ADC (= 200 ksps).
Source code ./applications/plc-cape-oscilloscope

This is a typical screenshot of the application running in emulation mode (in Ubuntu 14.04.5):
Figure 60. plc-cape-oscilloscope - Screenshot

These are the main features and benefits of the tool:

• It has been developed in C++.

• It is based on the GTK+ engine for a rich GUI (Graphical User Interface).

• Compared to the measurements with a real oscilloscope, this application shows the digital samples
after the ADC capturing process, which is very convenient to analyze some effects like the
undersampling (aliasing) or the quantification.
82/181 Design of a low-cost device for data transmission over power lines

• It offers shortcuts to quickly configure the AFE031 PGAs (Programmable Gain Amplifiers) in the
reception chain (RX_PGA1 and RX_PGA2). This is useful to condition the received signal to
suitable levels for the ADC capturing process. A shortcut is also provided to allow switching
between CENELEC-A and CENELEC-B/C/D in the RX filter.

• The application allows to fully customize the captured graphs to simplify post-analysis. Additionally,
the graphs can be stored in PNG (pixel-based) or SVG (vectorial-based) depending on the needs.

• The samples captured can be exported to a format compatible with other third-party tools, as Octave.

• It is more comfortable than using an external oscilloscope because neither probes nor additional
connections are required.

• It allows defining different configuration profiles through an editable XML file which helps to
quickly setup the measurement environment for a given scenario.

This is a typical SVG capture of a 2 kHz ramp generated by the plc-cape-lab tool in calibration mode:
Figure 61. plc-cape-oscilloscope - Example of a SVG capture

By having a look at the above graph, we can see that in the top-right corner we have a series of indications.
For example we can get the whole area dimensions from the Viewer field:

Viewer: [2 ms; 1500±500]

The first unit indicates the total width of the area that is currently displayed in the graph (in this case 2
milliseconds).

The second unit indicates the Y-axis dimensions in the form of the central value followed by half the total
range. In the above example, the middle of the whole displayed area will correspond to 1500, the bottom
will be 1500-500 = 1000, and the top will be 1500+500 = 2000.

The Y-axis values correspond to the ADC captured data (like in the Octave graphs from the plc-cape-lab
tool). The main advantage of plc-cape-oscilloscope over plc-cape-lab is the real-time visualization, a very
interesting feature for a faster and more comfortable analysis at the receiver side.

In contrast to the Octave graphs, the FFT generated by this tool only plots half the digital frequency range,
from 0 to 0.5, avoiding redundant information. In our above example we can see a 10 divisions grid. With a
200 ksps sampling rate, each division corresponds to 100 kHz/10 = 10 kHz.
Design of a low-cost device for data transmission over power lines 83/181

Find following some more examples of graphs generated by the tool:

Export to SVG Export to PNG

Note: To appreciate the difference between “Export to SVG” and “Export to PNG”, zoom in these graphs.

FFT superposition Zoom to two cycles. Representation with lines

Representation with bars Representation with crosses

The plc-cape-oscilloscope is a graphical tool. The real-time captured data will be displayed in a graphical
display if we have one attached to the BBB. The BBB has an integrated HDMI connector which is ready for
use in the off-the-shelf Debian image. We can also use an VGA display but in such a case we need an HDMI-
to-VGA converter (in fact, I have used this configuration in some test).

However, there is a more practical way to see the real-time data in the screen: through a remote SSH
connection. On a Linux-based distribution, a remote graphical connection can be set by means of ssh -X:

# ssh -X [email protected]
Debian GNU/Linux 7
BeagleBoard.org Debian Image 2015-03-01
[...]
# source init_env_samba_usb.sh
# cd $DEV_SRC_DIR/applications/plc-cape-oscilloscope
# ./run.sh 2 2
84/181 Design of a low-cost device for data transmission over power lines

I have successfully tested it in my desktop-PC with Ubuntu 14.04.5 (Linux Kernel 3.13.0) and in my mini-
laptop with Ubuntu 10.10 (Linux Kernel 2.6.35).

The output of plc-cape-oscilloscope is routed from the BBB to the desktop-PC where it is displayed. The
code runs on the BBB but the results are displayed on the PC. This is a very interesting option because we
can remotely manage our oscilloscope in a very comfortable way. The responsiveness of this solution is good
because the CPU load is divided between the BBB and the desktop-PC:

• the BBB is in charge of the ADC capturing data and issuing the graphical commands

• the Desktop-PC is in charge of the final graphical rendering, a heavy task that is assisted by the
powerful graphic card included in any modern PC

This is a screenshot of the application rendered in Ubuntu:

Figure 62. plc-cape-oscilloscope - Screenshot of a remote SSH session from Ubuntu

In the above graph we can see a sinusoid. I have generated it by opening another terminal session with the
BBB and executing plc-cape-lab configured to transmit a sine wave of 2 kHz in calibration mode:
Figure 63. plc-cape-lab - Screenshot of a remote SSH session from Ubuntu

Note: the above test takes a lot of resources in the BBB (concurrent transmission + reception + graphical
processing + floating point operations), leading the app to freeze quite often (to be fixed in the next version).
Design of a low-cost device for data transmission over power lines 85/181

3.5.7.2 plc-cape-freq-response

Target plc-cape-freq-response
Purpose Analyze the frequency response of a DAC to ADC path
Details This application generates sine waves sweeping over a predefined range of
frequencies and analyzing the captured signal to get the attenuation occurred per
frequency. Then, it stores in a file the data representing the frequency response of
the DAC to ADC loop
Note: this version only analyzes the effects on magnitude (not phase)
Source code ./applications/plc-cape-freq-response

This application generates two files with Octave-compatible data:

• freq_response.csv: the transfer function for different frequencies (in voltage gain terms)

• adc.csv: the ADC captured wave for a particular frequency

To analyze the content of these files I have created an Octave script (tools/octave/plc_freq_response.m) that
plots three graphs:

• frequency-response in linear axes

• frequency-response in logarithmic axes

• captured samples for the reference frequency

The plc-cape-freq-response application accepts this command line:

# ./plc-cape-freq-response --help
Usage: plc-cape-freq-response [OPTIONS]
Tool to get the frequency response H(f) of a given TX-RX path via the PlcCape board

-A:FREQUENCY Initial frequency [Hz]

-B:FREQUENCY Final frequency [Hz]
-C:COUNT Number of sub-intervals between the initial and final frequencies
-D:FREQUENCY Reference frequency in which to also store the captured samples
-F:FILTER 0 for CENELEC BCD, 1 for CENELEC A
-H:ADC_RANGE Range (peak-to-peak) used for the H(f)=1 reference
-O:DAC_VALUE Offset value [in DAC units]
-R:DAC_RANGE Range (peak-to-peak) value [in DAC units]
-T:MODE Calibration mode index [0 to 3]:
0:none; 1:tx+tx_filter; 2:tx+tx_filter+rx_filter+rx_pga2; 3:tx
-U:GAIN TX_PGA gain index [0 to 3: 0.25, 0.5, 0.71, 1.0]
-V:GAIN RX_PGA1 gain index [0 to 3: 0.25, 0.5, 1.0, 2.0]
-W:GAIN RX_PGA2 gain index [0 to 3: 1, 4, 16, 64]
--help display this help and exit

For the arguments requiring an index from a list of options you can get more
information specifiying the parameter followed by just a colon

To execute the application, first load the PlcCape custom drivers (for ADC and DAC):

# $DEV_SRC_DIR/env/bbb/setup/load_drivers.sh 1 1
86/181 Design of a low-cost device for data transmission over power lines

Then, go to the location of the executable and run it with your custom parameters. For example, to get the
frequency response between 50 Hz and 200 kHz with 11 intermediate points in TX-RX calibration mode do:

# cd $DEV_BIN_DIR/applications/plc-cape-freq-response
# ./plc-cape-freq-response -A:50 -B:200050 -C:11 -D:20050 -F:0 -O:600 -R:400 -U:3 -T:2
SETUP
-----
Test: f_ini = 50 Hz, f_end = 200050 Hz, iterations = 11
DAC values (in DAC units)
Offset = 600.000000, Range = 400.000000, AC Mean = 127.323952
EXPECTED ADC values [in ADC units]
DC mean = 1912.000000, Range = 1400.000000, AC mean = 445.633820
Sampling rate = 522 ksps

TRANSFER FUNCTION
-----------------
Running freq = 50 Hz...Samples captured. DC mean = 1919.14, AC mean = 69.88
Running freq = 20050 Hz...Samples captured. DC mean = 1912.12, AC mean = 440.26
Running freq = 40050 Hz...Samples captured. DC mean = 1913.95, AC mean = 438.30
Running freq = 60050 Hz...Samples captured. DC mean = 1913.44, AC mean = 433.67
Running freq = 80050 Hz...Samples captured. DC mean = 1916.52, AC mean = 415.20
Running freq = 100050 Hz...Samples captured. DC mean = 1916.62, AC mean = 376.39
Running freq = 120050 Hz...Samples captured. DC mean = 1914.36, AC mean = 320.09
Running freq = 140050 Hz...Samples captured. DC mean = 1919.14, AC mean = 252.47
Running freq = 160050 Hz...Samples captured. DC mean = 1929.33, AC mean = 172.61
Running freq = 180050 Hz...Samples captured. DC mean = 1941.60, AC mean = 124.04
Running freq = 200050 Hz...Samples captured. DC mean = 1932.72, AC mean = 92.16

Frequency response from 50 to 200050 Hz (11 samples) stored in 'freq_response.csv'

ADC capture for frequency 20050 (10000 samples) stored in 'adc.csv'
FFT max expected at index 1002.50 (freq 20050.00 Hz)
FFT max at index 1003 (freq 20060.00 Hz), abs(H)/N = 336.69
NOTE: FFT steps = 20.00 Hz

END with success

Now, in Octave, first setup the environment:

>> run X:/tools/octave/plc_setup.m;

plc_setup.m: Loading dependencies...
plc_setup.m: Workspace ready
>> plc_setup_configure("Y:/applications/plc-cape-freq-response", 200000);

Then, plot the graphs:

>> plc_freq_response_plot_all("10k-200k-cenelec-b")
DC mean = 1911.07, AC mean = 440.87, AC Range = 1409.00, FFT max at 20100.00 Hz
H max = 0.99, H min = 0.16

The Octave script returns a brief analysis of the samples captured at the reference frequency (given in the
-D:freq parameter of the command line):

1
N∑
DC mean x [n] Average value of all the captured samples
N

Average of the absolute values after the removal of the

1 DC component
N∑
AC mean |x [n]−DC MEAN|
N Note: for a sequence x[n]=C+A·sin(K·n), AC mean=
2A/π = peak-to-peak/π = 0.318·peak-to-peak

Difference between the maximum and minimum values

AC Range max( x [n])−min( x [n]) of the captured samples.
For a sinusoid, AC Range ≈ π·AC mean
Design of a low-cost device for data transmission over power lines 87/181

Frequency at which the FFT presents its maximum

FFT max max|FFT (x [n])|
value

H max max(H [n]) Maximum and minimum values for the H[n] sequence
H min min(H [n]) (representing the H(f) frequency response)

We can save the plotted graphs to PNG files by using the plc_freq_response_save_plots script:

>> plc_freq_response_save_plots
Storing adc.pdf...
Storing freq_response.png...
Storing freq_response_log.png...

These are the results obtained for a test with an isolated PlcCape-v1:

H[n] in freq_respose.png (left) and freq_response_log.png (right) highlighting the CENELEC-B band

And this is the graph for the samples captured at 20050 Hz in the adc.pdf (and a zoom using a stem plot to
see the individual samples):

ADC data from adc.pdf. At right a zoom to 100 samples with plot and stem

Execution examples of this tool can be seen in the section 4.4 PlcCape RX chain or in 9 Annex IV. AFE031
Calibration modes.
88/181 Design of a low-cost device for data transmission over power lines

3.5.7.3 plc-cape-lab

Target plc-cape-lab
Purpose Laboratory tool to explore the main features offered by the PlcCape board
Details It is the main application for "laboratory work". It offers access to the different
configurable options of the AFE031.
Features:
• Multi wave generation
• Real-time and deferred DAC transmission
• Real-time and deferred ADC reception
• Capturing to file in Octave-compatible format for post-analysis
• Configure main AFE031 parameters: CENELEC band, gains, calibration
modes, etc
• Time measurements
Source code ./applications/plc-cape-lab

plc-cape-lab v0.2 introduces two important new features: XML profiles and plugin-specific settings.

XML PROFILES

In plc-cape-lab v0.1 the configuration profiles where hard-coded. When we required some setting to be
modified for a specific test, we had to do that in the source code and then recompile it.

In the new version, the profiles are defined in an editable XML file (profiles.xml) that is loaded when the
application is started. This considerably simplifies the management of the configuration settings associated
to the different testing scenarios: TX-only, RX-only, TX-RX loop, filtering parameters, etc:

profiles.xml
<plc-cape-lab.profile_definitions>
<profiles>
[...]
<profile id="loop_ramp_2k" inherit="loopback" title="LOOP Ramp 2kHz">
<app-settings>
<setting id="samples_to_file">1000</setting>
</app-settings>
<encoder-settings plugin="encoder-wave">
<setting id="stream_type">ramp</setting>
<setting id="freq">2000</setting>
<setting id="offset">800</setting>
<setting id="range">400</setting>
</encoder-settings>
<decoder-settings plugin="decoder-raw"/>
</profile>
<profile id="tx_2kHz" inherit="tx_pga" title="TX 2kHz">
<encoder-settings plugin="encoder-wave">
<setting id="stream_type">freq_sinus</setting>
<setting id="freq">2000</setting>
<setting id="offset">800</setting>
<setting id="range">400</setting>
</encoder-settings>
</profile>
[...]
</profiles>
[...]
</plc-cape-lab.profile_definitions>
Design of a low-cost device for data transmission over power lines 89/181

Profiles can be selected from the user interface or through the command line:

# ./plc-cape-lab -P:tx_2kHz

The UI menu with the profiles is populated according to the tree structure defined in the profiles.xml itself.
Take a look at the existing profiles.xml for an example of how to do so.

PLUGIN-SPECIFIC SETTINGS

In v0.1 the settings available for plugin usage were globally defined in the plc-cape-lab application, a
strategy that goes against the encapsulation/modularity principle (there is an inter-dependency between the
plugin and plc-cape-lab).

In v0.2 each plugin informs the plc-cape-lab application about the settings it supports so that the UI can
dynamically show them.

It is based on the function get_accepted_settings declared in plugins/encoder/api/encoder.h:

/**
* @brief Asks for the settings accepted by the plugin
* @param handle Handle to the encoder-plugin
* @param accepted_settings_count The number of accepted settings
* @return
* A persistent pointer with a list of setting definitions.
* The pointer must not be released
*/
const struct plc_setting_definition *(*get_accepted_settings)(encoder_api_h handle,
uint32_t *accepted_settings_count);

Find following an example of the implementation of this function in the encoder-ook plugin:

const struct plc_setting_definition accepted_settings[] = {

{
"sampling_rate_sps", plc_setting_float, "Sampling rate [sps]", {
.f = 100000.0f }, 0 }, {
"offset", plc_setting_u16, "Offset", {
.u16 = 500 }, 0 }, {
"range", plc_setting_u16, "Range", {
.u16 = 400 }, 0 }, {
"freq", plc_setting_float, "Frequency", {
.f = 2000.0f }, 0 }, {
"bit_width_us", plc_setting_u32, "Bit Width [us]", {
.u32 = 1000 }, 0 }, {
"message", plc_setting_string, "Message", {
.s = "This is PlcCape. Hello!\n" }, 0 } };

const struct plc_setting_definition *encoder_get_accepted_settings(struct encoder *encoder,

uint32_t *accepted_settings_count)
{
*accepted_settings_count = ARRAY_SIZE(accepted_settings);
return accepted_settings;
}

int encoder_set_setting(struct encoder *encoder, const char *identifier,

union plc_setting_data data)
{
if (strcmp(identifier, "sampling_rate_sps") == 0)
{
encoder->sampling_rate_sps = data.f;
}
else if (strcmp(identifier, "offset") == 0)
{
encoder->settings.offset = data.u16;
}
[...]
return 0;
}
90/181 Design of a low-cost device for data transmission over power lines

MAIN MENU CHANGES

The main menu in v0.2 is slightly different from the one in v0.111:
Figure 64. plc-cape-lab - Screenshot

Basically:

• The Profiles [P] sub-menu is now dynamically generated from the profiles.xml file.

• The Plugins [L] sub-menu is new. It allows the selection of a specific encoder or decoder plugin
among the available in the predefined directory.

• The Settings Encoder [E] and Settings Decoder [D] are new sub-menus for the
configuration of the plugin-specific settings.

3.5.8 Plugins
Three new plugins have been developed:

• encoder-wav, to reproduce content from standard WAV files

• encoder-morse and decoder-morse, to check the interoperability with existing standardized systems

Some improvements have also been introduced in the existing plugins as:

• The demodulation algorithms have been improved for better reliability. In v0.1 the demodulation
was carried out with the abs() function, ideal for performance (very fast) but only acceptable for a
single carrier and low noise scenario. In v0.2 some steps have been taken in coherent demodulation
(which requires much more computational effort)

• In encoder-wave (the plugin in charge of generating different wave patterns) I have added the
possibility to generate a square wave

11 For information about the operation with the plc-cape-lab application consult PlcCapeSoftwareFramework.pdf[1]
Design of a low-cost device for data transmission over power lines 91/181

3.5.8.1 encoder-wav

Target encoder-wav.so
Purpose Reads a 16-bits WAV file and generates the corresponding samples in plc-cape
compatible format
Details Configurable settings
• filename
Source code ./plugins/encoder/encoder-wav

This plugin allows playing a WAV file through the AFE031 DAC. I have used it to verify the real-time
behavior of the custom SPI-to-DAC driver (some real-time pitfalls are difficult to be discovered with an
oscilloscope). The idea is to reproduce some suitable WAV and qualitatively check that the emitted audio is
clean. For example, real-time problems can be manifested as audio glitches.

To produce audible output we can use earphones, a speaker or a passive buzzer. I have used a small passive
buzzer from the 37-in-1-sensors-kit[11]:
Figure 65. encoder-wav - Test with a passive buzzer connected to PlcCape-v2

I have done two tests with the plc-cape-lab application:

• Firstly, with the encoder-wave plugin (the multi-waveform generator) I have generated a 1 kHz tone
and confirmed the audible sound. I have also modified the frequency and the TX_PGA settings to
verify that the passive buzzer works as expected

• Secondly, with the new encoder-wav plugin I have selected a WAV file with a clean sound and
reproduced it repeatedly. The resulting audio is clear, indicating that the plugin and the customized
SPI driver are working as expected

Note that, due to the PlcCape-v2 patch (see 3.3.7.7 TX_F_OUT bridge), we are using TX_F_OUT (a
3.3V-based signal with low current sourcing capabilities) instead of PA_OUT (the 15V-based signal for
higher current sourcing). Even in these conditions the current sourced is enough to produce audible sound.

The first version of this plugin is very basic and only recognizes some specific WAV formats. In fact, the
target here was to check only that the system worked fine, not to build a WAV player.

In any case, this is an example of how the PlcCape framework can be used for other purposes than just PLC.
92/181 Design of a low-cost device for data transmission over power lines

3.5.8.2 encoder-morse

Target encoder-morse.so
Purpose Encodes data in Morse-code
Details Configurable settings
• sampling_rate_sps, offset, range, freq, bit_width_us, message
Source code ./plugins/encoder/encoder-morse

Morse code can be considered a specific implementation of an OOK modulation. It is not very efficient but it
is an interesting option that can be used for interoperability: any existing system that implements the well
known Morse code would be able to understand the data sent by this plugin:

static const char *morse_table[] = {

// 0 to 9
"-----", ".----", "..---", "...--", "....-", ".....", "-....", "--...", "---..", "----.",
// : to @
"---...", "", "", "-...-", "", "..--..", ".--.-.",
// A to Z
".-", "-...", "-.-.", "-..", ".", "..-.", "--.", "....", "..", ".---", "-.-", ".-..", "--",
"-.", "---", ".--.", "--.-", ".-.", "...", "-", "..-", "...-", ".--", "-..-", "-.--", "--.." };

As an example of the signal generated by this plugin, I have done a test using these settings:

• Offset = 400, Range = 800, TX_PGA = 1 V/V

• DAC at 522 ksps (SPI at 6 Mbps)

• Carrier frequency: 110 kHz

• Message: SOS

This is the result in the TX_F_OUT pin:

TX_F_OUT. 5ms TX_F_OUT. 20us/div

In the left figure we can clearly identify the symbols corresponding to the SOS message in Morse:
• S -> ...

• O -> ---
Design of a low-cost device for data transmission over power lines 93/181

3.5.8.3 decoder-morse

Target decoder-morse.so
Purpose Decodes Morse data
Details Configurable settings
• sampling_rate_sps, freq, data_hi_threshold, data_offset, bit_width_us,
samples_to_file
Source code ./plugins/decoder/decoder-morse

A Morse decoder allows understanding other systems transmitting in that encoding (interoperability).

I have used it to validate the behavior of the Emulator in the desktop-PC. The idea was to use an external
tool to generate standard Morse tones and check that the Emulator was able to capture them from a
microphone and properly decode the message.

On the Internet we can find many tools that return the Morse encoding corresponding to a given message.
For example, we get “...---...” for “SOS”. Additionally, on some tools there is also a play button that
allows reproducing the Morse code through the speakers of the PC. The Pitch (frequency of the beeps) and
the encoding rate (width of the beeps) can also be configured.

To check the proper behavior of the decoder-morse plugin, I have performed the following test with the
desktop-PC:

• At the transmitter side, I have opened a window with the Internet Browser and the tool generating
the Morse beeps of a message12.

• At the receiver side, I have executed the plc-cape-lab application running in emulation mode (3.5.6
Emulator) and configured to decode the data received from the microphone in real-time.

In this test we can hear the beeps and see, in real-time, how the message is properly interpreted, confirming
the correct implementation of the decoder and the Emulator.

Logically, if I make enough noise during the test, the decoded message becomes corrupted.

12 I have used an on-line Morse encoder available at http://morsecode.scphillips.com/translator.html

94/181 Design of a low-cost device for data transmission over power lines

3.5.9 Multiplatform test with the Raspberry Pi

With the aim of illustrating the versatility of the PlcCape Software Framework I have tried to execute it in
another different platform, the Raspberry Pi, which is also based on an ARM processor and accepts Debian-
based distributions (see 2.5 Raspberry Pi). Note that the Raspberry Pi 3 has 4 cores and thus, it could be an
alternative to the BBB when more computational effort is required.

To test the proper execution of the framework we will just generate a pure tone in Emulation mode (see
3.5.6 Emulator). The advantage of this mode is that it relies on standard libraries (ALSA) instead of using the
custom driver developed for the BBB (in the SPI and ADC areas). The current plc-cape framework checks
for the presence of a BBB and if not, it automatically switches to Emulation mode.
Figure 66. RPI interoperability - Testing environment

I have used this testing environment:

• A Raspberry Pi 2 powered through the USB port

• Earphones connected to the integrated 3.5mm audio

jack

• A connection with my WiFi router (and its DHCP

server) through Ethernet

• A desktop-PC running Ubuntu to establish the SSH

remote connection with the RPI

First, I have prepared the RPI by writing to a micro SD a Raspbian Lite image downloaded from the official
website13. Then I have started the Raspberry with the new image and updated it with the most recent changes
(apt-get update and apt-get upgrade). After that process, I have executed some identification
commands:

$ uname -a
Linux mjpi 4.4.38-v7+ #938 SMP Thu Dec 15 15:22:21 GMT 2016 armv7l GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 8.0 (jessie)
Release: 8.0
Codename: jessie

$ dpkg --print-architecture
armhf

Here we have interesting information:

• The RPI is based on the armv7l architecture, as the BBB. The armhf also indicates that it has
hardware-floating support, which is important here due to the intensive use of the floating point
calculations performed by the plc-cape software framework.

13 Raspian downloads are available at https://www.raspberrypi.org/downloads/raspbian

Design of a low-cost device for data transmission over power lines 95/181

• The Raspbian Lite is based on Debian Jessie 8.0 (Linux Kernel 4.4.38). In my BBB I have Debian
Wheezy 7.8 (Linux Kernel 3.8.13), which is the original version that came pre-installed. So, this test
is also useful to validate the plc-cape behavior across different versions of Debian distributions.

For the test, I wanted to use the same BBB plc-cape binaries, with no rebuilding process involved. To do so,
I shared my BBB binaries through a SAMBA resource in the desktop-PC (as described in
PlcCapeSoftwareFramework.pdf[1]). Then, I connected to the RPI through a SSH session and followed this
procedure:

myuser@mypc:~$ ssh pi@mypi

[...]

pi@mypi:~ $ sudo mount -t cifs //mypc/plc-cape-bin-bbb /mnt/plc-cape-bin -o user=,password=,exec

pi@mypi:~ $ cd /mnt/plc-cape-bin/applications/plc-cape-lab/
pi@mypi:/mnt/plc-cape-bin/applications/plc-cape-lab $ ./plc-cape-lab

The plc-cape-lab application has started without complaint. I have then configured it to generate a sine wave
at 2 kHz (audible sound) with a sampling rate of 48 ksps (which is a typical value to play audio with high-
quality). This is the screenshot of the plc-cape-lab showing the connection with the ALSA driver:
Figure 67. RPI interoperability - Screenshot of plc-cape-lab when playing a tone

By starting the wave generation with ON, we ear the pure tone through the earphones, confirming that most
of the developed software can be easily reused on other Debian-based platforms.

This test suggest another possible use for the plc-cape framework: we could connect our Push-Pull amplifier
(or similar) to the audio output of the RPI and have a kind of fully customizable function generator (limited
to the bandwidth of the audio DAC, probably close to 48 ksps).

As a curiosity, I have repeated the above test using an HDMI connection with the TV. In this case, the audio
is played through the speakers of the TV because the ALSA engine routes it this way.
96/181 Design of a low-cost device for data transmission over power lines

4 Analysis & results

4.1 Overview
This chapter is focused on real tests with the modules described in the section 3 Implementation.

Firstly, you will find some tests intended to deeply check the behavior of the individual devices involved in
this project. Then, the communication of modulated data between modules will be evaluated:

Test Summary

The PlcCape output signals involved in the generation and

transmission of the data are analyzed. A full characterization of the
4.3 PlcCape TX chain TX chain is carried out by using different testing conditions.
The behavior of the Push-Pull amplifier stage is also analyzed (as an
optional module within the TX chain).

The PlcCape input signals involved in the reception of data are

4.4 PlcCape RX chain analyzed. A full characterization of the RX chain is performed by
looking at the different probing points.

4.5 Arduino and Push-Pull The behavior of the assembly composed of the Arduino Leonardo
amplifier board and the Push-Pull amplifier is analyzed.

The communication of data between devices is evaluated:

▪ Firstly, the direct connection between two BBBs (with the
4.6 Data communication
PlcCape boards attached) is checked.
over an unpowered line
▪ Secondly, the connection between the Arduino+Push-Pull-
Amplifier and the BBB+PlcCape is tested.

4.7 Analysis of the 230VAC The resulting signal after the 230VAC decoupling stage is captured
mains and analyzed to get an idea of the transmission channel conditions.

Communication tests over the 230VAC line are performed on

4.8 Data communication different conditions.
through the 230VAC line The equipment used for the tests is composed of:
▪ at TX, Arduino + Push-Pull amplifier + AC coupling module
▪ at RX, BBB + PlcCape

The full system is validated. It consists in getting the temperature

reported by the remote device from a different electrical outlet.
4.9 Final system The equipment used for the test is composed of:
integration ▪ at TX, Arduino + Temperature sensing shield + Push-Pull
amplifier + AC coupling module
▪ at RX, BBB + PlcCape
Table 15. Summary of tests performed
Design of a low-cost device for data transmission over power lines 97/181

At the beginning of each test there will be an initial summary of the objectives pursued and a photo of the
testing environment. When a result leads to an interesting conclusion, it will be highlighted.

The enclosed plots share these characteristics:

• The captured graphs have been minimized because qualitative results are more important than
accurate quantitative measures.

• Each capture has a title indicating the most relevant settings involved in the test. For a series of
graphs, the settings that change from one capture to the next are highlighted in bold.

• At the right of each capture I have added some comments related to the results obtained.

For the meaning of the signals in the TX or RX chains, see 2.2.2 AFE031 blocks and pins. For the PlcCape
probing points, see Figure 21. PlcCape-v1 probing points and Figure 39. PlcCape-v2 probing points.

4.2 Considerations
4.2.1 230VAC measurements
I want to highlight here the special care that must be taken when working with hazardous high voltage, as the
230VAC in the mains (~650 VPP). A mistake in a connection involving 230VAC usually results in dramatic
consequences: huge electronic damage, fire, injuries...

CAUTION!
230VAC high-voltage is dangerous. It may constitute a safety hazard if not operated
properly. It can even imply death. Be very careful if working with. Always double-check
any step you do and, in case of doubt, avoid it.

In fact, due to my modest experience in 230VAC electronics, I realized a few times how easy it is to make a
severe mistake there:

• If you use a USB oscilloscope to capture signals, remember that it is usually grounded to the GND of
the USB connection. If you probe some 230VAC-based signal (usually using x10 scope probes and
behind large resistors to cut down the voltage), you might make a very dangerous loop that can crash
any equipment connected to the USB, including your oscilloscope or the motherboard of your PC

• A weak soldering in the 230VAC path can produce a flame of fire in it

4.2.2 RX filtering
The PlcCape board has a first filtering stage at reception to attenuate frequencies out of the CENELEC band.
As we can see in the Figure 12. PlcCape-v1 SCH AFE031 core circuitry, it consists in a forth-order passive
RLC network (resistors, inductors and capacitors).

At the beginning of the project I soldered, by mistake, the RLC components corresponding to the
CENELEC-A band, whereas this project is CENELEC-B oriented. As a result, the 110 kHz signal used in
the tests experiences extra attenuation (because out of the CENELEC-A band). I realized this mistake in an
advanced phase of the project. In order to avoid confusion, I opted to keep the configuration that I had been
using since the beginning of the project.

In any case, if we are able to receive a 110 kHz carrier with a penalizing CENELEC-A filter, we will also be
(and more easily) with a more suitable CENELEC-B filter.
98/181 Design of a low-cost device for data transmission over power lines

4.2.3 Wearing of PlcCape boards

During the testing phase, I damaged the Power Amplifiers of the two PlcCape boards that I had. Fortunately,
it seems that this did not hugely affect other blocks in the AFE031 but, there may be some kind of negative
effect due to premature wearing. In this chapter, there are tests done before and after that moment. A new
PlcCape board could give slightly different results in quantitative terms but the qualitative results (the main
goal of this project) will be the same.

4.3 PlcCape TX chain

The main objective of this section is to validate and characterize the transmission chain of our PlcCape
board: discover limitations in magnitude and frequency, examine the effect of different AFE031 settings, etc.
It includes the oscilloscope captures of the most relevant signals in the TX chain in different conditions. That
information is useful to understand the behavior of the AFE031 and also for future reference.

To validate the TX chain, different waves have been generated from the 10-bits DAC of the AFE031 (via the
SPI bus) using the plc-cape-lab application. As a reminder of its usage[1], the Offset setting indicates the
center of the wave while the Range setting indicates the peak-to-peak value. Both come specified in DAC
units. This way, an Offset = 512 and a Range = 1020 means a wave covering a range 512±1020/2, or in
similar terms, a wave from a DAC value equal to 2 to a DAC value equal to 1022. Note that I have usually
used 1020 instead of 1024 to give some margin in case of any possible rounding mistake on the wave
generation software.

With plc-cape-lab we can also configure the gains of the PGAs at TX and RX, and the CENELEC filter.

The most relevant signals involved in the TX chain come directly from the AFE031 chip and are:

Signal name Description

The AFE031 DAC is operated through a high throughput SPI bus.

SPI block: The SPI behavior is not a key topic in this project. It is assumed to be working
SCLK as expected. Anyway, a basic analysis done in this area is provided in the
DOUT chapter 8 Annex III. PlcCape board SPI analysis. It can be useful, for instance,
CSN if the throughput of the SPI bus is required to be boosted (a way might be by the
use of some external hardware to produce a shorter Chip Select pulse).

TX_PGA_OUT DAC output after the Programmable Gain Amplifier (TX_PGA).

TX_F_OUT TX_PGA_OUT once filtered by the AFE integrated Low Pass Filter (LPF).

Signal reaching the input of the Power Amplifier (PA). It is the TX_F_OUT
PA_IN
after a decoupling capacitor which allows for proper required biasing.

Amplified output with a high current sourcing capability. Thus, this output can
PA_OUT
be injected into low impedance AC lines.
Table 16. Signals involved in the PlcCape TX Chain

For the TX test, we are going to generate a simple sinusoid and look with the oscilloscope at the different
points in the chain. I am going to use the PlcCape-v1 board because the better accessibility of the probing
points (compared to PlcCape-v2).
Design of a low-cost device for data transmission over power lines 99/181

4.3.1 TX_PGA_OUT vs. TX_F_OUT

Objective: Expose the differences between the two available low-power outputs

Testing environment: PlcCape-v1 + oscilloscope probing both signals

Figure 68. TX chain analysis - PlcCape - Testing environment

For the TX_PGA_OUT the oscilloscope probe must be manually held on the TX_PGA_OUT probing point.

Find following a summary of the signals analyzed and their arrangement in the graphs in following pages:

It is the output of the AFE031 DAC after the Programmable Gain

Amplifier (TX_PGA) but before the internal CENELEC filter
CH1
(TX_LPF).
TX_PGA_OUT Blue
At the maximum rate allowed by the DAC (1.5 Msps) it could
Top
generate signals of frequencies up to 750 kHz (Nyquist theorem).
Range = 0 V to 3.3 V.

It corresponds to the TX_PGA_OUT after traversing the internal

CH2 filter (TX_LPF). This reduces the achievable frequency to around
TX_F_OUT Red 200 kHz. The filter softens TX_PGA_OUT by attenuating the
Bottom harmonics with frequencies over the CENELEC band.
Range = 0 V to 3.3 V.

For the tests in this chapter, I have used a SPI clock of 6 Mbps (bps = bits per second) which means an
effective DAC sampling rate of 522 ksps (sps = samples per second).

Note: To convert from SPI baud rate (bps) to sampling rate (sps) use the following formula 14:

1
freq_DAC [samples per second]=
10.5
+165∗10−9
SPI rate in bits per second

14 To get more information about how this formula has been found consult the PlcCapeSoftwareFramework.pdf[1]
100/181 Design of a low-cost device for data transmission over power lines

Sinus 110 kHz. Offset = 512. Range = 1020. TX_PGA = 0.25 V/V. Filter = CENELEC-B
In the graph at the left, we can clearly see the
effect of the internal low-pass filter (LPF):
▪ TX_PGA_OUT (at top) exposes the typical
sample&hold shape of DACs
▪ TX_F_OUT (at bottom) exposes the
smoothed shape after the low-pass filter
Other conclusions on TX_F_OUT:
▪ A Range of 1020 means a ΔV of ~925 mVPP
▪ TX_F_OUT is centered around 1.7 V
Sinus 110 kHz. Offset = 512. Range = 510. TX_PGA = 0.25 V/V. Filter = CENELEC-B

By reducing by half the Range setting, produces

half the amplitude in TX_F_OUT, 478 mVPP in
the left figure.
Note that the 478 mVPP is just a rough
approximation, affected by the resolution of the
oscilloscope cursors and the manual measurement
procedure. I am using here the exact value from
the left picture just to clearly show where the
measure comes from.

Sinus 110 kHz. Offset = 256. Range = 510. TX_PGA = 0.25 V/V. Filter = CENELEC-B

The Offset value affects the DC component of

the TX_F_OUT.
In the left figure, the center of the wave has
changed from the 1.7 V for the Offset 512
(previous graph) to 1.44 V for the Offset 256.
With the data got, we can propose a first version
of the formula converting Range to voltage (for
TX_PGA = 0.25 V/V):
ΔVTX_F_OUT = Range·0.925VPP/1020 = Range/1100

Sinus 110 kHz. Offset = 256. Range = 510. TX_PGA = 0.5 V/V. Filter = CENELEC-B

By doubling the gain of the TX_PGA (through a

SPI dedicated command), the peak-to-peak
volatage of the TX_F_OUT is also doubled, to
966 mVPP.
Note that the offset of TX_F_OUT has also
moved down from the previous 1.44 V to about
1.3 V.
Design of a low-cost device for data transmission over power lines 101/181

Sinus 110 kHz. Offset = 256. Range = 510. TX_PGA = 1 V/V. Filter = CENELEC-B

By doubling again the gain of the PGA, we can

see that the output spans now from 0 V to 1.84 V.
This is about 4 times the result got with
TX_PGA = 0.25 V/V (which was 0.478 VPP).
So, considering the previous experiences, we can
deduce an approximate formula between the
Range setting and TX_F_OUT peak-to-peak
voltage for frequencies within the pass-band:
ΔVTX_F_OUT (approx) = Range·TX_PGA/275

Sinus 110 kHz. Offset = 256. Range = 510. TX_PGA = 1 V/V. Filter = CENELEC-A

In this test the AFE internal filter (TX_LPF) has

been switched from CENELEC-B (pass-band
frequency[17] = 145 kHz) to CENELEC-A (pass-
band frequency = 95 kHz).
We can see that TX_PGA_OUT (the signal before
the filter) is not affected but we realize that
TX_F_OUT (signal after it) is highly attenuated.
Now the amplitude has decreased from 1.8 VPP to
0.8 VPP.

Sinus 50 kHz. Offset = 256. Range = 510. TX_PGA = 1 V/V. Filter = CENELEC-A

By decreasing the frequency to 50kHz, which is

within the CENELEC-A band, the amplitude of
TX_F_OUT comes back to the non-filtered level
(close to 2VPP).

Sinus 50 kHz. Offset = 512. Range = 1020. TX_PGA = 1 V/V. Filter = CENELEC-A
In this last test I have configured the Offset and
Range to practically cover the whole DAC range.
We can appreciate a saturation effect on
TX_F_OUT. That is because we are reaching the
maximum level of TX_F_OUT, close to 3.3V.
Therefore, special care should be taken when
choosing the offset, range and PGA gain to
avoid saturation issues.
Note: here the voltage scale for CH1 and CH2
have been doubled (1V/div) in relation to
previous captures.
102/181 Design of a low-cost device for data transmission over power lines

4.3.2 Sampling rate effects

Objective: Examine the effects of the DAC sampling rate in the TX_F_OUT signal

The sampling rate at the DAC is essential to have a good signal generation. The Nyquist theorem states that
it must, at least, double the maximum analog frequency covered. In the following tests I have used a low
frequency sine wave (~20 kHz) to not be affected by the TX_LPF filtering and, this way, be able to isolate
the sampling-rate effects. In the below graphs:

• The top plot corresponds to the TX_F_OUT signal.

• The bottom plot is the Fast Fourier Transform calculated by the oscilloscope software.

• All the captures have a scale of 500 mV/div and 50 us/div. For the FFT the scale is 50 kHz/div.

• In the title it is specified the SPI baud rate and the corresponding DAC freq (see formula in 4.3.1).

SPI CLK = 750 kbps = 70597 sps → Nyquist freq = 35299 Hz = 35 kHz

Here we can see that when generating a wave close to the Nyquist frequency (and therefore, using few
samples per cycle), the generated wave has a considerable amount of harmonic content due to the
square shape of the sample&hold process at the DAC.
SPI CLK = 1.5 Mbps = 139567 sps→ Nyquist freq = 70 kHz

If we double the sampling frequency, the sample&hold time is reduced (we have more DAC samples per
cycle). This raises the frequency of the harmonics, which then fall out of the TX_LPF pass band.
SPI CLK = 3 Mbps = 272851 sps → Nyquist freq = 136 kHz

At 3 Mpbs = 272 ksps there is not noticeable harmonic content.

If we repeat the test for higher frequencies we can conclude that a minimum baud rate of 6 Mbps (522
ksps) is recommended in order to generate a suitable 110 kHz signal.
Design of a low-cost device for data transmission over power lines 103/181

4.3.3 TX_F_OUT, PA_IN and PA_OUT

Objective: Analyze the output of the Power Amplifier and its relation with TX_F_OUT

The PA_IN is the input at the Power Amplifier of the AFE031. It corresponds to the TX_F_OUT signal after
a decoupling capacitor (see 3.3.6.2 Schematics).

Testing conditions:

• Sinusoid of 20 kHz at 1.5 Mbps

• CH1 and CH2 scale = 1 V/div. Time scale = 100 us/div

TX_F_OUT (at top) and PA_IN (at bottom)

The capture shows that PA_IN is equal to TX_F_OUT but with the DC removed (see the 0V reference marks
at the left margin).

To analyze the behavior of PA_OUT (the output of the Power Amplifier), we will use this configuration:

• Sinusoid of 10 kHz at 3 Mbps. TX_PGA = 0.25 V/V

• A 15 VDC supply to power up the Power Amplifier of the AFE031

• CH1 and CH2 scale = 2 V/div. Time scale = 200 us/div

Offset = 800. Range = 400 Offset = 500, Range = 800

We can see that with a Range of 400 DAC units we get an output of 2.5 VPP centered on 7.5 V, which is half
the power supply of the PA. By doubling the level of the DAC Range, the PA_OUT doubles too, to 5 VPP.

As per the previously obtained formula (ΔVTX_F_OUT = Range·TX_PGA/275), a Range = 400 means a
ΔVTX_F_OUT = 0.36 VPP, and therefore a PA gain of 2.5/0.36 = 6.9 → ΔVPA_OUT (approx) = 6.9·ΔVTX_F_OUT. This
result is close to the nominal gain given in the AFE031 datasheet, 6.5 V/V.

Note that the Offset setting used to configure the DC component of the TX_F_OUT (800 in the left figure,
and 500 in the right one) does not affect PA_OUT, which is internally biased to half the power supply.
Therefore, PA_OUT will always be centered on 7.5 V when using a 15V power supply.
104/181 Design of a low-cost device for data transmission over power lines

4.3.4 PlcCape-v1 and Push-Pull amplifier stage

Objective: Verify the proper operation of the Push-Pull amplifier stage

Testing environment: PlcCape-v1 + Push-Pull amplifier

Figure 69. TX chain analysis - PlcCape to Push-Pull - Testing environment

• The TX_F_OUT of PlcCape-v1 is connected to the input of the Push-Pull amplifier (blue wire). In
this test the voltage divider block (potentiometer) is skipped: with PlcCape it is not necessary
because we can configure the signal levels by software.

• The output of the Push-Pull amplifier (PUSH_PULL_OUT) is probed with the oscilloscope (green
wire). In the test it is connected to a load of 2.7 kΩ.

• The PlcCape-v1 is powered up with an external power supply of 5V 1A. The power supply rail is
shared with the Push-Pull amplifier (red and black wires).

• The plc-cape-lab tool is used to generate different waves at PlcCape-v1.

• The base waveform is configured with: sinus 110 kHz, Offset = 256, Range= 510, TX_PGA_1V/V,
sampling rate = 522 ksps (6 Mbps). This generates a sinusoidal wave in TX_F_OUT from 0 to 1.9 V.

• When relevant, I have reported the status of the red LED in the Push-Pull amplifier module, which is
used as a rough indicator of the voltage level at the PUSH_PULL_OUT.

In this section we monitor PUSH_PULL_OUT and TX_F_OUT:

CH2
Output of the Push-Pull amplifier stage (ideally a voltage
PUSH_PULL_OUT Red
follower).
Top

CH1
TX_F_OUT Blue Output of the PlcCape-v1 DAC after the internal filter.
Bottom

Note the arrangement of the involved signals: the INPUT of the Push-Pull stage (TX_F_OUT) comes at
bottom whereas the OUTPUT comes at top. For a more intuitive view they should be in reverse order.
Design of a low-cost device for data transmission over power lines 105/181

Sinus 110 kHz. Offset = 256. Range = 510. TX_PGA = 1V/V. Ro = 2.7 kΩ
We can see that PUSH_PULL_OUT (at top, in
red) properly follows TX_F_OUT (at bottom, in
blue). There is a small difference due to the
minimum drop voltage required at the transistors
of the Push-Pull stage:
▪ TX_F_OUT = 1.9 VPP
▪ PUSH_PULL_OUT = 1.72 VPP
In this test, the red LED in the Push-Pull module
(used to monitor the output level) lights
tenuously.
Sinus 110 kHz. Offset = 512. Range = 510. TX_PGA = 1V/V. Ro = 2.7 kΩ

In this test I have added an offset to the

TX_F_OUT signal (Offset = 512) to verify that
the Push-Pull stage properly removes the DC
component.

Sinus 150 kHz. Offset = 512. Range = 510. TX_PGA = 1V/V. Ro = 2.7 kΩ

Here, I have increased the input frequency to

150 kHz. TX_F_OUT is attenuated to 0.9 VPP due
to the PlcCape-v1 internal CENELEC filter
(150 kHz is out of the pass-band).
PUSH_PULL_OUT properly follows
TX_F_OUT, without extra attenuation. That
means that 150 kHz is within the pass-band of
the Push-Pull amplifier.
The LED does a short flash at beginning
(transient), then it is permanently OFF.

Square 30 kHz. Offset = 512. Range = 510. TX_PGA = 1V/V. Ro = 2.7 kΩ

In this test we check the response of the Push-Pull

module for a square waveform.
With TX_F_OUT we cannot test square waves of
high-frequency due to the low-pass filtering. That
is why I have used 30 kHz here, a low enough
frequency to have a square shape after the LPF.
We can see that the Push-Pull properly follows
the TX_F_OUT.
In this configuration the LED lights energetically.
106/181 Design of a low-cost device for data transmission over power lines

Sinus 50 kHz. Offset = 512. Range = 765. TX_PGA = 1V/V. Ro = 2.7 kΩ. Y-axis = 1 V/div

Here, I have scaled the amplitude of TX_F_OUT

in a 1.5 factor, from Range = 510 to 765 (notice
the new scale for the y-axis, doubled to 1V/div).
I have also switched back to a sinusoid (50 kHz).
We can appreciate a saturation-effect on the
generated TX_F_OUT (2.6 VPP) and how it is
reproduced at the output of the Push-Pull
amplifier (2.47 VPP).
The LED lights vigorously.

Sinus 50 kHz. Offset = 400. Range = 765. TX_PGA = 1V/V. Ro = 2.7 kΩ

By centering TX_F_OUT (Offset = 400), the

saturation problem is resolved. It produces a
TX_F_OUT = 2.8 VPP and a
PUSH_PULL_OUT = 2.56 VPP.

Sinus 50 kHz. Offset = 400. Range = 765. TX_PGA = 1V/V. Ro = 1 kΩ

Now we want to check the effects of the load

impedance. I have replaced the 2.7 kΩ by 1 kΩ.
We can see that the PUSH_PULL_OUT slightly
decreases, from 2.56 VPP to 2.39 VPP.
Thus, our Push-Pull amplifier depends on the
load, as we already saw in the SPICE analysis.
This is a penalty associated to the simplicity of
our Push-Pull circuit.
The LED lights vigorously.

Sinus 50 kHz. Offset = 400. Range = 765. TX_PGA = 1V/V. Ro = 100 Ω

A load resistor of 100 Ω makes the load-effect

more evident: the voltage level at
PUSH_PULL_OUT decreases now to 1.41 VPP.
That is in line with the results found in the SPICE
analysis in 3.4.4.3 Single voltage power supply.
The LED lights very tenuously, almost OFF (it is
difficult to appreciate it).
Design of a low-cost device for data transmission over power lines 107/181

Sinus 1 kHz. Offset = 400. Range = 765. TX_PGA = 1V/V. Ro = 100 Ω

Finally, I want to check the Push-Pull amplifier
performance for very low-impedance conditions.
For that, I am going to use an 8 Ω speaker.
First, I need to cut down the frequency for
audible sound, for example to 1 kHz.
Keeping the R = 100 Ω reveals that the amplitude
decreases to 1.1 VPP. This is due to the AFE031
TX filter (you can see that TX_F_OUT is also
attenuated).
In this situation the LED lights so tenuously that
can only be appreciated in darkness.
Sinus 1 kHz. Offset = 400. Range = 765. TX_PGA = 1V/V. Ro = 8 Ω (a speaker). 1V/div

The 8 Ω speaker makes the voltage level to be

reduced to 686 mVPP.
In these conditions we can clearly hear the 1 kHz
tone, indicating that the Push-Pull is properly
working as a power amplifier.
The LED is always OFF.

Sinus 1 kHz. Offset = 400. Range = 765. TX_PGA = 1V/V. Ro = 8 Ω (a speaker). 100 mV/div

Scaling to 100 mV/div reveals the shape of the

tone which is not a pure sine because the
limitations of the basic Push-Pull amplifier (note
also that the nature of a speaker is not purely
resistive).
In these conditions the current sourced by the
Push-Pull amplifier would be approx IPP = 0.619/8
= 77 mAPP.

Sinus 1 kHz. Offset = 400. Range = 765. TX_PGA = 1V/V. Ro = 15 Ω (pure resistor). 100 mV/div

As the resulting output voltage is low for 8 Ω

(< 1 VPP), I can safely repeat the test with a pure
low-power resistor of 15 Ω (PMAX = 1VPP2/15 =
67 mW).
In both cases we can appreciate the typical
cross-over effect of the Push-Pull amplifiers.
108/181 Design of a low-cost device for data transmission over power lines

To end this chapter, we are going to check the system with an OOK-based signal, which is the modulation
scheme we will use later on the communication between devices.

In particular, the goal of this test is to confirm that the Push-Pull amplifier removes the DC offset of the input
signal efficiently (with minimum transient time):

Sinus 50 kHz. Offset = 400. Range = 765. TX_PGA = 1V/V. OOK ‘Hi’. Ro = 1 kΩ. 1 ms/div

In the oscilloscope capture, we can clearly

identify the H symbol (0x48) in the OOK
encoding: 1 start bit + 01001000 (binary).
TX_F_OUT (at bottom) has a DC component of
about 1.4 V which is immediately and completely
removed in PUSH_PULL_OUT (at top).
The LED flashes intermittently at each Hi word
transmitted.

Sinus 50 kHz. Offset = 400. Range = 765. TX_PGA = 1V/V. OOK ‘Hi’. Ro = 1kΩ. 10 us/div

A zoom to 10 us/div shows the smooth beginning

of each transmitted bit of data at
PUSH_PULL_OUT, with no DC level.
In the chapter dedicated to the transmission with
Arduino, we will see a different transient
behavior because, in that case, the idle level of
the involved signal does not correspond to the
center of the waveform, as happens here.

With this last test we have confirmed that the Push-Pull amplifier removes the DC offset of the input
signal with no transient if the voltage level of the idle state matches the middle level of the OOK
carrier.
Design of a low-cost device for data transmission over power lines 109/181

4.4 PlcCape RX chain

In this section we will analyze how an input signal travels along all the RX path.

To validate the RX chain of the PlcCape board, I have studied two different configurations:

• Auto-loop: the same PlcCape board generates and captures the involved signals. There, we will get
the frequency response H(f) of the loop. In a second iteration I have included the Push-Pull amplifier
into the loop and analyzed its impact. The tests has been carried out with the plc-cape-freq-response
tool

• PlcCape-v2 to PlcCape-v1: the PlcCape-v2 board generates different waves that are captured by the
PlcCape-v1. The tests are carried out by using the plc-cape-lab application. In theory we could rely
on the Auto-loop mode for them, but the plc-cape-lab application hangs quite often when
simultaneously running in both modes (TX and RX) due to the extra CPU overload involved.

4.4.1 Auto-loop with a direct bridge

Objective: Verify the proper operation of the RX chain as a whole

To characterize a system, a practical way is by obtaining its transfer function in the frequency domain. For
that purpose I developed a simple tool, plc-cape-freq-response, and an auxiliary Octave script (see chapter
3.5.7.2 plc-cape-freq-response for more details).

By the way, a very interesting functionality offered by the AFE031 is the possibility to internally connect
some of its composing blocks to make different TX to RX paths. These paths are called Calibration modes
because they can be used to tune the system parameters within a known predefined configuration. We can
also use them to check the proper behavior of the AFE031 internal blocks (TX_PGA, TX_LPF, RX_LPF,
RX_PGA2). For a detailed analysis refer to 9 Annex IV. AFE031 Calibration modes.

As calibration modes make internal bridges in the AFE031, we cannot check the behavior of the external
forth-order filter. Thus, a better approach is to do a direct bridge from TX_F_OUT to TXRX as follows:
Figure 70. RX chain analysis - TX_F_OUT to TXRX bridge
110/181 Design of a low-cost device for data transmission over power lines

In the above auto-loop configuration, we must disconnect the output of the Power Amplifier from the TXRX
line in order to avoid any unexpected feedback. I have done it in PlcCape-v1 by removing the C12 capacitor.

With this testing environment, we will get the transfer function from the DAC to the ADC when TX_F_OUT
and TXRX are interconnected. We well use this auto-loop configuration to establish a normalized reference
for H(f) = 1.0 in the plc-cape-freq-response application.

We will use these settings:

• DAC: Offset = 511, Range = 1022

• TX_PGA = 0.5 V/V

• RX_PGA1 = 1 V/V, RX_PGA2 = 1 V/V

• FILTER = CENELEC-B

This configuration results in a suitable non-saturated TX_F_OUT.

In the tests, we will use 50 kHz as the reference frequency. That means that the test iteration closest to 50
kHz will be stored in a file for further analysis.

To get the transfer function, we just need to execute the plc-cape-freq-response and the corresponding
Octave script, following the steps described in the section 3.5.7.2 plc-cape-freq-response:

# ./plc-cape-freq-response -A:50 -B:200050 -C:41 -D:50050 -F:0 -O:511 -R:1022 -U:1 -V:2 -W:0 -T:0
SETUP
-----
Test: f_ini = 50 Hz, f_end = 200050 Hz, iterations = 41
DAC values (in DAC units)
Offset = 511.000000, Range = 1022.000000, AC Mean = 325.312714
EXPECTED ADC values [in ADC units]
DC mean = 1912.000000, Range = 807.380005, AC mean = 256.997040
Sampling rate = 522 ksps

TRANSFER FUNCTION
-----------------
Running freq = 50 Hz...Samples captured. DC mean = 1911.08, AC mean = 0.84
Running freq = 5050 Hz...Samples captured. DC mean = 1911.28, AC mean = 10.44
Running freq = 10050 Hz...Samples captured. DC mean = 1911.35, AC mean = 40.18
Running freq = 15050 Hz...Samples captured. DC mean = 1911.49, AC mean = 92.44
Running freq = 20050 Hz...Samples captured. DC mean = 1911.28, AC mean = 155.91
Running freq = 25050 Hz...Samples captured. DC mean = 1911.44, AC mean = 207.64
Running freq = 30050 Hz...Samples captured. DC mean = 1911.48, AC mean = 235.92
Running freq = 35050 Hz...Samples captured. DC mean = 1910.59, AC mean = 250.05
Running freq = 40050 Hz...Samples captured. DC mean = 1911.48, AC mean = 255.29
Running freq = 45050 Hz...Samples captured. DC mean = 1911.48, AC mean = 256.72
Running freq = 50050 Hz...Samples captured. DC mean = 1912.45, AC mean = 256.31
Running freq = 55050 Hz...Samples captured. DC mean = 1912.28, AC mean = 254.24
[...]
Running freq = 195050 Hz...Samples captured. DC mean = 1913.04, AC mean = 6.67
Running freq = 200050 Hz...Samples captured. DC mean = 1912.80, AC mean = 5.94

Frequency response from 50 to 200050 Hz (41 samples) stored in 'freq_response.csv'

ADC capture for frequency 50050 (10000 samples) stored in 'adc.csv'
FFT max expected at index 2502.50 (freq 50050.00 Hz)
FFT max at index 2503 (freq 50060.00 Hz), abs(H)/N = 150.74
NOTE: FFT steps = 20.00 Hz

In the Octave graphs, we can highlight the 3 dB cutoff level, which corresponds to a factor 1/sqrt(2) in
voltage terms:

>> plc_freq_response_plot_all("10k-200k", 1/sqrt(2))

DC mean = 1915.34, AC mean = 256.51, AC Range = 809.00, FFT max at 50100.00 Hz
H max = 1.00, H min = 0.00
Design of a low-cost device for data transmission over power lines 111/181

The Octave script plots the H(f) graphs and returns a brief analysis of the samples captured at the reference
frequency (50 kHz). See the chapter 3.5.7.2 plc-cape-freq-response for information about.

H(f). Direct bridge between TX_F_OUT and TXRX

In the left plot we have the frequency response in linear axes; in the right plot we have it in logarithmic axes
(like in Bode diagrams).

As already mentioned, I have manually tuned the plc-cape-freq-response application to give H(f) = 1.0 for 50
kHz with the testing conditions specified above.

By getting the frequencies at which the H(f) reaches the 3 dB cutoff level, we can conclude that the RX
chain of our PlcCape boards has a pass-band between 22 kHz and 91 kHz. This result is according to the
expectations due to the components used in PlcCape-v1 for the fourth-order band-pass filter, targeted to
CENELEC A (as discussed in 4.2.2 RX filtering).

We can compare this result with the obtained in the AFE calibration mode for the TX-RX internal loop (see
section 9.3 TX_PGA + RX_LPF + RX_PGA2 loop):

H(f) for the TX_PGA_RX_PGA2_RX_LPF internal loop in CALIBRATION mode

By comparing both H(f), we can conclude that the inclusion of the forth-order band-pass filter into the loop:

• adds a high-pass cutoff frequency at 22kHz (not present in the H(f) of the Calibration mode)

• brings down the low-pass cutoff frequency, from 125kHz to 91kHz

112/181 Design of a low-cost device for data transmission over power lines

It is interesting to probe the TXRX with the oscilloscope and compare it with the ADC captured data.

TXRX. Direct bridge. 50 kHz. Offset = 511. Range = 1022. TX_PGA = 0.5 V/V

We can see that at 50 kHz we get a TX_F_OUT =

TXRX = 1.67 VPP.

These are the samples captured by the ADC (a zoom to 60 samples at right):

ADC data. Direct bridge. 50 kHz. Offset = 511. Range = 1022. TX_PGA = 0.5 V/V

We can see that with the configuration used (RX_PGA1 = 1 V/V and RX_PGA2 = 1 V/V) the data captured
by the ADC for a TXRX of 1.67 VPP spans from 1500 to 2300 approximately (which coincides with the AC
Range = 809 calculated by the Octave script above).

From all these data, we can deduce the attenuation of the forth-order filter:

1 4096
ADC Range=TXRX⋅FilterGain⋅RX_PGA1⋅RX_PGA2⋅ ⋅
2 1.8
The ½ factor at the end of the formula is due to the voltage resistor divider to accommodate the 3.3 V levels
of the AFE031 to the 1.8 V of the ADC in the BBB (see R14 and R15 in the Figure 12. PlcCape-v1 SCH
AFE031 core circuitry). The 4096/1.8 term corresponds to the 12-bits of the ADC for the full 1.8 V range:

ADC Range 809

FilterGain= = =0.426→ FilterGain( dB)=20⋅log(0.426)=−7.4 dB
1 4096 1 4096
TXRX⋅ ⋅ 1.67⋅ ⋅
2 1.8 2 1.8
So, the forth-order filter introduces an attenuation of 7.4 dB.
Design of a low-cost device for data transmission over power lines 113/181

4.4.2 Auto-loop through the Push-Pull amplifier

Objective: Analyze the frequency response of the Push-Pull amplifier stage

Here we are going to replace our direct bridge between TX_F_OUT and TXRX by the Push-Pull amplifier in
order to check if it introduces some distortion in the band of interest. We will test two configurations:
Figure 71. RX chain analysis - Figure 72. RX chain analysis -
PlcCape to Push-Pull without voltage divider PlcCape to Push-Pull with voltage divider

We are going to first check the case with the voltage divider disabled (above picture at left):

# ./plc-cape-freq-response -A:50 -B:200050 -C:41 -D:50050 -F:0 -O:511 -R:1022 -U:1 -V:2 -W:0 -T:0
[...]
DAC values (in DAC units)
Offset = 511.000000, Range = 1022.000000, AC Mean = 325.312714
EXPECTED ADC values [in ADC units]
DC mean = 1912.000000, Range = 807.380005, AC mean = 256.997040
Sampling rate = 522 ksps

TRANSFER FUNCTION
-----------------
Running freq = 50 Hz...Samples captured. DC mean = 1911.12, AC mean = 0.81
Running freq = 5050 Hz...Samples captured. DC mean = 1911.36, AC mean = 8.15
Running freq = 10050 Hz...Samples captured. DC mean = 1911.33, AC mean = 28.61
Running freq = 15050 Hz...Samples captured. DC mean = 1911.04, AC mean = 57.94
Running freq = 20050 Hz...Samples captured. DC mean = 1911.12, AC mean = 89.33
Running freq = 25050 Hz...Samples captured. DC mean = 1910.49, AC mean = 113.86
Running freq = 30050 Hz...Samples captured. DC mean = 1910.19, AC mean = 130.54
Running freq = 35050 Hz...Samples captured. DC mean = 1909.94, AC mean = 140.52
Running freq = 40050 Hz...Samples captured. DC mean = 1910.38, AC mean = 145.57
Running freq = 45050 Hz...Samples captured. DC mean = 1911.08, AC mean = 147.57
Running freq = 50050 Hz...Samples captured. DC mean = 1911.12, AC mean = 148.11
Running freq = 55050 Hz...Samples captured. DC mean = 1911.98, AC mean = 146.80
[...]
Running freq = 195050 Hz...Samples captured. DC mean = 1912.74, AC mean = 6.23
Running freq = 200050 Hz...Samples captured. DC mean = 1912.64, AC mean = 5.22

Frequency response from 50 to 200050 Hz (41 samples) stored in 'freq_response.csv'

ADC capture for frequency 50050 (10000 samples) stored in 'adc.csv'
FFT max expected at index 2502.50 (freq 50050.00 Hz)
FFT max at index 2504 (freq 50080.00 Hz), abs(H)/N = 101.35
114/181 Design of a low-cost device for data transmission over power lines

In Octave:

>> plc_freq_response_plot_all("10k-200k", 0.58/sqrt(2))

DC mean = 1910.96, AC mean = 148.39, AC Range = 481.00, FFT max at 50100.00 Hz
H max = 0.58, H min = 0.00

For the cutoff level I have used 0.58/sqrt(2) because a first execution of the Octave script gave 0.58 as
the maximum value of the H(f) response.

H(f). Push-Pull amplifier between TX_F_OUT and TXRX

We observe two noticeable variations in the frequency response:

• The low-pass cutoff frequency has not decreased. In fact, it has even increased a bit, from 91 kHz to
100 kHz. This means that our Push-Pull amplifier is suited for signals within the CENELEC
band.

• The maximum gain has dropped from 1.0 to 0.58. In logarithmic units this means that the Push-Pull
amplifier introduces an attenuation of 4.7 dB when skipping the voltage divider.

If we look at the signal at the reference frequency (50 kHz) with the oscilloscope and Octave, we have this:

TX_F_OUT (left) and ADC data (right). Push-Pull amplifier between TX_F_OUT and TXRX

Now TX_F_OUT = 968 mVPP, which corresponds to the previous 1.67 mV PP * 0.58 (= 0.969 mVPP).

The ADC captured signal spans from about 1700 to 2150. Octave returns an AC Range = 481. If we look at
the mean values, the Octave script gives an AC mean = 148.39, which is 0.58 times the mean in the direct
bridge case (AC mean was 256.51).
Design of a low-cost device for data transmission over power lines 115/181

Now we are going to analyze the effect of the voltage divider stage. We first set the potentiometer to the
maximum value = 890 Ω (measured with a multimeter):

# ./plc-cape-freq-response -A:50 -B:200050 -C:41 -D:50050 -F:0 -O:511 -R:1022 -U:1 -V:2 -W:0 -T:0
[...]
DAC values (in DAC units)
Offset = 511.000000, Range = 1022.000000, AC Mean = 325.312714
[...]
Running freq = 50 Hz...Samples captured. DC mean = 1911.08, AC mean = 0.85
[...]
Running freq = 200050 Hz...Samples captured. DC mean = 1911.29, AC mean = 2.54
[...]
FFT max at index 2504 (freq 50080.00 Hz), abs(H)/N = 59.07

In Octave:

>> plc_freq_response_plot_all("10k-200k", 0.34/sqrt(2))

DC mean = 1911.58, AC mean = 85.44, AC Range = 273.00, FFT max at 50100.00 Hz
H max = 0.34, H min = 0.00

H(f). Push-Pull amplifier between TX_F_OUT and TXRX with voltage divider (Rr2 = 890 Ω)

TX_F_OUT (left) and ADC data (right). Push-Pull amplifier with voltage divider (Rr2 = 890 Ω)

We see two effects of the voltage divider (which includes a capacitor):

• H max = 0.34 which means that the Push-Pull amplifier with the voltage divider enabled
introduces a minimum attenuation of 9.4 dB (for Rr2 = 890 Ω).

• The entry capacitor in the voltage divider has a significant impact on the low-pass cutoff
frequency of the TX-to-RX loop, which falls from 100 kHz to about 80 kHz.
116/181 Design of a low-cost device for data transmission over power lines

We set now the potentiometer to ¼ (90º) = 150 Ω (measured):

# ./plc-cape-freq-response -A:50 -B:200050 -C:41 -D:50050 -F:0 -O:511 -R:1022 -U:1 -V:2 -W:0 -T:0
[...]
DAC values (in DAC units)
Offset = 511.000000, Range = 1022.000000, AC Mean = 325.312714
[...]
Running freq = 50 Hz...Samples captured. DC mean = 1911.61, AC mean = 0.78
[...]
Running freq = 200050 Hz...Samples captured. DC mean = 1911.69, AC mean = 2.51
[...]
FFT max at index 2503 (freq 50060.00 Hz), abs(H)/N = 27.80

In Octave:

>> plc_freq_response_plot_all("10k-200k", 0.20/sqrt(2))

DC mean = 1912.18, AC mean = 49.97, AC Range = 169.00, FFT max at 50100.00 Hz
H max = 0.20, H min = 0.00

H(f). Push-Pull amplifier between TX_F_OUT and TXRX with voltage divider (Rr2 = 150 Ω)

TX_F_OUT (left) and ADC data (right). Push-Pull amplifier with voltage divider (Rr2 = 150 Ω)

In this configuration H max = 0.2. This means that with Rr2 = 150 Ω in the voltage divider, the Push-Pull
amplifier introduces an attenuation of 14 dB.
Design of a low-cost device for data transmission over power lines 117/181

4.4.3 PlcCape RX chain characterization

Objective: Analyze the most interesting signals in the RX chain of the PlcCape

In this chapter we will deeply analyze the received signal in different points while it traverses the RX path.
For that, we will use the PlcCape-v2 as the transmitter and the PlcCape-v1 as the receiver. I have also
included the Push-Pull amplifier15 as a replacement for the Power Amplifier of the PlcCape-v2 (see 3.3.7.7
TX_F_OUT bridge):
Figure 73. RX chain analysis -
PlcCape + Push-Pull + PlcCape - Testing environment

• PlcCape-v2 is used to generate known signals over the TX_F_OUT (blue wire).

• TX_F_OUT is connected to the Push-Pull amplifier skipping the voltage divider.

• The Push-Pull amplifier is powered by the 5V from the PlcCape-v1 (red wire) which directly come
from the 5V 1A power supply. We cannot use the 5V from the auxiliary header of the PlcCape-v2
because it has no voltage when powered by USB (as explained in the section 3.3.7.2 Schematics).

• PlcCape-v1 is used to capture the data.

• The grounds of the three modules are bridged to guarantee the same GND reference.

• Default signal used: Sinus 50 kHz. Offset = 400. Range = 765. TX_PGA = 1 V/V.

• For the load we are using a Ro = 1 kΩ.

15 Examples of direct transmission from BBB to BBB without an intermediate stage can be consulted in
PfcSoftwareFramework.pdf[1]
118/181 Design of a low-cost device for data transmission over power lines

We interact with PlcCape-v2 via USB and configure it for transmission with the plc-cape-lab app:
Figure 74. RX chain analysis - plc-cape-lab at transmission

We interact with PlcCape-v1 via Ethernet and configure it for reception:

Figure 75. RX chain analysis - plc-cape-lab at reception

On a basic initial test, we can see at the bottom of the Figure 75 that AC Mean = 50.1, which indicates that
PlcCape-v1 is receiving a signal with a significant voltage level.

For reference, we also measure TX_F_OUT with PlcCape-v2 isolated (leaving the blue wire floating):
Figure 76. RX chain analysis - TX_F_OUT on an isolated PlcCape-v2

We get a TX_F_OUT of 2.4 VPP for a Range = 765. Note that the signal is slightly saturated at top. It seems
to be due to the wearing of the AFE031 in the PlcCape-v2 because it did not happen with the PlcCape-v1
using the same settings (as seen in 4.3.4 PlcCape-v1 and Push-Pull amplifier stage, which resulted in a
proper sinusoid of 2.8 VPP).
Design of a low-cost device for data transmission over power lines 119/181

I have captured the PUSH_PULL_OUT for different frequencies:

TX_F_OUT (top, blue) and PUSH_PULL_OUT (bottom, red). 50 kHz. 20 us/div

We can see that for a TX_F_OUT = 2.4 VPP we get

a PUSH_PULL_OUT = 1.2 VPP.
This low voltage level at PUSH_PULL_OUT is
due to the input impedance of the PlcCape-v1 RX
block, which is close to 150 Ω for a 50 kHz signal.
In this configuration the LED in the Push-Pull
amplifier lights very tenuously but it is still
noticeable on a dark environment.

TX_F_OUT and PUSH_PULL_OUT. 1 kHz. 1 ms/div

If we check with 1 kHz, we get a higher
PUSH_PULL_OUT = 1.68 VPP.
This is because the input impedance of the
PlcCape-v1 RX block increases at low
frequencies leading to a higher gain at the Push-
Pull amplifier (which is load-dependent).
The LED lights now with a good intensity.
If in this configuration we take a look at plc-cape-
lab at reception, we will see an AC Mean close to
zero because the filters in the RX chain remove
low frequencies before reaching the ADC of the
BBB (as seen in 4.4.1).
TX_F_OUT and PUSH_PULL_OUT. 110 kHz. 20 ms/div

At 110 kHz the PUSH_PULL_OUT achieves 1.18

VPP, similar to the 50 kHz case.
In this configuration the LED lights very tenuously
(as in 50 kHz), but the AC mean given by the plc-
cape-lab is close to 30 (it was 50 for 50 kHz). That
is due to the forth-order passive filter which is
intended for the CENELEC-A band (see 4.2.2 RX
filtering and 4.4.1 Auto-loop with a direct bridge).

In the following pages I have included the oscilloscope captures at different points in the RX chain for
different configurations. For the probing points of the involved signals see Figure 21. PlcCape-v1 probing
points. By default, I will use the TX_F_OUT signal at 50 kHz already seen above.
120/181 Design of a low-cost device for data transmission over power lines

PUSH_PULL_OUT (blue, top) and TXRX (bottom, red)

The PUSH_PULL_OUT line is directly connected

to the AC pins of the receiver (PlcCape-v1)
through the green and black wires (see Figure 73).
At TXRX we observe a small gain in voltage, from
PUSH_PULL_OUT = 1.2 VPP to TXRX = 1.5 VPP,
which represents a factor of 1.25 (=1.5/1.2). This is
an effect of the coupling transformer (see the
Figure 22. Auxiliary AC coupling module -
Schematic).

RX_PGA1_IN (top) and RX_PGA1_OUT (bottom). AFE031 RX block = OFF

In this test we measure the signals at the input and

output of the first RX block within the AFE031,
the Programmable Gain Amplifier 1 (see Figure 5.
AFE031 blocks and pins).
At the input (RX_PGA1_IN), the signal has
already traversed the forth-order passive filter (see
Figure 12. PlcCape-v1 SCH AFE031 core circuitry)
. It has been attenuated from 1.5 VPP to 717 mVPP.
RX_PGA1_OUT = 0 V because the AFE031 RX
chain has not yet been enabled within plc-cape-lab.

RX_PGA1_IN and RX_PGA1_OUT. AFE031 RX block = ON. RX_PGA1 = 0.25 V/V

If we enable the RX chain with plc-cape-lab, we

see two effects:
▪ RX_PGA1_IN is risen by the AFE031 about
1.4 V in order to adjust the input of the PGA to
suitable levels.
▪ The output signal (RX_PGA1_OUT) is now
enabled. It is attenuated from 717 mV PP to
197 mVPP, which means a gain of 197/717 =
0.27, close to the 0.25 expected.

RX_PGA1_IN and RX_PGA1_OUT. RX_PGA1 = 1 V/V

By increasing the gain of the RX_PGA1 from

0.25 V/V to 1 V/V (with plc-cape-lab) we see that
the output of the PGA is equal to the input, as
expected.
Design of a low-cost device for data transmission over power lines 121/181

RX_F_IN and RX_F_OUT. RX_PGA1 = 1 V/V. 50 kHz. RX_LPF = CENELEC-B

Here we measure the input and output of the

internal AFE031 RX filter (RX_LPF).
In the PlcCape board design, RX_F_IN is directly
connected to RX_PGA1_OUT through a trace, so
it matches the RX_PGA1_OUT graph of the
previous test.
The output of the filter (RX_F_OUT) is 717 mVPP,
equal to the input because 50 kHz is in the pass-
band of the CENELEC-B filter.

RX_F_IN and RX_F_OUT. RX_PGA1 = 1 V/V. 110 kHz. RX_LPF = CENELEC-B

If we increase the frequency of the signal to

110 kHz, we face some attenuation.
This attenuation does not come from the AFE031
internal filter (RX_LPF), since both signals here
(input and output) are equal.
Here the attenuation comes from the forth-order
filter stage, which is targeted to the CENELEC-A
band (see 4.2.2 RX filtering).

RX_F_IN and RX_F_OUT. RX_PGA1 = 1 V/V. 110 kHz. RX_LPF = CENELEC-A

If we switch the AFE031 internal filter to the

CENELEC-A band (with plc-cape-lab), we can see
how the RX_F_OUT signal is attenuated.
It goes from the 384 mVPP in the CENELEC-B
case to 229 mVPP in CENELEC-A.

RX_PGA2_IN and RX_PGA2_OUT. RX_PGA1 = 1 V/V. RX_PGA2 = 1 V/V. 50 kHz. CENELEC-B

Now we focus on the RX_PGA2 programmable
amplifier (with configurable gains of 1, 4, 16, 64).
We take a look at the input and output signals.
RX_PGA2_IN is connected to RX_F_OUT
through a capacitor of 10 nF. This eliminates the
DC-component of the signal and allows the
AFE031 to bias it to a suitable working voltage.
We observe that with a gain of 1 V/V the
RX_PGA2_OUT follows the RX_PGA2_IN.
Note that to measure RX_PGA2_OUT we need to
put and hold the oscilloscope probe on the
corresponding SMD pad (in R14).
122/181 Design of a low-cost device for data transmission over power lines

RX_PGA2_IN and RX_PGA2_OUT. RX_PGA1 = 1 V/V. RX_PGA2 = 4 V/V. 50 kHz. CENELEC-B

If we set the RX_PGA2 gain to 4 V/V (with plc-

cape-lab) we can see the corresponding x4
magnification at the output.
Note here that the low side of the sinusoid is
saturated because the magnified signal would go
below 0 V. Therefore, in real scenarios, we will
need to adjust the gain of our PGAs to get
suitable voltage levels before reaching the ADC,
taking care of avoiding any saturation effect.
RX_PGA2_OUT = 2.44 VPP

RX_PGA2_IN and ADCIN. RX_PGA1 = 1 V/V. RX_PGA2 = 4 V/V. 50 kHz. CENELEC-B

Finally, we take a look at the signal reaching the

ADC of the BeagleBone Board, which is equal to
RX_PGA2_OUT after a 0.5 voltage divider:
ADCIN = RX_PGA2_OUT/2
In the graph, ADCIN = 1.23 VPP, as expected.

For the final tests on the RX chain, I am going to focus on the digital samples captured by the ADC of the
BeagleBone Board. For that matter, I am going to rely on the plc-cape-lab functionality that allows storing in
a file an interval of the ADC captured samples. Then, we will use Octave and a custom script16 to plot that
data. In particular, I will execute this command:

> execute_test("adc", "Y:/applications/plc-cape-lab", 200000)

DC mean = 1296.78, AC mean = 895.42, AC Range = 2784.00, FFT max at 50000.00 Hz

16 For additional information about the Octave script see PfcCapeSoftwareFramework.pdf[1] or look at the source code
Design of a low-cost device for data transmission over power lines 123/181

ADC data (with Octave). RX_PGA1 = 1 V/V. RX_PGA2 = 4 V/V. 50 kHz. CENELEC-B
I have repeated the previous test and captured
2000 samples from ADCIN (1.23 VPP, saturated).
If we look at the Y-axis of the ADC capture plot,
we see that the top ADC value is about 2800
which coincides with the expected value:
▪ ADCIN max = 1.8 V (see the BBB datasheet)
▪ ADC max value (12-bits) = 212 = 4096
▪ ADC[1.23V] = 1.23*4096/1.8 = 2799
In the FFT plot at bottom, we see a peak at the
sample index 500. In digital frequency terms this
means 500/2000 = 0.25. And considering the
sampling rate of 200 ksps, this translates to a
frequency of 0.25*200k = 50 kHz.
ADC data. RX_PGA1 = 1 V/V. RX_PGA2 = 4 V/V. 50 kHz. CENELEC-B. Zoom to 50 samples

For this test I have configured the Octave script to

plot the samples in stem-format.
At sample level we can identify a periodicity of 4:
peaks are repeated every 4 samples. In digital
frequency terms this means 1/4 = 0.25.

To analyze the case of a typical non-saturated waveform I have reduced the gain of RX_PGA2 to 1V/V:

ADC data (with Octave). RX_PGA1 = 1 V/V. RX_PGA2 = 1 V/V. 50 kHz. CENELEC-B

In the corresponding oscilloscope test, we would

measure a RX_PGA2_OUT = 717 mVPP.
We can apply the conversion formula already
seen:
▪ ADC = ADCIN*4096/1.8
▪ ADC = RX_PGA2_OUT/2*4096/1.8
▪ ADC[717 mVPP] = 0.717/2*4096/1.8 = 817
samples-peak-to-peak
In the ADC capture plot we observe a peak-to-
peak range from 800 to 1600 (800 peak-to-peak),
and therefore it is close to the calculated result.

ADC data. RX_PGA1 = 1V/V. RX_PGA2 = 1V/V. 50 kHz. CENELEC-B. Zoom to 50 samples
By zooming we can see the details of the captured
sinusoid.
Note that the peak-to-peak values vary depending
on the interval chosen: we will have maximum
values when the capture triggering coincides with
the peak value of the analog signal.

This test ends this chapter. We can conclude that we have validated the proper operation of the RX chain.
124/181 Design of a low-cost device for data transmission over power lines

4.5 Arduino and Push-Pull amplifier

In previous sections we have been working with the SUPERVISOR unit, based on the PlcCape board. Now it
is time to analyze the behavior of the REPORTING device, based on the Arduino Leonardo platform and
using the Push-Pull amplifier to be able to source the required current:
Figure 77. Arduino to Push-Pull amplifier - Testing environment

Testing environment:

• The Arduino Leonardo board will generate a 110 kHz square wave through the pin 13
(ARDUINO_TX, blue wire), which is connected to the input of the Push-Pull amplifier BEFORE the
voltage divider to allow simple adjustments of the voltage level.

• To power the Push-Pull module we will use the 5V provided by the Arduino (which come from the
USB).

• An Arduino sketch is developed to send a Hi word in OOK once per second, with a 110 kHz carrier
(see 3.4.1 Simple transmitter with Arduino).

• Load Ro = 1 kΩ.

In this section we will measure:

CH1
It is the Arduino OOK signal from the pin 13
ARDUINO_TX_DIV Blue
(ARDUINO_TX) but AFTER the voltage divider block
Top

CH2
PUSH_PULL_OUT Red Output of the Push-Pull amplifier stage
Bottom
Design of a low-cost device for data transmission over power lines 125/181

4.5.1 Voltage divider

Objective: Check the effect of the voltage divider potentiometer in the Push-Pull output

We are going to analyze the output of the Push-Pull stage when operating the potentiometer of the voltage
divider. For the different potentiometer positions tested, the resistance has been measured with a multimeter.
In particular, for the 1 kΩ potentiometer that I used, I got a real measure around 860 Ω at the top of the scale
(due to tolerance, imperfections, wearing, etc).

Find following a first couple of graphs displaying the signal at the Arduino pin 13 (ARDUINO_TX, at top, in
blue) and a typical Push-Pull output (PUSH_PULL_OUT, at bottom, in red):

ARDUINO_TX and PUSH_PULL_OUT. 1ms/div ARDUINO_TX and PUSH_PULL_OUT. 20us/div

Here we can see:

• The Arduino generates a proper square wave of 110 kHz from 0 to 4.6 V.

• The PUSH_PULL_OUT spans over 2.1 VPP.

• The PUSH_PULL_OUT has an initial transient due to the DC offset removal.

Next, we check the effect of the potentiometer on the Arduino signal after the voltage divider
(ARDUINO_TX_DIV) and on the Push-Pull output (PUSH_PULL_OUT).

ARDUINO_TX_DIV (top) and PUSH_PULL_OUT (bottom). Potentiometer = 450 Ω. 1ms/div

The signal level after the voltage divider

(ARDUINO_TX_DIV) is 2.5 VPP.
The output level after the Push-Pull amplifier
(PUSH_PULL_OUT) is 2 VPP.
The red LED in the Push-Pull amplifier flashes
periodically once per second with a short pulse of
several milliseconds.
Note that this capture corresponds to the H
symbol (start bit + 0x48 ASCII code).
126/181 Design of a low-cost device for data transmission over power lines

ARDUINO_TX_DIV and PUSH_PULL_OUT. Potentiometer = 450 Ω (½ cycle). Zoom to 10us/div

By zooming we can confirm the carrier frequency

of 110 kHz and get a detail of the initial transient
(due to the DC component removal).

ARDUINO_TX_DIV and PUSH_PULL_OUT. Potentiometer = 60 Ω (close to the anti-clockwise limit)

In this test I have adjusted the potentiometer until

the LED stops flashing. I have then captured the
graph (at left) and measured the potentiometer
(≈ 60 Ω). For higher resistance values, the LED
still flashed, although very tenuously.
From the left figure, we can conclude that the
Push-Pull LED does not produce any light
when PUSH_PULL_OUT is below 1 VPP.
Note that the capture at left corresponds to the i
symbol (start bit + 0x69 ASCII code).

ARDUINO_TX_DIV and PUSH_PULL_OUT. Potentiometer = 860 Ω (clockwise limit)

At the top position of the potentiometer

(860 Ω) we get a Push-Pull output of 2.2 VPP.
The LED noticeably flashes every second for a
short while.

ARDUINO_TX_DIV and PUSH_PULL_OUT. Potentiometer = 860 Ω. Cr bypassed

In this final test I have replaced the Cr capacitor
by a short-circuit (see the Figure 52. Push-Pull
amplifier - Voltage divider).
The result is that the output at the voltage divider
(ARDUINO_TX_DIV) has a DC offset
component that takes longer to be removed from
PUSH_PULL_OUT by the other capacitors in the
Push-Pull stage.
Hence, the importance of this first capacitor, as
mentioned in the section 3.4.4.4 Voltage divider
and low-pass filter.
Design of a low-cost device for data transmission over power lines 127/181

4.5.2 Frequency response

Objective: Analyze the Push-Pull output for different frequencies

We are now going to examine the effects of the basic low pass filter in the Push-Pull amplifier (Cf capacitor
in the Figure 52. Push-Pull amplifier - Voltage divider).

For that purpose, I have adjusted the potentiometer to 860 Ω (for maximum output) and modified the
Arduino sketch to generate different carrier frequencies.

ARDUINO_TX_DIV (top) and PUSH_PULL_OUT (bottom). Carrier frequency 50 kHz

At 50 kHz we can still identify the square shape

of the original Arduino waveform because the
cut-off frequency of the low-pass filter allows for
some harmonics.
PUSH_PULL_OUT = 2.3 VPP.

Carrier frequency 110 kHz

At 110 kHz PUSH_PULL_OUT loses its

square wave appearance (coming closer to a
sinusoid) because the harmonics fall out of the
pass-band.
The amplitude of the signal is preserved
because the carrier frequency is still within the
pass-band.
PUSH_PULL_OUT = 2.3 VPP.

Carrier frequency 150 kHz

At 150 kHz we are in the attenuation region of

the low-pass filter. Hence, the decrease on the
amplitude:
PUSH_PULL_OUT = 2.1 VPP.
So, the Cf filter is a basic way to reduce the
unwanted harmonics of the square wave signal.
A future improvement would be using a higher
order filter for better selectivity.
128/181 Design of a low-cost device for data transmission over power lines

4.5.3 Load impedance

Objective: Analyze how the load impedance affects the Push-Pull output

To conclude this series of tests focused on the Push-Pull amplifier, we are going to analyze the effects of the
load impedance.

For that purpose, I have adjusted the potentiometer to 860 Ω and checked with different loads.

ARDUINO_TX_DIV (top) and PUSH_PULL_OUT (bottom). Ro = 10 kΩ

With a high impedance (Ro = 10 kΩ) the output

of the Push-Pull amplifier reaches its maximum
range, 2.4 VPP.
The LED flashes noticeably.

ARDUINO_TX_DIV and PUSH_PULL_OUT. Ro = 1 kΩ

With a medium impedance (Ro = 1 kΩ)

PUSH_PULL_OUT reaches 2.2 VPP, close to its
maximum value.
The LED flashes noticeably.

ARDUINO_TX_DIV and PUSH_PULL_OUT. Ro = 100 Ω

With a relatively low impedance (Ro = 100 Ω)
PUSH_PULL_OUT drops noticeably to
1.2 VPP.
In this configuration the LED flashes
tenuously.
I have repeated this test using an external power
supply of 5V 1A to check whether the reduction
of the voltage level was due to a limitation on the
deliverable current from the USB port. The
results obtained have been exactly the same. So,
the attenuation is due to the nature of our basic
Push-Pull amplifier.
Design of a low-cost device for data transmission over power lines 129/181

As a final test, I have used an 8 Ω speaker as a very low load impedance to test a scenario where the
deliverable current from the power supply becomes an important factor.
Figure 78. Arduino to Push-Pull amplifier -
Testing environment with a low impedance
The mini speaker has the following
attributes17:

• Impedance: 8 Ω

• Speaker diameter: 36 mm

• Response frequency: 20 Hz-2 kHz

• Max output power: 400 mW +

400 mW

The potentiometer will adjust the level of

the output and so, the volume of the
audible sound and the LED intensity.

I have also modified the sketch to generate an audible carrier frequency of 1.5 kHz and longer OOK pulses:

...
#define DELAY_BETWEEN_MESSAGES_MS 100
#define DELAY_BETWEEN_SYMBOLS_MS 100
#define SYMBOLS_LENGTH_MS 100
...

void setup()
{
// Code used to generate a 110kHz carrier
// configure_pwm13(clock_base_divider_one_half, 1, 110000);

// Code used to generate an audible 1.5 kHz carrier

// To test FastPWM in the audible band use the min frequency
// freq = 0 will set the minimum freq for a given config
// Example: (clock_base_divider_two, 6, 0) -> Min freq = 24MHz/256/64 = 1464.8 Hz
configure_pwm13(clock_base_divider_two, 6, 0);
}

To power the Arduino we have two alternatives:

• From an external power source, either through the 2.1 mm jack or the Vin pin. In fact, both
(connector and pin) share the same power rail. As a consequence, Vin can be used as Power Input or
Power Output depending on the needs.

• From a USB connection, limited to 500 mA. In this case, if we need to power other circuits from
the Arduino, we can use the pin identified as 5V, which comes from the USB power.

In the test, we properly get audible sound. By operating the potentiometer we adjust the volume. The
changes in loudness are mainly noticeable for Rr2 values < 200 Ω. For greater values it hardly changes.
Concerning the LED, it shuts down since Rr2 < 200 Ω (approx).

Find following the output we get (PUSH_PULL_OUT) for different scenarios: with the USB port (5V
500mA) versus an external power supply (5V 1A):

17 Interesting audio considerations can be found at https://en.wikipedia.org/wiki/Audio_power

130/181 Design of a low-cost device for data transmission over power lines

ARDUINO_TX_DIV (top) and PUSH_PULL_OUT (bottom). USB power. Ro = 1 kΩ

As a first test, we check the system with an

impedance of 1 kΩ.
At 500 ms/div we can see the list of long OOK
pulses (100ms per bit). Note that the y-axis scale
is set to 2 V/div.
We can identify the word Hi: the i has the widest
pulse (200ms) because two consecutive bits of
100ms each (i = 0x69 → start bit + 01101001)

ARDUINO_TX_DIV and PUSH_PULL_OUT. USB power. Ro = 1k. Zoom to 500 us/div

By zooming to 500us/div we can measure the

frequency of the carrier (~1.5 kHz) and see how
the square waveform is converted to a series of
spikes (due to the high-pass filtering of the
capacitors in the Push-Pull stage).
PUSH_PULL_OUT = 3 VPP.
The LED flashes vigorously.

ARDUINO_TX_DIV and PUSH_PULL_OUT. USB power. Ro = 8 Ω speaker

By replacing the 1 kΩ resistor by the 8 Ω speaker,

we can observe the attenuation at the output:
PUSH_PULL_OUT = 1.75 VPP.
In any case, this voltage level is enough to power
the speaker and clearly hear the beeps of the
OOK transmission.
The LED flashes during the transmission of each
bit but very tenuously.

ARDUINO_TX_DIV and PUSH_PULL_OUT. External power supply. Ro = 8 Ω speaker

If we switch the USB powering by an external

power supply of 5V 1A and feed the Push-Pull
amplifier through the Vin pin (instead of the 5V
pin) we observe that the output amplitude is
slightly higher:
PUSH_PULL_OUT = 2.2 VPP.
That means that the USB Port was not able to
supply all the current requested by the assembly
composed of Arduino, Push-Pull-amplifier and
speaker.
Design of a low-cost device for data transmission over power lines 131/181

4.6 Data communication over an unpowered line

In this chapter the target is to check that we are able to communicate real data between devices in the
particular case of a transmission line with no voltage (0 VAC).

4.6.1 BBB to BBB

Objective: Check that the software framework is able to encode and decode modulated data

Figure 79. PlcCape to PlcCape communication -

Testing environment Testing environment:

• PlcCape-v1 will generate the signal corresponding to

the word Hi (in different encoding schemes) and
transmit it through TX_F_OUT.

PlcCape-v1 is powered by an external power supply

(5V 1A) and remotely controlled through Ethernet.

• The Push-Pull amplifier is acting as a replacement of

the Power Amplifier block of the AFE031 (which is
damaged). Moreover, as this module will be present in
the communication over the 230VAC, it is worth
including it here.

• PlcCape-v2 will process the signal received from the

AC pins.

PlcCape-v2 is powered and remotely controlled

through the USB port.

Both PlcCape assemblies will be running the plc-cape-lab

application: one configured for transmission, the other
configured for reception.

We will test the transmission of data with three different

encoding schemes: OOK, PWM and Morse.
132/181 Design of a low-cost device for data transmission over power lines

4.6.1.1 OOK encoding

The configuration of plc-cape-lab at transmission (PlcCape-v1) for an OOK encoding ( encoder-ook.so)
with a 110 kHz carrier (profile tx_ook_110k) can be seen in the following screenshot:
Figure 80. PlcCape to PlcCape communication - plc-cape-lab at transmission

The configuration at reception (PlcCape-v2) is based on the rx_ook_110k profile:

Figure 81. PlcCape to PlcCape communication - plc-cape-lab at reception

In the Log area we can see the received words (many Hi) with no transmission errors. So plc-cape-lab
properly decodes a message sent in OOK.
Design of a low-cost device for data transmission over power lines 133/181

With the oscilloscope we can check the output at PlcCape-v1 (TX_F_OUT) and the output at the Push-Pull
amplifier (PUSH_PULL_OUT):

TX_F_OUT (top) & PUSH_PULL_OUT (bottom). TX_F_OUT & PUSH_PULL_OUT.

1 V/div. 1 ms/div 0.5 V/div. 10 us/div

In the capture at left, we can clearly identify the H symbol in the OOK encoding.

In the capture at right, we can see the smooth transient at the beginning of the carrier.

With plc-cape-lab we can store the ADC samples received and plot them with Octave:

ADC data (in Octave). 3000 samples

We can see that the level of the data captured by

the ADC is very low, from 1250 to 1360. That is
due to the attenuation of the forth-order filter in
the PlcCape and the attenuation of the internal
RX_PGA1 block (configured to RX_PGA1 =
0.25 V/V).
The good point is that, even in these hard
conditions, the system has been able to decode
the OOK signal.
In the FFT plot, we can observe how the ADC
detects a 90 kHz signal (instead of 110 kHz) due
to the 200 ksps sampling rate (undersampling
effect).

ADC data. Zoom to 100 samples

In a zoom to 100 samples it is difficult to

appreciate the sinusoid carrier because, when
close to the Nyquist frequency (100 kHz here),
we have very few samples per cycle.
134/181 Design of a low-cost device for data transmission over power lines

4.6.1.2 PWM encoding

If we repeat the same test with the PWM encoder ( encoder-pwm.so) using a granularity of 100 us per step,
we confirm that plc-cape-lab properly decodes a message sent in PWM. With the oscilloscope we get this:

TX_F_OUT (top) and PUSH_PULL_OUT (bottom). 1 V/div. 5 ms/div

In the capture we can clearly identify both PWM

symbols:
▪ H = ASCII 0x48 = 72
→ Symbol width = 72*100us = 7.2ms
▪ i = ASCII 0x69 = 105
→ Symbol width = 105*100us = 10.5ms

ADC data (in Octave). 6000 samples

Again, we observe a narrow range for the ADC

captures, from 1250 to 1360.
The 6000 samples of the captured graph can be
divided in three regions:
▪ Idle: 1000 samples at the beginning and
ending, with a value close to 1300
▪ Symbols: 1440 samples for the H and 2100
samples for the i. To convert samples to time
use the ADC sampling frequency:
1440/200 ksps = 7.2 ms
▪ Inter-symbol guard: 200 samples (= 1 ms)

4.6.1.3 Morse encoding

Finally, I have repeated the test using the Morse encoding ( encoder-morse.so) and the word HI (in
uppercase letters). The test confirms that plc-cape-lab properly decodes a message sent in Morse code.
With the oscilloscope we get this:

TX_F_OUT (top) and PUSH_PULL_OUT (bottom). ‘HI’ word in Morse. 1 V/div. 2 ms/div

In the oscilloscope capture we can clearly identify

the Morse beeps (dots):
▪ H = .... (4 dots)
▪ I = .. (2 dots)
Design of a low-cost device for data transmission over power lines 135/181

4.6.2 Arduino to BBB

Objective: Check that the software framework is able to decode the data sent by the Arduino

For the next experience, we replace the BBB by the Arduino board configured to transmit the Hi word in a
110 kHz OOK encoding through the pin 13. It is the configuration implemented in the section 3.4.1 Simple
transmitter with Arduino.
Figure 82. Arduino to PlcCape communication -
Testing environment

Testing environment:

• The Arduino Leonardo board sends the word Hi

in OOK through the pin 13.

• The pin 13 (ARDUINO_TX) is connected to the

input of the Push-Pull amplifier (blue wire).

• The output of the Push-Pull amplifier is

connected to the AC connector of the PlcCape-
v2 (green wires).

• With the oscilloscope we probe the signal

reaching the AC Connector of the PlcCape-v2
(which would correspond to the 230VAC line in
the final system). Note that here it corresponds
to PUSH_PULL_OUT.

The PlcCape-v2 is put in reception mode and the ADC

samples stored by the plc-cape-lab tool and plotted in
Octave.

plc-cape-lab is configured with the rx_ook_110k profile,

which specifies these gains in the PGAs at RX:

▪ RX_PGA1 = 0.25 V/V

▪ RX_PGA2 = 1 V/V
136/181 Design of a low-cost device for data transmission over power lines

With plc-cape-lab we observe that we properly receive the ‘Hi’ word (one ‘Hi’ per second):
Figure 83. Arduino to PlcCape communication - plc-cape-lab at reception

For each transmitted Hi, the LED in the Push-Pull amplifier flashes weakly.

With the oscilloscope we probe the input signal at the Push-Pull amplifier after the voltage divider
(PUSH_PULL_IN_DIV), and also the output of the module (PUSH_PULL_OUT):

PUSH_PULL_IN_DIV (top) and PUSH_PULL_IN_DIV (top) and

PUSH_PULL_OUT (bottom). 1 V/div. 1 ms/div PUSH_PULL_OUT (bottom). 1 V/div. 20 us/div

In the PUSH_PULL_OUT we can observe the effect of the low pass filter in the Push-Pull amplifier,
which converts the square wave generated by the Arduino to a smoothed version.

In contrast to the tests done with PlcCape-v1 being the transmitter, here we see a short initial and final
transient at each symbol due to the time required for the capacitors to remove the DC component:

• In the PlcCape-v1 case, the idle level matched the middle of the wave so that no additional biasing
was required for DC removal

• In the Arduino case, the idle level corresponds the low level of the wave (0 V). For effective DC
removal, a biasing is required per symbol
Design of a low-cost device for data transmission over power lines 137/181

Find following the Octave plot of 3000 captured samples:

ADC data. RX_PGA1 = 0.25 V/V. RX_PGA2 = 1 V/V. 3000 samples

As in the PlcCape-v1 case, the captured signal

covers a low ADC range, from 1250 to 1350.
In the FFT we can confirm the frequency of the
carrier: it is in the 90 kHz, which corresponds to the
undersampled version of the 110 kHz.

ADC data. RX_PGA1 = 0.25 V/V. RX_PGA2 = 1 V/V. Zoom to 100 samples

A zoom to the beginning of the symbol shows the

initial transient: there is an initial peak that reaches
an ADC value of 1400.

ADC data. RX_PGA1 = 1 V/V. RX_PGA2 = 1 V/V. 3000 samples

By increasing the gain of RX_PGA1 4 times, we

get a wider ADC range, from 1100 to 1500.
Note that the noise due to the quantification process
(analog to digital with 12-bits) has less importance
here:
▪ we can see the idle level at 1300 cleaner than in
the previous case
▪ the FFT is also cleaner

ADC data. RX_PGA1 = 1 V/V. RX_PGA2 = 1 V/V. Zoom to 100 samples

In a zoom to 100 samples we can confirm the wider

ADC range covered.
138/181 Design of a low-cost device for data transmission over power lines

4.7 Analysis of the 230VAC mains

The target of this section is to analyze the 230VAC domestic power line (which will be the transmission line
in our communication tests) to have a qualitative idea of the background noise and to check for the presence
of other possible interfering signals.

4.7.1 AC coupling module validation

Objective: Check the proper operation of the AC coupling module and have a quick look at the
noise in the mains

Figure 84. AC coupling module - Testing environment

In this first experiment we are going to measure with

the oscilloscope the background noise or the presence
of other interfering signals in the 230VAC. For that
purpose we are going to use the AC coupling module,
which can be used in both senses, either to couple a
signal to be transmitted over the 230VAC or to
decouple it from the power line.

I am going to use the environment shown at the right.

With the oscilloscope will measure the TXRX

decoupled signal after the transformer of the AC
coupling module. See the chapter 3.3.6.7 AC coupling
auxiliary module for more info.

TXRX. 200 mV/div. 4 ms/div

A first oscilloscope capture of the

decoupled TXRX shows a periodic
noise each 2.5 divisions = 10 ms. This
corresponds to a frequency of 100 Hz.

As the 230VAC line delivers energy at

50 Hz, it means that we have some
impulsive noise every half cycle.

The noise seems to span over 2

divisions in average = 400 mVPP, with
an initial short peak taking about 5
divisions = 1 VPP.
Design of a low-cost device for data transmission over power lines 139/181

TXRX. 200 mV/div. Zoom to 400 us/div

If we zoom to a half cycle, we can appreciate

what it seems a carrier frequency.

TXRX. 200 mV/div. Zoom to 40 us/div

A bigger zoom confirms the presence of the

carrier.
If we measure the time from peak-to-peak, it
gives a carrier of about 65 kHz with an
amplitude of about 400 mVPP.
There is also an initial transient of about
1.2 VPP.

FFT of TXRX

With the oscilloscope we can get the FFT of

the signal for more accurate information.
The analysis in the frequency domain reveals
a peak at 64.9 kHz.
Given this scenario we can conclude that, if
we want to use a detection-by-level method to
check for the presence of our carrier, we will
need to use a signal level over the 1.2VPP to
avoid false detections. If computationally
possible, we should use a carrier detection
method based on frequency analysis instead
(our 110 kHz carrier can coexist with 65 kHz
noise in a non-interfering way).
140/181 Design of a low-cost device for data transmission over power lines

4.7.2 AC to PlcCape
Objective: Analyze the impact of the connected appliances into the 230VAC line

Figure 85. AC to PlcCape - Testing environment

I am going to repeat the previous chapter experience but

replacing the oscilloscope by PlcCape-v2 to analyze the
decoupled signal captured by the ADC of the BBB.

We will use the plc-cape-lab application to store some

samples, and Octave to analyze them.

The testing environment is composed of the PlcCape-v2

connected to the mains and operated remotely through a USB
connection.

This is the data captured for two different RX_PGA2 gains:

ADC data. RX_PGA1 = 0.25 V/V. 10000 samples ADC data. RX_PGA1 = 1 V/V. 2000 samples

Like in the oscilloscope case, we can appreciate here the noise bursts at 100 Hz.

In the FFTs we can clearly identify the frequency of the carrier, now around 58 kHz (remember that our ADC
is configured with a sampling rate of 200 ksps which directly translates to a 200 kHz width for the Digital
Frequency axis).

For the test in the previous chapter, I run the USB oscilloscope from a different PC. As the frequency of the
noise has changed now (from 65 kHz to 58 kHz), this could mean that the power supply of the PC could be
the responsible of that noise.
Design of a low-cost device for data transmission over power lines 141/181

To confirm if the periodic noise comes from the PC or not, I run the BBB + PlcCape-v2 from an isolated
laptop powered by the internal battery:
Figure 86. AC to PlcCape - Testing environment with a laptop

With this environment and running the plc-cape-oscilloscope application through a ssh -X session (with
RX_PGA1 = 1 V/V and RX_PGA2 = 1 V/V), we can see how the level of the periodic noise decreases when
switching OFF the desktop-PC (which is running on a contiguous room):

ADC data in 230VAC mains with desktop-PC ON ADC data in 230VAC mains with desktop-PC OFF

Therefore, we can conclude that the switched-mode power supply of the desktop-PC introduces a
considerable amount of noise into the AC mains.
142/181 Design of a low-cost device for data transmission over power lines

ADC data. PC ON. Bedroom. RX_PGA1 = 0.25 V/V. RX_PGA2 = 4 V/V. Y-Range ±50

In the previous test we had the desktop-PC in the

study-room and the laptop + PlcCape-v2 in the
bedroom, a contiguous room.
I have turned ON again the desktop-PC and
repeated the test several times.
Sometimes I have found, besides the PC generated
noise, another source of noise with a higher level
(compare the left figure with the previous one).

ADC data. PC ON. Bedroom. RX_PGA1 = 0.25 V/V. RX_PGA2 = 4 V/V. Y-Range ±200

By zooming out we can see the magnitude of the

pulse, of about 400 peak-to-peak in ADC-units
(Viewer ±200).
The peaks are again spaced 10 ms. So, they have
also a triggering frequency of 100 Hz.

ADC data. PC ON. Bedroom. RX_PGA1 = 0.25 V/V. RX_PGA2 = 4 V/V. Zoom to desktop-PC noise

If we zoom to the “low-level” noise (viewer ±58),

we get the already discussed desktop-PC noise.
The FFT reveals the peak at 58.9 kHz.

ADC data. PC ON. Bedroom. RX_PGA1 = 0.25 V/V. RX_PGA2 = 4 V/V. Zoom to high-level pulse
If we zoom to the “high-level” pulse (viewer ±200)
and do the FFT, we can see that in this case the
frequency representation of the noise is different: it
is present at lower frequencies and spans over a
wider bandwidth.
This noise will probably come from a different
connected appliance.
The important fact here is that our 230VAC is very
noisy. In these conditions, if we use simple
decoding methods based on just the presence of a
carrier, we will have frequent errors when these hi-
level pulses occur. For a robust implementation we
should use more complex strategies, as coherent
demodulation using the predefined carrier
frequency.
Design of a low-cost device for data transmission over power lines 143/181

ADC data. PC ON. Kitchen. RX_PGA1 = 0.25 V/V. RX_PGA2 = 4 V/V. Y-Range ±50
I have repeated the previous test but now plugging
the PlcCape-v2 to an outlet in the kitchen, which
involves a longer distance to the desktop-PC room.
By comparing this graph with the dual one in the
previous page (Y-Range ±50), we can see here how
the PC noise is highly attenuated (because the
distance).
However, we can still appreciate the other low-
frequency noise.
ADC data. PC ON. Kitchen. RX_PGA1 = 0.25 V/V. RX_PGA2 = 4 V/V. Y-Range ±500

By repeating the test several times, I have been able

to capture high-level noise pulses with even more
power than in the bedroom case (notice the
Y-Range ±500 here).

ADC data. PC ON. Kitchen. RX_PGA1 = 0.25 V/V. RX_PGA2 = 4 V/V. Zoom to low-level pulse

In a zoom to the low-level noise region we observe

that the noise from the desktop-PC is still present in
the kitchen but hugely attenuated (a low level peak
at 58 kHz).

ADC data. PC ON. Kitchen. RX_PGA1 = 0.25 V/V. RX_PGA2 = 4 V/V. Zoom to high-level pulse
On the other hand, a zoom to the high-level pulse
reveals that the low-frequency noise has, in the
kitchen, a higher voltage level than in the bedroom.
This would indicate that the source of the low-
frequency noise is close to the kitchen.
The important fact here is that, even in the same
domestic line, we can have different noise
scenarios depending on the location of the
transmitter and the receiver.
144/181 Design of a low-cost device for data transmission over power lines

4.8 Data communication through the 230VAC line

Objective: Analyze the communication of data between the Arduino assembly and the PlcCape
through the mains in different configurations

Now that we have analyzed how the transmitter and the receiver work, and done a basic analysis on the
230VAC line, the next step is to effectively communicate some data between the low-cost device (Arduino-
based) and the central unit (BBB-based).

At the transmitter side (the REPORTING device) I have used the following assembly, composed of the
Arduino Leonardo + the Push-Pull amplifier + the AC Coupling module:
Figure 87. 230VAC communication - The REPORTING device at transmission

In the AC Coupling module, in JP1 I have placed a customized jumper which shortcuts the three pins of the
connector. This simplifies the link with the PUSH_PULL_OUT through the X4 connector in the top side of
the board (see 3.3.6.7 AC coupling auxiliary module)

At the receiver side (the SUPERVISOR unit), I have used the assembly composed of the BBB + the
PlcCape-v2. It will be connected to the mains, as we have already seen in the previous chapter:
Figure 88. 230VAC communication -
The SUPERVISOR unit at reception

First, we check that the system works in the simplest way, through a direct isolated connection with a couple
of wires from the transmitter to the receiver, with no 230VAC involved yet.

In all the tests the Arduino board generates an OOK signal sending Hi at every second, using a 110 kHz
carrier (as seen in 3.4.1 Simple transmitter with Arduino).
Design of a low-cost device for data transmission over power lines 145/181

In this configuration, if we analyze the AC pins with the oscilloscope, we get:

AC pins. Isolated direct connection. 1 ms/div AC pins. Isolated direct connection. 20 us/div

We can identify the OOK signal corresponding to the transmission of the H symbol.

This is the only measurement I have done with the oscilloscope in this chapter. Remaining graphs correspond
to the captured data by the ADC of the BBB, recorded either by the plc-cape-oscilloscope tool or the plc-
cape-lab application + Octave.

In all the test the AFE031 is configured to work in the CENELEC-B band.

So, I have repeated the previous test (direct wire with no 230VAC present) and captured the data with the
plc-cape-lab application.

ADC data. Isolated direct connection (230VAC OFF). RX_PGA1 = 1 V/V. RX_PGA2 = 1 V/V
In this basic scenario with RX_PGAs configured
for unitary gain, the ADC captured samples span
from 1150 to 1450.
In the FFT plot we can see that the ADC
interprets the 110 kHz carrier as 90 kHz because
the undersampling effect (as already seen in
4.6.1.1 OOK encoding).
If we take a look at the Push-Pull monitoring
LED, we can observe an important fact. In the
interconnected system, the LED flashes tenuously
per word transmitted. However, if we disconnect
the PlcCape-v2, then it flashes energetically.
This is due to the input impedance of the PlcCape
board: at 110 kHz it would be around 150 Ω
which cuts down the output voltage of the Push-
Pull amplifier in a significant way (as seen in
4.5.3 Load impedance).

The next step is to inject the 230VAC into the direct connection. We can safely do that because both, the
transmitter and the receiver, have a coupling transformer.
146/181 Design of a low-cost device for data transmission over power lines

So, if we supply 230VAC to the direct connection and repeat the capture with plc-cape-lab, we get this:

ADC data. 230VAC ON. RX_PGA1 = 1V/V. RX_PGA2 = 1V/V

We can see that the results are more or less the

same. There is some attenuation because the
impedance introduced by the 230VAC line (due
to the connected appliances).
In this configuration the Push-Pull monitoring
LED flashes tenuously during the transmission of
each word (once per second). If I disconnect the
PlcCape from the TX-RX loop (like we did in the
previous unpowered scenario), the LED still
flashes tenuously. That is because we have
removed the input impedance introduced by the
PlcCape, but not the one from the connected
appliances.

Therefore, this experiment confirms that the main behavior of the system is correct.

Now we need to cover more realistic scenarios, testing the communication between separated plugs, and
looking at the effects of the longer transmission lines and the noise. For that matter, I am going to use the
plc-cape-oscilloscope tool at the receiver side.

Find following a couple of photos of the testing environment at both sides of the communication channel:
Figure 89. 230VAC communication - Figure 90. 230VAC communication -
Transmitter configuration Receiver configuration

In this series of tests, the refrigerator and the water heater were always ON. Therefore, they are possible
sources of noise.
Design of a low-cost device for data transmission over power lines 147/181

By default, unless otherwise specified, the PGA gains are configured to RX_PGA1 = 0.25 V/V and
RX_PGA2 = 4 V/V.

For all the tests in this chapter, I have set the base location of the transmitter assembly in the study room,
where the desktop-PC is located.

RECEIVER IN THE STUDY ROOM

For the first series of tests (in the study room), I have placed the receiver and the transmitter in the same
outlet, through a hub. The desktop-PC is ON.

ADC data. BBB isolated (AC pins unconnected). RX_PGA1 = 0.25 V/V

In this first test I have just checked the ADC

captured data by the PlcCape when it is not
connected to the mains (i.e. floating).
Obviously there is no captured signal, just some
unavoidable noise. As displayed in the Viewer
annotation, the middle level of the ADC captured
samples is 1303.

ADC data. BBB connected to mains (AC pins to 230VAC). No TX. RX_PGA1 = 0.25 V/V

By connecting the BBB to the mains, we can notice

periodic pulses of 50 peak-to-peak (in ADC units)
and spaced 10 ms in time (see the Grid annotation).
This is mainly the noise introduced by the desktop-
PC (already discussed in 4.7.2 AC to PlcCape).

ADC data. BBB connected to mains. RX_PGA1 = 0.25 V/V. FFT

The FFT of the noise reveals the switching

frequency of the power supply of the desktop-PC,
at 58.9 kHz.

ADC data. BBB connected to mains. TX ON, in the same outlet hub. RX_PGA1 = 0.25 V/V

Here I have turned ON the Arduino assembly

located in the same 230VAC hub.
In the ADC captured data, we can clearly identify
the OOK transmitted signal. Note the viewer range
±200. The OOK signal has a much higher level than
the desktop-PC noise and so, can be easily decoded
using a simple level-detection mechanism.
148/181 Design of a low-cost device for data transmission over power lines

ADC data. BBB connected to mains. TX ON, in the same hub. RX_PGA1 = 0.25 V/V. Zoom to 500 us

If we zoom to the beginning of an OOK symbol

(using the bars representation of plc-cape-
oscilloscope), we get a detailed view of the small
transient involved in the removal of the DC
component (already seen in 4.6.2 Arduino to BBB).

ADC data. BBB connected to mains. TX ON, in the same hub. RX_PGA1 = 0.25 V/V. FFT

The FFT reveals a peak at 90.4 kHz. In theory it

should be 90kHz (dual of 110 kHz when sampling
at 200 ksps) but our Arduino PWM sketch
generates a frequency close to 110kHz but not
exactly that.

RECEIVER IN THE BEDROOM

In this section I have changed the location of the PlcCape receiver for a more practical test: the
communication between the outlets of two different rooms. In particular, I have put the receiver in an outlet
of the bedroom, which is contiguous to the study room.

ADC data. Desktop-PC ON. RX_PGA1 = 0.25 V/V. Viewer [10 ms; ±200]

By comparing with the previous test (outlets in a

hub), we can notice here a significant drop in the
level of the data captured (I have preserved the
Viewer range to ±200 samples for easier
comparisons).
Therefore, the distance between outlets has a big
impact on the attenuation.

ADC data. Desktop-PC ON. RX_PGA1 = 0.25 V/V. Viewer [500 us; ±50]

A zoom reveals that the level of the samples

received has been reduced from 200 peak-to-peak
to 50 peak-to-peak, a factor of ¼.
Design of a low-cost device for data transmission over power lines 149/181

ADC data. Desktop-PC ON. RX_PGA1 = 0.25 V/V. Viewer [20 ms; ±50]

The zoomed view (Viewer ±50) reveals that we can

still use the level-detection mechanism to decode
the carrier but that we are close to the limit because
the noise injected by the desktop-PC has a
comparable level.
From this test, we can conclude that the carrier-
detection-by-level method is not a good strategy
to decode data from the 230VAC mains.

ADC data. Desktop-PC OFF. RX_PGA1 = 0.25 V/V. Viewer [20 ms; ±100]
If we switch OFF the PC, we observe two effects:
▪ The impulsive noise at 100 Hz is considerably
lower.
▪ The signal received doubles (notice the Viewer
±100). That is because the impedance in the AC
line increases when the PC disconnects, and due
to the load-effect of our Push-Pull amplifier this
means a boost in the output voltage.
ADC data. Desktop-PC OFF. RX_PGA1 = 0.25 V/V. Viewer [2 ms; ±100]

In the third OOK symbol of the previous figure we

can see a strange effect: an attenuation in part of it.
We can zoom to it to have a clearer view.
Considering the known impact of the impedance in
the voltage level, we can deduce that this notch in
the OOK symbol would probably be due to an
instantaneous peak in 230VAC consumption from
some appliance (which means an impedance drop).

ADC data. Desktop-PC OFF. RX_PGA1 = 1 V/V. Viewer [20 ms; ±400]

Here I have scaled RX_PGA1 from 0.25 V/V to

1 V/V (a x4 magnification). We can see how ADC
samples span now over more than 400 ADC units.
We can also realize that the second OOK symbol
has been affected by an instantaneous impedance
drop. This test reveals that our basic Push-Pull
amplifier needs to be improved for no load-
dependency to be usable in the 230VAC mains.

ADC data. Desktop-PC OFF. Power supply from battery. RX_PGA1 = 1 V/V. Viewer [20 ms; ±300]

I have replaced the 5V 1A external supply of the

Arduino transmitter by an external battery, like in
Figure 46, to check that we can use it on our tests.
We have the same voltage levels (note the Viewer
scale ±300) and the same effects (voltage drop in
the second OOK symbol because a lower
instantaneous impedance). See 4.5.3 Load
impedance for additional info.
150/181 Design of a low-cost device for data transmission over power lines

ADC data. Desktop-PC OFF. TX OFF. RX_PGA1 = 1 V/V. Viewer [20 ms; ±300]

If we disconnect the Arduino transmitter, we can

have a look at the background noise.

ADC data. 230VAC switch OFF. TX OFF. RX_PGA1 = 1 V/V. Viewer [20 ms; ±300]

Here I have turned off the master mains switch,

breaking the connection between the electrical
network at home and the 230VAC external
network. Therefore, the network at home has
become a mesh of unpowered wires.
In this configuration the background noise is much
lower and uniform, without the peaks due to the
appliances.

ADC data. 230VAC OFF. TX ON from battery. RX_PGA1 = 1 V/V. Viewer [20 ms; ±300]

I have then connected the Arduino transmitter

(powered by the battery).
The OOK signal captured is now very clean:
▪ There is no noise coming from the appliances.
▪ There are no voltage drops due to changes in the
instantaneous impedance.

ADC data. 230VAC OFF. TX ON from battery. RX_PGA1 = 1 V/V. FFT

With the FFT we can corroborate the clearness of

the OOK signal at 90 kHz (110 kHz indeed).

ADC data. 230VAC OFF. TX ON from battery. RX_PGA1 = 1 V/V. Viewer [2 ms; ±300]

Zooming to 2 ms (and representing the captured

samples with bars), we can also realize the
homogeneity of one OOK captured symbol.
Design of a low-cost device for data transmission over power lines 151/181

RECEIVER IN THE LIVING ROOM

ADC data. 230VAC OFF. TX ON from battery. RX_PGA1 = 1 V/V. Viewer [20 ms; ±300]

If in the 230VAC OFF scenario, we move the

receiver from the bedroom to the living room,
which is farther, we observe a higher attenuation in
the OOK received signal, from the 500 peak-to-
peak of the previous test (approximately) to a more
modest range of 300 peak-to-peak.

ADC data. 230VAC OFF. TX ON from battery. RX_PGA1 = 1 V/V. Viewer [2 ms; ±300]

In a zoom to 2 ms we can get a more accurate view

of the voltage attenuation. By comparing with the
corresponding graph in the bedroom case, we could
calculate the exact attenuation factor.

ADC data. 230VAC OFF. TX ON from battery. RX_PGA1 = 1 V/V. Viewer [1 ms; ±300]

If we zoom to the beginning of the OOK symbol,

we can appreciate the higher level of some samples
during the initial transient corresponding to the DC
removal.

ADC data. 230VAC OFF. TX ON from battery. RX_PGA1 = 1 V/V. Viewer [1 ms; ±300]

If we zoom to the ending of the OOK symbol, we

can appreciate a little oscillation due to the final
transient corresponding to the delivering of the DC
stored energy.
152/181 Design of a low-cost device for data transmission over power lines

RECEIVER IN THE KITCHEN

ADC data. 230VAC OFF. TX ON from battery. RX_PGA1 = 1 V/V. Viewer [20 ms; ±300]

The kitchen is the farthest room from the study

room (where the Arduino transmitter is connected).
As already discussed, this increased distance means
extra attenuation.
Anyway, as we can still identify the OOK pulses
we should be able to decode the signal.

ADC data. 230VAC OFF. TX ON from battery. RX_PGA1 = 1 V/V. Viewer [1 ms; ±100]

A zoom to 1ms gives a more accurate view of the

received signal, which spans over ~100 peak-to-
peak (compared to the 300 peak-to-peak got when
the receiver was placed in the living room).

To check if we are able to recover the original message (periodic Hi words) I have stopped the plc-cape-
oscilloscope application and started the plc-cape-lab. I have configured it with RX_PGA1 = 1 V/V,
RX_PGA2 = 4 V/V and manually adjusted the threshold for the carrier detection.
In these conditions I have successfully recovered the original message without errors, as shown in the
following capture of the laptop screen:
Figure 91. 230VAC communication - plc-cape-lab capture from the laptop
Design of a low-cost device for data transmission over power lines 153/181

ADC data. 230VAC ON. TX OFF. RX_PGA1 = 1 V/V. Viewer [20 ms; ±200]
Here, I have disconnected the Arduino transmitter
and turned ON again the 230VAC main switch.
The high levels of sporadic noise reappears.
If we compare the level of that noise with the level
of the received signal in the previous test, we will
see that it will completely mask the OOK carrier
(note the scale of the viewer here set to ±200).
In fact, in these conditions I have not been able to
recover the original signal using the plc-cape-lab
application and the carrier-detection-by-level
method.
ADC data. 230VAC ON. TX OFF. RX_PGA1 = 1 V/V. FFT

The FFT of the above captured noise reveals a low

frequency peak that could come from some
connected appliance (maybe the refrigerator) or
from the 230VAC network outside.

ADC data. 230VAC ON. TX OFF. RX_PGA1 = 1 V/V. Viewer [20 ms; ±200]

By repeating the test, we get similar noise (in

frequency terms) but with lower power, confirming
the impedance variability of the 230VAC line.

ADC data. 230VAC ON. TX OFF. RX_PGA1 = 1 V/V. Viewer [20 ms; ±200]

This is another capture at a different time with even

a lower noise level.
So, the level of the noise varies depending on the
instantaneous consumption of the connected
appliances.

The most important conclusions we can take from the experiences done in this section are:

• The connected appliances introduce a significant level of noise on frequencies in the kHz range

• The instantaneous impedance in the transmission line is not regular. The power supplies of the
connected appliances have consumption peaks that involve sudden impedance drops which
translate to huge voltage notches in our transmitted data
154/181 Design of a low-cost device for data transmission over power lines

4.9 Final system integration

Objective: Check that the SUPERVISOR unit is able to properly receive the data sent by the
REPORTING device from a different outlet in the 230VAC mains

This chapter is going to summarize, in a final practical scenario, most of the experiences covered in previous
chapters.

On the TX side we arrange the temperature sensing and REPORTING device (Arduino Leonardo +
Temperature sensing Shield + Push-Pull amplifier). We do first a test without the AC coupling module:
Figure 92. Final system - Push-Pull output probing

With the oscilloscope we probe the output of the Push-Pull amplifier which will be emitting a periodic OOK
message with the temperature. Note that there is a Ro = 1 kΩ just to simulate a medium impedance load:

PUSH_PULL_OUT. OOK message. 20 ms/div PUSH_PULL_OUT. Carrier details. 20 us/div

In the current configuration the Push-Pull amplifier reduces the input voltage from 5 V PP to 2.3 VPP and
softens the original square wave towards a sinusoidal waveform.

The message transmitted by the Arduino is a counter followed by a colon and the temperature, all in ASCII
chars (as described in 3.4.3 Sensing and transmitting device with Arduino).
Design of a low-cost device for data transmission over power lines 155/181

Now, we set up the final TX-to-RX testing environment:

Figure 93. Final system at TX - The REPORTING device Figure 94. Final system at RX - The SUPERVISOR unit

On the TX side, I have added the AC coupling module. Notice the JP1 triple-jumper in order to comfortably
connect the PUSH_PULL_OUT using the X4 connector (see 3.3.6.7 AC coupling auxiliary module).

On the RX side, I have arranged the testing environment that I have already used in previous chapters, based
on an isolated laptop running on batteries. The SUPERVISOR unit (BBB + PlcCape-v2) is controlled
through a SSH session via USB.

The battery-powering mode at RX has to targets:

• Do not introduce extra noise from a switched mode power supply

• Allow some tests with the 230VAC mains switched off

I have connected the temperature REPORTER device (TX) in the room where the desktop-PC is located
(study-room) and the SUPERVISOR unit (RX) in the outlet of a contiguous room in order to test the
communication in low-attenuation conditions.

I have done three tests:

• Normal conditions: The ARDUINO_TX input signal traverses the whole Push-Pull amplifier
(Figure 93).

• Voltage boost: The ARDUINO_TX input signal is injected into the Push-Pull amplifier skipping the
voltage divider and thus resulting in a higher voltage output.

• 230VAC OFF: I have switched off the main 230VAC breaker so that the communication is carried
out through an unpowered line.

For each test I have enclosed:

• the ADC samples captured by the plc-cape-oscilloscope tool running on the laptop

• the data interpreted by the plc-cape-lab application configured for OOK symbol decoding (with a
width of 1 ms) using the simplest method, the carrier-detection-by-level. For each test I have
manually adjusted the RX threshold to detect the OOK carrier and ignore the background noise
156/181 Design of a low-cost device for data transmission over power lines

COMMUNICATION BETWEEN CLOSE OUTLETS

In normal conditions these are the ADC samples captured by the plc-cape-oscilloscope tool:
Figure 95. Final system - ADC data captured from the 230VAC

In the above graph (captured with RX_PGA1 = 1 V/V and RX_PGA2 = 4 V/V) we can guess some main
challenges we are going to face at decoding the OOK message, due to the following issues:

• There are high level noise bursts due to the power supplies of the appliances connected (e.g. see the
interval from 10 ms to 12 ms in the above figure).

• We are receiving a low level signal due to the line attenuation. The ADC data spans over 600
peak-to-peak ADC units, even with the x4 gain in RX_PGA2.

Despite these conditions, I have been able to receive some data with the plc-cape-lab application, which I
have configured with RX_PGA1 = 2 V/V and RX_PGA2 = 4 V/V:
Figure 96. Final system - Demodulated data from 230VAC

In the Log panel we can identify the format of the reported counter and temperature (e.g. 1252: 20.06 ºC) but
we also see many errors in the form of dots (‘.’), which in plc-cape-lab are used to indicate an OOK
detection out of the ASCII range (32 to 128). Such errors will probably be due to a wrong interpretation of
the background noise in the carrier-detection-by-level method. A more complex coherent-frequency-based-
detection would avoid them.

Conclusion: we are able to communicate data between two 230VAC close outlets, but with errors.
Design of a low-cost device for data transmission over power lines 157/181

COMMUNICATION BETWEEN CLOSE OUTLETS WITH A VOLTAGE BOOST

In this test I have injected more voltage into the 230VAC line just by skipping the voltage divider of the
Push-Pull amplifier (which introduces some extra attenuation). In plc-cape-oscilloscope I have used the same
PGA gains as in the previous test (RX_PGA1 = 1 V/V and RX_PGA2 = 4 V/V):
Figure 97. Final system - ADC data captured from the 230VAC
(voltage divider at TX skipped)

We can see the improvement on the voltage level: now the OOK carrier spans over 1200 ADC units,
compared to the 600 ADC units of the previous case (notice the double value of grid divisions).

In this case the main problem is not the noise but another challenging issue:

• There are sporadic significant voltage drops in the OOK signal due to instantaneous changes in
the line impedance. In the above graph we can identify two occurrences of this issue, in the first and
third OOK pulses, which are partially good, partially attenuated.

Find following a screen capture of the plc-cape-lab application configured with RX_PGA1 = 1 V/V (AFE
rx1:2) and RX_PGA2 = 4 V/V (AFE rx2:1):
Figure 98. Final system - Demodulated data from the 230VAC (voltage divider at TX skipped)

Now, with a higher threshold for the carrier detection, we have fewer errors (fewer dots).

Note that the initial temperature is 23.56 ºC and the final one is 20.56 ºC. That is because I forced a rise by
putting a finger in the sensor, to check that the device was properly sending the real current temperature.
158/181 Design of a low-cost device for data transmission over power lines

COMMUNICATION BETWEEN DISTANT OUTLETS WITH 230VAC OFF

As a final test, I have turned OFF the 230VAC by switching OFF the main breaker of the electrical network
at home. This way, we eliminate the noise and the impedance drops due to the power supplies of the
connected appliances. For this test we need the REPORTER device to be self-powered. I have used the
PowerBank already employed in Figure 46. Arduino shield - Test.

In these conditions, we perfectly receive the transmitted data, even using low PGA gains. For instance, in the
figure below the PGAs were configured with RX_PGA1 = 0.25 V/V and RX_PGA2 = 1 V/V:
Figure 99. Final system - ADC data captured from unpowered mains

Here we are neither facing voltage drops nor background noise. The captured signal spans only for 80 ADC
units due to the low PGA gains (0.25 V/V in total). Note that in previous tests we used a total gain of 4 V/V,
16 times higher.

This is the capture of plc-cape-lab configured with RX_PGA1 = 0.25 V/V and RX_PGA2 = 1 V/V:
Figure 100. Final system - Demodulated data from the mains when unpowered

The message transmitted by the Arduino assembly is perfectly received, with no errors.

The tests carried out in this chapter demonstrate that the whole system is working and viable but it
requires important improvements, mainly in the Push-Pull module (to avoid the dependency with the
instantaneous line impedance) and in the detection software (which should implement a more robust
decoding strategy).
Design of a low-cost device for data transmission over power lines 159/181

5 Conclusions
5.1 Feasibility
This project can be considered an introductory step to PLC technology.

I have been able to transmit data between two 230VAC outlets in different rooms using affordable electronics
(4.9 Final system integration).

For that purpose, I have proposed this system and deeply analyzed each component:
Figure 101. System proposal

However, the communication performed has not been reliable enough to consider it a suitable system.

In the positive side, the reliability problems have been clearly identified and alternatives have been proposed.

Two main tests confirm the feasibility of the solution:

• On the one hand, we have achieved a reliable communication at home between two distant outlets
after having switched off the 230VAC (through the main circuit breaker). With this test we have
confirmed that our system is suitable for data transmission over medium distances and is able to deal
with the attenuation in the line.

• On the other hand, with the 230VAC present, we have also achieved an acceptable communication
between two outlets close enough. Therefore, the system is able to properly couple and decouple the
data to and from the electrical network.

In the analysis phase, many tests have been carried out and results deeply analyzed. They constitute a helpful
guide for the design of a more robust future system (4 Analysis & results).

In this project I have also developed software tools to simplify the analysis phase (3.5.7 Applications). I have
also provided some plugins (3.5.8 Plugins) to demonstrate the ability of the framework to use different
encoding algorithms in the communication (4.6 Data communication over an unpowered line).

Concerning reusability, I have included some examples and guidelines of how to use the developed tools for
other applications than just PLC (5.2 Reusability).

The usage of Linux (and Debian) as the backbone of the software framework has been proven to be a key
point of this project. The extensive functionality provided this operating system will be indispensable when
designing a complete solution where the BBB will act as an Internet-ready central server able to send and
receive data from several low-cost devices attached to the electrical network.

Summarizing, the proposed system is feasible and versatile but needs to be improved in reliability and
robustness. The weaknesses have been identified and point the way to follow in future versions.
160/181 Design of a low-cost device for data transmission over power lines

5.2 Reusability
The experiments done in this project prove that the system proposed may be used for other purposes beyond
the communication over power lines.

Find following some other possible usages:

• The assembly composed of a BeagleBone Black and a PlcCape can be used to play sound (as seen
in 3.5.8.1 encoder-wav or in 4.5.3 Load impedance).

• Similarly, we can use the current software as a microphone recorder taking advantage of the ADC
of the BBB, which is able to capture signals up to 100 kHz, far below the typical high-fidelity audio
range.

• The load-dependency-effect of the Push-Pull amplifier (an important pitfall in this project) can be
profitable. It might be used as a rough instantaneous impedance meter of all the appliances
connected to the mains. We can inject a carrier of a predefined level and analyze with the FFT the
attenuation experienced, which is proportional to the impedance.

• The whole system can be used to measure the attenuation between two points in the electrical
network (or any other transmission line) for a given frequency. The idea is to inject a predefined
waveform on one point and measure the level received at a different location.

The software developed for this project is also reusable:

• The mini-oscilloscope application that shows in real time the captures from the ADC of the BBB
(3.5.7.1 plc-cape-oscilloscope) is a tool that can be used even with no PlcCape attached (therefore,
usable out of the PLC scope). It can be used to monitor real time data at frequencies up to
100 kHz (sensors, microphones, etc.).

• The frequency-response analyzer (3.5.7.2 plc-cape-freq-response) can be used to get the behavior in
frequency of any system, not only for PLC related ones. As an improvement, we should provide an
access point in the PlcCape board to allow direct access to the ADC of the BBB and avoid passing
through the CENELEC filters.

• The main application (3.5.7.3 plc-cape-lab) can be comfortably used as a function generator of any
waveform thanks to the high-speed DAC and the plugin-based approach.

I have also demonstrated the reusability of most of the software framework in other Linux-based
platforms (except for the custom SPI/DAC and ADC drivers, specifically targeted to the PlcCape and the
BBB):

• In the section 3.5.9 Multiplatform test with the Raspberry Pi, I have executed the software
framework in a Raspberry Pi (with Debian Jessie) to play sound

• In the section 3.5.6 Emulator, I have explained how the software framework has been adapted to
allow execution in a desktop-PC (with Ubuntu 14.04.5) and be able to do most of the available
operations through a speaker and a microphone, emulating the DAC and the ADC of the
BBB+PlcCape assembly
Design of a low-cost device for data transmission over power lines 161/181

5.3 Weak points and future improvements

During the analysis phase I faced several weaknesses in the electronic design that need to be addressed on
future versions.

Concerning software, considerable development work is still pending to have a stable and profitable
package. That is way I have identified it with the version 0.2 (the zero in the major number means beta
phase).

In the following sections I have summarized a list of proposed improvements in the different areas covered
by this project.

BBB + PlcCape electronics

• Due to a mistake, the RLC values proposed in this project for the forth-order RX filter are targeted to
the CENELEC-A band, whereas the whole project is targeted to the CENELEC-B band (see 4.2.2
RX filtering). This results in extra attenuation for the 110 kHz carrier used in the tests. For the next
version use CENELEC-B values for the RX filter.

• Add more access points, connectors and jumpers for more versatility. For example:

◦ Add comfortable access points to TX_F_OUT and TX_PGA_OUT, which exhibit different
characteristics (as seen in 4.3.1 TX_PGA_OUT vs. TX_F_OUT).

◦ Give the possibility to reach the ADC of the BBB bypassing the CENELEC-based RX chain in
order to cover other applications than just PLC (e.g. use the plc-cape-oscilloscope tool to
monitor real-time data from a sensor).

• Make the PlcCape more modular in order we can easily solder only the involved components for a
given application. For example, for a basic receiver in a low-noise environment, we could even omit
the AFE031 (which would only add a LPF and a couple of PGAs here) and fully rely on the ADC of
the BBB, reducing this way the cost of the board.

• Improve the thermal dissipation in the AFE031 and its monitoring in order to avoid damage even
in the worst conditions.

• Add an EEPROM for identification of the PlcCape (model and version) when connected to the
BBB.

• Implement other minor improvements as described in 3.3.7.8 Future improvements.

BBB + PlcCape software

• In the software side we should improve the decoding algorithms. In this project I have relied on
what I have called the carrier-detection-by-level mechanism: the DC offset is first removed from the
samples captured, then calculated the absolute values and applied an averaging formula to finally
compare with a threshold to determine if the OOK carrier is present or not. This method is simple
and computationally efficient but it only works if we have a single carrier and the level of signal is
higher than the background noise. In practical terms it means that this system only works if the
outlets are close enough.
162/181 Design of a low-cost device for data transmission over power lines

A much better approach for a more reliable communication would consist in applying a coherent
demodulation using the predefined frequency of the carrier. I was working on it but I have been
short of time. It is an imperative action to be done in the next version.

• For extra robustness and reliability we should also put in place communication protocols with
error detection (like parity, Checksum, CRC) or even with error correction (ECC).

• In the current implementation the ADC capturing rate is hard-coded to the maximum allowed value,
200 ksps. Due to the Nyquist theorem and the undersampling effect, this poses a problem when
recovering signals close to the 100 kHz (as it is the case in the CENELEC-B band). A lower ADC
capturing rate (e.g. 150 ksps) could overcome it (more details in 3.5.3 Future improvements).
Therefore, consider a configurable ADC capturing rate for a future version.

Push-Pull amplifier

• The Push-Pull amplifier used in this project is very basic and lead to considerable trouble due to its
dependency with the load impedance. It would work fine on a scenario with small changes in the
impedance but it is not the case in the 230VAC mains (as seen in 4.8 Data communication through
the 230VAC line and 4.9 Final system integration). A future iteration should improve the circuitry
to avoid any dependency with the line impedance.

• The voltage divider stage in the Push-Pull amplifier is a basic method to roughly adjust the output
level (it is affected by the input impedance of the next stage). We should use a better alternative for
a more appropriate voltage tuning, for example using an operational amplifier configuration.

• The filtering stage is composed of just a capacitor. This is enough to soften the square wave coming
from the Arduino board but a more selective filter should be considered for a more pure
sinusoidal output.

• In the current implementation with Arduino, there is a short transient at the beginning and ending of
each OOK pulse (seen in 4.5 Arduino and Push-Pull amplifier). We should put in place means to
eliminate or reduce the OOK transients.

Arduino + Shield

• Integrate the Push-Pull and the AC coupling module into the Arduino shield to reduce cost and
connection complexity.

• To reduce cost we can even replace the Arduino + Shield concept by a whole custom board. We
can reuse the processor of the Arduino Leonardo (ATmega32u4) to benefit from the Arduino
framework (IDE and libraries). We can start from the free schematics available in the Arduino
website[9] by removing all the unnecessary components (headers, LEDs, reset button, etc.).
Design of a low-cost device for data transmission over power lines 163/181

6 Annex I. Tools
Find enclosed a list of the tools used in this project:

ELECTRONIC DEVELOPMENT

EAGLE 7.5.0 I have used it to design the PlcCape boards. The limitations of the freeware
license fulfill the needs of this project: board dimensions, just one schematic
sheet and educational purposes. It is available for Windows, Mac and Linux.
http://www.autodesk.com/products/eagle/free-download
http://www.cadsoft.de/freeware.htm

UltraLibrarian I have used the free version to download the footprint of the AFE031 in Eagle-
6.4.202 compatible format.
http://www.accelerated-designs.com/ultra-librarian

LTspice 4.23l It has been a very helpful GUI to analyze electronic circuits with SPICE.
http://www.linear.com/designtools/software/#LTspice

SOFTWARE DEVELOPMENT

Eclipse 4.5 Mars Multipurpose open source IDE to develop, build and debug applications.
http://www.eclipse.org

Arduino IDE Open source IDE for the Arduino framework to write code, build it and upload
1.6.4 the resulting binary to the board.
https://www.arduino.cc/en/Main/Software

DEVICES

Hantek 6022BE It is a cheap entry-level USB oscilloscope. It has a 48 Msps ADC covering a
oscilloscope bandwidth up to 20 MHz. It can measure voltage levels up to 35 VPP.
http://www.hantek.com/en

OTHER TOOLS

Octave 4.0.1 Tool used for mathematical analysis and plots.

https://www.gnu.org/software/octave/index.html
http://wiki.octave.org/GNU_Octave_Wiki

LibreOffice Open source office suite used for the edition of this document.
5.1.3.2 https://libreoffice.org
Table 17. Tools used in this project
164/181 Design of a low-cost device for data transmission over power lines

Finally, I want to mention a tool that I have developed to automatize and simplify the conditioning of the
images included in this documentation. I have called it ImageConditioner:

I have used it to adapt some screenshots to Figure 102. ImageConditioner tool - Main screenshot

make them more readable (e.g. by cropping

the oscilloscope captures to only include the
main information) and paper-friendly (e.g.
by removing dark backgrounds).

This tool avoids the manual steps that

would be required otherwise. For example,
these would be the necessary steps to adapt
the captures from the Hantek oscilloscope
software to a more suitable format:

1. First we need to save the oscilloscope

capture to a BMP (PNG is not
supported and JPG is a lossy format)

2. Then, with a third party tool (like

Microsoft Paint), we need to convert
the resulting BMP to PNG to reduce the image weight (from ~1 MByte to a few KBytes) and thus, keep
the final PDF size manageable

3. We also need to remap some colors that are not paper-friendly. For instance, the original background is
black. In paper, a white background is preferable for better readability and for environmental friendliness
(because less ink consumption)

4. Finally, it is probable that some details in the capture need to be removed for a cleaner documentation

This an example of a conditioning from a Hantek capture (at left) to the resulting image (at right):

Original Hantek capture Resulting conditioned image

At development level the tool is simple and not very efficient in computational terms. But in any case, it does
the automated job quickly enough.

The tool is programmed in C# .NET. I have released it under GPLv3 and uploaded the sources to GitHub:

https://github.com/jose77105/ImageConditioner
Design of a low-cost device for data transmission over power lines 165/181

7 Annex II. LTspice - How to add third party models

I have used the LTspice tool to analyze the different versions of the circuits proposed.

It offers a powerful and helpful GUI that simplifies the edition and the analysis phase.

It also allows the integration of third-party library models. There is a guide for at
http://www.linear.com/solutions/1083.

As a summary, find here the steps that I have followed to incorporate the TIPxxx.LIB BJT models:

1. In the schematic canvas of LTspice, add a generic transistor.

2. Right-click on the symbol inserted while holding CTRL down.

3. Change the Value field by the exact name of our transistor (look at the .SUBCKT or .MODEL
clauses in the LIB file).

Note: if our LIB is a .SUBCKT, we also need to change the Prefix field by specifying an X (which
corresponds to generic sub-circuits). In our case, the TIP122 comes defined as a .SUBCKT. It is a
Darlington macro-model using several components.

It is also important to mention that, when using a .SUBCKT, we must check that the netlist order in
the .SUBCKT clause matches the logical pins of the symbol used. In LTspice we can check it
opening the symbol definition by clicking on the Open symbol button.

For instance, for NPN and PNP transistors (Prefix = QN and QP) the order is 1-Collector, 2-Base and
3-Emitter. By looking at the .SUBCKT of the TIP122 (and TIP127) we can confirm that it matches
the netlist order of the corresponding transistor symbols.

Tip: If we do not find a suitable symbol for a specific SUBCKT, we can create our own with LTspice
just by opening the LIB file, going to the .SUBCKT line, right-clicking there, and selecting Create
Symbol. The symbol (tip122.asy) will be stored in the LTSpiceIV/lib/sym/AutoGenerated directory
and available within the [AutoGenerated] section when adding a circuit component.

4. Add a .inc SPICE Directive indicating the location of the library18. For example:
“.inc http://www.onsemi.com/pub_link/Collateral/TIP122.LIB”

5. Run a simulation. The LIB will be automatically downloaded and copied into the local directory.

6. We can then replace the URL-location with the local relative path (just by specifying the name):
“.inc TIP122.LIB”

Notes:

• We can use the directive “.lib” instead of “.inc” if we want to download just the referenced model
instead the whole library file. In our case, as there is only one model in the library, it will produce
identical results.

• Alternatively, we can manually download the LIB file and copy it to our local directory.

18 The PSpice model for the TIP122 is available at http://www.onsemi.com/pub_link/Collateral/TIP122.LIB.

Other models are available at http://www.onsemi.com/PowerSolutions/supportDoc.do?type=models&rpn=TIP122.
For the TIP127 just replace TIP122 by TIP127 in the URLs given.
166/181 Design of a low-cost device for data transmission over power lines

8 Annex III. PlcCape board SPI analysis

I have included in this section a brief analysis of the SPI bus, just for reference.

Testing conditions:

• The plc-cape-lab application is continuously sending data through SPI.

• SPI involved lines (SCLK, DOUT, CSN) are captured with the oscilloscope.

Note: the standard criteria states that the DOUT line corresponds to the data sent from the BBB to the cape.
In PlcCape-v2 this standard is met but PlcCape-v1 implements just the opposite. Therefore, to measure the
SPI data sent from the BBB to the PlcCape-v1 put the probe at DIN.

8.1 Clock and data

The first series of tests are focused on the SPI clock and data. For example, this is a capture of the SCLK line
when transmitting DAC samples at 46875 bps through the plc-cape-lab application.

SCLK. Baud rate = 46875 bps 1 V/div. 100 us/div

By measuring the clock period, we confirm that the baud rate is properly configured by the software.
We can appreciate a small gap every 10 clock cycles. That is due to the 10-bits size of the DAC samples.

SCLK (top) and DOUT (bottom). 46875 bps. DAC sample = 0x200 2 V/div. 50 us/div

In this test, a static DAC sample with value 0x200 is being continuously sent (in binary 0b1000000000).
We see that the first bit (after the gap in SCLK) is ON during 1 clock cycle and then OFF, confirming that the
DOUT line is properly managed.
This test is also helpful to figure out the bit order: most significant bit first (as required by the AFE031).
Design of a low-cost device for data transmission over power lines 167/181

The next graphs expose some more examples for different data values:

SCLK and DOUT. 46875 bps. Data = 0x2 2 V/div. 50 us/div

This capture confirms that the data sent

to the SPI driver is converted to the
proper SPI sequence in DOUT.

SCLK and DOUT. 46875 bps. Data = 0x1 2 V/div. 50 us/div

Here we see a longer DOUT bit pulse

(1.5 clock cycles). This is an
optimization of the SPI driver: it is not
necessary to turn DOUT off during the
extra gap between DAC samples (half a
clock cycle).

SCLK and DOUT. 46875 bps. Data = 0x2AA 2 V/div. 50 us/div

The transmission of data with

alternating bits confirms the proper
behavior of the SPI transmission and
the gap between samples.

SCLK and DOUT. 46875 bps. Data = 0x1FF 2 V/div. 50 us/div

Here we see the correct transmission of

a word consisting in all the bits ON
except the first one.

SCLK and DOUT. 46875 bps. Data = 0x3FF 2 V/div. 50 us/div

When transmitting words with all the

bits equal to 1, DOUT is always ON.

SCLK and DOUT. 46875 bps. Data = 0x0 2 V/div. 50 us/div

When transmitting words with all the
bits equal to 0, DOUT is always OFF.
This confirms the optimization already
discussed when Data = 0x1: during the
gap between DAC samples, the SPI
driver keeps the last value to avoid
unnecessary transitions.
168/181 Design of a low-cost device for data transmission over power lines

8.2 Chip Select

The second series of tests are focused on the customized Chip Select management.

As explained in the first stage of this project [1], the transmission of DAC samples to the AFE031 involves a
particular management of the Chip Select: it is used to indicate the end of every sample (10-bits). This
implied a customization of the standard driver which resulted in the following management:

SCLK and CSN (Chip Select Negated). 375000 bps 2 V/div. 10 us/div

This test confirms that the customized driver properly emits a CSN pulse every 10-bits in order to notify the
AFE031 that a full DAC sample has been sent.
DOUT (0x2AA) and CSN. 3 Mbps 2 V/div. 1 us/div

Here we can see that the CSN pulse has a significant width at high baud rates.
CSN detail. 375000 bps 1 V/div. 500 ns/div

At medium baud rates (375 kbps) the CSN pulse takes 160 ns, which is much lower than the DAC sampling
period (= 10.5/375 kbps = 28000 ns). Therefore, the CSN pulse width is negligible.
CSN detail. 3 Mbps 1 V/div. 500 ns/div

At high baud rates (3 Mbps) the width of the CSN pulse is also 160 ns, but in this case it cannot be ignored
when compared to the theoretical DAC sampling period (= 10.5/3 Mbps = 3500 ns).
Design of a low-cost device for data transmission over power lines 169/181

If we evaluate the CSN pulse width for different baud rates, we get these graphs:

SCLK and CSN. 1.5 Mbps 2 V/div. 1 us/div

SCLK and CSN. 3 Mbps 2 V/div. 500 ns/div

SCLK and CSN. 6 Mbps 2 V/div. 200 ns/div

SCLK and CSN. 12 Mbps 2 V/div. 100 ns/div

Note: At 12 Mbps the SCLK is not displayed as a square wave because we are close to the bandwidth
limitation of the USB oscilloscope used.

According to the results obtained, we can conclude that:

• The CSN pulse is independent of the baud rate and takes around 160ns.
• The CSN pulse adds an extra delay in the clock line that must be considered when calculating the
effective DAC frequency. It can be ignored only when using low baud rates.
The formula that considers the CSN pulse width in the conversion from the SPI baud rate (bits per second) to
the effective DAC sampling rate (samples per second) is given in the chapter 4.3.1 TX_PGA_OUT vs.
TX_F_OUT.
170/181 Design of a low-cost device for data transmission over power lines

9 Annex IV. AFE031 Calibration modes

The AFE031 offers a very useful functionality, called calibration modes, that can be helpful to validate the
proper operation of the device. In these modes, internal bridges are set up between the different blocks of the
AFE031.

In this chapter, all the available calibration configurations are tested to have a clear idea of how they work.

The following pages enclose the DAC-to-ADC frequency response graphs obtained with the plc-cape-freq-
response tool (see chapter 3.5.7.2):

H(f) = K*ADC(f)/DAC(f)

K is an arbitrary constant to normalize the H(f) response to 1.0 for a predefined configuration, since the
direct relation from the DAC (10-bits) to the ADC (12-bits) is not very interesting. In particular, for each
calibration configuration I have adjusted K in order H(f) returns 1.0 for 10 kHz (just a reasonable reference)
with the AFE031 filters configured for CENELEC-B.

The following environment has been arranged for the analysis:

• PlcCape-v1 with the following AFE setup:

◦ TX_PGA = 0.25 V/V. The minimum gain of the TX_PGA has been chosen to avoid saturation
effects.

◦ RX_PGA1 = 0.25 V/V. This value is ignored, since RX_PGA1 does not participate in any
calibration mode.

◦ RX_PGA2 = 1 V/V. This is the minimum gain of the RX_PGA2.

◦ FILTER = CENELEC-B, unless otherwise noted.

• Signal: sinusoid with a DAC Offset = 600 and Range = 800. This range has been selected because it
is in the linear region of all the calibration modes. Other values can produce saturation in the
transmitted signal.

• Iterations: 41 equidistant frequencies between 50 Hz and 200 kHz. I have chosen 10 kHz has the
reference frequency to be captured because it is within the pass-band of the CENELEC filters and far
from the Nyquist frequency (to have many samples per cycle).

The above settings translate to this command line:

./plc-cape-freq-response -A:50 -B:200050 -C:41 -D:10050 -F:0 -O:600 -R:800 -U:0 -V:0 -W:0

Note that the plc-cape-freq-response application takes in consideration the PGA gains (-U:n -V:n -W:n)
as well as the Range (-R:n) when calculating H(f) so that they can be freely modified to adjust the level of
the DAC-to-ADC signal without affecting the 1.0 normalized reference.
Design of a low-cost device for data transmission over power lines 171/181

9.1 TX_PGA loop

Calibration configuration19: DAC → TX_PGA → ADC

This mode only adds the Programmable Gain Amplifier block to the DAC-to-ADC loop.

This calibration mode is activated with the -T:3 flag:

# ./plc-cape-freq-response -A:50 -B:200050 -C:41 -D:10050 -F:0 -O:600 -R:800 -U:0 -V:0 -W:0 -T:3
SETUP
-----
Test: f_ini = 50 Hz, f_end = 200050 Hz, iterations = 41
DAC values (in DAC units)
Offset = 600.000000, Range = 800.000000, AC Mean = 254.647903
EXPECTED ADC values [in ADC units]
DC mean = 930.000000, Range = 1240.000000, AC mean = 394.704224
Sampling rate = 522 ksps

TRANSFER FUNCTION
-----------------
Running freq = 50 Hz...Samples captured. DC mean = 640.41, AC mean = 423.04
Running freq = 5050 Hz...Samples captured. DC mean = 636.47, AC mean = 418.24
[...]
Running freq = 195050 Hz...Samples captured. DC mean = 632.63, AC mean = 177.71
Running freq = 200050 Hz...Samples captured. DC mean = 634.98, AC mean = 179.96

Frequency response from 50 to 200050 Hz (41 samples) stored in 'freq_response.csv'

ADC capture for frequency 10050 (10000 samples) stored in 'adc.csv'
FFT max expected at index 502.50 (freq 10050.00 Hz)
FFT max at index 503 (freq 10060.00 Hz), abs(H)/N = 262.76
NOTE: FFT steps = 20.00 Hz

In Octave:

>> plc_freq_response_plot_all("10k-200k")
DC mean = 638.48, AC mean = 394.58, AC Range = 1245.00, FFT max at 10100.00 Hz
H max = 1.07, H min = 0.45

19 The calibration configuration diagrams are copied from AFE031 datasheet. Replace the C2000 MCU proposed in the
AFE031 by the BBB used in this project
172/181 Design of a low-cost device for data transmission over power lines

H(f). TX_PGA loop

In the graph we can see that this mode exhibits a considerable attenuation for even low frequencies. This
does not fit very well with the expected behavior, which should be H(f) = 1.0 for a wide range of
frequencies. So, it might be a sign of a wrong behavior of the AFE031 due to wearing or damage, or due to
an indirect feedback from somewhere. It is something to be analyzed in a future review.

If we look at the ADC captures for 10 kHz, we have this:

ADC data at 10 kHz. TX_PGA loop

We can see that the ADC captured samples span

from 0 to 1200 (approx.).

The peak in the FFT confirms the proper

reception of a sine wave at 10 kHz.
Design of a low-cost device for data transmission over power lines 173/181

9.2 TX_PGA + TX_LPF loop

Calibration configuration: DAC → TX_PGA → TX_LPF → ADC

This configuration adds the TX Low-Pass Filter (CENELEC-configurable) to the transmission path.

This calibration mode is activated with the -T:1 flag:

# ./plc-cape-freq-response -A:50 -B:200050 -C:41 -D:10050 -F:0 -O:600 -R:800 -U:0 -V:0 -W:0 -T:1
SETUP
-----
Test: f_ini = 50 Hz, f_end = 200050 Hz, iterations = 41
DAC values (in DAC units)
Offset = 600.000000, Range = 800.000000, AC Mean = 254.647903
EXPECTED ADC values [in ADC units]
DC mean = 480.000000, Range = 640.000000, AC mean = 203.718323
Sampling rate = 522 ksps

TRANSFER FUNCTION
-----------------
Running freq = 50 Hz...Samples captured. DC mean = 1500.99, AC mean = 196.81
Running freq = 5050 Hz...Samples captured. DC mean = 1539.00, AC mean = 201.32
Running freq = 10050 Hz...Samples captured. DC mean = 1538.93, AC mean = 200.83
Running freq = 15050 Hz...Samples captured. DC mean = 1539.20, AC mean = 200.64
[...]
Running freq = 195050 Hz...Samples captured. DC mean = 1538.94, AC mean = 12.58
Running freq = 200050 Hz...Samples captured. DC mean = 1538.24, AC mean = 10.32

Frequency response from 50 to 200050 Hz (41 samples) stored in 'freq_response.csv'

ADC capture for frequency 10050 (10000 samples) stored in 'adc.csv'
FFT max expected at index 502.50 (freq 10050.00 Hz)
FFT max at index 503 (freq 10060.00 Hz), abs(H)/N = 143.34
NOTE: FFT steps = 20.00 Hz

In Octave:

>> plc_freq_response_plot_all("10k-200k")
DC mean = 1538.32, AC mean = 201.28, AC Range = 641.00, FFT max at 10100.00 Hz
H max = 0.99, H min = 0.05
174/181 Design of a low-cost device for data transmission over power lines

H(f). TX_PGA + TX_LPF loop

Here the graphs are the expected ones. We can clearly identify a cutoff frequency (gain = 1/√2 = 0.7) around
125kHz.

ADC data at 10 kHz. TX_PGA + TX_LPF loop

We can see that, even with the same settings as in

the previous test, this calibration mode changes
the range and the DC offset of the ADC samples:

• In TX_PGA loop: ADC from 0 to 1200

• In TX_PGA + TX_LPF loop: ADC from

1250 to 1850

In the FFT we can check that the captured

waveform is a proper sine wave.

The FFT representation is a useful way to detect distortion effects. For example, in case of saturation we will
see several harmonics with a noticeable level.

We can force this situation by configuring the TX_PGA to 1V/V. To do so, use the flag -U:3 in the command
line:

# ./plc-cape-freq-response -A:50 -B:200050 -C:41 -D:10050 -F:0 -O:600 -R:800 -U:3 -V:0 -W:0 -T:1
SETUP
-----
Test: f_ini = 50 Hz, f_end = 200050 Hz, iterations = 41
DAC values (in DAC units)
Offset = 600.000000, Range = 800.000000, AC Mean = 254.647903
EXPECTED ADC values [in ADC units]
DC mean = 1920.000000, Range = 2560.000000, AC mean = 814.873291
Sampling rate = 522 ksps

TRANSFER FUNCTION
-----------------
Running freq = 50 Hz...Samples captured. DC mean = 1502.71, AC mean = 625.16
Running freq = 5050 Hz...Samples captured. DC mean = 1621.14, AC mean = 629.39
Running freq = 10050 Hz...Samples captured. DC mean = 1622.87, AC mean = 631.41
Running freq = 15050 Hz...Samples captured. DC mean = 1626.76, AC mean = 636.61
[...]
Design of a low-cost device for data transmission over power lines 175/181

Running freq = 195050 Hz...Samples captured. DC mean = 1733.89, AC mean = 131.13

Running freq = 200050 Hz...Samples captured. DC mean = 1731.71, AC mean = 112.03

Frequency response from 50 to 200050 Hz (41 samples) stored in 'freq_response.csv'

ADC capture for frequency 10050 (10000 samples) stored in 'adc.csv'
FFT max expected at index 502.50 (freq 10050.00 Hz)
FFT max at index 503 (freq 10060.00 Hz), abs(H)/N = 350.37

In Octave:

>> plc_freq_response_plot_all("10k-200k")
DC mean = 1621.10, AC mean = 632.08, AC Range = 1773.00, FFT max at 10100.00 Hz
H max = 0.81, H min = 0.14

Here we can see a first sign of trouble: the maximum value of H(f), H max, has decreased from 1.0 to 0.8.
That means that we are getting 20% less voltage level (in average) than expected.

H(f). TX_PGA + TX_LPF loop. TX_PGA = 1V/V

The H(f) response is similar in shape to the non-saturated case, except for the H(f) gain level.

ADC data at 10 kHz. TX_PGA + TX_LPF loop. TX_PGA = 1V/V

We can see the saturated wave at right, and the presence of harmonics in the FFT at bottom.

The ADC captured range spans now from 600 to 2400 which is far below the maximum ADC range (from 0
to 4905). That means that saturation occurs on transmission, not on reception.
176/181 Design of a low-cost device for data transmission over power lines

In the following test we have switched the TX_LPF filter from CENELEC-B to CENELEC-A, and reverted
back TX_PGA to the default gain (0.25 V/V):
./plc-cape-freq-response -A:50 -B:200050 -C:41 -D:10050 -F:1 -O:600 -R:800 -U:0 -V:0 -W:0 -T:1
SETUP
-----
Test: f_ini = 50 Hz, f_end = 200050 Hz, iterations = 41
DAC values (in DAC units)
Offset = 600.000000, Range = 800.000000, AC Mean = 254.647903
EXPECTED ADC values [in ADC units]
DC mean = 480.000000, Range = 640.000000, AC mean = 203.718323
Sampling rate = 522 ksps

TRANSFER FUNCTION
-----------------
Running freq = 50 Hz...Samples captured. DC mean = 1497.99, AC mean = 195.67
Running freq = 5050 Hz...Samples captured. DC mean = 1537.65, AC mean = 200.98
Running freq = 10050 Hz...Samples captured. DC mean = 1537.48, AC mean = 200.64
Running freq = 15050 Hz...Samples captured. DC mean = 1537.45, AC mean = 200.44
[...]
Running freq = 195050 Hz...Samples captured. DC mean = 1536.31, AC mean = 1.20
Running freq = 200050 Hz...Samples captured. DC mean = 1536.03, AC mean = 0.99

Frequency response from 50 to 200050 Hz (41 samples) stored in 'freq_response.csv'

ADC capture for frequency 10050 (10000 samples) stored in 'adc.csv'
FFT max expected at index 502.50 (freq 10050.00 Hz)
FFT max at index 503 (freq 10060.00 Hz), abs(H)/N = 127.55
NOTE: FFT steps = 20.00 Hz

In Octave:

>> plc_freq_response_plot_all("10k-200k")
DC mean = 1538.03, AC mean = 201.07, AC Range = 637.00, FFT max at 10100.00 Hz
H max = 0.99, H min = 0.00

H(f). TX_PGA + TX_LPF loop. TX_PGA = 1V/V. CENELEC-A

Now the cutoff frequency in H(f) is close to 90kHz, as expected.

Design of a low-cost device for data transmission over power lines 177/181

9.3 TX_PGA + RX_LPF + RX_PGA2 loop

Calibration configuration: DAC → TX_PGA → RX_LPF → RX_PGA2 → ADC

This configuration includes the RX blocks in the DAC-to-ADC path.

Note: Although the diagram in the AFE031 datasheet includes into the loop the first RX PGA (RX_PGA1), it
seems that it is not. In a dedicated test I got the exact same ADC values for RX_PGA1 = 0.25 V/V as for
RX_PGA1 = 2.00 V/V.
This calibration mode is enabled with the -T:2 flag:

# ./plc-cape-freq-response -A:50 -B:200050 -C:41 -D:10050 -F:0 -O:600 -R:800 -U:0 -V:0 -W:0 -T:2
SETUP
-----
Test: f_ini = 50 Hz, f_end = 200050 Hz, iterations = 41
DAC values (in DAC units)
Offset = 600.000000, Range = 800.000000, AC Mean = 254.647903
EXPECTED ADC values [in ADC units]
DC mean = 1912.000000, Range = 700.000000, AC mean = 222.816910
Sampling rate = 522 ksps

TRANSFER FUNCTION
-----------------
Running freq = 50 Hz...Samples captured. DC mean = 1915.47, AC mean = 35.09
Running freq = 5050 Hz...Samples captured. DC mean = 1912.56, AC mean = 223.42
Running freq = 10050 Hz...Samples captured. DC mean = 1912.22, AC mean = 223.88
Running freq = 15050 Hz...Samples captured. DC mean = 1912.03, AC mean = 223.84
[...]
Running freq = 195050 Hz...Samples captured. DC mean = 1913.38, AC mean = 42.94
Running freq = 200050 Hz...Samples captured. DC mean = 1914.20, AC mean = 38.03

Frequency response from 50 to 200050 Hz (41 samples) stored in 'freq_response.csv'

ADC capture for frequency 10050 (10000 samples) stored in 'adc.csv'
FFT max expected at index 502.50 (freq 10050.00 Hz)
FFT max at index 503 (freq 10060.00 Hz), abs(H)/N = 128.78
NOTE: FFT steps = 20.00 Hz

In Octave:

>> plc_freq_response_plot_all("10k-200k")
DC mean = 1911.10, AC mean = 224.35, AC Range = 719.00, FFT max at 10100.00 Hz
H max = 1.01, H min = 0.16
178/181 Design of a low-cost device for data transmission over power lines

H(f). TX_PGA + RX_LPF + RX_PGA2 loop

Notice here an important difference compared to the previous calibration modes: now the iteration at 50 Hz
is not in the pass-band (gain < 0.2).
If we repeat the test for the CENELEC-A (-F:1) we get:
H(f). TX_PGA + RX_LPF + RX_PGA2 loop. CENELEC-A

In CENELEC-A the cutoff frequency decreases to 85 kHz.

ADC data at 10 kHz. TX_PGA + RX_LPF + RX_PGA2 loop

The range of the ADC captured samples for this

configuration covers the range from 1600 to 2300.
Design of a low-cost device for data transmission over power lines 179/181

Finally, we can analyze the low frequency range (10 Hz to 1 kHz) in a more accurate way by executing the
tool as follows:
# ./plc-cape-freq-response -A:10 -B:1010 -C:41 -D:1010 -F:1 -O:600 -R:800 -U:0 -V:0 -W:0 -T:2
SETUP
-----
Test: f_ini = 10 Hz, f_end = 1010 Hz, iterations = 41
DAC values (in DAC units)
Offset = 600.000000, Range = 800.000000, AC Mean = 254.647903
EXPECTED ADC values [in ADC units]
DC mean = 1912.000000, Range = 700.000000, AC mean = 222.816910
Sampling rate = 522 ksps

TRANSFER FUNCTION
-----------------
Running freq = 10 Hz...Samples captured. DC mean = 1919.55, AC mean = 3.12
Running freq = 35 Hz...Samples captured. DC mean = 1916.11, AC mean = 24.45
Running freq = 60 Hz...Samples captured. DC mean = 1912.51, AC mean = 42.16
Running freq = 85 Hz...Samples captured. DC mean = 1917.21, AC mean = 59.75
Running freq = 110 Hz...Samples captured. DC mean = 1915.82, AC mean = 74.13
[...]
Running freq = 985 Hz...Samples captured. DC mean = 1913.38, AC mean = 212.72
Running freq = 1010 Hz...Samples captured. DC mean = 1910.60, AC mean = 213.21

Frequency response from 10 to 1010 Hz (41 samples) stored in 'freq_response.csv'

ADC capture for frequency 1010 (10000 samples) stored in 'adc.csv'
FFT max expected at index 50.50 (freq 1010.00 Hz)
FFT max at index 51 (freq 1020.00 Hz), abs(H)/N = 111.58
NOTE: FFT steps = 20.00 Hz

In Octave:

>> plc_freq_response_plot_all("10-1k")
DC mean = 1909.71, AC mean = 214.21, AC Range = 679.00, FFT max at 1000.00 Hz
H max = 0.96, H min = 0.01

H(f). TX_PGA + RX_LPF + RX_PGA2 loop. CENELEC-A. Focus on 10 Hz to 1 kHz

We see here the response of a high-pass filter with a cutoff frequency around 300 Hz.
180/181 Design of a low-cost device for data transmission over power lines

10 Bibliography
All the bibliographic references (unless otherwise noted) are provided as online URL links which have been
accessed and validated on April 2017.

10.1 PlcCape framework

[1] Josep Maria Ortega, Data communication through power lines using a system based on BeagleBone,
September 2016, 180 pages
http://upcommons.upc.edu/handle/2117/98244

10.2 BeagleBone Black

[2] BeagleBoard.org - bone101
http://beagleboard.org/support/bone101
[3] Gerald Coley, BeagleBone Black System Reference Manual, Revision A5.2, 2013, 108 pages
https://cdn-shop.adafruit.com/datasheets/BBB_SRM.pdf
[4] Beagleboard:BeagleBone Capes - eLinux.org
http://elinux.org/Beagleboard:BeagleBone_Capes
[5] Beagleboard:Cape Expansion Headers - eLinux.org
http://elinux.org/Beagleboard:Cape_Expansion_Headers
[6] Adafruit Eagle Library
https://github.com/adafruit/Adafruit-Eagle-Library

10.3 Arduino
[7] Arduino - Home
https://www.arduino.cc
[8] Arduino - ArduinoBoardLeonardo
https://www.arduino.cc/en/Main/arduinoBoardLeonardo
[9] Arduino_Leonardo-REV3b.sch, 2012, 1 page
https://www.arduino.cc/en/uploads/Main/arduino-leonardo-schematic_3b.pdf
[10] Atmel, ATmega16U4/ATmega32U4 8-bit Microcontroller with 16/32K bytes of ISP Flash and USB
Controller, Datasheet, 438 pages
http://www.atmel.com/Images/Atmel-7766-8-bit-AVR-ATmega16U4-32U4_Datasheet.pdf
[11] Arduino | 37 in 1 Sensors Kit Explained
http://www.instructables.com/id/Arduino-37-in-1-Sensors-Kit-Explained

10.4 Raspberry Pi
[12] Raspberry Pi - Teach, Learn, and Make with Raspberry Pi
https://www.raspberrypi.org

10.5 PLC
[13] Power-line communication
https://en.wikipedia.org/wiki/Power-line_communication
[14] DC Power Line Communication (PLC) Reference Design
http://www.ti.com/tool/24VDCPLCEVM?keyMatch=PLC&tisearch=Search-EN-Everything
[15] Welcome to CENELEC - European Committee for Electrotechnical Standardization
https://www.cenelec.eu/
Design of a low-cost device for data transmission over power lines 181/181

10.6 AFE31
[16] AFE031 | Precision Amplifier | Operational Amplifier (Op Amp) | Description & parametrics
http://www.ti.com/product/afe031
[17] "Texas Instruments, Incorporated”, Powerline Communications Analog Front-End (Rev. D), Data Sheet,
2010-2012, 58 pages
http://www.ti.com/lit/ds/symlink/afe031.pdf
http://www.ti.com/lit/gpn/afe031
[18] "Texas Instruments, Incorporated”, AFE Design for a Narrowband Power-Line Communications
Modem Using the AFE031 (Rev. A), Application Reports, 2011, 36 pages
http://www.ti.com/lit/an/sboa130a/sboa130a.pdf
[19] "Texas Instruments, Incorporated”, QFN Layout Guidelines, Application Reports, 2006, 7 pages
http://www.ti.com/lit/an/sloa122/sloa122.pdf
[20] System on Module for Industrial Power Line Communication (CENELEC Frequency Band)
http://www.ti.com/tool/tidm-somplc-industrial-cenelec
[21] Power Line Communications Kit for CENELEC Frequency Band
http://www.ti.com/tool/tmdsplckitv4-cen

10.7 Push-Pull
[22] Push-Pull Output Stage
http://www.ecircuitcenter.com/Circuits/pushpull/pushpull.htm
[23] MOSFET Push Pull Amplifier
http://reviseomatic.org/help/s-push-pull/Push%20Pull%20MOSFET%20Amp.php

10.8 Open source libraries

[24] FFTW Home Page
http://www.fftw.org
[25] The GTK+ Project
https://www.gtk.org
[26] GTK+ 3 Reference Manual - Developer center of GNOME
https://developer.gnome.org/gtk3
[27] The XML C parser and toolkit of Gnome
http://www.xmlsoft.org
[28] Advanced Linux Sound Architecture
http://www.alsa-project.org