Programming – SYMON MUTHEMBA

FPGAs for Innovating Digital Communication Interfaces

symonmk — Mon, 28 May 2018 19:26:46 +0000

It’s 11th May, and we just arrived at a client’s studio at 11:45pm. I assure my colleague that we’ll get it right this time. Our job that night was to link two studios over an Ethernet connection. Simple enough despite the fact that neither of us had done it before. We had gone through the manuals over and over again, 4 different manuals in fact, that’s why I felt certain, at least 80% certain it would be possible. In the end, we achieved connecting two LAWO audio engines over a VLAN network that could send and receive digital audio channels over MADI (AES 10). More on that later. After our 5 hour stint, I couldn’t help wonder how even such an interface was achieved. In this post I cover what it takes for hardware and communications engineers to prototype, test and innovate such interfaces using FPGAs. Field Programmable Gate Arrays (FPGAs) FPGAs, Figure 1, are re-programmable silicon integrated circuits developed by Xilinx in 1984. FPGAs are what exist between ASICs (application specific integrated circuits) and general purpose processors. This means that FPGAs can be programmed to perform one complex task and later be fully reprogrammed to perform another. This flexibility is why FPGAs have become increasingly popular for prototyping and deploying custom functionality. Programming for FPGAs can be done with low level (digital design) or high level (C code) programming environments. These software then compile the code into a bitstream or configuration file that reconfigures the internal circuitry of the FPGA. Some advantages of using FPGA technology over the common microprocessor include: High performance. As FPGAs are custom programmed chips for a specific functionality, data (signal) processing performance is high as applications have full control of processing cycles as well as inputs and outputs. Rapid prototyping. With the recent improvements in high level design, engineers spend less time developing and prototyping FPGA functionalities. Also, since FPGAs are re-programmable iteration is faster as compared to ASICs. Low costs. Consider ASICs, they’re manufactured once to handle specific tasks. If a customer’s requirements change they have to obtain a new chip (often a new device altogether) with more functionality. FPGAs recognize the need to change the functionality of the chip as the user’s requirements change. Can be used long-term. In this post we are about to discuss FPGA use in digital communication interface design. However, we know that standards are ever changing with the market. Luckily, with FPGAs you can perform field updates years after the initial installation. FPGA use in Digital Communications Applications for FPGAs span across different industries like medical electronics, aerospace and defense, broadcast and pro A/V, consumer electronics, wired and wireless communication and manufacturing. I take a special interest in communications and will cover that. You may be wondering, what was I dealing with that night? Who’s MADI? MADI is Multichannel Audio Digital Interface (AES 10) which you can read more about here. In summary, MADI is an interface that can carry multiple channels of digital audio (one interface port can carry 64 mono channels!) over coaxial or optical fiber up to 2km! What the exclamation points signify in the last sentence is that MADI is a capable system for large pro A/V and broadcast applications. Its scalability has made it increasingly attractive in such applications. We carried the MADI channels over the RAVENNA (AES67) media-over-IP standard. RAVENNA is an open standard for carrying real-time media over an IP network. With this in mind, we see how such an interface and a network can be made possible with FPGA boards and a can-do attitude. Implementation To understand how this can be implemented, we start with the understanding what is going on inside FPGAs. A single chip has three parts to it: input/output blocks, logic blocks and programmable routes. During development cycles, you are in full control of these 3 segments to configure to your specific application. Then comes the interesting bit of (re)programming. In the not so distant past, FPGAs were mostly programmed using hardware description languages (HDL) such as VHDL and Verilog. That was much harder and not so friendly to most programmers. Only recently have development being made easier with the SDAccel development environment. With this, applications can be built in C/C++. A popular programming and design suite is the Xilinx ISE. Now back to our work today. To start developing for a particular protocol, you need to identify all the technical specifications with that protocol. For MADI you are required to know the electrical characteristics and data organisation, Figure 3, of the protocol. Additional circuitry should also be accounted in design as the final system will be a combination of input and output ports. Then reference the timing diagram to define the logical signal flow. This simple tutorial shows how one can program an FPGA board to accept audio signals and transmit them over a MADI channel. Your Future with FPGA As we develop more complex systems, we’ll paradoxically need simpler communication interfaces. FPGA based solutions work best when ideas are still experimental and budgets are limited. They provide a simple solution to the interface I described in the first chapter. (FPGAs are just one way they made it possible, in reality it could be with ASICs or DSPs) In the IoT industry, FPGAs are popular in interface design. Even in processing, FPGAs are currently being used to replace power hungry GPUs and inflexible ASICs. This leads to smaller, power efficient and future-proofed systems. (The IoT industry is shrouded in uncertainty due to continuous development of telecommunication technologies as I discussed before.) When doing this research, I was humbled by the vast information that already existed on this topic. I’ll be sure to dive deeper and experiment with this. The learning curve seems pretty steep, but that’s why I always carry my harness. Badum tss! Thank you if you have made it this far. I’ll be happy to know more about this topic from you so let’s […]

