wasic3gpio watching is at: http://hands.com/~~lkcl/hp6915/phone.research.txt
from this, we can definitely deduce that BTUART is used as the serial port to communicate with the GSM module.
oh _great_. this is a gnuharet wi trace of the BTUART data, decoded: http://hands.com/~~lkcl/hp6915/btuart.trace.decoded.txt and it shows some ridiculous binary data, indicating that there's multiplexing going on. greaat. i am very reassured.
enabling GSM AT command logging in wince with phm regedit, which you can use to set SOFTWARE\OEM\ATDbgLog.
13nov2006: oh, arse: as i suspected, BTUART data is sent in between the GPIO signals. ok, other than that little pain in the arse, here's some raw data from a wi trace, off the btuart:
actually, two wi traces were actually carried out: one which captured btuart IRQs and GPIOs, and another which captured btuart irqs and btuart send/receive data. here's the second one:
it can clearly be seen that there is an initialisation sequence. also it can be seen that there is a 0x02 'command', followed by a 2-byte LSB length field, in the request.
also it can clearly be seen, in the response, that there is a 0x81 'command'.
so, so far, it looks like this:
<0x02> <2-byte length, LSB first> <command-byte> <0x00> <2-byte crc checksum>
<command-byte>s seen so far include 0x00, 0x81 and 0x82.
at least two 0x82 responses has been seen, unsolicited: 80 cc cb was the first, and 2b 43 47 52 45 47 3a 20 34 0d a8 70 which is "+CGREG: 4" in ascii, was the second.
the crc is a 16-bit crc checksum, running from <command-byte> through to the end of the data, and the initial lead-in crc value is 0xffff. i found some random c-code with a crc16 algorithm in it, that is 'Derived from CRC algorithm for JTAG ICE mkII, published in Atmel Appnote AVR067' - i've dumped the whole lot at:
you compile it with gcc serial.c and run ./a.out (of _course_ you use linux)
crc16.c comes from: http://www.koders.com/c/fid6BB47D55FAE4B2158CDF7F923C8CACD953525F04.aspx