PSR-500 Failure to Track P-25 Systems Thread

[LEH]

Actually, I was okay with 'firmware' upgrade. I've been around long enough to see firmware migrate from a hard wired piece of equipment to the programming code that makes that piece work.

What threw me was seeing a 'firmware upgrade' followed immediately by a 'correspondeing CPU upgrade'. Now I'm thinking hardware (the actual CPU) AND software (the firmware). Oh well, I'll leave this lie now that I have confused the whole thing.

 

[SCPD]

Firmware upgrades.

Actually, I was okay with 'firmware' upgrade. I've been around long enough to see firmware migrate from a hard wired piece of equipment to the programming code that makes that piece work.

What threw me was seeing a 'firmware upgrade' followed immediately by a 'correspondeing CPU upgrade'. Now I'm thinking hardware (the actual CPU) AND software (the firmware). Oh well, I'll leave this lie now that I have confused the whole thing.

My thought has always been if software is stored within a non-volatile chip (OTP, EPROM, EEPROM, Flash etc.) that it is called "firmware". In the case of the PSR-300/400/500/600, I hear the storage method is "flash".

Sorry for any confusion - there is no soldering to upgrade the CPU or DSP (500/600 only) firmware within the above mentioned radios.

 

[bonus1331]

Looks like the firmware has been released on the GRE support site.....

Edit, looks like a firmware date of 9/3/07. Looks like it may possibly be the original loaded firmware.
Maybe prepping for new firmware download

 

[DaveIN]

No that is the original CPU firmware: CPU Firmware 1.0 - Release Date 09/03/2007

Unless you see something else?

 

[SCPD]

My thought has always been if software is stored within a non-volatile chip (OTP, EPROM, EEPROM, Flash etc.) that it is called "firmware". In the case of the PSR-300/400/500/600, I hear the storage method is "flash".

Sorry for any confusion - there is no soldering to upgrade the CPU or DSP (500/600 only) firmware within the above mentioned radios.

"As we all wait with baited breath" I am too!

 

[detroit780]

CPU Update

Yes it says version 1.0 9-03-07 but the description says modified 11-05-07. I downloaded it and installed it and will see if does anything different. Strange they would post the original.

No that is the original CPU firmware: CPU Firmware 1.0 - Release Date 09/03/2007

Unless you see something else?

 

[NYG]

They might be posting the original firmware so people can revert back to it if need be.

Anyway I thought we were waiting on new DSP code with CPU code to arrive a little later.

 

[kikito]

They might be posting the original firmware so people can revert back to it if need be.

Anyway I thought we were waiting on new DSP code with CPU code to arrive a little later.

Yep, that's the smartest thing they could do, post the original firmware and hopefully leave almost every version that comes out thereafter available.

Maybe they posted the CPU firmware in case someone messes up the radio by updating the CPU with the DSP firmware.

The reason I say (or joke about) that is because as you guys may know, there's different modes you put the radio in, depending on what you're updating, manual page 90.

 

[DonS]

Yep, that's the smartest thing they could do, post the original firmware and hopefully leave almost every version that comes out thereafter available.

Maybe they posted the CPU firmware in case someone messes up the radio by updating the CPU with the DSP firmware.

The reason I say (or joke about) that is because as you guys may know, there's different modes you put the radio in, depending on what you're updating, manual page 90.

I'll bet it's impossible to load DSP code into the CPU, and vice-versa. That is, it won't crash the radio - you just won't get that far into the update process.

 

[kikito]

I'll bet it's impossible to load DSP code into the CPU, and vice-versa. That is, it won't crash the radio - you just won't get that far into the update process.

That is good to know and it'll save GRE a lot of headaches!!!

 

[detroit780]

CPU update

Well if nothing else it is a good test, the orignal CPU firmware installed without a hitch using Vista Home Premium. So it should be a piece of cake once the real update is posted. Now that we have a back up of the original we are ready for the next step.

I'll bet it's impossible to load DSP code into the CPU, and vice-versa. That is, it won't crash the radio - you just won't get that far into the update process.

 

[kikito]

They might be posting the original firmware so people can revert back to it if need be.

Anyway I thought we were waiting on new DSP code with CPU code to arrive a little later.

One thing I forgot to add related to this is, you can always revert to the factory DSP firmware easily since it's built-in the radio (page 90). Don't think it's possible for the CPU.

 

[DaveIN]

0, CLR Erases DSP APP Upgrade code, restores factory DSP version.

 

[mikeh]

i will wait on the frimware

i will wait on the frimware
till i see what it changes and if it works well

 

[mikeh]

what will the frimware update do.

what will the frimware update do.

 

[mikeh]

