Go here to sign up for The Embedded Muse.
The Embedded Muse Logo The Embedded Muse
Issue Number 462, January 16, 2023
Copyright 2023 The Ganssle Group

Editor: Jack Ganssle, jack@ganssle.com

   Jack Ganssle, Editor of The Embedded Muse

You may redistribute this newsletter for non-commercial purposes. For commercial use contact jack@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email.

Contents
Editor's Notes

SEGGER embOS-ULTRA

Tip for sending me email: My email filters are super aggressive and I no longer look at the spam mailbox. If you include the phrase "embedded muse" in the subject line your email will wend its weighty way to me.

Here's the latest on industrial prisons, uh, open offices. They discourage productivity and pretty much everything else required for creative work, so, of course, these remain popular.

This article, once again, shows how interruptions are the worst productivity killers. Remote (e.g., working from home) environments rock!

Quotes and Thoughts

“We exist in a bizarre combination of Stone Age emotions, medieval beliefs, and god-like technology,”

E.O. Wilson, sent to me by Duncan Peterson
Tools and Tips

Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past.

Freebies and Discounts

Jacob Beningo is graciously giving three copies of his new book away to Muse readers.

Enter via this link.

Comments on Audio Telemetry

A lot of readers replied to the article on Audio Telemetry in the last issue.

John Carter wrote:

My first job involved a Perkin Elmer lab computer, analysing hundreds of Beta ray spectra recorded on ye olde mag tape reels, the results were recorded onto ye olde removable disk packs large enough to contain a  large christmas cake.

I knew exactly which phase of my program was executing by the way the tape drive "nodded" or "walked" or "ran backwards". I knew what part made a "shhk! shhk! shhk! " sound of the head in the disk pack seeking, or the tik, tik, tik of it streaming data out as the head "tik'ed" one track on.

In later years, PC's had a remarkably simple and reliable "Beep" speaker api.... so I used those tones to represent events.

Alas, now most devices have _much_ more capable audio, but lack a simple direct synchronous "beep" api. Now the only audio hint is that the cooler fans sound as if the machine is trying to take off.... very crude and low resolution.

In the embedded realm we often use LED's to flash events, but you have to pay continuous attention to it, and you don't get the subconscious "that sounds wrong" heads up warning.

Charles Manning remembered debugging decades ago:

Your piece on alternative debugging brought back some memories from the 1980s.

As you say, source code debugging was rare, even on computer platforms - let alone embedded. $5000 to $50,000 (real dollars back then) debuggers were out of the reach of many  organisations - let alone being one-per-desk or owned by hobbyists.

While the good old LED was ubiquitous, there are two debuggers of the day that I remember fondly:

The chirping power supply: Back then it was common for the inductors in power supplies to whistle and chirp.  At one workplace we had a workstation with a chirping power supply that made a different tone depending on the load. It squeaked and squawked as it executed code. You could hear it looping through code. This was really helpful for debugging hints. Unfortunately the computer went in for a service and they gooped the ferrite - no more debugging.

At one place I worked, someone hooked up two DACs to the top 8  bits of the address bus then attached the outputs to a scope (linear scopes back then) in X/Y mode. As the CPU executed, the address was translated into two 0 to 15 values causing the dot to dance about the screen following the  execution of the code. It was remarkably useful.

One of the problems trying to replicate those ideas these days is that address spaces are larger and CPU speeds are higher. On top of that caching hides the address buses etc.

The Good Old Days?? Naah, I'll take my modern desktop thanks!

Clyde Shappee mentions an HP logic analyzer. I googled the part number, which showed what has happened to HP: a printer showed up. He wrote:

Your statement about using our ears as debugging tools strikes a couple of chords with me.

One, is back in the day, one hooked a logic analyzer on the processor.  I was told to hook up 16 wires on the address bus.  The analyzer (HP1610) had a mode which would display the data in an X-Y fashion.  Lower 8 bits on the X axis and upper bits on the Y.  I never had much luck with this, but the patterns could reveal a wildly off instruction flow.