The post FPGAs for Innovating Digital Communication Interfaces appeared first on SYMON MUTHEMBA.

Off-Grid Communications For The Masses: Smart Metering

symonmk — Mon, 30 Apr 2018 20:50:28 +0000

In East Africa, a large percent of the population still does not have access to electrical energy and its benefits. To address this, several companies have developed micro-grids to provide AC power to rural East Africa. In order to sustain these grids, a remote, robust communication system has to be developed for purposes of metering and billing. In this post, I propose several efficient designs of a communication system that could be used to monitor and manage off-grid customers. Specifically, it proposes the technologies that can be used, the hardware and software implementation of such as system and how it can make business sense addressing equipment and operation costs. This post proposes a communications system that tackles the stated situation within the boundaries of the limitations set by a real-world scenario, i.e. budget, energy supply and manpower. A comprehensive approach to systems design is valuable to ensure the sustainability of such a project. Sections in this post will cover the hardware, communications channels and protocols, remote monitoring systems and software that can be used to solve the stated design issue. The goal is to provide micro-grid providers with a trustworthy system for off-grid power management as well as help the locals with a solution that sufficiently caters to their needs. Hardware Implementation A reliable remote metering system has to have a few basic characteristics: A smart metering system that connects every household, enabling 2-way data transfer between the customer and utility provider A network technology to enable the 2-way communication (fixed wired or wireless) A software system that actively manages the billing system and analyses usage data With a system defined as in Figure 1, we can start to see how we can bring together the hardware components. Smart Metering Smart meters are already in the market, such as Hexing Electric HXE 110-KP single phase prepayment smart meter and ZTE ZX E211, Figure 2, single phase prepayment smart meter. These meters meet Standard Transfer Specification (STS) standards and are fit for our application. The ZX E211 is the preferred choice here as its supports a variety of communication protocols (RS485, M-BUS, ZIGBEE, RF-MESH, PLC and GPRS). We will see how these communication protocols will be used in this post. ZTE ZX E211 LoRa based meter is particularly useful in long distance communication and allows us to adjust several parameters such as the transmission rate and frequency. The main feature is its low power consumption with a transmit current of less than 90mA@ 17dBm, receive current less than 13mA and standby current less than 0.7 uA. Since data communication may occur only few times a day, a majority of the consumption will be the standby current. Depending on the data that is provided by this meter, or a comparable one in the market, we may choose to consider meters that do not conform to STS standards. This may help us with communication protocols unavailable to us but may limit us in scaling and future upgrades with the national grid. Fabrication of a communications device alongside the meter may be required to send more usage statistics and deliver the desired data. This can be used for analysis to improve the overall system. This can be covered in a future post with AVR, PIC or FPGA as the processing IC in our DIY smart meter. Communication System This post will discuss two concepts of a smart meter communications in a rural area based on two assumptions: Location size – Are the residents physically close to each other or spread out? Terrain – Is the area flat or hilly? Dense vegetation cover or dry grassland? To meet the requirements of the location, I propose two systems that can be established. They are the RF-MESH network and RF-STAR network. Both networks rely on wireless channels to carry data. RF-MESH Network This type of network allows for data transmission via other wireless devices via a mesh (chain) network using a low power transceiver radio. This network is suitable for close-knit residential areas with few obstacles and is cheap to implement and scale. The architecture consists of low power transceiver radios per every meter box and data concentrators as in Figure 3. A proposed transceiver is the Silicon Labs Si4463 chip that facilitates the RF communications link. This is a transceiver I’ve worked with before on a previous project. Schematics of the full transceiver system is covered here. It is a low power transceiver with up to 20dBm (100mW) transmitting output power and a receiving sensitivity of -117dBm. Its wireless frequency band is 433.4 – 473.0MHz, and up to 100 channels can be set up with a channel stepping of 400 kHz. A serial port baud rate of 2400bps allows for a baud rate in air of 5000bps and a wireless receiving sensitivity of -117dBm. This gives an operating range of 1000m at clear line of sight between modules under ideal conditions. A concentrator can then be installed somewhere central in the village to aggregate the data of multiple smart meters and one concentrator may support hundreds of smart meters. This system is immune to sudden channel blocking as communication can flow using alternative paths. The DRF1110N20-C concentrator works well with DRF1110N20-N network nodes on a sub 1GHz channel. The concentrator can then upload the received data to micro-grid databases at different times of the day depending on the availability of the data network. RF-STAR Network This network type is of a point to multi-point (PtMP) configuration. This communication system is admittedly more expensive than the RF-MESH network but is suitable in hilly terrains with thick vegetation and obstacles. The architecture consists of high-power radio transceivers with a line-of-sight to an omni-directional antenna radio as in Figure 4. To implement this system, a 2.4GHz ISM channel may be used. A clear line of sight from a transmitter antenna to the receiver should be established, I recently talked about the art of obtaining strong microwave links. The smart meter information […]

