Home
  Balloons
    Globo 4
      Digicam
        Protocol

Language:
  Espaņol

Digicam
  weeCam
    Internals
    Principle
    Sensor
    Protocol
    Analyzer
    Program
    Tests

Subjects:
  Flight 2(bis)
  Flight 3(bis)
  Flight 4
  Theory
  Other 'ballooners'

Protocol

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.

IEEE-1284 Negotiation

Luckily, with modern computers, parallel ports have seen some progress too. Particularly, when IEEE standardized the colorful mixture of weird protocols that appeared on the market, a giant step forward was achieved towards high-speed parallel communication. It's probably the IEEE-1284 spec that saved the parallel port from its demise at the same time as the serial ports.

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.

Parallel port ECP protocol

ECP protocol 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.


1284-mode Original Direction
HClk Strobe Out
HAck Autofeed Out
PClk Ack In
PAck Busy In
RevReq Init Out
RevAck NoPaper In
XFlag Select In
1284Active SelectIn Out
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!

14294


(c) John Coppens ON6JC/LW3HAZ mail