MSP430 tracker

[petertux 40]

here's my latest project, a fully open-source msp430f5510-based gps/gprs tracker. it's a device that wakes up every few minutes and does the following:

 - tries to get a gps fix
 - connects to the gsm network, marks the tower cell ids it talks to
 - executes sms commands received - if any
 - starts a gprs connection and sends all the info it has collected via http to my server

it does all this only based on interrupts (zero blocking functions are used - all the similar projects I've seen are riddled with delay()s).

functions that fail due to network unavailability are retried a given number of times.

the data received on the server is placed into a database and gps positions of the cell towers are obtained for future triangulation. this info can be used if there is no gps coverage due to obstacles.

 

to give a little context, I felt the need of making my own tracker because I bought something like this an year ago and quickly became dissapointed by the dubious quality of the hardware design and software of the product.

here is the first prototype - the magnet wire was used to debug the hardware flow control-enabled UART of the sim900.

the first assembled module is ready to be used on my trip to Greece. instead of a small flat LiPo I ended up using 2 cells from a discarded laptop battery - there was no time to wire this to my motorbike. now after ~20 days it is still tracking.

I am pretty happy with this first revision, but I'm working on the next one that will include a small serial fram chip. I decided to use that as a buffer because of the weird way the mobile phone company is counting the gprs traffic.

for some more eye-candy, you can see my route from home to Ouranoupoli on a google-map overlay here:

http://www.simplex.ro/files/trips/test.html

 

waypoints are 10 minutes apart, the trip took 10 hours and about 800km.

project home: https://github.com/rodan/tracy

 

 

[username 198]

Looks great mate! I might be going overboard/feature creeping here but i'd be handy if you added a micro SD to log additional data / data when cell isn't available. Then add an interface to transfer the SD data via USB MSD as well as charge the batteries.

 

Had a question, what are the copperish looking wires that were soldered to the cell module for?

[petertux 40]

hi @@username

 

yes, you are right, if there is no gprs coverage the currently acquired data is lost in this first revision. for the second one I decided to include a tiny serial F-RAM chip from cypress (FM24V10) that is able to buffer info and send it whenever there's connectivity. also having larger chunks of data (but less of them in total) would make the phone bill smaller when I am roaming. because apparently there is a tax on the number of gprs logins and there is a minimum accountable session traffic size.

 

regarding USB, I don't know. I'm trying to make this project as small as possible - I hope to have it 5cm/3.8cm in rev2, while still using parts that I can manually solder myself.

using that f-ram also does not complicate the pcb routing enough to require 4 layer boards and software-wise it will take much less ram/flash then a full filesystem-based ecosystem.

 

also note I am using a USB-friendly charger chip already, the BQ24072. so even rev1's batteries are charged from a 5V source

 

those magnet wires were used to see the UART+RTS+CTS signals with a logic analyzer. since all the communication with the sim900 are AT commands that can timeout or have a reply in a large timespan, timing is an important thing to get right in this project.

 

PS.  I've seen that cheap diy satellites use that f-ram chip, so i _have_ to try it out

[username 198]

hi @@username

 

yes, you are right, if there is no gprs coverage the currently acquired data is lost in this first revision. for the second one I decided to include a tiny serial F-RAM chip from cypress (FM24V10) that is able to buffer info and send it whenever there's connectivity. also having larger chunks of data (but less of them in total) would make the phone bill smaller when I am roaming. because apparently there is a tax on the number of gprs logins and there is a minimum accountable session traffic size.

 

regarding USB, I don't know. I'm trying to make this project as small as possible - I hope to have it 5cm/3.8cm in rev2, while still using parts that I can manually solder myself.

using that f-ram also does not complicate the pcb routing enough to require 4 layer boards and software-wise it will take much less ram/flash then a full filesystem-based ecosystem.

 

also note I am using a USB-friendly charger chip already, the BQ24072. so even rev1's batteries are charged from a 5V source

 

those magnet wires were used to see the UART+RTS+CTS signals with a logic analyzer. since all the communication with the sim900 are AT commands that can timeout or have a reply in a large timespan, timing is an important thing to get right in this project.

 

PS.  I've seen that cheap diy satellites use that f-ram chip, so i _have_ to try it out

 

FRAM is neat in MCUs because you could potentially dynamically allocate your RAM vs. Flash. Now, for external storage, why bother with FRAM since its more pricey and doesn't give ya a whole lot over Flash? Is it to avoid having to buffer page writes..ect? Or just simply because FRAM is kewl? XD

[petertux 40]

FRAM is neat in MCUs because you could potentially dynamically allocate your RAM vs. Flash. Now, for external storage, why bother with FRAM since its more pricey and doesn't give ya a whole lot over Flash? Is it to avoid having to buffer page writes..ect? Or just simply because FRAM is kewl? XD

 

true, it is pricey but it saves a lot of headaches. so I have to try it out.

uC flash is used to save settings.