TABLE OF CONTENTS 

   

Overview

The TMT and Miles guide contains information on how miles get to TMT from Geotab, explains how different odometers are used within TMT, and contains troubleshooting steps that can be taken to better understand meter readings in TMT. 

 

Integration to Totalmail (TMT)

TMT is an asset maintenance system.  The meters are used as a measure for when maintenance needs to occur, and the meters have maintenance schedules connected to them for the assets. The best source of mileage will be from Geotab because it updates continuously and will have the most up to date reading.  Geotab is also a good source because it has historical tracking, feeds directly off the truck’s ECM (engine control module), will match what the ECM is reporting, and if the ECM doesn't report, then the truck’s position can be used to calculate mileage and update meters. Primary meters need to be set for recording certain activities, and TMT has "Validations" that can run to make sure the readings are being recorded properly (such as preventing the meter from going backwards or jumping by huge amounts).


The process that feeds mileage to TMT is as follows: 

  1. Background Services on the Web Server listen to the Geotab Feeds every 5 minutes.
  2. This polls the latest data from several feeds at Geotab, including StatusData and LogRecords.
  3. That data is combined into a record which is inserted in ELEOS.TelematicsLocations. The record includes location, odometer, bearing, Fuel, and more.
  4. After inserting the record in ELEOS.TelematicsLocations, a procedure called ELEOS.usp_SaveOdometer_AMS runs and populates a record in TMT.


Common Meter Types the Integration Populates to TMT: 

    1. ODOMETER This meter follows standard TMT insert rules, meaning TMT validates each reading and decides whether to accept or reject it. Clients often designate this as their primary and validated reading.

  • TMT may reject new readings based on prior data.
  • Example: If a mechanic mistakenly enters a manual reading of 100,000 miles during a repair, and the actual current odometer is 70,000 miles, TMT will reject all subsequent readings below 100,000. As a result, no updates will be accepted until the odometer reading surpasses 100,000.

    2. GTODOM This meter is a pure ECM feed created by ASR and typically set as a secondary meter. It bypasses TMT validation rules.

  • GTODOM should always match ECM readings from Geotab (though Geotab data can still be inaccurate).
  • The advantage is that it avoids the additional layer of validation that can cause TMT to reject updates.
  • If GTODOM does not match ODOMETER or ECMMETER, it likely indicates that TMT is rejecting readings due to its configured validation rules.

    3. ECMMETER This meter is used for PeopleNet customers and, like ODOMETER, follows standard TMT insert rules with validation. 

  • ECMMETER was created by PeopleNet and is tied to maintenance schedules for certain assets.
  • TMT will validate each reading and may reject it based on prior data, similar to how it handles ODOMETER readings.


TMT is actively being fed with ODOMETER, ECMMETER, and GTODOM coming from the ECM readings in Geotab.  The readings in ELEOS.TelematicsLocations are updated every 5 minutes, but TMT is only updated every 12 hours to avoid overly frequent readings. The reason that TMT is only updated every 12 hours is to optimize TMT performance and maintain data integrity. 


Occasionally, updates fail or are dropped due to TMT’s internal validation rules, especially when readings decrease unexpectedly or conflict with existing data. TMT will not 'reject' readings but instead will ignore readings, meaning it won't display or use them.  There is still the raw feed of all the readings provided in the VIEW_METERREADINGS view which TMT uses. TMT will only use and show the highest when validation is on.


GTODOM typically serves as a "check value" within TMT. It is not subject to validation and simply reflects the latest ECM readings. When clients encounter questionable or inconsistent data, GTODOM can be referenced and compared against other meters in TMT to help identify and resolve discrepancies. Having this secondary reference point makes it easier to trace issues and correct invalid readings on the validated primary odometer.


TMT recommends an optimal configuration that includes:

  •  A validated primary meter used for preventive maintenance (PMs) and reporting.
  •  An unvalidated secondary meterthat acts as a raw data feed for troubleshooting and review.


In most implementations, GTODOM functions as the unvalidated secondary meter, while the client’s chosen primary meter undergoes validation.


Note that the above is the standard setup, and some clients may have customizations to the 3 meters, change if they are validated, or have additional meters. We recommend that at least one meter stay validated, and one be unvalidated so that one can have PMs (preventative maintenance) based upon it and the other meter can serve as a check.  


Validations in TMT

If the user interface of TMT decides that “Reading" fails any of the customizable "Validations" that can be enabled, (and there are multiple validations with configurable rules, they aren't always the same customer to customer) then the "Reading" is essentially invisible to the user, like no entry was ever made. This is why updating a "Validated" meter can be so inconsistent.  There are multiple feeds into the meter, such as manual entry by Mechanics, Fuel entries at the Pump, and programmatic Geotab entries. If any of them get erroneous values, subsequent meter readings that are valid can be ignored by TMT.  There’s almost always some maintenance needed for the readings, such as ignoring erroneous higher readings, or fixing invalid items that came in so the feed can continue to flow.  That’s why the secondary "check" meter is so important because it can be used to confirm what the values should be and get back on track.