to everyone i found it

Bulletin Release - 11/05/2007 -

GRE - A beta release of PSR-500 CPU and DSP Firmware has been released. Please be advised that this is a Beta Release only. We would like to get as much feedback as possible to help us find any know issues before an official Firmware update is released. Your feedback and support would greatly appreciated.

"CPU500_U01" (Beta) Release Note Fixes.

-Fixed: EDACS will no longer trunk to encrypted (Pro-Voice) calls

-Fixed: Properly display SiteID for M36 in trunking analysis mode (SiteID was
previously one too low in number)

-Fixed: Pressing ATT at power-up, changing the setting, then saving will now
preserve the new value

-Fixed: P25 dwell timeout when not holding/paused

-Fixed: Mot3600 CC dwell timeout when receiving RF SQ but no CC messages

-Fixed: RF Squelch timers on CCs. Should fix cases where CC could not be
found

-Fixed: Monitoring of DG signals in Tune mode (would pulse the audio every
few seconds)

-Improved: Unmuting on start of DG calls

-Improved: Less falsing of Mot subaudible detect in Tune mode

-Fixed: When paused while scanning, better handle changing CCs

-Improved: PC/IF remote control presents the radio's speaker mute state
within more real time

"DSP500_U01" (Beta) Release Note Fixes.
- Improve P25 DG decoding on all system types

Please download the Beta Release Firmware at: http://www.greamerica.com/support

- The GRE Development Team -

 

[Russell]

Dear GRE,

Please come to Austin.

While the BETA CPU/DSP upgrades seems to receive markedly better the radio still suffers from slightly better than mediocre decoding of the Austin/Travis County P25 system (9600 P25 CAI Exclusive using CQPSK on 800MHz). This radio is leaps and bounds better then the Pro96, but still suffers from some of the same DSP problems. The tracking problems are less severe (the T tends to stay on more).

Where the Pro96 did tons of "motorboating" and decoded about 30-50% of the time, the PSR500 does no motorboating (it seems to mute if it can't decode). Audio recovery is very good, but not great. It seems like once it gets a good "grip" on the freq and begins to decode all is usually well but getting the "grip" is sometimes elusive. I have less experience with the Uniden models, but the 396 does a similar thing (mutes if it can't decode).

Do not misunderstand, this is an excellent radio. I am ready to sell all the others because I simply don't use them anymore. Apparently, CQPSK presents special problems and is much harder to decode. Texas DPS digital (CPSK) is clearly decoded at nearly 100%, the Austin system is choppy (sometimes very choppy). The PSR500 does a good job and the upgrades seem to help, but again, like the Pro96 there are times when the radio simply can't get the job done. On the Pro96 I would just turn it off; on the PSR500 I just miss parts of the transmissions. This is the best scanner ever made, but it is still frustrating not being able to clearly copy the audio.

At this time, with the beta CPU and DSP upgrades the scanner still bounces between VC and DG on the voice channels. It displays the TG (and alpha tag), I see VC and the freq but it sometimes it won't switch to DG and decode the audio. This also seems to be affected by location. In the bad location switching between the ducky and the outside antenna does not help. This would seem to indicate that the radio is being overdriven. Turning on the attenuator appears to help at times, but at others times results in no audio at all. Results are very inconsistent. In the "good" location the ducky is sufficient but still mutes the audio in the middle of a transmission.

I've traveled extensively over the years and have monitored the Colorado DTRS P25, San Mateo P25 UHF, San Francisco P25, Ohio MARCS P25 among others and I find Austin's system is, by far, the most difficult system I've monitored (decoding voice-wise). If you can nail this one down then you've probably solved your problems on many other systems.

Russell

 

[detroit780]

Firmware Update

I downloaded the CPU and DSP ugrades this morning so I could evaluate them on the 1 hour drive in to work.

What I noticed:

Once I reach the halfway point I switch over to my work V-Folder. It was not in V-Folder 01 in fact there was nothing there. Nothing in the first 6 V-Folders. It seems my home folder is now in position 00 and my work folder is in 01 and so on.

The radio still lights up the LED and sits on a TG with no Audio. I did notice it was only breifly so it may be stopping at the tail end of a transmission I won't know till I get home and turn on the 2096 to compare. Sometimes it will stop and in the middle of no audio dispatch may say something like affirmative yada yada yada making me think perhaps the issue is fixed and it stops on the TG just as the conversation ends.

Analog trunked systems like the Oakland County system in Michigan now has the same issue, stopping on a TG with not audio. The radio never did this before analog transmissions were always right on, no missing audio. Again it seems it may be stopping at the end of a transmission once I compare this I will know. If that is the case, I'm happy with that and I know I won't miss anything.

