PIC with u-blox 7

[crayfellow]

Hi guys, I've got a little project with a u-blox 7 that is having a hard time getting a fix at times. I haven't narrowed down the exact cause.

It appears to have something to do with the module getting ephemeris data to know where to search for the satellites. I suspect this because I am monitoring RXM-SVSI and NAV-SVINFO to watch for visible satellites, usedForNav/unhealthy bits for the SV's, and carrier/noise signal ratio (C/No).

When the issue occurs, often at first power up, RXM-SVSI will report 0 visible satellites for many minutes and only then will it start acquiring a fix. I know according to the data sheet it can take up to hours to download full ephemeris, but shouldn't it be able to acquire a first fix in less than a minute in normal conditions?

If anyone has direct experience with NEO-6/7/8, I'd love to hear your thoughts.

thanks all!

[Ttelmah]

Not 'first fix', no.

The chip holds it's current ephemeris in flash. Without the ephemeris you can't even begin to get a fix. The point is that if it has an ephemeris (even one several weeks 'out of date', the changes will be relatively small, and a 'first location' can begin in a few seconds.
However an ephemeris is needed. Problem is that boards typically ship with the ephemeris for where they are manufactured. This is as bad as 'none', unless this happens to be within a few hundred miles of where the unit is now powering up.
A little while ago, quite a few quadcopters shipped with the NEO GPS units. When first powered in the UK, they would take up to about 15 minutes to get a 'good' lock, if powered up on a site with nice clear horizons. The full ephemeris can be read in just 12.5 minutes, with a clear view. However if the satellite being used goes from sight 'mid fetch', this can easily double.
It used to be recommended that you powered the unit up with a clear sky view, for about 30 minutes.
However, once this was read, powering up again for the next few months, typically only takes perhaps 30 seconds. Shipped then to customers in the UK, the units would happily wake up in only a minute or two. But there were still problems with these units (see below).

The units that manage much faster startup times than this, are devices like smartphones, which can use an internet connection to get the current ephemeris (aGPS).

Key is to find a good site, and power the unit up here. Then see how well it wakes up in the future. There can be very significant problems if for instance, your site it getting 'impossible' data. This happens if there are tall buildings nearby, and you then get reflections from satellites giving an invalid location.

There are a number of telescopes that had built in GPS locators, and it is a common problem to find that the GPS can not lock, even if left outside and turned on for an age. Things like roads, giving intermittent reflections are the 'killer'. With the aGPS systems, the almanac can be taken as 'read', and then errors ruled out, but more basic GPS's can't do this. However the module involved also affects things.

The Ublox GPS (Neo), is particularly 'well known' for giving sudden spurious location shifts, and on things like the quadcopters, it has been necessary to take the signal from an inertial system, and use this to 'reject' spurious movements signalled by these. Generally many other units are considered much less likely to have problems. I replaced the Ublox modules used on such units, with MTK modules, with a much higher success rate....

[crayfellow]

Interesting, thanks for the great detail.

That is one confusion point for me, where ephemeris and almanac get stored. the data sheet describes various available nonvolatile storage, but seems to suggest the only onboard is battery backed RAM and that any Flash would be external "where available".

So theoretically, powering one of these up from the factory can take up to 30min to get ephemeris, then from there it should be less than a minute? What does it mean if one is powered up and it does the ~30min routine again?

As an aside, I have some simple filtering on the position data to kill those massive outlier readings, but I'd love some guidance on use of accelerometer data. Specifically, how to use its readings. It seemed like just accumulating the magnitude in a given period and comparing against the dv (sog)/dt (tow) from the GPS couldn't work based on the different timing between the two. Are there any concrete examples of this truly working?

[Ttelmah]

I'd say multiple possibilities:
1) The chip is losing it's Vbackup supply.
2) You have a really bad antenna.
3) You have a really bad interference problem.
4) Are you running with WAAS enabled?.
Does WAAS cover your area?.

If you have this enabled, and WAAS is available, it massively speeds the acquisition of the initial almanac (WAAS includes the local almanac, transmitted at a higher data rate). However I remember people having problems, when their area didn't have WAAS, and it was enabled, the chips 'assumed' it was going to get the almanac from this, and didn't store it....

- 4) may be the problem. Depends where you are.

[Ttelmah]

