by Marcus Gröber 2001, http://www.mgroeber.de

• 115.200 baud, 8N1
• The adapter provided by Casio seems to be fixed to these parameters, so it doesn’t require any special initialization, like some of the other IR "pods". The adapter appears to be compatible to the Extended Systems "JetEye" products – at least I have always been able to use JetEye drivers for it in all applications so far.

A frame is structured in a way that is very similar to the IrLAP format, although the protocol is somewhat simplified (thanks to Daniel Plakosh for pointing this out). A good description of IrLAP frames can be found on Microsoft’s web site in the DDK for Win2k. (I’m omitting the actual reference because deep links into MSDN typically have a very short half life...)

The following table describes the various components of such a frame:

• The contents of the frame between BOF and EOF are escaped to avoid confusing data bytes with BOF/EOF symbols: any byte that is either BOF, EOF, or 7Dh will be replaced by the combination (7Dh), (byte XOR 20h).
• On the WQV-1, the checksum is always a 16-bit sum of all the preceding bytes, exclusing the BOF code itself. The checksum is computed before escaping the original contents for transfer.

The following exchange always takes place when a new connection between the PC and the watch is started. Note that the PC always initiates the connection by sending data to the watch (direction ">").

It is interesting to note (though not essential for the protocol) that the <hh>:<mm>:<ss>:<ff> sequence sent by the watch is the time-of-day at the time the request was received, represented as hours, minutes, seconds, and 1/256^th of a second.

After this prelude, the actual data is "pumped" from the watch to the PC. This happens by repeating the following exchange as often as necessary for getting all the images:

Here, <get> and <ret> are cycled through a list of values to implement some kind of simple packet numbering:

• <get>: 31h, 51h, 71h, 91h, B1h, D1h, F1h, 11h, 31h, 51h, ...
• <ret>: 42h, 44h, 46h, 48h, 4Ah, 4Ch, 4Eh, 40h, 42h, 44h, ...

The data stream consists of repetitions of the following structure for each image (note that the size of this structure is 1C3Dh bytes, which also occurs in the prelude as sent from the watch):

Finally, the exchange is terminated by this sequence:

After that, the image is downloaded just in the same way as for the multi-image download.

After this prelude, the actual data is sent from the PC in the same format as used by the upload. This happens by repeating the following exchange as often as necessary:

Again, <put> and <ack> are each cycled through a list of values:

• <put>: 32h, 34h, 36h, 38h, 3Ah, 3Ch, 3Eh, 30h, 32h, 34h, ...
• <ack>: 41h, 61h, 81h, A1h, C1h, E1h, 01h, 21h, 41h, 61h, ...

Finally, the exchange is terminated by this sequence: