This snappy name is more about what it does than anything else. We'll have to to let marketing run with the sales name.

Traditionally we've used gps dataloggers like the G-Ray 2 and + as failsafe manual methods to collect machine tracks. The benefits are that they're relatively cheap, reliable, and unobtrusive. The downside is they require tending to download data, that download is slow, they have no realtime capability and they're increasingly being squeezed out of the marketplace by smartphones, dedicated exercise devices (fitbit,etc) and other multipurpose devices. We're investigating replacements but it seems like that niche has run it's natural course. The question comes down to a cost-effective replacement that at least gets us the equivalent and maybe better.

The answer today seems to be inexpensive android cellphones. A brand new Motorola E is contract free at $129 and contains all the sensors we need for tracking even if just wi-fi enabled. Adding a Sim and about $10 or less per month makes it an almost real-time tracker. Adding an otterbox with magnets creates a more capable tracking system than a G-Ray that we can modify for less than a $40 differential.

I only have one story right now for this app because it's relatively simple and I can't see having stages of implentation

I don't think we have any new coding tasks here but typically putting new projects together out of different code results in some re-architecting and improvements. The pieces I see are:

Requires a Login so we now where the tracks should be uploaded to. The question is whether we have a conventional user login or do something custom for trackers. Obviously we have to send the data to the appropriate company but the keying is less clear. Do we key this? (Certainly for prototypes). Since the data only goes to our server do we need to key it? Do we just have one customer upload account that all the trackers use?

* GPS tracking - collecting points for upload as tracks to the server. We don't need to represent these graphically in the app. A simple moving point count for collection confirmation will be sufficient

• Motion sensing - We need to use the built in g-sensor to turn off GPS tracking after a specified amount of time and restart tracking upon movement. This is to minimize useless points and save battery. Battery usage is a major consideration of this program. A goal should be to run for 12.5 hours on a new phone without charge. The rational behind it is that batteries age and we want to still be running 10 hours after a year.
• Access Server track uploads and the deferred uploader. Connectivity is not assured with this device.
• Compass Offset - Compensating for mounting direction variations.
• Persistence - Ideally this program would load on boot and stay running. The devices this program is intended for are probably the only program that's run (that's not a google service).

The customer wants to track a particular piece of equipment. He may just have on tracker but usually will have more. He turns on the cell phone (program too?) and places it on the vehicle (case, on dash, etc) but won't take much care in orientation. The program begins collecting points and uploading to the server if it has connectivity.

With all of these tracking devices my best guess is the customer should configure them to run from a single user account. The benefit is that all access points are automatically added to all devices with PINS so adding additional access points should confer automatic connections.