Notes from the vault – 0x01 – Analog-to-digital converters (ADC)

Part of group NOTES FROM THE VAULT.

If you understand what 0x01 means (or $01, #01..) then there may be something for you here. I guess you also must like to.. just read, with little attraction from pictures. So, if you are intersted in a variety of detail, this may be for you.

This note (and I hope, series of notes) started on 20Aug2020 with a question in a mail:

“If I may ask, have you worked with in your career? I see you have worked with embedded systems and I am wondering how you got into the . I’m asking out of curiosity, since electronic engineering has a broad spectrum of applications it is nice to hear how a career in the field can unfold across different domains.”

I answered something like “You ask about  in my career. Thanks for the question! You gave me the idea of actually jotting down matters like that in my blog. Perhaps somebody out there might think reading it interesting, as I would, writing it. Simply because I am older than I used to be, and maybe something like this hasn’t been spelt out too extensively out there. And then, nobody has worn my shoes.”

I have no disposition. I have I, up to now, had no problem in finding other things to write about. But still, I might find something in my memory box. Even if I also have to respect my Work Disclaimer (here).

I did make some notes like this some years ago. Starting in 2004, here are 18 notes: Designer’s notes (here). I have also presented my career and some nitty-gritty detail in numerous lectures for students attending lectures in real-time, at the university here in Trondheim. Some of theme also in English (here).

The title mimics the “Tales From The Vault” in the IEEE Life Members NEWSLETTER (here and here). Alas, it’s one of the few paper magazines appearing in my wall mailbox. That one comes two times a year.

Analog-to-digital converters (ADC)

Disclaimer. It’s all re-collected from memory! Some of this may only be correct by way of “it must have been something like that”.

A voltmeter instead of a display

New 21Aug2020. Updated 23Aug2020 (ver.1.0)
This was in 1978. We were designing a start/stop control unit for emergency power units. Our own electronics boards were in a rack in a large cabinet, together with enormous contactors for high power. They were placed on a lot of mountain tops in Norway. Usually the radio equipment got power over a mains connection, from the valley. But there were backup batteries, I think of type NiCd. When power from the valley failed, there was to be a minute-settable delay. Then, both minimum mains voltage (like 180V AC) and maximum voltage (like 250V AC) were settable. Also, how many minutes the power generator, which was started after the initial delay (with three retrials), should run after the mains reappeared (since it could fail immediately again when power was switched back). The door of the cabinet also had several switches, for on/off inputs to the SW, but also to bypass the whole control unit.

This was Autronica’s first product containing a microcontroller. We decided to use an Intel 8048 type. At that time the Intel 4004 was still used. My boss did not want to buy an Intel Intellec station, so we ended up with a Prompt-48. I had to write in assembler. No conditional jumps over the four 256 byte pages. Yes, it is true! 1kB altogether! (A few years later we indeed bought several Intellec “blue boxes” and coded in PL/M. Good machines – before the IBM PCs.)

There was no display and no keyboard in our start/stop box. No ADC converter. So I made a successive approximation AD converter with 8 resistors taken high and low with some CMOS logic, controlled from the controller. We did have 1% resistors, which we thought was excellent, and I had a fair sample and hold circuitry and a fairly good op-amp (741, I think) as a comparator. Speed was no issue, but a complete conversion, I think, was around 10 ms. And I used a CMOS mux (multiplexor) in front of the circuitry, to switch between inputs. I was in no position to test the accuracy or linearity, but I did have a good memory scope (the memory was in the screen’s afterglow), where I could indeed see how even the lowest bit did change when I thought it should.

As mentioned I wrote the SW in assembler. I remember I had a very long paper, glued from several landscape A3, showing the flow diagram of the complete code, not only of the A/D converter. I think I saved it. I’ll try to find it and photograph it.

Analog inputs were from voltages and pot-meters (potentiometers are variable resistors). We had scales in minutes and Voltage, around the screw-slotted pot-meters. But we also had banana contacts for each. The service personnel who were going to set the values used their digital meters (yes, we all had some very nice ones, with dixie-tubes) and a screwdriver. 180V AC was 1.8V. 30 minutes delay probably also was 1.8V.

The good thing is that be setting the values like this we didn’t need any EEPROM in the product. We could burn the 8048 in the Prompt-48, but the 8035 had external EEPROM. We had to burn it in a large box, from Intel Hex files.

I think the processor stuff and SW had a working life of about 15 years. We had no updates of the SW. But I seem to remember that there was one fault that was considered not critical.

Using a ∆Σ-converter

New 29Aug2020. Updated 18Oct2020 (ver.0.91)
This was in the late nineties. Up to now I have thought that such ADCs were called sigma-delta converters (ΣΔ), but now I see that Wikipedia has an article called Delta-sigma modulation (ΔΣ) on the theme (here). Even if they are also called ΣΔ modulator (SDM), I will continue to call them ΣΔ sigma-delta converters.

The sigma-delta converter in mind was used in the third microprocessor-based version of this product. But before this I will take a detour. There’s more to the story than analogue-to-digital conversion.

The first product was in the middle of the eighties, based on Texas Instruments TMS9995 processor and (I think) ADC via their serial (CRU) bus. We programmed in Microprocessor Pascal (MPP) that was shipped with a scheduler, and an accompanying task abstraction, albeit at a rather low level. This was my not my first encounter with tasks, but it was the first time I saw it included in the package. Per Brinch Hansen had done a good job with initial theoretical discussions.

We had a single box with floppy disk, a colour CRT screen and buttons, plus all the electronics. And two big handles on each side, taking on the appearance of the time’s oscilloscopes. There was one for every main diesel combustion (not turbine) engine on ships. Those motors that fill much of the hull, over several floors.

This was the Autronica NK-10 engine condition monitoring system “MIP calculator”. Medium Indicated Pressure is a measure of delivered power, and the instrument had been pioneered by Autronica in the early seventies, I believe. It also monitored the piston rings. It was meant to help keep the propulsion engines well monitored and consequently, working. With the intention to avoid fatal incidents, such as the one that almost happened with Viking Sky, just some km from where I write this right now – when she was that close to rock bottom. Losing engine power is no joke for any large ship, let alone a cruise ship, full of passengers.

Next and second version was NK-100 and we had switched to PCs. We waited for Windows 3.1 with windows and a mouse,  and now we would only need one PC box for the entire multi-engine system. Autronica had Thor Vollset (of Tordivel AS) do the GUI code in Modula-2, which ran on the PC. (Aside: more interesting stuff about about Thor here and here). My role was more under the hood. We used a LonWorks network between the remote data aquisition boxes and the PC. With NK-100 GUI clients running on the PC, programmed in Modula 2. We used smaller transputers (T222 16 bits machine, by INMOS) to do ADC in the remote boxes and a T805 32 bits floating point transputer plugged into the PC to do the calculations. (We still seem to have been shipping these systems as late as 2001 (here)). We bought an ADC board from a small company in Scotland (they were called Sunnyside), and I can’t remember the ADC type. But I think it was a standard, fast ADC – since our around 1000 samples arrived from the board as already being equidistant in time. The distributed multi-core system was programmed as one system in occam 2. It changed my life. The LonWorks network was transparent to the occam code, and occam’s configurer took care of placement of the code on all the connected transputers. I now had transputers with built-in scheduler in the silicon. It had synchronous communication over channels, between processes (the occam term for task). Context switching time was less than a microsecond. The whole distributed multi-core system was all compiled on my PC, on a main transputer plug-in board. I just loved the work that INMOS and University of Oxford had done. Thanks to David May and Tony Hoare. We were in the early nineties.

But alas, the transputer technology went down the same lane – as too early technology often does. The T9000 transputer was not the success INMOS had hoped for, and it was difficult to scale up towards 50 MHz. I think they had problems with the design with distributed common internal clocks – as the DEC Alpha processor’s probably solved better at that time. But the T9000 links later evolved into IEEE 1355 serial interconnect standard – and SpaceWire. And the T800 and T9000 later evolved as ST20 series by STMicroelectronics, used in set-top boxes and GPS. [WIkipedia: transputer].

Our third design was therefore based in a Texas Instrument TMS320C32 DSP. The product was called NK-200. The code base in occam was kept, since som guys at Southampton University had developed a fantastic occam-to-C translator, the SPoC. Thanks to Debbage, Hill, Wykes and Nicole.

Aside-1: With the occam toolset itself, the SPoC (both then), the XC compiler and WordPress (both now) are the softwares that have impressed me the most over all these years. Plus, even Apple Pages (also now). But then, there is so much fantastic software out there.

I designed a PC/104 board with this stuff. We wanted more bits on the analog side and they had to be picked up faster, since we were to follow up at higher speed engines. I think like 1500 RPM, which was fast for ship’s main engines. We needed two channels, since we picked up both the combustion pressure and the injection pressure. As always we needed to interpolate and correlate the equidistant in time samples to equidistant in half degree angles of rotation. We picked up angular position from 30 iron pins plus one reference pin, bored into the flywheel of the engine. There was a lot of mathematics. But we could measure cylinder after cylinder, that was ok. The total kW delivered was always the sum anyhow.

Asides-2-4: The PC/104 board also contained a dual-port RAM memory that kind of started my technical, public writing. A protocol I developed was written down in an article in the EDN magazine in June 1996 (here). We had at first included that solution in another product. Too bad that the money I received from EDN, that I had stupidly saved, as cash in an envelope, was stolen in a burglary here at home. Sad, because it was about the only time that I got compensated for my writing.

Two channels? Fast? This was still when magazines and books did the info job for us. Sigma-delta stereo converter? Those cheap things used in stereo boxes, like for microphone inputs? Record players were loosing ground, but I guess these also had been used to convert data from magnetic pick-ups. I figured that yes, that was quite possible. So I designed one in.

However, making them very linear in time was not as easy as I thought. Interrupts could be used, but there were other interrupts and I realised that the flutter would become just too large. DMA to the rescue! I could start the ΣΔ converter to deliver all my values over DMA, and I only had to handle a single interrupt when all values were lined up in memory. This worked even if the converter delivered its two channels over two SPI serial lines. From my interrupt an occam channel would signal an occam process to process those samples.

Being quite some years away I find it rather hard to recollect much more. But I think I have the code somewhere in this vault. Update: I found it. The 18 bits SAA7367 (from Philips Semiconductors) chip of type third order sigma-delta converter we sampled in stereo at 39.0625 kHz. There were two DMA buffers of 1000 samples each, so that I did not need to treat an interrupt every 25.6 µs, but instead every 25.6 ms. I can’t wait to study the occam code again. It’s been so long..

References: SPoC (as also used on another of Autronica’s products). PC/104 (not PC-104) (here). SAA7367 sigma-delta concerter (here). Transputer: here. Our PC/104 board: here. Viking Sky incident 2019: here.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.