TINY EMBEDDED BOARDS

OCTOBER 2023
circuitcellar.com ISSUE 399

circuit cellar Inspiring the Evolution of Embedded Design

TINY

I MEMS Sensors I Backend Web Development |

zram in Embedded Linux | Evaluating EDATEC's Industrial Modules |

Build a Solar-Powered Bobblehead I What to Do When Tech Goes Wrong |

Searching for "Fists" in Embedded Systems |

Using the Sun's Energy— Modbus Client The Future of EV Efficiency

 circuit cellar < ■ circuit cellor ■ » circuit cellor circuit cellar
EMBEDDED PCs SUIT UP FOR EMBEDDED SOLUTIONS LIFT UP EMBEDDED SYSTEMS ENABLE DRONE DEVELOPMENT KITS
SMART TRANSPORTATION SMART CITIES CONDITION MONITORING EMPOWER HANDS ON DESIGNS
 Get the complete Circuit Cellar issue archive and article code stored on a
stylish, durable and portable USB flash drive. You can easily keep your CC
Vault archive up to date by purchasing subsequent issues from our webshop
or by downloading issues with a Circuit Cellar Digital Subscription. Issues
appear in searchable PDF format.
cc-webshop.com
circuit cellar >circuit cellar i circuit cellar circuit cellar
ADVANCES IN THE
MODERN RAILWAY SYSTEM
G
HYBRID AND ELECTRIC
VEHICLE SOLUTIONS
e PCB INNOVATIONS
in
WEARABLE DEVICES

nun linn ■m
2 CIRCUIT CELLAR * OCTOBER 2023 0 9 9
V o lta g e
Systems That Save Lives
y mother-in-law was diagnosed with young-onset Parkinson's disease
almost 20 years ago, roughly a decade before I met her. A silver lining
to young-onset Parkinson's is that the disease has a significantly
slower progression than its more commonly diagnosed counterpart.
And indeed, in the time that I've known her, any changes have happened so slowly
as to be almost imperceptible. Still, it did progress, until she made the decision
recently to undergo deep brain stimulation (DBS).
DBS is a surgical procedure that places a device called a neurostimulator in the
patient, which sends electrical impulses through implanted electrodes to targeted
regions ofthe brain. In successful cases, motor fluctuations and tremors are reduced.
Remarkably, the underlying principles of DBS are still not completely understood—
there are at least four competing hypotheses that attempt to explain how, exactly,
the electrical signals manage to restore some control of motor functions to DBS
patients. And here I should issue a disclaimer of sorts: DBS is a newer procedure
with a few associated risks, including potential changes in the personalities of
patients, not to mention the usual risks associated with brain surgery. As such, it ’s
still something of a controversial option for people with PD, and, obviously, everyone
should consult with their doctor, and then maybe several other doctors, before
making such a weighty decision for themselves or their loved ones.
The wonderful news, in our family's case, is that the DBS has appeared to work
beautifully for my mother-in-law. She is experiencing significantly fewer tremors,
which means that now she can sleep through the night for the first time in years, so
that her overall mood, focus, and energy are almost back to what they once were.
I know we are deeply fortunate to have access to this treatment at all, let alone for
it to work without a hitch.
We're visiting my wife's parents as I write this, and on our first night here, my
mother-in-law had to charge her neurostimulator. She did this via a charging pack
that hung around her neck and over her chest, where the device was placed. My
wife lovingly teased her mom that she's a robot now. You probably know where this
is going. My Circuit Cellar editor brain lit up when I saw that glowing pack around
her neck. While a tremendous amount of credit must go to the numerous doctors
and medical researchers who developed the DBS procedure, I realized some unsung
heroes here—and of countless other modern medical procedures—are the embedded
systems engineers who designed, built, and programmed the devices involved.
The neurostimulator, also referred to as the implantable pulse generator (IPG),
consists of a battery and power module, CPU and program memory, and a
microprocessor (MPU) to manage device activation/deactivation, pulsing parameters,
internal diagnostics, and communication with external devices [1]. How precise, how
carefully tested this embedded system must be! I can only imagine the years of
experience and depths of expertise needed to take on such a challenge as a design
like this one, where lives hang in the balance. It's brought me to reflect more broadly
on how so much of our modern lives depend—critically—on the tiniest devices, no
less sophisticated for their size. And so I applaud you, readers, for your passion and
dedication to this underappreciated, crucial discipline. Thank you for keeping our
world spinning. And thank you for reading
1| S a r it a , Can e t a l. " I m p la n ta b le Pulse G e n e ra to rs f o r Deep
B ra in S t im u la tio n ; C ha lle n ge s, C o m p u ta tio n s , a nd S tra te g ie s fo r
P r a c tic a lity a n d L o n g e v ity /’' F ro n tie rs in H u m a n N e u ro s c ie n c e ,
V ol. 15, 2 0 2 1 , h ttp s ://d o i.o rg /1 0 .3 3 B 9 /F n h u m .2 D 2 1 .7 0 B 4 B l.
swallace@circuitcellar.com
Is s u e 3 9 9 O ctober 2 0 2 3 J ISSN 1 5 2 8 -0 6 0 8
CIRCUIT CELLAR® (ISSN J52S D&DS1 is published m on th ly by:
KCK Media Corp.
PO Box 417, Chase City, VA 23924
Periodical rates paid a t Chase City, VA, and additional offices.
One-yea r { 12 issues) subscription ra te US and possessions
$50, Canada $65, Foreign/ ROW $75. All su b scrip tio n o rd e rs
payable in US funds only via Visa, M asterCard, international
postal money order, or check d ra w n on US bank.
SUBSCRIPTION MANAGEMENT
Online Acco u nt Man age men t: c i rcu i Lee Ila r .cem/acoc- ui i L
Renew | Change A ddress/E -m ail ] Check S tatus
CUSTOMER SERVICE
E- m aiI: c ust o me rse r v i i.e Lqjci r c u i tee Ila i .co m
Phone: 434.533.0246
Mail: C ircuit Cellar, PO Box 417, Chase <Jty, VA 23924
Postm aster: Send address changes to
C irc u it Cellar, PD Box 417, Chase City, VA 23924
NEW SUBSCRIPTIONS
ci rc u itcella r. co m f t ubscr i ptio n
ADVERTISING
Contact: Hugh Heinsohn
Phone: 757-525^3677
Fax: B3B-9BD 13D3
E- mai I: h hei nsoh n@ci rc u itcella r.com
A dvertising rates and te rm s available on request.
NEW PRODUCTS
E■mail: p roduebed ito r ^ c i rc uitce Ila r.com
HEAD OFFICE
KCK Media Corp.
PO B o x 417
Chase City, VA 23924
Phone: 434-533-0246
COPYRIGHT NOTICE
E n tire c o n te n ts c o p y rig h t © 2 0 2 3 by KCK Media C orp.
A ll rig h ts re se rve d . C irc u it C e lla r is a re g is te re d tra d e m a rk
o f KCK Media C orp. R e p ro d u ctio n o f th is p u b lic a tio n in
w h o le or in p a r t w ith o u t w r it t e n co n se n t fro m
KCK Media C orp, is p ro h ib ite d .
DISCLAIMER
KCK Media Corp, makes no w a rra n tie s and assum es no
responsibility o r liability o f any kind fo r e rro rs in these
p rogram s o r schem atics o r fo r th e consequences o f any such
e rro rs p rin ted in C irc u it C e lla r® . F urth erm ore, because of
possible v a ria tio n in th e q ua lity and co n d itio n o f m ate ria ls and
w orkm anship o f reader-assem bled projects, KCK Media C o rp ,
disclaim s any responsibility for th e safe and p ro pe r fu n c tio n
o f reader-assem bled projects based upon o r from plans,
d escriptio ns, o r in fo rm a tio n published in C irc u it C ellar® .
The in fo rm a tio n provided in C ircuit C e lla r® by KCK M edia
Corp, is fo r educational purposes. KCK M edia C o rp , makes
no claim s o r w a rra n ts that readers have a rig h t to build
things based upon these ideas under patent o r o th e r
relevant intellectual p ro p e rty law in their ju ris d ic tio n , o r
th a t readers have a rig h t to co n stru ct o r o pe ra te any o f
th e devices described herein under th e relevant patent or
o th e r intellectual p ro p e rty law o f th e reader's ju ris d ic tio n .
The rea de r assum es any risk o f in frin g e m e n t lia b ility for
c o n s tru c tin g o r o pe ra tin g such devices.
© KCK M edia Corp. 2023 Printed in the United States
 circuitcellar.com 3

OUR NETWORK

I' circuit cellar

Backend Web Development for MCU Clients
LinuxGizmos^
Part 1: Handling HTTP Requests in PHP
By Raul Alvarez-Torrico

zram in Embedded Linux

I ^^LOUDSPEAKER
How to Maximize RAM in a Linux Environment
W JSO U R CEB O O K
By Pedro Bertoleti
SUPPORTING COMPANIES
Evaluating EDATEC's Line of Industrial Modules
Analog Devices 15
Based On the Raspberry Pi Compute Module 4
Avnet 45 By Brian Millier
CCS, Inc. 61
Build a Solar-Powered Bobblehead
EmbeddedTS 61, C4 Using an Electromagnet to Drive the Bobble
Microchip 21 By Dev Gualtieri

Renesas 49
TECHNOLOGY FEATURE
STMicroelectronics 55
Tiny Embedded Boards By Michael Lynes
TDK C3
DATASHEET
NOT A SUPPORTING MEMS Sensors
COMPANY YET? They Sense Just About Everything
Contact Hugh Heinsohn
By Sam Wallace
hugh@circuitcellar.com,
Phone: 757-525-3677,
Fax: 888-980-1303 Start to Finish
to reserve space in the When Technology Goes Wrong
next issue of Circuit Cellar.
How Bad I t Can Get, and What You Can Do About It
THE TEAM By Stuart Ball

FOUNDER Steve Ciarcia

Embedded in Thin Slices
PUBLISHER KC P rescott How Thin-Slicing Can Help Us
CONTROLLER Chuck Fellows
The Search fo r "F ists" in Embedded Systems
EDITOR-IN-CHIEF Sam W allace
SENIOR ASSOCIATE EDITOR By Bob Japenga
Shannon Becker
From the Bench
TECHNICAL COPY EDITOR
Carol Bower Local Isolation: Using the Sun's Energy
CONTRIBUTING EDITOR Part 2: Modbus Client
Brian M illie r
PROJECT EDITORS Ken Davidson By Jeff Bachiochi
David Tweed
MARKETING MANAGER Tori Zienka TECH THE FUTURE

ADVERTISING SALES REP.

The Future of EV Efficiency
Hugh Heinsohn Gate-Drive Strength in EVs
ADVERTISING COORDINATOR
H eather C hildrey Why Real-Time Variable Gate-Drive Strength Enables
COLUMNISTS SiC Traction Inverte r Efficiency Im provem ents
Jeff Bachiochi (From the Bench) By George Lakkas
Stuart Ball (Start to Finish)
Joseph Corleto (The Magic Smoke Factory) 60 : TEST YOUR EQ
58 : Product News
Bob Japenga (Embedded in Thin Slices)
Brian Millier (Picking Up Mixed Signals) @editor_cc
Colin O'Flynn (Embedded Systems Essentials) @circuitcellar circuitcellar
(S) circuit_cellar
4 CIRCUIT CELLAR • OCTOBER 2023 #399
for MCU Clients
S
E
R
U
T
A
E
F
Raul Alvarez-Torrico
Sometimes edge devices must interact with servers that
understand only HTTP and HTTPS, even though MQTT protocol is
often preferred for sending loT data to a server. Thus, proficiency
with servers, HTTP, and backend technologies is a valuable skill
for the embedded systems professional. In this new article series,
I will cover backend web development for embedded clients such
as microcontrollers and edge processors for loT applications.
n this three-part article series, I discuss
backend web development for embedded
clients, such as microcontrollers (MCUs)
and other edge processors for Internet-of-
Things (loT) applications. I describe how to set up
a web server with a database to develop backend
applications for receiving sensor data from remote
devices via Hyper Text Transport Protocol (HTTP)
requests. The received data are parsed, processed,
and stored in a database using the PHP scripting
language.
Sensor data are sent from the MCU client as
a string of Comma Separated Values (CSVs). The
JavaScript Object Notation (JSON) data-interchange
format can be used as well. The receiving PHP script
running on the server processes the data and stores
them in a database. Another PHP script is used to
query the database and extract data matching a
certain criterion, such as a given period of time. The
script prepares the available results as a JSON or
Extensible Markup Language (XML) file, and sends it
back to the HTTP client that made the request—for
instance, a web browser that requested the data to
visualize them graphically in a web page.
Although there are cases in which Message
Queuing Telemetry Transport (MQTT) protocol
would be a better option to send loT data to a web
server, sometimes edge devices need to interact
with servers that understand only HTTP and secure
HTTP (HTTPS). However, web clients such as web
browsers generally access server data using HTTP/
HTTPS almost exclusively. With that in mind, knowing
about servers, HTTP and backend technologies
RHP
can be helpful for an embedded developer, for
prototyping web applications that store and retrieve
loT data from a web server using databases, and for
other applications.
To be able to follow the topics discussed in this
article series, you will need to have some experience
with the Arduino platform. It is also desirable to
have some experience setting up server software
(Apache, PHP, MariaDB, PhpMyAdmin) on a single­
board computer (SBC), such as the Raspberry Pi
board, or any conventional personal computer. I will
not be covering in great depth how to do the latter,
but I will describe the main steps in reasonable
detail. Nevertheless, it's a simple procedure and
there are also countless tutorials on the Web
covering the topic. It is also possible to just use a
typical shared web hosting service to avoid setting
up your own server.
The code referenced throughout this article is
available on the Circuit Cellar Article Materials and
Resources webpage.
FULL-STACK WEB DEVELOPMENT
Let's begin by explaining "full stack web
development," to establish a clear conceptual
base for all that will be discussed in this article.
"Full stack" refers to the development of both the
"frontend" (client side) and "backend" (server side)
portions of a web application [1]. Full-stack web
developers can design and implement complete
web applications or websites, because they have
the knowledge to work on both the frontend and
the backend. They also know how to use databases

and perform all necessary debugging tasks
typical of web applications and websites.
Figure 1 illustrates the concept of full­
stack web development and how it is divided
into its two components: the frontend and
the backend. Let's explain in more detail
what is the frontend or the client side of the
application, and what is the backend, known
also as the server side of the application.
The frontend is the visible part of the
web application or website, and is typically
in charge of user interaction. It is built
using frontend languages, such as Hyper
Text Markup Language (HTML), Cascading
Style Sheets (CSS), and the JavaScript
scripting language. HTML and CSS are not
strictly programming languages; rather,
they are markup and stylesheet languages,
respectively. Additionally, there are some
frontend frameworks and libraries, such as:
AngularJS, ReactJS, VueJS, Bootstrap, jQuery
and SASS, among others. Data exchange
formats such as JSON and XML, along with
query languages such as GraphQL are used
by web clients to request data from servers.
The backend is the non-visible, server­
side part of the web application or website,
and it defines how the website works for the
most part. It is also responsible for managing
the database, and interacts with it on behalf
of web clients. To this end, it provides
Application Programming Interfaces (APIs)
to the client side. Backends are typically built
using languages such as PHP, Ruby, C++,
Java, Python, JavaScript/NodeJS, and others.
Some frameworks, including Express, Django,
Rails, Laravel, and Spring, also are available.
Databases are also part of almost any backend.
Popular database technologies used are Oracle,
MongoDB and MySQL/MariaDB, among others.
There are also some popular technology
stacks used for backend development. They
include MEAN (MongoDB, Express, AngularJS,
and Node.js), MERN (MongoDB, Express,
ReactJS, and Node.js), Django (Django,
Python, and MySQL), Ruby on Rails (Ruby,
PHP, and MySQL) and LAMP (Linux, Apache,
MySQL, and PHP).
In this article series we will use LAMP,
because it is arguably the most popular and
is commonly found. For instance, most of the
shared hosting servers offer LAMP installed by
default, so you don't need to install anything
else to begin developing web applications.
BACKEND WORKFLOW
Let's describe a typical backend workflow
for a simple loT web application. Figure 2 is a
conceptual diagram of this type of workflow.
For the purpose of this article, the web
client will be primarily any edge device. For
the concrete application example we will
circuitcellar.com
Front End Back End
HTML/CSS PHP/ Java/ Python MySQL/MongoDB
JavaScript Ruby/C++/Java Script Oracle
f i g ur e 1
discuss here, the web client will be an MCU Full-stack web development.
that gathers sensor data and sends them
periodically to the web/application server. The
server receives these data and stores them in
a database. Data are sent by the client (the
MCU) via periodic HTTP POST request to the
server. To retrieve data from the database,
any client (for example a web browser or the
MCU, itself) can send HTTP GET requests to the
server as well. Both types of requests (POST
and GET) are part of the REpresentational
State Transfer (REST) architectural style, on
top of which most Internet websites are built.
The data are transferred from the client
to the server using data interchange formats
such as CSV, JSON or XML. In general, CVS
and JSON are the most efficient in terms
of memory space, because they use less
metadata for data representation. However,
to retrieve data from the application server,
JSON and XML are typically used, especially by
more conventional web clients, such as web
browsers. For MCU clients requesting data
from the application server, JSON is more
efficient in comparison with XML, in terms
of memory. CSV can also be used, which is
even more efficient; but at the same time, it
has its drawbacks—being less clearly defined,
not hierarchical and not easily scalable in
comparison to JSON and XML. Nevertheless,
CSV can be convenient for small datasets.
Front End Back End
MySQL/
PHP MariaDB
Client Web/Application Database
Server
FIGURE 2
Backend workflow for an loT web application.
CIRCUIT CELLAR • OCTOBER 2023 #399

WEB AND APPLICATION SERVER Radxa RockPro64, Nano Pi R4S, and others.
To build your first HTTP loT web application, Moreover, any regular Linux computer or
there are two easy options for setting up an laptop can also be used. A computer with the
application server. The first one is to use an Windows operating system can be used after
SBC, such as the Raspberry Pi board, as a installing WAMP (Windows, Apache, MySQL
server, and to install on it the LAMP stack. and PHP) or Laragon [2].
Other SBCs can be used as well, for instance, The second option is to use a regular
boards such as the Orange Pi, Le Potato, shared hosting server. Most cheap web
Asus Tinker Board, Odroid N2+, Banana Pi, hosting options (around $10 a month) come
with the LAMP stack installed by default. The
user doesn't have to install anything else to
1 # Setting Up a LAMP Web Server On A Raspberry Pi be able to write web applications using PHP
2 and MySQL/MariaDB databases.
3 ## Step 1: Update Your Operating System In this article, we will use the first option,
4 sudo apt update and I will describe the main procedure to set
5 sudo apt upgrade up a Raspberry Pi server. I will not go into
6 great detail, but the procedure is fairly easy
7 ## Step 2: Install and Test Apache Server for someone that has reasonable experience
8 sudo apt install apache2 using a Raspberry Pi and the Linux terminal.
9
10### Find your Raspberry Pi IP address: RASPBERRY PI SERVER
11 Hostname -I Setting up a Raspberry Pi web server is
12 relatively easy. The procedure described
13### Open the IP address on your web browser. For next assumes you have already installed the
example: http://192.168.0.100 Check that the “Apache2 Raspberry Pi OS on your board. The same
Debian Default Page” is shown. steps will work equally well with other Debian­
14 based operating systems, such as Armbian
15## Step 3: Install and Test PHP and Ubuntu. Listing 1 shows the commands
16sudo apt install php 1ibapache2-mod-php to run on the Linux terminal to install the
17 LAMP stack [3].
18### Test your first PHP script. Go to the Apache web As a first step, it is a good idea to update the
folder: operating system by running the commands
19cd /var/www/html from lines 4-5. Next, install the Apache web
20 server software by running the command
21### Create a new PHP file: in line 8. After the installation finishes, you
22sudo nano test.php will be ready to test Apache. Make sure your
23 Raspberry Pi is connected to your local LAN
24### Copy this code into it: via Ethernet or Wi-Fi, and get the IP address
25<?php phpinfo(); ?> assigned to it by running the command in line
26 11. Open that IP address on a web browser
27### Open the script on your web browser. For and check that the default "Apache2 Debian
instance: http://192.168.0.100/test.php Check that the Default Page" loads on the web browser page.
default PHP Info “PHP Version x.x.x” is shown. It should look like the screenshot in Figure 3.
28 Next, run the command in line 16 to install
29## Step 4: Install and Test MariaDB PHP and the Apache plug-in that interprets
30sudo apt install mariadb-server php-mysql PHP files. After the installation, you can test
31 it with a simple PHP script. Go to the server's
32### Restart Apache: root folder (line 19), create a "test.php" file
33sudo service apache2 restart (line 22), and write in the PHP code from line
34 25. Line 22 uses the "nano" terminal-based
35### Check that MariaDB is installed properly. Start text editor to edit the aforementioned PHP
Mari aDB: file, but you can use any other terminal-based
36sudo mariadb or Graphical User Interface (GUI) text editor.
37 Next, open the PHP script on a web browser
38### List all available databases: (see line 27). If PHP is set up correctly, you
39show databases; should see a webpage similar to the one
40 shown in Figure 4.
41### Exit MariaDB: As one of the last steps, install the MariaDB
42exit database by running line 30. For practical
purposes, MySQL and MariaDB are the same
LISTING 1
database. MariaDB is an improved, open-
Raspberry Pi web server installation. source fork, backward-compatible version of
 circuitcellar.com

MySQL. MariaDB supports the same features

present in MySQL and adds various others,
as well as many security and execution
improvements. That's why "mysql" and
"mariadb" names are used interchangeably
in much available documentation, as well as
related code and Linux command examples.
After installing MariaDB, restart the
Apache web server (line 33) and test your
database installation. Start MariaDB on a
terminal window by running the command
in line 36. For the reasons explained above,
if you type "sudo mysql" instead, you will
get the same result. Once you have the
MariaDB command-line client running, run
the command in line 39 to get a listing of
all currently available databases. Any fresh
MariaDB installation comes with some pre­
installed databases for internal use. These
will be shown after running the show
databases; command. Don't forget to type
the semicolon in line 39. That line is an SQL
query, and all SQL queries for MariaDB must
be terminated with a semicolon. If you don't
get any errors after performing these steps,
it means the database is installed correctly.
Exit the command-line client by typing "exit"
to return to the Linux system prompt.
Apache? Debian Default Page
’J 11
It w o rk s!
Tb«s is ths default welcome page used to test ths correct operation of ths Apache? server after
installation on Dothan system a. If you can read this page. It means that the Apache h t t p server
installed at this site is working properly. You should replace this file (Located at
/v a r/w w ^ /h tel/in d « x .h te l) before continuing to operate your HTTP server.
If you are a normal user of this web site and don t know what this pogo Is about, this probably means
that: the site Is currently unavailab • due to maintenance. Jf the problem persists, please contact the
site s administrator.
C o n fig u ra tio n O ve rvie w
Deb ar s Apache? default configuration Is different from the upstream default configuration, and split
Into several hies optimised for interaction with Debian tools. The configuration system is fu lly
do cum ented in /u s r/s h a re /d o c /a p a c h e 2 /R E A D M E .D e b ia n .g z . Refer to this for the full
documentation. Documentation for the web server itself can be found by accessing the m anual f the
apache?-doc package was installed on this server.
The configuration layout for an Apache? web server installation on Debian systems is as follows:
/etc/cpache?/
apache?,conf
/ * - • p o rts ,conf
FIGURE 3
Default Apache web server page.

MCU-BASED WEB CLIENT

To test the web application we will be
building in this article series, we will use
an MCU-based HTTP client to send sensor
data to our server. This MCU client needs
network access to exchange data with the
server, so it must have Ethernet or Wi-Fi
connectivity. There are various options that
fulfill this requirement. A couple of those are ±.

the Espresiff Systems ESP8266 and ESP32

FIGURE 4
MCUs, which are considered the cheapest and
PHP version info web page.
most popular options for this type of do-it-
yourself projects. Both include an integrated
TCP/IP protocol stack, and a Wi-Fi transceiver
to connect them to a Wireless Local Area
Network (WLAN).
Figure 5 shows the NodeMCU ESP8266-
based data logger prototype, and Figure 6
is its circuit schematic. As shown, the data
logger uses the Bosh Sensortec BME688
Environmental Sensor, which can detect
Volatile Organic Compounds (VOCs), Volatile
Sulfur Compounds (VSCs) and other gases,
such as carbon monoxide and hydrogen.
Additionally, it can measure atmospheric
pressure, temperature, and relative humidity
[4].
Because ESP8266 boards aren't supported
by the Arduino IDE by default, a support
package must be installed first, to be able
to compile code for this MCU. The support
package includes all necessary libraries to FIGURE 5
connect the MCU to the Internet, using Wi-Fi ESP8266-based MCU client prototype.
CIRCUIT CELLAR • OCTOBER 2023 #399

FIGURE 6 and the HTTP protocol. Installing this support