On the storage, GPS's commonly hold the almanac in SRAM, since Flash can't handle the number of updates involved. Therefore a rechargeable battery is required. However some newer low power systems take advantage of using a really large flash area, and a scrolling update into this to reduce the cycles involved, and get rid of the need for a battery.

[crayfellow]

As for the WAAS/SBAS, I will have to check UBX-CFG-GNSS and UBX-CFG-SBAS to see what these are using. Supposedly according to the protocol spec for the neo-7 (http://www.u-blox.com/images/downloads/Product_Docs/u-blox7-V14_ReceiverDescriptionProtocolSpec_Public_(GPS.G7-SW-12001).pdf) SBAS should be enabled by default, but if it is not specifically enabling WAAS or is getting confused and tying up channels seeking SBAS systems for other geographic locations, I could see that adding delay.

re: ephemeris storage, OK, so if the v_backup pin were wired to the main battery as opposed to a dedicated backup battery, when the main battery is removed or dies, that is lost, no?

I just powered on 3 of these that had gone completely (or near) dead over the past several days and they all were able to get a fix in less than a minute. I will see if I can replicate the 20+min delay condition, perhaps by removing and replacing the battery.

[ezflyr]

Hi,

Yes, all very interesting, but does it have anything at all to do with the CCS C compiler? I suspect you simply Googled Ublox GPS and landed here as a result of several recent threads. This forum has a narrow focus, it's not a general electronics help forum!

John

[crayfellow]

Hi John!

I'm quite sensitive to being a good forum citizen so I did consider that before posting, but I hope you guys consider that a testament to the caliber of folks posting on here. The forum description for General CCS C Discussion states "General discussions related to using the CCS C compiler in your Microchip PICmicro MCU designs. Also any discussion related to embedded systems programming and design."

and because this is a discussion related to embedded systems programming, I felt it germane. Even if I am not personally using the CCS compiler, these sorts of topics are so rare and hard to find help with it seems like a nice fit for a number of reasons. Folks using the compiler benefit, and CCS benefits as others like me looking for suggestions will now end up here through search and learn of the CCS compiler anew.

But yes, if you want to be strict and do not agree this is beneficial to the forum and site regardless of what compiler I'm using, then I may have to start a forum elsewhere.

cheers!

[Ttelmah]

It is borderline. However a lot of the people here are trying to talk to these or similar GPS's, so 'knowing the problems', may be useful.

[Torello]

If EzFlyer can tolerate just one helping message...

Crayfellow, I've been working the past years, and currently, intensively with Ublox GPS modules.
Lea-4S, Max-6G and recently I evaluated the Max-7C in our application as a validation to migrate to the EVA-7M. My application involves GPS birdtrackings devices thus it need to be as light weighted and low power as possible. The 4S in the past and current Max-6G are performing very well. The 6G can give me a first fix in 30-40 seconds with good sky view. Without SBAS (EGNOS or WAAS). I have never seen those satellites pop-up during debugging, so haven't put much effort in it.
Consecutive fixes, after power-down and with backup power enabled depend on the -off- time. But are also OK.
The Max-7C is an other story. It works in my application but not as good. Far longer times for first fix (up to 3 minutes) and consecutive times (multiplication of 2, 3). Far higher backup power (10 times!) All that is a pity of the energy.
I've had intensive contact about this, but it did not lead to solid answer. The Max-7C doesn't have an temperature controlled crystal oscillator and that is probably the reason.

Anyway, you should be able to get some results. Of course as Hamlett states the hardware needs to be OK. I can add to the list a low noise power-supply for the GPS module.

What I did, and that helped me a lot, is creating a debug mode in my application, that simply (bit-bang) passes the Ublox information to a serial connection to your computer. Then you can investigate the module behavior in your application (thus with your hardware) by using the Ublox U-center application. Then you can simple see if it is receiving any signal at all or that some other settings (filters, dynamic platform) are blocking your fix. And you are also capable of changing them. Ublox have a very good manuals; you do need them!

Note that for the above you need make a setup near a -none- coated window and that you GPS antenna has good sky view. Also the debug connection out of your application should not circle around the GPS antenna (if you have a passive antenna on your PCB as I have). And some electronic equipment -does- interfere with the reception. My scope does for example.

Last remark. Ublox-7 is capable of receiving GPS, Glonass and QZSS. For Glonass to work, your antenna needs to be capable receive it. It is an slightly other frequency band. It can't do GPS and Glonass at the same time.

Lots of success!
_________________
Regards, Edwin. PCWHD v5.114