Circuit Cellar No 331 February 2018

Prévia do material em texto

w Product Focus: MCU Development Tools w Non-Standard SBCs |
Programmable Ad Hoc Mesh Network | Building a VR Arm Tracker | 
 Video Game Console Uses Microchip PIC32| Home Cleaning Robot (Part 3) | 
w Shannon and Noise | IoT Security (Part 1) | Modulation Fundamentals |
 Money Sorting Machines (Part 3) w The Future of Industrial IoT
DRIVERLESS VEHICLES
FEBRUARY 2018 
ISSUE 331CIRCU
IT CELLAR | ISSU
E 331 | FEBRUARY 2018
circuitcellar.com
circuitcellar.com
MCUs PAVE THE FUTURE FOR 
DRIVERLESS VEHICLES
Inspiring the Evolution of Embedded Design
Trust Your Application
www.iar.com/ew
Developing embedded systems is a challenge. Higher complexity, better performance 
and more connectivity brings a rapid increase of safety and security demands. This creates 
needs for secure workflows and full code control, extending the developers’ reach all the 
way from design through to production. 
We are dedicated to provide you with the superior technology and close-at-hand 
support you need to be confident in your code when building the products of today and 
the innovations of tomorrow. Using the right tools, you can trust your application and 
create for the future.
https://goo.gl/dQLvhC
ACCELERATE. SlingShot Assembly’s state-of-the-art production
facility uses the latest software, processes and equipment to produce high-quality, 
prototype and small-run PCB assemblies, fast. www.slingshotassembly.com
PROTOTYPES IN 5 DAYS. OR IT’S FREE.
For more details, contact us or go to SlingShotAssembly.com/prototypes
info@SlingShotAssembly.com 720.778.2400
©2018 COPYRIGHT SLINGSHOT ASSEMBLY
Not Your Average SlingShot.
https://goo.gl/ghgTfq
mailto:info@SlingShotAssembly.com
www.slingshotassembly.com 
Denver
info@SlingShotAssembly.com
720.778.2400 
©2018 COPYRIGHT SLINGSHOT ASSEMBLY
• No Order Too Small 
• Turn-Times as Fast as 24 Hours
• Bare Board and Component 
Turn-Key Services 
• 24/7 Online Ordering and 
Custom Quotes
• Check Bom Instantly Online for Price 
and Availability
• Industry’s Best Design for Assembly 
(DFA) on All Orders
• Functional Test, Box Build and 
Conformal Coating Services 
• High-Quality, Industry-Leading Jet Paste 
Printing Process 
• Quality Process Includes 3-D X-Ray of 
BGAs/Leadless Parts and In-Line AOI
We are dedicated to helping engineers across 
all industries speed the transformation of their 
designs into properly functioning circuit boards. That 
means more than simply providing fast, high-quality PCB assembly 
at a reasonable price. We offer a variety of related services, all designed 
to streamline the process of PCB prototyping and low-volume production 
assembly. One of our unique tools includes our industry-best design check, 
which identifies issues before assembly to save you time and frustration. 
Give us a try. We believe you will be amazed at how we can help you meet 
your project goals.
NOT YOUR AVERAGE QUICK-TURN
PCB ASSEMBLY COMPANY
ACCELERATION: A NEW APPROACH TO PCB ASSEMBLY
 CORE SERVICES
We accelerate your ideas by solving problems before they happen. We offer 
these additional services so your project doesn’t get unnecessarily delayed. 
BOM ANALYSIS • Identify Parts Availability and Price Issues Early 
• Pre-Buy BOM and We’ll Store it for You
DESIGN ANALYSIS • Analize Design Files for Mistakes that will Stop 
 an Assembly Project
MANUFACTURABILITY ANALYSIS • Review Design to Identify Cost and Risk Drivers 
 for Manufacturing Early. 
SSA17-01 AverageSlingShotAd_vFFwww.indd 2 12/22/17 2:08 PM
https://goo.gl/ghgTfq
mailto:info@SlingShotAssembly.com
X 
MARKS
THE
SPOT
Join us at the spot where new ideas are imagined. Register now at XPONENTIAL.org
Colorado Convention Center | Denver | Educational Program: April 30 – May 3 Exhibits: May 1 – 3 
New capabilities and technology advances are 
transforming the unmanned systems industry. 
Now is the time to learn about the trends and 
best practices for the next generation of 
unmanned technology as well as identify new 
unmanned systems solutions.
> 200+ educational sessions across four tracks: 
Policy | Technology | Business Solutions | Trending Topics
> Covering the most timely topics: 
Counter UAS | Artificial Intelligence | Data 
> New products for technology 
725+ exhibitors showcase the full spectrum of technolo-
gies, products and solutions
What’s New in Unmanned Systems for Technology 
http://xponential.org
CIRCUIT CELLAR • FEBRUARY 2018 #3312
OUR NETWORK
SUPPORTING COMPANIES
NOT A SUPPORTING COMPANY YET?
Contact Hugh Heinsohn 
(hugh@circuitcellar.com, Phone: 757-525-3677, Fax: 888-980-1303) 
to reserve space in the next issue of Circuit Cellar.
Accutrace, Inc. C3
All Electronics Corp. 77
AUVSI Xponential 1
CCS, Inc. 77
IAR Systems, Inc. C2
Newhaven Display International, Inc. 19
Siborg Systems, Inc. 11
Technologic Systems, Inc. C4, 77
Issue 331 February 2018 | ISSN 1528-0608
CIRCUIT CELLAR® (ISSN 1528-0608) is published monthly by:
KCK Media Corp.
PO Box 417, Chase City, VA 23924
Periodical rates paid at Chase City, VA, and additional offices. 
One-year (12 issues) subscription rate US and possessions 
$50, Canada $65, Foreign/ ROW $75. All subscription orders 
payable in US funds only via Visa, MasterCard, international 
postal money order, or check drawn on US bank.
SUBSCRIPTION MANAGEMENT
Online Account Management: https://goo.gl/XFbewK
Renew | Change Address/email | Check Status
CUSTOMER SERVICE
E-mail: circuitcellar@pcspublink.com
Phone: 800.269.6301 | 760-738-4970 ext. 124
Mail: Circuit Cellar, P.O. Box 462256, Escondido, CA 92046
Postmaster: Send address changes to 
Circuit Cellar, P.O. Box 462256, Escondido, CA 92046
NEW SUBSCRIPTIONS
circuitcellar.com/subscription
ADVERTISING
Contact: Hugh Heinsohn 
Phone: 757-525-3677
Fax: 888-980-1303
E-mail: hheinsohn@circuitcellar.com
Advertising rates and terms available on request.
NEW PRODUCTS
E-mail: editor@circuitcellar.com
HEAD OFFICE
KCK Media Corp. 
PO Box 417 
Chase City, VA 23924 
Phone: 434-533-0246 
COPYRIGHT NOTICE
Entire contents copyright © 2018 by KCK Media Corp. 
All rights reserved. Circuit Cellar is a registered trademark 
of KCK Media Corp. Reproduction of this publication in 
whole or in part without written consent from 
KCK Media Corp. is prohibited.
DISCLAIMER
KCK Media Corp. makes no warranties and assumes no 
responsibility or liability of any kind for errors in these 
programs or schematics or for the consequences of any such 
errors printed in Circuit Cellar®. Furthermore, because of 
possible variation in the quality and condition of materials and 
workmanship of reader-assembled projects, KCK Media Corp. 
disclaims any responsibility for the safe and proper function 
of reader-assembled projects based upon or from plans, 
descriptions, or information published in Circuit Cellar®.
The information provided in Circuit Cellar® by KCK Media 
Corp. is for educational purposes. KCK Media Corp. makes 
no claims or warrants that readers have a right to build 
things based upon these ideas under patent or other 
relevant intellectual property law in their jurisdiction, or 
that readers have a right to construct or operate any of 
the devices described herein under the relevant patent or 
other intellectual property law of the reader’s jurisdiction. 
The reader assumes any risk of infringement liability for 
constructing or operating such devices.
© KCK Media Corp. 2018 Printed in the United States
THE TEAM
PRESIDENT
KC Prescott
CONTROLLER
Chuck Fellows
FOUNDER
Steve Ciarcia
EDITOR-IN-CHIEF
Jeff Child
ADVERTISING 
COORDINATOR
Nathaniel Black
ADVERTISING SALES REP.
Hugh Heinsohn
GRAPHICS
Grace Chen
PROJECT EDITORS
Chris Coulston 
Ken Davidson 
David Tweed
COLUMNISTS 
Jeff Bachiochi (From the Bench), Bob Japenga (Embedded in Thin 
Slices), Robert Lacoste (The Darker Side), Ed Nisley (Above the Ground 
Plane), George Novacek (The Consummate Engineer), and Colin O’Flynn 
(Embedded SystemsEssentials)
mailto:hugh@circuitcellar.com
https://goo.gl/XFbewK
mailto:circuitcellar@pcspublink.com
mailto:hheinsohn@circuitcellar.com
mailto:editor@circuitcellar.com
circuitcellar.com 3
INPUTVoltage
Jeff Child
T hroughout my career, I’ve always been impressed by Intel’s involvement in a wide spectrum of computing and electronics 
technologies. These range from the mundane 
and practical on one hand, to forward-looking and disruptive 
advances on the other. A lot of these weren’t technologies 
for which Intel ever intended to take direct advantage of 
over the long term. I think a lot about how Intel facilitated 
the creation of and early advances in USB. Intel even sold 
USB chips in the first couple years of USB’s emergence, 
but stepped aside from that with the knowledge that their 
main focus was selling processors.
USB made computers and a myriad of consumer 
electronic devices better and easier to use, and that, 
Intel knew, advanced the whole industry in which their 
microprocessors thrived. Today, look around your home, 
your office and even your car and count the number of USB 
connectors there are. It’s pretty obvious that USB’s impact 
has been truly universal.
Aside from mainstream, practical solutions like USB, 
Intel also continues to participate in the most forward-
looking compute technologies. Exemplifying that, last 
month at the Consumer Electronics Show (CES) show in 
Las Vegas, Intel announced two major milestones in its 
efforts to develop future computing technologies. In his 
keynote address, Intel CEO Brian Krzanich announced the 
successful design, fabrication and delivery of a 49-qubit 
superconducting quantum test chip. The keynote also 
focused on the promise of neuromorphic computing.
In his speech, Krzanich explained that, just two months 
after delivery of a 17-qubit superconducting test chip, Intel 
that day unveiled “Tangle Lake,” a 49-qubit superconducting 
quantum test chip. The chip is named after a chain of lakes 
in Alaska, a nod to the extreme cold temperatures and the 
entangled state that quantum bits (or “qubits”) require to 
function.
According to Intel, achieving a 49-qubit test chip is 
an important milestone because it will allow researchers 
to assess and improve error correction techniques and 
simulate computational problems.
Krzanich predicts that quantum computing will solve 
problems that today might take our best supercomputers 
months or years to resolve, such as drug development, 
financial modeling and climate forecasting. While quantum 
computing has the potential to solve problems conventional 
computers can’t handle, the field is still nascent.
Mike Mayberry, VP and managing director of Intel Labs 
weighed in on the progress of the efforts. “We expect it 
will be 5 to 7 years before the industry gets to tackling 
engineering-scale problems, and it will likely require 
1 million or more qubits to achieve commercial relevance,” 
said Mayberry.
Krzanich said the need to scale to greater numbers 
of working qubits is why Intel, in addition to investing 
in superconducting qubits, is also researching another 
type called spin qubits in silicon. Spin qubits could have 
a scaling advantage because they are much smaller 
than superconducting qubits. Spin qubits resemble a 
single electron transistor, which is similar in many ways 
to conventional transistors and potentially able to be 
manufactured with comparable processes. In fact, Intel 
has already invented a spin qubit fabrication flow on its 
300-mm process technology.
At CES, Krzanich also showcased Intel’s research into 
neuromorphic computing—a new computing paradigm 
inspired by how the brain works that could unlock 
exponential gains in performance and power efficiency for 
the future of artificial intelligence. Intel Labs has developed 
a neuromorphic research chip, code-named “Loihi,” which 
includes circuits that mimic the brain’s basic operation.
While the concepts seem futuristic and abstract, 
Intel is thinking of the technology in terms of real-world 
uses. Intel says Neuromorphic chips could ultimately be 
used anywhere real-world data needs to be processed in 
evolving real-time environments. For example, these chips 
could enable smarter security cameras and smart-city 
infrastructure designed for real-time communication with 
autonomous vehicles. In the first half of this year, Intel 
plans to share the Loihi test chip with leading university 
and research institutions while applying it to more complex 
data sets and problems.
For me to compare quantum and neuromorphic 
computing to USB is an about as apples and oranges as you 
can get. But, who 
knows? When the 
day comes when 
quantum or 
neuromorphic chips 
are in our everyday 
devices, maybe my 
comparison won’t 
seem far-fetched at 
all. 
Quantum Leaps
CIRCUIT CELLAR • FEBRUARY 2018 #3314
@editor_cc
@circuitcellar circuitcellar
COLUMNS
 50 Embedded in Thin Slices
Internet of Things Security 
(Part 1)
Command Injection
By Bob Japenga
 54 The Consummate Engineer
Modulation Fundamentals 
By George Novacek
 58 The Darker Side
Shannon and Noise
Putting the Theorem to Work
By Robert Lacoste
 64 From the Bench
Money Sorting Machines (Part 3)
Bill Validation
By Jeff Bachiochi
TECH THE FUTURE 79 The Future of Industrial IoT
Gearing up for a Post-3G, 
Sensors Everywhere Era
By Brent Ward
71 : PRODUCT NEWS 78 : TEST YOUR EQ
circuitcellar.com 5
 6 Video Gaming Console Uses PIC32
Object Oriented Design
By Dongze Yue and Yixiao Zhang
 
14 Building a VR Arm TrackerSensor Fusion in Action
By Emma Wang, Daryl Sew and Zachary Zimmerman
20 Designing a Home Cleaning Robot (Part 3) 
Circuit Designs
By Nishant Mittal
26 Programmable Ad Hoc Mesh Network 
Meshed-Up PICs
By Raghava Kumar, Brian Clark and Alex Wong
 
SPECIAL FEATURE 34 Electronics Propel Driverless Vehicle Designs Forward
From Assist to Autonomous
By Jeff Child 
TECHNOLOGY SPOTLIGHT 40 Non-Standard SBCs Put Function Over Form
Compact, Low-Power Solutions
By Jeff Child 
PRODUCT FOCUS 46 MCU Development ToolsConnectivity Expands
By Jeff Child
FEATURES
CIRCUIT CELLAR • FEBRUARY 2018 #3316
FE
AT
U
RE
S
Video Gaming Console Uses PIC32
Object Oriented Design
By
Dongze Yue and Yixiao Zhang
T he gaming console we built comes with a demo game called Rope Jumper that we implemented 
with the game engine. We built 
corresponding software libraries to support 
rendering all the game components. Finally, 
we developed an easy-to-use game engine that 
PIC hobbyists can use to develop any game on 
this console. Our motivation to build a PIC32-
based gaming console (Photo 1) came from 
a variety of sources. First, we were aware 
of Nintendo’s popular game “WarioWare, 
Inc.” with all its interesting minigames. And 
we saw how enjoyable it could be to quickly 
switch between different minigames with 
totally different gameplay mechanics [1]. At 
the same time, game engines such as Unreal 
and Unity Engine provide a straightforward 
and elegant way of managing a game into 
components such as scenes and sprite objects. 
The “director/manager” part of the game can 
then load and instantiate the components.
All the objects are arranged in a highly 
hierarchical structure so that loading the 
scene also loads the corresponding objects 
within it. We decided to exploit the possibility 
of synthesizing real-time NTSC video as well as 
supporting all the game mechanics on the tiny 
PIC32 microcontroller. We proposed to build 
a game console that arranges a composite 
video signal, at approximately 3,000 sample/s 
audio output and a polling input from a NES 
Controller. Running on the console is the 
lightweight game engine that is derived from 
the modern game engines that can load and 
switch game scenes when it is triggered by 
user-defined event.
We started by looking into the methods 
of synthesizing video output from the 
microcontroller. Then we moved on building 
the game engine itself with an incremental 
design approach. Wethen implemented the 
demo game, Rope Jumper, using our game 
engine and explored ways of reducing graphic 
artifacts on the display as well as relieving 
heavy memory usage. Figure 1 shows the 
By
Video game systems marry an interesting blend of graphics, computing and 
display technologies. Learn how these two Cornell students designed a Microchip 
PIC32-based gaming console that supports NTSC video output, audio output and 
takes input from an NES Controller.
PHOTO 1
Our PIC32 Analog Video Gaming 
Console (PICGAME) is a portable 
gaming device that supports real-time 
NTSC video output. The Microstick 
II development board contains the 
PIC32 MCU is plugged into a manually 
soldered perfboard, and the board is 
fitted into a laser-cut acrylic casing.
circuitcellar.com 7
FEATU
RES
overall structure of our gaming console.
As described in the block diagram in Figure 
1, PICGAME runs on a core Game Manager 
software block that uses various libraries 
to interface with the peripheral devices and 
synthesize video output. Around the main 
software block there are several hardware 
drivers that drives the controller, video output 
and audio. 
HARDWARE DESIGN
Figure 2 shows a wiring schematic of the 
gaming console. The VIDEO pin and SYNC pin 
are connected via a 2-bit digital-to-analog 
converter (DAC) and produce the composite 
video output. The NES Controller has five pins: 
CLK, LATCH, DATA, VCC and GND. Besides the 
voltage reference pins, the rest of the pins are 
wired to the IOPORTB pin 0-2 of the MCU. The 
audio output is connected to the CVREFOUT pin.
The NTSC standard (RS170) is used for 
generating black and white analog signals 
that display image on closed circuit TV. 
Figure 3 shows a diagram for black/white 
NTSC signal. As electrons sweep across TV 
screen, intensity at each point varies so that 
images are formed.
Full NTSC display video system uses an 
interlaced scanning technique, which updates 
the odd number lines and the even number 
lines alternatively. The signal involves both 
vertical sync signals that divide up even/
odd frames, and horizontal sync signals that 
divide up scan lines. Figure 3 contains a 
breakdown of one horizontal scan line. Due 
to low resolution, we used a progressive 
scanning approach that does not distinguish 
even/odd fields. To generate sync signals that 
meet NTSC standard and produce pixel-wise 
black-and-white information of the image, we 
used a timer that is accurate to one cycle to 
generate the sync pulse and a DMA module to 
get nanosecond accuracy.
The book Programming 32-bit 
Microcontrollers in C: Exploring the PIC32, 
by Lucio Di Jasio, introduced a way of 
synthesizing NTSC video by chaining two DMA 
channels together [2]. But another approach 
FIGURE 1
The gaming console has a core software block called game manager that does the computing and runs all the game related contents. A series of drivers and signal generators lie 
around the main software block, providing support to interface with peripheral devices.
Video
to
monitor
Audio
to
speaker
NES Controller
Takes user
input
Resistor DAC
Combines video
signal and sync
signal into
one analog 
video signal
3.5mm 
audio Jack
Outputs audio
into speaker
Controller driver
Handles
polling of the 
controller 
status
Thread 2:
Controller
Audio driver
Configures the
DMA Channels
to playback
soundtrack
NTSC Driver
Reads the internal
graphic memory
and generates
video signal
NTSC Sync Gen
Generates timer
based vsync
and hsync
pulses
Graphics library
Input event handler
Audio switcher
Game manager
Manager update
Scene renderer
Scene switcher
PIC32
PICGAME Gaming console 
Thread 1: Game manager
CIRCUIT CELLAR • FEBRUARY 2018 #3318
FE
AT
U
RE
S
was available, which we decided to follow in 
the end. This approach was introduced in 
Cornell Professor Bruce Land’s NTSC video 
generation on PIC32, which uses an Output 
Compare module instead of two DMA channels 
to generate the front porch of the signal [3].
VOLTAGE REFERENCE
The PIC32 MCU has an on-chip voltage 
reference module that can be programmed to 
output a reference voltage on an external pin. 
Although originally designed for providing 
reference voltage for the comparator module, 
this module can be configured as a 4-bit DAC 
and produce audio during gameplay. Since 
the VREF module is a 4-bit DAC, we had to 
truncate and fit the original audio data into 
16 voltage level bins. Also, since the MCU only 
has 128 kB flash, we have to resample the 
audio file into a much lower sample rate so 
that the MCU could hold as many audio data 
as possible while still being able to play the 
audio with acceptable quality. To rapidly 
produce the header files for audio data, we 
used Mathwork’s MATLAB’s resample function 
to convert original audio at a sample rate of 
44,100 down to 3,000 samples/s and then 
wrote the data into a C header file that can be 
included into this project.
In order to take user input and be able to 
control the game, we adapted a Nintendo NES 
Controller to interface with the player. The NES 
Controller uses a serial interface to transmit 
a packet of data from the controller to the 
MCU. As shown on the schematic diagram 
(Figure 2), the MCU sets the latch pin high to 
begin transaction and toggles the clock pin 
to emulate clock pulses. As the clock signal 
pulses, the data pin will return the current 
status of a corresponding key. Since there 
are eight keys in total, an unsigned char with 
8-bit length will contain all the information for 
the controller keys.
SOFTWARE DESIGN
In order to operate the game on the 
microcontroller, we needed to implement the 
foreground and background components of 
the game and run them at the same time. We 
wrote with a library written in C that enables 
manipulating screen buffer, rendering 
objects and interfacing with the NTSC video 
output. We packaged all the dependencies 
into a “game engine” so it can be reused for 
developing games.
To support all the game components, we 
built a display library that has accessible 
functions to draw and fill shapes on the 
display buffer that is being synthesized into 
analog video signal in real-time. Since we 
define every pixel to be either black or white, 
we draw or erase pixels on the display by 
setting or clearing the corresponding bit.
To draw lines in a pixelated screen, we 
adapted the Bresenham line algorithm that 
takes in the two sets of coordinates and 
automatically figures out which pixels to fill 
between the starting and ending points [4]. 
We also added support of drawing quadratic 
bezier curves onto the display [5]. To do so, 
we specified three anchor points on the screen 
and used the parametric function to trace 
each point of the curve and fill the points. We 
developed functions to draw rectangles and 
circles on the display buffer, following the 
implementation of Adafruit’s TFT library. 
The game needed to have not only outline, 
but also more filled shapes. So, we also wrote 
functions to fill rectangles and circles line-by-
line. When filling horizontal lines, we directly 
wrote 1’s the display buffer. However, when we 
actually kept erasing and filling a large rectangle 
frequently, we noticed significant blinking on 
the shape. That’s because this filling technique 
is not fast enough when working with large 
shapes. We worked around the problem later 
by avoiding repeatedly re-filling large shapes. 
In the end, we loaded the bitmap data for 
displaying characters on the screen.
We decided to use an object-oriented 
approach for all the in-game components. 
Because of this decision, we designed the 
engine to enable the user to define all the game 
mechanics in the init and update functions 
FIGURE 2
This hardware schematic diagram shows the hardware hierarchy of our system. The synthesized sync pulse 
and image signal are combined into one video output using a 2-bit DAC. The audio output is directly wired 
to the CVref pin on the MCU. All the wirescoming from the controller also get directly wired to GPIO pins 
on the MCU.
circuitcellar.com 9
FEATU
RES
within all the components. Our game engine 
has only one entry point that interacts with 
the outside main function called the game 
manager. Every component of the game is 
defined and encapsulated within the game 
manager object. Therefore, by initializing the 
game manager and routinely calling the game 
manager update function, we will be able to 
initialize and update all the game components 
that belongs to the game manager.
Since there are multiple components 
running at the same time, we adapted 
Protothreads, a lightweight library that 
supports multithreading on microcontrollers 
to support several independent modules at 
the same time [6]. One of the threads we 
created is the main game thread where the 
game manager is initialized and routinely 
called. The other thread is the I/O thread, 
which periodically pulses the clock pin to 
the NES Controller and latches the most 
recent controller status. The controller 
status is saved as a global variable and can 
be immediately accessed by components 
in the game manager. In our configuration, 
we sample the input from the controller for 
100 times a second and update the main 
game 30 times a second.
SCENES AND SPRITES
Inside the game manager, the game 
content is arranged in scenes. Scene is a 
data structure that resembles the idea of 
a “world” which has its own rules, displays 
and mechanics. The scene object contains 
two function pointers that point to the init 
function and the update function of the scene. 
It also contains a list of sprites that the scene 
contains. The init function initializes the 
scene and all the scene’s sprites. The update 
function will update the scene and all its 
children sprites.
Sprite is really the notion of “object” in the 
game. It represents anything on the display 
that has a position and dimension. It also has 
an optional data array pointer that allows 
the video driver to load a corresponding 
bitmap data to the display. Sprite contains 
two function pointers, and those point to the 
init and update function of the itself. There 
are two ways of displaying objects onto the 
screen, one being directly loading the bitmap 
data. The other way is to use the functions 
in the display library to repeatedly erase and 
draw shapes and texts.
We used the three data structures 
introduced earlier to handle different parts 
of the game. For example, consider this 
very basic scenario: A user interface panel 
appears on the screen showing the current 
time and there is also a ball on the side of 
the screen that will bounce up when a user 
taps the controller key. In that example, we 
define two sprites, one for the current time 
text and another for the bouncing ball. The 
game manager then selects the current scene 
to be se scene we just created.
At initialization, the scene will draw the UI 
panel on the screen buffer. While it is doing 
so, the text sprite—which is attached to the 
scene—also gets initialized and keeps drawing 
the current time (saved as a global variable) 
text string on the screen. Finally, the ball 
sprite gets initialized at a given position. And 
ABOUT THE AUTHORS 
Dongze Yue (dy85@cornell.edu) is currently an undergraduate student at 
Cornell University, majoring in Electrical and Computer Engineering. Beside 
all the coursework, he is very interested in embedded system and Internet 
of Things projects in general. He is also a member of a student-led project 
team, Cornell University Unmanned Air Systems or CUAir. In his free time, 
he also makes indie films and does film photography.
Yixiao Zhang (yz624@cornell.edu) is an undergraduate Electrical and Comput-
er Engineering major at Cornell University. Her major interest is in embedded 
system design and system programming. Yixiao has a broad interest in arts. 
She has 10-year membership in Beijing Philharmonic choir, and is a Chinese 
modern dance instructor at Cornell Amber Dance Troupe.
FIGURE 3
Shown here is the detailed breakdown 
of a NTSC line signal. Each new line 
starts with a horizontal sync pulse that 
pulls the pin low and then followed 
by a back porch on the voltage level 
of black image. Then the actual 
video signal comes in, showing the 
brightness of each pixel on the line in 
a 53.6 µs window.
mailto:dy85@cornell.edu
mailto:yz624@cornell.edu
CIRCUIT CELLAR • FEBRUARY 2018 #33110
FE
AT
U
RE
S
since the ball is just a circle, we use the display 
library to repetitively draw/erase the circle on 
the display inside the update function. It also 
checks the current keypress status variable 
that is constantly updated by the controller 
thread. If a keypress is detected, the ball will 
decrease its y coordinate—the user observes 
it to move up.
DEMO GAME
When we finished building all the libraries 
and hardware components, we moved on 
to create Rope Jumper, the demo game. 
The objective of Rope Jumper is to keep the 
character jumping when the rope is swiveling 
past the ground. The player controls the 
character’s jump by pressing A on the 
controller. The character’s jump speed and 
interval are limited, so the player cannot 
blindly spam the controller to hover above the 
ground. The speed of the rope will also change 
when player enters a certain level. Also, the 
center of the rope will move left or right 
randomly when a certain level is achieved.
As shown in Figure 4, the Game Manager 
contains multiple scenes in it. The first 
scene is the main menu that the game loads 
by default. Inside the main menu scene 
there are three sprites, each representing a 
corresponding button. The user can use the 
arrow keys on the controller to switch from 
different buttons. The second scene is a 
countdown scene that elegantly counts three 
seconds and switches to the game scene. 
The third scene is the main game scene that 
contains four sprites: rope, character, human 
and a UI tooltip sprite. Finally, there is a pause 
menu scene which renders a pause menu on 
top of the current game and a credits scene 
that displays the makers of the game.
As shown in Photo 2, when the main 
game scene loads up, it first draws a large 
box around the display as a container of 
all the other visual elements of the game. 
FIGURE 4
This Rope Jumper Game Components 
Hierarchy Diagram shows the 
available scenes under game manager 
as well as all the sprites and system 
components used by each scene.
Rope
jumper:
game
manager
Scenes
Main menu
Sprites
Countdown Text Systemdependencies
Tooltip
UI Box
Text
ISR Driven
clock
Audio
playback
Controller
status
Display
libraryRope
Character
Human
Buttons
Buttons
Load page
(countdown)
The game
Game paused page
Game over page
Credits page
Game engine
demo page
PHOTO 2
This screenshot shows the actual gameplay of Rope Jumper. The two human figures are holding and swinging 
a bezier-curved rope, allowing the character in the middle to jump.
circuitcellar.com 11
FEATU
RES
Next, the scene loads all the attached sprites. 
The rope sprite is a quadratic bezier curve 
that contains three anchor points. To simulate 
the physics of the rope, we fixed the starting 
and ending point of the curve and vary the 
middle point of the curve up and down. That 
makes it look like an elastic rope swinging. We 
also used a sine table to map the y position of 
the middle point, so we can obtain a smooth 
and more realistic rope animation. In order 
to compensate for gravity, we increased 
the falling speed of the rope by 1.5 times 
compared to the rising speed by skipping 
more samples in the sine table.
The character sprite can be found 
in the center of Photo 1. It consists of a 
round rectangle and a text box on top of 
the rectangle. The sprite is drawn at init 
and constantly erased and redrawn during 
update. The sprite also checks the current 
controller status and adds an upward thrust 
to the object whenever a press on the key A 
is detected. Thethrust is treated as a vector 
force so that the character’s velocity and 
position can be computed from it. Once the 
character arises from ground, a new gravity 
force (downward acceleration) will be applied 
to the character to make sure the character 
drops back to the ground.
On the two ends of the rope, there are 
two human sprites that draw the humans on 
the sides. The humans are pixel arrays that 
is generated from MATLAB by reading and 
pixelating a hand sketched human figure. 
The image array contains multiple frames so 
that the human’s arm can move up and down 
with the rope’s rotation. The update function 
of the sprite compares the current rope’s 
rotation position with its frame number so 
that if the rope rotates to a certain angle the 
sprite changes its display frame to be the 
corresponding frame number.
DRAWING HUMANS
Our first approach to displaying motion 
of the humans was to constantly remove 
and redraw the figure when the rope moves. 
However, since the size of the humans is 
fairly large, we saw very blinky images. 
Therefore, in order to reduce visual artifact 
as much as possible, we altered the code to 
only erase and redraw the middle portion of 
the figure that contains the human’s moving 
arm. Since the top and bottom part of the 
figure does not move, they do not need to be 
updated at all. By doing so we were able to 
minimize visual artifact and optimize game 
experience.
LCR-Reader Pro
• 0.5% Basic Accuracy
• LCR- and ESR-meter
• NIST Traceable 
Calibration
LCR-Reader-MP
• L-C-R, ESR, Diode/LED
• 0.1% Basic Accuracy
• AC/DC Voltage, Frequency,
 Pulse Period, Duty Cycle
