Inav: Investigate what default should be used for SBAS - NONE or AUTO

[iforce2d]

Attempting to use ground assistance in regions with poor SBAS coverage can cause many satellites to be ignored (all GLONASS sats and even many GPS sats too). In the worst cases, this can cause GPS fix to be abandoned completely.

http://www.rcgroups.com/forums/showthread.php?t=2495732&page=384#post34725614

Currently there is no option in the configurator to disable the ground assistance type used by the GPS receiver. It's either auto, or a specific SBAS region.

By doing set gps_auto_config=OFF in the CLI, it is possible to skip all GPS module settings, but this is not ideal for two reasons:

1. Skipping GPS config does not disable SBAS, it just does not enable it (ie. if it was already enabled it will remain enabled)
2. Skipping GPS config also skips all the setup necessary to use UBX protocol for most modules which use NMEA by default.

I think it would be great to have a 'Disable' option in the 'Ground assistance type' combobox in the configurator.

[digitalentity]

Shame on me! I forgot about SBAS! The recent complaints about sat loss might in fact be related to ground assistance - since this is the only thing that does not get enabled when doing manual config and is enabled in auto.

[digitalentity]

0037380fc0e09ef2600eb82626cd4dee79867953 allows to disable SBAS. Settings changed - those who had it set to AUTO will now get DISABLED.

[iforce2d]

Thanks! From a backwards compatibility point of view I would be more inclined to add the new option at the end of the enum so that existing installs are not affected.

[theArchLadder]

I think disabling SBAS is the wrong approach and here's why:

After reading the wiki this is my understanding of SBAS:
A few ground stations with known locations receives the GPS satellites and measures/figures out a few different errors in the GPS signal/position etc, then this information is sent to a SBAS satellite that then broadcasts this correction information that our multirotors can receive to get a more accurate position reading. Sounds like a good thing to have.

I have been playing around in u-center, i have plenty of both gps and glonass sats used, but when i get a lock to a SBAS sat, all my GLONASS sats becomes unused, so this is the "gps dropout" problem we'll been having.

But, i think i found a solution that lets us have the cake and eat it too! :)

In u-center, there is a setting for SBAS called "apply integrity information", with inav default this is enabled, but it's disabled with ublox defaults. When i disabled this, i no longer lost my GLONASS sats! I have been bench testing for more than an hour and i have around 15 sats all the time while having SBAS lock, even though my gps unit is close to my house. Yay!

I think the code here
https://github.com/iNavFlight/inav/blob/master/src/main/io/gps_ublox.c#L143
Should be changed to this, please confirm this though since i had some issues with hex stuff in u-center

EDIT: Checksums are wrong here, do not use these lines!

    { SBAS_AUTO,  { 0xB5, 0x62, 0x06, 0x16, 0x08, 0x00, 0x03, 0x03, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x31, 0xE5}},
    { SBAS_EGNOS, { 0xB5, 0x62, 0x06, 0x16, 0x08, 0x00, 0x03, 0x03, 0x03, 0x00, 0x51, 0x08, 0x00, 0x00, 0x8A, 0x41}},
    { SBAS_WAAS,  { 0xB5, 0x62, 0x06, 0x16, 0x08, 0x00, 0x03, 0x03, 0x03, 0x00, 0x04, 0xE0, 0x04, 0x00, 0x19, 0x9D}},
    { SBAS_MSAS,  { 0xB5, 0x62, 0x06, 0x16, 0x08, 0x00, 0x03, 0x03, 0x03, 0x00, 0x00, 0x02, 0x02, 0x00, 0x35, 0xEF}},
    { SBAS_GAGAN, { 0xB5, 0x62, 0x06, 0x16, 0x08, 0x00, 0x03, 0x03, 0x03, 0x00, 0x80, 0x01, 0x00, 0x00, 0xB2, 0xE8}}

the 8th number should be 0x03 instead of 0x07 as long as i got everything right... I guess the last two are some error checking

[theArchLadder]

To clarify: I think it would be wrong to have "SBAS disabled" as the default, I'm not against a "disabled" option even though i don't see any use for it with my fix...

[stronnag]

I fear you have forgotten to update the checksums, and the hex strings should be (according to my tacky little ub_chk script):