Data logger circuit schematic.
package is easy. You just have to open the
Arduino Preferences window and add the
support package URL into the "Additional
Board Manager URLs" field. For a tutorial on
how to do this, see the Circuit Cellar Article
Materials and Resources webpage [5].
Listing 2 shows the code for the data
logger to upload sensor data to the web
server. Lines 17-25 inside the s e t up ()
function connect the ESP8266 to the Wi-Fi
network with the ID and password specified
in lines 4-5. In lines 31-34 inside the lo o p O
function, we randomly generate four values to
simulate sensor readings. Even if the sensor
is connected already, it is usually preferable
to do the first tests using randomly generated
data. This allows us to test just the HTTP
n mM c u i iif o communications, without worrying about
tt |>r4 ■»>
errors from other system components, such
as sensors modules.
The data logger sends periodically its
sensor readings to the web server. This is
accomplished with the non-blocking delay
implemented in lines 37-46. Line 37 computes
the elapsed time since the last data sent.
Line 39 compares this elapsed time with the
publication interval defined in line 2, which
is 5,000ms (5 seconds). This is the interval
at which we want to send data to the server.
If the elapsed time is greater-than or
equal to the publication interval (line 39),
a CSV string is created by concatenating
all sensor readings with commas (line
41). The resulting string will look like this:
FIGURE 7
Arduino serial monitor displaying response from the web server.
"49.00,93.00,9.00,41.00". Next, with lines 42-
43, the string is printed to the Arduino serial

1 i n c l u d e <ESP8266WiFi .h>
2 # d efin e PUB_INTERVAL 5000 / / Data p u b lic a t io n in t e r v a l (msec)
3
4 char* s s id = “ M yW iFi” ;
5 char* password = “ MyCatKnowsAssembly” ;
6
7 W iFi C lie n t c l i e n t ;
8 char s e rv e r_ a d d r[] = “ 1 9 2 .1 6 8 .0 .1 5 ” ; / / S e rve r IP addres
9 char p h p _ s c r ip t _ u r i[] = “ / b a c k e n d /re c e iv e _ c s v . php” ; // URI f o r the PHP s c r ip t th a t w i l l
re c e iv e and p ro cess the data
10 S t r in g csv_ d a ta ; // CSV data s t r in g to send to the s e rv e r
11
12 vo id s e t u p ! ) {
13 S e ri al . begin (115200); // Open the A rd u in o s e r ia l te rm in a l
14 w h ile ( I S e ri a l );
15
16 // Connect to Wi Fi
17 S e ri a l . p r i n t ( “ Connect! ng to : “ );
18 S e ri a l . p r i n t l n ( s s i d );
19 W iF i.b e g in ( s s id , passw ord);
20 w h ile (W iF i. s t a t u s () != WL_CONNECTED) {
continued

LISTING 2
MCU web client Arduino source code.
 circuitcellar.com 9

terminal for debugging purposes. Line 44 will print the incoming server response after
calls the Send_Http_Request() function attending the HTTP POST request.
that's in charge of sending the CSV data to the Lines 55-74 show the Send_Http_
web server by issuing an HTTP POST request. Request () function definition. After creating
Line 45 takes the current system time a connection to the server (line 56), lines
in milliseconds to restart the time count for 59-68 send the HTTP POST request header. F
E
the next publication interval. Lines 48-51 Line 69 separates the header from the body, A
T
U
R
E
S
21 delay(500); LISTING 2
continued
22 Seri al.pri nt(“ .”);
23 }
24 Seri al.println(“WiFi connected. IP address:” );
25 Seri al.pri ntln(Wi Fi.1ocal IPC));
26 }
27
28 void 1oop() {
29 static long prev_mi11is; // Stores time of the last publication
30 // Generate random values to simulate sensor readings
31 float gas_resistance = randomCO, 100);
32 float pressure = random(0, 100);
33 float temperature = randomCO, 100);
34 float rel_humimidy = randomCO, 100);

36 // Compute elapsed time since last publication

37 long elapsed_time = millisC) - prev_mi11is;
38 // Send data to server if publication period has been reached
39 if (elapsed_time >= PUB_INTERVAL) {
40 // Create and send sensor data as CSV string
41 csv_data = String(gas_resistance) + + String(pressure) + + String(temperature)
+ + String(rel_humidity);
42 Seri al.print(“CSV string to send: “ );
43 Seri al.println(csv_data);
44 Send_Http_Request(); // Send data in an HTTP request
45 prev_millis = millisC); // Take current time to compute next interval
46 }
47 // Print response from server
48 while (cl ient.aval 1able()) {
49 char c = client.readC);
50 Seri al.pri nt(c);
51 }

54 // Function that sends data to server

void Send_Http_Request () {
56 if (client.connectCserver_addr, 80)) { // Create a connection with the server
57 Seri al.println(“Connected to server!” ); // Print to serial monitor
58 // Send HTTP POST request to server
59 cl ient.print(“POST “ );
60 client.print(php_script_uri); // Receiving PHP script URI
61 client.println(“ HTTP/1.1” );
62 cl 1ent.print(“Host: “);
63 cl ient.println(server_addr); // Include server address
64 cl ient.pri ntl n (“User-Agent: Arduino/1.0” );
65 cl ient.pri ntln(“Connect!on: close” );
66 client.println(“Content-Type: text/csv; charset=UTF-8” );
67 cl ient.printC“Content-Length: “ );
68 cl lent.printl n(csv_data.1engthC));
69 cl 1ent.println();
70 cl ient.print(csv_data); // CSV data inside the request body
71 } else {
72 Seri al.println(“Connect!on to server failed.”);
73
74
10 CIRCUIT CELLAR • OCTOBER 2023 #399

1 <?php
2 $csv = fi1e_get_contents(‘php://inpUt’); // Get the body (CSV string) from the incoming request
3
4 echo “Received CSV string: // Send back received data to client just for debugging
S 5 echo $csv . “\n” ;
E
R 6
U
T 7 $data_array = str_getcsv($csv); // Convert CSV to array
A
E 8
F
9 if($data_array != null) {
10 $unix_t = timeO; // Read unix time (GMT) from server
11
12 // Extract received remote values from array
13 $gas_res = $data_array[O];
14 $pressure = $data_array[l];
15 $temperature = $data_array[2];
16 $rel_hum = $data_array[3];
17
18 // Build SQL query string for the database
19 $query = “INSERT INTO data_logger(unix_t, gas_res, pressure, temperature, rel_hum) VALUES”

20 “(‘$unix_t’, ‘$gas_res’, *$pressure’, ‘$temperature’, ‘$rel_hum’)” ;

21
22 echo “SQL query: $query\n” ; // Send back query string to client just for debugging
23 }
24 ?>

LISTING 3
Listing for the "receive_csv.php" php and line 70 sends the CSV data as the body
script- of the HTTP request. The described structure
follows the HTTP protocol specification. The
Circuit Cellar Article Materials and Resources
webpage includes a link to an explanation
of HTTP protocol basics, in case you are not
familiar with it [6].
Note that line 60 inserts in the header
the Uniform Resource Identifier (URI) of the
PHP script on the server that will receive and
process the data. The php_script_uri
variable is defined in line 9. The URI string
7backend/receive_csv.php" specifies that
the request is directed to a "receive_csv.
php" script inside a "backend" folder in the
server's root directory. Line 63 inserts the
web server's IP address defined in line 8.
Additional materials from the author are available at:
www.circuitcellar.com/article-materials
References [1] to [7] as marked in the article can be found
there.
RESOURCES
Adafruit | www.adafruit.com
Arduino | www.arduino.ee
Bosch Sensortec | www.bosch-sensortec.com
Espressif Systems | www.espressif.com
Laragon | laragon.org
Raspberry Pi | www.raspberrypi.org
OUR FIRST PHP SCRIPT
So, to attend to the HTTP POST requests
sent by the MCU client, we need a PHP script
that will run on the server every time those
requests arrive. Remember from the MCU
client's Arduino code that the URI for this PHP
script is included in the HTTP header. So, now
we need to create a "receive_csv.php" script
and put it inside a "backend" folder in the
server's root directory. Listing 3 shows the
PHP code for the aforementioned script.
PHP code must be surrounded by an
opening tag, as shown in line 1 (<?php), and
a closing tag as shown in line 24 (?>). For
the most part, PHP is similar to C and C++
languages. However, all variable names in PHP
must begin with the character. In line 2
of Listing 3, the fi 1e_get_contents PHP
function reads from the server system the
incoming HTTP request's body, which, if you
remember, contains the CSV string with the
sensor readings. In the same line, this CSV
string is stored in the $csv variable.
Lines 4-5 send back debugging data to the
client using the echo "function" (technically,
a "language construct") that is analogous to
the printf C language function. Suppose
the received CSV string was, for example,
"49.0,52.0,23.0,30.0"; lines 4-5 will send
back to the client the string, "Received CSV
string: 49.0,52.0,23.0,30.0\n". The last two
characters (\n) are the "new line" character
that makes the cursor jump to the next line

in the screen. The '.' character in line 5 is the
PHP string concatenation operator. See as
well that in line 22 we have another e c h o .
All strings from these e c h o construct callings
will be included in the HTTP response's body
that the server will send back to the client.
Line 7 uses the s t r _ g e t c s v PHP function
to parse the CSV string and store the result
to the $ d a t a _ a r r a y array. The cells in the
resulting array will contain the individual
sensor values that were separated by commas
in the received CSV string. Line 9 checks that
the conversion operation was successful and
the resulting array is not null. If so, in lines
13-16 the array is indexed to read all sensor
values into local variables. But previously,
in line 10, we read the "Unix time" from the
server system and stored it into the $ u n i x _ t
variable.
In case you are wondering, Unix time is
a way of representing a timestamp as the
number of seconds since January 1, 1970
at 00:00:00 UTC. Unix time timestamps are
represented as integers, which makes them
easier to parse using programming languages
[7]. Here we are using the obtained server
Unix time as a timestamp for the sensor
readings batch that just arrived.
Next, in lines 19-20 we build the SQL query
string that will insert the received values
into the database. I will explain MariaDB
databases and SQL queries in more detail in
Part 2 of this article series. For now, let's just
accept as a fact that these two lines build the
required SQL query to insert the data into
the database, by concatenating two strings
(see t h e '.' at the end of line 19), including the
values stored in variables (line 20).
Line 22 echoes the resulting string
contained in the $ q u e r y variable to the
client. The string will look like this:
INSERT INTO d a t a _ lo g g e r ( u n ix _ t ,
g a s_ re s, p re ssu re , te m p e ra tu re ,
r e l_ h u m ) V A LU E S ( 4 9 . 0 , 5 2 . 0 , 2 3 . 0 , 3 0 . 0 )
The names inside the first parentheses
are column names in the "datajog ger"
database table. The values inside the second
parentheses are the corresponding values to
be inserted in each column. For now, we are
just showing how to create the SQL query, but
we are not using it yet. We will do that in Part
2 of this article series.
RUNNING THE FIRST TEST
Let's describe now the procedure to run
a first test with all that we have ready. First,
create a "backend" folder inside your web
server's root directory. On a typical Raspberry
Pi server installation, the server root directory
will usually be: "/var/www/html." The same
circuitcellar.com
applies to other Debian-based distributions,
such as Armbian and Ubuntu. Download
all source code files from the Circuit Cellar
Article Materials and Resources webpage.
Then, copy the "receive_csv.php" script to
the "backend" folder and make sure the file
has the right access permissions. For setting
the permissions open a terminal window on
the "backend" folder, and run the command:
chm od 644 r e c e iv e _ c s v . p h p
Next, connect the ESP82266 board to
your PC, and upload the "esp8266_http_post_
client.ino" Arduino sketch. Before flashing
your board, don't forget to change lines 4-5
with your Wi-Fi credentials and line 8 with
the IP address assigned to your server. After
flashing the board, it will reset itself and try
to connect to your Wi-Fi network. Open the
Arduino IDE's serial monitor to see debug
information. Once the board is connected
to your Wi-Fi, it will automatically start to
send data periodically to the web server. A
response from the server, similar to what
is shown in Figure 7, will be printed on the
serial monitor.
CONCLUSION
I hope I succeeded in showing you how
relatively easy it is to receive data from an
MCU client on a web server, and process
the data using PHP. To understand the
workflow, it greatly helps to be fam iliar
with the client/server model and the HTTP
protocol. If some concepts are still new
and confusing to you, take the time to read
the included resources, test the example,
and carefully analyze the provided code.
Don't w orry if you still have some lingering
doubts; just make sure you understand the
general workflow, and give yourself some
extra time to understand the details.
In Part 2 of this article series, I will
explain how to create a database and store
the received data in it, using a slightly
modified version of the PHP script described
here. I will also explain how to extract data
from the database and send it back to a web
client using a second PHP script. We will
also explore the pros and cons of using
different data exchange formats, such as
CSV, JSON, and XML.
ABOUT THEAUTHOR
Raul Alvarez-Torrico has a BEng in e le ctro n ics and is the fou n d er
of TecBolivia, a com pany offering services in physical com puting and
educational robotics in Bolivia. In his spare time, he likes to experim ent
with wireless sensor networks, robotics, and artificial intelligence. He is also
committed to publishing articles and video tutorials about embedded systems
and programming in his native language (Spanish), at their company's site
www.TecBolivia.com. You may contact him at raul@tecbolivia.com.
12 CIRCUIT CELLAR • OCTOBER 2023 #399

zram m
Embedded Linux
S
E
How to Maximize RAM in a
R
U
T
A
E
F
Linux Environment

By
Pedro Bertoleti

In this piece, I discuss how to use zram for memory swap, in order to create a drive/
disk that is mounted in RAM memory itself, using on-the-fly data compression and
decompression. This expands the real storage capacity in RAM and significantly
increases write and read speed in swap operations. As a practical example, III
also show how to use zram in a Raspberry Pi single-board computer (SBC).

a mbedded Linux is popular for its
I flexibility, wide array of supported
hardware, and robustness. But,
as happens for applications for
personal computers, the memory footprints
of applications supported by embedded Linux
tend to grow over time—and as a consequence
they demand more RAM memory to work
properly. This leads to more memory swap
operations, a must-have solution to keep
memory management healthy in embedded
Linux.
However, memory swap has a huge cost
for embedded Linux: it decreases the overall
performance of the operating system (OS).
Traditional memory swap operations use a
certain portion of a mass storage memory
(flash memory, SSD, HD, and so forth) to store
the less frequently used data. Considering
mass storage memory speed (read and write
speed) is much slower than RAM memory
data access speed, every single memory
swap operation suffers from the slowness in
writing and accessing data from mass storage
memory, which results in overall embedded
Linux latency.
This article covers how to use zram for
memory swap, so as to create a drive/disk
mounted in RAM memory itself, using on-the-
fly data compression and decompression. This
expands the real storage capacity in RAM and
significantly increases write and read speed
in swap operations. As a practical example,
I'll show how to use zram in a Raspberry Pi
single-board computer (SBC).
WHAT IS ZRAM?
In brief, zram is a Linux OS feature
with which you can create a block device
mounted into RAM memory, with on-the-fly
compression (so data can be written into
zram in compressed form) and decompression
(so data is automatically decompressed in
zram read operation). Data is automatically
compressed before being stored in zram,
and data from zram is automatically
decompressed before being read, too. This
compression-decompression feature gives
zram the ability to more data than its real
capacity, as all data is stored in a compressed
form.
Since zram is like a disk or storage
drive mounted into RAM memory, it takes
advantage of high-speed read and write
operations in RAM. Thus, zram also offers a
significantly higher read and write speed than
traditional mass storage memory (especially
old hard drives).
See Figure 1 for an interesting comparison,
the source for which can be found on C ir c u it
C e lla r's Article Materials and Resources
webpage [1]. As you can see, a RAM disk (or

a multipurpose disk mounted into RAM, such
as zram) can be more than 10 times faster
than a solid-state drive (SSD), and more than
47 times faster than a hard-disk drive (HDD).
zram is, definitionally, a resource that
allows one to create a compressed device
block into RAM memory. But its enhanced
data capacity and data read/write speed
make it the perfect choice for memory in
swap operations. In fact, using it as such
has many advantages. Let's examine some of
these now.
Faster read/write o f data: Even with
the time spent doing on-the-fly data
compression and decompression, zram is
still a significantly faster alternative to mass
memory storage. Using zram as memory
for swap significantly decreases the general
latency seen in embedded Linux when it's
in memory swap operation, since the I/O
wait—the time the CPU spends waiting for a
response from an I/O device, such as a block
device— is much shorter in zram thanks to the
RAM memory speed in data access. Hence,
embedded Linux performance tends to be
significantly enhanced, providing a smoother
experience to the user. In extreme cases,
zram can even prevent the memory thrashing
effect, wherein excessive memory swapping
drastically reduces system performance.
Avoids wearing out flash memory: As
discussed, traditional memory swap uses
mass storage memory. Nowadays, embedded
Linux systems usually have flash memory
for mass storage, and this can quickly wear
out with excessive memory swap operations.
Flash memory becomes unusable, and
embedded Linux won't work. With zram for
memory swapping, the flash memory isn't
used and is thus preserved—at least, it won't
wear out as quickly.
More flexibility: The way zram compresses
and decompresses data is governed by a
"compression algorithm." There are multiple
types of compression algorithms available,
enabling developers to test several and
choose the best fit for a particular solution. In
Hard Drive SSD
5 •
• 477.9
402.7
M l 30.49
200.3
circuitcellar.com
many cases, the right compression algorithm
can mean better overall embedded Linux
performance.
Increased total swap memory capacity:
Some compression algorithms offer
compression rates greater than th r e e -
meaning zram can actually store more than
three times its real data capacity. This feature
is especially useful in solutions that use a lot
of RAM memory, like rich user interfaces with
animations and high-resolution images.
PREREQUISITES FOR ZRAM IN
EMBEDDED LINUX
To use zram in embedded Linux, some
prerequisites must be met. These relate to
Linux kernel configurations that enable zram
usage, and that indicate which compression
algorithms must be integrated into the kernel
in its compilation. Then, enabling zram and
its compression algorithms involve Linux
kernel compilation.
If you're not familiar with the Linux kernel
compilation process, Raspberry Pi's website
has excellent documentation detailing the
full process for Pi boards [2]. Assuming
you are familiar, the following Linux kernel
configuration settings enable zram to work in
an embedded Linux OS:
• CONFIG_zram: Must be set to y.
• C0NFIG_zram _LZ4_C0M PRESS: For a
compression algorithm to be available in
embedded Linux, kernel configs must inform
it which compression algorithm to integrate
into the kernel when compiling. For example,
to make the LZ4 compression algorithm
available, CONFIG zram LZ4 COMPRESS
must be set to y. Consult Linux kernel zram-
related documentation to see other available
compression algorithm options (and their
corresponding kernel configs).
CONSEQUENCES OF USING ZRAM
As with everything, there isn't a definitive,
costless, and miraculous solution for an
RAM Disk
- C: •
235.7
248.9
64.67
FIGURE 1
233.2 A speed comparison between a hard­
disk drive, solid-state drive, and RAM
disk drive.
CIRCUIT CELLAR • OCTOBER 2023 #399
FIGURE 2
Free tool output
embedded system problem. There's always
a trade-off. A solution that improves some
aspects of a system can simultaneously worsen
others. And of course, zram is no different.
Specifically, zram demands more
processing from CPUs. Its on-the-fly
compression and decompression tasks require
extra processing compared to traditional swap
processes (those using mass storage memory
for swap). It's a good practice to check CPU
usage when using zram, to prevent undesired
side effects. I strongly recommend you:
• Check the overall impact on CPU usage: Can
the CPU still smoothly run everything? Is
overall performance significantly worse?
• Check the CPU's temperature: More CPU
usage means a higher CPU temperature.
You'll need efficient heat dissipation when
using zram. CPU overheating is a big
problem, and, needless to say, should be
avoided in all real-world implementations
of your solution.
ZRAM IN A RASPBERRY PI
So how d o you use zram in embedded
Linux? Due to its popularity and ease-of-use,
I'll use a Raspberry Pi SBC in my example
of using, testing, and validating zram. The
processes described here will work on any
Raspberry Pi except the Pico, as it doesn't
support embedded Linux. You'll need:
• One Raspberry Pi board, other than the Pico
• One micro-SD card to flash the embedded
Linux image
• One power source to supply the Raspberry
Pi (a 5V/2A micro-USB power source, for
example)
In addition:
• The micro-SD card must have the most recent
Raspberry Pi OS flashed. I recommend the
Raspberry Pi imager software, available on
their site [3]. It's intuitive and perfect for
this job.
Additional materials from the author are available at:
www.circuitcellar.com/article-materials
References [1] to [4] as marked in the article can be found there.
Resources
Raspberry Pi | www.raspberrypi.com
• You need access to a terminal in Raspberry
Pi. This can be done either via a local network
using SSH, or using a physical keyboard,
mouse, and monitor connected to the Pi.
• Your Raspberry Pi needs Internet access
to be able to update its packages and to
download the required software for zram.
Assuming you've already compiled the
Linux kernel with the discussed configurations
(the Raspberry Pi OS kernel is already okay),
the only thing left is to set up zram for
memory swapping.
There's an interesting open-source project
available on GitHub that helps in this regard
[4]. The appropriately named "zram-swap"
contains useful scripts to prepare a Pi board
to use zram as memory for swaps without
requiring the user to be familiar with memory
swap setup commands in Linux. I find it's a
practical solution for those who want to
quickly verify zram is working for swaps on
their Pi. To use zram-swap:
• Upgrade all currently installed packages by
executing the following commands:
sudo apt-get update
sudo apt-get upgrade -y
This can take several minutes to
complete, depending on your Internet
connection speed and how many
packages will need to be updated.
• Install git by using the command: sudo
apt-get in s ta ll g it
• Reboot Raspberry Pi using the sudo
reboot command.
• After Raspberry Pi reboots, go to the home
directory and clone the project source-code
by using the following commands:
cd
g it clone https://github.com/
toundobjects/zram-swap
• Enter the project's directory and execute
the install script by using the following
commands:
cd zram-swap
sudo ./ in s ta ll .sh
After finishing these steps, zram should
be working on your Raspberry Pi board as
memory for memory swap operations.

ZRAM SETUP IN RASPBERRY PI
By default, the zram-swap project from
GitHub configures zram to use 50% of the
total Raspberry Pi's RAM size, and configures
LZ4 as the compression algorithm. If you
want to change these configurations, you can
do so by accessing the /etc/default/zram-
swap file. This contains all configurations for
this project, should you ever need to tweak
any of them.
It's good practice to test some different
zram sizes and compression algorithms when
developing, to fine-tune the performance of
an embedded Linux distro. And you'll end up
with a clearer picture of how a given zram
size and compression algorithm influences
the performance of a particular embedded
Linux solution.
CHECKING THAT ZRAM IS
WORKING IN RASPBERRY PI
One useful way to check if zram is working
as memory for swap operations in your Pi is
to examine the content of the /proc/swaps file
by using the c a t / p r o c / s w a p s command.
This file contains information on swaps on
Linux, including type, priorities, and sizes.
You can also use the free tool to verify the
memory swap usage on the system. Figure 2
Ultra low power
digital MEMS
accelerometer for
battery-powered
applications
ANALOG
DEVICES
circuitcellar.com
shows an example of the output of the free
tool. Note that you can check several memory
stats on embedded Linux, including the swap
usage.
CONCLUSION
Hopefully now you know a little more
about the main advantages of zram over
traditional mass storage memory. It can be
significantly more efficient, as well as much
faster since it uses RAM memory. Further, I
hope you have sense of how and why to use
zram for swapping in embedded Linux. I think
it's an excellent way to the overall performance
of embedded Linux and prevent flash memory
wear-out. zram is great for embedded Linux
solutions that require a lot of RAM. Consider it
for your next application—I'd love to hear how
it turns out.
ABOUT THE AUTHOR
Pedro Bertoleti is a Brazilian embedded systems engineer and publisher
on Embarcados, a Brazilian embedded systems website. He has extensive
experience in development with PIC, ESP32, ARM Cortex MO and M3, and
Rabbit RCM22xx microcontrollers. Bertoleti also has knowledge in loT projects
and embedded Linux development in embedded systems.
" ^ O E V /C E S
a DXL367
VISIT ANALOG.COM/ADXL367
16 CIRCUIT CELLAR • OCTOBER 2023 #399

Evaluating EDATEC's
Line of Industrial Modules
Based On the Raspberry Pi Compute Module 4
S
E
R
U
T
A
After a few years during which all Raspberry Pi boards were
E
F unavailable to me, I was interested in getting my hands on a line
of modules made by EDATEC that are based on the Raspberry Pi
CM4 module. Here's the review.

FIGURE 1
This is a front view of the unit showing all of the terminal blocks, which are used to connect the
various I/O devices. There is a power LED and an activity LED, as well as a recessed Reset switch.
By
Brian Millier

a DATEC is a Raspberry Pi partner In this column, I'll specifically look at

H that manufactures a broad line of
industrial and Internet-of-Things
(loT) units that are all based on the
Raspberry Pi Compute Module 4 (CM4). This
module contains a Broadcom BCM2711 quad­
core Cortex-A72 (ARM v8) 64-bit CPU plus
supporting circuitry. Using the CM4 System-
on-Module (SoM) as the CPU/memory is a
good choice. Since there is a huge base of
Raspberry Pi users, there's an abundance
of Linux applications, drivers, and technical
assistance available for this platform.
When I was approached by EDATEC to
evaluate one or more of their CM4-based
products, my ears perked up immediately.
I had worked with the original Raspberry
Pi board introduced in 2012, all the way up
to the Raspberry Pi 4. But, for the last few
years, neither the Raspberry Pi 4 nor the CM4
module were available to individual users like
me, due to manufacturing supply chain issues.
I understand that the supply bottleneck is
easing up this summer, and CM4 modules
must be getting out to the manufacturers of
industrial/commercial products. Therefore, I
was interested in trying out the CM4 modules
that had been unavailable to me until now.
EDATEC's CM4 Industrial Module. However,
there are a number of similar units available
that are variations on the Industrial unit,
which contain different peripherals to better
suit different applications (Sensing, ED-
IPC2200, and so on).
Figure 1 is a photo of the front panel of the
CM4 Industrial module. In the foreground, you
can see that it is fitted with a DIN rail mount
which is detachable. All of the input/output
connections are made using detachable terminal
blocks with 2.5mm pin spacing. Two antennas
are shown here: one is for Wi-Fi/Bluetooth, and
the other is for a cellular modem. Both Wi-Fi/
Bluetooth and cellular are optional. A recessed
Reset switch is present, as are two LEDs to
indicate power and program memory access.
Figure 2 shows the rear panel of the unit.
Power (nominally 12V) is supplied through the
barrel socket. Two ethernet ports are standard:
one is lOOOMb/s and the other is 10/100Mb/s.
The lOOOMb/s port is handled by the CM4
module directly. The 10/100 Mb/s connection
is supplied by the LAN9500A USB2 to 10/100
Ethernet controller, fed by an LD36500A USB
hub chip. This hub chip also handles the two
USB2 sockets shown in Figure 2.

The Industrial contains a single HDMI
video port. It's rated for 4K operation and,
while it's unlikely to be used this way in an
industrial setting, I tried it out on my 4K
computer m onitor and it worked properly.
For industrial purposes, it's more likely that
a smaller TFT panel would be needed. This
module contains the standard DSI connector
found on the Raspberry Pi boards, and which
is compatible with the official Raspberry Pi
TFT touchscreen display. It also contains a
separate FPC HDMI connector which supports
a second HDMI screen plus a USB-based touch
controller. These two connectors would only
be readily accessible if you purchased the CM4
Industrial w ithout an enclosure and custom-
housed it yourself.
There are slots available on the back panel
to accommodate a pSD card as well as a SIM
card. While the slots/sockets will be present
on all models, they are only operational in the
following scenarios:
• The pSD socket can only be used when
eMMC memory is not mounted as the
system Flash memory. You can't use both.
• The SIM card is only active if you have
installed a 4G/LTE modem module.
I like the fact that the CM4 Industrial
can be purchased with 8, 16, or 32GB of
eMMC flash (as well as an option w ith no
eMMC, but using a pSD card for program
memory). Early adopters of the Raspberry Pi
sometimes experienced SD card corruption
when power was removed unexpectedly from
the Raspberry Pi. While the Raspberry Pi OS
has improved somewhat in this regard, the
problem still exists that pSD cards, even when
labeled w ith reputable brand names, can be
poor-quality clones. The eMMC memory is
more reliable.
The CM4 Industrial can be ordered with
1, 2, 4, or 8GB of RAM memory. Actually,
Flash size, RAM size, and Wi-Fi/Bluetooth
functionality are all dependent upon which
CM4 module is mounted in the unit. As the
CM4 is a socketed device and is available
from Raspberry Pi distributors/retailers, it
would certainly be possible to upgrade a CM4
Industrial module post-purchase, if needed.
The CM4 Industrial comes in a steel
enclosure w ith a reasonable amount of cooling
vents. The CPU and other heat-producing chips
contained on the CM4 SoM are coupled to this
steel enclosure via therm al pads. There is no
fan included with this unit, although there
is an adjustable speed fan control circuit on
the PCB and a 3-pin socket fo r a tachometer
fan. The CM4 Industrial is available w ithout
an enclosure and presumably that is when
the fan and controller m ight be utilized. I was
circuitcellar.com
only able to test the unit in my office, which
has seen ambient temperatures in the high
20s Celsius due to our hot summer weather.
The steel enclosure did not seem to get much
hotter than the ambient room temperature
under normal operating conditions, and the
CPU temperature widget on my toolbar showed
CPU temperatures in the high 40s Celsius. In
contrast, the EDATEC CM4 Media module, which
is enclosed in a small CNC-machined aluminum
case, gets pretty warm to the touch. However,
its CPU temperatures are comparable to what
I see on the CM4 Industrial.
At the other tem perature extreme, there
are two different CM4 Industrial model
variations: one fo r 0°C —►50°C and another
for -25°C 50°C.
Earlier, I mentioned that the CM4 Industrial
module is powered by 12V via a barrel socket.
I used the ED-PSU1202 DC adapter module
that was sent along w ith the CM4 Industrial.
This supplies 12V at 2A. Earlier versions of
the CM4 Industrial (V I.1 to V I.3) were rated
for an input range of 9V-18V. However, 24V
is commonly used in industry, so the newer
versions (V1.4 onward) are now rated for
9V-36V. The unit I received came in a box
showing exactly what options were present
(memory, Wi-Fi, cellular), but neither the
box nor the unit's enclosure contained either
a serial number or the hardware version
number. However, the revision level is clearly
shown on the PCB itself. Figure 3 is a photo
of the top of the CM4 Industrial's PCB; the
revision number is located to the right of
the A26 socket. The purpose of each of the
Axx legends is described in section 1.4 of the
user manual [1]. The CM4 Industrial module's
power supply is capable of providing a 5V at
1A output on the 2-pin header labeled A24.
When I checked, all of EDATEC's CM4
modules contained a Mini PCIe socket. This
FIGURE 2
This is the rear view of the unit. This contains two USB, two Ethernet, and an HDMI port that are normally
used to connect to a keyboard, monitor, and network connections.
18 CIRCUIT CELLAR • OCTOBER 2023 #399
can be used to add a cellular modem or SSD. I
was in an unusual position because I received
both a CM4 Industrial and a CM4 Media unit,
and it's unlikely any one customer would order
both. While reading the Media's documents,
S
I noticed that it could handle an SSD with a
E Mini PCIe interface. After ordering such an
R
U SSD, I discovered that the CM4 Industrial unit
T
A
E
F can handle a cellular modem in this Mini PCIe
socket, but not an SSD. This seemed unusual
to me, but the CM4 Media block diagram
shows the Mini PCIe socket connected to the
BCM2711's PCIe bus via a USB3 hub with an
mSATA port. In the case of the Industrial,
the PCIe socket connects to the BCM2711's
PCIe port directly. In any case, the new SSD I
purchased works fine in the CM4 Media.
INDUSTRIAL-PURPOSE INPUTS/
OUTPUTS
The CM4 Industrial module comes with the
following standard I/O ports:
• Two channels of Digital Input (optically
isolated)
• One Digital Output (DPDT relay 125V, 1.5A
contacts)
• RS-232 Serial port (±5V signal levels)
• Two RS-485 ports (half-duplex)
• One ADC (TI ADS1015 with three of four
channels available)
• Two CSI Camera ports (supports official
Raspberry Pi 5/8/12 Megapixel cameras)
• One HDMI port (4K-capable)
A1 A2 A3 A4 AS A6 A7 A8
A22 A21 A20 A19 A18 A17
FIGURE 3
This is the top side of the PCB. The "Axx" labels are described in section 1.4 of the User Manual.
• HDMI port via an FPC socket with I2 C port
for touchscreen controller
• One DSI display port
• Two externally-accessible USB 2.0 type A
ports
• Raspberry Pi standard 40-pin GPIO
connector (on the internal PCB)
There is an additional Micro USB socket,
accessible only with the enclosure removed.
This is used solely to program the eMMC flash
(assuming the CM4 module contains eMMC).
This should be hidden, as you don't want a
port that can reprogram Flash to be readily
observable or accessible.
Having a few more USB ports might be
useful—there are two header footprints
on the PCB: USB6 on A12 and USB5 on A13
(Figure 3). I wired up header pins and a cable
to these footprints, and these extra USB ports
worked fine.
Let's take a closer look at the I/O targeted
for Industrial purposes. The system diagram
in the user manual gives a block diagram
of all of the circuitry in the CM4 Industrial.
I wasn't supplied with a schematic diagram,
but a close inspection of the board allowed
me to draw Figure 4, which shows what ICs
are used for these I/O ports, as well as which
BCM2711 port drives them.
The CM4 Industrial datasheet lists part
numbers 2EDGR-2.5-XP/15EDGRC-2.5-XXP -1 4 -
00AH for the various input/output removable
terminal blocks on the front panel (where X
or XX are the number of terminals). The unit
comes complete with these pluggable terminal
blocks. The sockets and pluggable terminal
blocks are made by Degson and have a spacing
of 2.5mm between pins. The supplied terminal
blocks have pushbuttons that, when pressed,
allow the wire to be fully inserted and locked in.
I believe that the part number quoted above is
a combination of both the socket and pluggable
terminal block, but I couldn't find that exact
number for the terminal blocks on Degson's
site. However, Degson does carry 15EDGK-
2.5-XXP-10020000066 parts that are identical
to the terminal blocks supplied with the CM4
Industrial (again, the XX is the number of wire
terminals contained in the block).
Digital Inputs: Each of the two digital
inputs consists of a TLP185 optocoupler
connected to a specific BCM2711 GPIO pin.
The Digital Input connector contains six pins,
two of which are +12V and Ground. You can
use this 12V supply, along with switches and
so on, to drive the TLP185 opto-coupler. While
EDATEC shows a resistor divider network,
as shown in Figure 4, they didn't provide
any resistance values. They did state that a
voltage of 3V or greater across the DI+, DI-
terminals will activate the optocoupler, but

not much else. I wanted to know more, so
I performed some actual measurements
and determined that the equivalent internal
resistance in series with the TLP was about
4700. I also found that 4V (not 3V as stated)
was needed across DI+/DI- to activate
the TLP185 in my unit. Given the TLP185
datasheet and the approximate 4700 internal
current-lim it resistors, you can calculate what
size external current-lim iting resistor would
be needed if you're dealing with higher input
voltages. These inputs can be tested using the
following commands from the CLI (that is, a
term inal window):
r a s p i- g p io g et 11 (DINI)
r a s p i- g p io g et 26 (DIN2)
When 4V or more are applied to either
digital input, the level value that is returned
will be 0—otherwise it's a 1 (in other words,
negative-logic).
Digital Output: The digital output consists
of a single DPDT relay that is activated by
32 Mbit SPI NOR Flash Raspberry PI
CM4
Real Time Clock
Buzzer
USER BUTTON
Note: No I/O protection components
shown here.
circuitcellar.com
GPIO22. This is not a particularly heavy-duty
relay: the contacts are rated at 2A at 30VDC or
1.5A at 125Va c . The labeling on the front panel
uses " 0 " for the N.O. contacts, "C" for the N.C.
contacts, and "W" for the moveable contacts.
The relay output can be easily tested using
the following commands from the CLI:
sudo r a s p i- g p io s e t 22 op dh
(opens the relay)
sudo r a s p i- g p io s e t 22 op dl
(closes the relay)
Here again, this uses the negative-logic
convention.
RS-232: The front panel RS-232 connector is
driven by a Sipex SP3232 RS-232 interface chip.
This device contains its own charge pumps to
provide the ±5V RS-232 signal levels. As far as I
can tell, there are no hardware handshake lines
available for this port. UART5 on the BCM2711
drives this port. I tested it with the Minicom
Serial terminal program—the RS-232 port is
device /dev/ttyAMA3 in the Linux OS.
GP1Q22
FIGURE 4
This is a block diagram of the CM4
Industrial's input/output ports
showing what chips are used for each
function. I don't show the ports used
2A30V o
to connect up to USB devices or an
0.5A 125V
HDMI monitor.
20 CIRCUIT CELLAR • OCTOBER 2023 #399
S
E When you have Minicom running, if you
R
U
T hit Control-Z followed by A, you get the Menu
A
E
F
FIGURE 5
This is a scope capture of one of the RS-485 ports that was outputting data at 115,200 baud. The
differential voltage output (2.44V) is the standard RS-485 specification.
RS-485: The RS-485 was a bit more
difficult for me to test since I don't have
modules with an RS-485 interface on hand.
The RS-485 standard is a two-line, differential
signal. In the CM4 Industrial, there are two
half-duplex RS-485 ports using UART3 and
UART4. To test the RS-485, I placed a 1200
termination resistor across the port's A and B
terminals. I then placed a 'scope probe on each
of the A,B terminals. I hooked up the probe's
ground lead to the RS-485 "G" terminal. While
the EDATEC user manual recommends using
the Picocom application, I used Minicom since
I was able to configure it to:
• Send an ASCII file, without the use of
a file-transfer program that requires a
FIGURE 6
This is a scope capture of a 5.1KB file being transmitted via RS-485. The 450ms time that it took for the
transfer matches the 115,200 baud rate that I was using.
handshake routine with the destination
device in order to proceed.
• Allow the chosen UART port (UART3 or
UART4) to control the data direction line on
the SP3485 RS-485 Interface chips.
screen. You then get into the configuration
menu by typing O. There you pick the Serial
Port Setup and type H for RS-485 enable. For
the serial port device, you use either /dev/
ttyAM Al or /dev/ttyAMA2, depending upon
which RS-485 port you are testing.
Back at the Minicom main screen, you then
start your file transfer by typing Control-Z
and O. You choose ASCII for the file protocol
and then pick a file to send.
Figure 5 shows a scope capture of the RS-
485 output during the transmission of a 5.1KB
file. The signal amplitude is 1.22V for each
line. You can see that they are differential
signals, so the total signal amplitude is 2.44V,
which is the RS-485 specification. From
Figure 6, you can see the total transfer time
was 4500ms—this is the correct timing for a
5.1KB file sent out at the 115,200 baud rate
that I had chosen.
While I did have a Maxim MAX3485 RS-485
driver chip on hand, due to time constraints,
I did not wire it up to a PCB and test out the
CM4 Industrial's RS-485 receive function.
Note that the RS-485 wiring diagram in
Section 3.1.5 of the user manual is incomplete.
The GND terminal of the CM4 Industrial
should be connected to the ground terminals
on any connected RS-485 peripheral devices.
It's unlikely any user of RS-485 devices would
neglect to connect these up.
The RS-485 ports have an input protection
circuit as shown in Figure 7. This consists
of SMBJ12-CA-13-F TVS devices connected
across the A-B terminals and between each of
A and B to ground.
Miscellaneous I/O Devices: There are
two miscellaneous I/O devices: a piezo buzzer
which can be used for an alarm, and a user
switch on the front panel. The Piezo buzzer
is driven by GPIO25 and can be turned on/off
as follows:
ON: sudo r a s p i- g p io s e t 25 op dh
OFF: sudo r a s p i- g p io s e t 25 op d l
The user button is connected to GPIO6 and
can be detected as follows:
r a s p i- g p io g e t 6
which returns: GPIO 6: level=X fsel=0
func=INPUT pull=UP
where X=1 if the switch is NOT pressed, X=0
if it is (negative-logic used)
 circuitcellar.com

The CM4 Industrial's PCB contains a few crosses a threshold (a window mode is also
header pin footprints that are not mentioned available)
in EDATEC's documentation. There is a 4-pin • A wide supply range of 2.0V to 5.5V
footprint with labels for 3.3V, GND, ANO, and • I2 C interface (up to 400kHz in standard
AN1. I am not sure what they are for. mode, up to 1MHz in high-speed mode)
There are also pinouts for SYNC IN and
SYNC Out. While these are not mentioned I've used this particular ADC many times
anywhere in the documents, I know from the in the past and find it to be accurate and
Raspberry Pi CM4 technical reference that versatile. In the CM4 Industrial, only AIN1
they are 1.8V signals to support IEEE 1588-
2008 [2]. This is a feature that allows for a
1V3 445wi
high-precision clock synchronization protocol
derived from the Ethernet signal itself.
Analog Input: The CM4 Industrial
contains three channels of analog input. This
is handled by a Texas Instruments ADS1015
which contains the following features:

• 12-bit sigma-delta ADC

• A built-in PGA amplifier with full-scale
ranges between ±256mV and ±6.144V
• An 8-way input multiplexor that can select
each of the four inputs in single-ended
mode or four differential modes using
combinations of the four input pins
• Sample rates between 128SPS to 3300SPS
• A programmable comparator that can FIGURE 7
trigger an interrupt when the input voltage This is a snippet of the protection circuitry present on the RS-485 ports.

A \ M ic r o c h ip
CIRCUIT CELLAR • OCTOBER 2023 #399
through AIN3 are brought out to the Analog
terminal block. For some reason, AINO is not
available. This reduces the single-ended input
choices to three and the differential input
choices to two.
The ADS1015 is a single-supply ADC. I
don't see any sign of logic-level translators
near this chip, so I assume it's powered
by 3.3V, as that is the logic level expected
by the BCM2711. That means that the
ADS1015's analog input signals must remain
between ground potential and 3.3V. For the
single-ended input mode, this means that
only positive voltages in this range can be
measured. If you configure the ADS1015 for
differential input measurement, then bipolar
signals can be measured, but only if they
ride on a common-mode voltage that keeps
the signal peaks within the OV to 3.3V range.
Given this limitation, the ±6.144VFS scale can
be used but you will never see any readings
beyond about half-scale.
I asked EDATEC whether there was any
protection circuitry present for the ADS1015
inputs A1-A3. They replied that the ADS1015
itself has ESD ratings of ±2000V HBM model
and ±500V CDM model. These figures are
from TI's datasheet. No additional circuitry
is present. However, you cannot apply any
sustained voltage to any of the ADS1015's
analog inputs outside of the GND-0.3V to
Vc c +0.3V range, so I would be careful to allow
for this in any external circuits that might be
connected up.
I am accustomed to using the ADS1015 in
"C" or Python programs. In these cases, you
interact with the ADS1015 via a driver library
that is written in "C." With the Linux operating
system present on the CM4 Industrial,
controlling and reading the ADS1015 is
done much differently. Texas Instruments
provides a Linux driver for the ADS1015
using the device tree. However, there was
not enough information on TI's website for
me to determine if that is what is used on
this module. However, if you navigate to the
following folder:
/sys/bus/iio/devices/deviceO
you will see a whole series of files. To read
the voltage present on a specific ADC
TABLE 1
LSB sizes corresponding to full scale
readings
channel, you just perform a file read on
the file "in_voltageX_raw" where "X" is the
channel number (other files are present for
the differential readings as well). Note that
these files are labeled in the same way that
the ADS1015 datasheet uses. That is, they
range from channel 0 through channel 3. So,
for example, you can read the ADC channel
labeled AIN1 on the front panel by issuing the
following command from the CLI:
cat in_voltagel_ raw
As mentioned earlier, the ADS1015 CHO is
not brought out to the Analog terminal block.
Also present in this folder is a series of files,
one for each ADC multiplexor channel (single-
ended and differential) that end in the word
"scale." If you examine any of those files,
you'll see that they contain the single number
3.00000. This corresponds to the number of
millivolts per LSB, expressed in millivolts.
In this case, 3mV corresponds to a full scale
of 0.003 x 4096 = 12.288V. However, since
the ADS1015 provides bipolar readings, this
corresponds to a VFS of ±6.144V. For other full-
scale ranges, you can change this entry, as
shown in Table 1. When I tested the ADS1015
in the CM4 Industrial module, even on the most
sensitive (±0.256 V) scale, I only observed one
LSB variation in the results, with the input
voltage held constant. From experience, I also
know that each of the available PGA gains are
exactly a factor of 2.00 apart, so you can do
things like auto-scaling easily without any
per-range calibration factors needed.
Similarly, there are a series of files
ending in "sampling_frequency." The number
contained in these files can be read and/or
changed to the following sample rates: 128,
250, 490, 920, 1600 (default), 2400, and 3300
samples per second. I doubt that the Linux
driver can handle the higher rates, however.
The ADS1015 is capable of responding to I2 C
addresses of 0x48, 0x49, 0x4A, and 0x4B,
depending upon how its Address pin is
strapped. In the CM4 Industrial, it responds
to the default I2 C address of 0x48.
I have not found any evidence that the
supplied ADS1015 Linux driver can handle the
comparator function that I mentioned earlier,
but I could be mistaken about this.
Raspberry Pi 40-Pin GPIO header: This
unit contains a footprint for the standard 40-
pin GPIO header found on all recent Raspberry
Pi modules. You should note, however, that
a number of these GPIO pins are already
allocated to internal functions: GPIO 6, 26,
and 11 are some examples.
RTC: The unit comes with a PCF8563
real-time clock chip installed. There is an
accompanying CR1202 socket, but the unit

does not ship with a battery (at least outside
of China). The OS board support package
integrates this RTC with the OS system time,
so the unit will m aintain the correct tim e
even if power is removed and an internet
connection is not im m ediately available to
load the system clock using an NTP server.
This device is connected to the I 2 C-1 bus.
The datasheet gives its 7-bit I 2 C address as
0x51, which I confirm ed with the i2cdetect
utility. I tested it, and it was working fine, as
described in section 4.6 of the user manual.
SPI NOR Flash: The CM4 Industrial
comes with a 25Q32SCSIG 32Mb SPI NOR
Flash device. This could be used to hold any
param eters that seldom change but need
to survive a power-down, power-up cycle.
Things like encryption and authentication
strings come to mind. Section 4.10 of the user
manual covers this topic but is quite vague.
While I was able to follow the instructions
there and erase the SPI Flash, I was not able
to mount it to the OS filesystem using the
com m and that they suggest:
sudo mount -t jffs2 /dev/mtdO /mnt
I would need some help from EDATEC's
technical support to figure out how to use this
Flash m em ory in Linux.
However, the datasheet gives the
allocations for this device in section
Personally, it would likely be easier for me
to utilize this Flash chip using Python and an
appropriate library, given that the SPI port
pins and CS line are known.
4G Modem: The CM4 Industrial's
PCIe socket is meant to accept an optional
4G modem. This would be a Quectel modem:
there are four different versions of this modem
depending upon what part of the world you
are operating in. The custom Debian Buster OS
that I downloaded from EDATEC came with the
Network Manager Tool installed (in place of the
standard dhcpcd network utility normally found
on the Raspberry Pi OS). Section 4.5.11 of the
user manual explains how to set up this modem.
EDATEC sent me the CM4 Sensing module
with a Quectel EC25-AFX modem (North
Am erica) installed. It would be easy for me to
transfer this over to the CM4 Industrial. I have
worked with cellular Particle loT modules,
but don't have any prior experience using a
cellular modem with a Raspberry Pi. Also, I
didn't have a usable SIM card on hand. So, I
have not tried out this function yet.
CM4 INDUSTRIAL OS FIRMWARE
When I received these modules
EDATEC, I assumed that they came directly
from the factory in China, and that the pre-
loaded OS image would be the latest version.
circuitcellar.com
I also assumed that each of the units would
perform as was described in the respective
user manual. However, the ones I received were
sent by EDATEC's USA sales representative
and came with an older OS image installed
and without the board support package
(BSP) installed. Later, I noticed that the CM4
Industrial's version number (internally labeled
on the PCB) was V I.3, not the latest V1.4.
Note that, at startup, a new Raspberry Pi
will prom pt you to do an update. While this
is som ewhat of a lengthy process (depending
on your Internet connection speed), it's not
updating the installed Linux kernel to the
newest version— it's just doing a lot of other
useful updates.
When I contacted tech support at EDATEC,
the presence of the older firm w are was
confirm ed. So I started from scratch and
downloaded the latest OS image from their
website.
Loading a new OS image to the EDATEC
CM4 m odules is straightforw ard. You basically
take the proper ZIP file obtained from EDATEC,
extract it, and use either the Raspberry Pi
Im ager program or balenaEtcher, both of
which are user-friendly. This is the procedure
to use if your EDATEC CM4 module has its OS
located on a pSD card— which is how the CM4
Media unit that I received was configured.
pin However, it's more likely that a CM4
4.1. Industrial module will be ordered with eMMC
flash m em ory instead of a pSD card. In this
case, it's a bit more involved.
The CM4 Industrial (and other sim ilar
modules with eMMC Flash) contains an internal
Mini Micro USB socket (labeled as A9 in Figure 3).
This is a USB OTG port that is connected to
the BCM2711 MCU (via a USB switch device).
This USB port is configured to look like a USB
Flash drive when it is plugged into a PC. So,
when you do the flash operation from either
the Raspberry Pi Im ager or balenaEtcher, you
select this USB Flash drive as the destination.
There is one im portant thing to note.
If you plug the CM4 Industrial into your
W indows PC (using a USB cable connected
to this Micro USB socket), and power up the
Industrial, you will hear the standard tones
that indicate a USB device has been detected.
However, the W indows File Explorer will not
pop up to show you an attached USB Flash
drive. This is unlike many 32-bit ARM MCUs
that run CircuitPython (as well as some other
ARM MCUs) which im m ediately show up as an
attached USB Flash drive.
Instead, before you plug in the CM4
Industrial, you have to load a custom Windows
from driver that is designed to recognize a Raspberry
Pi CM4 module. This driver is loaded by a
program called "rpiboot setup.exe"—the URL
for which can be found in section 5.2 of the
24 CIRCUIT CELLAR • OCTOBER 2023 #399

are supposed to contain the BSP for the CM4

