The telematics of today becomes a lot more complicated and diverse than simply processing the data from GPS trackers, applying analytics, and building reports. In many cases, the telematics device also serves as a hub for numerous sensors to control tire pressure, the temperature in reefer, proximity to the loading dock via BLE, vibration level, and other parameters.
When a GPS tracker collects data from peripherals, it saves them into the designated bytes on the device. However, sometimes the original GPS tracker protocol says nothing about how to parse the custom data that came from the external sensors. Each of these connected accessories has its own parsing scheme designed by its manufacturer. The question is: how to apply the right parsing logic to different parts of the message?
Use post-processing protocols.
Post-processing concept
Post-processing technology allows injecting custom user-defined logic into the tracker data processing pipeline.
For instance, one manufacturer produces high-precision temperature sensors that connect to a tracker via RS485 interface, another manufacturer produces passenger count sensors using BLE technology to communicate with the tracking device, and we also have a task to define vehicle location using cell tower positioning in the areas and conditions with the poor GPS signal.
To relieve our customers’ engineers from having to deal with parsing data from custom sensors we gave them the possibility to use GPS trackers as transport for sensor data and apply user-defined logic to this data including custom parsing schemes.
A resulting message is a JSON object including normalized data from all connected sensors as well as calculated LBS values. The most impressive thing here is the possibility to list a sequence of such post-processing protocols to be applied to the given transport-level protocol. Having once implemented a (usually fairly simple) parsing for a given BLE sensor, you can then seamlessly introduce it into the processing pipeline of a transport channel based on a Suntech, Teltonika, Queclink, and any other type of tracker.
All in all, post-processing channels can operate in one of the two modes:
a post-processing channel modifies the original JSON message and saves the modified message into the initial (transport) channel.
a post-processing channel makes a copy of the original JSON message, modifies it according to the channel logic, and saves the modified message into the given post-processing channel; the original JSON message in the initial (transport) channel stays intact.
Typical usage
When flespi receives a packet from the tracker in the channel, initially it applies the parsing scheme corresponding to the channel protocol (transport channel). The values from the connected peripherals get into the proper general-purpose or designated message parameters of the resulting JSON object (message), mostly in a generic format like HEX string. To “extract” meaning out of these parameters as per their protocol specification you can specify a proper post-processing channel (or several channels) in the transport channel configuration:
These protocols will be applied sequentially in the specified order after initial parsing. A post-processing channel takes the entire message and handles the parameters carrying the values from the specific sensor (or other connected peripheral). For example:
BEFORE | AFTER |
{ "ident":"354018111000000", "position.latitude":54.206333, "position.longitude":27.84076, "timestamp":1634817914, "payload.hex":”0000000100000002” } | { "ident":"354018111000000", "position.latitude":54.206333, "position.longitude":27.84076, "timestamp":1634817914, “custom.sensor.1”:1, // first 4 bytes: "00000001" of payload.hex “custom.sensor.2”:2 // last 4 bytes: "00000002" of payload.hex } |
Note: post-processing protocols are currently designed by the flespi team upon request or based on frequent use case scenarios. The plan is to give a possibility to create own post-processing protocols directly to the customers.
More than just parsing
Post-processing protocols can be designed to do more than extra parsing for the custom payload — in essence, they can be instructed to perform any parameter modifications, complex calculations, etc.
A good example will be the calculation of the LBS positioning (cellular tower positioning) and substitution of location-related parameters (i.e. position.latitude, position.longitude) in times when GPS is weak (indoors, due to bad weather, etc).
Another scenario is when a peripheral protocol sends custom parameters in unknown measurement units, so the initially parsed message might include such parameters with the wrong units. Then a specific post-processing channel with the right multipliers can fix such inconsistency.
A step into the IoT door
Apart from streamlining the implementation of complex projects relying on a variety of hardware types, this technology facilitates entry to the prolific world of IoT protocols that most of the time operate on top of Sigfox, LoRaWAN, and the like.
***
Post-processing can do many things, but the underlying concept is the same — it allows handling the incoming messages in a variety of user-defined ways and can sequentially apply several lines of logic.
Already excited? Stay tuned — a more practical guide is coming up soon.