0xb5, 0x62, 0x06, 0x16, 0x08, 0x00, 0x03, 0x03, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x2d, 0xc9
0xb5, 0x62, 0x06, 0x16, 0x08, 0x00, 0x03, 0x03, 0x03, 0x00, 0x51, 0x08, 0x00, 0x00, 0x86, 0x25
0xb5, 0x62, 0x06, 0x16, 0x08, 0x00, 0x03, 0x03, 0x03, 0x00, 0x04, 0xe0, 0x04, 0x00, 0x15, 0x81
0xb5, 0x62, 0x06, 0x16, 0x08, 0x00, 0x03, 0x03, 0x03, 0x00, 0x00, 0x02, 0x02, 0x00, 0x31, 0xd3
0xb5, 0x62, 0x06, 0x16, 0x08, 0x00, 0x03, 0x03, 0x03, 0x00, 0x80, 0x01, 0x00, 0x00, 0xae, 0xcc

or in terms of the new branch settings:

 {{ /* SBAS_NONE */  0xb5, 0x62, 0x06, 0x16, 0x08, 0x00, 0x02, 0x03, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x2c, 0xc1 }},
 {{ /* SBAS_EGNOS */  0xb5, 0x62, 0x06, 0x16, 0x08, 0x00, 0x03, 0x03, 0x03, 0x00, 0x51, 0x08, 0x00, 0x00, 0x86, 0x25 }},
 {{ /* SBAS_WAAS */  0xb5, 0x62, 0x06, 0x16, 0x08, 0x00, 0x03, 0x03, 0x03, 0x00, 0x04, 0xe0, 0x04, 0x00, 0x15, 0x81 }},
 {{ /* SBAS_MSAS */  0xb5, 0x62, 0x06, 0x16, 0x08, 0x00, 0x03, 0x03, 0x03, 0x00, 0x00, 0x02, 0x02, 0x00, 0x31, 0xd3 }},
 {{ /* SBAS_GAGAN */  0xb5, 0x62, 0x06, 0x16, 0x08, 0x00, 0x03, 0x03, 0x03, 0x00, 0x80, 0x01, 0x00, 0x00, 0xae, 0xcc }},
 {{ /* SBAS_AUTO */  0xb5, 0x62, 0x06, 0x16, 0x08, 0x00, 0x03, 0x03, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x2d, 0xc9 }},

[DzikuVx]

Yay... no more broken landing gear on emergency landing? Cool!
And by the way I also agree with @theArchLadder that disabling "integrity check" might be better than forcing SBAS disabled in AUTO configuration

[theArchLadder]

I just did a flight test, almost all my logs from before look similar to the first graph, thats a flight from yesterday, last two graphs are with the fixed setting i talked about here, looks great! I guess it's to early to call out victory from just one test flight, but this feels promising since i did the testing in u-center with the same result earlier today.

[digitalentity]

@theArchLadder, @stronnag thanks for figuring the new ubx sentences!
I've also switched AUTO and NONE, existing setups won't be broken.

[iforce2d]

I noticed that the defaults for these settings are to disable the test satellites and integrity information:

This is a good hint from the manufacturer that the best typical setting is to have these disabled. It might also explain why the dropping satellites behavior stopped for some users when they turned gps_auto_config off, because the Cleanflight config enables everything.

By the way, it's pretty easy to get the hex strings and checksums from u-center, no need to calculate them yourself. Here's the setting that Cleanflight has been applying until now - everything on hehehe...

And here is the default setting according to the Ublox docs:

This is what @theArchLadder has suggested above, but with test satellites disabled as well. I'm about to test this now, will update later.

Side note: isn't it great to be able to discuss a single topic in one thread without dozens of different conversations going on, across hundreds and hundreds of pages? I can't stand the way threads are done on RCGroups, which is why I hardly ever post there despite having an account for a long time. And the other suggestion I hear about asking on the IRC chat is even worse, don't get me started. I think a dedicated Cleanflight forum is long overdue... anybody else agree?

[iforce2d]

I tested with settings as in the last screenshot of my post above, but I think for my geographical location this is not ideal either. The problem is that when SBAS kicks in the quad will suddenly re-position itself. It usually only moves about 2-3m in the cases that I saw, but the movement is very sudden and 2-3m is further than the 1.5m or so range that it stayed within when I had SBAS disabled completely. Position hold did seem slightly better, but not significantly.

I guess it will depend on how spotty the SBAS signal is in your location and what you're using your multi-rotor for, but I think for my situation I'll stick with the SBAS_NONE setting to be safe.

[digitalentity]

@iforce2d
Yes, IIRC SBAS is used to improve absolute accuracy that is only relevant when doing autonomous flights (missions). For poshold and RTH we use relative positioning and SBAS probably won't greatly improve perfomance

[digitalentity]

I wonder if we can upgrade to 3 settings for GPS nav model:
LOW_G = Pedestrian (better GPS reception, suitable for slower drones)
MED_G = Airborne<1G (a balanced setting)
HIGH_G = Airborne<4G (top-end performance at cost of higher sat quality requirement)

[oleost]

@digitalentity Good idea, but I would be very carefull with Pedestrian.

Atleast not default, and with warning that this is mostly for only flying in GPS assisted modes with limited speed.

There are multiple of us having fly aways with Pedestrian.

I know other flightcontroller have success with Pedestrian, maybe there is an issue with iNav how it uses the GPS data ?

[theArchLadder]

@iforce2d I use linux (archlinux) so i run u-center in wine and i have also tried it in virtualbox on window7. In the settings window there is a small button in the bottom row called "show hex toggle", but it's grayed out for me do i can't click it. So i can't get u-center to show me the hex codes... How do i get that to show?

@digitalentity Sounds good but IMHO LOW_G should not be the default because of the fly-away risk. I have not tried <1G yet...

@digitalentity Do you think we could bbox log the SBAS status?

I took a closer look at the log from the graphs i posted here before, and GPS height seems very accurate! I just happend to stand next to a lake that i know is 88 meters above sea level, and i was standing around 5 meter above that lake, and indeed, the GPS height shows 93 meters! It only logs at meter-precision, but it looks like GPS height follows baro height really well, i need to start logging GPS height at centimeter-precision...

I'm curious if the GPS can be used for althold when it has a good HDOP/sat count and SBAS...

EDIT: Would be awesome if someone could tell me where i change from meter to centimeter for gps height logging... EDIT2: is it just here? https://github.com/iNavFlight/inav/blob/master/src/main/blackbox/blackbox.c#L992

[iforce2d]

@theArchLadder I'm using u-center via wine in Fedora linux and the hex toggle button just works, don't know how to help about that. I did notice though, that when the hex panel is hidden, you don't need the button to show it, you can just drag the divider upwards from the bottom of the window. I also noticed that if I drag the divider all the way down when the hex view is showing, it sets the hex view size as zero so that subsequently the button appears to have no effect - perhaps you did this earlier?

[theArchLadder]

@iforce2d The divider works as you say for "full form toggle" (left side panel), and i can just drag that back, but there is no divider at the bottom... Same thing in both wine and windows7. What version of u-center are you running? I use v8.20

As for your side-note from before: Yes i agree, this is much better than RCGroups. I like how we all helped in our own ways to solve this together, even though you made most of the work... This really show the beauty of open-source development :) I think this issue tracker should be used more, and with wider topics for discussing possible solutions/improvements... Not just "Solve this specific bug with this solution".

[digitalentity]

@theArchLadder
LOW_G (Pedestrian) won't be a default, it would be a user-selectable option. I also think we need better names for these LOW_G, MEG_D, HIGH_G. Ideas, anyone?

We don't collect SBAS or SV data from GPS unit for the sake of minimizing the jitter of GPS data - that's why we have detailed satellite information removed.

GPS altitude is used for AltHold in airplanes and it works rather well.

[theArchLadder]

Has anyone been able to find any information on how big the improvement in accuracy usually is with SBAS?
How can i tell in u-center if my GPS is using SBAS or not...?

[iforce2d]

@theArchLadder I'm using u-center v8.13. In one of the docking panels with status display of lat/lon, HDOP, 3D Acc etc there is a 'Fix mode' which should display 'DGPS' when the fix is currently using differential GPS.

I would be surprised if the SBAS improvement is any more than a few meters. I think to be sure about that you need a location for which you know the absolute real lat/lon, not as easy as you might think :)

[theArchLadder]

https://en.wikipedia.org/wiki/Global_Positioning_System#Accuracy_enhancement_and_surveying
This claims that accuracy can go from 15 meters to 3 meters with SBAS-WAAS.

https://en.wikipedia.org/wiki/Wide_Area_Augmentation_System#Accuracy
This claims that "Actual performance measurements" show better than 1 meter accuracy.

