Did you work with that thing? You seem to have quite a bit of background on it.
In any case, it confirms my (strong) suspicion that it has no place in my body.
Damn, I which Destron Fearing redesigned the Bio Thermo with an NFC frontend: I read the patent for that chip and it’s really a great design.
I’ve been running my uFR Nano Online reader on one of the Brady tags all afternoon to roll over the counter, and at least now I know the temperature of the reader when it’s constantly blasting at full power: it’s running at close to 140 degrees now. Hot cookie 
Digital Logic readers never run cool, but this one really needs a heatsink for that sort of thing. Not that it’s typical usage though…
Well, surprisingly, it rolls over at 10,000. I didn’t expect that. In fact, it’s rolled over several times already. I just realized looking at the log.
Ah yeah I should have mentioned the smartsensor chip let’s yoy also put a small C program on there to control nfc output. They clearly made their own counter… bit why such a small rollover limit?
I guess it’s arbitrary. Those tags are sold as cold chain trackers. They’re supposed to be tacked onto temperature-sensitive goods and scanned a few times between manufacture and the point of sale. Possibly a few dozen times at the most if the tracking is exceptionnaly thorough. 10,000 is plenty good enough for that application.
I’m just surprised that a programmer has bothered changing the limit at all instead of letting whatever native variable roll over on its own, and also that it’s a decimal limit. Programmers typically think in powers of two when they code that sort of thing.
Anyway, the tag has performed over 160,000 reads now and it’s still going. At this point I think I’m stress-testing the uFR reader, because when I turn the TV off, it makes a funny chip-chip-chip-chip noise at each read now.
If anybody’s interested, here’s the code to read Brady tags:
#!/usr/bin/python3
"""Reads a Brady temperature sensing NFC tag repeatedly.
Requires either:
- A libnfc-compatible reader (e.g. ACR122U) and the nfcpy module
- A Digital Logic uFR series reader and the pyuFR class
(https://github.com/Giraut/pyuFR)
"""
### Parameters
use_ufr_device = True
ufr_device = "tcp://ufr:8881"
### Modules
import re
import sys
if use_ufr_device:
import pyufr
import ndef
else:
import nfc
from nfc.clf import RemoteTarget
### Main program
if __name__ == "__main__":
# Initialize the reader
if use_ufr_device:
ufr = pyufr.ufr()
ufr.open(ufr_device)
ufr.self_reset()
if not ufr.get_anti_collision_status()[0]:
ufr.enable_anti_collision()
else:
clf = nfc.ContactlessFrontend("usb")
target = None
# Read the tag until the user hits CTRL-C
while True:
uid = None
uri = None
# Get the Brady URI using a uFR reader
if use_ufr_device:
try:
ufr.enum_cards()
uid = ufr.list_cards()[0]
ufr.select_card(uid)
n = ufr.linear_read(pyufr.ufrauthmode.T2T_NO_PWD_AUTH, 10, 150)
uri = list(ndef.message_decoder(n))[0].iri
ufr.deselect_card()
except KeyboardInterrupt:
ufr.disable_anti_collision()
quit()
except:
continue
# Get the brady URI using a libnfc-compatible reader
else:
if not target:
try:
target = clf.sense(RemoteTarget('106A'))
except KeyboardInterrupt:
quit()
except:
target = None
continue
try:
tag = nfc.tag.activate(clf, target)
except KeyboardInterrupt:
del(target)
quit()
except:
tag = None
del(target)
target = None
continue
try:
uid = ":".join(["{:02X}".format(v) for v in tag.identifier])
uri = tag.ndef.records[0].iri
except KeyboardInterrupt:
del(tag)
del(target)
quit()
except:
del(tag)
tag = None
del(target)
target = None
continue
del(tag)
# Process the URI
m = re.findall("rfidtemperaturemonitoring\?n=([0-9]+)&d=([0-9]+)C&"
"o=([0-9a-f]+)&i=([0-9a-f]+)&h=([0-9a-f]+)", uri, re.I)
if not m:
continue
n, d, o, i, h = m[0]
counter = int(n)
temp_c = -40 + int(d) / 10
temp_f = temp_c * 1.8 + 32
serial = i
# Display the tag's data
print("Brady temperature sensing label:")
print(" UID = {}".format(uid))
print(" S/N = {}".format(serial))
print(" Read counter = {}".format(counter))
print(" Temp = {:.1f}C / {:.1f}F".format(temp_c, temp_f))
sys.stdout.flush()Actually there is no native counter in this chip. The entire nfc output is programmatic.
Ah ok. I thought it had some kind of a framework that could be customized.
Anyway, that’s one chip I won’t implant. It’s all over the place precision-wise. I got close to 200,000 samples before calling it quits (I’m gonna fry my uFR reader if I keep going) and even if I oversample over thousands of samples, it’s nowhere near precise enough to measure body temperature.
Did you miss this?
That’s one awesome chip.
I didn’t miss this. In fact, I read it verbatim: a “small C program to control the NFC output”. As in, the chip does what it does (including, I thought, maintaining a counter) and your little C program just defines how the string in the NDEF is constructed. The sentence didn’t indicate that the C program was given full control.
If the temperature sensor was good, it’d be awesomer.
I wonder if it’s reprogrammable once it’s been customized. Temperature sensor precision aside, it might be a good platform to create interactive NFC implants. In which case, I would definitely implant one
Time to find the spec sheet I guess…
Amal, didn’t you say you were working on a sensor implant of some kind, or did I dream it? Is it based on this chip?
Nope
Amal does seem quite knowledgeable about it…
I might be falling for advertisement but they claim “Absolute accuracy of 0.3°C in the range of 0 to 40°C” and have a cert (whatever that’s worth haha).
EDIT: AH I see
Careful there: I measured precision, not accuracy.
My data shows accuracy seems to match the marketing material - possibly even better. But the precision is not good, and their literature says nothing about that.
At least, it’s not good for the purpose of measuring body temperature. Maybe it’s good enough to track the temperature of a frozen leg of lamb and certify that the cold chain hasn’t been broken.
In theory, yes… but what we found playing with it, you need to externally power the chip to reliably get the code updated… if you try to do it over nfc alone it’ll basically fail every time… one of a few reasons we abandoned this chip.
Even in a powerful-ass field?
Hmm, I think I’m gonna check if the flash on the Brady labels is locked and see if reflashing it with my DL533XL would do the trick. With any luck, they forgot to lock the pages, and the DL533XL puts out 1W.
It might just work
It has to do with power management inside the chip itself. If they used a nice sized power capacitor then sure it might work but 1) probably didn’t bother since updating in the field not necessary for this product, and 2) much easier to simply attach an antenna to the chip with no other components (temp sensor is built in) than to include a pcb and traces just for the power cap.
FYI the temperature sensor being inside the IC also lends itself to inaccurate results for multiple successive reads as the chip itself also heats up.
That said it sounds like a good idea to try anyway… if they didn’t lock the chip.
That’s true, but it would only affect accuracy, not precision. What I’m bitching about is precision. Accuracy can always be compensated for.