• 100 kHz Oscilloscope
Shielded Kelvin
Probe Connector
• Smart Tweezers/LCR-Reader
• 5 Replaceable Probes
MADE IN CANADA
Smart Tweezers ST5S-BT
• 0.2% Basic Accuracy
• LCR, ESR, Q/D, Diode Test
• NIST Traceable, 
Blue Tooth
www.lcr-reader.com
LCR-Reader-MP
• L-C-R, ESR, Diode/LED
• 0.1% Basic Accuracy
• AC/DC Voltage, Frequency,
 Pulse Period, Duty Cycle
• 100 kHz Oscilloscope
https://goo.gl/xJxaZM
CIRCUIT CELLAR • FEBRUARY 2018 #33112
FE
AT
U
RE
S
In the end, in order to further enhance 
experience, we wanted to display a floating 
text when the play levels up or encounters a 
new challenge. We decided to create a sprite 
that displays a floating tooltip on top of the 
character when defined events take place. 
Whenever there is a speed up, difficulty 
change or the player loses lives, the tooltip 
sprite generates a text box over the character 
and the text box gently rises up and disappear 
in three seconds. The generation, controlling 
and animation of the text is implemented as a 
state machine so that whenever a new tooltip 
request comes in, it resets the floating text’s 
position, displays the new text and gradually 
shifts the position of the text upwards 
overtime. It also contains an internal counter 
to remove the text after a defined time 
interval expires.
Finally, the game scene actively polls for 
the current controller status so that if user 
presses start key during game, the scene will 
call game manager’s scene switcher function 
to switch the current scene to the pause menu 
scene by reassigning the game manager’s 
current scene pointer to the target scene. 
Therefore, at the next update cycle, the target 
scene will get initialized and scheduled for 
routine update. Also, the scene continuously 
checks for conditions when the user press 
the button too early or too late so that the 
character trips over the rope. When those 
condition are detected, the user will lose one 
life, and the corresponding tooltip will be 
displayed. Once the user loses all the lives, 
the current scene will call scene switcher to 
switch to the scene that displays the game 
over contents.”
RESULTS
As shown in Photo 3, our complete system 
build includes the game console running on 
the PIC32 which has been installed in an 
acrylic casing, a NES Controller that directly 
plugs into the console, a mobile cellphone 
charger that powers up the console and a 
speaker that outputs audio. When powered up, 
our design is capable of rendering up to seven 
scenes—each containing around 5 to 6 sprites 
with independent logic as well as playing a 
looped soundtrack that is 10 seconds long. 
We have used up around 90% of our 128 kB 
programmable memory and every component 
functions robustly.
Actual successful video generation under 
the NTSC standard is an essential foundation 
for all the work we have done in the project. 
The video signal is stable enough so that on a 
normal sized monitor we can clearly identify 
all the components of the game. In the end, 
we have extracted all the depending libraries 
into a distributable game engine for quick 
game development on PIC32. A demo video 
of this project along and a link to our project 
website can be found on the Circuit Cellar 
article materials webpage.
We would like to acknowledge Yuqing Sun, 
another member of our group, for participating 
in the overall scheme proposal and 
contributing to game engine and global 
messaging implementation. 
Additional materials from the author are available at: 
www.circuitcellar.com/article-materials
References [1] through [6] as marked in the article can be found there.
RESOURCES
Adafruit | www.adafruit.com
Mathworks | www.mathworks.com
Microchip | www.microchip.com
PHOTO 3
This shows the complete portable build of our system. A mobile battery pack provides the power for the MCU 
and a portable speaker outputs audio generated by the console. Users can easily plug in the RCA cable to the 
analog video connector shown on the bottom right of the picture and start gaming right away.
http://www.circuitcellar.com/article-materials
http://www.adafruit.com
http://www.mathworks.com
http://www.microchip.com
From home control systems to 
animatronic toys to unmanned 
rovers, it’s an exciting time to 
be a roboticist. Advanced Control Robotics 
simplifies the theory and best practices of 
advanced robot technologies, making 
it ideal reading for beginners and experts 
alike. You’ll gain superior knowledge of 
embedded design theory by way of 
handy code samples, essential schematics, 
and valuable design tips. 
With this book, you’ll learn about: 
• Communication Technologies
• Control Robotics
• Embedded Technology
• Programming Language
• Visual Debugging... and more
Get it today at cc-webshop.com. 
When it 
comes to 
robotics,
the future 
is now!
http://www.cc-webshop.com
CIRCUIT CELLAR • FEBRUARY 2018 #33114
FE
AT
U
RE
S
Building a VR Arm Tracker
Sensor Fusion in Action
By
Emma Wang, Daryl Sew and Zachary Zimmerman
T he three of us had an interest in wearable technology, virtual reality and sensor fusion, so we designed 
a project that drew from all of 
these fields. For a long time, we’ve wanted to 
design an ergonomic wearable that could track 
posture and body position, so we set out to 
design a device that would enable the evaluation 
of form for fitness applications. We also saw an 
opportunity to expand to an immersive martial 
arts video gaming experience.
You can find body pose tracking 
applications in gaming, healthcare and other 
industries. But the more precise systems 
come with a high price tag. An effective, 
low-cost alternative would easily disrupt the 
existing high-end motion tracking market. 
With that in mind, the opportunity for us to 
capture that market niche appealed to us.
To track and ultimately display a 
user’s pose in real time, we used Inertial 
Measurement Units (IMUs) made of gyroscope-
accelerometer sensor units along three points 
of the arm to measure accelerations and 
angular velocities. After some filtering, our 
virtual reality application displays the user’s 
pose and movements by computing joint and 
end-effector positions for given joint angles. 
Commonly known as forward kinematics, this 
process uses translation matrices to represent 
a link (a forearm) and rotation matrices to 
represent a joint(an elbow), and multiplies 
them together to produce an output matrix 
that represents the end effector pose.
Our overall process can be explained as 
follows: While the sensors gather data on 
three axes, the Microchip PIC32MX250f128b 
microcontroller retrieves their register 
contents via I2C communication. The PIC32 
then communicates sensor readings over 
serial to a PC which integrates the readings 
and applies filtering algorithms to produce 
3D positions and orientations. The computed 
results are then used as inputs into a virtual 
reality application for user interaction. We 
would like to acknowledge Kionix for donating 
sensor units for us to use, NumPy for its open-
source computation library and Panda3D for 
its graphics engine.
HIGH-LEVEL DESIGN
We considered several different overall 
approaches to body pose tracking, such as 
computer vision, LIDAR, structured light and 
flex sensor based approaches. We decided 
to use gyroscopes and accelerometers 
By
Wearable technologies, virtual reality and sensor fusion make for a powerful 
combination when all are used together. These Cornell graduates designed 
a low-cost arm controller that translates arm motions into interactions with 
virtual objects using sensor fusion technology.
circuitcellar.com 15
FEATU
RES
because these components are extremely 
low cost and can easily be integrated into a 
wearable device—desirable features for the 
consumer applications we have in mind. We 
anticipated that we would be able to apply 
advanced sensor fusion techniques to bring 
the odometry quality up to par with higher 
cost, higher fidelity sensors.
The accelerometer and gyroscope give data 
that can be used to compute arm trajectory. 
There are several methods to process the 
sensor data, and these methods vary in terms 
of simplicity and accuracy. One method is to 
rely on accelerometer data exclusively. In this 
case, you would use tri-axis accelerometers 
to measure the acceleration in x-, y- and 
z-axes at a particular point on the arm. Using 
standard relations of acceleration, velocity 
and position, we know that this acceleration 
can be integrated to produce a velocity, and 
that integrated velocity will produce position.
Using this method will most certainly 
result in unwanted drift. The solution to 
minimizing the accelerometer drift is to (1) 
calibrate, and to (2) weight the gyroscopic 
and accelerometer data. To do this we 
implemented the complementary filter. The 
complementary filter is essentially a weighted 
average of the gyroscopic and accelerometer 
data. Figure 1 demonstrates the functionality 
of the complementary filter with sample data.
 Accelerometers sense acceleration 
via “differential capacitance arising from 
acceleration induced motion of the sense 
element” [1]. Therefore, electromagnetic 
interference from circuitry can affect the 
quality of the data, so common mode 
cancellation is used to compensate for this. 
The device temperature can also change the 
sensor reading. The benefit of using the Kionix 
accelerometer is its onboard temperature 
sensor and digital signal processor (DSP) that 
applies temperature compensation as well as 
some basic filtering techniques.
DEVELOPING THE POSE PROCESS
Our process from raw data collection to 
body tracking display can be summarized in 
three steps: 1) Collect angle velocities at a 
moment in time: 2) Apply the complementary 
filter to the velocities collected and store the 
inferred orientation; and 3) Input orientations 
in the form of quaternions to the virtual reality 
application and use forward kinematics to 
draw the arm.
We used the Kionix tri-axis gyroscopes-
accelerometer unit, the KXG03, to measure the 
angular velocities and accelerations in x-, y- 
and z-axes at a particular point on an arm. We 
then integrate these complementary filtered 
angular velocities and accelerations from the 
gyroscope to produce the orientation.
Next, we represent the weighted angle 
velocities with quaternions to avoid the 
singularities of an Euler angle orientation 
representation. Similar to Euler angle 
orientation, quaternions indicate the 
difference in rotation between each position 
FIGURE 1
Shown here is a demonstration of a 
complementary filter. Gyroscope data 
dominates at fast moving rates and 
accelerometer data dominates at slow 
moving rates. In other words, outliers 
in the acceleration orientations will be 
ignored when the joint is fast-moving, 
and the gyroscope’s orientation drifts 
will be ignored when the joint is slow-
moving and the acceleration derived 
orientations are high fidelity.
Demonstration of complementary filter
Complementary filter
Gyroscope data
Accelerometer data
1.5
1
0.5
0
−0.5
−1
−1.5
0 5 10 15 20 25 30
Time
Angle
CIRCUIT CELLAR • FEBRUARY 2018 #33116
FE
AT
U
RE
S
of the arm in 3D space. Passing quaternions 
to the virtual reality application allows smooth 
interpolation of data. In the field of robotic 
manipulation, forward kinematics refers to 
the use of a model as a sequence of links 
(translations) and joints (rotations) to produce 
the position of the end effector (given joint 
angles). In that way we are able to predict 
end effector position given only orientation 
measurements.
HARDWARE/SOFTWARE 
TRADEOFFS
In order to read data as quickly as 
possible from the PIC3232MX250f128b and 
IMU connections, we moved as much of the 
computation as possible off the microcontroller 
to a full powered computer. We accomplished 
this by sending the sensor register data to a 
PC via serial communication. Doing this also 
enabled us to use a powerful, but CPU/GPU-
intensive 3D graphics engine—one with more 
compute performance than is available on the 
PIC3232MX250f128b.
By using the I2C bus, we were initially 
under the impression that we’d be able to 
open one channel and connect all gyroscope-
accelerometer sensor units to it—with each at 
its unique address. However, we discovered 
that the sensor unit designs only allowed 
I2C user addressing of one bit—resulting in 
only two unique I2C address per sensor unit. 
That means we could hook up at most two 
gyroscope-accelerometer units on the one 
I2C channel. Our first workaround was to 
retrieve data from the third set of sensor 
units from the second I2C channel on the 
PIC3232MX250f128b. Due to problems 
indicated in PIC32MX250f128b errata, 
transmission from both I2C channels stalled.
Instead of spending more time debugging 
this issue, we moved on to an alternative 
solution. This involved issuing read/write 
instructions to the same address for 
gyroscope-accelerometer and toggling the 
ADDR line of each respective sensor unit. 
Essentially, we implemented a Chip-Select 
function on one I2C channel. We found that 
there were no timing issues with toggling the 
ADDR line across each sensor unit. As a result, 
successful communication was established 
amongst the three sensor units.
Aside from the addressing issue, we found 
the Kionix device versatile and relatively 
hassle-free to use. In an ideal world, it 
would be best to source or work with the 
PHOTO 1
Running controller.py results in real time arm angles being reflected in virtual reality. The user is free to move arm across and around body to interact with the virtual balls.
circuitcellar.com 17
FEATU
RES
manufacturer for the device to use the true 
I2C function. But in the meantime, we offer up 
our implementation as a workaround.
SOFTWARE DESIGN
We created two main chunks of software. 
One we wrote in C code—to compile and load 
onto the PIC32. It was responsible for reading 
sensor data over I2C and sending it to a 
computer over serial. The other chunk we wrote 
in Python. It resides on the computer and is 
responsible for parsing incoming data on the 
serial port, filtering/fusing it, integrating it and 
rendering it via the game library Panda3D.
Starting with the C files, we used 
Protothreads to schedule and connect to 
a PC to communicate over serial. We foundthat adapting the i2c_helper.h file from a 
previous project for its i2c_read and i2c_
write wrapper functions to be immensely 
helpful [2]. The wrapper functions abstracted 
away the I2C methods of reading and 
writing to a register on a sensor. It’s best 
to write these functions based on the sensor 
datasheets and PLIB manual for the sensors 
and microcontroller unit of your choice. For 
increased ease of use, it’s best to implement 
functions for each of the three sensor units, 
and for each accelerometer and gyroscope at 
these locations. Read and write I2C wrapper 
functions can be used for both initializing the 
sensors as well as reading data from them.
We have a total of two threads. One 
thread starts out by writing configuration 
and wakeup values to the sensors and then 
repeatedly reads from the sensors and sends 
their data over serial in the second. Since only 
one thread is scheduled throughout this whole 
process, the program reads and sends sensor 
values at maximum configuration speed, 
provided that the baud rate is set proper.
The protocol we designed for sending data 
over serial uses spaces to delimit registers 
from the same sensor, newlines to delimit 
different sensors and the word “init” followed 
by a newline to delimit sensor readings at 
different timesteps. This protocol enables 
the corresponding Python script to connect 
to the device at any time as the script can 
use inits to separate out sensor readings by 
timestamp.
The following is an example data chunk 
from one timestep containing the angular 
velocity and acceleration readings from 
the gyroscope-accelerometer unit. You can 
compare results but note the variations due 
to sensor fabrication and other settings:
init
6 34 8 -899 -14546 -9824
32511 40 28009 9119 -867 11209
36 -259 -261 -3954 -2928 14885
PYTHON FILES
These were run on Mac OS, but all 
applications can be configured to run on 
Windows or Linux.
controller.py: This file runs the virtual 
reality application and displays the user’s 
arm movements in real-time (Photo 1). We 
enabled concurrent execution of the game 
and reading from serial in a while True loop. 
Thanks to the global interpreter lock, the 
only way to be truly concurrent in Python 
is to use process concurrency through 
inter-process communication. As such, we 
implemented a shared queue that the read_
sensors.py process uses to communicate 
odometry data over to the process rendering 
the game.
read_sensors.py: In this file, we use 
pyserial to read incoming data on the 
serial port and parse it into custom classes 
for accelerometer data and gyroscope data. 
We implemented a calibration period of 
three seconds over which we asked the user 
to extend his/her arm horizontally outward 
with all three IMUs facing upwards. We 
required that the devices be at rest during 
this time. The first 120 sensor readings we 
collected during calibration were averaged 
and used for initial values after which we 
integrated for relative changes in position 
and orientation. The calibration offsets 
depend on the location and temperature.
 In the read loop, we integrate the data 
and update an odometry dictionary, which 
keeps track of the position and velocity of 
each sensor. If run as main, this file prints out 
the sensor values it is reading. We also apply 
the complementary filter to the orientation, 
where the angular velocity is replaced by 
0.97 x angular_velocity + 0.03 x acceleration. 
ABOUT THE AUTHORS 
Emma Wang (exw2@cornell.edu) graduated from Cornell in 2017 with a B.S. 
Electrical Engineering, and Operations Research and Industrial Engineering. 
She currently works at Johnson Controls as an Electrical Engineer within the 
Special Hazards team. Her interests are in circuit design,and she has a pen-
chant for developing wearables and spending time in her community.
Zachary Zimmerman (zacharytzimmerman@gmail.com) graduated from the 
Cornell in 2017 with a B.S. in Computer Science. He currently works at Micro-
soft doing rapid prototyping for new technologies. His interests include design 
and ergonomics, computer graphics programming and game development.
Daryl Sew (darylsew@gmail.com) graduated from the Cornell College of En-
gineering in December 2016 with a B.S. in Computer Science. He currently 
works at Snapchat on computer vision and augmented reality. He’s passionate 
about game design and robotics.
mailto:exw2@cornell.edu
mailto:zacharytzimmerman@gmail.com
mailto:darylsew@gmail.com
CIRCUIT CELLAR • FEBRUARY 2018 #33118
FE
AT
U
RE
S
Each output by the complementary filter 
generates a quaternion.
game.py: In this file, we created a virtual 
representation of an arm in a sandbox 
environment, allowing users to interact with 
objects on the screen just by moving his/
her arm. Our game is made to demonstrate 
these capabilities by letting the user hit balls 
and watch them bounce around a ball pit 
according to physics simulation.
You need several Python BSD compatible 
libraries to speed up the software development 
process. All of these can be found with a search 
engine. We chose libraries that were compatible 
with our system and easy for us to use.
pyserial: This is used to process incoming 
information on the serial port and can easily 
be found using a search engine.
Panda3D: Used to render the virtual arm 
visualization. We found this application through 
a search engine and chose this application for 
its ease of use and compatibility.
NumPy: Used for fast numerical 
computation. Described as the “fundamental 
package for scientific computing with Python”.
matplotlib: Used for creating graphs. This 
was helpful when debugging and discovering 
the value of our position data.
HARDWARE DESIGN
The PIC32MX250f128b serves as the 
intermediary link between the sensor units 
and the PC. It drives the I2C1 lines and the 
serial communications. Pins 17 and 18 are 
reserved for the I2C channel—pin 21 is UART 
transmission and pin 22 is UART receiving.
FIGURE 2
IMU Sensors are placed along the right arm. Each joint, shoulder, elbow and wrist receive an IMU. Gyroscope 
and accelerometer data from each location is fused to generate and track arm position.
Elbow
Wrist
Shoulder
IMU Sensor location on body
FIGURE 3
This shows the system’s wiring. (a) PIC32MX250f128b Wiring, note the construction of proper voltages to drive the ADDR pin of each KXG03 sensor unit; (b) Constructing proper 
VDD for KXG03 units with diode voltage drop; (c) KXG03 wiring, note wiring is identical among the three units except for the ADDR pin
a) b)
c)
Shoulder - Gyro/Accel Elbow - Gyro/Accel Wrist - Gyro/Accel
circuitcellar.com 19
FEATU
RES
In order to safely power the KXG03 sensors, 
we had to construct proper voltages. Drawing 
from the 3.3 V of the PIC32, we dropped 
down the voltage by using the diode to bias 
to approximately a 0.7 V drop. Ground the 
signal of this divider through a 1 kΩ resistor, 
using 10 µF and 0.1 µF capacitors to eliminate 
transients. You can also directly source from 
a power supply set to 2.6 V.
The toggling address Chip Select lines 
also need to be alternating at 2.6 V and 0 V. 
The proper voltage must be constructed in 
this case because of the toggle instruction 
originating from the PIC32. A voltage divider 
with the properly ratio of resistors is used to 
create the voltage for each sensor unit. This 
needs to be down with each address toggle 
line. In this case, that means providing three 
unique voltage dividers for each of the three 
sensor units.
The sensor units used are three of the 
KXG03 gyroscope-accelerometer units. They 
are also referred to as IMUs. The IMUs are 
placed along strategic mapping points along 
the limb—in this case an arm—at the shoulder, 
elbow and wrist (Figure 2). Essentially, each 
joint receives an IMU.
Each of our IMUs receive VDD, IO_VDD 
(same value as VDD), GND, I2C channel, 
1 CLK and data lines, and a line that toggles 
the last bit of I2C address to 1 or 0. Using 
the PIC32MX250f128b,we assigned 3 pins to 
toggle the ADDR line of the shoulder unit, the 
elbow unit, and the wrist unit. We used open 
pins 4,5 and 6. See Figure 3 for a detailed 
overall schematic.
RESULTS
We are pleased with the result of 
the project. The device enables users to 
manipulate objects in a virtual world when 
moving their arm around. We are happy that 
the complementary filter proved effective 
in eliminating orientation drift. As demos 
show, implementing the complementary 
filter produced orientation measurements 
that were impressively precise. With a 
PIC32MX250f128b baud rate of 115,200, we 
were able to read from all three sensors at 
approximately 41 Hz. Enabling high speed 
I2C mode compatibility on the devices and 
microcontroller could possibly result in higher 
quality odometry. That’s because a higher 
quantity of sensor data would enable us to 
improve our fusion algorithms.
Using a complementary filter substantially 
increased the overall usability of our 
application. We went from having arm drift 
from the beginning (0 seconds) to being able 
to run for up to two minutes before having 
to reset to eliminate drift. If you have good 
ground truth measurements for arm motion 
then you would be able to provide a more 
quantitative analysis of your accuracy. In 
testing, we found that movement passing 
through the initial calibration position 
periodically at about 1-minute intervals also 
helped the drift to correct itself.
For code and details, go the Circuit Cellar 
article materials page. You can view our 
results and there are two demo videos 
where we demonstrate the use of our system 
and give brief explanations of its inner 
workings. 
Additional materials from the author are 
available at: 
www.circuitcellar.com/article-materials
References [1] and [2] as marked in the 
article can be found there.
RESOURCES
Kionix | www.kionix.com 
Microchip | www.microchip.com
NumPy | www.numpy.org
Panda3D | www.panda3d.org
EVE2
4
3
2
1
TFT Modules
Find a discount code and learn more 
about these cutting-edge products:
Power Re-Envisioned
NHdisplay.com/EVE2cc1
sizes
These Capacitive & Resistive 
Touch HMI displays feature:
media types
connectors
powerful chip
3.5”, 4.3”, 5.0” and 7.0”
High-res graphics, video and audio
Standard 20-pin FFC and IDC
EVE2 graphic engine by FTDI/Bridgetek
http://www.circuitcellar.com/article-materials
http://www.kionix.com
http://www.microchip.com
http://www.numpy.org
http://www.panda3d.org
https://goo.gl/g8NYTT
CIRCUIT CELLAR • FEBRUARY 2018 #33120
FE
AT
U
RE
S
Designing a Home Cleaning 
Robot (Part 3)
Circuit Design
By
Nishant Mittal 
Cypress Semiconductor
I n the previous two parts (Circuit Cellar 329, December 2017 and Circuit Cellar 330, January 2018) of this home cleaning 
robot article series, I setup the base of 
the system and its mechanicals and put the 
components together. In this and in next 
month’s part, I’ll delve into the electronics 
and algorithms needed to make the automatic 
home cleaner work.
Figure 1 shows the block diagram of the 
electrical system. Because this is a mobile 
system, a battery will be used instead of 
bench-top power supply. Because of the size 
constraints of this system, we’re using a 9 V 
battery. Two voltage regulators are needed: 
one boost regulator for 9 V to 12 V, and one 
buck regulator for 9 V to 5 V conversion. These 
voltages are mostly required to drive the 
motor and sensors. All the data processing and 
data transfer happens through the controller 
module from Cypress Semiconductor: the 
CY8CKIT-042 BLE.
In this next installment of his four-part article series about building a home 
cleaning robot, Nishant discusses the circuitry behind the system. This involves 
the selection of the electronic components and optimizing the system for overall 
power consumption.
FIGURE 1
Block diagram of the electrical system
Header for fitting
CY8CKIT-042 BLE
Module
Gnd 12 V 12 V
12 V
12 V
5 V
5 V
Motor1Motor2
Motor4Motor3
Motor Driver
IR Sensors
Six sensors
Motor Driver
Regulator
Regulator
Example of a basic iRobot cleaning robot 
(Image courtesy of www.irobot.com)
http://www.irobot.com
circuitcellar.com 21
FEATU
RES
This module is very easy to use. You can 
make a custom board to meet your system 
requirements and then hook up this module to 
your custom board—and that’s what we did in 
our design. Photo 1 shows the CY8CKIT-042 
BLE module we used. This module contains the 
PSoC 4200 BLE which is capable to handling 
all kinds of digital and analog processing 
within a single SoC. This SoC not only does 
data processing, but also embeds Bluetooth 
functionality—resulting in an extremely low 
cost and compact solution.
The next important component choice 
is the battery. When choosing a battery, we 
had to consider current rating (in mA-hours) 
and the required voltage. Higher the voltage 
rating, the bigger the battery needed. We 
needed a battery with long life and a decent 
voltage and current rating. The battery also 
had to be rechargeable, low cost and long 
lasting. With all that in mind, we chose the 
HPB Power battery with 2,200 mA-hours and 
9 V at 2 A. Photo 2 shows the battery—a 
lithium polymer cell.
The next design element to be selected is the 
sensor. Here, we chose an IR sensor although 
an ultrasonic sensor was an option. Both have 
their own advantages and disadvantages. 
Instead of designing our own modules, we 
bought the module shown in Photo 3. In 
this module, we can tune the distance. The 
module contains the circuitry that modulates 
the signal received and converts into digital 
data. That data is then fed to the input of the 
microcontroller. Using the potentiometer, the 
modulation can be tuned to mark the distance 
of object detection.
CIRCUIT DESIGN
We’ll begin the discussion of the circuit 
with the power supply design. As mentioned 
earlier, we have a 9 V, 2 A input. That is split 
into 12 V and 5 V as shown in Figure 1. To do 
that, we needed to design a buck regulator 
and a boost regulator. The boost regulator is 
needed for 9 V to 12 V conversion. For that 
we chose a Texas Instruments (TI) LM2585 
chip. The LM2585 is a fly back boost regulator 
with has a switching frequency of 100 kHz 
and a wide input voltage range of 4 V to 40 V. 
Figure 2 shows the design of boost regulator. 
The resistor calculation for this is determined 
using the equation:
V V R
R
where V Vout ref ref= × +



