mtindor said:
Does this not hint that the less talk groups you have, the more conventional channels you have, etc. Does this not hint that one can rob Peter to pay Paul?
That would be an accurate statement. The scanner is very flexible in the types of objects can be placed within the memory of the radio. If you fill the memory, and then delete a talkgroup object, you can then add a conventional object in it's place without any issue since they are both the same size.
The radio can hold up to 1852 objects, but the exact number of objects depends on the types of objects that are entered. Some objects use up multiple object IDs because of their size. If all you put in were conventional objects, you could enter 1852 of those, because they only use 1 object ID.
mtindor said:
What's the difference between objects and object ids? You say that it takes 10 object ids to make up a TSYS object. Can you diagram how a TSYS object is laid out and just how a TSYS object comes to take up 10 object ids?
I can't go into detail about the memory layout of the radio beyond this:
There are 1852 Object IDs available on the PSR-500/600. Each Object ID points to a block of memory within the radio. Each object type uses a set number of Object ID slots within that memory ranging from 1 object ID for conventional and talkgroup objects, to 10 object IDs for Motorola/P25 TSYS objects.
mtindor said:
I'm taking a wild guess that since you guys are programmers, that you must have gotten specific details about how to program for the scanner from GRE, is that correct? Is all of this information about memory usage based upon something that programmers just inherently know, or are you privy (because of some agreement between you and GRE for programming for their scanners) to specific data that they have provided you which tells you how memory is used, where it is used, etc?
The information needed to program the scanner was provided by GRE.
mtindor said:
I just don't understand why having what I would call an additional 'field', 8 or 16 chars in size (for a long or abbreviated alpha tag) is such a big thing. I mean, when that field contains no data (i.e. no alpha tag), then why would space still need to be taken? Shouldn't it be that space is only taken when you have entered in data to occupy that space? Is it a function of how the firmware is programmed, the type of processor, etc. that determines whether memory can be reused for other things or must be set aside (reserved) instead?
There are two ways to store data in general. The first and most common method is to use fixed data structures. These structures allow quick access to the stored information with minimal overhead. The drawback to this method is that it uses more memory (or storage space) due to all of the unused space within those structures. This is the basic method used in these radios. It reduces the power needed in the radio's CPU to read and use the data.
The second method is to dynamically store the information and allow the data to shrink and grow as needed. While this method uses less memory since there's no unused space within the data, it also requires more overhead when extracting the data to be used within the application. It takes more programming to handle this type of data (read as more memory in the code segment), and more processing power to deal with it.
As you can see, when you're dealing with a relatively small amount of memory, and somewhat limited resources in hardware (although I admit I don't know how powerful the CPU is in these radios), the fixed structure method is the better fit in this application.
mtindor said:
For instance, if I would like to see at least an abbreviated alpha tag for frequencies in a TSYS object, then I'm thinking it's going to take 8 additional something (8 characters, 8 bytes, 8 whatever) for each frequency in a TYS object that I decide to alpha tag. If I have 10 TSYS objects, 9 of which do not require alpha tagging of frequencies because those objects are site specific, and then I have 1 TSYS object that is a multisite object with 20 frequencies and I want to alpha tag each of those frequencies so that I know what site a transmission is coming from in that multisite TSYS object, why isn't that simply 20 freqs x 8 chars = an additional 160 something used?
See above regarding fixed data structures.
mtindor said:
And let's say we have Joe Schmoe who wants to have one a few conventional objects, two or three TSYS objects, and as many talk groups as possible. How is it that me wanting to have 20 frequencies in a TSYS object alpha tagged?
I don't understand your question here, but if you're wondering why it would affect you, see the fixed data structures explanation above.
mtindor said:
Perhaps this isn't even a memory issue and I'm looking at it all wrong? 1800 objects in total available. Does this mean I could have 900 TSYS objects full of 32 frequencies each programmed in, and then have 900 wildcard TGRP objects and thus be able to scan 1000 trunking systems with no specific alpha tags?
It is a memory issue. You would never be able to fit 900 TSYS objects within the memory of the radio, since a TSYS object uses 4-10 Object IDs depending on the system type. The difference between those is the type of information needed to make the systems work (frequency tables, and the like).
The best you could do on TSYS objects would be 370, and then only if they were LTR or EDACS, and you only entered the Wildcard Talkgroup for them. That number would go down for every Motorola system you added.
mtindor said:
If so, then what if I have 10 TSYS objects and a total of 500 TGRP objects programmed in between those ten systems? Does that not leave me with 1290 (1800 - 510) objects to use for other things?
Depends on the type of TSYS. If they were all Motorola/P25, you would have used 600 object ids. (10 TSYS @ 10 Object IDs = 100 + 500 TGRP object IDs).
mtindor said:
Why can't an alpha tag for a frequency in a TSYS object be equivalent to a TGRP object for a TSYS? And thus if I have less TGRP objects, I have more objects free to use for alpha tagging frequencies in a TSYS and vice versa?
The alpha tag of a TGRP object is part of the data structure, and that entire structure fits into a single object ID space. The TSYS object is already larger than a single object ID space can hold. Adding alpha tags for each frequency would use the space regardless of if they were used, because of the fixed structure method used.
mtindor said:
Are any of these questions making sense?
The questions make sense. Just remember that not every object uses a single object ID. Some object types use more space in memory than what is allocated to an object ID depending on how much information is needed for that object type.
When you're dealing with Motorola/P25 systems, you need all of the frequencies, the TSYS options, frequency tables, system alpha tag, and various other information. When you're working with LTR or EDACS, you don't need frequency tables and things of that type that are specific to Motorola/P25 systems, so those objects are smaller in size, but still take up multiple object ID slots.
Mike
