And… they sent me the oversized UHF tags 
Grrr…
1 Like
This is getting embarrassing… I just received a package with a letter saying “So sorry we sent you the wrong labels, here are the right ones” and a bag full of the same UHF labels 
The package also contains a pamphlet with the motto “Specialists in identification”. Indeed, I can tell…
8 Likes
Yeah, I got me a bunch of NFC labels today! (shall we say the Brady bunch? … Sorry…)
Preliminary tests aren’t good:
-
I stuck one in the temperature chamber, stabilized at 22C: the temperature it reports swings from 21.4C to 23.3C from one read to the next. While that’s probably okay to track the temperature of frozen goods (possibly it’s optimized for freezing temperatures too), the precision is far too low for body temperature. Accuracy seems reasonable though.
At any rate, it gives me a renewed respect for the humble Destron Fearing Bio Thermo aka xBT, which performs much better precision-wise.
-
There’s a counter in the URL: each time the chip is read, the counter increases. The question that immediately springs to any programmer’s mind is: how deep is the counter and what happens when it overflows?
Or said another way, if the counter is 16 bits and I read it 65536 times, does it roll over and keep going, does the chip crash or does the chip disable itself?
The side question is, since it probably writes the counter to the same memory cell over and over, what happens when said cell becomes unwritable? I will of course test this by reading the shit ouf ot it until it dies (if it dies), but it does not inspire confidence.
-
This being a shitty world of IoT cloudiness where the companies don’t want you to have control over your own devices, sure enough the temperature data is obfuscated. It’s not encrypted exactly - at least it doesn’t appear to be - but it’s not in clear text. Some reverse-engineering is in order.
I kinda hoped it wouldn’t be, but… no real surprise there: why make it an honest-to-goodness device when you can make it shifty, tie it to an online service and hamper the user’s ability to do what they want?
Also, the device seems to tack on an OTP, and if you mess with it, the Brady website throws a fit and “disables” the device - meaning it refuses to report the temperature from that point on. Not that I care, I don’t intend to send them any data, but I thought I’d mention it because it’s really sad.
Okay, owned. Sometimes I amaze even myself
Re precision, it may not be as bad as I thought: the tag’s mass is so small that it has a stupidly small thermal inertia. As a result, I’m picking up a lot of stray heat variations, mainly from the ACR122U reader I use, and from drafts in my office. Just putting it on the reader is enough to make the temperature reading jump 60 degrees in one second. Amazing!
Anyway, I need to affix it to something metallic with enough mass, and read it with an external antenna to assess the precision properly. That’s for another day.
2 Likes
1 Like
Tolerance is ±0.9C and standard deviation is 0.3C in ultra-stable temperature environment at 30C over 600 samples. Not great…
1 Like
If it’s anything like the NTAG216 then it would be a 24 bit counter. My hunch is that the chip inside it is actually the SmartSensor chip from NXP which has a shitty thermal sensor built in… but I could be wrong. Does TagInfo identify it as an NXP chip?
As for counter rollover, in the NTAG216 this is what the SDS says;
Once the NFC counter has reached the maximum value of FF FF FF hex, the NFC counter value will not change any more.
Therman inertia… I’ve not heard of that term before but it makes perfect sense. NEW PHRASE UNLOCKED!
2 Likes
I am still bitter about that thing. POS
1 Like
If it goes over 65535, I’ll get it up to above whatever is needed to wear out the flash and see what happens then.
It says:
- IC manufacturer: NXP Semiconductors
- IC type: NHS
- Capacitance: 50 pF
- Storage size: 888 bytes
If that’s what’s in them tags I got here, I can see why. Sensor performances are sub-par. Even for their intended application (cold chain tracking), I’m pretty sure a fussy QA inspector would not validate the solution, on account of the fact that you might read -4C when the goods are really at -3C.
Or did you have other complaints?
The NHS3100 is a temperature sense IC that NXP specifically advertises as field programmable, but when you spend countless hours doing R&D only to find out that their execution of that is a hack job side project by one of their engineers that is poorly optimized for non-ideal coil shapes, they tell you to punch sand.
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()
2 Likes
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.
1 Like
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…