TwoNav 6 amélioration de l'enregistrement des altitudes
TwoNav 6 intègre une correction qui est sensée amélioré les recalages automatiques du capteur barométrique.
- Dans cet exemple Altitude départ / arrivée IGN identiques 124 m
- TwoNav Terra part avec un décalage de + 5 m et a l'arrivée -1 m
- Suunto Part avec un décalage de - 2m et a l'arrivée - 1m
(Les PIC sur le rouge ce sont les passages sur ou sous des ponts rien d'anormal)
C'est plutôt bien, on était habitué a un glissement. Cette activité c'est un peu plus de 3h30 donc au moins 7 recalages a vérifier dans le log.
-
Thanks, that means you get the Altitude solely from the barometer without a calibration via cdem file, which is the standard value (Modo_Altura_Grabacion=3). Track is stored by timechange every 2s. All the other settings are the standard value (under navigation).
Actually I do prefer Modo_Altura_Grabacion=5 which means barometer with cdem calibration, since I'm using the device most of the time walking, that makes more sense for me, though I can't control how often the altimeter is calibrated via cdem file. I did play with the AltimeterKalmanFilterMeasError and found a value of 0.1 for my tastes better but that might be a delusion.
Regards
-
Thank you, interesting discussion on a complex subject.
- AltimeterKalmanFilterMeasError=0.5000000000 is for filter = medium
- AltimeterKalmanFilterMeasError=0.1000000000 is for filter = low
The Kalman filter acts on the calculation of the elevation difference, it does not act on the recording of altitudes. See the attached image, my previous activity) with the filter on low the situation between the resetting of the track on the DEM (RGE IGN) Suunto and TwoNav is the same (Suunto is always close the DEM/Dtm). On the other hand, concerning the elevation difference with a filter on low the difference is 64% and with a filter on medium the difference becomes 23% (Difference between elevation difference calculated by Land on the same track in one case these are the altitudes recorded by the GPS TwoNav and in the other the altitudes of the DEM/DTM IGN France)
I do not use Baro+Cdem for this type of case (illustrated in the image),
the route passes under a bridge placed on an embankment. The CDEM gives the altitude of the deck and you are underneath. If we analyze the case (analysis that I did recently) of a mountain route, you descend into a cirque (or on the side of a valley, or under the canopy) for example the horizontal location precision of the GPS deteriorates, the altitudes of the DEM used will be extracted from the adjacent slabs (Analysis done with a LIDAR DEM 0.5 m x 0.5 m x 0.5 m), during this analysis it is a hike on steep paths the view of the satellites is reduced the trace is rarely on the path (General problem in hiking due to the low speed). If you have loaded a less precise CDEM the altitude of the tile will rarely be that of the path it is an average value in the slab which includes this path. So either you type next to it with a precise DEM/DTM or it is an approximate value which depends on the size of the tile. If you cross a valley on a vine bridge the altitude of the DEM is the bottom of the valley with a precise DEM (e.g. mesh < 30m) otherwise it is somewhere between the deck and the bottom of the valley. In addition, the recalibration is not like a manual recalibration it does not bring the altitude of the barometric sensor back to the altitude of the CDEM, it compares the variation of altitude of the barometric sensor to that calculated on the CDEM to deduce a correction coefficient which will be applied for future recordings. So in the case of the "vine bridge" you will drag a biased correction until the next recalibration.
-
First altitude calibration (Log file)
- Start @ 11h52'15 "
- GPS ON @ 11h52'42"
- Gps time ok @ 11:53:20 (First fix time 38")
- Time synchronisation @ 11h53'56
- Altimeter callibation @ 11h53'56"
- LogCalibration: [Altimeter CDEM calibration] - Modo_Altura_Grabacion=3, altitudes (gps=-9999.000000, baro=110.060928, cdem=124.000000) iterationToCalibrate=1800 barometricAltitudeDrift=0.000000
- LogCalibration: [Altimeter CDEM calibration] - ERRORS SNR=40.200001 EVPE=11.200000 VDOP=1.390000 PDOP=1.770000 HDOP=1.110000 SATELLITES=12
- LogCalibration: [Altimeter CDEM calibration] - DIFFS diffBaroGpsAverage=0.000000 diffVdopAverage=0.000000.
A priori the first altitude recalibration is done on the CDEM after the first FIX
The starting altitude of the DEM/DTM is not fully taken into account deviations + 5 m (last activity) or + 3 m (previous activity) by TwoNav while Suunto is closer to the DEM profile. Next activity with the filter on high
First NMEA message 11h57'46"
The next altitude calibration come 30 minutes later with the GPS
- 12:23:56 LogCalibration: [Altimeter GPS calibration (next)] - Modo_Altura_Grabacion=3, altitudes (gps=146.000000, baro=149.455780, cdem=-9999.000000) iterationToCalibrate=1800 barometricAltitudeDrift=0.000000
- 12:23:56 LogCalibration: [Altimeter GPS calibration (next)] - ERRORS SNR=35.799999 EVPE=1.900000 VDOP=1.060000 PDOP=1.260000 HDOP=0.680000 SATELLITES=12
- 12:23:56 LogCalibration: [Altimeter GPS calibration (next)] - DIFFS diffBaroGpsAverage=4.742414 diffVdopAverage=0.874375
- 12:23:56 LogCalibration: [Altimeter calibrated OK!] - Modo_Altura_Grabacion=3, altitudes (gps=146.000000, baro=149.455780, cdem=-9999.000000) iterationToCalibrate=1800 barometricAltitudeDrift=0.000000
- 12:23:56 LogCalibration: [Altimeter calibrated OK!] - ERRORS SNR=35.799999 EVPE=1.900000 VDOP=1.060000 PDOP=1.260000 HDOP=0.680000 SATELLITES=12
- 12:23:56 LogCalibration: [Altimeter calibrated OK!] - DIFFS diffBaroGpsAverage=4.742414 diffVdopAverage=0.874375
Bilan :
Altimeter GPS calibration
- GPS 146 m
- Baro 149.45
Altitude recorded track : 150m, altitude terrain (DEM) 144 m => erreur +6 m (+5 m au départ, variation +1m)
[Altimeter calibrated OK!] - DIFFS diffBaroGpsAverage=4.742414 diffVdopAverage=0.874375
CDlt
-
Hi, I find this a very interesting discussion and findings. Especially also the findings about the automatic barometer calibration in Modo_Altura_Grabacion=3. Thanks for that. What I don't understand is why the Kalman filter is not finding its way into the track recording. From where did you get that info?
Regards
-
Sideinformation:
We have the oportunity to choose between Kalman(2), Exponential(1) or No Filter(0):
[Navigation]
AltimeterFilterType=2 (standard)
[Tracks]
FilterToolType=1 (standard)
Kalman allows a filterintensity setting:
[Navigation]
AltimeterKalmanFilterMeasError=0.5000000000 (standard)
[Tracks]
FilterToolKalmanMeasError=0.1 (standard)
and a Q-Variance setting:
[Tracks]
FilterToolKalmanQ=0.01 (standard)
[Navigation]
AltimeterKalmanFilterQ=0.05 (standard)
Exponential Filtertool adaption via:
[Tracks]
FilterToolExponentialAlpha=0.2 (standard)
-
First observation: the effect of the filter is manifested on the elevation difference value; there is no impact on the recorded altitude.
Next, Kalman filtering, by definition, applies to a series of measurements, integrating their uncertainties. This is possible for altitudes if the equipment is capable of measuring altitude at high rates (10 times per second, for example).
In the case of interest to us, the principle consists of comparing the barometric altitude variation to the average variation (elimination of noise on GPS altitude) of GPS altitude over a period of 30 minutes (20 minutes for Suunto). Then, the "covariance parameters" applied by a pseudo-Kalman are probably derived from the EVE. If we observe this specific case, EVPE = 1.9 and diffVdopAverage = 0.874375, which is not far from 0.5, which is the parameter setting. By making some assumptions we will end up obtaining the equation
-
"Sideinformation:"
Without information on the variation domain (value max, value min) of these parameters it is difficult to use them.
We have the oportunity to choose between Kalman(2), Exponential(1) or No Filter(0):
[Navigation] AltimeterFilterType=2 (standard) => Kalman
[Tracks] FilterToolType=1 (standard) =>>>>> Doesn't exist for my GPS
The track filter was a question for me, it is not accessible via the menu, but we can clearly see its effect on the track, the origin, the cause of its creation, I think I understood
Kalman allows a filterintensity setting:
[Navigation]
AltimeterKalmanFilterMeasError=0.5000000000 (standard)
0.1 , 0.5 or 1 , button Low, Medium or hight
Parameter missing from [Track] ? Value From ? min to ? max
- FilterToolKalmanMeasError=0.1 (standard)
- FilterToolKalmanQ=0.01 (standard)
- FilterToolExponentialAlpha=0.2 (standard)
Parameter missing from [Navigation] ? Value From ? min to ? max
- AltimeterKalmanFilterQ=0.05 (standard)
Parameter missing from [Tiempo real] ? Value From ? min to ? max
[TiempoReal]
Umbral_VDOP_Altimeter=1.5 (standard)
Umbral_PDOP_Altimeter=3 (standard)
-
After some research I'm sure we can set a filter to a selectable value recorded in the track. Value is defined in the FiltertoolDatafield section, in this case it is the recorded altitude (6).
[Tracks]
FilterToolDatafield=6
FilterToolType=1 (standard=Exponential, 2=Kalman, 0=no filter)
FilterToolKalmanMeasError=0.1 (standard)
FilterToolKalmanQ=0.01 (standard)
FilterToolExponentialAlpha=0.2 (standard)
And from an older options.cxml some values:
<Property name="Select datafield to filter" mag="117" type="1" c1="Tracks" c2="FilterToolDatafield">
<Value id="6"/> <!-- CAMPOPV_altura -->
<Value id="44"/> <!-- CAMPOPV_altura_barometrica -->
<Value id="43"/> <!-- CAMPOPV_altura_GPS -->
<Value id="94"/> <!-- CAMPOPV_presion_atm -->
<Value id="3"/> <!-- CAMPOPV_velocidad_gps -->
<Value id="378"/> <!-- CAMPOPV_bike_speed -->
<Value id="376"/> <!-- CAMPOPV_heart_rate -->
<Value id="377"/> <!-- CAMPOPV_bike_cadence -->
<Value id="575"/> <!-- CAMPOPV_POW_instantaneousCadence -->
<Value id="27"/> <!-- CAMPOPV_POW_power -->
</Property>
-
BTW: Tracks recorded in trk format have additional information depending on the datafields (not only in the mapscreen). Those infos are stored in the x values section. Here is an entry from a recent track of mine:
X 94,91,92,57,350,59,696,
Those values correspondent with these variables:
Air pressure,GPS altitude,Barometric altitude,Land Altitude,HDOP,Slope,Speed (rolling average)
and here a some example values for them:
x 100615.00,135.00,129.00,129.00,14.11,0,0.50
-
Regarding the X –values int trk files.
First of all, those are no official informations, I collected them via trial and error, so they have some speculative factor too.
I found out that while in PROTO mode, I could to a certain extend change the variables in the X field by changing the datafield (not only in the mapscreen). This might be during a track recording too, resulting in additional X values in the middle of a track. For instance my datafield (mapscreen) shows the following data (no external sensors connected):
Distanz (activity), time (activity), altitude (baro), HDOP
The X values in the recorded tracks are:
X 94,91,92,57,350,59,696
Which corresponents to:
Air pressure,GPS altitude,Barometric altitude,Land Altitude,HDOP,Slope,Speed (rolling average)
If external sensors are connected, the X variables change too.
-
Uwe,
Playing with Twonav's internal settings is extremely interesting for understanding how it works, but be aware that their scope can very well change from one firmware version to another. Without the source code, it's impossible to know whether such a setting is permanent or not.
Best regards, -
Bonjour,
Rappel : Recalage automatique sur le CDEM après le premier FIX (J'utilise la carte CDEM "5m" disponible sur le site de Bernard)
Précédemment
- Biais Départ / Arrivée 5 m / 2m -
Dénivelé
- AltimeterKalmanFilterMeasError=0.5000000000 is for filter = medium => écart IGN /TwoNav + 23%
- AltimeterKalmanFilterMeasError=0.1000000000 is for filter = Low => écart IGN /TwoNav + 63%
Exploration du jour
- AltimeterKalmanFilterMeasError=1.000000000 is for filter = Hight => écart IGN /TwoNav + 16%
- Biais Départ / Arrivée constant +5 m / +2m
Altitudes GPS en vert Altitudes IGN en rouge
A suivre
-
After some consideration I'm quite certain, that the gps.ini entries regarding the altitude under the section:
[navigation]
are used and intended to predict the altitude for the planned route. Here is a list of all possible entries in this section:
[Navigation]
AltimeterFilterType=2 (standard, possible are: Kalman(2), Exponential(1) or No Filter(0))
AltimeterKalmanFilterMeasError=0.5000000000 (standard)
AltimeterKalmanFilterQ=0.05 (standard)
Short_Distance_Algorithm=
DisableWifiWhenNavigating=
WifiActiveBeforeNavigating=
Using them either in Land or on the device helps Twonav to create a prediction, what is coming out of the data they have (cdem, altitude entries in the track). Using them on an activity that has been done, which I think is happening in Therrys case, does change the output quite, since it intermingles recorded data with an underlying cdem data source.
As I wrote before, activity recording filters are most probably to find in the [Tracks] section. The field FilterToolDatafield defines, on which recorded value those filters are applied:
[Tracks]
FilterToolType=1 (standard=Exponential)
FilterToolKalmanMeasError=0.1 (standard)
FilterToolKalmanQ=0.01 (standard)
FilterToolExponentialAlpha=0.2 (standard)
FilterToolDatafield=6 (standard=altitude)
The above and by me added entry (standard) marks the default value for that entry and is used by Twonav if no other entry is present.
-
Bonjour,
Constat suite à 4 activités enregistrées avec TwoNav 6, chacune avec une option de filtre différente
Le filtre des altitudes agit sur le calcul du dénivelé effectué sur l'enregistrement des altitudes, il ne semble pas agir sur les mesures d'altitude (Pas de constat différents sur le profil des altitudes enregistrées).
Les altitudes prévisionnelles, courbe en bas de l'écran sont celles enregistrée par Land dans la ROUTE a suivre.
Bonnes randonnées
-
Not sure if it is a language problem, but that sentence doesn't make sence to me and if we are speaking about differences we should certainly quote between which factors.
The altitude filter acts on the calculation of the altitude difference carried out on the altitude recording, it does not seem to act on the altitude measurements (No different findings on the profile of the recorded altitudes).
-
En toute logique:
- Vu qu'a pied ou sur deux roues le contact est permanent avec le sol,
- Vu que le DEM/DTM est le niveau du sol hors "Apports" de l'homme,
- Si l'itinéraire reste au niveau du sol (absence de pont, de viaduc, ou tout autre construction séparant le cheminement reel du niveau du sol)
- Si la précision du GPS est bonne... Si la position reste bien sur le chemin,
Oui ça doit être quasiment identique, et si c'est identique ca montre que la mesure et l'hybridation Baro /GPS est bien faite..
Maintenant..
- Si l'itinéraire passe sur des tablier de pont, des viaducs, en tunnel. Le trajet dans le plan vertical n'est plus sur le DEM (Il est au dessus ou en dessous)
- Si l'itinéraire est a flanc de montagne ou de combe, la précision GPS va se dégrader et l'altitude prélevée sous cette position (dans le cas de l'utilisation d'un DEM) ne sera pas celle de l'itinéraire (C'est l'exemple de la descente dans la combe de Navacelles analysée il y a quelques semaine)
- Si le DEM/DTM est composée de grande dalle, l'altitude sera une moyenne de la surface et la précision sera dégradée
Donc Oui & Non c'est selon la situation..
Il se trouve que l'exemple utilisé dans cette illustration est une zone vierge "d'apports humain", sans combes mais avec un relief très "tourmenté", détaillé et disponible avec deux précisions le RGE ALTI et LIDAR 0.5 m.
Donc c'est la situation parfaite ou la différence entre le DEM précis et la mesure Baro Hybridée GPS doit être la plus minimaliste, ce que montre cet exemple.
Please sign in to leave a comment.
Comments
25 comments