Programming TG’s into memory limited GRE PSR500 on WIN500

[dizwiz]

I still have a trust GRE PSR500

im programming TG IDs, using win500, for OHIO MARCS.

now i already am making use of the v folders. Im breaking it down into the 9 zones(and 9 v folders) the state of Ohio has MARCS broken into.
but even so, im running out of memory for the TG IDs.

theres prob 7000 total TG IDs. Obviously I dont need all of them in each zone, but it would make my life so much simpler if there was a way I could just throw them all into the scanner without having to delete, copy, paste the ones I dont think I need

then to further complicate this issue,there is a 700 and 800 MHz version of ohio marcs.

so i have to double the talkgroup id’s in each v folder. one set for the 700 system and another duplicateset for the 800.

if anyone has any ideas if there is a way i could make every v folder reference the same set of TG IDs (again app. 7000 of them)

and/or make both the 700 and 800 mhz system utilize the same set of TG IDs
(Instead of having to duplicate them)

id love to hear!

 

[buddrousa]

To make a short answer a TRX would be a better choice if you are a GRE/WHISTLER FAN.
If not UNIDEN x36 or SDS scanner would be the other choice.

 

[fredva]

then to further complicate this issue,there is a 700 and 800 MHz version of ohio marcs.

so i have to double the talkgroup id’s in each v folder. one set for the 700 system and another duplicateset for the 800.

I don't think that is correct. The current MARCS system uses both 700 and 800 frequencies combined in the same system. Look at the frequencies on this page; you'll see that the sites in the system use both frequency ranges: https://www.radioreference.com/apps/db/?sid=6643

You may be getting confused with the fact that there was an old MARCS system which used only 800 mhz frequencies and now a new MARCS-IP system which uses both 700 and 800 mhz frequencies. The old MARCs is retired. There aren't two separate versions of MARCS that exist today. Make sure you don't have the programming for the old MARCs in your scanner or else you are taking up space unnecessarily. You only need the current MARCS-IP system.

 

[gmclam]

I am no expert on the system you're trying to monitor, but am a whiz with GRE scanner programming. If in fact the same TG IDs are used between "two systems" you want to monitor, and you would only be monitoring from a single control channel frequency at a time; you might be able to just "list" all the control channel frequencies in the TSYS object.

I face the same dilemma when it comes to this (and other) issues. I bought a TRX-1, which solved some issues, but has plenty new ones. I posted a review on it here on RR.

I had previously purchased a BCD996P2 for my dad and think it handles this issue much more eloquently (sharing TGs across different sites, even if scanning multiple control channels at the same time). But I do not like the user interface at all.

With Phase II and simulcast issues it appears the only real solution presently available is the SDS-100/200. But this creates even more issues (such as what batteries it uses, user interface, etc). It seems like there is nothing out there to solve it all. We really need a new choice (such as previously proposed TRX-100) but that doesn't look like it will come to fruition, if ever.

 

[dizwiz]

I am no expert on the system you're trying to monitor, but am a whiz with GRE scanner programming. If in fact the same TG IDs are used between "two systems" you want to monitor, and you would only be monitoring from a single control channel frequency at a time; you might be able to just "list" all the control channel frequencies in the TSYS object.

I face the same dilemma when it comes to this (and other) issues. I bought a TRX-1, which solved some issues, but has plenty new ones. I posted a review on it here on RR.

I had previously purchased a BCD996P2 for my dad and think it handles this issue much more eloquently (sharing TGs across different sites, even if scanning multiple control channels at the same time). But I do not like the user interface at all.

With Phase II and simulcast issues it appears the only real solution presently available is the SDS-100/200. But this creates even more issues (such as what batteries it uses, user interface, etc). It seems like there is nothing out there to solve it all. We really need a new choice (such as previously proposed TRX-100) but that doesn't look like it will come to fruition, if ever.

i tried that and it didnt work.
I listed the 700 and 800 Mhz control channel freq together and it didnt work.