The other was having an old Kodak lens (fast! f/7.7) cleaned, lubricated and adjustment of the shutter timing.  I got to watch the man do it.  It was incredible.  At the end, he fired the shutter twice at every speed and reported that he was done, it was all set.  I asked "Aren't you going to time the shutter?"  His response was "I already have.  I can hear it that it is on.  Take pictures with it and you think the timing is off, we will take a look".

This was the late Steve Grimes, noted camera repair person.

Of course, the shutter timing was spot on.

Does anyone remember signature analysis? My creaky brain can't remember the vendor who promoted this, but it was a cool idea. One reader wrote:

I'm old timer who do HW/SW for some time and your 'tone based debugging' reminded me 2 things - one is using lamps (incandescent at that time) that was connected to this or the other line and that was providing visual 'blinky' interface for debugging HW/SW. Idea was simple - eye is also good in recognizing patterns. Second thing returned me to the school (well... to the WUT  in fact) - at that time Signature Analysis diagnostic technique was fancy and on the top. In fact that is also about cycles and distinguishing differences.

Why SA and EMI based techniques are not used? Except for lack of precision and need for training on working units there is also issue with current multitasking / multicore designs where there are thousands of processes running at the same time..

Dave Brooks sent the following, which is about a computer I had never heard of:

Back in the '60s we did just that. The Elliott 803 (first machine I learned on) had a monostable connected to a speaker, triggered whenever a successful branch was taken. The 503 (same, but faster) had a prescaler between the mono & speaker, otherwise the same. We quickly learned the sound of a "good" run.

Fabrizio Bernardini wrote about "sonification":

Your comment on “audio telemetry” made me think about a couple of things.

One is the fact that, in science, audio conversion of data sets is indeed used to “get a feeling” about the data themselves, maybe to discover patterns or even outliers in the data. The process is called “sonification”, and you can read more about that here: https://en.wikipedia.org › wiki › Sonification

The other is about the actual use of audio telemetry in many, if not all, artificial satellites in the early stage of space exploration. In the attached image you see the avionics architecture of the first Italian satellites, called San Marco, which produced essential data about the upper layers of Earth’s atmosphere.

Three sensors (Bilancia X, Y and Z) measured tiny atmospheric drag components from the ingenious “Bilancia di Broglio” (out of scope here). The three values modified the frequency of three sub-carrier oscillators (Oscillatore Sottoportante) that got mixed together to modulate a Telemetry Transmitter (Telemetria Trasmettitore 136.52 Mcycles, MHz today). A separate sub-carrier was used for other telemetry data, with a Pulse Amplitude Modulator (PAM).

Similar arrangements were used in other satellites. Many of them used audio frequencies for the sub-carriers to be compatible with existing communication equipments. At that time it was reasonably easy to receive these signals and the weird-sounding audio signals they generated, but you could not decode them unless informed about the design of the specific satellite.

Remember squealing modems? Larry Marks worked on them:

For a few years I was responsible for the design of fax/modem products in PCMCIA packages, an interesting challenge from several aspects including the mechanical problem of getting an isolation transformer to fit inside a package with an external thickness of 5mm (about 1/5 of an inch). My responsibilities included the user publication.

Modems are kind of opaque to the consumer. You open the application and after a bit the connection completes--or it doesn't. Unlike Ethernet, you can't Ping, or Netstat, or Ifconfig.  But there are a bunch of useful sounds. After a while I learned to whistle the (ITU-T Recommendation V.8) negotiation sounds (mating call) of a Group 3 fax machine--at least far enough to send it off to never-never land. Got pretty good at modems, too. 

  • I insisted that a troubleshooting guide like the following be inserted in the User Guide.
  • From a terminal, issue ATL3M1 [enter]. This sets the modem volume to Loud and disables Mute.
  • Start your app.
  • Did you hear the modem go "off hook?" Did you hear Dial Tone? If not, is the modem plugged into the telephone jack? Is the jack live? Plug a telephone into it and check.
  • Did you hear the modem begin to dial? Was it sending touchtones? Did the dial tone stop as soon as the first tone was sent? If the dial tone persisted, this may be a line that only accepts pulse-dialing. Change the modem setup string in your app from ATDT to ATDP for pulse dialing and retry. After receiving dial tone, the modem sound should be series of clicks, like a rotary-dial phone.
    ...

