I started work on a Near Field Communication (NFC) module. The design uses ST Micro’s CR95HF chip. The module above is the first shot prototype unit. This device uses a 13.56MHz RF carrier frequency and amplitude-shift keying . The CR95HF carrier frequency powers the loop antenna shown on the module above and the resulting field couples with a similar loop antenna on an NFC enabled card. The field coupling, like two loops of a transformer, powers the card. Powering up the card allows the CR95HF to transmit data to and from NFC cards. That’s the theory anyway.
NFC is also used in some newer cell phones. Below is a Samsung commercial touting the feature. It has a cute wife allegedly sending her husband a naughty video, which I guess is a pretty cool selling point.
In my world I’m not trying to send or receive a video. I’m just trying to write and read from an NFC card. One example of this kind of card is the ISO 15693 “Tag-it” provided by Texas Instruments. Another is ST Micro’s LRi2K. The Tag-it is shown below, and you can see the loop antenna built into the device. The LRi2K looks more like a credit card, and the antenna is not visible. On a side note, sorry about the dirty fingernails in the picture. I spent last weekend beating the ball joints out of my 1964 Galaxie 500. That’s a dirty job I haven’t yet recovered from.
I started off having pretty good success with the project. But I’m starting to understand why some engineers go bald. The CR95HF can be interfaced via an SPI or UART port. I opted to connect to it using a serial UART interface and write some Visual Studio 2010 code. The CR95HF is supposed to handle all of the NFC particulars including CRC16 generation, ASK modulation of data, and transmit and receive protocols. All you have to do is select the parameters of the protocol you want to use (in my case ISO 15693), and then embed the command to the NFC card within a Send-Receive command sent to the CR95HF. This last part is where my project seems to be going south.
Using my Visual Studio software I was able to communicate with the module I designed. I was able to verify using a spectrum analyzer that I was transmitting at 13.56Mhz. In fact, when comparing my module to the CR95HF demo kit I could see that the magnitude of my signal was pretty close, even though my loop antenna is much smaller. That’s an indication that my antenna matching is on par with the demo board. A good sign.
My software could read the ID from the CR95HF, turn on/off the NFC carrier wave, adjust the RF modulation and receiver gain, and even run through a recommended calibration process. I could even get it to wake up when a tag was brought close to the loop antenna, so it is detecting the cards. The one thing I couldn’t get it to do was talk to the card.
After re-reading the CR95HF datasheet, then re-re-reading it, I couldn’t see what I was doing wrong. I had a CR95HF demo board with software and I was able to determine that the cards I was trying to read do work. This led me to believe that the problem might be on the RF side. Perhaps my module wasn’t successfully transmitting and receiving the ASK data. I decided to make a few adjustments to the CR95HF demo board. I removed the microcontroller they had on the board and jumpered the UART TX, RX and ground connections to BM010 USB to serial converter I had on a breadboard.
The setup above guaranteed that I had an RF section that worked since I was just sending my software commands to the functional demo board hardware. If my prototype had a mismatched antenna then the demo board hack should work with the software I had written. With this setup I could see that my calibration values were different. They seemed “better”. But the end result was no change. The demo board that could read the cards would not interface to them using my software.
After a few hours of reviewing the source code of the software ST Micro provides for the demo board, and the source code of the microcontroller used on the demo board, I still haven’t found any indication of what I’m doing wrong. I seem to be sending the same data to the CR95HF that the demo board code sends. But I’m getting nothing back from the NFC cards.
Like all engineering problems, this one will get solved. Unfortunately, I’m getting close to last resorts. ST Micro’s microcontroller that was on the demo board was used to convert USB commands to SPI commands that are sent to the CR95HF. I may need to put the demo board back together, and use an oscilloscope to capture the SPI data. At that point I could compare what is being sent over SPI that works with my serial commands that don’t. Manually decoding SPI is not what I would consider fun. So maybe I’ll re-re-re-read the datasheet first.
Update: Shortly after finishing this blog I tried something a little different in my Visual Studio software, and ta-da, it worked. I was activating every command to the CR95HF via a button on my software form. When I implemented a series of communications between the software and the CR95HF I was able to link up with the NFC cards. I still don’t have a complete grasp on why the previous method didn’t work, but there appears to be a timing requirement at play. I’ll post more later, but as of now things are looking good.