Just recently, cuflow has gained the ability to generate 3D previews, just like real PCB CAD software.

Even better, the previews are a simple web page. Take a live look here.

If I’d had this view when designing TermDriver I would surely have noticed that the EXCAMERA LABS text is covered up by the header. Oh well.

The slider at the side strips down the layers. Here’s the copper:

Then the solder mask. The traces underneath are still visible if you look closely.

Then the silk screen:

Then the paste mask. I’ve messed the paste mask up a few times in the past, and it’s not always clear in a gerber viewer, so this is a valuable view.

One nice detail; the paste is slightly thick, about 0.050 mm, just like the real thing

And the components, of course:

A few things have come together to make this possible:

• Browser 3D support is much better than when I started cuflow six years ago. three.js in particular seems to work everywhere.

• Models for parts are available on LCSC, and the Python package easyeda2kicad downloads them, well, easily.

• Of course, agentic coding means this somewhat daunting side-quest has been really just a quite pleasurable series of aesthetic tweaks. For example, there has been a lot of back-and-forth on lighting and materials setups.

Thanks for reading.

These are four little simulated indicator lights in the corner of the TermDriver2 display. The top two (TX, TX) flicker and light up as traffic flows, and the bottom two show the current state of the control lines.

On/off didn’t seem good enough. For TX and RX in particular, I wanted the lights to remain on for longer than the transmission time, otherwise you can easily miss the flash. (FTDI’s UART chips do the same; they implement a pulse stretch on their LED outputs for just the same reason.)

But I also wanted a more analog feel to the lights. Something like the wonderful indicators from the Apollo era.

So to start with, no more instant on/off. Incandescent bulbs don’t work that way. Each of the four lamps is animated from off-to-on in 16 steps:

The firmware keeps a 0-15 counter for each lamp. If the signal is on, it increments the counter by 5, and if it’s off it decrements it by 1. So the lamps get brighter a lot faster than they get dimmer. This produces a nice bulb-like time response.

A single byte produces a perceptible but dim flicker. A steady stream of traffic produces maximum brightness. When the traffic stops, the bulb takes about 1/4 of a second to go fully dark.

But that’s not all. The bulb graphics themselves (which are a very tiny 24x16 pixels) contain a surprising amount of detail. First, the outline isn’t a simple round-cornered rectangle, it’s a superellipse, beloved by geometry fans for their pleasing curved outline.

The brightness isn’t flat across the lamp. There’s a quadratic falloff from bulb-center to bulb-edge. You can see it in the three colored lamps most clearly. The center is fully bright, becoming less saturated towards the bulb edges.

But again that’s not all. There’s a final pass that adds a Gaussian glow to simulate the bright light of the bulb starting to leak through the black text, making it appear brighter.

And of course all these steps are rendered at 96x64 resolution, then filtered down 4x to the final 24x16 that’s used in the hardware.

Overall I think I spent a whole afternoon getting the bulbs looking this way. Time well spent? My feelings on this are a bit complicated. In 2024 when I did it, perhaps not really. There was a lot of other work I could have been doing: getting the TermDriver2 firmware ready, writing test suites, doing acceptance testing.

But in 2026? Yes, very much so. A lot of that other work can be automated. Writing pretty good test suites, for example, is no problem for coding agents. But the aesthetic work can’t be automated. And all of the decisions I made above were matters of taste. We have taste, and exercising that taste in places where it shows seems like time and effort well-spent.

Thanks for reading.

In the non-movie world, we make prototypes. Some rules:

• At least one prototype before production

• Not too may prototypes

• You don’t ship the prototype

I’ve worked at places that broke all these. Maybe you have too. But here at Excamera Labs, we do it right!

I normally break prototyping into two parts. The “works-like” prototype is functionally the same as the final product, but doesn’t look like it. It usually looks like a mess. You show it to people and then ask them to use their imagination.

It may not impress bystanders, but the “works-like” prototype is where it all happens. The firmware gets written. Any impossible design decisions get exposed. First usability feedback comes in.

These days I don’t use breadboards. Every Excamera Labs product consists of a microcontroller and some peripherals. So I use a Python generator that puts them on a PCB together. The PCB is 100mm x 100mm, the maximum size for cheap JLCPCB 2-layer boards. There’s no clever signal routing, just a dumb bus running from microcontroller to the peripherals.

The RPi pico is on the left. Every trace is broken out into a big East-West bus. The peripherals are plugged into it on the North and South edges. Electrically and physically it’s far from ideal. But it does function just like the finished article, while design time is very short. Design time is short because this board is a shopping list:

def spiq_2():
    nm = "spiq_2"
    pb = Protoboard(nm)
    pb.logo_center = (83, 13)
    pb.mcu_pico(flush = True)

    pb.add_module(Module_LCD240x240)
    pb.add_module(Module_spiq_pwr)
    pb.add_module(Module_spiq_ios)
    pb.add_module(Module_Serial_Debug, (56, 4), 180)

    pb.finish(mount_holes = False)
    pb.save(nm)

The Python program lays them out. The most recent board came back yesterday. It looks like this

I did a quick check for shorts, then soldered in the three important things: the microcontroller (a RPi Pico), the debug header and the LCD panel.

Does it work? Initially I thought that answer was a resounding no. But after 25 minutes of investigation, I discovered that I had made a bad solder connection to the panel’s VCC contact.

The panel is alive, and the firmware is loadable over the debug connection. Excellent progress. I’m waiting for some parts for this section:

Which is a fairly high precision I²C current sensor using the TI INA226. More on that next week, hopefully.

If all you have is a hammer, everything looks like a nail

For me, software has changed a lot this year. Agentic coding tools have got really good. When I give the tool a contained task on an established code base, it usually does a great job. (It usually does a slightly better job than I would have done, to be honest.)

I decide how the task gets broken down, and what the steps are. The agent does the coding, in steps that usually take a few minutes. I know some people let it run for hours, but my experience has been that it lacks good taste, and when unsupervised will write code that’s hard to follow. Or “slop” if you prefer.

Having a tireless assistant means that more gets done every day. By quite a margin. Writing software has got cheaper. However, non-software tasks remain as they were before. So their cost relative to software has increased.

So there’s now a strong incentive to make every project look like a software project.

Normally, PCB design is a CAD task, not a software task. At least for most people. But for many years now I have been playing around with cuflow, a software PCB design system.

cuflow is a Python program that draws the PCB, then outputs the Gerber-format design files. There’s no CAD step. Just Python code to place components and trace out wires. cuflow has a lot of conveniences to make layout somewhat automatic, but it’s still been quite laborious. For example TermDriver’s PCB ended up about 600 lines of Python and took me about a week to finish in cuflow (source).

But not any more. Now I chat to the agent, it edits the Python, runs the generator, looks at the output Gerbers, and iterates until it’s got a good layout. This morning I’ve been wiring up a USBC connector for the first time, and this is the kind of thing I’ve been saying to the agent.

And that’s how layout goes. The agent doesn’t only think about layout and code; it also knows how a USBC connector works. Which is more than I did, to be honest.

The code it’s generating is not too bad. Here’s the block that connects the two USB GND pins to the ground plane using extra-wide wires:

        power_width = 2 * self.board.trace
        for name in ("A1/B12", "B1/A12"):
            self.s(name).setwidth(power_width).w("o -")

This seems fine, that’s probably how I would have expressed it.

It’s all working very well. I don’t know if conversational interfaces for PCB CAD software exist right now, but it does seem that’s what I’ve accidentally arrived at.

I’m not suggesting for a moment that you design a PCB in cuflow. But if there’s a project that’s current not a software project, and could plausibly be turned into a software project, there’s never been a better time to switch and reap the rewards.

Thanks for reading.

Excamera Labs shop note: the ever-popular SPIDriver is back in stock.

Your PCB comes back. You put a microcontroller on it. It powers up, wonderful! Then you start testing all the pin connections. Maybe there’s a bad solder joint, a short, maybe you even messed up the design?

Subscribe now

It’s an important step, and being certain of all the GPIO connections before connecting any peripherals is a lot better than crossing your fingers and carrying on.

But how do you check the signals? I guess everyone has their own method.

What I used to do until yesterday was write a little hack on the microcontroller to toggle each pin, and then probe the signal on the PCB. After confirming that it toggles, I’d change the code, recompile, and test the next pin. A laborious process.

Well not anymore, now that I have gpio-announcer. It’s a tiny CircuitPython script (or dedicated .uf2, see below) that drives all the GPIOs simultaneously, each one saying their name at 115200 baud. All you have to do is connect a serial converter (e.g. the wonderful TermDriver) to the signal and it literally shouts its name nonstop!

Here the RP2040 Pico’s pin GP14 is being probed, and the string “GP14” is continuously being sent out at 115200 baud.

This is the development board I wanted to check out. I can just quickly probe all the hookups, confirming each one against the schematic.

Pretty handy. The script has a little bit of smarts. It first probes every pin, and only transmits the pattern on ones that are floating. So if the PCB has a GPIO already hooked up to an input, that’s not included in the test pattern.

It’s directly inspired by this FPGA implementation by Alex Forencich in 2023 (youtube, and github repo pin-uart). As far as I could find out there wasn’t an existing RP2040 implementation, or indeed much else for any microcontroller.

If you’re familiar with the RP2040, you might be wondering how it makes every pin function as a serial output, when only a few of them (the UART TX ones below) support hardware serial out.

The code uses a tiny PIO program to send out data on all pins at the same time. Codex and I wrote it together over the course of an hour. The implementation is brutally simple: it blasts the different bit patterns out across all 23 GPIOs at 115200 Hz.

Codex also made a C port thats in the repository under pico/. That single C program builds gpio_announcer.uf2 that’s in this release. Just drop it into a blank RP2040 and it will announce its pins.

Thanks for reading.

• The Silicon Labs workhorse EFM8 microcontroller, used in SPIDriver and I2CDriver

• The WS2812B RGB LED, better known as the Adafruit NeoPixel

• The CH32V003 RISC-V microcontroller, famously priced at about 10¢

• DHT11 / DHT22 / AM2302 temperature-humidity sensors

• Dallas / Maxim 1-Wire devices, like DS18B20

They’re all configured with a 1- or 2-wire protocol that requires timed pulses. Because pulse shape and line turnaround are timing-critical, they require custom low-level code on a microcontroller to implement the protocol.

Here’s an example I was looking at recently. It implements the debug protocol for the CH32V003, in AVR assembly. It’s technical, fiddly stuff. I’ve written my share of this kind of thing over the years.

But all these protocols aren’t so different, really. They all specify pulse high and low times, within a certain margin. For instance here’s Adafruit’s documentation on the NeoPixel 1-wire protocol.

Imagine you could write some CircuitPython that did this:

import pulsetrain

