Time for some technical details!

Each "player tag" will be a small self powered PCB with a low power MSP430 and a TI CC2500 radio. These radios will broadcast small packets containing some basic information (Tag No., Player name, etc) that can be received by a network of receiver nodes in the field of play. The receiver nodes will again be small battery powered devices with an MSP430 and CC2500 radio. They will listen for nearby player tags, record the received power of each tag and forward this information to the base station. The base station will be a USB device plugged into a computer, again with an MSP430 and a CC2500. The computer will receive the player tag power information from the network of receivers and triangulate the location of each player. It will then plot these locations on a map and post it online for players to view on their smartphones.

So why not use GPS to find player locations? Well there are a few reasons, but I will narrow the list down to two. First, GPS will not always be accurate or available at all in large concrete and metal facilities where many paintball or air-soft games are held. Second, GPS chips on every player tag would add a HUGE expense to this project, especially since we will still need to use radios for wireless communication. Fortunately, since the CC2500 is dirt cheap and high performance, it solves several of our problems.

Project Tasks:

- Hardware

- Prototype RF communication with EZ430-RF2500 development boards

- Design PCBs for all three types of devices (Player Tag, Receiver Node, Base Station)

- Design firmware to handle communication between devices as well as data management

- Order PCBs, assemble them, debug, debug and debug some more

- Software

- Database

- Code to triangulate player locations from RF power info (Not trivial)

- Code to host website with player locations plotted on a map

Project Logs

Collapse

Sci-Fi-Contest Complete!
John Boyd • 04/23/2014 at 16:38 • 0 comments
Well we have finally got this project to a state we feel comfortable calling "complete" for the Sci-Fi-Contest. While any project of this nature can always be revised and improved, we now have a fully functioning system that tracks your location and displays it on a map! Below we will have a video demonstration.
Summary of project:
The project uses a network of TI EZ430-RF2500's to measure the signal strength of a tracking beacon inside a building. We demonstrate our system using 1 tracking tag, 1 base station receiver & 5 receiver nodes and only a 1Hz location update rate, but this can easily be expanded to have hundreds of nodes and many tracking tags. The update rate can also be increased, but we had it running slowly for other tests. The network nodes measure the signal strength (RSSI) of the locator beacon and send this signal strength information back to the base station. The base station hands this data over to a python script that pushes all of the information onto a database. Finally, a C# GUI application gathers the information from the database, calculates the best approximate location of the tracking tag within the room and displays it on a map.
Video:
Demo Video
Some notes about the video:
- Sorry about the random circles and lines appearing on the map. We had these displaying for debug use and forgot to turn them off.
- You may notice the green dot bounces away from the actual position a few times (even off the map once). This is because of RF interference in the room. It turns out RF tracking inside a room like this is a non-trivial task. Our system recovers relatively quickly though and starts showing an accurate location again.
Testing, testing and more testing
John Boyd • 04/17/2014 at 18:54 • 0 comments

So as Clayton mentioned in the previous log, we pretty much have the entire system integrated and now it is time to test, debug and improve. We have been testing the system in different environments, and have had interesting results. While the results are certainly not as reliable as we would like them, we do get results that are "in the ball park".
Just a little hardware update: I resolved several issues with the hardware, most notably porting the firmware from the EZ430-RF2500 platform to our custom platform, but a few issues still remain. Unfortunately, since the project works decently just using the EZ430-RF2500 boards and time is running out, we will be sticking with these boards for the proof of concept, and may come back and finish up the custom hardware once the project is completely working.
We are well on our way to wrapping this project up. We mainly need to improve our distance calculations between the receivers and the tracking tag. Once we work that out, the system should work much more reliably. Stay tuned for progress!
The Green Dot of Success...
wahwahweewahh • 04/14/2014 at 20:22 • 0 comments

The software has seen a lot of improvements since the last update. First of all, we officially have tracking. The screenshot below shows three nodes (red dots) and one beacon (green dot). The program can process data in real time and is currently only limited to how often the nodes send data to the base station (1Hz). When the 'Start Tracking' button is pressed, the program will make the following query on the database:
'SELECT * FROM Data WHERE BcnTXID = transactionID AND ID > cursor'
Since John incorporated a transaction ID, I can choose groups of readings easily by selecting a certain transaction ID. The cursor handles placement within the database, making sure previously selected rows aren't selected again. Once the database returns the resulting tuples from the database, if there are more than two rows the program can begin triangulation. The program then runs through various calculations in order to return a coordinate for the beacon (green dot).
The image below just shows a simple program flow that the user would take when running the program. The user sees a welcome screen and clicks the Next button to go to the main program window. From here, the user must select the Load Image button in order to load a floor plan image. As soon as the user selects and opens the image, another window appears to allow the user to input the dimensions of the room. The user is led back to the main program window where they can output the list of nodes and begin tracking.
Overall, the project is complete, however there is room for some slight improvement and modification that will be looked into by John and I.
SQLite and Concurrency
wahwahweewahh • 04/03/2014 at 03:19 • 0 comments

Just a little minor update this week. I have successfully integrated SQLite into the visualization program (C# - WinForms) as well as the Python script that handles reading the PC's serial port. Instead of writing serial port data to a file, the plan is to parse through strings of serial port data and push the data to a local SQLite database. The visualization program will read tuples from the database and begin processing. One of the fields in the database corresponds to a row identification number and will be used to tell the viz program where to read the next tuple. Since the viz program knows the last row that was read, I can perform a query to only (SELECT * FROM Data WHERE rowID > currentRow;) get rows that have been added after. If the result returns NULL, then we know there has been no new data added to the table.
Countless hardware troubles!
John Boyd • 04/02/2014 at 01:34 • 0 comments

It has been a while since I posted a project log, so I thought I would give an update. I have been working hard trying to debug several issues on our assembled board. For some reason I cannot get the SPI communication between the MSP430 and CC2500 working. At first I thought the CC2500 got fried during soldering, but now I am severing the SPI wires and watching them on the scope, only to see that the SPI clock isnt even being driven by the uC.
The problem with this is it could be a firmware issue (The SimpliciTI SPI APIs are deep and complex) or I may have broken the eUSCI module on the MSP430 if I accidentally overcooked it during soldering. Given that both of these problems are tedious to solve, I will be focusing on integrating the firmware better with Clayton's software and we can just use the EZ430-RF2500 devices to demo the project for the Sci-Fi Contest. Once the firmware is solid, I will come back to debugging the hardware, but PCBs may arrive after the contest has ended. Dont worry, we will continue to update this project LONG after the contest is over :)
Software is in the works!
wahwahweewahh • 03/29/2014 at 00:11 • 0 comments

Hey guys, just wanted to let you all know that the software side of this project is in the works also. (source code here) I (wahwahweewahh) have chosen to go with a C# program, because of the awesome GUI tools this language offers. Microsoft's Visual Studio is also a great platform to quickly try out different GUI ideas without having to dive down into the inner workings of the code.
Got ourselves a fancy map styled welcome screen :)
This is the layout I am playing around with for the program. A map of the field will go on the right side in place of my picture.
I also added a form so that we can add receiver nodes to the network. I have also been writing code to deal with incoming data from the sensor network. Currently I have a python script that receives data from the network via USB and stores it to a file. I have been playing with the data in Excel trying to formulate a good algorithm to calculate the distances between each sensor node and the tracking tags. Once I know these distances, it is just a matter of solving a few algebraic equations to triangulate the location of each tag. Python will most likely not be a permanent solution, but it is working for now as a proof of concept.
Hardware is coming along.
John Boyd • 03/26/2014 at 03:51 • 0 comments

I made some rough PCB prototypes for the board a while ago, just to test the radios, micro-controller and firmware together. You can see a picture of the Altium board file below. I had the Electrical Engineering Department at my school (Texas A&M) mill the PCB to test. If the PCB works as expected, I will modify the board and send out to OSHPark (or similar) for a more professional run.
I spent hours soldering the tiny SMD components on (0402 SMD inductors, 0603 SMD Caps, etc), especially the CC2500 which I was only able to get in a QFP package.
This little fella was NOT easy to hand solder! You may notice some pretty terrible copper patterns in the picture above. This was actually a milling error that the PCB mill at school did. The final product will be ordered from a fab house and will have no such issues.
Here are some pictures of the board soldered up and ready for programming and testing. Now that the board is assembled, I will be focusing on debugging any hardware issues and then porting the firmware from the EZ430 to this board.
I have a lot of extra test loops and jumpers in this circuit for debugging, but my final circuit will not have any.
Firmware Ahoy!
John Boyd • 03/25/2014 at 04:32 • 0 comments

We now have a first draft for firmware for all three devices!
After spending about a week playing around with the EZ430-RF2500, we finally have something to show for it! We have three build configurations in Code Composer Studio each with a first draft firmware for all three devices using TI's SimpliciTI protocol stack. The Player Tag is broadcasting its basic info (Tag ID number, broadcast strength and packet number). The receiver nodes are receiving these packets, measuring RSSI and forwarding that to the base station. The base station is capturing this data and immediately streaming it to the computer via USB serial interface provided by the EZ430. The code can be found here.
Issues:
I spent several hours debugging packet collision issues. At first I did not know why none of our packets were being received, but after a bit of thought we realized that all of our packets were transmitting at the same time and interfering with each other. To fix this I gave each device a specific time to transmit based on its device ID, ensuring that no two devices tried to transmit at the same time. While this is working, it is not very efficient and slows the total packet rate the network can handle.
What next?
Now that we have a basic implementation of the system on the EZ430 development boards, it is time to start designing some PCBs. Dont get me wrong, I still have tons of work to do on the firmware (specifically improving the communication strategy), but it is a great start! Now that I have data flowing to the computer, Clayton (wahwahweewah) has some real data he can work with as he develops the software.