Mileage Discrepancies in TMT

 The meter readings entered by a TMT user are associated with a repair order.  When the repair order is opened, it defaults to the last reading in the list, so it is possible that the user accepts what is there by default. Typically, the user just confirms the last reading.  If validation is off, this shouldn’t impact the values that are inserted by Geotab.


The reason it is recommended for the primary meter, which feeds PMs and Reporting, to be validated is that invalid readings may cause issues with the PMs schedule.   For example, if the meter goes back and forth on some readings.  When the mechanic initiates a repair order and confirms the mileage on the vehicle, it references the errant mileage reading and could trigger a repair order.  Typically, this issue is handled by keeping validation on, and when there are errant high values, they need to be manually ignored.


Invalid Meter Readings

Practically, for a single truck, the odometer will never physically go backwards (barring some kind of manipulation).  Thus, on the surface, it seems logical to block odometers from ever reading "Backwards" to mirror that physical reality.  However, there are a lot of human errors that cause a reading to be problematic.  TMT had the concept of "Ignoring" Odometer readings that were invalid so there is a steady stream of valid readings.  Reasons for "Ignoring" readings over time included things like the following:

  1. Invalid Odometer Entries
    The Odometer seen in Geotab includes an "offset" that is human entered (to account for things like engine rebuilds, or GPS driven odometer values after install).  If that offset was entered wrong, it could cause a strangely high reading, then be stuck with it for an extended time without correction.
  2. Moving the Geotab Unit
    Geotab GO9 device swaps or reinstalls happen quite a bit for troubleshooting or for units being taken out of service.  When a swap/reinstall happens, the odometer reading from the other vehicle can be different.  Of course, in theory a unit should be renamed once the unit is moved so that the new odometer reading should go to the correct unit, but that isn't always the case.  For example, if the unit is renamed first, then there would be an old odometer reading coming through for a different unit, causing new valid odometer readings that come in that are lower. The lower readings would be ignored and instead the higher reading would stay until the unit’s odometer passes it. 
  3. Faulty Connection to ECM
    ECMs are computers and transmitting signals via wire.  Sometimes the GO device may send incorrect readings due to faulty ECM connection, weak signal transferring the reading, or entire device failures.  This can create invalid meter readings which are challenging to diagnose or troubleshoot.
  4. Invalid GPS Positions
    Similar to the faulty connections, Odometer readings can be calculated by GPS positions and travel when the ECM is not providing an Odometer reading. However, if the Geotab GO9 device is not connected properly, it may be losing signal or it may have gaps in the GPS history, which may cause jumps from location to location, causing invalid mileage to be calculated. Usually this would shorten the readings, but not always. It can also compute massive speeds and jumps. For example, the device didn't read in between a state and suddenly jumped in position from one side of the state to the other when it reconnected.  

It is possible to get invalid data at times, and once the invalid data comes through, it might skew readings for a long time.  TMWSuite attempts to never let an Odometer decrease but in doing so this may require manual intervention to remove the invalid mileage reading which may be stuck too high.  

 

Troubleshooting

To learn more about the invalid readings, the following TMT tables listed below contain information on meter readings.

  1. METERDEF
    The main definitions for all "Meters".  Meters are a record concept that represents some kind of physical tracking.  Odometer is the most obvious example (meter that measures the miles turned by the engine), but there are also ones for time (things that get checked every 90 days) or hours (engine check after 500 hours, etc...).
  2. UNITMTR
    The mapping of meters to a particular unit.  This gives the specific assignments and usages of that Meter Type for that Unit.  Join by METERDEF.METERDEFID = UNITMTR.METERDEFID.  This tells things like the latest readings, dates of readings, who modified the readings, and if it's required when creating other records (This is because sometimes the mechanic should manually enter a reading before they perform maintenance on a Repair Order, etc...). Most importantly, the table indicates if it's a Primary Meter for the unit, and if it's a Validated Meter for the Unit.
  3. METERRDG
    The actual readings that have occurred.  This table can be used to drill in and see what's been recorded for a meter.  
  1. UNITS
    The master table for units. This table contains the UNITID, which is needed to query the other tables mentioned above and map things out for a specific unit in question.

 

Incorrect Readings Coming From Geotab

If there are only one or two trucks that are reporting inaccurate mileage, check if the mileage in MyGeotab is correct for the truck.  If the mileage in MyGeotab is inaccurate for a truck, then that could indicate that there is an issue with the Geotab device within the truck that is causing it to report readings that are inaccurate or can cause it to stop reporting odometer at all. In this case, reseat the GO device within the truck or try swapping it out for a new device. Typically, a unit should be renamed once the unit is moved so that the new odometer reading should go to the correct unit. Check if the GO9 device in the truck has been updated at any point recently, or if there is any recent record of the device being in another truck. If there was a swap with that device, that same serial number would be assigned to a different truck on the backend, but the data on the backend still sees that serial number as having odometer from the original device but is reporting the odometer from another device.  


Geotab also has some articles to aid in troubleshooting: