1

Speed Manipulation

(edited by Fernando Brochetto 28/10/2020 19:43:45)

Topic: Speed Manipulation

Hello,
We often have troubles when the subject is speed.

Problem:
As the equipments get the speed by GPS, it happens sometimes that the speed sent to Wialon is incorrect, you can see for example in the screenshot the difference between the speed by GPS and CANBUS. As you can see in the example, the tracker have 10 sats, so there is no option that a filter could ignore this messages, and as this is very frequently in large scale, there is no way to be deleting every message with error. If I'm not wrong, I've already saw other partners asking for this feature and other partners that asked for a new unit of speed:

https://forum.gurtam.com/viewtopic.php?id=15381

Solution:
I think that two things could be done:
1 - Create speed sensors;
2 - Create an algorithm similar to the fuel smoothing (I don't really know if this funcion would work fine).

Users:
With the speed sensores, would be able to use the CANBUS speed, the most reliable data and also could manipulate parameters to smooth speed parameters, for example using aritmetic average: (speed + #speed)/const2, or even relate speed to motion status (very often the vehicle is parked but GPS give some speed around 1-10 km/h).
Also, they would be able to convert speed in any unit required.

Fernando Brochetto
Technical Support, Rastreasul

fernando@rastreasul.com.br
2

Speed Manipulation

Re: Speed Manipulation

Hello Fernando  Fernando Brochetto!

First of all, I apologise for this long delay in response.
It took some time to analyse the task and search for similar requests. Indeed, you are right, there were enough requests to use the speed received from the canbus. And it's strange to see that nobody has supported you in more than a month on the forum.

What kind of implementation option we see now.
Your proposal to have a separate type of sensor with its own parameter seems to be the most optimal at the moment. But there is a nuance here: the sensor will not be used for all speeds, but specifically for the speed from the canbus. In other words, in order to receive and use the speed from the canbus, rather than the GPS speed, you will need to create a sensor with the conditional name 'Speed Adjustment', specify a parameter in which we will receive the required speed value (if necessary, perform any transformations of the parameter in the sensor) and activate its operation. What will happen next?
We propose this mechanism:
1) after the next message arrives, we will analyse the presence of the sensor described above at the unit and whether it is activated or not;
2) if the sensor is activated, we will replace the GPS speed value when registering the message with the value obtained in the parameter, i.e. from the canbus.
3) the system will continue to function as it does now, i.e. no additional settings for reports, notifications, etc. will be required.
Restrictions:
1) will work for position messages (when we receive coordinates)
2) the values must be valid.

I have described to you the simplest and most painless implementation option. What do you think about this? Do you have any additional questions or clarifications? 

I will add the task to the list of suggestions for product development. In any case, we will conduct an in-depth needs analysis and think about how we can make implementation more optimal and convenient for our partners. Therefore, your questions, comments and suggestions will be very useful to us.

Unfortunately, you are not allowed to view this text

Nastassia Maslovskaya
Business Analyst, Gurtam
3

Speed Manipulation

Re: Speed Manipulation

Hello mana, thank you for the answer!
Yes, that's perfect, the presence of the sensor only when needed is even better, generally our clients don't care much about irregularities, but we have customers who are very restricted.

Fernando Brochetto
Technical Support, Rastreasul

fernando@rastreasul.com.br
4

Speed Manipulation

Re: Speed Manipulation

I vote for the above feature. It must be included in the Wialon Hosting.