Overview of the tracker diagnostics
Explanation of the different tracker diagnostics
Diagnostics aim to give an idea of the overall performance of various elements of the tracker. Whether a result is good or bad depends heavily on the use case. Some use cases tolerate less than ideal data.
If you look to the diagnostics, it is best is to start with selecting the time period of which you want to see the diagnostics. By default the time period is set to the last month, but you can change this depending on the preference
Note: How they look like, depends on when you make the diagnostics. If you
look at the journey now or last week there's a possibility that it will still improve due to
data recovery.
Battery diagnostics
| Diagnostic metric | Description | How to interpret the diagnostic metric? |
|---|---|---|
| Battery percentage | The battery percentage still available on the tracker during the defined period | The estimated battery lifetime is in general around 5 years (but depends on use case & configuration). If you see that the battery percentage is going down much faster it is best to contact Sensolus support. |
| Average battery consumption in a day | Average battery consumption (in mAh) in a day during the defined period. This consumption is driven by the number of locations and the number of messages that is send out. | This metric is a good one to compare over time. Is the average battery consumption in a day value in relation to the usage of the tracker over time? |
| Remaining battery lifetime | Time period (in months) the battery of the tracker will remain working | This metric is good to follow up to be able to plan battery replacement. If you see this diagnostic going down very fast it is best to contact Sensolus support |
| Battery consumption | Total battery consumption (in mAh) over the defined period. | This metric is good for analyzing whether the battery consumption had increased over a certain period (week/month/customized). If you suddenly notice that the battery consumption has increased a lot then you could analyze the reason that caused this increase. You should not worry if that increase is a result of a new tracker configuration or a FW upgrade but you should take actions if the configuration is very heavy by looking for solutions to make it lighter. |
Transmission diagnostics
| Diagnostic metric | Description | How to interpret the diagnostic metric? | Metric available for trackers communicating over which network? |
|---|---|---|---|
| Liveness | The liveness indicator gives insights on the speed of arrival of messages sent by the tracker. It is the ratio of all messages received by the platform cloud in less than 10 minutes after detection by the tracker to the total number of messages sent by the tracker. | A liveness ratio of 100% means that all messages are received within 10 minutes after detection. Note that this ratio can be impacted by certain tracker configurations such as the stop time-out (that could be longer than 10 minutes) and the "send on stop" feature that forces the tracker to only send a message when it stops moving. | Sigfox, NB-IoT |
| Days without throttling ratio | Throttling means the tracker wants to send more data than its transmission budget allows. This metrics indicates the percentage of days where no throttling occurred. 100% is the perfect score. | This metric is valuable for assessing whether the tracker transmits more messages than the communication budget of the network provider allows. If this occurs frequently, it might be needed to consider adjusting the configuration to lighter settings. However, if the tracker enters throttling mode, it will prioritize data recovery, potentially resulting in low-priority data not being recovered depending on the message queue load. | Sigfox, NB-IoT |
| Time online | This percentage indicates how often the tracker was seen online by the platform. Trackers can go offline when they move out of network coverage. As soon as they move back to a covered zone they will appear again online. | This metric provides insight into the percentage of time the tracker remains online. When this metric indicates a low online presence, it is advisable to examine the overall Time Online across the organization. This can be investigated through the Diagnostic page, where it is possible to assess if a significant number of trackers within the organization are experiencing low online time percentages. In such instances, further investigation is needed. Low online time percentages may indicate areas where assets are located with limited coverage or are detected indoors. In response, appropriate actions can be taken to enhance online time, such as improving coverage in affected areas or implementing measures to ensure better connectivity indoors. | Sigfox, NB-IoT |
| Network quality | The Network quality indicator gives insights on the quality of the communication network used to send out messages from the tracker to the cloud. It is calculated as the ratio of messages which have a rating of Excellent & Good vs all messages. As long as enough messages arrive a non perfect score here is not a cause for concern. | This metric serves as a valuable indicator of the Network strength within the vicinity of the tracker's movement. In regions where coverage is sparse or remote, the metric can highlight areas where network strength may be insufficient, leading to potential message transmission issues. | Sigfox |
| Message transmission success | The Message transmission success metric gives insights on the reception of messages sent by the tracker. It is the ratio of the number of messages successfully received by the cloud to the total number of messages sent by the tracker to the cloud. | A ratio of 100% is perfect reception of the messages. This ratio is independent of whether data gets recovered through data integrity algorithms: if a data point is sent a first time and doesn't arrive, and is then successfully sent a second time, the ratio will be 50%. | Sigfox, NB-IoT |
| Average number of send messages in a day | This metric indicates how many messages were sent on an average day. | This metric indicates how many messages were sent on average daily. If this value is too high it can lead to throttling and it will have a negative impact on the battery life. | Sigfox, NB-IoT |
| Number of send messages | Total messages sent by the tracker. This doesn't mean those messages where received by the cloud platform. This metrics is relevant to check if the tracker is sending too many messages with respect to its transmission budget which can lead to throttling. | This metric is related to the throttling diagnostics, and what a good number is depends on the network subscription. | Sigfox, NB-IoT |
| Total hours offline | Total hours this tracker has been declared offline. | This metric offers insight into the percentage of time the tracker is not online. When this metric indicates a significant offline presence, it's recommended to examine the overall time Offline across the organization. This can be explored through the Diagnostic page, where we can evaluate if a substantial number of trackers within the organization are experiencing high offline time percentages. In such cases, further investigation is necessary. High offline time percentages may suggest areas where assets are situated with limited coverage or are detected indoors. Accordingly, steps can be taken to enhance online time, such as improving coverage in affected areas or implementing measures to ensure better connectivity indoors. | Sigfox, NB-IoT |
| Throttling event | Throttling means the tracker wants to send more data than its transmission budget allows. It will temporarily suspend transmission. If this happens occasionally there is no problem but when it is happening frequently the configuration should be updated to result in less messages (less sensitive start/stop detection, larger OTM period, less frequent sensor updates,…) | This metric can indicate that the tracker is struggling often to transmit all the messages. That means that there will be low priority messages that might never arrive to the cloud. In this case the configuration should be modified. If that happens to a Sigfox tracker and the configuration cannot be improved then you should consider moving from Sigfox Silver to Sigfox Platinum which can send double data. | Sigfox, NB-IoT |
| Message transmission distribution | Distribution of messages that are received (by the cloud) and messages missed
(send by the tracker but not received by the cloud). Values = received, missed. |
The higher the number of received messages, the better. | Sigfox, NB-IoT |
| Network quality distribution | Distribution of the messages over quality of the communication network used to send out messages from the tracker to the platform cloud. The distribution ranges are: excellent, good, average and limited quality. The category 'missed' contains the messages that weren't received by the platform cloud. | Values = excellent, good, average, limit, missed | Sigfox |
| Message type distribution | Distribution of messages over the different data types the tracker sends to the platform cloud. Different data types are visualized: location_updates, keep_alive_messages, debug_messages, .... | - | Sigfox, NB-IoT |
| Liveness distribution | Distribution of messages over the different time windows (from less then 5 minutes up to more or equal to 2 days) that are needed to have a message send from the tracker to the cloud. | This metric tells something about the need for data recovery and the traveling of trackers in non-covered areas. | Sigfox, NB-IoT |
| ECL0 ratio | ECL = Extended Coverage Level. ECL0 is the best level to have | The higher the ECL0 ratio, the better. | NB-IoT |
| Modem | Modem restart/reconnect count. Values = modem_restart_count, modem_poweroff_count |
This metric gives an idea on how often the tracker gets disconnected of the network. The lower the better. | NB-IoT |
| Modem active time | The active time in seconds of the modem (communication module in the tracker itself) | The lower the active time, the better | NB-IoT |
| ECL distribution | Distribution of the ECL levels used to transmit data. In the higher ECL
levels the repetition of the messages (on radio level) are increased, and it will
take longer to send data and it will use more battery energy. Values = ECL0 (good), ECL1 (worse), ECL2 (worst) |
NB-IoT | |
| Transmission band | Metric on how many messages are send over which transmission band. | Europe is band 20 | NB-IoT |
| Operator | Metric on which Telco network is used to send messages over the network. | When trackers travel around they can be communicating over different Telco providers due to roaming agreements. Sometimes, problems with the tracker are caused by the provider. Therefore it is interesting to know which provider is used by the tracker. | NB-IoT |
| Reference Signal Received Power (RSRP) | A key measurement of signal strength for modern LTE networks (NB-IoT) |
|
NB-IoT |
| Reference Signal Received Quality (RSRQ) | A key measurement of signal quality for modern LTE networks (NB-IoT) |
|
NB-IoT |
Location diagnostics
| Diagnostic metric | Description | How to interpret the diagnostic metric? |
|---|---|---|
| Location source distribution | Distribution of location technologies used to capture information by the tracker. Sources are: GNSS, geobeacon, Wi-Fi, ... | This metric could help us analyze how often each of the localization technologies are used. We could have an indication of which technology is the most used and use this localization technology as first in our configuration. We are currently working on bringing this information in the diagnostics of the organization for having a better overview on all the trackers. |
| Location trigger distribution | Distribution of the trigger that is used by the tracker to decide to capture a location. Triggers are: Start (the tracker has started to move), Stop (the tracker stopped moving), On the move (the tracker gets a location update while moving as defined in the tracker profile), periodic (the tracker gets periodic -e.g. every 2 hours- a location update as defined in the tracker profile) | This metric gives us an indication of which activity is used the most by the tracker. If there is a high number of messages per month on one of the activities (except start/stop) we could investigate if we can make a lighter configuration by reducing a bit the use of that activity. It can also be a good indication of using wrongly the activity of tamper/tilt/etc . |
GPS diagnostics
| Diagnostic metric | Description | How to interpret the diagnostic metric? |
|---|---|---|
| GPS fix success | The GPS fix success indicator is the ratio of the number of successful GPS fixes to the total number of attempted GPS fixes. | A ratio of 100% means all GPS locations are captured in an optimal way. If the success rate is low it can mean the asset is traveling more inside then outside and another tracker profile should be pushed to the tracker or a fine-tuning should be done to work optimally. Contact Sensolus support to align. |
| GPS fix distribution | Distribution of GPS fix attempts outcomes. Note that if the tracker does a
fallback to another localization technology (e.g. WIFI) and that succeeds it won't
be counted here.
|
Use this diagnostic to find an explanation for a low GPS fix success statistic. |
| GPS fix time distribution | Distribution of the GPS attempts durations. | Here you see the distribution of the fix time duration to capture a GPS location. Ideally the fix time is as short as possible or indoor_detect is used. The more locations take a long GPS fix time, the more problematic. Longer GPS fix time use more battery. |
| GPS accuracy distribution | Distribution of the made GPS fixes over the accuracy of the fixes from an accuracy less than 10 meter (<10m) up to more or equal to 320 meter (>=320m). | Ideally there is a combination of low GPS fix times and high GPS accuracy. But more often it is a trade-off between GPS fix time and GPS accuracy. Defining the optimal trade-off depends on the needs of the use-case. |
WiFi performance
| Diagnostic metric | Description | How to interpret the diagnostic metric? |
|---|---|---|
| Wi-Fi resolution success | The WIFI resolution success indicator is the ratio of sets of MAC's which resulted in a valid location versus all set of MAC's for which a location resolution was attempted. It gives an indication of the completeness and coverage of the resolution database. | This metric provides insight into the completeness and coverage of the resolution database. It's worth noting that a high-quality resolution database excludes non-static access points (e.g., car access points), so achieving 100% success may not always be feasible. |
| Wi-Fi | The number of successfull Wi-Fi resolutions versus the number of failed Wi-FI resolutions. | This metric shows the success of Wi-Fi messages in achieving resolution. "Yes" indicates the number of messages successfully resolved, while "No" indicates the number of messages that did not resolve. |
Journey
| Diagnostic metric | Description | How to interpret the diagnostic metric? |
|---|---|---|
| Short movement ratio | This metrics gives the percentage of the on- the-move (OTM) trip segments which are considered as short. Too many short trips means the tracker is probably too sensitive for motion. This can be changed through configuration of the tracker. | This metric helps to investigate if the reason of many short movements is due to the use case or due to incorrect configuration. If the tracker performs many short movements without really changing location then we should modify the configuration. |
| Journey completeness ratio | The Journey completeness ratio indicator is the ratio of the journey locations (start, stop, OTM) that arrived in the cloud and are visualized on the platform to the full journey locations that were send by the tracker. | A low journey completeness ratio can be explained by a low network coverage, so best is to check the transmission diagnostics. Ideally you have a 100% journey completeness ratio. |
| Short stop ratio | This metric gives the percentage of stop segments which are considered as short. Too many short stops means the tracker has probably a wrong stop time configuration. This can be changed through the configuration of the tracker. | Too many short stops will typically lead to too many localizations and messages which has a negative impact on battery life, Typically those stops are also irrelevant. 0% is the ideal score. A short stop is defined as a stop which is <30m. |
| Journey completeness | - | |
| Journey stop time distribution | This shows the variation in stop times of journeys. Too many short stops typically indicate that the motion sensitivity setting of the tracker should be tuned. Too many short stops can have a negative battery life impact. | If you have a high short stop ratio percentage, this metric explains why this happens. Based on this insights you can define a new configuration of a stop on the tracker. |
| Journey movement | This shows the variation in on-the-move times of journeys. Too many short journeys typically indicate that the motion sensitivity setting of the tracker should be tuned. | If you have a high short movement ratio percentage, this metric explains why this happens. Based on this insights you can define a new configuration of a stop on the tracker. |
Tracker behavior
| Diagnostic metric | Description | How to interpret the diagnostic metric? |
|---|---|---|
| Average number of reboots on a day | This metric gives the average number of reboots in a day. In normal operations without configuration changes it should be zero. | If this metric is higher than 1 per day and that happens often then we need to investigate why the tracker is rebooting. It can happen in different occasions such as that the tracker was wrongly installed and water entered the tracker or that the tracker was hit hard and it broke. If that happens sporadically, it would be advisable to investigate why the tracker had rebooted. It coulc happen because of firmware upgrade or changes in the configuration. |
| Number of reboots | This metric gives the average number of reboots in a day. In normal operations without configuration changes it should be zero. | If this metric is low then we need to investigate if that happens often, sporadically or if it was an one time event. If the number of reboots is very high them it might mean that the tracker is damaged and it might break soon. |