Industrial. I only tried the OS with the desktop
64-bit version and confirmed that the BSP had
been included.
While the image file that I loaded came
with the BSP, there was one small detail
S
E that was not already done and had to be
R
U performed manually. The Raspberry Pi CM4
T
A
E module contains its own trace antenna for Wi-
F
Fi/Bluetooth. The CM4 Industrial has a steel
case, so this internal antenna won't work well
enough to be useful. You will either not detect
your Wi-Fi router at all, or you may connect
to it and then have a poor, slow connection. To
switch to the CM4 Industrial's external whip
antenna, you must add the following line to
the /boot/config.txt file:

dtparam = ant2

When I questioned EDATEC about why this

wasn't done as part of their custom OS images,
FIGURE 8
they replied that the CM4 Industrial is available
This shows the internal USB connection that I made when re-flashing the eMMC memory with the newest
as a bare board without a case, so they left
OS firmware.
the choice up to the end user. It's somewhat
confusing to a new end user, however.
The EDATEC custom 64-bit desktop version
of the OS (Buster release), that I loaded takes
CM4 Industrial user manual. When this file is up about 5.9GB. This is a significant proportion
run for the first time, a Windows PC will drop of the 8GB eMMC Flash that came with the
into the command line mode and install this CM4 Industrial that I received. This might
driver. You will see a message to indicate that be enough free storage space to run most
this was successful. After this is done, when industrial applications. Foolishly, I thought
you subsequently plug in the CM4 Industrial, it I'd try loading the Arduino IDE plus the board
will show up as a USB Flash drive. At this point, support package for the ESP32 MCU that I
you can use either the Raspberry Pi Imager or commonly work with. This completely filled up
balenaEtcher to download the new OS image. the eMMC flash space before the installation
Figure 8 shows the hook-up of the USB cable. was even completed. I had to manually
This is a right-angle, surface mount socket, so remove all of the files to regain that space.
insert the USB cable gently. I'll try this again on the CM4 Media module,
EDATEC provides both 32 and 64-bit which now contains a 32GB pSD card as well
Raspberry Pi OS images in two versions: full as a 250GB SSD which I installed myself.
(with desktop), and Lite. All four versions
CONCLUSIONS
Once I realized that the unit came with
ABOUT THE AUTHOR old OS firmware and was missing the board
Brian Millier runs Computer Interface Consultants. He was an support package, I was able to update it
quickly enough. After that, all of the tests
instrumentation engineer in the Department of Chemistry at Dalhousie
which I performed (described earlier) worked
University (Halifax, NS, Canada) for 30 years.
well.
EDATEC's website is informative. My initial
firmware problems were exacerbated because
Additional materials from the author are available at: the link to the CM4 Industrial's user manual
www.circuitcellar.com/article-materials was broken. I spun my wheels over the first
References [1] to [2] as marked in the article can be found there. weekend until I was able to contact EDATEC
and get a PDF copy of it. That link is now fixed.
RESOURCES EDATEC's website does not include any
DEGSON | www.degson.com pricing, but you can go to DigiKey's website
and get pricing there.
EDATEC | www.edatec.cn
I'd like to acknowledge the software
Raspberry Pi | www.raspberrypi.org technical assistance I received promptly from
Texas Instruments | www.ti.com Ray Xie at EDATEC.
j 'Jj j j liny n jjji iuyJj-
such as this book,

designing a microprocessor
can be easy.
Microprocessor Design Using
Okay, maybe not easy, but certainly Verilog HDL will provide you
with information about:
less complicated. Monte Dalrymple •Verilog HDL Review

has taken his years of experience • Verilog Coding Style

• Design Work
designing embedded architecture • Microarchitecture
and microprocessors and compiled • Writing in Verilog
• Debugging, Verification,
his knowledge into one comprehensive and Testing

guide to processor design in the • Post Simulation and more!

«
real world.

Monte demonstrates
™»<>P>ocessor
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.
 CIRCUIT CELLAR • OC1OBER 2
<
Replacing batteries in non-rechargeable
devices is expensive. When I built personalized
bobbleheads for my grandchildren, I decided to
make them so Iar-powered. Here's a description
of their electromagnetic actuation and simple
circuitry.
■ x*
obbleheads, sometimes called
wobbleheads, have been with us
for more than 200 years. They
were popular in the 1950s, but
they surged in popularity in the 1990s
with the emergence of precision injection
molding techniques that allowed recognizable
representations of sports, entertainment,
and political figures. Three-dimensional
printing technology allowed the creation of
personalized bobbleheads starting around the
year 2000.
My Internet research revealed that
bobblehead and wobblehead as a description
for such dolls is a generic term, but
"Bobblehead" was briefly trademarked a few
years ago for other items, including cat toys
and dog toys. Those trademarks have been
abandoned, but there is a trademark for a
specific type of bobblehead: Royal Bobbles.
The alternative spelling, "Bobble Head,"
was briefly trademarked, but abandoned.
Wobblehead is also the name of a type of
fishing lure.
I wanted to make bobbleheads of my
grandchildren, but I wanted the heads to
DlOlDJ D
be in constant motion without any human
interaction. Continuous mechanical actuation
of any sort requires a lot of power, and
battery power would have required many
battery replacements in a year. Using one of
the ubiquitous wall transformers for cellphone
and tablet computer charging would have been
overkill for such a simple toy, and there's also
the problem of a wire attachment. I finally
decided to make them solar-powered.
SOLAR POWER
The average intensity of solar energy above
the atmosphere directly facing the Sun is about
l,360W per square meter. At Earth's surface,
this intensity varies by latitude, cloudiness,
and time of day. At my latitude of about 40.9
degrees, it's l,000W/m 2 at noon on a clear day
around the summer solstice (June 21).
Conversion of this solar energy to electrical
energy happens with an energy conversion
efficiency. The first photovoltaic cells of the
type that powered the Telstar communication
satellite in 1962 were fabricated from
expensive single-crystal silicon wafers
with efficiency of slightly above 10%. While

advanced thin film solar cells as used in
rooftop systems have efficiencies above 25%,
inexpensive polycrystalline photovoltaic cells
available to hobbyists have efficiencies of
about 10%-15%.
When I was searching for suitable
polycrystalline photovoltaic cells, the most
frequent comment I saw among customers
was that the supplied currents claimed by
manufacturers were far higher than what was
achieved in practice. At that point, I decided
to do a first-principles calculation of how
much power should be obtained. Taking 10%
as the efficiency, and the theoretical optimum
insolation of l,000W/m2 , I calculated that
a 5cm x 10cm 5V cell (about the largest
acceptable size for my project) would likely
give a maximum current of 100mA.
MECHANICS
I created the bobbleheads of my
grandchildren from Lego images I found on
the internet with image modification by the
GNU Image Manipulation Program (GIMP). For
the purposes of this article, I needed a public
domain image, so I selected the iconic image
of Apollo 11 astronaut Buzz Aldrin taken by
Neil A. Armstrong. I used GIMP to enhance
the image contrast and color saturation. The
image was pasted onto foam board and cut to
size with an X-ACTO knife.
A current of 100mA at 5V, 0.5W, was not
enough power for an up-down bobble action,
as my experiments confirmed. However, it
was enough for a side-to-side wobble action
using a pendulum mechanism that I devised.
The actuation was achieved with a rare earth
circuitcellar.com
FIGURE 1
Rear view of my bobblehead, left,
with a diagram representation on the
right. A current pulse in the copper
wire coil draws the magnet inwards
and rotates the rod. For a larger
response, another magnet can be
stacked on top of the first magnet.
magnet being attracted into a coil of copper
wire. The actuation was periodic with about
a three-second cycle, and a capacitor was
used to store energy between activations to
ensure a strong response. A plan view of the
pendulum can be seen in Figure 1. An acrylic
plastic rod was used as the pendulum with
the pivot point slightly above its center. The
pivot point can be adjusted to how much
wobble you want.
A low-friction rotational pivot with limited
motion in transverse directions is desired. I
made mine from a 4-40 bolt inserted into a
block of polyethylene, as shown in Figure 2.
I don't recommend lubrication, as oils will
gum with age. Dry graphite powder, as used
to lubricate locks, might be suitable, but I
FIGURE 2
Detailed views of the pendulum pivot and attachment to the image head. The pivot should be low-friction
with easy rotation but limited-motion in other directions. This was accomplished by using a polyethylene
block with a long path for the attachment bolt. Attachment to the image head was with a stiff wire that
allowed easy manipulation in all directions.
28 CIRCUIT CELLAR • OCTOBER 2023 #399

FIGURE 3
My simple coil winding jig (left), and
a detailed view of the coil assembly
with magnet and pendulum rod.
The counterweight, supplied by
multiple steel nuts, ensured that
S the resting state of the magnet was
E
R at the entrance of the coil. Careful
U
T measurement would center the
A
E carrier bolt for the magnet with the
F
lower portion of the coil opening.
However, in this case, I needed to use
a technique that my colleagues and I
humorously called "precision bending"
to effect the proper alignment. The
connecting wires from the coil are
sent to the bottom of the base, where
there's a cavity under the solar cell for
holding the printed circuit board.

didn't need it for my bobbleheads. I attached

the head with a stiff wire that allowed easy
adjustment of the head position by bending.

COIL
The coil was 1,000 turns of AWG-36
enameled copper wire wound on a coil form
made from a 0.5" length of 0.75" outside
diameter PVC pipe commonly available at
home goods stores. Thin plastic discs were
glued to the ends of the PVC pipe section to
contain the wire. The large inner diameter of
the pipe allowed easy passage of the magnet
FIGURE 4 from one end to the other. The coil resistance
Bobblehead circuit. The circuit provides precaution against polarity reversal of the capacitors. The is slightly more than 100ft, and it varied
reverse-biased diode across the coil protects the drive transistor from an inductive kick-back voltage. from 103ft to 112ft for the five coils I made.
The circuit was designed with a 1500pF storage capacitor, which worked adequately. In the end, I used This resistance draws about 50mA from the
a 3300pF capacitor that slightly overflowed the circuit board edges (see Figure 5). nominal 5V source voltage; so, it's not too
demanding of the solar cell. The magnet
used is the commonly available NdFeB rare
earth disc magnet, 8mm in diameter by 3mm
thickness.
Manually winding 1,000 turns for a single
coil is possible, but tedious. Since I needed
to make several coils, I assembled a simple
winding jig from available scrap materials in
my workshop (Figure 3). The jig was mounted
in a bench vise, and the copper wire was
spooled from a vertical rod. While a manual
turns counter would be useful, a precise
number of turns is not required. I counted in
increments of 100, writing down when each
FIGURE 5
Printed circuit board layout (left), and a photograph of the board in the base cavity of the bubblehead
hundred's interval had passed as a memory
figure. As explained in the text, a 1500pF capacitor was originally used to store energy from the solar cell, aid.
but a 3300pF capacitor works somewhat better.
CIRCUITRY
The circuitry for the bobblehead, as shown
Additional materials from the author are available at:
in the schematic (Figure 4), is simple and
cheap. A CD4011B CMOS logic circuit is used
www.circuitcellar.com/article-materials
as a square wave oscillator and edge detector.
Reference [1] as marked in the article can be found there. While non-buffered CMOS logic ("A" series) is
seldom found today, it's important to use a
RESOURCES buffered ("B" series) chip. Circuit portions,
Texas Instruments | www.ti.com ICla-IClc, form a square wave generator, and
 circuitcellar.com

ICld is an edge detector. Since we need to use FIGURE 6

Voltage w aveform measured at
polarized capacitors for the required large
the bobblehead coil during normal
capacitance values, two series capacitors
operation. There's a sharp voltage
with a large value resistor are used in place of
pulse at 2.75-second intervals.
a single capacitor to prevent polarity reversal.
The nominal oscillator period is three seconds,
which gives an aesthetic bobble time for the
head. Coil polarity is important. If the magnet
is repulsed by the coil rather than being
attracted to it, reverse the coil connections.

FINAL COMMENTS
Children are not typically careful, and I
wanted to prevent any damage to the
ABOUT THE AUTHOR
bobblehead figures. For that reason, I
Dev Gualtieri received his Ph.D. in Solid State Science
enclosed the figures in transparent Lucite
and Technology from Syracuse University in 1974. He
plastic cases, 4x4x8" in dimension. I have
had a 30-year career in research and technology at
ceiling spotlights above my workbench, and
these have enough light to fully excite the a major aerospace company and is now retired. Dr.
bobblehead into action. LED desk lamps and Gualtieri writes a science and technology blog at
table lamps work when the solar cell is tikalon.com. He is the author of three science fiction
directly below them, as does an LED flashlight. novels, and books about science and mathematics.
Direct sunlight through a window will work See tikalonpress.com for details. You can reach Dev at
for a few hours a day; so, the bobblehead gualtieri@ieee.org.
would act as a sunlight intensity meter.

COIL INDUCTANCE AND MAGNETIC FIELD measurement is based on the resonance of a parallel LC
Inductance coils are the most perplexing components in circuit (Figure 7). Manually sweeping a signal generator to
electronic circuitry. It's possible to source many standard determine the resonance with a selected capacitor allows a
values of resistors and capacitors, but obtaining particular calculation of the inductance by the equation:
inductance values is a difficult task. That's why hobbyists 1
L=
are forced to wind inductance coils specific to their projects.
4tt 2F2C
There are some empirical formulas for winding coils
to a specific inductance value, the most notable being a for which L is the inductance in H, F is the frequency in
century-old formula for multilayer coils devised by Harold A. Hz, and C is the capacitance in F. For the bobblehead coil
Wheeler and published as "Simple inductance formulas for and a O.OlpF capacitor, the resonance frequency was
radio coils" in Proceedings of the IRE in 1908 [1]. Wheeler's 11kHz, giving an inductance of 20.9mH. You can see that
formula is as follows: Wheeler's estimate gives a smaller
value, the supposed reason being
0.8a 2N 2 that the bobblehead coil is longer
6a + 9b + 10c than Wheeler's model coil.
The magnetic field inside a coil is
where L is the inductance in pH, N is just a function of the current and the
the number of turns, a is the average turns per length:
radius of windings, b is the length
of the coil, and c is the difference D _ M -N
between the outer and inner radii
of the coil (all in inches). For our for which B is the magnetic field in
1,000-turn coil in the bobblehead, gauss (G), p0 is the permeability of
this calculation gives an inductance the vacuum (0.01257G-m/A), I is the
of 18.7mH. As Wheeler wrote in his current in amps, N is the number
paper, the equation is accurate only of turns, and L is the coil length in
for coils in which the three terms in meters. For the bobblehead coil,
the denominator are approximately this gives a field internal to the coil
equal. This would be a flatter coil than of about 50G for its 50mA current.
the bobblehead coil. The resultant attractive force of the
Most multimeters will measure FIGURE 7
coil to the rare earth magnet is a few
resistance and capacitance, but A circuit to measure the resonance of a parallel combination grams, somewhat less than the weight
not inductance. The technique that of inductance and capacitance. A capacitance of O.OlpF of a nickel coin. This underscores the
I've always used for inductance gave the resonance response shown for a bobblehead coil. need for a low-friction pivot.
 es, sorry to say fellow engineers,
