CameraWorld Part 3

CameraWorld: Hiptop Camera and Serial Data Transfers

Part Three:
Hiptop and Camera Data Gathering

Hiptop Analysis:
The Hiptop does not begin to deliver voltage until it starts to send camera clocks, and is removed after 10 seconds of camera inactivity. In addition, the Hiptop will probe the camera when it is plugged in with some sort of impedance check. This can best be seen by using a long (6 foot) extension cable to attach the camera. When the camera is plugged in, you will get an alert that the camera is not correctly attached. Shortening the extension cable to 3 inches allows the camera to function correctly. At present it appears the clock line is being checked to differentiate between a camera and a headset, but have yet to determine the connection heuristic being used.

The Hiptop sends out a clock signal of 1MHz (the new color version has yet to be tested). As for clocking in data, the camera asserts its data at the rising clock edge and is valid up to the next rising clock edge. For those of you keeping score, this means the camera data is good at the Hiptop's source clock falling edge. However, it would be best if you did not dilly dally sending data once you see the rising input clock from the Hiptop. Signal-wise, this is really about it for the Hiptop. The CameraDevice API grabs an image with a YUV 4:2:2 (YCbCr422) color space and a data size expected from a Treva type camera. This is good news since it matches everything known about the Treva camera module.

HW Specification:
Voltage: 3.3v
Clock: 1MHz (Gray scale original Hiptop)
Data: Valid on clock falling edge

1MHz, 3Vp-p DC clocks from the Hiptop to the camera. These clocks are not the cleanest ever seen, but it may be due to capacitance, inductance, and/or resistance of the breadboard.

Series of clocks from the Hiptop to the camera as an image is being fed into the device. Note the odd cyclic nature of the output clock voltage swing. Again, this may be a manifestation of the measuring environment.

Camera data scope plot. These data waveforms are nicely formed, and seem not to be affected by the breadboard measuring environment.

