SDS100/SDS200: SDS100 Firmware 1.03.01 Public Release

[jonwienke]

Already did all those things. Its not the settings or programming, the scanner worked fine until firmware update. No matter what is put manually for GPS it does not see my local tower anymore. All frequencies are correct.

Even reset everything, just updated database in scanner with all Service Typed checked...nothing.

If you can receive any site from the MPSCS system, then that rules out a firmware problem.

What site are you trying to receive? The SDS100 allows NAC to be set at the site level instead of the system level. In some cases the NAC listed for the site is incorrect in the database, and if the scanner is using that incorrect NAC, it will completely disable reception for the site. If a NAC is listed for the site, change it to NAC Search.

 

[Hit_Factor]

Even reset everything, just updated database in scanner with all Service Typed checked...nothing.

I sent you a PM with contact info. I monitor the same system from SW Michigan. I'd like to help.

 

[MiTreasureHunter]

I sent you a PM with contact info. I monitor the same system from SW Michigan. I'd like to help.

Thank you, sent a PM back for tonight. Will definitely get with you if can not figure this out, looks like we are not very many miles apart.

 

[MiTreasureHunter]

If you can receive any site from the MPSCS system, then that rules out a firmware problem.

What site are you trying to receive? The SDS100 allows NAC to be set at the site level instead of the system level. In some cases the NAC listed for the site is incorrect in the database, and if the scanner is using that incorrect NAC, it will completely disable reception for the site. If a NAC is listed for the site, change it to NAC Search.

Fixed, thank you for the help. Zero idea why before the firmware update the NAC status did not disable my local tower, but I set it to NAC search and yep fixed. So everyone take note that importing directly from the RR database sometimes the data is incorrect.

Anyways it was a learning experience, a Big one! It forced me to dig deep into the programming that I never dealt with before. Never been a Uniden scanner guy so this Sentinel software is new to me.

Now to rebuild all my Favorites lists I deleted LOL.

 

[GTR8000]

Zero idea why before the firmware update the NAC status did not disable my local tower, but I set it to NAC search and yep fixed.

Because only the most recent database pulls for Sentinel included the Site NAC, so it was a non-factor earlier.

So everyone take note that importing directly from the RR database sometimes the data is incorrect.

Assuming you now know the correct NAC, please make sure to submit it to that system in the database so that others don't suffer the same issues.

 

[phask]

Fixed, thank you for the help. Zero idea why before the firmware update the NAC status did not disable my local tower, but I set it to NAC search and yep fixed. So everyone take note that importing directly from the RR database sometimes the data is incorrect.

Anyways it was a learning experience, a Big one! It forced me to dig deep into the programming that I never dealt with before. Never been a Uniden scanner guy so this Sentinel software is new to me.

Now to rebuild all my Favorites lists I deleted LOL.

That's what I suggested in post 188 yesterday.


But then, you stated you tried everything

 

[nwadler436]

Creating Log File

Feeling stupid but how do you create a log file for the SDS100? Things seem to be improving with the SDS100 but I like to be able to contribute. I couldnt find a solid lead searching the forums.

 

[rbrtklamp2]

Hold avoid while turning the radio on and then go to setting - debug log - SD card- and then back to scanning. When done making the log go back and turn debug off then plug your scanner into the computer find the debug folder and post it's contents for UPMan to use to fix these issues.

Sent from my SM-N910V using Tapatalk

 

[nwadler436]

Hold avoid while turning the radio on and then go to setting - debug log - SD card- and then back to scanning. When done making the log go back and turn debug off then plug your scanner into the computer find the debug folder and post it's contents for UPMan to use to fix these issues.

Sent from my SM-N910V using Tapatalk

So if I am not sure if there is an issue should I create a log anyways and post it? I have an old scanner, GRE PSR 500, and it’s like using apples and oranges with my local simulcast system.


Sent from my iPhone using Tapatalk

 

[rbrtklamp2]

If your missing things on the radio or having some kind of issue that is bug related you should probably post the log. It should at least be up to par with our GRE radios. If you are hearing things on your GRE that you aren't on the SDS100 make a log. I made a log because my GRE radios would pick up patched tgs and the SDS didn't. I'm still hoping they fix that next firmware update.

Hope this helps,
Bob

Sent from my SM-N910V using Tapatalk

 

[MiTreasureHunter]

That's what I suggested in post 188 yesterday.


But then, you stated you tried everything

Like previous statement NAC was not an issue until latest database pull. I had done everything I ever needed to do that has been working.

 

[scrotumola]

To date I had been really disappointed with how the SDS100 had performed with the San Antonio/Bexar County 800 mhz EDACS ProVoice system, completely missing upwards of 80% of traffic even with a -45 dbm average signal with the Radio Shack 800 antenna.

Having had the chance to put 2 SDS100s side by side with both beta open firmware options and a BUNCH of 436s, I was in the process of comparing 1.02.05a and 05b open and how the alpha open was better than b in regards to EDACS ProVoice performance.
For the record, alpha was better but still unacceptable.

Now comes SDS100 Firmware 1.03.01 and I am happy--no, ECSTATIC to report that the SDS100s are performing just as well as their 436/536 counterparts! The radio also doesn't seem to heat up as drastically and before there was degradation of traffic in other modes as the temp increased.

I'm sure there is still room for improvement, but for now, I am happy that I can actually use my latest acquisition.

THANK YOU PAUL, and all of the development crew at muppet labs for making good on this one!

~S~

It really irks me to say this, but I must retract the ENTIRE posting. Less than 36 hoursafter I shared the above news, I started noticing decreased performance of the SDS100 on the San Antonio/Bexar County EDACS ProVoice system--initially with occasional choppiness gradually worsening to the point that today the radio remained stopped on the assigned talkgroup, but the entire fireground operation remained silent. It has also missed many transmissions completely. Other times, the channel unmutes after the LCN was released leaving an open squelch unmodulated carrier.

No longer a happy camper.

 

[jonwienke]

Less than 36 hoursafter I shared the above news, I started noticing decreased performance of the SDS100 on the San Antonio/Bexar County EDACS ProVoice system--initially with occasional choppiness gradually worsening to the point that today the radio remained stopped on the assigned talkgroup, but the entire fireground operation remained silent.

Firmware wouldn't cause a gradual change in performance that didn't start until more than 24 hours after it was installed. It would be an immediate change happening as soon as it is installed. Something else has changed, either with the system configuration, or with your antenna/coax.

Have your RSSI values changed? Was there rain or severe weather around the time of the change that could have caused antenna damage, or caused water to infiltrate into the coax?

 

[MiTreasureHunter]

So the RR database has the NAC's incorrect for several of the Tower sites here in Michigan for the MPSCP system.

Question, I'm not seeing a way in the Sentinel software to correct the NAC's in my database, I only know how to in Favorites lists. Am I missing something, is it possible to correct? If not can it be corrected in the scanner itself?

The bummer is with my local tower being wrong in the database I can not really run a Full database scan on that system on my scanner.

 

[GTR8000]

So the RR database has the NAC's incorrect for several of the Tower sites here in Michigan for the MPSCP system.

Question, I'm not seeing a way in the Sentinel software to correct the NAC's in my database, I only know how to in Favorites lists. Am I missing something, is it possible to correct? If not can it be corrected in the scanner itself?

The bummer is with my local tower being wrong in the database I can not really run a Full database scan on that system on my scanner.

The full database in Sentinel cannot be edited; only within a Favorite list can something be changed.

As I suggested in my previous post, the proper course of action is to determine the correct NAC for the sites in question, then make a submissions to the database. A database administrator will make the corrections, which will make their way into the full Sentinel database for the Monday update that follows any changes being made.

 

[troymail]

Seems like this is an issue that won't really "go away" -- true - as things are found and corrected in the database, certain issues will resolve (in time - after someone submits the change, waits for the DB admins to act on the submission and then wit until the following week) but it could be like "whack a mole" as new submissions are made that contain bad information.

Still seems there should be an option to globally ignore site NAC (on/ignore by default). Otherwise, these types of "doesn't work" reports will only continue. Remember - many users aren't experts in this stuff...

 

[jonwienke]

Just make the default site setting NAC Search. You can still specify a site NAC if you're experiencing an interference issue, but normally NAC Search will avoid more issues (wrong NAC set) than it causes (interference).

 

[MiTreasureHunter]

Seems like this is an issue that won't really "go away" -- true - as things are found and corrected in the database, certain issues will resolve (in time - after someone submits the change, waits for the DB admins to act on the submission and then wit until the following week) but it could be like "whack a mole" as new submissions are made that contain bad information.

Still seems there should be an option to globally ignore site NAC (on/ignore by default). Otherwise, these types of "doesn't work" reports will only continue. Remember - many users aren't experts in this stuff...

I'm looking at all the surrounding Tower Sites that do work and they all have NAC as "N/A" in the database. Seems may be better off if they would just leave all sites that way.

As a database dependant hobbiest that don't get deep into the how's or why's...what is the benefit of knowing the true Site NAC?

 

[jonwienke]

Sometimes you can hear two different systems on the same frequency. Programming the NAC prevents traffic from one system from being incorrectly identified as originating from the other system.

 

[troymail]

I'm looking at all the surrounding Tower Sites that do work and they all have NAC as "N/A" in the database. Seems may be better off if they would just leave all sites that way.

As a database dependant hobbiest that don't get deep into the how's or why's...what is the benefit of knowing the true Site NAC?

There are actually some benefits but with an "always on" implementation - even more so for the full database - having incorrect information in the database is detrimental to proper operation - particularly for novice users.