what features would you add to the PRO-106

[al95]

It's just a question. What features would you add to the PRO-106 if any? I would like to see the auto mute feature, found in the BCD396T.

 

[SCPD]

Instant Reply of last x seconds of audio.

 

[mtindor]

A few hundred dollars worth of brute filtering to nail anything below 25 mhz, 88-108 Mhz, VHF TV band, and 861-865 Mhz.

Yeah, I know - it isn't going to happen, would add size/weight/cost, and maybe even more than "a few hundred" dollars. But it would be nice, and I'd scrape my pennies up and save for one.

This applies to the PRO-106/197 and GRE PSR-400/500. I would _not_ want to sacrifice the great sensitivity.

Mike

 

[kerrinnes]

I would add bluetooth for a headset and wireless connection to a computer

 

[KI6ABZ]

WIDE FM reception along with Broadcast AM/FM reception. The new Yaesu mobile has this (along with a stereo AUX input), as do the Yaesu and Kenwood HT's. It really adds a lot of utility to the device.

I'd also like to get tv audio and digital-tv audio. I've gotten a lot of utility out of being able to hear TV while on the move, and now that TV is going digital, our scanners should be able to keep up with that.

It would also be slick if we could pop in an SD card and record straight to MP3 audio, along with file tagging of freq and text tag.

 

[KI6ABZ]

A few hundred dollars worth of brute filtering to nail anything below 25 mhz, 88-108 Mhz, VHF TV band, and 861-865 Mhz.

Yeah, I know - it isn't going to happen, would add size/weight/cost, and maybe even more than "a few hundred" dollars. But it would be nice, and I'd scrape my pennies up and save for one.

This applies to the PRO-106/197 and GRE PSR-400/500. I would _not_ want to sacrifice the great sensitivity.

Yaesu and Kenwood HT's both have broadcast receive. Icom wideband receivers can also receive broadcast and HF. My Kenwood handheld transceiver is so small that I could fit 5 of them in the space of 1 Pro-106.

And all of those radios cost less than the Pro-106.

 

[gmclam]

PRO-106 features

WIDE FM reception along with Broadcast AM/FM reception. ... I'd also like to get tv audio and digital-tv audio.

While this is a nice feature to have, I understand the technical requirements to do so and feel it should be on a different scanner, not the PRO-106.

It would also be slick if we could pop in an SD card and record straight to MP3 audio, along with file tagging of freq and text tag.

I would like to see a memory card slot, such as the SD card, but used to load frequencies, log statistics of reception, record audio and a myriad of things. Two outputs that scanners lack are LINE OUT and a physical discriminator output.

Create a robust serial protocol to program, control and query the scanner. Make that protocol OPEN to everyone so that applications can be written.

Make the battery charger 'turn off' when batteries reach a full charge.

 

[SOFA_KING]

This has been done to death...but here we go again.

P25 ENCRYPTION MUTE/MASK! (conventional channels...double low beep at start and hold for reply)

MDC1200 MASK THAT WORKS LIKE BIG /\/\ DOS.

SEARCH OPTION TO SEARCH ONLY CTCSS/DCS/NAC (no CSQ hangups!)

Just a few of many that actually could be done without designing a new scanner.

Phil

 

[Astrak]

This has been done to death...but here we go again.
Phil

It certainly has...

http://www.radioreference.com/forums/radio-shack-scanners/131808-pro-106-firmware-1-7-wish-list.html

 

[hcpholder]

Talkgroup ID look-up! Gets hard to look up "text tags" when you can't remember what you have in that big thing!

 

[al95]

It certainly has...

http://www.radioreference.com/forums/radio-shack-scanners/131808-pro-106-firmware-1-7-wish-list.html

I missed that tread. Thank-you for letting me know. Now I can see that I'm not the only one wanting auto mute, and some other feature I was in the other tread.

 

[ratboy]

A few hundred dollars worth of brute filtering to nail anything below 25 mhz, 88-108 Mhz, VHF TV band, and 861-865 Mhz.

