SDS100/SDS200: SDS100 Firmware 1.02.05b for Open Beta

[UPMan]

I have some firmware for testing against some of the reported issues. Specifically, the items below.[FONT=&quot]
[/FONT]

1. [FONT=&quot]P25 systems holding on site with good signal, but RSSI indication blanks and many comms are missed.[/FONT]
2. [FONT=&quot]EDACS system missing many comms.[/FONT]
3. [FONT=&quot]Some Harris P25 systems missing many comms.[/FONT]
4. [FONT=&quot]Inconsistent backlight operation[/FONT]
5. [FONT=&quot]Hold time 0/1 sec have different results (1 was better).
   [/FONT]

[FONT=&quot] [/FONT]
To apply this test firmware, download http://info.uniden.com/twiki/pub/partnerweb/sds100-beta/SDS-100_V1_02_05b.bin

Copy this file to the FIRMWARE folder on your SDS100, then reboot the scanner.

To report in this thread, follow this format:
Quote: Tested Against:
1. P25 systems holding on site with good signal, but RSSI indication blanks and many comms are missed.
2. EDACS system missing many comms.
3. Some Harris P25 systems missing many comms.
4. Inconsistent backlight operation
(keep only the lines above that apply to your test)

Results: Problem is fixed/not fixed (for each item you checked)

Link(s) to system(s) checked:

Discussion: (describe how you tested/what specific results were for each item you checked)

Log File(s):
<log file name> : Which system this log is from and which problem is still occurring.

To make a log, first set up to scan only a single system that exhibits the problem you are logging. Best approach is to put directly from the main database to a favorites list, then scan only that favorites list.

Then, turn off the scanner and turn it on while holding AVOID.

MENU --> SETTINGS --> SET DEBUG MODE --> SD Card (File)

Capture a log long enough to catch the problem.

MENU --> SETTINGS --> SET DEBUG MODE --> Off

The file is put in the debug folder. If you make multiple logs against different problems, keep track of the order in which you tested so that you describe each log file correctly.

I will ask admins to delete any post that either does not follow the above format or is not in a direct response to a followup from me so that this thread only contains reports (or clarifications/follow ups).

 

[W2SJW]

Tested Against:
4. Inconsistent backlight operation

Results: Problem appears to be fixed

Link(s) to system(s) checked: https://www.radioreference.com/apps/db/?sid=7021

Discussion: As with the previous beta test, I held on the simulcast site that I reside in & let it scan all known talkgroups. Scanner stops & illuminates the backlight for all Phase-I & Phase-II traffic without flickering/pulsing, and the backlight now stays on until the end of my scan delay (added bonus!).

 

[rbrtklamp2]

Tested Against:
4. Inconsistent backlight operation

Results: Problem appears to be fixed

Link(s) to system(s) checked: https://www.radioreference.com/apps/db/?sid=7021

Discussion: As with the previous beta test, I held on the simulcast site that I reside in & let it scan all known talkgroups. Scanner stops & illuminates the backlight for all Phase-I & Phase-II traffic without flickering/pulsing, and the backlight now stays on until the end of my scan delay (added bonus!).

I am seeing the same results as reported above but more importantly analog and digital audio sound much much better. This is just my preliminary testing but it does seem to be sound and work better thank you UPMan for listening to the posts in the previous thread. Seems to be working and sounding much better.

 

[jonwienke]

I have the backlight set to Squelch, and it is staying on for the Delay setting (5 seconds) after squelch closes on all the digital and analog channels I've tested so far. I like that, as it makes it much easier to see who was talking on short transmissions. Please migrate this behavior to the x36 firmware.

I also spent some time listening to FMB, and the periodic dropout issue seems to be fixed, and audio quality is improved. It still seems to have a 5KHz low-pass filter applied (which should be changed to 15-20KHz), but audio doesn't sound clipped any more.

 

[UPMan]

I should have included in the first post:

• If you previously set site hold time > 0 to improve performance, please set it back to 0 for testing. Setting a longer hold time strictly for performance issues should not be necessary.

• The backlight issue is that the backlight would briefly flicker, then fail to illuminate at all for the next comm. Not that it did or did not stay on as long as you wanted. (i.e. actual bug, not design)

 

[W2SJW]

I should have included in the first post:

• If you previously set site hold time > 0 to improve performance, please set it back to 0 for testing. Setting a longer hold time strictly for performance issues should not be necessary.

• The backlight issue is that the backlight would briefly flicker, then fail to illuminate at all for the next comm. Not that it did or did not stay on as long as you wanted. (i.e. actual bug, not design)

I was just pleasantly surprised to see the the 'squelch' backlight behavior on this new beta.

I will be testing in an hour or so on another mixed 500/700 P25 system (just to confirm that the fixed behavior is not a fluke limited to just the NJICS).

 

[wx5uif]

Tested against:
3. Some Harris P25 systems missing many comms.

Results: Still having issues.

The previous beta seemed to have better results for me. TG 1000 (Broken Arrow PD) has the dispatch (UID 100111) in the clear but units are encrypted. Scanner skips the encryption, but when dispatch speaks, the scanner pauses for a brief second then continues scanning. During the brief stop, you can hear what sounds like the audio amplifier coming on, but no voice. Confirmed traffic occurring with DSD. Previous firmware I didn't see this issue with.

TG 1007 acts the same way. Dispatch (UID 100113) clear while units are encrypted.


Link to system: https://www.radioreference.com/apps/db/?sid=7634
Testing on site 1.

 

[JamesO]

Back light behavior is much improved, will need to spend some more time before this is considered acceptable.

Not sure this has been considered, would there be any power saving if the keypad back light did not come on with the squelch unless a key is pressed as an option?

Given the power hungry nature of this radio, this may help with run time and could be an easy option to add.

 

[jonwienke]

Issues 1/3 Missing comms / oscillating between control & voice channel
Still happening
Monitoring Washington County MD
https://www.radioreference.com/apps/db/?sid=6451
Most TGs work normally, but sheriff and MD State Police TGs are not heard, scanner jumps back and forth between control and voice channels, and no audio is heard. Possible encryption? If so, a flag should be set so that the scanner doesn't keep rechecking the transmission every second or so. If encryption is detected, the TGID should be temporarily ignored until the transmission ends, or the transmitting UID changes.

New issue:
When GPS is connected, scanner loses contact with GPS. The GPS icon goes away, and "No GPS" is displayed in the lat/lon text boxes in Detail View. Going into the Location menu and resetting the baud rate restores the connection--the GPS icon lights up and the lat/lon boxes show coordinate data again. This happened twice. The scanner acted as if the baud rate had been set to NONE or something incorrect, even though the menu showed the correct value when I went in to reset it. Re-selecting the displayed value in the menu re-established communication with the GPS.

Link to logs:
https://1drv.ms/u/s!ApJIS-l4xqPtgvgDRVTGN1i90e3R5g

 

[seth21w]

Firstly backlight is functioning properly now.

2. Some Harris P25 systems missing many comms.

result is its still missing short comms. And maybe the first half second to a whole second of the comms. I am not running any sys hold time as requested.

https://www.radioreference.com/apps/db/?sid=6907

this is our system I'm monitoring.

 

[Gilligan]

Issues 1/3 Missing comms / oscillating between control & voice channel
Still happening
Monitoring Washington County MD
https://www.radioreference.com/apps/db/?sid=6451
Most TGs work normally, but sheriff and MD State Police TGs are not heard, scanner jumps back and forth between control and voice channels, and no audio is heard. Possible encryption? If so, a flag should be set so that the scanner doesn't keep rechecking the transmission every second or so. If encryption is detected, the TGID should be temporarily ignored until the transmission ends, or the transmitting UID changes.

For the Washington County, MD system, all law enforcement is encrypted. I agree though that the scanner shouldn't really even pause on those talkgroups even momentarily.

 

[jonwienke]

I'm OK with the scanner doing an initial check for encryption, because sometimes comms are in the clear even on channels that are customarily encrypted. But once encryption has been verified for a transmission, there's no value in re-checking the same transmission repeatedly.

If the transmission is complete, or a different unit starts talking (for channels where dispatch is clear but other units are encrypted) the temp ignore flag can be reset and the channel checked again.

 

[Nasby]

Backlight works wonderfully now.

 

[W4KRR]