the Problem is if i do that (list them together) I have to select either P25 700 Mhz (and itwill monitor the700 Mhz system) or P25 800 Mhz (and it will monitor only the 800 Mhz system).

Both systems are part of the current MARCS system. I saw the previous post and i know MARCS-1 (an 800 mhz system) is defunct. The new system also has a couple 800 Mhz sites , but is mostly 700 Mhz

i wonder if theres a way to setup custom control channel tables (that can do both 700 and 800 control channels at the same time as part of the same Tsys ID) that way i dont have to list my marcs TG IDs twice

 

[dizwiz]

This gre psr500 has been a very impressive scanner just minus the limited memory.

it roams well. I use it mobile most of the time across ohio. Rarely stationary.

I cant see getting rid of it until TDMA phase 2 takes over

 

[gmclam]

It sounds like you want to monitor both the 800 & the 700 systems "simultaneously". That's why, in the PSR-500, you need to duplicate the TGs, unfortunately. I have the same problem here with the Sacramento city & county analog systems. However, once they switch over to P25 only, it looks like it will be one simulcast system (new problem).

I too love my PSR-500. Too bad it can't (easily) be upgraded to handle TDMA/Phase II. Last year I took the PSR-500, a new TRX-1 and my dad's 996P2 on a "tour" of the Pacific Northwest and ran them simultaneously. I was upset with how the TRX-1 performed. I was amazed at how much traffic I was able to monitor from "Phase II systems" on the PSR-500 because that specific TG was Phase I.

When I was in Phase II only territory, the 996P2 outperformed the TRX-1. However, there are places where the simulcast issues make these 3 choices unworkable.

 

[Swipesy]

Here is the deal for you. I still use a PSR-500 along with a WS-1080. For the PSR-500 you are limited to 1,852 object blocks per V-Folder. That includes all control, alternate tower frequencies, conventional frequencies and trunked Talkgroups and Radio ID's. There is no getting past the 1,852. Also, you are limited to 32 frequencies per trunked system. Here in Northern Ohio I have programmed MARCS, GCRCN, Parma P-25 and Austintown and Erie, Pa trunked systems along with 130 Conventional frequencies. I have 30 MARCS Control and Alternate frequencies programmed for 7 towers mixing the 700 and 800 mhz together (someone once said to put 800 first and 700 second. I have done it that way, mixed way and 700-800 and have not noticed a difference). My conventional and TG's include all police, fire, ems, hospital,OSP, ODOT for Northern Ohio along with 100 RID's. This configuration takes up 1,630 objects and produces about 2,500 hits per day. If you are using 7,000 TG's then you are hearing so much you really are not hearing anything, lol. Do not waste precious Objects by duplicating TG's.

 

[dizwiz]

Here is the deal for you. I still use a PSR-500 along with a WS-1080. For the PSR-500 you are limited to 1,852 object blocks per V-Folder. That includes all control, alternate tower frequencies, conventional frequencies and trunked Talkgroups and Radio ID's. There is no getting past the 1,852. Also, you are limited to 32 frequencies per trunked system. Here in Northern Ohio I have programmed MARCS, GCRCN, Parma P-25 and Austintown and Erie, Pa trunked systems along with 130 Conventional frequencies. I have 30 MARCS Control and Alternate frequencies programmed for 7 towers mixing the 700 and 800 mhz together (someone once said to put 800 first and 700 second. I have done it that way, mixed way and 700-800 and have not noticed a difference). My conventional and TG's include all police, fire, ems, hospital,OSP, ODOT for Northern Ohio along with 100 RID's. This configuration takes up 1,630 objects and produces about 2,500 hits per day. If you are using 7,000 TG's then you are hearing so much you really are not hearing anything, lol. Do not waste precious Objects by duplicating TG's.

i couldnt use 7000 TG’s even if I wanted to bc as you just stated each v folder can only handle 1852 .
My point is it would be so much easier for me to program if I could just copy/paste all 7000 TGID’s from RR DB into win500

