Component Selection
Computing Platform
The computing platform is the core of the phasor measurement unit. It is responsible for acquiring raw AC voltage waveform data from an Analog to Digital Converter (ADC) in synchronicity with the GPS Pulse Per Second (PPS) time code, computing the magnitude and phase of the signal, packaging the measured data into the IEEE C37.118.2 transmission format and sending the resulting data packet over the internet to a PDC. Many options were considered in the choice of the computing platform for this project, including the well- known Raspberry PI, the Arduino, BeagleBone Black, and Intel Edison. The Raspberry PI, while it is a relatively powerful platform with thorough documentation and an active user base, was dismissed due to the lack of an onboard ADC. Choosing a platform with an onboard ADC is important because it simplifies the circuitry and reduces the cost of the device. An Arduino, while it has an onboard ADC, lacks the computing power of the other SOC based alternatives, requires additional components to connect to the internet, and does not have the ability to be reprogrammed remotely, an important consideration when deploying a device in the homes of laymen residents.
Intel’s Edison platform was considered for its high computing power density (dual core 500 MHz processor), but rejected due to the scarcity of public documentation. Ultimately, the BeagleBone Black was chosen as the computing platform. It has a 1 GHz proces- sor, which outperforms the Raspberry PI’s 700 MHz, a built in ethernet port for internet connection, and an onboard ADC with eight input channels. The Black also can run the Debian or Ubuntu Linux distributions. Using these Linux distributions provides built in support for remotely accessing the device and a large package database to pull from when implementing components of the project. Of the most consequence in choosing this board was the NEON and Programmable Realtime Unit (PRU) subsystems. The NEON subsys- tem provides hardware acceleration for floating point calculations and a implementation of the Fast Fourier Transform that utilizes this capability has already been developed. Uti- lizing this library will allow for the reduction of the computational load on the processor, which in turn should enable the device to achieve a higher reporting rate. The PRU, es- sentially an onboard microcontroller in which the execution of each instruction is fixe is significant because all of the instructions available in this subsystem have a fixed execu- tion time of 5ns. The PRU interfaces directly with the ADC subsystem and the Black’s onboard memory, meaning it can acquire data from both the GPS and AC voltage inputs to the ADC and store it for processing in a fixed, known amount of time that can be easily compensated for in the final calibration of the device.
GPS Module
As stated in the Timing section of the Design Requirements, the time source must be accurate within ±26μs in order to achieve the accuracy specified in [11]. There are many timing-specific GPS modules on the market, but their average price is $450, [18] which is prohibitive for the budget of this project. The Adafruit Ultimate GPS Module is offered at a reasonable $40 and achieves ±9μs accuracy [19] on its PPS output. Though this is not as accurate as timing-specific sources, some boast sub ±5μs accuracy, [20] it is well within the specifications and budget for this device.
Software Design
Signal Processing
From the initial stages of the project, Python was the desired programming language for processing raw data into synchrophasor measurements. Availability of Python packages for signal processing and ethernet packet transmission, cross platform compatibility, and the ease with which the language can be interpreted by a lay person were the driving factors in this choice. By choosing such a widely known and supported language the code generated in this project can be of greater utility to others researching PMUs. However, Python is a high-level programming language which presents a few challenges when interacting directly with hardware. Python code has to be parsed by the Python interpreter before it is executed, exacting a performance penalty. In addition, low-level programming languages like C are more suited to direct memory interaction than Python.
It was possible to use Python, despite its deficiencies, in this project because the heavy lifting is handled by the PRU. Samples generated by the ADC are stored in shared memory accessible from the CPU by the PRU, which ensures that latency between sample acqui- sition and storage in memory is a fixed, known value. Texas Instruments, the designer of the AM335x processor onboard the BeagleBone Black, provides a library for sending assembly code to and monitoring interrupts from the PRU written in C, another obstacle. Fortunately, PyPRUSS, a community project focused on 3D printing with the Black, incorporates a Python wrapper for the C library, enabling its functions to be called within Python code.
Signal Acquisition
Acquisition of data with the BeagleBone Black’s onboard ADC can either be handled by the CPU or by the PRU. The host CPU runs Debian, a variant of linux, which is not a realtime operating system. Any processes interacting with the ADC are scheduled at the mercy of the operating system, which is not a desirable characteristic in an application where precise timing is of the utmost importance. Therefore, the PRU was used to communicate with the ADC subsystem. The PRU is controlled with assembly code loaded by the CPU. Coding in assembly presents a few challenges; operations involve direct manipulation of registers and memory locations which is time consuming and potentially catastrophic as the PRU has access to the memory and storage used by the operating system. Ultimately, the tight timing constraints imposed by the design requirements necessitate the use of the PRU despite the faults of coding in assembly.