I watched some youtube videos and got the impression that SBAS is very important for aviation when doing landing approach in fog etc.

So it seems to provide a big benefit, but the question still remains if it's only absolute accuracy, witch is not that important to us, or if it also improves relative accuracy... I guess i will have to try and do some test myself...

[theArchLadder]

I just did a test flight with GPS enabled for althold with these settings:
inav_w_z_baro_p = 0.00
inav_w_z_gps_p = 0.500
inav_w_z_gps_v = 0.200
And it sort of works, it's more stable compared to baro, non of those jumping up and down, but it did drift very slowly 2-3 meters up.

I then tried these settings:
inav_w_z_baro_p = 0.100
inav_w_z_gps_p = 0.000
inav_w_z_gps_v = 0.200
And it did look smoother than just baro. Perhaps using both gps and baro could be a good thing for althold, more testing and tuning will tell i guess.

Blackbox got full so no logs :(

[iforce2d]

Absolute accuracy implies relative accuracy, doesn't it? It's relative to 0,0 :)
When I lived in Japan with good SBAS coverage I did many tests where I matched the results of two separate modules (a 'follow-me' RC car) and it worked very well, often to the meter. I'm planning to do this with a quad now in NZ without SBAS, so I really hope the uncorrected position error of the two modules is the same.

[digitalentity]

@theArchLadder your settings didn't make AltHold use GPS.
Multicopter: BARO only even if GPS is avaliable
Airplane: BARO + GPS fused together per inav_w_* settings.

[theArchLadder]

Well, if the absolute position on average has a 10 meter error to east, it would be possible to just offset the position with 10 meters towards west, but this would not improve relative position, right?

[iforce2d]

Relative to what?

[digitalentity]

@iforce2d relative to point of launch.

[theArchLadder]

@digitalentity I removed STATE(FIXED_WING) from here:
https://github.com/iNavFlight/inav/blob/master/src/main/flight/navigation_rewrite_pos_estimator.c#L519
I think this should be enough to use gps, right? I doubt it would hold altitude that well without any position sensor...?

[DzikuVx]

Relative to previous readout/point of launch. PosHold needs to know diff between current and target position that was also recorder by current readout. So it does not matter if acquired position is 10m to East or even 100km to south. As long as each acquired position has low error comparing to target, everything is OK.
But if you plan WAYPOINT to move to x/y and UAV thinks x/y is somewhere else, there will be a problem. This is absolute

[iforce2d]

I see. Maybe repeatability is a better word. No, I don't think SBAS will help with that.

[digitalentity]

@theArchLadder @DzikuVx @iforce2d
I think "Disabled" is a safer default. SBAS kicks in significantly later than initial fix is acquired. This may happen when the quad is already in flight and will introduce some unknown shift to absolute positioning. This will cause PosHold to change position rapidly but what's even worse - it will change the launch point position! RTH will return the quad to a different point!

[theArchLadder]

@digitalentity Have you seen this shift in testing?

I have done multiple flights now and i have not seen any shifts in either poshold or home-location. But i guess safety and consistency is more important than peak performance, so perhaps "disabled" is a better default.

I think the real question that needs to be answered is if SBAS does improve relative position accuracy or not...

[digitalentity]

I have seen a sudden single occurance of position drift a few times (2-3m usually). Suspected bad sat coverage (it was 6-7 sats), but now I figure it might actually be SBAS kicking in.

[iforce2d]

I saw shifts a few times within about ten minutes, I must be in a pretty bad location for this :) For me it was also about 2-3m, and along the same direction each time. This was with SBAS enabled and the integrity information disabled. I often test hovering just off the ground, in those cases I rarely see it until I go higher.

Yes, I think disabled being the default is safer and might avoid some "what's going on?!" moments for newer users. If possible a 'what is SBAS?' link to info in the configurator might help people to decide in a more educated way than just thinking "uhh... auto is good right?" like I have been doing all this time :) It would be a pity not to use it if you live in a region with good coverage, which is probably the majority of users.

[theArchLadder]

@iforce2d Are those shifts gone when you disable SBAS though?

[iforce2d]

@theArchLadder so far, yes. https://www.youtube.com/watch?v=odConQAhMsY
I'll do some more testing this week.

[theArchLadder]