instead I have to select out which ones I want to see for each zone /v folder.
This can take some time to program.

BTW, I do always run a wildcard to catch TG’s I may not have programmed.

 

[gmclam]

BTW, I do always run a wildcard to catch TG’s I may not have programmed.

When the system is well known, I take the time to program the desired TGs. Yeah it takes time, but this is our hobby isn't it? I'll use the wild card on systems that are new and/or don't have all the TGs listed. When a TG is received, I'll store it (F3). Then periodically I'll download from the scanner, ID and tag those saved IDs and repeat the process.

What I've found is there are now often several dozens of TGs listed that "never" get used. Many are InterOp or for situations that might never happen. By using the wild card I only populate the scanner with TGs I explicitly do or don't want. Sometimes the list of what I don't want is shorter (takes less memory to program). It really depends on what (system) you're scanning and personal preferences.

This configuration takes up 1,630 objects ...

Perhaps you can share your profile with dizwiz. Does programming 800 before 700 make them both work in the same TSYS group?

 

[Swipesy]

"Does programming 800 before 700 make them both work in the same TSYS group? "

Some time ago (couple years) there was a RR post on the GRE forums that suggested that the architecture of the 500 and 800 was such that it would catch 700 mhz before 800 mhz in mixed frequency tower control and alt frequencies. I could never prove that to be fact on my 500 or 800 radios. Perhaps if some type of equipment could measure that it is true but just listening I see no difference.

 

[Spitfire8520]

i tried that and it didnt work.
I listed the 700 and 800 Mhz control channel freq together and it didnt work.

the Problem is if i do that (list them together) I have to select either P25 700 Mhz (and itwill monitor the700 Mhz system) or P25 800 Mhz (and it will monitor only the 800 Mhz system).

Both systems are part of the current MARCS system. I saw the previous post and i know MARCS-1 (an 800 mhz system) is defunct. The new system also has a couple 800 Mhz sites , but is mostly 700 Mhz

i wonder if theres a way to setup custom control channel tables (that can do both 700 and 800 control channels at the same time as part of the same Tsys ID) that way i dont have to list my marcs TG IDs twice

It sounds like you want to monitor both the 800 & the 700 systems "simultaneously". That's why, in the PSR-500, you need to duplicate the TGs, unfortunately. I have the same problem here with the Sacramento city & county analog systems. However, once they switch over to P25 only, it looks like it will be one simulcast system (new problem).

The PSR-500 has a built-in feature that will force it to cycle through all control channels for a single trunked system, no duplicate programming is needed. In Win500, the MultiSite Mode set to the Stationary mode forces the scanner to check all control channels when the "Check all CCs in every Scan-mode pass" option is checked. If the option is not checked, it will check a different control channel on each pass of the system instead of all at once. If you use either of the other MultiSite Mode settings (Off being the default), the PSR-500 will try to stay on a single control channel until either the signal drops (in Off mode) or when the signal drops below the decode threshold (in Roam mode).

The older memory limited GRE/RadioShack/Whistler scanners had better multi-site management options than the newer TRX scanners for whatever reason.

 

[K9DAK]

The PSR-500 has a built-in feature that will force it to cycle through all control channels for a single trunked system, no duplicate programming is needed. In Win500, the MultiSite Mode set to the Stationary mode forces the scanner to check all control channels when the "Check all CCs in every Scan-mode pass" option is checked. If the option is not checked, it will check a different control channel on each pass of the system instead of all at once. If you use either of the other MultiSite Mode settings (Off being the default), the PSR-500 will try to stay on a single control channel until either the signal drops (in Off mode) or when the signal drops below the decode threshold (in Roam mode).

The older memory limited GRE/RadioShack/Whistler scanners had better multi-site management options than the newer TRX scanners for whatever reason.

THAT is the best explanation of MultiSite Mode I've seen in 10 years of owning a PRO-106 and 197! Huzzah!