=1 123
125
1 23 .
A 1% tolerance metal film resistor is 
recommended for better accuracy. Figure 2 
shows the circuit diagram of the same which 
is designed for this project.
PHOTO 2
Lithium polymer battery for the home cleaning robot
PHOTO 1
Cypress CY8CKIT-042 BLE module
PHOTO 3
IR sensor module
FIGURE 2
Boost regulator 9 V to 12 V
CIRCUIT CELLAR • FEBRUARY 2018 #33122
FE
AT
U
RE
S
Next up is the buck regulator. We went with 
a switching regulator instead of a low drop out 
(LDO) regulator. That’s because we are using 
DC motors that wouldn’t perform efficiently 
using an LDO as a power source. We needed 
a buck regulator with a 9 V to 5 V output. The 
power module from TI called LMZ14203HTZX/
NOPB meet these requirements. This regulator 
requires minimal circuit elements to make the 
chip work. This chip has an internal shielded 
inductor which makes the PCB design easier. 
This regulator has soft start-up sequencing 
using external soft start and precision enable. 
This regulator drives loads up to 3 A with 
good power conversion efficiency and output 
accuracy.
The regulated output voltage determined 
by external divider resistors RFBT and RFBB is:
Vout V RFBT
RFBB
= × +



0 8 1.
This resistor should be between 1 kΩ to 
50 kΩ. Figure 3 shows the circuit diagram of 
the power module for 9 V to 5 V converter 
used in this design.
Figure 4 shows the motor driver circuitry. 
Here, we’ve used the L293D from TI, which 
can be used to drive two motors using a single 
IC. That means a total of those of theseICs 
are required. The IC needs two power sources 
at 12 V and 5 V—5 V at Vss and 12 V at Vs. This 
is to drive the motor directly using 12 V while 
the IC voltage is at 5 V.
Figure 5 shows the I/O header for 
inserting into the CY8CKIT-042 BLE module. 
We’d needed as many as 8 pins for the motor 
and 6 pins for the sensors—however other 
pins are brought out as GPIOs. Figure 6 
shows the connector used to insert the sensor 
shown in Photo 3. These sensors are readily 
available on any electronics hobbyist website. 
These sensors are easy to use direct digital 
output sensors which can be connected to the 
PSoC. The enable pin for these sensors are set 
by default to ground because they are active 
low. However, these can also be connected to 
the GPIO pins and can be driven according to 
application needs.
PCB DESIGN
Because our board contains switching 
regulators, designing the PCB appropriately is 
very important. Very fast switching current 
around long tracks and inductance generates 
voltage transients which can cause problems. 
For minimum ground loops and inductance, 
track lengths need to be as short as possible. 
Single point grounding or a ground-plane 
based approach is recommended for best 
results. Power grounds and signal grounds can 
FIGURE 3
Power module (buck converter)
FIGURE 4
L293D motor driver
FIGURE 5
CY8CKIT-042 BLE header for module placement
circuitcellar.com 23
FEATU
RES
FIGURE 6
Sensor connector
PHOTO 4
(a) bottom track of board. (b) top track of board
FIGURE 7
Feedback routing of the power module on board
VIN
VIN
Loop 1
VOUT
CIN1
High
di ⁄dt
GND
Loop 2
VO
CO1
LMZ14203H
CIRCUIT CELLAR • FEBRUARY 2018 #33124
FE
AT
U
RE
S
also be separated. But that’s not necessary, 
provided there is analog processing circuitry 
on board. Decoupling capacitors should 
be placed as close to the chip as possible. 
Photo 4 shows the overall routing of the top 
and bottom layers. A file available on the 
Circuit Cellar article materials page can be 
used as a reference for the design.
For the power module, poor board layout 
can disrupt the performance of the DC-DC 
converter and surrounding circuitry due to 
electro-magnetic interference (EMI), ground 
bounce and resistive voltage drop in the traces. 
These can send error signals to the converter 
making the output poorly regulated and 
unstable. Apart from those considerations, a 
good power module PCB design should provide 
short feedback paths. It’s also important 
to place a feedback resistor near the chip 
to ensure stability. A lot of heat sinking vias 
should be placed around the board. Those will 
also help to keep the ground uniformly spread. 
Figure 7 shows the feedback routing of the 
power module to be designed.
Photo 5 shows the placement diagram 
of the PCB. The power supply section 
is towards the left with all components 
placed as close as possible. The Motor 
driver is placed in the center so it can 
be distributed throughout the board. 
Sensors are placed all around the board 
to be in line with the mechanical system. 
Photo 6 shows the finally assembled board.
In this part of the article series we covered 
electronics part of the system—the selection of 
components, designing of the elements, power 
supply, PCB design and so on. In the final 
article next month, we’ll explore algorithms 
and programming of the system. 
PHOTO 5
Placement diagram
PHOTO 6
Finally assembled board
ABOUT THE AUTHOR 
Nishant Mittal is a Systems Engineer at 
Cypress Semiconductors in Bangalore,
India.
Additional materials from the author are 
available at: 
www.circuitcellar.com/article-materials
RESOURCES
Cypress Semiconductor | www.cypress.com
Texas Instruments | www.ti.com
http://www.circuitcellar.com/article-materials
http://www.cypress.com
http://www.ti.com
http://www.cc-webshop.com
CIRCUIT CELLAR • FEBRUARY 2018 #33126
FE
AT
U
RE
S
Programmable Ad Hoc Mesh Network
Meshed-Up PICs
By
Raghava Kumar, Brian Clark and Alex Wong
A s a final project for an upper level technical course at Cornell, we built low-cost, programmable 
mesh network. It can be used 
to build motion sensitive alarm systems, 
automatic lighting, door alarms and various 
other home automation systems in a matter 
of minutes. Our motivation for this project is 
the high cost and low extensibility of existing 
home automation solutions. We believe that 
cutting edge IoT functionality can be delivered 
at a fraction of the cost of these systems, and 
are using this project as a proof-of-concept of 
a versatile, configurable and scalable network 
that costs less than $20-per-node. To do this, 
we used a distributed mesh network capable 
of defining relations between inputs and 
outputs across nodes.
At the heart of our project is a version of 
the Ad hoc On-Demand Distance Vector (AODV)
[1] routing algorithm. It is used in popular 
wireless protocols such as Zigbee. This 
algorithm is capable of learning, storing, and 
updating paths through a network as needed. It 
can therefore support any presented network 
topology. We implemented this algorithm on 
the Microchip PIC32 microcontroller, and used 
the Nordic NRF24 (nRF) radios to facilitate 
wireless communication among nodes.
To demonstrate the power of this network, 
we used it to build a programmable home 
automation system. Each node in our system 
has one (analog or digital) input and one 
output, to which a variety of sensors and 
actuators may be connected. The system is 
controlled by a “master” node that is capable 
of querying any node’s input, controlling every 
node’s output and setting arbitrary logical 
relationships among the inputs and outputs 
of other nodes in the network (Photo 1). The 
master leverages the mesh to perform these 
tasks, so it doesn’t need to be in direct range 
of the nodes it is configuring. Once these 
relationships are configured, the mesh can 
operate independently of the master, and 
can be used for a variety of “if-then-else” 
automation tasks.
To manage complexity in our project, we 
divided the system into the logical components 
shown in Figure 1. These are loosely based on 
the standard Open Systems Interconnection 
(OSI) model. The bulk of our work was devoted 
to developing, integrating and optimizing the 
top the layers of this stack: application, mesh 
and radio. The NRF24 library was developed 
earlier by Douglas Katz and Fred Kummer and 
used with minor modifications and edge case 
corrections.
APPLICATION LAYER
The application layer of our project is 
designed to allow users to control various 
Can cutting edge IoT functionality be delivered at lower costs than today’s 
expensive home automation solutions? These Cornell students set out to 
prove that they can with their programmable mesh network project based on 
Microchip’s PIC microcontroller.
PHOTO 1
Shown here is our master node 
plugged into the USB port of a 
laptop.
circuitcellar.com 27
FEATU
RES
devices, monitor the status of sensors and 
set logical relations to automate tasks in their 
home with a few keystrokes. For instance, our 
system may be used to:
● Remotely control the intensity of any 
connected light in the house
● Check the temperature of every room their 
house from the comfort of their bed
● Automatically turn the lights on when it is 
too dark in the kitchen
● Configure what it means for it to be “too 
dark”
● Turn the lights off if no motion is detected 
in a room
● Set off a buzzer whenever the fridge door 
is left open
Our code is designed to be as flexible as 
possible, enabling the system to interface 
with a variety of analog sensors, motors, 
servos, LEDs and so on. Every node is capable 
of generating events that can affect other 
nodes, and maintains logical tables that 
determine which events can modify its output. 
The user can configure these settings using 
the master node, and therefore set arbitrary 
relationships between the inputs and outputs 
of other nodes.
All functions of the application layer 
are supportedthrough a custom, byte-
encoded message protocol. We designed 
these messages to be short (so they can be 
transmitted reliably on the radio modules), 
easy to parse (to minimize microcontroller 
loading) and expose as little of the underlying 
software implementation as possible. Our 
system consists of the network messages 
shown in Table 1. Messages that can only 
originate from the master node are marked 
with an asterisk.
The application layer supports user 
FIGURE 1
We divided our project into 
independent layers that interacted 
using clean APIs. These layers are 
based on telecommunications layers 
defined in the OSI model, and helped 
us manage complexity effectively.
TABLE 1
Application layer functionality is implemented through a set of custom messages that allow nodes to generate and subscribe to events. The messages marked with an asterisk can 
only be sent by the master node for node configuration.
Message Semantics
Force* Force a node’s output high or low
Query* Check the value of a node’s input, or any of its configurable parameters
Query Response Reply to the master with a requested value
Event Inform subscribers that the node’s input has just been turned high or low
Config* Configure a node parameter (see Table 2)
Add Event* Add a dependency to a node’s output
Add Subscriber* Add a subscriber to the node’s events
Remove Events* Remove all dependencies for a node’s on or off state
Remove Subscriber* Remove an event subscriber from this node’s subscriber list
CIRCUIT CELLAR • FEBRUARY 2018 #33128
FE
AT
U
RE
S
interaction through the master node, 
which can be plugged into the USB port of 
a computer. Communication is facilitated 
using a CP2102 UART-to-USB converter, and 
is used to provide a command line interface 
to the user. User commands are parsed by 
the master node, and essentially translate 
to one or more network messages. A sample 
screenshot of this interface is shown in 
Figure 2.
The functions of the application layer 
are supported by the mesh layer, which is 
responsible for path discovery and message 
forwarding. The interface between these two 
layers is implemented using a mesh level send 
function that routes messages within the 
network, and a receive callback function that 
alerts the application layer when a message 
addressed to this node is received. To use 
the mesh-level send function, the application 
layer simply inputs a message and destination 
node and lets the mesh layer handle the rest.
MESH LAYER
The mesh layer of our project is 
designed to provide a robust, reconfigurable 
networking protocol for the multiple PIC32 
nodes. The protocol borrows heavily from 
the well-established AODV algorithm with 
several design changes to simplify the 
software and improve reliability. The main 
features of the network are: multi-node path 
communication, dynamic route discovery 
and dynamic route reconfiguration. Multi-
node path communication is essential for 
our project in order to provide an adaptive 
distributive network. This protects against 
possible attenuation between two nodes 
by allowing communication through other 
nodes. Dynamic route discovery allows for 
each node to actively determine the shortest 
route to another node. Finally, dynamic 
route reconfiguration enables our network 
to maintain efficient communication by 
constantly updating routes.
Each node is loaded with almost identical 
mesh network software, with the only 
difference being individual software-defined 
node IDs. These are defined in a header file at 
program time and can be changed to include 
more nodes into the network. As shown in 
Table 2, only 1 byte is allocated for each field 
in our message sending structs, with one of 
them being the node ID. Because of this, there 
is currently a limit of 256 nodes in the network 
for this particular iteration of the project. In 
the future, it would be very simple to modify 
the struct to have more bits and thus enable 
more nodes in the network.
A cache is used to house path information 
for each node which, upon startup, is initially 
empty. Each cache is implemented via an array 
and pointers to the destination node, the next 
node to hop to (for multi-node hops) and the 
total number of hops. When the send function 
is called by the application layer, the mesh 
layer will receive information on the source 
node, destination node, message and message 
FIGURE 2
The user can configure the network 
through a simple command-line 
interface. They can query the status 
of a node, force it on/off or build 
links between different nodes in the 
network.
circuitcellar.com 29
FEATU
RESsize. The cache will be searched for a cache 
entry that contains a path to the destination. 
If one is found, the cache hits and the mesh 
layer can send immediately by transmitting a 
packet with the data—along with a prepended 
7-byte header for information—to the next 
hop node. Otherwise—if there is a cache 
miss—it will begin the cache miss process. 
We’ll detail that miss process more later.
Assuming a cache hit, the next hop node 
will decode the packet and see whether it is a 
data packet to forward or to receive. This node 
will also have a cache entry to the destination, 
so when the send function is called again, 
it will always respond with a cache hit and 
send. This is shown in Figure 3 which shows 
a cache hit for a multi-node message send. 
In this case, the source node, Node 50, will 
have the destination node in its cache with 
the next hop address field being Node 20. 
Node 20 receives this message and because 
of the way we propagate RREP messages, 
will also have a cache hit. The data message 
is therefore sent forward to the destination 
node, Node 10. If there is a cache miss, then 
there is currently no path from the current 
node to the destination. As a result, the route 
request routine must be started.
ROUTE DISCOVERY
In addition to having multi-node sending, 
it is also important to be able to discover 
new routes from source nodes to destination 
nodes. By having a dynamic routing algorithm, 
the network is able to easily acclimate to 
losing connection with individual nodes. Upon 
initialization of the network, the first possible 
event that can happen is the master node 
sending out any command. The master node 
attempts to send to another node which it has 
not established route information for, since 
no paths are known. In this case, there will 
be a cache miss which will begin the dynamic 
route discovery routine.
The dynamic route discovery routine 
works by first sending a Route Request (RREQ) 
message via a network flood. The RREQ 
message acts as a broadcast to all nodes 
saying that the source node does not have a 
path to the destination node. Any node which 
receives the RREQ has two options: forward 
the RREQ message by flooding its own RREQ 
message or return a Route Reply (RREP) 
message, signifying that it knows a path to 
the destination through itself. It either has a 
path in its cache or is in fact the destination 
node. Because of this, all nodes that have 
propagated forward the RREQ will also be 
able to fill in its cache information about the 
path. Eventually the source node will receive 
the RREP message and fill in its own cache 
before sending actual data packets through 
the found path to the destination.
In order to properly forward the RREP 
message to the original requester of the path, 
the path that was taken by the RREQ message 
must be reversed. This is done by storing 
the propagator of the RREQ flood message 
in every node in the path. If a node receives 
a RREP, it’s because it was either one of the 
nodes along a constructed path, and should 
forward the RREP to the node that sent it 
the corresponding RREQ, or the source. This 
means after a RREQ has been propagated to 
the destination node, the RREP will exactly 
retrace the path of the RREQ. This is shown 
in Figure 5, which shows how the RREQ and 
RREP routines work. In this case, we have 
a networkwith 3 nodes with Node 50 and 
Node 10 far apart and Node 20 acting as an 
intermediary node.
In this specific case, the nodes are in 
startup with empty caches. We have Node 
50 attempting to send to Node 10 so it 
floods the network with a RREQ message. 
Node 20 receives this and realizes that it 
Type BYTE 0 BYTE 1 BYTE 2 BYTE 3 BYTE 4 BYTE 5 BYTE 6
Message Header type size src addr dst addr hop addr num hops curr hop
RREQ Message broadcast id dst addr dst seq cnt sec addr src seq cnt hop cnt pad
RREP Message dst addr dst seq num src addr lifetime pad pad pad
Route Table Entry dst addr dst seq num valid flag hop count next hop addr lifetime network int
TABLE 2
This table shows the byte-level 
encoding of the various message 
headers used in the mesh networking 
protocol.
FIGURE 3
This graph shows how the message headers used in the mesh network change in order to allow multi-node 
hopping. Here we are only viewing sent message packets. In this case the first number represents the type 
of the message (a data message, for example), the second number represents the source node ID, the third 
is the destination node ID and the last is the next hop node ID. In this example, the packet types are only 
data messages which has an ID of 0. The rest are self-explanatory.
Message legend:
Packet type | Source ID | Destination ID | Next hop ID
Node
50
0|50|10|20 0|50|10|10
Node
20
Node
10
CIRCUIT CELLAR • FEBRUARY 2018 #33130
FE
AT
U
RE
S
is not the destination and it has no path to 
the destination so it propagates it forward 
to Node 10. Node 10 receives this and is the 
destination so it sends back a RREP message 
to the node which flooded it, Node 20. Node 20 
receives this and fills its cache and propagates 
the RREP message to which node flooded it, 
Node 50. This then receives it and fills its own 
cache before sending out a data message. 
Figure 6 is a variant of a similar procedure 
except in which the distances between all 
nodes are arbitrary. In this case, Nodes will 
ignore multiple floods from the same source.
There is a lot of startup overhead in terms 
of filling in all of the node’s caches and flooding 
the network with RREQ messages and RREP 
messages (Figure 7). But this networking 
algorithm works very efficiently for both very 
small networks with close proximity nodes 
and also for very large networks with many 
nodes. In the first case, the discovered paths 
will generally be direct paths. That’s because 
simply receiving a message and returning at the 
destination is faster than processing multiple 
floods. For large networks, this topology is 
almost necessary to have in order to ultimately 
achieve efficient paths between the nodes. 
Furthermore, this system was designed to be 
long-term with a very long battery life. Because 
of this, the large startup overhead needed for 
achieving full network throughput is weighed 
against getting the fastest path between all 
nodes at steady-state.
In regards to our abstraction layers, the 
mesh layer provides a simple send function 
to the application layer and uses the latter’s 
receive callback function. The mesh layer in 
turn uses the radio layer’s send function to 
actually send messages between nodes. In 
addition, it provides its own receive callback 
function for the radio layer to use.
RADIO - HARDWARE LAYER
At a high level, we wanted our nodes to 
be simple, lightweight and easy to interface 
with. In order to fulfill these requirements, we 
minimized physical node size and put effort 
into streamlining the nodes for our users.
Each node consists of the following key 
components:
● nRF24l01+ Radio Transceiver
● 3 AA battery pack
● PIC32 microcontroller
● TFT header for debugging
In order to create a fully functional 
independent node for practical use, several 
factors had to be considered when designing 
the nodes. A node that’s too fragile, too large, 
too expensive or even required too much 
power would be impossible to implement from 
a practical standpoint. With all that in mind, 
we decided to use the PIC32MX250F128b 
microcontroller as the processor for our nodes. 
This inexpensive, easy-to- implement and hard-
to-break chip enabled us to use the required 
libraries and tap into enough processing power 
to meet our network demands while drawing 
very low amounts of current. Figure 8 shows a 
component-level circuit schematic diagram for 
each general node.
The PIC32 and nRF24L01 require a constant 
3.3 V power supply, so three 1.5 V batteries are 
fed into a 3.3 V regulator to provide a constant 
power source. There is about a 1 V drop across 
FIGURE 4
This illustrates a route discovery routine where the source floods the network with a RREQ message and an 
intermediary node with a path receives it and sends back a RREP message. In this case we have two types 
of packets—we have 1 = RREQ and 2 = RREP.
Message legend:
Packet type | Source ID | Destination ID | Next hop ID
Node
50
1|50|10|
2|50|10|50
Node
20
Node
10
FIGURE 5
This shows how the route discovery routine functions. Intermediary nodes will re-flood original flood 
messages while changing the next_hop field. This enables the destination node to send a route reply message 
using the newly discovered path.
Message legend:
Packet type | Source ID | Destination ID | Next hop ID
Node
50
1|50|10
2|50|10|50
Node
20
Node
10
2|50|10|20
1|50|10|
circuitcellar.com 31
FEATU
RES
the voltage regulator. This power is fed into the 
nRF Vin pin and hooked up to the PIC32.
Besides these considerations, the hardware 
design was fairly straightforward. This is 
because the hardware was designed to be as 
flexible as possible, leaving as much room as 
possible for various configurations. With the 
minimal hardware on board, the PIC32, TFT 
and radio drew 100 mA of current in steady 
state—enough for about 20 hours of battery 
life. However, if further optimizations were 
made to the radio, and if we tapped into low-
power modes for the PIC32, or removed the 
TFT, longer battery life could easily be achieved.
Each node except for the master contains 
an optional TFT display so that the actual 
packets going through the networked can 
be visualized. This is useful for debugging 
purposes as well as ensuring correct 
operation of various attachments put onto the 
nodes. The master node, instead of having a 
TFT display, simply puts its outputs onto the 
serial terminal that is used to interface with 
it. This enables a user to communicate with 
all general nodes through a single master 
FIGURE 6
This illustrates a route discovery routine where the source floods the network with a RREQ message and the 
destination receives it and sends back a RREP message while another intermediary node receives the RREQ 
flood and attempts a flood of its own which the destination ignores. (1 = RREQ, 2 = RREP)
Message legend:
Packet type | Source ID | Destination ID | Next hop ID
Node
50
2|50|10|50
Node
20
Node
10
1|50|10|
1|50|10|
1|50|10|
Message legend:
Packet type | Source ID | Destination ID | Next hop ID
Node
50
2|50|10|50 2|50|10|60
2|50|10|80
Node
20
Node
30
Node
50
Node
70
Node
40
Node
80
Node
60
Node
10
1|50|10
1|50|10
1|50|10
1|50|10
1|50|101|50|10
1|50|10 1|50|10
1|50|10
1|50|10
1|50|10
2|50|10|20
FIGURE 7
This diagram illustrates the scalability of the mesh network 
due to the simple software filtering of flood messages built 
into the mesh layer’s receive callback. (1 = RREQ, 2 = RREP)
CIRCUIT CELLAR • FEBRUARY 2018 #33132
FE
AT
U
RE
S
Additional materials from the author are available at: 
www.circuitcellar.com/article-materials
Reference [1] as marked in the article can be found there.
RESOURCES
Microchip | www.microchip.com
Nordic Semiconductor | www.nordicsemi.com
node that can be universally plugged into 
any computer with a USB port (Photo 1). 
The master node is also equipped with a 
PIC32 and nRF24L01 so that it supports the 
same network interface as the general nodes.
TESTING AND VERIFICATIONConsistent with the high-level abstraction 
that we detailed earlier, we chose to 
independently develop our three layers prior 
to integration. This meant unit testing of each 
layer was handled by the respective developer.
● For the application layer, this involved 
simulating data packets, observing node 
behavior, and ensuring user input was 
serialized correctly.
● For the mesh network, unit testing mainly 
comprised of testing possible data paths 
for sending and receiving, such as cache hit 
hop and cache miss hop.
● For radio layer, testing consisted of ensuring 
packet reliability and functionality across 
different distances and number of nodes.
Once all three layers passed their unit 
tests, we put them together and began 
rigorous integration testing. First, we tested 
simple one-to-one communication with 
all three layers active. Once this worked, 
we attempted communication with two 
nodes in range of the master node. It was 
here that we first started to drop packets 
among nodes. This didn’t happen earlier 
because nRF radios have a built-in auto-
acknowledgement packet that is sent out on 
successful reception. With multiple nodes in 
range however, the master node would never 
know whether every node in range correctly 
received the packet.
We bypassed this issue by disabling 
auto-acknowledgement on the radios and 
manually retransmitting a fixed number of 
times. This seemed to alleviate the problem 
for a small number of radios, at the risk of 
increasing the possibility of packet collision 
for a large number of nodes.
The next step was to test long range 
message hopping. To do this, we placed one 
radio outside the range of the master node 
and another one in between the two. This 
was difficult in practice, because there’s a 
grey area in which nodes would still be in 
range, but with a very low success rate. All 
that said, we were able to make the master 
node to communicate with nodes out of 
direct range—demonstrating one of the 
key functionalities of our mesh network. 
We were also able to verify path discovery 
in larger multi-node networks. In these 
FIGURE 8
Component-level circuit schematic 
diagram for each general node
http://www.circuitcellar.com/article-materials
http://www.microchip.com
http://www.nordicsemi.com
circuitcellar.com 33
FEATU
RES
ABOUT THE AUTHORS 
Raghava Kumar (rk534@cornell.edu) is a senior in Electrical and Computer 
Engineering at Cornell University. He loves working with microcontrollers, 
FPGAs, and embedded computers.
Alex Wong (aw528@cornell.edu) is a senior double majoring in Electrical and 
Computer Engineering and Computer Science at Cornell University. He enjoys 
all things Computer Architecture, ASIC/FPGA Design, and Space.
Brian Clark (bac239@cornell.edu) is a senior at Cornell University currently 
double majoring in Electrical and Computer Engineering and Computer sci-
ence. You can find him spending his free time on applying microcontrollers 
to practical applications and writing code for various application.
networks, we observed high traffic in the 
form of RREQ floods and RREP messages 
during route discovery stage, and had to add 
software packet filtering to ensure stable 
performance.
RESULTS
After completing our project, we 
conducted range tests and observed 
performance to collect the results shown in 
Figure 9. The application and mesh layers 
performed consistently well through our 
experiments. We tested different commands 
and messages with up to four nodes 
communicating and dynamically discovering 
paths in the network. We were able to verify 
multi-node paths by constructing several 
test cases with nodes out of direct range. 
This worked well for a small number of 
nodes, despite occasional packet drops and 
collisions. One limitation here was that four 
is a relatively small number for realistic 
applications. Ideally, we would have liked to 
test latency and throughput under higher 
stress conditions.
The radio and hardware layers were able 
to achieve a reasonable tradeoff between 
cost, performance and power-consumption. 
Our prototype nodes cost $20 each and 
would last 20 hours of continuous usage. 
If we optimized for production, we believe 
cost could easily be halved, and battery life 
could be increased significantly with some 
software support.
All that being said, hardware was the 
limiting factor our in-network reliability. 
A lot of effort was put into debugging the 
seemingly inherent unreliability of the nRF in 
multi-node situations. We experimented with 
different channels, pipes and transmit rates 
among other factors, but were unable to 
increase packet reliability beyond a certain 
threshold. For future iterations, we believe 
it would help to either experiment with 
different radio modules, use independent 
radios for transmission and reception on 
each node, or find a more robust library.
FUTURE DEVELOPMENT
We were able to achieve many of the 
goals of our final project. While radios turned 
out to be more fickle and mesh algorithms 
far more difficult than expected, we were 
able to demonstrate automation functionality 
on a mesh, as desired. Future work on this 
project could involve testing with superior 
hardware, optimizing the mesh algorithm to 
increase reliability and adding more 
application layer functionality to make this 
project into a full-fledged, highly 
customizable automation system. 
FIGURE 9
Shown here is a racket reliability 
chart. Straight: No obstacles between 
the destination and master node. 
Bend: 90º angles about every 45 feet 
at which one hop node was placed.
100
90
80
70
60
50
40
30
20
10
0
Packet success rate vs. Distance
Success
rate
(%)
Two nodes
Three nodes straight
Three node bend
Four node bend
Distance between master and destination node (ft.)
0 20 40 60 80 100 120 140 160 180
mailto:rk534@cornell.edu
mailto:aw528@cornell.edu
mailto:bac239@cornell.edu
CIRCUIT CELLAR • FEBRUARY 2018 #33134
It may not happen overnight, but the shift from driver assisted 
vehicle controls to full autonomous driving is underway. To meet 
demands, MCU and analog IC vendors are crafting new chip and 
development tool solutions.
W ithin the next couple years, we’ll blink our eyes and driverless cars will suddenly be a mainstream phenomenon. Building toward that goal, chip vendors are evolving their driver assistance 
technologies into complete driver replacement solutions. These 
solutions make use of powerful system-on-chip (SoC) and microcontroller devices 
to analyze a car’s surroundings, process the information and employ control 
functionality to steer cars safely.
Building on their long histories of serving the automotive market, the leading 
microcontroller vendors have taken the lead, facilitating driverless car systems 
with not just chips, but also very elaborate development platform solutions. And 
over the last 12 months, that trend has accelerated as MCU suppliers evolve their 
driver assistance technologies in parallel with their autonomous vehicle solutions.
LEVEL 3 AUTONOMY 
Exemplifying these trends, Infineon Technologies supplies key components for 
the Audi A8, the first series production car featuring level 3 automated driving 
(Photo 1). Level 3 automated driving is where drivers can temporarily take their 
hands off the steering wheel under certain conditions. The Audi A8, for example, 
allows this when parking and exiting, in slow-moving traffic or in traffic congestion. 
Electronics Propel Driverless 
Vehicle Designs Forward
From Assist to Autonomous
By Jeff Child, 
Editor-in-Chief
SP
EC
IA
L 
FE
AT
U
RE
PHOTO 1
The Audi A8 is the first series production car featuring level 3 
automated driving. Level 3 is where drivers can temporarily take 
their hands off the steering wheel under certain conditions.
circuitcellar.com 35
SPECIAL FEATU
RE
Table 1 shows how the ability of cars to self-
drive is split into a number of different levels.
Various chips from Infineon enable 
automated drivingin the Audi A8. These 
include sensors, microcontrollers and power 
semiconductors. Radar sensor chips from the 
Infineon’s RASIC family are installed in the 
front and corner radar. They send and receive 
high-frequency 77-GHz signals and forward 
these on to the central driver assistance 
controller (zFAS). A microcontroller from 
Infineon’s AURIX family is a key component of 
the zFAS for reliable automated driving. AURIX 
enable a secure connection to the vehicle 
data bus. It assesses and prioritizes data 
packets and initiates their processing in the 
fastest possible time. For example, it initiates 
emergency braking based on data from radar 
and other sensor systems. The AURIX family 
of microcontrollers is especially ideal for this 
purpose thanks to high processing power and 
extensive safety features.
AURIX microcontrollers are used in several 
controllers in the Audi A8. They control 
the functions for the engine. And they also 
operate in the Audi AI active chassis and in the 
electronic chassis platform, which controls the 
shock absorption. The microcontrollers also 
support activation of the airbag. In addition to 
the electronics for drive, driver assistance and 
chassis, other semiconductor solutions from 
Infineon are installed in the comfort and body 
electronics, such as for example LED drivers from 
Infineon’s LITIX Basic family in the tail lights as 
well as bridge drivers from the Embedded Power 
family in the windscreen wipers.
PROCESSING LIDAR INPUT
LiDAR (Light Detection and Ranging) is a 
critical technology used in vehicles to detect 
surrounding conditions. And processing 
incoming LiDAR data is a perfect example 
of the kind of technology that address both 
assisted driving functionality today and 
automated driving of the future. With that 
in mind, Renesas Electronics in December 
announced a collaboration with Dibotics, a 
supplier of real-time 3D LiDAR processing. 
The companies are working together to 
development an automotive-grade embedded 
solution for LiDAR processing to be used in 
advanced driver assistance systems (ADAS) 
and automated driving applications. The 
jointly-developed solution is expected to enable 
system manufacturers to develop real-time 3D 
mapping systems with high level functional 
safety (FuSa) and low-power consumption.
The effort marries Renesas’ high-
performance image processing, low-power 
automotive R-Car system-on-chip (SoC) 
with Dibotics’ 3D simultaneous localization 
and mapping (SLAM) technology. The result 
is the SLAM on Chip (Photo 2). The SLAM 
PHOTO 2
SLAM on Chip combines Renesas’ high-performance image processing, low-power automotive R-Car system-
on-chip (SoC) with Dibotics’ 3D simultaneous localization and mapping (SLAM) technology.
TABLE 1
The ability of cars to self-drive is split into a number of different levels (Source: German Association of the 
Automotive Industry).
Autonomous Driving Levels
Level 0
There are no automated driving features. The driver is 
responsible for longitudinal guidance (maintaining speed, 
accelerating, braking) and lateral guidance (steering). There 
are no intervention systems, simply warning systems.
Level 1
A system can either take over longitudinal or lateral guidance 
of the vehicle, while the driver permanently executes the 
other activity respectively.
Level 2
The driver can hand over longitudinal and lateral guidance to 
the system in a specific application. The driver must always 
be in a position to immediately retake control of the vehicle.
Level 2
The system identifies the system limits independently. The 
driver no longer has to permanently monitor the longitudinal 
and lateral guidance of the vehicle. However, the driver has 
to remain able to resume driving when prompted by the 
system with a specific buffer time.
Level 4
The driver can hand over the full driving task to the system 
in specific applications (road type, speed zone, environmental 
conditions).
Level 5
Driverless driving. The vehicle can perform the driving task 
fully autonomously—on all road types, in all speed zones and 
under all environmental conditions.
CIRCUIT CELLAR • FEBRUARY 2018 #33136
SP
EC
IA
L 
FE
AT
U
RE
on Chip implements 3D SLAM processing 
on a SoC, a function that used to require 
a high-performance PC. It also realizes 3D 
mapping with LiDAR data only, eliminating 
the need to use inertial measurement units 
(IMUs) and global positioning system (GPS) 
data. The collaboration enables a real-
time 3D mapping system with low power 
consumption and high-level functional 
safety in automotive systems.
To prepare for the autonomous-driving 
era, the automotive market is optimizing the 
sensor technology required for autonomous 
vehicles, including real-time, high-definition 
perception of the environment, precise 
localization of the vehicle and real-time 
sensor fusion. LiDAR has become a key part 
of that puzzle, providing higher-precision 
obstacle sensing around the vehicle and real-
time electric control unit (ECU) management 
for vehicle control. Those are all welcome 
advantages over alternative methods 
such as cameras and radars. New LiDAR 
sensor technologies in turn increase in the 
amount of data to be processed, and that’s 
increasing the need for high-performance 
real-time processing of all that data.
In contrast to existing approaches, 
Dibotics’ Augmented LiDAR software realizes 
3D SLAM technology that only requires data 
from the LiDAR sensor to achieve 3D mapping. 
As mentioned earlier, it does not require 
additional input from IMUs, GPS and or wheel 
encoders. That eliminates extra integration 
efforts, lowers bill-of-material (BOM) costs 
and simplifies development. In addition, the 
software realizes point-wise classification 
detection and tracking of shape, speed and 
trajectory of moving objects and Multi-LiDAR 
fusion.
STEREO VISION SENSOR
In keeping with the theme of assisted 
driving technology advances as a stepping 
stone toward automated driving, Cypress 
Semiconductor in October announced that 
automotive supplier DENSO Corporation 
selected Cypress’ 6-Channel Automotive 
Power Management IC (PMIC) and FL-S Serial 
NOR Flash memory solution to enable the 
latest stereo vision sensor for Advanced 
Driver Assistance Systems (ADAS). The DENSO 
stereo vision sensor uses image processing 
techniques to detect obstacles of different 
shapes and lane lines, as well as empty spaces 
on the road. This supports autonomous 
emergency braking and automatic steering 
control to avoid obstacles. Cypress’ highly-
integrated, 6-Channel automotive PMIC 
regulates power for the entire sensor, and 
the FL-S NOR flash memory enables fast 
program execution for high-performance 
systems (Photo 3). Each device has a small 
footprint that makes the solution ideal for 
this compact design. 
For its part, Cypress works with the 
several top automotive companies to supply 
them ADAS, 3-D graphics displays, wireless 
connectivity, full-featured touchscreens and 
vehicle body electronics. Cypress’ automotive 
portfolio includes the Traveo MCU family, 
power-management ICs (PMICs), PSoC 
programmable system-on-chip solutions, 
CapSense capacitive-sensing solutions, 
TrueTouch touchscreens, NOR flash, F-RAM 
and SRAM memories, along with USB, Wi-Fi 
and Bluetooth connectivity solutions.
DEVELOPMENT KIT
There’s no doubt that integrating 
automated driving technologies is a complex 
effort. Easing those efforts, technology 
suppliers have recently been rolling out 
complete development kids to make it easier 
to craft and test applications. An example 
just last month was NXP Semiconductors with 
its new NXP Automated Drive Kit, a software 
enabled platform for the development and 
testing of automated vehicle applications. 
PHOTO 3
Cypress Semiconductor’s 6-Channel automotive PMIC regulates power for the entire sensor, and the FL-S 
NOR Flash memory enables fast program execution for high-performance systems.
circuitcellar.com 37
SPECIAL FEATU
RE
Thekit enables carmakers and suppliers 
to develop, test and deploy autonomous 
algorithms and applications quickly on an 
open and flexible platform with an expanding 
ecosystem of partners.
Automated driving applications require 
easy access to multiple hardware and 
software options. NXP has opened the door 
to hardware and software partners to foster 
a flexible development platform that meets 
the needs of a diverse set of developers. The 
NXP Automated Drive Kit provides a baseline 
for level 3 development and will expand to 
additional autonomy levels as the ecosystem’s 
performance scales (Figure 1).
The first release of the Automated Drive 
Kit will include a front vision system based on 
NXP’s S32V234 processor, allowing customers 
to deploy their algorithms of choice. The 
Kit also includes front camera application 
software APIs and object detection 
algorithms provided by Neusoft. The kit also 
includes sophisticated radar options and GPS 
positioning technology. System developers 
can choose from various LiDAR options 
and can add LiDAR Object Processing (LOP) 
modular software from AutonomouStuff, 
which provides ground segmentation and 
object tracking.
VEHICLE NETWORKING
An important piece of future autonomous 
vehicle infrastructure is the ability for vehicles 
to communicate with other vehicles and with 
other platforms outside the vehicle. Providing 
a solution for those needs are Vehicle-to-
vehicle (V2V) and vehicle-to-infrastructure 
(V2I) communication, collectively referred 
as V2X. V2X is a wireless technology aimed 
at increasing road safety and improve traffic 
management. V2X technology is based on 
5.9 GHz Dedicated Short Range 
Communication, a derivative of Wi-Fi 
specifically defined for fast moving objects. 
It allows vehicles to communicate their 
state, such as their position and speed, to 
surrounding vehicles and infrastructures even 
in non-line-of-sight condition, such as behind 
a building or a curve.
At the Consumer Electronics Show (CES) 
last month, Autotalks, a manufacturer of V2X 
communication chipsets and STMicroelectronics 
partnered to highlight both V2V and V2I use 
cases at the show. The companies showed the 
first mass-market-ready 2nd-gen DSRC-based 
V2X solution (Figure 2). This includes ST’s 
Telemaco3 telematics platform and Autotalks’ 
CRATON2 chipset, an advanced and secure V2X 
communication module.
In a demonstration, they showed how 
the now commercially-ready technology can 
be used to avoid collisions, describe road 
conditions and indicate distance to important 
infrastructure, such as EV charging stations. 
The DSRC-based technology today exceeds 
all existing US Department of Transportation 
(USDOT) specifications. The exhibit featured a 
virtual reality experience that allowed visitors 
to “drive” a V2X-equiped vehicle so they can 
see the technology’s benefits while “driving 
through” multiple hazardous road scenarios.
MORE EFFICIENT CONNECTIVITY
Automated driving functionality is certain 
to increase the demand for accommodating 
FIGURE 2
This V2X solution includes ST’s Telemaco3 telematics platform and Autotalks’ CRATON2 chipset.
FIGURE 1
The first release of NXP’s Automated Drive Kit will include a front vision system based on NXP’s S32V234 
processor, enabling developers to deploy their algorithms of choice.
CIRCUIT CELLAR • FEBRUARY 2018 #33138
SP
EC
IA
L 
FE
AT
U
RE
heavier amounts of data networking 
throughout vehicles. This is being fueled not 
only by the increasing amount of sophisticated 
driving electronics, but also the emergence 
of more sophisticated infotainment systems 
aboard cars. Microchip Technology for is 
part is helping evolve that networking with 
its intelligent networking solution. In June 
of 2017, Microchip announced its newest 
MOST150 Intelligent Network Interface 
Controller (INIC). It enables automotive 
manufacturers and tier one suppliers 
to incorporate Media Oriented Systems 
Transport (MOST) networks in a daisy-chain 
configuration on coaxial physical layer with 
the support of full-duplex communication, in 
addition to a ring topology.
MOST technology is the choice of many 
automobile manufacturers and tier one 
suppliers for in-vehicle networking. It 
specifically targets infotainment and telematics 
applications such as smart antennas, head 
units, amplifiers, digital clusters, rear seat 
entertainment, Advanced Driver-Assistance 
Systems (ADAS), driver/passenger information 
systems and public transportation infotainment 
and information systems.
With a full-duplex daisy-chained network, 
a single cable segment is sufficient to connect 
two adjacent devices in the network, reducing 
cables and connectors for the back channel on 
each network connection. It also eliminates 
the return wire connecting the last node of 
the network to the first. This reduces wiring 
and component count resulting in lower 
system costs as well as potential weight 
savings that can impact Corporate Average 
Fuel Economy (CAFE) goals and other fuel 
efficiency regulations.
Using Microchip’s OS81119 INIC 
allows developers to simplify the network 
architecture of automotive in-vehicle 
infotainment systems by using integrated 
coaxial physical layer (cPHY), optical physical 
layer (oPHY), daisy-chain topologies or 
creative hybrid combinations. Customers 
currently using MOST150 systems can also 
rapidly migrate to new topologies or daisy-
chain additional nodes with little hardware 
and software redesign.
Besides an integrated cPHY, a USB 2.0 
high-speed user interface is also part of the 
OS81119 INIC. This integration further reduces 
system component count, driving down overall 
costs. Time to market can be improved when 
using the USB standard and corresponding 
standardized MOST Linux Driver. Meanwhile, 
using an open-source Linux operating system 
and driver for the OS81119 helps customers 
reduce costs. By employing the standard 
Application Programming Interfaces (APIs), 
customers can also minimize the risk of 
application issues.
RADAR SENSOR
While microcontroller vendors steal a lot 
of the spotlight for automotive electronics, 
analog ICs are an indispensable part of the 
picture. And analog IC technologies are 
just as important for autonomous vehicle 
systems. In an example along those lines, 
last April Analog Devices teamed up with 
Renesas Electronics to collaborate on a 
system-level 77/79-GHz RADAR sensor 
demonstrator to improve Advanced Driver 
Assistance Systems (ADAS) applications and 
enable autonomous driving vehicles. The 
demonstrator combines two cutting-edge 
technologies that include the RH850/V1R-M 
microcontroller from the Renesas autonomy 
Platform and ADI’s Drive360 advanced 28 nm 
CMOS RF-to-bits technology.
According to ADI, the seamless system-
level operation of these two technologies 
makes driving safer by enabling earlier 
detection of smaller and faster moving 
objects at greater distances. It will also 
lower RADAR system integration efforts and 
reduce evaluation risks for automotive OEMs 
and Tier One suppliers.
Analog Devices Drive360 28 nm CMOS 
RADAR technology platform builds on 
the company’s ADAS, MEMS, and RADAR 
technology portfolio widely used throughout 
the automotive industry. Drive360 is the 
first automotive RADAR technology based 
on advanced 28 nm CMOS and provides high 
RF performance for target identification and 
classification. ADI’s RADAR solution enables 
earlier detection of smaller and faster 
RESOURCES
Analog Devices | www.analog.com
Cypress Semiconductor | www.cypress.com 
Infineon Technologies | www.infineon.com 
Microchip | www.microchip.com
NXP Semiconductors | www.nxp.com
Renesas Electronics America | www.renesas.com 
ST Microelectronics | www.st.com
Texas Instruments | www.ti.com
http://www.analog.com
http://www.cypress.com
http://www.infineon.com
http://www.microchip.com
http://www.nxp.com
http://www.renesas.com
http://www.st.com
http://www.ti.com
circuitcellar.com 39
SPECIAL FEATU
RE
moving objects.High output power enables 
greater range and identification of smaller 
objects, while its low phase noise improves 
unambiguous detection of smaller objects in 
the presence of large objects.
The Renesas Autonomy Platform is an 
open, innovative and trusted platform for 
ADAS and automated driving, supported 
by Renesas’ sustainable and scalable SoC 
and MCU roadmaps. The RH850/V1R-M MCU 
was specifically designed for use in RADAR 
applications as part of the sustainable and 
scalable portfolio. The new MCU includes 
optimized programmable digital signal 
processing (DSP), a dual CPU cores each 
operating at 320 megahertz (MHz) with 2 MB 
of flash and 2 MB internal RAM.
With feet in both worlds, Texas 
Instruments for its part is a provider of 
both embedded processing and analog ICs 
aimed at the automotive space. For example, 
TI’s Jacinto family of processors provides 
support for a variety of automotive digital 
cockpit applications including infotainment, 
head unit co-processing for infotainment, 
informational ADAS, integrated digital 
cockpit, digital instrument cluster, head-
up display and more. Designed for 
automotive safety and robustness, the 
Jacinto heterogeneous architecture includes 
hardware firewalls, allows separation 
between High Level OS (HLOS) and safety OS 
as well as implementation of robust multi-
domain software architecture capable to be 
ASIL-B safety certified.
INFOTAINMENT EVOLUTION
Although it may seem obvious, the 
emergence of autonomous vehicles will 
naturally boost demands for more advanced 
in-vehicle infotainment systems. Drivers will be 
freed up to take advantage of those systems 
once being hands-off the steering wheel 
becomes “normal.” The trend toward more 
advanced vehicle infotainment will involve a 
variety of high-performance computing, 
display and connectivity technologies. But we’ll 
save that for a future article. 
http://www.cc-webshop.com
CIRCUIT CELLAR • FEBRUARY 2018 #33140
TE
CH
 S
