Working With NordicID RFID Readers

Recently we've been working on a solution for a client which is very heavy on RFID. The client has specified NordicID EXA31 and EXA51 readers for scanning food items in a retail context. It was our first experience working with this brand of RFID hardware, but so far the experience has been pretty great. Here are my top three lessons learned:

1. Code samples are an extraordinary help

NordicID are ahead of the curve for hardware manufacturers and provide excellent code samples for their devices, to integrate with any platform you could think of. In fact, the source code of their official demo apps for Android and iOS is all available on their GitHub.

Because of the permissive license on this code, I didn't have to worry about making a clean-room re-implementation - we were able to imitate and even recycle parts of their code without any fear of breaking the law.

Not all vendors are this smart, and often integration has been harder for us; writing serial-level drivers for devices with ages-old technical manuals, no support, and no examples. We can get there, but the modern way is a lot more satisfying and lets us give the client a great result, much faster.

2. Keep in touch with the vendor

When I discovered what I thought was a bug in the Windows 10 sample app, I posted a GitHub issue (with a full reproduction case and screenshots of course), and the original developer was really friendly and responsive in getting back to me. The team at NordicID helped us clear up the issue which turned out to be because of the firmware on our device... it must have been languishing in our client's cupboard for a while!

3. Assume the best

At one point, facing a strange bug where events from the hardware were arriving twice, I was fooled for a moment into thinking it was the hardware's fault (or by design). We all make mistakes. After a little break to breathe some nice outdoors air, it dawned on me that I had accidentally attached the event handler twice.

A few years ago in my programming journey, it would have been all too easy not to challenge my assumption, and to continue to believe that I was right and the hardware was wrong. This would lead to all kinds of nasty mitigations in the code which add complexity.

So this brought home the lesson that we must always: Step back, take a breath, and assume that the hardware (the computer, the API, etc.) is right, and I am wrong. Assume the best of the third party and the worst of yourself. This challenges our humility, but is ultimately healthy for our growth as developers (and probably our growth as people too - a grand point, I know).

Wrap up

So in conclusion, working with hardware is much easier with a friendly, modern vendor. Keep in touch using the right channels (like GitHub), and always check yourself when it comes to assumptions about right and wrong!