Y
the ancient saw is true. Size not
only matters, but it's a critical
acceptance parameter. I've done
the research, conducted extensive, in-depth
interviews, and can state here definitively that
the jury has returned their verdict: Smaller is
better. But no matter what the size, it's also
important what you can do with it.
Hold on a minute there! I can see that
you're getting all excited but it's not what you
think. Get your mind out of the flux gutter
and pay attention. This is not some random
post on Twitter, er, um, X. We're talking about
embedded board size. And, as the red circles
around your eyes from the magnifying lab
goggles you need just to place your scope
probe in the approximate location of the pin
on the ultra-fine pitch SMT part that your
current embedded project is using can attest,
they're getting smaller by the day.
Now don't get me wrong—despite the
inordinately long run-on sentence you just
FIGURE 1
Olde-timey IC lead spacing
waded through, I'm not advocating for the
return of through-hole components, 16-bit
multiplexed address/data buses, or discrete
ICs with tenth-of-an-inch lead spacing
(Figure 1). It's just that as I continue to ripen
into juicy, soft, senior-EE-hood, my eyes aren't
what they used to be. As any regular reader of
this space may already know, I'm somewhat
visually challenged, and ever since I can
remember I've always been forced to wear
corrective lenses to mitigate that condition.
Technically my nearsightedness is so severe
that I am legally blind in one eye. When you
can't see the big 'E' on the chart with your
right hand covering your left eye, they hand
you a cane, a tin cup, and some dark glasses
at the ophthalmologist's office and send you
on your way. Though this condition can be an
obstacle when you want to operate a motor
vehicle or play a nice set of tennis, it comes
in handy whenever I need to do an up-close
inspection of some grain-of-sand-sized SMT
component (Figure 2).
When tasked with identifying the
aforementioned sand grain, my optical
handicap suddenly becomes a super-power.
Fellow OG-EEs stare in frank admiration as I
whip off my Coke bottle lenses, bring the part
up right under my nose, and, using my uber-
myopic right eye to zoom in on the microscopic
font incised on the offending component,
read off the numbers. Of course, even 20/400
micro-vision isn't going to cut it when we
have folks like IBM creating chips with 2nm
(yes, that's 2 nanometers) transistor spacing
(Figure 3), with the capability to place 50
 circuitcellar.com 31

billion (yes, that's billion with a 'b') transistors, each about

five atoms wide, in a space roughly the size of one olde-style
555 timer chip. So, considering the trend, smaller is here to
stay.
In fact, "smaller" is a chief characteristic of the broad
category of iterative innovation itself. Looking at technology
from this perspective, several truisms become clear. One of
them is expressed by Moore's law [1], famously proposed
by (and named after) Gordon Moore, the co-founder of
Fairchild Semiconductor and Intel. Moore's "law" (though it's
more of an observation than a true physical law) holds that
computing power, as expressed in terms of semiconductor
density, doubles approximately every two years or so. It's a
special case of the nature of all technologies to decrease in
cost or rise in capability exponentially over time. This type
of inverse relationship was first expressed by aeronautical
engineer Theodore Wright, who observed in 1936 that "[the]
cost of airplanes fell as the number of planes manufactured
rose" [2]. Specifically, he observed that the cost was inversely
proportional to the number of planes manufactured raised to
some power.
This theory has since been put forward as a more general
law that governs the costs of technological products, and
is often explained on the basis that the more a particular
technology is manufactured, the better and more efficient it
gets. Technologies broadly tend to become more powerful
and capable over time, while their prices don't increase and,
indeed, often decrease. Consider, as another example, the cost computing platforms. But to refer again to Moore's law, we
of non-volatile data storage. With each successive innovation, seem to be reaching a plateau in the exponential curve. The
storage density increases, while unit cost remains nearly physical constraints of junction size, speed of electrons in the
constant. The overall trend is that per-bit cost decreases medium, and heat dissipation all seem to be at or near their
exponentially at some rate. limits. Still, as we speak, some introverted cellar dweller may
Novel inventions occur first as stepwise discontinuous be on the verge of a breakthrough that will revolutionize the
discoveries, sudden leaps forward if you will. There are long industry once more. Only time will tell.
stretches where nothing much changes, and then one fine And with that, we return to our topic of embedded board
morning a bright young engineer wakes up and invents the size with fresh eyes. As we can now see, embedded boards
wheel, or the lever, or disposable napkins, or some such thing. are the downstream beneficiaries of innovation in the Junction
The new thing is then tested in the marketplace. Surviving Density Space Race, if you will. This has allowed designers to
technologies, those that accrue a degree of market success, place whole embedded systems or subsystems within a single
provoke a flurry of duplication, with the basic invention chip, moving vast amounts of capability out to the very edge
remaining relatively unchanged, and engineering efforts go of the edge of the Internet. Below we will explore several
toward developing applications or adaptations of the original companies who are operating in this arena. There is a lot
design. Successive rounds of iterative innovation increase the going on here, and frankly, this OG-EE was astonished by
overall number of units produced, and subsequently result what he found. So, with all that said— let's get small.
in the aforementioned exponential improvement in capability
over some time frame. GETTING SMALL
Often the iterative effort to improve a basic technology can Lantronix: Put those lab goggles back on, because you're
result in a secondary invention, which, though derivative, can going to need them. First up on our teeny-tiny list is the
still be a significant advance. Hence the far greater prevalence Xpico suite of embedded Internet-of-Things (loT) products
of designs like the transistor radio, patented in 1954 by Texas
Instruments [3], than true inventions or discoveries like U.S.
Patent No. 1745175 [4], submitted in 1926 by Julius Edgar
Lilienfeld for his invention of the transistor junction itself, the
result of many years of research in semiconducting materials.
The transistor, and its subsequent refinement into a
marketable device through the efforts of William B. Shockley,
John Bardeen, and Walter H Brattain of Bell Laboratories [5],
is arguably one of the most important discoveries of the last
hundred years. It would not be an exaggeration to say that
the totality of our modern world rests upon that foundational
invention. Further, no single device since has had a more FIGURE 3
profound impact on the size, capability, and efficiency of Uber-uber-small chip tech
 CIRCUIT CELLAR • OCTOBER 2023 #399
from Lantronix [6]. One of the most powerful
market drivers of miniaturization in the last
few years has been the explosion of loT.
Consumers can't get enough low-power, high-
capability, extremely small-footprint devices.
And Lantronix is at the forefront of companies
in this space. Founded in 1989 in Irvine
California, Lantronix was initially focused on
networking peripherals— primarily network-
connected print servers. As networks moved
into small and medium-sized enterprises,
Lantronix continued to innovate, making their
devices less expensive and easier to use and
maintain—especially with the emergence of
home Wi-Fi networks in the 2000s.
FIGURE 4
Xpico versus George Washington
FIGURE 5
Xpico Wi-Fi
• FIGURE 6
NVIDIA Nano JetBot
Serving this trend, the company rose
to become one of the premier providers of
wireless and wired networking devices. loT was
a natural extension of this specialization. The
market drove its embedded devices towards
even smaller form factors. As you can see in
Figure 4, its line of wired and wireless loT
devices is incredibly small. The board you see
pictured (Figure 5) has a full TCP/IP stack,
embedded security profiles, AES 256 encryption,
two RS232 serial ports, up to 16 GPIO pins,
and an integrated 10/100 ethernet PHY. Power
consumption for this configuration in operating
mode is typically less than 250mA. For those
interested, Lantronix's eval kit package is
available as a download on Circuit Cellar's
Article Materials and Resources web page, as
well as a link to its developer kit guide [7].
NVIDIA: Another name in this space
is NVIDIA [8]. Known more broadly for its
graphics engines, NVIDIA is active in the
Artificial Intelligence (Al) sector as well. As
A l follows the loT out to the edges of the
network, the need for powerful, compact,
and power-efficient A l platforms only gets
stronger. Serving this market trend, NVIDIA
has developed the Jetson Nano, an Al-capable
embedded computing device that it says
will "[open] new worlds of loT applications,
including entry-level Network Video Recorders
(NVRs), home robots, and intelligent gateways
with full analytics capabilities." In addition
to the Jetson Nano, NVIDIA has a full line of
miniaturized A l platforms, with the entry­
level JetBot (Figure 6) aimed at the student/
hobbyist market. That said, the Nano is far
from just a toy. Leveraging Moore's and
Wright's laws, the Nano brings powerful
robotics processing power to the user at a
competitive price. See Circuit Cellar's Article
Materials and Resources web page for a video
that demonstrates how capable this platform is
[9]. And NVIDIA's hosted community platform
is chock-full of resources for everyone—from
the beginner to the A l maven [10].
Toshiba: Next on my uber-small list is
Toshiba, which has jumped headlong into
the race for the smallest Bluetooth module.
Toshiba has a long history in semiconductor
components, microprocessors, Systems-on-
Integrated-Chips (SoICs), non-volatile data
storage, and much more. Bluetooth has
become an important modality for wireless
communications in the embedded board
space. With the ubiquity of this mode of
communication has come additional constraints
on bandwidth (maximizing the efficiency of
the band), along with the need for strong
error correction, dynamic configuration, and
minimal power consumption. Enter Bluetooth
Low Energy (BLE) devices designed to meet
the requirements for low-power environments
 circuitcellar.com

(think: earbuds), and the race was on to make FIGURE 7

the smallest BLE with the lowest possible World's Smallest BLE Device

power consumption profile. Toshiba SASP

BLE (Figure 7) is the current record holder
[11]. Based on its partnership with Nordic
Semiconductor, Toshiba has developed the
world's smallest BLE device using Nordic's
nRF52811 System-on-Chip (SoC), in a 4mm x
100mm integrated package (that includes the
antenna). The device incorporates a 64Mhz
Arm Cortex M4, with PDM, PWM, SPI, UART and
TWI interfaces. Add in a fast 12-bit ADC, and it
still weighs in at an amazing 0.09g, using less
than 5mA peak current in Odbm Tx mode.
Nordic Semiconductor: Speaking of Nordic
[12], its BLE chip is not the only offering it has
in the super-super-small embedded board
marketplace. The company also manufactures
the nPM6001 Power Management IC (PMIC)
(Figure 8), built to give designers fine control
of six independent rails/power domains. Each FIGURE 8

domain can be independently regulated, Nordic Semiconductor PMIC

powered down, and woken up as needed. The

package, measuring a mere 2.2mm x 3.6 mm,
has selectable voltage outputs from 0.5VDC to
3.3Vd c , with four highly efficient step-down
buck regulators. Additionally, two low dropout
(LDO) regulators can supply up to 15mA fixed
at 1.8Vd c or selectable between 1.8VDC and
3.3Vd c at 30mA. The typical quiescent current
draw for this part is only 1.2pA. The PMIC also
has an ultra-low power mode that it can enter
based on a programmable WDT expiration
time. In this mode, consumption drops to an
astonishing 300nA.

IS IT IN YET?
All the above components, and many
others besides those mentioned, are just
the tip of the iceberg, so to speak. There
are many other companies leveraging these
minuscule components to give developers the
most flexible, and ultimately the smallest,
embedded platforms.
Espressif Systems: In that vein, we have
companies like Espressif Systems, with its
ESP32 line of embedded boards. The ESP32-
PICO [13] is one of a series of embedded
development platforms, designed with
the prototype builder in mind, that allows
a developer the freedom to design their
embedded application with confidence in the
tools and environment. The ESP supports
Wi-Fi, Bluetooth, and UART interfaces, has a
full USB interface for programming, and is
supported by multiple flavors of Linux and
other embedded OS like FreeRTOS. As you
can see in Figure 9, the board has an efficient
layout with lots of I/O and on-board memory.
Multiple frameworks are supported, including
Google loT Core, AWS loT, and Aliyun, to FIGURE 9
name a few. Espressif also provides its own ESP PICO development board
CIRCUIT CELLAR • OCTOBER 2023 #399

native frameworks for Wi-Fi mesh networking, DSP, audio

EasyAVR PRO v8 board processing, and facial recognition.
MIKROE: Another great option for the embedded
programmer is the EasyAVR PRO 8 from MIKROE [14]. MIKROE
is a development tools provider, and its EasyAVR PRO supports
a large variety of microcontrollers, PICs, embedded displays,
and I/O devices. It comes as part of its Wi-Fi-capable software
development kit (SDK) (Figure 10) that enables your chosen
embedded platform to be flashed and debugged over the air
(OTA) on your in-house wireless network.
Founded in 2001, MIKROE specializes in making the tools
and development environments that embedded designers
need to be efficient and productive. It's always pushing
the envelope, supporting the most popular and efficient
embedded controllers, and is a partner that can take your
project from initial concept to final production design, so you
can miniaturize and move to a fully independent device in a
shorter period of time.
Arduino: No discussion of embedded boards would be
complete without a paragraph on Arduino [15]. Now, hold
on—I can already see you purists rolling your eyes. But
FIGURE 10
despite the Arduino sketch development environment's bad
MIKROE EasyAVR rap, and that Arduino devices have been hit-or-miss when it
comes to quality and support, overall, the platform has made
a significant inroad into the engineering prototype space,
crossing over from hobbyist into homegrown lab equipment,
controllers of various sorts, Proof of Concept (POC) boards,
and laboratory curiosities of all types. The nice part about
this platform is the price. Following our friends Moore and
Wright, the Nano (Figure 11) can be purchased directly from
Arduino for as little as $30. That, plus their free development
environment, can get your project jumpstarted in short order.
Raspberry Pi: And, of course, we must mention the
Raspberry Pis. Famously taking the embedded Linux world by
storm, the original Raspberry Pi was a revolutionary device: a
cheap, powerful, all-in-one embedded development platform
that bridged the gap from microcomputer-based Linux to
the embedded space. It brought the competition to other
embedded operating system providers of the day, like Wind
River Systems' VxWorks.
The Raspberry Pi Pico [16] is the latest generation, an
inexpensive (as low as $4) device that incorporates a host of
major-league capabilities. The RP2040 features a dual-core
Arm Cortex-M0+ processor, 264kB internal RAM, and support
for up to 16MB of off-chip flash. I/O options include I2 C, SPI,
and configurable numbers of programmable I/O (GPIO) pins.
FIGURE 11
Raspberry Pi supports the developer with a robust IDE, and
A rduino Nano
there are many off-the-shelf Linux kernel builds that can
be loaded onto the platform. Despite their low price point,

Additional materials from the author are available at: www.circuitcellar.com/article-materials

References [1] to [18] as marked in the article can be found there.

Resources
Adafruit | www.adafruit.com Nordic Semiconductor | www.nordicsemi.com

Arduino | www.arduino.ee NVIDIA | www.nvidia.com

Espressif Systems | www.espressif.com Raspberry Pi | www.raspberrypi.org

Lantronix | www.lantronix.com Toshiba | www.toshiba.com

MIKROE | www.mikroe.com
 circuitcellar.com 35

knockoffs abound— hence the Fruit Pi spectrum

of compatible boards to choose from.
Raspberry Pi and Arduino are direct
competitors in the embedded board space
(Figure 12), each trying to outperform the
other on price and feature sets. The winner
here is the developer, as the competition for
the smallest, most powerful, and cheapest
embedded platform rages on.
A d afru it: Last, but far from least, we
have Adafruit [17], with its Feather line of
embedded boards. Adafruit is one of the more
solid providers of embedded technology, with a
reputation for well-tested, stable components,
cleanly integrated embedded peripherals, and
robust development platforms. The Feather FIGURE 12
is no exception. As Figure 13 shows, they Raspberry PI versus Arduino
offer a highly customizable array of Feathers.
Each one has a similar core functionality but
is outfitted with specific peripherals and I/O
suites to meet a range of designer needs.
The microprocessor cores on the Feather are
largely from the Arduino family. But Adafruit's
dedication to quality and tested reliability
sets them apart from other offerings.
A good resource for more information on
tiny embedded boards is RS DesignSpark [18].
There are lots of articles written by people in
the industry, with links to original content in
the articles. Well worth signing up (it's free).

THE FINE PRINT

Whew! I don't know about you, but for this
OG-EE that was a lot of squinting. Time to drag
those lab-googles off your face, rub your
burning eyes, and take a break. After all, it's
October, pumpkin spice is everywhere, and the
lab is starting to look even scarier than usual.
Stand up, take a couple of deep breaths and a
stretch, get a cup of something hot, put on your
shabby jacket, and go out into the crisp
sunshine. Focus your eyes on something bigger,
like the big blue sky or the changing leaves, and
forget about how many millions of MOSFETs can
dance on the head of a silicon pin. The work will
always be there, and you'll be the better for the
rest. In fact, I think I'm going to take my own
advice, and leaf this (see what I did there?) right FIGURE 13
here. Until next month. Adafruit Feather configurations

A B O U T THE AUTHOR

M ichael Lynes is an entrepreneur who has founded several startup ventures. He w as aw arded a BSEE
degree in Electrical Engineering from Stevens Institute of Technology and currently works as an embedded
software engineer. When not occupied with arcane engineering projects, he spends his tim e playing with his
three grandchildren, baking bread, w orking on ancient cars, backyard birdw atching, and taking am ateu r
photographs. He's also a prolific author with over th irty works in print. His latest series is the Cozy Crystal
Mysteries. Book one, M oonstones a n d M urder, is already in print, and book two is on its way. His latest
w orks include several collections of ghost stories, short w orks of general fiction, a collection called Angel
1
Stories, and another collection called Novem ber Tales, inspired by the fiction of Ray Bradbury. He currently lives w ith his wife
Margaret in the beautiful, secluded hills of Sussex County, New Jersey. You can contact him via em ail at m ikelyn es@ gm ail.com .
 DATASHEET

N E S B n e M C
IR
E d a y n i n i C
U
X m a c
M Da
I
it e T
T o b r
o C
r- W le E
M n i re -e LL
A
d
E tsa
O -C a c R
e le •
N h
ll
a n h c O
C
M eh
T ie c t it t T
O
H f e o h ro B
E
S' , e R
ff 2
0
-m
rt
S te:
T e 2
o 3
O ri e #
u c S 3
P n 9
n h 9
IC a u A la b tr m b lo lo e o p tr M g a
se
l e u y
sc
x f o a
co s s
:
D
va
t,s
s,
a
n
so
n
te M
e
r
g
e
r
le
e
v
e ic
ro
e e
d co
w
-
b
a
la p
w
o m
tr
e re
p
u
la
M
E
n
sf
o
E
M
S
n
u
m
l
T in e
e
n
n
ic
e
C a rs ch a "s
e l w e a M , a n
- b ly n n sc ra y le isg ts e s ri S rm se th , l
D to o w a g st n in r ly o ty w te S m h h
ro ze
lo h le e e trc o f n n e ta e
so
is i
C a g d m o h t r m co se s. fo y so ' ch
y m s i s
d it a g ile
.s n n n
te o ve n
ch e m g te
C e y , e a r ch u r o
in a a h c
o r to th to s.
"
ic y m n su si P r g n o r
o
e h s, a u m ti se n n p cu lo i o n e y l h
n n m r a lik a A a c v ri n o e ro g f th n
v e s e n p n
ss fa
p e m lo x d
ra
y a
ca
, n
tw a d
ch
d . a
si
n g t te t l th a n i o
e ke a a ie ro -p
u
ct ti
o T g y u is e w
o re
n v d b h p d . lo
rs
rt d
ta v y e o u e ro ri n e
irly
a r
ct e th sy e te
e
rk o f d n . , o s a e la ' g
e f lu d ci u g A y p co je ss tse re g y
o ro e e co n
re
— n a p n h t se e m
te r
rs f ics m ti m g a ce
d ls M ct l n e a
io o b si u d d w o E
ilc ti . a e ti fo
s
st
x
S in
n n e g o h M a n t a re h
e te iz d n sre u
ily
d E h M ti u ct
l in
ci te
a
n ,s
th e d s , ic M a S o e o c io fr (M te d
d lli e d e
tc in e h n s n to o d s
g a d n o v S ve
s u m n E m
re e n w o th m e t ic m ld o t M d
la n d o h t e g e te a se fo to f a S ic to e r
t o p ir e e c n n n n ) e
e ce
lrd w te
o s ra s. a h e s r p y o ro b s
d co ch n s o a g o in f v
p sy n w n
ss si th te F s is p te e se -e ri
n
ig
o
r n a e o ze a d u a h e
rs v ro
n n
so
n le g n
o st e ro ib
t a w e lu se lu
d e u lo le w trh v ig ci r w n so ct
u m
ct
n u g a c a it e e h a a ie ita ito s ro yo s t
tc s to d se a n re h ry ly lly re yt i
n lly e n o rs
u o io
a
y,
t r, r r . - lu
n .s n
n i
o In ti z
u in o t to o m o h in a te th b im o m d e a m to o e
n f in f r n
sh
e
lim th e x n n
ce sp fe i d M u ig te d ch a i
p e a
f-
T e is a
d d
m e a lt e h W n n g h d it T isve rk e s
ir ri E ip n rf w , k s ic l
e h lo ti
n e n .
e a n st y.
M v
-p h a s a u in in a e st
t a s
n ti g N S le ir re e e th n e g l p g a b W
ts o o th icn a e i
n d
se . s a
ss, e n rt le e
n
s. (
p e ty n ci
e g d a r o e n
to u
se
p m
ra
ri p e A p p a ic -u p n
in
ce
n e
si
o r w b a v e s p fr
o p lr h p p e s
e N n s e n el u e x II(
m e e o w ro o
d e sa so s n it rt n te a o lic lci a o
s,
it th v r o t a p h ,s se n T a a d u
rt u
o n p a
rs
e e in ri f a re
m
to sp
— ) ti e y n
s
so n
r@ rt t ly o s l cc
s o a si e o n
ti
o ti
o
fo h e , p e e o p h c v x v n n o n
it
w
lu d
ci e n t n se le su e a th
e e a ir te s n ie ti a
rc ll
o d th io s n r ti
o n s e ly m ,s s e
s o u n
u w
le e n o ro e n in e p
tu rt th ll n
it is s si m . g s sh x in le a to a e
fo
a p d
in )
s,s d rs n p p ll n i fo r s
fo s.
ce
g co a , g e re ri lo a : y th m r m th r T
lla v te se u a n r u a e a a h
g lu a th
u n p k a a e e n e
r. a I sl m l
ia e n d in to cc
n in n M rk e x
is
co vi s,r so a
ti
o m e E e m o
m
lle n b re it
s g n y d t,
M is
v m
h re
o le 's th rs
w to
. o le w u tp b e
ti e
yr p r e , h b h tr S la e r n a
. e o e a th r isz M ro
e tsr a c d a g n
p to
h a m g o sm e o lie m r n e d b s
f re d u t a le r e e ia e u
s g y a o e ,s l sp se
to d n n
y a
o e e l ro w f te y o n d
co
u
u v v e in rt
s e r ro o
In s d a m
a n e w te
se sc o p e b rs
u
rt o a sy
n p m
ts lo g n o h n
ce
o
te a y. a e
ila p e so p lrd o n h rn ti sr st
e ce
n
fi b e a ra e n si ti a c e o m i
ro
n l th lt t rs o e n tl cs v a n u
d e e rs h e , s,
f s g y, , e n t- , is s o se
f s
 circuitcellar.com 37

Ultralow Power 3-Axis Ultra-Low Power Smart Hyper-Accurate Pressure Sensor

Accelerometer Sensor System The ICP-10125 pressure sensor
provides ultra-low noise at the
The ADXL367 is an ultralow power, The BHI380 is a highly integrated, lowest power, enabling industry­
3-axis microelectromechanical systems ultra-low power, customizable smart leading relative accuracy, sensor
(MEMS) accelerometer that consumes sensor system consisting of a best- throughput, and temperature stability.
only 0.89pA at a 100Hz output data rate in-class 6-axis IMU, a programmable The pressure sensor can measure
and 180nA when in motion-triggered 32-bit microcontroller (Fuser2 Core), pressure differences with an accuracy D
wake-up mode. Unlike accelerometers a second ultra-low power MCU, with a of ±lPa, an accuracy enabling altitude A
T
A
that use power duty cycling to power software framework containing measurement differentials as small as S
H
achieve low power consumption, the pre-installed sensor fusion and other 8.5cm, less than the height of a single E
E
ADXL367 does not alias input signals sensor data processing software stair step. Consuming only 1.3pA @ T
by undersampling, but samples the within a 2.5mm x 3mm LGA package, 1Hz, the device is available in a small
full bandwidth of the sensor at all data pin-to-pin backward compatible with footprint 3.55mm x 3.55mm x 1.45mm
rates. The ADXL367 always provides 14- Bosch Sensortec IMUs. The BHI380 chimney package with waterproofing
bit output resolution. 8-bit formatted is a variant from the BHI3xx family gel providing IPx8 waterproofing to 10
data is offered for more efficient single­ featuring a larger set of integrated ATM. The ICP-10125 is ideally suited
byte transfers when a lower resolution application-specific algorithms. for wearable fitness monitoring and
is sufficient. 12-bit formatted data battery-powered loT.
is also provided for ADXL362 design • 1.8V operating voltage
compatibility. Measurement ranges of • Fuser2 (running CoreMark) has a • Pressure operating range: 30 to
±2g, ±4g, and ±8g are available, with current consumption of 950pA in long HOkPa
a resolution of 0.25mg/LSB on the ±2g run mode (20MHz), and 2.8mA in • Noise and current consumption: 0.4Pa
range. "turbo mode" (50MHz) @ 10.4pA (ULN mode); 0.8Pa @ 5.2pA
• Sensor fusion operation is 1.2mA @ (LN mode); 3.2Pa @ 1.3pA (LP mode)
• Supply voltage range: single-cell 800Hz ODR, and 1.0mA @ 100Hz ODR • Pressure Sensor Relative Accuracy:
battery operation—1.IV to 3.6V; • Standby current of 8pA ±lPa for any lOhPa change over
internal power supply regulation for • Static accuracy (head., pitch, roll): 2, 950hPa-1050hPa at 25°C
high PSRR 2, 2 degrees • Pressure Sensor Absolute Accuracy:
• Ultralow power • Dynamic accuracy (head., pitch, roll): ±lhPa over 950hPa-1050hPa, 0°C to
• High resolution: 0.25mg/LSB 7, 2, 2 degrees 65°C
• Built-in features for system level • Calibration time: <1 second • Pressure Sensor Temperature
power savings • Orientation stabilization time: 0.2 Coefficient Offset: ±0.5Pa/°C over
• Low noise to 170pg/VHz seconds 25°C to 45°C at lOOkPa
• Acceleration sample synchronization • Temperature Sensor Absolute
Bosch Sensortec
via external trigger Accuracy: ±0.4°C
www.bosch-sensortec.com
• On-chip temperature sensor • IPx8: Waterproof to 10 ATM
• Internal two-pole anti-alias filter • Temperature operating range: -40°C
• SPI (4-wire) and I2 C digital interfaces to 85°C
• Host Interface: I2C at up to 400kHz
Analog Devices
• Single Supply voltage: 1.8V ±5%
www.analog.com
• RoHS and Green compliant
InvenSense (TDK)
invensense.tdk.com

DATASHEET URLS:

Analog Devices ADXL354/ADXL355: https://www.analog.com/media/en/technical-documentation/data-sheets/adxl367.pdf

BOSCH BH1380: https://www.bosch-sensortec.com/media/boschsensortec/downloads/product_flyer/bst-bhi380-fl000.pdf

Invensense ICP-10125: https://invensense.tdk.eom/wp-content/uploads/2021/04/DS-000329-ICP-10125-vl.l.pdf

38 CIRCUIT CELLAR • OCTOBER 2023 #399

Datasheet:
MEMS Sensors

Accelerometer with On- Combined Gyroscope and Super-Sensitive Infrared

Chip Mixed-Mode Signal
Processing
The MXD6235Q is a low-noise,
low-profile, dual-axis accelerometer
T
E fabricated on a standard CMOS process.
E
H It is a complete sensing system with
S
A on-chip mixed-mode signal processing.
T
A
D The MXD6235Q measures acceleration
with a full-scale range of ±lg and a
sensitivity of 12.5%/g at 3V at 25°C. It
can measure both dynamic acceleration
(e.g., vibration) and static acceleration
(e.g., gravity). The MXD6235Q design
is based on heat convection and
requires no solid-proof mass. This
eliminates stiction and particle issues
normally found with capacitive-based
technology, and significantly lowers
field failure rate and in-line loss due to
handling during assembly.
• Ultra Low Noise 0.13 mg/VHz typical
• RoHS compliant
• Ultra Low Offset Drift 0.1mg/°C
typical
• Resolution better than Img
• Monolithic CMOS IC
• On-chip mixed signal processing
50,000g shock survival rating
• Low profile LCC package
• 2.7V to 3.6V single supply
• No adjustment needed outside
MEMSIC Semiconductor Co., Ltd.
www.memsic.com
Accelerometer Family
Murata has developed a new MEMS
combined gyroscope and accelerometer
sensor family, which has best-in-
class offset and linearity stability
performance over its lifetime and
temperature. The new SCC400T series
enables implementation of a 6DoF
sensor solution on one application PCB
by combining 5DoF and IDoF sensors.
The SCC400T series provides two
parallel acceleration and turning rate
outputs with independent filter controls
via digital SPI communication interface.
Gyroscope measurement range is
±300% for both parallel outputs and
accelerometer measurement range is
±6g for normal and ±8g for secondary
output. The sensor family offers
excellent offset stability (offset drift
over lifetime < 0.9%, < 25mg) and
noise performance.
• New architecture enabling low noise
for gyro and accelerometer
• Excellent linearity and offset stability
over temperature
• Single package up to 5DOF High
Performance Combined Gyro Sensor
and Accelerometer
• Extensive self-diagnostics
• Proven reliable Murata 3D MEMS
design
• Secondary gyro output with
independent low pass filter control
• RoHS compliant robust SOIC plastic
package suitable for lead free
soldering process and SMD mounting
Murata
www.murata.com
Thermal Sensor Series
Omron Electronics D6T Series MEMS
Thermal Sensors are super-sensitive
infrared temperature sensors that
make full use of Omron's proprietary
MEMS sensing technology. Unlike
typical pyroelectric human presence
sensors that rely on motion detection,
the D6T thermal sensor is able to detect
the presence of stationary humans by
detecting body heat, and can therefore
be used to automatically switch off
unnecessary lighting, air conditioning,
etc. when people are not present. As
the D6T sensor is also able to monitor
the temperature of a room, it can
also be used to continually maintain
optimal room temperature levels,
instantly sense unusual changes in
temperature thereby detecting factory
line stoppages, or discover areas of
overheating for early prevention of fire
outbreaks.
• Achieves world's highest level of SNR
• Accurate temperature measurements
with little impact from outside
• Superior noise immunity with a digital
output
• High-precision area temperature
detection with low crosstalk field-of-
view characteristics
• RoHS compliant
• Compact size for space savings and
embedded applications
• Converts sensor signals to digital
temperature output, allowing easy use
of microcontroller
Omron
www.omron.com/global/en

DATASHEET URLS:

MEMSIC MXD6235Q: https://www.memsic.com/Public/Uploads/uploadfile/files/20220119/MXD6235QRev.pdf

Murata SCC400T Series: https://www.murata.com/-/media/webrenewal/products/sensor/pdf/datasheet/datasheet-scc400t-series-short.ashx?la=en-us&cvid=20220610055733000000

Omron D6T Series: https://www.mouser.eom/datasheet/2/307/en_D6T_catalog-1633759.pdf


Easy-to-Implement Gas
Sensor Module
The ZMOD4410 Gas Sensor Module
is designed for easy implementation
to detect total volatile organic
compounds (TVOC), estimate C02 ,
and monitor indoor air quality (IAQ).
The module works reliably in various
conditions, including very humid and
dusty applications with the possibility
of water spray, condensation, or
immersion. The small LGA assembly
consists of a gas sense element and a
CMOS signal conditioning IC. The sense
element is a Si-based microhotplate
with a robust and highly sensitive
metal oxide (MOx) chemiresistor. The
signal conditioner (ASIC) controls the
sensor temperatures and measures
the MOx conductivity, which is a
function of the gas concentration. The
measurement results are easily read
via an PC interface with the user's
microprocessor, which processes the
data.
• Sensor output based on A l machine
learning algorithmic
• High sensitivity to hydrogen based on
resistance output
• Heater driver and regulation loop for
constant resistance, minimizing effect
of environmental temperature on
signal
• Built-in NVM for module-specific data
(configuration and calibration)
• Ultra-low average power consumption
down to 160 pW
Renesas
www.renesas.com
DATASHEET URLS:
Renesas ZMOD4410: https://www.renesas.com/us/en/document/dst/zmod4410-datasheet
SiTime SiT95145: https://www.sitime.com/support/resource-library/datasheets/sit95145-datasheet
STMicroelectronics LIS2DUX12: https://www.st.com/resource/en/datasheet/lis2duxl2.pdf
Single-Chip MEMS Clock Jitter
Cleaner
The Cascade ClkSoC SiT95145 is a
single-chip MEMS clock jitter cleaner
optimized for the highest level of
clock tree integration, consolidating
multiple clock ICs and oscillators into
a single device. Its low-noise quad-PLL
architecture and programmable output
drivers can deliver up to 10 differential
or 20 LVCMOS low-jitter clock outputs.
This ClkSoC supports four additional
clock inputs with fracN dividers,
enabling virtually any input to output
frequency translation configurations
from 8kHz to 2.1GHz.
• Quad fractional-N PLLs with
integrated VCO and loop filter, 120fs
typical RMS integrated phase jitter
• Wide output frequency support:
Differential outputs from 8kHz to
2.1GHz; LVCMOS outputs from 8kHz
to 250MHz; Supports 1Hz to 2.1GHz
output frequency on one output
• Wide input frequency support:
Differential input from 8kHz to
750MHz; LVCMOS input from 8kHz to
250MHz
• Individually configurable output
formats and VDD supply: LVPECL,
CML, HCSL, LVDS or LVCMOS; 1.8V,
2.5V or 3.3V
• Flexible input to output frequency
translation with jitter attenuation,
four inputs, 10 outputs
• Programmable jitter attenuation
bandwidth for each PLL: ImHz to
4kHz
SiTime
www.sitime.com
circuitcellar.com 39
Smart Digital Linear
Accelerometer
The LIS2DUX12 is a smart, digital,
3-axis linear accelerometer whose
MEMS and ASIC have been expressly D
designed to combine the lowest current A
T
A
consumption possible with features such S
H
as always-on anti-aliasing filtering, a E
E
finite state machine (FSM) and machine T
learning core (MLC) with adaptive self­
configuration (ASC). The FSM and MLC
with ASC deliver outstanding always-
on, edge processing capabilities to
the LIS2DUX12. The LIS2DUX12 MIPI
I3C slave interface and embedded
128-level FIFO buffer complete a set of
features that make this accelerometer
a reference in terms of system
integration from a standpoint of the
bill of materials, processing, or power
consumption.
• Supply voltage range from 1.62V to
3.6V
• Four operating power modes
• Ultralow power consumption
• Low noise down to 220 pg/VHz
• ±2g/±4g/±8g/±16g programmable
full-scale
• ODR from 1.6Hz to 800Hz
• Embedded machine learning core
• Programmable finite state machine
• Adaptive self-configuration (ASC)
based on the sensor processing
output (FSM / MLC)
• Embedded temperature sensor
STMicroelectronics
www.st.com
It has been said that there is no such thing as an accident, and that most
mishaps and disasters actually are predictable and preventable. Technology is
only as good as its design—which should incorporate forethought about what
could go wrong. In this article, Stuart looks at how lessons from past technology
failures from faulty indicators and designs—including one he experienced
firsthand—can prevent future problems and disasters.

n 1973, there was a movie called waypoint (a geographical position with specific

I
Westworld, about a robotic amusement
park. The movie trailer said, "Nothing
can possibly go wrong. Go wrong. Go
wrong..." Of course, the entire movie
about things going murderously wrong.
My article will be unusual, in that there are
no schematics, and there is no code on the
Circuit Cellar website. It is about what happens
when technology goes wrong, and how we
can prevent or deal with such situations in
our designs. I'll start with a short version of
my own potentially deadly experience with
technology that went wrong.
MY ACCIDENTAL CAMPING TRIP
I live in Colorado. In March of 2015,1 went
snowshoeing at an area called Brainard Lake,
which is at about 10,000 feet altitude. I had
planned to go to a different area early in the
day, but it was inaccessible due to snow. So I
went to Brainard in the afternoon. I set a GPS
latitude and longitude coordinates), where I
parked the car.
I had not been to Brainard before, so I was
wasplanning a short familiarization hike, maybe
an hour or so. The only other people I saw
all afternoon were some cross-country skiers,
and they were long gone by the time I got my
snowshoes on. I've never had a good sense
of direction, so when I decided I'd gone far
enough, I wasn't sure of the direction to the
car. I should have backtracked on the trail
and returned that way. But it was late, so I
decided to bushwhack to the car in a straight
line using the GPS. But the GPS waypoint was
bad, and it led me in the wrong direction.
By the time I reached the waypoint and
realized I was lost, the shadows were getting
long, it was getting cold, and I had put back
on the layers of clothing I had taken off. I
considered hiking back, but the area I'd hiked
was all trees and deep snow—difficult terrain,

and no place to stop if I ran out of daylight.
The place where I ended up had a tree with
dry ground, surrounded by elk droppings.
Presumably some elk had recently spent the
night there and melted the snow. I decided it
was safest to stay there.
It was nearly dark, and I spent the little
time I had tearing down pine branches for
insulation and collecting firewood. It got very
dark—trees were just vague shapes. I built a
fire but didn't have enough wood to keep it
burning through the night. (If you've never
done it, you'd be surprised how much wood
that takes.) Figure 1 is a picture of the fire
as I was getting it started, you can see my
water bottle packed with snow for melting.
My gloves were wet, so I took them off. They
froze solid overnight.
I didn't have cell phone signal, and I
couldn't even send a text message. (Safety
tip: a text only needs a brief connection to
transm it, and will often be sent even if the
connection isn't stable enough for a voice
call.) I decided that since I was well away from
where I should have been, searchers might
not look there for a while (later confirmed
by one of the rescue searchers). So, despite
the usual advice to stay put, I decided to
follow my tracks back in the morning. If
snow covered my tracks during the night, I'd
follow the bad GPS heading backward until I
intersected the trail, and as a last resort, I'd
follow my compass.
I started back about a half hour before
daybreak with my headlamp. By the time I
reached the more difficult terrain, there was
enough sunlight to see. Searchers had a
helicopter looking for me. I could see them,
but they couldn't see me, because I was in a
wooded area.
I eventually encountered one of the dog
search teams and we returned to the trailhead.
One of the rescuers said they had done rescue
searches in conditions less severe than mine
and the outcome wasn't good. The sheriff's
report said I became disoriented, found a dry
place to spend the night, constructed a shelter,
and built a fire. "Shelter" is a bit of a stretch;
it sounds like I built a log cabin or something.
I know what I did that got me lost. I
started out late, leaving me no time to recover
if something went wrong, I got off-trail in an
unfam iliar area, and I followed the GPS into
difficult terrain. One of the rescue searchers,
who was on cross-country skis, said she was
impressed with some of the terrain I covered;
I told my wife later that I had no intention of
covering any terrain that would impress those
people.
I admit that I had made some bad decisions.
But if the GPS waypoint had been correct, none
of my bad decisions would have mattered,
circuitcellar.com
because it would have taken me right back to
my car. That GPS model isn't supposed to set
a waypoint if it doesn't have a good fix on the
GPS satellites. But this one time, it did, without
reporting any error or warning.
I worked on GPS development back when
it was an all-Department-of-Defense (DoD)
program, so I have some knowledge of how
it works. The GPS system is very reliable;
what it does is technically complicated,
but conceptually very simple. But the GPS
receivers we use are not always as reliable.
I contacted the m anufacturer to see if there
was a firm ware update for my unit, but never
received a response.
In my case, the GPS didn't tell me (or
didn't know) that the waypoint was bad.
Fortunately, even with my mistakes and the
faulty GPS indication, it ended well enough.
But there was another situation where a
faulty indicator caused a nuclear meltdown.
SENSOR FAILURE: REACTOR
MELTDOWN AT THREE MILE
ISLAND
The Three Mile Island (TMI) nuclear reactor
was completed in 1978. In 1979 it suffered a
partial meltdown of one reactor (Figure 2).
The Nuclear Regulatory Agency identified
several causes of the incident, including
inadequate operator training and incorrect
procedures. There are a number of articles
about TMI, including one on Wikipedia [1]. I
won't go into all the details; rather, I want to
look at one small piece of the problem. One
thing stood out to me, that, like my wayward
GPS, could have mitigated the entire scenario.
In the TMI reactor, a relief valve was stuck
open. However, the valve had a light indicating
that it was closed. But the light actually
FIGURE 2
Newsmen and spectators stand in front of the main gate of the Three Mile Island Nuclear Generating
Station in Middletown, Penn., April 2, 1979.(Photo Credit Jack Kanthal/The Associated Press)
CIRCUIT CELLAR • OCTOBER 2023 #399
indicated only whether power was applied
to the solenoid that controlled the valve, not
the actual valve position. The operators took
several actions in the first few hours of the
accident, based on their assumption that the
valve was closed. Those actions made the
problem worse, and likely turned an orderly
shutdown into a disaster.
I'm not a nuclear engineer, and the plant
was built in 1978, without a lot of our modern
technology, so maybe it wasn't feasible to
detect the actual valve position. But like my GPS
that was sending me the wrong way without
warning, there was no way for the operators
to know that the valve was actually stuck open.
Like my accidental camping trip, a lot of
things went wrong at Three Mile Island—
mostly bad decisions—but the effect was
multiplied by the bad information about
the position of that one valve. After reading
articles about that incident, it appears to me
that if the valve light had reported the actual
position of the valve, the operators would have
taken the correct actions instead of the wrong
ones. There would still have been a reactor
accident and a shutdown, but probably not a
partial meltdown.
Failure o f Sensors in Embedded Systems:
In an embedded system, a small thing can
sometimes lead to big issues. The Boeing 737
MAX experienced two fatal crashes, because
a sensor sent faulty information to the flight
control system, indicating that the plane's nose
was too high. In the two crashes, 346 people
died. The plane was taken out of production
until the problem was solved, and the entire
incident cost Boeing billions of dollars.
How could such failures be prevented? In
designing an embedded system, ask yourself
what happens if a sensor goes bad. Can you
detect it? Depending on the design, an open
or shorted sensor might be easy to detect.
But a faulty sensor might not. Do you have a
way to detect that a sensor is sending bad or
noisy data? Can you detect an out-of-range
condition? And if you can't detect it, what is
the worst that can happen?
Answering that last question may require a
detailed analysis, or even simulating a faulty part.
I used to keep a flakey cable in my desk just for
that kind of testing. You may not be working on
anything that can cause deaths, but something
like an industrial robot can do a lot of damage if
things go really wrong. Even something like the
temperature control in a soldering iron can do
damage if it runs wide open.
It's easy to fall into the trap of designing
things to work when nothing is broken, but
how badly can things go sideways if a sensor
or something else breaks? Will the system
catch fire if an essential cooling fan fails? If
so, you should probably have both a fan speed
monitor and a temperature sensor. What if you
have a stepper motor or solenoid, like Three
Mile Island, that your software controls but
has no way to check? How bad can things get
if the solenoid coil burns open or the solenoid
gets stuck and can't move? Can two parts
smash into each other if the stepper position
isn't where the m icrocontroller (MCU) tried to
send it? Can a cascade failure occur like the
one that happened at Three Mile Island? If
your stepper can actually break something, it
probably needs an encoder to verify position.
Do you need a way to verify that a solenoid
is in the right position or that a heater is on
when it should be—or off when it shouldn't?
Ideally, sensors should be designed so that
they never saturate in normal operation. For
example, in a piece of equipment designed
to operate up to 50°C, and using an 8-bit
analog-to-digital converter (ADC) to measure
the temperature, don't make OxFF equivalent
to 50°C. Instead, scale the ADC input so
OxFF is the value for, say, 70°C. That way,
if you ever see OxFF, you know two things:
the temperature is way out of range, and
the sensor reading can't be trusted because
it's saturated. It might be 70°C or it might
be 150°C; you just don't know. But you know
something needs to be done, whether it's
a system shutdown or notifying a human
operator. And if that temperature sensor ever
does read OxFF, don't display 70°C for the
operator, display "Overtem p" or something
similar. Because, again, you can't know the
actual value of a saturated sensor.
If using a pressure sensor, can you detect
an overpressure failure? And what can break
if the pressure can't be measured?
In some cases, where there are potential
safety issues or equipment damage, a
redundant sensor is a good solution. Yes, that
adds cost, but the cost of a single field failure
may exceed the additional product cost many
times over.
Think of the Boeing 737 MAX as an
example. The plane actually had a redundant
sensor, but didn't use it. I don't know the
technical challenges involved in integrating
the second sensor, and there was reportedly
a desire to minimize the need for additional
pilot training for the new version, but it's
hard to imagine that the cost would exceed
the human and monetary cost of those two
crashes. Even if you can't tell which sensor is
working, getting wildly different results from
redundant sensors is a signal that something
is wrong and human intervention is needed.
A lot of industries use some version of
failure mode effects analysis (FMEA) [2],
which attem pts to determine what happens
when things fail, and the potential severity of
the failure. Even with systems that are not

safety-related, thinking about these situations
and handling them in your design will make it
more robust. A reputation for poor reliability
may not kill anyone, but it can kill a company.
FAULTY SOFTWARE AND
DESIGN: RADIATION THERAPY
OVERDOSING BY THERAC-25
The Therac-25 was a radiation therapy
machine used for treating cancer. Produced
in 1982, it was controlled by a PDP-11
minicomputer. The Therac-25 had two modes
of operation, one where a low-power beam
was used to target a specific location on the
body, and another mode where a much higher
power was used with an attenuator to produce
attenuated x-rays; (I'm sim plifying this a lot).
Over the course of 2 years, the Therac-25
was involved in at least six incidents involving
overdosing patients with excessive radiation,
causing at least three deaths. There are
numerous articles about the Therac-25, both
on the Internet and in print publications, so
I won't rehash the details here. They are
summarized in a Wikipedia article [3].
In the Therac-25, the operator would select
the treatm ent mode, and the PDP-11 would
set the beam power and rotate a turntable to
put the attenuator between the em itter and
the patient. The problem occurred when an
operator would start the setup for one mode,
then switch to the other mode. The machine
took several seconds to set up the hardware,
and the computer would leave the machine
partially configured when the mode was
switched in mid-setup. The high-power beam
would then be applied to the patient without
the attenuator, causing severe radiation burns.
Numerous faults were found in the
software and in the design process. I want to
look at just two of the design flaws and their
applicability to our embedded systems.
Problem 1—Software Design and
Operator Error: When asked why it's hard to
design a bear-proof garbage can, a Yosemite
park ranger supposedly said that there is
considerable overlap in intelligence between
the sm artest bears and the dumbest tourist.
It's not that bears are sm arter than people,
but if someone can use a bear-proof garbage
can incorrectly, someone eventually will.
The Therac-25 engineers attempted to
reproduce the failure. But the problem was
actually caused by quick operators combined
with bad software. Operators of equipment like
that use it all day, every day, and they have a
lot of opportunity to get very fast at routine
operations. What happens to your system
if the operator performs some unexpected
operation? Does it recover or is it in a bad state?
The Therac-25 race condition was caused by a
fast operator. But it wasn't that the computer
circuitcellar.com 43
was too slow, it was that the machine setup,
being motor driven, took seconds to complete.
The software design assumed the setup would
be complete before the operator could change
modes. It was a genuine race condition but the
error window was several seconds wide.
In your system, it might not be a human
operator; it could be an input from some
external device, such as a speed sensor,
USB interrupt, or some other event. Can an
unexpected combination of events put your
system into an unknown state? And can you
detect it when that happens? What about an
intermittent connection that produces runaway
pulses much faster than the design can handle?
Problem 2—Inappropriate Code Reuse:
The Therac-25 used code from earlier versions
of the product. But the earlier versions had
fuses and interlocks to prevent the machine
from applying high power without the
attenuator. The developers of the Therac-25
used the old code, but removed the hardware
interlocks, trusting their software skills to
prevent dangerous conditions.
C
In an old song, "Signs," the singer reacted O
L
to a "No trespassing" sign by shouting at a U
M
farmhouse that they didn't have the right to put N
S
up a fence to keep him out. There is an old saying
that you should never tear down a fence until
you understand why it was put up. That fence
might be there not to keep you out, but to keep
in an aggressive bull. The Therac-25 developers
removed the interlocks that prevented exactly
the kind of dangerous conditions that caused
the incidents. The software bugs had existed in
the earlier machine, but the hardware interlocks
prevented harmful incidents.
Code reuse isn't a bad thing. But when
reusing code, especially on new hardware, it
is im portant to analyze what can go wrong in
To Ceiling To Ceiling
FIGURE 2
Construction design change at the Kansas City Hyatt Regency Hotel. This change led to the collapse
of two overhead walkways, and hundreds of fatalities and injuries.
CIRCUIT CELLAR • OCTOBER 2023 #399
the new system that didn't apply to the old
one. I can't read the minds of the developers
of the Therac-25, but I am confident that
if there were interlocks to prevent beam
activation in the dangerous configuration,
those patients wouldn't have been killed. The
developers of the Therac-25 had confidence in
their software skills and in the applicability
of the reused code to the new h a rd w a re -
overconfidence, as it turned out.
Some solenoids, heaters, and other parts
aren't designed for continuous operation and
will burn out if powered continuously; such
a device controlled by software can fail if
left energized too long. If your software can
do actual damage to the hardware or to the
user, how well protected is it against such
conditions, and how confident are you that the
protections hold up against a "dumb tourist"
who will try things you didn't think of?
FAULTY DESIGN: WALKWAY
COLLAPSE AT THE HYATT
REGENCY HOTEL
In 1981, two overhead walkways in the
Kansas City Hyatt Regency Hotel collapsed,
killing 114 people and injuring 126 more. As
with the other catastrophes mentioned here,
there were extensive investigations into the
causes, which are summarized in Wikipedia
[4]. I want to focus on just one thing that went
wrong, and how it is applicable to our designs.
The two overhead walkways were tied to
ceiling supports, and then held up with hanger
rods that went through the walkway beams.
During construction, a request was made to
change the design to make fabrication easier.
In the original design (Figure 3, left), a
single support rod goes through the upper
beam, which is held by a nut. The rod
continues to the lower beam and is held by
another nut. Thus, the rod carries the weight
of both walkways but each nut carries the
weight of only one walkway.
In the modified design (Figure 3, right),
there are two hanger rods. One rod stops at
the bottom of the upper beam and another
rod connects the upper and lower beams. As
a result, the nut on the upper beam, and the
beam itself, have to support the weight of
both walkways instead of just one. It was not
designed to do that.
The design change request was not
unreasonable from the viewpoint of the
company making those support rods. In a
complex building like that, there were probably
many design changes during construction. But
Additional materials from the author are available at:
www.circuitcellar.com/article-materials
References [1] to [4] as marked in the article can be found there.
none of the others were fatal.
In the case of the Hyatt disaster, the
problem was that nobody recalculated the
stress analysis for the design change; possibly
the original designer didn't even know the
change request had been made.
This goes back to the adage about tearing
down a fence before you understand its
purpose. Apparently nobody in the decision
chain for that change even recognized the
problem or tried to check. In a building like
that Hyatt, there are thousands of bolts,
tons of concrete that must be poured to
specification, miles of electrical wiring, and
hundreds of electrical fixtures. After an
incident investigation, when the cause of
the failure has been found, it's easy to say
someone should have checked; hindsight
always has 20/20 vision. But every design
change can't result in a complete reanalysis
of the entire building—how would someone
know to check the stress on that specific nut?
If your embedded system hardware or
software has a safety-critical element, how
does anybody know it's important? You could
add a comment to the code: "Safety is s u e -
do not change without analyzing 'xyz'." But is
that adequate?
In a similar way, how are safety features or
limitations that prevent device damage retained
in your code or in the hardware documentation?
As I mentioned, some solenoids will burn out
if current is applied too long. Does your code
have fail-safes to prevent these events? How
do you keep someone from changing them?
Someone changing the code years after original
development may not even be aware of the duty
cycle limitation on the solenoid.
My Experiences with Faulty Design
Changes: I worked on a project years ago
that involved a rotating drum. Someone
changed the drum material, presumably
to reduce cost. But the original drum was
made of conductive plastic, whereas the new
one was ordinary plastic. The result was an
unintentional Van de Graaff generator that
could produce arcs up to a quarter inch lo n g -
right into the control PCB. Nobody was hurt,
but the hardware sure didn't like it. How did
that person make that decision?
I worked on another system where
guys in another group, in another country,
had difficulty getting a part. Their vendor
recommended a replacement, and they
accepted it without asking me, though I had
designed the PCBA and firmware. The boards
seemed to work, but we got a lot of failures
in the field. Nobody was hurt, but a bunch of
boards had to be replaced in the field, and
erroneous results from those boards cost the
company money. The alternate part worked
well enough to pass board-level test, but

didn't work over the full range of conditions
encountered in the field.
When I looked into it, it was obvious
what had happened. The replacement part,
a current-sensing resistor, was the right size
and type, but the wrong value. I had put notes
on the schematic that included the calculation
for the part, and those notes should have
made it obvious not to change the value. I'm
guessing that the engineer who approved the
change didn't even look at the schematic.
Thus, in an exact parallel to the Hyatt disaster,
an engineer trusted the recommendation of
the vendor without checking with the designer
(me) or the documentation. The Hyatt disaster
happened essentially because an obscure but
potentially hazardous part of the design was
changed with no review or accountability.
Could something like that happen in
your designs? How does anyone in your
organization know to evaluate such a change,
and who has the authority to require that
such an analysis be performed?
CONCLUSION
There have been many incidents and
disasters that we can learn from. I've only
looked at a few here, and these are relatively
notorious in the engineering world. Many
safety lessons have been gleaned from those
circuitcellar.com 45
occurrences, and standards have been created
to accommodate those lessons. Hazard and
operability (HAZOP) analysis has been around
since the 1960s, and use of FMEA started in the
1940s with the U.S. military. Yet, the Boeing 737
MAX crashes happened despite all the lessons
learned from earlier disasters, and with all
those new processes and standards in place.
No m atter how many lessons we learn and
standards we create, humans are a critical
link in the development process. With the
complexity of modern systems, knowing how
one failure affects the entire system isn't
always obvious. The im portant point is to
make sure you understand how things can go
wrong and how badly they can go wrong, and
to design with that in mind.
Hopefully, this has given you some ideas of
what to look for in your own designs—so you
can avoid having your or your company's name
in the press after some high-profile disaster
happens! Because things do go wrong. Go
wrong. Go wrong...
C
O
L
U
ABOUT THE AUTHOR M
Stuart Ball recently retired from a 40+ year career as an electrical engineer
N
S
and engineering manager. His most recent position was as a Principal
Engineer at Seagate Technologies.
A V NET
LAUNCHING... WHAT’S NEXT!
Launching new technology is more complex than
ever. When it comes to navigating today's design
and supply chain challenges, Avnet is at the heart
of it all. Whether you're just starting on a design
or working to get your product to market, Avnet
delivers the right mix of technology and expertise
to help your business succeed. We deliver what's
next in design, supply chain and logistics so you
can deliver what's next for all of us.
Learn more at avnet.com
 46 CIRCUIT CELLAR • ER 2023 #399

in Thin S lices

How This-Slicing
Can Help’ Us
The Search mor "Fists
jfijilBWbddded Systems

k This month, I discuss the origin of my use of the

phrase "in thin slices," and how it can help us
S design, debug, and test our embedded systems.
N
M
U

J
L
O
C
f
By
Bob Japenga
FIGURE 1
Blink: The Power of Thinking Without Thinking, by Malcolm Gladwell

number of years ago, I was part
of a leadership team wrestling
with some long-term planning
decisions. We were considering
a major shift in one of our activities. I had
proposed that we do some more study and
reflection on the viability of the change. One of
my teammates was incensed. "We have got to
make a decision and get moving on this right
now. Another study will bury the project."
I share this story to let you know that, in
general, I err on overthinking a problem. I
am a process-oriented guy who likes to work
through all of the details before I launch on
a new endeavor. I like our systems and our
processes to be ever-improving.
I share this anecdote because this month
I would like to build a case for (sometimes)
making embedded system design decisions in
the blink of an eye. In the process of doing
that, I also want to celebrate the beginning of
13 years with Circuit Cellar as a columnist. As
some of you know, I end every column with
something like: "Next time we will wrap up
this series and look at specific strategies that
I have found helpful in debugging embedded
systems. But, of course, only in thin slices."
Many of you weren't with us when I started
these columns and explained what I mean by
"thin slices" (from which the column gets its
name). So, let's start there.
WHAT DOES THE TERM "THIN
SLICES" MEAN?
First, some background. In Malcolm
Gladwell's bestseller Blink (Figure 1), he
talks about the way we make decisions.
In particular, he describes a process our
brains go through called "thin-slicing." Thin-
slicing describes our ability to find out what
is important with limited data. I have been
designing embedded systems for 50 years,
yet I find I am always a beginner. I always
have limited data and a limited vision of what
is coming next. The field is so broad, and the
applications so varied, that no one person can
completely understand even a small portion
of the field.
Let's look at some details from the book: In
his first chapter, Gladwell focuses on explaining
how thin-slicing, or rapid cognition, works in
everyday life while making decisions. Gladwell
states that, often, a little information about a
person or situation is enough to make correct
conclusions. He describes an experiment
where friends and strangers were asked to
evaluate a student's personality (with respect
to extraversion, agreeableness, emotional
 circuitcellar.com 47

stability, conscientiousness, and openness to FIGURE 2

new experiences) based on observing their Morse code

dorm room. The results of this experiment
demonstrated that strangers were better
overall at evaluating a student's character
traits than friends. Gladwell also notes that
thin-slicing isn't an exotic gift, but rather a
"central part of what it means to be human."
Later in the book, he describes John
I • • V • • • •
Gottman, a therapist who could predict J M M ■ W • « M
whether a marriage would last at least 15 K M • — X • ™ • •
years based on spending just three minutes L Y • • • •
with them. If he could watch a 15-minute M " m z • • • •
video, he could predict with 90% accuracy.
And his success rate went to 95% if he saw
a 60-minute video of them. In his book The variety of fields. Thin-slicing is not foolproof.
Mathematics of Marriage, Gottman explains Gladwell admits that our thin-slicing can lead
how he is able to do this. And Gladwell claims us astray and we can get it wrong. I once
that it validates how thin-slicing, or rapid met a man for the first time, and within a few
decision-making based on very little data, can minutes he talked about me as if he really
be successful. knew me. But his thin-slicing was completely
Gladwell tells another interesting story wrong. A week later, I asked our daughter
about intercepting German Morse code about him and she said: "He's nice, but he
(Figure 2) during World War II. There were comes off as if he knows you really well—but
C
thousands of interceptors who listened to he is completely wrong in his assessments O
L
German broadcasts in Morse code from about me." As I got to know him, I saw this U
M
German military intelligence. The code was over and over again. His thin-slicing was N
S
not in English or German. What is fascinating malfunctioning.
is that the interceptors couldn't understand Gladwell also tells us that thin-slicing
what the Germans were saying, but they is something that can be learned. The
could learn who was speaking. marriage therapist was able to train others
The following is an excerpt from Blink. to accurately predict a marriage that was in
"The interceptors had such a good handle trouble. And the Morse code listeners were
on the transmitting characteristics of the able to teach others how to quickly identify
German radio operators that they could unique characteristics.
literally follow them around Europe—
wherever they were. That was extraordinarily DO WE NEED "THIN-SLICING" IN
valuable in constructing an order of battle, EMBEDDED SYSTEMS DESIGN?
which is a diagram of what the individual After all these years of embedded system
military units in the field are doing and what design, I feel like I know virtually zilch about
their location is. If a particular radio operator
was with a particular unit and transmitting
from Florence, and then three weeks later you
recognized that same operator, only this time
he was in Linz, then you could assume that
that particular unit had moved from northern
Italy to the eastern front. Or you would
know that a particular operator was with a
tank repair unit and he always came up on
the air every day at twelve o'clock. But now,
after a big battle, he's coming up at four in
the afternoon, and seven in the evening, so
you can assume that unit has a lot of work
going on. And in a moment of crisis, when
someone very high up asks, 'Can you really
be absolutely certain that this particular
Luftwaffe Fliegerkorps [German air force
squadron] is outside of Tobruk and not in
Italy?' you can answer, 'Yes, that was Oscar,
we are absolutely sure.'"
In typical Gladwellian style, Blink has many FIGURE 3
other stories Gabout thin-slicing in a wide Intel 4004
48 CIRCUIT CELLAR • OCTOBER 2023 #399
Fists that Potentially Distinguish
Hardware Bugs from Software Bugs
When nothing makes sense
When it is something only hardware can do
When the bug is affected by the environment (temperature, humidity,
atmospheric pressure, vibration, supply voltage stability)
When the bug doesn't manifest itself on all hardware
When the bug appears in older hardware even after re-booting
When the bug appears in new hardware but not in older hardware
When it is something that software cannot do
t a bl e 1
Possible fists
the subject. I am constantly bombarded
with things I don't know. Datasheets for
our processors were once nine pages long
S (the Intel 4004) and now run more than
N
M 3,000 pages. Our chips are so complex that
U
L testing one configuration every second would
O
C take longer than mankind has been around.
The 4004 (Figure 3) had just over 2,000
transistors, while Cerebras' deep learning
computer system, the Wafer-Scale Engine 2,
has 2.6 trillion MOSFETs (and 850,000 cores).
We must learn thin-slicing to survive.
Which processor will be right for our
project? On my first project there were nine
to choose from. Nine total! Today there are
tens of thousands of different processors.
We have to learn how to make important
decisions with limited information.
Which algorithm will work best in a
particular application? I once gave an
employee a task to design an algorithm for
a critical embedded system. His algorithm
was 20 pages long. Do we go ahead and
ABOUT THE AUTHOR
Bob Japenga has been designing embedded systems
since 1973. From 1988-2020, Bob led a small engineering
firm specializing in creating a variety of real-tim e
embedded systems. Bob has been awarded 11 patents
in many areas of embedded system s and motion
control. Now retired, he enjoys building electronic
projects with his grandchildren. You can reach him at
Bob@ListeningToGod.org.
Additional materials from the author are available at:
www.circuitcellar.com/article-materials
Reference [1] as marked in the article can be found there.
implement it? Do I dig into his weeks' worth
of work to see if this is what was needed?
I didn't have time. In the blink of an eye, I
knew that this was not correct and gave it to
another designer who came up with a four-
page algorithm. And that aircraft is still flying
with that algorithm today.
How about in project management? Is this
schedule realistic for this project? Are we even
in the ballpark? As managers, we can't always
dig into all the details to evaluate a particular
schedule. Yet we need to make a decision with
lots on the line and little information.
I hope that someone will do for embedded
system design what Gottman did for marriage:
develop the markers—or, to borrow the term
used for distinct Morse code rhythms, the
"fists"—that would signal dead ends, projects
that will never get done, designs that will fail, or
algorithms that won't perform. Is it possible?
I think so. Marriages and relationships are
much more complex than even our most
complex embedded system. (One estimate,
as discussed in Scientific American, is that
the human brain has around 2.5 petabytes
of storage. That's 2.5 thousand times bigger
than the memory in most of our embedded
systems, assuming most embedded systems
use less than 100GB of storage.)
As a first attempt, let's try to determine
if there are some markers that would help us
to evaluate whether a bug is in hardware or
software. I'm convinced there are some, and
that we can get better at recognizing them.
Over the years of debugging (I created a lot of
bugs in my time), I found that I could "smell
out" a hardware bug. How did I do it? I'm not
quite sure. But my success at predicting them
was high. As I mentioned, thin-slicing is not
magic. It's not even a gift—it can be taught.
CREATING FISTS THAT INDICATE
IF A BUG IS IN HARDWARE
My February 2023 article in Circuit Cellar
("Debugging Embedded Real-Time Systems:
Strategies to Determine if a Problem is in HW
or SW," Circuit Cellar 391) on debugging is
a good place to start [1]. There, among the
strategies, are seven fists (Table 1) that I
have used to determine if a bug is in hardware
or software. The other strategies in the article
were procedural strategies for determining
the nature of the bug.
None of these are foolproof. Sometimes,
temperature can reveal a software bug, making
it environmentally dependent. Remember,
Gottman's fists were not 100% predictive of a
successful marriage. Memory fragmentation
and memory leaks can make a bug only
appear after long periods of operation. New
hardware can run faster and expose software
race conditions. But what if we can build a
 circuitcellar.com 49

list of these (send me any suggestions and I

will republish the list) so that we can debug
faster through thin-slicing? I am convinced
that with these fists (and others you provide),
embedded systems developers could much
more rapidly determine whether a bug is in
hardware or software.

SUMMARY
Let me restate my hypothesis. We can
create fists, or signatures, to aid in embedded
systems design and debugging. Malcolm
Gladwell demonstrates in Blink that we can
solve complex problems quicker than expected
(Figure 4). I've only scratched the surface. I
would love to hear from you. Can you provide
some other fists to help us get to the bottom
of a problem more quickly? Perhaps you can
augment the areas in embedded systems
design for which I've proposed to create
fists. More critically, can we get some serious
research in developing fists to help speed up
the various aspects of our work? I think it's
possible. Is there some PhD candidate looking
C
for such a project? We certainly need it. O
L
Next time, I want to explore requirements U
M
elicitation. How do we obtain the N
S
requirements for a project? But of course, FIGURE 4
only in thin slices. Blink - solve complex problems quicker

FIRMWARE CONFIGURABLE INDOOR AIR QUALITY (IAQ)

SENSOR WITH EMBEDDED ARTIFICIAL INTELLIGENCE (Al)
Optimized to support public building air quality standards

Visit renesas.com/zmod4410 to learn more

Re n e s a s
50 CIRC1OTWELLAR • OCTOBER 2023i

From th e B<

UsMRnm!Ss8ElBB8ES8
Partl2^Moa mnW l imt:-
flu ■M l

rA

in last month's column, I discussed a low-voltage solar 1

S
N
S energy system I built for lighting my Scout troop's large ■
storage shed. I described the battery I chose, and the
I Modbus protocol with RS-485 serial communication used for
remote monitoring of the system's performance ("sniffing"
M
U
L or listening to communication on the bus, and decoding
O
C
each message). This month I expand on this node's capacity FIGURE 1
Two south-facing 100W solar panels are mounted
to do much more than just listen and decode. on the back of our Eagle's Nest equipment shed.

By
J eff Bach iochi
hanks to a grant from the Hartford battery node (yes, this is a smart battery)

T
Foundation for Public Giving, our through a twisted-wire RS-485 network, using
newly constructed equipment shed, the Modbus protocol. So far, our solar supplier
the Eagle's Nest, now has a system is not publishing the Modbus specifications for
each node. This makes it a bit difficult to add
to collect and store solar energy, and then
use it to power LED lighting throughout our own node to the bus.
the shed's two floors. The system uses two Fortunately, the Modbus protocol is an open
south-facing solar panels, a solar charge standard, with specifications available from
controller, a lithium iron phosphate battery, Modbus [1]. With them, we can understand
and a Bluetooth module (Figure 1, Figure 2, the communications protocol. In my project
and Figure 3). Previously, the Scouts used the last month ("Local Isolation: Using the Sun's
flashlights on their cell phones to search for Energy," Circuit Cellar 398, September 2023)
and pack equipment needed for meetings and [2], I created an RS-485 node that can listen
campouts. This caused safety issues that were to ("sniff") all the communication happening
eliminated by providing sufficient permanent on the twisted pair bus, and decode each
lighting. message. This month I will expand on this
We can light the area with simple 12V LED node's responsibilities to do more than just
lighting bars, so we won't need to convert listen.
the energy into 120VAC; a low voltage (12V)
system will suffice and will be safer. It can MODBUS REVIEW
all be monitored with a cell phone app that The Modbus protocol uses two types of
allows you to see real-time and historical data, nodes: clients and servers. In our case, the
as long as you're within range of the shed. Bluetooth node is a client, and the controller
Unfortunately, it is too far from our sponsor's and battery are servers. The protocol requires
building for power or an Internet connection, a client to request data from a server. Servers
so we're on our own. The Bluetooth module have address registers where data is kept.
communicates to the controller node and These are defined as input registers, holding
 circuitcellar.com

(output) registers, discrete (bit) inputs , and coils (output

bits). Note that I/O bit operations are usually performed on a
single bit of an input or holding register.
As of this writing, I have not seen any bit I/O requests.
All requests have been of the register kind; registers are a
minimum of 2 bytes or a word. However some requests are
for multiple registers, and could be several separate pieces
of data, or a single value that requires multiple words. The
sniffer application tries to understand whether it's seeing a
request or a response. Sometimes this is clear, and other
times it is not—for example, when a request and a response
are identical.
The PDU (Protocol Data Unit) request and response
packets are similar in makeup; they begin with a command
and end with data. All servers have an assigned address
associated with them. Servers require the first byte of a
packet to be their assigned address, or else they neglect the
PDU. To assure that the PDU gets delivered without error, a FIGURE 2
cyclic redundancy check (CRC) is added to the PDU. The PDU The solar controller, along with the communication hub, Bluetooth module and
is therefore wrapped with the server address as the first byte power hub, are mounted to the wall opposite the solar panels, just under the
and the CRC as the last bytes. The total packet is called the stairway leading to the shed's attic. The 12V power hub has individually fused
Application Data Unit or ADU. The first 2-3 bytes of a packet circuits for all the LED lighting.

are the server address and the command. The remaining data
and CRC bytes are in pairs or words.
don't have to add much code to allow the sniffer to become
BLUETOOTH CLIENT a client. Most of the code allows the serial port to become
All communication is initiated by the client. Here, the client a user interface. This is presented as a menu of supported
is a Bluetooth (BT) module. The client receives commands from commands.
the cell phone application (DC Home). To know which nodes
(servers) are in a system, you must first select the BT module. 1 - Read a Register
When communication is established between the application 2 - Write a Register
and the BT module, you can add devices by connecting them 3 - Restore Factory Default
one at a time to the Modbus. The application will perform a 4 - Clear History
request for register OxlA to the general broadcast address 5 - Change Address
0x00. 6 - Change myDebug

0x00 0x03 0x00 OxlA 0x00 0x01 Ox?? Ox?? Note that the first two menu items allow for register reading
server command register register count CRC and writing. The second two items are system commands and
are not used in normal querying. The last two items change
The connected server will respond with a packet. application parameters, the server address, and the kind of

0x00 0x03 0x01 0x00 0x10 Ox?? Ox??

server command register count data CRC

When the connected node is the solar controller, it responds

with its server address, in this case 0x0010. Once registered
with the BT module, it will remember that there is a node at
address 0x10. Remove it from the bus and continue adding
nodes until all your nodes are identified. In fact, the BT client
will ask for other information about the node, such as the
product's model and serial numbers. The server address is not
revealed to the user, which is one reason last months "sniffer"
project was developed. We will need this to communicate
with any of the nodes. The sniffer determined that the solar
controller (Rover Elite 20A) uses address 0x10, and the lOOA-h
Lithium Iron Phosphate battery uses address 0xF7.

SNIFFER AS A CLIENT FIGURE 3

When the BT module is not connected to the phone
application, there is no communication on the Modbus. I can
use the sniffer project to look like the BT module client, and
request data from any of the server nodes on the Modbus. We
Since our shed is unheated, the Lithium Iron Phosphate lOOA-h battery has
internal heating pads to prevent it from reaching the low temperatures of our
sometimes cruel Northeastern winters. Internal lithium cells are made up of four
series groups of pouch cells. The Modbus communications port allows each of
the four groups of cells to be individually monitored.
52 CIRCUIT CELLAR • OCTOBER 2023 #399

debug data that is sent to the serial port. In
most cases, we will be using item #5 to select
the server we want to talk to, and item #1 to
query information. Let's spend some time on
item #1, "Read a Register."
QUERYING INFORMATION
In the application described last month
[2], the auxiliary serial port, i f ( S e r i a l l .
a v a i 1a bl e ()), was polled to see if there was
activity on the Modbus that we should sniff
(attend to). For this application, we add a poll
to the primary serial port (USB), i f ( S e r i a l .
a v a l 1a b le ( )). On the primary port, we are
using the Serial Monitor in the Arduino IDE to
handle the user I/O. Because debug data also
uses this port, it is best to keep the debug
data to a minimum. Note that you can see
which bits enable and disable various debug
output in the sketch listing. Since we are

11
/ / s t a r t lo o p
//
v o id lo o p ( )

// read from p o r t 1, send to p o r t 0:

if ( S e r i al 1 . a v a l 1a b l e ( ))

case 1:
S e r i a l . p r i n t l n ( “ Request a R e g is t e r ” );
S w h i1e ( S e r i a l . a v a l 1a b l e ( ))
N
M
U
L S e ri a l . re a d ();
O
C
S e r i a l . p r i n t l n ( “ How many r e g is t e r s do you w ish to re a d ? ” );
S e r i a l . s e tT im e o u t( 10000);
m o d b u sR e g iste rC o u n t = S e r i a l . p a r s e l n t ( );
S e ri a l . p r i n t l n ( “ You asked f o r “ + S trin g (m o d b u sR e g iste rC o u n t) + “ R e g is t e r ( s ) ” ) ;
S e r i a l . p r i n t l n ( “ E n te r th e s t a r t in g R e g is t e r Number” );
S e r i a l . s e tT im e o u t(lO O O O );
m o d b u sS ta rtA d d re ss = S e r i a l . p a r s e ln t ( ) ;
Seri a l . p r in t ln ( “You entered the R egister Number Ox” + String(m odbusStartAddress, HEX));
1f ( a re Y o u S u re ( ))

modbusIndexTX = 7;
m o d b u sA rray[0] = m odbusA ddressC ode;
m o d b u sA rray[1] = 0x03;
m o d b u sA rray[2] = m o d b u sS ta rtA d d re ss >> 8;
m o d b u sA rray[3] = m o d b u sS ta rtA d d re ss & OxFF;
m o d b u sA rray[4] = m o d b u sR e g iste rC o u n t >> 8;
m o d b u sA rray[5] = m o d b u sR e g iste rC o u n t & OxFF;
checkCRC(m odbusIndexTX);
m o d b u sA rray[6] = c a lc u la te d C R C >> 8;
m o d b u sA rray[7] = c a lc u la te d C R C & OxFF;
sendM odbus( ) ;

/ / --------------
/ / end lo o p
/ / --------------

LISTING 1
Once the user enters a menu choice, the switch command uses the integer found to branch to the chosen routine.
 circuitcellar.com

expecting the user entry to be an integer

between 1 and 6, we can use the Arduino II
control structure, switch...case, to branch to II s t a r t fu n c tio n sendModbus
the appropriate routines. 11
In Listing 1, we make sure the serial void sendModbusC)
buffer is empty before asking, "How many
registers do you wish to read?" The response di s a b le R X ();
becomes the m odbusRegisterCount. e n a b le T X ();
f o r ( i n t i = 0; i < (modbusIndexTX+1); 1++)
The next question is, "Enter the Starting
Register Number?" The response becomes
if(myDebug & 0x40)
the m odbusStartAddress. A final question
asks, "Are You Sure? Hit Y." This allows you Seri a l . p r in t ln (“ 0x”+ String(m odbusArray[i], HEX));
to proceed unless you made an error. If // w i l l prolong the en ableTX /disableTX pulse
you choose to proceed, then we set up the
m odbusArray[] with the appropriate data Seri al 1 .wri t e (m odbusA rray[i]);
and call the sendM odbus() routine.
In last month's project [2], I used an delay(modbusIndexTX+3);
SN75176 to handle the physical interface
di s a b le T X ();
en ableR X ();
between the application microcontroller
(Adafruit's HUZZAH32) and the twisted-pair H
Modbus. Although the Modbus protocol doesn't II end fu n c tio n sendModbus
specify what the physical communication //
medium is, in this case the industry standard
multi-drop RS-485 is used. With this balanced
LISTING 2
and differential twisted-pair bus touting high
Here is where we actually enable a Modbus communication. The modbusArray[] holds the packet we
speed and long distance, communications
want to send. The variable modbusIndexTX holds the packet count.
must be driven in only one direction at a time.
This fits with the Modbus request-response
protocol. Please refer to last month's column
[2] for a discussion on the SN75176 and the
circuit connections to the microcontroller.
For sniffer operation, we needed only the
receiver portion of the SN75176. The receiver
and the transmitter have separate enable
inputs, so you can control when the receiver
will output data found on the Modbus, and
can also enable the transmitter to drive
the Modbus. Remember, only one device is
allowed to drive the Modbus at a given time.
That will be the client when requesting, and
a server when responding. You can see from
Listing 2 that the enable/disable controls
are changed before and after the packet is
transmitted. The control lines for the receiver
and transmitter must be placed in the correct
logic states to allow for packet transmission.
Since responses are already coded from
the original sniffer application, once a request FIGURE 4
has been transmitted, the response will be This tiny PCB is a serial TTL-to-bipolar RS-232 converter. It uses a MAX3232 to generate the bipolar
displayed. Note that the Bluetooth module voltage necessary to convert between TTL serial and an inverted bipolar TX and RX.
BT-2 is for use with those devices that have
a RS-485 interface (RJ-45). Renogy offers
controllers that are not RS-485 compatible.
These devices have an RS-232 interface ABOUT THE AUTHOR
using an RJ-12 connector. The BT-1 Bluetooth
Jeff Bachiochi (pronounced BAH-key-AH-key)
module is designed for the controllers that
has been writing for Circuit Cellar since 1988.
use serial RS-232. This interface is a 1:1
His background includes product design and
interface, and does not support multi-drop or
manufacturing. You can reach him at:
more than one server.
What if you have a controller with an RS- jeff.bachiochi@imaginethatnow.com, or at:
232 communication port, and you want to use www.imaginethatnow.com.
it in a multi-drop system?
CIRCUIT CELLAR • OCTOBER 2023 #399

Luckily both RS-232 and RS-485 use
the same baud rate, 9600 baud, and use
the Modbus protocol. Remember, I said the
Modbus protocol does not actually call out any
particular physical interface. We can use the
RS-232 controller by adding some circuitry
to convert RS-232 to TTL and then add an
RS-485 interface. I prototyped this interface
using two conversion modules found on the
Internet for less than $20 (and that cost was
for multiple modules).
The tiny board in Figure 4 uses a MAX3232
to convert the bipolar serial signals (RX and
TX) into inverted TTL level (RX and TX). The
larger board in Figure 5 has a microcontroller
as well as a MAX488 RS-485 driver. The
microcontroller handles the RS-485's TX and
RX enables, so you don't have to worry about
them. It will enable TX and disable RX for a
period of time, based on receiving data from
the TX line. I verified that this project works
with a 10A Wanderer controller (Figure 6). This
adds the ability to use this type of controller
with the RS-485 multi-drop system.

LOCAL USE
Since you may be using a similar system on
your property, you may be in range of a Wi-Fi
connection. If so, you are in luck, because the
HUZZAH32 MCU has both Bluetooth and Wi­
Fi capability. We've already got a Bluetooth
app, so let's add in some Wi-Fi capabilities to
allow the sniffer to monitor and report some
parameters using MQTT.
MQTT is a standard messaging protocol
for the Internet of Things. It is a lightweight
publish/subscribe messaging transport that
is ideal for connecting remote devices with
FIGURE 5 a small code footprint and minimal network
This PCB is a serial TTL-to-RS-485 converter. In addition, it handles the control of the TX driver and bandwidth. I've used this in many projects in
RX receiver of the RS-485 converter with a microcontroller that monitors the TTL TX line for activity.
the past. My system runs on a Raspberry Pi.
When it senses activity, it enables TX and disables RX. This operation is usually handled by your
The Node-RED application allow you to easily
circuit. (See my September, 2023 column in C irc u it C e lla r [1]).
display the data on a PC (or locally on the Pi)
by pointing to the MQTT port of the Pi's IP in
a browser.
First let's briefly touch on the requirements
for this HUZZAH32 to connect to my LAN, and
connect to the MQTT running on my Pi. The
Wi-Fi uses the W ifi .h library, and MQTT
uses the P u b S u b C lie n t.h library. I have
hard-coded my network name and network
password into the application. This module
will be used in station mode (client), since my
router will assign a local IP to devices that
want to connect. Once it has been assigned an
IP, we can attempt communication with any
other device on this LAN. I have hard coded
my Pi's IP address in the application, so an
attempt is made to connect to the Pi. Once
it connects, we're ready to go. Well, almost.
MQTT requires two additional functions.
The r e c o n n e c t() function is used to
establish a connection with MQTT and, as the
function name suggests, it will also be called
if there should be a loss of connection. Within
this function, you can request a subscription,
FIGURE 6
This month's project is assembled in my office and is used to prove the application written for the
or to be kept up to date on some function
HUZZAH 32 MCU. Beneath the micro is the RS-485 converter. The 3-wire group exiting the PCB is happening elsewhere on the MQTT network.
the RS-485 Modbus connections. For this installment, I am using a Renogy Wanderer. This controller In this case, I subscribe to the DateTime
has an RS-232 output; thus, it uses the circuits shown in Figure 4 and Figure 5 to create a Modbus function. This is an MQTT routine that
connection. publishes the Date and Time every minute.
 circuitcellar.com 55

Now our module can stay in sync with the

world. The second function is ca llb a ck O . //
This routine is used to processes any I I s ta r t fu n ctio n requestRegisters
subscriptions. I take the Date/Time info and
H
integrate it into this application. void re q u e s tR e g iste rs ()
The main 1o o p ( ) function is fairly simple.
It has six things to check: 1) increment the / / S e r ia l. p r in t ln ( “ Request!ng C o n tro lle r
second variable after 1,000ms; 2) check for Regi s t e r s ” ) ;
disconnection and reconnect if necessary;
modbusRegisterCount = 0x20;
modbusStartAddress = 0x0100;
3) check for MQTT requests; 4) if it's time to
modbusAddressCode = 0x10;
request solar controller registers; 5) if it's
modbusIndexTX = 7;
time to send response data to MQTT; and 6) if
modbusArray[0] = modbusAddressCode;
there is any traffic on the Modbus.
modbusArrayLl] = 0x03;
Before we can request or send any MQTT modbusArray[2] = modbusStartAddress >> 8;
data, we have to decide just what to send. In modbusArray[3] = modbusStartAddress & OxFF;
this application, I will request registers from modbusArray[4] = modbusRegisterCount >> 8;
the dynamic group (live data)—one request modbusArray[5] = modbusRegisterCount & OxFF;
for 32 registers starting at address 0x100. checkCRC(modbusIndexTX);
Our sniffer routines will capture the response. modbusArray[6] = calculatedCRC >> 8;
Note the variable successArrayCount in modbusArray[7] = calculatedCRC & OxFF;
Listing 3. This will be incremented each time successArrayCount = 0;
a different register found in the response is sendModbus();
received. This should equal 32, when all 32
registers have been reported. We use this
11
I I end fu n ctio n requestR egisters C
variable to determine when the response has O
// L
been found and all of the register variables U
M
have been updated. N
S
Once the solar controller has responded LISTING 3
to our Modbus request, all local variables All parameters of the modbusArray[] are set up. Then a call to send out a request is made (see
have been updated. We use these to prepare Listing 2).
CIRCUIT CELLAR • OCTOBER 2023 #399

