Hi. Yeah, good idea with putting it in the fridge to force battery voltage down. I guess you could also heat it.
I think it's more likely that reading would be battery than say temp, although of all the packets I've seen captured, they all seem to be about D8, so maybe it's temp? I wonder if there's a temp-based correction, since the enzyme reaction is very temp-sensitive, but you'd think the human body would be doing an awesome job at temp regulation, esp sub-dermal.
very interesting also about the use of the different port. The port field in SimplicIT seems to be like a TCP port.
from nwk.h file (in SimplicIT DK from TI) (can see in GitHub at https://github.com/andrewgodwin/OpenChronos/blob/master/simpliciti/Components/nwk/nwk.h)
/* well known ports*/
#define SMPL_PORT_PING 0x01
#define SMPL_PORT_LINK 0x02
#define SMPL_PORT_JOIN 0x03
#define SMPL_PORT_SECURITY 0x04
#define SMPL_PORT_FREQ 0x05
#define SMPL_PORT_MGMT 0x06
#define SMPL_PORT_NWK_BCAST 0x1F
#define SMPL_PORT_USER_BCAST 0x3F
It looks like that may be a request to move frequency, since from nwk_freq.h
#define FREQ_REQ_MOVE 0x01
Some heating
64ETH 40 00 00 00 D8 00 0E
64ETH A0 00 00 00 D8 00 C0
64ETH 40 00 80 00 D9 00 26
64ETH 80 00 80 00 D8 00 88
64ETH 00 00 80 00 D8 00 F2
64ETH 00 00 00 00 D8 00 33
Hi all, Hjoke, those Frequencies work in the US also, I tried out your code yesterday. I'd really like to see the source, I need that to communicate with my rfduino without the USB involvement. As to interpreting the data, you need to create a standard curve with a range of values, then you can use y=mx+b to extrapolate your current glucose from the raw counts which is what you're seeing. The 12 hour calibrations allow the software to "shift" the curve to account for decreasing counts over time, as the sensor ages.
Hi DonB, I have attached some files.
7368-something.zip (10.2 KB)Hi hjoke. There are a couple of checksum algorithms built into the CC2511 that are able to be used by applications running in them. TI have details on them. I tried to do some matching but didn't get anywhere with them either (and they generate a 16 bit crc).
We just changed my son's sensor, so I collected some readings immediately (well a couple minutes) after disconnection.
90 99 96 D9 D8 00 E5
D0 00 C9 29 D8 00 8E
D0 00 9E AE D8 00 92
50 00 25 58 D8 00 6F
D0 00 00 00 D8 00 A7
50 00 00 00 D8 00 DD
these are consecutive readings. It looks like the numbers wind down and take a while to get to zero after disconnection. This makes me think maybe there is some averaging window being applied to the data.
Hi Adrien, I believe the checksum routine is the most secret in these messages because it is the only way to check if the message is real.
The transmitter also has more than one reed switch because it started to send different messages when I have removed it from package and then put it back. There is some averaging because it needs several samples to change the state.
I have still also some problems with the upper bits. If we combine bytes 13 and 15 as below:
K = (B13 & 15) * 16 + (B15 & 15) we can get some values like:
DE 9E D9 99 EE EA 9A FD FB DB DD BD
We could make some table for at get these upper bits.
IF (K = 234) OR (K = 238) THEN D = 1
IF (K = 153) OR (K = 154) OR (K = 158) OR (K = 219) THEN D = 2
IF (K = 217) OR (K = 221) OR (K = 222) THEN D = 3
IF (K = 251) OR (K = 253) THEN D = 0
IF (K = 219) OR (K = 221) THEN D = ?
IF (K = 189) THEN D = 3
Value is 256 * D + byte as earlier
There are some possibilities but some are still missing. Do you have better info?
I am now working with the software for my insulin pump and next monday I should go to eye surgery.
Hi hjoke
I think you might have more luck following the route that Don took, where he matches the bits in the received packets with the records stored in the dexcom receiver in table 3 (radio data). See http://dexwatch.blogspot.co.nz/2014/04/matching-up-meter-records-to-packet.html
regards
Adrien
Hi Adrien, thanks for info but I can't get from it much sense. I have my logs over 2000 messages and when I try 14 or 13 bits then there is something that looks nice but there are still big problems with the msbs. I can get values from 1000h to 1ffff or 3fffh but only 8 lsbs could be right. I have tried both pairs (1,2 and 3,4).
Hi hjoke, do you have code to poll the data from the dexcom receiver?
Once you have the data that's stored in the receiver, it's the decoded packets, so you can match them to the received packets from your pololu.
I wonder if the msbs are flags for some other meaning. What dev environment are you using? I could send you some msdev 2010 code if you like.
Adrien
p.s. I don't know if the checksum is really that interesting.
the FCS done by the hardware tells you if the packet is corrupted. If it's not corrupted, and it's from your transmitter, and the correct port etc, then do you really need to verify the checksum as well? the data seems to be plaintext. Possibly can just ignore the checksum.
I'm more interested in the meaning off all the other bits that don't seem to match the records in the receiver.
in the receiver, data is organised in tables. There's a table (3) that stores decoded radio packets, and table 4 contains the calibrated BGL:direction records.
The decoded radio packets contain 2 DWORDS and a SHORT (all records of all types start with 2 dates - internal and display date so this is after that).
The 2 DWORDS are normally very close together. We thought it might be signal and noise values, but if you subtract, the result doesn't correlate to BGL. However the average of the 2 (or either one) does correlate well to the BGL. It's a bit of a slight curve. I think the calibration readings alter the calibration curve.
Hi Adrien,
Below are some messages. The 8th number is my result.
The next are 14 bits in reverse order from 2 bytes.
The 9th is 14 bits from bytes 1 and 2 in hexadecimal.
The 10th is 14 bits from bytes 3 and 4 in hexadecimal.
The 11th is 9th in decimal.
The 12th is 10th in decimal.
B2 4D EF 09 D8 00 F7 800 324D 10F7 12877 4343
B0 CD C4 49 D8 00 A3 818 330D 1223 13069 4643
DB CD 37 49 D8 00 49 818 33DB 12EC 13275 4844
79 2D 41 C9 D8 00 DF 835 349E 1382 13470 4994
D1 4D 4B C9 D8 00 24 803 328B 13D2 12939 5074
1F 0D 04 49 D8 00 24 770 30F8 1220 12536 4640
16 0D 3A 89 D8 00 DC 769 3068 115C 12392 4444
6D F9 CD 09 D8 00 33 752 1FB6 10B3 8118 4275
7D 79 F8 09 D8 00 6F 736 1EBE 101F 7870 4127
28 79 02 FE D8 00 61 751 1E14 3F40 7700 16192
86 B9 16 7E D8 00 B5 734 1D61 3E68 7521 15976
CD 39 F5 BE D8 00 B6 717 1CB3 3DAF 7347 15791
BD D9 00 BE D8 00 E0 701 1BBD 3D00 7101 15616
DB 59 02 3E D8 00 21 684 1ADB 3C40 6875 15424
37 19 F6 5E D8 00 43 650 18EC 3A6F 6380 14959
E7 E9 8E 9E D9 00 2F 633 17E7 3971 6119 14705
31 E9 C1 1E D8 00 FE 632 178C 3883 6028 14467
88 19 DB EE D8 00 34 647 1811 37DB 6161 14299
1E 99 93 EE D8 00 AC 663 1978 37C9 6520 14281
51 D9 71 1E D8 00 55 696 1B8A 388E 7050 14478
EC B9 D8 5E D8 00 7A 730 1D37 3A1B 7479 14875
21 79 10 3E D8 00 C4 748 1E84 3C08 7812 15368
BB F9 BB BE D8 00 3A 765 1FDD 3DDD 8157 15837
AA 0D 32 FE D8 00 92 783 3055 3F4C 12373 16204
27 0D 19 09 D8 00 03 768 30E4 1098 12516 4248
30 8D 87 09 D8 00 3A 784 310C 10E1 12556 4321
1F 0D E0 89 D8 00 48 769 30F8 1107 12536 4359
6D 0D 20 89 D8 00 B1 769 30B6 1104 12470 4356
CA 0D DB 09 D8 00 6B 768 3053 10DB 12371 4315
77 B9 B0 09 D8 00 CA 720 1DEE 100D 7662 4109
79 39 2B 7E D8 00 61 718 1C9E 3ED4 7326 16084
52 D9 66 BE D8 00 87 701 1B4A 3D66 6986 15718
82 99 63 5E D8 00 EA 666 1941 3AC6 6465 15046
44 E9 6D 1E D8 00 2E 632 1722 38B6 5922 14518
FC 69 9D EE D8 00 45 615 163F 37B9 5695 14265
DA A9 BD 6E D8 00 05 598 155B 36BD 5467 14013
8E 29 33 AE D8 00 B7 581 1471 35CC 5233 13772
95 C9 97 2E D8 00 AE 564 13A9 34E9 5033 13545
75 49 7A CE D8 00 47 547 12AE 335E 4782 13150
B2 49 F3 4E D8 00 01 546 124D 32CF 4685 13007
E8 49 B6 4E D8 00 71 546 1217 326D 4631 12909
Thanks, this is awesome. By Checksum/CRC all I want is to throw out packets that were interfered with. I don't believe that was working in the above code. If you use the CRC check from the sniffer example:
putchar((pkt[len + 2] & 0x80) ? '+' : '-');
and I also think radio_registers.c change PKTCTRL0 = 0x05;
Now when there's a bad Byte, it gets flagged.
Ex.
12 FF FF FF FF CA 58 61 00 3F 03 C6 1E 8D 20 49 D8 00 3C +
12 FF FF FF FF CA 58 61 00 3F 03 C7 1E 8D 20 49 D8 00 3C +
12 FF FF FF FF CA 58 61 00 3F 03 C8 1E 8D 20 49 D8 00 3C +
12 FF FF FF FF CA 58 61 00 3F 03 C9 1E 8F 20 49 D8 00 3C - Bad packet
As soon as you get a packet with a good CRC, you're done, no need to read the others and compare etc.
Also, memset all those packets each iteration,
Ex.
memset(&packet0, 0, sizeof(packet0));
Thanks
I've also been reading the TI application notes. There are some really good ones that would help to design a system to maximise battery life. E.g.
a) by putting the system to sleep as long as possible
b) choice of power supply (may need to use SMPS / DC-DC converter instead of linear regulator)
c) minimising amount of time the receiver is in RX state.
So if you get a good packet, you should turn off the receiver. If it's bad, then swap to next frequency etc until you do get a good one.
Hi DonB, I am sorry but there is not CRC in use. I am sure about that. First when I tried to receive packets, my first result is got using continuous receive mode and I have triggered memory scope and captured the data to the screen. I have got the trigger signal by using an antenna with rf-detector near the transmitter. Later I have tried to send same looking message and I was lucky only when it was sent without CRC. Then the message length was very same in both cases. They don't need the CRC because they are using their secret checksum method.
hi hjoke
when we use the TI CC2511 EMK USB dongle and the SmartRF PAcket Sniffer to capture from the dexcom transmitter, it has a FCS field which it marks as OK or ERR depending on the radio frame checksum.
So from our tests with that environment, it looks like there is a FCS checksum in use by the transmitter.
Regards
Adrien
Hi Adrien, here are few logs that I have self decoded from scope screen when I have used continuous receive mode:
AA AA D3 91 D3 91 12 FF FF FF FF B0 CD 61 00 3F 03 E1 85 8D DE 49 D8 00 33 DD 33
AA AA D3 91 D3 91 12 FF FF FF FF B0 CD 61 00 3F 03 F0 E7 F9 66 09 D8 00 7C EB 8A
AA AA D3 91 D3 91 12 FF FF FF FF B0 CD 61 00 3F 03 3F 3B 59 D2 3E D8 00 0A F6 C6
I tried to find the CRC from last 2 bytes but I didn't. The last byte came out from demodulator after the end of rf transmission. Rf transmission ended a little before the end of the 2nd last byte. When I have not found any CRC then I have supposed the last byte is only from noise because the shapes were not full synchronized. But the 2nd last can be real. However there is inbuild CRC16 calculation and we have only one byte. It can be some kind of checksum.
Hi, that's very interesting. From the TI documentation on simplicIT, it has a preamble, then synch word, then packet (to addr, from addr, etc), then 2 byte CRC.
I wonder if one of the bytes we're seeing in payload is actually the first byte of the radio CRC, and we should be ignoring it? E.g. maybe really only a 6 byte payload? The TI application notes go into detail on the checksum in various notes:
http://www.ti.com/lit/an/swra313/swra313.pdf
http://www.ti.com/lit/an/swra113a/swra113a.pdf
Regards
Adrien
p.s. when you check the FCS, you need to use the TI checksum algo, and only start from after the synch word.
Adrien