Firmware Bug Affecting All Uniden GPS-Capable Scanner Models

[jonwienke]

This is a bit technical, and is primarily for @JoeBearcat, but I'm posting it publicly because the issue affects compatibility between all current Uniden scanner models and all GNSS units that are capable of receiving multiple satellite navigation systems (Beidou, Galileo, GLONASS, etc), and has probably affected other forum members.

The issue has to do with the way Uniden is parsing NMEA sentences. The basics of the standard can be found here: http://navspark.mybigcommerce.com/content/NMEA_Format_v0.1.pdf

For GPS-only receivers, a typical data output from the receiver looks like this (comments in italics):
Time, date, position, course and speed data
15:11:42 $GPRMC,151142.00,A,3905.42289,N,07810.38664,W,0.845,,240621,,,A*61

Course and speed relative to the ground
15:11:42 $GPVTG,,T,,M,0.845,N,1.565,K,A*2D

Time, position, and fix related data of the receiver
15:11:42 $GPGGA,151142.00,3905.42289,N,07810.38664,W,1,05,5.57,324.7,M,-34.3,M,,*6E

IDs of satellites which are used for position fix
15:11:42 $GPGSA,A,3,17,14,,,,,,,,,,,8.98,5.57,7.05*0D
15:11:42 $GPGSA,A,3,82,74,73,,,,,,,,,,8.98,5.57,7.05*03

Satellite elevation, azimuth and CNR
15:11:42 $GPGSV,2,1,06,06,23,213,20,07,01,172,,14,83,085,22,17,66,320,17*79
15:11:42 $GPGSV,2,2,06,28,,,24,30,28,197,*45
15:11:42 $GPGSV,2,1,08,66,03,020,,67,05,067,21,73,79,254,28,74,34,325,11*76
15:11:42 $GPGSV,2,2,08,80,37,163,18,82,19,040,27,83,61,008,20,84,42,249,15*74

Position, time and fix status
15:11:42 $GPGLL,3905.42289,N,07810.38664,W,151142.00,A,A*72

This data is typically output once per second, with all the variables being refreshed each time.

$ is always the first character of the sentence. The GP after the $ is the talker ID, which indicates the data is derived from the US GPS system. However, the talker ID changes when other satellite systems are introduced into the mix:

Galileo Positioning System	GA
BDS (BeiDou System)	GB
NavIC (IRNSS)	GI
GLONASS	GL
Global Positioning System (GPS)	GP
QZSS	GQ
The “GN” Talker Identifier shall be used when the data in the sentence is produced from a combination of multiple satellite systems.	GN

https://www.nmea.org/Assets/20190303%20nmea%200183%20talker%20identifier%20mnemonics.pdf

So when the receiver is combining data from multiple systems (in this example, GPS and GLONASS), the data looks like this:
15:49:53 $GNRMC,154953.00,A,3905.41318,N,07810.42978,W,0.080,,240621,,,A*76
15:49:53 $GNVTG,,T,,M,0.080,N,0.148,K,A*38
15:49:53 $GNGGA,154953.00,3905.41318,N,07810.42978,W,1,06,1.55,243.0,M,-34.3,M,,*7A
15:49:53 $GNGSA,A,3,14,06,,,,,,,,,,,2.65,1.55,2.16*1A
15:49:53 $GNGSA,A,3,74,73,67,83,,,,,,,,,2.65,1.55,2.16*14
15:49:53 $GPGSV,3,1,12,01,23,045,,02,09,227,,03,33,080,,06,39,222,27*75
15:49:53 $GPGSV,3,2,12,11,09,221,,14,68,138,25,17,68,004,13,19,56,303,20*72
15:49:53 $GPGSV,3,3,12,21,05,048,,22,22,054,,24,17,308,21,30,13,190,*70
15:49:53 $GLGSV,3,1,10,67,12,049,28,68,10,097,,73,61,201,36,74,52,311,26*64
15:49:53 $GLGSV,3,2,10,75,03,334,22,80,16,168,18,82,04,051,18,83,44,028,25*6C
15:49:53 $GLGSV,3,3,10,84,54,279,23,85,04,245,25*69
15:49:53 $GNGLL,3905.41318,N,07810.42978,W,154953.00,A,A*64

Instead of every sentence having the GP talker ID, GN is used where data from multiple systems is combined, GL is used for GLONASS satellite position data, and GP is used for GPS satellite position data. And that is where the problem arises.

The firmware for all current Uniden scanners incorrectly looks at the first 6 characters of the sentence to parse the sentence type, rather than just characters 4, 5, and 6 ($ being character 1). As a result, all valid NMEA GLL and GGA data sentences with talker IDs other than GP are ignored, and the scanner will not update its position from the data, even though the data is correctly formatted and being received by the scanner, when the GNSS receiver is receiving multiple systems, or any satellite navigation system other than GPS. This also breaks compatibility with ALL multi-system GNSS receivers.

