PSR-500 Failure to Track P-25 Systems Thread

[mikey60]

well for a p25 system here...petersburg trs, the only way i can get it to work is P25 Manual: Default. PSREDIT wont let me set it like that, so everytime i have to go in the scanner and set it manually. Setting it for P25 auto never works for me, altho someone who beta tested said that is what they used. so i dunno.

Oops, now that I re-read your message, I see what you're talking about. I'll fix this right now for the next release.

Mike

 

[mikey60]

Hi Mike; You are correct it changed to 4095! But it still must be set to "P25 Auto" with the "Trunking Tables" set to my Base and Offset. If I use "P25 Custom" it won't track! Let me know if you still want the CC Dump. Thanks, Bill

The correct settings would be:

Type: P25 Manual
T Tables: Custom
Then set table 0 to your base and offsets.

Mike

 

[LEH]

Well I tried the York/JCC/Williamsburg system wth the Parma settings as well. Set the TSYS to P25Manual and the table to custom (doing this manually, not with software).

When I set the custom table, the system quit working entirely. It would stop, but the frequency shown was 894.0000 MHz and no talk group. The system also showed VC rather than the DG.

When I changed the P25 from Manual to Auto, my custom table did revert back to the values passed by the system (hi channel 4095).

I changed the scanner back to P25 Manual and set the Hi channel to 65535. I am receiving, but I do not see any appreciable improvement in the tracking.

start
p25autol lo 0 high 4095 base 851.00625 offsett 0 step 6.25
change 1
p25Manual lo 0 high 65535 base 851.0125 offset 0 step 12.5
change 2
p25Auto lo 0 high 65535 base 851.0125 offset 0 step 12.5
These all reverted to the start settings.
change 3
p25manual lo 0 high 65535 base 851.00625 offset 0 step 6.25
reception here is really no different than with the start (P25 Auto) setting.

 

[fmon]

If you set it as P25 AUTO, T Tables: Custom, then entered your own data, but the data later changed to your above, that indicates to me that the system is sending out invalid IDEN_UP information. If that's the case, you'd have to use P25 MANUAL, to keep the radio from using the IDEN_UP data to overwrite your custom T Tables.

With either P25 type (AUTO or MANUAL), the IDEN_UP data should appear on the PC/IF port if you have "CCDump" set to Yes in the FUNC+GLOB menu.

Yup it was P25 AUTO, changed to MANUAL and settings hold.

Trying it in STARS VHF P25 also with the base set as 136.0000 and step at 2.50.

On the 800 P25 system I'm getting false freq 142.5000 with TG displayed but no voice.

On VHF P25 system I'm also getting false freqs in the 17x.xxxx range but getting some voice. However, correct talkgroup is displayed with or without voice.

Scratching All in all, both systems work better befor these test settings...going to another dug out, maybe the BoSox.

 

[DonS]

If the system sends out good IDEN_UP packets, then P25 AUTO will work (the "T Tables" item is irrelevant).

If the system doesn't send out good IDEN_UP packets (either it doesn't send them, or the ones it sends are wrong or incomplete), you have to use P25 MANUAL. Then, if the system uses "standard" P25 trunking tables, you can use "T Tables: Default". Otherwise, you have to use "T Tables: Custom" and set your own table entries.

Clear as mud?


EDIT: For P25 AUTO, it doesn't look like the radio will trunk out to VCs until it actually starts populating the trunking tables via IDEN_UP. I suppose this makes sense, as it doesn't know how to calculate a voice frequency until the IDEN_UP messages are received. Of course, you could "pre-populate" the trunking tables with known values, then let the radio update them from IDEN_UP.

 

[kikito]

Yup it was P25 AUTO, changed to MANUAL and settings hold.

Trying it in STARS VHF P25 also with the base set as 136.0000 and step at 2.50.

On the 800 P25 system I'm getting false freq 142.5000 with TG displayed but no voice.

On VHF P25 system I'm also getting false freqs in the 17x.xxxx range but getting some voice. However, correct talkgroup is displayed with or without voice.

Scratching All in all, both systems work better befor these test settings...going to another dug out, maybe the BoSox.

Frank,