"b" beta firmware test.
System tested:
https://www.radioreference.com/apps/db/?sid=8214
Specifically, the Fort Lauderdale site, although the Plantation site suffers from the same issues. Coral Springs site is fine, but I am closer to it.

Results:
Issue 1: No change. Scanner appears to have trouble locking onto and holding the control channel. RSSI indicator rapidly flashes between -45dBm and blank "---". Talkgroups will rapidly flash and disappear from the screen with no audio heard. Sometimes complete conversations are heard; others drop out in mid sentence.

Issue 2: Not tested
Issue 3: Not tested
Issue 4: Back light issue seems fixed or greatly improved.

Tested with Radio Shack 800MHz duck antenna, and an external multi band scanner antenna mounted outside up about 12 feet. Better results from the outside antenna.

In general: The systems that are received easily on my BCD436HP are received easily on the SDS100, and the systems that give me difficulty on my BCD436HP give me difficulty on the SDS100. Although I would say that overall reception is slightly better on my BCD436HP.

 

[captainmax1]

Tested Against:
4. Inconsistent backlight operation

Results: Fixed/Working properly now.

Before update I could only get backlight to work during squelch or always on via keypress no matter what different setting combinations I used. Now, when I set it to squelch for 15 seconds, it stays on the set time. Also NO more flickering.

 

[jonwienke]

[Columbo]
One more thing I forgot to mention...
[/Columbo]

Well 2 things, actually. Something is wacky with the numeric RSSI display calibration. At -60 and below, it changes in 1dB increments. Above that, it changes in 5dB increments, so you only see -55, -50, -45, etc.

Similarly, the digital decode error display currently only shows values evenly divisible by 5 when you're doing a site hold and the scanner is dwelling on the control channel. While on a voice channel, it can show any integer value. I also occasionally see values >100, like 125. Is that right? Isn't the decode error supposed to be a percentage of the data that decodes with a good checksum?

 

[Ubbe]

In professional radios it is a percentage value stating the Bit Error Rate BER but I belive Uniden counts the number of errors in a frame, maybe it can be called Bit Error Number BEN.

/Ubbe

 

[sibbley]

Firmware 1.02.05b: DMR/NXDN - Using a Duck antenna.

Paul, This is not really relevant to the issues the latest firmware is supposed to fix. However, I chose to post here since the latest firmware has fixed issues I have been having.

I have been having issues with some OFT DMR/NXDN systems in my area not in the RR database. I wasn't able to hear much from these systems compared to the 436. Last open beta firmware did help a little. The RSSI on these systems was -100 or worse, with horrible decode at best. I would have no signal bars on the SDS100 when the 436 would show 4 or 5. I am in close range of these systems, so weak signal wasn't the problem. Setting hold time to 1 or 2 seconds also helped a bit.

Upon upgrading to this latest firmware, I'm hearing much more from these systems. The RSSI has gone up to the lower -80's and -90's. I'm now seeing signal bars, and decode is much better even as low as -114. Error rates went from double digits on last beta (20's), to single digits(2-5) on today's release. Today's testing was done using 0 hold time on all systems.

Trunked systems always worked good on the SDS100 and had good decode. However, I'm now seeing much better RSSI values on trunked systems too. On this system, https://www.radioreference.com/apps/db/?sid=8818 using the last firmware beta, I was seeing values in the -90 to -98 range on the Pen Argyl site which is closest to me. Since the latest firmware this morning, I'm seeing values from -70 to -77.

I don't know what engineering did in this latest release, but it seems it has made receive better. At least in my area.

Again, this was all using a duck BNC antenna w/ provided adapter.

Thank you and team, for continuing to make these scanners the best they can be.

 

[Badboy536]

With this latest Beta firmware what im getting .when i listen to LAPD P25 a signal will be full Full scale on the S meter abd a low RSSI will be low -60 with the radio sitting in one spot the signal will drop out no bars on the s meter and nothing on the RSSI then it will pop up on the signal meter to 2 bars and a RSSI of -105. It acts like its got a short in the radio the way the signal's can bounce around.it also does this on Analog Frequencies as well like ham radio and Analog police and fire. Definitely still need some tweaks on the firmware.

 

[RF23]

You might try using the ATT. to see if the SDS100 is being overloaded with strong RF signals.