Using telematics units that send discrete values with timestamps

Topic: Using telematics units that send discrete values with timestamps

We are experimenting with telematics devices which send data in discrete values with timestamps instead of sending all values at once as most telematics units do.  For example, the telematics device might send a GPS latitude/longitude, then a few seconds later it sends an ignition status, then a few seconds later it sends a device voltage measurement, then a few seconds later it sends another location, then a few seconds later it sends an ECM vehicle speed, and so on.  We are loading this data in Wialon Hosting via Wialon IPS protocol.

Sending the data as-is from the device (using NA where values are not available as per the Wialon IPS protocol), we have some concerns about Wialon's handling of such data.
- Some parameters such as speed report as zero instead of blank or not available.
- Report tables like sensor tracing and message tracing correctly show no lat/long values, but repeat location (street address) values for messages where no location was provided.
- Notifications, such as those based on value change, may trigger when not intended.  For example, if ignition was off and a unit message arrives with ignition on, it triggers the notification as expected.  But if the next message has no ignition value, the notification would trigger again.  Later if ignition on is reported by the device again, it triggers another notification even though the ignition was last reported as on.  (Note, I created a separate topic post for this specific issue as well.)

Since we are building Wialon IPS unit messages anyways, an initial thought was to repeat previous message parameter values in future messages which don't have those values.  But this causes all kinds of other problems.  For example, a final RPM of 900 reported will continue to report that RPM even after ignition is reported off and the vehicle is parked.  Repeated locations in unit messages without location make the vehicle appear to move quickly, stop, move quickly, stop, etc.  Messages arriving out of order also cause problems, since the last reported value may not be accurate according to a unit message we receive shortly thereafter, causing a "bouncing" effect.

Perhaps there is a need for better handling of such telematics data in Wialon.  Has anyone else run across such telematics units or similar cases?