So before I jump the gun and say it's fixed or not fixed I'll just report my initial observations here. It does seem better.

Regardless, thanks GRE for working on this and posting the Beta updates so quickly. At least it gives us something to play with and hopefully lots of data so you can further fine tune this awesome little radio.

Bulletin Release - 11/05/2007 -

GRE - A beta release of PSR-500 CPU and DSP Firmware has been released. Please be advised that this is a Beta Release only. We would like to get as much feedback as possible to help us find any know issues before an official Firmware update is released. Your feedback and support would greatly appreciated.

"CPU500_U01" (Beta) Release Note Fixes.

-Fixed: EDACS will no longer trunk to encrypted (Pro-Voice) calls

-Fixed: Properly display SiteID for M36 in trunking analysis mode (SiteID was
previously one too low in number)

-Fixed: Pressing ATT at power-up, changing the setting, then saving will now
preserve the new value

-Fixed: P25 dwell timeout when not holding/paused

-Fixed: Mot3600 CC dwell timeout when receiving RF SQ but no CC messages

-Fixed: RF Squelch timers on CCs. Should fix cases where CC could not be
found

-Fixed: Monitoring of DG signals in Tune mode (would pulse the audio every
few seconds)

-Improved: Unmuting on start of DG calls

-Improved: Less falsing of Mot subaudible detect in Tune mode

-Fixed: When paused while scanning, better handle changing CCs

-Improved: PC/IF remote control presents the radio's speaker mute state
within more real time

"DSP500_U01" (Beta) Release Note Fixes.
- Improve P25 DG decoding on all system types

Please download the Beta Release Firmware at: http://www.greamerica.com/support

- The GRE Development Team -

 

[DaveIN]

Turning on the attenuator appears to help at times, but at others times results in no audio at all. Results are very inconsistent. In the "good" location the ducky is sufficient but still mutes the audio in the middle of a transmission.

Detroit and Russell: Turning on the attenuator with the external antenna helps, or turning on the attenuator with the stock ducky helps?

What other settings are you using? Default global settings? Did you reset your global settings to the default?

 

[Statevillian]

First Impressions this morning

Dear GRE,

Please come to Austin.

While the BETA CPU/DSP upgrades seems to receive markedly better the radio still suffers from slightly better than mediocre decoding of the Austin/Travis County P25 system (9600 P25 CAI Exclusive using CQPSK on 800MHz). This radio is leaps and bounds better then the Pro96, but still suffers from some of the same DSP problems. The tracking problems are less severe (the T tends to stay on more).

Where the Pro96 did tons of "motorboating" and decoded about 30-50% of the time, the PSR500 does no motorboating (it seems to mute if it can't decode). Audio recovery is very good, but not great. It seems like once it gets a good "grip" on the freq and begins to decode all is usually well but getting the "grip" is sometimes elusive. I have less experience with the Uniden models, but the 396 does a similar thing (mutes if it can't decode).

Do not misunderstand, this is an excellent radio. I am ready to sell all the others because I simply don't use them anymore. Apparently, CQPSK presents special problems and is much harder to decode. Texas DPS digital (CPSK) is clearly decoded at nearly 100%, the Austin system is choppy (sometimes very choppy). The PSR500 does a good job and the upgrades seem to help, but again, like the Pro96 there are times when the radio simply can't get the job done. On the Pro96 I would just turn it off; on the PSR500 I just miss parts of the transmissions. This is the best scanner ever made, but it is still frustrating not being able to clearly copy the audio.

At this time, with the beta CPU and DSP upgrades the scanner still bounces between VC and DG on the voice channels. It displays the TG (and alpha tag), I see VC and the freq but it sometimes it won't switch to DG and decode the audio. This also seems to be affected by location. In the bad location switching between the ducky and the outside antenna does not help. This would seem to indicate that the radio is being overdriven. Turning on the attenuator appears to help at times, but at others times results in no audio at all. Results are very inconsistent. In the "good" location the ducky is sufficient but still mutes the audio in the middle of a transmission.

I've traveled extensively over the years and have monitored the Colorado DTRS P25, San Mateo P25 UHF, San Francisco P25, Ohio MARCS P25 among others and I find Austin's system is, by far, the most difficult system I've monitored (decoding voice-wise). If you can nail this one down then you've probably solved your problems on many other systems.

Russell

I concur in the short term. It seemed to have no problem that I could detect last night....many miles from tower site on Starcom21 700/800Mhz P25 system. Everything posted by Russ is true of Starcom still. I need to go back and put the various towers in scanlists and have wildcard entries only and see how that does. More later.