PSR-500 Failure to Track P-25 Systems Thread

[KC9NEG]

Did GRE update the U01 releases to fix the V-Scanner renumbering issue? I see "modified" dates of 7:30 this morning for both CPU and DSP.

EDIT: Oops wrong thread--mod's please feel free to move.

EDIT: I see now "modified" has changed to 7:45 so maybe there's some automatic process in place--makes me doubt the files have changed.

Todd/Indy

 

[djg000111]

Please come to Macomb County Michigan

My experience with the CPU and DSP beta upgrade is almost identical to Russell's experience in Austin TX. The P25 in Macomb County is CQPSK and is listed in the RR data base as Macomb County Simulcast. My local fire and police use this system along with county sheriff and other county, township, and city agencies.

The main difference between Russell's and my experience is that my Pro-2096 receives better than the PSR-500 with the beta upgrade. The PSR-500 is very sensitive to location and receives very poorly when walking with the unit.

The beta upgrade is a big improvement but my Pro-2096 is still a better P25 receiver.

 

[detroit780]

P25

P25 Auto
Attenuator off 800MHz Radio Shack rubber duck
Super track on
Multi site Stat

I'll try global Attn on and off on the way home tonight.

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?

 

[fmon]

Fixed M36 mixed analog/digital system and improved STARS

Loaded both CPU and DSP upgrade, very little change on VA STARS. Reverted back to CPU F1.0 and found improvement on STARS.

However, what a difference DSP U0.1 made on this M36 mixed analog/digital system http://www.radioreference.com/modules.php?name=RR&sid=179 . Most of the digital was hit and miss before (more miss). This DSP fixed the problem, works perfect.

 

[SCPD]

DSP Upgrade U0.2 is out

Looks like DSP U0.2 is out. The release note is:

DSP Beta Firmware - U.02
- Fix V-Folder numbering error on U0.1, otherwise identical to U0.1

http://www.greamerica.com/support/

 

[bonus1331]

Haven't had a chance to download yet due to work.
Guess I was asking to much for all responses to come back as "WOW".
Really concerned now that certain posters are saying that they reverted the CPU upgrade back to original, while upgrading the DSP.
For those of us new to the RS/GRE scanner upgrades-can anyone explain the difference between upgrading the CPU and DSP, besides the definition of CPU and DSP.
Assumption-the DSP only has to do with decoding digital while the CPU has to do more with the overall aspect of the scanners functions?

 

[fmon]

We have a hot scanner down here in SE Virginia

Haven't had a chance to download yet due to work.
Guess I was asking to much for all responses to come back as "WOW".

It's a wow!

Really concerned now that certain posters are saying that they reverted the CPU upgrade back to original, while upgrading the DSP.

I'm one of them, DSP U0.1 fixed a terrible M36 system completely, and after trying VA STARS only while walking to my voting booth and back, ( 2 miles round trip) it appears to be much much much better.

For those of us new to the RS/GRE scanner upgrades-can anyone explain the difference between upgrading the CPU and DSP, besides the definition of CPU and DSP.

Push different buttons for each. Instructions are in the upgrade dialogs similar to the 20(96).

Assumption-the DSP only has to do with decoding digital while the CPU has to do more with the overall aspect of the scanners functions?

I think the CPU change puts the scanner in the same configuration as some of the beta scanners.

BTW, DSP U0.2 surely fixed the V-folder issue.

 

[KC9NEG]

OT: I walked 2mi to vote today, too.

Todd/Indy

 

[rdballenger]

page 90 of the manual explains the power-ups you need to do before you start the upgrade - there are different ones for the CPU and the DSP

 

[rvawatch]

fmon: why did you end up reverting to the older cpu? what negatives did you notice you were getting with it? it might just be me, but i feel like i lost sensativity on STARS with the upgrades. It works okay with ROAM, but can't pick up anything at all with STAT. (stat never worked well before the upgrades either) The STAT feature works greeat on the local 800 dig system tho...

i do think that the upgrade is a major improvement overall. I love the stat feature. im picking up tgs that i normally dont hear locked onto just one cc.

 

[DonS]

fmon: why did you end up reverting to the older cpu? what negatives did you notice you were getting with it? it might just be me, but i feel like i lost sensativity on STARS with the upgrades. It works okay with ROAM, but can't pick up anything at all with STAT. (stat never worked well before the upgrades either) The STAT feature works greeat on the local 800 dig system tho...

i do think that the upgrade is a major improvement overall. I love the stat feature. im picking up tgs that i normally dont hear locked onto just one cc.

