Copter 3.5-rc9 spamming GCS with GPS 1: detected as SBF at 'xx' baud

Have just updated from rc7 and did not see this behaviour previously.

The messages tab is being spammed with:
“GPS 1 : detected as SBF at ‘xx’ baud”

This was sitting on the work bench so no GPS was going to be possible, but it has never done this spamming before.

Just checked the logs and not GPS logging???
Now I am positive I always have GPS logging on, especially while setting up and testing.
Will check today, must have changed the log bit mask!
And get some sats to see if the spamming stops.
4 1-01-2000 10-02-32 (3.0 MB)

I’ve ping’d Michael du Breuil (our GPS maintainer amongst other things) to see if he’s got an idea about these messages.

So the Septentrio spamming isn’t actually a new behaviour, I’ve had an issue open about it for over a year now but haven’t actually addressed it yet…

This only happens if we can’t get valid information from the GPS. I’m failing to find any signficant patches that were applied to RC9 since RC7 (the three most recent ones are the only ones that came in for RC9).

I’ve been flying Plane with a AsteRx-M on master with no problems and that includes with some more SBF specific enhancements (reporting vdop, loading velocity accuracy estimates, reporting the SBF lag, and preventing arming if we should be logging to the GPS’s SD card but aren’t writing on it).

Your log file indicates the GPS bitmask was correct, there are no GPS messages logged, because it never reported a single position that was useful for some reason.

I assume nothing physical or anything in wiring changed between RC7 and RC9?

Correct, nothing at all changed.
From test flights and tuning, and all was fine, the only change was loading rc9.

I have some problems with 3,5.rc9 and I think the problem is the same. The GPS was in the begin long time to get signal, where Gps HDOP was 99,99 and Sats = 0. After some time ( 10 min ) the AC annonce some change in the setup ( EK2_GPS_TYPE set to 1 and EK2 IMU0 origin set ) and sats was ok. Flying no problem. After 3 restart AC not got Sats anymore…

Log was missing6 06-07-2017 (2.0 MB)

@ersko Can you post a DF log from before RC9? I suspect your issue is because NMEA is no longer accepted as an automatically detected GPS type.

I didn’t have any logs from before, cleaned up

@ersko I strongly suspect if you were to ground test with a previous RC that you will see your GPS detected as NMEA.

The GPS I use is a 3DR Ublox GPS. I have now tried GPS_TYPE=2 witch was working was working for some time and then stop working. Now I will try to go back to 3.4.6 and do retest…

@mboland @rmackay9 I’ve confirmed that RC10 (took me to long to test against RC9) fails to detect a SBF GPS correctly. I’m pretty lost on why that’s happening at the moment. Will take me until sometime next week to properly regression test that one, the only good news is there are only 3 patches in the GPS library to blame…

It’s worth noting that 0b269083 (plane) works flawlessly with SBF, will need to compare the two, my current guess is that one of the copter GPS patches that came in needed one of the other follow on patches to work correctly.

@mboland Didn’t make it very far, the new AsteRx-m I pulled out of the box today isn’t working with a subset of firmwares it was working with before though, so I’m not sure at this point what the root problem is. I’ve started to wonder if it’s actually associated with the firmware on the AsteRx, but I haven’t gotten to look into that yet.

For reference when I get back to this, what firmware version s on your AsteRx-m?

@mboland found it, longer config strings for SBF caused race conditions, I didn’t notice as my GPS has the correct config saved on it regardless…

Thanks for the wonderful efforts to sort this.

Will this be in rc11?

Do you need any information from my AsteRx?
Or any other info I can provide?
I have been a bit out of the loop as it seems email notifications of posts has stopped working in the Forum. should resolve the problem. (Still needs to be tested on a copter build, but I confirmed/created the exact problem was happening on plane builds as well)

I believe their will be an RC11 with this. In fact the release got held up because of this issue so I’m pretty sure you will see RC11.

@mboland ,

As WickedShell says, we’ve got some potential fixes ready for -rc11 and I’m wondering if you could give the changes a try before we push it out to everyone? The changes are that we’ve temporarily fixed a race condition in the SBF GPS driver and we’ve also re-enabled the NMEA GPS detection.

Below is a dropbox link to a zip file that contains two files. the -v2.px4 file is for a Pixhawk1, the -v3.px4 file is for a Cube (aka Pixhawk2).


Sorry to say, the answer is, it is still spamming the GCS with “GPS 1 : detected as SBF at ‘xx’ baud”

The Log file 3 1-01-2000 10-05-32 (4.3 MB)

Found part of the problem, but not the reason for spamming the GCS.

Pulling everything apart I discovered the AsteRx-m was not being powered up, so no data to the PH.
The message was false in that it said GPS detected??
Once the GPS was detected, that is, had some power to it, the expected messages of GPS detected and GPS use showed up.
This happened due to lightening the power load on the PH and re-routing the power from the PDB straight to the AsteRx-m, but the PDB had a bad solder pad :rage: that the power wire was connected to.
Had done this just before updating the FW to test everything and just didn’t connect the two actions.

So the issue is really if the GPS is not being seen and the parameters are set to SBF then this spamming occurs saying a GPS HAS been detected when it should say “no GPS”.
The flight data screen was also saying “no fix” rather than “no gps” when a Ublox type is used.

So the short answer is this is now a non issue.
Sorry guys, my bad.