GPS count

[putimir]

For some unknown reason GPS functionality "suddenly stopped working" I'm getting 0 sats out in the open, exactly where there were never an issue with visibility.

I'm running v2.0.0, on a MATEKF405-STD w/MATEK FCHUB-W on a wing, GPS module BN-800 on UART5

Relevant GPS config:

gps_provider = UBLOX
gps_sbas_mode = NONE
gps_dyn_model = AIR_4G
gps_auto_config = ON
gps_auto_baud = ON
gps_ublox_use_galileo = ON
gps_min_sats = 6
inav_use_gps_velned = ON

I'm not sure what happened, if somehow fucked it up, but I now just can't get a GPS fix, not even 1 single sat, without touching upper config.

I have now tried with several different GPS modules (Beitian BN-880, BN-220 and also a Drotek SAM-M8Q), everyone of them working properly; check with U-Center, they all get a 3D fix pretty quickly.

Also I have tried different baud rates on the port with no success.

The funny thing I noticed is, that on the GPS tab, I see correct latitude, longitude and altitude, but no sat count.

If I do a serialpassthrough on the GPS uart and go to the packet console of the U-center, I only see 4 types of messages:

...
15:10:22  R -> UBX NAV-SOL,  Size  60,  'Navigation Solution'
15:10:22  R -> UBX NAV-STATUS,  Size  24,  'Navigation Status'
15:10:22  R -> UBX NAV-POSLLH,  Size  36,  'Geodetic Position'
15:10:22  R -> UBX NAV-VELNED,  Size  44,  'Velocity in WGS 84'
15:10:22  R -> UBX NAV-SOL,  Size  60,  'Navigation Solution'
15:10:22  R -> UBX NAV-STATUS,  Size  24,  'Navigation Status'
15:10:22  R -> UBX NAV-POSLLH,  Size  36,  'Geodetic Position'
15:10:22  R -> UBX NAV-VELNED,  Size  44,  'Velocity in WGS 84'
15:10:22  R -> UBX NAV-SOL,  Size  60,  'Navigation Solution'
15:10:22  R -> UBX NAV-STATUS,  Size  24,  'Navigation Status'
15:10:22  R -> UBX NAV-POSLLH,  Size  36,  'Geodetic Position'
15:10:22  R -> UBX NAV-VELNED,  Size  44,  'Velocity in WGS 84'
15:10:22  R -> UBX NAV-SOL,  Size  60,  'Navigation Solution'
15:10:22  R -> UBX NAV-STATUS,  Size  24,  'Navigation Status'
15:10:22  R -> UBX NAV-POSLLH,  Size  36,  'Geodetic Position'
15:10:22  R -> UBX NAV-VELNED,  Size  44,  'Velocity in WGS 84'
15:10:22  R -> UBX NAV-SOL,  Size  60,  'Navigation Solution'
15:10:22  R -> UBX NAV-STATUS,  Size  24,  'Navigation Status'
15:10:22  R -> UBX NAV-POSLLH,  Size  36,  'Geodetic Position'
15:10:22  R -> UBX NAV-VELNED,  Size  44,  'Velocity in WGS 84'
15:10:23  R -> UBX NAV-SOL,  Size  60,  'Navigation Solution'
15:10:23  R -> UBX NAV-STATUS,  Size  24,  'Navigation Status'
15:10:23  R -> UBX NAV-POSLLH,  Size  36,  'Geodetic Position'
15:10:23  R -> UBX NAV-VELNED,  Size  44,  'Velocity in WGS 84'
...

Does anybody have any ideas what might be happening here?

Once again: If I disconnect this very same module and connect it via ftdi adapter, it gets a fix immediately. It looks to me like inav is "misconfiguring" the module...

[stronnag]

Those look like the stanza iNav uses for UBLOX.

Momentary drops to 0 satellites are not that unusual, here they rarely last for > 200ms and iNav sails through them, even in WP mode There's a somewhat extensive analysis in an earlier PR https://github.com/iNavFlight/inav/issues/3643#issuecomment-407490775

The values in the your screen shot (EPV/EPH/HDOP) are entirely consistent with the GPS reporting no coverage.

Is there a Runcam Split involved, as we've seen these cripple GPS reception?

[teckel12]

@putimir Looking at my settings, I have the following differences:

set gps_dyn_model = AIR_1G
set gps_ublox_use_galileo = OFF

I believe the gps_ublox_use_galileo can't be used unless you have the correct configuration on your GPS module. With gps_dyn_model the default is AIR_1G and I'm not sure what that feature even does.

[stronnag]

Pretty notable day for momentary 0 sats events today:

$ inav_0sat.rb /t/inav/2018-08-24_deadcat/LOG0000*.TXT 
****** /t/inav/2018-08-24_deadcat/LOG00001.TXT index = 1
 GPS 0-sat event of 0.08s duration
 Before : numsats=12, fixtype=2, hdop=152, time=148.64s
 Event : numsats=0, fixtype=0, hdop=9999, time=148.67s
 Resume: numsats=13, fixtype=2, hdop=145, time=148.75s
****** /t/inav/2018-08-24_deadcat/LOG00002.TXT index = 1
 GPS 0-sat event of 0.08s duration
 Before : numsats=15, fixtype=2, hdop=119, time=85.93s
 Event : numsats=0, fixtype=0, hdop=9999, time=85.94s
 Resume: numsats=15, fixtype=2, hdop=119, time=86.02s