This may be obvious, but keep in mind that MultiSite=Stat causes the radio to go through every frequency you have programmed into the TSYS, one at a time, looking for CC data. If only CCs are opening squelch, it should spend about 1 second on each (or whatever you've set the TSYS's dwell time to). If you have additional frequencies in the TSYS, like VCs that are opening squelch, it could make the radio take a _very_ long time to get through the whole list of freqs - and that would likely result in missing calls. (This would probably also happen if RF SQ opened for inactive CC freqs, like if the SQ knob was too far CCW).

 

[rvawatch]

This may be obvious, but keep in mind that MultiSite=Stat causes the radio to go through every frequency you have programmed into the TSYS, one at a time, looking for CC data. If only CCs are opening squelch, it should spend about 1 second on each (or whatever you've set the TSYS's dwell time to). If you have additional frequencies in the TSYS, like VCs that are opening squelch, it could make the radio take a _very_ long time to get through the whole list of freqs - and that would likely result in missing calls. (This would probably also happen if RF SQ opened for inactive CC freqs, like if the SQ knob was too far CCW).

hmm.. i know thats how stat works, but i guess i didnt really think of it as the problem. that makes sense tho. i had all sites' primary cc programmed, so that would take alot of scanning time. if many sites like that are programmed, then roam probably would be good. for my local 800 mhz system, some tgs for a different county are not always associated with the closest site, so for those stat would probably be best (3 primary cc). i could then set the tgs that are for my county to roam, which would lock onto my county's site, and would work fine since the local tgs are obviously affiliated with the local site. <-- this all sound right??

what difference did you notice specifically between cpu 1 and .1?

 

[fmon]

fmon: why did you end up reverting to the older cpu? what negatives did you notice you were getting with it? it might just be me, but i feel like i lost sensativity on STARS with the upgrades.

Didn't receive T quit as well. I also lost the Chesapeake M36 system voice traffic altogather. However, that turned out to be my DA mistake...I'd tried the 800 tables (unsuccesfully) for it yesterday then tried (unsuccesfully again) splinter but forgot to change it back. Changed setting back after going back to CPU F1.0 and left in DSP U0.1. Chesapeake is fixed. STARS is nearly perfect.

It works okay with ROAM, but can't pick up anything at all with STAT. (stat never worked well before the upgrades either) The STAT feature works greeat on the local 800 dig system tho...

Don answered the STAT but I use Off while sitting here or in the area because I have 28 freqs listed in the TSYS. If I go traveling, I'll change to ROAM.

i do think that the upgrade is a major improvement overall. I love the stat feature. im picking up tgs that i normally dont hear locked onto just one cc.

I used STAT when only two freqs were in the list. My thoughts are the DSP upgrade is a great improvement. Waiting for Lynn's input on his York/JCC 800 P25 system. Don't get the T very well down here.

Also, gotta get use to the Att button for STARS, when sitting here at PC, needs to be on, when walking outside, needs to be off.

 

[DonS]

hmm.. i know thats how stat works, but i guess i didnt really think of it as the problem. that makes sense tho. i had all sites' primary cc programmed, so that would take alot of scanning time. if many sites like that are programmed, then roam probably would be good. for my local 800 mhz system, some tgs for a different county are not always associated with the closest site, so for those stat would probably be best (3 primary cc). i could then set the tgs that are for my county to roam, which would lock onto my county's site, and would work fine since the local tgs are obviously affiliated with the local site. <-- this all sound right??

If I'm understanding you correctly, you'd want some TGRPs to "roam", while others are set to "state". If so, you'd need multiple TSYS objects for that. Sounds like it might work, though.

what difference did you notice specifically between cpu 1 and .1?

Mostly, I noticed better acquisition of the CC if I didn't have the SQ knob set correctly.

 

[LEH]

Frank,

Sorry, I put it out there somewhere, probably in the GRE firmware thread.

Anyway, York/JCC/Williamsburg is actually working. I like it, I like it.

I really haven't played that much with it today. Been busy with work and looking to see what the scanner is doing was distracting.

I'm still having issues with STARS though. Not sure what (beyond the MOT VHF/UHF setting) is the problem. Though it seems to be locking on okay now.

Even Newport News is behaving better. I'd lose the occasional transmission. Didn't seem to be doing that, but again, I'm not watching the scanner that closely right now.

 

[DaveIN]

I'm glad to hear most everyone is having good luck with the CPU and DSP firmware updates.

 