Yeah, I know - it isn't going to happen, would add size/weight/cost, and maybe even more than "a few hundred" dollars. But it would be nice, and I'd scrape my pennies up and save for one.

This applies to the PRO-106/197 and GRE PSR-400/500. I would _not_ want to sacrifice the great sensitivity.

Mike

I don't see why filtering would add all that much to the cost of the radio, and I could live with the size increase. If designed in from the start, the price shouldn't be all that much higher, as the component cost isn't much and the CPU could be designed to switch the filters as needed..

 

[ratboy]

I would really like the SD card (and only an SD card, not one of the other formats, I don't want to buy two formats of flash memory cards, as everything I have is SD) recording idea, using them in camcorders is the best idea in a long time, as it removes one more moving part, and allows a smaller size. Adding a card slot and the firmware to record and tag it on a scanner would be a great idea, as long as it's done correctly.

But the best feature would be a way to get the radio to mute on the unimportant part of a transmission, instead of the part that really means anything! It happens constantly, and drives me nuts!

 

[N8IAA]

My only wish is for a remote head. And don't suggest that I buy a Uniden. No way, no how.
Larry

 

[gmclam]

My only wish is for a remote head. And don't suggest that I buy a Uniden.

This is why I want the robust open serial connection & protocol. Then a remote head could be designed by 3rd parties or GRE and make GRE products an even better choice.

 

[kayi4cle]

I want more Scan Lists. It doesn't make sense to have a radio with all these great features and be so limited. What were they thinking?

 

[gmclam]

I want more Scan Lists. It doesn't make sense to have a radio with all these great features and be so limited. What were they thinking?

Scan lists require non-volatile memory. Memory costs $$$. It is always a trade-off in determining how much memory to design into a product. This is also why I would like to see something like support for an (SD) memory card slot. Then each user can use whatever amount of memory they desire (to purchase).

 

[jnewell]

I want more Scan Lists. It doesn't make sense to have a radio with all these great features and be so limited. What were they thinking?

After using (happily) both my PSR-600 and my BCD-396XT, I have to agree with that.

 

[PanJurekMrJerry]

Wide FM, AM Broadcast, SD Card Slot, USB Slot for a Mini Keyboard so that you do NOT have to use a computer. Hey a SD Card slot and mini keyboard, who would need a computer? How about more Frequency slots for the different types of Trunked radio Systems? Oh yeah, and HD AUDIO for both IBOC AM/FM and HD audio for TV audio reception.

 

[Mike_G_D]

Scan lists require non-volatile memory. Memory costs $$$. It is always a trade-off in determining how much memory to design into a product. This is also why I would like to see something like support for an (SD) memory card slot. Then each user can use whatever amount of memory they desire (to purchase).

Actually, scan lists in the GRE/RS high end units are not actually memory locations. This is a common misconception caused by carrying the "scan list = bank" analogy too far. Scan lists, as used in the PSR500/600 and PRO-106/197, are better thought of as tags or pointers to actual memory locations. The memory locations in the scanner are represented as blocks and cataloged by the Object ID number. Objects take up one or more blocks of memory depending on the kind of object (TSYS, TGRP, conventional frequency, etc.).

This is why you can have an object belong to any number of scan lists as you like but not use up any more memory space as would be the case in a bank scanner. One object could belong to one or all twenty-two scan lists and the same amount of memory would be used either way. Each scan list also has no real "limit" in the sense of how many objects can belong to it. You could have every object in a scanner belong to one list and even if the entire memory of the scanner was used it would be no different then if no objects belonged to any list or if each belonged to different lists. This is actually very efficient and quite flexible.

Nevertheless, and perhaps even more so because of the above, I, too, would like to have more scan list categories. Due to the above, rather than total memory capacity being the limiting factor it is more likely that some form of memory structure construction issue is the problem. This might be some low level code that was written to form the overall structure of the memory (22 scan list limit, 32 frequencies limit for TSYS's. etc.) and to change it might be either impossible or very difficult (requiring a near total rewrite of the memory organization of the scanner).

Personally, I would like to see another layer of categorization in addition to the scan lists (say sub lists). One way of doing this is to create something akin to the "TSYS" for conventional frequencies as someone else mentioned some while ago and called it a "CSYS". This is because the TSYS's can be used to add a layer of organization in addition to the scan lists - great for trunking systems but of no help to conventional frequencies.

Ideally, I would like to be able to categorize with three layers regardless of type of object (talk group or conventional frequency). For me, I would use the layers as follows:

Layer 1: Location (i.e. North San Diego County).

Layer 2: Broad Usage Category (i.e. Law Enforcement, Fire, Parks, Roads, Transportation, etc.).

Layer 3: Sub-category of usage for geopolitical specifics (i.e. County, State, Federal, Multi-use, Private, etc.).

The above layers would be user defined so you could use them any way you want - I just used examples of how I would do so. Ideally, there should also be a minimum limit of 10 divisions for each layer (with 3 layers this should be more than sufficient to specifically categorize an object in a very flexible and precise manner). Nevertheless, for maximum flexibility and to appease as many potential users as possible you could make the top layer have say 50 or 100 divisions while layers 2 and 3 could have less and the user should be allowed to not use a layer at all if so desired.

And, of course, talk groups should be allowed to belong to multiple trunking sites if desired rather than having to be entered multiple times for multiple sites. Ideally, a TSYS should define a trunking system containing a name, SYSID, type (Motorola, P25, EDACS, etc.), and modulation (wide, narrow) with capacity for multiple sites which each contain a name (if applicable), site number (if applicable), and location (if desired) plus the primary and alternate control frequencies relevant to that site. Then, talk groups could be "linked" or "associated" to one or more of these sites as desired so duplication would not be required. Alternatively, if the above cannot be done, at least allow talk groups to belong to multiple TSYS's in the current configuration if at all possible.

Also, usage of the SYSID for filtering the TSYS's would be a very useful feature IF it could be made to work effectively. Alternatively, or in addition to that, it would be useful to be able to assign priorities to the trunking site's control channels (try this one first, then this, etc.) or, if the multiple sites belonging to a TSYS option could be made to work as outlined above, then assign priorities to the individual sites (try this one first, then this, etc.). In each case, higher priority sites (or control frequencies) would be checked first on each pass and given the most due consideration during signal loss due to drop outs and fading.

I've also been toying with an idea for a "DSYS" object (for want of a better term) wherein conventional frequencies used in semi-duplex split frequency simplex systems could be scanned more efficiently than they are in current configurations. For example, the well known California Highway Patrol systems. Most of the channels used throughout the state are of the above format wherein the mobiles respond to the bases on a separate frequency and are not repeated. Traditionally, when scanning these types of systems the user would have to program two sequential channels with the base and mobile frequency respectively and leave the delay for each channel off. This "sort of" works but if the mobile does not respond quickly enough or the signal is fluctuating the mobile response may be missed (even if the signal is strong enough). Since trunking systems are set up with multiple frequencies being checked I would think it a relatively simple matter to create a type of object that has two frequency slots for a base and mobile pair. When scanned, that object looks at both of those frequencies for a specific time before moving on. If either frequency has a signal with the correct tone and sufficient strength, etc., the scanner stops on that object and unmutes; when the signal stops it quickly scans between only those two frequencies within that object for a specified time (just the user defined delay time as used on any other object) before moving on. This would make it far more likely that one could catch the mobile response if within range than using the traditional method. Additionally, the two frequencies should be able to have their own respective squelch modes, CTCSS, DCS, even NAC, for maximum flexibility - I know the CHP don't (as far as I know) use separate tones but I would want the system to be as flexible as possible and not limited to just one methodology. Many taxi systems also use a similar method. Also, because when looking at this object the scanner is rapidly scanning between these two frequencies, it will not matter if the mobiles are talking to each other on the base output frequency, as the CHP routinely does for car-to-car use, as they will still be caught if in range. Oh well, just a thought.

I don't necessarily expect that all of the above would be feasible for these current units with a simple firmware change but - perhaps on future units.

-Mike