The post Off-Grid Communications For The Masses: Smart Metering appeared first on SYMON MUTHEMBA.

Simplification in Design of Wireless Systems: 5 Useful Steps

symonmk — Fri, 20 Apr 2018 08:02:26 +0000

As we all know, wireless is the preferred method of connectivity between most of our devices. This is going to take more precedence in coming years. The number of connected devices per person and the demand for fast, reliable content delivery within a network is rapidly increasing. Add that to the already ongoing craze of developing IoT devices and the super-scaling of server farms to support them. In my view, RF, DSP and embedded systems engineers will have a lot going on. This shift is largely dependent on the wireless systems we build. In this post, I try to figure out the best way forward in design of wireless systems. The RF spectrum houses a number of wireless standards and medium in use today, these include WiFi, Bluetooth, FM broadcast, DVB-T, DAB, GSM, UTMS, LTE, WLAN, radar. The upcoming 5G standards are yet to be agreed upon as I illustrated here, but we can consider some technologies already in use today such as MIMO and MU-MIMO. Engineers responsible for the development of these systems are aware of the standards involved, however, they are required to understand a vast number of fields during the design phase that implementation takes a lot of time. This, of course, is uneconomical in the fast paced world we live in. Fortunately, engineers have figured out that the design process could be simplified into 5 major blocks: Modelling and simulation of digital, RF and antenna systems Optimization of design algorithms Automatic HDL and C code for hardware and software implementation Prototype design and testing with SDR hardware Iterative verification using model as a reference Modelling and Simulation There are a number of softwares in use for modelling. In today’s case, we will consider MATLAB (free alternative GNU Octave). MATLAB is a renowned development kit for engineers and scientists. It is rare that you find something you can’t do with this software and its additional toolboxes. Must be why it costs a kidney, but it’s a good place to start. Simulink is an environment within MATLAB that you use to perform model-based design. I’ve developed a simple communications link, Figure 1, that I can use as a basis of further developments. The model in Figure 1 is initiated by the following script: The model above used the DSP System Toolbox and Communication System Toolbox. This model can be useful in the following ways: a starting point of system level design and verification a test-bench of design algorithms written in C language a point of generation of C or HDL code for use in DSP/FPGA implementation This model also allows us to simulate the results of our input and process variables to ensure we are getting the desired outputs. Algorithm Design and Optimization Algorithms are the coded processes within a process block of a program. It defines what steps are in between the START and STOP operations of a process. Simple well known algorithms are flow control loops, error handling and on higher level languages we have object oriented programming (OOP). A while back I wrote an article touching on FFT algorithms. Many programming environments are set up with debugging features for your code. They analyze and give warnings of bad syntax and compile errors. This is particularly useful before running bad code into your hardware that may bring firmware failure. The best environments go a step further and allow you to optimize your code. You can set break points to see what happens when your program reaches a certain step, allowing you to tweak your variables accordingly. Very useful in precise calculations, characteristic of antenna design. A feature of MATLAB called Profiler allows you to run your algorithm while measuring its performance. It then generates a profile with details of the areas of your code that could use some improvement. This is based on the time the section took to run and how much of the processing resources it required. HDL and C code Generation Hardware Description Language (HDL) and C/C++ language are pretty similar languages used in design and implementation of integrated circuits on supported microcontrollers, microprocessors or FPGA devices. They are the core of every embedded system, like in Figure 2, a Xilinx FPGA board. While developing complex wireless systems involving several devices, it is inefficient to separate simulated algorithms and IC programming. A software like MATLAB enables the automatic generation of HDL and C code using MATLAB Coder. To illustrate, we will generate C code from a Kalman filter algorithm. A Kalman filter is an optimal estimation algorithm used for parameter prediction. It is quite popular and used in the fields of vehicle navigation and guidance, computer vision and wireless systems design. MathWorks provides a write up of the example in use. In that example kalmanfilter.m is my function file and ObjTrack.m is my algorithm which defines inputs, runs the Kalman filter and plots it in a graph, Figure 3. Conversion involves using the MATLAB Coder. Add the function on the entry point file and define its inputs types after which go ahead and build the C code, Figure 4. The generated C code can be obtained from your MATLAB code directory. SDR Hardware Prototypes Software-defined radios (SDRs) deserve a post of their own and thus will be briefly covered here. Basically these are computers whose components, traditionally implemented in hardware, are implemented through software. This means that the filters, amplifiers, modulators/demodulators are implemented using programming languages. In the previous section we discussed how to perform code generation. What SDRs offer is the flexibility to test and implement wireless designs and architecture with the provision to add more features in future. SDRs are used in conjunction with FPGA, GPP (general purpose processors), DSP or ASIC (application specific ICs) to implement various wireless architectures. It is a low cost method that is becoming increasingly popular in wireless systems design. Verification Finally, the system is rigorously verified using simulated and on-field test parameters to ensure the best product […]

