Want a free board? Read below!
My regular readers may already know that I never stop working on a project half-way. This is unfortunately the only exception so far, motivated by the fact that an IC isn’t doing what it’s supposed to do, that my thread on the TI support forum was left unanswered for months and that I’d like to upgrade some of the chosen hardware.
So a few months ago I wrote a quick post about using a standard coil for NFC tag implant reading. The PCB you saw in the article is the one I’ll be writing about.
The main components are:
– the USB-enabled ATMega32U4
– a connector for the NRF24L01
– a Lithium-Ion battery charger
– an NFC transceiver
– a proximity sensor
The main idea of this platform is to read NFC tags while keeping its power consumption low. The microcontroller is communicating with the NFC transceiver so you can use the platform as a standalone device or computer peripheral.
You could therefore control a switch (using the expansion header), send the tag data via RF (using a NRF24L01 you’d connect) or simply have the ATMega32U4 forward the read/write commands sent from your computer. The original idea was to support libnfc.
The bq24232h is a neat little chip that is very convenient when having a USB powered platform. It’ll of course charge your battery but will also behave like a standard LDO when none is connected. As Li-on battery charges can be very complex it has several inputs used to set the optimal charging parameters (charging/termination current, pre-charge/fast-charge safety timers, maximum current on the 5V USB input…). If you look at its datasheet you’ll see on page 17/18 how a proper li-ion charge should be done. The chip can also monitor the battery temperature and even has short-circuit protection.
A USB interface was required to operate the platform as a computer peripheral.
The chosen ATMega32U4 has several low power modes, an integrated bootloader and has all of its IO pins used in our platform. As the voltage will vary anywhere between <3V and 4.6V we are running it at 8MHz. Its 3.3V regulator is used to power an external NRF24L01. Given that the latter accepts 5V signals and that the ATMega32U4 also sees 3.3V signals, no voltage translation is required.
Unfortunately the bq24232 doesn’t have any battery under-voltage lockout so the li-ion battery voltage could theoratically go as low as 2.7V (minimum voltage for the ATMega32u4 and NFC transceiver).
The PCF8883 is a capacitive touch/proximity switch with auto-calibration and very low power consumption (3uA). The goal of this chip in our platform (when operating as a standalone device) is to wake-up the microcontroller when the NFC tag/implant is close. Our device will therefore always be in power-down and will only consume power when it is actually needed. Given its voltage range is 3V->9V our platform will never wake-up once the li-ion battery goes under 3V.
I chose the (not so cheap) TRF7970A from TI. This decision was motivated by a collaboration with Amal Gaafstra (the xNT tag creator), who was interested in having a transceiver with NFC peer to peer mode support. The TRF7970A is the updated version of the quite popular TRF7960.
This transceiver is supposed to take care of all the low level stuff for you (modulation, framing and such) for the ISO15693/ISO18000-3, ISO14443A/B and FeliCa protocols. In short, you just need to give it the data you want to send to the tag using one of its interfaces (SPI or parrallel). It even has a 127 bytes FIFO.
To put it simply: the TRF7970A isn’t doing what it’s supposed to. I found several examples (provided by TI) of tag reading procedures that I implemented as is…. without success. I put the sniffed communications on the e2e forums demonstrating the odd behavior yet my thread is left unanswered. In more details, among other things, I was forced to use 10ms delays to fetch data from the internal FIFO instead of using the dedicated RX interrupt.
Thinking that I may have made a mistake on my PCB I even bought the official development board! This is something I practically never do 🙂 … but that didn’t help as I was still getting the same odd behavior. I couldn’t find anything in the erratas either.
If you want a free PCB and a small bag with most of the platform components in it, please drop me a message and I’ll gladly send them to you. I decided to stop working on it because the official development board with the official tag reading commands didn’t work but also because I currently am very busy working on the Mooltipass production process.
I might get back to it some point in the future, though I may replace the NRF24L01 with an ESP8266.
Edit (03/19/2015): 5 months later I got a reply, it seems that a possible solution to the problem would be here. Will try and let you know.
They’re all CERN & GPLv3 licensed. If you look at the firmware you’ll see that I implemented my own ISO14443A activation and selection procedure following the official specs.
kicad files NFC firmware TI examples and advices NFC reader BoM