The RAMSA Meter Bridge
A 390-LED meter bridge from Panasonic’s 1998 RAMSA WR-DA7 digital mixing console, brought back to life as a spectrum analyzer for whatever the PC is playing. There is no console, no published description of how the two talk, and the case was never opened. Everything goes in through the connector on the back: three wires from a cheap counterfeit USB-serial adapter.
The WR-MTBR showing music from the PC: 23 frequency bands, and the left/right level on the MONITOR A pair at the far right.
🎙 What It Does
Every LED Under Control
All 26 columns, any height from 0 to 15 LEDs. Checked bit for bit on a logic analyzer: 30 full updates out of 30 exact.
Three Wires
Clock, data and address, from a counterfeit USB-serial adapter. No microcontroller needed, no case opened.
Live Spectrum Analyzer
Whatever Windows plays, split into 23 bands from 32 Hz to 16 kHz, plus a left/right level meter on the MONITOR A pair.
Even Brightness
0–100 %, every column dimming the same, and steady while the music is busy.
No Flicker
Every update is slipped into a moment when the columns it affects are dark anyway. Measured flicker: the camera’s noise floor.
Fast
About 200 column updates a second from the adapter. 60 full frames a second from an Arduino Nano.
Survives Power Cycles
Switch the bridge off and on between sessions and nothing needs recalibrating. A Reset wizard recovers it from any state.
Two Ways to Drive It
The adapter does everything. An Arduino Nano is a tested alternative, with a fourth wire that re-syncs the bridge whenever it connects.
Case Still Shut
Nothing was modified. Everything goes in through the 15-pin connector on the back.
The finished meter bridge following music from the PC.
💡 Why This Project
On a mixing console, every channel has a level meter: a column of lights that climbs with the sound. A meter bridge is a long strip of those meters that sits above the console, where the engineer can see every channel at a glance.
The WR-MTBR is the meter bridge for the Panasonic/RAMSA WR-DA7, a digital mixer from around 1998. It has 26 columns of 15 LEDs each, 390 in all: 16 columns for the input channels, 8 for the buses (the mixes the console sends out), and a separate pair for the monitor output, MONITOR A left and right. Green at the bottom, orange in the middle, red at the top.
On its own, it does nothing. It has no audio inputs and no idea what to show. It has a 15-pin connector on the back, which carries its 7 V power and the console’s instructions: column 7, light 9 LEDs; column 8, light 4… Without a console, the meters stay dark.
I like old-fashioned spectrum analyzers, the kind with rows of LED bars jumping with the music. I bought this bridge on eBay for $100, and then it sat in my garage for years, because there was no information anywhere on how to drive it. Eventually I decided to give it a try anyway.
The bridge is here; the console is not. The goal was to make the bridge useful on its own, as exactly that kind of spectrum analyzer, showing the music playing on a PC.
What made it hard
- A private protocol. The service manual calls it Panasonic’s own “Level NET II” format. No public description of it could be found.
- Block diagrams, not schematics. The 86-page service manual shows what connects to what and lists the parts, but not the circuits, and not what travels on the wires.
- Nothing to listen to. With a console, you could record the signals it sends and copy them. Without one, every signal had to be worked out from scratch, sent, and checked against what the LEDs did.
- The case stays shut. All the work goes through the rear connector.
📏 One rule for the whole project
Anything worked out rather than measured stays marked as a guess until a measurement confirms it. Several early conclusions broke that rule and had to be withdrawn. The story below includes them, because they explain most of the lost time.
🔍 What’s Inside
The service manual’s block diagram and parts lists give a clear picture of the inside without opening the case:
The meter data goes from the connector straight into two custom chips. The bridge’s small computer only looks after the front buttons and its own serial line.
- Two custom chips (Panasonic T7C110F003, “meter control”) decode the meter data and run the LEDs. One handles the 16 input columns, the other the 8 bus columns and the MONITOR A pair. They are fixed hardware with no software inside: their behaviour cannot change, and there is no firmware to fool.
- A small microcontroller (NEC µPD78052) reads the four front buttons, lights their status LEDs and talks to the console over a slow serial line. It never touches the meter data.
- Ordinary LED driver chips (Toshiba TB62705 and TD62M8600) do the heavy lifting, about 28 mA per LED.
- Line receivers (MC74HC367) sit on every input. They run on 5 V.
The connector
| Pin | Name | What it carries |
|---|---|---|
| 1 | LBCK | The clock. Each pulse tells the meter chips to read one bit. It turned out to drive the display as well. |
| 2 | LDATA | Data: the heights of the bars. |
| 3 | LADD | Address: which column a height is for. |
| 4 | LWCK | A sync line. Not needed for three-wire driving; on the last day it turned out to line everything up with a single pulse. |
| 5, 6 | CTXD, CRXD | The microcontroller’s serial line in and out. Pin 6 is an output. Not used for the display. |
| 7, 14 | +7 V | Power |
| 9–13, 15 | GND | Ground |
| 8 | — | Unknown; left open |
⚠ 5 V logic
The receivers only see a 1 above 3.5 V. A 3.3 V board such as an ESP32 or a Raspberry Pi will not drive them reliably without a level shifter (a 74HCT buffer).
🧪 The Bench
Four instruments did all the work:
| Tool | What it is for |
|---|---|
| Bench power supply | 7 V into pins 7 and 14. The bridge draws 0.15 A when idle and under 1 A with every LED on. |
| Logic analyzer | A cheap 8-channel USB analyzer (24 MHz) with the free sigrok / PulseView software. It records the wires as ones and zeros, which proves what was really sent rather than what the software meant to send. |
| USB webcam | Aimed at the bridge, it lets the PC see the LEDs: which columns lit, how high, how bright, how steady. It made unattended test runs possible. |
| Multimeter | Voltages at the connector. A logic analyzer cannot tell a quiet wire from a probe that has fallen off; a multimeter can. |
Every test got a number and an entry in a dated log: about 250 recordings (analyzer traces and camera frames) in a little over a week. When a result looked odd later, the recording was still there to check, and several times that is what caught a mistake.
The software and the physical display running together on the development bench.
The bridge running from the rear D-sub harness, with the case still shut.
📜 The Story
From the first power-up to a working spectrum analyzer took a little over a week of bench sessions, in September 2026. The dead ends are included.
Power, and a heartbeat
7 V from the bench supply into the connector, case shut. The microcontroller woke up and the front buttons worked, but every meter stayed dark: the bridge was waiting for a console. The logic analyzer found it calling for one on pin 6, the same byte every 26 ms at 31,250 bits per second (the speed MIDI uses). Sending back each of the 256 possible bytes did almost nothing: one of them silenced the bridge until the next power cycle. The serial line was a dead end for the meters, as the block diagram suggested. The meter data never reaches that chip.
Hours of nothing
The only driver on hand was a USB-serial adapter, a counterfeit FTDI FT232R. Real FT232R chips have a “bit-bang” mode that lets software set each pin directly; the clone silently ignores it. That leaves three usable outputs: the transmit line, which is fast, and two control lines, RTS and DTR, which are slow because every change is a request over USB. Test after test lit nothing, apart from one flash of the first column that never came back. Going back over the recordings showed why so little had been learned: five of the analyzer’s eight probes had never been connected, and a probe that is not connected looks exactly like a quiet wire. Four conclusions were withdrawn that day.
First light
The culprit was a wire nobody was driving. The address line, pin 3, had been left floating at 3.3 V: neither a valid 0 nor a valid 1 for 5 V logic. Tied to ground, with the clock running and the data line high, the first column lit from bottom to top, all 15 LEDs. Five bursts, five flashes, every time. Running the clock without gaps kept it lit: the display is only lit while the clock runs.
Luck, then a method
Random signals on all three lines (“fuzzing”) lit columns 2, 3 and 4 for the first time, but replaying the same signals did not do it again: lucky hits, not a method. Two changes made the rest possible. The webcam became an automatic eye, so tests could run unattended. And a simple trick turned the serial port into an exact clock: every byte sent comes out as a fixed pattern of pulses (one byte of 0xFF is exactly one pulse), and the slow control lines are changed only between bytes. Slow, but every bit lands exactly where it is meant to.
Columns on purpose
With exact control, a single 1 was moved through every position of the stream while the camera watched. Sixteen positions on the data line changed the height of column 1: a 16-bit level. The same walk on the address line found four positions that moved the bar to columns 2, 3, 5 and 9, which is binary 1, 2, 4 and 8. The stream is made of 32-pulse “words”, and each level goes to the address sent in the word before it. A staircase across columns 2 to 10 landed exactly, first try.
All 26 columns
The right-hand group would only ever light its first column. The reason: its chip counts words 9 pulses ahead of the other chip, so everything meant for it arrived in the wrong positions. Framed in its own timing, all eight BUS columns answered. The MONITOR A pair was found by trying all 32 possible timings. By the evening, one update set all 26 columns, with three wires, and the fourth control line still tied to ground.
From working to good
The clock also drives the display (see How It Works), and stopping it at the right moments dims every column evenly: brightness from 0 to 100 %. Then came a C# library and a Windows app with 26 sliders and a live spectrum analyzer, and a new problem: flicker. Every change of the data line pauses the clock, and every pause leaves one column lit at full power. Fewer pauses, shorter pauses, and pauses placed where the lit column is dark took the flicker from 33 % to 1 %, the camera’s noise floor. The adapter was pushed to 3 million bits per second, its maximum, and the chips did not miss a single pulse in a 60-second test. A wait that had been set by guesswork was finally measured: it was seven times longer than needed.
Polish
The spectrum stopped depending on the Windows volume setting. One column glowing brighter than the rest turned out to be the app’s map of the display scan slipping by three slots. A Sync scan button now fixes that by eye, with one click.
The bridge “broke”
After many power cycles the bridge came up in random states: nothing lit, half-lit columns, stale groups. An Arduino Nano brought in as a second driver failed as well. Its problems turned out to be two swapped wires, analyzer probes dragging its 5 V outputs down to 3.5 V, and a bridge whose display was already scrambled. Then an attempt to read the bridge’s heartbeat made things worse: pin 6 went to a pad on the adapter labelled RX that was really on the transmit line. The bridge’s heartbeat was now clocking the meter chips, about 113 stray pulses a second, and the adapter stayed powered with its USB cable unplugged, fed backwards from the bridge. Removing that one wire fixed everything at once.
Ten power cycles
Ten deliberate power cycles, each one read by the camera, settled the rules. With the adapter powered, the bridge always comes up in the same known state. With the bridge and the adapter both unpowered, it comes up scrambled. The old advice, “unplug the adapter before switching the bridge off”, was exactly backwards. The app gained a Reset bridge wizard that recovers it from any state, with no camera.
The Nano, and the fourth wire
A second Nano, wired directly with pull-down resistors, worked at once: the bridge counted its clock cleanly over 16 million pulses, and its updates landed on all 26 columns. The earlier failures had been the scrambled display, not the Nano. New firmware clocks it at about 600 kHz, and the spectrum runs on it at 60 frames a second. With a fourth output available, pin 4 (LWCK) was tested at last: one rising edge lines up both chips and resets the display scan, and the Nano now does that every time it connects. Running LWCK continuously, the way the console probably did, turned up nothing new: no hidden peak-hold dots. Smoothing and Decay sliders for the spectrum finished the day.
⚙ How It Works
No electronics background needed for this part. Four ideas make it work.
1. The display is a very fast slideshow
Only one column per chip is lit at any instant. Each chip steps through 16 time slots and lights one column per slot. The whole cycle repeats about 900 times a second, far too fast to see, so the eye blends it into a steady picture. This is called multiplexing, and many LED displays work this way because it needs far fewer driver circuits.
The surprise was what moves the slideshow along: the clock line itself. Each slot lasts 64 clock pulses, a full cycle 1,024. So the display is lit only while the clock runs. If the clock stops, the column showing at that moment stays on at full power while everything else goes dark: a bright flash. Between slots there is a short gap where nothing is lit, the blank window. Stopping there leaves the whole display dark.
Both chips step through their slots together. The right chip has only 10 columns, so in 6 of its 16 slots it lights nothing.
2. The message format
The meter chips read the stream in words of 32 clock pulses. On every pulse they read one bit from the data line and one from the address line. Only some positions in a word mean anything:
One word, 32 pulses. Each chip only listens to words whose page bits are its own.
A column update takes two words: one carrying the address, then one carrying the level. In fact every word does both jobs at once: it carries the level for the previous word’s address and the address for the next word’s level. A word with the address line high on every pulse is addressed to nobody, so the display can be kept running with “empty” words in between updates.
The level is not a plain LED count. Values 0 to 5 light 0 to 5 LEDs, then the steps get wider, and anything from 20 up lights all 15. The software keeps a table.
The awkward part: each chip counts words its own way, starting from the moment it powered up, and nothing sent on the three wires resets that count. An update has to line up with the target chip’s word boundaries, and the two chips’ boundaries are not in the same place. Get it wrong and the update lands in some other column, or in a bank the bridge does not even show.
3. A serial port as a clock
A serial port sends each byte as a pattern of highs and lows: a low start bit, eight data bits, then a high stop bit. Connect the transmit line to the clock input, and every low bit becomes a clock pulse. The byte 0x55 (binary 01010101) gives five pulses; 0xFF gives one.
The bits go out lowest first. At 3 million bits a second each bit lasts a third of a microsecond, so a stream of 0x55 bytes is a 1.5 MHz clock.
The data and address lines go on the adapter’s two control lines, RTS and DTR. Software can only change those slowly, through a USB request that takes a tenth of a millisecond or more, so they can never keep pace with the clock. The trick is not to try: change them only while the clock is stopped. The meter chips have no sense of time at all. They count clock edges, and whether the next edge comes a microsecond later or a second later makes no difference to them.
Because the chips cannot be reset over three wires, the software counts every single pulse it sends. That count is how it knows where each chip is in its words and in its display scan. It is saved when the app closes and read back when it starts. (An app that is killed instead of closed loses it, and the app says so at the next start.)
4. Hiding the pauses
Every change of the data or address line pauses the clock, and every pause freezes one column per chip on at full power. A single column update needs about seven pauses. Done naively, every update flashed, and the whole display flickered along with the music. Three changes fixed it:
| Stage | What changed | Flicker |
|---|---|---|
| First version | Every line change paused the clock for about 2 ms. | 32.8 % |
| Shorter, fewer pauses | Each pause cut to about 0.14 ms. An optimizer moves data changes onto positions where the address line changes anyway, so fewer pauses are needed. | 11 % |
| Pauses in the dark | Each update is timed so its pauses fall in a slot whose columns are dark anyway. In spectrum mode one column (L16) is always kept dark, so such a slot always exists. | about 1 % |
Flicker here is the camera’s measure: how much each column’s light varies from frame to frame. A display receiving no updates at all reads 0.6 %.
Brightness uses the same knowledge. The clock runs only a fraction of the time, and every stop falls in the blank window: run it half the time and every column gets half the light. The stops have to come after whole scans, though. An early version stopped after a whole number of slots, so one column got lit one extra time per burst, and a brighter column marched across the display.
Steady brightness under load. Each column update costs about 1 ms of darkness, so a busy song used to dim the whole display. The app now sets aside a fixed share of the time for updates (20 % by default). The brightness stays put, and about 200 column updates a second fit in.
🔌 Wiring
The adapter setup that does everything:
Three adapter outputs drive pins 1–3, and pin 4 is tied to ground. All the grounds meet at the supply’s negative terminal. The adapter’s own 5 V pin stays unconnected: the bridge is never powered from USB.
| Bridge pin | Signal | Adapter | Notes |
|---|---|---|---|
| 1 | LBCK, clock | TXD | The serial transmit line is the clock. |
| 2 | LDATA, data | RTS | Inverted: RTS “on” is 0 V. |
| 3 | LADD, address | DTR | Inverted. Idles high, which addresses no column. |
| 4 | LWCK, sync | — | Tied to ground. The adapter has no fourth output. |
| 7, 14 | +7 V | — | From the bench supply. |
| 9 | Ground | GND | To the supply’s negative terminal. |
| — | — | VCC | Not connected. |
⚠ Pin 6 is an output
Never connect it to an adapter pad until you have proved that the pad is the adapter’s receive input. A pad labelled RX turned out to be on the transmit line, and that one wire cost an evening: the bridge’s heartbeat clocked the meter chips and the adapter could no longer pull the clock low.
🔄 Keep the adapter powered when the bridge powers up
With the adapter powered, the bridge comes up in a known state. Without it, the display comes up scrambled. To recover from anything: bridge off, adapter unplugged for 5 seconds, adapter back in, bridge on, then bridge off and on once more. The app’s Reset bridge wizard walks through it.
The Arduino Nano option
A 5 V Arduino Nano can set all four lines with a single instruction, so data, address and clock change together and the clock never has to stop for an update. It is optional: the adapter does everything. What the Nano adds is speed (60 full frames a second, with no dark time for updates) and the fourth line, LWCK, which re-syncs the bridge every time the app connects.
The complete Nano harness: D-sub breakout, four signal wires, ground and the 10 kΩ pull-downs.
A closer view of the Nano, screw-terminal carrier and resistors at the connector.
| Bridge pin | Signal | Nano |
|---|---|---|
| 1 | LBCK, clock | D12 |
| 2 | LDATA, data | D11 |
| 3 | LADD, address | D10 |
| 4 | LWCK, sync | D9 |
| 9 | Ground | GND, to the supply’s negative terminal |
Each of pins 1–4 also gets a 10 kΩ resistor to ground, so the lines stay low while the Nano resets instead of floating. The Nano is wired directly, with no series resistors, and runs from its USB cable; its 5 V pin is not connected to the bridge.
💻 The Software
A Windows app, MeterBridge (C#, .NET 8), does the driving. It finds the adapter by itself, whatever COM port Windows has given it.
The main window: 26 sliders, brightness, and the spectrum controls.
| Feature | What it does |
|---|---|
| 26 sliders | Set any column to 0–15 LEDs by hand. Only the column that changed is sent: the bridge keeps every level until it is overwritten. |
| Spectrum analyzer | Listens to whatever Windows plays and splits it into 23 bands from 32 Hz to 16 kHz, across the input columns (one kept dark) and the 8 bus columns. The loudest band lights all 15 LEDs. |
| MONITOR A | The separate pair shows the left and right level, on its own automatic gain, so the balance shows. |
| Sensitivity | A slider for the bands and one for MONITOR A, −20 to +20 dB each. |
| Smoothing, Decay | How quickly the bars rise and fall, five steps each. |
| Ignores the volume knob | Windows lowers the audio before the app hears it. The app reads the volume setting and adds it back, so the bars don’t sink when the music is turned down. |
| Brightness | 0–100 %, every column dimming the same. |
| Reset bridge… | Walks through the power-up sequence that puts the bridge back into its known state, then reconnects. |
| Sync scan… | Re-finds the display scan by eye: one click on the column that stays lit. |
| Remembers | Levels, settings and the pulse count are saved. If it was connected when it closed, it reconnects when it starts. |
A command-line companion, mbcli, runs the self-tests (among them: every update is simulated against a software model of the two chips, for all 1,024 combinations of their word timing) and the bench tests that work with the analyzer and the camera. The Nano runs its own small firmware, which plays out each update from memory at about 600,000 pulses a second.
⚖ What Worked, What Didn’t
✅ Worked
- Three wires and a counterfeit adapter, at its 3 Mbaud maximum. The chips never missed a pulse at 1.5 MHz.
- One pulse per byte. Using the serial port as an exact, slow clock turned guesswork into controlled tests.
- Moving one bit at a time through the stream and watching where it lands. It mapped the whole format in an afternoon.
- A webcam as an instrument. It read every column’s height and brightness, and made unattended runs possible.
- A software model of the chips, checked against the bridge, so every update is simulated before it is sent.
- Measuring before giving up. The adapter was written off as “not good enough” four times, each time for a reason a measurement later showed was wrong.
- The Nano, wired directly with pull-downs, and the one-pulse
LWCKsync.
❌ Didn’t
- Talking to the microcontroller. One byte in 256 did anything, and all it did was silence it.
- The adapter’s bit-bang mode. The counterfeit chip ignores it.
- A floating address line. Every early test ran with pin 3 at an undefined voltage, so none of them could have worked.
- Fuzzing. Random signals lit new columns by luck, but never twice.
- Trusting a flat line. A probe that is not connected reads exactly like a quiet wire. A day’s worth of “verified” tests verified nothing.
- “Unplug the adapter before power-cycling.” Made a rule after one stuck column, it was the very thing that scrambled the display.
- A wire to a mislabelled pad, pin 6 to “RX”.
- The first Nano runs. Swapped wires, probes loading the lines, a scrambled display, and a “ringing” clock that got the blame but was never measured, and turned out not to exist.
- Peak-hold dots. The console’s manual mentions peak dots on its meters, which raised hopes of single dots on the bridge. Nothing reachable through the connector draws a lone LED: every level is a bar from the bottom.
🧭 The lessons that cost the most time
Check every probe against a signal you know is alive before believing a flat line. Keep guesses labelled as guesses, or they quietly become facts in the notes. And before calling something a hardware limit, measure it.
📍 Where It Stands
As of October 2026:
| Part | Status | Notes |
|---|---|---|
| All 26 columns, 0–15 LEDs | Done | Bit-exact, three wires. |
| Brightness | Done | 0–100 %, even across columns, steady while updating. |
| Flicker | Done | At the camera’s noise floor. |
| Spectrum analyzer | Done | 30 frames a second on the adapter, 60 on the Nano. |
| Power cycles | Done | Nothing to recalibrate between sessions; a Reset wizard for anything else. |
| Arduino Nano | Done | Optional second driver; syncs the bridge by itself at every connect. |
| Bridge heartbeat into the Nano | Open | The firmware listens for it; the wire and the app side are not done. |
| Single LEDs, peak dots | Not possible | Not through the connector. It would mean opening the case. |
🚧 What’s Next
- The bridge’s heartbeat into the Nano. With pin 6 wired to an input on the Nano, the app would notice when the bridge is switched off and on while it runs, and recover by itself.
- One last look at the serial line. Sending the microcontroller pairs of bytes, a command and a value, to see whether anything switches a bank or draws a dot. Lowest priority.
- Per-LED patterns (dots, text, scrolling) would mean opening the case and driving the LED driver chips directly. Not planned: bars are fully solved without it.
- Maybe an ESP32. If patterns ever outgrow the Nano, an ESP32 can stream all the lines straight from memory, the way LED-panel libraries drive big matrix displays. It runs at 3.3 V, so it would need a 74HCT buffer in front of the bridge.