A memory idea

[Pro-95]

With the advent of dynamically allocated memory....

How long before we see dynamically assigned TG's being used.

Example in a large multi-site county or on a statewide system where there is a common and sometimes long list of talkgroups that are used on several tower sites can a list of TG's be dynamically assigned to that system or multiple systems, freeing up tons of duplicated memory for other uses.

 

[Admin0140434]

With the advent of dynamically allocated memory....

How long before we see dynamically assigned TG's being used.

Example in a large multi-site county or on a statewide system where there is a common and sometimes long list of talkgroups that are used on several tower sites can a list of TG's be dynamically assigned to that system or multiple systems, freeing up tons of duplicated memory for other uses.

not sure what your trying to say, but if youre asking why you cant program more then 200 TG per system, its cuase by the time the CC looks through all the TG's programed in, it will have already moved on to the next TG keying up the CC (i think i explained it right...)

 

[JnglMassiv]

I don't get it.

Aren't DMA scanners already doing that?

 

[Pro-95]

If they are already doing it I seemed to have skipped right on past it in the manual.

Ok say you have a large system. The system has several to many tower sites or "systems". However there is a common list of talk"groups" that are shared amongst the entire system. So rather than programming the same groups over and over again for each "system" have a listing of the talkgroups be shared amongst several systems. This would reduce the amount of memory used to store the talkgroups since common talkgroups can be assigned to multiple systems. Not to mention allow for talkgroup updateing to be vastly easier on large multi-site/system systems.

Now while using ARC246 and the BC246T and re-reading the manual for both, I don't see where this is the case but if I missed this, please tell me.

So with a little example: EDACS

Statewide system
Site 1 = system1
Site 2 = system2

Both sites are using the same talkgroup list.

Currently and in particular an EDACS system you would need to have two copies of the talkgroups one for each system programmed into the scanner. Where if the talkgroup list could be stored seperatly from the system and dynamically assigned to a system then you could have one list of talkgroups for even a massive 100 system system.

The memory saved would equal the amount of memory in a talkgroup list times the number of systems you programmed.

Clear as mud? Now on a Moto system this may not be an issue but for EDACS and from what I can tell with ARC246 or the BC246T manual this could be a huge amount of memory savings that could be used elsewhere. Not to mention making the changes, updates to systems a whole lot easier than checking several talkgroup lists.

 

[AZScanner]

I would simply program all the sites as one large system. This is what I do with Mesa/Phoenix - they are all in one bank of my PRO-96 and BC796. If I wish to monitor only specific site(s) I lockout the others. There's very little overlap in the systems so I can usually only listen to one site at a time anyway. Listening to the other sites doesn't do me any good because I can't decode the CC - too far away.

-AZ

 

[Pro-95]

Yep, works wonders in Moto-land but here in EDACS country......

:!: :!: :!: :!:

 

[br0adband]

I think the biggest problem with this kind of thinking, and I believe it was Voyager that touched upon it in another post but if someone else did I apologize for the improper credit, is that people keep thinking the 246 is scanning talkgroups - and this simply can't be further from the truth.

When a talkgroup ID is broadcast on the control channel - which is constantly being monitored in between transmissions - the 246 simply does a quick lookup against the talkgroup IDs you have programmed in. There are three possibilities when a TGID is received:

1) The 246 is in ID SCAN mode meaning it will only open the audio circuit for TGIDs if a match for one you have programmed in is found.
2) The 246 is in ID SEARCH mode meaning for any TGID it receives even if no match if found among the programmed TGIDs it will display the TGID found on the display so you can note it for later usage or hit Enter to save the TGID into the current system and set options for it as well as open the audio circuit.
3) The 246 is in either mode and it receives a TGID for which it finds a match in the preprogrammed list; opens the audio circuit and displays the alphatag for the TGID currently programmed.

This is how all modern trunk tracking scanners work, period. The dynamic memory allocation (DMA) has nothing to do with how the 246 tracks trunked comms.

It's not scanning through the entire list of TGIDs every single time since the only way this would happen is if the one talkgroup you're listening to just happens to be the last one you have programmed in. It's random meaning that if the TGID that's received is say, 25th out of 100 per the order you have them programmed in, it's going to stop at the 25th one on the list because that's the winner.

Since the 246 does the lookup based on the programmed order of TGIDs per system, it does have some logical meaning to say you should program your 246 with the most popular TGIDs in your area as the first group - for almost all of us that means the Police talkgroups, usually followed by another group with the Fire/EMS ones and then possibly the city services group in your area. This isn't a written-in-stone rule, just a suggestion - and with the DMA it's easier than baking a cake.