PO
TL
IG
HT
Non-Standard SBCs Put 
Function Over Form
A rich set of single board 
computer products fall into 
the non-standards-based 
category. These SBCs 
offer complete embedded 
computing solutions suited 
for applications were 
reducing size, weight and 
power are the priorities.
By Jeff Child, 
Editor-in-Chief
Compact, Low-Power 
Solutions
W hile standard form factor embedded computers provide a lot of value, 
many applications demand 
that form take priority over function. The 
majority of non-standard boards tend to 
be extremely compact, and well suited for 
size-constrained system designs. Although 
there’s little doubt that standard open-
architecture board form factors continue to 
thrive across numerous embedded system 
applications, non-standard form factors free 
designers from the size and cost overheads 
associated with including a standard bus or 
interconnect architecture.
In very small systems, often the size and 
volume of the board takes precedence over 
the need for standards. Instead the priority 
is on cramming as much functionality and 
compute density onto a single board solution. 
And because they tend to be literately “single 
board” solutions, there’s often no need to 
be compatible with multiple companion I/O 
boards. These non-standard boards seem 
to be targeting very different applications 
areas—areas where slot-card backplane or 
PC/104 stacks wouldn’t be practical.
Non-standard boards come in a variety 
of shapes and sizes. Some follow de facto 
industry standard sizes like 3.5 inches, while 
others take a twist on existing standards—
such as ATX, ITX or PC/104—to produce a “one 
PHOTO 1
TS-7553-V2 is developed around the NXP i.MX6 UltraLite, an advanced implementation of a single 
ARM Cortex-A7 core, which operates at speeds up to 696 MHz. The board specifically targets the 
industrial Internet of Things (IIoT) sector.
circuitcellar.com 41
TECH SPO
TLIG
HT
off” implementation that takes some of the 
benefits of a standard form factor. There are 
also some company-specific “standard” form 
factors that offer an innovative new approach. 
The focus in this article is on commercial SBCs 
for professional applications, not modules for 
hobbyist projects.
ARM-BASED BOARDS
In terms of sheer numbers of SBC 
products, Intel processor-based solutions 
tend to dominate. But in recent years, non-
standard SBCs based on ARM embedded 
processors are increasing mindshare in 
the industry. In a recent example of an 
ARM-based solution, Technologic Systems 
in December starting shipping its newest 
SBC, the TS-7553-V2 (Photo 1). The board is 
developed around the NXP i.MX6 UltraLite, a 
high-performance processor family featuring 
an advanced implementation of a single ARM 
Cortex-A7 core, which operates at speeds up to 
696 MHz. While able to support a wide range of 
embedded applications, the TS-7553-V2 was 
specifically designed to target the industrial 
Internet of Things (IIoT) sector.
The TS-7553-V2 was designed with 
connectivity in mind. An on-board Xbee 
interface, capable of supporting Xbee or 
NimbleLink, provides a simple path to adding 
a variety of wireless interfaces. An Xbee 
radio can be used to link in with a local 
2.4 GHz or sub 1 GHz mesh networks, allowing 
for gateway or node deployments. Both Digi 
and NimbleLink offer cellular radios for this 
socket, providing cellular connectivity for 
applications such as remote equipment 
monitoring and control. There is also the 
option for a cellular modem via a daughter 
card. This allows transmission of serial data 
via TCP, UDP or SMS over the cellular network. 
The TS-7553-V2 also includes an on board 
WiFi b/g/n and Bluetooth 4.0 option, providing 
even more connectivity.
Further radio expansion can be 
accomplished with the two internal USB 
interfaces—one on a standard USB Type A 
connector, and the second on simple pin 
headers. The USB interfaces enable support 
for multiple proprietary networks via a dongle 
or USB connected device. This provides 
the opportunity to run mesh, LoRa, ZigBee, 
automotive WiFi or other protocols with the TS-
7553-v2. All of these radio options combined 
with the on board 10/100Base-T Ethernet 
create the opportunity to communicate 
seamlessly with up to 5 different networks 
simultaneously from a single point.
FAMILY OF ARM SBCs
Also leveraging ARM technology, Gateworks 
in October unveiled its Newport Family of 
SBCs featuring eight standard models. The 
Newport Family is based upon the Cavium 
Octeon TX 64-bit ARMv8 SoC, which has been 
designed specifically for high performance 
networking applications. The Newport Family 
of boards offers processors ranging from 
an 800 MHz Dual Core up to a 1.5 GHz Quad 
Core. The Octeon TX features large L1/L2 
caches, rich I/O with support for the latest 
standards (PCIe Gen 3, SATA3.0, USB 3.0, 
DDR4), security and networking acceleration 
engines, hardware virtualization, low power 
(less than 4 W) and IPSec performance of 8 
Gbps with only 2-cores.
The Newport Family of network processor 
boards feature up to 8 GB of DDR4 DRAM, 
up to 64 GB eMMC flash, up to 5 GbE Copper 
Ethernet ports, up to 2 SFP ports for fiber 
support, microSD, SIM and USB 3.0. The board 
also has up to 4 Mini-PCIe expansion sites 
allowing support for a variety of peripherals 
including Wi-Fi radios, 4G/LTE cellular 
modems, mSATA drives and other Mini-PCIe 
cards. Optional features include GPS w/PPS 
support, CAN bus and a SHA-256 crypto-
strong symmetric key-based authentication 
IC for secure deployments.
Additional standard features include 
digital I/O, RS232/RS485 ports, USB3.0, 
SPI/I2C expansion ports, wide voltage range 
input (8 VDC to 60 VDC), 802.3af/at PoE, 
industrial temperature operation and the 
Gateworks System Controller (GSC). The 
GSC provides system health monitoring and 
advanced watchdog support, including the 
ability to power up and down the board at 
programmable intervals.
Board sizes range from a small GW6100 at 
35 mm x 100 mm, up to the largest GW6400at 140 mm x 100 mm. Power consumptions of 
PHOTO 2
The Gumstix Cobalt MC single board computer shows off some of the best multimedia features of the NXP 
SCM with CSI2 camera, native HDMI, and audio, and connects over Gbit Ethernet, Wi-Fi and Bluetooth.
CIRCUIT CELLAR • FEBRUARY 2018 #33142
TE
CH
 S
PO
TL
IG
HT
the Newport Family boards range from 4 W 
for the smallest board and up to 10 W for the 
largest model.
MYIR Tech Limited’s latest offering likewise 
aimed ARM technology at a compact, low-
power solution with its MYC-Y6ULX CPU Module 
announced in November. Measuring only 
37 mm by 39 mm, the MYC-Y6ULX CPU Module 
is covered with a shield and powered by an NXP 
i.MX 6UltraLite / 6ULL processor based on the 
ARM Cortex-A7 architecture. The board offers 
a choice of G2 and Y2 sub family processors 
running at 528 MHz and integrated with 
256 MB DDR3 and 256 MB NAND flash (4 GB 
eMMC flash is optional). Applications well 
suited to the MYC-Y6ULX include industrial 
control, communications, HMI, smart 
healthcare and IoT. The board connects many 
of its peripheral signals and I/Os through a 
1.0 mm pitch 140-pin stamp hole expansion 
interface to allow customer’s extension for 
their next embedded design. The module is 
ready to run Linux and can support industrial 
operating temperature range from -40°C to 
+85 °C.
MYIR also offers a development board 
MYD-Y6ULX which is built around the MYC-
Y6ULX CPU Module with a specially designed 
base board. A variety of peripheral interfaces 
have been brought out to the base board 
through headers and connectors including 
serial ports, two USB Host, one USB OTG, 
two 10/100Mbps Ethernets, CAN, Camera, 
LCD, Audio, TF card as well as a Mini PCIe 
interface for 4G LTE Module. The board also 
has an integrated Wi-Fi Module with external 
antenna to allow wireless communications. 
Along with some cable accessories, the MYD-
Y6ULX is a complete evaluation platform and 
reference design for development based on 
i.MX 6UL/6ULL processors.
DESIGN-TO-ORDER SBCs
As a provider of design-to-order embedded 
boards, Gumstix comes at non-standard SBCs 
from a different perspective than traditional 
off-the-shelf SBC vendors. Gumstix’s latest 
ARM-related focus was its announcement 
in October about its adding the NXP 
Semiconductor SCM-i.MX 6Quad/6Dual Single 
Chip System Module (SCM) to the Geppetto 
D2O design library and the Gumstix Cobalt 
MC (Media Center) development board (Photo 
2). The NXP SCM-i.MX 6D/Q [Dual, Quad] Core 
SCM combines the i.MX 6 quad- or dual-
core applications processor, NXP MMPF0100 
power management system, integrated flash 
memory, over 100 passives and up to 2 GB 
DDR2 Package-on-Package RAM into a single-
chip solution.
Using Gumstix’s services, embedded 
systems developers can, in minutes, design 
and order SCM-powered hardware combining 
their choices of network connection, 
communication bus, and hardware features. 
During the design process, users can compare 
alternatives for features and costs, create 
multiple projects and receive complete custom 
BSPs and free automated documentation. 
Designers can go straight from a design to 
an order in one session with no engineering 
required.
The NXP SCM is equipped with a wide 
range of I/O, multimedia processing, and 
connectivity features. Condensing it, a 
feature-rich power management IC and over 
100 passive circuit elements into a single 
package, the SCM-i.MX 6Quad/6Dual greatly 
reduces the SoC’s cumulative footprint. The 
PHOTO 3
The Zybo Z7 board is built around the Xilinx Zynq-7000 FPGA family. The Zynq family tightly integrates a 
dual-core ARM Cortex-A9 processor with Xilinx 7-series FPGA logic.
RESOURCES
AAEON | www.aaeon.com
Advantech | www.advantech.com
Axiomtek | www.axiomtek.com
COMMELL | www.commell.com
Diamond Systems | www.diamondsystems.com 
Digilent | www.digilent.com 
Gateworks | www.gateworks.com
Gumstix | www.gumstix.com
MYIR Tech Limited | www.myirtech.com
Technologic Systems | www.embeddedarm.com
http://www.aaeon.com
http://www.advantech.com
http://www.axiomtek.com
http://www.commell.com
http://www.diamondsystems.com
http://www.digilent.com
http://www.gateworks.com
http://www.gumstix.com
http://www.myirtech.com
http://www.embeddedarm.com
circuitcellar.com 43
TECH SPO
TLIG
HT
feature-rich Gumstix Cobalt MC SBC shows 
off some of the best multimedia features 
of the NXP SCM with CSI2 camera, native 
HDMI and audio—and it connects over Gbit 
Ethernet, Wi-Fi and Bluetooth. The Gumstix 
Cobalt MC source description is available in 
Geppetto for any Geppetto user to copy and 
modify the board to meet their specific device 
requirements in minutes.
Coming at embedded boards from an 
FPGA-core perspective, Digilent’s latest ARM 
offering is built around Xilinx FPGA technology. 
In November Digilent announced its Zybo Z7 
board (Photo 3), a feature-rich, ready-to-
use embedded software and development 
board built around the Xilinx Zynq-7000 FPGA 
family. This is the second-generation update 
to the popular Zybo that was released in 
2012. The Zynq family is based on the Xilinx 
All Programmable System-on-Chip (AP SoC) 
architecture, which tightly integrates a dual-
core ARM Cortex-A9 processor with Xilinx 
7-series FPGA logic.
The Zybo Z7 surrounds the Zynq with 
a rich set of multimedia and connectivity 
peripherals to create a formidable SBC, even 
before considering the flexibility and power 
added by the FPGA. The Zybo Z7’s video-
capable feature set includes a MIPI CSI-2 
compatible Pcam connector, HDMI input, HDMI 
output and high DDR3L bandwidth. Attaching 
additional hardware is made easy by the Zybo 
Z7’s Pmod connectors, allowing access to 
Digilent’s catalog of over 70 Pmod peripheral 
boards, including motor controllers, sensors, 
displays and more. Zybo Z7 comes in two 
APSoC variants: Zybo Z7-10 features Xilinx 
XC7Z010-1CLG400C. Zybo Z7-20 features the 
larger Xilinx XC7Z020-1CLG400C.
DEFACTO STANDARD: 3.5 INCH
Among the most popular embedded board 
form factor size these days in the 3.5-inch 
SBC. The 3.5 wasn’t created by any official 
standards body, but it’s close to PC/104’s 
dimensions. The 3.5-inch size turns out to 
be just right for Intel processor based SBCs. 
And if the connectivity and stackable features 
of PC/104 aren’t needed, then 3.5 inch is the 
right size for many applications. Diamond 
Systems, a long team key player in PC/104 and 
other technologies, rolled out a 3.5” SBC last 
year called the VENUS SBC based on the Intel 
“Skylake” 6th Generation Core i7/i5 processor 
(Photo 4). Venus features DDR4 memory 
soldered on board, bottom side conduction 
cooling, two PCIe Mini Card sockets, in the 
3.5” embedded form factor. Venus is available 
in two models, the high performance 2.6 GHz 
i7 version (VNS766-4GD) and a lower cost 
2.4 GHz i5 model (VNS563-4GD).
 The wide range of I/O functionality 
