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.

Basic frame format

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:

BOF (C0h)

Address byte

Control byte

Data, if any

16-bit Checksum

(high byte first)

EOF (C1h)

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.

Initial connection setup

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 ">").

>

FFh

B3h

(possibly repeated)

<

FFh

A3h

<hh> <mm> <ss> <ff>

>

FFh

93h

<hh> <mm> <ss> <ff><assigned address>

<

<adr>

63h

(possibly repeated)

>

<adr>

11h

<

<adr>

01h

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/256th of a second.

Upload of all images from the watch

> <

(see "Initial connection setup")

>

<adr>

10h

01h

<

<adr>

21h

>

<adr>

11h

<

<adr>

20h

07h FAh 1Ch 3Dh 01h

>

<adr>

32h

06h

<

<adr>

41h

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:

>

<adr>

<get>

<

<adr>

<ret>

05h Data

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):