Here is the information that we have on the PalmPix protocol. The protocol itself is very simple and easily broken down. The only part we are having trouble with is the color picture information. It is stored in some compressed form and without documentation I am having to take pathetic stabs at cracking it.
Initialization:
The XX is a battery level from 00-FF. Out: 88 Wait for: XX Out: 60 Wait for: 17 Out: 68 8A Wait for: 17 Out: FF 44 Wait for: XX Out: 00-FF
Getting preview frames:
Out: 88 Wait for: XX Out: 22
It should then send you 2400 bytes (always, regardless of 22 or 23) of black/white data as a preview frame. Repeat that 88 22 sequence to get another preview frame. Zoom mode 2X (in 640x480 only) is achieved by using 23 instead of 22. This data looks to be in a simple 160x120 matrix of bitmap bits.
To grab a full-size picture I believe this is how it is done. I can't be sure that there isn't an extra sequence at the end or something because this operation does not complete while in POSE.
To get a 640x480:
Out: 55 57 77
Picture data then will then be sent. Note that the palmpix software started sending 55 57 but waited until the last preview frame was complete before it issued the 77.
The picture data is sent in bands. I haven't added it up yet to see how large each one is, but I presume each one is what is represented as a block on the progress bar. After the initial band which is sent, you need to send a 00-XX to get successive bands. I've only gotten POSE to give me 3 bands at most before it gives an error so I don't know if you need to know the number of bands ahead of time or not.
A 320x240 is the same except you send 55 57 78.
For zoom 2X of 640x480:
Out: 56 58 79
At the end of the whole process it looks like you send it an EE byte.
Okay I did a little more in looking at the full-size picture data. Each band is of a different size but very close to the same size so I presume there is some type of compression being used. The first few bytes of each band appear to be a CLUT (Color LookUp Table) of some type; 161 bytes for 320x240 and 322 bytes for 640x480. The rest of the data is unknown except that the final byte of each frame is 0x90+the next band number. So the first band ends with 90, then the next with 91 etc etc. Not sure why.
It looks like the information within the Palm database is the same as what is sent over the wire with the exception of a few bytes at the beginning and end. That is very encouraging, and a time saver since I am able to now compare record data instead of having to capture it along the wire.
Each record seems to correspond with a different section of the serial data; there is a record of 2400 bytes that is the black/white version, and there is a 6K-8K record for each band of color information that goes along the wire.
I set the conduit to save as a BMP file, which it turns out is uncompressed, at least I believe so since each image is the identical file size and I don't recall BMP having any type of compression for 24bit. I then took this and converted it into a PPM file which is easier to read since it is in ASCII and simply RGB values. Plus I think BMP files are stored bottom to top or something retarded like that.
So now I can look at the original record data and compare it to the RGB values in the PPM file. Unfortunately I can't tell squat from that.. and I am hoping that it is in a similar format to other Kodak products but I'm having a hard time finding decent docs of those as well. Like maybe the KDC format.
This is a 320x240 image.
Here is from the PPM file (RGB values):
243 235 211 243 235 211 241 234 206 244 241 212 248 245 214 247 246 216 243 245 219 243 247 223 246 247 229 247 247 225 245 247 222 246 248 216 239 243 206 237 243 190 229 244 171 208 231 143 188 217 112 165 200 96 136 178 73 133 181 59 145 201 62 138 200 71 148 196 75 149 179 88 158 165 105 190 174 122 199 182 137 201 184 132 175 165 105 150 149 104
And here is from the ArchImage.pdb (the first picture record):
0000: c3 c8 c2 c5 c9 cb c3 a4 68 37 24 21 23 3c 5b 3d 0010: 21 1b 1b 1c 1f 2e 3b 5a 6d 79 8c 9b 94 88 88 97 0020: a6 a6 a1 9d 75 41 39 50 95 af 7c 3d 3d 44 49 48 0030: 4b 58 79 d1 cf cf d2 cd d0 ce cb ca ce cd ce d3 0040: cf d0 cd ce ce cd d4 d2 ca ca ce cb d4 d7 cc d4 0050: d0 c9 cf ca cd ca cc cf cc d1 ca cf ce c9 cf cf 0060: ce c9 ca ce c8 cc cb d0 d0 d0 d6 cb cd c9 c0 c3 0070: ca c7 c4 ca d0 ca c6 ba bf c0 c4 c2 c7 c6 ca ce 0080: b0 a6 aa b0 b4 b9 bc c2 c3 c0 a2 9d a2 a3 a4 ac 0090: ad b2 b6 bc b1 92 8e 93 96 98 9d 9f a2 a4 a6 97 00a0: c2 8b c2 de ff 7f 7d ff 7f b7 ef 48 a2 dd ef 9b 00b0: 22 73 a8 b1 67 22 17 ef d2 c9 b4 b0 1f ee b0 f3 00c0: c3 4e d1 34 02 69 97 28 e7 c9 2b 81 f0 08 d0 ce 00d0: b9 c0 34 81 02 b4 01 64 e5 69 21 21 ca 90 84 84 00e0: e5 68 00 12 bb 8c 84 2e fb fd fd d2 7d 12 16 41 00f0: 9c 3b 39 66 dc e7 38 9c 87 bf 7e 9c 9d 04 c3 fe 0100: ad 26 9a 51 92 eb 86 9a 2f 55 6a 79 d0 13 01 28 0110: 54 49 54 c3 94 09 e4 56 d8 81 33 4e 80 93 4e 21 0120: 34 d0 0a 6c 10 09 2b 0d b6 1a 1a b2 c9 54 ef 9d 0130: 0e 73 ee 56 41 e5 12 22 cb 17 7d 64 e0 1d 67 f9 0140: 67 c2 a9 f3 6a 35 18 d3 e6 93 33 54 42 1e 15 79
Notice that the first 161 bytes is "different" just like in the serial data. So I presume the actual color information starts at 00a1 but how the heck that string of crap represents the PPM data I have no idea.
Perhaps sometime in the future we will run into someone bright enough to decode the picture information. At that time we could actually make the device useful. It can be plugged into other devices, or even used from your PC. I have used The Bridge to hook it up to several devices, but without knowing the picture encoding we cannot develop the software fully.
Here is how I have wired up The Bridge so that I can plug it into different devices. First of all make sure that your bridge doesn't have faulty etching and test the continuity between the pads. They had a problem with the pads not being fully etched, if there is continuity just use an exacto knife and cut away the junk between the pads.
I chose to wire a small 3" cable and a female DB9 to the terminals. I used 6 wires though not all are used by the PalmPix. The end result is that I can use it either as a bridge or as a palm to DB9 cable. My DB9 is wired DCE so that it appears as a modem would to a computer.
The PalmPilot connector has 10 pins; looking at the bottom from right to left:
1 - DTR (+3V to +6V non-standard) 2 - +3.3V 3 - RXD 4 - RTS 5 - TXD 6 - CTS 7 - GPI1 8 - GPI0 9 - NC 10 - GND
A DCE-wired DB9 is:
1 - DCD 2 - TXD 3 - RXD 4 - DSR 5 - GND 6 - DTR 7 - CTS 8 - RTS 9 - RI
Therefore I wired my DB9 to the bridge terminals as follows. With the bridge upside down and the circuit board pads (long pads not soldered terminals) closest to you it will be numbered right to left.
Terminal DB9 1 DTR 4 DSR 3 RXD 2 TXD 4 RTS 7 CTS 5 TXD 3 RXD 6 CTS 8 RTS 10 GND 5 GND
To test it you can just slide the bridge onto a palm modem (if you have one laying around) and plug directly onto PC serial port with the DB9. You should be able to operate it normally. To use POSE there is a setting where you specify which serial port to use.