Overview

• CAMMS - airborne component
• Quasonix - air-to-ground RF link
• DGX - CAMMS image processor and network device
• GDP - ground based adaptation of WASP ADP

DGX ↔ GDP Communication

This is a summary of what Steve Kapp and I worked out together in a meeting while the rest of the group was describing calibration and ortho-rectification. What we settled on is a middle ground between Steve's preference for records and my own streaming preferences. Steve, go ahead and add comments here or propose changes as you see fit. -- BobKrzaczek - 20 Nov 2007

Notes:

• Each CAMMS image is, nominally, 6MB. Compression might gets us down to the 3MB neighborhood.
• DGX and GDP communicate with each other over simple network connection.
• We'll ride over TCP. We'll sacrifice some bandwidth for reliability and error correction.

Starting State

The DGX listens for connections from the network via TCP on a specific port. When any network client, such as the GDP, wishes to receive live CAMMS data, it opens a connection to this service and begins processing messages from the client (as in a limited form of a command loop). In the future, multiple cameras and data sources can be served on multiple ports. This port number should be easily reconfigurable. We'll agree to a port number between the DGX and GDP in advance.

For this project, we'll use port 6 (still unassigned by IANA).

Presently, in some tests, I'm using port 6789 to make it easier to deal with the privileged port issue. We can later decide on a permanent port assignment for this system. -- BobKrzaczek - 26 Nov 2007

Message

Each message exchanged between the client or server starts with a single byte that defines its contents.

Immediately after this byte are three padding bytes, which should always be zero. Maybe we'll use them for an extended command, or a priority, or some other functionality in the future.

Next are four bytes defining the length of this message in little endian format. The remainder of the message is the payload. "Empty" messages (a command with no data) are fine, but they must specify a length of zero. So, every message sent between the client and server is always at least eight bytes long. This length field includes the length of the header, so even an "empty" message would have a length of 8.

Commands that don't define a payload (e.g., the start command) may still include a payload that's used for debugging purposes. The receiver can ignore these unimportant payloads, log them, or do anything else; all that's really important is that the message length bytes are respected.

Because we're using TCP, we won't bother with checksums or framing bytes.

Negotiation

Upon a new incoming connection, the server sends a description of the channel to the client (see below), and waits for further messages from the client.

Start

When the client wishes to start receiving data from the server, it sends a message of type S to the server. No payload is defined for this message.

Stop

When the client wishes for no more CAMMS data, it sends a stop message to the server. The server should stop sending data to the client at its earliest convenience; once sent, there's no guarantee the client process further data packets.

A stop message does not drop the connection. The server can be instructed to start again at a later point, for example.

Goodbye

Either side can choose, for various reasons, to terminate the session. Rather than just dropping the connection arbitrarily, a goodbye message can be sent by the side wishing to terminate. The receiver of this message should then drop the connection. A sender can, obviously, wait for a period of time after sending this message, and then choose to drop the connection itself if there's no action by the receiver.

NOP

Either the client or the server can send a NOP message to the other side. This is not required; however, some networks require "keep alive" functionality. More importantly, though, this message could be used during those periods when the CAMMS is not acquiring data during a flight, and the operator at the other end of the link wants to know when was the last time the system was "heard from".

I don't think we need this now, but it's something to keep in mind.

Alternative: a message that must be "answered". A simple "are you there?" message, that must be followed up with a "yes" message.

This is not to be implemented in the current protocol. However, for possible concerns listed above, we'll keep this as a placeholder to start future discussions, should the need arise.

Description

The description supplies all the static information that is associated with the camera data available in this channel.

Width and height are typically 1920 and 1080, respectively. Bands would be 3 for typical color (RGB) imagery.

The bits per pixel tells us how many bits are used in each value in a pixel. Note that the raw image data is still packed on 8 bit boundaries; so, for example, even if BPP were 12 (as in the case of the GSI Terrapix), the individual values in camera data would still be padded out to 16 bits. When the bits per pixel are 32 or less, an unsigned integer value is assumed. If 64, IEEE single precision reals are assumed, and 128 indicates IEEE doubles. CAMMS is understood to be using 8 bit data, here, and so this field should be 8.

The interleave describes how the values making up a pixel are arranged in the image. 0 indicates band interleaved pixels (BIP), 1 indicates band interleaved lines (BIL), and 2 indicates band sequential (BSQ) format data. Even though the Leica ortho-rectification software only works with the usual BSQ style imagery, we're expecting BIP data from CAMMS.

The short description of the channel is used to identify it with a name (e.g., "CAMMS") for use in logs, filenames, and such. The long description of the channel describes its contents, software versions, dates, and the like (e.g., "CAMMS v1.2 3/4/5678, DGP v9.0, Foobar 7"). Both strings are encoded with a leading length (as in Pascal strings, or Forth counted strings) and use UTF-8 encoding for their contents (although just the ASCII subset will probably be used on this project).

Camera Data

In the interest of space and accuracy, we're going use raw binary in a lot of fields here. All raw binary fields are defined to be in little-endian format.

Right now, we're defining things in the WGS-84 UTM coordinate system.

The payload of a Camera Data message first presents all the "small" data that goes with an image, followed by the image data itself.

Outstanding GDP Issues

Need CCD size parameter for CAMMS, part of its interior orientation. We're currently subsampling Terrapix data to simulate CAMMS data. The CCD in the Terrapix has a 9μ square pixel. In scaling down from a 4096 × 4096 image to 1920 × 1080, we're multiplying the Terrapix pixel size by . This is just a "best guess", it would be great to get the real number here.

The Leica based software cannot accommodate crossing UTM zones; thus, once a flight begins in a particular zone, it has to stay within it.

Still fighting the brittle Leica software, moving from Terrapix and Phoenix imagery to CAMMS.

• Leica's software is only defined to work for planar (band sequential) data. Worse, it has never worked for 8 bit data. It is unreasonable to have CAMMS send us 12 bit (like Terrapix) or 16 bit data when the source data is only 8 bits; this is a waste of our communication bandwidth (which we suspect will become a rather precious commodity). Therefore:
  1. GDP receives BIP8 (a.k.a. RGB24) data from CAMMS, as expected.
  2. GDP not only reorganizes, but also pads, the data into BSQ16 format.
  3. Leica ERDAS Imagine ortho-rectifies data.
  4. GDP converts data back down into BSQ8 format, and stores it GeoTIFF format.
• Leica software still having issues with my simulated interior orientations.
• Did the old DEM issue come back? No; problems are reproducible without DEM.