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.
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.
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.
My TC Jenny, was just going too well, then the graphics display dies after a few minutes , and it was looking quite pretty.
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
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.
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.
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.
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
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$
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?