I’m trying to code an application to extract the temperature measurement from Destron Fearing Lifechip with Bio-Thermo - sold by Dangerous Things as the xBT. I can tell at least part of it is in the 24 application bits in the 128-bit FDX-B telegram. I also have a strong hunch that the value is encoded in the 9 last bits, little-endian.
But I’m not sure for several reasons:
With all the readings I’ve taken with my PM3, compared with readings from my Halo Scanner, many times the value in the 24 application bits hadn’t changed while the temperature reported by the Halo Scanner had. I figured maybe the chip returned 2 telegrams in sequence, one for “regular” FDX-B readers with the MSB of the temperature value, the other (not picked up by normal readers, but picked up by Bio-Thermo-aware readers) with the LSB. So I modified the PM3 client to decode another possible telegram right after the first one, and there does seem to be some biphase-encoded data there. But it doesn’t seem to be ISO 11784 and I can’t make heads or tails of it. But I’m thinking maybe I’m just looking at noise.
Or the telegram is not strictly ISO 11784 and has been made slightly longer to pass extra bits after the end of the standard telegram length of 128 bits. Again, I changed the PM3 client to grab 136 bits (in case the application bits had been made 32 bits instead of 24) and I do get a value after the end of the telegram, but the value seems to be fixed. Or maybe it’s just noise again.
Or the missing data is encoded in the 3 parity bits.
Or I’m wrong and the value is entirely contained in the regular FDX-B 24 application bits (or part of em) and I can’t figure out how it’s encoded for the life of me.
Destron Fearing, unsurprisingly, won’t answer my technical questions. Anybody know exactly how the temperature value is returned by that chip?
Okay you guys, I’ve cracked it. It took me all evening with the Proxmark3, and dumping all possible temperature readings from my Halo reader and my SureSense reader, but I got it all figured out. Here goes:
The temperature is encoded strictly in the 24 application bits in the FDX-B telegram, but the chip doesn’t set the “extra application bits” bit. I’m not sure why. Possibly to fool dumb readers into accepting the telegram as a valid ordinary FDX-B telegram.
The temperature is encoded as follows:
The last byte encodes the temperature as 74 + (0.2 * byte_value) in Fahrenheit. So 0x00 encodes 74F, 0x01 encodes 74.2F, 0x02 encodes 74.2F…
The least significant bit of the middle byte is the parity of the temperature byte: so for instance, for temperature byte value 0x7b, it should be 1. For temperature byte value 0x7c, it should be 0.
All the other bits encode nothing, but should be zero. The SureSense reader doesn’t care if the other bits are set, but the Halo reader rejects the temperature value if any of them is.
So in short, the 24 application bits look like this:
00000000 0000000P TTTTTTTT
A couple of notes about the Halo and SureSense readers:
There’s some weird math going on in them. Almost all of their values are off by ±0.1F, and some are off by ±0.2F, or even ±0.3F in the SureSense. But the most precise values are found in “normal” temperature ranges. The most “off” temperatures are found in temperature ranges that are impossible for a living mamal. On average however, they follow almost exactly the equation above. I have no idea what they’re doing internally, instead of simply offering a simple linear progression. More strangely, they don’t do the same bizarre math. I have a feeling whoever coded the firmware in each of them also reverse-engineered the Destron Fearing format, but they’re doing the temperature conversion with an empirical table or something
The Halo reader ignores the parity bit. The SureSense reader doesn’t however.
The Halo reader ranges from 74.6F to well over 112F (I stopped at 112F because I got tired of extracting values that are of no practical interest). The SureSense reader only reports values from 91.3F to 109.5F, but does display a * sign below 91.3F (probably to tell you you’re dead) and a sign above 109.5F (probably to tell you you need a cool beer quite soon).
Above 99.9F, the Halo reader displays 10.xF instead of 10x.xF So if you run a temperature above 100F, you won’t get the decimal. Annoying - especially when you try to reverse-engineer the temperature scale.
There ya go. Now you know how the Destron Fearing Lifechip Bio-Thermo reports the implant temperature. I’ll be submitting a patch to the Proxmark folks to include temperature readings in the LF FDX section.
The code is trivially easy. It’s just the process of figuring it out from existing products and double-checking over the entire temperature range that was a real drudgery.
Oh well, at least now I can buy a suitable reader and get going on my application. I think I found a doozie of a reader - bluetooth, battery powered and water-proof - and the manufacturer has already confirmed I’ll have access to the 24 application bits for my purpose. More on this later.
Good timing! I just figured it all out about an hour ago. I had set this aside while traveling and just picked it up again.
I am using a bare RFID board. You need an RS232-to-USB converter to read and power it and a serial terminal program on your computer.
What was confusing me is that the 4-bit nibbles and parity are reversed. So 0006C10000 becomes 0xC6 with parity 1. That can then be converted to temperature using your formula. With the chip in warm water, over time, the values fall in a monotonic and orderly way. So it seems like everything is working.
Thanks so much for your work on this. I would not have figured things out otherwise.
Yeah I thought the 24 application bits were in reverse order at the end.
What weirds me out is the extra zeros between the UID and the application bits.
Are you using the Priority 1 Design board? I know it returns the datagram raw or semi-cooked. But I’ve never used one and I’m not sure what format it returns exactly.
If you have a LF field detector, could you try checking if the board keeps the field on all the time as long as it’s powered, or if it turns it on only when you send it a read command (if there is a read command) or if drops the field when the RS232 voltages aren’t present or something?
I’m on the market for a high-power EM/FDX reader that would let me control the field somehow. The ones I use radiate through me all day long and I’d rather they didn’t.
Oh another thing: do you know if it reads EM tags also, or just FDX? I know the eBay seller only mentions FDX, but very often FDX readers do both, because there are EM animal tags out there (EM4305 for pigeons)
Ah don’t worry about it. I’ll just get em and I’ll see for myself. I thought maybe you had an EM tag lying around. Even if it only does FDX, I have a use case for such a device (actually a product I’m developing).
sign above 109.5F (probably to tell you you need a cool beer quite soon).