The "raw" log file from Portmon
This is the image that "PhotoMAX" produced after this exchange:
Here, I'll be trying to keep track of developments as work continues on putting together a driver for gphoto2 for Polaroid's Xirlink-based digital cameras (the "Digital 320" and the "Fun! Flash 640SE", and perhaps others).
Nathan Stenzel has related site devoted to the Polaroid "Digital 320" (which seems to use essentially the same protocol) and the efforts to get it working for gphoto as well, which you may also find informative.
More news - 21-Feb-2001
Polaroid, it turns out, is exceptionally unhelpful about their products, at least,
the digital ones. (Note that the polaroid digital products that DO work with gphoto
apparently only do so because they use the same chipset as another manufacturer's camera,
which somebody managed to figure out the protocol for on his own...)
So far, all requests from people for information about the camera protocol (and, in my case, a request for information about information about the protocol [no, that's not a typo - I asked them about who I should contact about getting information about the protocol information and/or permission to see it]) seem to be getting curt dismissal from Polaroid, inc. If nobody can make any sense of the data transfer format for these cameras, someone may have to contact Xirlink directly...
Okay, enough self-pity from me for now. On with the known details and sample data.
A "cleaned" version of the log (Thanks to Scott Fritzinger for sending me the parse-portmon.pl script!)
The "raw" log file from Portmon
This is the image that "PhotoMAX" produced after this exchange:
> also, here is what i'm noticing about the picture transfer. (Sean, you
> might want to add this to the protocol specs).
>
> Here is the initial picture-download sequence:
>
> 0001 > E6
> 0001 > E6
> 0001 > E6
> 0001 > E6
> 0004 > 05 01 FA FE
> 0001 < 04
> 0004 < 00 00 00 02
> 0528 < FF C2 01 E0 02 80 F6 D8 0C 6A B3 47 29 50 B1 39 EA 7F E5
> 9B 80 E0 9F C5 98 0F A5 74 4F 92 CA 57 AB 28 3F 42 32 BF
> FB 21 3F FD 6A CA CF 0A 4F 62 41 CF 62 8D F2 8C 7F B8 63
> 38 EF 9F C2 BD BA 09 20 8D 25 59 59 02 C3 23 6E 2C 46 36
> 9F DE A1 C7 B2 B8 03 D4 83 E9 59 7A F3 D9 BE 93 72 D1 CC
> AB 88 5A 58 D9 65 65 56 68 4E 76 FF 00 75 89 1F 2E DE A4
> 64 0E D4 27 98 77 EF 03 61 56 5D D8 0C 41 21 B9 CE 3E 50
> 18 2E 1B 71 07 24 10 31 F3 35 89 52 8C 7F 85 E3 62 A4 1C
> 14 2D CF 1D F8 C1 E0 64 1E 4F 6A C7 F1 14 F6 27 47 9A 65
> 74 50 91 AC F1 38 DE 11 FC A6 CE CC AF CA C5 D4 63 6F 56
> 1F 85 79 B4 57 49 70 9E 7A CC D0 C7 68 0B 42 E9 3A E5 24
> 0D BD E5 8C
> 0002 < DA 85
> 0001 < 04
> 0004 < 00 01 00 03
> 0528 < 8F 17 E9 36 76 0D 7C D6 22 57 31 BE C9 D2 48 D8 A9 2A E0
> 40 59 81 25 25 CB 2F 94 AA AA A8 CE C2 3E 01 38 7A 5F C4
> [snip]
>
> E6's are written 1 at a time, command packet (0x05) is all in the same
> chunk. the response (0x04) is read in, then 4 bytes (the packet
> 'counter'/sequence bytes), then 528 bytes of data, then 2 bytes read in
> (checksum).
>
> notice how the 4 bytes after 0x04 are constantly increasing. it starts
> out at 00 00 00 02, then next one is 00 01 00 03, and so on. the second
> and fourth bytes are incremented by 1 with each packet (sequencing bytes).
>
(Note by Sean - I think the first two bytes are "packet number of this picture", while
the second two bytes are "total packets sent since the beginning of this 'session'" (e.g.
since initialization)
> after the last packet is received:
>
> 0001 > E6
> 0001 > E6
> 0001 > E6
> 0001 > E6
> 0004 > 0C 01 F3 FE
> 0001 < 07
> 0002 < 00 06
> 0006 < 00 54 81 2A 66 59
> 0002 < 1B 18
>
> "0C" appears to be requesting some info about picture #1. The response
> is 0x07, followed by 2 bytes (big-endian length of following data?),
> followed by 6 bytes of data, and then 2 byte checksum.