Start of a 5.1 surround monitor box project

Years ago I was working with Barry  Porter, of Trident/Cadac fame, on a little 5.1 monitor selector using the now obsolete Wolfson WM8816 integrated circuit. I’d met Barry while working on Final Test at Cadac, a strangely disfunctional, but successful company  (Enid…)

I’d been working on and off as stage crew, in Video Village, all over Europe. Barry used to pick me up from Luton Airport, and drive me home from those depressing corporate soul sucking video gigs. It was great to get back to my little  scruffy spare bedroom  workshop and “do” some analogue. We chatted for hours on the phone about studio audio, I was good at Studers, A80’s  etc. and he was great at consoles.  A good mix.

Good days.

I was doing the 8051 programming for the Monitor Box, as Baz didn’t have a clue, but I was sort of OK with doing 8051 stuff at the ground level / interface in C.

Anyway Barry died and so the 5.1 project ground to a halt, and I had moved to Spain.

So this is my little tribute to Baz, and my modern  version of what I hope Baz would approve of.


Found the display bug

The Jenny program consists of 2 parts, a LTC reader and a LTC generator joined together by a teeny bit of code that monitors  a push button every frame in TC read, if the button is held down for 25 consecutive frames it transfers from TC read , (storing the current incoming LTC of course) at bit80, the end of the current frame, and trundles over to the TCgen code in a microsecond or so, continuing from the LTC stored when the reader handed over to the Jenny.  It needs most of that microsecond to set up the numbers for the frame rate counter, figure out if DF or NDF standard, and look up the fiddle factors to compensate for any long term TCXO errors, from when the board was calibrated against my rubidium clock.

The TCreader has a lot of debugging code in it, like set a port pin high or low if something (defined by me) happens. I use the AVR’s PORTB for debugging, just convenient for the circuit board that I made.  The graphic LCD has it’s reset line connected to a PORTB pin, and somewhere in the TCreader this pin is being set low, unintentionally, so stopping the display, so not a faulty display, just me being untidy.

The TCgen has been running on the bench for a couple of weeks without dieing,

Happy, just got to get some enthusiasm to find the bug in the Reader part of the code.

TC Jenny

My TC Jenny, was just going too well, then the graphics display dies after a few minutes , and it was looking quite pretty.

So far

It reads external time code, all flavours.


It generates TC and will jam to external code, frame accurate. It’s only running off a standard 50ppm accuracy crystal, so about a frames drift every couple of hours, a TCXO will fix that.


Reads TC via the 433 MHz receiver, haven’t got the signal strength metering working, or any simple error checking.

Haven’t got the menu working, run out of push buttons, needs a a 9V battery, I need to get my hands on a little  switch mode IC so it can run off 2 AA cells, like the LTC3499, looks like a nice little animal.

It uses a Atmel micro which is almost full

AVR Memory Usage


Device: atmega88p

Program: 7672 bytes (93.7% Full)

(.text + .data + .bootloader)

Data: 117 bytes (11.4% Full)

(.data + .bss + .noinit)

The main program is only about 2300 bytes of that, most of  it is storing the fonts for the display, so it needs a chopping down with a chain saw, so I can get the Menu in.

Got sidetracked

A quick test to see how a cheap  inexpensive graphic LCD can display real time LTC, and evaluate the LCD in terms of how much modification to the open source software is needed

Take a bright yellow Hammond 1553 plastic box and hack a hole in it.
CNC Milling it under water cools the milling bit so the plastic doesn’t melt. Only took a couple of minutes to cut the hole, nice clean edges.
Blu-tack a LCD module,a cheapo generic RF receiver module and little circuit board left over from another project.
Copy some software I wrote from my precision TC generator into the microthingy, and bodge it to use a LCD instead of a LED display.


Almost got it straight..

Just need a matching red box for the LTC transmit side of the equation.

Not bad for a couple of days work.

The new box arrived

A lot of spare time now, so more done on the box, it’s been sitting around for long enough. I’ve been playing around with the clapper, countersinking the brackets. It looks nicer, but takes a very long time to mill in my Sherline CNC setup, much more than a couple of hours.

The weight is about 520g, just over a pound, with batteries.Image

Much neater than my metal work, pity they ignored my “No Screw Holes  to be Visible”. A minor miss-comprehension! Otherwise all OK.

It cost over the equivalent of one months apartment rent.




Still a few things to consider such as the  paint finish, should it have a removable transparent  polycarbonate front plate, so you don’t need to write on the box.

This is what it looks like before I finish the wiring. That’s the last development board being sacrificed. The new one (to be) is much better in terms of talking to the outside world, that’s switches and button to press, and possibly LTC out, after it has been jammed.


Can’t do much more until the Molex connectors arrive, hopefully tomorrow

Just about finished

All the code works, it’s stable, and so is the hardware.

Just waiting for the finalised metalwork to turn up.

My Vinten tripod is on sale on Spanish Ebay to help pay for the first batch.

The only things left to do are add and test an off the shelf bootloader program so the slate can be re-programmed without Return to Base hassles through the USB port.

Nice for custom apps.  A very accurate intervalometer for DSLR’s was the first thing I thought of.

Ball park price? 500€ or about 650$

Cross jamming time code


Just checking the timing (again), feeding the slate with 25FPS from my atomic boat-anchor reference LTC generator.
The jammed slate was set to generate 23.976NDF and it crossed jammed fine, it wasn’t intentional, honest!
Accuracy was in the region of 2 parts in 10 million, measured over a 2 second period, with a 10MHz clock, and tweaked some “numbers” via the slate’s USB serial port in the temperature compensation routine.

20.020,020 Hz. This is the perfect frequency for DF code

and this is what the slate  gives out, pretty spot on

Probably won’t cross jam between 24 and 30 FPS, too greater difference for the LTC pulse discriminator to handle.

I could write some code to prevent cross jamming, as it could be dangerous in the wrong hands.

Not sure whether to leave as is.

Still deperately waiting for the finished case from the metal fabricators in the UK, rent’s due again, where do the days go to?