tag:blogger.com,1999:blog-2090121141266718432.post8990560308554510152..comments2023-05-29T08:02:26.948-07:00Comments on CGMS Watch: Matching up Meter Records to Packet SnifferUnknownnoreply@blogger.comBlogger7125tag:blogger.com,1999:blog-2090121141266718432.post-65340991155856408402014-05-05T16:39:56.554-07:002014-05-05T16:39:56.554-07:00ignore that about transmitter ID. it's coded ...ignore that about transmitter ID. it's coded from the packet SimplicIT source address, split into 5-bit values and looked up in a table. So the SimplicIT source address is the transmitter ID, so we don't need to look for it anywhere else (such as a checksum)AdChttps://www.blogger.com/profile/01051761007137529243noreply@blogger.comtag:blogger.com,1999:blog-2090121141266718432.post-57405843974009293122014-05-04T02:53:00.145-07:002014-05-04T02:53:00.145-07:00I got 2 CC2511EMK devices, so I started capturing ...I got 2 CC2511EMK devices, so I started capturing on 2 frequencies. So now we can say that the payload is plaintext (which we knew). We can also say that the TxId is not used in any computation (e.g. of checksum). The payload (all 7 bytes) is identical on the 2 frequencies I captured. So it really looks like the transmitter only affects the 7 byte payload, and so we're looking in that 7 bytes for the way to lock a reading to a transmitter ID. I'm guessing since the transmitter ID is 5 bytes, and we have about 5 bytes of significant payload, we could XOR the transmitter ID with the 5 bytes of payload, and then calc the normal dexcom checksum code over it.<br /><br />Since the packet sniffer seems to give everything in bit-reversed order, we'd need to reverse first.AdChttps://www.blogger.com/profile/01051761007137529243noreply@blogger.comtag:blogger.com,1999:blog-2090121141266718432.post-33609297813454930482014-05-03T14:57:24.956-07:002014-05-03T14:57:24.956-07:00United States Patent 8231531 http://pdf.sumobrain....United States Patent 8231531 http://pdf.sumobrain.com/US8231531B2.pdf?AWSAccessKeyId=AKIAIBOKHYOLP4MBMRGQ&Expires=1399250086&Signature=b7vJ4mUT8eMUIlRXjksmmi2Wnh4=#view=FitHLorihttps://www.blogger.com/profile/06665487190552759437noreply@blogger.comtag:blogger.com,1999:blog-2090121141266718432.post-41067215001643159092014-05-02T14:14:55.343-07:002014-05-02T14:14:55.343-07:00Just looking at my receiver sensor data, the secon...Just looking at my receiver sensor data, the second long value have even much better (R near 1) correlation to EGV value (when looking at data within two "calibrations")Lorihttps://www.blogger.com/profile/06665487190552759437noreply@blogger.comtag:blogger.com,1999:blog-2090121141266718432.post-56751781373998764842014-04-30T14:54:45.365-07:002014-04-30T14:54:45.365-07:00sorry about layout - couldn't figure out how t...sorry about layout - couldn't figure out how to put it into pre mode.<br /><br />Also, it could be interesting to try correlating BGL to difference in these 2 numbers. the reason being is that the dexcom sensor has 2 electrodes that give a reading. There's the main one for the enzyme reaction, and there's another reference silver electrode which is meant to be used to cancel noise. If these 2 readings were the 2 electrode readings, then we could be meant to subtract the 2 to get the raw result. So this may correlate to BGL.AdChttps://www.blogger.com/profile/01051761007137529243noreply@blogger.comtag:blogger.com,1999:blog-2090121141266718432.post-63193855697350884382014-04-30T14:47:22.631-07:002014-04-30T14:47:22.631-07:00Hi Don. I've been looking into this more. If...Hi Don. I've been looking into this more. If you look at the record from the machine, there are 2 numbers stored in 4 bytes each and a short. The 2 numbers I think are transported as only 13 bits each. in each case you get 3 bits flag followed by 13 bits reading then another 3 flag fields and another 13 bit reading.<br /><br />CC 59 35 9E => 11001100010110010011010110011110<br /><br /><br /> 1A33 => 1101000110011<br />reversed => 011 1100110101100 100 1101000110011<br /> 19ac => 1100110101100<br /><br />I've repeated this with a number of readings, and it's reliable. Also it doesn't work if you consider the data to be 14 bits.<br /><br />As for what the 2 number are / mean. They are generally pretty close (within 5000 which is about 5 points). I wonder if the way it works is sending high and low bounds on the reading, and if you used the average to correlate to BGL reading you might get a better result.AdChttps://www.blogger.com/profile/01051761007137529243noreply@blogger.comtag:blogger.com,1999:blog-2090121141266718432.post-6942415816239832112014-04-24T16:02:57.591-07:002014-04-24T16:02:57.591-07:00Nice!Nice!Lorihttps://www.blogger.com/profile/06665487190552759437noreply@blogger.com