MQTT packets. The PubSubClient.h library
will handle all the messy stuff. We only need
to supply two arrays, to p ic [ ] and msgEJ.
The topic array is the same for all messages,
"ESP32_9592FC". The msg array contains
a JSON-encoded object. JSON (JavaScript
Object Notation) is a text format that is
completely language independent, but uses
conventions that are familiar to programmers.
In its simplest form, a JSON object contains
just one member, and the member is in the
form {"string":value}. While this can contain
multiple members separated by a comma, I'll
send just one member in each MQTT packet.
// batterySOC
myString=” {\” batterySOC\” :” + String(batterySOC) +
m yString. toCharArray(msg, msgSize);
myString = ID;
myStr1n g.toC h arA rray(topic, m sgSize);
c l i e n t . p u b lis h (t o p ic , msg);
LISTING 4
After filling in the msg and topic character arrays, the function client.publish(topic, msg) will
perform the necessary step to publish the MQTT message.
The function c lie n t.p u b lis h ( to p ic ,
msg) will use the topic and msg arrays to
assemble and send an appropriate MQTT
packet to the MQTT application running on my
Pi. This is done for each of the solar controller
registers. Listing 4 shows one of these
registers. You can sample and send data at
a predetermined rate. This is controlled in
the lo o p O function. For this application, I'm
publishing data every minute.
MQTT
Assuming MQTT is receiving our published
data, we can choose to display this from
any browser. If we point our browser to the
MQTT port of the Pi (http://<my Raspberry PI
IP>:1880/), we are brought to the Node-RED
application (Figure 7). You can check out a
couple of my past "From the Bench" columns
[3][4] on MQTT and Node-RED, or visit the
websites for MQTT [5] and Node-RED [6] for
more information.
Node-RED provides a graphical palette of
nodes that can be used to perform operations
on your MQTT data. While this might look a bit
intimidating, its pretty easy to understand. In
the upper left of Figure 6 is a pink-colored

■* * r -

r A fr*

FIGURE 7
This column sends JSON elements to my Raspberry Pi running MQTT and Node-RED. MQTT handles all publish/subscribe communications, and routes them as
necessary. Node-RED is a graphical programming language that allows data to be manipulated in many ways. Here the program "flow" gathers MQTT elements and
massages member data so it can be displayed to a user.

•t 1
FIGURE 8
The display page of Node-RED demonstrates the result of my program "flow" in Figure 6. In this case, each chart will display the data received during the last week.
Other data is displayed as text, which is the more appropriate choice.
node that grabs the MQTT data that has
the topic "ESP32_9592FC." This feeds two
yellow nodes that separate each JSON object
member into separate pieces—the topic or
sensor name, and the payload or sensor value.
The switch node then routes each topic to a
separate output, so each sensor's value can
be displayed. The blue nodes are two different
types of display—a chart or a text box. Most
of the green nodes are debug nodes that can
display raw in the debug panel on the right.
This group of nodes is known as a "flow." All
of my present flows can be seen across the
top of the display as tabs.
Once you have programmed a Node-
RED flow, you can see the results in the
User Interface, a second browser window
at http://<my Raspberry PI IP>:1880/ui/
(Figure 8). Here the data is displayed in
real time. You can see the data from the
experimental home setup using a small 12V
10W panel. There are five charts and six text
areas.
THE END?
This column shows how we might hijack
the Modbus communication port, retrieve
data, and send it via Wi-Fi to another network
node, which can collect and display the data.
But it does not satisfy the requirement that
we began with. That is, Troop 96's equipment
shed has no access to electricity, and Internet
circuitcellar.com
ri
•• it f t i r t
is not within reach. My September and
October columns in Circuit Cellar have been
merely a prelude to the last piece of this
puzzle. Although our solar energy system
can communicate using Bluetooth, once we
move off the property, that is no longer
accessible. Although this month's column
shows how we might use Wi-Fi, if it were
available, we are unfortunately out of range.
So what can we do? Next month, I'll use
something that I've never discussed before.
You might be able to guess what that might
be. If not, then you'll just have to wait until
next time, because there is just too much to
do and so little time.
Additional materials from the author are available at:
www.circuitcellar.com/article-materials
References [1] and [6] as marked in the article can be found there.
Resources
Adafruit | www.adafruit.com
Arduino | www.arduino.ee
Modbus | www.modbus.com
MQTT | www.mqtt.org
Node-RED | nodered.org
Renogy | www.renogy.com
Texas Instruments I www.ti.com
58 CIRCUIT CELLAR • OCTOBER 2023 #399

PRODUCT NEWS by Kirsten Campbell

Adafruit Launches New Microcontroller For loT And A l Integration

Adafruit's new Metro ESP32-S3 boasts a 16MB flash and
an 8MB Pseudo-Static Random Access Memory (PSRAM)
development board
The ESP32-S3 is a state-of-the-art, energy-efficient, 2.4GHz
WiFi/BLE System-on-Chip (SoC) incorporating built-in native
USB and other novel features such as Time of Flight distance
assessments and Artificial Intelligence (Al) enhancements.
Given its superior power and Radio Frequency (RF) capabilities,
this SoC is a prime selection for applications like the Internet of
Things (loT), wearable technology, and smart home systems.
With a native Universal Serial Bus (USB) and an abundance
of PSRAM, the board is suited for CircuitPython or Arduino,
allowing for affordable WiFi integration while maintaining
compatibility with shields. The Metro ESP32-S3 consists of
a dual-core 240MHz processor, placing it on par with the
dual-core capabilities of the ESP32. While it doesn't support
Bluetooth Classic, it does offer Bluetooth Low Energy (BLE).
The ESP32-S3 mini-module embedded in the Metro is coupled
with 512KB of Static Random Access Memory (SRAM). The
board uses SRAM for quick memory access and PSRAM for
spacious but slightly slower access. Furthermore, it is ESP-
IDF or Arduino compatible.
The microcontroller board is designed for energy efficiency
and offers multiple sleep modes. The three primary operating
states are normal, light sleep, and deep sleep. Only the real­
time clock remains functional, which can wake the chip. Upon
rousing from this mode, the chip restarts from the beginning
of the code, ensuring a fresh start each time.
Some key features of the development board include:

• ESP32-S3 Dual Core 240MHz Processor

• FCC/CE certified mini module
• 16 MByte Flash, 8MByte PSRAM.
• Power: USB-C or Lipoly battery.
• JTAG 2x5 Header for debugging.
• Optional serial debug output pins.
• STEMMA QT connector for I2 C
• LEDs: On/Charge/User + status NeoPixel.
• Low Power: ~100pA in deep sleep mode.
• Turn off NeoPixel & I2 C Power for the lowest current draw.
• Compatible with ESP-IDF, Arduino, CircuitPython
S
W Adafruit | www.adafruit.com
E
N
T
C
U
D
O A New 3rd Gen SiC MOSFET Series for Industrial Equipment From Toshiba
R
P
This new series includes five devices with a drain-source charge (QGD) values, it will enable low losses even in high
(VDSS) rating of 650V and a further five devices rated at frequency applications.
1200V for higher voltage applications. The devices are capable of delivering continuous drain
The TWxxxZxxxC series from Toshiba may look like your currents (ID) of up to 100A.
parents' Wi-Fi password, but this set of ten SiC MOSFETs
is intended to reduce losses in a wide variety of industrial Toshiba Electronic Devices & Storage Corporation
applications, including switching power supplies for servers | www.global.toshiba.com
& data centres, electric vehicle (EV) charging stations,
photovoltaic (PV) inverters and uninterruptible power supplies
(UPS).
The new products are the first in Toshiba's SiC MOSFET
line-up to use the four-pin TO-247-4L(X) package, which
allows Kelvin connection of the signal source terminal for
the gate drive. The package can reduce the effect of source
wire inductance inside the package, improving high-speed
switching performance. For the new TW045Z120C, the turn­
on loss is approximately 40% lower and the turn-off loss
reduced by approximately 34%, compared with Toshiba's
current product TW045N120C in a three-pin TO-247 package.
This helps to reduce equipment power loss.
The new TWxxxZxxxC series includes five devices with
a drain-source (VDSS) rating of 650V and a further five
devices rated at 1200V for higher voltage applications. The
typical drain-source on-resistance (RDS(ON)) is ranging
between 140mfi and 15mQ. Combined with low gate drain Three-phase Inverter using SiC MOSFET

NEW PRODUCT SUBMISSIONS— E-mail: product-editor@circuitcellar.com

 circuitcellar.com 59

PRODUCT NEWS

Knowles Precision Devices Introduces a Medical-Grade Capacitor

Catalog For Implantable Device Applications
This series is designed to offer the broadest va rie ty of In addition to the
m edical-grade capacitors so engineers can have confidence MD Series distinction,
in the com p atib ility and quality of th e ir selections. the catalog indicates
Knowles Precision Devices, a division of Knowles chip size, dielectric,
Corporation, recently introduced the MD Series, a range of capacitance, tolerance,
m edical-grade capacitors fo r im plantable designs. The MD voltage VDWC,
Series encom passes COG, X7R and X5R m onolithic ceram ic term ination, high-
chips. re lia b ility testing,
With a legacy in testing and screening m ilita ry-g ra d e packing option(s), and
re lia b ility specifications (MIL-SPECS) for defense and m ilita ry screening. Beyond
applications, Knowles has adopted that sam e rig o r for m edical Group A, all screening
applications. options are tailored for selectable-com bination testing. This
"O ur in-house engineers know how helpful it is to have reduces or elim inates the cost associated w ith developing
com prehensive specifications readily available. It saves a lot and m aintaining device-specific docum entation packages and
of tim e in ordering and sourcing, w hich expedites the overall better preserves each com ponent's perform ance in teg rity
production process," said V ictor Lu, applications engineer, through design and m anufacturing.
Knowles Precision Devices. "We wanted it to be easy for design The MD Series can be screened using two long-standing MIL-
team s to identify which com ponents are m edical-grade and SPECs: MIL-PRF-55681 (Group A) and MIL-PRF-123 (Group A).
w hat screening they've undergone. Ultim ately, engineers
should feel assured that these com ponents w ill serve th eir Knowles Precision Devices |
designs and m eet th e ir h ig h -re lia b ility requirem ents." www.knowlescapacitors.com

GOWIN Semiconductor & Andes Technology Corp. Announce The First RISC-V CPU and Subsystem Ever
Embedded 22nm SoC FPGA
GOWIN is offering the Andes A25 RISC-V CPU IP and AE350
subsystem as instantiated hard cores in its GW5AST-138 FPGA
Andes Technology Corporation is thrilled to announce that its
AndesCore A25 RISC-V CPU IP and AE350 peripheral subsystem
is hardened and embedded in the GW5AST-138 FPGA chip from
GOWIN Semiconductor, the world's fastest growing FPGA company.
This integration, one of the first complete RISC-V microcontrollers
in an FPGA, provides designers the A25 processor power and
the peripherals most processors require without consuming any
FPGA resources. This is exciting because the hardware team
can populate the FPGA with their value-added design while the
software team can concurrently create application code based on
the rich RISC-V ecosystem. Talk about win-win.
"In the Arora V family, we incorporate the peripherals that
a RISC-V CPU typically requires in hard instantiations," says
GOWIN's Sr. Director of Solution Development, Jim Gao. "We
included a fully controllable high-speed SerDes for communication, P
R
video aggregation, and A l computing acceleration applications O
D
that demand very high data rates. Other instantiated functions U
C
include Block RAM modules supporting ECC error correction, T
N
high-performance multiple voltage GPIO, and high accuracy clock E
W
architecture. These hard functions save the FPGA programmable S
fabric of up 138K LUT's for the designers' unique logic
implementation."
About the RISC-V Based GW5AST-138 FPGA:
The AndesCore A25 hard core, running at 400MHz, supports
the RISC-V P-extension DSP/SIMD ISA (draft), single- and double­
precision floating point and bit-manipulation instructions, and
MMU for Linux based applications. The AE350 AXI/AHB-based
platform comes with level-one memories, interrupt controller,
debug module, AXI and AHB Bus Matrix Controller, AXI-to-AHB
Bridge and a collection of fundamental AHB/APB bus IP components
pre-integrated together as a system design. DDR3 controller and
SPI-Flash controller in the FPGA fabric back up the A25's 32KByte
I-Cache and D-Cache after cache misses. Off chip DDR3 provides
data memory, SPI-Flash contains the A25's instruction memory
(codes copied from SPI-Flash into DDR3 and Cache upon boot­
up). Besides hard instantiated functions, the GOWIN GW5AST-138
FPGA fabric affords 138K LUTs for custom design implementation.
GOWIN EDA provides an easy-to-use FPGA hardware development
environment for the Arora V. The environment supports multiple
RTL-based programming languages, synthesis, placement and
routing, bitstream generation and download, power analysis and
in-device logic analyzer.

GOWIN Semiconductor | www.gowinsemi.com

NEW PRODUCT SUBMISSIONS— E-mail: product-editor@circuitcellar.com

60 CIRCUIT CELLAR • OCTOBER 2023 #399
Answer 1—The term "virtual" is confusingly overloaded
in these discussions. You need to have virtual addressing
in order to have virtual memory, but you don't necessarily
need to use virtual memory if you have virtual addressing.
A memory management unit (MMU) creates virtual, or
"logical," address spaces, and maps them, page by page
(or segment by segment), into the physical memory that is
present on the machine. Usually, each process running on
the machine gets one of these logical address spaces to run
in, and it basically starts at address zero and goes as high
as needed.
This has several advantages. The first is protection: if no
mapping to a particular physical page exists in the current
process's logical address space, then that process cannot
affect that page in any way.
The second is the ease of dynamically allocating physical
memory to processes: pages that are contiguous in the
logical address space do not need to be contiguous in
physical memory. One example of this is managing stack
space. Suppose you allocate 16 4KB pages (64KB) initially
for a process's stack, but it turns out to be a deeply
recursive process that needs more. As soon as it touches
the first location outside the allocated area, an exception
will occur and the underlying handler will have the option of
assigning additional physical memory to that process for its
stack. When the handler returns, the process will continue
as though it had had that memory all along. "Heap" space
can be grown as needed in the same way.
Memory can be shared by having two or more logical
address spaces map some of their pages to the same set
of physical pages. You can even set this up so that only one
process at a time has "write" permission for the pages.
Finally, you can do virtual memory if you want. Virtual
Q
memory simply means that not all of the memory pages are
E actually in physical memory at all times—some of them are
R
U swapped out to disk storage. This allows the total number
O
Y of pages to be larger than the amount of physical memory
S
T that is actually present on the machine. All this means is
S
E that there's an entry in the logical address map for a page,
but there's a "not present" flag set and a disk address is
stored in the map instead of a physical memory address.
When the process touches the page, it gets suspended until
such time as the I/O can be done to bring the page into
memory. Then the mapping is updated to "present" and the
new physical address of the page, and then the process can
be resumed.
Sub S - 5 0 % OFF
S ig n u p to d a y a n d
I Sign up today an d S£
LI Sign up today a n d SAVE 50%
cuitcellar.com/subscription
TEST YOUR EQ Contributed by David Tweed
Answer 2—The PDP-11 family of minicomputers from
Digital Equipment Corporation (the first machines on
which Unix was run outside of Bell Labs) had 16-bit virtual
addresses, providing up to 64kB of memory per process
(128kB on some models that had separate I and D spaces).
The physical address was either 18 or 22 bits, allowing up
to 4MB of physical memory.
Similarly, the HD64180, Hitachi's contribution to the Z80
family of 8-bit processors, also had 16-bit virtual addresses,
but either 19- or 20-bit physical addresses, allowing up to
1MB of physical memory.
Answer 3— Virtual memory means that any memory
access made by the CPU might not succeed immediately,
resulting in what is generally called a "page fault," sometimes
signaled by a "bus error." The key feature required of the
CPU is that it must be able to suspend the execution of the
instruction that caused the page fault in order to service the
bus error, and then resume that instruction and complete it
correctly when the page has been loaded.
For example, this is the key difference between the
Motorola 68000 and the 68010 that followed it. The very
first engineering workstations were based on the 68000,
and they had to resort to some bizarre tricks to be able
to handle bus errors for virtual memory. Some went so
far as to include a second 68000 chip whose only purpose
was to handle the page faults while the primary CPU was
suspended, waiting for its memory access to complete. The
68010 has the ability to save enough of its internal state on
the stack so that it can resume an instruction in the middle
of execution, allowing it to handle its own page faults.
Answer 4— Virtual addressing can help with running
large applications. Instead of using "overlays" to handle
large amounts of program code, the application can be
divided into multiple tasks, each of which runs in its own
virtual memory space. The tasks can communicate and
synchronize with each other using facilities provided by the
operating system. For example, this is a key feature of Unix
running on a PDP-11.
circuit cedar
M€U-BASED COLOR
f D A T A ACQUISITION
CMK
 circuitcellar.com 61

The Directory of

Advertisers must furnish digital files that meet our specifications (www.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.

C Work shop Com pile r : ON LY $ 9 9 !

Professional grade, feature rich compiler
for a fraction of the cost

Full support for 13 popular processors

Perfect for students, hobbyists, or those

looking to learn C for PIC® MCUs
Add an a ddit iona l chip for $20
Sales@ccsinfo.com
(262)522-6500 Ext. 35
www.ccsinfo.com/cc1023

www.embeddedARIVI.com

TS-7100
NXP i.MX 6UL 696 MHz ARM CPU w ith FPU
Our smallest single board com puter

*jjembeddedTS
62 CIRCUIT CELLAR • OCTOBER 2023 #399

Gate-Drive Strength in EVs

Why Real-Time Variable Gate-Drive Strength Enables
SiC Traction Inverter Efficiency Improvements

ith the electrification of light vehicles and trucks replacing fossil fuels
as an energy source, the traction inverter is the most important power
conversion and delivery subsystem of the electric vehicle (EV) powertrain.
A traction inverter's role is to convert the EV battery's high-voltage DC
to the AC that the electric motor needs. The traction inverter controls the speed and
torque of the motor, and the efficiency of the traction inverter has a direct impact on
the power and thermal dissipation of the system, as well the EV's driving range over
a single battery charge. "Traction" indicates the act of pulling the EV over a surface in
coordination with the motor. As traction inverter power levels approach 300kW, reducing
energy losses throughout the drive cycle is the number one design consideration for car
original equipment manufacturers worldwide.
To improve efficiency, the industry has widely adopted silicon carbide (SiC) field­
effect transistors (FETs); the isolated gate drivers that power these switches, as shown
in Figure 1, have become more sophisticated, and now include isolated analog-to-digital
George Lakkas converter sensing, multiple modes of overcurrent protection, bias supply monitoring,
Product Marketing Engineer, gate monitoring, programmable safe states, built-in self-test and a new feature called
real-time variable gate-drive strength.
High Power Drivers Additionally, depending on the Automotive Safety Integrity Level (ASIL) functional
safety requirements, the gate-driver integrated circuit (IC) may have to be International
Organization for Standardization 26262-compliant, ensuring fault detection of >99%
and >90% for single and latent faults, respectively.
In this article, I will focus on the benefit of real-time variable gate-drive strength on
improving SiC FET switching losses and efficiency, and therefore extending EV operating
ranges.

SIC FET SWITCHING LOSSES

SiC FET switching losses are the total of the turnon (EON) and turnoff (EOFF)
losses, and they depend on the drain-to-source voltage (VDS), drain current (ID) and
switching frequency (fSW), as shown in Equation 1. The first part in the equation is the
turnon energy, the second is the turnoff energy, and multiplying both by the switching
frequency determines the switching losses.

t2 t4
P sw_T = j u(t)i(t) dt+ j u(t) i(t) dt ^sw
*3

HIGHER SIC EFFICIENCY

THROUGH REAL-TIME GATE­
DRIVE STRENGTH CONTROL
Modern gate-driver ICs have to turn
on and turn off the SiC FETs as quickly
as possible through a voltage slew­
rate control method (dv/dt), minimizing
the time (dt component) in Equation 1,
reducing turnon and turnoff energy, and
thus reducing overall switching losses.
This ability to control and vary the
gate-drive current strength provides an
FIGURE 1
EV traction inverter block diagram
impressive reduction in switching losses,
 circuitcellar.com 63

at the expense of increasing transient overshoot at the

switch node during switching, as shown in Figure 2.
The advantage of a real-time variable gate-drive
strength gate driver is that it offers designers the flexibility
to optimize their traction inverter designs for both efficiency
and transient overshoot mitigation.

WHAT IS A GATE DRIVER WITH REAL-TIME

VARIABLE GATE-DRIVE STRENGTH?
A gate driver that employs real-time variable gate-drive
strength has a dual split-output power stage.
The UCC5880-Q1 from Texas Instruments is a 20A
SiC gate driver that has advanced protection features for FIGURE 2

traction inverters in automotive applications [1]. Its gate­ SiC slew-rate control by varying gate-driver IC drive strength

drive strength varies from 5A to 20A, and is variable through

both a 4MHz bidirectional Serial Peripheral Interface (SPI)
bus or three digital input pins.
Both the OUTH 1 and 2 pullup and OUTL 1 and 2 pulldown
are split into two, as shown in Figure 3, allowing for the
installation and independent control of separate resistors.
The UCC5880-Q1 output is selectable between each output,
or the parallel combination of both, in real time using either
the GD* digital inputs or the SPI bus. Using the GD* digital
input pins makes it easier to set the drive strength at power
on without needing to use the SPI bus.

OPERATING CONDITIONS FOR VARYING THE

GATE-DRIVE STRENGTH
It is possible to realize SiC efficiency by varying the
gate-drive strength (through SiC FET slew-rate control,
FIGURE 3
as I discussed earlier) from the moment the battery
The UCC5880-Ql's dual-output split gate-drive structure
starts discharging (from 80% to 20%). Because that is
approximately 75% of the charge cycle, the efficiency gains
can be quite significant. A fully charged battery with a state
of charge from 100% to 80% should use a low gate-drive
strength to maintain SiC voltage overshoot within the limits.
As the battery charge decreases, using a high gate-drive
strength reduces switching losses and increases traction
inverter efficiency. Figure 4 illustrates a typical transient
overshoot vs. battery peak voltage and state of charge.

SELECTION CRITERIA FOR WEAK VS.

STRONG GATE-DRIVE STRENGTH
Selecting a weak or strong gate-drive strength depends
on certain criteria. If the load current is high (the motor
load increases with higher speeds, rapid acceleration or
FIGURE 4
deceleration), the battery is >80% full and the ambient Efficiency zone during battery peak voltage vs. state of charge

Weak gate drive strength criteria

r High load current (di/dt) f _ _ -------- *

► >80% peak battery k I
voltage at max charge ‘ y -•*
> Cold temperature G A T E
‘ w- f “ ’ — ‘
SOURCE
Strong gate drive strength criteria
> Low load current i
> <80% peak battery
voltage at max charge
> Ambient & Hot
temperature GATE­
FIGURE 5
SOURCE Weak vs. strong gate drive strength criteria
64 CIRCUIT CELLAR • OCTOBER 2023 #399

temperature is cold, then it's best to use a
weak gate-drive strength. If the load current
is low (which is true for the majority of EV
FIGURE 6
800V, 300kW SiC-based traction
inverter reference design data
Output Current [A]
driving profiles), the battery is <80% full,
and the temperature is room or warm, then
employ a strong gate-drive strength. The
control logic should include parameters such
as phase current, current threshold, and
external gate resistor values.
Figure 5 summarizes the criteria, while
the results in Figure 6 illustrate how the
combined drive with variable strength in the
High-Power, High-Performance Automotive
SiC Traction Inverter Reference Design enables
lower power losses in the power module,
maintaining stable thermal performance [2].
So, what does this mean for the ultimate
goal—longer range? Consumers choose EVs
today for their reliability, performance, and
looks, but range is an important decision
factor.

FIGURE 7 EXTENDING DRIVING RANGE

WLPT and real log-speed
acceleration histograms
and In tests performed with the UCC5880-Q1,
the strong gate drive strength enabled a large
reduction in SiC switching losses on an already
90% efficient traction inverter. Thus, the
efficiency gains can be impressive, depending
on the traction inverter's power level.
Modeling with the Worldwide Harmonized
Light Vehicles Test Procedure (WLPT) and real
drive log-speed and acceleration settings, as
shown in Figure 7, resulted in a 2% boost in
efficiency of the power stage, corresponding
to an additional 7 miles of range per battery
or perhaps a smaller battery for the same
amount of range at a lower cost.
Ml real

CONCLUSION
With EV traction inverters approaching
300kW power levels, the need for higher
reliability and higher efficiency is imperative.
SiC-isolated gate drivers with real-time
variable gate-drive strength are useful in
achieving these goals. The UCC5880-Q1
comes with design support tools including
evaluation boards, user's guides, and a
functional safety manual to assist you with
your designs up to ASIL D.

Additional materials from the author are available at: ABOUT THE AUTHOR
www.circuitcellar.com/article-materials
George Lakkas George Lakkas has been in the power supply
References [1] to [2] as marked in the article can be found there.
and power management IC industry for 33 years, having held
positions as a power supply test engineer, assistant design
RESOURCES
engineer, applications engineer, product marketing engineer,
Texas Instrum ents | www.ti.com
product marketing manager, and product line manager for power
management ICs. Since joining TI in 2006 George has worked in
various product marketing roles for non-isolated DC-DC conversion
solutions, and currently is a product marketing engineer for
automotive traction inverter isolated gate drivers. George lives in
Raleigh, NC.
 ©TDK

pPOL™ Chip-Embedded
Power Modules
A Simple Solution for High Power Density Applications

TDK pPOL™ DC-DC converters are compact and highly integrated

point-of-load converters for powering CPUs, MCUs, ASICs, FPGAs,
DSP, and other advanced digital logic devices, providing the high
performance, fast load transient response, and high accuracy voltage
regulation needed by these devices.

Technology Includes Inductor, DC-DC regulator with MOSFETs and Driver

Ultrathin: 3.3 mm x 3.3 mm x 1.5 mm or 4.9 mm x 5.8 mm x 1.6 mm

Plug & Play (No Compensation Required)

DC-DC Analog & Digital Bus Options (I2C / PMBus)

Current Output: 3 A, 4 A, 6 A, 12 A
REGISTER FOR
Wide Input Voltage (up to 16 V) A FREE pPOL
EVALUATION
Adjustable Vout ±5m V
BOARD
Output Voltage, ±0.5% Initial accuracy (Up to 5 winners)
 Powered by the NXP i.MX6 SOC w ith the Arm® Cortex®-A9
core, theTS-7970 industrial Single Board C om puter (SBC)
stands o u t from the crowd w ith its high perform ance
com ponents, connectivity options, and m ultim edia
capabilities. It's a general purpose, low -pow er SBC ready
to tackle dem anding applications including digital signage,
HMIs, data acquisition, Edge loT, industrial autom ation,
and anything in between.

3 8 0 0 MHz Solo or 1 GHz Quad Core Arm based CPU

to 2 GB DDR3 RAM

3 4 G B M L C e M M C Flash

TS-7970 3 S A T A II, MiniCard, DIO, ADC, ModBus, USB, CAN

NXP i.MX6 Arm® Cortex®-A9 ARM CPU
^ M u ltim e d ia Solution w ith HDMI, LVDS, and A udio I/O
Single Board Computer

* ^ M a d e in USA
h ^ ^ V w ith Global Parts ^embedded Io