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.

* Showing Load counts on the main screen

We have talked about distributing the load counting to the individual trackers to minimize loads on the server. It turns out there's another potential reason. Operators don't necessarily like to be tracked but do have to provide load counts at the end of the day. By providing the load count on the screen there's some mitigation.

Obviously we can only do this if someone specifies a cycle line for the tracker and we should leave the cycles blank (don't show a number or the word loads) when no cycle line exists. Cycles reported by the trackers (statistics?) are uploaded to the server. Assigning the cycle line is done through TrackManager (could be Trackwork later but I think it's unlikely).

• Remote configuration
• Telemetry statistics
• Event Logs

A small story based on the first out-of-state permanently mounted (powered) sensors. Because these sensors have very little AGTEK interaction there's a desire to control and view more about the sensors programatically.

Previous installations were battery constrained and getting to the end of the third day was sometimes a challenge. Powering the sensor allows removing some of the compromises of the battery power. One such compromise was the upload frequency and it is sometime desirable to update faster than 5 minutes. We've added features like updating whenever the cycle line is crossed but setting the upload frequency faster and remotely is another. Along those lines being able to change/fix settings upon server contact.

Configuration items we should be able to set remotely are:

• Update Frequency - And allow for a faster frequency than 5 minutes.
• Motion Timeout - Allow change of timeout, disabling entirely, sensitivity (new, how do we represent this?)
• Automatic Start - Off/On
• MJA - How to edit, in TM? Assume trigger off of vehicle and associated tracker.
• Logging?
• MJA - Part of configuration. One time checkbox, causes ST to upload. HOW? Send to email?
• MJA - Need to disable vehicles from TM. In edit vehicle. Prosed screen next.
• 

Items I can think of adding to the tracking are:

• Powered Yes/No
• Charging State
• Motion Sensor State (are we moving/Paused)
• MJA - Proposal of viewing
• 

Not being on site and having equipment moving means that figuring out why we're getting an error needs more information provided. For example we've had one scraper on Rummel SC1017 that has showed a “Paused” State on data collection while all the other equipment has been working fine. It has also had intermittent uploads where it will regularly upload and then not communicate for thirty minutes. A log of the state that is accessible remotely when it does start talking again might be helpful. There are also error codes we get on the main SimpleTrack screen that could probably be pushed further back into the interface if we could get them remotely. Reading them on screen and capturing them on site is not really practical and is better suited to be viewed here at AGTEK for problem diagnosis.

SimpleTrack started as a self-reporting G-ray replacement and evolved into a much more capable and cost-effective device than I had imagined. Over time it's acquired some additional complexity to add capability beyond being on a box on the roof and I believe we need to simplify what's there and split the functionality off into it's own application like truck tracking.

Things like load counts designed for human consumption aren't appropriate for box on the roof.

Truck tracker constraints

• Trucks are often for hire so using a box on the roof isn't optimal. You might not get it back
• The phones in trucker's pockets are of mixed operating systems. Accommodating background operations in IOS is one of the technical challenges
• Since the truck driver isn't an employee there's a need to avoid the conventional userid/password login
• Trucks carry varied loads throughout the day. Tagging the load means there's some sort of user interface required that's probably different than SimpleTrack.
• Reporting every 5 minutes is fine for on-site machinery but trucks have varying timeliness requirements. For example, knowing where a truck is in nearly real-time when approaching the job site or hot plant allows the foreman to make tactical adjustments based on his distance.