Hardware · Audio

dbCANary

A lot of amplifiers speak CAN and nothing else. The control software that drives them expects to find them on a network, and the box that bridges the two is a discontinued piece of someone else's hardware that turns up rarely and costs what rare things cost. This is that bridge, as an open board you can build.

It is deliberately a transparent bridge and nothing more. It does not interpret a single amplifier parameter, it adds no protocol of its own, and it holds no state about what is on the bus. Frames arrive on the network and leave on CAN, and the reverse. The control application should not be able to tell it apart from the hardware it stands in for, and if it ever can, that is a bug rather than a feature.

Rev A boards have now been made. The first was powered, flashed and put on a network on 9 September 2026, and it works. What that does and does not amount to is set out further down, in more detail than is comfortable, because "a board exists" and "the job is done" are a long way apart.

What is on it

Top view render of the dbCANary rev A board, showing the processor module at the top, the network controller and magnetics on the right, the isolated CAN transceiver at lower left, and three connector footprints along the bottom edge — Component side. Power enters top right, the processor module is top centre, the network controller and its magnetics are on the right, and the isolated CAN section is the darker region at lower left.

Block	Parts	What it does
Power	USB-C PD → CH224K → AP63200	One USB-C connector is the only power inlet and the only programming port. A CH224K negotiates the supply and an AP63200 buck drops it to 3.3 V. There is no barrel jack and no PoE on this revision.
Processor	ESP32-S3-WROOM-1-N8	Dual core with 8 MB of flash, running ESP-IDF. Native USB, so the same cable carries power, firmware and the console. The module sits at the board edge with its antenna overhanging, so its keep-out falls off the board rather than eating copper.
Network	W5500 over SPI, discrete magnetics	A hardwired TCP/IP controller rather than the processor's own MAC, driven at 20 MHz. Magnetics are discrete parts feeding a Neutrik etherCON, so the network jack is the same locking connector as the rest of a touring rack.
CAN	ADM3053, isolated	Transceiver, digital isolators and an isolated DC-DC in one part. It carries the bus at a fixed 100 kbit/s onto two more etherCON jacks, and it is the boundary between the two ground domains on this board.

100 × 81 mm, four layers, 76 placements and all of them on the top side, so the solder side is bare copper and the board can be assembled in one pass. Fifty lines on the bill of materials, forty-five of which carry a distributor part number that was checked against live stock rather than a catalogue.

The barrier down the middle

The single most important thing about this board is that it is two boards electrically. Everything on the network side shares one ground. Everything on the CAN side shares another. They are separated by seven millimetres of empty board with no copper crossing it, and the only things that span the gap are the isolator inside the ADM3053 and the transformer that feeds the far side its power.

This is not a refinement. An amplifier rack and the laptop running the control software are usually in different parts of a building, on different mains circuits, and the CAN bus is a long piece of copper joining them. Without isolation that bus becomes the lowest-resistance path between two earths, and the traffic on it is the least of the consequences.

It also has an awkward practical edge, which is worth stating because it has scrapped other people's boards. A single ground clip across the barrier defeats it, and a board that has had one on it will pass every functional test in the procedure and still be ruined. The bring-up document opens with that warning rather than closing with it, and the probe drawings shade the isolated region so it is obvious which side a meter lead is on.

What board #1 actually did

One board out of the batch, on one bench, on one day. Everything below is either something that was observed or something that was not attempted — there is no third category here.

USB enumeratedverified
First plug-in, no button sequence. This was the biggest risk on the batch — these boards were made before the USB routing was tidied, and the connector is the only way to power them.
Flash and processorverified
8 MB confirmed, chip revision read back, firmware written and verified.
Network controllerverified
Answered its version register at both 4 MHz and the full 20 MHz the application runs at, and a write-then-read walk proved the bus in both directions.
CAN transceiververified
A frame went out of the processor, across the isolation barrier, onto the bus wires and back, with no transmit or receive errors. That also proves the isolated supply started, which nothing on the other side of the barrier can observe.
Live networkverified
Link in 2.2 seconds, DHCP lease taken, bridge listening.
Protocol, end to endverified
A host-side acceptance script ran nineteen checks against the board over the network — discovery, the full command set, and the two commands that must go deliberately unanswered. All nineteen passed.
Discovered by the control applicationverified
It appears in the interface list at its own address, with a green status.
CAN against a real busnot yet
The transceiver has only ever talked to itself. Nothing has been connected to an amplifier.
Supply rails and isolation resistancenot yet
Board #1 went straight to USB-C power, so the bench-supply sequence and the measurements that go with it were skipped.
Indicator LEDs and the power-delivery status pinnot yet
Both need a person looking at the board rather than a script reading it.
Driving amplifiersnot yet
The last link. The control application lists the board but has not been taken through to controlling anything with it.

What building it found

Two firmware faults surfaced in the first hour on real hardware that had survived everything before it. Both are the argument for building the thing.

A stack overflow nothing else could reach

Typing the self-test command at the board's console crashed it every time. The command builds a two-kilobyte report on the calling task's stack, and the console task had four kilobytes to hold that plus two device drivers. It ran off the end into the heap and the scheduler died reading a pointer out of memory something had already overwritten. The identical code passes at start-up, because start-up runs it on a larger stack — which is why several hundred automated checks, a full emulator boot and a simulated acceptance run had all gone green. Nothing before that day had typed the command at the prompt. Fixed.

The board describes its own socket wrongly

The control application finds the board and lists it, but under the wrong transport: two fields in the discovery record were set from a misreading of how the application decodes them. It was caught by reading the name the application displayed, then confirmed by standing a second emulated device beside the real one with the fields set differently and watching which label changed. Not yet fixed — the correction touches the firmware, its host-side twin, the protocol notes and a test that currently asserts the wrong values.

How it gets tested

Three pieces, written before the boards arrived so that bring-up was a procedure rather than an afternoon of poking at it.

The board tests itself. A separate firmware image walks the hardware — flash size, network controller at both clock speeds, a bus write and read-back, the CAN loopback across the barrier — and prints a result line per check plus a machine-readable summary. It does not start the bridge, so nothing it finds is confused by the application running underneath it.

A host script does the network half. It runs the real discovery exchange and the full command set against the board and checks the answers, including the two commands that must produce no reply at all. It also has a simulation mode that runs the same checks against a software model, so the test rig itself was proven correct before any board existed to run it on.

The bench procedure is written down. Every expected value is tagged with where it came from — a datasheet, a calculation, or a guess — so that reading a measurement that disagrees, you know whether to doubt the board or the document. The probe drawings that go with it are generated from the board file itself, and the generator refuses to run if any probe has moved off its pad, which means a drawing cannot quietly go stale the way the renders on this page once did.

Where it goes next

The immediate work is finishing what board #1 started: correcting the discovery fields, then taking the control application all the way through to driving an amplifier, and putting the CAN side on a real bus with a properly isolated adapter. After that, the rest of the batch and the measurements that were skipped.

Rev B already has a list: power over Ethernet, protection on the network jack, a pull-up on the network controller's reset line that the processor currently leaves floating until firmware runs, and a silkscreen pass — several reference designators on rev A overlap into unreadable blocks, which does not affect how the board works but makes it unpleasant to rework.

Honest status

Boards exist and one of them works. Board #1 was powered, flashed and put on a network on 9 September 2026: it enumerated over USB first time, passed its own self-test six for six, took a DHCP lease and answered a host-side acceptance run of nineteen network checks. The control application discovers it and lists it. What that does not cover: the CAN side has only been run as a loopback through its own transceiver, never against a real amplifier bus; the bench sequence of rail and isolation-resistance measurements was skipped on this board; the indicator LEDs and the power-delivery status pin still need somebody to look at them; and the last link - the control application actually driving amplifiers through it - is not finished. One board of the batch has been touched. Rev B is where the fixes go.

← All boards