So you're having trouble with the PSR-500 tracking the STARS system?

I wonder what's different in you guys' system because as far as I know, STARS was almost identical to our ALMR and ours tracks fine from day one with P25 AUTO. Other than your system is a few MHz lower and higher in the frequencies, what else could be different? In fact, STARS even uses the default stepping in their frequencies whereas in ours, having the "odd" stepping and with the Flexstep option turned off, it still works with the frequencies being off +/- 2.5kHz.

BTW, Initially and in my case, my main problem was being caused by the STAT setting.

 

[kikito]

EDIT: For P25 AUTO, it doesn't look like the radio will trunk out to VCs until it actually starts populating the trunking tables via IDEN_UP. I suppose this makes sense, as it doesn't know how to calculate a voice frequency until the IDEN_UP messages are received. Of course, you could "pre-populate" the trunking tables with known values, then let the radio update them from IDEN_UP.

BTW, I was wondering how long does the radio take to "populate" the tables? It's probably within a few seconds I would guess....

 

[DonS]

BTW, I was wondering how long does the radio take to "populate" the tables? It's probably within a few seconds I would guess....

Depends on the system, I'd guess, and how often it sends enough IDEN_UP messages to populate the table for all identifiers used in the system.

Looking at the "CCDump" output should give you some indication of the system's "IDEN_UP cycle time". You'd probably have to program a bogus TGID (one never used on the system), then camp on that TGRP in MAN mode, to keep the radio on the CC without trunking out to VCs.

 

[fmon]

First shot is P25 AUTO T Table: Default and second is p25 MANUAL T Table: Custom. Auto may be slightly better but not much if any.

 

[kikito]

Looking at the "CCDump" output should give you some indication of the system's "IDEN_UP cycle time". You'd probably have to program a bogus TGID (one never used on the system), then camp on that TGRP in MAN mode, to keep the radio on the CC without trunking out to VCs.

I noticed when starting Pro96Com for the first time to track any site, it takes about 2 to 4 seconds to get all 10 tables for our system. Would that be another way to find out?

 

[DonS]

I noticed when starting Pro96Com for the first time to track any site, it takes about 2 to 4 seconds to get all 10 tables for our system. Would that be another way to find out?

It could be. My way, though, should tell you what the radio itself is doing with the data. You should see some kind of text indicating that the radio is actually handling the IDEN_UP info.

 

[fmon]

Frank,

So you're having trouble with the PSR-500 tracking the STARS system?

I wonder what's different in you guys' system because as far as I know, STARS was almost identical to our ALMR and ours tracks fine from day one with P25 AUTO. Other than your system is a few MHz lower and higher in the frequencies, what else could be different? In fact, STARS even uses the default stepping in their frequencies whereas in ours, having the "odd" stepping and with the Flexstep option turned off, it still works with the frequencies being off +/- 2.5kHz.

BTW, Initially and in my case, my main problem was being caused by the STAT setting.

Jose, our system doesn't provide a SysId on line 4 of 96/2096 or on Analyz on this scanner. I believe we still have the same bag of worms. I've tried all Multi-site settings including adjusting the ROAM.

Also, I have tried the two local controls in various locations and still cannot get one of them to ever light off even though it carries nearly the same decode rate.

IOW, there times when all three of my GRE scanners light off with same talkgroup, the 96 on Hampton tower, the 2096 on Chesapeake tower or visa-verse but the 500 is always on the Hampton tower. The 2096 and 500 are both on the same Scantenna through an Electroline cable amp. Hampton tower is closest to my location.

Strangely, when I first turn these scanners on in the am, the 500 appears to kick butt on this system.

Lynn's 800 P25 system is also terrible with this scanner as is neighboring Chesapeake 800 M36 analog/digital system. Both work fine on the 20(96). Three Military UHF M36 100% digital systems work great as do 5 analog Smartnet's plus an 800 EDACS and 800/900 LTR systems.

Works great on conventional and air band all the way up through 390 MHz.

 

[kikito]

Jose, our system doesn't provide a SysId on line 4 of 96/2096 or on Analyz on this scanner.

