On Sun, Oct 09, 2005 at 06:31:13PM +0100, Chris Ridd wrote: > The protocol seems to revolve around ASCII control characters 0x02 - 0x06. That's pretty common.
> An 0x02 means a string follows, terminated by 0x03 and 4 more characters > (perhaps a checksum). Usually some sort of XOR or CRC16/32/MD5 of the bytes between STX and ETX. > One problem is that quite frequently I fail to get back the required 0x06 > byte in the initial "handshake". If I don't, then I write the 0x05 and try > and read again. I can get 6 failures in a row before the meter decides to > respond correctly. That doesn't feel right, so I guess I'm missing some > earlier setting. Seems like you want to play around with flow control settings on the serial link. Try XON/XOFF software flow control instead of RTS/CTS. Also try DTR/DSR if XON/XOFF fails. My bet is XON/XOFF, though, as that would allow to scrape off a few cents off the chip/cable cost as it does not require hardware flow control logic and allows to use 3-wire cables. > Once those failures are out of the way, the message/response and subsequent > messages/responses all work fine. Since XON/XOFF is software only (eg the payload bytestream is interpreted for flow control) things work as long as sender/receiver are in sync. Which is likely to happen for short messages once initial sync has been established. > I've been replaying commands sniffed from Precision Link, so they have > included whatever checksums Precision Link calculated. It might be worth > trying to figure out the checksum algorithm. At the very least we could > check that the meter's sending valid stuff. And one should. The meter is likely to offer a command to free it's memory. For which we would want to know the integrity of what we read from the meter. > "Long" strings contain 0x17 followed by 4 checksum characters which the > other end needs to ACK with an 0x06. 0x17 or 17 ? 17 is XON which might indicate the XON/XOFF protocol. Also watch out for 0x15 (21, NAK) which might indicate comm failure of some sort. For an example driver for a medical device take a look here: http://savannah.gnu.org/cgi-bin/viewcvs/gnumed/gnumed/gnumed/device-drivers/ I'd be quite happy to host any Python code you develop for the Glucose meter in the GNUmed CVS if you so wish. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ------------------------ Yahoo! Groups Sponsor --------------------~--> Most low income households are not online. Help bridge the digital divide today! http://us.click.yahoo.com/cd_AJB/QnQLAA/TtwFAA/W4wwlB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/openhealth/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
