This page is a list of answers to "frequently asked questions", some of which are unasked, but deliberately included, as the answer is informative. We encourage app users to read it, and maybe print it.
Note that more documentation is available (eg INFO, and HELP). (see links to main documentation at the bottom of this page).
If you want to contact us about your app, see answer to 2nd question below.
The TrackEcho iOS app was developed by John Evershed of Project Computing in Australia. The Server side infrastructure was mostly developed by Kent Fitch of Project Computing.
If you cannot find what you need in this page or any of our pages that are linked to from this page, you can send us an email.
Our mail support user is trackechosupport
Our mail support domain is projectcomputing.com
Send your support query to user@domain
(but replace user and domain as above, of course!)
We would love to receive your feedback, suggestions and compliments.
If you are having some problem with the app, consider looking at the 2nd last screen in the settings, via the app SET tab. That screen, titled STATUS, shows data which may be useful in the email dialog with us, so we have a clearer picture of your app situation.
Initially, in late 2017, we had discussions with a group of light aircraft pilots who had approached us with an idea that since phones were now powerful computers with many sensors, perhaps there could be an app which could make phones into an effective "Flight Data Recorder lite".
We did some experiments with periodic in-flight upload of GPS and sensor and audio data, including FFT analysis of the audio. We then considered the alternative functionality of an informal "flight note" where a "responsible person" is given notice about an impending flight and its ETA etc.
The initial prototypes ("Flighty McFlightFace", then "SkyRunner") just used GPS data, and would send flight status information when the pilot requested it, direct from the phone.
Subsequent improvements simplified the pilot input, and sent emails from our server when the device uploaded a small HTTP data packet after a user button press action. Also, during a flight, small UDP data packets were automatically sent to the server with position updates from time to time, without need for user action.
At this stage some important requirements evolved:
- simple, so pilot cognitive load was low;
- data to be kept private;
- data to be persistent, so it could be a private log of recent flights;
- track map available on both device and server;
- no advertising clutter;
- no distracting push notifications;
- clarity needed with times, timezones (use intervals from start);
- should not be specific to Australian conditions;
- require as few user permissions as possible;
- very hard to accidentally start (no "pocket flights!");
- remind user if it appears that recording has been left on too long.
Then the decision was made to make the app (now renamed "TrackEcho") suitable for other users, as well as light aircraft pilots. For example cyclists, bush walkers.
So the app was generalised, update notes were allowed, logging was expanded, relevant local notifications were provided, a device map was added, with evolving track shown (and other features like saved track overlays, interactive waypoint markers).
On the server side, provision was made for nominated persons (which we call "trip observers"), who the user declares prior to starting a trip, to securely access the track data in the form of a track on a map via their web browser, and to refresh the view, to see progress in near real time.
Finally, after thousands of test trips, mainly by the app developer John Evershed (a keen cyclist, unicyclist and walker), and more feedback from the group of pilots, and their aviation connections, we have the current app, which we are proud of.
If you are a private light aircraft pilot in general aviation or amateur aviation, you should use the SET function to customise the app to use SAR data fields. Also customise it to allow an additional SMS message to be composed for you to your observers at START (telling them to be ready for STOP and START emails). You may also consider customising it to to use aviation specific distance related measures (only if your trip observers are familiar with these units!). These customisations are done simply by selecting them as options.
When preparing details of an upcoming trip, you should normally use your aircraft tail number (aircraft registration) as the TAG field, and if you regularly fly a certain aircraft, you ought to insert the tail number as a pre-set value for TAG in the SET function, to save preparation time on future flights (and so avoid typos in future).
You should make sure that your email observers understand the terms in the emailed "flight note", and that you both have an understanding of what should be done if it seems that SAR time has been exceeded without a trip STOP email being received. Depending on the observer and the circumstances, you might want to agree to use common location names for landing areas (in DEP and DEST fields) instead of ICAO codes.
Ideally, make sure that the phone is in a "good" location in the cockpit, not too hot, not too close to metal surfaces, preferably mounted (centrally), with a charging connection, and a good view of the sky. And before take-off give the device time to "find itself" if needed, preferably not inside a building. A good check is to go to the MAP function of the app and zoom in to your location blue dot - it should be in the right position, not wandering about too much and not surrounded by a large blue halo of uncertainty.
You probably already know that, unless you are travelling very fast or at a very high altitude, there is surprisingly good cell coverage in flight over areas with poor or non-existent phone reception on the ground, so there is a very good chance your observers will be able to see your full track in detail, and see it updated (in "near real time") when they refresh the map view.
Probably you will want to use the default SET function options, as it unlikely that you would want your trip observer(s) to think about whether search and rescue may be needed. If you live in a country that uses Imperial measurements (feet and miles), then you could select that option.
When preparing details of a trip, you could use you car registration as the TAG value, or maybe a short name which describes the purpose of the trip, or even a quirky name (remembering that the TAG cannot exceed 12 characters and cannot contain spaces).
While you could probably keep the phone (screen off) in your pocket, it would be better to keep it in a central position inside the vehicle - preferably in a special holder, and connected to a charging outlet. Naturally you should respect any legal requirements for use of phones in a motor vehicle.
Be aware that GPS will work poorly in tunnels, and phone reception (cellular data) may not be so good on some back roads but is usually quite good on main roads.
Decide whether you want the SAR functionality. This is easy to change, even if you are already interacting with the PREP screen, by simply tapping the SET tab, and navigating to the OPTIONS screen and tapping SIMPLE or SAR, as needed, then going back to PREP, by tapping the TRACK tab. Mostly you would not want the SAR option, but if you do use it, make sure your observers understand what you want them to do if your trip exceeds its maximum duration.
When preparing details of a trip, the TAG could be something as simple as HIKE or BIKE, or something which indicates the nature of the trip purpose, like EXPLORE or PICNIC.
You might want to carry the phone in a bumbag or top backpack pocket. For a very long trip, you could consider an external battery for charging.
While walking on a trip, you may want to tap the MAP tab which will show you your track in yellow, and can give information when you tap your location icon, or tap any map "pins" that you have previously placed to get extra information, or you can add a new pin (by a long press) or modify an existing pin (eg rename it or add a the current time to its metadata). If you set pin location to 'x' it will move to your current location. If you want, you can overlay the track of an old trip (in orange) on the map, to compare with the current evolving trip.
To have a good experience when viewing the map when you are away from a settled (urban) area, you should view the location of your proposed trip BEFORE you start, when you have good cellular data connectivity, and zoom in. This will ensure that the map pages are cached, and so available later on the actual trip, even if there is then NO cellular data availability.
Remember that any UPDATE emails will only reach your observer when you reach a spot of reasonable connectivity - so if you press the button in a "dead spot" the email will actually only get sent after you have moved into a zone of connectivity. So it is worth while remembering that mobile communication can be patchy in isolated rural areas, but is often good on hills. And it may be worth checking the indicated signal strength on your phone.
Also, do NOT force quit the app unless you have finished a trip AND subsequently reached an area with a workable cell data connection.
This is very easy, and probably quite common. You just make yourself the only observer. You can still define others as potential observers, in the SET tab (usually in initial customisation), but on any trip that you are preparing (on the OBSERVERS preparation screen), just ensure that only your own email is ticked. In general you should only use other observers if it could be good for rescue purposes, where someone trustworthy can be given access to your last known whereabouts, or if a friend was very interested in your trip.
In any case, the app gives you the ability to see your position on the device map as you proceed, and use other map features that can assist way finding, plus an on-device stored log and track that can be reviewed later, plus waiting in your inbox will be the START, STOP and possible UPDATE emails, which each have a link to the trip map, which you may wish to later view on a larger screen device. Even weeks or months later you could send someone else that link because you are proposing a repeat of your trip, with them (or give them the GPX file).
Every trip recorded by the app needs at least one observer, but that observer can just be you, so nobody else gets the trip emails or map link data. Also, even if you are part way through a trip with observer(s) other than yourself, you can press the PAUSE button to stop GPS location updates until you later press the RESUME button - this means that the observer(s) cannot see the exact details of that part of the track in the time interval between the two button presses.
NO! The app has the potential to improve your safety, by giving your trip observers the possibility of recognising non-arrival and other problems, so they may be able to take action to help if needed or notify oficial safety authorities. BUT the TrackEcho app does NOT somehow make your phone into a safety device. The phone itself is fragile, with limited battery life, GPS sensitivity and accuracy, software reliability, water, thermal and impact resistance. It is also dependent on cell phone tower availability and does not have the capacity to activate on impact, or broadcast to satellites. If you want to be safer, consider purchasing an EPIRB or personal locator beacon.
Although the app has a button labelled PANIC on the recording screen, this simply increases the frequency of UDP position updates to the server, and generates a post to the server which will generate an email to your observer(s). All this will only be helpful IF there is some network connectivity AND your observer checks their emails!
No. The screen must, of course, be initially visible, and the app active in foreground to prepare your trip plan (TAG, DEP, DEST etc), but after you have pressed START, you can turn off the screen and/or use the app switcher to actively use some other app for the duration of your recorded trip. (but don't forget to return to the app at your trip conclusion and press STOP!).
Note that if you use the app switcher and then use some other highly memory intensive apps, there is a small chance that iOS will have to terminate our app to release memory. If this happens, our app will probably set up a notification so you know and if your trip cannot be resumed, you may need to contact your observer.
If it is vital that your observer needs a regularly updated track to view, it may be best to simply turn off the screen, or at least avoid memory hungry activities (like video?), depending on the memory available on your phone.
The full track, and trip plan data, is stored on your phone, accessible to you (and deletable if you wish). A compressed track and most plan data (TAG, DEP, DEST etc) is also stored on a server run by Project Computing. This server is physically located in Germany.
Trip data is securely stored on our server, and not shared with anyone except you and your designated trip observers. This trip data is needed so your observers can use the unique trip link keys (given in trip emails generated on your behalf) to view a trip map.
If you wish (maybe you are very privacy conscious and don't fully trust your trip observers), you can at any time (except while actually on a trip) delete ALL your trip location history data, which has the side effect that all links contained in past trips will fail. After the purge operation, the app will still function correctly if you undertake new trips, and trip location data which is actually on your device (rather than the server) will remain. This means you can still view your trip log history and layer an old trip onto the map to view it. Of course you can also delete these log entries and trip tracks on the device if you like, but these are fully private and protected by Apple iOS on your device, so you would probably only do that if you wanted to tidy up very old trip data.
To delete all server based trip data, go to the SET tab, and tap CUSTOMISE, then keep tapping 'Next' until you reach a screen titled SPECIAL. Do this when you have a good cellular connection. Then tap the PURGE button, and you will be shown a screen with a CONFIRM PURGE button. This button has a red border which means it needs the "dit-daah" press to confirm. When pressed you will see a spinner which will stop when the server confirms receipt of your purge request. Unless there was a problem, you will then see the initial SET page again.
You will note that the trip emails (at START, STOP, and any UPDATE button presses) contain two links: one to the map of the track (via Open Street Maps on the web page), and one to a gpx file also representing the track, in a format (GPX) designed specifically for exporting tracks and importing into another app or system.
Yes, you can import a GPX file if the standard system email or browser has a message or page containing a link to a suitable GPX file. You do a long press on the link and, as the app is registered as able to handle such files, you will be able to download and import the set of points into a pseudo track which you can overlay onto the map function, just the same as you can overlay one of your own actual tracks.
On your device, as long as you wish. You can delete selected tracks or log entries on the device via standard functionality in the app. You can also delete the app completely (which also automatically deletes the app data on the device), which can be handy if you are selling the phone or giving it to another family member. It is possible (but very unlikely) that a phone issue unrelated to our app or sometimes even an operating system upgrade could result in lost app data (for our app and other apps) - you may need to use iCloud backup or other means to get back the app data (ie the locally stored trip logs on the device). But normally the phone data is safe and persistent. As for data on the server, there is no absolute guarantee that the trip data stored in the server database will be there forever, but there is plenty of server capacity and we will try to keep it for you for years. However, if there has been no activity from you for 12 months, your data may be purged by us. Also there is a function in the app so you can delete all your server trip data if you wish.
No it is not. And we will not sell your data.
Although your trip data can be seen on our web site if you know the key (which of course your observer does for those trips where you designated them as observer, from the link in the generated trip emails), it is virtually impossible to guess your trip url, as there are more than 5 trillion possibilities for the attacker to try to guess. If you are a highly prized target of the spy agencies of a wealthy super power with backdoors into the internet infrastructure and a team of agents probing your communications, and don't want them to know any trip detail, then don't buy our app (in fact, don't use the internet!)
Sorry, not at the moment. It is written in swift, and the code is backed up to a GitHub repository with private access.
No, not yet.
No, we respect your privacy, we cannot examine your contacts. We cannot send emails or texts without your explicit involvement. This is because we do not request your permission to access the contacts list, as we believe most people would not want this. Consequently, if you enable the "SMS on START" option, it won't happen transparently - we can only pre-compose a message to your observer for you to inspect and send, via the SMS app (which will appear as needed "on top of" our app), but this works well. If you look at privacy settings you will see that we will NOT have requested access to your contacts.
Everybody has an email acount, emails can easily be viewed on other devices, emails can contain more content, emails can be more easily viewed and arranged into folders. Also it is easier to manage sending emails from the server. However, not all your trip observers may be scrupulous about checking their emails, so that is why we do actually offer to allow you to optionally request that the app generates a "hi, trip starting, check email" style of SMS, for you to send when a trip STARTs (in addition to the email). SMS observer START prompts are a customisation option which you can enable in the last screen of the SET function (default is no SMS).
Your observers should know what you expect them to do. At the minimum they should be able to recognise your server generated emails, and at least be aware that there is useful information in them if for some reason you don't return from your trip. If using our app as an aviation "flight note", ensure that your observers know the way to interpret the time formats, and what you are putting in the TAG field (usually your aircraft registration), and what SAR time is, and how to contact relevant authorities if needed. You should probably arrange to do a dummy trip (like a drive to the shops) using the app with them as an observer, then check the emails with them, explaining them and showing them the map link. By the way, there is a slight chance (depending on their email provider and emailing history) that the trip emails are interpreted as spam, so if that was the case, they should be flagged as being valid. They can also, in some cases, be labelled as 'Promotions' in which case usually remove that label.
Well actually it is FREE for a limited number of trips, which should make it easy for you to evaluate it, and then for a small cost, purchase a consumable "recharge pack" of trip entitlements which should last you a long time, and can be repurchased as needed, if you are a really heavy long term user.
You are getting an app that took an awful lot of highly skilled development and testing, which does NOT bother you with advertising of any kind, and which provides a carefully selected set of features to be highly functional for pilots, walkers, cyclists etc (not, to our knowledge, found in any other app). Moreover, we provide server processing, emailing, map generation and storage. And we don't even try to make you upgrade the app or have functions disappear after a few months, or present or require subscriptions. Help us help others like you (and us) who want to record and log their adventures, and have that little extra security of being able to nominate observers for their trips.
You add extra trip credits by going to the SET tab and the first customization screen shows how many credits are available, and allows you to buy more if needed, as an App Store In-App Purchase.
No, there are none at all. We want pure, clean functionality!
And we don't nag you for app reviews, either.
While GPS will use a certain amount of battery, many other things unrelated to TrackEcho contribute to battery use: screen on, phone calls, background app refreshes, wifi or bluetooth on when not needed, etc.
If you want to increase battery life, you could go to battery settings and put the device into low power mode (this will also disable background app refresh, but TrackEcho does not use that facility). You could also disable wifi and bluetooth for the duration of your trip (via settings, NOT via control center, which only partially disables them). You should also turn off the screen by tapping the physical screen lock on/off button (usually on the side of the phone). And you could also NOT enable the 'Raise to Wake' option in the display settings.
Note that Apple does not recommend that you use use low power mode unless absolutely neccessary, and it could even impact GPS timeliness. Also Apple suggest leaving wifi on to get better location accuracy when indoors or in "urban canyons", but if you are in a real (rural) canyon, there would be NO wifi nearby, so it may as well be switched off.
During a recorded trip, you could consider temporarily stopping our use of GPS if you stop in one location for a while (such as a lunch break), by pressing the PAUSE button (and not forgetting later to press the RESUME button). However if some OTHER app is actively using GPS, this will have no real battery saving effect. You can also slightly reduce battery use by putting the device into Airplane Mode for a while, but NOTE that this means your observers will not ever get any of the periodic "near real time" position updates during the time when you are in Airplane Mode (!), and any emails to observers via UPDATE or STOP buttons will be delayed until Airplane Mode is switched off again.
By the way, if you had set yourself as the only observer of a trip, it might be reasonable to put the phone into Airplane Mode a couple of minutes after pressing START, then disable Airplane Mode at the end of the trip and press STOP. Although the track would not "evolve on the emailed map link in near real time", you are probably not looking at the server map en-route (as you have the device map), so you don't care. However you will be happy to know that when the STOP button takes effect (ie when cell data becomes available some time after you pressing that button), the server will have a track on the linked map, because the final connection with our server sends a specially reduced version of the track (100 key points).
But if you want a rich track, which can be seen changing by your observers, and with a full set of points in the final server map, just turn off some stuff you don't need, maybe use low power mode, ensure mobile data is ON, and physically turn off the screen.
A final note - as long as GPS is on, the map you see on the phone (as opposed to the server map) will always have the FULL point detail, as you can see by going to the MAP tab function and viewing it. (but here is a tip: view the map of your expected trip locations in that MAP function before you start the trip, so map data is cached, rather than being downloaded en-route. This could be done at home, and you can expect that iOS will keep those Apple Map details cached for weeks).
If there is absolutely no data connection for the whole trip, see the answer to the app working without a sim card. The app will work in very poor connection situations though. The START, UPDATE, STOP button functions deliver an email to your observer. If connectivity is patchy, the server connections which allow the emails to be generated may be delayed, but they will get through if there is a moment of reasonable connectivity at some later stage in the trip. The regular UDP position "recent history" updates will be sent if connectivity becomes available, but are not re-sent if they are lost "in transit" to the server. So on a trip with poor and intermittent cellular connectivity, your observer will see a poorer representation of your track and may not be able to see the "near real time" latest position. However when START email is received (as it will as soon as you get some reasonable connectivity for a short while after the event) the observer will always see what your trip intent was, and even in the worst case, they will see a good track of your trip whenever the STOP email gets to them, regardless of the communication issues en-route.
Well yes, but hardly ideal. For example, I took one of our test phones, without a sim card, and also disabled wifi. Then prepared a simple walk, pressed START, after a while pressed UPDATE, finally got back and pressed STOP (and OK to dismiss the trip summary). By the way, TrackEcho showed an alert at the start, warning that network data was needed. When STOP was pressed, the trip was over, without any possibility of connecting to a server. Clearly the observer has no emails in their inbox from my trip at that time. Then I enabled wifi on the phone and moved indoors to get a wifi connection. In a very short time the observer's email box contained 3 emails (one for START, one for UPDATE and one for STOP). Each email contained a link to the server generated map of the complete track. And of course the phone itself always had, right from the START, a visible yellow track on the MAP screen, and the LOG entry was there. So yes it works, but you EVENTUALLY need a conection of some sort before you start another trip or force quit the app, and without ANY connectivity the observer cannot get "near real time" updates.
The app is available via the App Store for iPhone ONLY - NOT yet for iPad!
In developer-only testing, the app works well on an iPad, although it is primarily designed for a smaller screen (for example it also works well on an iphone 5s). Of course the map view would be easier on a larger screen, and you would rarely need to scroll.
However an iPad would HAVE to be 'Wi-Fi+Cellular", because 'Wi-Fi only' models usually have NO GPS hardware!.
Even if it was available for iPad we expect most of you would use it on your iPhone.
Nearly all phone GPS is quite accurate (and greater accuracy and availability is gotten because commonly, location is not simply derived from GPS satellites, but also Glonass and Galileo and soon Beidou). For the purpose of trip tracking, a 10 meter error is quite acceptable (a reported error of 5m or less is common). However, if the device GPS is freshly started, it takes some time to discover the needed satellites, especially if it is a while since last used and even more if the location has changed significantly since last use. Also if you start in a poor location (shielded by cliffs or in a dense forest of trees or inside a concrete building, for example) it is even harder to get a good initial position. Finally, it is worth remembering that there can be certain (varying) "unlucky" dates and times and locations where the satellite positions in the sky are not good for accuracy.
In an urban environment, it may be useful (especially at GPS start up), to turn on Wi-Fi, which enables AGPS (assisted GPS). But if you have a relatively clear view of the sky, or are in a rural area, it is better to disable Wi-Fi.
Our app tries to help, by ignoring location updates with high reported errors, and starting the GPS in the PREP time before you actually press START on the trip (if you take too long before pressing START, it will stop checking GPS, warning you with an alert, until you actually press START, then GPS will be turned on again).
Sometimes you can notice the location errors when looking at the track on the map, but it is usually pretty good if the GPS had time to "warm up" and there is a reasonable "view" of the sky. If you are walking, you might notice sometimes the maximum speed seen in the trip is faster than you thought you could run - don't get too excited about your athletic potential, as it almost certainly relates to a higher than usual GPS error near the start of the trip.
The total distance of a trip, shown in your log, is algorithmically derived from the GPS location points, accounting for speed, error and track curvature. It is quite accurate.
The final stored tracks, in your device and server trip history databases, are algorithmically "simplified" to remove superfluous GPS points, but the track shown on the device (via the MAP tab) contains the full set of points.
The GPS, as you would expect, is active for the duration of your trip, from START to STOP. It is not used after STOP. When you prepare a trip (ie enter TAG, DEP, DEST, OBSERVERS) the GPS is started up so it can "warm up" and "find itself" in anticipation of you soon pressing START, but this is subject to a timeout, so if if you PREP well in advance of START, the GPS will be soon turned off, then turned on again when you actually START. Of course when we say it is "off" or "on" we just mean that our app is not using the device's GPS service, but other apps may well be using GPS. By the way, it is good to start outdoors rather than indoors, to get more accuracy in the start of your track. If you use the PAUSE button during a trip, GPS will then stop being used, until you press the RESUME button.
If you use the bottom tab to navigate to our MAP function, and view the map, this will use GPS of course, while the map is actively viewed. However there is no tracking happening unless you START a trip.
NO, GPS accuracy is poor, the base map probably cuts out at latitude 85S, Your device may not work well in the cold, you are unlikely to get a cellular data connection, screen tap gestures will be difficult, distance calculations can fail.
It is unneccessary, distracts from the main purpose, uses more computing power, and is subject to error. It is a fun programming exercise (which we have done for a watch app in the past) to detect steps, but this job is better done by dedicated fitness devices. And calorie consumption is pretty much a guess.
The app can be helpful for planning a trip, although it is primarily for track recording. You can use the MAP function to view and zoom into the area where you are considering travelling, and maybe long press on a map position to make a long lived "map pin" with name, as a waypoint. On the actual trip, you can go to the MAP function, tap on one of your waypoints, then tap again on the info icon that appears, to get the direction and distance from where you are, to that waypoint. You can also easily repeat a trip you have previously made by using another map function to overlay its track on the map. Even more, if you generate a gpx track in another app or have a link to a gpx track, you can import that track and use it similarly as a map overlay.
Most users of the app will use it for recording tracks which will NOT be on main roads. The app does NOT give routing directions (like you might get on Apple Maps or Google Maps when driving on streets or highways) because you are not confined to standard roads. However, before you start a trip, you can add some waypoints to help find your way. Then if you open the MAP function (which is still available during a trip), you can see your track evolving and see how far it is to the next waypoint. And if you tap a waypoint and then tap the info icon that appears, you can see the compass direction from your current location to that waypoint, as well as the exact straight line distance to that waypoint.
While you are on a trip, and viewing the map, you can also tap the map icon (blue circle) which represents your current location. Then tap the green circled 'i' which appears, to get more information. You will be shown the battery level, elevation, GPS accuracy, time, elapsed trip time, and calculated distance travelled since START.
You should note that the map can be viewed in 3 different modes. The modes are indicated by the shape of the location arrow in the bottom bar of the map (just above our app TAB bar). You can switch between these modes by tapping the location arrow. In the 1st ("default") mode, the map can be panned and zoomed and the blue dot representing the current location can go go off screen (and if you use a rotate gesture on the map, another compass arrow at the top will indicate map North). In the 2nd ("follow") mode, it is very similar, but as you move, the blue dot will stay in the center of the screen. In the 3rd ("follow with heading") mode, the blue dot will stay in the center of the screen, and the map will be oriented so if you hold it in front of you, the top of the map should be where you are looking in reality, and if you look in the direction of the little compass icon (N arrow) you will be looking in the true North direction in reality. Note that in modes 2 and 3, if you pan, the mode will switch back to default. Also in mode 3, a rotation gesture will switch the mode back to mode 2.
If you are trying to find your way on the ground, then the "follow with heading" map mode can be very useful.
That's just life in the web - HTML can be thought of as "hints" to the browser. In particular, mobile devices have to act a little differently with respect to zooming and panning due to the small screen size, and the fact that mobile devices rely heavily on touch events as they do not have a mouse. The map that the observer sees from your trip email links, can be successfully viewed and interacted with on, any device. However, of course it can often be easier to view on a larger screened device or PC.
There are several universal problems with times. Obviously you could easily be in a different time zone to your observer, and also your trip could cross time zones. We try to use time intervals from a known start time as much as possible to simplify things. We also give the start imes in a full format with the standard timezone indicated for your location, but on every email we also indicate the time sent in UTC time (known as "Zulu time" in aviation circles). If the SAR option is set in customisation, the email will give the SAR time in both formats (pilot local, and UTC) in the observer's email, as SAR time is VERY important! UTC time is also embedded in the track map.
Metric units are the defaults, but nevertheless there is a customisation option to use imperial or aviation units, if the user (and observer) prefer these units. However some quantities, like GPS error, are always shown in metric units. Also, on the map of the track (and the generated gpx file of the track), because it may copied or viewed later, the map uses metric altitude and speed (and degrees true, for course). Units are always indicated along with the values to avoid any confusion.
Because we want to be frugal with network resources (which helps reliable packet delivery), at each time the server is sent a UDP location update, it includes the battery state, speed and course for that current point, but it also includes some previous points, for which there is just a 4D location (latitude, longitude, altitude, time). So when you view the web map, and click on a point, most of the points are of that "previous" kind, so they won't show the extra data at the top of the map.
The in-app help (via the INFO tab function) is designed to be concise and helpful for when you are actually using the app. The website help (pages reached by navigating to 'More' in the in-app help, and tapping a link) is much more verbose, but may be more recently updated. It is worth a read, when you have time. Note that we have tried to make the app usage as easy as possible by keeping it as simple as possible, and by including short prompts and explanations in most screens in text boxes with light blue background. But pretty soon you will not even need that help.
To add an observer, they must be in your contacts list on the device, with a name, phone number and email. You can easily add contacts (including yourself) by using the standard Contacts app on your device. Usually your contacts will be good, but sometimes you may need to add an email address to an existing contact. If your device does not have a sim card or you just don't use it for calls and messages (eg an iPad, perhaps), you can still add contacts. Of course, if the device cannot access the internet except with wifi, then it is far from ideal for "near real time track recording" outdoors.
It is important to put your "best" email address as your identifier when you register immediately after app purchase. It cannot be subsequently changed without losing your device data.
Yes. There is an UPDATE button which can be pressed while on a trip, which will pop up a keypad so you can type a short message (of up to 240 characters) which will be then sent to your observer(s) when you tap 'Done' on the keypad.
We actually thought about this, but it would be rarely used, tedious to enter on a small device, would increase the data packet size and storage costs, and is a potential privacy issue. If you REALLY wanted to do this with the existing app, you could press UPDATE, and type the names into the text box so the observer will see it in the associated email.
Quite often we expect users to use locations which are not on normal lists, or to use a shortened local name, or a coffee shop. So the "helpful" list of nearby places would be useless clutter. It would also increase the size and complexity of the app, and probably make it slower to prepare a trip.
We value consistency of the interface, so prefer alphabetical order which everybody can understand. You will probably use "muscle memory" to easily find often used locations in the list of suggestions. Also remember that it is you who create the list (in the SET function), and so it will be a short list of frequently used locations anyway.
We allow you to set locations in advance, and you are the best judge of what is going to be useful in future. Remembering every possibly miss-spelled location probably means you will want to delete them soon. And anyway, it is easy to enter a location at preparation time, and having a standard (personalised by you) set of stored custom locations, enables a simple, consistent, predictable interface.
Well, the observer will receive a special 'OVERDUE' email after the nominated SAR time has been exceeded by a margin (assuming you have previously customised the app in the SET function to use the SAR option).
Note that you MUST ensure that you press STOP when your trip ends, to avoid false alarms. You will receive a local notification after your expected trip time is passed, and also after your SAR time is passed, to help you remember, even if you temporarily switched to another app.
If we also sent the observer a push notification, that would require something like a free companion app that your potential observers would need to be willing to install in advance. That is not very practical and would limit your choice of observers.
Allowable intervals are to the nearest 5 minutes. EET must be less than END. END must be less than SAR. SAR must be less than 24 hours.
If you wanted to use the app on multi-day trips it would be best to break it, on the app, into several shorter trips.
These time intervals are only used if you have customised the app to use the SAR option (rather than the 'Simple' option).
EET is the estimated elapsed time of your trip, and the expected time of arrival can be deduced by adding it to the time at which you pressed START.
END is short for endurance. For a light aircraft pilot, this would be the maximum possible flying time with the given load, wind, speed, and flight trajectory. For something like cycling it is not so useful, but think of it as a time when your observer should start to worry about you.
SAR is "Search And Rescue" time. When your trip has taken this long or more after START, your observer(s) should be VERY worried if they have not received your STOP email, especially if you have briefed them about the importance and they can assume that mobile reception would be reasonable at the STOP location. Note that after a while an OVERDUE email will be sent to your observers, so if they get this but not the STOP email they can be pretty sure that you have a problem (or have missplaced your phone or forgotten). They should look at the map link to try to see where you went, and try to contact you.
During preparation (ie after pressing PREP and when you are entering DEP, DEST etc) the GPS is in "warm up" mode. Typically you will soon press START to begin the trip recording, but if you don't, that is not a problem, but the GPS will be turned off again, and you will get a vibration alert and a popup reminder. Incidentally, any time you view the MAP function, you will also effectively be warming up the GPS, even if not anticipating a trip. Note that any GPS warmup is NOT part of the recorded trip. Regardless of any START delay, GPS will always be turned on at START.
This is bad (especially if you have set the SAR option), and probably worrying for your observers. It should be hard to forget (if you have your phone nearby), as we give local notifications to help you remember. The first thing you should do, if you have forgotten to press STOP in time, is to press STOP anyway. But if you have "force quit" the app (a very silly thing to do in an active trip!) you won't be able to do this when you get the local notification. In any case, try any way you can to contact the observers to reassure them, and maybe avoid the embarrassment and expense of a search which was never needed.
Of course, a trip recording app needs to access location services for the duration of a trip. Also, to help you from accidentally using GPS too much, we need to send a "local notification" as a reminder prompt if you seem to have forgotten to press STOP at the end of your trip. That is all - two key permissions.
When the app first wants to listen to GPS (on your first trip after first launch of the app), the device operating system will show an alert (Allow "TrackEcho" to access your location while you are using the app?). You need to then tap "Allow while Using App".
Similarly, on your first trip, when the app needs to schedule a local notification, the device will show an alert ("TrackEcho" Would Like to Send You Notifications). You need to tap "Allow".
By the way, you won't be bothered by ANY notifications if your trips are not delayed for too long and you remember to press STOP when a trip ends.
We really don't want you to accidentally do a "pocket tap" to START a phantom trip or accidentally prematurely PAUSE or STOP a valid trip. Our testing shows that our special "dit-daah" press is easy to do on purpose, but virtually impossible to do accidentally. So you won't have to give any embarrassed explanations to your puzzled or worried trip observers.
The 'dit-daah' press is reserved for trip recording (and data purging), and is like a double tap, except you keep your finger held down on the 2nd tap (until you see a alert pop up). The first tap is quick.
By the way, as a general note about tapping and pressing (NOT just our 'special press'), remember that if you are viewing screen content that can be scrolled (such as items in a table that may not fit in the screen space) you should be careful to tap without also moving your finger, as the system may interpret that as a scroll, instead).
Only buttons associated with a server based operation are highlighted this way. This includes STOP, START and UPDATE trip recording. It also includes an optional PURGE of your server based trip data.
These highlighted buttons (and only these buttons) need the special 'dit-daah' press. and is like a double tap, except you keep your finger held down on the 2nd tap (until you see a alert pop up). The first tap is quick.
You will encounter editable lists in the SET, LOG and even MAP functions.
The item deletion is usually done the standard system way, which involves tapping a small red circle on the left side of the screen containing a "-" sign. Because of its size and location you may need to tap accurately. Some screen protectors can make this a little bit more difficult, but it is not normally a problem. In some cases, you tap a 'Delete' button which either deletes the current item or (if viewing a list), it adds one of those red circles onto every item, so you can then tap any to delete.
These are all optional buttons that you can press (with the dit-daah press) while recording a trip. But on most trips you will only use STOP and START.
The UPDATE button gives you a way to easily compose a short message that will be included in an email (along with time and location etc) that will be generated at the server, just like with the START button, but on mid-trip. A typical use of this would be to advise a change of destination, or a delay.
The PAUSE button can save battery or hide locations for part of the trip, until RESUME is pressed. The PANIC button merely increases the rate of automatic server location update attempts until RELAX is pressed. PAUSE, RESUME, PANIC and RELAX generate emails to the observer from the server (with an automatic very brief text explanation as a trip status update included in the email body. See also other documentation about these buttons.
Note that the RESUME and RELAX buttons are simply the PAUSE and PANIC buttons with different labels, so you won't see them unless you need them. And if you can see one of these two buttons, all the other buttons will be greyed out until you eventually press the enabled button, to return to normal recording state.
We want this app to be as simple to use as possible, and to be reliable. There is certainly no need for emojis, and also locations are forced to upper case for consistency and obvious ordering. (A location could be 'YSCB, 'SHAG ROCK' or '-41.139,146.823'). Certain "dangerous" characters that can cause issues as the data is encoded and passed to the storage server and web server are avoided as a precaution. The TAG field has added restrictions - no spaces (but hyphens allowed) and no more than 12 characters, so it can be a succinct trip identifier.
If you tap on the position 'arrow' symbol when using the MAP tab, a small magnetic compass icon will appear to help you correlate the direction that the device is facing with North. Sometimes (not often), iOS will then ask you to calibrate the device compass (by tilting the screen as shown).
It is possible to view an associated web page from INFO or LOG tabs. If the Safari browser needs to be launched or the network connectivity is poor, an external web page can take a few seconds to load.