All GPS Status codes and their exact meaning

[Kai Getrost]

Is there a list somewhere of all the possible GPS Status codes and exactly what they mean (i.e. exactly how SharpCap determines when to display them)? Especially for QHY174M-GPS cameras. The following are what I've seen and my understanding of them, in SharpCap 3.2.6248:

• PartialData
  The GPS sees some satellites, but is still acquiring a fix. Time and position may be (significantly) off. (This condition may sometimes be reported as BadData instead; see below.)
• Locked
  The GPS has a fix (precise location and time). However, it may or may not have a full almanac and thus could be missing the proper leap second(s) count. So time could actually be off by a small (1-3?) number of seconds -- but always an exact integral amount. But there is no further indication in GPS Status of when/if the almanac has been downloaded (after the initial position fix and `Locked' status). Waiting for Locked, and then waiting another 12.5 minutes at least (the almanac broadcast repeat cycle), is the only assurance I know of that the leap second count (and hence GPS Time) is fully correct. I seem to recall watching the System <-> GPS Time difference change by a small integral number of seconds well after Locked was achieved, and have interpreted this as indirect evidence that the almanac had then finished downloading (often some several minutes after Locked was achieved).
• BadCalibrationReduceEndPos
  The GPS has a fix, but Calibration End Pos is set too high; I think the reported GPS time also freezes (but at a recent value). (A similar condition -- bad End Pos but no fix -- may sometimes be reported as BadData instead; see below.)
• BadTimeStamp
  The reported GPS time is more than 24 hours different from the system (PC) time, the latter of which is assumed to be at least that accurate and thus the GPS time is assumed to be in error. I'm not sure if the GPS has to be reporting having a fix for this error to happen; i.e. if no fix, would a greater-than-24-hour time diff be ignored and PartialData be reported instead?
• BadData
  Multiple causes? 1) The GPS is reporting some faulty data? Or SharpCap thinks it is faulty? I don't know the details for this case. 2) The GPS has partial data only (normally reported as PartialData), but Calibration End Pos is also set too high (normally reported as BadCalibrationReduceEndPos if there were a GPS fix), causing the reported GPS Time to freeze -- and at a significantly bad value (e.g. year 1995 or 2061). This is a recent issue I've discovered; I posted details to the IOTA ilst but not here yet. I can elaborate if desired; this is a reproducible scenario -- and will not resolve on its own, even when a GPS fix is achieved.

Additions, corrections, clarifications are welcome. Are any of these statuses directly reported by the camera and merely passed on by SharpCap to the GPS Status display? And/or are some determined and set by SharpCap itself, e.g. the BadTimeStamp code? Thanks.

[procyon12]

Hi,

There is also a GPS log file (if activated in SC settings) which could give hints. There are empty fields, see screenshot. So far I know that they could be filled after a firmware update (this firmware is said to exist, but nobody knows it ..., and an update can potentially be a risk ).

Christian

[admin]

Hi,

this is the list

NoSignal,
Initializing,
PartialData,
Locked,
BadData,
BadCalibrationReduceEndPos,

The first four come from the GPS unit itself. The last two come from SharpCap if it spots anomalies in the data coming from the GPS unit. BadData is used when the offset of the time from the system clock is more than 24 hours. BadCalibrationReduceEndPos is as you described.

As far as I'm aware even with the updated firmware, there is no way to find out if the almanac has been downloaded other than monitoring the time signal. With the updated firmware you can extract all the NMEA data and that will be saved to the GPS log file for later processing.

If anyone is interested, I think I could locate the firmware files and instructions for updating the camera – you also need a USB blaster device to program the firmware onto two separate chips inside the camera. Although I have the parts and the information I must admit I haven't dared to do this yet!

Cheers, Robin

[SteveInNZ]

Hi Robin,

I'd be interested in the information for upgrading my 174 if it's not too much trouble.

Cheers,

Steve.

[Kai Getrost]

I'd be interested in info on firmware upgrades as well. Although I get GPS data in 16-bit mode, getting the altitude and other info alluded to in the GPS log would be nice (if indeed that is the case after upgrade).

[admin]

Hi,

Ok, I will do my best to share the info here - I do have to ask for permission to share the notes I was sent on performing the update though, as they did not come from QHY

thanks,

Robin

[procyon12]

Hi Robin,

Good news ...

Two things are interesting:
a) will be there a way back if the upgrade fails or is bad for some reasons ?
b) a changelog (only the empty GPS fields ore more) ?

Thanks.

Christian

[TimHaymes]

Ive seen that UT can be off by 1-3 sec when the GPS reports Locked, and before any leap seconds are received. I usually have another UT signal near-by to check the GPS seconds are in step before I start recording. It hasn been a problem so far.
Thanks for the info on the upgrade.
-Tim

[procyon12]

Hi,

@Tim: Tim, a good hint. It would agree with Kai's initial post. Maybe, the additional GPS data can indicate this - I'll observe it.

@Robin:

perhaps if I can get all the additional info into ADV or FITS

Yes, good idea. But for some reasons (SER, critical events - the log is additional data) we should keep the GPS-log, one can optionally deactivate it.

Christian