@iforce2d Good to know, i will also investigate this, my plan right now is to leave my quad sitting in a field while the blackbox is recording and do this for like 15 minutes with SBAS off, then SBAS on, and calculate the average RMS error to the average position... And i guess max/min error could also be interesting. And graphs... Well this escalated quickly!

If anyone has a better idea on how to measure the relative position accuracy, let me know!

EDIT: Would be nice to have a way to confirm that SBAS is active, i don't have a laptop so using u-center will be difficult...

[digitalentity]

Guys, what do you think about 1f49891? Now 3 dynamic modes for Ublox autoconfig - conservative PEDESTRIAN, somewhat optimal AIR_1G and extreme AIR_4G. I've also renamed the setting to avoid confusion.

[digitalentity]

@theArchLadder we can subscribe to an SBAS message, but do we have any use for this info?

[theArchLadder]

@digitalentity Looks fine to me, naming is more clear but harder to remember, is there a way to list possible alternatives for an setting in cli?

As for SBAS: I think this would be useful for debugging and investigating the benefit of SBAS.

[digitalentity]

Something like set parameter_name=? could list min/max or alternatives. Good idea. Opening an issue for this - #198

[stronnag]

Tested 1f49891, never seen the sat count so stable. Great fix.

[digitalentity]

@stronnag thanks for testing. I'll merge this after testing on a not-so-good Ublox7 module today that seem to work acceptable only with Pedestrian setting.

[theArchLadder]

Please merge ASAP, it's a big improvement over current code... And i keep forgetting to merge sbas-none branch into my own custom build branch :wink:

IMHO we should keep this issue open to investigate if NONE or AUTO should be the default.

[iforce2d]