Just realized this was about 30 years ago...

Bob McKillip sent this:

Your section on acoustic monitoring brought back memories of tuning a telemetry system that processed some UAV flight data in real time using MATLAB. Since the MATLAB code is not compiled, I struggled to determine the optimal mix of buffer length of TM data to process once it was received, to get timely turn-around on displaying and saving the data.  When I realized that the baud rate was in the audio band, I coupled a RadioShack amp/speaker to the RS-232 pin to listen to the bits, and adjusted the buffer to minimize the gaps between the noise to ensure I was capturing and processing as much data as MATLAB could handle in each buffer.  It felt somewhat Frankenstein-like but satisfying to hear the data coming through while updating the displays with the monitor.

The Computer History Museum has a working IBM 1401. Mike Cheponis worked on one:

I've been doing this since my 1st computer, the IBM 1401, where I was able to tell which compiler phase my compiler was in, and other things, such as when it got into infinite loops due to bugs, simply by 'listening to the radio'.

One would put an AM radio near (on top of, usually) the external Core memory box, and out would come your 'debugging info', like this:

https://youtu.be/myt6DApmiv0

And of course, the 1620 boys couldn't be far behind, and perhaps I'm a little late for this holiday season, but.... https://youtu.be/rqrA7jdj23U

So, heck yeah, we've been doing audio debugging this way since the 60s, at least.  In our case, it 'came for free' - so why not?

Bob Paddock uses Morse:

Many of my products use Morse Code to communicate status, calibration and error messages. There are Apps that will decode it for those that can't do it by ear.

Real Soon Now I'm going to switch to BPSK or one of the many newer audio based digital transmission systems used by Ham Radio operators.
Programs like FLDigi can be used to decode them.

http://www.w1hkj.com

I could never get past the 13 words/minute Morse requirement for an Advanced ham license; Amateur Extra needed 20 wpm. Now the code requirement is gone and the Extra license is a pretty trivial 50-question multiple-choice test.

And finally, channeling the Greek's and Kepler's musica universalis/music of the spheres, Gennaro writes:

Just as perfect pitch exists in music, I wish I were an engineer who only by listening to the "music of the firmware" can hear where the problem is! What a wonderful job!

They Are Watching You

… Every breath you take
And every move you make
Every bond you break
Every step you take
They'll be watching you

… Every single day
And every word you say
Every game you play
Every night you stay
They'll be watching you

… Oh, can't you see
You belong to me?

- The Police, slightly modified

A couple of months ago I built a PC. Over that brief time my web surfing resulted in thousands of cookies assaulting the machine. A few are useful to me, generally for saving logon credentials. Most give me no value, though the sites' operators feel they are allowed to store their crap on my computer. (theweek.com, which has great cartoons and nothing else of value, dropped an astonishing 63 cookies in a three-second visit to the home page).

For fun I cleared my cookies and then clicked on the home page of some of the EE sites I visit.

"Site's Value" is my very subjective take on the site's usefulness, ranging from 0 (no value) to 5 (worth every visit).

Site Cookies Site's Value (0 to 5) Comments
electronicdesign.com 13 2 Site too busy; too much video content; strange layout
embedded.com 12 2 Too few interesting articles
edn.com 12 5 Always useful, has hard-hitting EE content, love the schematics
linkedin.com/groups/4023060/ 12 0 All social media; no tech content
eetimes.com 10 2 Used to be excellent; now little tech content
eejournal.com 5 3 Steve Leibson's articles always great; little else useful
ieee.org 4 4 Superficial but some interesting stuff
embeddedrelated.com 2 2 Infrequently updated but some good stuff
shape-of-code.com 0 4 Wonkish but thought-provoking
blog.adacore.com 0 3 Often good MCU content