included on Venus meets a majority of 
today’s embedded computing connectivity 
requirements. The board includes six USB 
2.0/3.0 ports, four RS-232/422/485 serial 
ports, sixteen digital I/O lines, two Gigabit 
Ethernet ports, HDA audio, camera interface 
and TPM support. Venus supports three 
simultaneous independent displays consisting 
of VGA, HDMI and LVDS LCD. All three displays 
are 4K capable.
For additional I/O needs, the board 
includes a PCIe/104 OneBank-Plus socket 
(PCIe/104 and PCI-104 expansion) with 
support for up to 4 I/O modules. Venus also 
supports two Mini Card sockets. The top side 
socket supports full-size PCIe and USB Mini 
Card along with mSATA disk modules, while 
the bottom side socket supports full and half 
size PCIe Mini Card. Mass storage options 
include SATA DOM, mSATA and a connector 
for an external SATA drive (all ports are SATA 
III capable). The wide range 9 V to 18 V input 
voltage provides additional flexibility.
Venus incorporates a full suite of rugged 
features such as soldered memory, latching 
connectors, and a thicker PCB, making it 
suitable for themost demanding vehicle 
applications. The 4 GB soldered memory 
may be upgraded to as high as 20 GB using 
Diamond’s unique RSODIMM rugged memory 
modules, which are designed to withstand 
MIL-STD-202G shock and vibration 
specifications. Standard DDR4 SODIMM 
modules may also be used.
 The bottom side heat spreader provides 
the most efficient cooling solution in a 
PHOTO 4
Based on the Intel “Skylake” 6th Generation Core i7/i5 processor, the Venus features DDR4 memory soldered 
on board, bottom side conduction cooling, two PCIe Mini Card sockets—all in the 3.5-inch embedded form 
factor.
CIRCUIT CELLAR • FEBRUARY 2018 #33144
TE
CH
 S
PO
TL
IG
HT
weight-optimized design, enabling Venus to 
run reliably at up to 85°C (lower operating 
limit is -40°C). Venus is the latest addition to 
Diamond’s Raptor rugged computer systems 
that offer MIL-DTL-38999 connectors, MIL-
STD-202G shock/vibration conformance, MIL-
STD-461 compliance and IP67 environmental 
rating. These systems can be customized to 
include additional I/O boards and storage 
media, as well as customer-specific connector 
arrangements.
XEON-BASED SBC
Likewise embracing the 3.5-inch defacto 
standard, COMMELL in October announced 
its LS-37K 3.5-inch embedded mini-board 
based on Intel 6th/7th generation FCLGA1151 
Skylake / Kaby Lake Core processor 
family and Xeon E3-1200 v5 processor 
(Photo 5). The Skylake PC is claimed to deliver 
30% better performance than a PC base on Ivy 
Bridge architecture, 20% better performance 
than a PC based on Haswell, and 10% better 
performance than a Broadwell PC.
LS-37K-3D8The LS-37K desktop 3.5-inch 
mini-board platform supports DDR4 memory 
DIMM 1866/2133 MHz up to 16 GB. The 
platform is based on Intel HD530 (Skylake) 
HD630, (Kaby Lake) and HD P530 (Xeon E3-
1200v5). For graphics, the Skylake GPU offers 
24 execution units (EUs) clocked at up to 
1150Mhz (depending on the CPU model). The 
revised video engine now decodes H.265/HEVC 
completely in hardware and thereby much 
more efficiently than before, and HD Graphics 
630 GPU is largely identical to the 530 found 
in Skylake. The only real upgrade here is the 
HEVC and VP9 support. LS-37K Displays can 
be connected via 1 VGA, 1 LVDS, 1 DVI, 1 HDMI 
and one DP port, up to three displays can be 
controlled simultaneously.
LS-37K offers lots of features including 
high-speed data transfer interfaces such as 
4 x USB 3.0 and 2 x SATA III, equipped with 
dual Gigabit Ethernet (One of the dual LAN 
with iAMT 11.0 supported), and comes with 
PS/2 port, 5 x RS232 and 1 x RS232/422/485, 
4 x USB 2.0, Intel High Definition Audio, and 
1 Mini PCIe socket (supporting mSATA) and 
9 VDC to 30 VDC input.
Axiomtek’s offering is the CAPA312, a 
fanless 3.5-inch embedded motherboard, 
powered by the Intel Pentium processor 
N4200 or Celeron processor N3350. This 3.5-
inch embedded board is a performance-driven 
solution for IoT/M2M related applications, 
such as industrial automation, self-service 
terminals, digital signage, POS/kiosk displays, 
medical and more. It offers a wide operating 
temperature range from -20°C to +60°C (or 
optionally up to +70°C) and comes with rich 
I/O connectors, various display interfaces and 
PHOTO 5
The LS-37K-3D8The LS-37K desktop 3.5-inch mini-board platform that supports DDR4 memory DIMM 
1866/2133 MHz up to 16 GB. The board is based on Intel HD530 (Skylake) HD630, (Kaby Lake) and HD P530 
(Xeon E3-1200v5).
PHOTO 6
The GENE-SKU6 W1 is a 3.5-inch subcompact board designed to handle harsh, unstable conditions. This 
includes has a DC input range of 9 VDC to 36 VDC that enables it to take power drops and spikes in its stride 
and continue operating.
circuitcellar.com 45
TECH SPO
TLIG
HT
two PCI Express Mini Card slots for a wide 
array of industrial applications.
For memory the board provides a 
DDR3L-1867 SO-DIMM, up to 8 GB. The boards 
rich set of I/O includes two USB 2.0 and four 
USB 3.0 ports, four PCI Express Mini Card 
slots and two Gbit Ethernet ports supporting 
Wake-on-LAN. The board’s operating 
temperature ranges from -20°C to +60°C 
(-4°F to +140°F)—or with additional option up 
to +70°C (+158°F).
DESIGNED FOR HARSH 
ENVIRONMENTS
Not all applications are equal when it 
comes to their environmental requirements. 
And several non-standard SBCs take special 
care in their designs to enable them to operate 
in harsh environments. Along those lines, 
in December AAEON has launched its GENE-
SKU6 W1, a 3.5-inch subcompact board with 
the specifications needed to handle harsh, 
unstable conditions (Photo 6). When hardware 
is used for outdoor, factory automation, or in-
vehicle applications, you can’t always be sure 
that its DC input will remain stable. Because 
businesses can’t afford for their systems to 
shut down, they need computers that can 
withstand power fluctuations and keep on 
running. With that in mind, the GENE-SKU6 
W1 has a DC input range of 9 VDC to 36 VDC, 
so it takes power drops and spikes in its stride 
and continues operating.
This rugged subcompact board also 
has a WiTAS 1 wide-temperature rating, 
meaning it’s guaranteed to run smoothly in 
environments as cold as -20°C and as hot 
as 70°C. This capability is achieved through 
intelligent design, low-power components and 
an effective heatsink. Those design features 
enable the GENE-SKU6 W1 to function as 
a reliable, fanless solution. The board’s 
features include support for 4K resolution 
and independent DP, DVI, and LVDS display 
outputs. It has Mini-card and mSATA slots, 
four USB 3.0 and two USB 2.0 ports, four COM 
ports and an additional BIO interface enabling 
board-to-board connection.
Meanwhile, Advantech latest play in the 
3.5-inch SBC arena is its MIO-5350. Released 
in October, the MIO-5350 is a 3.5” fanless SBC 
that supports the latest Intel Pentium N4200/ 
Celeron N3350/ Atom E3900 series low power 
consumption processors with a TDP of only 
6 W to 12 W (Photo 7). MIO-5350 provides 
40% CPU performance enhancement and 46% 
graphic performance boosts compared with 
previous generations. It offers 4K2K graphics 
and three simultaneous displays through 
HDMI/DP, LVDS/eDP, and VGA interfaces. 
MIO-5350 comes bundled with Advantech’s 
exclusive iManager APIs, utilities and WISE-
PaaS/RMM—a cloud ready solution for remote 
device management that brings the benefits 
of cloud computing within the reach of many 
embedded application developers.
MIO-5350 is designed to fulfill a variety 
of vertical application needs. It adopts a rich 
array of I/O interface including: dual LAN ports, 
2 x USB3.0, 4 x USB2.0, 4 x COM ports, and 2 
x SATAIII. For expansion, MIO-5350 supports 
1 x M.2 (key-E), 1 x full-size MiniPCIe (mSATA), 
and MI/O Extension (MIOe). These allow various 
peripherals modules like WiFi, 3G/LTE, storage, 
and I/O expansion (EXM and MIOe) to expand 
functionality. MIO-5350 can operate under wide 
temperature settings ranging from -40 °C to 
85 °C, making it well suited ideal solution for 
use in rugged and harsh environments such 
as factory automation, railways and outdoor 
signage and kiosks.
While non-standard SBCs aren’t expected 
to really encroach too much into the market 
share of standards-based form factor 
solutions, they do have a bright future. The 
direction of semiconductor integration is 
always leading to an ability to fit more 
electronics on a smaller board. That means 
that non-standard SBCs will trend toward 
ever higher compute-densities while pushing 
down the power dissipation curve. 
PHOTO 7
The MIO-5350 is a 3.5-inch fanless SBC that supports the latest Intel Pentium N4200/ Celeron N3350/ Atom 
E3900 series low power consumption processors with a TDP of only 6 W to 12 W.
CIRCUIT CELLAR • FEBRUARY 2018 #33146
PR
O
D
U
CT
 F
O
CU
S
Product Focus: 
MCU Development Tools
PR
O
D
U
CT
 F
