Adafruit GPS Photon problem


#21

Interesting. Why does the battery helps getting a fix?


#22

It holds its last position lock in memory so when you power it up next time it already knows where it is and just needs to reconnect to the satellites VS starting from scratch which usually takes quite a bit more time.


#23

Additionally downloading the GPS almanac (the table where all the satellites are supposed to be where in this very moment and other data to calculate exact position) takes time.
If it’s not delivered via cell radio and forwarded to the GPS device this data will be downloaded off the satellites with rather limited bandwidth - so it’s best to keep it alive via battery backup.


#24

Regarding “preloading” the GPS almanac; from the module manual:

The AGPS (EPO in flash™) supply the predicated Extended Prediction Orbit data to speed TTFF. Users
can download the EPO data to GPS engine from the FTP server via internet or wireless network. The
GPS engine of the module will use the EPO data to assist position calculation when the navigation
information from satellites is not enough as is the case of weak signal. For more details on EPO, visit
our website.

I couldn’t find anything on their website. I sent an inquiry, but have not yet gotten a response. I’m not sure exactly how to go about sending this information to the module. Anyone have any experience on this?


#25

AFAIK someone at Particle (can’t remember if @BDub or @Dave) has already mentioned that they are working on strategies to provide ways to do something like that.


#26

Yup! I have code to preload time/date and starting location, and I’ve collected info on preloading almanac and EPO and Ephemeris data, as well as good sources of that data. :slight_smile: My hope is to provide an EPO sample in the coming week or two, and the preload date/time/loc sample today or tomorrow.

I’ll put those examples here - https://github.com/dmiddlecamp/fancy-asset-tracker

Thanks,
David


#27

@dave Do you know what exactly what data the Adafruit Ultimate GPS is saving when the battery is installed? Is it time, date, and EPO data?


#28

In theory the battery should allow the GPS to keep the GPS RTC going, and keep the satellite almanac, and ephemeris data going. In my testing I’m not sure if this only happens after a really good lock or not, I’ve had some trouble getting the battery backup to behave quite like I expect so far.


#29

Looking forward to your new GPS code regardless.

The battery has made a decent difference for me. I can usually get a GPS lock inside my garage in 120 seconds or less using the Adafruit Ultimate GPS + battery.


#30

@Dave: Excellent!


#31

I didn’t see this code in your fancy-asset-tracker. Did I misunderstand?

Also, I’ve been using the TinyGPS++ library with good results (it seems a little cleaner to me than the Adafruit library): http://arduiniana.org/libraries/tinygpsplus/


#32

By the way, I’ve noticed that the number of satellites reported by $GPGGA never exceeds 4. Is that an internal limit of the GPS module (i.e. once it has 4 satellites locked, it won’t bother to use any more, even if it can “see” others)? Has anyone else seen a higher reported value?


#33

Hi @Eric24,

Good questions! I haven’t posted the time suggest code yet, will do that soon.

In general, at any given time it’s rare to have more than ~8-9 satellites visible on the horizon. If you use an external antenna, or you have a very clear view of the sky, you should see more. I routinely get 7-9 with my external antenna outdoors facing up on a level surface.

There is a really fantastic gif on wikipedia that relates the visible satellite thing:
(Wow, that upload really killed the resolution, check it out on wikipedia for a better version)

Thanks!
David


#34

Good info, @Dave

What I’m basing my observation on is a comparison of two cell phones running GPS apps (that show the satellites in view) and the content of the $GPGGA sentence from the G.Top GPS module. I’ve never seen that value be greater than 4. When you are seeing 7-9 satellites, exactly where are you seeing this?

I look forward to seeing the time suggest code. Does that include the EPO upload? I was working on both of these, but couldn’t find any information anywhere on even how to start, so go nowhere.


#35

The EPO upload will be more complex, and will take me longer. But I’ve found data, and most of the specs needed to base the work on. It took quite a lot of searching to find the relevant information, but I’m happy to share if you want to build that part :slight_smile:

edit: just added suggest-time-and-place to the repo

Thanks,
David


#36

@Dave: Sure, if you have any info, let me take a look and see what’s involved. I’m happy to help if I can.


#37

Heya @Eric24,

Sure thing! If you have time and want to take a stab at it, here’s the info I collected so far:

Checkout the last few lines in that readme, it links to another awesome project that actually implemented this. I was going to use that as inspiration to build a version that does this in firmware. Ideally I’d love for the firmware to be able to do this on the fly / in the wild – without needing to be tethered to a laptop, etc.

Thanks!
David


#38

@Dave: New code looks good–simple and straightforward. It was the PMTK740 and PMTK741 commands that I couldn’t find in the docs I was looking in. But it’s my interpretation that if you are sending PMTK741, then PMTK740 isn’t also needed (i.e. if you have only time, send PMTK740; if you have time and coordinates, send PMTK741).

On the topic of coordinates, my ultimate objective is to use the ublox CellLocate service (currently not working, as described on another thread) to determine the initial fix and use that to seed the GPS.


#39

@Dave: Good info; lots to digest!


#40

Agreed, I wanted the time/location demo to use CellLocate, but I didn’t have that example yet.

Yes, finding those NMEA commands was HARD, probably didn’t need both, but I wanted to include both in case someone had time, but not starting location. :slight_smile:

Thanks,
David