Hi Adrien, when I tried to find the CRC then I have tried everything possible and also older CRC (CC2400) but not any results.
one other thing the mention is that FCS is in MSB (most significant bit first).
so it's possible you'd need to bit-reverse all bytes.
sorry I also missed packet length (the 0x12 = 18). That's included in the FEC calculation.
but like you say, I can find any match anywhere either, even when reversing bits, incorporating length, and it looks like the synch word is repeated, so I'm not sure if the second one is supposed to be counted in the CS as well.
most frustrating!
here's the overview doc... hard to find!
In receiver sensor data structure if
time stamp data 4 + 4 bytes
1st 4 bytes is sensor value as received
2nd 4 bytes is somehow processed value that has R near 1 correlation to BGL
3rd 1 byte is RSSI
4th 1 byte is something that varies 0,1,2
Hi, that's interesting about the RSSI.
I think though that the second 4 byte integer is from the sensor/transmitter as well. By matching transmitted data with these records we could match both DWORDs.
Did you try correlating the average of these 2 numbers?
p.s. I saw your blog. Since I'm a complete newbie at android, I'd be keen to see your code (I won't judge!).
Anyway I think the dexcom is doing quite a lot of data massaging, and making assumptions about how fast it is possible for BGL to actually change. I think this is required to cope with drop-outs in the signal from the sensor. I think one of the things that happens is body movements affect the coupling between the sensor and your ISF, and so the noise signal can be quite large. I think if noise gets too large for too long, that's when the receiver starts to show ???
I am newbie to Andriod too. It is not even a service thus not yet triggering alarm. Android tends to kill :( I hope I will publish it on Github. Chart is from AndriodPlot library.
Yes, receiver show ??? when noise is marked as Heavy(4) in EGV record. I don't know how noise part is calculated but raw sensor data looks still good (not that bad) as mentioned on blog. I think it is calculated by algorithm.
Little update: 2nd 4 bytes are from value sent by sensor too. As per 3 + 13 bit encoding scheme (by Adrien and Don).
Let's have 200192 (2nd 4 bytes) as a value from receiver then divide it by 32 we get 6256 which is what we get from sensor using 3+13 encoding scheme from 3F-19.
So far 2nd provides very good linear correlation on the data from last calibration.
I'm starting to think the 2 numbers are actually both BGL readings, but at separate times within the 5 minute interval.
the second number seems to correlate really well with the 1st number of the previous sample.
This would then allow a single transmission to allow the receiver to estimate slope.
also I think it must be 13 bits (not 14 or 12 or anything else) significant, since no other value matches the records in the receiver.
I also think there are scaling factors in play. there's 1 bit in each group of 3 bits if set you multiply the value by 2 and they correlate a lot better. I'll post some images showing it
raw data:
8C BD 3E B9 D8 00 C8 285 LEVEL
0D 3D E2 B9 D8 00 3D 280 LEVEL
2A 3D 1F 39 D7 00 16 275 LEVEL
E7 DD 49 39 D8 00 2C 270 LEVEL
8E DD 04 39 D8 00 C1 265 LEVEL
60 DD B5 D9 D8 00 1B 260 LEVEL
5D 5D 82 D9 D8 00 5E 257 LEVEL
BD 9D B3 59 D8 00 4D 246 45 DN
CF 1D DC 59 D8 00 F2 236 45 DN
D9 ED 76 99 D8 00 E2 221 DOWN
E5 6D 66 19 D8 00 A8 210 DOWN
78 6D F2 E9 D8 00 DA 204 DOWN
C1 AD 7A 69 D8 00 58 197 45 DN
C7 2D 35 A9 D8 00 2F 190 45 DN
E2 2D 24 A9 D8 00 4E 183 45 DN
AD CD F9 29 D8 00 25 176 45 DN
98 CD 30 29 D8 00 EC 169 45 DN
0E 4D 36 C9 D7 00 E0 161 45 DN
07 8D D3 49 D7 00 5D 155 45 DN
34 8D 94 49 D7 00 76 147 45 DN
E6 0D C1 89 D8 00 A6 138 45 DN
91 F9 6B 09 D7 00 09 131 45 DN
59 79 14 09 D8 00 F2 125 45 DN
EB B9 98 FE D7 00 68 121 45 DN
7F 39 F8 7E D8 00 06 116 45 DN
54 39 AA BE D7 00 31 111 LEVEL
D1 D9 79 3E D7 00 BF 108 LEVEL
5F 59 D7 DE D7 00 CC 104 LEVEL
4A 59 02 DE D7 00 4B 101 LEVEL
64 99 89 5E D7 00 13 94 LEVEL
FC 19 E3 9E D8 00 73 89 45 DN
FD E9 27 1E D7 00 69 86 LEVEL
B8 E9 90 1E D7 00 5E 82 LEVEL
E5 E9 AE EE D7 00 38 85 LEVEL
F3 19 16 EE D7 00 27 92 LEVEL
C8 59 FF EE D7 00 3E 99 LEVEL
7D D9 0C 9E D8 00 F9 109 45 UP
D9 B9 93 5E D7 00 73 120 45 UP
81 F9 A9 3E D7 00 8C 130 UP
9C 0D 3A 7E D8 00 E9 136 45 UP
3A 0D CB FE D7 00 5D 137 45 UP
C2 0D 1A 09 D8 00 16 136 LEVEL
B4 0D 8E 09 D7 00 DF 135 LEVEL
B4 0D 2A 09 D8 00 3C 135 LEVEL
DA F9 84 09 D7 00 AD 130 LEVEL
14 F9 4B FE D7 00 AD 128 LEVEL
7A F9 4E FE D7 00 0F 130 LEVEL
3E F9 9C FE D7 00 48 130 LEVEL
5C F9 EC FE D7 00 39 129 LEVEL
OK, I think I have it sorted out.
in the 4 bytes received from the radio, there are 2 x 16 bit floating point numbers.
the floating point is 3 bits exponent, and 13 bits mantissa. the exponent is biased in the middle of the range of 3 bits. So to convert the number, the equation is
number = mantissa * 2 ^ (exponent - 3)
When you do this with both numbers, you find that one value is consistently much smaller than the other (the second one). I believe this is the noise value from the reference electrode. If you subtract this value from the other value, the result correlates well with BGL assuming a slightly curved compensation / calibration function.
Hi Adrien, I have to check the floating number possibility but just one comment: There are 2 contacts and this means that there can be only one sensor. Few weeks ago I tried to test if it is only voltage meter but it isn't. The sensor has some voltage and it can maybe measure the impedance of the sensor. But there can't be any noise from reference electrode.
Hi hjoke.
the dexcom patents around the sensor go to great lengths to talk about several electrodes. They discuss a platinum central filament, a reference silver electrode, and an electrode to supply O2 for the enzyme reaction, since there's not enough free oxygen in the flesh to fully react the glucose otherwise and the sensor would saturate at a very low level. Plus enzyme layer and semi-permeable layer.
Like you, I don't know how one can create a circuit with only a single contact. Maybe there's some complicated waveform going in, or they drive it to generate O2, then read it afterwards to get electron count from enzyme reaction. It would be very interesting to pull a transmitter apart and analyse the circuit.
It's also possible the patent is not what is shipped.
Hi Adrien, but if we talk about a battery, it has also two electrodes and the voltage is measured between them. In Dexcom case the measuring process can be much more complicated.
I'm sure it is more complex.
From what I understand, in normal human flesh a healthy person has only 1% as many free oxygen molecules as glucose.
So, maybe what they do is this:
1. Assume if they aren't driving the circuit, then the enzyme activity is related to background O2 in the flesh, and that's small enough to ignore, and therefore if they read at this stage, they get a noise value.
2. Drive the O2 producing electrode for a timed period
3. Count the electrons on the circuit. This is the signal.
This gives 2 numbers with 1 circuit. If you hook your oscilloscope to the terminals on your transmitter with a resistor between, you should be able to capture voltage waveform. I'm not sure if my old trio scope still works. I haven't used it in 20 years.
Hi Adrien, I can check it but I should first connect wires to the sensor pins for at get some real results. However the highest priority is now in the software of my insulin pump. I would like to get it to work for at see how it works. When I want to get the signal, it needs some time because the level is probably measured every 5 minutes and I have to set the trigger levels rioght. If not then I have to wait again 5 minutes.
What I'm hoping is it might be possible to make another sensor circuit that can drive the sensor more frequently than 5 minutes. E.g. every 1 minute.
I think I will dust off my old scope and see if I can get a reading, also would be interesting to test impedance of the sensor. I think it's probably high impedance, in which case you could probably hook the scope probe direct to the transmitter without hooking up the sensor. It probably drives DC one direction to generate O2, and then gets a signal in the other polarity once it turns off the drive signal. I'm guessing it then waits 5 minutes because it needs to let the system settle down, it needs some window to count signal back, and it's trying to balance battery life etc. I believe it should be possible to create a new sensor that firstly is not using wireless to send to a transmitter, but is cabled into the box that does the calculation, then you could have a much lower profile CGM site.