Tested 1f49891, behavior seems the same (not sure what I'm looking for exactly) except that this time it showed 18 satellites, first time I have seen that many since disabling SBAS. Of course this might just be dependent on their current position in orbit...

[digitalentity]

Ok, SBAS code merged as well as new gps_dyn_model code. Issue renamed to conclude default settings.

[theArchLadder]

I did a very basic test today.
I started with sbas=NONE. I powered up my quad and waited a few minutes until i had 19 sats or so, i then armed and let it sit there for 15 minutes, i then changed to sbas=EGNOS, powercycled and did the same thing again.

In both test the error radius was around 3 meters from the average position and it looks like the position difference between the two tests was less than a meter.

There are a few problems with this though

1. I have no way to tell if SBAS was actually used.
2. I have yet to come up with a accurate way to calculate the average of 10000+ floats to high precision, ideas? I'm using processing now and it behaves a bit weird with floats and doubles.
3. Only two tests are to few to really draw any conclusions.

IMHO, the only take-away is that i did not see a massive improvement (or any for that matter) in relative accuracy when using SBAS.

I also checked position with my android devices, one galaxy S4 (uses gps+glonass, but no sbas AFAIK), and an old galaxy S2 (only gps).
S4 was 1.5-2 meters away from both tests, i have seen up to 5 meters when trying follow-me though, sbas=EGNOS on the quad.
S2 was 11 meters wrong.

[theArchLadder]

Did some flying with sbas=NONE and it felt like home position moved more than usual. Could just be a coincidence though, so as always, more testing needed.

[digitalentity]

I didn't notice any difference between auto and none neither in position
hold accuracy nor rth accuracy. Not sure if my crappy Ublox7 is using sbas
at all.

[theArchLadder]

I think we need to log sbas status if we should be able to investigate this, but adding that feature is sadly beyond my skills.

[DzikuVx]

Did some testing with 1.1 and SBAS Auto. Sat count 18-19, most of the time 19. No jumps, no losses, solid sat cout and pretty stable HDOP.

[theArchLadder]

I have never really seen any position drift with SBAS=EGNOS either.
For now i have been using SBAS=NONE, and i have been surprised a few times over how much the home position have drifted, like several meters.

I will try to switch between EGNOS and NONE every other day or so, to try to get a feel for how much my home position drifts.

[iforce2d]

I would vote to have NONE as the default. Usually I don't like to mess with defaults because backward compatibility is a nice thing, but it's a question of having a setting that works well for 100% of users, versus one that works very well for 90%+ of users and can be dangerous for the other 10%. These percentages I just made up, I suppose there may actually be more than 90% of users with good SBAS coverage, but I think the principle is still valid.

Even when SBAS does work well, the advantages for the typical user don't seem that huge. Some situations I can think of where having a good absolute positioning would be helpful:

• I want to send my quad to hover within a few meters of a building/tree etc, just by using mission planner and giving no manual input while flying
• I want my quad to land autonomously at a remote location where I will not be able to observe or control it while it lands
• I want the quad to go to an exact position and drop something accurately, and I will not be able to adjust the position before dropping

So in general, SBAS helps in situations where I want to position the quad using only the map, and then give no manual input or adjustment, and I cannot tolerate more than a few meters of error. Quite frankly I don't see myself ever trusting my quad that much, no matter how good iNav gets :)
And we should also keep in mind that the google maps we're using to specify the absolute locations may not be that accurate in the first place.

I would expect that most users will be flying in fairly open areas where their landing area has at least some meters of leeway for RTH, and they don't need to hover in close proximity to buildings/trees, and they will be present to observe the craft and make adjustments manually anyway. I would also think that having mission waypoints a few meters off the true absolute position is not a huge deal.

From what I've read about SBAS, the real strength of it will be seen if the flight starts and ends in different locations (so the measured home location cannot be used) and it spans hundreds of kilometers and many hours. In those cases the local conditions (atmospheric/ionospheric) at the start and end points can be quite different, compared to our flights which start and end in pretty the same conditions, and finish in less than an hour.

[digitalentity]

Well written! I totally agree with you.

[theArchLadder]

@iforce2d "can be dangerous", do you mean that sudden 2-3m shifts you talked about earlier?

Regarding that 90% vs 10%, it looks like 10% can have sudden shifts in position, and the 90% could maybe have improved position accuracy, but we don't really know that. I have been suprised with the home-shift with SBAS=NONE, but that could have been a coincidence. More testing needed here.

So yeah, i guess with the data we have now, i would agree with you that SBAS should default to NONE.

[stinkydiver73]

I'am lost, i thought the problem was not the whole SBAS, but only the integrity information in it. And we disabled that (true ?).

[theArchLadder]

@stinkydiver73 Yes, true, that was the big problem and it is solved now!

Now we are just trying to figure out if SBAS should default to AUTO or NONE, it doesn't really make a huge difference it seems. @iforce2d had position shifts of 2-3 meters because he has crappy SBAS coverage, SBAS sounds great but we have not yet been able confirmed that it actually helps us.

[iforce2d]

@theArchLadder Sorry, when I said "dangerous" I was thinking back to the original problem where SBAS would drop enough satellites that GPS functions would be abandoned altogether and the quad would drift with the wind. So that problem is not a problem anymore, correct. At least now it will not fly away, but I wouldn't say the 2-3m shifts are ideal.

In most typical cases we should not be flying that close to obstructions, although in my testing I have sometimes been hovering quite low and it almost got me once. So perhaps it's not as dangerous as I made out, but I feel that the safest available option is better for a default, especially when the gains to be had from SBAS are quite small for most users. People seeking better performance can delve a little deeper into their settings, and will hopefully have more awareness of what those settings are doing as a result. I think it would be great to have a link in the configurator next to the SBAS option, to explain a bit about what it does.

[theArchLadder]

@iforce2d I agree with everything you said!
How confident are you that those 2-3m shifts are because of SBAS=AUTO? How many times has it happen and have you flown a lot with SBAS=NONE without having any of those shifts? (not saying you're wrong, I'm just curious!)

SBAS=NONE as default and info in the wiki that SBAS could be helpful if they live in areas with good SBAS coverage sounds like the way to solve this issue IMHO!

[digitalentity]

Ok to conclude: SBAS doesn't really improve PosHold and RTH performance (that's what a general users wants) and it may actually reduce performance in areas with crappy SBAS coverage.

I suggest we default SBAS=NONE as it's the safest.

[theArchLadder]

Well, we don't know if SBAS helps imho, i will keep using SBAS NONE/EGNOS every other week or so and see if i can notice any difference, would be nice if @stronnag and others with good sbas coverage could do the same!

Still, i agree SBAS=NONE seems like the best default for now :+1:

[aster94]

did you noticed any improvement in these 3 years? is still advisable to leave SBAS to NONE or try one region?
do you know where i could find a map of EGNOS? i didn 't find any

[teckel12]

@aster94 https://en.m.wikipedia.org/wiki/European_Geostationary_Navigation_Overlay_Service

[aster94]

Thanks @teckel12 I happen to be near a RIMS station, I guess I turn it on 😁