# How should I interpret this USB packet in a human readable way?

Using a wixel (wireless transmitter/receiver with USB capability, "this "wixel" thingy is a general-purpose microcontroller board that includes, among other things, USB, 2 UART's, and a 2.4GHz radio.") in conjunction with this wixel app to read in a transmission from a Dexcom glucose sensor/transmitter, for use in some software I'm writing. Here's the relevant pieces of C code:

void print_packet(Dexcom_packet* pPkt) {
uartEnable();
uartDisable();
}

uint32 dex_num_decoder(uint16 usShortFloat) {
uint16 XDATA usReversed = usShortFloat;
uint8 XDATA usExponent = 0;
uint32 XDATA usMantissa = 0;
bit_reverse_bytes((uint8*)&usReversed, 2);
usExponent = ((usReversed & 0xE000) >> 13);
usMantissa = (usReversed & 0x1FFF);
return usMantissa << usExponent;
}

void bit_reverse_bytes(uint8* buf, uint8 nLen) {
uint8 XDATA i = 0;
for(; i < nLen; i++) {
buf[i] = bit_reverse_byte(buf[i]);
}
}

uint8 bit_reverse_byte(uint8 in) {
uint8 XDATA bRet = 0;
if(in & 0x01)
bRet |= 0x80;
if(in & 0x02)
bRet |= 0x40;
if(in & 0x04)
bRet |= 0x20;
if(in & 0x08)
bRet |= 0x10;
if(in & 0x10)
bRet |= 0x08;
if(in & 0x20)
bRet |= 0x04;
if(in & 0x40)
bRet |= 0x02;
if(in & 0x80)
bRet |= 0x01;
return bRet;
}


My problem is that the readings I get are nonsensical. I'm using Labview to write up my software, so I employ a simple VISA read (listening for a packet) for an unknown number of bytes and a termination character \n. The rest of the Wixel app shows that it's using RTS/CTS hardware flow control, so I've set that up. My problem is that I'm expecting a long decimal (%lu), an unsigned short char (%hhu), and a decimal (%d), but when I read off the individual bytes received as these data types, my values come out weird.

For example, a reading of 98 on the real glucose meter was "117888 215 0\n" in my packet. I've ruled out endianness, as reading the backwards bytes as ASCII gives super strange unicode style characters. I just fail to see how the first number is in any way related to the second one. I honestly think I may just be interpreting the data type incorrectly, although I know that printf gives purely ASCII characters. The last weird thing is that the 215 almost always shows up somewhere in the packet, be it the first number, middle number, or last number. It's quite strange and leads me to believe I might be missing something.

Any help in interpreting this data would be appreciated.

• I don't think you've defined the format well enough. It sounds like you're looking for an ASCII string, but USB stuff is typically binary with a not-necessarily-trivial arrangement of bits to try and compress out any unused bits. – AaronD Jun 4 '15 at 19:29
• Oh wait, there's a UART in here? Is this actually a USB->UART converter that then connects to the sensor? Then I can understand using ASCII, but it adds another point to verify. – AaronD Jun 4 '15 at 19:32
• @AaronD I do believe there's a UART in there. Does that make this easier? – ijustlovemath Jun 4 '15 at 19:33
• Your code mentions one. At this point, it's still uncertain whether it's a physical pair of TX/RX lines that can be probed with a logic analyzer, or a virtual construct that's used to save a developer's time somewhere. It'd be really nice to see what's happening on the raw UART if possible. – AaronD Jun 4 '15 at 19:38
• I think you're not so much looking at a USB packet, but rather the payload. You can safely forget it is transmitted over USB as it could equally well be BT or RS-232. – jippie Jun 4 '15 at 19:42

Turns out, the raw value (which is what I was posting about) needs to be calibrated via a linear regression in order to convert it into the value I'm looking for. The inital regression is about glucose(raw)=1.0*(raw/1000) - 30, with additional sensor readings being used in a least squares fit to refine the coefficients. When in doubt, do some statistics! Thanks everyone who put forth the effort to help me out!