We need to estimate the number of parameters in each message so we ask:
which device types do you use?
are devices connected to CAN-bus?
do you have many sensors tied to the device?
We need to estimate the number of messages sent per day so we ask:
how precise must the track be?
how frequently does the device send messages?
how intensively is a vehicle with the tracker used? (e.g. daily mileage)
And finally, we need to understand what you need to do with this data so we ask:
do you know how to manage device storage?
what historical data do you need for your app business logic? (maybe you don’t need whole messages but just track routes and mileage or engine hours)
do you have the ability to automatically download and store backups on your side?
You get the idea, but not an answer :) In this article I will try to benchmark flespi device message storage based on the simulated data from the real device. In the first part, I take the Teltonika FMB110 device installed in my car to check how tracking settings affect the number of messages per km and per hour for city and highway driving. In the second part, I will compare the number of messages per 1 MB of flespi storage depending on the device type (number of parameters per message). These two steps will provide us with an algorithm of flespi storage estimation: you input the requirements of your project and get an approximate but reasonable number.
Messages per km and per hour
The benchmark shows valid results when we measure the change in the target parameter while controlling for all insignificant parameters. Almost every GPS tracking device has settings that allow adjusting track accuracy — a telemetry message can be generated on timeout, on distance change, on angle change, and on speed change. These are variable parameters. The more messages the device sends, the higher the traffic consumption. But this article is not about how to define optimal tracking parameters.
To account for traffic and route differences I picked two geofences on the way from home to work: highway (21 km) and city (2 km) without traffic lights. How do we count the number of messages per geofence? Using flespi analytics of course.
Simple expression “1” counter with the “summary” method applied will count the number of messages. Mileage and duration of the interval can be used to determine the number of messages per kilometer and per hour.
Here are the results of my test:
Msgs per KM (highway)
Msgs per Hour (highway)
Msgs per KM (city)
Msgs per Hour (city)
How to use these numbers?
daily engine hours — 8.
the device is tuned for Moderate track quality
city/highway ratio is 70%/30%
(334 * 30% + 443 * 70%) * 8 hours = 3282 messages daily ~ 100K messages monthly
weekly average mileage is about 1K kilometers
the device is tuned somewhere between Moderate and Sufficient track quality
vehicle mostly rides down the highways
Interpolate the number of messages per kilometer for the city — 12 and for the highway — 2. Let’s assume that the city/highway ratio is 10%/90%. Thus
(2 * 90% + 12 * 10%) * 1000 = 3K messages weekly ~ 13K messages monthly
Ok, but what do these numbers tell me? Welcome to the next chapter.
Messages per MB
flespi storage is a real work of art. But this article is not about its architecture but about numbers: the number of messages per MB or the average size of a message in bytes.
The number of kilobytes shown on the device card can be obtained in the device messages_size field via REST API or as a retained message via the topic flespi/state/gw/devices/169791/messages_size. But how to obtain the number of messages? flespi analytics helps. The same expression “1” counter and interval selector that is true for each message would give the number of stored messages per device.
Note that some system parameters are registered in each message even if the device itself sends just one simple sensor value. These system parameters include channel.id, device.id, device.type.id, device.name, ident, protocol.id, server.timestamp, timestamp. So the smallest possible message will consist of nine parameters.
Parameters in message
Amount of messages per MB in flespi storage
Approx message size in bytes
Tracker (no CAN-bus)
Tracker (with sensors)
How to use these numbers? Let’s look at some real-life examples:
I have a fleet of 200 vehicles from Task 1 above, each generates 100K messages monthly, and the number of parameters in the message is ~ 25. How much will I pay for flespi storage if I store the messages history for half a year?
25 message parameters can be interpolated to 300 bytes per message.
300 bytes * 100K * 6 * 200 / 1GB = 33.5 GB. This will incur an additional storage fee of €33.
I have a fleet of 1000 vehicles from Task 2 above, each generates 13K messages monthly, these are full-featured trackers connected to CAN-bus and different sensors, each message contains ~37 parameters. I don’t want my storage bill to be more than €10/month (which means no more than an extra 10GB of storage). How long can I store the messages history? (read: what messages TTL should I set for devices?)
Note: each device in the Commercial account has 10GB of message storage.
10GB / (500 bytes * 13K messages * 1000 vehicles) = 1.65 month = 50 days.
Set messages TTL to 50 days and feel safe about your monthly storage billing.
As you can see, there are a lot of moving parts in the calculation of storage required for your telematics device messages. This article helps you estimate how many megabytes your trackers will generate in a month, and how this number depends on the reporting frequency, the number of parameters in the message, and other project needs. Hope this will give you a clearer understanding of what adjustments can be made to optimize the final figure and fit it into your budget.
P.S. We are going to release an interactive “Estimate my project” calculator soon to help you make informed business decisions when evaluating flespi as a foundation for your project.