RS VS. GRE VS. Uniden
- Thread starter Drumnjim
- Start date
- Status
rkovalik
Member
- Joined
- Jul 11, 2004
- Messages
- 7
It seems the restrictiveness of the 500/600 is the ability to isolate action within systems.
The designers probably expected you would always put an entire system in a list and just scan that, not taking into consideration that a "system" can cover a large geographical area
that you may not care about other than whats local for you.
Owning a 996, I would agree 20 "lists" is a limitation even though my next purchase will be a 500 to play with.
In Ontario for example there is a Province wide system that covers all Ontario Police and Ambulance. Granted, I believe its divided into three system regions but still...
First I would want to divide the two types of traffic as I may not want to listen to medical. (2 Lists)
Then, I would want to divide this into regions which I think is 12 per geographical system.
So I would "lockout" all except my local region and as I travel, I would "unlock" and "lock" regions as I go.
From this example, I almost used up all my lists and still have not added things like local police, transit, local ems, air, fire, tow trucks etc.
Maybe someone can enlighten me on a better way of doing this but from my example, the 20 lists fall short.
I hope this isnt a physical memory limitation and can be addressed in a firmware release.
Bump this to 40 or 50 and it would be the scanner to beat.
After all these years or scanners, I dont know why when the newest is released, it is not cut and dry the best at the time. If we look at the GRE's which are really the only competitors to the Trunk Trackers and are brand new, they dont blow the Unidens away on every feature.
There always seems to be a comprimise choice to be made.
The designers probably expected you would always put an entire system in a list and just scan that, not taking into consideration that a "system" can cover a large geographical area
that you may not care about other than whats local for you.
Owning a 996, I would agree 20 "lists" is a limitation even though my next purchase will be a 500 to play with.
In Ontario for example there is a Province wide system that covers all Ontario Police and Ambulance. Granted, I believe its divided into three system regions but still...
First I would want to divide the two types of traffic as I may not want to listen to medical. (2 Lists)
Then, I would want to divide this into regions which I think is 12 per geographical system.
So I would "lockout" all except my local region and as I travel, I would "unlock" and "lock" regions as I go.
From this example, I almost used up all my lists and still have not added things like local police, transit, local ems, air, fire, tow trucks etc.
Maybe someone can enlighten me on a better way of doing this but from my example, the 20 lists fall short.
I hope this isnt a physical memory limitation and can be addressed in a firmware release.
Bump this to 40 or 50 and it would be the scanner to beat.
After all these years or scanners, I dont know why when the newest is released, it is not cut and dry the best at the time. If we look at the GRE's which are really the only competitors to the Trunk Trackers and are brand new, they dont blow the Unidens away on every feature.
There always seems to be a comprimise choice to be made.
The 500/600 does have what they call the V-Scanner folders that allow you to keep 21 different configurations in the scanner. You could say it allows 420 scan lists, just that you can only use 20 of them at a time. Not everyone finds this very convenient, but it should work in the majority of situations if you plan ahead. Program different V-Scanner folders for different areas of your state/province and swap them in when you travel.
I'm pretty sure scan list membership is something that's stored with each object in the database. One could say the scan lists do not exist as entities in their own right. They are virtual reflections of specific characteristics of the objects. The upshot of this is that while it could change, it's unlikely.
I suspect one of the bigger issues would be how to represent scan list activity if the number of lists was greatly expanded.
I'm pretty sure scan list membership is something that's stored with each object in the database. One could say the scan lists do not exist as entities in their own right. They are virtual reflections of specific characteristics of the objects. The upshot of this is that while it could change, it's unlikely.
I suspect one of the bigger issues would be how to represent scan list activity if the number of lists was greatly expanded.
Actually this is a completely false statement. Channels and talk groups are indeed exactly the same thing. Talk groups and frequencies are different, but in the context of this discussion, a DMA scanner system is either a TRS or conventional system. The "channels" in each group are either TG's or conventional frequencies; in either case they are channels.AlabamaRS said:
rkovalik:
I too have a pretty large system that I monitor and the way I like to monitor I keep the law enforcement separate from the fire and EMS. In addition, I need to keep areas separate. The way I handle this is by establishing multiple systems, usually broken down by geographical boundaries, and then within those use the 20 available groups (although I generally don't use 20 of them) to break out the type of communication (LE, FD, EMS, etc.). This gives me the ability to turn on the appropriate geographical system and restrict what I listen to within that area.
Patch42:
The "V-folders" concept was a great idea in 2003 (when the Pro-96 was introduced) as a way to allow you to have more "sets" of configurations in the traditional "banks & lists" scanners, but it has really become more of a hindrance than a benefit in the age of dynamic memory and object oriented scanners.
I can see where one might think it has outlived its usefulness, but a hindrance? That's overstating a bit, don't you think?loumaag said:
I do have to wonder why they haven't thought to include a slot for a SD card or something like that. I mean, my cell phone came with a 500MB mini-SD card that's about the size of the nail on my little finger. You can buy a 2GB SD card for about $20 these days. Even the very fast cards capable of transferring 10MB/sec aren't that expensive.
Realistically, the biggest challenge these days shouldn't be the memory, but how to coherently display the scan list configuration on the tiny screens of handhelds.
I don't disagree with your analysis of SD card usage, but I still think that having a V-Folder (or indeed any not active memory "setup") for the scanner is a hindrance. It encourages the exact point brought up by you earlier. There should be no limit on the usage of the memory available on the scanner, don't waste space holding something in memory when that memory could have been configured as active "instead" of "storage". Consider this, on the PSR 500/600, how much more effective would the memory management have been if instead of being limited to 1800 objects, you could have used 36000 objects and over 400 scan lists?Patch42 said:
I know nothing about the specifics of the bits inside the 500 and 600. I do know some generalities about types of memory that I suspect apply.
Non-volatile memory that requires no power to sustain the contents tends to be rather slow as memory goes. My guess would be that the 500 and 600 use this slower, cheaper, non-volatile memory for the v-scanner folders, and a faster, more expensive type of memory for the working data. I would see it as not dissimilar from a computer where the hard disk holds the persistent data and the RAM contains the software and working data. The existence of the hard disk doesn't take away from what can be accomplished with the RAM. Or, put another way, removing the hard disk doesn't make the RAM able to do more.
Which is not to say that with memory as cheap as it is the 500 and 600 shouldn't be capable of managing more objects and lists. I just suspect it's not the simple trade-off you imply.
Non-volatile memory that requires no power to sustain the contents tends to be rather slow as memory goes. My guess would be that the 500 and 600 use this slower, cheaper, non-volatile memory for the v-scanner folders, and a faster, more expensive type of memory for the working data. I would see it as not dissimilar from a computer where the hard disk holds the persistent data and the RAM contains the software and working data. The existence of the hard disk doesn't take away from what can be accomplished with the RAM. Or, put another way, removing the hard disk doesn't make the RAM able to do more.
Which is not to say that with memory as cheap as it is the 500 and 600 shouldn't be capable of managing more objects and lists. I just suspect it's not the simple trade-off you imply.
Paulsan said:
The output from the 396 is a Uniden connector. The cable that comes with the radio is serial, but Uniden sells a USB cable.
The output for the 500 is a 1/8 inch connector to USB. This is the same physical output as the 96, only the 96 cable ends with a serial connector.
If you have more than one scanner with a serial interface, consider buying one of the serial to USB converter cables on the market.
Uh, almost. The cable is a USB -> serial converter. The signal being sent to and from the 500/600 is still serial. To the best of my knowledge, there are no USB scanners (or commercial radios for that matter) in existence. Such an animal would require a device driver for each model and that just is plain silly. The device driver you are loading to use that "USB cable" is for the USB->Serial adapter included in the cable, not the radio.LEH said:
- Status
Similar threads
