Introduction
I was initially looking into off the shelf hardware, however was unable to find any readily available equipment (to the hobbyist market in low quantities) that was reasonably priced, and fit the requirements. Therefore partly as a personal project, and partly in preparation for a possible commercial product I decided to put together a prototype active RFID tracking System.
The solution I came up with is based on 3 main hardware components, and 5 software components. It utilises mesh networking meaning that only a single reader needs to be physically connected to a PC, all other readers just require power.
Hardware:
- Tags – Carried around / placed on assets to be tracked.
- Reader Nodes – Placed around the area where the assets need to be tracked in.
- PC Reader – Connected to the PC, receives data from reader nodes and sends it to the PC.
The main hardware component used is the Synapse RF Engine, a 2.4 GHz transceiver module with built in support for running Python scripts, 2 UARTs, a number of GPIOs, and a 2.5uA low power mode.
Software:
- Tags – Software running on the tag to send out a “ping” at a defined interval, then put the “tag” to sleep before sending another ping.
- Reader Nodes – Software running on the reader node hardware to listen for tag “pings”, and after receiving a ping, send the tag ID, reader node ID, and received signal strength to the PC Reader.
- PC Reader – Software running on the reader hardware to receive data over the air from the many reader nodes and forward it to the serial / USB interface.
- PC Serial to HTTP data forwarder – Software running on the PC that listens for data from the serial / USB connected PC Reader, and forwards that data via HTTP to a server.
- Location tracking processing / display GUI – Web based software to process the tag data into a location, and display it on a map.
The software consists of Python used by the Tags, Reader Nodes, PC Reader. C# used by the “PC Serial to HTTP data forwarder”, and PHP, HTML, JavaScript, SVG used by the “Location tracking processing / display GUI”.
Video showing simulation of tracking between 8 rooms, using 5 tags. For real life demo showing a single tag moving between 3 rooms see below.
System Design
The system was originally designed around the principle of Trilateration. Reader Nodes are placed at fixed known positions around the room / rooms containing tags that need to be located. As long as a tag is within range of at least 3 reader nodes the tags position can be calculated by using the signal strength of the tag to each of the 3 nearest readers. However this approach turned out not to be very feasible since past around 2 meters thesignal strength started fluctuating in a seemingly unpredictable way. It may be possible to predict / error correct for the fluctuations however I opted to go for a simpler approach of just plotting tags next to the reader with the highest signal strength (the one they are nearest to). This now means that readers need to be placed in each room (ideally centrally) where tags need to be tracked and it is only possible to determine a tag is in a room, and not its position in that room (although it is not used the original trilateration code has been left in the download).
Using a two part system of sending the tag data to a web server (via a locally run data forwarding application) then displaying it back to clients in the browser has a number of advantages:
- Main application processing / display logic can be maintained in a single central location for one or more deployments.
- Location display / viewing GUI is cross platform (can be accessed via most modern browsers the have support for SVG excluding Internet Explorer).
- No software to install on client PCs viewing the map.
- Multiple users can logon and view the map at the same time.
The use of mesh networking means that only a single device needs to be directly connected to a PC, all the others just need to be within range of any other unit that itself is either close to the PC, or close to another reader that is close to the PC. The makes setting up the system much easier as there is no need to wire each node to the PC / the network or have a PC next to each node. The nodes just require 3V power.
Tag Hardware
Parts List
Per individual tag
| Qty | Name | Supplier | Cost (£ GBP) |
|---|---|---|---|
| x1 | Pocket Card Enclosure | Teko PC.4 | 3.56 |
| x1 | RF100P86 Synapse RF Engine | Future RF100P86 | 15.09 |
| x1 | VBH2032-1-LF Battery Holder | Farnel 1216359 | 0.84 |
| x1 | CR2032 Battery | Rapid 18-0386 | 0.88 |
| x1 | Small Stick On Feed (sold in packs of 4) | Maplin FE32K | 0.89 |
| x1 | Large Stick On Feed (sold in packs of 4) | Maplin FW38R | 0.89 |
Note: I used a CR2032 battery from Rapid however both Farnel, and Future also have a selection available from various manufacturers.
Building The Tag
I choose the Teko Enclosure because of its compact, credit card size. Unfortunately however this meant that the RF Engine would not fit vertically inside. I could have used one of the alternate form factor modules (sold by companies such as Panasonic that also support the Synapse firmware) however having the pins broken out is actually useful for updating the tag Python software / firmware at a later date. I therefore decided to bend over the pins, allowing one side to be plugged into the evaluation board as normal (albeit it a much looser fit) and the other to be plugged into the IDC header via an extension cable. 
I tried a number of approaches to bending over the pins, including bending them all at once using pliers, and trying to bend them against a flat surface, neither proved very fruitful. In the end I found the best approach was individually bend each using the tip of the pliers.
In terms of wiring things are fairly straight forward, pin 24 on the modules goes to (-) on the battery holder, and pin 21 to (+) on the battery holder. I soldered to the top of the module to avoid obstructing the pins meaning they can still be plugged into the evaluation board/extension cable for reprogramming. I also used some heat shrink tubing to tidy things up.
To secure the module in the enclosure I used two small stick on feet on the module itself, and two larger stick on feet to wedge the battery holder into a corner of the enclosure.
Not being as adept as I could be with finding productions on Digikey’s site I took the approach of ordering two parts (3M1324-ND, SAM1242-12-ND) really designed for PCB mounting and soldering a ribbon cable to them. A better approach (if such parts exist) would have been to purchase connectors that can mount directly to ribbon cable (therefore requiring no soldering), and to purchase suitable sized ribbon cable to fit.
Note: If you are going to use the same approach I did and solder the connections then ensure the solder does not leak into the socket, otherwise it will not be possible to plug it in to the evaluation board.
Reader Node Hardware
Parts List
Per individual reader – at least 3 reader nodes are required
| Qty | Name | Supplier | Cost (£ GBP) |
|---|---|---|---|
| x1 | 50mm x 50mm x 20mm ABS Box | Maplin N53FK | 1.59 |
| x1 | RF100P86 Synapse RF Engine | Future RF100P86 | 15.09 |
| x1 | 2.1mm DC Socket | Maplin JK09K | 1.69 |
| x1 | Regulated 3V DC 400mA Power Adapter | Maplin MG76H | 7.99 |
Building The Reader Node
As with the tags in terms of wiring, the reader nodes are fairly straight forward, with pins 21 and 24 going to the appropriate connections on the DC plug.
As with the PC reader it would be possible to use the “SNAPstick USB Module Interface” to avoid the soldering work, and in this case a USB power supply e.g. plug form or cabled form would also be required.
Using the Maplin N53FK box I found the modules only just fitted alongside the DC Plug, I had to remove one of small plastic mounting stands in the box to make it fit. The other small mounting stand served to secure the module in the box with one row of pins on the module fitting between it and the outer case wall. 
After the module and DC plug were fitted inside the box some space remained between the top of the module and the top of the box, therefore I used a single packing peanut to secure things. Something like hot glue could also be used however the packing peanut means the modules can quickly and easily be removed and put back into the box, e.g. for reprogramming (however generally it would be possible to reprogram them over the air).
Note: If you are looking for additional range the Synapse RF100PC6 (including a transmit amplifier) or RF100PD6 (including a transmit amplifier and allowing connector of an external antenna) may be more suitable for the both the PC reader, and reader nodes.
PC Reader Hardware
Parts List
| Qty | Name | Supplier | Cost (£ GBP) |
|---|---|---|---|
| x1 | 50mm x 50mm x 20mm ABS Box | Maplin N53FK | 1.59 |
| x1 | RF100P86 Synapse RF Engine | Future RF100P86 | 15.09 |
| x1 | TTL-232R-3V3 USB to Serial (3.3v level) Cable | SK Pang | 18.98 |
| x2 | LP2950ACZ-3.0 Voltage Regulator | Farnel 1685546 | 0.64 ea |
| x1 | 6 Way 2.54mm Molex Header | Rapid 22-0846 | 0.48 |
| x1 | Cable Tie |
Building The Reader
To simplify the process of linking the 3V Synapse module to the PC (i.e. avoid using a MAX232 and the extra PCB / wiring that would involve) I used a 3V FTDI USB to serial cable. The USB end plugs straight into the PC and provides a virtual serial port, the other end connects to the UART pins on the Synapse module. In terms of power, to avoid the need for an external power supply I used an LP2950ACZ-3.0 Voltage Regulator to convert the 5V power provided by the USB port / FTDI cable to the 3V needed by the module. The LP2950ACZ-3.0 however is only rated for 100mA therefore I used two in parallel to provide 200mA (the Synapse RF Engine datasheet quotes a transmit current of 110mA and a receive current of 65mA).
To save some of the work involved in building the readers a SNAPstick USB Module Interface (as included in the evaluation kit), and a RF100P86could be used instead however it would still require a suitable enclosure, and USB extension cable bringing the cost to ~50 GBP per reader.
[View: Module Wiring | Connector Wiring |Connector & Module]
Tag Software
The Python tag software is fairly straight forward, it performs 5 main functions:
- Set transmit power level for the tags.
- Initialise GPIOs to optimise current consumption in sleep mode.
- Turn off relaying of messages for other devices in the mesh network (it will only be powered up for a small amount of time every specified interval therefore this would not be very useful, also it may use up extra current).
- Send out a ping (via multicast RPC) to any reader nodes in range with the tag id, and a TTL of 1.
- Go to sleep for e.g. 10 seconds.
Specifying a TTL of 1 on the multicast RPC call causes only readers that are directly in range of the tag to receive the ping, otherwise by default any nodes not in direct range of the tag would be forwarded the call from readers that were. This would mean it would not be possible to work out which reader actually communicated with the tag directly and which communicated 2nd hand.
The software is loaded onto the tag via the Synapse “Portal” application available for Windows, Mac, and Linux, also included with the evaluation kit.
When programming the tag you should plug it into the evaluation board rather than run it on battery and program it over the air because leaving the module on the workbench un-programmed, even for just a few minutes will quickly drain the small battery (15mA when idle according to the datasheet) and 40mA / 110mA when receiving / transmitting.
[Download: Python Source]
Reader Node Software
The reader node Python software is responsible for receiving a multicast ping from the tag, and then forwarding it back to the module connected to the PC, along with the signal strength of the tag that sent the ping, and the id of the reader itself. Thanks to the SNAP (Synapse Network Appliance) protocol the intricacies usually involved with using a mesh network are all abstracted away from the programmer meaning it can be done in only 2 lines of code (excluding comments, variables).
[Download: Python Source]
PC Reader Software
The PC Reader Python software handles receiving data from the reader nodes (which themselves receive data from tags). It initialises the serial port, connects UART 1 (itself connected to the FTDI cable, which appears as a virtual serial port on the PC side) to STDIN/STDOUT (i.e. meaning that any Python “print” statements cause that data to be sent over the UART to the PC), and then initialises it to 9600 baud. The software prints the tag ping data to the serial port (after decoding the hex values to plain text).
Example: 003c02,001a06,57
(i.e. [tag id],[reader id],[signal strength]
If the tag that sent the ping is in range of e.g. 4 reader nodes at that time, 4 lines will be received with the same tag id, but different reader ids, and varying signal strengths depending on which reader nodes the tag is closer to.
Note: There is not a command / function to send data to the UART, Python access to it is available only by e.g. cross connecting the UART with STDIN/STDOUT.
[Download: Python Source]
PC Serial To HTTP Data Forwarder
The data forwarding application listens for data on the virtual serial port created by the FTDI adapter, and sends it to a HTTP server via HTTP Post. The local “COM Port” (e.g. COM 6) and remote servers HTTP address (http://www.example.com/locationtrack/?p=clientapi&password=track111) running the server software should be specified. If no HTTP server API address is specified tag data will be logged to the screen only (useful for debugging / testing).
It does not simply pass data straight through to the web API however does some initial processing, firstly in order to minimise HTTP requests (improve performance), and secondly in order to group tag pings together based on a 1 second time limit (something that would be otherwise unnecessarily complex to do on the web application side). It is assumed a tag is in the same location when any reader reports seeing that particular tag within a 1 second window from when the tag was first seen by any reader.
The application includes an “Auto Connect” checkbox which will cause it to automatically open the connection to the serial port when the software is loaded.
Note: One of the selling points of using the Synapse module (Python / high level language / RPC) based solution is the ease of use of it, everything is very much simplified for the programmer over other options such as perhaps using a Nordik nRF24LU1, and controlling it over I2C with an AVR in “C”. However this does bring with it additional licensing costs if you use over 6 modules on a network at a time using Portal. Therefore I coded a custom client side data forwarding application, rather than loading a Python script into Portal to do this and using RPC calls which would have been a simpler solution. In terms of deployments using the C# application also simplifies things avoiding the need for Portal to be installed / configured, the C# application just requires setting the COM port and URL.
The .net framework is required to run this application, it is available from Microsoft Update or as a download from microsoft.com.
C# Express Edition is available for free from Microsoft for viewing / editing the source code.
[Download: C# Source | Application Executable]
Location Tracking Processing / Display GUI
Coded in PHP this part of the code is responsible for accepting data from the HTTP Data Forwarder, converting the signal data into a location on a map, saving the data to a MySQL database and displaying it to one of more users viewing the map. The frontend is coded in JavaScript and SVG(using the jQuery SVG plugin). AJAX is used to poll the server for tags that have moved and JavaScript / SVG is used to dynamically animate them to their new positions on screen.
When the map is first loaded the tags will animate from their last 2 positions coming to rest at the current live location. JavaScript code has been written to ensure that tags are not placed on top of each other but rather clustered around the closest reader.
Support is provided on GUI for adding maps (one or more), readers, tags, and users (who can login) to the system.
[Download: PHP Source]
[View: Demo]
Video showing a single tag moving around the map plan diagram corresponding to its real world location in one of 3 rooms. The tag ping interval was set to 3 seconds.
Video showing failed attempt to use trilateration to determine the unknown position of tag using the known position of 3 readers, and signal strengths to them.
General Notes
I would suggest purchasing the Synapse Starter Kit (Future Electronics), since although modules are programmable over the air, a serial connection is required in some situations such as deleting running scripts that are in an infinite loop, or have disabled the RF interface used by the “Portal” software for uploading new software.
Synapse Wireless software, and documentation is available from the Synapse forum.
Download All
Includes all project files as linked individually above (Tag Python, Reader Node Python, PC Reader Python, C# Data Forwarder Source, Data Forwarder Binary, PHP Processing / Display application).
[Download: All Code]
Issues
- With the non trilateration approach of placing tags nearest to the highest signal strength reader, readers need to be carefully situated, particularly if they are in different sized rooms adjacent to each other in order to avoid false readings.
- If building the readers again I would use a different type of DC socket, as the one chosen was fairly loose when used with the 3V adapter plugs.
- I was expecting to achieve a longer battery life, as it stands battery life is around 1 week for a 10 second ping interval, and around 2 days for a 3 second interval on the CR2032. In terms of increasing battery life the main options would be decreasing the ping rate (therefore increasing the sleep time), or going for a different battery however this would likely require a larger form factor enclosure.
OpenBeacon Suitability
At first glance OpenBeacon hardware (as used at conferences such as the CCC’s 24C3) would appear to be an ideal choice, their website even mentions it is “meant to be used as a reference platform by hardware and software developers”, however the more I looked into it the more it did not seem suitable for my particular requirements:
- Form factor of 20 EUR white tags is not particularly ideal (open circuit board / battery).
- Keyring tags are available however they cost 25 EUR each + 5 EUR for the case, i.e. 30 EUR in total per tag.
- USB readers are available for 85 EUR however require a PC by each reader, not particularly suitable for even a small deployment with e.g. 4 or 5 readers.
- Ethernet readers are available but at a cost of 340 EUR’s they are somewhat expensive and still require a network cable to each, not ideal.
- Readers are not able to provide received signal strength but rather rely on the tags broadcasting at a set (limited) number of power levels meaning a position can not be calculated as accurately as it may otherwise.
Update: Reader Tip on setting up “Reader Nodes”.
Other Projects
If you are interested in this project you may find these others also of interest: Parallel Track, a free (for personal non commercial use) server side vehicle tracking application coded in PHP designed to be used with Python supporting Telit hardware modules running the embedded TModSoft software (firmware). Track Any Mobile, a web application for mobile phone tracking using the MSC (MSISDN) available using an SS7 API provider.
