Event_Logger

for TomTom

 

 

 

News – June 28, 2013

 

MrGPS is out!

 

A Symbian version of Event_Logger, renamed MrGPS, come out to Ovi store. It’s a very new application for Nokia mobile phones. Through MrGPS, you can exploit all features of Event_Logger plus many more.

 

While Event_Logger for TomTom is a tracking assistant targeted to vehicles, MrGPS allows personal GPS logging and real time statistics for your outdoor sporting activities. Running on a cheap, small and lightweight Symbian Nokia phone, it assists you in challenging activities where you might not find appropriate to bring with you a large and expensive smartphone device.

 

Rather than an Event_Logger porting, MrGPS is a complete and optimized Symbian C++ rewrite; this resulted into a lightweight and high performing native application which supports Nokia Belle smartphones and can also run on old legacy Nokia devices, easily coexisting with other programs on the same mobile phone. For instance, you can effectively run MrGPS and your favourite mapping or navigation application on the same legacy mobile device, exploiting also all advanced Nokia phone capabilities, like A-GPS (Assisted GPS), long battery life, removable battery, camera, accelerometer, magnetometer, phone calls, messages, data publishing (automatic track upload to your personal cloud), and data integration (WiFi, 3G, etc.) including Apps (and notice that these features are not all available on stand-alone navigation and tracking handhelds).

 

With MrGPS you get a high-performance, compact, robust, comprehensive application which provides voice support, 60+ statistical data and 240+ configuration settings. Speech capabilities allow hands-free assistance while you are fully focused in sport activities requiring physical and mental concentration in optimal performance.

 

MrGPS is the ultimate GPS tracking and real time statistics tool for sport professionals.

 

Check Ovi Store to download it: http://store.ovi.com/content/359009

 

Check http://web.tiscali.it/macri/mrgps/ for its user manual.

 

Users interested in MrGPS and having already donated for Event_Logger can drop me an email including phone IMEI (call phone number *#06# on your Symbian device).

 

 

 

Event_Logger Version 9.1 - RELEASED

 

 

NEW!!! Click this LINK to browse the NEW presentation of Event_Logger v9.1. NEW!!!

 

 

 

May 8, 2010

 

Added new presentation of Event_Logger 9.1

 

 

 

February 28, 2010

 

Event_Logger 9.0 offers a vast improvement over the previous releases and provides end-to-end management of itineraries from planning to reporting, fully integrated with Google Maps and TomTom.

 

The relevant effort to upgrade Event_Logger took over almost one year and produced a new framework including many additions and upgrades.

Event_Logger v9 now introduces a Web Application called GmapToItn, which allows designing an itinerary through Google Maps, with no restrictions. Not only Google waypoints are fully managed, but also draggable directions and points of interest (POI) are allowed. After designing the whole itinerary with the standard Google Maps web application, including multiple subsequent destinations and dragged points on the paths to customize each route, the TomTom Itinerary data is simply produced by selecting a simple bookmark: a panel appears presenting the ITN report ready to be copied to a file on the TomTom device; besides, data can be further customized through an easy user interface providing appropriate configuration switches. POIs produced by Google local searches are presented as multiple destinations and every point or destination includes the related description. GmapToItn is compatible with virtually any Internet browser and does not require installation (just a bookmark is needed).

Transferring the data produced by GmapToItn to the TomTom device requires a very simple manual operation consisting in creating an ITN file (e.g., with notepad) and pasting the acquired data; alternatively, Event_Logger 9.0 provides a separate tool called SendTomTom, which allows transferring data to TomTom via Bluetooth with only the need to provide a file name (it requires that BTConsole is installed and running on TomTom; the application supports UNIX, Mac OS X, Linux and PC through Cygwin).

The GPX Browser (gpx.xsl), already available in previous Event_Logger versions to allow interactive track analysis, now introduces many enhancements including draggable direction markers, Street view overlays as well as Panoramio, Wikipedia and YouTube overlays, reverse geocoding (translating coordinates and map points into addresses), GPX 1.1 support (other than GPX 1.0), right key mouse options, complete integration with Google Earth and many bug fixes.

Other than the widely used GPX Browser, Event_Logger v9 introduces a new reporting tool called ITN Browser. It consists of a comprehensive web application that offers a new way to review travels through detailed analysis of more ITN files even within long timeframes. It can browse any ITN file as well as the enriched ones produced by Event_Logger, aggregating data from more files and organizing the produced report in a very descriptive and readable table. ITN Browser is not only linked with GmapToItn (the Google Maps plugin allowing generating the TomTom itinerary data) but is also extensively integrated with Google Maps, exploiting all geodecoding and direction capabilities offered by Google. For instance, ITN Browser allows to quickly identify which and how many destinations have been travelled for work in the previous month, together with the related distances, tour durations and stay times.

The core stack of Event_Logger v9 running inside TomTom devices supports any model and NavCore version, including NavCore v9 that has introduced unexpected restrictions. Event_Logger v9 provides further enrichments to the features available with Event_Logger 8.2 (like the periodic ITN autoupdate during the trip), it is very responsive and does not inhibit TomTom’s functionality in any way. Bugs are virtually nonexistent. 

The following elements, which are included in Event_Logger 9.0 and run on NavCore 7 and 8, are unfortunately no more compatible with NavCore 9:
 - reverse geocoding,
 - snap-to-road positioning,
 - delayed flashing overlay messages (including Event_Logger ShowAltitude switch),
 - automatic day/night change,
 - POI management.
These restrictions are due to the limitations of NavCore v9 compared to the previous versions.

The additional software included with Event_Logger v9 should compensate the geodecoding limitation, considering that gpx.xsl, GmapToItn and Itn Browser offer advanced reverse geocoding features through Google Maps.

A completely rewritten and optimized NMEA/SiRF binary driver transparent to TomTom’s software can decode and record direct GPS data without virtually impacting NavCore and with automatic installation; this should compensate the missing Snap-To-Road capability.

An upgraded highly performing screen management functionality including different fonts together with a new driver managing screen and keyboard interaction with NavCore, again completely transparent to TomTom’s software, shall compensate the missing flashing messaging capability of NavCore v9.

 

Unfortunately, by now there is nothing doing for the inhibited SDK features that allowed automatic day/night change and add POI. It is the result of a direction by TomTom to completely close the navigation appliance to software contributors, differently from the original TomTom strategy providing a well documented and working SDK.

 

While Event_Logger 8.3 is feely downloadable , due to the effort I needed to accomplish this upgrade, Event_Logger v9 is only reserved to donors.

 

The update Event_Logger 9.1 is released now.

 

Here is a link to a complete presentation.

 

Again, thanks to people who already donated, supporting my work. Visit soon this site to review the new Event_Logger v9 documentation.

 

Amacri

 

1. Introduction

Event_Logger provides end-to-end management of itineraries from planning to reporting, fully integrated with Google Maps and TomTom; Event_Logger includes a tracking and logging Agent enhancing all all-in-one TomTom GPS devices. It can log TomTom events to Itinerary files that are managed by TomTom like native Itinerary files created through the ordinary user interface; besides, Event_Logger can produce standard GPX XML files where events are represented as waypoints and the whole route is logged through a sequence of track points obtained by querying TomTom GO for location information at short periodical intervals; the produced tracking will result bound to the roads through the assistance of both the TomTom GO mapping and the ASN feature (if active) in order to normalize tracking even without proper GPS reception; other than this default process to produce snapped-to-road GPX tracks, an additional option allows retrieving raw GPS data not intermediated by TomTom GO, useful for off-road tracking and also including altitude; Itinerary records and GPX waypoints take account of boot, resume, suspend events and optionally other information generated by manually tapping on the available (and extensible) logging menu icons. Other than generating Itinerary and GPX files, Event_Logger can create POIs (Points of Interest) for each event (or for a configurable subset).

The production and archiving of Itinerary and GPX tracks is completely automatic; no user intervention is needed to regularly split files upon new paths, save and catalogue them as well as store old information in compressed archives. The history of all travelled paths can be accessed by browsing the Itn directory of the SD card (or HD).

As the power button of TomTom GO is actually a suspend/resume button, any related pressure is logged by Event_Logger. Besides, Event_Logger automatically defines a new path each time the TomTom device is switched off and then switched on again after six minutes or more. If the docking station is connected to the vehicle ignition, the driver’s interaction with the vehicle will automatically raise ‘resume’ and ‘suspend’ events, caught by Event_Logger. This means that each ignition will automatically catalogue a new path (unless a short break is performed).

A boot happens when the user manages the USB, the SD Card as well as the reset hole on the unit’s bottom (the last action also resets the TomTom GO system clock); boot events are accounted by Event_Logger too.

All Itinerary records include date and time of each event occurrence as well as the associated duration data and possibly the current position, altitude, speed, course and address. Depending on Event_Logger configuration settings (e.g., snap-to-road/off-road) and on the NavCore version, GPX data can potentially deal with all parameters produced by the GPS device, including also number of used satellites, HDOP, PDOP, VDOP, magnetic variation (when available) and geoid separation (see related description).

A special selection activates a snapshot report displaying advanced statistics related to the current trip, also including slope computation. An additional panel included in Event_Logger provides an astronomical calendar in textual format where data depend on the current local time and position. Besides, switching between day and night colours of TomTom GO is automatically performed according to the elevation of the sun.

For instance, Event_Logger helps answering the following questions:

• What itinerary did I travel yesterday?
• When did I start driving this morning?
• How long did I take?
• Which is the current altitude and speed?
• How can I remind precise positions?
• When exactly I travelled there?
• Which is the altitude of this place?
• Which was the maximum uphill and downhill slope of my previous trip?
• Where is the moon now?

And so on.

The GPX files collected by Event_Logger allow performing any kind of post-processing, batch analysis, statistics and file conversion together with XSLT stylesheets or external applications (file converter, GIS, mapping and analysis tools running on PC or legacy systems).

An XSL file included with Event_Logger allows Internet Explorer to automatically transform each GPX file into an HTML interactive report with zoomable graphical map from Google Maps, including coloured tracks and fully clickable waypoints; the map provides advanced functionalities and is followed by detailed tables analyzing almost all data registered inside the GPX file, with computation of distance, speed, altitude and slope related to each fix, segment, trace or whole file. Each table can be easily imported to Excel. Besides, two delimiters can be easily set over the map in order to allow interactive trip analysis.

Event_Logger virtually supports any all-in-one GPS TomTom device and is designed to be independent from specific models (e.g., display size and geometry), firmware versions (including NavCore v7) and GPS device (SiRF Star II, SiRF Star III, SiRF Star III with QuickGPSfix and Global Locate's Hammerhead GPS units are all supported).

The subsequent chapters describe all these functionalities in detail.

Event_Logger today delivers the most comprehensive set of functionalities that complement TomTom and is a reference for independent tools on top of the TomTom firmware and of the NavCore application.

Differently from the majority of similar applications, Event_Logger also provides fully commented source code, allowing verification of the implementation quality and sharing the innovation; with its pervasive documentation including development guide, Event_Logger not only details functions and customisation aspects to users, but also is a common reference for independent developers. Great care was taken in preparing the whole documentation, constantly updated upon each release of new features.

Pioneering the methods to add software into the TomTom device, Event_Logger was the first to automatically intercept and log TomTom events like “switch on”, “switch off” and “boot”, exploiting them in a core functional process that is able to automatically split trips through the analysis of the switch off time; any derived process of Event_Logger is based on this automation; this provides great help to users which have not to remind to manually mark the beginning of a new trip. This method, which is innovative on a TomTom device, has been inspired from the behaviour of software odometers embedded in some vehicles.

Event_Logger perfectly harmonizes with TomTom, avoiding any redundant information already provided by the standard application and introducing a lot of additional trip based data to users; it was the first application to successfully interface NavCore through its “file transportation layer” without requiring the SDK platform; the result was the implementation of a free method which allows NavCore to display messages and to retrieve normalized fixes through the TomTom map assistance (the basis of the “snap-to-road” method). Event_Logger was also the first application exploiting the Itinerary management of TomTom, to allow user reading externally collected fixes through the NavCore function “Itinerary Planning”, introduced with NavCore 5.

Besides, Event_Logger first introduced GPS tracking and since the beginning adopted the GPX standard; it is also the only application providing both “snap-to-road” and “off-road” collection methods.

Event_Logger v9 introduced a Web Application called GmapToItn, which allows designing an itinerary through Google Maps, with no restrictions. Not only Google waypoints are fully managed, but also draggable directions and points of interest (POI) are allowed. After designing the whole itinerary with the standard Google Maps web application, including multiple subsequent destinations and dragged points on the paths to customize each route, the TomTom Itinerary data is produced by selecting a simple bookmark: a panel appears presenting the ITN report ready to be copied to a file on the TomTom device; besides, data can be further customized through an easy user interface providing appropriate configuration switches. POIs produced by Google local searches are presented as multiple destinations and every point or destination includes the related description. GmapToItn is compatible with virtually any Internet browser and does not require installation (just a bookmark is needed).

Transferring the data produced by GmapToItn to the TomTom device requires a very simple manual operation consisting in creating an ITN file (e.g., with notepad) and pasting the acquired data; alternatively, Event_Logger 9.0 provides a separate tool called SendTomTom, which allows transferring data to TomTom via Bluetooth with only the need to provide a file name (it requires that BTConsole is installed and running on TomTom; the application supports UNIX, Mac OS X, Linux and PC through Cygwin).

The GPX Browser (gpx.xsl), already available in previous Event_Logger versions to allow interactive track analysis, now introduces many enhancements including draggable direction markers, Street view overlays as well as Panoramio, Wikipedia and YouTube overlays, reverse geocoding (translating coordinates and map points into addresses), GPX 1.1 support (other than GPX 1.0), right key mouse options, complete integration with Google Earth and many bug fixes.

Other than the widely used GPX Browser, Event_Logger v9 introduces a new reporting tool called ITN Browser. It consists of a comprehensive web application that offers a new way to review travels through detailed analysis of more ITN files even within long timeframes. It can browse any ITN file as well as the enriched ones produced by Event_Logger, aggregating data from more files and organizing the produced report in a very descriptive and readable table. ITN Browser is not only linked with GmapToItn (the Google Maps plugin allowing generating the TomTom itinerary data) but is also extensively integrated with Google Maps, exploiting all geodecoding and direction capabilities offered by Google. For instance, ITN Browser allows to quickly identify which and how many destinations have been travelled for work in the previous month, together with the related distances, tour durations and stay times.

With the goal to allow smooth execution into the limited resources of embedded systems (CPU, RAM memory, SD memory), Event_Logger singularly implemented the functional process through scripting and the building blocks by extending an efficient interpreter with C functions; zsh was selected as the basis for the script interpreter, not only because much tinier and lighter than external perl or java portings, but also because it outperforms the system tools available inside the TomTom firmware; a considerable set of customizations have been applied to zsh in order to increase functionalities and in parallel to further reduce its executable size. Event_Logger also integrates the infoZIP archiver into an unmatched functional management process to classify and incrementally save data on the SD card. The result is an architecture that provides robust functionalities without introducing performance degradation.

      Notice that it is mandatory to carefully read and accept the disclaimer of warranty and license conditions at the end of this document before downloading and using Event_Logger.

2. What's new

What's new in 9.0 and 9.1

(May 8 - January 23, 2010)

This version is ready and offers a vast improvement over its predecessors.

Click at this LINK to browse the NEW presentation of Event_Logger V9.

Donations are more than happily accepted! Event_Logger took a lot of development time, as well as large number of testing and user support; if you like this software, you are kindly invited to send donations; click on the PayPal button to proceed, or email to amacri@tiscali.it to know how to perform this.

2.1. What's new in 8.2

(June 29, 2009)

This version includes the following changes and corrections versus 8.1.

• New shortcut button functionality for “Log Position to Itinerary”. Simply press the screen very close to its top left margin (e.g., near the “+” zoom symbol during standard navigation); after an audible shutter click produced by TomTom, the position is logged as if the “Log Position to Itinerary” was pressed. This also enables this function on TomTom devices not supporting custom menus. In order to speed up the TomTom response to an Event_Logger request, tap on the default navigation screen to get the TomTom menu (e.g., to exit the default real time navigation map) and wait for the displayed message (which should come faster through this operation, in few seconds).  If the new shortcut button function is not wanted, set DoWtchScrFld variable to no. Besides, again in case custom menus are not supported by your TomTom version, all files of SdkRegistry/Geo can be copied to SdkRegistry; then menus are available as map position detail elements (menu à second page à Browse map  à Navigator icon (  ).
• This version supports also the display popup of altitude (above sea level) and normalized slope (percent) each time this information is received by the GPS and roughly every minute. Set ShowAltitude=yes in order to enable this function. The display method is the same of all other popup messages and follows the delay issue of the main NavCore navigation mask mentioned in the previous point. If prompter popup timing is needed, tap on the screen to select a different screen (e.g., the TomTom menus). Each popup message remains active on the screen for four seconds (ref. AltDuration variable). By switching to off-road (e.g., long off road travel) this popup is shown every polling time (ref. TrackingGranularity variable) whenever a GPS 3D fix (including altitude) is fetched.
• Now, when keeping the touchscreen pressed while executing “Log Position to Itinerary”, the Advanced Statistics splash screen remains frozen on the screen even if the finger is immediately released (there is no more need to keep the finger pressed until the HOLD message is displayed). Press again the touchscreen to restore the NavCore screens. This behaviour can be controlled through the variable “WaitBeforeHold” (which is now set to 0).
• As explained in the instructions, GPX.XSL is a file, available inside Itn directory, which allows opening GPX files (both GPX and XML extensions) with Internet Explorer. Simply double click each XML file to graphically render it. In order to allow this, Gpx.xsl should be in the same directory of the XML and GPX files (typically, the itn folder). If these files are moved from the Itn folder to another directory, also Gpx.xsl shall be copied. A new version of GPX.XSL provides the following new functionalities:

·         Included messages with units in miles and feet other than km and meters. Simply move GPX.XML in a backup directory and rename gpxMilesFeet.xsl to GPX.XSL.

·         Now GPX.XSL overcomes a current Google Maps bug (by forcing version 2.99). You will not find an error anymore while clicking on markers to show related details.

·         GPX.XML now manages BOOT events and POI events with appropriate icons.

·         The map rendering performed by GPX.XML (press P = “More maps”) also includes the following sources:

·         Microsoft MSN Virtual Earth (Map, Satellite and Hybrid; http://maps.live.com)

·         Yahoo! Maps (Map, Satellite and Hybrid; http://maps.yahoo.com)

·         OpenStreetMap tiles (http://www.openstreetmap.org and http://wiki.openstreetmap.org) using the following renderers:

• Mapnik (http://www.openstreetmap.org/index.html)
• Osmarender (http://www.openstreetmap.org/index.html)
• Cycle Map (http://www.opencyclemap.org)
• CloudMade (http://maps.cloudmade.com)

·         MyTopo (http://www.mytopo.com)

·         RunwayFinder (http://www.runwayfinder.com)

·         OnEarth daily MODIS (http://onearth.jpl.nasa.gov)

Now the full list of allowed tiles is: Google Map, Google Satellite, Google Hybrid, Google Terrain, USGS topo, USGS aerial, USGS aerial+Google, U.S. Nexrad, Canada topo, Can. topo+names, Landsat 30m, Blue Marble, Blue Marble Next Gen., Daily "Terra", Daily "Aqua", Daily MODIS, SRTM elevation, EarthTools Contour, OpenStreetMap Mapnik, OpenStreetMap Osmarender, OpenStreetMap CycleMap, OpenStreetMap CloudMade. Virtual Earth Map, Virtual Earth Satellite, Virtual Earth Hybrid, Yahoo! Map, Yahoo! Satellite, Yahoo! Hybrid, RunwayFinder, U.S./Can. MyTopo.

• Event_Logger is comprehensively ported to NavCore 8.2x and 8.3x (including Event_Logger agent auto start-up during boot time, development of the new touchscreen functions which are now transparently supported by bsh, new timing algorithm to avoid reboots during resume operations). Tested versions: 8.204, 8.300, 8.320, 8.410, 8.412, 8.413.
• Event_Logger is also tested also with NavCore 8.002, 8.010, 8.011, 8.051 and with additional TomTom models, including GO 930T.
• NavCore firmware versions 8.350 and 8.351 do not allow interacting with external applications started through menu items; what happens is that the touchscreen is shared between the started external application and NavCore, which is not brought to background (differently from all other NavCore firmware versions). The behaviour of versions 8.350 and 8.351 do not compromise the log tracking of Event_Logger, which is performed in background with no need of user interaction. Besides, the shortcut button functionality activating “Log Position to Itinerary” still works. Anyway, functionalities provided by selecting the Event_Logger menu items are unusable with the standard devshare.so included in the Tracer directory. To allow interaction with versions 8.350 and 8.351, after the installation replace the file Tracer\devshare.so with Tracer\navcore8.35x\devshare.so. In case this is not enough to overcome the display issue, try replacing file Tracer\devshare.so with Tracer\navcore8.35x_and_old_devices\devshare.so.
• Now comments inside ITN files can be inhibited in order to provide full compliance with TomTom specifications (that ignores the possibility of adding comments even if NavCore can show them at the beginning or at the end of a file). See “NoCmtInItn” variable (setting it to yes would result in loosing general comments unrelated to positions in all generated Itinerary files, but provides increased compatibility with Tyre).
• A new feature allows exploiting the external SD card (for those TomTom devices supporting it). If the external SD card includes a directory named itn (which the user has to manually create in advance), the GPX logs are archived on that directory instead of exploiting the default itn directory of the internal TomTom memory (this might be useful when the space of the internal memory is very limited). Besides, if the external SD card also includes the “Tracer” directory, Event_Logger is executed from that directory (anyway, cleanup.txt and ttn must be in the root directory of the internal memory and a directory named “Tracer” including at least mkel has to be installed in the internal memory). If for some reason Event_Logger is required to run on a specific card or different hard disk from the previously described process (e.g., both Tracer and Itn directory on an external SD card also including the whole TomTom program and maps), simply create a null file called “hererun” (with no double quotes and no txt extension) inside the related Tracer directory.
• Translation strings have been improved, thanks to suggestions coming from users; Croatian translation has been added.
• Improved management of date strings in ITN and GPX files; date comments are clearer; now date syncs do not affect trip time accounting. Added “IncorrectDateSymbol”, used to identify ITN records with incorrect or inaccurate date (it defaults to a question mark, displayed just after an incorrect date). Besides, additional comments can be found in GPX files which highlight whether a date is incorrect (e.g., because not yet synced after a hard reset).
• A note has been added in relation to TomTom models hosting a SiRF Star III with QuickGPSfix software; when decoding from that GPS device, the returned PDOP (Position Dilution of Precision) and VDOP (Vertical Dilution of Precision) are actually Estimated Horizontal Position Error (EHPE in meters) and Estimated Vertical Position Error (EVPE in meters). Dilution of Precision (DOP) is a measure of how the geometry of the satellites affects the current solution’s accuracy.
• This version includes additional controls that avoid incorrect GPX formats (which might have happened in previous versions under rare circumstances).
• Now event logging of waypoints in GPX files (like RESUME, SUSPEND in “wpt” tags) take advantage of the Event_Logger Agent cache memory other than the NavCore one. This improves precision when both GPS and NavCore cannot return valid fixes (e.g., while suspending). The Event_Logger Agent cache is also dumped to the file named TripData under the Tracer directory.
• Other than supporting the new touchscreen functions for the latest NavCore versions, BSH has been further developed: read command now accepts a timeout argument; ztouch command has been updated; added also new setopt FunctionPhArgZ, new commands watchd, zrd, watchf, lease, inotify, dnotify (see documentation, in the last part of the development section). Even if implemented, inotify and dnotify are currently disabled due to the missing TomTom Linux kernel functionalities; for the currently available ttsystem versions, the kernel has been compiled with the related switches disabled.
• To improve suspend/resume performance, now “OldGpxToKeepOnline” is set to 0 by default, so that archiving of GPX file is disabled. Can be enabled by setting this variable to a value greater than zero.
• This version has a completely redefined GPS decoder, to improve performance. Now the measured speed parameter is correctly included in GPX files for off-road settings. Removed a bug producing wrong course in GPX files under some rare cases.
• Corrected a bug occurring when processing negative time zones.
• Additional bug fixing and performance tuning.
• When devshare.so is available inside the Tracer directory, the tracking granularity can be configured up to two seconds; notice that this takes additional CPU resources. Remove or rename devshare.so for standard operation (by default files devshare.so and ttn are both positioned in the startup subdirectory, so that the related functions are disabled).
• Documentation has been updated.
• Source code (Sources.zip) has been revised in order to allow easier recompilation (make clean; make; make clean; ./mkarm).
• Additional notes:
• It is normal that Top reports three Event_Logger instances concurrently running: this is because Event_Logger consists of a Posix milti-threaded application which is shown in such a way by Linux /proc. Actually, only one single process and memory resource are used of the three shown Linux tasks.
• Files created by Event_Logger inside the Tracer directory are for internal usage. Target GPX and ITN files can be found inside the Itn directory.
• If the automatic start-up of Event_Logger at boot time is not wanted, a null file named noeventlogger can be created in the root directory of NavCore (where also the file ttsystem can be found). Event_Logger will be started at the first pressure of the “Log Position to Itinerary” button icon.
• As described in the instructions, setting NoWatchDog=yes has the effect to inhibit the standard NavCore watchdog agent and to start a custom agent included in Event_Logger, which prevents NavCore reboots under certain conditions; this setting is generally not needed and becomes active after an initial reboot. In order to avoid this initial reboot, a null file named nowatchdog can be created in the root directory of NavCore (where also ttsystem can be found).
• This version also allows compatibility with Height (http://gps.dg4sfw.de/files/height_8.zip). Notice anyway that the ttn file to install on TomTom should be the one included in Event_Logger, not the one insight Height.

INSTALLATION AND UPGRADE NOTES: same as in “What's new in 7.2” below.

 2.2. What's new in 8.1

(March 10, 2008)

This version includes the following changes and corrections versus 8.0.

• Optional support of the bzip2 compression method in zip files produced by Event_Logger (often gives a better compression ratio than standard zip deflate, at the cost of greater CPU time). Before using bzip2 compression, please verify that a modern UnZip program with bzip2 support will be used to read the resulting zip archives so that entries compressed with bzip2 can be read.  Set “Bzip=9Zbzip2 ZipExec=zip3” in the configuration section to enable bzip2 compression.
• Now Event_Logger can automatically create an optional Itinerary file (ITN) and an optional POI file (OV2) including detailed tracking of each travelled route (e.g., basing on each produced GPX file and transforming it through GPSBabel). Both ITN and OV2 tracks can exploit a simplification method which removes points that have the smallest effect on the overall shape of the route; this filter is particularly important for ITN files, because NavCore allows browsing only the first 48 lines of them. Check ItnTrkPt and Ov2TrkPt variables to enable these transformations and control the simplification factor. Enable this feature only if really needed: each file generation takes some seconds to the power-on, power-off and boot procedures; consider that these files can always be manually generated basing on XML/GPX tracks.
• Corrected bug related to NoWatchDog=yes when running NavCore 7, that was causing cyclic reboots; now NoWatchDog=yes should inhibit all unattended reboots even with slow TomTom devices or SD memories. Besides, a specific description on how to manage possible cyclic reboots after the initial Event_Logger installation has been added in the Installation chapter.
• Corrected bug causing wrong computation of motion duration.
• Corrected bug in GPX.XSL related to the rendering of distance calculations in case of initial GPX segment with zero elements.
• Removed a bug preventing correct renaming of ITN and GPX archive backups.
• Now splash messages more appropriately manage TomTom screens with different sizes.
• Corrected mistype in icons.
• Documentation corrected and updated.

INSTALLATION AND UPGRADE NOTES: same as in “What's new in 7.2” below.

2.3. What's new in 8.0

(January 20, 2008)

This version includes minor changes and corrections versus 7.2.

• Corrected bug in SirfBinToAscii (bsh) setting some latitudes or longitudes to zero
• Corrected bug in geoid (bsh) not accepting longitude values between +/-90 and +/-180 degrees
• Corrected bug in Event_Logger.txt resetting GeoidSeparation (altitude shift issue)
• Corrected bug in Event_Logger.txt when computing altitude in feet (besides, altitude computation in GPX files has been slightly improved)
• Corrected bug in GPX.XSL related to the rendering of time calculations in case of initial GPX segment with zero elements.
• Now the Astronomical Calendar has an increased timeout for the fix retrieval operation; besides, the fix retrieval to start the Astronomical Calendar also exploits the direct GPS device interface if NavCore fails to provide data via SDK.
• Now, when the "advanced statistics" splash screen is selected, no event is recorded unless the IgnLongList variable is set to yes.
• Added WaitBeforeHold variable related to the "advanced statistics" splash screen, which allows configuring the timeout in seconds to keep the touchscreen pressed before the splash is frozen, so that the finger can be immediately released with the splash frozen if WaitBeforeHold=0 (as usual, a second pressure will make the splash disappear).
• Documentation corrected and updated.

INSTALLATION AND UPGRADE NOTES: same as in “What's new in 7.2” below.

2.4. What's new in 7.2

(December 30, 2007)

This version could be considered like a major upgrade for the relevant enhancements included. The most noticeable one is the support of virtually all the TomTom devices now available, including the various embedded GPS units and also NavCore 7 (with some limitation; ref. to the “Compatibility” paragraph). Considering the occasionally very slow SDK API response of NavCore 7 used by Event_Logger in snap-to-road mode, a specific feature (that can be configurable) automatically gets positioning information from the GPS when NavCore 7 does not provide any answer within a predefined timeframe. All other changes are described here below.

·         Setting the GeoidHeight variable is no more needed: for older TomTom devices, this value is now dynamically calculated by Event_Logger basing on latitude and longitude; besides, for newer models, this value is directly generated by the internal GPS device and fetched by Event_Logger. The algorithm used by Event_Logger exploits a function available in the GPSD project (http://gpsd.berlios.de/). Basing on the automatically computed values, GeoidHeight is still in place (and defaulted to 0) to allow statically setting a further translation correction, when really needed. As a reminder, the altitude is logged only when the off-road options are selected (not the snap-to-road ones).

·         Now an important limitation of the off-road feature of Event_Logger has been removed; it prevented retrieving direct information from the GPS devices in newer TomTom models, e.g., those ones hosting a SiRF Star III GPS unit which is set to use the SiRF binary protocol rather than the NMEA one. Event_Logger can now auto-detect the GPS unit type and decode both NMEA and binary SiRF frames, managing the off-road feature for any TomTom model; this allows tracking real coordinates, altitude, number of satellites and position error estimations with no specific configuration to apply, apart from enabling the off-road option from the related menu button.

·         Support of TomTom devices hosting Hammerhead GPS unit.

·         A further tuning has been performed to the NMEA driver which decodes information produced by TomTom devices and now GPX files should always include PDOP, VDOP, HDOP and Number of satellites in each GPX <trkpt> fix.

·         Slope computation has been added, including instantaneous slope, average slope for the last stretch of the path, maximum downhill and uphill slope, all accurately tuned for pretty reliable values. These parameters are included in the Event_Logger advanced statistics pop-up, which is the splash screen shown after selecting "Log Position to Itinerary" and when then keeping the touchscreen pressed for more than five seconds. Max uphill and downhill slope values also appear in the <name> tag of the GPX file.

·         As many users found difficulties in opening GPX files with Internet Explorer, now a new configuration setting allows saving GPX track files with either the “.gpx” or the “.xml” extension. By default, the latter is configured (rather than the previous versions, where .gpx was used), enabling easy GPX browsing: Internet Explorer opens XML files and automatically starts the XSL parser when the file “gpx.xsl” is available in the same directory of the GPX/XML files. Check the GpxFileExt variable in the configuration section of Event_Logger to select the wanted extension type. Notice that switching among the two extensions is a standard rename operation, which can be manually accomplished by any user in any moment. Besides, an Event_Logger function automatically renames un-archived GPX files (the last five ones by default) according to the value set in the GpxFileExt variable.

·         GPX files can now be correctly edited with notepad, because the DOS/Windows <CR> - <NL> character sequence is used for line separator. A new CR0 variable has been introduced for this; it can be configured for Windows or UNIX formats.

·         Previous version 7.1 reported the issue to lock the TomTom auto-reboot when extracting the SD card or when connecting the USB; this is a side effect of disabling the kernel watchdog feature (thanks Franz Haas of the OpenTom list for this hint), which sometimes happens to generate a device reboot when Event_Logger takes too many seconds to perform its internal operations (e.g., including archiving, file backup and zip compressions); notice this should never happen in normal operation, but only in debug mode, e.g., when resuming while tracing at level 5. Now this no-watchdog setting is configurable and by default is disabled (watchdog enabled, WatchDog=yes). If some user happens to verify reboots once in a while and wants to ensure avoiding them, the WatchDog variable in the configuration section can be set to no (and it needs a manual reboot via suspend button after inserting the USB cable or extracting the SD card).

·         Now each single backed-up archive inside itn\Bkp will never exceed a predefined size (which is configurable for Itn and Gpx types) in order to prevent too slow update operations. This should avoid that an automatic reboot might happen while resuming.

·         New button icons are available, thanks to Herbert Macho. The installation package also includes alternative TomTom button icons in a separate directory (provided by Herbert Macho and by Francesco Bombassei); simply select the icons you prefer.

·         The accuracy of distance computation has been improved by ignoring fixes with HDOP = 20 or greater.

·         Now the radius of the Earth has been set to 6378.137 kilometres in Event_Logger configuration (E_RADIUS variable), in order to produce values compatible with Google Maps.

·         Removed a bug preventing ITN and GPX archiving in some cases.

·         Removed rare syntax bugs in GPX tracks (now GPX files should always be syntactically correct or 'well formed', e.g., should never generate errors when opened with Internet Explorer).

·         Reduced refresh rate in the Astronomical Calendar, allowing improved readability.

·         Now bsh and zip (Info-ZIP) are compiled optimizing performance (-O3) rather than size (-Os).

·         Minor bug fixing.

·         Revised documentation.

·         New BSH commands: SirfEnvelope, SirfBinToAscii, dumps and geoid (see documentation, in the last part of the development section).

·         Further improvement to the Google Maps integration of the GPX browser, with a number of relevant additions included in GPX.XSL:

1.       Automatic management of locale settings (with very limited need of configuration)

2.       Local search component, which can be activated via key S or through the options panel (see documentation)

3.       New map layers (including other 13 maps from external providers other than the three standard Google maps types) and online altitude retrieval for any selected point

4.       Support of the new Google Map Layer named “Terrain”

5.       Fixes are now highlighted with small coloured square blocks than square icons, highly improving performance and allowing a wider default of concurrently managed fix elements.

6.       All waypoint markers can be dragged to improve readability, especially in case they are overlapped. Delimiters can also be dragged.

7.       Now all shown graphic elements have a tooltip.

8.       Simplified management of X key.

9.       New blue colour for the “delimiter” markers.

10.    Minor additions and fixes.

11.    Tested to also run inside Firefox through the IE Tab addon http://ietab.mozdev.org.

INSTALLATION NOTES: copy all files (apart from “Sources“ directory, Event_Logger.pdf and any ReadMe.txt). It is essential to preserve the directory structure included in the ZIP package unaltered. Edit Tracer\Event_Logger.txt with any editor (including notepad) and, above all, check variables TIMEZONE and LANGUAGE. If the Tracer directory is missing after the archive extraction, this mean that the directory structure of the package has not been respected. See the Installation paragraph for further information.

UPGRADE NOTES: replace all files (apart from “Sources“ directory, Event_Logger.pdf and any ReadMe.txt); remove H:\ttn (if existing) of any old Event_Logger version (important), then rename _Logger.itn (if existing) to _Latest_Events.itn; files EventLogger.tgz and Event_Logger.tgz (if existing) in “Itn” directory are no more used: they can be archived out in the Bkp directory; “Track” directory (inside "Tracer" directory) is no more used (can be saved out and then deleted); expr in the "Tracer" directory (if still existing) can be removed. Edit Tracer\Event_Logger.txt with any editor (including notepad) and, above all, check variables TIMEZONE and LANGUAGE. If using POIs, rename Tracker.ov2/.bmp (if existing) to POI_Tracker.ov2/.bmp. See the Installation paragraph for further information.

Verify that Debug is set to 0 inside Event_Logger.txt. If any of the files ttnlog-<date>.txt, TtnLog.txt, TrxLog.txt, trxlog-<date>.txt are available in the Tracer directory, this means that the Debug flag was not set to 0 in a previous Event_Logger version; all these files can be safely deleted to save space; anyway, before deleting them, with the WordPad editor please check the presence of the string _Event_Logger_Script_ERROR_ inside each of them; if this string exists, email the files to amacri@tiscali.it in order to facilitate bug fixing.

FURTHER INSTALLATION NOTES:

-          Do not forget to copy the file named “cleanup.txt” to the root of the SD or HD. If this file already exists, see the Installation paragraph for further information.

-          Do not exceed the maximum number of 10 “.cap” files in the “SdkRegistry” directory.

-          Setting the owner's preferences (a specific menu of TomTom) is discouraged (it might freeze the TomTom SDK functions until the "Continue" button is pressed).

-          A random menu reset to the initial menu page (e.g., page 1) might happen while navigating into the menu pages (typically after powering the device on; this is due to a small glitch in NavCore while processing the Event_Logger command changing night/day colours).

2.5. What's new in 7.1

(June 11, 2007)

·         Significantly improved browsing of GPX files with the addition of interactive analysis through Internet Explorer.

·         Slightly revised behaviour of “Toggle snap-to-road or raw GPS” button.

·         Some bug fixed (now the produced GPX file is always browsable with Internet Explorer and the suspend/resume operations are a bit more robust when the trace/profiling level is maximized).

·         Revised documentation.

INSTALLATION AND UPGRADE NOTES: same as in “What's new in 6.5” below.

2.6. What's new in 7.0

(March 17, 2007)

·         When opening the GPX files with Internet Explorer (e.g., "Open with… Internet Explorer" or drag and drop a GPX file to IE), Google Maps is started inside the browser, graphically representing the recorded path, together with many additional tables of statistics about the trip. Check to be connected to the Internet and that "gpx.xsl" is available in the same directory of the new gpx files.

·         Event_Logger can calculate the travelled distance (km or miles) while producing GPX logging; consequently, the average speed of a trip (km/h or miles per hour) and other new statistics can be produced. Besides, the GPX agent can trace the max and min altitude (meters or feet) as well as the motion duration (minutes) and max. speed.

·         When selecting "Log Position to Itinerary", a new mask can be activated by keeping the pop-up message pressed for some seconds. The new splash page shows advanced statistics related to the current trip. As soon as the touchscreen is released, the mask disappears unless the screen is kept pressed for additional five seconds: in the latter case the mask remains frozen on the screen until a new pressure is performed.

·         The GPX logging and GPX segmentation have been improved, with more precise timings and values. The process also monitors possible cases of wide distance between adjacent fixes, reporting conditions of nearby or faraway restarts (the former as new segment, the latter as new track).

·         Event_Logger now allows promiscuous usage; an appropriate chapter describes how to properly configure the application. GPX and ITN generation can be disabled, with decoupled behaviour to the day/night colour switcher. Besides, ITN and GPX archives can now include password protected files.

·         ITN and GPX archives now take advantage of an additional automatic backup copy of old archives inside the Bkp directory; this improves resilience in case of fault while producing a ZIP archive.

·         Event_Logger has been further tuned for performance with NavCore version 6.520 (SpeedNotAvailable variable is now set to yes, disabling the related NMEA feature).

·         The “Toggle GPX Tracker” icon is revised not to interfere with the day/night colour switcher. A new icon "Toggle Event_Logger Agent" in now available, with similar functions to what available in previous versions. (It is not really useful, so not suggested to be installed for normal operation.)

·         A bug introduced with version 6.5 about archiving old Itinerary files is now fixed. Other minor bugs have been fixed. SyncTime capability has been restored.

·         The documentation has been revised in all parts.

INSTALLATION AND UPGRADE NOTES: same as in “What's new in 6.5” below.

2.7. What's new in 6.5

(November 12, 2006)

·         Ported to NavCore 6.140, 6.150 and 6.520.

·         Fixed bug when setting negative values of GeoidHeight.

·         Improved NMEA driver including validation of the commands generated by the GPS device through the new NmeaChkSum function added in BSH.

·         GpxFileName variable with revised format in order to avoid two dots in GPX files, for better Google Earth compatibility

·         Debug now defaulted to 0 (it was set to 2 in version 6.4).

·         SyncTime capability is now disabled for better compatibility with NavCore 6.

·         NewGpxWhenDateChanges changed to NewGpxWhenDateAdjusted in order to avoid confusion.

·         Added Dutch translation.

·         All programs recompiled with the latest TomTom toolchain.

·         Some errors corrected in the documentation.

INSTALLATION AND UPGRADE NOTES: same as in “What's new in 6.4” below.

Verify that Debug is set to 0 inside Event_Logger.txt. If any of the files ttnlog-<date>.txt, TtnLog.txt, TrxLog.txt, trxlog-<date>.txt are available in the Tracer directory, this means that the Debug flag was not set to 0 in a previous Event_Logger version; all these files can be safely deleted to save space; anyway, before deleting them, with the WordPad editor please check the presence of the string _Event_Logger_Script_ERROR_ inside each of them; if this string exists, email the files to amacri@tiscali.it to facilitate bug fixing.

2.8. What's new in 6.4

(July 25, 2006)

·         Added off-road option to the GPX Tracker in order to allow processing data directly fetched from the raw GPS device (through the NMEA driver of Event_Logger). Check TTGOtoGPX and GpsToGPX variables for this; tracking can be tuned through TrackingGranularity and DelayToBreakTracks (representing intervals in seconds). (Off-road setting means GpsToGPX=yes, TrackingGranularity=5, DelayToBreakTracks=180).

·         Improved GPX Tracker with superior accuracy; each <trk> now includes geodecoded data; The NMEA driver has been enhanced to support additional messages and names.

·         Revised framebuffer and touchscreen calls in fb.c, (but without embedded touchscreen calibration); a printf wrapper is included, supporting bold attribute, ink/background/numeric colours, configurable shifts and ISO-8859-1 charset. Associated refinements in Top, Astronomical Calendar, bsh.

·         Slight revisions in Event_Logger.txt (added Norwegian language; now GeoidHeight supports decimals; other refinements)

·         Tested with TomTom GO version 5.450.

·         Ported and tuned to NavCore 6.120. Due to v6 busybox limitations, archiving is completely revised: the “Track” directory is no more used (can be saved out and then deleted). All ITN and GPX files are now stored in “itn” directory, including related archives (ItnArchive.zip and GpxArchive.zip) which are compressed in standard ZIP format (gzipped tar format is no more used). NavCore 6 automatically syncs Linux time to UTC; by consequence of this, browsing SD (or HD) files through a PC will produce “last modification times” set to UTC time zone (not local times); this feature is correctly managed by Event_Logger 6.4.

·         Revised documentation:

·         new information related to the additional features of this version and specifically to the GPX format;

·         Added mention of GPSBabel, a conversion tool which can be used to translate the GPX files produced by Event_Logger into many different output formats;

·         for developers, revised usage of zstat, framebuffer and touchscreen (now ts_press automatically removes bounces with no need of additional coding).

INSTALLATION AND UPGRADE NOTES: replace all files (apart from Sources directory, Event_Logger.pdf and any ReadMe.txt); remove H:\ttn (if existing) of any old Event_Logger version (important), then rename _Logger.itn (if existing) to _Latest_Events.itn; files EventLogger.tgz and Event_Logger.tgz (if existing) in “Itn” directory are no more used: they can be archived out and then deleted; “Track” directory (inside "Tracer" directory) is no more used (can be saved out and then deleted); expr in the "Tracer" directory (if still existing) can be removed. Edit Tracer\Event_Logger.txt with any editor (including notepad) and, above all, check variables TIMEZONE, LANGUAGE and GeoidHeight. If using POIs, rename Tracker.ov2/.bmp (if existing) to POI_Tracker.ov2/.bmp. See the Installation paragraph for further information.

Do not exceed the maximum number of 10 “.cap” files in the “SdkRegistry” directory.

Setting the owner's preferences (a specific menu of TomTom) is discouraged with NavCore 6.210 (it might freeze SDK functions until the "Continue" button is pressed).

A random menu reset to the initial menu page (e.g., page 1) might happen while navigating into the menu pages (typically after powering the device on; this is due to a small glitch in NavCore while processing the Event_Logger command changing night/day colours).

2.9. What's new in 6.3

(May 20, 2006)

·         Fixed a display bug with RIDER (e.g., now Top, Astronomical Calendar and splash messages are correctly shown on the screen of the RIDER). Now the display should support any TomTom model, including those with increased screen sizes.

·         Corrected small bugs in Astronomical Calendar (computation of moonrise and moonset; slightly improved descriptions). Added horizontal coordinates of the moon.

Upgrade note: same as in “What's new in 6.2” below.

2.10. What's new in 6.2

(May 6, 2006)

·           Corrected a bug preventing Bluetooth to work.

·           Fixed ts_press bug in bsh.

·           Improved pen management in “top” command; added “df” command (disk free) too (keep the screen pressed for more than 5 sec.).

·           Corrected small bugs in GPX description fields.

·           Further tuning for TomTom GO version 5.440.

·           Added Astronomical Calendar.

·           Added Automatic Switching between Night and Day colours basing on the elevation of the sun (original idea by ScaredyCat).

·           Updated documentation.

·           Revised installation process.

NOTE: Upgrade by replacing all files; remove H:\ttn (if existing) of any old Event_Logger version (important), then rename _Logger.itn to _Latest_Events.itn and EventLogger.tgz to Event_Logger.tgz in the “Itn” directory; expr in the "Tracer" directory can be removed. Check above all variables TIMEZONE, LANGUAGE and GeoidHeight. If using POIs, rename Tracker.ov2/.bmp to POI_Tracker.ov2/.bmp. See the Installation paragraph for further information. NOTE: Do not exceed the maximum number of 10 “.cap” files in the “SdkRegistry” directory.

2.11. What's new in 6.1

(Apr 11, 2006)

·           Corrected GPX bug occurring when coordinates are smaller than 1 degree.

·           Fixed TIMEZONE bug.

·           Corrected a small bug preventing VERSION expansion in GPX headers.

·           Further performance improvement (sleep builtin command of BSH now accepts decimals).

·           Updated documentation.

Upgrade note: same as in “What's new in 6.0” below. For programmers: usage of “ts_press” is discouraged in this version.

2.12. What's new in 6.0

(Apr 6, 2006)

·           Now Event_Logger.txt can be configured with any editor including notepad.

·           Simplified timezone setting.

·           Performance enhancements. The busybox ash interpreter as well as the external expr command are no more used by Event_Logger, which now exploits a new 265KB shell (called bsh, with sources and programming manual included) based on zsh 3.0.5 (http://www.zsh.org) and implemented by simplifying the original zsh code from one side and extending it from another. The Event_Logger script (now called Event_Logger.txt and placed inside the Tracer directory) was ported to efficiently support bsh.

·           Improved tracking accuracy.

·           Bug fixing and further tuning for TomTom GO version 5.420 and 5.440.

·           The new “Top” menu button is now available, producing the same output of the UNIX top command: it continuously monitors the system until the touchscreen is pressed.

·           Updated documentation.

NOTE: Upgrade by replacing all files; then rename _Logger.itn to _Latest_Events.itn and EventLogger.tgz to Event_Logger.tgz in the “Itn” directory; expr in the "Tracer" directory can be removed. Check above all variables TIMEZONE, LANGUAGE and GeoidHeight. If using POIs, rename Tracker.ov2/.bmp to POI_Tracker.ov2/.bmp. See the Installation paragraph for further information. NOTE: do not exceed the maximum number of 10 “.cap” files in the “SdkRegistry” directory. For programmers: usage of “ts_press” is discouraged in this version.

2.13. What's new in 5.9beta

(Jan 9, 2006)

·           Added geoid height correction constant, to be manually edited in order to generate Mean See Level altitude (TomTom GO GPS does not support geoid separation: altitude values returned by NMEA GGA messages are WGS84 ellipsoid heights; MSL altitude should be obtained by adding the relative geoid height; Event_Logger approximates this with the constant GeoidHeight).

·           Additional tuning for TomTom GO version 5.420. Added variable DoAnotherGpsRead, to be used in order to improve GPS retrieval (but reducing performance); it might be appropriate when using TomTom GO version 5.420.

·           Unit conversion functions (km/h to miles/h and meters to feet)

·           Updated documentation

2.14. What's new in 5.8beta

(Dec 31, 2005)

·           Additional tuning for TomTom GO version 5.420

·           fixed other minor bugs

2.15. What's new in 5.7beta

(Dec 29, 2005)

·           Added German translation (LANGUAGE variable now supports IT, FR, EN, DE)

·           Added menu entry to toggle the logging level

·           improved configuration and tracing

·           the NMEA interpreter has been rewritten to avoid usage of the 'sed' command

·           Improved flashing messages readability

·           support of an additional optional newline in GPX files to improve readability (see CR1 and CR2 variables)

·           fixed a bug related to the startup and shutdown of the GPX tracker through the menu button

·           fixed other minor bugs

2.16. What's new in 5.6beta

(Dec 12, 2005)

·           Fixed an error that prevented managing negative coords in itinerary files

·           AllowDateTranslation substituted with LANGUAGE; support of IT, FR, EN

·           Improved procedure to show date changes

·           The GPX tracker can now be started and stopped through new menu button

·           included optional GPX counter

·           support of optional newline in GPX files to improve readability

2.17. Features available in release 5.4beta

(Nov 28, 2005)

·           Fixed bug which prevented date sync.

·           Fixed bug which prevented GPX logging of negative coords.

·           First porting to TomTom GO version 5.420

2.18. Features available in release 5.2beta

(Oct 8, 2005)

·           GPX Tracking system (GPX files automatically archived with gzip compression)

·           Automatic track segmentation inside GPX files based on stop periods.

·           Geodecoding

·           POI creation

·           Integration with TomTom GO via file SDK (display message; more accurate positioning in case of poor radio coverage)

·           Management of short intervals, with the introduction of the aggregate items.

·           Computation of the duration of aggregated periods, including total journey time, total run time, time of small stops.

·           Archiving of past itinerary files into a single TGZ file (tar archive compressed with gzip).

·           This release also includes a bug correction in the GPX speed format (m/sec instead of km/h).

2.19. Previous versions

·           Release 5.1beta (Sep 19, 2005), including GPX Tracking system with the following issues:

·           geodecoding of waypoints generated by switch-off events do not work; related GPX information missing.

·           code not tuned ("sed" usage should be substituted by internal loops); very slow suspend time; usage of the enbedded version of busybox "ash" + external "expr" with so many process forks and pipes might reduce the used filesystem size to the minimum but I do not think not the best choose...

·           release 5.0beta, exploiting SDK

·           release 4.0beta (Sep 3, 2005), aggregating events occurred within short intervals

·           release 3.0beta (Aug 5, 2005), (Single ttn file. GpsLogger can be deleted.)

·           release 2beta (July 19, 2005, slight improvement)

·           release 1beta (July 14, 2005): POIs replaced by Itinerary files. Two separated files: GpsLogger (to be placed in the directory "Tracer" of the SD card) and TTN (to be placed in the root filesystem of the SD card). Many bugs and limitations.

·           release 0beta and initial development called Event POI Category Manager (June 2005), creating dummy POIs upon events.

3. Function list

The following features are available in Event_Logger release 8.2.

o        Application fully integrated with all NavCore versions and with any TomTom all-in-one device. An optional plugin allows managing specific NavCore issues.

o        Support of the following GPS units: SiRFstar IIe/LP, SiRF Star III with and without QuickGPSfix (SiRF binary and NMEA protocols), Global Locate's Hammerhead.

o        Management of the following hardware events: boot, resume (switch-on), suspend (switch-off).

o        Management of software events manually produced by pressing appropriate menu buttons. Two of them added by default: “Log Position to Itinerary” and “Log Position and add POI”. There is also a fast alternative to the “Log Position to Itinerary” menu button, consisting in pressing the top left margin of the screen until a shutter click is heard.

o        Aggregation of events occurred within short intervals (period is configurable).

o        Creation of Itinerary files including all events occurred within one or more consecutive journeys; information is shown by TomTom GO so that start of journey, end of journey and waypoints can be clearly distinguished.

o        Computation of the duration of each travel and stop period and other statistical data.

o        Flashing message within TomTom GO, showing collected information. Optional flashing message continuously showing altitude (above sea level) and normalized slope (percent).

o        GPX Tracking system, creating standard GPX files (GPX or XML file extensions) and supporting full tracking as well as waypoints for all occurred events; tracks are automatically segmented by managing short stop periods, including geodecoded data for each stop. Event_Logger also calculates the travelled distance, the average speed of a trip, the max and min altitude as well as the motion duration and slope.

o        All events occurred in one day are grouped in the same Itinerary file; when a file is going to exceed the max. number of allowed lines, data are automatically segmented into more files including sequencing reference.

o        A GPX file by default includes only information related to a single journey (configurable) in order to improve management.

o        GPX files are produced by either querying TomTom GO (producing snap-to-road traces) or directly the GPS device (this is useful when performing off-road travels). Related control is facilitated through appropriate menu icons. The direct access to the GPS device can extensively decode both the NMEA protocol and the SiRF binary one. An optional plugin allows

o        Other than GPX files, Event_Logger can optionally create Itinerary file (ITN) and POI file (OV2) that include detailed tracking of each travelled route. It can also simplify the ITN or OV2 track by removing points that have the smallest effect on the overall shape of the route.

o        GPS data are automatically retrieved from the TomTom cache in case the GPS device does not produce valid information.

o        Past Itinerary and GPX files are automatically archived into single ZIP files to save space on the SD card (or HD); anyway, the most recent files are not archived so that they can be easily managed (and, in case of ITN files, they can be opened within TomTom GO). Optionally, ZIP files can be compressed with the bzip2 algorithm.

o        Each position is possibly geodecoded. The current speed and altitude is also collected in case the GPX device provides the data. Values can be shown in km/h, miles/h, m, feet. Slope is also computed, together with pretty reliable maximum and minimum values. Altitude is automatically calibrated when needed.

o        Optionally, POIs (Points of Interest) are created upon each event.

o        When opening the GPX files created by Event_Logger with Internet Explorer (e.g., drag and drop a GPX file to IE), a GPX browser is started, graphically representing the recorded path through Google Maps, together with many additional tables analyzing the path in detail. The GPX browser also allows interactive analysis through the usage of mouse, keyboard and with the support of a comprehensive option menu. Functionalities include centre/zoom, fixes, direction arrows, traffic layer, local search, additional map layers, draggable waypoint markers, tooltip, altitude retrieval for any selected point, etc.

o        When selecting "Log Position to Itinerary" and then keeping the touchscreen pressed for some seconds, a mask appears, showing advanced statistics related to the current trip, also including slope computation.

o        Event_Logger allows both personal and promiscuous usage. GPX and ITN generation can be disabled. Besides, ITN and GPX archives can include password protected data.

o        An astronomical calendar is included, based on the current time and coordinates, providing standard calendar data, Ephemerides of sun and moon, rise and set time, twilight time, moon phase, etc.

o        The Event_Logger Agent includes a silent feature which automatically switches between night colours and day colours of TomTom GO basing on the elevation of the sun at the current position and time.

o        Two additional menu buttons easily allow toggling the tracing level and stopping/restarting the Event_Logger Agent; besides, a service button implements the UNIX “top” utility which easily allows to verify CPU and memory consumption as well as disk usage of the TomTom GO processes.

o        A shortcut soft-key function to log position can be activated from any NavCore screen or menu.

o        Event_Logger includes the full set of documented source code to allow revision and improvements.

4. Menu Buttons and Icons

Event_Logger adds the following menu buttons and icons to TomTom GO:

The previously described functions are fully customizable through the configuration section of the Event_Logger.txt file (inside the Tracer directory). The following chapters describe this in more details, as well as all the features of Event_Logger. A development guide is also included.

Depending on the firmware version and TomTom model, some TomTom devices do not support custom menus (even after a correct installation of Event_Logger, custom menu buttons are not shown).  This is unfortunately a TomTom limitation (or bug) with some device model. When menus are not shown, you can use the shortcut button: press the screen very close to its top left margin (e.g., near the “+” zoom symbol during standard navigation); after an audible shutter click produced by TomTom, the position is logged as if the “Log Position to Itinerary” was pressed; of course this method does not allow the same interaction as pressing the custom menu buttons. Another possibility is to install the custom menu buttons to a different (and more cumbersome) position: copy all files from SdkRegistry/Geo to SdkRegistry, replacing previous files; then menus are available as map position detail elements; to find them, press the screen to show the standard menu, go to the second page, select the Browse map menu () and finally press the Navigator icon (  ). You should find there the additional menus.

5. Examples

The following pictures show examples of flashing messages produced by selecting the “Log Position to Itinerary” button (or by pressing the upper left margin of the screen).

Example 1.

In this picture, 33.3km is the total travelled distance; 351m is the altitude above the sea; 47km/h is the current speed, 93km/h is the maximum speed within the same travel; the asterisk means that the message was manually generated through the “Log Position to Itinerary” icon (or through the pressure of the top left margin of the screen); [46’,44'] indicates that the whole travel took 46 minutes, but the real duration was 44' with two minutes of stop (i.e., TomTom GO has been switched off for two minutes in between). The geodecoded address shows street, civic numbers when available and town. (A trailing dot informs that the debug option is disabled, otherwise a number is shown, representing the debug level.) Notice that flashing is directly managed by TomTom and currently there is no way to convert the flashing information into a fixed pop-up.

Example 2.

Here {25'}  means that the TomTom device has just been powered on (i.e., resumed) after 25 minutes from the previous power-off (i.e., suspension); 10.5km is the total travelled distance of the previous trip and max=113km/h is the maximum speed registered during the previous trip. Currently the vehicle is stationary (this is because no current speed shown).

Example 3.

In this last picture, -1 means that TomTom GO (e.g., the vehicle) has just been restarted after a short stop of one minute; the current trip has taken 36 minutes effectively or 37 minutes in total, including the sum of the short stops (which in this case corresponds to the shown minute).

Example 4.

The following example shows advanced statistics produced when selecting the button "Log Position to Itinerary". In order to produce the reporting screen, keep the touchscreen pressed for some seconds while the splash message is shown (this message is composed of two lines reporting "Running Event_Logger Version 7.1 - [LOG]" followed by the current date or by the privacy reminder "Warning: your actual travel is being tracked"). Notice that advanced statistics cannot be produced when pressing the top left border of the screen.

After few seconds, a white mask is shown with some information. You can the release the touchscreen; the mask is frozen on the screen for 120 seconds and it can be closed in any moment by tapping on it.

Advanced statistics include the following data:

-          Trip length: total distance covered in the current travel

-          Total trip duration: this also includes any possible short stop (time when the TomTom device is switched off for a short while during the same travel)

-          Real duration (excluding stops): this duration excludes short stops and only includes the time when TomTom has been switched on

-          Settings: standard snap-to-road driving, off road trekking and racing, long travel, snapped-to-road, long off road travel, custom settings. off-road settings are coloured in green.

-          Current/max. speed: instantaneous and maximum speed within the current travel

-          Average speed (Avg.): this average value relates to the total trip duration

-          Average speed excluding stops: this average value relates to the real trip duration

-          Motion duration (excluding halts): time in minutes representing the duration of the travel calculated excluding any halt (no significant change of coordinates) or stop (TomTom switched off)

-          Average speed when in motion: this is the average speed (in minutes) during the motion time

-          Total halt time: in minutes; this time includes pull up (no significant change of coordinates) and stops (TomTom switched off)

-          Pull up time: sum of all the stationary periods reported in minutes (during this time, the coordinates have not significantly changed)

-          The optional message "No positioning data from TomTom and GPS device" means that the current fix is not available.

-          Source of positioning data: 'cache' means that the GPS device is not currently providing the fix, but TomTom has this information cached; 'active GPS' means that the fix is directly fetched form the GPS

-          Altitude: normalized information MSL (fetched from the GPS device when active). Max and min registered altitude values are also included.

-          Slope: instantaneous slope (percent value, computed on the last two fixes; might be imprecise), in parentheses, average slope for the last stretch of the path (percent value, computed more or less on the last kilometre, depending on the speed); maximum downhill and uphill slope. The last three values are calculated through a specific algorithm, tuned for pretty reliable values.

-          Follows the description of the geodecoded position also including an header message produced by TomTom.

-          The optional last message "Data referred to last recorded event: " reminds the previous flash message (i.e., the message preceding the current log, which of course might not be up to date); this information is shown when the current fix is not reliable or not available.

By default, when selecting the “advanced statistics" splash screen, no event is recorded (unless a specific configuration is applied).

Example 5.

This example shows how to access the Itinerary file: press the touchscreen, select “Itinerary Planning”

then select “Load Itinerary”,

the list of Itinerary files created by Event_Logger are shown; the last one, called “_Latest_Events”, is highlighted in red in the picture; the blue square shows the past files, which are sorted by crescent date. Select “_Latest_Events”,

confirm to load the Itinerary (press yes).

Find below examples of details of some Itinerary files.

Description lines include date of previous and current logs, list of events, boots, marks indicating each trip, automatic time synchronization and information related to log closure (date of rotation).

Lines can be browsed with TomTom GO. Selecting one of them, the panel showing the line property is presented. Press “Show on map” to check the graphical position of the logged event in the map.

Example 6.

Example of Astronomical Calendar:

(Note: can be simulated with Cygwin through ./acal.exe -a -m 1145696710 49.52607 11.51662 7200; the last parameter means UTC+2)

Remarks: when horizontal coordinates of sun and moon are highlighted in gold, the celestial body is locally visible in the sky. Times are local.

Example 7.

Event_Logger records tracking information to GPX files. A file named GPX.XSL allows transforming the tracked itinerary into a browsable map. In order to perform this, expand the Itn directory with Windows Explorer, verify that gpx.xsl is available in this directory (in general, verify that gpx.xsl is available in the same directory of the GPX file), select a GPX file produced by Event_Logger and simply drag it to Internet Explorer when connected to the network (e.g., accessing http://maps.google.com); alternatively, open the GPX file with Internet Explorer (e.g., select the GPX file, press the right key of the mouse, select “open with”, select Internet Explorer).

Wait for some tens of seconds. The resulted map is like the one shown in the next page, where the coloured “polyline” represents the tracked route with descriptions, segmentation and waypoints. The map also allows interactive analysis, as detailed in the related chapter. Press the “Map options” button to access the menu page.

The following picture shows an available feature allowing to interactively drag each marker, one by one; this is useful to improve visibility in case many markers are crowded inside a restricted perimeter.

6. GPX Tracking System

GPX (the GPS Exchange Format) is a light-weight XML data format for the interchange of GPS data (waypoints, routes, and tracks) between applications and Web services on the Internet. Find more information at http://www.topografix.com/gpx.asp.

Event_Logger creates GPX files. Other than including waypoints in GPX files basing on information logged to the Itinerary files (e.g., while processing the “Log Position To Itinerary” button), Event_Logger automatically logs GPX tracks through a specific process called Event_Logger Agent, which periodically polls TomTom GO and the GPS device in background; the Event_Logger Agent does not need to be activated (it is started by the Event_Logger startup features at boot time); a specific menu button allows to shutdown and to restart it on demand; appropriate configuration settings allow controlling all the GPX features.

Event_Logger archives GPX information as follows: the files /Tracer/Wpt.gpx (including current waypoints) and /Tracer/Trk.gpx (including current tracks) consist of incomplete GPX data (with missing envelope) collected at runtime. The file /itn/Trk_Last_Path.gpx is an uncompressed GPX full format generated when powering off TomTom GO: it collects all the latest GPX data (e.g., fetched from /Tracer/Wpt.gpx and /Tracer/Trk.gpx). After restarting or rebooting TomTom GO, GPX files are definitively consolidated under /itn (GPX repository). Old GPX files are then archived inside “GpxArchive.zip”.

As GPX is a XML format, a browser (e.g., Internet Explorer) can be used to open it.

Event_Logger also provides an XSL stylesheet (named “gpx.xsl” inside Itn directory) only compatible with Internet Explorer, transforming each GPX file into a XHTML interactive document. The produced report includes a Google Maps JavaScript which creates the map and allows interactive analysis; besides, detailed tables are available following the map.

In case of error, check the presence of the file “gpx.xsl” in the same directory of the GPX file. Check also to be connected to the Internet. Notice that the GPX file should also include

<?xml-stylesheet href="gpx.xsl" type="text/xsl"?>

in the second line (all GPX files produced by Event_Logger versions previous to 7 are missing of this line and need manual editing).

Of course, different stylesheets can be produced by users, implementing any kind of data transformation as well as additional capabilities than those ones provided by gpx.xsl.

In order to simplify the opening of GPX files with Internet Explorer, a configuration setting of Event_Logger allows saving GPX track files with either the “.gpx” or the “.xml” extension. By default, the latter is configured, enabling easy GPX browsing: Internet Explorer immediately opens XML files and automatically starts the XSL parser when the file “gpx.xsl” is available in the same directory of the GPX/XML files. The GpxFileExt variable allows selecting the wanted extension type. Notice that switching among the two extensions is a standard rename operation, which can be manually accomplished in any moment. Besides, an Event_Logger function automatically renames un-archived GPX files (the last five ones by default) according to the value set in the GpxFileExt variable. In this manual the GPX files are all named with .gpx extension in order to simplify understanding, even if as mentioned the GpxFileExt variable is defaulted to “.xml”.

Other than XSL transformations, a lot of programs can manage GPX data. Among them, TopoFusion, Google Earth and GPSBabel are notable for their capabilities. TopoFusion is an appropriate tool to perform basic graphical representation and analysis of GPX files produced by Event_Logger (with 2D and 3D rendering); it can download and cache maps and digital elevation data from Internet as well as access them locally. It allows normalizing tracks (e.g., see spline/interpolate functionality), calculates speed (average, instantaneous, etc.), path length (also interpolated) and allows adding elevation data to a track; it can then perform lap and climbing statistics as well as other types of analysis. Google Earth is the well known 3G soft globe and graphical information application; it can directly import the GPX files produced by Event_Logger, graphically representing the related tracks within the many available free layers (including the TeleAtlas road network). GPSBabel is one of the most interesting utility to convert the GPX files (waypoints, tracks, and routes) produced by Event_Logger in many other formats. It is a freeware and can manage about four dozen file formats, including TomTom POI, NMEA, HTML, Keyhole Markup Language (used by Google Earth), Magellan, Garmin and many others. (The syntax used by Google Earth to do the internal conversion of GPX to KML should be: gpsbabel -i gpx -f foo.gpx -o kml,points=0 -F foo.kml). GPSBabel runs on almost any computer and provides both a command-line interface and a GUI. An up-to-date ARM Linux version of the GPSBabel command line tool is also integrated with Event_Logger in order to perform optional automatic batch conversions, as subsequently described.

Event_Logger creates GPX files if at least one of the two variables DoGpxWpt and DoSdkTracking is set to yes (the latter also conditions the automatic switching between day and night).

When DoGpxWpt is set to yes, <wpt> elements are created upon each waypoint (suspend, resume and log menu buttons events). When DoGpxWpt is set to yes, DoTrackWpt allows adding <trkseg> elements upon each waypoint, including altitude information in case this is retrieved from the GPS device (this option is not invasive and should always be set to yes).

If DoSdkTracking is set to yes, a background agent is started in low priority execution, repeatedly fetching positioning data every TrackingGranularity seconds (sampling period). Data can be retrieved from TomTom GO via SDK (default, also called as snap-to-road) or directly from the GPS device (used for off-road tracking). When querying for TomTom GO, the process takes irrelevant CPU and limited memory (about 1.7 – 2.0 MB of RAM memory). In case the automatic switching between daytime and nighttime is set (e.g., DoSdkChSet=yes), Event_Logger takes additional CPU and memory (e.g., a constant memory size of about 2.2 – 2.3 MB and limited CPU which can go up to 40% for a very short fraction of time on each TrackingGranularity timeout; this does not produce any sensible degradation of performance). In case tracking information is unneeded (as well as the automatic day/night switching), the automatic start-up of the agent can be avoided by unsetting DoSdkTracking.

Notice that the Event_Logger Agent must be active in order to enable the automatic switching between day and night colours.

As mentioned, the standard settings optimize the performance impact by interacting with the TomTom GO application via SDK file interface without performing direct collection from the GPS device; by consequence of this, altitude data (not provided by the TomTom GO application) are not retrieved inside <trkseg> elements. (Notice also that speed and heading are not provided by TomTom GO versions 5.4XX. Either Version 5.2xx or 6.xxx are needed to get these parameters). Querying the TomTom GO takes advantage of the map assistance provided by the application in order to improve tracking information especially when the GPS reception is weak; ASN can also be exploited when configured; due to the mapping references, the resulting tracks will be generally bound to the road.

Alternatively, when the TomTom GO device needs to be used off-road (e.g., sailing, biking, flying, hiking and trekking), snap-to-road tracks might provide imprecise information of the actual path (especially when the mapping system includes roads close to the off-road track); in this case, it is worthwhile setting GpsToGPX=yes, which performs direct retrieval of raw GPS data via NMEA protocol. As TomTom models exploiting the SiRF Star III chipset are interfaced to TomTom via SiRF Binary Protocol rather than NMEA commands (like in older SiRF Star IIe/LP chipset), a driver decoding SiRF Binary Protocol is included in Event_Logger (see gpsdecoder bsh function). This allows the "off road" tracking with the old models like TomTom GO Classic or 500 as well as with TomTom 510, 710, 910, One, Rider, Rider II and newer models.

More generally, the variables managing the query methods are:

Snap-to road settings (tracks assisted by TomTom maps, without altitude):

Off-road settings (including altitude and many other parameters; tracks are not assisted by TomTom maps when the GPS is active, but in case the GPS device does not provide data, Event_Logger tries to fetch the fixes from TomTom, exploiting also the related mapping):

Off-road settings (including altitude and many other parameters; tracks are never assisted by TomTom maps, even if the GPS does not provide data):

TrackingGranularity defaults to 5 and can be raised to any value (for better performance and reduced size of the collected data); lower values, even if possible (e.g., 3 or 4), are untested and not generally suggested (will significantly reduce the TomTom GO response). Setting TTGOtoGPX to yes allows querying TomTom GO for georeferenced data (standard option); when setting GpsToGPX to yes, data are first attempted for retrieval from the raw GPS device and, in case of failure (no GPS data), fetched from TomTom GO (the latter provided that also TTGOtoGPX is set to yes); notice that GpsToGPX has the effect that Event_Logger contends with TomTom GO for the GPS resource, almost always winning the conflict. This means that the produced GPX files are rather accurate, while the TomTom GO response time will be slightly affected. The icon "Toggle snap-to-road or raw GPS" simplifies the related configuration. As already mentioned, the off-road settings (GpsToGPX=yes and TrackingGranularity=5) takes significant GPS resources to TTGO (even if not heavily affecting CPU and memory resources, so not significantly perceived by the user).

As previously summarized, when TTGOtoGPX is set to yes, the following information are retrieved from TomTom GO and converted to GPX: Latitude, Longitude, Date, Time, Course and Speed.

When GpsToGPX is set to yes, the retrieved GPX data include Latitude, Longitude, Date/Time, Speed, Course, Altitude, Number of used satellites, HDOP, PDOP, VDOP (horizontal/position/vertical dilution of precision). When supported by the GPS device, also the Magnetic Variation and Geoid Separation are collected; besides, in case “AddGeoidheight” is set to yes, Geoid Separation can also report the “GeoidHeight” predefined variable when the related GPS value is missing. For SiRF Star III devices, PDOP and VDOP are substituted by the “Estimated Horizontal Position Error” and the “Estimated Vertical Position Error” values, both in meters.

NavCore 7 introduces a relevant issue related to the periodic retrieval of positioning data when Event_Logger is set in the default snap-to-road configuration: occasionally, the unsupported NavCore 7 SDK API interface produces very inefficient answers; in order to overcome this problem, a specific feature of Event_Logger automatically gets positioning information directly from the GPS when NavCore 7 does not provide any answer within a predefined timeframe. The variable BkupFixFromGps controls this option: when TTGOtoGPX=yes, it can occasionally force a direct GPS retrieval in case of missing positioning information from the NavCore 7 SDK API interface.

In addition to the previously described settings, other options are available, influencing performance.

The first two options should be left unchanged; the related performance improvement goes at the cost of reduced functionalities. SirfIgnoreChkSum might be set to yes in order to process any SiRF binary message, including those ones that the GPS device generates with wrong checksum value; by consequence of this, the retrieval performance is slightly improved.

In case GPX data are used to draw new road maps (e.g., like contributing to the free mapping initiative at http://www.openstreetmap.org), consider setting TTGOtoGPX to “no” in order to avoid introducing copyrighted information (e.g., TeleAtlas mapping) into the produced GPX files.

A GPX file can include zero or more <wpt> (waypoints) and/or zero or more <trk> sections with optional <trkseg> (track points). Null GPX files are anyway discarded. Track points and waypoints are distributed into more files basing on rules controlled by variables:

-          NewGpxWhenDayChanges,

-          NewGpxWhenNewItinerary,

-          NewGpxWhenBooting,

-          NewGpxWhenDateAdjusted and

-          NewGpxWhenNewTravel.

If NewGpxWhenDayChanges is set to yes, a new GPX file is created as soon as the day changes. If NewGpxWhenNewItinerary is set to yes, a new GPX file is created if the itinerary file is missing, renamed or deleted. If NewGpxWhenBooting is set to yes, a new GPX file is created upon each boot. If NewGpxWhenNewTravel is set to yes, a new GPX file is created as soon as a new travel is identified (e.g., suspend interval taking more than ShortInterval minutes). If NewGpxWhenDateAdjusted is set to yes, a new GPX file is created as soon as the date is adjusted by Event_Logger through the automatic sync with the GPS device, which requires SyncTime=yes.

Appropriate variables control tracks segmentation, which produces more <trk> sections basing on a timeout expiration. GPX tracks are segmented if DoBreakTracks is set to yes and when the same 2d fix (latitude, longitude) does not change for more than (TrackingGranularity + DelayToBreakTracks) seconds. The configuration variable AllowDuplicatedCoords controls the process used to segment tracks; if not set, no information is collected when TomTom GO stands in a fixed position for enough time (typically when the vehicle stops for enough time, e.g., waiting in queue with ignition on) and a new track segment is produced when the position returns to change; besides, a new track segment is generated each time the vehicle ignition is restarted (e.g., TomTom GO stays suspended for enough time). If AllowDuplicatedCoords is set to yes, only when TomTom GO stays suspended for enough time a new track segment is generated.

Event_Logger monitors possible cases of wide distance between adjacent fixes; if NearbyRestart is set to yes and the residual speed (difference between real speed and measured one) is greater than 50 m/sec., a condition of nearby restart is reported (new trkseg inside the GPX file and warning inside the ITN file). Residual speed greater than 200 m/sec. generates a condition of faraway restart (new trk inside the GPX file and warning inside the ITN file).

Readability of GPX files can be configured through the variables CR0, CR1 and CR2, which can add linefeed separators in standard cases (CR0), after <trk> (CR1), <trkseg> (CR1) and </trk> (CR2). When CR0 is set to <CR> - <NL> (DOS/Windows character sequence, default configuration), GPX files can be correctly edited with notepad; notice that the end of line notation used in CR0 (e.g., Windows or UNIX) should be kept coherent with the settings of CR1 and CR2 (unless they are not valued).

An optional counter field can be added inside the GPX records, by setting the variable AddGpxCounter to yes. In this case, a new item <name>Point n</name> is added to each <trkseg> section, where n is a sequential integer starting from 0.

As mentioned before, generated GPX files are archived under the directory /itn inside the SD card (or HD) and zipped to save space. Dates in the names of each GPX archive refer to the archiving instant and use local time; dates inside GPX comments use local time as well, while internal dates in the trk and trkseg sections use UTC time, as reported in the related GPX directive. Each file date can be either a local time or UTC time depending on “LinuxTimeIsUTC” (setting it to “yes” allows usage of UTC times). Notice that LinuxTimeIsUTC must be set to yes when using NavCore 6.

GPX file size depends on the selected information and on the travelling period. In general, each travelling hour might produce up to about 5 KB of compressed GPX data (assumption is to set snap-to-road with 10 seconds sampling period). Files in itn should be periodically deleted or moved out of the SD card (or HD) in order to preserve space.

In summary, usage of GPX Tracking system can be configured through the following variables:

GPX files of Event_Logger exploit a free interpretation of <name> and <descr> tags inside the heading “<gpx…” element, the former including “END date” (so not really the descriptive name of the file) and the latter “BEGIN date”: these refer to the time of the first and last fix tracked inside the GPX file. Following “END Date”, the “<gpx…” element also includes “Total distance”, “Max speed”, “Motion duration”, max. uphill and downhill slope values.

<trkpt> elements may also consist of SUSPEND or RESUME events when the GPX reception is good enough; they are specifically marked with tags <sym>Waypoint</sym><type>SUSPEND</type> or <sym>Waypoint</sym><type>RESUME</type>. Besides, log events are reported as <sym>Dot</sym><type>LOG</type>.

Track segmentation is performed through the repetition of more <trk> elements with relevant information inside the related <name> field; each <trk> includes one <trkseg> tag containing zero or more <trkpt> fixes (trackpoints). The reason for breaking on <trk> tags rather than on <trkseg> is related to the need to add information to each segment (e.g., inside a <name> tag), which is not possible within <trkseg> in GPX 1.0.

GPX 1.1 is not used, due to the need to exploit some types of tag inside <trkpt> (like speed) that are defined for GPX 1.0 but unfortunately not for GPX 1.1.

The following table details the syntax of the tags in <trk> elements, which actually includes information related to the track segment.

All <name> tags include the current date using local time translated into the selected language (while dates inside <trkpt> are standard GPX strings with UTC time). An optional geodecoded position is available inside <desc> tags only when TomTom returns it.

As mentioned before, GPSBabel version 1.3.5 is included with Event_Logger in order to optionally generate Itinerary files (ITN) and POI files (OV2) from GPX tracks (only the command line tool has been ported to ARM Linux). ITN conversion exploits a custom style embedded in the program. Through the “simplify” filter, fixes can be reduced to a predefined value with the smallest effect on the overall shape of the route; this is particularly important for ITN files, considering that NavCore allows browsing only the first 48 lines of them.

In order to allow the generation of Itinerary files (ITN), set the ItnTrkPt configuration variable to a value different than zero. To generate POI files (OV2), set Ov2TrkPt to a value different than zero. Each value controls the related simplification factor (e.g., it sets the maximum number of produced points for the target format).

OV2 files are saved in the same directory of the latest active map (so, where all the other ov2 files are stored). NavCore seems to ignore the existence of any new OV2 file generated by GPSBabel until a soft reboot is performed (e.g., extract and reinsert the SD card, or plug and unplug the USB cable). Notice that too many OV2 files can slow down NavCore execution if all of them are loaded and active.

None of the files generated by GPSBabel is compressed by Event_Logger.

Notice that all these conversions take additional seconds to the power-on, power-off and boot procedures of TomTom, so they should be enabled only if really needed.

Alternatively to the automatic conversions allowed by Event_Logger, file format conversions can always be manually obtained by running GPSBabel on a PC and using the following command syntaxes:

GPX to Itinerary:

gpsbabel -w -r -t -i gpx -f "<input GPX file>.xml" -x track,merge -x simplify,count=<max points> -x transform,rte=trk,del=n -o tomtom_itn -F "<output file>.itn"

This command implements the standard transformation included in gpsbabel, where route points are automatically labelled with short descriptions like the following ones:

RPT001

RPT002

RPT003

RPT004

...

The transformation implemented by Event_Logger exploits a special TomTom ITN style embedded in the gpsbabel porting for ARM Linux (included in the Event_Logger package). This file (check file tomtom_itn.style in Sources.zip) allows creating ITN items with descriptions like the following one:

RPT016 fix=3d. 08-03-10 21:16:52. Alt=138 m. Distance=1.2 km. Speed=0.0 km/h

When using a standard GPSBabel tool to get this type of custom ITN files, use the xcsv format instead of tomtom_itn, specifying the custom style included in Sources.zip. Specifically, the related command line is:

gpsbabel -w -r -t -i gpx -f "<input GPX file>.xml" -x track,merge -x simplify,count=<max points> -x transform,rte=trk,del=n -o xcsv,style=tomtom_itn.style -F "<output file>.itn"

Notice that Itinerary files generated through this command (or by setting ItnTrkPt to a value different than zero) have different content from those ones described in the next chapter, because including all the fixes of a GPX file (or a simplification of them). ITN files in next chapter only log each TomTom event instead of the whole route (or simplified route).

GPX to TomTom POIs:

gpsbabel -w -r -t -i gpx -f "<input GPX file>.xml" -x track,merge -x simplify,count=<max points> -x transform,wpt=trk,del=n -o tomtom -F "<output file>.ov2"

GPX to Google Earth (Keyhole) Markup Language (KML):

gpsbabel -w -r -t -i gpx -f "<input GPX file>.xml" -o kml,line_color=995555ff,line_width=4,points=0,units=m -F "<output file>.kml" 

Follow the GPSBabel instructions (gpsbabel.html) to set up additional options or select other target formats like CSV, NMEA, additional transformations for GPX files, etc.

If GPSBabel is not used, the file named gpsbabel in the Tracer directory can be deleted to save considerable space.

7. Itinerary file format

Event_Logger creates Itinerary files compliant with the TomTom file format.

The management of Itinerary files is included in any updated TomTom version, regardless of the used processor or embedded system (TomTom Mobile for Symbian mobile phones, TomTom Navigator for PDA, all the TomTom GO models exploiting ARM Linux, etc.).

A TomTom user can manually create, edit and use Itinerary files as an alternative method to the single destination route planning (with optional single 'via' location) allowed by the standard “Navigate to…” function of TomTom: exploiting itineraries allows managing journeys which consist of a list of 'waypoints' and 'destinations'; other than planning compound journeys, itineraries can be saved and, as they are ascii files, they can be easily exported.

The general syntax for Itinerary records managed by TomTom GO (e.g., format of each line of an Itinerary file) is:

< longitude >|< latitude >|< comment >|< flag >|

where:

< longitude > is the longitude in millionths of degrees (WGS84 datum);

< latitude > is the latitude in millionths of degrees (WGS84 datum)

Note: when both <longitude> and <latitude> are valued to 0, it means no positioning available and TomTom shows the related line barred.

< comment > might include any string (e.g., in general there should be the fix name in the itinerary); see below for the actual syntax used by Event_Logger inside this field.

< flag > is a number (typically 0, 1, 2, 3 and 4). The following component values are allowed to generate the flag (all components have to be ORed together in order to produce the flag value).

• 0x00 None
• 0x01 Itinerary location is enabled
• 0x02 Itinerary location is a stop-over (as opposed to a pass-by location)
• 0x04 Itinerary location is departure point (should only be set for the first item in the itinerary file)

Considering how Event_Logger manages this flag, value 4 is never used, while 3 is used to mark the last record of a journey, separating the closed journey from the next one. 0, 1 and 2 are used for lines within the same journey (e.g., 0 and 2 make TomTom GO show the previous records in grey instead of black; this is used by Event_Logger in order to differentiate the representation of heading comments).

Event_Logger generates Itinerary files if DoGenerateItn=yes. If DoGenerateItn is set to no, any Itinerary file generation is inhibited (this setting is useful in case of privacy issue or promiscuous usage).

The syntax used by Event_Logger in the Itinerary comment field is:

<hour>:<minute> <first set of symbols> [<total journey duration>,<real journey duration>]<short stopover interval> <distance> <altitude> <speed><second set of symbols> <Address>

Alternate duration syntax:

{<total stop duration>,<real journey duration following the stop>}

Note: all symbols are configurable, including altitude and speed symbols.

Detailed description of each field in the comment string:

<hour>:<minute>: two digits for hour (00-24 format), column symbol, two digits for minutes. A subsequent question mark indicates incorrect or inaccurate date (check IncorrectDateSymbol variable)

<first set of symbols> the following symbol might optionally be shown:

• ^: meaning outdated positioning; when this symbol is shown, the related positioning is referred to the previous registered event (both TomTom GO and the GPS device were not able to provide positioning data).

<short stopover interval>: it reports short stops within a journey, representing the total minutes resulting from the calculation of the sum of any contiguous short stop period; more precisely, the reported value consists of the overall period of a sequence of one or more “stop-and-go” taking in total up to 6 minutes (configurable timeout); these short breaks are aggregated into one line and made part of the current journey in order to improve readability of itinerary records by differentiating the representation of short stopovers from long stops, where the latter case (e.g., stops longer than four minutes) winds up a journey and produces the separation of the performed track from the next one (e.g., set the < flag > field of the last record of the journey to 3 instead of 1). The syntax is "-<minutes>" (e.g., minutes preceded by the dash symbol) and in case the period at a waypoint takes less than one minute, the additional <’> apostrophe character is added at the end. The related date is referred to the last aggregated event (by subtracting the reported minutes, the date of the occurrence of the first aggregated event can be easily calculated). Notice that <-0> (referring to more aggregated events occurred in the same minute) is substituted by <-1’>.

<distance>: this parameter reports the covered space between the starting point of the journey and the last measure log, meaning the actual length of the current trip, followed by its unit symbol (configurable); km is the default unit, unless the unit conversion variables are set to show feet.

<altitude>: parameter optionally returned by the GPS device, followed by its unit symbol (configurable); meters is the default unit (e.g., “m” symbol), unless the configuration variable mToFeet is set to yes, so that the value is converted to feet). Notice that altitude is always mean-sea-level and might optionally be calibrated through the GeoidHeight variable.

<speed>: (<current speed>-<max. speed><unit>) one or two parameters (separated by a dash symbol) optionally returned by the GPS device or by TomTom GO, followed by their unit symbol (configurable); kilometres per hour is the default unit (e.g., “km/h” symbol), unless the unit conversion variables are appropriately set. The two values represent the instantaneous and maximum velocity; the former relates to the measured speed at the time of the last log event; the latter is the maximum speed collected by Event_Logger during the current trip.

< second set of symbols >: the following symbols are used:

• *: the related line is generated by the manual selection of the appropriate menu button. (A line without the asterisk symbol (*) is instead produced by a TomTom GO event.)
• !: the positioning information might be slightly outdated (not produced by the GPS device, simply fetched from the TomTom GO application cache; in this case, altitude is missing as the TomTom GO application does not currently manage this dimension)

<total journey duration>: period covering the time difference between the last registered event of a journey (e.g., last stop) and the first one (e.g., first start).

<total stop duration>: duration of a long stop (more than 6 minutes), reporting the time separating two different and consecutive journeys. It is enclosed within curly brackets to differentiate it from the total journey duration, which is enclosed in square brackets. The first line (event) of a journey should include this data, optionally followed by the real journey duration, which is separated by a comma inside the braces.

<real journey duration>: sum of all the real trip durations composing a single journey (different from the “total journey duration”, which also computes the small stop timings between trips). To improve readability, the < real journey duration > field is only reported if the related value is different from the <total journey duration> field (e.g., in general the real duration is slightly shorter than the total duration; anyway the values can be the same if a journey does not include short stopover intervals).

Time formats used in fields <total journey duration>, <total stop duration> and <real journey duration> are:

• For intervals up to 59 minutes: <minutes>’ (number of minutes followed by the apostrophe symbol)
• For intervals between 1 hour and 23:59 hours: <hour>:<minute> (one or two digits for hour in 0-24 format, column symbol and two digits for minutes).
• For longer intervals: <number of days>-<hour>:<minute> [Note: this option does not apply to <real journey duration>, that always uses the “<hour>:<minute>” syntax]
• An automatic date change during the Event_Logger processing might incorrectly produce negative durations; in this case, the RESET label will appear instead of negative values.

The syntax used by Event_Logger in the Address field of the Itinerary comment is:

<street name> <adjacent number1>-<adjacent number2>, <city>

The optional geodecoded information represents house number or numbers (when available) after the street name (syntax can be changed by revising the code). If there are two house numbers, they are separated by a dash symbol. Street (when available) and city names are separated by the comma symbol.

Note: the two configuration variables $UnnamedRoadString1 and $UnnamedRoadString2 allow deletion of useless internal predefined strings informing of unnamed road or unknown place. This variables should be valued in accordance with the locale setting of the TomTom GO application.

For each event, the date when the event occurred and the related interval computations are basic information always available. As a matter of fact, these data can be directly managed by Event_Logger and do not depend from the TomTom GO application and from the GPS device.

Through the interaction with TomTom GO via SDK, Event_Logger enhances the data by adding the following values:

• Positioning, speed and altitude, when provided by the GPS;
• Cached positioning, important when the GPS device cannot provide information (the altitude field is anyway unmanaged by the TomTom GO application and so not cached);
• Geodecoding: street, street number or neighbouring street numbers and city name

There are cases in which the SDK interaction fails and does not produce enhancements to the basic information produced by Event_Logger; for example, after a reset the SDK management is temporarily frozen until TomTom GO retrieves the first valid information from the GPS device; as soon as this information is retrieved, the SDK management starts and correctly provides updated information received from the GPS device (or cached information in case the GPS data are not available). Consider also that, when a route calculation freezes waiting for a valid GPS data, also the SDK management is inhibited. Notice that even if the GPS data are available, TomTom GO might give precedence to its internal routing (or re-routing) calculation than managing SDK requests; for this reason, Event_Logger treats asynchronously all external requests managing internal timeouts; so, during a route recalculation or while other TomTom GO internal processing algorithms execute, the data enhancement might not be fulfilled in time. In all these cases the enhancements are lost (e.g., not used by Event_Logger).

When browsing or managing an Itinerary file within TomTom, while TomTom controls the longitude, altitude, and flag fields in each Itinerary line, it completely ignores all the previously described syntax internally used by Event_Logger and simply shows the whole comment field as a multiline string (e.g., one or two lines per record, depending on the field length).

Example:

934137|4556701|17:49 [50',46'] 15.3km 197.6m 57-125km/h* A4/E64 Autostrada Milano Brescia, Agrate Brianza|1|

Meaning: during a journey, at 17:49, the driver pressed the custom menu icon when travelling about 57 km/h over a position with longitude 9.34137 degrees, latitude 45.56701 degrees (WGS84) and altitude 198 meters, which corresponds to the highway “A4/E64 Autostrada Milano Brescia” within the town “Agrate Brianza”; The travel duration took 50 minutes but the actual run took 46 minutes (that is, there was a short stop of 4 minutes before). The covered distance is 15.3 km and the maximum speed is 125 km/h. The TomTom GO application shows this information as follows:

17:49 [50',46'] 15.3km 197.6m 57-125km/h* A4/E64 Autostrada Milano Brescia, Agrate Brianza

As this comment is long and by default only the first characters are displayed, press the line and keep it pressed in order to make the TomTom GO application change the character format and show the full multi-line comment. (Besides, when tapping on the line, the related menu appears and, in its heading note, the first part of the comment is shown.)

Comments inside ITN files can be inhibited in order to provide full compliance with TomTom specifications (that ignores the possibility of adding comments even if NavCore can show them at the beginning or at the end of a file). This can be done by setting NoCmtInItn to yes.

8. Astronomical data

Event_Logger manages astronomical data through the Astronomical Calendar, providing a full-screen textual presentation (where times are represented as local, not UTC); it also exploits a BSH additional component through the Event_Logger Agent for the automatic switching between day and night colours/brightness of TomTom GO.

The point of switch between night and day can be calibrated through the “MaxSunElevation” variable also mentioned in the next paragraph (ref. to “Usage of the SDK”), which can be valued to:

The default setting is -4, inside the civil twilight. When setting MaxSunElevation, decimal point is dot, like for any other BSH variable.

Variables "DNChangeCounter" and "DNChangeFactor" can be used to further tune the repetition of commands sent by Event_Logger to TomTom GO in order to change the day/night colours.

Many internet sites can help to understand the meaning of the shown data. Check in particular http://www.stjarnhimlen.se/comp/tutorial.html and http://www.stjarnhimlen.se/comp/riset.html for further information.

For the definition of sunrise and sunset, moonrise and moonset, civil, nautical and astronomical twilight, visit page http://aa.usno.navy.mil/faq/docs/RST_defs.html. (Civil twilight is when illumination is sufficient, under good weather conditions, for terrestrial objects to be clearly distinguished. During nautical twilight general outlines of ground objects may be distinguishable, but detailed outdoor operations are not possible, and the horizon is indistinct. In astronomical twilight sky illumination is so faint that it is practically imperceptible even if it is not dark enough for accurate star observation.)

Sun and moon can be immediately identified in the sky above us through their horizontal coordinates:

-          Azimuth (Az): the horizontal angle of the sun (or of the moon) or related direction produced through compass bearing, like that one graphically represented by TomTom. The azimuth is the arc between the true north and the vertical circle passing through the centre of the sun or the moon, clockwise from the north point (0°) through 360 degrees

-          Elevation (Elev.): the angular distance of the sun (or of the moon) above the horizon, represented in degrees between -90° and 90°; 0° represents the horizon; the elevation is the arc of a vertical circle intercepted between the sun (or the moon) and the horizon

elevation and azimuth: 1 horizon, 2 zenith, 3 sun or moon, 4 meridian, 5 vertical circle; the angle from the horizon is the elevation, 6 azimuth (angle from north=0°), 7 observer

Position of the sun and of the moon:

-          Read the azimuth and elevation of the sun through the Astronomical Calendar

-          Ensure that the elevation angle is positive (when negative, the celestial object is not visible; notice that when the celestial object is visible, the Astronomical Calendar highlights the related values in gold yellow)

-          Switch back to TomTom and ensure that the compass is shown including the direction angle; move TomTom for some meters in order to read a valid compass bearing

-          Orientate the TomTom compass to the same azimuth angle of the celestial body

-          The elevation measures the vertical angle of the sun or moon in degrees from the horizon. A negative value means sun or moon below the horizon. More specifically: -0.5833 degrees is sunrise/sunset (which will delimit nighttime from daytime), -6 degrees is the civil twilight, -12 degrees is the nautical twilight and the astronomical twilight is 18 degrees below the horizon (-18°).

Solar eclipse:

-          Both sun and moon are visible, apart from the period when the moon obscures the sun (e.g., each elevation > 0)

-          Azimuth of the sun = azimuth of the moon

-          Elevation of the sun = elevation of the moon

Lunar eclipse:

-          Moon is visible, apart from the period when not obscured by the sun (e.g., elevation > 0; possibly the moon should be gibbous or full)

-          Azimuth of the sun = opposite of the azimuth of the moon (e.g., difference of 180 degrees between them)

-          Elevation of the sun = opposite of the elevation of the moon (e.g., same absolute value with opposite sign)

eclipse (umbra and penumbra): E= earth, M =moon, , S =sun

9. Event_Logger GPX Browser

This chapter describes the information produced by Internet Explorer when browsing a GPX file generated by Event_Logger, provided that the file ‘gpx.xsl’ is also available in the same directory of the GPX file. As the produced report allows interactive analysis, this chapter also provides the related instructions.

The following browser error means that “gpx.xsl” cannot be found in the same directory of the GPX file:

Currently, ‘gpx.xsl’ is only compatible with Internet Explorer versions 6 and 7; all the other browsers will produce an error similar to the following one:

Event_Logger should also run inside Firefox through the IE Tab addon http://ietab.mozdev.org (this might also allow using Linux by installing IEs4Linux and then configuring IE Tab to open IEs4Linux as an external application).

As many users successfully run GPX.XSL through IE, I would suppose that there should be some issue on your browser configuration.

I take this occasion to inform everybody that Event Logger V7.2 is currently being sent to selected testers and donators and will soon be available to the community.

When opening a big sized GPX file with Internet Explorer, the document generation might take many tens of seconds (e.g., up to 2 minutes or more, depending on the number of fixes in the GPX file). This waiting duration is normal.

The document generation and the interactive analysis application exploit the browser status line, which always reports the result of the last command or event.

The first two displayed elements at the beginning of the document are the main title (with hyperlink to the related URL) and the author’s name (with hyperlink to the author’s e-mail). These data are fetched from the <gpx> header tag of the GPX file:

• Main title: content of “urlname” and “url” tags (e.g., Event_Logger 7.1)
• Author: content of “author” and “email” tags (e.g., amacri)

After the title, two items are generally shown, indicating begin and end dates of the path as well as total distance, max speed and motion duration. Also these data are fetched from the <gpx> header tag of the GPX file:

• <name>: end date, total distance, max speed, motion duration, max. uphill and downhill slope values (data produced by Event_Logger)
• <desc>: begin date (information produced by Event_Logger)

Example:

Subsequently, the Google Maps window is shown: the map includes a large pan/zoom control in its top left corner (where the centre button allows returning back to the original pan and zoom settings), a map scale in miles and kilometers, localized buttons that let the user toggle between map types (such as Map, Satellite, Hybrid), a collapsible overview map in the bottom right corner of the screen and of course the path descriptors. A specific “Map options” button is also available.

Example:

The map is automatically resized to the window dimension. By resizing Internet Explorer, the map dimension automatically changes accordingly.

The track attributes added to the map include:

-          travelled path, represented with subsequent brown, blue and green segments;

-          arrow indicators, showing the directions;

-          stopover markers (representing the start of a GPX <trk> segment; red or green colours depend on the presence of the “cmt” tag);

-          waypoint markers (showing data included in <wpt> tags; dot represents a LOG event, small arrow a resume event and small square a suspend event);

-          fixes (referring to <trkpt> tags and also showing data included in the “fix” tag; more precisely, red, gold and white, respectively represent 2d, 3d and cached fix quality).

Below the map, a complete set of tables extensively report the path analysis. Map and tables are fully interconnected by virtual hyperlinks which simply allow to switch from graphical representation of a fix to related tabular analysis and vice versa. The produced map also allows interactive analysis through the usage of keyboard and mouse. The interactive analysis can control visibility, switch specific map elements to related description and manage a comprehensive interactive segment calculator. Other than using the keyboard to select the interactive options, a menu panel is available, graphically showing all the possible configuration settings; this menu can be opened by pressing the “Map options” button or when the mouse flies over the right red border of the map.

After selecting an option, the menu disappears; besides, in case of selection through the right red border of the map, the menu automatically fades away when the mouse goes outside the panel perimeter.

While segments, stopovers and waypoints are always shown by default, in order to speed up map rendering and reduce visual clutter, arrows and fixes are visible only at closer zoom levels, where these details are relevant; besides, these attributes (fixes and arrows) are shown only when their number is lower than 500. For higher number of attributes, their granularity is automatically reduced by a proportional factor, so that up to about 500 fixes are drawn in all cases. This factor is called graininess. Irrespective to the selected graininess, fixes including “sym” comments are always shown, as well as the first and last one of each <trkseg> segment. Appropriate controls (numeric keys pressed once or twice) allow manually changing the graininess factor; higher values speed up map rendering but reduce outline sharpness (graininess=3 or more should be effective at wider zoom levels, where details might not be so relevant; the smallest graininess level is 1, where all fixes are shown, meaning the first 500 elements by default). Key ‘F’ has two behaviours; when the number of fixes is limited (specifically, up to 200 - not even 500), it simply toggles their visualization (either always visible or only at closer zoom levels); when the fixes are more than 200, by repeatedly pressing key ‘F’, subsequent trunks of 200 fixes are switched in turn, including also path lines; in order to highlight the condition of sliced path in the middle of a <trkseg> segment (e.g., broken brown or blue line), the line colour will be green for broken segments which continue with next trunk. Key ‘A’ simply toggles direction arrows visibility (either always visible or only at closer zoom levels).

The interactive segment calculator exploits two specific markers, called Delimiter A and Delimiter B. Delimiters are interactive objects that can be positioned over the map, clicked on, removed and, in some cases, they can be also dragged to a new location. To add a delimiter, click on the map and press key ‘Y’. Depending on the kind of selection before pressing this key, delimiters can be inside the path or over a generic map position. A selection outside the path (e.g., through a generic click over the map) will generate a generic delimiter, which can always be dragged together with its position. A selection inside the path (e.g., referred to a table element or to a fix point) will generate a special delimiter; its graphic object can be dragged as any other waypoint markers to improve visibility, but the related position remains statically bound to the selected fix. One or two delimiters can be added to the map in sequence (first Delimiter A, then Delimiter B). When clicking on a delimiter, a segment calculator appears as a pop-up table, showing information related to the whole path, to the relative position of the delimiter inside the path and to the correlations with the other delimiter (when available). While a delimiter outside the path offers limited correlations (not related to any path position), when both delimiters are placed inside the path, by clicking on each of them the segment calculator will display full data and computations.

In order to test the delimiters, browse the path tables below the map and, using the mouse, select an hyperlink referred to a specific fix; the map is shown and a closeup pop-up table appears in correspondence to the selected point; besides, the related selected information is also cached so that, by pressing key ‘Y’, a delimiter appears on the map over the specified fix position. Trying to drag it, the graphic object will be moved, but not its related reference position. This operation also works when clicking on any generic point of the map (i.e., outside the travelled path): after pressing ‘Y’, a draggable delimiter appears (this is different from the delimiter referring to a fix within the travelled path, which statically points to the selected position, even if the removal operation is anyway allowed). When clicking on each delimiter, the segment calculator appears, reporting computed data inside a table.

Here is an example of calculator referred to Delimiter A:

Both delimiters A and B are within the path.
Direction is Delimiter A to Delimiter B.

The initial sentence “Both delimiters A and B are within the path” means that all data are available and that both delimiters are bound to path positions. Elements in red refer to the whole path (irrespective to the delimiter position). Elements in blue are only shown in case of delimiters within the path. “Linear distance from Delimiter” refers to the most direct route between the two points, as the crow flies; it appears when both of them are available (regardless within or outside the path); all the other black elements require two delimiters linked to the path. Difference of altitude and slope only appear when related heights are available.

“Total” means whole path including stopovers (intervals while the TomTom is kept switched off) and also including junctions between separate segments (like space and time between different tracks or different track segments, also called nearby or faraway restarts). “Real” means whole path excluding stopovers and junction segments (which typically do not refer to travelled space). “Motion” reduces the travelled time to the motion periods, keeping the travelled space unaltered (i.e., it excludes all temporary suspensions of movement, like intervals when the vehicle stops for a while or moves at a speed lower than 1,4 m/sec = 5 km/h). “Units” are fixed.

When “Total” and “Real” values (both distances and times) are the same, the path consists of a set of consecutive segments (or single unbroken segment) without stopovers. When “Total” and “Real” distances are the same, but with different times, the path consists of a single unbroken segment and includes stopovers (e.g., periods when the TomTom device has been temporarily switched off for few minutes). There is no difference between “Real” and “Motion” distances. When “Real” and “Motion” periods are the same, the vehicle has always been in movement for the whole path duration.

The following picture shows two delimiters manually placed somewhere in the map (not bound to the path).

In next picture, delimiters are both are within the path.

Notice that in this picture delimiters and some waypoints have been dragged to improve visibility. Anyway, the pink line connecting both delimiters remains bound to the path.

Key ‘Z’ allows centring and zooming; it applies to zero, one or both delimiters and can be pressed once or more times. When no delimiter is available and no generic click is made over the map, key ‘Z’ simply resets the map to the original centre (i.e., default pan and zoom positions; in this case, when pressed another time, also allows the full application reset). After a generic click over a map, it centres the clicked position when pressed once and when pressed twice also opens an info window over the last clicked point with a closeup map around the position. When one delimiter is available, key ‘Z’ centres it the first time it is pressed, while the second time the related info windows appears (like clicking over the delimiter). When both delimiters are available, key ‘Z’ zooms the map to them the first time it is pressed and makes the related info windows appear in turn when subsequently pressed more times.

Considering that two delimiters define a zoom rectangular perimeter, keys ‘Y’ and ‘Z’ can be used to easily zoom a specific part of the map. For this, click over a map position (i.e., close to the top left corner of the desired zoom rectangle) and press ‘Y’ to add Delimiter A. Then click close to the bottom right corner of the zoom rectangle; press again ‘Y’ to add Delimiter B. Drag both delimiters in order to more precisely define the zoom rectangle. Press ‘Z’ to zoom. After zooming, delimiters can still be dragged to further restrict the zoom rectangle; press ‘Z’ to zoom again to the new perimeter.

Other procedures allow fast zooming. When no delimiter is set, simply click on the point to be zoomed, then press key ‘Z’ to centre this point (this is an alternative and quicker way to pan the map by dragging it through the mouse). Then press keys ‘+’ or ‘-’ (or the zoom slider) to zoom in or out. The same operation can also be accomplished through the usage of one delimiter. Click around the point to be zoomed. Press ‘y’ to add the first delimiter. Drag the delimiter to precisely position it to the centre of the zoom rectangle (you will find this operation easier than dragging the whole map). Press ‘Z’ to centre the delimiter; the map will be dragged accordingly. Finally press keys ‘+’ or ‘-’ to zoom in or out.

The following picture shows an example of map with available attributes.

The main attribute is the track path, consisting of segments which in turn plot sequence of fixes (<trkpt> elements in the GPX file). Segments are represented with subsequent red and blue “polylines” in order to highlight the related separations (<trkseg> elements in the GPX file), which typically occur in correspondence with a stopover/pull-up event (shown through a small red marker). A red interconnection segment represents separated track segments (this happens in case a new <trkseg> element within a single <trk> one is spatially separated from the previous segment).

Other than the track path, the attribute elements might also include clickable waypoints, clickable stopovers, direction arrows, clickable fix indicators. All these markers can also be dragged to improve visibility. Each of them is subsequently described.

Clickable waypoint:

It represents <wpt> elements inside the GPX file, which corresponds with Event_Logger events, like BOOT, RESUME, SUSPEND, LOG, etc. The related color might vary accordingly. The graphic object can be dragged to improve visibility.

-          red with black dot symbol in case of standard LOG event,

-          green with ‘right arrow’ symbol for initial resume event,

-          red with black square symbol in case of last suspend,

-          red with ‘S’ letter in case of intermediate suspend,

-          red with ‘R’ letter in case of intermediate resume.

Clickable stopover: this attribute represents <trk> elements in the GPX file and indicates a pull-up event (e.g., vehicle standing still for some seconds). The graphic object can be dragged to improve visibility.

Direction arrow: in the middle of a segment, indicates the direction of the path.

Clickable fix indicator:

It represents <trkpt> elements inside the GPX file, which correspond with 2d, 3d or cached fixes produced by TomTom. The related color varies accordingly:

-          red dot: 2d fix provided by TomTom while the GPS is active (latitude and longitude are available, but with no altitude);

-          gold dot: 3d fix directly provided by the GPS (latitude, longitude and altitude are available, together with many additional information elements);

-          white dot: 2d fix in TomTom cache, without GPS assistance (might be imprecise).

When the fix is clicked, the control goes to the related table element, which is also highlighted; this simply allows analyzing details. Besides, the related position is used by subsequent Y (yank), Z (zoom), G (Google Maps) operations.

As previously described, the keyboard and mouse controls allow interactive analysis; the available actions are detailed here below.

Mouse instructions:

-          Mouse left click and drag: map dragged to the mouse direction

-          Mouse left double click: zoom in

-          Mouse right double click: zoom out

-          Mouse Scroll wheel: Zoom in and zoom out

Keyboard instructions:

If Google Maps cannot be contacted, the following message is shown:

Below the map, If the browser if off-line, the following message is shown:

Your browser is set to work off-line, exploiting cached data. If you are connected to the network, set it to on-line in order to read updated content (start a new instance of Internet Explorer by pressing CTRL+N, select the File menu. There would be a tick by the 'Work Offline' option. Click it to take IE off 'Work Offline' mode; reload the GPX file).

The following table describes how to read the overall statistics.

10. Compatibility

Event_Logger is specifically designed for the all-in-one GPS TomTom devices (like TomTom GO), which exploit the ARM Linux operating system; it is not suitable for TomTom Navigator and TomTom Mobile (e.g, it does not support Poket PC, Windows CE and Symbian devices).

Event_Logger also supports TomTom models which include a disk instead of the SD card (the installation is exactly the same).

The screen functions inside Event_Logger support 240 x 320 3.5”, 320 x 240 3.5” and 480x272 4” displays (e.g., TomTom GO 700, 500, 300, Classic, ONE, OneXL, RIDER, RIDER II, GO 910, 710 and 510); in case of problems with the screen functions, they can be disabled through DoSplashTxt=never and by avoiding to run the Top and the Astronomical Calendar commands.

This version has been currently tested with NavCore 5.202, 5.420, 5.440, 5.450, 6.120, 6.140, 6.150, 6.5*, 7.13, 7.162, 7.163, 7.221, 7.45x, 8.002, 8.010, 8.011, 8.051, 8.204, 8.300, 8.320, 8.410, 8.412, 8.413, 8.350 and 8.351. Possibly, more recent versions are supported.

NavCore firmware versions 8.350 and 8.351 do not allow interacting with external applications started through menu items; what happens is that the touchscreen is shared between the started external application and NavCore, which is not brought to background (differently from all other NavCore firmware versions). The behaviour of versions 8.350 and 8.351 do not compromise the log tracking of Event_Logger, which is performed in background with no need of user interaction. Besides, the shortcut button functionality activating “Log Position to Itinerary” still works. Anyway, functionalities provided by selecting the Event_Logger menu items are unusable with the standard devshare.so included in the Tracer directory. To allow interaction with versions 8.350 and 8.351, after the installation replace the file Tracer\devshare.so with Tracer\navcore8.35x\devshare.so. In case this is not enough to overcome the display issue, try replacing file Tracer\devshare.so with Tracer\navcore8.35x_and_old_devices\devshare.so.

Event_Logger can manage all GPS units included in the current TomTom all-in-one models. Specifically, it supports SiRFstar IIe/LP Chip Set via NMEA protocol, SiRF Star III without QuickGPSfix via NMEA protocol, SiRF Star III with QuickGPSfix via SiRF binary protocol and Global Locate's Hammerhead via translated NMEA protocol (accomplished by the internal TomTom gltt daemon).

Technically, Event_Logger is a special zsh script executed by the bsh interpreter (a modified zsh shell included in the Event_Logger package); additional applications are also included (top, Astronomical Calendar). The Event_Logger loader (Tracer/mkel) also modifies /etc/rc.suspend and /etc/rc.resume files which are automatically executed by TomTom GO upon suspend and resume events. Other aspects are managed, like temporarily mounting the SD card filesystem on suspend and usage of the “File transportation layer” to invoke TomTom GO SDK functions. Some of the exploited interfaces might depend on internal TomTom GO development strategies which could change in future versions. Check at http://www.opentom.org/FileInterface for further information on the “File transportation layer” used by Event_Logger.

TomTom declares compatibility of SDK with NavCore version 6.x up to 6.15 and SDK is currently discontinued with NavCore version 7 (even if still functional).

The following SDK limitations have been empirically found with NavCore 7.

-          NavCore 7 does not provide correct city geodecoding when managing v6 maps; if NavCore 7 accesses a v6 map, when tapping on “Help me!” and then “where am I?”, the resulted street name should always be correct, but possibly not the city/town/place name, which might report a nearby place. In general, there should not be relevant reasons to introduce NavCore 7 when browsing v6 maps. The same problem happens when Event_Logger interfaces NavCore via SDK in order to retrieve a fix geodecoding; it is better to disable geodecoding (DoSdkGeodecode=no) when necessarily running NavCore 7 with a v6 map.

-          Customized menu items do not support any newly introduced icons (ref. to new V7 features), which will result missing when applying customized menus (tomtom.mnu). Notice anyway that tomtom.mnu is correctly working on NavCore 7, even if not supported; unfortunately no new entry can be added anyway, like “Help Me!” and “Map Corrections”. If Help Me is really needed, it is suggested to delete tomtom.mnu with NavCore7.

-          Newly introduced custom icons (i.e., new .CAP files) will influence the standard NavCore 7 menus by removing some of the V7 icons like “Help me” (for some NavCore 7 version) and changes the behaviour “Map Corrections” (for all the known versions). For instance, if Event_Logger is installed (hence including the related .CAP files), when pressing "Map Corrections" on screen 2, some the latest menu page appears instead of the related "Map Corrections" submenus. Anyway, when browsing the map (“Browse Map” menu item), the new “Correct location” item should always be available (it can be found when tapping on the Cursor button and it allows correcting the location shown at the cursor position). If the whole V7 menus are wanted, it is better to delete all the .CAP files in the SdkRegistry directory (or simply rename the SdkRegistry directory); Event_Logger will still continue to work in background, but without possibility of user interaction.

-          Occasionally, the SDK API response of NavCore 7 may be very slow, taking a lot of seconds. This include also geopositioning, geodecoding and providing flashing information on the display. A feature on Event_Logger overcomes this problem when BkupFixFromGps is set to yes. An hint to speed up the generation of the final flashing message after selecting “Log Position to Itinerary” is to try tapping on the display and navigating through menus.

To better clarify, Event_Logger has nothing to do with these limitations, which are completely related to the unsupported SDK of NavCore 7.

The Itinerary files produced by Event_Logger follow the TomTom GO specifications and should be compatible with any TomTom software supporting them.

Usage of SDK function can be controlled through the following configuration variables (SDK functions are activated when the variables are set to “yes”; unsetting or commenting them out will disable the related SDK options):

# NOTE: avoid using spaces in any filename

See also “Poi” configuration variables subsequently described.

The embedded tracking system follows the GPX 1.0 specifications and should allow interfacing any GIS, mapping or analysis tool accepting the GPX 1.0 format. GPX files produced by Event_Logger should pass the validation described at http://www.topografix.com/gpx_validation.asp.

GPX files produced by Event_Logger have been tested for compatibility with:

o        TopoFusion (all versions; specifically, v. 2.85 was successfully tested; v.3.21 is a very stable release)

o        GPS Visualizer (on-line tool)

o        GPSBabel (converts GPS route and waypoint data from one format type to another. GPS Visualizer also provides a Web interface to GPSBabel).

o        TopoGrafix EasyGPS and ExpertGPS (all versions; specifically, v. 1.3.7 was tested)

o        Google Earth (tested versions: 3.0.0616 beta and 3.0.0762)

o        uTrack (on-line GPX track report generator which produces HTML and PDF maps including information about elevation, speed, time and calculating flat and real distance).

GPX.XSL is only compatible with Internet Explorer version 6 and 7. Tested Google Maps API versions are 2.81 and all more recent ones.

11. Installation

o        Download the latest release of the Event_Logger software from http://web.tiscali.it/macri/Event_Logger; the downloaded zip package includes everything: software, documentation, sources; only the software should be installed on the TomTom device.

o        In case a ReadMe.txt file is available inside the Event_Logger archive, this includes the latest version information which might not be fully documented here.

o        Verify that the PC used for the installation has the date reasonably adjusted. This is because, in case of hard reset of TomTom device, Event_Logger will set the TomTom GO date to the last modification time of the Event_Logger.txt file (this also takes correctly care of the LinuxTimeIsUTC variable). In relation to the feature that automatically syncs the date with the GPS device, the last part of this chapter reports a detailed description of possible reboot issues and how to overcome them.

o        Unzip the Event_Logger zip archive and place the files in the TomTom GO SD card (or HD device, when supported instead of the SD), respecting directories and cases; directories must be created if not existing. The Sources directory is not needed on the TomTom device and may not be extracted or can be deleted in any moment to save space. A typical error during this operation is to save all the files in the same flat directory instead of respecting the directory structure of the ZIP installation archive. Renaming files or file extensions are other errors (also renaming cases is not allowed).

o        For instance, in case the TomTom GO file system is named “H:” when mounted to an external system via USB, verify that the following files have been installed:

o        H:\cleanup.txt (notice that H:\ttn of any previous Event_Logger version must be deleted)

o        H:\ttn (only needed in case of NavCore version 8.2 or higher)

o        H:\Tracer\acal

o        H:\Tracer\bsh.bz2

o        H:\Tracer\bz2cat

o        H:\Tracer\Event_Logger.txt

(Event_Logger.txt can be configured through any Windows editor, regardless of DOS or UNIX newlines)

o        H:\Tracer\mkel

o        H:\Tracer\toggledata

o        H:\Tracer\toggledmn

o        H:\Tracer\toggletrk

o        H:\Tracer\togglelog

o        H:\Tracer\top

o        H:\Tracer\zip

o        H:\Tracer\wd

o        H:\Tracer\gpsbabel (default is not to use it; can be deleted if not needed, to save considerable space)

o        H:\Tracer\zip3 (default is not to use it; can be deleted if not needed, to save space)

o        H:\Itn\gpx.xsl (should be also copied in all the directories including unzipped gpx files)

o        H:\Itn\gpxMilesFeet.xsl.xsl (rename to gpx.xsl replacing the original file when using miles)

o        H:\SdkRegistry\acal.cap

o        H:\SdkRegistry\logpoi.cap

o        H:\SdkRegistry\logpos.cap

o        H:\SdkRegistry\toggledata.cap

o        H:\SdkRegistry\toggledmn.cap (can be deleted if the “Toggle Event_Logger Agent” command is unwanted)

o        H:\SdkRegistry\toggletrk.cap (can be deleted if the “Toggle GPX Tracer” command is unwanted)

o        H:\SdkRegistry\togglelog.cap (can be deleted if the “Toggle Debug Level” command is unwanted)

o        H:\SdkRegistry\top.cap (can be deleted if the “Top” command is unwanted)

o        Menu icons:

• H:\SdkRegistry\acal.bmp
• H:\SdkRegistry\logpoi.bmp
• H:\SdkRegistry\logpos.bmp
• H:\SdkRegistry\toggledata.bmp
• H:\SdkRegistry\toggledmn.bmp
• H:\SdkRegistry\togglelog.bmp
• H:\SdkRegistry\toggletrk.bmp
• H:\SdkRegistry\top.bmp

o        In case H:\cleanup.txt is already available because a different SDK program is installed, add the following line to the existing file instead of replacing it:

daemon|Tracer/mkel|

(NOTE: H:\cleanup.txt must have only one recurrence of the previous command.)

o        Remove H:\ttpnpd (if existing) of any beta Event_Logger version (important)

o        If a tomtom.mnu file is already available in the SdkRegistry directory of the TomTom device, that file should be modified in order to include the new eight menu entries. Notice that only two additional menu options are supported by the current versions of NavCore (max 10 custom menu items in total). Using a tomtom.mnu file with NavCore 7 is discouraged (see the Compatibility chapter).

o        The following Event_Logger buttons are suggested not to be installed (they can be removed from the SdkRegistry directory in any moment): top.cap, toggledmn.cap, togglelog.cap (this simplifies the TomTom menu and allows installing additional custom functions). Event_Logger can even run without .cap files in the “SdkRegistry” directory (of course, no user interaction will be available in that case).

o        Edit the Event_Logger.txt script inside the Tracer directory with any editor (including notepad) and set at least the variables LANGUAGE and TIMEZONE (see related paragraphs); if English units are preferred, check the Localization paragraph. Verify that the Debug variable is set to 0 (set it to 5 in case of trouble).

o        In order to upgrade from previous versions of Event_Logger, all the files included in the new archive must replace the old ones installed in the SD card (or HD); besides, two files have to be renamed and some have to be removed.

• Check presence of file _Logger.itn in “Itn” directory; if existing, rename it to _Latest_Events.itn.
• Check presence of file EventLogger.tgz inside “Itn” directory: they can be can be moved in Itn\Bkp directory (the Bkp directory inside Itn one can be created if not existing, otherwise Event_Logger automatically creates it to store backup files).
• Check presence of file expr in "Tracer" directory; if existing, it can be safely removed.
• All log files called ttnlog-<date>.txt, TtnLog.txt, BootLog.txt, TrxLog.txt, trxlog-<date>.txt in “Tracer” directory or in the root directory can be removed. If a file called “GpsLogger” exists in the "Tracer" directory, it can be removed (anyway, before deleting them, with the WordPad editor please check the presence of the string _Event_Logger_Script_ERROR_ inside each of them; if this string exists, email the files to amacri@tiscali.it).
• If the directory Traces exists inside the Tracer directory, it can be archived out and then removed (now every GPX file is generated inside the itn directory.

NOTES:

o        IMPORTANT WARNING: no more than 10 “.cap” files are allowed in the “SdkRegistry” directory. The TomTom GO application will crash when exceeding this number.

o        Notice that the directory “SdkRegistry” under the root of the SD card (or HD) must be created, if not already existing.

o        Verify that the itn directory exists in the SD card (or HD); alternatively, create it (under the root; three letters, all lowercase).

o        bsh.bz2 in the "Tracer" directory must not be substituted with its unzipped version (e.g., leave it zipped in order to save space of the SD card (or HD): the boot installer will automatically unpack it in the RAM file system).

o        Event_Logger.txt in the "Tracer" directory can be edited with any editor (including notepad) and can safely include the DOS/Windows newline format (0x0D, 0x0A).

o        The file called “mkel” in the Tracer directory is a simple installer that does not need to be edited (all configurations settings are included in Event_Logger.txt). In case a modification is anyway needed, verify to use an editor able to manage UNIX newlines (hex 0x0A, not the DOS format 0x0D, 0x0A).

o        The instruction files (PDF or TXT files) as well as the sources (Sources directory and Sources.zip archive) which might be included in the Event_Logger archive can be either deleted from TomTom device or simply not installed to save space.

o        Setting the owner's preferences (a specific menu of TomTom) is discouraged with NavCore 6.210 (it might freeze SDK functions until the "Continue" button is pressed). Other v.6 NavCore versions are untested against this issue.

A random menu reset to the initial menu page might happen while navigating into the menus (typically after powering the device on; this is due to a small glitch in NavCore while processing the Event_Logger command changing night/day colours).

When devshare.so is available inside the Tracer directory, the tracking granularity can be configured up to two seconds; notice that this takes additional CPU resources. Remove or rename devshare.so for standard operation (by default files devshare.so and ttn are both positioned in the startup subdirectory, so that the related functions are disabled). NavCore firmware versions 8.350 and 8.351 require specific devshare.so, as already described (replace the file Tracer\devshare.so with Tracer\navcore8.35x\devshare.so. In case this is not enough to overcome the display issue, try replacing file Tracer\devshare.so with Tracer\navcore8.35x_and_old_devices\devshare.so).

For TomTom devices supporting an internal SD or hard disk as well as external SD card, Event_Logger allow installation on either memory. If the external SD card includes a directory named itn (which the user has to manually create in advance), the GPX logs are archived on that directory instead of exploiting the default itn directory of the internal TomTom memory (this might be useful when the space of the internal memory is very limited). Besides, if the external SD card also includes the “Tracer” directory, Event_Logger is executed from that directory (anyway, cleanup.txt and ttn must be in the root directory of the internal memory and a directory named “Tracer” including at least mkel has to be installed in the internal memory). If for some reason Event_Logger is required to run on a specific card or different hard disk from the previously described process (e.g., both Tracer and Itn directory on an external SD card also including the whole TomTom program and maps), simply create a null file called “hererun” (with no double quotes and no txt extension) inside the related Tracer directory.

While installing Event_Logger for the first time, some unsolicited reboot might happen. This is because current versions of NavCore have an issue related to first date settings which might cause an initial instability of NavCore while the TomTom time is not yet in sync with the Linux system date. When Linux system time gets synchronized with NavCore time, no additional reboot will happen over the long time. Pressing the hard reboot (discouraged) resets the Linux system time and might cause reboots until both NavCore and Linux get synced through the GPS timing.

More in detail, the very initial time TomTom is switched on (or e.g., after an hard reset), the TomTom internal system clock defaults to a predefined old date (set in the firmware or in the Linux O.S.). NavCore allows adjusting its internal time (which is shown on the display) through an appropriate menu; in order to automatically set the clock's time to the GPS time, tap on the screen, press “Change preferences”, “Set Clock” and “Sync”, then use the arrow buttons to set the hours, confirming your time zone. This standard procedure will not change the Linux system date, it only manages an internal time adjustment inside NavCore. Anyway, Event_Logger requires that the Linux system date is also correctly set in order to perform valid history logging. For this reason, Event_Logger tries to perform a system date sync through the GPS unit each time the device is switched off and each time the “Log position to Itinerary” button is manually pressed; there is also an auto date sync in case the last modification date of Event_Logger is more recent than the current Linux system time (in this case, typically happening after an hard boot, if no GPX timing is available, the modification time of Event_Logger is used to set the operating system clock). Unfortunately, NavCore might perform a reboot when an external application changes the system date under some circumstances. Consider anyway that, after the first stabilization period, surely no additional reboot should happen over the long time.

The procedure to solve the continuous reboots should be the following: after installing Event_Logger, verify that TomTom is placed in a zone at open air where it can receive GPS satellites, then boot it, wait for the first fix, press "Log position to Itinerary" more times in order to produce a system date sync, then go to the NavCore clock settings, change the clock accordingly so that also NavCore reports a correct time, press again "Log position to Itinerary" and verify that the date is no more changed (clock settings in NavCore should keep a valid time), then power down the device (still under GPS reception). Wait for 10 minutes. Power it on again under GPS reception, wait for the fix, verify that the NavCore date is ok, press "Log position to Itinerary", verify that NavCore date is not changed. Power off the device. After this procedure, the date is synced and no additional reboot should happen.

Upon an hard reset (when pressing the reset button by inserting a straightened paper clip in the reset hole on the unit's bottom) you might happen to suffer some reboots and have to repeat this tedious operation in order to fix the problem.

Anyway, you should never have to perform an hard reset of the TomTom device under normal circumstances.

It is normal that Top reports three Event_Logger instances concurrently running: this is because Event_Logger consists of a Posix milti-threaded application which is shown in such a way by Linux /proc. Actually, only one single process and memory resource are used of the three shown Linux tasks.

Files created by Event_Logger inside the Tracer directory are for internal usage. Target GPX and ITN files can be found inside the Itn directory.

If the automatic start-up of Event_Logger at boot time is not wanted, a null file named noeventlogger can be created in the root directory of NavCore (where also the file ttsystem can be found). Event_Logger will be started at the first pressure of the “Log Position to Itinerary” button icon.

Setting NoWatchDog=yes has the effect to inhibit the standard NavCore watchdog agent and to start a custom agent included in Event_Logger, which prevents NavCore reboots under certain conditions; this setting is generally not needed and becomes active after an initial reboot. In order to avoid this initial reboot, a null file named nowatchdog can be created in the root directory of NavCore (where also ttsystem can be found).

This version also allows compatibility with Height (http://gps.dg4sfw.de/index.php/menuid=57). Notice anyway that the ttn file to install on TomTom should be the one included in Event_Logger, not the one insight Height.

12. Configuration

After the initial configuration, use the TomTom unit for one or two days before verifying the quality of information produced by Event_Logger. This is because of the date synchronization issues that need some stabilization. During the first day after the configuration, be sure to switch off and on the TomTom unit at least one or two times while the GPS is active, so that the correct date is acquired and set; then tap on your device, press "Change preferences", tap on "Set Clock", adjust the hours, tap on the 'Sync' button, eventually repeat the operation until "hours" and "minutes" are correctly set. Notice that upon each hard reset (e.g., operating the reset hole on the unit's bottom), this operation should be repeated.

Configuration can be accomplished by editing Event_Logger.txt inside the Tracer directory. The standard for assignments is zsh (e.g., like sh, bash). Notice that in numeric values the decimal point is always the dot. Notice also that in all assignments no spaces must be inserted before and after the "equal" symbol ('='). Everything is case sensitive.

The TIMEZONE variable at the beginning of the Event_Logger.txt script should be set to the target time zone offset from UTC using the format +/-hhmm without any acronym; notice that there is no specific switch for daylight saving, which must be managed changing the TIMEZONE variable accordingly; so, TIMEZONE must represent the local time including daylight saving when needed (e.g., ‘+0000’ for GMT or UTC, ‘-0700’ for US & Canada Mountain Time, which is GMT-07:00, ‘+0100’ for WEST – West Europe Standard Time, which is GMT+01:00, ‘+0200’ for WEDT – West Europe Daylight Saving Time, which is GMT+01:00+01:00=GMT+02:00, etc.).

The variables related to time synchronization are the following:

If the variable SyncTime is set to yes, time synchronization is enabled: this means that each time the TomTom GO is being suspended (not booted or resumed) with good enough radio reception of the GPS signal, the date is automatically set to the satellite time. The selection of the Log menu button (generating “log” events) can also perform a time synchronization. As soon as an Event_Logger time synchronization happens, the TomTom GO clock changes accordingly, apart from the time zone shift which should be set manually in case the variable LinuxTimeIsUTC is set to yes (which is required for NavCore 6); in this case, simply adjust hours manually and only once, e.g., just at the first time sync after an hard reset. If the time synchronization is not wanted within Event_Logger, unset SyncTime (or set it to no instead of yes). In case of NavCore 6, the Event_Logger time sync can be used in parallel to the built-in SAT sync tool of TomTom GO, provided that LinuxTimeIsUTC is set to yes. (For older firmware versions, set LinuxTimeIsUTC to no.)

The variable DateCalibration allows compensating the internal delay inserted by Event_Logger from the time returned by the GPS to the instant when the synchronization is actually performed.

The configuration section of Event_Logger includes a set of additional variables (e.g., labels and file names) which can be used by experienced shell programmers to customize execution. Related documentation is included in the code. Avoid including spaces in file names and in all the variables which have a default value without spaces, as the result is not tested (might even produce loss of data). Avoid also special characters, unless you are sure of the related escaping methods within a shell script. Pay attention to change the date formats, as only a subset of strings is allowed. Exchanging the position of month and day can anyway be done.

In order to manage some locale strings, the variable LANGUAGE needs to be set to either IT, FR, EN, DE, NO, NL.

Additional languages can be added by adding new sections within the case/esac expression involving the variable LANGUAGE and by changing the variables:

• UnnamedRoadString1,
• UnnamedRoadString2.
• TargetWords,

E.g., a new language can be added after the NL) case and before the *) case through new lines similar to the following:

<new language>)

UnnamedRoadString1=’<…>’

UnnamedRoadString2=’<…>’

TargetWords=(… … …) # list of months and days of the week

;; # do not forget this sepataror

The variable “TargetWords” refers to date strings included in GPX files, as well as to the extended date reported into the itinerary file when the first event of each day occurs. UnnamedRoadString1 and UnnamedRoadString2 corresponds to the strings produced by the geodecoding function of the TomTom GO application in case of unknown or unnamed places; by setting these variables, the related values will be discarded by Event_Logger improving log readability. The language translation used by default is English.

Event_Logger.txt must be a plain ISO-8859-1 ascii file in MSDOS format (with DOS/WINDOWS line separators, using <CR><LF>). Unfortunately, the BSH interpreter (which executes Event_Logger.txt) does not support Unicode or UTF-8 character-encoding systems. This means that Asian characters are not allowed (specifically, Greek, Slavic, Arabic, Chinese or Japanese comments cannot be included inside translations).

The following switches control the general behaviour of Event_Logger and allow configuring it for promiscuous usage, preserving privacy (no positioning data permanently written on the SD or HD) in case the same TomTom GO device is managed by more people:

To disable the “Log Position to Itinerary” shortcut button function is not wanted (function activation by pressing the top left margin of the screen), set DoWtchScrFld variable to no.

In case custom menus are not supported by your TomTom version, copy all files of SdkRegistry/Geo to SdkRegistry; then menus are available as map position detail elements (menu à second page à Browse map  à Navigator icon (  ).

See the paragraph related privacy concerns in order to appropriately configure Event_Logger for promiscuous usage.

Other strings and symbols can be customized, as documented inside the configuration section of Event_Logger.txt.

13. Localization

Event_Logger by default uses the English language. Apart from the Astronomical Calendar and TOP applications, which are separate C written programs, all the other expressions of Event_Logger can be translated in other languages by changing the strings available in Event_Logger.txt.

Some basic parts described in the previous chapter are affected by the variable LANGUAGE, which can be set to all the supported locales.

Unit conversions can also be localized; the default configuration represents distance in km, speed in km/h and altitude in m.

For English units, set the following variables:

-          DistanceUnit="ml" # Default=km

-          SpeedUnit="mph" # Default=km/h

-          AltitudeUnit="ft" # Default=m

-          UseMiles=yes # Default=no

-          kmhToMilesh=yes # default=no

-          mToFeet to yes # default=no

-          E_RADIUS=3963.0 # statute miles; (meters=6378.137; nautical miles=3437.74677)

-          MilesToKm=1.609 # default=1.609; for nautical miles, set it to 1.852

For English language, other than setting LANGUAGE=EN, you might also want to exchange the position of month and day in all date formats (e.g., DateFormat and LongDateFormat).

# Date formats (English locale):

DateFormat="%I:%M %p" # Date for ITN records with current, valid fix (untested, alternative setting)

LongDateFormat="%m/%d %I:%M %p" # Date included in description records (untested, alternative setting).

Today="%A %B %e %Y" # Date included in the new day notifications (untested, alternative setting).

Date and time formats:

Variables MinSpeed and MaxSpeedToShowPoint, provided for tuning purpose, do not require unit conversion (also when UseMiles=yes): set MinSpeed always using m/sec and MaxSpeedToShowPoint always using km/h.

Notice that unit conversion does not affect values inside GPX files (apart from comments); this is because the GPX standard format specifies the fixed units to be used.

Specific menu items presented by TomTom and pointing to Event_Logger functions can be localized editing the related “.cap” files in the SdkRegistry directory of the SD card (or HD). These files cannot be opened by notepad; use a UNIX style editor like Ultraedit instead. The message to change is the fourth token (the last one) of the last line, with format “COMMAND|CMD||<icon file name>|<message to be localized>|”.

Example (English to Italian):

COMMAND|CMD||toggledmn.bmp|Toggle Event_Logger Agent|

COMMAND|CMD||toggledmn.bmp|Attiva o disattiva Event_Logger|

GPX.XSL can be edited with any application, including notepad, in order to support different numeric formats. By default, the Italian notation is selected. In order to enable the English numeric settings, search for “START OF CONFIGURATION SECTION“,remove the italian lines and uncomment the English ones (in order to perform this, remove the comment lines “<!-“ … and “-->” after “<!-- English -->”; in fact, “ <!- “ means start of comment, while “ --> “ represents the end of comment).

Italian (default):

English:

Any other message produced by the GPX browser can be either included in GPX.XSL (search for it and change it to your language) or in the GPX file itself.

14. Altitude and distance calibration

The altimeter functionality provided by Event_Logger always produces Mean Sea Level (MSL) values. For older TomTom devices (hosting the SIRF GSP2e/LP-7451 GPS device which only implements the WGS-84 ellipsoid model and does not support either the SiRF binary 0x29 message or “Geoid Separation” within NMEA GGA messages) this value is obtained by Event_Logger by summing up the altitude produced by the device to the geoid separation value, dynamically calculated by Event_Logger basing on latitude and longitude; for newer models, the MSL altitude is directly generated by the internal GPS device and fetched by Event_Logger. The algorithm used by Event_Logger to compute the geoid separation for old TomTom models exploits a function available in the GPSD project. The Event_Logger variable GeoidHeight can be used to statically setting a further linear translation correction to the automatically computed values, when this calibration is really needed; in normal operation this variable should be left initialized to 0.

Event_Logger produces the travelled distance of each trip by summing up all the distances of the fixes queried by the Event_Logger agent, each compared with the previous one; the distance of each pair of fixes (e.g., the current and its previous one) is calculated exploiting the Great Circle Distance Formula. In order to produce more accurate results, fixes with HDOP = 20 or greater are ignored. The computation first provides a fraction of the Earth radius, which is then multiplied by the value stored in the E_RADIUS variable, defaulted in Event_Logger to 6378.137 kilometres (value compatible with Google Maps); anyway, E_RADIUS can be set to whatever unit and value: 3437.74677 nautical miles or 3963.0 statute miles for instance. By changing the value, the distance can be calibrated. Notice that the formula used by Event_Logger does not currently consider differences of altitude, so the result should be rather precise when the whole trip is over a flat land, while errors are introduced in case of steep roads, e.g. in the mountains (these roads should result slightly shorter than the actual length).

An optional feature of Event_Logger allows showing the display popup of altitude (above sea level) and normalized slope (percent) each time this information is received by the GPS and roughly every minute. Set ShowAltitude=yes in order to enable this function. The display method is the same of all other popup messages (and consequently it is subjected to the NavCore delay issue; if prompter popup timing is needed, tap on the screen to select a different mask, like a TomTom menu). Each popup message remains active on the screen for four seconds (ref. AltDuration variable). By switching to off-road (e.g., long off road travel) this popup is shown every polling time (ref. TrackingGranularity variable) whenever a GPS 3D fix (including altitude) is fetched.

15. Basic usage

After following the installation instructions, use TomTom GO normally. The Event_Logger automatically generates GPX and Itinerary files under the itn directory of the TomTom GO SD card (or HD) with past files zipped in appropriate archives inside the same directory. Itinerary files can be opened and edited through TomTom GO. The most recent of them is called _Latest_Events.itn (its name can be changed through the variable ITNName). Each time _Latest_Events.itn is opened inside TomTom GO, it reports the updated list of events occurred during the current day. In order to manage itineraries within TomTom GO, tap roughly in the middle of the TomTom GO display and let the options menu appear. Tap on the arrow button one or more times, until the “Itinerary planning” or “Log Position to Itinerary” icons appear (the latter referring to the menu button). In order to browse the generated event log, tap on the “Itinerary planning” icon, select Options, open a new Itinerary File and select _Latest_Events.itn; confirm all prompts until the file content is presented; scroll the logged events through the up and down arrows (the last event at the bottom is the most recent); press on any listed event and keep it pressed in order to read the whole description; tap in any listed events in order to let the related menu appear; “position” is one of the presented option and, by tapping on it, the related point location in the map will be shown; if the position icon is grey and cannot be selected, the related event is not provided with positioning data and will be also barred in the listing. Return back to the main TomTom GO menu and tap on “Log Position to Itinerary” in order to record the data related to the current position (this operation will take some seconds). Verify the flashing information appearing on the screen after some seconds. Then open again the _Latest_Events.itn file to see the updated data.

16. Aggregate Records

If for example the vehicle is parked, then powered off, then restarted, moved in order to find a better position and then powered off again, all those events are registered by the program, but it would be worthwhile to aggregate them into only one record to improve readability, instead of generating many different trips: actually this is performed by a specific option of the program. More generally, in case more events occur within a short timeframe, they can be aggregated into only one line of event, showing only the last of them (e.g., the last date), the last valid position acquired and the time difference between the first aggregated event and the last one; in this case, the trip is not broken down into many trunks, so that the total journey duration will consider the whole timeframe, while the real journey duration will be calculated by summing up all the power on timeframes. This capability is controlled by the variable “ShortInterval”. All events occurring within the ShortInterval timeframe expressed in minutes (with no decimals) are aggregated. A value of 0 can be set and indicates the same minute. ShortInterval can also be set to -1 in order to disable the feature.

Basing on aggregate records, Event_Logger can thus calculate the trip duration of each journey (total journey duration, real journey duration, total stop duration).

Configuration details for aggregate records:

ShortInterval=6 # Minutes. More events are aggregated into one if happening within this

 # timeframe in minutes. Set ShortInterval=-1 to disable this feature.

Rounding=31 # Rounding of seconds to the nearest minute in date calculations (including computation delays)

17. Points of Interest

Optionally, Event_Logger can generate Points of Interest (POIs). Each managed event can virtually generate a POI (e.g., each waypoint or Itinerary entry). POI creation is controlled through appropriate configuration variables; the variable DoSdkAddPoi enables or disables the feature. PoiEventFilter can be used to restrict the event types which produce POIs (default is that only POI events produce POIs). Event_Logger version 7 comes with two menu buttons: by default POI generation is disabled for the standard “Log Event To Itinerary” menu button (LOG), while is activated for the POI button. Notice that the script can virtually support more types of log events (e.g., LOG, NOPOI, etc.), where only a subset of them (e.g., POI) can produce POIs; this allows controlling POI creation through appropriate additional menu buttons. The variable PoiFileName represents the trailer part of the name of the TomTom GO POI category were POIs are stored: the whole file name is composed by adding the <event> header to the variable PoiFileName, and by applying the “.ov2” extension; optionally, an icon file can be manually associated to it.

More in detail, usage of SDK function controlling POI creation can be configured through the following variables:

DoSdkAddPoi=yes # Set to yes in order to add POIs to file <event>$PoiFileName

                # upon events described in PoiEventFilter (otherwise unset)

PoiEventFilter='POI' # Quoted list of events separated by '|' generating a Poi if

                     # DoSdkAddPoi=yes (e.g.: 'RESUME|POI|LOG' or '*')

PoiFileName=_Tracker # File to be created in the current "Map" directory, hosting

                     # the POIs added through $DoSdkAddPoi and $PoiEventFilter. Full Filename is

                     # <event type>$PoiFileName.ov2; e.g., POI_Tracker.ov2 (An icon file

                     # <event type>$PoiFileName.bmp can be manually saved there if needed.)

Differentiation of LOG events can be either obtained by calling Event_Logger with different arguments or by linking the filename to different other names internally managed by the Event_Logger script (TomTom GO version 5.420 and TomTom GO 5.440 only support the second option). In order to add an additional link, see the code inside the mkel file (e.g., duplicate the “ln” instruction to a different name); an additional “.cap” file should also be created in the “SdkRegistry” directory, basing on “logpos.cap” and calling the new link; then, to associate a new event to a different file name, check inside the Event_Logger script (at the beginning of the MAIN section).

18. Logging details

Logged events include:

o        Each boot occurrence, marked as appropriate barred lines, registered when powering on the TomTom GO after a physical reset or after an external modification of the SD card.

o        Suspend events, registered when powering off the TomTom GO through the power button; if the TomTom GO is appropriately connected to the vehicle ignition, this event automatically occurs, driven by the vehicle. The “suspend” events can be distinguished by the “resume” ones because marked with appropriate icon and separator line.

o        Resume events, registered when powering on the TomTom GO after a suspend event; if the TomTom GO is appropriately connected to the vehicle ignition, also this event automatically occurs. “Resume” events can be distinguished by “log” ones because occurring after a Suspend or boot.

o        Log events, registered when pressing the “Log Event To Itinerary” menu button of TomTom GO. These events are similar to “resume” events but include an asterisk within the description in order to be easily recognised; they can also be distinguished by “resume” events because occurring after a “resume” (or ”log”) and before a ”suspend”.

o        Each date change: if a date is automatically changed by the internal synchronization algorithm, two barred lines are reported in the Itinerary file, reporting the previous and new dates.

o        Each occurrence of log rotation: this refers to the rename operations of log file in order to separately archive old information. Logs are automatically renamed each day and in case the number of lines exceeds $MaxItnLines (set to 45 by default). Notice that currently TomTom GO cannot coop with Itinerary files including more than 48 lines.

Event_Logger can be easily upgraded in order to include more kind of log events, activated by more menu buttons.

For a detailed description of the information logged upon each event, see chapter “Itinerary file formats”; in summary, relevant data include:

·         event type (start, stop, boot, log events, appropriately shown by TomTom GO)

·         date and time of the event (date is shown through a specific line at the beginning of the Itinerary file);

·         information related to the duration of the journey

·         flags indicating whether the position is up to date;

·         information about aggregated events

·         position (in case this information is provided by the GPS; otherwise, the latest valid stored positioning is reused);

·         altitude (when available);

·         speed (when available);

·         address (geodecoded position, when available).

Date, time and duration are always present and refer to the current TomTom GO clock (possibly but not always synchronized with the satellite: as mentioned, date synchronization happens during the “log” or “”suspend” events, provided that there is good enough satellite coverage when these events occur). Notice that, as Event_Logger exploits date comparisons for its core algorithms, synchronization is mandatory: in case the Event_Logger date sync tool is disabled, an external date synchronization tool must be enabled. However, it is not a good idea to have two or more date synchronization tools concurrently active (e.g., if the Event_Logger date sync is enabled, no external tool should be left running). The most important point is to avoid using the TomTom GO built-in manual sync method, which only inserts a time shift inside TomTom GO without updating the Linux system clock (so, this kind of shift is only partially perceived by Event_Logger, causing improper behaviour). In case the manual date sync option included in TomTom GO is accidentally used when a Linux time synchronization tool is active (e.g., when the Event_Logger date sync is enabled), the possibly improper time shift which might occur in the visualized time should be deleted through an hard reset of the TomTom GO.

Example of generated Itinerary file:

1.     0|0|From Log-05-10-04_21.18.itn|1|

2.     0|0|Tuesday 4 October 2005|1|

3.     0|0|Boot 04/10 10:26|2|

4.     922948|4554766|10:27^-1 88.0km/h|0|

5.     920982|4552277|10:32 181.9m 4.0km/h* [5'] Viale Fulvio Testi, Bicocca (Milano)|1|

6.     920654|4551402|10:37 184.4m [10']|3|

7.     920654|4551402|20:47 184.4m {10:10} Via Giovanni Silvestri 10, Bicocca (Milano)|1|

8.     920781|4551381|20:54! 187.4m 14.0km/h* [8'] Viale Sarca 160, Bicocca (Milano)|1|

9.     922948|4554766|21:05^-1 5.0km/h [11',10']|3|

10.  0|0|Rotated on 05/10 05:58|2|

Notice first that each record sting is made up of four fields, where the third one is the actual string message shown by TomTom GO, while the first two fields indicate the two-dimensional geoposition and the last field (which can be 0, 1, 2, 3, 4) informs TomTom GO of the record type (e.g., 0 and 1 are for “start” and 3 for “stop”; record with 0 or 2 and all records before are marked as already visited.

The first line will be shown barred and grey by TomTom GO (e.g., place already visited with wrong/unknown position) and indicates that the previous log is the file named “Log-05-10-04_21.18.itn” (tap this line in order to read all the characters). Besides, the name of the file highlights that the last event included in this file happened on October 4, 2005 at 21:18.

The second line shows the date when all the events of the current file happened (this date can be fully customized through the variable $Today following DATE(1) formats). Also this line is shown barred and grey by TomTom GO in order to better distinguish comments from standard positioning records.

The third line informs that on October 4 at 10:26 a boot happened.

The fourth line represents the start of a trip. Notice that symbol “^” informs that there was no radio coverage when the vehicle was powered on (e.g., booted in our case) and so the position was referred to a previous event (e.g., that might be found in file Log-05-10-04_21.18.itn; notice that there are still cases where an outdated position is anyway correct, e.g., if the GPS data were correctly saved during previous powered off). Following the hour when the event happened and the symbol of outdate positioning and altitude, there is the string “-1” (aggregate record); it means that the vehicle was first powered on one minute before the shown date, then finally restarted at 10:27 (maybe that was necessary to open a gate).

The fifth line is a mark obtained by pressing the menu button (see the asterisk). In that time the journey took 5 minutes. Speed, altitude and address (geodecoded position) are shown.

The sixth line refers to the end of the trip and it is shown with a stop mark by TomTom GO (see the flag 3 at the end of the record). As altitude is included, position is supposed to be correct (notice that for a limitation in the current version produces the missing address in suspend records). Speed is not reported: this means that the vehicle was supposed to be stopped while turning ignition off (i.e., TomTom GO suspended).

The seventh line is the start of a new trip. Find the stop duration inside braces. (Resume events correctly calculate the address).

The eighth line, happening after 8 minutes, has an exclamation mark representing cached information (possibly inexact).

The ninth line (aggregate record) indicates a stop and restart which took one minute. The total trip duration took 11 minutes (time elapsed from the first start to the last stop), while ignition was switched on for 10 minutes (i.e., there was a stop of one minute at the end of the trip).

The last line (shown barred and grey by TomTom GO) documents the log rotation happened the day after.

By default, when the "advanced statistics" splash screen is selected, no event is recorded (e.g., LOG events are not recorded for both ITN files and GPX ones), unless the IgnLongList variable is set to yes. The "advanced statistics" behaviour is influenced by the variable WaitBeforeHold, which allows configuring the timeout in seconds to keep the touchscreen pressed before the splash is frozen; after freezinf the screen, a second pressure will make the splash disappear. By default this variable is set to 5 seconds; when set to 0 seconds, the finger can be immediately released with the splash frozen.

19. Management of old information

The itn directory includes “_Latest_Events.itn” (last Itinerary file) and “Trk_Last_Path.gpx” (last GPX file), as well as the past files, named “Log-yy-mm-dd_HH.MM[.n].itn” (past ITN files) and “Trk_yy-mm-dd_HH.MM.ss.gpx” (past GPX files). The number of Itinerary and GPX files kept on-line by Event_Logger are controlled by the variables OldItnToKeepOnline and OldGpxToKeepOnline. All previous files are automatically saved in zipped archives called ItnArchive.zip and GpxArchive.zip (always inside the itn directory) in order to save space.

The archiving process can be controlled through the following configuration variables:

Archiving functionalities used in Event_Logger (since version 6.4) exploit Info-zip, which is a free, portable, high-quality version of the Zip compressor-archiver utility (as well as UnZip, not used by Event_Logger). Zip 2.32 (the used version) can be downloaded from http://ftp.info-zip.org/pub/infozip/Zip.html or http://ftp.info-zip.org/pub/infozip/src/zip232.tar.gz; the “zip” executable was produced through the cygwin gcc cross-compiler for ARM Linux, always using –O3 option, then stripped. Info-ZIP is highly compatible and many applications, including WinZip, exploit it.

Archiving can also take advantage of password based encryption as described in paragraph “Privacy concerns”.

In order to improve resilience in case of fault while producing a ZIP, an additional automatic backup copy of old ITN and GPX archives is performed when DoArchiveBackup=yes; the produced clones are saved inside the Bkp directory; ItnBkpArchive and GpxBkpArchive variables control the related pathnames. As the ZIP process takes relevant time especially to update big archives, the maximum archive size of each single file can be controlled through MaxSzItnArc and MaxSzGpxArc.

Optionally, Event_Logger supports the bzip2 compression method, which often gives a better compression ratio than standard zip deflate, at the cost of greater CPU time. Notice that bzip2 compression method requires a modern unzip.  Before using bzip2 compression, please verify that a modern UnZip program with bzip2 support will be used to read the resulting zip archives so that entries compressed with bzip2 (compression method 12) can be read.  Older unzips probably won't recognize the compression method and will skip those entries. Info-ZIP Zip 3.0f BETA (September 24th 2007) has been included in the Sources directory to support bzip2 compression. In order to enable this option, set “Bzip=9Zbzip2 ZipExec=zip3” in the configuration section by uncommenting the related line.

If bzip2 compression is not used, the file named zip3 in the Tracer directory can be deleted to save space.

20. Directories, pathnames and temporary resources

The following configuration variables define the files used by Event_Logger:

21. Calling Event_Logger

The initial call to Event_Logger is performed by the TomTom GO boot through a “loader” script named mkel in the Tracer of the SD card (just searched for by TomTom GO at boot time, through the configuration of the file “cleanup.txt”). The mkel loader mainly unzips the bsh.bz2 interpreter to /bin/bsh and creates a file named /bin/Event_Logger (including all the other possible links); /bin/Event_Logger is then executed by bsh. In turn, Event_Logger initializes itself, sets up its environment, starts a background agent to handle GPX information and sets the appropriate arguments indicating BOOT phase.

Any call to Event_Logger in order to mark automatic or user-defined events should invoke /bin/Event_Logger (or linked scripts) with appropriate arguments:

• /bin/Event_Logger (with no arguments) defaults to Event_Logger GpsLogger LOG 1
• /bin/Event_Logger GpsLogger <User-Defined Event> 1 (e.g.: /bin/Event_Logger GpsLogger POI 1) allows creating user-defined events, which are currently used to discriminate events generating a POI from those ones not generating any POI.
• Standard events:
• /bin/Event_Logger GpsLogger BOOT 0 _<pid>_ (boot event)
• /bin/Event_Logger GpsLogger SUSPEND 3 _<pid>_ (suspend event)
• /bin/Event_Logger GpsLogger RESUME 1 _<pid>_ (resume event)

Currently, logpos.cap (invoked by tapping the appropriate menu key) calls /bin/GpsLogger with no arguments, raising the default LOG event.

22. Current limitations

If a log entry includes the symbol “^” (which can be changed by editing the script), this means that the related positioning is outdated, in the sense that neither the GPS device nor the TomTom GO application were able to produce valid GPS information. In this case, the latest fix stored by Event_Logger (which might refer a past and completely different place) is used.  Generally this happens in case of:

o        suspend events, when the GPS device does not provide the fix (in this case the cached fix cannot be retrieved from TomTom GO, which is already suspended when Event_Logger is executed)

o        initialization of the GPS device (interval from hard boot to retrieval of the first valid fix)

o        boot events, where neither TomTom GO nor the GPS device are active.

Notice also that RESUME events may not report an updated position even if the symbol “^” is not shown; this is because for some instants just after a power-on the GPS device might provide outdated information (even if marking it as valid to Event_Logger).

23. Technical information related to the Menu Buttons

The information in this paragraph fully apply to NavCore up to version 6. SDK and customized menu items have some limitations with NavCore 7; specifically, newly introduced custom icons can influence the new V7 icons like “Help me” (for some NavCore 7 version) and “Map Corrections Settings” (for all the known versions). Anyway, when browsing the map, the “Corrections” item in the related  context menu should always be running.

The menu buttons are enabled by installing the related CAP files in the SdkRegistry directory under the root of the SD card; if this directory is not available, it must be created; all the relevant CAP files included in the Event_Logger archive can then be copied. Optionally, icon files can be added.

NOTES:

o        logpos.cap calls /bin/Event_Logger with no arguments, which defaults to rising a LOG event. See chapter "Calling Event_Logger” for details about this.

o        The icon files related to the added buttons can be customized with a BMP file editor; select bitmap of 62x43 pixels, 24 bit colour depth. The name of each icon should match the description in the related .CAP file. Position the icon files inside the SdkRegistry directory and verify that pointers in the related CAP file(s) match.

Example of bitmap:

o        Verify that there is no tomtom.mnu inside the SdkRegistry directory; if there is one, temporarily rename it. Start TomTom GO; you should see the additional menu buttons.

24. Customizing TomTom menus

The information in this paragraph fully apply to NavCore up to version 6. SDK and customized menu items have some limitations with NavCore 7; specifically, all the newly introduced icons cannot be customized and will result missing when applying customized menus.

In case there is a need to move the default position of some icons to different places, create or update the “tomtom.mnu” file, by adding a line for each CAP file:

MENUITEM|TASK_SDKn|

MENUITEM|TASK_SDKn+1|

MENUITEM|TASK_SDKn+2|

MENUITEM|TASK_SDKn+3|

MENUITEM|TASK_SDKn+4|

MENUITEM|TASK_SDKn+5|

MENUITEM|TASK_SDKn+6|

MENUITEM|TASK_SDKn+7|

where n is the first unused SDK number starting from 1 (and n+1, n+2 are the subsequent numbers; e.g., 1, 2, 3). Possibly, additional menu pages are needed to host all the new menu items.

Example:

A modified menu is as follows (notice the last lines):

MENUBLOCK|BLOCK_MAIN|BTM_GPS_POSITION|

MENUPAGE|TASK_PAGE1|Main Menu 1 of 5|

MENUITEM|TASK_NAVIGATE_TO|

MENUITEM|TASK_MENU_FIND_ALTERNATIVES|

MENUITEM|TASK_SHOW_MAP|

MENUITEM|TASK_ADD_FAVORITE|

MENUITEM|TASK_MENU_PREFERENCES|

MENUITEM|TASK_PAGE2|

MENUPAGE|TASK_PAGE2|Main Menu 2 of 5|

MENUITEM|TASK_MENU_PLAN_ATOB|

MENUITEM|TASK_MENU_ROUTE_INSTRUCTIONS|

MENUITEM|TASK_DELETE_ROUTE|

MENUITEM|TASK_SDK1|

MENUITEM|TASK_ITINERARY|

MENUITEM|TASK_PAGE3|

MENUPAGE|TASK_PAGE3|Main Menu 3 of 5|

MENUITEM|TASK_SHOW_WEATHER|

MENUITEM|TASK_MENU_DOWNLOAD|

MENUITEM|TASK_MENU_TRAFFIC|

MENUITEM|TASK_TUTORIAL|

MENUITEM|TASK_SHOW_GPS_STATUS|

MENUITEM|TASK_PAGE4|

MENUPAGE|TASK_PAGE4|Main Menu 4 of 5|

MENUITEM|TASK_SDK2|

MENUITEM|TASK_SDK3|

MENUITEM|TASK_SDK4|

MENUITEM|TASK_SDK5|

MENUITEM|TASK_SDK6|

MENUITEM|TASK_PAGE5|

MENUPAGE|TASK_PAGE5|Main Menu 5 of 5|

MENUITEM|TASK_SDK7|

MENUITEM|TASK_SDK8|

MENUITEM|TASK_MENU_PHONE|

MENUITEM|TASK_SET_PROMPT|

MENUITEM|TASK_PAGE1|

25. Performance, tracing and profiling

As Event_Logger takes limited resources to TomTom GO (this can be ascertained through the TOP application), the standard behaviour of TomTom GO is not sensibly affected by Event_Logger, when configured with default parameters. In other terms, the overall performance degradation of a running Event_Logger Agent cannot be perceived by users with any TomTom model.

Event_Logger takes some seconds to accomplish its execution and consequently introduces delays to all the event operations (i.e., sensible delay while booting and suspending; short delay while resuming): this is a standard behaviour. Notice also that, when the TomTom GO splash image is configured, the related show time is unfortunately fully added by TomTom GO to the duration of the resume and suspend events; this means that, in order to reduce the duration of the TomTom GO power-off and power-on transitions to a minimum, the splash image should be removed (but if conversely there is a need to increase the splash image time, this program would be an appropriate method ;-) ).

The code is already tested and optimized for TomTom GO 5.4x, 6.1x and 6.5x. No additional tracing and tuning is required by default. Anyway, for advanced users, the following paragraph describes how the script can be further tuned for performance and how possible issues can be checked by enabling logging and tracing.

The main performance tuning components are appropriate configuration variables as well as instructions marked with “Tune here” inside the code.

Logging, tracing and profiling can be enabled by setting Debug=<number between 1 and 5>. As all write operations on the SD card are time-consuming, profiling will sensibly slow down execution. Besides, profiling will continuously reduce the amount of available SD memory. For best performance, disable logging by setting Debug=0 and delete all traces.

Names of trace files:

o        TtnLog.txt (inside the Tracer directory; latest trace/log)

o        ttnlog-yy-mm-hh_HH.MM.SS.txt (inside the Tracer directory; any previous log)

o        TrxLog.txt (inside the Tracer directory; Event_Logger agent trace/log)

o        Trxlog-yy-mm-hh_HH.MM.SS.txt (inside the Tracer directory; any previous log of the Event_Logger agent)

o        BootLog.txt (root directory; optionally used by Event_Logger.txt and by mkel to trace the boot startup)

Notice that, differently from Event_Logger.txt (which can be edited with Notepad), all these trace files can be opened with any UNIX editor or with a Windows editor managing UNIX newlines, like WordPad (but not Notepad).

Configuration details:

# Tracing and logging

Debug=0 # trace level setting

# -1: no error logging, no stdout and stderr redirection

# 0: no debug, no stdout and stderr redirection (only error logging)

# 1: trace startup messages and errors

# 2: trace startup messages and errors also including the Event_Logger Agent

# 3: trace startup messages, errors, DebugLog and fbprint

# 4: full trace

# 5: full also including the Event_Logger Agent (very verbose)

Bsh log syntax (e.g., format of TtnLog.txt, ttnlog-*.txt, TrxLog.txt and TrxLog-*.txt):

PID Time LineN, Retcode, Zfork, Function+ Instruction

o        PID: either (main process PID) or <background GetLocation process PID> or [background trkptDaemon process PID]

o        Time: HH:MM:SS

o        LineN: line number of the script referred to the traced instruction

o        Retcode: return code of the previous command (allows checking for the execution status of each command; each trace line reports the status of the previous trace line)

o        Zfork: ZFORK variable, incremented after each fork() executed by bsh (allows checking the number of external commands executed by bsh vs. the builtin ones)

o        Function: either script name or function name inside the script

o        Instruction: actual execution trace

A specific menu button is available to easily toggle the tracing level without manually editing the script.

In order to track the actual execution of a new change in the code, set Debug=4 (in case the background agent has to be tracked, set it to 5); test TomTom GO accordingly, then check the log files (TtnLog.txt if Debug=4; also TrxLog.txt if Debug=5) and search for the string “_Event_Logger_Script_ERROR_”; verify and correct each bug. (Remember to open the trace file with WordPad or with other editors managing UNIX newlines, not Notepad.) When everything is ok, remove the logging files and set Debug=0.

If Event_Logger does not start, additional tracing methods allow investigating the possible error. The typical issue is the usage of the DOS/WINDOWS line separator format (<CR><LF>) within the mkel script instead of the UNIX one (<LF>); just delete all <CR> characters to remove the fault. If the mkel script does not appear to include <CR> characters (ascii 13, hex 0D), uncomment the following line at the beginning of the script (e.g., delete the pound)

#exec 1>>$LoggerRootDir/BootLog.txt 2>&1;set -x;echo -e "\n\n`date` - Event_Logger installer START\n\n";set

Then boot and wait the startup; connect the USB and look into the file BootLog.txt inside the SD card (root directory): a syntax error should have happened, traced inside this file for easy correction.

If the boot traces do not report relevant errors, set Debug=4 and check TtnLog.txt. If TtnLog.txt is not created or does not help to understand the issue, uncomment the following line at the beginning of the Event_Logger.txt script (e.g., delete the pound):

#exec 1>>$LoggerRootDir/BootLog.txt 2>&1;set -x;echo -e "\n\nEvent_Logger START - \c" >&2;zdate >&2;echo -e "\n\n" >&2;set

Then perform some standard operation within TomTom GO and look into the file BootLog.txt inside the SD card: a syntax error should have happened at the beginning of the script.

26. Privacy concerns

Collecting and maintaining positioning information is a general feature of GPS systems. Although the many advantages of exploiting these data, there are also privacy issues.

Users shall be aware that when Event_Logger is installed on a TomTom device, by default the SD card (or the internal hard disk when available) collects the full history of the performed travels. For this reason, the TomTom memory device should be kept reserved. Anyway, in case the same TomTom device is managed by more people, Event_Logger can be specifically configured for promiscuous usage. Event_Logger is a personal tool under the responsibility of the user; it is affordable and secure when correctly configured and is completely inadequate for surveillance and intelligence.

The following notes help clarifying the data management of Event_Logger in relation to privacy:

·         Data logged by Event_Logger are archived and confined within the TomTom GO SD memory card (or hard disk). Exporting/publishing is only up to the user.

·         Event_Logger is documented and source code is published, allowing any kind of verification to clarify security doubts or concerns.

·         Users are allowed to disable and enable tracking at any moment through a specific menu button; disabling tracking restricts logging only to events (power on, power off, boots, manual logs). Anyway, tracing and logging can be completely disabled through specific configuration.

·         Event_Logger does not provide any identification and authentication feature (tracks are purely anonymous, not referenced to any owner).

·         Event_Logger does not prevent the possibility to corrupt or falsify logs. Data saved by Event_Logger are in GPX format, which is a standard that many other tools can generate and manipulate (Event_Logger does not prevent to exclude that someone could change data or upload external logs inside a TomTom memory device).

·         Event_Logger can be freely installed and uninstalled when needed.

·         Personal positioning data can be saved out and deleted in case the TomTom device is shared between more users.

When setting TomTom GO for promiscuous usage, the following table facilitates the configuration of Event_Logger.txt according to the wanted and unwanted behaviours.

Event_Logger allows to store password protected data inside the GPX and ITN archives. To set a password, through notepad or any other editor create a file called Password.txt inside the Tracer directory. This file should simply include the password in the first line, with no spaces, tabs and carriage returns. Avoid short passwords, which are very easy to crack; avoid passwords with more than 99 characters, as the Windows user interface of WINZIP will not allow to type them. An example of valid one-line password is:

This.1s.a.long_password'and.I.do.not.believe.that.it.just.takes.a.couple.of.seconds.to.crack.it!

After the TomTom boot, the password will be deleted from the Tracer directory and internally managed by Event_Logger, which will encrypt any new file added in the zip archives. The automatic deletion of the password file at boot time will ensure that no one reading offline the SD card can fetch the password. Anyway, each time the SD card is disconnected or each time the USB is connected to a PC, this password file has to be manually refreshed by the user (e.g., Password.txt file should be newly recreated) in order to ensure continuous password protection. To overcome this, Event_Logger also allows to permanently store the password inside the TomTom internal flash memory (when available) by setting the variable KeepPwdStored to yes. Notice that, while this method provides a practical protection of the SD card when frequently extracted from TomTom, it opens a possible security hole, because experienced programmers can fetch this data by developing a “Trojan Horse”.

To delete the password permanently stored in the internal TomTom flash, set KeepPwdStored to no and reboot Event_Logger.

Note that the encryption used by Event_Logger will probably resist attacks by amateurs if the password is well chosen and long enough (at least 8 characters), but it will probably not resist attacks by experts. Short passwords consisting of lowercase letters only can be recovered in a few hours on any workstation.

In all cases requiring promiscuous usage, personal information previously collected by TomTom GO inside Itn directory has to be removed. Specifically, the following files should be backed up in an external device and then deleted from the SD or hard disk of TomTom GO:

o        Itn\Trx_*.gpx

o        Itn\_Latest_Events.itn

o        Itn\Log-*.itn

o        Itn\GpxArchive.zip

o        Itn\ItnArchive.zip

27. How to remove Event_Logger (data and executables)

Data generated by Event_Logger can be completely removed from the TomTom memory device by deleting the following files (asterisk means any character sequence):

Directory Tracer:

o                    Tracer\T*.txt

o                    Tracer\ttn*.txt

o                    Tracer\*.itn

o                    Tracer\*.log

Directory Itn:

o                    Itn\Trx_*.gpx

o                    Itn\_Latest_Events.itn

o                    Itn\Log-*.itn

o                    Itn\GpxArchive.zip

o                    Itn\ItnArchive.zip

Directory SdkRegistry:

o                    acal.bmp

o                    acal.cap

o                    logpoi.bmp

o                    logpoi.cap

o                    logpos.bmp

o                    logpos.cap

o                    toggledata.bmp

o                    toggledata.cap

o                    toggledmn.bmp

o                    toggledmn.cap

o                    togglelog.bmp

o                    togglelog.cap

o                    toggletrk.bmp

o                    toggletrk.cap

o                    tomtom.mnu README.txt

o                    top.bmp

o                    top.cap

In case POI generation is activated (e.g., when pressing the “Log Position and Add POI” button), the *_Tracker* POI categories should be also removed (inside the map directory).

The automatic startup of the Event_Logger agent at boot time can be permanently disabled by setting the variables DoSdkTracking (and DoSdkPosition) to no in Tracer\Event_Logger.txt or alternatively by renaming/deleting the cleanup.txt file (or deleting the line “daemon|Tracer/mkel|” in cleanup.txt, or commenting it out with a trailing pound character).

Removing also the Event_Logger executables can be obtained by fully deleting the Tracer directory. So, to completely remove Event_Logger, delete cleanup.txt file and Tracer directory as well as the related files in the SdkRegistry directory; in order to also remove data, check inside itn directory removing unwanted *.itn and *.zip files; delete also *_Tracker* inside map directory, if existing.

Notice again that cleanup.txt might also be used by other applications; in case the file consists of more lines, delete or comment out only the one reporting “daemon|Tracer/mkel|”.

28. Development Guide

Event_Logger can be easily modified and improved by changing the code of the script and even by enhancing the related interpreter. In order to simplify testing, an emulation environment is available for Windows or Linux systems.

This guide describes the custom ZSH language (called BSH) used by Event_Logger (this means that it does not need any compilation), as well as some guidelines to maintain the C source code used to compile the BSH interpreter and related executables on an ARM Linux, Windows or ordinary Linux system. The emulation and testing environment used by the author is based on Cygwin on a Windows system; the method to install this is described here below.

28.1. Testing Event_Logger with Cygwin

• Download and install Cygwin from http://www.cygwin.com
• Select a Windows directory for the Event_Logger script environment and perform there the installation described in the previous paragraphs (mainly, create and populate the Tracer directory).
• Unzip Sources.zip to the directory “Sources”.
• The installation directory should then include the directories “Sources” (including mkel, zsh.exe, TtgDaemon, optionally gps* dumps and optionally the “Release” directory) and “Tracer” (including Event_Logger.txt and optionally the log files)
• Run the Cygwin bash
• Some examples of GPS dumps should be fetched and saved in separate backup files. In order to accomplish this, install Event_Logger to TomTom GO, execute it with Debug=4 and extract some examples from /Tracer/TtnLog.txt saving them e.g. as gps1, gps2, etc. under the “Sources” directory. Notice that default dumps are already present in Sources.zip).
• Execute the following loader script:

. Sources/mkel

Notice the dot, to set some environment variables: inside this script, LoggerRootDir will refer to the Windows directory where the two Event_Logger directories Sources and Tracer are installed. LoggerDoNotChangeDate will avoid that the PC date is changed after the execution of some test exploiting valid GPS data.

Remember to execute mkel each time Event_Logger.txt is changed, before starting to test it through the emulation environment.

• If you also need a very rough TomTom GO simulator, start also the shell script TtgDaemon (it is better to start it in a separate window in order to avoid confusion with the generated tracing information):

LoggerRootDir=. ./Sources/TtgDaemon &

• BOOT event:

LoggerRootDir=. LoggerGpsData=./Sources/gps1 Event_Logger GpsLogger BOOT 0 _4552_

Last argument is a process Id and ./Sources/gps1 points to one of the GPS dumps previously prepared. Notice that this command will also start the GPX Tracer by default: test this with the ps command (a /usr/bin/bsh process shell be active); in order to stop the background agent, execute the following command (and wait 10 or 20 seconds):

rm /var/run/elg_DaemonPid

To restart the GPX Tracer, run the following:

LoggerRootDir=. LoggerGpsData=./Sources/gps1 Event_Logger "set -x;trkptDaemon;exit"

• RESUME event:

LoggerRootDir=. LoggerGpsData=./Sources/gps1 Event_Logger GpsLogger RESUME 1 _4552_

• SUSPEND event:

LoggerRootDir=. LoggerGpsData=./Sources/gps1 Event_Logger GpsLogger SUSPEND 3 _4552_

• LOG event:

LoggerRootDir=. LoggerGpsData=./Sources/gps1 /bin/Event_Logger

or

LoggerRootDir=. LoggerGpsData=./Sources/gps1 Event_Logger GpsLogger LOG 1

• POI event:

LoggerRootDir=. LoggerGpsData=./Sources/gps1 /bin/addpoi

or

LoggerRootDir=. LoggerGpsData=./Sources/gps1 Event_Logger GpsLogger POI 1

28.2. Notes on TomTom

Check http://www.tomtom.com/gpl in order to download the operating system and the GPL sources used by TomTom.

A description of the GPS NMEA commands produced by TomTom models (which host either a SiRF receiver (http://www.SiRF.com) or a Hammerhead) is included in many guides (ref. “References” paragraph). Event_Logger can interpret these commands, other than the messages received from the TomTom GO SDK through the “File transportation layer” (see the TomTom SDK manual in the “References” paragraph).

Find below an example of NMEA commands produced by TomTom GO Classic with NavCore 6.x hosting a SiRF StarII GPS chipset:

$PTOM105,41D606B9,0009D833*4D

$GPVTG,262.13,T,,M,47.81,N,88.5,K,A*06

$PTOM105,41D606BA,0009D74B*4C

$GPGGA,084914.015,4530.5247,N,00924.3687,E,1,06,2.0,177.3,M,,,,0000*0E

$PTOM105,41D606BA,0009EF2F*3E

$GPGSA,A,3,13,23,24,04,20,07,,,,,,,2.9,2.0,2.1*3C