Unless the most popular talkgroup in your area (which is usually the primary Police dispatching talkgroup) just happens to be the last one you program in - and that would be counterproductive - you should never really have any issues with the speed at which the 246 does it's internal TGID lookup, even for 200+ talkgroup systems.

Even if you had over a hundred TGIDs in any given system (and I have two that have at least 120 in each), the amount of time it takes to blaze through the list looking for the matching TGID and alphatag you have programmed in is negligible. The 246 is a top-of-the-line scanner for it's abilities and pretty fast at what it does.

In my own example, in one system I have 147 TGIDS all properly tagged. If it hits on any given TGID and I listen to the transmission then hit Scan one time, as long as there are not other TGIDs active it will return to the one open TGID in about 1/4 of a second. I've done this countless times as a test for myself just to get some idea of how fast the scanning takes place.

As stated above, it breaks down this way for listening to trunked communications:

- when no transmissions are happening, monitor control channel until a TGID is broadcast;
- when a TGID is broadcast, do a lookup against the internal map of programmed TGIDs;
- if scanner is in ID SCAN mode and no match is found, return to monitoring the control channel;
- if scanner is in ID SEARCH mode and no match is found, display TGID for possible notation or storage, tune to appropriate frequency and open audio circuit, when transmission ends return to monitoring control channel;
- if scanner is in ID SCAN or ID SEARCH mode and a match is found, display alphatag and tune to appropriate frequency and open audio circuit, when transmission ends return to monitoring control channel;
- loop back to monitoring control channel

Simplistic, yes, but in reality that's all the 246 does for trunked radio systems. Sure there are other variables involved but that is basically the gist of it.

I did a flowchart just for kicks to further illustrate it and it's attached to this message. But to reiterate the main point here:

The dynamic memory allocation (DMA) used by the 246T and future Uniden scanners realistically has no bearing on how the scanner tracks trunked radio communications systems.

Hope this helps,

Paul

 

[Voyager]

There are three possibilities when a TGID is received:

2) The 246 is in ID SEARCH mode meaning for any TGID it receives even if no match if found among the programmed TGIDs it will display the TGID found on the display so you can note it for later usage or hit Enter to save the TGID into the current system and set options for it as well as open the audio circuit.

Paul, you forgot a check: #2 does what you said as long as the TG is not locked out. If it is, it ignores it and continues the evaluation of the TRS.

The problem with the original post is:

How do the RADIOS know what to look for? Would you have to have an ID number for each group (AKA A TG ID?) Back to square one.

Besides, there are 65535 TGs available on a P25 TRS. I doubt they are going to run out of them anytime soon (Statewide systems being the most likely ones to run out first).

For reference: Max # of TGs you can scan on the radios: Typically 10-16. That's a far cry from 200 that scanners can scan. Some models will scan more, but scanners are already beating the radios in the number of available TGs to scan. The 200 limit is far better than the radios we are trying to monitor.

Joe M.

 

[Admin0140434]

i now understand what your saying pro95... sorry, i misread your post...

 

[scanfan03]

He isn't talking about the TGID limit or the way the scanner tracks. He is talking about having more than one site from one system cover a group of 200 TGIDs. Instead of having to program in 3 different systems in the scanner for 3 different sites of one system with all of the 3 sites having the same 200 TGs (this eats up memory). The way he is talking about you would save 800 memory slots (if you use text tags).

In Mot terms: Right now we have privacy plus scanners. We want Smart-Zone scanners.

 

[Pro-95]

Whew! I thought for sure I was going to wrestle with trying to explain this.

So if the TGID's could be seperated from the systems and the TGID's could be programmed as a list with a key and then each system could be assigned a key to use a designated TGID list. This way and in the case of Nevada, using two EDACS system here in the northern territory, I could program two lists of TGID's one for Washoe County and one for the State then program each of the 8 Washoe sites (systems) and 40 of the State sites (systems) and use only 2 TGID lists.

Thanks to those who understood what I was trying to say. Sometimes my fingers just can't type what it is I'm thinking.

 

[UPMan]

Multi-site will be implemented on future scanners. Amazingly similar to the above (not exactly, though...independantly "invented" by our team within the past couple of months).

 

[Pro-95]

Multi-site will be implemented on future scanners. Amazingly similar to the above.

SHAWEEET! I am ready. 8) 8) 8)

Do I get a prize for pre-releasing this cat?

 

[UPMan]

Ah, well, I think I mentioned it a while back. After we had decided to do it but before we nailed down the "how."