Open pturri opened 9 years ago
Currently you cannot use GPS to calibrate altitude. QNH1 and QNH2 have to be set by user.
Ok thanks, this was what I supposed but better to get your confirmation :)
Last question: are you planning to implement GPS autocalibration on next updates?
This might be more complicated. The GPS altitude is not the very precise. I would rather implement manual calibration using GPS, so the user will decide if he want to use it or not.
You are right, and I agree, IMHO anyway being GPS already on board it's a pity to do not exploit this information, there are some quite important advantages by using "also" GPS altitude:
As said, being GPS height already available, I'd suggest to add a further altimeter field showing GPS height, then you can decide to which Alt to rely more on depending on daily needs.
I agree, and I also like the baro alert function
TODO: Set Alt from GPS - Easy
What about the alert function? Say when Alt1 changes by 300m (configurable), then Alert pilot and set Gps alt to Alt1? What do you think?
I'm glad you accepted my small idea :)
Regarding alert, I think there are more approaches, depending on what you want to bring to pilot's attention:
1) Takeoff altitude wrong: GPS <-> Alt1 check at boot -> if 2 values too different = Alarm -> confirm to Set Gps alt to Alt1 (you migh feature also auto-calibration at boot)
2) pressure change warning: GPS <-> Alt1 timed check (30min?) -> if gap gets too big during the sampling period = Alarm "Severe pressure change!" -> confirm to Set Gps alt to Alt1 (and land... :) Being this ALSO a weather alert, you should find (or calculate) which is a reasonable pressure change per time unit that might lead to a weather degradation. I don't know this data, but it should not be hard to find. I can ask to a friend, he is a weather guru :) Thes idea is this: let's say your take off is at 1000m, in Standard conditions baro should read 878hPa. You switch Drop on e set GPS => Alt1 After 30 min, you are still waiting to take off, GPS reads always 1.000m, but Alt1 = 1300m Or, alike, you take off immediately, after 30 min GPS reads 2.000m (=760hPa) but Alt1 shows 2300m (729hPa) Besides the altitude mistake (not negligibe), that you can easily fix in flight, pressure dropped more than 30hPa in 30 min. This is definetly worrisome.... The only issue is how to get a GPS data to make warning reliable.A spot reading might be very wrong, 300m meteres are possibile, but if you average a certain sample I'm quite sure you can get a very precised GPS data. Note: actually this will make Drop the first vario with such weather warning ;)
3) In any case, I'd suggest to add an additional Alt5 (or AltG :) for GPS altitude value, at pilots taste.
So I will implement it like this
I think you are doing it the right way :+1:
for the pressure change warning: a quick weather change leads to a pressure change of 1-2 hpa/h. More than 2hpa/h means really stormy weather coming. This means an "altitude change" of 8-16m per hour. (1hpa -> about 8m) So a big average of the gps height is neccesary to avoid false alarms.
Thanks for implementing all those amazing features!
thanks for the update, you are really making this device wonderful!
2015-09-08 11:07 GMT+02:00 SonnenSimon notifications@github.com:
for the pressure change warning: a quick weather change leads to a pressure change of 1-2 hpa/h. More than 2hpa/h means really stormy weather coming. This means an "altitude change" of 8-16m per hour. (1hpa -> about 8m) So a big average of the gps height is neccesary to avoid false alarms.
Thanks for implementing all those amazing features!
— Reply to this email directly or view it on GitHub https://github.com/fhorinek/SkyDrop/issues/27#issuecomment-138488343.
Altitude setting from GPS is working really well on 6030. It seems the altitude coming from GPS is averaged in the GPS chip, sop on 6030 (if you set for altimeter to be set by gps, whi9ch is default) the altitude flashes until you launch and then setting is fixed. So you can see GPS altitude, compare to map/notice on launch etc. It is very repeatable and accurate in my experience (but I am starting instrument maybe 15 mins before flight every time, because I am a hang glider and I take longer to prepare!). I find setting like this gives me very good accuracy for altitude of even distant landing places after long flights.
Regarding pressure changes during the flight - I don't think even hang gliders can fly in weather where they cross a significant number of isobars on the pressure chart without being in danger!
This is much more useful than setting from a map (either printed or a terrain map in the instrument or another instrument) because normally we are on a steep slope and map altitude is hopeless - unless you are on an flat airfield.
Hi, I've a question related to QNH2 altimeter. I don't know why, probably testing the various options, I've changed the QNH2 value to 1013.19. I've tried to change this value to obtain the original value (1013.25) but I failed to do so, the only value that I can put in are 1013.19 or 1013.44 . There is a way to put in the original value 1013.25? Thanks.
I fully agree with moyesboy. The feature (for relative altimeters) like "set to GPS upon fix" would be great. Of course not after first 3D fix, but after a few (a minute or so).
An additional Option would be, to set ALT1 based upong GPS Position and AGL (gound Level data stored on SD Card). Surely, this is only possible, if AGL data is available.
After getting a (stable) GPS fix, we could offer the user the following question?
ALT1 is 1040m
GPS height is 1208m
GDL is 1180m
Set ALT1 to
GPS Nothing GDL?
< O >
IMHO a nice option, but not so accurate on steep slopes and the elevation map needs to be good, as the error is approximately equal to: (2D fix err + elevmap position error) * tan(slope angle) + elevmap height error.
Not so obvious which is more accurate (GPS height vs GPS 2d + elevation map), but if we could choose among setting to "GPS height" and "GPS 2d + elevmap" it would be great.
Anyway, PLEASE make an option of automatic setting of altimeters upon (stable) fix. I like to configure my instrument at home, and then at the site I just turn it on, give it some time when I'm preping for launch and fly. Without having to touch anything on the vario :-)
A 'Baro altimeter set from GPS on first fix' feature would be my preferred option. Average the GPS height over a short period after first fix, then set (with audio confirm sound). Likely to give much better results than DEM setting. As maticus suggests... fire and forget config setting on the Altimeter setting, not something that demands interaction with the instrument before takeoff is preferred.
Feature is implemented as https://github.com/fhorinek/SkyDrop/pull/323 and merged. Probably part of the next release. The functionality is as follows:
SkyDrop has up to 3 methods to obtain the correct height:
The implementation associated an error value with each source and uses the value from the source with the least error. This typically means:
Feature must be turned on in Settings>Altimeters>Alt1 (Auto calibrate: YES). Then NO pilot interaction is necessary. Will always calibrate as good as possible.
How does the implementation determine relative errors of 2. and 1?
Most flying will occur in areas that are not flat, indeed, the vario will normally be switched on at launch, so by definition the DEM approach will generally be discarded immediately.
GPS 3d has a certain reasonable (95%) accuracy expectation, depending upon VDOP figure. Averaging over successive positions can improve this. For a good VDOP value (1 or less), errors should normally be less than 75ft.
Barometer though, no idea. If last flying was on a standard atmospheric day of 1013.2hPa but today is on a high pressure day at 1023hPa, then a 300ft under reading error would be expected. How can the algorithm make any judgement about the validity of a previous flying day's pressure setting in comparison to today?
I would suggest that unless VDOP is quite high (above 2.5) an average GPS height should be the approach. Where VDOPis above this, and no surface calibration was possible then stick to the calibrated baro, but correct this as soon as VDOP becomes good enough...
Following methods are used for the error of
Hope that answers your questions. Currently, the implementation works quite well. I suggest we try it and improve it over time. Many suggestions are welcome.
OK, sow how I guess this will work in flight scenario...
Takeoff is on a hill... so DEM model is discarded. Barometer has 100m error estimate and GPS signal is OK, so GPS height is used to calibrate baro and Error is (perhaps) 30m which is transferred to Baro. Baro error now grows as flight proceeds. On a regular basis Baro error will be found to be greater than GPS error and a recalibration will occur.
Will this not lead to frequent height discontinuities in the log files? And vario 'glitches'?
I'd prefer the initial calibration to be left alone once it has been made, and also after takeoff have no recalibrations if the Skydrop is making an IGC log.
Only std pressure is recorded in the baro field of the igc. So no calibrations affect the igc recording.In theory you might fly a long way to a remote airfield, call them on radio for a pressure altitude number, and then reset your altimeter so it reads correctly for your landing approach. :)Well, you might, if you were a sailplane.On 2 Jul 2018 10:26 am, bluearcus notifications@github.com wrote:OK, sow how I guess this will work in flight scenario... Takeoff is on a hill... so DEM model is discarded. Barometer has 100m error estimate and GPS signal is OK, so GPS height is used to calibrate baro and Error is (perhaps) 30m which is transferred to Baro. Baro error now grows as flight proceeds. On a regular basis Baro error will be found to be greater than GPS error and a recalibration will occur. Will this not lead to frequent height discontinuities in the log files? And vario 'glitches'? I'd prefer the initial calibration to be left alone once it has been made, and also after takeoff have no recalibrations if the Skydrop is making an IGC log.
—You are receiving this because you commented.Reply to this email directly, view it on GitHub, or mute the thread.
You got it. :)
Two ideas:
You should try it out and report, what you think should be done to improve.
Igc is recording GPS altitude and standard pressure altitude, so its numbers are not affected by recalibration, so recording the recalibration is not recording anything that is actually affecting the igc recording, unless you added extra user set altitude fields that are not part of the civil specification.I don't understand and worry that you are recalibrating pressure altimeter that pilot is referring to using GPS altitude because while flying gps altitude is not accurate at all. During climb it climbs too fast, recording a considerably higher max altitude than barometric. If you drop low from launch and climb back up it records much lower than you went, usually under the ground. This is the case for all the GPS devices I have tested and is clearly visible from just about all igc files you might see from gliding flight.So GPS altitude while flying, unless you are cruising level with a motor, is not good for the pilot to refer to.If you recal altimeter with gps at top of last climb you will arrive too low at goal every time.Changes in pressure are usually small, because we are not capable of flying in weather where we can fly across many isobars on the weather map. Very long distances are along the isobars anyway ;)So using a fixed barometric altitude from launch is usually best. Base map if it is flat, GPS averaged over time if it is sloping.On 2 Jul 2018 10:45 am, "Dr. Tilmann Bubeck" notifications@github.com wrote:You got it. :) Two ideas: it would be better to turn on SkyDrop some time before the start (e.g. when you walk to the starting point). This would give it a chance to recalibrate based on DEM whenever you cross a "flat" area. Apart from that, you are rightYes, it will recalibrate during flight with GPS 3d (every few hours). We can enter a comment into IGC to explain this. I think that a recalibration is better, than a wrong altitude... Maybe we find some better handling of glitches. You should try it out and report, what you think should be done to improve.
—You are receiving this because you commented.Reply to this email directly, view it on GitHub, or mute the thread.
As the Geoid GPS height and baro reading are in the IGC, then the IGC should be fine. However altering the QNH setting for a barometric altimeter in flight automatically is not normal behaviour and I would rather the instrument can be configured to calibrate the altimeter QNH to GPS or DEM altitude, if in a flat area and on the ground, when it has a good signal and to leave it set to this value for the period of the flight.Adding altimeter labels to indicate type (GPS, auto-baro, baro, QFE) would be useful. As would widgets for VDOP and HDOP.On 2 Jul 2018 14:16, moyesboy notifications@github.com wrote:Igc is recording GPS altitude and standard pressure altitude, so its numbers are not affected by recalibration, so recording the recalibration is not recording anything that is actually affecting the igc recording, unless you added extra user set altitude fields that are not part of the civil specification.I don't understand and worry that you are recalibrating pressure altimeter that pilot is referring to using GPS altitude because while flying gps altitude is not accurate at all. During climb it climbs too fast, recording a considerably higher max altitude than barometric. If you drop low from launch and climb back up it records much lower than you went, usually under the ground. This is the case for all the GPS devices I have tested and is clearly visible from just about all igc files you might see from gliding flight.So GPS altitude while flying, unless you are cruising level with a motor, is not good for the pilot to refer to.If you recal altimeter with gps at top of last climb you will arrive too low at goal every time.Changes in pressure are usually small, because we are not capable of flying in weather where we can fly across many isobars on the weather map. Very long distances are along the isobars anyway ;)So using a fixed barometric altitude from launch is usually best. Base map if it is flat, GPS averaged over time if it is sloping.On 2 Jul 2018 10:45 am, "Dr. Tilmann Bubeck" notifications@github.com wrote:You got it. :)
Two ideas:
it would be better to turn on SkyDrop some time before the start (e.g. when you walk to the starting point). This would give it a chance to recalibrate based on DEM whenever you cross a "flat" area. Apart from that, you are rightYes, it will recalibrate during flight with GPS 3d (every few hours). We can enter a comment into IGC to explain this. I think that a recalibration is better, than a wrong altitude... Maybe we find some better handling of glitches.
You should try it out and report, what you think should be done to improve.
—You are receiving this because you commented.Reply to this email directly, view it on GitHub, or mute the thread.
—You are receiving this because you commented.Reply to this email directly, view it on GitHub, or mute the thread.
You can see VDOP, HDOP and PDOP in the GPS details view under "Menu".
I would like to be able to see them on a default startup screen which I look at as I'm getting ready...
Time Battery % GPS Satellites in view/GPS satellites used in fix HDOP and VDOP Altitude
Having to go into the menu to see GPS stats, not so good. If I don't like what I see on this screen (ie the GPS reception is bad because of a poor satellite geometry at this particular moment) I can make my own calibration of my main baro altimeter (which should set the error to zero...)
It seems I can alter all the atimeters 1 thru 5 on screen, and possibly while flying too? I would like to see one altimeter that is QNE, and not user settable. ie it displays the altitude being recorded in the igc file (1013.25mB = zero). Having now fiddled with the altimeters I have now also run into the issue of not being able to set QNH1 to 1013.25 anymore... was there a solution to that? seems I cant get any altimeter to read exactly what is being recorded in the igc... as per Fulminao commented on 9 Feb 2016
You should be able to use alt5 for exactly that if you haven't changed it in the setting. Try reset to factory.
I think it would be better to commit one altimeter to 1013.25mb, so it shows flight levels, and cannot be changed.I see that each one begins at 1013.25 but each one can be changed.... And the only way to get back to 1013.25 exactly is a factory reset...It coupld be named AltFL rather than Alti5 or whatever so its clear what it is and why it is not adjustable.On 12 Feb 2019 7:58 am, "Dr. Tilmann Bubeck" notifications@github.com wrote:You should be able to use alt5 for exactly that if you haven't changed it in the setting. Try reset to factory.
—You are receiving this because you commented.Reply to this email directly, view it on GitHub, or mute the thread.
i use this feature because i like the "turn on and forget" use of the device but each time i use the web configurator i have to manually put the option back in the vario after update. is there a place where we can find the option in the web configurator ? i didn't find the checkbox in https://vps.skybean.eu/configurator/#/altimeters
This could be a problem in the configurator. Which exact option should be saved? I don't understand this from your previous comment.
If I know exactly what is missing, we can fix it
The option to set the altitude 1 with GPS: "auto from GPS"
Cf https://image.noelshack.com/fichiers/2019/23/1/1559598573-img-20190603-233922.jpg
1) how is absolute altitude calculated at start up? Based on GPS data only? Or pressure+GPS? 2) can you briefly explain the difference between Alt's? Alt1 = Absolute to QNH1 Alt2 = Relative to Alt1 Alt3 = Relative to Alt1 Alt4 = Absolute to QNH2