O
CU
S Today’s crop of microcontroller development platforms provide a rich set 
of resources for embedded system developers. Wireless connectivity and 
power design supportare the latest trends for these solutions.
By Jeff Child, 
Editor-in-Chief
Connectivity Expands
A s microcontrollers get ever more powerful, adding new levels of functionality, so too are the development 
tools for those MCUs. Today’s crop of 
MCU development tool packages provide advanced 
software tools, rich design examples and complete 
development board resources. The two most obvious 
trends MCU development platforms over the past 
year have been wireless connectivity and power 
system design.
Driven primarily by the fast-growing 
Internet of Things (IoT) phenomenon, today’s 
new generation of MCUs includes many 
product offerings that have on-chip wireless 
connectivity. As a result, many of their 
associated development kits feature boards 
with antennas and RF transceivers to support 
the development of connected IoT devices. 
Some even feature cloud-connectivity support 
in their offerings.
On the power design side, some MCU 
development kits have gone heavy in the 
direction of including analog devices like 
MOSFETs, line drivers and buck converters 
on their boards. These enable MCU system 
developers to measure transient responses 
and the quality of the control loops under 
different load conditions.
Because MCUs are used in such diverse 
applications and industries, it’s hard to 
generalize or pick a truly representative design 
example. Certainly automotive, industrial 
systems, smart city, smart home, wearable 
devices and medical gear are among the 
leading MCU application areas.
Exemplifying the diverse types of MCU uses, 
C2 Development made use of NXP’s Multi-
Protocol Kinetis KW41Z Wireless MCU to help 
simply its simplify its aquarium systems control 
application. The technology made it easy 
for C2 Development to simplify connecting, 
configuring and controlling aquarium lighting 
and pumps. The design challenge for the C2 
Development engineers was to reduce the 
cost and complexity of creating an aquarium 
ecosystem that connects AquaIllumination 
systems with each other—and with EcoTech 
Marine’s pumps. Because NXP’s Kinetis KW41Z 
wireless MCU supports multiple connectivity 
protocols, it provided C2 Development with a 
flexible, cost-efficient foundation for an IoT-
driven aquarium ecosystem (Photo 1). This 
enabled aquarium enthusiasts to quickly and 
easily create a connected system of aquarium 
lights and pumps, and control it all from 
anywhere with just a smartphone.
There are a variety of MCU development 
tools are represented in the product gallery 
displayed on the next couple of pages. Naturally 
chip vendors have many development kit 
solutions, so these are representative products 
from each vendor. 
Photo 1
Because NXP’s Kinetis KW41Z wireless MCU supports multiple connectivity protocols, it was 
possible to build an IoT-driven aquarium ecosystem. This enabled aquarium enthusiasts to 
quickly and easily create a connected system of aquarium lights and pumps, and control it 
all from anywhere with just a smartphone.
circuitcellar.com 47
PRO
D
U
CT FO
CU
S
Platform Supports ADI’s MCUs 
and RF Transceivers
The EV-COG-AD4050 is a development 
platform for Analog Devices’ Ultra Low 
Power technology across ADI’s MCU 
and RF transceiver portfolio. The board 
uses CrossCore Embedded Studio, an 
open source Eclipse based Interactive 
Development Environment (IDE), which 
can be downloaded free of charge. 
The platform contains many hardware 
and software example projects for 
customers to prototype and create 
solutions for IoT applications.
• On-board ultra-low power ARM 
Cortex M4F MCU
• No external debugger/emulator tools 
required
• Small form factor (75 mm X 35mm)
• Multiple power options: USB, 
Coincell, External and Li-Ion
• Onboard peripherals: accelerometer, 
temperature sensor
• Compatible with ADI RF daughter 
cards, and RF modules
• Compatible with ADI application 
add-on boards (gears)
• Expansion connectors and jumpers 
for providing external access to all 
MCU signals and create solutions for 
IoT applications.
Analog Devices
www.analog.com
Tools for Cypress Semi’s PSoC 
BLE 6 MCU
Cypress Semiconductor’s PSoC 
BLE Pioneer Kit features a PSoC 63 
MCU with Bluetooth Low Energy 
(BLE) connectivity. The kit enables 
development of modern touch and 
gesture-based interfaces that are 
robust and reliable with a linear slider, 
touch buttons and proximity sensors 
based on the latest generation of 
Cypress’ CapSense capacitive-sensing 
technology.
• Single- or dual-core PSoC 6 MCU, 
with an ARM Cortex-M4 and ARM 
Cortex-M0+ core, 1 MB of Flash, 
288 KB of SRAM, 78 GPIO, 7 
programmable analog blocks, 56 
programmable digital blocks and 
Bluetooth Low Energy (BLE)
• 2.7” E-ink display shield board
• Cypress EZ-PD CCG3 power delivery 
system
• For CapSense, baseboard comes 
with 2 buttons, a 5-segment slider 
and a proximity sensor. 
• On-board antenna to develop BLE 
designs.
• Software, documentation, design 
files, and code examples
Cypress Semiconductor
www.cypress.com
Kit Enables XMC MCU Digital 
Power Development
Infineon Technologies’ XMC digital 
power explorer kit uses Infineon’s 
XMC range of ARM Cortex-M 
microcontrollers, OptiMOS BSC0924NDI 
MOSFETs and IRS2011S high and low 
side drivers. The kit’s power board 
features synchronous buck converter 
with on-board resistive load banks. The 
load banks can be switched between 
10%, 55% and 100% of the maximum 
load, so that the transient response and 
the quality of the control loop under 
different load conditions can be tested.
• Two control card options: XMC1300 
control card (ARM Cortex-M0) and 
XMC4200 control card (ARM Cortex-
M4F
• Synchronous buck converter
• 2 different control card options: 
XMC1300 and XMC4200
• High resolution PWM (150 ps) and 
smart analog comparators on 
XMC4200
• On board resistive load
• PMBus communication option
• Easy entry into digital power control
• Voltage mode control and peak 
current mode control (with slope 
compensation) available
• Full software support
Infineon Technologies
www.infineon.com
http://www.analog.com
http://www.cypress.com
http://www.infineon.com
CIRCUIT CELLAR • FEBRUARY 2018 #33148
PR
O
D
U
CT
 F
O
CU
S
MAX32625 Development 
Platform is mbed Enabled
The MAX32625MBED development 
platform from Maxim Integrated 
provides a convenient platform for 
evaluating the capabilities of the 
MAX32625 microcontroller. The 
MAX32625MBED also provides a 
complete, functional system ideal 
for developing and debugging 
applications. The MAX32625MBED 
includes a MAX32625 ARM Cortex-M4 
microcontroller with FPU, prototyping 
area with adjacent access to precision 
analog front end (AFE) connections, 
I/O access through Arduino-compatible 
connectors, additional I/O access 
through 100 mil x 100 mil headers, USB 
interface and other general-purpose 
I/O devices.
• Arduino-compatible headers 
and mbed support enable rapid 
prototyping of low-power embedded 
systems
• MAX32625 96 MHz ARM Cortex-M4 
microcontroller
• Expansion connections: Arduino 
form-factor headers; MicroSD Card 
connector; Micro-USB connectors; 
prototyping area
• Integrated peripherals: 4x user 
indicator LED; 2x user pushbutton
• Integrated DAPLink programming 
adapter
Maxim Integrated
www.maximintegrated.com
Eval Kit Facilitates Development 
for SAM D5x/E5x MCUs
Microchip Technology’s SAM E54 
Xplained Pro Evaluation Kit is available 
to kick-start development. The kit 
incorporates an on-board debugger, 
as well as additional peripherals, to 
further ease the design process. All 
SAM D5x/E5x MCUs are supported 
by the Atmel Studio 7 Integrated 
Development Environment (IDE) as well 
as Atmel START, a free online tool to 
configure peripherals and software that 
accelerates development.
• ATSAME54P20A microcontroller
• Embedded debugger with USB 
interface.
• Digital I/O: Two mechanical buttons 
(user and reset button); One Atmel 
QTouch button. One yellow user LED; 
Three Xplained Pro extension headers.
• 256 Mb of QSPIFlash
• ATECC508 CryptoAuthentication device
• AT24MAC402 serial EEPROM with 
EUI-48 MAC address
• Ethernet: 10Base-T/100Base-TX; 
SD/SDIO card connector; Parallel 
Capture Controller header and 
ATA6561 CAN transceiver
• Debug connectors: 10-pin Cortex 
Debug Connector with SWD; 20-pin 
Cortex Debug + ETM Connector with 
4-bit trace
• Supported with application 
examples in Atmel START
Microchip Technology
www.microchip.com
Platform Supports NXP Kinetis 
W Series MCUs with Bluetooth
The FRDM-KW40Z from NXP 
Semiconductors is a low-cost 
development platform enabled by 
the Kinetis W series KW40Z/30Z/20Z 
(KW40Z) family built on the Arm 
Cortex-M0+ processor featuring 
an integrated 2.4 GHz transceiver 
supporting Bluetooth Smart/Bluetooth 
Low Energy (BLE) v4.1 and/or IEEE 
802.15.4-2011 standards.
• Supports MKW24D512 Kinetis MCUs 
(up to 50 MHz Corte-M4 MCU, 512 
KB Flash)
• Full IEEE 802.15.4 compliant 
wireless node
 Software support: Thread, ZigBee Pro, 
802.15.4 MAC and SMAC and Kinetis 
Software Development Kit (SDK)
• Reference design area with small 
footprint, low-cost RF node
• Integrated PCB inverted F-type 
antenna and SMA RF port
• Selectable power sources
• 32 MHz reference oscillator; 32 kHz 
clock oscillator; 2.4 GHz frequency 
operation (ISM Band)
• OpenSDA debug interface
• Combo sensor, 6-axis sensor with 
integrated linear accelerometer and 
magnetometer
NXP Semiconductors
www.nxp.com
http://www.maximintegrated.com
http://www.microchip.com
http://www.nxp.com
circuitcellar.com 49
PRO
D
U
CT FO
CU
S
Wi-Fi Cloud Connectivity Kit 
Supports RX65N MCU
Renesas Electronics’ RX65N Wi-
Fi Cloud Connectivity Kit provides an 
easy-to-use platform for connecting 
to the cloud, evaluating IoT solutions 
and creating IoT applications through 
cloud services and real-time workflows. 
The RX65N Wi-Fi Cloud Connectivity 
Kit integrates the high-performance 
Renesas RX65N microcontroller (MCU) 
and Medium One’s Smart Proximity 
demo with the data intelligence 
featured in Renesas IoT Sandbox.
• 120 MHz RX65N MCU board
• GT202 Wi-Fi module with Qualcomm
QCA4002 low-energy 801.11a/b/g/n
SoC
• Maxbotix ultrasonic range finder
• USB to UART interface (with cable)
• 4 Pmod connectors
• Arduino shield socket
• E1/E2 Lite/J-Link header for external
J-Link support
• USB Type B connector (with cable)
• 5 VDC Power Jack
Renesas Electronics 
www.renesas.com
Development Platform Covers 
Whole STM32 MCU Line
STMCube from STMicroelectronics 
is the implementation of STMCube that 
covers the whole STM32 MCU portfolio. 
The package includes STM32CubeMX, a 
graphical software configuration tool that 
allows the generation of C initialization 
code using graphical wizards. It also 
comprises the STM32CubeH7 MCU 
Package composed of the STM32Cube 
hardware abstraction layer (HAL), plus a 
consistent set of middleware components 
(RTOS, USB, FAT file system, Graphics, 
TCP/IP and Ethernet). All embedded 
software utilities are delivered with 
a full set of examples running on 
STMicroelectronics boards.
• Complete embedded software
package that frees the user from
dependency issues
• Maximized portability between
all STM32 Series supported by
STM32Cube
• Hundreds of examples for easy
understanding
• High quality HAL using CodeSonar
static analysis tool
• STM32H7-dedicated middleware
including USB Host and Device,
TCP/IP and Ethernet
• Free user-friendly license terms
• Update mechanism that can be
enabled by the user to be notified of
new releases
ST Microelectronics
www.st.com
MCU Platform Enables IoT 
Application Development
The SimpleLink MCU platform from 
Texas Instruments is a single development 
environment that delivers flexible 
hardware, software and tool options for 
developers crafting IoT applications. With 
a single software architecture, modular 
development kits and free software tools 
for every point in the design life cycle, 
the SimpleLink MCU ecosystem allows 
100% code reuse across the portfolio of 
MCUs, which supports a wide range of 
connectivity standards and technologies 
including RS-485, Bluetooth low energy, 
Wi-Fi, Sub-1 GHz, 6LoWPAN, Ethernet, 
RF4CE and proprietary radio frequencies. 
SimpleLink MCUs help engineers easily 
develop and seamlessly reuse resources 
to expand their portfolio of connected 
products.
• 100% code compatibility across
SimpleLink MCU portfolio
• TI Drivers offers standardized set
of functional APIs for integrated
peripherals
• Integrated TI-RTOS, a robust,
intelligent kernel for complete, out-
of-the-box development
• POSIX-compatible APIs offer flexible
OS/kernels support
• Encryption-enabled security
features
• IoT stacks and plugins to add
functionality to IoT designs
Texas Instruments
www.ti.com
http://www.renesas.com
http://www.st.com
http://www.ti.com
CIRCUIT CELLAR • FEBRUARY 2018 #33150
CO
LU
M
NS
F or more than 40 years I used old mercury switch thermostats in my homes. My argument was that they 
were reliable and did everything I 
needed. Then about 25 years ago, I upgraded 
to a digital 7-day programmable thermostat. 
It was great to be able to set different 
temperatures for night and day and for when 
we were away. But I noticed that the house 
was not as comfortable as it was with the 
old mercury switch thermostat (Photo 1). It 
would cycle from slightly cool to slightly warm 
during the coldest months of the year. 
My best friend and business partner told 
me that there were two problems with the 
new thermostat. First it had only 1 degree 
of resolution. When the house reached 68°F, 
the heat would go off. When it reached 67°F 
the heat would come back on. A simple bang-
bang controller. The second problem was 
that the control would often overshoot and 
the temperature would actually go to 69°F. 
My old mercury switch thermostat had a 
really neat feature called a heat anticipator 
that prevented this (see sidebar “How the 
Anticipator Works”). I never knew these 
simple looking devices had this feature.
As often happens in first- and second-
generation electronics, my inexpensive digital 
thermostat didn’t work as well as the even 
cheaper electro-mechanical mercury switch. 
But I was so I cheap I kept it for 25 years. This 
month, I decided to enter the 21st century 
and put in smart a Wi-Fi-enabled thermostat. 
Guess what? The heating (and cooling) in my 
home is now more stable than it was with my 
cheap and very old digital thermostat. And the 
anticipator algorithm is far more sophisticated 
than the little variable resister in the mercury 
switch thermostat. But that’s not what we are 
talking about this month. What interested me 
about this new thermostat was the End User 
License Agreement (EULA) that I signed up to 
with this thermostat. Among other things, I 
agreed to the following:
Not to collect information from the 
thermostat using an automated software tool
Not to capture the data stream to or from 
the thermostat (we call this sniffing)
That got me thinking. What about the 
systems that we design? Would I want to 
prevent my users from doing this? This is 
exactly what hackers do maliciously. But 
many others are out trying to make a name 
for themselves and demonstrate holes in the 
security of devices. They show the world how 
clever they are and how “stupid” we are. But 
in the process, they do us a great service. 
They expose our faults. Typically, the good 
ones report the problem to us and we solve it 
before it is hacked maliciously. 
Just recently, one of our designs was 
hacked into by a very smart researcher. He 
Embedded in Thin Slices
In the first part of his new article series on IoT security, Bob 
examines command injection. Command injection is a type of 
attack that involves injecting and executing an unwanted shell 
command or operating system command into your IoT system.
Internet of Things Security (Part 1)
Command Injection
By
Bob Japenga 
circuitcellar.com 51
CO
LU
M
NS
first contacted our customer’s customer 
support but didnot get a satisfactory 
response. Customer support didn’t know how 
to handle this. We, the designers, were never 
contacted. The result was that he wrote us 
up in the Industrial Control Systems Cyber 
Emergency Response Team (ICS-CERT) data 
base (Figure 1) for all the world to know 
about our “stupidity.” Each vulnerability gets a 
score and our score was very high. “Very high” 
is not good—it means that the vulnerability is 
a real serious threat to life on the planet (not 
really). He did find the security hole by using 
automated software tools and sniffing our data 
stream to and from the unit. If our EULA would 
have had the words from the thermostat’s 
EULA and he was honest, he would not have 
done this. Hacker’s will not pay attention to 
EULAs, but serious researchers will.
WHAT HAPPENED
At the time of the attack, when new 
software was sent down from the host, it was 
signed (preventing someone from sending 
unauthorized software to our system) but it 
was not encrypted. This enabled any hacker 
to get access to the PHP code that handled 
the HTTP interface. With code in hand, anyone 
could find an obvious and gaping security 
hole where we were taking input from the 
HTTP interface and passing it to the Linux 
command line interpreter. We did not limit 
or bound the input in any way. This enabled 
the user to spoof the host and basically send 
whatever commands he wished to the Linux 
shell. He could create new user accounts. He 
could read our symmetric keys. Ouch!
This is a technique called “command 
injection” which is a subset of “code injection.” 
How did this happen? We know better. We 
know what command injection is. We know 
the dangers of command injection. We know 
how to stop it and even exploit it. In my 
article “ The Internet of Things (Part 5): IoT 
Security” (Circuit Cellar 307, February 2016) 
I discussed how we used extremely clever 
command injection to update some devices 
remotely that were destined for RMAs. How 
could this happen? Simple. Our systems 
are more complex that we are capable of 
perfectly protecting. But that doesn’t mean 
we don’t keep pushing for perfection. With 
that in mind, let’s look a little more in depth 
at command injection.
In my article “The Internet of Things (Part 
8): Security for Web-Enabled Devices” (Circuit 
Cellar 313, August 2016) I talked about code 
injection specifically with SQL which provided 
a simple mechanization for injecting unwanted 
code into the system. Our failure made it even 
easier to inject commands. Command Injection 
is a subset of Code Injection. In the Common 
Weakness Enumeration Database referenced 
in my article “The Internet of Things (Part 7): 
DoS Attacks with a Twist “ (Circuit Cellar 311, 
June 2016) command injection is identified as: 
“CWE-77: Improper Neutralization of Special 
Elements used in a Command.” Basically, a 
command injection vulnerability means that 
external to your IoT device, a shell command 
or operating system command can be executed 
that is not intended.
COMMAND INJECTION EXAMPLE
Our security breach didn’t happen over 
Internet traffic. It happened through use of 
an installer accessible configuration screen 
from an Ethernet port. When the configuration 
screen saved the settings, it created a URL 
with all of the settings as parameters. These 
were sent to an XML parser. These parameters 
were visible to someone sniffing the local 
communication which could then be modified 
to include any Linux command to be executed. 
The code snippet is shown in Listing 1.
cmdxmlin is an app that we wrote that 
parses xml input. Notice that we didn’t call 
the PHP shell_exec directly. A sophisticated 
hacker could still simulate the web browser 
and append his own commands by utilizing a 
feature of the shell command called sequential 
execution. Or the hacker could take advantage 
of many of the flexible features of the bash 
shell to perform all sorts of nefarious attacks.
LISTING 1 
Code snippet that captures configuration settings.
if ($_GET[‘submit’])// when saving config
{
 $keys = array_keys($_POST); // get all the parameters
 $config_string = ‘’;
 foreach ($keys as $key)
 { // Fill config_string with the parameters on the URL
 $config_string .= “\”$key=$_POST[$key]\” “;
 $response = `/apps/cmdxmlin set ${config_string}`;
 }
}
FIGURE 1 
The ICS-CERT coordinates control 
systems-related security incidents 
and information sharing with 
Federal, State, and local agencies 
and organizations, the intelligence 
community, and private sector 
constituents, including vendors, 
owners and operators and 
international and private sector CERTs.
CIRCUIT CELLAR • FEBRUARY 2018 #33152
CO
LU
M
NS
When I first introduced the topic of IoT 
security in this magazine, I described it as 
defending a castle where there are many 
layers of protection including the moat; the 
bridge, the entrance gate, the wall and even 
the boiling oil. I recommended that you use 
as many layers of protection as possible to 
mitigate risks. Our security gap could have 
been closed or mitigated through a number of 
layers as listed here:
Encrypting all program updates: Without 
being able to read the code, many forms of code 
and command injection security breaches can 
be avoided or at least be physically impossible 
to find by trial and error. A lot of web services 
code is interpreted rather than compiled. That 
means the source code is sent down during an 
update. Sending your code down unencrypted 
is just asking for trouble.
Don’t provide root access to the web 
interface: When we released our first IoT 
device, one of our customer’s customers 
asked us if our applications ran as root. They 
did because we didn’t know better. They 
refused to buy the product until we changed 
all of our application code to run as non-root. 
What would have been easy at the start of 
the design was difficult after the design was 
complete. Without root access, the hacker 
could not have done much damage even with 
the command injection security hole.
Limit write access to all critical files: This 
is similar to limiting root access. A careful 
look at your permissions to your files is in 
order. The web server app should not be 
able to write any file without some sort of 
authentication. Ideally the web server itself 
should be limited, but most are not. If your 
web server doesn’t support this, then some 
sort of watchdog that monitors certain critical 
files would be helpful.
Bound all input: Input from the web should 
be limited to be valid only within the narrow 
range of what you expect. We must recognize 
our inherent blind spots in this area. It is hard 
for us to think of all of the possible ranges of 
input. I love the first example from the classic 
“The Art of Software Testing” by Glenford 
Myers called a “Self-Assessment Test.” In it, 
he asks you to create a set of test cases for 
the following simple program:
The program reads three integer values from 
an input dialog. The three values represent the 
lengths of the sides of a triangle. The program 
displays a message that states whether the 
triangle is scalene, isosceles or equilateral.
Put down this article and try this now. 
Write out every distinct test case you can 
think of. You will have to buy the book to see 
how many you got right. Or email me your 
test cases and I will grade it. At the end of 
the article are three of the fourteen that I 
missed completely. This self-assessment test 
demonstrates how difficult it is to plan for 
every possible input.
Never treat data from the web as a 
command to the shell: Our engineer assigned 
to this described his fix as following:
We closed the hole by writing the “save 
configuration” data to a temporary file, 
rather than passing them to the command 
line interpreter. The ‘cmdxmlin’ program 
How the Anticipator Works
Before computers, electro-mechanical temperature controls 
used to have some pretty cool features. In today’s era of very 
cheap processing, we sometimes missthese kinds of solutions to 
the problems we face. Mercury switch thermostats have a coil that 
expands and contracts based on the temperature and rotates the 
mercury switch which turns on or off the furnace. In addition, there 
is a resistor in the thermostat through which the current flows 
that drives the relay that controls the furnace. When the furnace is 
running, current flows through the resistor. As the resistor warms 
up, because it is close to the thermostat coil, it warms up the coil 
(above the ambient temperature). That uncoils the spring and tilts 
the mercury switch to shut off the furnace before the ambient 
temperature reaches the setpoint thus preventing overshoot. The 
resistor is adjustable and if not set right can early or late shut off.
PHOTO 1
Mercury switch thermostats had an electro-mechanical feature called a heat 
anticipator that worked very efficiently.
For detailed article 
references and additional 
resources go to:
www.circuitcellar.com/
article-materials
http://www.circuitcellar.com/article-materials
circuitcellar.com 53
CO
LU
M
NS
that used to take the configuration data as 
command line parameters now reads the 
configuration data from /tmp/set_args.txt. 
This way the configuration items are treated 
as data and not evaluated by the command 
line interpreter.
Study every use of calls to the command 
line interpreter (shell): Be very careful with 
the passthrough exec system in PHP, the 
subprocess or os.system in Python, the 
system in Ruby…and you get the idea.
Push hard to close vulnerabilities: We 
knew about this security hole in 2012. It 
was exposed in 2015 and embarrassed the 
customer in 2016. The customer closed the 
vulnerability as soon as it was reported. We 
didn’t push hard enough to get this changed 
as soon as we knew about it. We as developers 
need to be more insistent about closing 
security holes.
An open EULA: We have come full circle from 
our introduction. I would challenge our users to 
find our security holes. Let them use automated 
tools to find our holes. Let them sniff our data. 
Then the EULA would ask them to report it to us 
before reporting it to a government watchdog 
agency. As I said earlier, the systems are more 
complex than we are capable of protecting. We 
need others help—especially those that want to 
make a name for themselves at our expense. It 
is really to our benefit.
CONCLUSION 
When you handle things in thin slices, 
there is so much to say and so little space to 
say it. IoT security is absolutely vital. We 
need to get this as right as possible. And we 
need each other’s help. Software terrorism 
has just begun. In my opinion we’ll only see 
it increase. Next time, more lessons learned 
in IoT security. 
ABOUT THE AUTHOR
Bob Japenga has been designing embedded 
systems since 1973. In 1988, along with his 
best friend, he started MicroTools, which 
specializes in creating a variety of real-
time embedded systems. MicroTools has a 
combined embedded systems experience 
base of more than 200 years. They love 
to tackle impossible problems together. 
Bob has been awarded 11 patents in many 
areas of embedded systems and motion 
control. You can reach him at rjapenga@
microtoolsinc.com.
cc-webshop.com
Monte demonstrates how Verilog 
hardware description language (HDL) 
enables you to depict, simulate, and 
synthesize an electronic design so 
you can reduce your workload and 
increase productivity.
designing a microprocessor 
 can be easy. 
Okay, maybe not easy, but certainly 
less complicated. Monte Dalrymple 
has taken his years of experience 
designing embedded architecture and 
microprocessors and compiled his 
knowledge into one comprehensive guide 
to processor design in the real world. 
Verilog HDL
With the right tools
http://www.cc-webshop.com
mailto:rjapenga@microtoolsinc.com
CIRCUIT CELLAR • FEBRUARY 2018 #33154
CO
LU
M
NS
M any systems must communicate with the outside world. Often their information-bearing 
signal can be carried by wires, 
but this may not always be practical or 
even possible. Fortunately, the information-
bearing signal can be altered—modulated— 
into another signal that is suitable for 
communication via radio, fiber optics, long 
cable and so forth. We call the original 
information the baseband and the modulated 
signal the carrier. Demodulation is a reverse 
process for retrieval of the baseband from the 
carrier.
In telephony, for example, every voice 
channel modulates a sub-carrier. The sub-
carriers are combined to modulate higher 
frequency carriers and those once again may 
modulate an even higher carrier that may be 
transmitted over fiber optics or microwave 
links. Consequently, much information—
voice and data—can be carried by a single 
transmission medium.
The oldest modulation technique is the 
amplitude modulation (AM). It is simple 
to implement and simple to demodulate. 
Figure 1 shows an idealized frequency 
spectrum of an AM carrier. In North America, 
the highest AM radio program frequency 
is 5 kHz and should the carrier frequency 
be 1 MHz, the required bandwidth will be 
995 kHz to 1005 kHz—10-kHz in total. 
Therefore, broadcast AM station carriers are 
spaced by 10-kHz to avoid interference within 
the AM radio operating band of 525 kHz to 
1,705 kHz. The latest AM broadcast modulation 
can carry additional information such as 
stereo, but AM is rather inefficient in terms of 
its power and bandwidth requirements. It is 
also subject to noise and interference.
The interference could be reduced by 
increasing the transmitting power, but there 
are practical as well as regulatory limits. The 
power inefficiency is caused by the carrier, 
which consumes most of the power and 
contains no information. And the bandwidth—
because it contains two mirror basebands—
requires double the maximum modulation 
frequency. Several methods have been 
implemented to reduce these inefficiencies.
The Consummate Engineer
Modulation Fundamentals
Modulation and demodulation are key techniques through 
which digital systems communicate with the analog 
world. In this article, George looks at various modulation/
demodulation methods and discusses the advantages and 
disadvantages of each.
By
George Novacek 
circuitcellar.com 55
CO
LU
M
NS
For detailed article references and additional resources go to:
www.circuitcellar.com/article-materials
The first method is the reduction of the 
carrier amplitude—reducing it down to, in 
some systems, its full suppression. Because 
the carrier is needed for demodulation, 
it can be restored or regenerated by the 
receiver. The second method involves the 
sidebands. Because both sidebands carry 
identical information, one of them can also 
be suppressed, cutting the bandwidth by 
half. These modulation techniques are called: 
reduced or suppressed carrier with double 
sidebands (DSB) and a single sideband with 
suppressed carrier (SSB). Vestigial sideband 
modulation (VSB) is similar to SSB but requires 
greater bandwidth. It is used primarily in 
TV transmission. The on-off keying (OOK) is 
popular for simple data transmission, in key 
fobs and remote control.
OOK MODULATION
OOK modulation results when the 
baseband is a rectangular wave, such as 
digital data. In many applications the OOK 
modulation index is 100%—such as when 
the carrier is fully on or off. In the days of 
Morse code communications, the continuous 
wave (CW) transmission mode was a typical 
OOK modulation. Some applications—
namely the WWVB transmission for clock 
synchronization—use 86% modulation index to 
prevent receivers from losing synchronization 
during transmission of logical 0s.
Three characteristics define the AM 
modulation: the carrier frequency, the 
bandwidth and the modulation index. Figure 2a 
shows 100% and Figure 2b 50% modulation 
index (depth). Amplitude modulators come 
in many different configurations and are 
quite simple to build. One of the early 
implementations was the bridgemodulator 
shown in Figure 3. Figure 4 shows the WWVB, 
86% depth modulator I built for my 60-kHz 
carrier transmitter in the WWVB repeater. 
This was covered in my article “WWVB Clock 
Revisited” (Circuit Cellar 288, July 2014). In 
this circuit the MOSFET Q1 operates in its 
resistive region to modulate the gain of the 
carrier amplifier U1A.
 Demodulation of the broadcast AM signal is 
commonly performed by envelope detectors, 
which can be nothing more than a simple 
rectifier diode followed by an RC network. The 
time constant of this network must be much 
larger than the carrier frequency period and 
much smaller than the shortest baseband 
period (the highest baseband frequency). 
This is generally not a problem in practical 
systems.
Demodulation of DSB and SSB are more 
complicated because the carrier needs to 
be restored. A suppressed carrier can be 
easily recovered by amplification. The fully 
FIGURE 1
Frequency spectrum of an AM modulated signal (not to scale)
FIGURE 2
In the top graph (a) a 100% modulation index is shown. The bottom one (b) shows a 50% modulation index.
a)
b)
FIGURE 3
Bridge AM modulator
http://www.circuitcellar.com/article-materials
CIRCUIT CELLAR • FEBRUARY 2018 #33156
CO
LU
M
NS
suppressed carrier is regenerated by a stable 
local oscillator as we can see in ham radio 
receivers. Another method for modulating 
a carrier is by changing its frequency or 
phase. Such modulation techniques can be 
seen in four basic configurations: Frequency 
modulation (FM) also used for commercial 
broadcast, phase modulation (PM), frequency 
shift keying (FSK) and phase shift keying 
(PSK). Figure 5 shows the FM carrier in 
frequency domain.
FM AND PM MODULATION
Similar to the AM, the main characteristics 
of the FM and the PM modulation are the 
carrier frequency, the required bandwidth 
and the modulation index. The modulation 
index is the frequency or phase deviation 
of the carrier in response to the modulation 
signal. PM is similar to the FM except that 
instead of changing the carrier frequency, 
which remains constant, only its phase is 
modulated. In the time domain analysis, both 
FM and PM look the same, just the deviation 
magnitudes are different. The FSK and the 
PSK modulations are used for transmission of 
logical data, because the frequency and the 
phase change in discrete steps.
FM carriers often contain multiple sub-
carriers for additional information. Figure 6 
shows the baseband spectrum of a typical FM 
broadcast station. The stereo information is 
modulated on a 38-kHz subcarrier generated 
from the 19-kHz pilot. Several other 
information bands, originally designed for 
quadraphonic music, can be transmitted on 
additional subcarriers.
There are many ways to perform FM, PM, 
FSK and PSK modulation of a carrier signal. 
One of the original approaches was to utilize 
varactor diodes (diodes whose capacitance 
can be varied by voltage) in the carrier 
generator. Nowadays many modulators use a 
phase locked loop (PLL), which can include a 
reference crystal oscillator to guarantee high 
stability of the carrier (Figure 7).
PLLs are available as integrated circuits 
and only a few external components need to be 
added. A PLL is in fact an electronic feedback 
servo system. A stable crystal-generated 
carrier frequency is fed into the phase detector 
which compares the frequency of the voltage 
controlled oscillator (VCO) with the reference. 
Because of the (optional) divider, the carrier 
frequency may be a multiple of the reference. 
The error signal from the phase detector to 
adjusts the VCO frequency is modulated by 
the baseband, causing the carrier frequency 
or phase to deviate accordingly.
Quadrature amplitude modulation (QAM) 
is a sophisticated modulation known by many 
FIGURE 4
Simplified diagram of the WWVB modulator
FIGURE 5
Frequency modulated carrier
FIGURE 6
Multiple modulation of an FM broadcast carrier
circuitcellar.com 57
CO
LU
M
NS
ABOUT THE AUTHOR
George Novacek is a retired president of an 
aerospace company. He is a professional 
engineer with degrees in Automation and 
Cybernetics. George’s dissertation project was 
a design of a portable ECG (electrocardiograph) 
with wireless interface. He’s been contributing 
articles to Circuit Cellar since 1999. Contact 
him at gjnovacek@nexicom.net with “Circuit 
Cellar”in the subject line.
readers as the heart of the old “high-speed” 
56k telephone modems. It is a combination 
of AM and PM. Given the limited bandwidth 
of the old analog telephone channels, QAM 
pushed its information carrying ability almost 
up to the theoretical limit.
ADVANTAGES FOR EACH
Each modulation technique has its 
advantages, disadvantages and applications. 
AM has been used in radio broadcasting 
since the birth of radio. Its modulation 
and demodulation are easy to implement 
and the receivers are rather inexpensive 
to build. DSB is used in instrumentation 
systems utilizing carrier amplifiers and 
modulating sensors, while SSB finds its 
use in certain radio communications, 
many by ham amateurs. Its derivative VSB 
modulates television signals. FM provides 
much better audio quality than the AM and, 
therefore, is used in broadcasting (radio 
and television audio). Its narrow bandwidth 
version and PM rule point-to-point mobile 
communications. FSK and PSK are employed 
for digital communications, while the 
analog QAM carries the chrominance (color) 
information in television broadcasting and 
the OOK is commonly found in remote 
control systems, key fobs and some digital 
data transmitters.
For completeness we should mention 
two special modulations: frequency hopping 
and spread spectrum modulation. These 
modulations do not carry information per 
se. The former is intended to increase 
communications security while the latter 
improves electromagnetic compatibility 
(EMC) of electronic systems.
Over the years numerous circuits have 
been developed for demodulation of FM, PM 
and other modulations. Older demodulators 
used the slope of LC resonant circuits, then 
came ratio detectors, PLLs, quadrature 
demodulators and others. Nowadays PLLs 
(Figure 8) are still used for both FM and PM 
demodulation, but this is quickly changing. 
Our present-day technology facilitates the 
development of digital radio, which relies 
on digitization of the carrier frequency. This 
makes possible digital signal processing 
and may be followed by conversion of the 
digital data back to analog to recreate 
the baseband. Whether data or voice 
communications are involved makes little 
difference. Digitization of 10 GHz carrier 
is already a reality and once digitized, the 
skies are the limits for further processing.
 I intentionally omitted the pulse width 
modulation (PWM). This is a technique for 
conversion of digital signals to analog power 
and not fitting the current topic. 
FIGURE 7
Principle of phase and/or frequency modulation by PLL
FIGURE 8
PLL demodulator
mailto:gjnovacek@nexicom.net
CIRCUIT CELLAR • FEBRUARY 2018 #33158
CO
LU
M
NS
The Darker Side
W elcome back to The Darker Side. My previous article was about the great 
results established by 
Claude Shannon in 1948. In that article—
”Information Theory in a Nutshell” (Circuit 
Cellar 329, December 2017)—I dealt with 
noise-free transmissions and I promised that 
this month I’d talk about the more interesting 
noisy channels. Well, here we go! Take a seat 
and enjoy. As always, I will use as little math 
as possible so you can grab the fundamentals.
In case you’ve either missed my last article 
or you need a refresher, here’s a summary: 
Information theory studies the transmission 
of data between devices, through a given 
transmission channel. Information theory is 
based on math, so it provides very strong 
and generic results. Thanks to its wide scope, 
it has applications ranging from computer 
science to biology to cosmology and—
fortunately—electronics.
In my last article, I assumed that the 
transmission channelwas error free: Every 
bit transmitted was supposed perfectly 
received. In that case, the so-called 
Shannon’s “noiseless coding theorem” (also 
called “source coding theorem”) allows you 
to calculate the minimum channel capacity 
in bits per seconds (bps), depending on the 
source. More exactly, Shannon assumes that 
the source generates on average S symbols 
per second. Each symbol is taken from a set of 
N different symbols. Symbols could be groups 
of bits, English words or anything else. And 
finally, each symbol has a given probability pi
to appear—meaning that some symbols could 
be sent more often than others. Assuming 
that the source has some good statistical 
properties (experts talk about “ergodic 
source”), Shannon defined a value called the 
entropy E of the source, calculated as:
E p p p p
p p etc
= − × − × −
× −
1 2 1 2 2 2
3 2 3
log ( ) log ( )
log ( ) .
In that formula, log2 is the logarithm 
function calculated using base 2, easily 
calculated as:
log ( ) log( )
log( )2 2
x x=
Ok, nothing exciting there…until you 
know the first strong theorem established by 
Shannon. It states that this entropy E is in 
fact closely linked to the minimum required 
channel capacity to transmit the data flow:
C bits s E entropy per symbol
in bits S symbo
MINIMUM( / ) ( ,
) (
=
×
 
 lls s/ )
Here’s an example: If the source sends 
S = 1,000 symbols per second and if the 
calculated entropy of the source is E = 1.5 bits 
per symbol, then the minimum capacity of the 
channel is 1,500 bits per second. This means 
that there is a way to correctly encode the 
data flow such that 1,500 bps are enough, on 
average. Read again in my last article where I 
showed that the so-called Hamming encoding 
enables you to come as close as you want to 
Shannon and Noise
In his previous article on Information Theory, Robert explained 
the Shannon–Hartley theorem as applied to the case of error-
free transmissions. This time he applies the theorem to noise, 
for which the theorem is even stronger and more impressive.
By
Robert Lacoste
Putting the Theorem to Work
circuitcellar.com 59
CO
LU
M
NS
this limit. Conversely this theorem also states 
that there isn’t any way to reduce it to less 
than this limit—even if you are the cleverest 
engineer on Earth!
In this article I will no longer assume 
that the channel is noise free. For simplicity, 
I will however restrict myself to the case 
of a binary data source (there are only two 
symbols to transmit: 1 and 0). I will also 
assume that the probability of 1s and 0s is 
identical: 50% of the bits are 1s and 50% are 
0s. It you do the calculation of the entropy of 
such a source, using the formula above, you 
will find of course that E = 1. This means that 
such a source needs a channel with a capacity 
of 1 bit per symbol: C = 1 x S = S. This simply 
means that there isn’t any way to compress a 
random source of binary bits.
SOME NOISE?
Okay, now let’s see what happen when there 
is some noise. And there is always noise in a 
circuit or transmission. Trust me! First of all, 
noise introduces errors in the bit transmission. 
Secondly, noise will limit the capacity of the 
channel, depending on its bandwidth. That 
second sentence may seem strange, but don’t 
worry. I will come back to it.
For the moment, I will simply assume 
that the noise introduces some errors on the 
transmitted bits. Of course, the higher the 
noise, the higher the probability to receive a 
wrong bit—as illustrated on Figure 1. By the 
way, I devoted an article on bit errors a while 
FIGURE 1
When noise increases, the probability 
of an error on a single bit also 
increases. Here the noise is supposed 
gaussian, which implies that there are 
always some errors from time to time.
5
0
Noise = 0.10 V (RMS) − Eb/No = 20 dB
−2 −1.5 −1 −0.5 0 0.5 1 1.5 2
2
0
Noise = 0.32 V (RMS) − Eb/No = 10 dB
−2 −1.5 −1 −0.5 0 0.5 1 1.5 2
1
0
Noise = 0.50 V (RMS) − Eb/No = 6 dB
−2 −1.5 −1 −0.5 0 0.5 1 1.5 2
1
0.5
0
Noise = 0.71 V (RMS) − Eb/No = 3 dB
−2 −1.5 −1 −0.5 0 0.5 1 1.5 2
0.5
0
Noise = 1.00 V (RMS) − Eb/No = 0 dB
−2 −1.5 −1 −0.5 0 0.5 1 1.5 2
CIRCUIT CELLAR • FEBRUARY 2018 #33160
CO
LU
M
NS
ago called “Let’s Count Errors” (Circuit Cellar 
295, February 2015).
If we assume that the probability of a bit 
error perr is not null, then the transmission will 
be deteriorated. Now, assume that you need to 
design a reliable and error free transmission 
using such a channel. What would your 
options be? You could try to improve the 
electronics with a better signal to noise ratio 
(SNR), reducing the noise as much as you can 
or try using stronger signals. Another way—
more interesting from an information science 
point of view—would be to use an error 
correction protocol instead of just sending 
the raw bits. Such a protocol would help to 
recover the erroneous bits—as long as they’re 
not too numerous. For that, you could simply 
add checksums to the transmitted data and 
retransmit any wrongly received message. 
You could also use forward error correction 
codes, as explained in another of my old 
articles: “ Living with Errors: An Introduction 
to Forward Error Correction,” (Circuit Cellar 
235, February 2010). 
In either case, the addition of these error 
correcting protocols will inevitably increase 
the number of bits to be transmitted. You 
will have to transmit not only the source 
bits, but also additional bits like checksums, 
retransmissions, error correcting codes and 
so on (Figure 2). So, when noise introduces 
some errors in the transmission, the actual 
channel capacity must be higher to allow 
error recovery. More exactly, this capacity 
(in bits per seconds) must be more than the 
minimum capacity in the case of a noise free 
channel, which is the entropy of the source 
times the symbol rate. But how much more?
FUNDAMENTAL THEOREM
And here comes some magic again 
with the fundamental Shannon theorem in 
presence of noise. Shannon proved that the 
minimum channel capacity in the presence of 
such a noise must be:
C bits s E entropy per symbol
in bits S symbols
MINIMUM ( / ) ( ,
) ( /
=
×
 
 ss
R reduction factor
)
( ) 
or
C bits s B useful bit rate bits s
R reduction facMINIMUM
( / ) ( , / )
(
= 
 ttor)