The post Simplification in Design of Wireless Systems: 5 Useful Steps appeared first on SYMON MUTHEMBA.

Recognizing “ndiyo” and “hapana” speech using MATLAB algorithms and FFT functions

symonmk — Tue, 18 Jul 2017 14:24:00 +0000

Ndiyo means yes in Swahili and hapana means no. The two words were chosen as they can be used to make very simple applications that may require a yes/no response such as an automatic telephone prompt system. Swahili translations of yes/no applies to the national language of Kenya, and an interface that recognizes the words can be used in local applications. Simple speech recognition The first step is to obtain speech samples of ndiyo and hapana from a large sample of people throughout the country. This can be done using a simple microphone and a recording instrument. For this project however, I took the generic pronunciations of the words from Google translate: ndiyo, hapana (I know, sounds weird). We can now plot the two audio files as a periodogram Power Spectral Density plot using fast Fourier transform (FFT) in MATLAB. FFT is simply an algorithm that makes computation of discrete Fourier transforms (DFT) more efficient by reducing the amount of computations involved. OR This gives the plots in figures 1 and 2. According to the two plots above, we can see that the signal for ndiyo has more energy in the lower frequencies than that of hapana. We can use this feature to differentiate the two signals. When the signals approach 4kHz however, they exhibit features that are similar and harder to differentiate. Trial and error resulted in a range of 0 to 3620 Hz for the lower frequencies and 3620 to 11025 for the higher frequencies. A threshold value is necessary for the separation of the features, this value is obtained by calculating the feature for all of the audio samples and examining the histogram for the ndiyo and hapana values. I chose a threshold value of 12 as an example but in practice this figure should be computed. The speech recognition algorithm is: Using this algorithm, the output for the speech recognition function on the two audio files is: This shows that the algorithm exercise was successful in distinguishing the speech from two audio sources using a simple recognition algorithm. REFERENCES AND SUPPORTING ARTICLES ‘Power Spectral Density Estimates Using FFT’ https://www.mathworks.com/help/signal/ug/power-spectral-density-estimates-using-fft.html. ‘DSP Mini-Project: An Automatic Speaker Recognition System’ http://minhdo.ece.illinois.edu/teaching/speaker_recognition/speaker_recognition.html. ‘Basic feature extraction and classification of audio files’ https://ccrma.stanford.edu/workshops/mir2011/Lab_1_2011.pdf. Enhance your DSP Course with These Interesting Projects http://www.asee.org/file_server/papers/attachment/file/0002/2611/Enhance_your_DSP_Course_with_these_Interesting_Projects.pdf.

The post Recognizing “ndiyo” and “hapana” speech using MATLAB algorithms and FFT functions appeared first on SYMON MUTHEMBA.