In this post we will take a look at how to improve the transmission power of your commercial UHF RFID reader to obtain optimal operation, in terms of communication distance and speed.

In our previous post we introduced the RFID technology and the possibility of developing battery free RFID sensor solutions. We introduced the challenges that you may encounter when developing a passive RFID sensor system.

As you already know, passive RFID sensor tags need to harvest more energy than tags used only for identification purposes. This need for energy makes imperative to optimize the power transmission from the RFID reader to the sensor tag. Not only the power level is important for passive sensor solutions, also the time during which your RFID reader is actually transmitting this power should be taken into account.

Synchronous vs. Asynchronous inventories

Most fixed UHF RFID readers allow you to do inventories synchronously or asynchronously. A synchronous communication would be that where you ask the RFID reader for the all the tags within reach and wait until answered.

On the other hand, it would be an asynchronous communication if the RFID reader informs you every time a tag is read.

It seems reasonable to think that setting your reader to operate asynchronously would give better results. In this case the RFID reader must do inventories continuously. But let’s find out if this is true.

For all the tests we used a simple application which allows to change the output power of the RFID reader as well as to start reading synchronously or asynchronously.

First we check that we are setting the output power correctly. The antenna port of the RFID reader is connected to a spectrum analyzer. Between the reader and the spectrum analyzer a 10 dB attenuator is placed to avoid possible damages.

To check the duty cycle for each of the reading modes we place a tag frontend in front of the reader’s antenna. The frontend’s Vdd is monitored with an oscilloscope. With this setup it can be seen clearly when the tag is obtaining energy.

Figure 1 shows the result obtained when doing a synchronous read in a loop. This setup has a duty cycle of around 50%. This result cannot be considered a good result since half the time the RFID reader is not transmitting power.

Read results using RFID reader with synchronous communication

Figure 1: Synchronous Read Results

This same reader running in an asynchronous mode obtains a result close to 99% (see Figure 2).

Read results using RFID reader with asynchronous communication

Figure 2: Asynchronous read results

It is clear that an asynchronous approach is better when trying to solve power issues. However, before committing to this approach you need to check that your RFID reader allows reading some memory position while doing inventories. Also, some sensors will not work with this method. Some sensors need to be accessed one position at a time and this usually cannot be done with an asynchronous read.

If a synchronous method must be implemented, it must be taken into account that the power transmitted when reading a user bank (instead a normal inventory) is smaller. Figure 3 shows the results obtained for a read data in a loop.

Read results using RFID reader with the read data command

Figure 3: Read data results

Since reading data sends less power, a simple solution to increase the communication distance is to do inventories in between measurements, though the data rate will be reduced considerably.

Note: the user must be careful in order to comply with local regulations – check for updates of this summary regularly – regarding power emission (check further details for both maximum values and duty cycle). Some RFID readers even allow setting a continuous wave. This means that the reader keeps sending power even if it is not doing anything. It can be a good trick to be used if done correctly.

Download your free Synchronous_vs_asynchronous_test SW and start testing with it or develop you own code.

Synchronous_vs_asynchronous_test

What is your experience? Do you prefer using synchronous or asynchronous communication? Does your application allow you to use any of them or does it require a specific one?