Data Specification:
ColorSpace name = YCbCr422 (Danger color space #11)
byteMapWidth == 120
byteMapHeight == 90
byteMapStride == 240 (2 bytes per pixel)
Note: Due to the YCbCr422 color space, bitmap size may be limited to a modulo 4 pixel run via 4 16-bit words for a complete sequence. We need to experiment with instrumented data to determine if there is an inherent size constraint.

Camera Analysis:

An eZ8 Encore! development system was used in an effort to verify the information on the Treva camera is similar to the Hiptop camera:
http://www.zilog.com/products/xq/asp/id.Z8ENCORE000ZCO/qx/partdetails.htm

The best tool for the analysis at hand was the eZ8 SPI (serial peripheral interface) for the camera communication. The SPI chapter in the Zilog Development Board User Manual and the SPI document "Interfacing an SPI Temperature Sensor with the Z8 Encore! SPI Bus", both found at the bottom of the Zilog page referenced above, are a good place to start for SPI documentation. Additional non-Zilog SPI references can be found at:
http://www.mcumaster.com/hc11/Block/SPI/spi.html
http://web.media.mit.edu/~fredm/papers/mb/node38.html

The host setup used for this development board was:
--> Macintosh 1GHz tower system
--> Virtual PC 5 running under OS9
--> Keyspan highspeed serial adapter set in VPC as Windows COM-1 port
--> Windows 98 under VPC running the Zilog IDE
--> Keyspan lowerspeed serial adapter used in OS9 by ZTerm for eZ8 terminal output
Under VPC, some serial devices work only under OS9 and some only work under OSX. Unfortunately, the eZ8 development board needed OS9 for reliable communication. VPC6 under OS9 has not been tried, but does not allow for reliable communication under OSX. ZTerm can be found at:
http://homepage.mac.com/dalverson/zterm

The eZ8 camera communications HW setup and code is rather simple. The quick and dirty engineering code does not handle bit shifted camera data since data is sucked in one full byte at a time. FYI: The camera tends to send full bytes of data at a time, but sometimes bit-shifted data is captured. This bit-shifted data may be the result of an internal camera state machine issue, but power cycling the camera seems to clear this up. Most of the online sample code sucks data in one bit at a time and will not run into this issue.

For initial characterization, bit-shifted data is ignored, the system is reset, and data capturing continues until data is returned as expected. Once real data started coming from the camera, it was easy to verify that the Hiptop camera is essentially a Treva style camera as expected.

The eZ8 Encore! development board was setup in the following manner:
Physical Connection from eZ8 board to CP-42524 4-Conductor jack (again, your mileage may vary):
Vdd 3.3v power == Outer ring
PC5_MISO data-in == Tip ring
PC3_SCK clock-out == Middle ring
GND ground == Inner most ring

SPI HW Initialization:
SPIMODE:
SSIO as an output by definition as a Master
SS pin set low in order to disable the eZ8 onboard temperature SPI device
8-bit data transfer as all data is 8 bit

SPIBRH/SPIBRL:
0x00, 0x10 resulting in about a 576kHz trigger clock

SPICTL:
PHASE clock phase hi
CLKPOL clock polarity lo
(SCK idle state is low, receive data on SCK falling edge)
SPI as a Master device
SPI Enabled

This is the 576kHz clock from the eZ8 to the camera. Note the 3 clock gap between sucking in 8 bits of data. It is very likely 2 clock ticks were missed due to slow running code at this clock speed.

However, as can be seen in this super slow 30kHz plot, there is still one clock missing for every 8 clocks sent to the camera. It appears this last missing clock is due to an SPI clock pulse generator reload sequence that prevents it from starting up within one clock tick.

SPI camera data capture eZ8 code:
ReadHeader()
Read data until we get 10 bytes of 0xff's in a row (waiting for sync bytes)
Read 0xff's until we don't see any more (wait for header marker start)
Read the next byte (byte 2 of the header marker)
Verify the header marker is 0xaa 0x55
Read the header frame bytes of 0xff 0xd8
Read the header size byte
Calculate remaining header bytes (header size &endash; 3, the 0xaa 0x55 does not count)
Read the remaining header information
Read the bitmap marker and verify correct (0xaa 0x55)
Calculate the width and height of the bitmap
ReadBitmap()
Read the next W * H * 2 bytes of bitmap data
ReadFooter()
Read 2 footer frame bytes
Verify the footer is 0xff 0xd9

eZ8 captured raw camera data:
27 85 2b 75 29 80 29 78
ff ff ff ff ff ff ff ff
aa 55 ff d8 1c f0 f1 00
78 00 5a 81 41 20 4b 43
23 38 42 50 2e 2e 00 00
00 00 00 00 00 00 aa 55
fe 7e fe 73 fe 7f fe 6c
df 80 ca 57 50 93 24 5d
...<camera image>
ff d9 ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
...<long string of 1s>
ff ff ff ff ff ff ff ff
aa 55 ff d8 1c f0 f1 00
...etc...

Camera Data Decode:
xx xx - Leading garbage (remaining image data bits from camera state machine?)
xx xx
ff ff - Leading 1s (Greater than 100 bytes, no guaranteed alignment, undetermined number of bits)
ff ff
ff ff
ff ff
aa 55 - Data start chunk marker
ff d8 - Header marker ID
1c    - Number of header bytes in frame (excluding 0xaa 0x55 chunk marker)
f0    - Device type (f0 == camera)
f1    - Device version
00 78 - Number of pixels wide (120) (pixels per line)
00 5a - Number of pixels high (90) (number if lines)
81    - 8-bit component data (0x8), YUV Space (0x1) ==> 16 bits per pixel (UY or VY)
41    - Data Order (Hiptop == 0x4 & Treva == 0x3 UYVY), Data Output (0x1 MSB Start)
20    - 4:2:2 (0x2), Incompressible data (0x0)
4b 43 - Manufacturer Information (KC#8BP..) <Kyocera 8 bit pixel camera>
23 38
42 50
2e 2e
00 00 - Additional Information (8-bytes)
00 00
00 00
00 00
aa 55 - Data start chunk marker
xx xx - Camera image data
xx xx   Number of bytes == width * height * 2 <16-bits per pixel>
ff d9 - Footer marker ID
ff ff - Trailing / leading 1s to repeat sequence (undetermined number)
ff ff
ff ff
ff ff
aa 55 - Data start chunk marker
ff d8 - Header Frame ID
etc.

Data Fidelity Analysis:

The last item to verify is camera data between that seen by the eZ8 and that captured by the Hiptop as seen in the CameraWorld sample application. There are high hopes this is the case since the camera appears to be YUV 2-byte per pixel, and the CameraWorld sample also claims the image data is YUV 2-byte per pixel. The real test will come when instrumented data is sent to the Hiptop in place of a camera. The other bit of info is the Hiptop API presentation of the data is byte swapped with the eZ8 captured byte dump. Since the eZ8 was capturing/printing data one byte at a time, it is assumed this is the natural camera data format and that the Hiptop endian swaps the 2 bytes of each pixel.

For this data fidelity test a black image and a white image were captured. Under a controlled environment, the eZ8 captured data and Hiptop data to look the same (within a small margin of error). There is a comparison problem where the camera will run an auto white balance & auto exposure compensation sequence when power is applied. Power was applied all the time on the eZ8, and by the time an image was captured, the camera had settled. For the Hiptop, power is applied only when it starts sending clocks. Plug the camera into the Hiptop and run the standard camera app in preview mode and you will see the camera auto compensate for exposure levels. The CameraWorld app and the eZ8 test apps did nothing to allow for auto image compensation of the camera before the data was taken.

BLACK IMAGE

Camera Header Data
ff d8 1c f0 f1 00 78 00
5a 81 41 20 4b 43 23 38
42 50 2e 2e 00 00 00 00
00 00 00 00 Hiptop Camera Information
ColorSpace = YCbCr422 (#11)
byteMapWidth == 120
byteMapHeight == 90
byteMapStride == 240

CAMERA IMAGE BEGIN
First 128 bytes:
1d 84 1b 7d 1a 81 1c 7b
1e 7b 1b 7d 1d 79 1d 7c
19 82 1b 7e 1c 7c 1d 7e
1f 83 1e 7f 1d 78 1f 81
1b 7c 1d 7f 1a 79 1c 7d
1c 84 1c 7d 1c 80 1a 7f
1c 80 1c 7c 1b 80 1b 7a
1b 84 1c 7b 1c 7e 1b 7e
1c 74 1b 7f 1c 7a 1b 7d
1c 88 1a 7b 1d 85 1d 7d
1d 81 1d 7c 1a 82 1a 7b
1c 84 1a 7b 1b 7c 1c 80
1b 7e 1c 81 1d 82 1b 7e
1a 7b 1c 7d 1c 7a 1c 81
1d 82 1d 79 1d 82 1c 7d
1c 86 1d 7a 1b 84 1c 7c

Last 128 bytes:
1a 69 1a 7f 19 69 1a 7e
1c 68 1b 7e 1a 63 1a 7f
1b 68 1c 7e 1c 6b 1b 7e
1c 6f 1a 7e 1b 76 1b 7b
1a 6b 1b 7c 1b 6e 1b 7d
1a 61 1b 7f 1b 71 1b 7f
1b 6e 1b 7d 1d 6f 1c 7f
1b 7a 1c 7f 1b 6d 1b 7e
1c 72 19 7c 1b 71 1c 7f
1c 6d 1b 7f 1b 69 1c 81
1d 6e 1b 7f 1c 69 1a 7a
1a 61 19 7b 1c 72 1a 79
1c 73 1c 7a 1b 6f 1a 7e
1b 70 1a 7e 1b 70 1a 7d
1c 70 1c 7d 19 6a 1c 7e
1a 64 1b 7c 1c 6a 1a 7d
CAMERA IMAGE END
HITPTOP IMAGE BEGIN
First 128 bytes:
7d 10 7e 10 7f 10 7d 10
80 10 7d 10 80 10 7d 10
80 10 7d 10 7f 10 7d 10
7e 10 7e 10 7f 10 7e 10
7f 10 7d 10 7f 10 7d 10
7e 10 7d 10 7e 10 7d 10
7f 10 7d 10 7f 10 7d 10
7f 10 7d 10 7e 10 7d 10
7c 10 7d 10 7d 10 7d 10
7d 10 7d 10 7c 10 7d 10
7f 10 7c 10 7e 10 7d 10
7f 10 7e 10 7f 10 7d 10
7d 10 7d 10 7f 10 7e 10
7d 10 7d 10 80 10 7e 10
7f 10 7e 10 7f 10 7e 10
7f 10 7e 10 7e 10 7e 10

Last 128 bytes:
7c 10 7d 10 7c 10 7d 10
7c 10 7d 10 7d 10 7d 10
7e 10 7c 10 7c 10 7d 10
7c 10 7d 10 7d 10 7d 10
7d 10 7d 10 7d 10 7c 10
7c 10 7d 10 7c 10 7d 10
7c 10 7d 10 7c 10 7e 10
7b 10 7d 10 7e 10 7d 10
7d 10 7e 10 7d 10 7d 10
7c 10 7d 10 7d 10 7d 10
7d 10 7e 11 7e 10 7d 11
7d 10 7d 10 7c 10 7d 10
7d 10 7d 10 7b 10 7d 10
7c 10 7d 10 7d 10 7d 10
7d 10 7d 10 7c 10 7d 10
7d 10 7d 10 7c 10 7d 10
HITPTOP IMAGE END

WHITE IMAGE

Camera Header Data
ff d8 1c f0 f1 00 78 00
5a 81 41 20 4b 43 23 38
42 50 2e 2e 00 00 00 00
00 00 00 00 Hiptop Camera Information
ColorSpace = YCbCr422 (#11)
byteMapWidth == 120
byteMapHeight == 90
byteMapStride == 240

CAMERA IMAGE BEGIN
First 128 bytes:
fe 7c fe 77 fe 7c fe 77
fe 7c fe 77 fe 7c fe 77
fe 7c fe 77 fe 7c fe 77
fe 7c fe 77 fe 7c fe 77
fe 7c fe 78 fe 7c fe 77
fe 7c fe 77 fe 7c fe 78
fe 7c fe 78 fe 7c fe 77
fe 7c fe 77 fe 7c fe 77
fe 7c fe 77 fe 7c fe 77
fe 7c fe 77 fe 7c fe 77
fe 7c fe 77 fe 7c fe 77
fe 7c fe 78 fe 7c fe 77
fe 7c fe 77 fe 7c fe 77
fe 7c fe 78 fe 7c fe 78
fe 7c fe 77 fe 7c fe 77
fe 7c fe 77 fe 7c fe 77
Last 128 bytes:
fe 7c fe 77 fe 7c fe 77
fe 7c fe 77 fe 7c fe 77
fe 7c fe 77 fe 7c fe 78
fe 7c fe 77 fe 7c fe 77
fe 7c fe 77 fe 7c fe 77
fe 7c fe 78 fe 7c fe 77
fe 7c fe 77 fe 7c fe 77
fe 7c fe 77 fe 7c fe 78
fe 7c fe 77 fe 7c fe 77
fe 7c fe 77 fe 7c fe 77
fe 7c fe 77 fe 7c fe 78
fe 7c fe 77 fe 7c fe 77
fe 7c fe 77 fe 7c fe 77
fe 7c fe 77 fe 7c fe 77
fe 7c fe 77 fe 7c fe 77
fe 7c fe 77 fe 7c fe 77
CAMERA IMAGE END
HITPTOP IMAGE BEGIN
First 128 bytes:
9b fe 75 fe 9b fe 74 fe
9a fe 72 fe 9a fe 73 fe
9b fe 73 fe 9a fe 75 fe
9b fe 73 fe 9b fe 76 fe
9a fe 74 fe 9b fe 74 fe
9a fe 76 fe 9c fe 74 fe
9b fe 73 fe 9a fe 74 fe
9a fe 72 fe 9b fe 73 fe
9c fe 74 fe 9b fe 74 fe
9b fe 74 fe 9a fe 72 fe
9a fe 74 fe 9b fe 71 fe
9b fe 74 fe 9a fe 74 fe
99 fe 74 fe 9a fe 73 fe
9a fe 74 fe 9a fe 75 fe
9a fe 73 fe 9b fe 72 fe
9a fe 74 fe 9b fe 74 fe
Last 128 bytes:
9c fe 73 fe 9c fe 74 fe
9c fe 72 fe 9c fe 71 fe
9c fe 72 fe 9c fe 72 fe
9c fe 72 fe 9c fe 72 fe
9c fe 70 fe 9b fe 73 fe
9b fe 73 fe 9c fe 71 fe
9c fe 73 fe 9c fe 73 fe
9c fe 72 fe 9b fe 73 fe
9c fe 72 fe 9c fe 75 fe
9b fe 72 fe 9c fe 72 fe
9b fe 74 fe 9b fe 73 fe
9b fe 72 fe 9a fe 73 fe
9b fe 71 fe 9c fe 72 fe
9c fe 73 fe 9b fe 73 fe
9b fe 73 fe 9c fe 72 fe
9c fe 74 fe 9b fe 72 fe
HITPTOP IMAGE END

<Back to CameraWorld Part Two

Last Updated: 6/19/03

email: eric3danger@outsidethelines.com

1MHz, 3Vp-p DC clocks from the Hiptop to the camera. These clocks are not the cleanest ever seen, but it may be due to capacitance, inductance, and/or resistance of the breadboard.
Series of clocks from the Hiptop to the camera as an image is being fed into the device. Note the odd cyclic nature of the output clock voltage swing. Again, this may be a manifestation of the measuring environment.
Camera data scope plot. These data waveforms are nicely formed, and seem not to be affected by the breadboard measuring environment.

This is the 576kHz clock from the eZ8 to the camera. Note the 3 clock gap between sucking in 8 bits of data. It is very likely 2 clock ticks were missed due to slow running code at this clock speed.
However, as can be seen in this super slow 30kHz plot, there is still one clock missing for every 8 clocks sent to the camera. It appears this last missing clock is due to an SPI clock pulse generator reload sequence that prevents it from starting up within one clock tick.