The Reyax modules I use for my internal GPS installs receive GLONASS and GPS, so I've been dealing with this issue for a few years. I've been working around this bug by reprogramming them to always use the GP talker ID, but any time the module gets reset to factory defaults, it resumes using the correct talker IDs, and the scanner doesn't recognize the position data from the module anymore. From a customer's view, that's indistinguishable from a module failure, and I get the joy of doing a warranty repair on a perfectly good module.

Fixing the problem won't just make my life easier, it will benefit everyone who wants to use a multi-system GNSS receiver for mobile scanning. And it should be easy to do; only a line or two of code should need to be changed.

 

[KK4JUG]

And it should be easy to do; only a line or two of code should need to be changed.

Now it's easy. You did all the work for them.

 

[jonwienke]

Now it's easy. You did all the work for them.

Except for actually changing the code, of course...

 

[jonwienke]

There are two other GPS-related firmware bugs:

According to several posts made by UPMan, when a GPS is connected to a scanner, the scanner is supposed to periodically sync its internal RTC with the GPS time from a GGA, GLL, or RMC sentence, to keep the displayed date/time accurate. THIS DOES NOT WORK CORRECTLY.

I currently have a 436, 536, SDS100, and SDS200 set up on my scanner rack. All of them have been running continuously while connected to GPS for over a week. Using a Garmin Forerunner as a GPS time reference and watching the scanner time displays, the 536, SDS100, and SDS200 all update the minute on the time display within a second of the Forerunner. However, the 436 doesn't update the time for another 7 seconds or so.

But before getting too excited about the non-436 models, I've connected a GPS to customer SDS100 and 436 units and not observed clock sync after an hour of running.

The scanner should sync the RTC to GPS time whenever any of the following events happen:

• The first time a GGA, GLL, or RMC sentence is received after boot
• Whenever a a GGA, GLL, or RMA sentence is received, and it has been more than an hour since the last RTC sync event

That will ensure the clock gets synced in a reasonable amount of time, without bogging down the scanner with syncing the clock constantly.

 

[donc13]

So... This begs te question... is the BC-SGPS a multi system receiver or just a US GPS receiver?

 

[jonwienke]

The Uniden pucks are GPS only. The ones I use are multi-system, which is part of the reason they get better reception.

 

[MStep]

Without reading the fine print, my guess is that Uniden likely "guarantees" that their receiver's GPS systems are only compatible with their own GPS devices. No doubt, they are more interested in selling their own devices. It would not be to their advantage profit-wise to alter their firmware to make them compatible with other non-Uniden devices.

 

[RMason]

Except for actually changing the code, of course...

And regression testing......

 

[JoeBearcat]

Both added to the list. All the diagnostics helps ensure that as many bugs as possible will be fixed since it eliminates some of the allocated time to find the issue.

 

[jonwienke]

Without reading the fine print, my guess is that Uniden likely "guarantees" that their receiver's GPS systems are only compatible with their own GPS devices. No doubt, they are more interested in selling their own devices. It would not be to their advantage profit-wise to alter their firmware to make them compatible with other non-Uniden devices.

But the sentence type parsing bug also precludes Uniden from developing, testing, and selling their own multi-system GNSS accessories, which means forfeiting a competitive advantage, in terms of price (you can ju$tify charging more for a device with more feature$) and performance. And it can be worked around by programming the 3rd-party device to always use the "GP" talker ID (which is what I've been doing for years).

Both added to the list. All the diagnostics helps ensure that as many bugs as possible will be fixed since it eliminates some of the allocated time to find the issue.

Thank you. BTW, my GNSS module supplier is interested in establishing a relationship with Uniden. PM me if there's any mutuality to that...

 

[dispatcher812]

So for those of us less techy, is this the reason my 436 with the sgps is not doing its thing? Also what firmware version has thus issue?

 

[jonwienke]

All versions of firmware for the SDS, x36, HomePatrol and x96 models are affected. My guess is the NMEA sentence parsing firmware code was written incorrectly for the x96 family, and then copied over to the other model families when they were developed and introduced.

But Uniden-branded pucks are GPS only, so they shouldn't be affected by the bug. The most likely issues is serial speed being set wrong. The two valid options are 4800 and 9600.

 

[nessnet]

Jon - quick question...?
Since the 355S4 is essentially the same puck as the OE Uniden - also GPS only?
I assume so?

 

[jonwienke]

As far as I can tell, it is the exact same hardware as the Uniden puck, the only difference being the brand sticker. It's GPS only and uses the GP talker ID, so it doesn't trigger the bug.

 

[gtaman]

GPS only is so behind. Multi system GPS has been used for years I think it’s time for the Uniden pucks to get a new revision.

 

[KK4JUG]

GPS only is so behind. Multi system GPS has been used for years I think it’s time for the Uniden pucks to get a new revision.

Good idea. Let's jack the price up some more.

 

[gtaman]

Good idea. Let's jack the price up some more.

It would literally cost pennies. Most GPS chips are multi system now. It would be like trying to build an LTE only phone today. It will end up costing more or the same than building a phone with 5G/LTE chip.

 

[jonwienke]

The uncased modules I use cost about $15 each retail.