I can understand a cookie or two, but a dozen?

Electronicdesign.com asked for permission to drop cookies. I did not accept, yet those 13 cookies appeared.

Plotting cookies vs. value one finds that (edn.com, the rightmost point, is an outlier) value inversely correlates with the number of cookies:

The dotted line is a trendline (y = -1.326x + 10.58).

They are watching you!

GE Transistor Manual

In Ogilvy On Advertising David Ogilvy claims there are three magic words in the ad world. Put one in the headline of your ad and people will read it. The magic words are new, free, and sex.

But the sure way to get my attention when flipping through a magazine is to have a schematic diagram. Any kind. A radio. Vacuum tube circuits. Logic. Piles of op amps. For some reason I find schematics arresting and always stop and take a closer look.

Clicking around the web recently I stumbled across some vacuum tube sites, which brought back fond high school memories of building tube ham radio transmitters. Everyone relied on the RCA Vacuum Tube Handbook as the bible for specs on the parts. Wouldn't it be cool to find an old copy? And wouldn't that be utterly pointless? That thought morphed to memories of the other indispensable tome of the time: The GE Transistor Manual. Not too many clicks later and one was on its way here.

I ordered the 1964 version. What’s astonishing is how much was known about transistor theory by that date; transistors had been in common use for just a handful of years at the time. And this is the seventh edition! Yet it explains transistor theory in a level of detail that my college classes a few years later never approached. Read - and understand - the first 170 pages and you’ll be a transistor expert. But no attempt is made to make the subject easy.

The price on the cover is $2, though it cost me, used, $6.98. Alas, the one that arrived is the “light-weight edition,” a 594 page subset of the full-blown one I remembered. The light-weight version is missing all of the detailed specs of the transistors GE once made.

The GE Transistor Manual was, and still is even though it has been out of print for generations, one of the best compendiums of information about designing transistor-based circuits. Part of its appeal was that it’s just stuffed with schematics of every conceivable kind of circuit. One can get lost for hours and days studying the cool ways the authors crafted designs with an astonishing economy of parts. It’s engineer porn, graphic illustrations that makes one’s heart beat a little faster as one furtively flips from page to page, looking at the pictures while pretending to read the story.

Old timers will remember the unijunction transistor. There’s an entire chapter dedicated to its use. These were used in timer circuits in the pre-555 days. UJTs are still available, though it has been a very long time since I've seen one in use.

But there’s no discussion at all about FETs, which today represent, to a first approximation, 100% of all of the quadzillion or so transistors made every year. Though FETs existed at the time, they enjoyed little commercial success, and even into the 70s were seen as niche products. Their exclusion from this book suggests that GE did not make any at the time.

Some of the components discussed are obsolete. Or, at least I thought they were till checking the web. Stabistors, for instance were low-voltage zener diodes, but it seems these are still available, and one can even get them in modern SOT packages. Are SNAP diodes still around? There’s a good description of them in the book.

Those who enjoy tech nostalgia - or schematics - will get a kick out of the book. If you want a deep look into transistor theory and use, this is a great resource. Copies can be found on various used book sites. Turns out,  it's online here.

Failure of the Week

Justin Clark send this image of a blood glucose meter that will order new supplies. I wonder... should one expect a delivery?

A NaN from UPS, sent in my Daniel McBrearty:

Have you submitted a Failure of the Week? I'm getting a ton of these and yours was added to the queue.

Jobs!

Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.

Joke For The Week

These jokes are archived here.

I started a band called 999 megabytes.

We still haven’t gotten a gig.

About The Embedded Muse

The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com.

The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster.