Kodak Ektapro 1000 TR high-speed video system
Shortly after having fun playing with a high-speed video camera system I was lucky enough to get access to, I found a similar system on ebay. It had previously failed to sell, so I was quietly confident, and was the only bidder, winning it for the opening price of $375... Plus $600 to ship it to the UK...!!! Still a bargain I thought, for something that I believe sold for something like $70,000+ when it was new!
This system was the predecessor of the 1012EM system I used before, and records images on tape instead of DRAM. It came with the intensifed version of the imager - the smaller box on top is the controller for the intensifier. As well as allowing adjustment of the gain, the intensifier also allows the exposure time to be gated down to as little as 10 microseconds, although I suspect this would require some insanely bright lighting to be useful..!
However on receiving it, I found a major snag - the control keypad was missing. This was a major problem, as although I could get a live image up on a monitor, confirming the image sensor was OK, I couldn't do anything else.
As soon as I saw the size of the tape controller (12x18x24"), and the dubious state of the 2 tapes I got with it, I decided that the eventual aim would have to be to replace it with a more modern DRAM based controller, however I wanted to get the system working at least to the extent of being able to set up the various camera modes & frame rates etc. to help reverse-engineer the imager interface.
some hunting, I eventually found a picture of the keypad on the site of a used
test-equipment dealer, and I spent a day or so emailing the addersses of anyone I could
think of who may have had some contact with this system in the past - college labs,
research facilities, high-speed video system distributors etc. to see if I could find
either a keypad or info on the serial protocol it used. A significant problem is that the
Kodak Spin Physics division that originally made this unit had been sold some time ago,
and as I wasn't a 'paying customer', tracking down anyone useful was not going to be easy.
I did get a response from a guy at Redlake (the company who it turns out bought the Kodak
division), and he thought he might have a keypad somewhere but this didn't pan out.
OK, so now to 'Plan B' - reverse engineering time...!
I dug out and blew the not-inconsiderable amount of dust off my old HP 1650 logic analyser. I've probably not used it for 12 years as it's that long since I had any dealings with a processor whose address & data buses were accessible, but knew it would come in useful one day. (Image right - Analyser probes attatched to the bottom of the 68000 processor PCB)
Logic analysers, and in particular state analysers, are an indispensible
tool for jobs like this, as they take a lot of drudgery and guesswork away from tracing
though disassembly listings. When set up correctly, you can get a snapshot of the
processor's execution, showing all program memory fetches, as well as RAM and data I/O
operations, complete with addresses and contents, and bus states decoded to meangful
symbols (e.g. "byte read", "word write" etc.).
< Logic analyser trace display. This corresponds to the disassembly listing below. Even if you're not too familiar with 68000 code (I'd never seen any before...!) you can see how much more information the analyser trace provides, revealing for example that D0 has a value of 0057 when written to 837C0 (line +0007), the branch at 42B5C is taken (the read from 42B5E is due to the CPU prefetch), and the value 0052 is read from 837C0 (line +0017).
00042B50 33c0 0008 37c0 MOVE.W
In desperation I fired off a few more emails to various people in the hope
of finding someone who knew anything at all about this system - even the button labels
would have helped at this stage. I then got back to doing some some real work for a
while.... Fortunately one of these mails found its way to someone who used to have one of
these systems many years ago, and although they had long-since traded up to the RAM based
EM1012 version of the system, still had the old manual, and was kind enough to photocopy
it for me.
I could now try to do things with the tapes, but my initial doubts over the state of the tapes and drive were confirmed by some nasty graunching noises and mangled tape. the rubber rollers were worn and starting to decompose, being slightly sticky. Trying to run tape at over 20 feet per second over sticky rollers is never likely to be pretty....
However I could now set the various different camera frame-rates and frame-split modes (the system can do partial frames at up to 6000 frames/sec) and look at how these affected the data going through the imager's huge 79-pin military-style connector (right).
Fortunately the image interface appears fairly straightforward.
The digital side of the interface appears to be about as simple as it could be - a 3.072MHz pixel clock, a 'start of frame' pulse, and 3 static lines that control how the image is 'sliced up' in partial-frame modes. The only minor complication is that the pixel clock changes at different frame rates but in retrospect this isn't really surprising - I'd just not given much thought to how lower rates would work.
See next section below for progress on replacing this humongous tape system with something more sensible...
]Meanwhile hare are some pics of the insides of this beast...
Note considerable size of motors (9v battery for scale)
Each hub of the custom-made cassette has a ball-race bearing, and construction in general is somewhat industrial.
I wonder how much these tapes cost originally....
Main card-cage (left) and contents (right)
This lot puts out a serious amount of heat!
The whole unit is absolutely stuffed with electronics, and not a surface-mount component in sight!
(left of picture) PSU regulator board. There is also a huge switchmode PSU in the base, plus a big ni-cad battery pack whose sole purpose in life seems to be to stop it tearing apart the expensive tape if the power fails while running.
(right of picture) Tape drive controller board
Write driver board and eject mechanism controller
The multi-track head assembly
I was pleased to get the intensified imager with the system, as it would make it much
easier to use at sensible light levels, but the penalty is significantly poorer image
quality - at the highest gains the image is very noisy, and even at the lower settings the
image has a rather grainy appearance.
Inside the imager, "Proxigate" intensifier assembly is on
the right (Made by Proxitronic in Germany).
I needed to check that the optical interface of the sensor would work OK on its own - it had been encapsulated & polished, and was fitted in direct contact with the fibre-optic face of the output end of the intensifier, with some sort of grease inbetween, presumably to avoid an air gap and get a consistent refractive index.
Fortunately I was greeted with a nice crisp image, so at some point I will do the
requisite metal-bashing to fix it all together properly. And then look for some bright
The face of the sensor after seperating from the intensifier. Apparently it's an NMOS sensor, not a CCD.
This chip is by far the most unique and valuable part of the system and would probably
have originally cost many thousands of dollars..!
At least as important though, the combination of the already quite big imager, and this monster lens looks really impressive!
Work In Progress.....
I've been wanting to get into using FPGAs for a while, and now I have a meaty project to get stuck into - I find the best way to learn about something new is to have a 'real' project rather than just tinkering around, as you have to work through any problems rather than just flitting on to something else when you get stuck.
I bought a Xilinx S3 starter kit to use as the basis for the processor. This contains a 200K gate FPGA and plenty of connectors for hanging external circuitry on to.
Current plan is to use eight TI THS10064 simultaneous-sampling ADCs doing 2 channels each, producing a 64 bit wide datastream into a 512Mbyte SDRAM DIMM. For readout, the 64 bit bus will be multiplexed down to 8 bits to reduce the number of FPGA pins required - there is no benefit in using a wider bus, as the data needs reading out a line at a time for display, and adjacent bytes will correspond to vertically adjacent lines.
SDRAM was chosen as available capacity on one DIMM is sufficient, and DDR is substantially more complicated to drive, and I don't need the extra speed. 512MBytes will give about 10 seconds' recording at 1000 frames/sec.
I spent a while looking at possible ADCs - there seems to be a gap in most
manufacturers' product range between the slow stuff up to a few hundred Ksamples/sec, and
the stupidly fast stuff at 20-30Ms/sec upwards. The THS10064 seems like a good fit, as it
will sample 2 channels simultaneously at 3Msamples/sec, and also has a fifo. The latter is
very useful when used in conjunction with SDRAM, as to get the best throughput from SDRAM,
you need to use burst accesses. The ADC FIFO allows 8 words to be read in a short burst,
leaving time to do a SDRAM burst-read and refresh cycle inbetween, to provide apparently
'simultaneous' write and read operations, so a live image can be displayed whilst
I'm hoping to be able to generate the VGA and CCIR outputs simultaneously. Display image data will be read from the SDRAM into two alternating line buffers for display. The line buffers will compensate for the different timebases for reading and writing, as well as allowing for easier line doubling/trebling to display the 192 pixel high image as 384 or 576 pixel high on VGA or SVGA TFT panels respectively. The Spartan-3 FPGA has several 2kbyte dual-port RAM arrays which are ideal for this. Another of these arrays can function as a pixel lookup table to allow for greyscale adjustments like gamma correction of required.
At some point it will probably also get a USB2 interface to dump the data
quickly to a PC, but I think I have plenty to be getting on with for now....!
A couple of days' tinkering with the FPGA board & a surplus 12" 800x600 TFT panel..... Display is arranged as 240x192 main display (pixels triplicated to 720x576 to fill screen), a status line along the bottom and an area to the right for displaying menus etc. Until I get some real data, the display shows a few test patterns selected by the switches. FPGA VHDL code here - excuse any un-prettiness - it's the first thing I've ever done in VHDL...!
Data on TFT panels is pretty scarce, but panels of the same type seem to be pretty similar interface-wise. You need to make sure it has a TTL type interface (3V logic levels), not a high-speed LVDS one - VGA TFT panels tend to be TTL, SVGA can be either, anything bigger will usually be LVDS. TTL panels typically have a 41-pin connector (6 each red,green,blue data, HS,VS,Data En and clock).
LVDS ones will have far fewer lines on the cable, usually twisted-pairs. I
would guess that later panels have integrated LVDS decoders, but I just looked at a common
800x600 panel (Samsung LT121S1-101), and it uses a Nat.Semi DS90CF562
receiver - this seems to provide a 'transparent' interface between the LVDS and TTL
interface, so to get one of these panels working, you could either use a DS90CF561 encoder
to drive it (scrap laptop PCBs would be a good source, but they are also available from
Digikey), or remove the LVDS receiver chip and connect to the TTL interface. pads. It
might be possible to drive the LVDS interface directly from the FPGA but I suspect the
timing would get a bit hairy due to the high clock rates involved...!
Not had much time to do much recently, but now we have some nice
anti-aliased text for menus etc...!
Screen shows output from sinewave input.
Imager timing is being driven by my board - the old system chassis is only being used for power. This is a lash-up to prototype the imager-to-ADC interface.
As there are 16 input channels, and there is a lot of high-frequency crud floating around, I want to put everything from the imager input to the RAM on a single 4-layer PCB, so I need to be fairly sure the input amp worked reasonably well - track-hacking each of 16 channels on a dense surface-mount PCB later would not be fun!
One of the 16 channels is being digitised and displayed as compressed 'slices' on the LCD.
The ADCs seem a little fragile - I've melted 2 of them so far....!
25 Sep 05- a major milestone - the imager is now operating completely independently of the original system, and displaying a recognisable image. The only remaining part of the original system is the connector board that breaks out the connections from the big round military-style connector (left) to more sensible IDC connectors - this will be incorporated into my controller.
As only one of the 16 analogue video channels is being digitised, the
image is a series of slices, like looking through a set of shutter blinds. However this is
good enough to evaluate image quality, noise and bandwidth of the video amplifier so I can
finalise the layout of the ADC/memory PCB.
Layout of the ADC/Memory board is now done. This four-layer Eurocard-sized PCB contains 16 differential video input amplifiers, 8 2-channel ADCs, a 512MByte SDRAM SIMM, some bus multiplexing to funnel the 64 bit SDRAM bus down to 8 bits, a DAC to set the black/white levels for the ADCs, and an interface to a USB2.0 module (from http://www.quickusb.com)
Fortunately I took some time to check it carefully, and found a problem
with the bus-steering logic that required a minor redesign of the decoder - instead of the
original 74AC138, a small GAL would be needed. Unfortunately, '138 was in an SSOP package
buried right in the middle of the PCB, and as they don't make 20 pin SSOP packaged GALs,
and a PLCC20 wouldn't fit, there was no space for it. Instead of doing a major rip-up I
decided to just put the GAL on a little vertically-mounted sub-board. Anyway, it
would be sitting next to the SDRAM DIMM so shouldn't look too out of place..!
Most of the components on the underside are decoupling capacitors and noise filtering inductors for the ADCs.
Miraculously there was only one error on the memory board, hence the white wire...
More progress - implemented the SDRAM controller.
First thing that looks like an image, but only just. Something clearly not right with the SDRAM addressing, and the data seems to be going negative at some point...
The addressing is somewhat involved, as the data comes in 16 parallel channels from the imager, and is then rearranged into 8 interleaved channels by the ADCs, and then for readout the 64 bit SDRAM bus gets funnelled down to 8 bits before being written to a 2-line de-interleaving fifo memory for the LCD display.
The imager connector shell found its way to an exposed mains-live lead on the PCB of one of the power supplies. Fortunately it was well earthed, and the only damage was a fuse in the PSU.. Phew!
Nearly there... after figuring out the address problem, still some odd negative things happenning.
Then I remembered the ADC had a mode bit to select offset or 2's complement output formats.....
Fortunately I'd already written most of the PIC code to to the record/playback control, so as soon as I had a proper picture I could do some recordings. Unfortunately it's now late in the evening, and the workshop lighting isn't really up to doing anything exciting, even with the image intensifier - will have to wait til tomorrow to play...
The only thing left now is to get the USB link working so I can get the images out of the box.
The new controller in its box, which originally housed the cassette
conditioner (this was a unit that as fas as I can tell wound and rewound the cassettes to
make them work better at the extreme speeds the old tape controller used).
I also decided that it would be useful to have an external video output for projectors or an external monitor, as I'm expecting to use the system for demos/presentations. The original plan was to have a composite video output, like the original system, but this would have been problematic due to the amount of SDRAM bandwidth available and availability of RAM resources in the FPGA for a line buffer.
I then realised that it would be really easy to provide a VGA output, as
the timing was the same as for the TFT panel - All that was needed was to add a DAC onto
the existing TFT data bus, and generate a couple of slightly re-timed sync outputs.
Not looking forward to cutting out a hole in the steel panel for the LCD....
Update 10-Mar-2006. First images!!
I've been too insanely busy with Real Work to do anything on this project
for a while, but I'm going to a tesla coiling event tomorrow, so did a mad last-minute
scrabble to bodge together enough software to get images out to the PC.
1 Apr 2006.
After using the system at a couple of events, I found that having my
controller and the intensified imager controller in seperate boxes made it somewhat
cumbersome to set up and move the camera around, so as there was some space left, I
decided to build the intensifier controller into the main controller casing.
..and finally got round to hacking out a hole for the TFT panel in the front case lid.
"Second floor.. power supplies...."
The 24V switcher on the left now supplies the imager regulator PCB (centre) and the intensifier controller.
Things are getting a little more cramped, so an 80mm fan was added to help the air get around better.
Intensifier controller PCB, mounted on top of PSUs.