pt = pulsetrain.PulseTrain(board.GP0, 2_500_000) # each tick is 0.4 us
code0 = "HLL"
code1 = "HHL"
pt.drive("H")              # line high by default
pt.drive(code0 * 24 + "H") # set neopixel to black, 24 zeroes
pt.drive(code1 * 24 + "H") # set neopixel to white, 24 ones

You wouldn’t need to count cycles; pulseTrain takes care of the bit timing. Each call to pt.drive() guarantees a precise pulse train. The control string is made of single characters for line operations, and integers for pauses.

• L line low

• H line high

• z tristate bus

• i read input

• n delay n ticks

Some examples, rendered with the excellent wavedrom. A single pulse

A repeating 7-tick square wave with a 4:3 duty cycle

Two single cycle high pulses separated by 8 low ticks.

So much for output. Input uses the “i” code, which samples one bit from the line. The library packs these bits into bytes which can be read out with pt.read(). So a protocol that sends a pulse then expects a transmitted bit (like the microcontroller 1-wire debug schemes), we have:

H L z i

Which outputs a high/low pulse, then tristates the line and reads a bit.

Currently the implementation runs on RP2040 CircuitPython. It only supports a single I/O line right now, but it seems not too difficult to get it running with 2 or more lines. It doesn’t have any external dependencies. It’s in https://github.com/jamesbowman/rp2040-circuitpython-pulsetrain. There are a couple of examples there. example-neopixel.py drives the neopixel strip in the photo above. example-ch32v.py is a simple but complete programmer for the CH32V003 microcontroller.

The implementation uses RP2040’s PIO block, and was, ah, interesting. PIO is hard, and I’m feeling that PulseTrain is an easier way to get results. The library is a work-in-progress right now, but I’ll be adding some more features soon, including multi-signal support.

Thanks for reading.

Here’s the result.

All you do is line up a light background behind the mobile, turn on the camera, and your phone joins the network.

Subscribe now

The code is at https://github.com/jamesbowman/wifi_qr_mobile
Usage instructions are in the README.md - the script generates the .scad file.

Printing time on the Bambu is about 90 minutes.

Also lasers

It also supports an —svg_out option for use with laser cutters. This is a lot quicker.

How it works

The script takes some wifi options, generates a QR code image, then outputs an OpenSCAD model with a hole for every white pixel in the code. It can also generate a similar SVG file for a laser cutter.

AI wrote the code

Firstly, none of this post’s text was AI generated.

However, ChatGPT Codex wrote the code. I built it up step by step, with a couple of git commits when things were looking ok. I did make a couple of manual edits for aesthetics. I was really impressed when it refactored the OpenSCAD generator to optimize rendering time. It would have taken me an maybe half an hour. It took Codex 30 seconds.

I’ve always been able to make things out of code. It’s much easier to do that now.

Thanks for reading.

This worked well. Perhaps too well, as there are now about 150 boxes. I find that I’m spending an increasing amount of time searching for any particular box.

So I’ve been experimenting with a scheme of:

1. labeling the boxes with printed QR codes

2. taking photographs of the shelves

3. making some software to make a physical search engine. The goal is to type “metric” (for example) and be shown the locations of boxes with “metric” on the label.

Talking this plan over with ChatGPT, it pointed out that qrencode supports something called “Micro QR Code.” This is a version of QR Code that uses a smaller area than the usual version, but with a very limited data capacity. That’s good: simpler QR codes mean that they will be more legible in photographs.

Here’s the string “254” encoded as a regular QR code, and as a Micro QR code. For the Micro QR the active area is just 11x11 pixels.

Support for Micro codes is not universal. Many packages only handle regular QR codes. But fortunately qrencode supports it for encode, and zxing supports it for decode.

Just to be clear, instead of encoding the box text on the label, the idea is to use a 3-digit code which is an index into a database.

After some quick experiments, I had a run of of labels for a test, and I wasted no time in sticking them onto the boxes.

The “database” is just a Python module that lists each code and the box label. It looks like this:

stuff = [
(100, "Flash 8-DIP 3.3v"),
(101, "USB UARTs"),
(102, "Crimp Terminals"),
(103, "IMXS MIPI"),
(104, "18650 Holders"),
(105, "space IMX577"),
(106, "VA800-SPI"),
(107, "FF Jumpers"),
(108, "Fixture Clamps"),
(109, "IPS 240x320"),
(110, "Brushes"),
...

So how will it do? Reliably recognizing QR codes needs plenty of resolution for each code. Here’s a blow-up from the above cell-phone picture. The code itself is about 150x150 pixels. That’s encouraging.

And plugging the image into zxing returned matches for every code. zxing does appear to have a limit of 255 codes per image. I doubt I’ll run into this with my use case.

And the final part is to make a self-contained page that does the search and shows the results. Here’s the one-page app, set up as a quick demo for just a couple of shelves.

The code for all this is in the findstuff repo on github.

Next steps, thoughts

Now that the basic idea seems to be working, I’m going to apply labels to all 150 boxes.

Then probably tidy up a bit. Throw out old boxes, consolidate contents. Maybe split some boxes. But here’s the thing. Because the box catalog is in git, these changes are more like a refactor than a tidy up.

This system means that I can have a lot more boxes. As long as I can remember the name of something, I can find it again. This will likely change how I keep and organize my stuff in the future.

How ChatGPT helped

I use ChatGPT a lot, and this weekend project was no exception.

It helped generate the box labels for the initial import. I uploaded photographs of all the boxes and it did a pretty good job (~90% accuracy) of extracting the text of the labels.

Some of the pieces of the Python scripts to generate the labels was written by ChatGPT, as was the interactive web page search.

This conversation about the most legible (for humans) font for the labels was pretty helpful.

None of this article was written with AI. The typos, digressions and non-sequiturs are all human-generated.

Subscribe now

Our chicken coop is a short distance away from our house. Far enough away that it doesn’t have electricity. This led me to install a small solar panel and a battery in the coop, to power indoor lights. The lights run on 12V DC from the battery, and are a great convenience when locking the birds up in the winter nights.

At this point, of course, I was filled with an irresistible desire to remotely monitor the solar battery voltage. And if I was going to monitor that, I’d also like to know if the coop door was open or not. (The coop must be locked up every night, and opened up every morning.)

So this got made. Not pretty, of course, like everything about the chicken coop, but it’s worked very well.

The box is cut from plywood using a customized design from the excellent boxes.py. Running the show is a Raspberry Pi Pico. It’s powered by the 12V the solar battery supply. A regulator drops it to 5V. The Pico has three sensors:

• battery voltage, connected through a resistor divider to an ADC pin

• an I²C temperature sensor from Electric Dollar Store

• an I²C magnetic compass, also from EDS

The Pico is collects the data and sends it back via the Reyax LORA module at the top of the box. The Reyax uses a simple serial interface at 115200 baud, with a good old AT-style command set for sending messages.

Every 60 seconds the Pico wakes up, samples the sensors, and sends a packet over the Lora with the sensors in JSON format like this:

{”magnet”: [-138, 104, -774], “vbatt”: 12.9571, “temp”: 13.625}

At this point you might be wondering why I’m interested in the direction and magnitude of Earth’s magnetic field in the henhouse. Well, the whole box is mounted on the henhouse door:

When the door is opened, it swings through almost 180° and the resultant change in compass bearing is easily turned into a door open/door closed flag. I was particularly pleased with this cunning scheme - the door sensor uses no moving parts! (Unless you count the whole electronics package itself as a moving part, which I don’t).

Back at the base, another Reyax receives the packets and is connected through a TermDriver to a Raspberry Pi.

The Pi reads the JSON data and sends it on to the house MQTT server, which is Mosquitto running on another Raspberry Pi.

One improvement I made last year is to hook up a lamp in the house to the door open/closed logic, using a Shelly Smart Plug. Besides all their cloud/smarthome features (which I don’t use) they have a simple web server for off/on control. So you can switch the socket off or on by fetching a single URL from the Shelly like:

http://192.168.0.60/relay/0?turn=on

As soon as the receiver sees that the door has been closed, it turns on the lamp in the house. This works very well; we can easily confirm that one of us has locked the chickens in each evening just because the lamp has gone on. We don’t have to look at a screen or remember to check anything. I particularly like this kind of invisible technology.

I should say a few words about the software. The Pico in the coop runs a small CircuitPython loop. The receiver Lora/MQTT gateway indoors is just a small Python script. It’s simple stuff, reliable and easy to diagnose if anything goes wrong.

Thanks for reading.

I’ll do my best to describe the theories, and then list objections.

Subscribe now

Simple price discrimination

Price discrimination is the economics term for charging different prices to different customers. For example in some places taxis charge different prices for tourists and locals. It’s a well-understood phenomenon, and the excellent MRU economics course explains it in full.

This situation looks like price discrimination. TI is the monopoly supplier of ADS1115 chips — nobody else can make and sell an ADS1115. TI knows that US customers are much less price-sensitive than Chinese customers, so sets a higher price in the US.

Alternately, US distributors (Mouser and Digikey) set the higher price, using their dominant supply position and reputation to sell to customers who are prepared to pay a premium to be certain about authenticity.

In the MRU video, note that the price setters in the examples like ambiguity. They won’t confirm or deny that they’re selling the same product at two different prices. In fact they often do things to increase ambiguity, because the uncertainty encourages people to buy the premium parts.

Failed units, or “third shift”

During manufacturing, some chips fail. What happens to them? Well, it depends. They might get destroyed, or they might get sold on to a third party. The failed parts can be packaged up and sold through gray market channels. I’ve experienced this with LCD panels for the Gameduino.

Something similar happens when a contract manufacturer makes the official part, but does extra production that they then sell themselves. This is called “third shift” — the idea being that two shifts are assigned to legitimate production, the third to this extra contraband production.

In both these cases, the parts get sold at a lower price than the genuine article.

Outright fakes

Many have pointed out the striking similarity between the ADS1115 and the Analogy ADX111. Here is the (part-Chinese part-English) datasheet. The datasheets are so alike it’s like an old spot-the-difference game:

Certainly at the I²C register level, I can see no way to distinguish between an ADS1115 and an ADX111. The TI datasheet says that timing is guaranteed within 10%, the Analogy 7%. So that might be a way. On the other hand the fact that the Analogy data sheet switches at random between two languages, and copies large sections of the TI sheet makes me skeptical of its truthiness.

The ADX sells for $1.77 qty 1K on LCSC.

Arguments, for and against

Several people expressed the opinion that LCSC is a reputable supplier, and that they have never received counterfeit parts when buying from them.

Some also stated that TI runs tight manufacturing operations, which makes sense given that they are a top-tier brand. Part of this is (a) making sure that failed parts get destroyed, and don’t escape through the factory back door, and (b) preventing “third shift” production.

When I tested the four cheap samples, three were ~5% out of timing spec. The fourth had a completely non-functional clock generator, but in a way that most customers would probably not notice. The accuracy of all four did not match the claims in either the TI datasheet or the Analogy sheet. All had gain errors of about 0.5%.

The marking on the cheap chips’ packages looks authentic to me. Of course this means nothing. The days of easily detectable fakery are long past.

One Hacker News commenter suggested decapping the chips and comparing microphotographs of the two dies. Apart from the effort involved in doing this, it might not actually prove much. The ADX111 die could look very much like the ADS1115 die, depending on whether it’s a functional replica or a straight die copy. Third shift production is the same product as legit production, but potentially with less stringent QA. The same goes for upcycled failed units. So you could easily spend a whole day sloshing boiling nitric acid around and be none the wiser.

And now, the real thing

Dropping the Adafruit ADS1115 breakout into the test setup was a breeze. The build quality of the PCB is in a different league from the no-name parts. There’s a power LED, dual Stemma/QWICC ports, and a separate analog ground. So the testbench changed from a wire tangle to this minimalist setup.

Running with the same test script immediately showed the differences. Timing is within 2% of nominal, better than the 10% promised in the TI datasheet. And the gain error is so low there’s not much point in calibrating it.

timing difference 99%
       raw=03415 v=2.4999
timing difference 99%
       raw=03415 v=2.4999
timing difference 98%
       raw=03415 v=2.4999
timing difference 99%
       raw=03415 v=2.4999

Overall, I was surprised at how much better this thing is.

Conclusions

There’s a clear difference in the performance of these parts. The Adafruit board was a lot better than claimed in the TI datasheet. The cheap boards were much worse. So that rules out price discrimination by TI.

Looking at the pricing and gain accuracy, I’d say that the cheap ADS1115 parts in the breakouts are fails, either from TI (unlikely), from Analogy, or from some other nameless vendor selling fakes.

I’m still curious about the bare chips from LCSC. I might use them in a short run of breakouts for Electric Dollar Store to see how they perform.

A final note

There’s a scene in the Matrix where Cypher simply decides to live without knowing the truth.

“You know, I know this steak doesn’t exist. I know that when I put it in my mouth, the Matrix is telling my brain that it is juicy and delicious. After nine years, you know what I realize? Ignorance is bliss.”

At the end of the day, if the imitation is so like the real thing you can’t tell the difference, then how much it does it matter if it’s real or not?

It’s a choice for each of us. Be like Cypher and settle for “close enough.” Or like Neo and pay the high price for insisting on the real thing.

Thanks for reading. Next week: my somewhat impressive chicken coop tech stack.

Recently I’ve been playing with the ADS1115. It’s a dedicated ADC from TI module which plausibly delivers 16 bit accuracy.

One really cool thing about the ADS111x family is a dynamic range feature that gives you up to 20 times finer measurement for small amplitude voltages. It’s accuracy where it matters.

The ADS1115’s programmable gain amplifier lets you shrink the full-scale range from ±6.144 V down to ±0.256 V. That means a single LSB can represent as little as ~7.8 µV (0.256 V ÷ 32768). Compare that with a microcontroller ADC with a fixed 3.3 V range: 9 ENOB steps are ~6 mV.

Another nice thing is that it uses an internal voltage reference. The RP2040, for example, requires an external 3.3V analog reference.

But there’s something fishy about the pricing of the ADS1115. At quantity 1K it’s around $4 from Digikey, yet $0.60 on LCSC. That’s quite a spread. I picked up breakout boards from Amazon for $2.97 if you buy four, and I very much think these are made with the $0.60 parts from LCSC or similar.

I’ve also ordered this very handsome breakout from Adafruit, which I assume uses the pricier version of the ADS1115. I’ll report back next week.

So how bad are these cheap ones? I hooked one up to an I²CMini and my trusty precision DC voltage source and tried to find out.

First check, are these functioning according to spec, or are they a cheaper part that’s being passed off as an ADS1115, as reported on forums?

As far as I can tell, they behave as if they are real ADS1115s. The readout is true 16-bits. The PGA (Programmable Gain Amplifier) appears functional. The readout rate is variable from 8 to 860 samples per second, and this approximately matches the TI datasheet.

I tested mostly in differential mode, and with the two inputs tied together, the ADC read consistently zero. With a calibrated 2.5V differential, the ADC measured very close to 2.5V, and with the polarity reversed gave exactly the same number negated. So far so good.

But closer inspection showed some deviations.

The TI datasheet says that the Data Rate, DR is ±10% of the nominal. So at 8 samples per second mode, samples should arrive 7.2 - 8.8 times per second. Three of the ADCs were close but slow (6.5-7 samples per second). One of the ADCs was nowhere near: 300 samples per second. That one didn’t get any further testing; there’s obviously something broken with its timing system. (But how many end users would actually notice that it’s running faster (and hence noisier) than it’s meant to?)

Looking more closely at the actual measurement, my calibrated 2.50067V source was being reported by the ADS1115 as 2.4883V. That’s a 12 mV error, and a 0.5% difference. Much bigger than the claim in the TI datasheet:

This isn’t quite the catastrophe that it might seem. After a simple linear correction on the MCU, I was getting results accurate to within 10 µV.

So what’s going on with the cheap parts? My best guess is that these are either quite good copies, or failed parts that somehow made their way into the hobbyist supply chain. When the more respectable part arrives next week I’ll put it through the same tests and report the result. However I only bought one of these, because it’s 4X the price!

Thanks for reading.

Felix had it hooked up to a Pico, as well as to a SPIDriver for bringup. Both worked fine, then both eventually stopped working at all. The display is an SSD1306, which uses the pretty-common “SPI plus a couple of control lines” hookup. Lots of panels use the same kind of scheme.

When we started working the problem, the suspicion was that something might have gone wrong with the software. After all, it’s very easy to make an innocuous-looking change that stops the hardware from working. I do it about once a day, so it seemed not completely impossible that my offspring had done the same. The apple never falls far from the tree, as they say.

What we really wanted was to run some known-good driver with the SPIDriver and the SSD1306. Enter Adafruit, and their impressive commitment to Open Source. They provide drivers and examples for a huge range of hardware. Including this ready-to-run Python module for the SSD1306.

In the past, I’ve taken the Adafruit Python drivers and ported them to SPIDriver’s API. The hardware SPI interface is a little different, but after a bit of rearranging, it generally works. But then what? I can’t port every driver — there are hundreds, and the maintenance would be continuous.

How much better it would be if the all the wonderful Adafruit libraries just worked with SPIDriver? Then we could run the sample code unchanged, and really confirm if the problem was software or hardware. And even better, anyone else who wanted to use an Adafruit driver could run with their SPIDriver.

The way Adafruit solved the portability problem between CircuitPython (on microcontrollers) and CPython (on PCs and SBCs) is using a library called Blinka. Blinka runs on the PC, and reproduces all the hardware interfaces (like SPI, I2C and GPIOs). Blinka supports all kinds of hardware, including many USB adapters. Adding SPIDriver and I2CDriver support to the list should be fairly straightforward.

And it was. After a bit of hacking, I had SPIDriver working under Blinka.

Then I took Adafruit’s example code for the SSD1306, changing the pin assignments for SPIDriver:

import board
import fourwire
import adafruit_displayio_ssd1306
import displayio
import busio

displayio.release_displays()

# This pinout is for the SPIDriver
spi = busio.SPI(board.SCK, board.MOSI)
tft_cs = board.CS
tft_dc = board.A
tft_reset = board.B

display_bus = fourwire.FourWire(spi, command=tft_dc, chip_select=tft_cs, reset=tft_reset, baudrate=1000000)
display = adafruit_displayio_ssd1306.SSD1306(display_bus, width=128, height=64)

and it came up immediately

then I added some code to draw a bitmap:

splash = displayio.Group()
bitmap = displayio.Bitmap(128, 64, 1)  # 1 color slot
palette = displayio.Palette(2)
palette[0] = 0x000000
palette[1] = 0xFFFFFF

from PIL import Image

pixels = Image.open(”logo128.png”).load()
for y in range(64):
    for x in range(128):
        bitmap[x, y] = pixels[x, y]
 background=/__u/excamera.substack.com/displayio.TileGrid(bitmap, pixel_shader=palette)
splash.append(background)
display.root_group = splash

and here’s the proof. It all just works.

Next step is adding I²CDriver support to Blinka as well, then I’ll submit a PR to the maintainers of Adafruit_Blinka.

When carefully assembled, they look great. We’re very happy with them. But they are extremely fiddly to assemble by hand. The box is slim, so opening it out is tricky.

So here’s a fixture to help. Technically, it’s a box forming mandrel. The piece (in this case the flat box) fits over it. As it’s pushed down, the mandrel progressively opens the box until it reaches its final shape.

The top edge is just a blade. The right-hand curve pushes the box edge open from the inside. The left-hand curve does the same on the outside. The bar on the right gives a bit of stability. The bottom half of the mandrel is a simple rectangle, to hold the box square.

It took several prints to get the mandrel right. I found a 0.25 mm fit works well. It’s printed flat in extra-fine quality, to reduce the layer lines that can snag on the box. This is the mandrel ready for use, with a few test boxes.

Here’s a video of me assembling a box. It takes about 12 seconds. But the more nimble hands of our workers should be able to do it in half that. 600 boxes an hour is a satisfactory rate.

We gave it a short test run to see how it performed. It worked great. We did hundreds of boxes assembled and ready to accept their TermDrivers. It will all be shipping in the next few days.

Thanks for reading.

That’s called a box former (or carton former). In packaging, it’s usually a tapered mandrel or jig: you set the flat box blank over it and press down, and the box pops open into its proper 3D shape around the form.

This morning I have a prototype box-forming mandrel. These mandrels are normally the domain of huge industrial scale production. But thanks to 3D printing, we can now have them for desktop-scale production. Truly we live in an age of wonders.

Our printer supplies the boxes packed flat, we then pop them open and tuck in the end flaps. Each one takes about 30 seconds. Later this month we’ll be assembling 2000 TermDriver2 boxes, that’s 16 hours of folding. Cue the obligatory xkcd.

The idea for the mandrel is that it has a bladed top. As you push the box down, it opens the box. The rectangular section at the bottom holds the box in shape. The mandrel’s height matches the height of the box, so a single downward motion is all it takes. Then the top flaps can be closed.

The math for the mandrel shape took some thought. It’s a series of stacked parallelograms. The topmost parallelogram is very flat, the bottom parallelogram is a rectangle. The layers in between smoothly interpolate between these two shapes.

I²CDriver and SPIDriver are fairly large boxes, 106mm wide and 137mm high. So the mandrel is quite large. After about two hours of printing, it looks ready:

I set up in a vise for a first test. The flat box fits over the bladed top just fine.

And then the moment of truth. I excitedly pushed the box down. It works!

Something I’m really appreciating about 3D printing is it’s easy iteration. If you’re a woodworker and you’ve made a table, you might want to adjust the design a bit. To do this you have to make another table, starting over. But with 3D printing, you tweak the design file, and send it to the printer.

As soon as I had this first mandrel in front of me, potential improvements were immediately obvious. The mandrel only twists one side of the box. A second exterior mandrel could twist the opposite, external side. Adding a guide on the right-hand-side would help make the box more rigid. Here’s the mark II.

It’s printing right now. I’ll report back on how well it works. Thanks for reading, and please subscribe if you’d like to follow the progress.

Subscribe now

This week I decided to add proper lighting to the outdoor shower. One thing I dislike about power outages is the feeble light from emergency lanterns. I wanted a lot of cheerful, warm light.

The bulbs themselves are these 6W warm LED filament-style bulbs. I tested them out on the bench, and found they stay lit anywhere from 7-24 V. They take a constant 18W for the whole set. The wiring is a spouse-approved 3-way pendant set.

The actual supply is in the box on the right. It’s a 3D printed enclosure with a pop-on/off lid.

In black PLA, it only took 1 hour to print. I’m getting a bit more fluent in OpenSCAD with practice. Designing the enclosure and lid took about an hour. Some of that was genuine thinking about shapes. But most of it messing around with the code. It’s a lot of fun.

Here’s the installed enclosure with the internals. Batteries, holder, and a switch.

The box uses a 4-way 18650 battery holder, so the voltage at full charge is about 16V. That’s about 2½ hours of light, so I might expect to have to recharge the pack every two weeks or so. A few years ago I discovered lever wire connectors and my life was slightly improved. Recommended.

This was my first time using 18650 Li-ion batteries. Amazon is full of 18650 batteries with utterly implausible capacity claims. These ones turned out to be the real thing. I did test them for a few cycles, and they are indeed 3300mAh. Phew! Though next time I’ll likely follow this buying advice on reddit.

Thanks for reading.

Gameduino 3X

We have these in stock in the Excamera Labs store. The bright 5” 800x480 premium touchscreen looks great. I’ve been working with CircuitPython over the last couple of years, and the EVE/Gameduino bindings in CircuitPython work very nicely. It’s probably the easiest way to put an interactive display on a microcontroller.

I²CDriver, I²CMini and SPIDriver

The price hasn’t changed over the years - still $29 - but there have been some improvements. The I²CDriver now includes with a cable for the popular Qwiic/Stemma connector.

If you bought either of the original products, they shipped in an antistatic bag. But a couple of years ago we added very nice product packaging for both:

All of these interface tools continue to sell through the Excamera Store, Adafruit, Mouser and Crowd Supply.

After a complicated and frustrating series of mixups with Amazon, both I²CDriver and I²CMini are available from Amazon again. Hurrah!

Electric Dollar Store

Electric Dollar Store was a spin-off from I²CDriver. The idea is a standardized breakout for I²C devices with lots of interesting peripherals to choose from. They’re packaged and tested here in the USA, and all very reasonably priced.

Thanks for reading, and if you’re a customer, thanks very much for supporting independent hardware.

Turns out people with antique computers do. I have a couple of antiques around the place, including a TRS-80 Model 100. So I spent a few minutes making sure that TermDriver can talk to it at 300 baud.

The Model 100 was introduced in 1983. Wikipedia calls it “one of the first notebook computers ever released.” Yes it is like a notebook. But using it is a reminder that things have improved a lot in 42 years.

But not everything has improved. The keyboard is pretty good by the standards of today’s laptops, with deep key travel and a positive action. And the accompanying spiral bound manual is surprisingly good.

Hooking up the serial hardware was surprisingly simple. The TermDriver outputs 3.3 V serial levels, not old-school RS232 levels, so I’ve plugged it into this level shifter from Amazon. It’s just the minimum: given 3.3 V and TX and RX from the TermDriver, it outputs RS232 levels on the DB-9.

With all the hardware hooked up, and the TermDriver set up at 300 baud, I could use TRS-80 BASIC to save and load programs over the serial line. It was fun to see ancient BASIC code scrolling up the TermDriver’s screen. I must admit to a tiny pang of nostalgia.

So for all the retro fans out there: yes TermDriver runs reliably at 300 baud. And it’s been confirmed on a machine from an age when 300 baud was considered pretty ok.

Dear readers, the TermDriver2 campaign is currently running over on Crowd Supply. Thank you very much for making its first two weeks such a success.

Do you ever wonder what your Raspberry Pi is doing? I do, particularly when rebooting. Of course you can plug in a bulky monitor, but the whole point of a Raspberry Pi is compactness. If only there was a miniature console that attaches directly to the Pi’s serial pins. Well rejoice, because you can now use TermDriver to do it — here’s how.

First, I wanted to make a holder for the TermDriver. Here’s my attempt, made using OpenSCAD.

It’s just a first draft; and it needs supports to print, so I think it would be better split into two pieces. If there are any 3D printing/OpenSCAD experts reading who want to have a crack at it, I’d be very grateful. The model is here and the source is here.

It’s an exact fit for the TermDriver, and holds it very nicely in place.

With the TermDriver securely in its tiny frame, it was a simple matter of hooking up the Raspberry Pi and powering on.

The wire connections are from the Raspberry Pi’s serial lines to the TermDriver, plus ground and 3.3 V. While TermDriver is normally used with USB power, it’s also perfectly happy running from the 3.3 V supplied by the RPi.

Of course you can plug in a USB cable and log in as well. It’s been invaluable as I’ve recently been debugging the RPi Zero W wifi link.

Simple as that. Again, you can pre-order a TermDriver now. Thanks for reading.

You can buy it from Adafruit, Sparkfun, and elsewhere. There’s a main page with a clear getting started guide, and a datasheet.

Because it uses the Qwiic connector standard, setting it up is a breeze . It plugs directly into I²CDriver or I²CMini - both ship with qwiic cables included. TCR has a color LED on the front side that blinks blue on power-on, and helpfully blinks green when it detects a QR code in front of it.

Within a a couple of minutes I had a Python loop that printed out the current QR code using the I²CDriver:

import sys
import struct
from i2cdriver import I2CDriver

class TCR:
    pass

if __name__ == '__main__':
    i2 = I2CDriver(sys.argv[1])
    i2.setspeed(400)
    i2.scan()
    while 1:
        i2.start(0x0c, 1)
        b = i2.read(256)
        i2.stop()
        (l, ) = struct.unpack("<H", b[0:2])
        s = b[2:2+l]
        if l:
            print(s)
        else:
            print('nothing')

That’s all it took. Sure enough, it worked immediately, decoding the code in front of it:

b'http://en.m.wikipedia.org'
b'http://en.m.wikipedia.org'
b'http://en.m.wikipedia.org'
b'http://en.m.wikipedia.org'

I didn’t test it with longer codes. The developer documentation hints that longer codes might be a problem. The I²C protocol itself limits the code size it can report to 254 bytes.

But the biggest limitation seems to be that it needs the code to be almost dead center in front of the camera sensor. The documentation says

The sensor has approximately a 110 degree field of view.

but using my setup above I found it to only recognize the code if it’s centered with 5 degrees in both vertical and horizontal directions. That’s about 10mm with a 130mm lens-to-code distance. Pretty tight. I have opened a github issue with the maker for clarification.

What’s inside the TCR is a pretty interesting exercise in minimalism. The microcontroller is a RP2040 (just like TermDriver), hooked up to the I²C lines on one side and the image sensor from Arducam on the other. The image sensor module is glued down to the main board, but easily comes apart to reveal a 30-pin connector.

The rest is software. It’s possible to imagine all sorts of useful applications for this hardware with different software. In fact the same company makes a person detector, using a slightly different hardware platform.

The most surprising thing about this product is the price. At $7 retail, I imagine the maker is selling them for around $4, which must be very close to the BOM for the product itself. I’m tempted to see if I can use it as a development platform — the $7 price for a stock RP2040 and an image sensor is pretty appealing.

Thanks for reading.

This post is all about TermDriver, a USB/serial adapter that is now available on Crowd Supply. You can be first in line for the world’s coolest USB serial adapter. Thanks.

Earlier I wrote about the TermDriver hardware development, and the technology of making tiny text readable. Something that I’m quite pleased about is the firmware that’s inside TermDriver.

The main thing

First and foremost, TermDriver’s job is to pass traffic between the UART and the USB port. That’s obviously what you want from this device. But it also needs to update the screen, redrawing it for every single character that comes through. For the terminal to be an accurate log of the traffic, TermDriver cannot ever drop a single character, otherwise the screen would be corrupt.

Graphics bandwidth

The screen on TermDriver is a surprisingly bright 240x240 LCD, controlled by an ST7789. The RP2040 that’s running the show is connected by an SPI interface to the ST7789, which refreshes the LCD at around 60 Hz. That sets the goal: to look crisp and snappy, the RP2040 needs to redraw the screen at 60 Hz. That’s 13.3 ms per redraw.

Can this be done? Yes, but it’s a lot of bandwidth for a microcontroller. 240x240 pixels at 18 bits per pixel at 60 fps comes out at 62 Mbit/s over the SPI bus. That’s on the edge of the maximum rate for the RP2040.

There’s a clever trick, although it costs a little bit of image quality. Instead of running 18 bits per pixel, the ST7798 can run in a 12 bit per pixel mode (i.e. 4 bits each for red, green and blue). This reduces the theoretical SPI bandwidth to 41 Mbit/s. Much safer. Cutting this corner also makes the RP2040 color code considerably faster.

Dual core action

RP2040 is a true dual-core microcontroller. This is what makes TermDriver possible. One core handles the communications between USB and the UART, and updates a block of memory that represents the screen as an array of characters and colors.

The second core reads from this in-memory screen, does the math to figure out the pixels, and writes it over SPI (using RP2040’s awesome DMA) to the display.

The beauty of this cunning scheme is that even if the data is coming through really fast, changing the whole screen hundreds of times per second, the display updates still happen at a steady 60 Hz. Each 60 Hz tick you see a snapshot of the instantaneous terminal state, guaranteed.

Racing the beam

One thing that increases visual quality is reducing “tearing” — seeing visible partial updates on the screen at the same time. The expensive solution to this is double-buffering, something that the EVE chip in the Gameduino supports in hardware. The ST7789 doesn’t support double-buffering; there’s only enough RAM inside for the visible pixels. But again there is a simple old-school trick that helps. Sometimes called “racing the beam,” it is to time the video writes exactly so they just follow the scanout line. That’s what the rendering thread does. It waits for the vertical refresh, then repaints all the pixels slightly more slowly than the scanout, so on the next frame. Result - smoother scrolling and updates.

Thanks for reading. Please subscribe — every week I write about what I’m making. And if you think a TermDriver would be a useful addition to your workbench, by all means place an order. Thanks again.