Get the basic ‘do’s and ‘don’t’s plus some quick tips to optimize the software you develop for maximized RFID sensor system performance.

We have mentioned how different APIs will impact your coding for RFID systems that include battery-free sensors but… how wary should you be about the impact of the API on the overall
performance of your solution?

As battery-free RFID sensor manufacturers, we have long been testing our tags with multiple readers.

Developing your own software

First things first, you want your system to work. Without testing all the options with the multiple parameters you can change, you already notice that the same setup just changing the reader model can provide very different results.

Setup example to check RFID sensor system performance

Setup example to check RFID sensor system performance

You can experience very different read ranges and very different data rates at this point. Do not give up yet, you should be able to program your software so that these results even quite a bit.

Giving it time to test with different configurations

I highly recommend you to test your own setup with multiple configurations and choose the one that works best for you.

While it is true that it takes time, the only reason for you not to do it is that you are already happy with the current performance. And even at this point I would recommend you to test in order to have a backup for unexpected issues and/or optimize your solution for efficiency!

Here are the hints of where you should look at depending on the issues you are experiencing:

  • Shorter read ranges than with other readers. The first thing you need to check is that the output power of the reader is the same. If it is not, you can optimize the software as much as you want but you will never get the same read range.

Once that’s checked, you want to make sure you’re using similar coding – in our experience Miller4 works great for sensor tags but again, it is to be tested in your specific application.

If you still have major read range differences there is a big probability that the idle time between commands is longer in the reader that has the shorter read range. You will have to check this in the APIs or even contact the reader manufacturer to understand if this could be the problem.

  • Lower data rates than with other readers. This will most probably be an issue with the coding and idle time between commands. In case you are lucky, the reader manufacturer may be able to change/reduce the idle time but not much more you can do here.

Our experience with readers in the market

We have worked with many different reader models and our feeling is that the read ranges you can achieve with readers having the same output power is very similar. No big differences here.

Just one hint: if you are experiencing trouble with the read range of a specific reader, you may want to check if it is a problem with the reader itself. Even though 95% of reader manufacturers design their models perfectly, we’ve found some that do not manage well the high output power – increasing the output power does not give better results due to saturation. This can be spotted if you seem to have the same read range when using a lower output power.

Data rates in different reader models tend to vary quite a lot between reader models. Here is where the APIs have the impact. You may find that you cannot send specific commands whenever you want but you are obliged to run a complete set of commands. This slows your code and reduces the data rate.

Even though we hope this information helps, programing software for RFID sensor systems is not an easy task so you will have to play around with different readers and APIs to deeply
understand how to develop software properly.

For more information about read range in RFID systems download the ‘The essential guide to developing RFID sensor software‘ free eBook.

Developing RFID sensor software eBook

Developing RFID sensor software eBook