We have a few of those sites too. And even though it doesn't display the SysId, it still tracks it. In fact, before knowing about the STAT issue, one of those sites was the main one to get locked on to while on STAT mode.

Strangely, when I first turn these scanners on in the am, the 500 appears to kick butt on this system.

I also noticed that too when I have it set to STAT on our system.

I know none of this helps you but thought I put it out there as FYI. Maybe when the upcoming firmware update comes out, it might solve some or all of those problems.

 

[fmon]

I know none of this helps you but thought I put it out there as FYI.

And we are always greatful for your input. You went through our struggles.

Maybe when the upcoming firmware update comes out, it might solve some or all of those problems.

Sure hope it does.

 

[detroit780]

No Audio

I am having trouble with Multi Site off, Roam, and Stat. It doesn't really matter. When driving to work I switch to my MPSCS APCO-25 V Folder with 32 tower sites in Roam mode. The break up of the audio kills me. When home I switch to my V-Folder with just one tower in it and run it with multi site off. At times it works superb but mostly now it just sits there displaying the frequency with the LED on and off. Mostly when the frequency is on the display the audio is fine, when the audio cuts the frequency disappears. Last week I thought it was my TG priority messing it up. Once I turned off all priorities it seemed ok.

My Pro-96 was shipped to it's new owner on Friday and I am regretting it already.

My 2096 does full time duty on my local control channel using Pro96Com. Hopefully the 500 will do that ok and I'll retire it to that duty and start using the 2096 again. I jumped the gun and preordered a 600 so I sure hope the fix in the works takes care of it.

Jose, our system doesn't provide a SysId on line 4 of 96/2096 or on Analyz on this scanner. I believe we still have the same bag of worms. I've tried all Multi-site settings including adjusting the ROAM.

Also, I have tried the two local controls in various locations and still cannot get one of them to ever light off even though it carries nearly the same decode rate.

IOW, there times when all three of my GRE scanners light off with same talkgroup, the 96 on Hampton tower, the 2096 on Chesapeake tower or visa-verse but the 500 is always on the Hampton tower. The 2096 and 500 are both on the same Scantenna through an Electroline cable amp. Hampton tower is closest to my location.

Strangely, when I first turn these scanners on in the am, the 500 appears to kick butt on this system.

Lynn's 800 P25 system is also terrible with this scanner as is neighboring Chesapeake 800 M36 analog/digital system. Both work fine on the 20(96). Three Military UHF M36 100% digital systems work great as do 5 analog Smartnet's plus an 800 EDACS and 800/900 LTR systems.

Works great on conventional and air band all the way up through 390 MHz.

 

[hypersight]

Hmmmmmm....I think I'll just stick to my good 'ol 96

 

[tuttleje]

"Looking at the "CCDump" output should give you some indication of the system's "IDEN_UP cycle time". "

Here is a several minutes of the "dump" on the Williamsburg STARS Tower "19E" using Pro96com. I hope it helps in determining if the system is sending the correct data for the 500 to decode.

 

[windchaser]

if gre is working on the p25 problum then maby thay will work on the muting of encryption at the same time. lets hope thay will solve both issues and all the others ,until then ill stay with what i have no gre for me at this time. wind chaser usmm

 

[DonS]

"Looking at the "CCDump" output should give you some indication of the system's "IDEN_UP cycle time". "

Here is a several minutes of the "dump" on the Williamsburg STARS Tower "19E" using Pro96com. I hope it helps in determining if the system is sending the correct data for the 500 to decode.

Actually, I was thinking of the text dump that the PSR-500 puts out on the PC/IF port when you have the FUNC+GLOB item "CCDump" set to "Yes".
It's human-readable text, and will show the "IDEN_UP" messages in a meaningful form.

 

[Russell]

I switched to P25 Manual on the Austin system and entered only the Lo = 0, hi = 65535, offset =0, base = 851.00625 and step = 6.25 and no other entries in the table. This seemed to help quite a bit. I also set the HD5 Qualify Time (digital) down from 75 to 50 and turned multisite off. I can now copy Austin quite well, though not 100%. There are still times when it won't switch to DG and just bounces back and forth between VC and ID:

With these setting it beats to Pro96 hands down.

Russell