For the last couple of years I have been using a GlobalSat BT368 as a navigational aid with both Android devices and desktop Linux via gpsd. Recently, this device most often does not find a fix at all though sometimes it does after just a few seconds. Over the years I found that depending on the view of the sky it would generally be anywhere from 15 seconds to a few minutes, but not more than that. Once it had a fix, it worked well even in canyons (real canyons, not urban ones) where other devices quickly stopped working.

I have found out that using gpsd + xgps will show what satellites (it thinks) are in view, the positions, and the signal to noise ratios even if there is no fix. Today I left the unit turned on and it took approximately 3500 seconds to find a fix. I just happened to be looking at the screen when it fixed, and the five satellites it was using quickly jumped to nearly opposite quadrants of the sky. Clearly this unit did not think the satellites were in the right place.

My first question is, Does anyone know whether this device's SIRF III chip set is affected by the recent GPS "Y2K" situation? I cannot really find much documentation on this at all aside from hearsay. When it finds a fix the UTC time is correct, though there is no time given when there is no fix.

The manufacturer has removed almost all trace of this device from their web site. They really seem not to stand by their products, unfortunately.

My second question is, If I replace this unit with something newer, does anyone have any suggestions for a similar device that is compatible with gpsd for Linux, and BlueGPS for Android (specifically that app, and the fdroid version of it, please no proprietary magic)? Does anyone have a Garmin GLO working this way by chance?

I am aware of the list of gps devices at https://gpsd.gitlab.io/gpsd/hardware.html but it seems unmaintained nowadays. Thanks.

After a lot of searching around and testing, I can conclude that this unit is indeed affected by the week rollover situation. Whether a GPS unit is vulnerable to this depends upon the physical chipset rather when the actual device was manufactured. Further, depending on how some devices parse and store timestamps, the effects of the week rollover might not be detectable for some time.

I found that after draining the battery completely (to the point that the device would not power on) and restarting it, it quickly found my location. After turning the unit off and back on again, it would not find my location no matter what.

There is a closed, Windows-only program called SirfDemo that will let you communicate directly with the firmware in the SiRF chip. This is basically just a graphical front-end to the commands found in the "SiRF Binary Protocol Reference Manual." Unfortunately for some devices, gpsctl won't communicate with the firmware. I was unable to make that work, so I had to consult SirfDemo. Although mainly used with USB devices, you can find the COM port of the bluetooth GPS and just use that.

- Turn on Bluetooth in Windows
- Turn on GPS Receiver
- Find COM port number
- Start Sirf Demo, use the above COM port number, set baud to 4800
- Then click Action -> Open Data Source

While the device tries to find your location, it should show satellites as well as some debug text. After 20 minutes my location was not found. In my case, it says we are in week 15 - it has been 15 weeks since the rollover.

To simulate draining the battery, try

- Action -> Initialize Data Source
- In the box that appears, check "Cold Start" and the option about clearing the internal RAM

After several seconds you should see the list of satellites change drastically. Within a 30-90 seconds it should find your location. It should now say week 2063 (ie 1024*2 + 15, first rollover was around 1999), or once it even said "n/a" but it still worked.

Leave the unit turned on.
- Then click Action -> uncheck Open Data Source
- Close SirfDemo
- Turn off Windows bluetooth

Now you can pair the GPS to your Linux computer or preferred mobile device and it should work.

(!) Unfortunately you need to do this every time you want to use the GPS.

This tells us that the saved settings used for warm start uses only two-digit week numbers. Yuck. So we need a way to force this device to do a cold start every time you turn it on. I have not found a way to do this yet.

References:
superuser, "Command to Change GPS from SiRF Binary to NMEA Output"
askubuntu, "Can gpsd change the firmware of a gps receiver?"
"Hacker's Guide to GPSD"
Maestro Wireless Solutions, "2019 GPS Week Number Rollover Update Customer Notification"
GPS Passion Forums, "NMEA Proprietary Commands - SiRF, NemeriX, etc..."
LIGO GPS Time Converter
"SiRF Binary Protocol Reference Manual"