GRE PSR-500 Firmware Release Thread

[IndyEmsGuy]

Well after installing the new firmware I am hardly receiving any traffic and when the scanner picks up traffic on the TGRP the LED lights up and so does the backlight like it should but there is no audio heard. Very frustrating. This is a Motorola Type II SmartZone Omnilink 800 system. It is the Indiana SAFE-T system. http://www.radioreference.com/modules.php?name=RR&sid=933

 

[Kalem]

I am getting mixed but positive results with the new firmware. I seem to be getting a lot more signals (less lingering - seems to be faster through the list too). I listen at home and at work - at home it seems to be 100x better (I didn't realize what I was missing). At work it seems to have trouble tracking a couple talkgroups (stops on them and no audio - or thinks there is a freq change and comes back on the same frequency but gaps out a chunk of the conversation). These same talkgroups work fine at home and both places have strong signals. This is all on the minneapolis 800mhz P25 system.

I picked up an 800mhz antenna and I will see if that helps (and it's not wobbly like the stock!).

 

[thewenk]

Well after installing the new firmware I am hardly receiving any traffic and when the scanner picks up traffic on the TGRP the LED lights up and so does the backlight like it should but there is no audio heard. Very frustrating.

Although I didn't mention this in my prvious post, I too observed this condition of no audio with the Idaho 700 MHz P25 System after upgrading to DSP Beta 0.1 The problem was corrected when I reverted back to DSP F1.0.

Dave

 

[rvawatch]

in a different thread someone updated the dsp, but kept the old cpu. that worked better for them than both upgraded. might be something to mess around with.

in general it seems to be working great for the 800 mhz smartzone dig system here. STARS sensitivity seems to be lacking tho...

 

[h8tdigitalradio]

So I reverted back to the DSP F1.0, but I did not change the CPU upgrade back. Everything seems to be working fine ... for me, the new DSP firmware would be unuseable as it is today. I have not tried adjusting anything else at this point.

Hello,

Same issue here. I did keep the CPU Firmware, but reverted back to version F1.0 of the DSP. The unit would not decode the weakest system with DSP version beta .02. It works better with the original firmware. It would be nice to have both versions in the unit, and be able to switch back and forth in case of issues, instead of having to reload Firmware from PC.

Also as previously mentioned, the Multi-Site Trunking STAT mode still has issues. ROAM mode works fine. In STAT mode, the unit always locks on the weakest CC instead of the strongest one.

73

Dave AKA The Tripzter

 

[fmon]

in a different thread someone updated the dsp, but kept the old cpu. that worked better for them than both upgraded. might be something to mess around with.

in general it seems to be working great for the 800 mhz smartzone dig system here. STARS sensitivity seems to be lacking tho...

That would be me, CPU F1.0 appears to give a stronger "T" on the VA STARS P25 system. Still room for improvement but with DSP U0.2 this scanner now does much better on STARS then the 2096 on the same Scantenna.

 

[SCPD]

Hello,

Same issue here. I did keep the CPU Firmware, but reverted back to version F1.0 of the DSP. The unit would not decode the weakest system with DSP version beta .02. It works better with the original firmware. It would be nice to have both versions in the unit, and be able to switch back and forth in case of issues, instead of having to reload Firmware from PC.

Also as previously mentioned, the Multi-Site Trunking STAT mode still has issues. ROAM mode works fine. In STAT mode, the unit always locks on the weakest CC instead of the strongest one.

73

Dave AKA The Tripzter

Here is an idea to try with DSP U0.2 that I think would help the team out a bit....

- Those that are having trouble with DSP U0.2, but found that DSP F1.0 worked okay, go into the PGM, Func-Glob super expert menu and scroll down to "Noise Thresh". Increase the number to a value of lets say "50". This will allow the DSP to stay tracking on a noisy signal. This might help. The liability of increasing the number above the default is that it is more likely the radio will stay on a channel after a valid transmission ends. However this is a good test.

 

[troymail]

So I'm not sure where it happened but I have the Washington DC system programmed and noticed it wasn't receiving as well as it HAD been (I never really had problems with that system).

I looked more closely and noticed that the tracking was set to STAT (which I haven't found a good use for in any system in my area yet). I think this happened when I reloaded my radio with Win500 to pull settings down from RR.

I have now switched it back to OFF and it seems to be receiving much better again.

 

[mikey60]

Here's the problem that I've encountered: I've D/L'd the CPU Firmware Upgrade 0.1 and installed same; for no better reason (and I know this isn't always a wise rationale) than "the latest MUST be the greatest". Conventional channels seem to work precisely as before - no problem. With the City of StL 800 mHz Police system, however, I have problems. The radio scans and the display shows it stopping on talk groups, but no audio comes from the speaker (!!).

I've reinstalled "CPU Firmware 1.0" and the radio works fine on both conventional and the StL trunked systems. I've reinstalled Firmware 0.1 and the same audio problem is again exhibited. Reinstalling Firmware 1.0 "cures" the problem (yet again).

No harm, no foul, I guess; but I am left to wonder - am I missing something here? Did I somehow botch the upgrade? Is anyone else seeing this phenomenon? Any insight, suggestions (including "If it ain't broke don't try and 'fix' it") and comments are welcome. This has me baffled (not hard to do). I await the insight of others more able than I.

You mentioned the CPU Firmware, but not the DSP firmware. Have you tried installing the DSP Firmware upgrade as well?

Mike

 

[dpm3]

Might DSP 0.2 help in combo with CPU 1.0?

You mentioned the CPU Firmware, but not the DSP firmware. Have you tried installing the DSP Firmware upgrade as well?

Mike

No, I did not. I calculated that my inept stumbling through further changes might only muddy the waters enough that getting back to the status quo ante might be a nightmare. I've thought of staying with CPU 1.0 and updating to DSP 0.2, but my thought was that since the StL PD 800 mHz Motorola system was analog and not digital there might not be much (if any) advantage to doing so. What I'm looking for is a "tweak" that might improve that quarter to half second delay in the audio after the radio stops on a talkgroup - a phenomenon that may also be present (though not so apparent) on conventional channels as well.

The "upgrades" are amazingly easy if follow GRE's instructions methodically, so it could be done; but a lack of confidence in my own ability and fear of botching it further has held me back. Is there some suggestion that CPU 1.0 and DSP 0.2 might show some improvement in "audio response" for analog trunked systems and on conventional frequencies? Or is it possible that the addition of DSP 0.2 in combo with CPU 0.1 would solve the "no audio" problem that I (and a couple others) have noted?

 

[DonS]

Potential Win500 data corruption

For those who have seen a 'failure to lock onto VC', or 'ping-ponging between CC and VC'....

If you're using Win500 to upload to the radio, it's possible that that program is contributing to the problem. I wasn't initializing some data correctly when building TSYS objects, and it looks like that corrupted data could kill the radio's ability to tune or unmute VCs in some circumstances. Apparently, that corrupted data affects CPU update U0.1 only (or, at least, more than CPU F1.0).

I was able to reproduce the problem here using U0.1 and Win500 v00.40. I've released Win500 v00.41 - I haven't seen the problem with that version.

 

[thewenk]

Here is an idea to try with DSP U0.2 that I think would help the team out a bit....

- Those that are having trouble with DSP U0.2, but found that DSP F1.0 worked okay, go into the PGM, Func-Glob super expert menu and scroll down to "Noise Thresh". Increase the number to a value of lets say "50". This will allow the DSP to stay tracking on a noisy signal. This might help. The liability of increasing the number above the default is that it is more likely the radio will stay on a channel after a valid transmission ends. However this is a good test.

I was about to try this suggestion. In my previous post I had stated that I had reverted back to DSP 1.0 from 0.1 and kept CPU 0.1 and my reception problems on Idaho 700 MHz P25 were fixed. Later I also reverted back to CPU 1.0.

So today I reloaded DSP 0.2 with CPU 1.0 to try the above suggestion. And lo and behold reception seemed really good with CPU 1.0 and DSP 0.2--none, or at least very few of the problems I had before.

So, could it be the combination of CPU 0.1 and DSP 0.1 or 0.2 and not just the DSP upgrade??

Next I loaded CPU 0.1 -- not the order recommended in the instructions. So now with CPU 0.1 and DSP 0.2 the reception is much better than yesterday. But CPU 0.1 still has a tendency to stop on a transmission but not pick up on the audio for several seconds even on stronger signals - worse than with CPU 1.0 and DSP 0.2. (I hope what I said makes sense)

I then tried increasing the noise threshold to 60 from 20 - no improvement noticed, but no degradation either.

In any case, the problems I had yesterday are much improved today, although I am not sure why. Any thoughts or suggestions appreciated. I'll continue observing with CPU0.1 and DSP 0.2 and see how it goes.

EDIT 1 - I was using WIN 500 to upload so maybe this is the unknown factor (As just posted by Don Starr)

EDIT 2 - WIN 500 corruption was not my problem. i have discovered that earlier in the day I get better reception on distant signals (higher humidity?). When my reception is better the upgrades work OK, but as the distant signal gets weaker the upgrades do not work. I found that the CC decode rate for the distant transmitter site went from >85% when I first posted this morning to 45% to 85% and highly variable about 3 hors later. This was all with CPU 0.1 & DSP 0.2. So I reverted to CPU 1.0 but kept DSP 0.2 with essentially no improvement.

Next I reverted to DSP 1.0, so now with CPU 1.0 and DSP 1.0, I am receiving all transmissions. Decode rate on the same distant site is now consistently 85% - 95% where befor it was highly variable and inconsistent.

My conclusion is that DSP 1.0 and CPU 1.0 do a much better job of decoding weak control channels and thus don't miss the transmissions that DSP 0.2 and CPU 1.0 do.

Dave

 

[mikey60]

No, I did not. I calculated that my inept stumbling through further changes might only muddy the waters enough that getting back to the status quo ante might be a nightmare. I've thought of staying with CPU 1.0 and updating to DSP 0.2, but my thought was that since the StL PD 800 mHz Motorola system was analog and not digital there might not be much (if any) advantage to doing so. What I'm looking for is a "tweak" that might improve that quarter to half second delay in the audio after the radio stops on a talkgroup - a phenomenon that may also be present (though not so apparent) on conventional channels as well.

If a high percentage of what you are listening to is analog, you could try reducing the HD2 Qual DG setting in the PGM-FUNC-GLOB menu. The default setting is 100 (x 10ms) . If I understand this setting correctly, this is how long the radio waits to detect a digital signal before unmuting in analog mode.

Mike

 

[DaveIN]

Please read this post it could solve some of the tracking issues:
http://www.radioreference.com/forums/showthread.php?p=645232#post645232

 

[thewenk]

I have edited my previous post with this info but I am also posting it here since I think I now somewhat understand the basic problem I have been having with this upgrade.

First of all - WIN 500 corruption was not my problem.

I have discovered that earlier in the day I get better reception on distant signals (higher humidity?). When my reception is better the upgrades work OK, but as the distant signal gets weaker the upgrades do not work. I found that the CC decode rate for the distant transmitter site went from consistently >85% when I first posted this morning (new firmware working OK) to 45% to 85% and highly variable about 3 hors later and not OK. This was all with CPU 0.1 & DSP 0.2. So I reverted to CPU 1.0 but kept DSP 0.2 with essentially no improvement.

Next I reverted to DSP 1.0, so now with CPU 1.0 and DSP 1.0, I am receiving all transmissions. Decode rate on the same distant site is now consistently 85% - 95% where before it was highly variable and inconsistent.

My conclusion is that DSP 1.0 and CPU 1.0 do a much better job of decoding weak control channels and thus don't miss the weaker transmissions that DSP 0.2 and CPU 1.0 do.

Dave

 

[rvawatch]

for me:

stat works now!! yay! it even works when i revert back to the old dsp and cpu... i even reset the entire scanner and load the system and stat works. i swear it didnt work before i ever loaded the updates.. nonetheless tho, it works... anyone else notice this?

i think cpu .1 has helped with the overall sound of digital and making the stat setting work.


with dsp .1 (practically same thing as .2) my overall signal of the STARS P25 system went downhill massively. when i picked it up, it seemed fine, but i could no longer get a signal in this room, nor many places while driving.

so all in all here im prbly keeping the cpu upgrade, but staying with the old dsp.

 

[Statevillian]

I never tried Win500 the VC DG ID wobble was there all along. Been experimenting. Too early to comment except that I was able to pick up a rare I call on a local EDACS system on the 396 but on the 500 I would get the brief audio of the squelch on the front end and then no audio. The pvt display would stay mute and either lock on or move on during the middle of the I call on the 396.

I dumped the dsp back to 1.0 but kept the cpu at the new firmware state and I will keep trying with that...taking lots of notes.

 

[SCPD]

If a high percentage of what you are listening to is analog, you could try reducing the HD2 Qual DG setting in the PGM-FUNC-GLOB menu. The default setting is 100 (x 10ms) . If I understand this setting correctly, this is how long the radio waits to detect a digital signal before unmuting in analog mode.

Mike

The setting to reduce audio delay if you are primarily listening to analog is PGM, Func-Glob, "DG Int Prime". If you made that setting lower you will get faster unmute on analog at the risk of more DG "braaping". It is interesting to experiment with.

 

[SCPD]

I was about to try this suggestion. In my previous post I had stated that I had reverted back to DSP 1.0 from 0.1 and kept CPU 0.1 and my reception problems on Idaho 700 MHz P25 were fixed. Later I also reverted back to CPU 1.0.

So today I reloaded DSP 0.2 with CPU 1.0 to try the above suggestion. And lo and behold reception seemed really good with CPU 1.0 and DSP 0.2--none, or at least very few of the problems I had before.

So, could it be the combination of CPU 0.1 and DSP 0.1 or 0.2 and not just the DSP upgrade??

Next I loaded CPU 0.1 -- not the order recommended in the instructions. So now with CPU 0.1 and DSP 0.2 the reception is much better than yesterday. But CPU 0.1 still has a tendency to stop on a transmission but not pick up on the audio for several seconds even on stronger signals - worse than with CPU 1.0 and DSP 0.2. (I hope what I said makes sense)

I then tried increasing the noise threshold to 60 from 20 - no improvement noticed, but no degradation either.

In any case, the problems I had yesterday are much improved today, although I am not sure why. Any thoughts or suggestions appreciated. I'll continue observing with CPU0.1 and DSP 0.2 and see how it goes.

EDIT 1 - I was using WIN 500 to upload so maybe this is the unknown factor (As just posted by Don Starr)

EDIT 2 - WIN 500 corruption was not my problem. i have discovered that earlier in the day I get better reception on distant signals (higher humidity?). When my reception is better the upgrades work OK, but as the distant signal gets weaker the upgrades do not work. I found that the CC decode rate for the distant transmitter site went from >85% when I first posted this morning to 45% to 85% and highly variable about 3 hors later. This was all with CPU 0.1 & DSP 0.2. So I reverted to CPU 1.0 but kept DSP 0.2 with essentially no improvement.

Next I reverted to DSP 1.0, so now with CPU 1.0 and DSP 1.0, I am receiving all transmissions. Decode rate on the same distant site is now consistently 85% - 95% where befor it was highly variable and inconsistent.

My conclusion is that DSP 1.0 and CPU 1.0 do a much better job of decoding weak control channels and thus don't miss the transmissions that DSP 0.2 and CPU 1.0 do.

Dave

I think you have good notes.

What is interesting is that you are getting variable results depending on time. Signals do change by time of day and even time of year (leaves, no leaves). In any case it seems that when conditions are good that you prefer CPU 0.1 and DSP 0.2?

 

[mikey60]

The setting to reduce audio delay if you are primarily listening to analog is PGM, Func-Glob, "DG Int Prime". If you made that setting lower you will get faster unmute on analog at the risk of more DG "braaping". It is interesting to experiment with.

Yep, My mistake. I figured that out later, but wasn't able to post the correction...

Mike