We are using a telit GE864GPS-QUAD module and I need to find out what is the average length of time (n seconds) that it should take the device to acquire a GPS signal once power has been applied to the module. (similar to a phone being powered up).
I am aware that , the GPS must update its almanac and ephemeris data and store it in memory (if the device hasnt been communicating or been used for a number of days or has possibly moved in that time) and for this reason the acquistion would take longer.
Is it possible to make a GPS receiver thik it has current almanac data in memory (despite no activity for a few days) and therefore can acquire satellite signals and determine initial position more quickly. The reason I say this is that the device we are using will not have moved or powered up since that last recorded GPS coordinate.
Time to First Fix (autonomous): ? Hot Start : 1s ? Warm Start: <35s ? Cold Start: <35s
See $FTPGETIFIX , $HTTPGETIFIX.
From the moment the GPS Receiver is queried for a hot start, the average time to acquire data is about 1s. This sometimes takes about 8 seconds.
For cold starts the time is approx 40 to 90 seconds.
I am trying to find out for each of these situations what could be causing the longer than usual time.
I did lookup $FTPGETIFIX and $HTTPGETIFIX but the device will not have an internet connection. Ideally I would like us to record the almanac/ephemeris data everytime we get new positional updates and then we can always use this data as part of SiRFInstant Fix to reduces the amount of time it takes the GPS receiver to acquire a fix. I think this would be akin to getting a cold sdtart to work witin 20seconds perhaps.
I think I have to use $GPSIFIX to instruct the module to enable Client GeneratedExtended Ephemeris (CGEE) But I am stil a bit unclear as to how current GPS information is stored and if it needs to be permenantly stored on the GPS receiver.
Is my logic to the approach needed correct?
Thanks for the reply Cosmin,
The hot Start Time to First Fix is taking longer than 1 second, maybe 5-8 seconds and the cold starts are anywhere from 40-90 seconds. Not sure why this is or how I can debug to see what is causing the delay.
Regarding the $FTPGETIFIX and $HTTPGETIFIX commands, I think both of these only work for Server Generated Extended Ephemeris (SGEE). The device I have does not have Internet access so any reference to the necesary SiRFInstantFizand I think I need to use Client Generated Extended Ephemeris (CGEE) and to use the GPSIFIX command to enable this.
What I cant figure out is how the SiRFInstatntFix file (required to facilitate a faster time to fix from cold restart) is populated and where. Do I as the client have to take the last known successful data provided by the GPS Receiver and store it somewhere in an Extended Ephemeris file then present it to the GPS Reciever os does the GPS Recevier have some way of doing this.
I am not sure if my logic is correct but any help on this would be appreciated.
Hello Mr. Boyden,
Could you please send me your schematic?
Which antenna are you using? passive or active?
The GE864-GPS has the possibility to use both feature, SGEE +CGEE or only one of these.
The main difference between these prediction is that:
-SGEE: required connection in order to download the SGEE data from out AGPS Server and an NDA have to be sign in order to get the username and password.
SGEE prediction files can be: 3,7,14 days
-CGEE: doesn’t required any connection, and the prediction derives directly from the navigation and the CGEE can have a max validity of 3days.
In order to get the CGEE prediction for the full constellation, you need to leave the receiver 12hours in track.
This is the command in order to enable the CGEE feature:
Let me know if you need any further infomarion.
GNSS Technical Support – EMEA Application Engineering
Hit enter to search or ESC to close
Knowledge Base & Download Zone