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 and dim the screen after a specified amount of time (under settings) 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).

Here's the current functions I can imagine under settings

• Upload frequency setting in minutes (default 10 minutes)
• Motion Sensor timeout (default 3 minutes?)
• Motion Sensor enable/disable (default enabled)
• Test Connection function

AGTEK Access (cloud) option displays the files to uploaded/Sent screen

• Tracker Name - The friendly name given to the Tracker at first login. Pressing this name should allow editing of the name, show the unique unfriendly name used by the server and probably should contain any credentials we need to change authentication.
• Status - No GPS, Collecting, Uploading. This should probably flash to show it's working. Something simple to show it's working.
• Started - The last time the tracker was started - Does it ever stop? Should it?
• Points Collected - The total number of points collected since the program was started
• Points Uploaded - The number of points uploaded
• Stopped Time - The amount of time where the motion sensor has stopped the collection of points.

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.

Story 2 is small refinements after having run the first version for months.The additions are:

• Add battery percentage remaining reporting (hourly) to server upload statistics for remote monitoring
• The capability of adding a vehicle name on the tracker itself. I have it at the top of the screen right now and think that a text box with autocomplete might be the best method of entry. Ideally the autocomplete could be populated by machines currently available on the server and display as the user types/taps in the name. Putting in a new name would add that vehicle to the list.
• The capability to set the project assigned. Setting this is not a requirement of the user and ideally programs that can set this would override this setting. (Am I creating something too complex here?). Ideally the tracker would never prompt for project list but instead would attempt to login to update the list only if selected on the tracker.

The layout below is a suggestion. I made the program icon consistent and moved the AGTEK logo (which was a good idea) down below. I didn't put the project next to the Alias/Name because I was concerned about accidentally picking the wrong one. I can be talked out of that though.

* Phone persistence. I'm not sure this is the correct wording but some apps like Facebook, Yahoo, etc. are always running in the background. We may have to add a stop tracking somewhere but I'd like the tracking to happen when the phone is turned on and moving. The motion sensor will hopefully limit the amount of track points sent while charging or sitting still.

This story is a combination of SimpleTrack and the Trackserver and SimpleTrack may even be spun off as a differently named app variation to distinguish between AGTEK distributed and Store distributed.

SimpleTrack is great if you have employees but in some cases like trucks, the operators are independents. For the most part SimpleTrack functions correctly for even this but because a driver doesn't always work for the company and may even work for several companies there's an idea of creating an App for the Google Play and Itunes store.

The current implementation uses our standard login/password implementation but with these remote/non employee it would be nice to have a way of giving that user a code that would serve as login/password and potentially route the tracks to the correct project as well. The difficulty is in coming up with a reasonable in length/security/ and uniqueness since this potentially could originate from any company on the server.