In this formula, R is called the reduction 
factor, and can be easily calculated with the 
following function:
R p p p perr err err err= + × + − −1 1 12 2log ( ) ( ) log ( )
As you can see, this number is only 
dependent on the bit error rate. It is always 
FIGURE 2
Error correction protocols always 
reduce the available throughput, or 
increase the required raw channel 
capacity for the same useful 
throughput.
Without errors
Useful bit rate Useful bit rate Useful bit rate
With risks of errors
Same raw channel capacity
Smaller 
useful bit rate
Smaller 
useful bit rate
Smaller 
useful bit rate
Error correction
overhead
ABOUT THE AUTHOR
Robert Lacoste l ives in France, between 
Paris and Versailles. He has 30 years of expe-
rience in RF systems, analog designs, and high 
speed electronics. Robert has won prizes in more 
than 15 international design contests. In 2003 
he started a consulting company, ALCIOM, to 
share his passion for innovative mixed-signal 
designs. Robert’s bimonthly Darker Side column 
has been published in Circuit cellar since 2007. 
You can reach him at rlacoste@alciom.com.
mailto:rlacoste@alciom.com
circuitcellar.com 61
CO
LU
M
NS
between 0 and 1. Look at the plot of this 
function on Figure 3. The capacity of a channel 
in presence of noise is simply reduced by a 
factor R, depending on the error probability. 
An example should help: Assume that you 
send ten million binary symbols (bits) per 
second and that 5% of them are corrupted by 
noise. What would be the minimum channel 
capacity for an error free transmission? Here 
we have E = 1 (one bit per symbol), S = 10M 
and R = 1+0.05.log2(0.05) + 0.95.log2(0.95). 
Do the calculation and you will find R = 
0.71. That meansthat the minimum channel 
capacity in that case is:
C M MbpsMINIMUM = × =1
10
0 71
14 1
.
. 
Okay, but what does this actually 
mean? What did Shannon prove? First, he 
demonstrated that if the raw channel capacity 
is lower than this value then there is absolutely 
no way to invent an error correction protocol 
that will correct the transmission errors. 
You will always have a significant number of 
errors, even if you are a genius. Conversely, 
Shannon also demonstrated that there exists 
a solution to have an error rate as low as 
you want, as long as the channel capacity is 
just slightly above that threshold. That result 
astonished the community in 1948—and is 
still to this day nearly unbelievable. The bad 
news is that the Shannon theorem is not a so 
called constructive proof. It doesn’t tell you 
what this best error correction method is, 
but simply that it exists. With that in mind, 
thousands of researchers are working on 
error correcting codes since 1948, in order 
to find error correction codes as close as 
possible to Shannon limit!
To summarize, the quite simple formula 
given above enables you to calculate the 
Shannon limit or Shannon capacity of a 
communications channel, which is the 
theoretical maximum error-free information 
transfer rate of the channel for a particular 
noise level. Information simply cannot be 
guaranteed to be transmitted reliably at rates 
beyond this channel capacity.
LIMITED BANDWIDTH
In my introduction, I told you that noise 
also limits the capacity of the channel 
depending on its bandwidth. What’s that 
all about? To understand, we have to move 
from a theoretical transmission channel to 
something closer to an actual channel—like 
a wire or radio link. It will for sure have a 
limited bandwidth W, expressed in Hertz. 
Let’s assume W = 100 kHz, and for simplicity’s 
sake consider that the channel is something 
like a brick-wall filter: It transmits perfectly 
all frequencies from DC to 100 kHz, but stops 
any signals above that threshold. 
What’s the capacity of such a channel 
in bits/s? First, a strange but true result: If 
there isn’t any noise, then this capacity is 
infinite. Now you probably think I’m crazy. Hey 
1.0
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
Channel
capacity
reduction
Probability
of bit error
0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5
FIGURE 3
This plot shows you the reduction of 
the channel capacity R, depending 
on the probability of an error on 
single bits: perr. Not surprisingly, 
the throughput is 100% when there 
are no errors, and 0 when bits are 
random (50% of bits wrong).
CIRCUIT CELLAR • FEBRUARY 2018 #33162
CO
LU
M
NS
Robert, don’t you remember Nyquist limit? As 
the channel bandwidth is W then one can 
send only send 2xW independent samples 
per second on the wire. It is the same rule 
applies when you state that a 200 ksample/s 
analog-to-digital converter (ADC) can only 
manage signals up to 100 kHz. That is true, 
but if there is absolutely no noise then each 
sample can have theoretically an infinite 
resolution! You could for example group the 
bits to be transmitted 100 per 100, convert 
each group into an analog voltage with a 
100-bit ADC (remember, there isn’t any noise 
at all so this is theoretically possible) and 
send that voltage 200k times per second. 
You would get 100 x 200k = 20 Mbps. If you 
need more, just increase the ADC resolution. 
This is exactly the idea behind what is called 
pulse code modulation (PCM), invented in 
1937 by A.H Reeves (French Patent 852,183).
So, you understood that the actual 
capacity of a channel is in fact limited by 
noise—or more exactly by the signal to noise 
ratio (SNR). Now let’s look at another form 
of the Shannon limit formula, usually called 
the Shannon–Hartley theorem. It could be 
derived from the formulas above but just take 
it as granted. Assuming that the noise is a 
“good” noise (gaussian), then the maximum 
number of useful error-free bits per second 
Bmax is:
B bits s W Hertz SNRmax( / ) ( ) log ( )= × +2 1
Figure 4 shows you the behavior of 
this function but I am sure you want some 
examples. If the signal to noise ratio is 1 
(same signal power as noise power), then:
B W Wmax log ( )= × + =2 1 1
In that case you can transmit 1000 error-
free bits per second in a 1,000 Hz channel 
bandwidth. However, if the signal to noise 
ratio is far better—say if the signal is 100 
times more powerful than noise (20 dB 
ratio)—then:
B W Wmax log ( ) .= × + = ×2 1 100 6 65
In the same 1,000 Hz bandwidth, you could 
then transmit 6,650 bits per second without 
error!
EB/N0?
I have covered all the important aspects 
of Shannon’s theorem, but here’s some 
additional information for those who want to 
go a little deeper. Just jump over this section 
if you’re feeling overloaded with math.
If you open any book on signal processing or 
information theory, you will find the expression 
“Eb/N0” in every page. What is this strange 
thing? It’s quite simple in fact. But I must admit 
that it took me some time to understand it and 
to link it to the formulas above. Here is my 
personal summary: Eb is the energy per bit (in 
Joules), calculated for each useful transmitted 
bit. It is then equal to the signal power S (in 
Watts) divided by the useful bit rate B:
Eb S signal level
B useful bit rate error free
= ( )
( , )
 
 
Similarly, N0 is called the noise power 
spectral density ratio. It is the noise power 
FIGURE 4
Here is the maximum useful error-free 
bit rate Bmax for 1 Hz of bandwidth, 
depending on the signal to noise ratio 
SNR (here expressed in dB).
7
6
5
4
3
2
1
0
Error
free bits
per Hertz
SNR (dB)
−20 −15 −10 −5 0 5 10 15 20
For detailed article 
references and additional 
resources go to:
www.circuitcellar.com/
article-materials
http://www.circuitcellar.com/
circuitcellar.com 63
CO
LU
M
NS
in a 1 Hz bandwidth, measured in Watts per 
Hertz. N0 is then calculated as the total noise 
power N divided by the channel bandwidth W:
N N noise level
W channel bandwidth
0 = ( )
( )
 
 
You will notice that Eb and N0 are 
both expressed in Joules, so their ratio is 
dimensionless. It can then be expressed 
in decibels if you wish. Of course, Eb/N0 is 
closely related to the carrier-to-noise ratio:
SNR S N Eb B
N W
Eb N B W= = ×
×
= ×/ ( )
( )
( / ) ( / )
0
0
And finally, remember the Shannon 
capacity limit? It is calculated as:
B bits s W Hertz SNRmax( / ) ( ) log ( )= × +2 1
The useful bit rate B should stay below the 
threshold Bmax, so we must have:
B W SNR or
B W Eb N B W
< × +
< + ×
log ( )
/ log ( / / )
2
2
1
1 0
 
If we call H = B/W (useful bits per Hertz of 
bandwidth), then this leads to:
H Eb N H or
Eb N HH
< + ×
< + ×
log ( / )
/
2 1 0
2 1 0
 
or finally:
Eb N
H
H
/ ( )0 2 1 > −
Read this last formula again. It provides 
an absolute minimum on Eb/N0, depending 
only on the effective number of bits per Hertz 
of bandwidth. This is illustrated on Figure 5. 
If H is very small (large bandwidth), then Eb/
N0 gets close to ln(2), which in decibels is 
10log(ln(2)) = -1.59 dB. This often-quoted 
limit of Eb/N0 = −1.59 dB applies only to the 
very theoretical case of infinite bandwidth. 
For limited bandwidth, the absolute 
Eb/N0 limit is always higher. For example, if 
H = 2 (bandwidth twice more than the bit 
rate), then the formulas shows that Eb/N0 is 
always above 1.76 dB.
WRAPPING UP
I know that these two articles on 
information theory were a little more math-
oriented than usual, but I am strongly 
convinced that these results are far too 
important to be skipped by any electronic 
engineer, ham radio guy or 
telecommunication enthusiast. I hope that 
you have grabbed the essentials. If not, read 
these articles again and have a look on the 
books and articles listed on Circuit Cellar’s 
article materials webpage. And finally, like 
most of you, I’m far more of an electronic 
designer than an information science expert, 
so don’t hesitateto contact me if I’ve said 
something wrong or too simplified. Last but 
not least, play with these formulas yourself 
and have fun! 
16
14
12
10
8
6
4
2
0
−2
Eb⁄No
minimum
(dB)
Error free bits per Hertz
0 0.5 1.51 2 2.5 3 3.5 4 4.5 5 85.5 6 6.5 7 7.5
FIGURE 5
The maximum achievable Eb/N0 
performance is closely linked to H: the 
number of useful error-free bits per 
Hertz of bandwidth.
CIRCUIT CELLAR • FEBRUARY 2018 #33164
CO
LU
M
NS
From the Bench
Money Sorting Machines (Part 3)Money Sorting Machines (Part 3)Money Sorting Machines (Part 3)
Bill Validation
M ost of us connect Ben Franklin with kites and lightning. He was also a printer and 
might be best known for Poor 
Richard’s Almanack—a yearly publication 
that he published from 1732 to 1758 under 
the pseudonym of Richard Saunders. It was a 
best-seller and thanks to his wit and wisdom, 
his portrait was added to the cover of The 
Old Farmer’s Almanac in 1851—appearing 
opposite the founder Robert B. Thomas. It 
remains there today.
As a master printer and engraver, in 1730 
Franklin began printing all paper money issued 
by Pennsylvania, New Jersey and Delaware. 
Paper money was first introduced in the 
region in 1723, but it remained a hot political 
issue. That’s because it helped farmers and 
tradesmen, while merchants and landowners 
wanted it eliminated or limited in its circulation. 
Paper money printed from ordinary type was 
easy to counterfeit, but Ben’s ingenuity solved 
that problem by printing pictures of leaves on 
every piece of money. Counterfeiters could 
not duplicate—or even imitate—the fine lines 
and irregular patterns. The process by which 
he made the printing plates was secret, but 
were probably cast in type metal from molds 
made by pressing leaves into plaster of Paris. 
There began the Feds vigilant effort to thwart 
counterfeiters.
Today every aspect of our paper currency 
is controlled—from its design to its printing, 
as well as its monitoring and destruction. The 
paper (which is not paper) and ink (multiple 
types and formulas) are fabricated for the 
express use by the Department of Engraving. 
That department is the Treasury bureau 
responsible for paper money—as opposed to 
the U.S Mint, which is the Treasury bureau 
responsible for coinage. US currency consists 
of 25% linen and 75% cotton and contains 
small randomly disbursed red and blue 
security fibers embedded throughout the 
material. Depending on the denomination the 
material is further enhanced by embedding 
security threads, ribbons and watermarks. 
Since 1996, printing with colored and color 
changing inks make the new currency pop. 
While older black and green currency is rather 
drab in comparison, it is still legal tender and 
remains the target of most counterfeiters.
The previous two parts of this article series 
centered around coinage. Before we look at bill 
validation for paper money, I need to finish up 
with that project. I had purchased a few Coin 
Acceptors and showed how they are used to 
identify coinage, especially but not limited to 
US coins. The acceptance and dispensing of 
money is presently used in many ways today, 
including vending machines and ATMs. The 
discussion also included National Automatic 
CO
LU
M
NS
In this final article of his money sorting 
machine series, Jeff wraps up his coin sorting 
project and examines how a bill validator can 
tell one bill’s denomination from another.
By 
Jeff Bachiochi
circuitcellar.com 65
CO
LU
M
NS
Merchandising Association (NAMA), the 
organization that developed the international 
specification for the Multi-Drop Bus/ 
Internal Communication Protocol (MDB/CP) 
released in July 2010. The MDB/ICP enables 
communication between a master controller 
and any of the peripheral hardware like Coin 
Acceptors and bill validators. By adhering 
to these guidelines, any manufacturer’s 
equipment is interchangeable.
Turns out the Coin Acceptors I purchased 
don’t have the MDB interface necessary 
to communicate with a Vending Machine 
Controller (VMC). I reviewed the protocol and 
VMC/Peripheral Communication Specifications 
required by the Coin Acceptor/Changer 
peripheral and began work on developing 
an MDB interface that would bridge my Coin 
Acceptor with the multi-drop bus.
PROJECT CIRCUITRY
If you need to review the MDB/ICP, please 
reread last month’s article (Circuit Cellar 330, 
January 2018) or get the specs from the NAMA 
website [1]. The communication protocol is 
9600, 9, 1, N. There are two unusual things 
here. First, you’ll note the data size on the 
MDB is 9 bits—not standard with many UARTs. 
The second thing here is that the multi-
drop bus uses a 20 mA control current and 
peripherals are opto-isolated from the bus. 
The LED transmitter in each opto-coupled 
device is easily turned on with 20 mA. The 
master directly interfaces with the bus and it 
must supply a minimum of 20 VDC with some 
hefty current in support of all connected 
peripherals. The MDB/ICP specs suggests 
some typical bus interfacing circuitry.
If you review this, you’ll find four different 
circuits (a through d), a non-isolated 
transmitter and receiver (master) and an 
isolated transmitter and receiver (slaves). 
There is a reason for presenting these as 
individual circuits (modules). This project 
requires emulating a slave device and, 
therefore, requires an isolated interface to the 
MDB. If you wanted to emulate a VMC (master) 
you would need a non-isolated interface to 
the MDB. Using modules would allow a carrier 
board to be configured for either a master or 
a slave by substituting modules! In fact, it also 
opens a third possibility—a configuration that 
might even be more useful in this project: an 
MDB spy board!
Without access to a complete system—like 
a product vending machine—it will be difficult 
to know if the protocol is being sent correctly 
unless we can monitor all MDB activity. 
Producing a spy device that can attach to the 
MDB and display both master transmissions 
and slave responses will be indispensable for 
assuring proper operation. A spy device will 
require two receivers for its configuration.
The carrier board will have a MDB 
connection on one end and a microcontroller 
with the ability to interchange 9-bit data 
with the MDB. My original project, the slave 
interface, requires a standard 8-bit UART to 
connect with the coin acceptor. While all the 
functions of a master could be programmed 
into this microcontroller when the carrier 
board is configured to emulate a master, 
a UART interface would enable a master 
interface to a PC. The PC could be used to 
emulate the master and allow a user to 
issue commands to the MDB. When used as 
a spy device the UART interface allows all 
communication to be displayed on a PC, LCD 
or even a printer! That’s the logic that has 
twisted this project’s circuitry into its present 
configuration.
The carrier board in last month’s 
installment contains a power supply front 
end for a master. Either an AC (transformer) 
or DC (power supply) input can be used for 
input when the carrier board is configured as 
a master. When used as a slave, the supply 
on the MDB is regulated into a 12 VDC supply 
and a 5 VDC supply. Not only does this give 
two additional voltage outputs for a slave/
spy device, but it also divides the regulator 
drops over two regulators reducing the 
power that must be dissipated by each. 
The microcontroller has a few configuration 
inputs and LEDs, enabling the application 
to be changed via jumpers. At present we’ll 
be using three of the four possible jumper 
settings for Mode 0:2—master, slave and spy.
SPYING
The protocol for any MDB activity requires 
that no slave send any response unless the 
master has asked that particular slave device 
to respond to its command. This means that 
while the MDB has a transmission path to all 
slaves and a separate response path from all 
slaves, that communication will only take place 
on one path at a time—either a commandor a 
response. You’ll note from the carrier board’s 
circuitry that when two receivers are used for 
ABOUT THE AUTHOR
Jeff Bachiochi (pronounced BAH-key-AH-
key) has been writing for Circuit Cellar 
s ince 1988. His background inc ludes 
product design and manufacturing. You can 
reach him at:
jeff.bachiochi@imaginethatnow.com or at:
www.imaginethatnow.com.
mailto:jeff.bachiochi@imaginethatnow.com
http://www.imaginethatnow.com
CIRCUIT CELLAR • FEBRUARY 2018 #33166
CO
LU
M
NS
a spy device (Mode 2), we have separate serial 
communication channels. If we are going to 
use one UART for peripheral communication, 
that only leaves one hardware UART left for 
the MDB communications. I figured I could 
just wire OR them into that UART. Since 
communication only exists on one of the two 
channels at a time, I could easily receive both 
through the same UART. This turned out to 
be a bigger issue than I expected. There 
was no easy way to determine the end of the 
command and the beginning of the response. 
Each command (or sub command) can have 
different lengths. After trying to predefine 
this, it was turning into a difficult project.
I experimented a bit with using an 
additional input to the MCU to determine 
when the command receiver was active. After 
that, I figured as long as I was going to use 
an additional input, I might as well implement 
a third UART via software. With the command 
receiver connected to the hardware UART and 
the response receiver connected to a software 
UART, the problem would go away!
Commands and responses are sent in 
groups. At 9600 baud, a data byte can 
be sent in just over 1 ms. The maximum 
interbyte delay can be no more than 1 ms. 
Any response to a command must be made 
within 5 ms of a command. Remember how 
the format of the MDB data is 9-bits? Well, 
this serves two purposes. First, the master 
PHOTO 1
Using RealTerm to display the SPY 
boards output of MDB traffic, you can 
see how the coin acceptor responds to 
commands from the master.
Denomination Security 
Thread
Security 
Ribbon
Bell in 
the 
Inkwell
Water- 
mark
Color Shifting 
Denomination
Raised 
Printing
Magnetic 
Ink
Micro 
Printing
Linen/Cotton 
w/red 
blue fibers
$100 X X X X X X X X X
$50 X X X X X X X X
$20 X X X X X X X X
$10 X X X X X X X X
$5 X X X X X X X
$2 X X X
$1 X X X
TABLE 1
High tech embedded technology helps to thwart counterfeiters. High value denominations include more technology that offsets the difficulty in reproductions.
circuitcellar.com 67
CO
LU
M
NS
sets the 9th bit of the first byte of every 
command as an indication of address data. 
The data in this byte is monitored by all slave 
devices to determine if it will respond to the 
command or just ignore it. As we saw last 
month, each different slave device has its 
own predefined address. For example, our 
Coin Acceptor/Changer has a base address of 
B’00001xxx’. Any address between 0x08 and 
0x0F should only be responded to by a Coin 
Acceptor/Changer slave device. Each separate 
address may have a pre-defined command 
specifically for that particular type of device. 
If a command is issued for an address with no 
pre-defined command, the slave device just 
does not respond. So, if the first byte of a 
received string of data has the 9th bit set on 
the first byte, it’s a command. Responses also 
use the 9th bit. In that case, the last byte of a 
received string will have its 9th bit set.
For the most part, all commands and 
responses will have a checksum added as the 
last character of the command string. This is 
simply the least significant bit (LSB) of all the 
proceeding bytes. There are three instances 
of no checksum: ACK, NAK and RET. The ACK 
response indicates the data is accepted. The 
NAK response indicates a timeout. The RET 
response is a request to resend the last data. 
Note that while none of these responses have 
checksums added, responses by the slave 
must have the 9th bit set because it is the 
last, and only, character!
So, as a slave device we can determine 
when a command ends by looking for a 
5 ms timer overflow after each command 
character received. Once received, the slave 
must determine if the command is using one 
of the slave’s addresses and if so, what to do 
next. For a spy device, we can potentially see 
a response within 1 ms. However, now that 
we can differentiate the response—because it 
comes into a separate software UART—it can 
now be displayed appropriately.
UNIVERSAL MDB RECEIVER
While the carrier board configured with 
modules can only be used for a specific 
configuration—master, slave or spy—the 
MCU’s application can support any of the 
Modes. Setting the jumpers is used to 
configure the Mode. In Mode 0 we’re emulating 
a master, while anything received from the 
MDB will be a response from a slave. When in 
Mode 1, we’re emulating a slave and anything 
received from the MDB will be a command 
from the master. Finally, when the Mode is 2, 
FIGURE 1
Here we see the $5 dollar bill with 
the visible security measures labeled. 
Validation looks for a combination of 
these and other measures to identify 
‘‘real‘’ currency.
PHOTO 2
Here I’ve exposed the main circuitry from two different bill validators. Optical sensors are used to measure 
physical parameters as well as spectrum components. These, along with magnetic signatures, help to 
assemble a digital representation of each bill. Validation occurs when this corelates to the prestored data 
for each denomination.
CIRCUIT CELLAR • FEBRUARY 2018 #33168
CO
LU
M
NS
we’re spying on both the master’s commands 
and any slave’s responses. Hardware UART2 
receives commands and software UART3 
receives responses.
As the coin acceptor slave device, once a 
command string has been received with an 
address byte between 0x08 and 0x0F—and 
the checksum verified—the command can be 
processed. This slave will respond to all legal 
commands, however only three are pertinent. 
The Reset command 0x08 will reset the slave 
device. The Setup command 0x09 response 
will indicate the coins that can be accepted. 
The Poll command 0x0B response will indicate 
when a coin has been accepted. The Coin 
Type command 0x0C can enable and disable 
the coin acceptor. The coin acceptor interface 
includes UART1RX to receive the monetary 
value of each coin accepted, 12 VDC power 
regulated from the MDB interface and an 
enable pin driven from one of the MCU’s I/Os.
As a spy device, command and responses 
are sent at 115200 baud via UART1RX. The 
data is formatted as ASCII text. The address 
range of every command is used to determine 
the destination of the data and is formatted as 
“Command to Coin Acceptor: 0x08 0x08”—in 
this case Reset with a checksum of 0x08. The 
data after the colon is the command string as 
received. Any response from a slave will be 
formatted as “Response from Coin Acceptor: 
0x00”—in this case ACK. Photo 1 shows the 
command/responses format the spy device 
displays for the ‘Coin Acceptor’ device.
Like any good system, a power up sequence 
will initialize everything into a known state. 
The master must make contact with each 
of its peripherals to insure communication 
and to reset each into a known state. Once 
all is marching in step, the master must 
continuously poll each peripheral to find out 
what’s going on. This input status enables it 
to make decisions and request output when 
necessary.
The master uses addressed commands to 
communicate with each peripheral. The MDB/
ICP suggests an initialization sequence, or 
list of specific commands for each individual 
peripheral. Each command is a string of one 
or more characters. When the carrier board is 
configured for Mode 0, a master, it can send 
any string of characters onto the MDB and wait 
for a response for the addressed peripheral. 
While we could use the MCU to handle all of 
the duties of a VMC, in this application all data 
comes from UART1RX (a PC). A peripheral’s 
response is merely redirected out the 
UART1TXafter being received from the MDB. 
In this project, the master is simply an 8-bit 
to 9-bit translator. I’ll use a PC application 
to form the commands and display a slave’s 
response.
PHOTO 3
The bill validator communication, displayed by the SPY device, is similar to that of the coin acceptor output 
in shown in Photo 1.
VMC 
Command
Address VMC Data Response 
Data
VMC ACK
RESET 0x30 - ACK -
SETUP 0x31 - 27 bytes ACK
SECURITY 0x32 2 bytes ACK -
POLL 0x33 - 16 bytes ACK
BILL ENABLE 0x34 4 byte ACK
ESCROW 0x35 1 byte ACK
STACKER 0x36 - 2 bytes ACK
EXPANSION 0x37 0x00 29 bytes ACK
TABLE 2
The command/response formats for most devices are similar—either a command with data and an ACK 
returned by the slave, or a command/response by the slave and an ACK by the master.
circuitcellar.com 69
CO
LU
M
NS
BILL MAKEOVER
Let’s take a quick look at the present 
technologies implemented in the most 
recent US currency by the Department of the 
Treasury’s Bureau of Engraving and Printing, 
which is issued and distributed by the Federal 
Reserve. Table 1 shows a chart of the security 
precautions and on which denominations they 
are used. Specific precautions are shown 
for the $5 bill in Figure 1. Bill redesigns are 
primarily for security reasons. The $1 bill—
and the $2 bill—aren’t often counterfeited, 
therefore there are no plans to redesign those 
bills. Interestingly, a recurring provision in 
the annual Financial Services and General 
Government Appropriations Act actually 
prohibits the redesign of the $1 note!
Today’s bill validators use multiple optical 
and magnetic readings to assure authenticity. 
These sensors identify various features 
unique to each denomination. In Photo 2 
you can see the numerous and wavelength 
specific optical devices that scan any item 
inserted into the validator. These devices are 
seen on the removable module that allows 
easy cleaning and access to the bill movement 
mechanism. A magnetic head is buried on the 
main unit and not easily accessed. Optical 
sensors include reflective and transmissive 
paths. The optical spectrum covers infrared 
to ultraviolet.
Left and right alignment sensors send 
information to the microprocessor on item 
width. The center optic sensor informs the 
microprocessor that an item has been inserted 
and ready to be transported. The left and right 
optic sensors perform various optical checks 
on the bill. The magnetic sensor reports on any 
magnetic properties of the item.
Once an item is inserted, the microcontroller 
enables the movement mechanism to feed the 
item back and forth across the sensors. The 
MCU assembles a digital fingerprint of the item 
and checks its data bank for a match to any 
preloaded prints of valid currency. If no match 
is made the item is rejected. A validated bill 
is then advanced to the holding area where 
its value can be used to purchase product 
and stored or returned to the customer if the 
transaction is canceled.
Like the coin acceptor discussed earlier, 
the bill validator has its own set of commands 
that must be recognized when connected 
to the MDB. The address range for the bill 
validator is 0x30-0x37. You’ll find the validator 
commands in Table 2 to be similar to that of 
the coin acceptor. When the bill validator is 
accessed via the master device, the spy device 
shows the command/response format of the 
bill validator as displayed using RealTerm 
(Photo 3). The setup now consists of three 
boards: the master (command converter to 
PHOTO 4
The total system comprised of 
the master, SPY and slave boards 
(top to bottom) are daisy chained 
with the bill validator to complete 
the system. The coin acceptor 
attaches to the slave board. The 
MDB is monitored via SPY’s AUX 
UART output. All commands are 
sent to the master via its AUX 
UART connection.
PHOTO 5
This Liberty Basic application enables each command string to be sent to the master. Responses are 
interpreted by the application and displayed in the center text box. This gives the user complete control over 
each slave device. Once initialized, each device is polled periodically. When a device indicates it has validated 
receiving a coin or bill, the application increases that specific denomination and also displays a running total 
of all currency.
CIRCUIT CELLAR • FEBRUARY 2018 #33170
CO
LU
M
NS
MDB), the spy (displaying all traffic on the 
MDB) and the slave (interfacing with the 
coin acceptor). As shown in Photo 4, the bill 
validator daisy chains to the MDB.
So now what? Well, to really put the system 
to the test we need to write an app to exercise 
it. I used my old friend Liberty Basic to write a 
quick app to be able to send commands to the 
master via its AUX UART. The results are shown 
in Photo 5. Tabs allow the user to select Review 
(command variables such as Bill Enables), 
Initialize (reset and initialize all slave registers), 
Polling (Start/Stop) and Coin Acceptor/Bill 
Validator (send individual commands).
I set the app to keep track of any coins 
or bills fed into the two slave devices. This 
is accomplished via the periodic polling of 
these two slave devices. I initially saw the bill 
validator continue to send the same response 
as if my ACK wasn’t being heard. So, I needed 
to review the two basic timing parameters 
(not counting a RESET): interbyte timing and 
response timing.
Since my master device is serving as a 
translator between the AUX UART and the MDB 
UART, there is at least a one-character timer 
lag introduced by this device. With the added 
lag in my Liberty Basic app to search for the 
end of a reply, verify it is good and reply with 
an ACK, I was exceeding the response time! 
Hmm... The only way I could be assured the 
ACK was sent in time was to handle it in the 
master device. While this worked, it doesn’t 
make sense to put this one bit of “smarts” into 
the master device. It probably should contain 
a totally smart solution. The AUX input is 
used to instruct the master which particular 
command to send, instead of sending the 
actual command byte sequences.
I’m going to end this project before it 
really gets out of control. The basic premise 
to investigate coin and paper money has 
expanded into creating a slave interface 
device for the MDB, creating a SPY device to 
monitor MDB activity and a master device to 
send and receive commands via MDB. 
Programming the master to be completely 
autonomous—or even just “smart”—would 
take this project beyond the bore factor for 
some. If your input demands it, I’ll continue 
this project in a later article. But next month 
we’ll look at something different. 
Additional materials from the author are available at:
www.circuitcellar.com/article-materials
Reference [1] as marked in the article can be found there.
RESOURCES
Microchip Technology | www.microchip.com
cc-webshop.com
Circuit Cellar
2017 Archive
Order yours today 
http://www.circuitcellar.com/article-materials
http://www.microchip.com
http://www.cc-webshop.com
circuitcellar.com 71
PRO
D
U
CT NEW
S
PRODUCT NEWS
Multi-Service IoT Gateways are Automotive-Grade
Eurotech has expanded its range of Multi-service IoT 
Gateways with the launch of the DynaGATE 10-12 and the 
announcement of the DynaGATE 10-06 (shown). Both systems 
are carrier pre-certified, with an integrated LTE Cat 1 cellular, 
GPS, Wi-Fi, BLE, E-Mark and SAE/J1455 certifications and a 
-40 ºC to +85 ºC operating temperature.
The DynaGATE 10-12 is a low-power gateway based on 
the TI AM335X Cortex-A8 (Sitara) processor family, with 
1 GB RAM and 4 GB eMMC. It features a 6 VDC to 36 VDC 
power supply with transient protection and vehicle ignition 
sense, 2x protected RS-232/RS-485 serial ports, 2x CAN bus 
interfaces, 3x noise and surge protected USB ports and 4x 
isolated digital I/Os. The DynaGATE 10-12 is suitable for on-
board applications, with a metal enclosure, high retention 
connectors and screw-flange terminal blocks.
The DynaGATE 10-06 (shown) is an IP67, heavy-duty IoTgateway for Automotive applications. It features an internal 
battery that provides minutes of uninterrupted operation 
in case of power failure. Based on the NXP 
i.MX 6UltraLite Cortex-A7 processor, with 
512 MB RAM and 4GB eMMC, the DynaGATE 
10-06 features a 6 V to 36 V power supply 
with protections and vehicle ignition sense, 
3x protected RS-232/RS-485 serial ports, 
2x CAN bus interfaces, 1x noise and surge 
protected USB port and 2x protected digital 
I/O. All these interfaces are available through 
a rugged AMPSEAL connector.
Eurotech
www.eurotech.com
Qseven Module Sports Renesas RZ/G1M Processor
iWave has announced a System-On-Module (SOM) based on Renesas RZ/G1M 
embedded processor. RZ/G1M SOM is Qseven R2.0 compatible industrial grade CPU 
module. Called the iW-RainboW-G20M, this SOM module supports 1 GB DDR3 RAM, 
4 GB eMMC Flash and 2 MB SPI NOR Flash. Expandable memory is optional. The 
module also includes on SOM Gigabit Ethernet PHY, Micro SD slot and USB HUB.
Renesas’s RZG1M processor supports dual cortex A15 core operating at 
1.5 GHz core and includes 64-bit DDR3 interface at 800 MHz. The high-speed on-
chip integrated USB 3.0, PCIe, Gbit Ethernet and SATA peripherals 
allows easy expansion of functionality without the need for external 
components. The RZ/G1M processor supports full HD hardware 
encode and decode processing up to 1,080 at 60 frames/s, dual 
display and three channel video input ports. The built-in PowerVR 
SGX544MP2 Graphics core at 520 MHz allows the user to develop 
highly effective user interfaces.
The RZ/G1M SOM is supported Linux 3.10 LTSI with Android BSP 
support to come. To enable quick prototyping of RZG1M SOM, iWave 
systems supports RZ/G1M development kit with comprehensive 
peripheral support. This will help engineers save up to 60% of 
their new product development cycle time using the RZ-G1M MPU.
iWave Systems Technologies
www.iwavesystems.com
http://www.eurotech.com
http://www.iwavesystems.com
CIRCUIT CELLAR • FEBRUARY 2018 #33172
PR
O
D
U
CT
 N