[detroit780]

Upgrade

Seems to miss many more talk groups with the upgrades. I tried the global attenuator and that about killed the performance. Then I went back to the original CPU firmware with the new DSP and attenuator off.

It seems to be a tad better than the original DSP now but not 100%. This is at home with only one control channel in the SYS. I'll try the my work v-folder tomorrow on the way to work and from work, it has all 32 slots filled and about 6 towers to roll through on the way.

Michigan APCO-25 system. I'll also check the analog Oakland County system that had trouble with the 2 upgrades this morning to see if it was the CPU upgrade or both.

P25 Auto
Attenuator off 800MHz Radio Shack rubber duck
Super track on
Multi site Stat

I'll try global Attn on and off on the way home tonight.

 

[rvawatch]

Didn't receive T quit as well. I also lost the Chesapeake M36 system voice traffic altogather. However, that turned out to be my DA mistake...I'd tried the 800 tables (unsuccesfully) for it yesterday then tried (unsuccesfully again) splinter but forgot to change it back. Changed setting back after going back to CPU F1.0 and left in DSP U0.1. Chesapeake is fixed. STARS is nearly perfect. Don answered the STAT but I use Off while sitting here or in the area because I have 28 freqs listed in the TSYS. If I go traveling, I'll change to ROAM. I used STAT when only two freqs were in the list. My thoughts are the DSP upgrade is a great improvement. Waiting for Lynn's input on his York/JCC 800 P25 system. Don't get the T very well down here.

Also, gotta get use to the Att button for STARS, when sitting here at PC, needs to be on, when walking outside, needs to be off.

id be curious to see how chesapeake works with the newer cpu (and the correct tables of course lol) ..unless you did test that and im just misreading. ill play with stars here and see which one does best for me.

 

[rvawatch]

If I'm understanding you correctly, you'd want some TGRPs to "roam", while others are set to "state". If so, you'd need multiple TSYS objects for that. Sounds like it might work, though.


Mostly, I noticed better acquisition of the CC if I didn't have the SQ knob set correctly.

yes thats what i meant. details below:

for my discussion right now, i am only talking about scanning this one system http://www.radioreference.com/modules.php?name=RR&sid=556. its a smartzone system, so each of the 3 counties has its own site and cc, but they can affiliate with eachother (not all tgs tho). depending on where i am, i can pick up all three sites. i can pick up the local one much better tho, obviously. so for my local tgs, id have a system with the 3 cc set to roam (off would work too with just the one cc, but you get the drift) and for the other counties' tgs, i would have a system with the 3 cc set to stat.

my reasoning for this: when i want to listen to just local (most of the time), i can just turn on that scanlist, which then will just scan the local cc and i get 100% of the traffic (theoretically). if im bored and want to hear crazy stuff going on elsewhere, i can turn on those scanlists and scan all 3 cc set to stat so that as long as i have good reception, i hear 100% of the traffic (theoretically). if i am only getting reception from the local site, then i can at least hear the other counties' tgs that are affiliated with the local site at that time.

the reason for not using the same sys (3 cc set to stat) for all tgs in the counties is because if i am just scanning for local tgs, first: i could miss traffic on the local site while the scanner is scanning the distant sites, and second: a local tg that i could easily pick up on the local site might go active while scanning a distant site that it is also affiliated with causing the tg traffic to be heard from the distant site rather than the local site (which depending on my location, could cause machine gunning, poor sound, etc, from not having a strong signal) which would have been eliminated altogether if i had just been set to roam.

the only problems i can really think of tho:

first: if i am in one of the other counties and really wanted to listen to back home for some reason, i would be set to roam, therefore only scanning what was affiliated with the current cc at that time (which i can easily change to stat, however.)

second: if i am scanning all the talkgroups, then i would be scanning through two sys objects in the scanner. one of them being all cc set to stat, and the other all cc set to roam. which i guess would create the delimna for me of which is better: scanning all tgs through two sys objects at a time (taking more time), or scanning all tgs with one sys set to stat (creating the possible lack of signal problem above).



okay i know thats alooot but i think many other systems out there are similar to mine (york, jcc one i think), and we havent had this issue to deal with before in scanners (except maybe the 996t? i dunno i dont have one). so maybe this will jog some ideas for others and they can post too.

ok i think i gave myself a headache thinking so much.

AC

 

[SCPD]

Assumption-the DSP only has to do with decoding digital while the CPU has to do more with the overall aspect of the scanners functions?

Exactly.