Language:
Español
Digicam
weeCam
Internals
Principle
Sensor
Protocol
Analyzer
Program
Tests
Subjects:
Flight 2(bis)
Flight 3(bis)
Flight 4
Theory
Other 'ballooners'
I did some preliminary spywork on the Windows drivers, hoping this would ease things, but apparently Alaris doesn't talk through the Windows API to the ECP port - it has its own drivers which directly touch the hardware. Some disassembly confirmed this, but then I tired of trying to guess how the code worked, particularly because most routines seem to have been coded several times.
Next stop, I decided that the way to go was hardware capturing the data flow. Again, my first try went wrong: I hoped I could put a 'thing' between the camera and the PC, which would manipulate the acknowledge lines of the parallel port to be able to acquire the datastream by software. Didn't work - it seems timing is important; somewhere, maybe in the Windows drivers, a timeout produced and it never worked well.
Ok... Last straw: I designed a complete hardware capture device, using two 32k RAM memories and quite a few other ICs, which captured the data in real-time. A kind of logic analyzer... It was actually quite impressive!I used the analyzer to capture, then transferred the captured data to my notebook using its parallel port.
This finally worked! Though I couldn't actually capture entire images, I was able to get most of the protocol, in different modes, and sending many commands to the cam (eg. change of brightness, contrast, etc.).
So, after many new sessions of guessing, I figured out probably most of the protocol. At least I was able to write a Linux program that actually controlled the camera. I've never written a driver for a Linux device, but maybe with this info someone will be able to do just that.
On startup, the computer will interrogate all devices on the parallel port, using a combination of signals that only IEEE-1284-capable peripherals recognize and react on. Several parameters are negotiated during this startup, and an identification string is received from the peripheral. Also, the peripheral can tell the host if it's capable of switching into EPP or ECP mode, and if RLL compression is available or not.
The IEEE spec also foresees the possibility of 'daisy-chaining' peripherals as was so popular with scanners, having the capability of even interrogating several pieces of equipment chained this way.
So, an operating system with IEEE-1284 capability, will detect all peripherals on startup. This happens, for example, if Linux was installed with 1284 support.
As a side note to developpers, the libieee1284 (see references) is an excellent tool to hide all the time-consuming details of the parallel port access.
This is not the place to find a complete definition of the ECP
protocol. Any browser will give you a number of places with better
information. I added this to give the protocol description a little
more structure.
There are 4 possible situations according to the ECP protocol, very nicely arranged. Transfers can be either data or commands. Some literature refers to commands as channels. And then we have two directions of the transfers: Forward from the PC to the peripheral, and the Reverse. Total: 4 possible transfer types.
The combination of the four lines: HClk and PClk (Clocks) and PAck and HAck (Acknowledge or handshakes) that define which type of transfer is happening and in which direction. The 'H' signals are originating from the Host (PC), the 'P's are coming from the peripheral.
|
Check the first graph (it's similar for the others): The host (PC)
wants to send data: Puts them on the datalines, then activated the
HClk line. PAck from the peripheral confirms reception, and permits
the host to release the HClk. This makes the peripheral to release
the PAck, and the cycle can begin again.
Normally, either Windows or Linux drivers take care of these details, but if you want to connect the camera to a microcontroller, you will have to generate these sequences yourself! |
| (c) John Coppens ON6JC/LW3HAZ |