Positioning using RFID (Part 2)
The basic RFID system consists of the reader,the reader’s antenna, the middleware, the data processing unit, and the tag(s). In many occasions, the middleware and the data processing unit refer to a single device, usually a computer. In addition, it is not uncommon for the antenna to be embedded to the reader, which is a welcomed combination when designing portable systems.
The positioning abilities of RFID are examined with the help of the parts shown in the table below.
The first item in the list is the Garmin eTrex® 10 GPS unit, a consumer-grade portable receiver with the ability to log single points (Waypoints) or a series of recorded points forming a track (Track). It is compatible with both GPS and GLONASS. Once on, it starts collecting points and building the current track. It is possible to set the time interval of point collection down to 1 sec. The unit connects to the computer via USB as a mass storage device; the spatial data is automatically converted to GPX format and can be transferred by copying the files to the hard disk. Long-range reader
The original purpose of the CF-RU5112 RFID reader model is outdoor placement for car parking lot access control; in a typical scenario, the registered cars are equipped with plastic RFID tags in the form factor of a credit card. The tags are remotely interrogated by the reader and, provided their code is valid, the middleware sends the right command to open the gate.
The device has two cable connections; one for power and one for communication. Power requirements are covered by either a power adaptor connected to the mains or a portable battery pack system which can provide a voltage as low as 9V for a limited functionality. Communication with the computer is possible via the Universal asynchronous receiver/transmitter (UART) port and a UART to USB adapter. The UART connectors are used with serial communication standards similar to the serial ports found on personal computers, and allow for transmission of data at configurable speeds, which are configured by the controlling device (in this case, the computer).
The smaller RFID reader is a desktop USB device about the size of a modern smartphone. It can read and write data to the tags using the bundled software. The tags are credit-card-sized UHF transponders with a small internal dipole antenna. They came blank so they had to be assigned to a unique ID code with the help of the small reader/writer.
The manufacturer of the RFID readers provides the necessary driver software for the units to be recognized by the operating system (Microsoft Windows only) and the necessary resources for further development of customized applications; in addition, they offer a demo app which connects to the reader and runs the functions it supports.
RFID readers are relatively simple devices that essentially send and return packets of data. For the data to be actually usable, they need to be “translated” to more meaningful information, such as ID code of the tag that was read, date and time of the reading, and of course the RSSI data which is essential to the positioning technique described here. All these tasks are performed by middleware devices. In the present implementation, the role of the middleware is undertaken by a small portable computer running the manufacturer’s demo software and a “spying” software, which logs the data packet transactions, since no logging function is provided by the demo app.
The device connects via UART port, connected to a UART to USB adapter and then to the computer. It should be noted that UART hardware devices require that the data format the transmission speeds are configured by a separate microcontroller, in this case, the computer via the demo software, in the Reader Parameter tab, as shown in the screenshot above.
The USB interface hosts a COM port which the demo software opens in order to initialize communication with the device. In parallel, a third-party software is activated and set to “spy” data traffic on the same COM port that is being used. The spying software, Device Monitoring Studio by HHD Software, (hereafter the logger), is a multi-use data logger which is able to log data sent and received across serial ports following the RS232 or RS485 communication protocol standards (which are typically combined with the UART hardware connectors) and save the logs to the hard drive.
The data captured by the logger is exported to a text file, but a preview is shown in the screenshot below. The generated text appears when the demo is set to Query Tag mode, in which the RFID reader continuously transmits query signals until a tag is found in the interrogation area and it responds. The query intervals are controlled by the demo software and can be set to anything between 40–300 ms. The data corresponds with the expected interrogation bytes explicitly described in the RFID reader’s User Guide document.
Obtaining data from the GPS receiver
Consumer GPS receivers like the Garmin eTrex used in this project are built to be user friendly and easy to export data. As mentioned in previous paragraph, the recorded data is exported to GPX format the moment the device is connected to the computer.
The GPS Exchange Format (GPX) file is a XML text file with .gpx extension. As exported by the GPS device, it contains information that can be converted to spatial features (points) by the dedicated tool in ArcMap. Regarding its structure, tracks are registered by the tag set
<trk> … </trk> and the logged points are found in between. The point entries do not have a serial ID number but they do have the following (in order of appearance):
- Latitude (in decimal degrees)
- Longitude (in decimal degrees)
- Elevation (in meters)
- Time (in the format: YYYY-MM-DD[T]HH:MM:SS[Z])
The GPX standard defines an
<extensions> tag for each point, but Garmin’s devices do not use it. Instead, URLs are found in the header (before any track points) which point to external location with the ‘extensions’ information: they specify things like the spatial units, various data type declarations, units for features of more advanced GPS devices such as temperature and heart rate, and others. Projection is not defined in the GPX file because it is always the standard WGS84, meaning that spatial features that are either generated or are directly exported from GPX originals will need to be projected.
Obtaining data from the RFID reader
In order to get usable data from the reader, a special setup has to be made. This is because the manufacturer does not offer data logging software; instead they offer SDKs for the customer to build their own. Below is a diagram which outlines the principle of the setup.
Data transfer among the parts of the system occurs at all times of operation, even if no tag responds. The command that initiates interrogation is sent by the software. The first state of operation is the query state, where the reader continuously scans the environment of tags that might respond. This can be observed by monitoring the data transfer through the logger’s live interface.
Above is a screenshot of the log from the communication between the reader and the tag number
00 99. The code is not easy to read, so here’s an explanation.
The communication between the reader and the tag contains one or more command-response dialogues. The first dialogue is always the Inventory: the reader interrogates its environment by transmitting signals with the Inventory command repeatedly until a tag is found. When one or more tags are found within the interrogation zone, they capture energy, activate and answer back to the reader. This initial response comprises a few data values which communicate the tags’ ID codes.
After the response from the tag(s), the reader compiles a message to be sent to the computer that includes the IDs of all the tags that responded coupled with the measured RSSI values for each of the tags. The second dialogue is the Read Data: the reader sends one command chunk to all the tags within its range notifying them that the data they contain need to be communicated back to the reader, followed by a second command chunk that notifies which of the tags must answer. This concludes the basic “read that RFID tag” function. More functions are possible, such as permanent or temporary deactivation (kill and lock) of a tag, modification of the data stored in the tag’s memory (write), etc. These functions, however, do not communicate RSSI meaning that they cannot be exploited for RSS positioning techniques.
From the user’s perspective, the operation of the RFID follows the steps outlined below, provided all software and drivers have been installed and are ready.
- Connect the UART end from the RFID reader to the UART-to-USB adaptor, and then to an available USB port on the computer
- Run the demo software and open COM port
- Run the serial port sniffer software, specify which COM port to “spy” and set the path where the log file will be saved. The log file is a text file without extension, and can be opened with a text editor.
- Switch over to the demo software and initiate Query function
After initiating the Query tool (which runs the Inventory), the software sends commands to the reader periodically via the COM connection in the form of small data packets, which are then translated into functions.
The frequency of the commands is specified by the Read Interval option, which can be between 40 – 300 ms. An increased Read Interval value means fewer interrogations per second. In the log screenshot above, the direction of the data can be either Up (from Reader to Computer) or Down (from Computer to Reader).
Regarding the Inventory function, which is the one returning RSSI values, the interrogation command has the following data form:
|1 byte||1 byte||0x01||2~4 bytes||2 bytes|
An example request code for the Inventory function is the following:
06 00 01 04 00 ac 36
Hexadecimal numbers are written with the prefix
0x …, to distinguish them from decimals, so
0x0a is the same as
|0x06||6||Length of the command data block in bytes, not including itself. The entire code is 1+6=7 bytes.|
|0x00||0||Address of the reader|
|0x01||1||Response command type. |
|0x04||4||Data parameter (Qvalue)|
|0x00||0||Data parameter (Session number)|
|0xac||172||Check byte – Least significant byte (LSB CRC-16)|
|0x36||36||Check byte – Most significant byte (MSB CRC-16)|
EPC ID data chunks contain:
EPC-1 = TagID length + TagID data + RSSI
In the example of the screenshot above, the following response data code can be seen:
0a 00 01 01 01 02 00 99 c7 12 7f
The length of this code is 11 bytes, i.e. 11 hex numbers.
|10||Length of the command data block inbytes, not including itself. The entire code is 1+10=11 bytes long.|
|0||Address of the reader|
|1||Response command type. 0x01 is Inventory|
|1||Number of the detected tag|
|2||Length of the tag ID, in this case,the next two bytes|
|0||First byte of the tag ID|
|99||Second byte of the tag ID|
|18||Check byte – Least significant byte (LSB CRC-16)|
|127||Check byte – Most significant byte (MSB CRC-16)|
Cyclic Redundancy Check (CRC) is an error-detecting computation, similar to hashing and checksum functions used for large data sets. The two numbers (LSB and MSB) are calculated from the rest of the data internally by the reader; the computer can then recalculate them from the same data and compare the new LSB and MSB to the original ones. Transmission or communication error will have occurred if the two sets do not match.
Calculation of GPS accuracy
GPS points collected over extended periods of time are normally distributed over the true value. For shorter periods, they do not always average over the truth because the sample data may not be enough (Rutledge, 2010). A normal mixture of normal distributions is normally distributed, meaning that for datasets of extensive periods of time, points converge to the true value. For shorter periods of collection, Garmin GPS accuracy is calculated by determining the standard distance in the X and Y directions, then by calculating Circular Error Probable (CEP), and finally by calculating the 2DRMS (95%) radius (Coyle, 2012).
Standard distance is calculated as follows (Mitchell, 2005):
where and the coordinates for feature i, and are the mean centers, and n the total number of features.
Circular Error Probable is a statistical computation used in ballistics and GPS. For a target at coordinates (x,y), CEP is defined as a circle with center (x,y) and the smallest possible radius so that it contains all locations where there is a 50 probability of finding the true target. CEP is calculated as follows (Coyle, 2012):
Next, the 2DRMS statistic needs to be calculated which combines the vertical and the horizontal probability. However, ArcMap calculates the standard distance based on the combined probabilities of the X and Y coordinates, therefore it is not necessary to include it.
Analysis of the RSSI behavior
RSSI is an indicator based on the strength of the signal reflected by the tag. In order to conduct a pragmatic survey and directly calculate the signal levels, it is necessary to have a complete reference guide on the specifications of the equipment, which was not the case with the specific model. Therefore, the first step is to take measurements of RSSI values for tags placed at known distances in an obstacle-free environment to prevent signal degradation as much as possible.
The equation of propagation that links measured RSSI and distance was built based on the values in the table below.
Natural logarithms are converted to base-10 logarithms as follows:
After this transformation, the developed equation matches the RSSI equation:
The equation of propagation is solved for distance :
The reader is placed at an “unknown” position in a clear environment. In addition, tags are placed at relatively close positions ( < 15 m) away from the reader. The position of the tag locations is determined by the GPS. The reader, which is controlled by the portable computer it is connected to is activated and RSSI value collection takes place, against one tag location at a time. The RSSI values are statistically analyzed and the average value is used as input for the pre-calculated propagation formula, which extracts a value of distance. Distances to all the tag locations are combined with trilateration calculations and a relative set of coordinates is produced (x,y), which is converted to global coordinates.
For a 2-dimension cartesian system, let unknown point, , , points with known coordinates, and , , distances between and , , respectively. The coordinates of the unknown point are the solutions of the system:
In the trilateration testing phase, tags were placed at locations and their positions were measured using a GPS. For each of the points, the most accurate data collection session was used, and their mean center was regarded as reference point. The coordinates had to be converted to UTM (projection WGS 1984 UTM Zone 33N) to correspond with the cartesian system. Using the generated model, the measured RSSI values are translated to distances.
Ideally, the system has solution . The system would ideally be represented by the figure below.
However, the system has solution within an area encompassed by arcs (ab, bc, ca).
Causes of imperfect position estimation are:
- Locations of reference tags are GPS-based
- Combined (pooled) variance does not include model error
- Terrain anomalies
- Multipath, mainly from ground reflections
- Antenna radiation pattern
- Collision of tags