****** /t/inav/2018-08-24_deadcat/LOG00006.TXT index = 1
 GPS 0-sat event of 0.08s duration
 Before : numsats=13, fixtype=2, hdop=151, time=379.31s
 Event : numsats=0, fixtype=0, hdop=9999, time=379.36s
 Resume: numsats=13, fixtype=2, hdop=151, time=379.44s
 GPS 0-sat event of 0.08s duration
 Before : numsats=13, fixtype=2, hdop=151, time=399.90s
 Event : numsats=0, fixtype=0, hdop=9999, time=399.95s
 Resume: numsats=13, fixtype=2, hdop=151, time=400.03s
Files 5, flight logs 5, zero-sat records 4

[putimir]

Facts;

If plug in the module into FC, I get 0 sats, even if I leave it for 15 minutes (never happened, to me, there were times with less reception, but not 0 + I said, I get correct position with altitude, but no sat data)

If I then take the same module, unplug it and immediately power it on via ftdi (same physica position), I get 3d lock in seconds with 6+ sats, and have no breakouts of the reception.

@stronnag : yes, matter in fact, I do have Runcam Split on the build (but so do I have 7 more in other builds with no such symptoms. I will disconnect it and try that.

@teckel12 : yes, I was playing with Galileo, and I found out you have to enable NMEA version 4.1 on the module (+ of course enable Galileo on GNSS), and I'm getting 1-3 sats...

[stronnag]

Fact:

Flew iNav 2 today, ublox, perfect

[putimir]

Hi, don't get me wrong, I just want to describe situation as good as I can ;)

I also love inav, basically it is all I fly, works perfect, I had 0 issues with it, this is one of strange things that I'm experiencing, and I'm not even saying it's something wrong with Inav, I just need a hint what could this be...

Thanks, everyone

Oh, is there any discussion about the Runcam issue so I can catch up...?

[stronnag]

And I'm not doubting that it's happening and driving you nuts. I'm just sceptical that it's a firmware issue. On runcam we have #3643 and #3730 as cases where it was the cause of no GPS fix.

[putimir]

Yes, what's driving me nuts even more is, that this was THE most trouble-less wing ever, I'm flying it now for 2+ months almost daily; perfect maiden, not a single crash, not even bad landing, the foam is MINT. And today....this. No GPS fix. 0. I haven't even seen this yet.

Plus, regarding RC Split, This is probably even a build, that has the Split and the GPS module the farthest apart: cc 20cm :D

[putimir]

An update: I have downgraded to 1.9.0, powered back the Runcam Split, and in a minute, I'm getting sats...(same exact build, sitting exactly in the same spot)

@stronnag : I have browsed through #3643 , should I write there?

[teckel12]

@putimir Try 2.0 but with no power to the Runcam Split. They create a ton of interference which in many cases totally disables GPS.

[putimir]

@teckel12 : I did exactly that; I just wrote, that I reverted to 1.9.0 AND powered the Split back into the system, and I got 3D fix no problem (couple of post back I also mentioned, that I flew this exact setup for 2 months and now it just started to act upon me). I know it sounds weird and it may be a coincidence. I'm now testing every build to see what I can gather :)

[stronnag]

Full erase when you flashed 2.0?

[putimir]

I ALWAYS do that.

In the meanwhile, I have flashed through ALL of the builds from 1.9.0, and the fix happens in all. I don't know, it seems something 'jolted' the GPS 'back to life'. I'm exhausted, I will now try to build up my config in steps to see if I can catch 'something'... Thanks

[putimir]

Hi, after extensive testing I can conclude, that the problem is indeed in the runcam split after all...the fact that the interference is probably not "stable" (intensity...) is what leads to strange random results, leading you to incorrect conclusions...

One last question: is it possible that the negative impact is more severe on GPS unit coldstart, when "searching" for satellites? I think once the unit gets the fix, I noticed that it is very unlikely that the unit looses the fix...?

Well, thank you all for your time and good will, I'm sorry I have wasted some of your time by not researching for the existing findings...

[teckel12]

@putimir Yes, getting an initial GPS fix requires a much clearer signal than keeping one. To get a GPS fix, the satellites need to transmit their current location and future locations. But once there's a fix, it's much easier to maintain it. So what your experiencing is totally normal.

[johnsobr]

I added Pololu mosfet switch wired to a spare Rx channel to allow me to power/depower my VTX via RC transmitter switch. I kept the camera alive all the time not knowing how the OSD I.C. on the Matek Wing would handle the video signal coming and going, but that may also be useful to switch on/off as well. Reasons I may want temporarily turn off the VTX (and/or camera):

1. to improve GPS lock time during first power up (my GPS battery is dead, so it takes a while)
2. if I accidentally "land" in a tree and cannot get the plane down ASAP the VX will not overheat, and battery will last longer
3. in case I swamp someone elses video feed, or suddenly desire to go offline
4. to test RC RSSI changes with and without video
5. In case the plane site powered up for a long time before take off

Of course the DL Rx is set to failsafe that channel to always "on" in case of RC link fail ;<) I know it "adds" a potential failure point but I like having it. https://www.pololu.com/product/2803

[stale[bot]]

This issue / pull request has been automatically marked as stale because it has not had any activity in 60 days. The resources of the INAV team are limited, and so we are asking for your help. This issue / pull request will be closed if no further activity occurs within two weeks.

[stale[bot]]

Automatically closing as inactive.