Servers by jDrones

Beitan BN-220 GPS slow to get 3D fix

I have a Bietan BN-220 GPS unit in a Bixler3 plane. The FC is an Omnibus F4 Pro v3 and it is running v4.0.5 of ArduPlane.

The BN-220 often takes ages (5 minutes or more) to obtain a 3D fix and the best I have seen so far is 10 sats with the unit out-doors in clear view of the sky.

My Samsung Galaxy S9 in the same location sees typically 36 sats …

I realise that the BN-220 has a patch antenna that is just 18mm x 18mm. However, the antenna in my phone must be even smaller.

Why is there such a difference in performance between the BN-220 and the GPS in my phone and how can I get a small GPS module that performs as well as the one in my phone?

what is GPS_GNSS parameter value ?
did you configured that with your location ?

GPS_GNSS_MODE is set to 0 = “leave as currently configured” - which is the default value.

No, I haven’t configured this value at all.

I am in Melbourne, Australia - can you suggest which mode/s I should select of these:

HDOP below 1.0 is one of the key values you want to look for, not just number of sats.
You could theoretically get a good 3D fix with only a few satellites, but that probably wont happen.

I’ve had good results with value 67 = GPS+SBAS+GLOSNASS for Australia.
I chose to use GLONSNASS because they have a few (more?) satellites with longitudinal orbits which was meant to give good coverage to the poles, and helps some southern regions like Oz.

I’m just about to try value 11 = GPS+SBAS+Beidou , since Beidou seems to have about the best most consistent coverage now. It remains to be seen if this gives fast or slower 3D fix times, or if the position quality is reliable.

try to set GPS_GNSS_MODE to 67 its working good in most locations but its excremental try to set different values to get the best result

I’ve returned to GPS_GNSS_MODE,67 - this seems to give me the most consistent performance.

GPS_GNSS_MODE,11 although having extremely good sat coverage, is sometimes overwhelming for older GPS units causing GPS Health warnings.
I havent tried the Beidou-only setting.

My Bietan BN-220 GPS module is still very slow to find satellites, even with GPS_GNSS_MODE set to 67.

I have a number of multi-copters that have GPS modules based on the u-Blox m8n chipset, but with 25mm patch antennas and they get a 3D lock within seconds of powering up and quickly lock onto about 12 satellites. And this is indoors.

But, with the Bietan BN-220, which is also supposed to use the same m8n chipset but with a smaller 18mm patch antenna, it can take 10’s of minutes to just find 3 or 4 satellites.

I suspected that the Bietan BN-220 GPS might be getting interference from the telemetry Tx, the Rx (which also has telemetry built-in) or the video Tx. But even with all 3 of those items powered down, the GPS is still just as slow.

I am now suspecting that the Bietan BN-220 GPS module is faulty, or it is a copy of the genuine item with inferior components. I have also unsuccessfully tried to connect to the Bietan BN-220 GPS module with the u-Blox u-center application to check on its settings. The fact that I have been unable to connect makes me suspicious about its origins, too … :slightly_frowning_face:

I will do some more testing and report back soon.


Small receivers like the BN-220 often have little to no ground plane around the patch which is detrimental to the antenna’s efficiency. If you peel the sticker off the back shield and electrically bond some kind of metal (aluminum or copper tape, for example) to increase the ground plane size you should find the receiver works a bit better. Many antennas spec ~40x40mm in their reference design but something in that ballpark should work fine; we’re not going to get it perfect. Take care not to short out the backup battery or LEDs on the bottom.

Here’s an example of some generic 18x18mm receiver off of Aliexpress. It claims to sport a uBlox M8N:

It’s bonded to the brass sheet with conductive adhesive copper tape. Below are SV lists, each 5min after a cold start, with and without the expanded ground plane. You can guess which corresponds to which:

Again the plane doesn’t need to be this large, that’s just what I had on the scrap shelf.

My guess is that your module is functional if Ardupilot is reporting the receiver is finding sats. Keep in mind that the default baud rate when powered on is probably 9600, so when trying to talk to it with u-center you’ll need to set the baud rate accordingly. Maybe try swapping Tx and Rx, that’s usually my problem :slight_smile:

It’s also worth noting that most, if not all of these cheap receivers have counterfeit ICs. They’ll look and mostly behave like u-Blox ICs but won’t perform as well. For the most part they’re good enough for our application.

Thanks @Muhammad_Al-Rawi for that information - it is very helpful.

I managed to get the BN-220 connected to u-center - somehow the BN-220 was set to 115,200 baud. Once I connected at 115,200 I was then able to reset the BN-220 to the default settings and it now works hapily with u-center.

It is still very slow (by comparison) to get a 3D lock and to get enough satellites to get the HDOP down to 1.0.

For example, I just did a test outdoors with a clear viw of the sky, of my quad-copter that has a 25 x 25 mm M8N GPS unit and my Bixler plane that has the BN-220 unit.

The quad reported a 3D lock in less than 1 minute and reached a HDOP of 1.1 with 12 satellites within 5 minutes.

The Bixler took 2.5 minutes to report a 3D lock (4 sats) and then took 8 minutes to report a HDOP of 1.1 with just 9 satellites.

I agree that the BN-220 may be slower because of the smaller antenna (18mm vs 25mm), but I suspect that the little silver cell that looks like a battery may be the culprit. From what I have read, some GPS units use a rechargeable lithium cell (~3 volts) to backup the RAM that stores the satellite information to enable quicker starts at power-on. And some GPS units use a “super-capacitor” for the same purpose.

I suspect that the BN-220 uses a tiny “super-capacitor” and it only has enough capacity to save the satellite data for a few minutes. Does that sound plausable?

I am going to try your suggestion of a 40 mm x 40 mm ground plane to see if that helps.

I am also in direct contact with Beitan (the manufacturer) to see if they can help.

This is getting weird … :open_mouth:

I have the BN-220 GPS connected to an Omnibus F4 Pro flight controller, to UART6 which is SERIAL3.

And SERIAL3_BAUD is set to 38 (38,400), while SERIAL3_PROTOCOL is set to 5 (GPS).

However, if I connect the BN-220 to uBlox u-centre after it has been connected to the Omnibus F4 Pro, the baud rate is set to 115,200.

But the Omnibus F4 Pro is supposed to connect to, and configure, the BN-220 at 38,400 baud.

So, how does the BN-220 end up being configured to 115,200 baud?

ardupilot auto-configurates and auto-bauds compatible revceivers (ublox6 and higher). default has been 115.200 for some time now and will be 230.400 in subsequent firmwares to allow enough bandwidth for newer hardware‘s high precision raw data.

@basti - thanks for confirming that … :grinning:

So, it doesn’t matter what value I set SERIAL3_BAUD to as ardupilot will override it and configure it to 115,200 for my ublox 8 GPS.

Servers by jDrones