EW
S
PRODUCT NEWS
Class I and II 500 W Configurable Medical Power Supplies
TDK has announced the XMS500 series of AC-DC power 
supplies, rated at 500 W output power, with a Class I and 
Class II (no earth ground connection) construction. The series 
conforms to curve B conducted and radiated emissions, with 
a 6-dB margin and has a low leakage current of less than 
150 µA. The high operating efficiency and mechanical design 
enables the XMS500 to operate at full load with airflow rates of 
just 1 m/s, reducing audible noise. Applications include home 
healthcare, hospital, imaging and clinical 
diagnostic systems in addition to industrial, 
test and measurement and communications 
equipment.
Designed as a configurable product, 
engineers can select from multiple standard 
options, to optimize both system performance 
and cost, without incurring development 
charges or minimum purchase quantities. 
The options include case styles (including an 
internal low speed fan), a choice of standby 
voltage, a 12 V fixed or variable speed fan 
supply, remote on/off, AC fail and single or dual 
input fuses. 12 V, 24 V, 3 6V or 48 V nominal 
outputs are offered, with other voltages upon 
request.
TDK-Lambda Americas
www.us.tdk-lambda.com
DC-DC Converter Boasts 4 A, 60 V Internal Switch
Analog Devices, acquired last year by Linear 
Technology, has announced the Power by Linear 
LT8364, a current mode, 2 MHz step-up DC/
DC converter with an internal 4 A, 60 V switch. 
It operates from an input voltage range of 
2.8 V to 60 V. The LT8364 can be configured as 
either a boost, SEPIC or an inverting converter. 
Its switching frequency can be programmed 
between 300 kHz and 2 MHz, enabling designers 
to minimize external component sizes and avoid 
critical frequency bands, such as AM radio. 
Furthermore, it offers over 90% efficiency while 
switching at 2 MHz. Burst Mode operation reduces 
quiescent current to only 9 μA while keeping 
output ripple below 15 mVp-p. The combination 
of a small 4 mm x 3 mm DFN or high voltage 
MSOP-16E package and tiny externals ensures 
a highly compact footprint while minimizing 
solution cost.
The LT8364EDE is available in a 4 mm x 3 mm 
DFN-12 package and the LT8364EMSE is available 
in a high voltage MSOP-16E (4 pins removed for 
high voltage spacing). Industrial temperature 
(–40°C to 125°C) versions (LT8364IDE and 
LT8364IMSE), and high temperature (–40°C to 
150°C) versions (LT8364HDE and LT8364HMSE) 
are also available. Pricing for the LT8364 in 
1,100s starts at $3.25.
Linear Technology
www.linear.com
http://www.us.tdk-lambda.com
http://www.linear.com
circuitcellar.com 73
PRO
D
U
CT NEW
S
PRODUCT NEWS
Skylake-Based SBC Runs on 15 Watts
Versalogic has released the Condor—a high-performance embedded computer that measures only 95 mm x 95 mm x 37 mm 
and is built around Intel’s 6th generation “Skylake” Core processor and boasts power consumption as low as 15 W. The Condor’s 
on-board TPM security chip can lock out unauthorized hardware and software access. It provides a secure “Root of Trust.” 
Additional security is provided through built-in AES (Advanced Encryption Standard) instructions.
PR_EPU-4460_HICondor is the latest addition to Versalogic’s line of EPU (Embedded Processing Unit) format computers. EPUs 
are designed around COM Express form factors, but are complete board-level computers. They provide all the future flexibility of 
separate CPU and I/O modules, and are delivered 
as complete fully assembled and tested units 
(including heat plate), ready to bolt into a system.
On-board I/O includes two Gbit Ethernet ports 
with network boot capability, two USB 3.0 ports, 
four USB 2.0 host ports and two serial ports. 
One SATA III interface supports high-capacity 
rotating or solid-state drives. Eight digital I/O 
lines, I2C and SPI are also available. Two Mini PCIe 
sockets (one with mSATA capabilities) provide 
flexible solid-state drive (SSD) options. Systems 
can be easily enhanced by leveraging the Mini 
PCIe sockets with plug-in Wi-Fi modems, GPS 
receivers, MIL-STD-1553, Ethernet, Firewire and 
other mini cards. OEM quantity pricing starts at 
$1,304 for the Core i3 model with 8 GB RAM.
Versalogic | www.versalogic.com
Radiation-Tolerant MCU Family Meets Space Requirements
A new microcontroller that combines specified 
radiation performance with low-cost development 
associated with Commercial Off-The-Shelf (COTS) 
devices is now available from Microchip Technology. 
The ATmegaS64M1 is the second 8-bit megaAVR MCU 
from Microchip that uses a development approach 
called COTS-to-radiation-tolerant. This approach takes 
a proven automotive-qualified device, the ATmega64M1 
in this case, and creates pinout compatible versions in 
both high-reliability plastic and space-grade ceramic 
packages. The devices are designed to meet radiation 
tolerances with the following targeted performances:
• Fully immune from Single-Event Latchup (SEL) up to 
62 MeV.cm²/mg
• No Single-Event Functional Interrupts (SEFI) which 
secure memory integrity
• Accumulated Total Ionizing Dose (TID) between 20 to 
50 Krad(Si)
• Single Event Upset (SEU) characterization for all 
functional blocks
The ATmega64M1 COTS device, along with its full 
development toolchain including development kits and 
code configurator, can be used to begin development of 
hardware, firmware and software. When the final system 
is ready for the prototype phase or production, the 
COTS device can be replaced with a pin-out compatible, 
radiation-tolerant version with the same functionality as 
the original device.
Microchip Technology | www.microchip.com
http://www.versalogic.com
http://www.microchip.com
CIRCUIT CELLAR • FEBRUARY 2018 #33174
PR
O
D
U
CT
 N
EW
S
PRODUCT NEWS
Stainless Steel Panel PCs Meet Food Industry Needs
Axiomtek has introduced the release of two new IP66/IP69K 
stainless steel touch panel computers: the 15″ GOT815L-511 
and 17″ GOT817L-511 (shown).These Intel Kaby Lake processor-
based stainless-steel touch panel PCs are especially designed 
for use in extreme humidity, moist, dusty or wet environments. 
The highly reliable stainless touch got817-511panel computers 
adopt a high brightness LCD display with 420 nits (GOT815L-511) 
and 350 nits (GOT817L-511) brightness to ensure visibility in 
harsh environments with varying light intensity and come with 
options for projected capacitive touch or 5-wire flat resistive 
touchscreen display. The SUS316 stainless steel case can 
prevent bacteria growth and rust brought on by prolonged 
usage in moist and wet environments. Furthermore, the flat 
panel design prevents accumulation of dust and moisture and 
also makes cleaning easier.
The 15” XGA and 17” SXGA stainless steel panel computers 
come with rich I/O interfaces with M12-type connectors 
including two RS-232/422/485 ports, four USB 2.0 ports and 
one gigabit Ethernet port. They both support one DDR4-2133 
SO-DIMM slot with up to 16GB system memory, and one 2.5″ 
SSD or 2.5″ SATA HDD for storage.
Axiomtek
www.axiomtek.com
Software Tool Aids STM32 MCU Programming
STMicroelectronics offers a new software tool, 
STM32CubeProgrammer, that provides device-programming 
and firmware upgrades for STM32 microcontrollers in a 
unified, multi-platform and user-configurable environment. 
Ready to run on Windows, Linux or MacOS operating systems, 
the STM32CubeProgrammer can program the STM32 
microcontroller’s on-chip Flash/RAM or 
external memories using various file 
formats. Further capabilities include whole-
memory or sector erase and programming 
microcontroller option bytes. Users can 
also generate encrypted files for secure 
programming (Secure Firmware Install/
Update) to authenticate production and 
protect intellectual property.
With this tool, users can program 
STM32 microcontrollers through the 
device’s SWD (Single-Wire Debug) or 
JTAG debugging ports, or the bootloader 
ports (such as UART and USB). Hence 
the STM32CubeProgrammer brings 
the individual capabilities of the ST 
Visual Programmer, DFUse Device 
Firmware Update tool, Flash Loader, 
and ST-Link utility together within the 
STM32Cube ecosystem. ST will extend 
the STM32CubeProgrammer’s capabilities by adding 
programming access via microcontroller I2C and CAN ports.
STMicroelectronics
www.st.com
http://www.axiomtek.com
http://www.st.com
circuitcellar.com 75
PRO
D
U
CT NEW
S
PRODUCT NEWS
Chipsets Provide Low Power LoRa Solution
Semtech has announced its next generation LoRa devices and 
wireless radio frequency (RF) technology (LoRa Technology) chipsets 
enabling innovative LPWAN use cases for consumers with its advanced 
technology. Addressing the need for cost-effective and reliable sensor-to-
cloud connectivity in any type of RF environment, the new features and 
capabilities will significantly improve the performance and capability of IoT 
sensor applications that demand ultra-low power, small form factor and 
long range wireless connectivity with a shortened product development 
cycle.
The next generation LoRa radios extends Semtech’s industry leading 
link budget by 20% with a 50% reduction in receiver current (4.5 mA) and 
a high power +22 dBm option. This extends battery life of LoRa-based 
sensors up to 30%, which reduces the frequency of battery replacement. 
The extended connectivity range, with the ability to reach deep indoor 
and outdoor sensor locations, will create new markets. Three new devices, 
SX1262 (+22dBm), SX1261 (+15dBm) and SX1268 (+22dBm, China frequency 
bands) are currently sampling to lead customers and partners and will be 
available in full production in late Q1 2018. Development kits for various 
regions and associated software will also be available at that time.
Semtech | www.semtech.com/iot
Bluetooth 5-Compliant ICs Boast -105 dBm Sensitivity
Toshiba Electronic Devices & Storage has added two new 
devices to its lineup of ICs that are compliant with the Bluetooth 
low energy standard. The new TC35680FSG (featuring 
built-in flash memory) and TC35681FSG are well-suited to 
applications requiring long-range communication, including 
beacon tags, IoT devices and industrial equipment. The new 
communication ICs support the full spectrum of data rates 
required for the high-speed features—2M PHY and Coded PHY 
(500 kbps and 125 kbps)—found in the Bluetooth 5.0 standard. 
The new devices also deliver an industry-leading receiver 
sensitivity level of -105 dBm (at 125 kbps) and a built-in high 
efficiency power amplifier in the 
transmission block that provides 
up to +8 dBm transmission power.
Based on an ARM Cortex-M0 
processor, the new ICs incorporate 
a 256 KB Mask ROM to support 
the Bluetooth baseband process, 
and 144 KB of RAM for processing 
Bluetooth baseband, stack and 
data. Toshiba’s TC35680FSG and 
TC35681FSG also feature 18-port 
GPIOs as interfaces, which can be 
set to 2 channels each for SPIs, 
I2C, and UART.
The TC35680FSG includes 128 
KB of flash memory for storing 
user programs and various data 
in stand-alone operations, making 
it well-suited to a wide range of 
applications and removing the 
need for external non-volatile memory. This also lowers 
the part count, which reduces both the cost and mounting 
area. The TC35681FSG, which does not include a built-in 
flash memory, operates in conjunction with an external non-
volatile memory or host processor. A wide operating range of 
-40° to +125°C makes it suitable for applications exposed to 
high temperatures.
Toshiba Electronic Devices & Storage
www.toshiba.semicon-storage.com
http://www.semtech.com/iot
http://www.toshiba.semicon-storage.com
Circuit Cellar is always adding new items to 
help with your design projects. Stop by often 
for the latest deals.
Have you 
stopped by 
the shop lately? 
back issues
books
audio
 
co
nt
es
t C
D
s
ar
ch
ive
 C
Ds
www.cc-webshop.com
http://www.cc-webshop.com
circuitcellar.com 77
sales@ccsinfo.com
262-522-6500 x 35
Includes: CCS C Compiler& more!
lear
n 
embe
dded
 c 
on a 
pic® mc
u!
Explore SENSORS
Learn C with hands-on tools that 
inspire real world applications.
PIC® MCU is a registered trademark of Microchip Technology, Inc.
www.ccsinfo.com/cc218
SENSORS 
EXPLORER KIT
TS-7250-V2
Single Board Computer
1GHz ARM Computer with
Customizable FPGA-Driven 
PC/104 Connector 
and Several Interfaces 
at Industrial Temp
www.embeddedARM.com
IDEA BOX
The Directory of
PRODUCTS & SERVICES
AD FORMAT:
Advertisers must furnish digital files that meet our specifications (circuitcellar.com/mediakit).
All text and other elements MUST fit within a 2” x 3” format. 
E-mail adcopy@circuitcellar.com with your file.
 
For current rates, deadlines, and more information contact 
Hugh Heinsohn at 757-525-3677 or Hugh@circuitcellar.com.
CC Vault
Unlock the power of
embedded design.
This pocket-sized vault comes fully loaded 
with every issue of Circuit Cellar magazine 
and serves as an unparalleled resource for 
embedded hardware and software design 
tips, schematics, and source code.
 *CC Vault is a 16-GB USB drive.
mailto:sales@ccsinfo.com
https://goo.gl/w1pDkR
https://goo.gl/eNLdNF
mailto:adcopy@circuitcellar.com
mailto:Hugh@circuitcellar.com
http://www.cc-webshop.com
https://goo.gl/VeJvYs
http://www.cc-webshop.com
CIRCUIT CELLAR • FEBRUARY 2018 #33178
TE
ST
S 
YO
U
R 
EQ
TEST YOUR EQ 
Contributed by David Tweed 
Answer 1—In a DLL, the input signal is fed both to the phase 
comparator and to the input of the delay line. The output of 
the delay line feeds the second input of the phase comparator, 
and the output of the phase comparator is filtered and used 
to control the delay line. The end result is that the delay is 
adjusted until it equals the period of the input signal, causing 
the delayed edges of coming from the delay line to line up with 
the undelayed edges.
Note that this requires the type of phase detector whose 
average output is zerowhen there is zero phase error between 
its inputs—not a simple XOR gate, for example.
Answer 2—The control voltage of the delay line tracks the 
average period of the input signal, within the bandwidth of the 
loop filter.
If the loop bandwidth is greater than the data rate, the control 
voltage directly tracks the frequency changes associated with 
the individual bits. This signal can be amplified and compared 
with a threshold in order to recover the original data.
On the other hand, if the loop bandwidth is significantly less 
than the data rate, the DLL tracks only the average frequency of 
a large number of bits. This means that at any given moment, 
the incoming signal will either be at a higher frequency 
(shorter period) or a lower frequency (longer period) than the 
For more information: 
circuitcellar.com/category/test-your-eq/
period established by the delay line. A simple D flip-flop 
can be used to discriminate between these two cases, 
providing a direct digital copy of the original baseband 
signal.
Answer 3—Since the digital baseband signal can be 
recovered directly using a DFF, the need for analog 
circuitry to amplify and “slice” the delay line control 
voltage is eliminated. This makes the technique much 
more amenable to implementation in a standard CMOS 
process for minimum power consumption and maximum 
compatibility with digital CMOS fabrication processes.
Answer 4—In order to keep the average frequency 
being tracked by the DLL as close to the center as 
possible, the baseband data should have an equal mix of 
ones and zeros. Furthermore, there must be a limit on 
the number of contiguous ones or zeros in a row.
There are a number of ways to accomplish these goals. 
One way is to use 8-bit/10-bit encoding on the data, 
which was originally developed to support various kinds 
of digital audio recording. With this encoding scheme, 
there are at most five ones or zeros in a row. Also, the 
running “disparity” between ones and zeros is tracked, 
and alternate codes are used where possible to keep the 
overall mix balanced.
http://www.circuitcellar.com/category/test-your-eq/
http://www.circuitcellar.com/
circuitcellar.com 79
TECH THE FUTURE
Gearing up for a 
Post-3G, Sensors 
Everywhere Era
By 
Brent Ward
VP Business Development, 
Device Solutions
The Future of Industrial IoT
T oday the Industrial Internet-of-Things (IIoT) is leveraging a variety of technology trends that are moving ubiquitous 
monitoring closer to reality. These trends 
include more efficient and more cost-effective cellular 
networks, smaller embedded wireless sensing 
devices with lower power consumption, improved 
communication protocols covering greater distances 
and maturing back-end analytic and operational 
integration.
Many of the changes to the way IIoT is implemented 
across numerous monitoring applications have been 
driven by carriers migrating their equipment to 
support 4G from 3G. This shift will drive greater 
efficiency in the network while also allowing for 
faster speeds, an increased number of users and 
an increased capacity for bandwidth. Of these, 
the increasing number of users/connections is of 
particular interest. That’s because most IIoT future 
predictions see everything of interest monitored with 
sensors and transmitting the data continuously.
Carriers like Verizon have notified their users that 
no new 3G devices will be allowed to be activated on the 
network after mid 2018 and that 3G network support 
will be sunset at the end of 2019. That means that 
most, if not all, new cellular devices require 4G. If you 
consider the number of 2G/3G devices that are already 
in the field and the time/effort that may be involved to 
test, validate, and then swap out equipment—there is 
very little time to make the switch.
SHRINKING WIRELESS DEVICES
Embedded wireless devices are aggressively 
competing for pole position on parameters including: 
decreasing size, increasing capability, decreasing 
hardware price, reducing power consumption, 
increasing data security, increasing transmission 
distances and decreasing communication costs—just 
to name a few.
At the most basic level, a single sensor device with 
power supply and communication link all need to fit 
inside the application’s physical constraints—and at 
the lowest cost possible with the highest security 
possible. Cell phones, smart watches and other 
80 CIRCUIT CELLAR • FEBRUARY 2018 #331
TE
CH
 T
HE
 F
UT
UR
E
Brent T. Ward is responsible for business and strategy development, marketing and sales activities. He has had experience working in multiple spin-offs 
and start-up’s out of RTI, RTP, and Silicon Valley. Brent holds a bachelor’s degree in electrical engineering and psychology, a master’s degree in electrical 
engineering from Duke University and an MBA from Fredericton University.
embedded wireless devices have continued to 
drive miniaturization and increased computing 
capabilities into very small form factors. Add 
to the mix the desire for quicker installations, 
elimination of wires, lower cost deployments, 
quicker realization of value and expectations 
to keep up with changing standards and the 
shift to 4G/5G seems like the perfect storm.
To further the efficiency and looking 
longer term, many embedded wireless 
sensing devices may do some amount of 
data analytics in the field—thereby providing 
business opportunities for managing the flow 
and format of the data more efficiently.
To realize the dream of sensors monitoring 
equipment wherever there is a chance to 
improve outcomes and efficiency, not only 
do the sensor devices require a low capital 
cost, but also a low operating cost. To achieve 
both of these objectives simultaneously, the 
ideal technology would be able to transmit 
great distances on low power locally while 
also requiring an order of magnitude (or two 
or three) less back-haul infrastructure—and 
ideally in an open spectrum.
For many companies looking to the future, 
Long Range low power technology (LoRa) is the 
platform of choice upon which they are basing 
their embedded designs. With the advent of 
LoRaWAN there is increased interoperability, 
improved security options and an emerging 
public network to support untold numbers 
of embedded wireless sensing devices at 
extremely low prices. If predictions are to be 
believed, systems will emerge that require 
only $1 of capital expense per device that is 
connected via LoRaWAN for just pennies a 
month.
ALL ABOUT ACTIONABLE
Data analysts love with the idea of 
generating more data, cellular providers 
love the idea of supporting more data from 
more devices and embedded sensing device 
manufacturers love the idea of selling more 
devices that generate more data. However, 
corporate customers are wary about collecting 
more data on their operations just for the 
privilege of having more data. In addition to 
the capital expenses for infrastructure and 
devices, there are the operating expenses for 
connectivity, data hosting/analytics and for 
ongoing maintenance.
Most organizations seem keenly aware 
that more data is likely going to result in 
more data-related jobs required in their 
organizations to make sense of the data—
possibly a large and ongoing expense. 
Ultimately, the corporate business owners are 
most interested in ecosystems that leverage 
the data for the purposes of driving action. 
That means action towards their goals and 
objectives: increased efficiency, better 
utilization, higher throughput, increasing 
safety, improved forecasting, reducing risks, 
optimized logistics, predictive maintenance 
and many other ways to drive value to their 
stakeholders and partners. But, data without 
action is, well…just data.
The convergence of low cost sensors, low 
cost embedded wireless devices and low-
cost communications is the perfect trifecta 
to driving sensors (across an enterprise) 
into every nook and cranny of operations 
and equipment to identify opportunities for 
improvements.Initially, many business cases 
may be based on optimistic expectations 
of results that will deliver a return in a 
reasonable period of time. Soon however, the 
devices and connections will be so ubiquitous 
and easy to deploy that business owners may 
speculatively place sensors in places they are 
unsure if they will derive value—but use the 
data for modeling and evaluating alternatives.
Should the creative, innovative and 
possibly lucky placement of sensors in novel 
locations prove to be valuable it will naturally 
beg the question: “Where haven’t we put 
sensors that could give us even more insight?” 
This is only half the story—the other half is 
automatically using the data to control 
equipment and processes throughout the 
operation and supply chain. We’ll save that for 
another article. 
Materials:
Fr4
Metal Core
Isola
Rogers
Polyimide - Flex
MagtronMagtron
Technology:
Up to 50 Layers
Any Layer HDI
Sequential Lamination
Blind / Buried Vias
Laser Drilling / Routing
Heavy CopperHeavy Copper
Whether you are an
EMS, CM or OEM,
let our bare boards be the foundation
you build your reputation upon!
We will make only what is needed,
when it’s needed,
and in the amount needed.
You no longer have to worry about long shelf life
or tie your capital in bare board inventory.
www.PCB4u.com sales@PCB4u.com
https://goo.gl/L91GbU
mailto:sales@PCB4u.com
OP
EN
RU
GG
ED
LO
NG
 LI
FE
OR
IG
IN
AL
TS-TPC-7990
Touch Panel PC
7” High End i.MX6 Mountable
Panel PC with Dev Tools Such 
as Debian GNU and QTCreator 
$299
Starting at
Qty 100
Starting at
TS-4900
$89
Computer on Module
Industrial High Performance
i.MX6 Module with Wireless 
Connectivity and Flash Storage
Starting at
Qty 100
TS-7680
Qty 100
Single Board Computer
Low Power Industrial 
Single Board Computer with 
WiFi and Bluetooth
$159
@ts_embedded
AUTOMATED
SMART
INDUSTRIAL
PRODUCTIVE
MESHED
LOW POWER
INTELLIGENT
CUSTOMIZED
LINKED
PERCEPTIVE
CONNECTED
SCRIPTED
HELPFUL
RUGGED
RELIABLE
WEARABLE
LIFE SAVING
BENEFICIAL
THINGSINTERNET OF 
TS-7553-V2
Single Board Computer
Technologic Systems introduces the TS-7553-V2, a single board computer 
that is a low power, cost effective, Internet-of-Things (IoT) capable, and 
ready-to-deploy OEM board with an emphasis on data integrity. 
With the TS-7553-V2 connect to Ethernet, WiFi, Bluetooth, USB, RS-232,
RS-485, and CAN networks or devices. Built in module interfaces like the 
XBee/NimbeLink socket and internal USB ports allow expansion to other 
networks like Cellular, DigiMesh, ZigBee, Lora, and other proprietary or 
industry specific networks. This ability to communicate over a wide variety
of wired and wireless interfaces puts the TS-7553-V2 in an excellent
position to be an industria IoT gateway.
For specifications go to www.embeddedARM.com/TS-7553-V2
Board Support Packages,
Source Code and Toolchains Available
https://goo.gl/67RXUV