System configuration by only system id

[nonposter]

Where can I submit an idea to Uniden for a feature I would like in a scanner?

The feature I would most like is the ability to program a trunked system by entering the system id and the scanner would find the system by searching for a control channel for that system. As a listener, I don't care what frequencies a system uses; I just want to listen to it. And "it" is defined by system id.

I have some other wishes; see my wishlist.

 

[swest90]

And just how exactly do you propose it 'finds' the control channels? A system id doesn't give any useful information in regards to finding a system. Only way I could think of is if the unit somehow had tcp/ip that could download from the rr databse here.

What range would it search to find these control channels? Everything in the VHF/UHF/700/800/900 MHz range? What happens when i switch off that system, does it have to find the control channels again by searching the entire spectrum that allows trunked modes? And the big question, whats so hard about programming in frequencies?

Sorry but this just isn't feasible. I know you dont care what frequencies a system uses, but thats how it works and you only have to enter them once. You may not care about what gasoline, oil grade and voltage your car runs on, but if you want it to run and continue to do so, you use whats required.

About your list, Options 4,6 and 7 are pretty much standard on any of the mid price+ units. Option 1 the list of 'last used' channels is a decent idea. But I dont see it being used much by the average user.

I would like to see a better smartzone implementation, It really wouldn't require additional receivers, it could just check the others site reception/decode levels during the idle time. It would be nice to have the selection for auto site lockon, or manual select.

Enjoy
Shawn

 

[nonposter]

And just how exactly do you propose it 'finds' the control channels?

The first time the scanner starts to scan a system, it searches the band (eg 800MHz) for a control channel with the system id. There are a set of known frequencies that can be used for the systems; the scanner would try each. When the scanner stops scanning that system (eg to scan another system, or turned off), it would save the last-known control channel (eg to flash memory), so it could start decoding the CC data quickly when it returns to that system.

Each system would have a band (eg 800MHz) programmed.

Each system has a unique system id. Each site in a system transmits the system id regularly. I don't understand your statement "A system id doesn't give any useful information in regards to finding a system."

whats so hard about programming in frequencies?

It's error-prone (I can mistype part of the frequency), it's unverifiable (if I mistype the secondary control channel while the primary control channel is active, I can't check that the secondary is correct), and potentially time-consuming if there are many sites in the system with different CC frequencies.

Contrast that with programming just the system id: it's 4 characters, and (as long as I can receive transmissions from any site) it can be easily verified. If I travel to any location within the system's coverage area, I know I can scan the system.

About your list, Options 4,6 and 7 are pretty much standard...

I didn't say they weren't. It's a list of things I would like to see in a scanner. The fact that some of them are in scanners already being manufactured is great. If a scanner is made that contains all of the items, I would call it ideal and buy one as soon as possible.

 

[bassmkenk2508]

I say, just be careful with when you type in the frequencies to program a system...

Or print out a list in small print of the control channels for your area and keep it in your wallet with the system IDs printed along.

 

[nonposter]

I say, just be careful with when you type in the frequencies to program a system...

Or print out a list in small print of the control channels for your area and keep it in your wallet with the system IDs printed along.

????

How do either of those suggestions make the use of my scanner more convenient? Technology should be used to our advantage.

I'm completely dumbfounded as to why you would suggest that I print a list of control channels... Are you recommending that I would reprogram my scanner as I travel? Why not just use a single-frequency radio, and replace the crystal for each frequency I want to listen to, when I think there would be an interesting transmission?

 

[bassmkenk2508]

The dynamic memory allocation of the newer Unidens can be used to one's advantage.

You wont have to reprogram your radio... just add a radio system and leave it in there No hunting for a control channel every time....

In my state, I have all the place I travel and surrounding major cities and only have used up 25% of its memory. So I can all major cities around my state and their respective states' highway patrol systems/frequencies and still not overfill my radio's memory.

But respectively, it is people who think outside the box like you who come up with more efficient products, especially scanners

 

[nonposter]

Sorry but this just isn't feasible.

What isn't feasible about this (finding a system by system id)? It's just software. The scanner is already able to decode control channel data; this is obvious since it can determine when talkgroup transmissions start and end, etc.

 

[nonposter]

Where can I submit an idea to Uniden for a feature I would like in a scanner?

No ideas?

 

[bassmkenk2508]

There does not seem to be any good points of contact on the Uniden website for idea submissions or suggestions that go to any direct person.

On this site, this Uniden forum is probably the best place to put an idea out in the open for a Uniden scanner. There is a product person from Uniden on RadioReference.com with the user name 'UPMan'. He is very knowledgable about the Uniden scanners' ins and outs. Usually he keeps a good eye out in the Uniden forum. He would be your best contact if anyone at all.

 

[slicerwizard]

So while we're dealing with real problems (like the lack of multi-site trunking on the 396), you want to enter a SysID on a scanner that doesn't have a hex keypad, and that will somehow be less error-prone than entering frequencies? And you've overlooked the fact that some systems use several SysID's.

And the time sync (from WWVB, which most scanners can't hear) is for what? I mean, most scanners don't have a clock, so ?? Your wish list includes items which are fairly standard these days (like PC programming), but no mention of a clock.

Multiple tuners, while nice, tend to drive up the price, which most consumers don't want to pay.

As for your strongest site search, Motorola radios (which is what you should get) manage to do it just fine with only one tuner.

I do agree that scanners should be smart enough to gather ACC data and neighbour lists and automatically build complete site lists for systems. It can be done automatically and would be a major asset for all users.

 

[nonposter]

So while we're dealing with real problems (like the lack of multi-site trunking on the 396), ...

How is this "real problem" related to asking a question about submitting a feature request? Isn't the "problem" of not having multi-site trunking really just the lack of a feature found on another scanner? Was this a problem before the 996 came out?

What can I do to help resolve the "problem" of the lack of multi-site trunking on the 396?

... you want to enter a SysID on a scanner that doesn't have a hex keypad, and that will somehow be less error-prone than entering frequencies?

The scanners allow programming of text tags to be associated with each system/group/channel, and they don't have full alphanumeric keypads. A computer, on the other hand, does have enough keys dedicated to specific characters that make it able to receive the requested information (system id) and transfer it to the scanner.

I still stand by my argument that entering one system id for a system, instead of several or many frequencies, is verifiable and less error-prone.

And you've overlooked the fact that some systems use several SysID's.

Which systems?

And the time sync (from WWVB, which most scanners can't hear) is for what? I mean, most scanners don't have a clock, so ?? Your wish list includes items which are fairly standard these days (like PC programming), but no mention of a clock.

Clock display. Timestamp for the log entries for last 10 heard transmissions, etc.

Multiple tuners, while nice, tend to drive up the price, which most consumers don't want to pay.

I would think most consumers wouldn't want to pay for anything, if given the choice. However, consumers who want the extra features are willing to pay the extra cost. As I said before, I want these features, and I'd be willing to pay for them.

As for your strongest site search, Motorola radios (which is what you should get) manage to do it just fine with only one tuner.

Where can I get one of these? Can they scan the same frequencies as my Uniden scanner? Are they easy to program, and can they be programmed by computer with included or freely downloadable software? Do the portables use AA batteries?

The multiple tuners would also be useful for simultaneously scanning trunked and conventional systems in (true) priority mode.

Just because Motorola radios have a certain feature doesn't mean that it wouldn't be useful in another manufacturer's product.

 

[slicerwizard]

I still stand by my argument that entering one system id for a system, instead of several or many frequencies, is verifiable and less error-prone.

And it will be totally useless for any system that doesn't use a SmartZone controller, as they don't announce their alternate control channels. I get the impression that you don't know how this stuff works.

Which systems (use several SysID's)?

Every OmniLink system that Motorola has deployed.

However, consumers who want the extra features are willing to pay the extra cost. As I said before, I want these features, and I'd be willing to pay for them.

But you're in the minority, so Uniden's marketing department isn't going to listen. To make matters worse, you're asking for features that require extra hardware! That's not going to fly with Uniden's engineering side. Unless you like tilting at windmills, you should limit your requests to software features.

Where can I get one of these? Can they scan the same frequencies as my Uniden scanner? Are they easy to program, and can they be programmed by computer with included or freely downloadable software? Do the portables use AA batteries?

You should be able to answer all of those questions yourself.

The multiple tuners would also be useful for simultaneously scanning trunked and conventional systems in (true) priority mode.

The rest of us use an old non-trunking scanner to do that. It works far better.

Just because Motorola radios have a certain feature doesn't mean that it wouldn't be useful in another manufacturer's product.

Unidens already have the single-tuner feature - just like Motorola gear.

 

[Jay911]

The scanners allow programming of text tags to be associated with each system/group/channel, and they don't have full alphanumeric keypads. A computer, on the other hand, does have enough keys dedicated to specific characters that make it able to receive the requested information (system id) and transfer it to the scanner.

If you're going to do it via computer, it would be just as easy to use whatever software you prefer that has the download-from-RR feature already built in. As for the specific issue about entering hex characters on a scanner, there's no reason the manufacturer couldn't make six of the function buttons work as A-F keys in keypad entry modes. Other electronic devices I've had do this.

I still stand by my argument that entering one system id for a system, instead of several or many frequencies, is verifiable and less error-prone.

This will only work for Motorola systems and only for the ones which have unique sysids or only one sysid. As slicerwizard said, there are a metric boatload of systems which have multiple sysids. There is no guarantee that a sysid hasn't been re-used; I think I've heard that some US naval vessels share the same sysid across many ships. (That was somewhere on a thread, here.) Plus, the scanner would still have to have a lookup table and somewhere to pick up all this data from. How would it do this? You can't just say that sysid 1234 means that the freqs it should use are a, b, c, and d.. it's not defined like that.

And as I said, other systems may use duplicate sysids (in the case of many MPT1327 systems I monitor - and I'm aware scanners don't manage MPT trunking, but I'd much prefer getting that feature added before your idea), or no sysid at all, in the case of many EDACS systems.

Clock display. Timestamp for the log entries for last 10 heard transmissions, etc.

These are pretty wise ideas. I think there's a "wish list" thread in this forum; if not, we should start one.

 

[nonposter]

And it will be totally useless for any system that doesn't use a SmartZone controller, as they don't announce their alternate control channels.

...OmniLink...

Do you mean adjacent control channels?

Many SmartZone systems are in active use, so being able to scan a system referenced by only it's system id would be widely useful.

The finding-a-system-by-system-id would be independent of adjacent control channel knowledge. Even without knowing the adjacent control channels, the scanner would be able to find other sites by, as I suggested earlier in this thread, scanning frequencies to find control channels that are in the same system.

For OmniLink, multiple system id's would need to be programmed. However, the number of zones in such a system will usually be small, while the number of sites will be very large. I still stand by my statement that a small number of system id's is less error prone than entering all control channel frequencies and easily verifiable.

But you're in the minority, so Uniden's marketing department isn't going to listen. To make matters worse, you're asking for features that require extra hardware! That's not going to fly with Uniden's engineering side. Unless you like tilting at windmills, you should limit your requests to software features.

Are you in Uniden's marketing or engineering departments, or do have you seen their decision making policy documents? Thanks for your opinions on what they will and won't listen to.

Based on your comments, it sounds like you don't think people should ever come up with suggestions for new features, and always be content with currently existing products. Is this accurate?

Where can I get (a Motorola radio)?

You should be able to answer all of those questions yourself.

You said that I should get a Motorola radio. I was asking you about the features and where to get one, since you brought it up.

The rest of us use an old non-trunking scanner to (scan conventional and trunked systems simultaneously). It works far better.

Carrying multiple scanners would not work "far better" for me. I want one device with the features making it most convenient.

Unidens already have the single-tuner feature - just like Motorola gear.

The quote was about adjacent site search, etc. Try not to confuse the readers by taking quotes out of context.

 

[nonposter]

This will only work for Motorola systems and only for the ones which have unique sysids or only one sysid. As slicerwizard said, there are a metric boatload of systems which have multiple sysids. There is no guarantee that a sysid hasn't been re-used; I think I've heard that some US naval vessels share the same sysid across many ships. (That was somewhere on a thread, here.)

Except for the boats, systems that are geographically near to other systems can't have the same system id. The radios would try to affiliate to the wrong system.

When would this be a problem? Here's what I can come up with: system "a" has the same system id as system "b", but "a" is here in Washington, and "b" is in Texas. When I travel to Texas, my scanner would start monitoring "b". Hopefully I would be smart enough to realize that the system in Texas has the same system id, since the scanner would display "Washington TRS," and I would disable that system from being scanned.

Can you point to some system pages in RR's database for systems with the same system id?

Plus, the scanner would still have to have a lookup table and somewhere to pick up all this data from. How would it do this? You can't just say that sysid 1234 means that the freqs it should use are a, b, c, and d.. it's not defined like that.

Pick up what data? If I want to monitor my city's system, and it has system id 1234, I would program my scanner with that system id, and it would find a control channel for that system, and then follow the same logic as existing scanners to follow talkgroup calls, etc. The frequencies for all possible channels are well known; see the link in the second reply in this thread.

 

[slicerwizard]

Do you mean adjacent control channels?

I said alternate control channels. You know, the currently inactive control channels found on every trunked site out there. Your scheme ignores them.

Many SmartZone systems are in active use, so being able to scan a system referenced by only it's system id would be widely useful.

Its limited utility is overshadowed by the fact that many users wouldn't know if it was going to work properly on a given system.

The finding-a-system-by-system-id would be independent of adjacent control channel knowledge. Even without knowing the adjacent control channels, the scanner would be able to find other sites by, as I suggested earlier in this thread, scanning frequencies to find control channels that are in the same system.

Why would you want to do a band scan when the current control channel is broadcasting a complete list of adjacent site control channel frequencies?

Speaking of band scans, the site I'm listening to just switched to the alternate control channel (the controller probably detected some interference on the inbound CC frequency); so how many comms am I going to miss while your scheme looks for the current control channel? What's going to happen in five minutes when the controller decides that the interference is gone and it switches back? More lost comms for me? And what if your scan finds a different site? Now I'm missing all my local comms. Maybe it'll eventually realize that it's on a new site (takes a bit for those site ID OSW's to repeat) and resume its band scan - yay, more lost comms. And if the local site goes into FailSoft, I'll get to watch the scanner search for a non-existent signal for how long? If it just did a proper job of building site lists (as I suggested), it would do a quick check of all the known channels for the current site, realize that none of them were working, and would use the current neighbour list to immediately latch on to a useable neighbour site. Once there, it could even use the neighbour list broadcasts to determine when full functionality had been restored to my local site.

For OmniLink, multiple system id's would need to be programmed. However, the number of zones in such a system will usually be small, while the number of sites will be very large. I still stand by my statement that a small number of system id's is less error prone than entering all control channel frequencies and easily verifiable.

Except that it's very error prone if the system happens to not use SmartZone hardware.

Are you in Uniden's marketing or engineering departments, or do have you seen their decision making policy documents? Thanks for your opinions on what they will and won't listen to.

Where have you been for the last two decades? Skimping on hardware has been their standard M.O.

Based on your comments, it sounds like you don't think people should ever come up with suggestions for new features, and always be content with currently existing products. Is this accurate?

Nice strawman. Be sure to keep it well fed and watered.

You said that I should get a Motorola radio. I was asking you about the features and where to get one, since you brought it up.

If you're seriously considering one, go educate yourself. Don't expect others to spoon feed you.

The quote was about adjacent site search, etc. Try not to confuse the readers by taking quotes out of context.

Your comment about Motorola vs Uniden features was in a paragragh of its own. There was nothing there about adjacent site searching. Also, in my post, to which you were replying, I agreed that adjacent site handling should be added, so why would you be repeating that?

Anyway, I can see that this discussion is becoming pointless, so PM Paul Opitz with your ideas and see what his response is.

 

[bassmkenk2508]

To tag along to the ending of this discussion, I dont think Uniden will put a bunch of "R&D", money and hardware/software development into something that will only benefit 1 of 3 types of trunked systems: Motorola (as opposed to EDACS and LTR).

Motorola is only a chunk of the market. EDACS and LTR systems jump frequency by pre-assigned LCNs, not the frequency numbering scheme that Motorola utilizes (forgot the proper name it is called). So this eliminates them from using the benefits of the newly proposed feature.

And I agree, the time it would take to find the next control channel being utilized would be too great for comfort. Crowded bands, and maybe other interfering factors, would take part in the important variable of time. Time affects efficiency.

If mistakes are a concern, just double check what you type in; doesn't take much time. If you find a mistake in the freqs found on here, submit them to the database so others wont have to worry as well.

Going 10-7.

 

[Jay911]

If I want to monitor my city's system, and it has system id 1234, I would program my scanner with that system id, and it would find a control channel for that system, and then follow the same logic as existing scanners to follow talkgroup calls, etc.

How would it 'find a control channel'? System IDs don't have any correlation to control channel frequency or band. Some systems even have (the ability to have) sites of different bands, i.e. VHF/UHF/700/800, in the same system.

In my city we have several 800mhz trunk systems - I'll simplify it to 800mhz and not other bands, just for the sake of argument. If I follow your logic and program my scanner with sysid 753f, how does it know which of the 8 control channels (six for the system 753f, and two for each of the other two systems in town) to pick?

If you are banking (pun unintended) on the system to announce its sysid, I can sort-of see your line of thinking. But other than matching the sysid to what's announced on the control channel, what benefit would this bring? I still think you'd need some way of retrieving the talkgroup IDs, etc., for this to be of any positive use IMO. For example, if I head into my hometown and tell the scanner I want to listen to sysid 401D, what is it that the scanner will do in your idea? Will it 'know' to check only 800mhz control channels, and simply find any one that announces 401D and then act like it's in Search mode with no text labels on any TGs/IDs? Will it somehow download the talkgroup and ID lists from somewhere (i.e. RadioReference) and use them?

How will it know where to search for a control channel in the first place?

The frequencies for all possible channels are well known; see the link in the second reply in this thread.

This is how the scanners already do trunking; it's how CC Only mode is possible (Control Channel, not Close Call). The trunk system says "go to channel 601", not "go to frequency 866.0375". However, this bandplan is NOT universal and does NOT extend to the bands other than 800mhz. There is an 800mhz system near me that is unmonitorable by the current batch of scanners because it uses a splinter format that is not part of the list posted on Batlabs. And the base/offset/spacing values in the VHF and UHF bands are done in place of having a set frequency plan as we do in 800.

 

[nonposter]

I said alternate control channels. You know, the currently inactive control channels found on every trunked site out there. Your scheme ignores them.

I didn't realize that every detail of every possible scenario had to be explained in excruciating detail. Sorry if I missed some steps, or if I didn't think of some edge cases. Does that make the general idea so bad?

Why would you want to do a band scan when the current control channel is broadcasting a complete list of adjacent site control channel frequencies?

I agree that using adjacent site control channels makes it more efficient. I did mention one way that the scanner could find other control channels even if it didn't have the adjacent control channel info.

Speaking of band scans, the site I'm listening to just switched to the alternate control channel (the controller probably detected some interference on the inbound CC frequency); so how many comms am I going to miss while your scheme looks for the current control channel? What's going to happen in five minutes when the controller decides that the interference is gone and it switches back? More lost comms for me? And what if your scan finds a different site? Now I'm missing all my local comms. Maybe it'll eventually realize that it's on a new site (takes a bit for those site ID OSW's to repeat) and resume its band scan - yay, more lost comms. And if the local site goes into FailSoft, I'll get to watch the scanner search for a non-existent signal for how long? If it just did a proper job of building site lists (as I suggested), it would do a quick check of all the known channels for the current site, realize that none of them were working, and would use the current neighbour list to immediately latch on to a useable neighbour site. Once there, it could even use the neighbour list broadcasts to determine when full functionality had been restored to my local site.

Hopefully, the scanner manufacturers won't just take my basic idea and limited knowledge of control channel data to implement the feature.

If you're seriously considering (a Motorola radio), go educate yourself. Don't expect others to spoon feed you.

You said, "As for your strongest site search, Motorola radios (which is what you should get) manage to do it just fine with only one tuner." Since you told me that I should get one, I asked a reasonable question about where to get one, yet you expect me to know everything about them.

 

[nonposter]

How would it 'find a control channel'? System IDs don't have any correlation to control channel frequency or band. Some systems even have (the ability to have) sites of different bands, i.e. VHF/UHF/700/800, in the same system.

In my city we have several 800mhz trunk systems - I'll simplify it to 800mhz and not other bands, just for the sake of argument. If I follow your logic and program my scanner with sysid 753f, how does it know which of the 8 control channels (six for the system 753f, and two for each of the other two systems in town) to pick?

In message #3 of this thread, I explained my idea of one implementation: The scanner would be programmed with a band (eg 800MHz) and system id (eg 753f), and would check each possible channel in that band until it found a control channel belonging to the desired system (753f).

If you are banking (pun unintended) on the system to announce its sysid, I can sort-of see your line of thinking. But other than matching the sysid to what's announced on the control channel, what benefit would this bring? I still think you'd need some way of retrieving the talkgroup IDs, etc., for this to be of any positive use IMO.

Yup, the talkgroup ids would still need to be programmed. The idea is that the physical parts of the system (eg frequencies) wouldn't need to be programmed, just the system id.

For example, if I head into my hometown and tell the scanner I want to listen to sysid 401D, what is it that the scanner will do in your idea? Will it 'know' to check only 800mhz control channels, and simply find any one that announces 401D and then act like it's in Search mode with no text labels on any TGs/IDs? Will it somehow download the talkgroup and ID lists from somewhere (i.e. RadioReference) and use them?

How will it know where to search for a control channel in the first place?

As noted above, if it's programmed to be a 800MHz system, it would search all of the 800MHz channel frequencies for a control channel belonging to system id 401D. After finding a control channel for that system, if you had talkgroup id's programmed, and you're in id scan mode, it would scan those ids.

Configuration of talkgroup id's would be the same as today's scanners.

This is how the scanners already do trunking; it's how CC Only mode is possible (Control Channel, not Close Call). The trunk system says "go to channel 601", not "go to frequency 866.0375". However, this bandplan is NOT universal and does NOT extend to the bands other than 800mhz. There is an 800mhz system near me that is unmonitorable by the current batch of scanners because it uses a splinter format that is not part of the list posted on Batlabs. And the base/offset/spacing values in the VHF and UHF bands are done in place of having a set frequency plan as we do in 800.

This might only be convenient for 800MHz systems. I don't have any experience with non-800MHz systems.