A Post to GMRS Radio Manufacturers

[mrgmrs]

Memory Banks/Groups

Another feature I like and use is memory banks/groups.  It is nice to be able to associate certain memories in one group (e.g., home channels), another set of memories in another group (e.g., brother's home channels), etc.  That way, while visiting various locations, one can switch to the group which contains the desired channels only.  Among other benefits, this speeds up scanning.

[mrgmrs]

mbrun, I agree with you regarding BuyTwoWayRadio's positive role in advancing and improving GMRS.

Another person who has done so is Randy from youtube channel NotaRubicon.  It's obvious that GMRS manufacturers are aware of him and that he is an influencer.  For example, when he mentioned nine or so issues with a recently introduced GMRS radio, the manufacturer responded and fixed the bulk of the issues with a firmware update immediately.

Another good contribution is mygmrs.com.  Its forum appears to be the main GMRS watering hole.  The repeater database is also appreciated.

Thanks for mentioning you were glad to see this thread started.  I appreciate your and everyone's comments.

[mrgmrs]

Unnecessary Limitations

One head-scratcher for me is when manufacturers put unnecessary limitations in place.

From the perspective of repeater users, the various manufacturers have been improving things, especially lately.  For example, split tone capability appears to be the norm with the newer radios.

Now let's look at the ability to store the same repeater frequencies with different tones in different memories.  Not long ago, some radios didn't support this.  Good news: lately this capability is becoming the norm.  Kind of sort of in some cases.

Though it has a large number of memories, one radio allows for only nine such extra repeater-focused memories. Why was the decision made to allow only nine?  The large number of memories exist already.  Why not let the radio operator use the existing memories to store as many different repeater frequency / tone combinations as needed?

Correcting this does not involve anything such as a hardware change.  All that is needed is to not put unnecessary limitations-by-software in place to begin with.  For radios already released with such a limitation, a firmware change could remove it.

[pcradio]

38 minutes ago, mrgmrs said:

Unnecessary Limitations

Correcting this does not involve anything such as a hardware change.  All that is needed is to not put unnecessary limitations-by-software in place to begin with.  For radios already released with such a limitation, a firmware change could remove it.

Yep, a frequency entry is a tiny byte array. We will remember the brands who can't accommodate a simple design element like this.

[mrgmrs]

As I mentioned in the paragraph I inserted at the top of my original post, I created this current reply you're reading as a summary section.  If/as additional points are made which could aid manufacturers and buyers, I will edit and update this same section.

Here is the running list, in no particular order:
•    Ability to store multiple versions of a GMRS repeater frequency with different tones is good
•    No arbitrary limit of how many of the above can be stored
•    To expand on the second point immediately above, careful about designing arbitrary limits in general
•    Tones should be specific for each memory and not across-the-board
•    When designing more capable "non-bubble-pack" radios, provide wide band and narrow band capability, not narrow band only
•    Double check firmware before new radios are released or when updating firmware.  (E.g., don't release radios with access tones or narrow band set in memories.)
•    Careful about proprietary designs.  (E.g., naming tones with proprietary names may be ok for bubble pack radios, but for more capable radios I'd stick with naming conventions such as 107.2, D025N, etc.)
•    Memory banks/groups are nice
•    Test OEM radio programming software adequately before releasing it.  These are often released with obvious, main-function bugs.  It's one thing to not catch more obscure error legs, but main-function bugs should be detected and fixed during testing.
•    OEM programming software should support a good, 21st century UI experience, such as copy/pasting
•    Good documentation please.  Missing, pertinent information is frustrating.  So is poor English.
•    The ability to field program a radio (including frequencies) using its keypad and/or knobs is desirable
•    For mobile radios, please use a DIN style mic connector.  This is the type which has a strain-relieved cable and a rotating, threaded, locking collar.  This is more robust than the RJ-45 style of connector.
•    Attention-to-detail niceties enhance a user's experience.  Examples can be found in the "Examples of Good Execution" portion of the original post.
•    Admittedly my personal opinion: non-bubble-pack radios should look professional/commercial rather than gimmicky

•    HTs should be stable (i.e., not prone to tipping over) when placed vertically on a flat surface. E.g., the end should be squared off, not rounded.

[gortex2]

I hate to laugh but with that list your talking a $500 radio....A reputable manufacturer does most of above if you look at part 90 stuff. Radios dont come programmed, software is tried and true and firmware releases are tested. 

[mrgmrs]

I respectfully beg to differ, but it doesn't take a $500 radio to incorporate the points I've presented.  Good documentation...$20 radio should have it, $500 radio should have it.  And most of the other points do not involve expensive changes nor hardware changes.  Most of these are cases of making simple, good decisions when programming the radio anyway.  So why not do things such as not imposing an arbitrary limit regarding how many of the abundantly provided memories one can program with multiple occurrences of repeater freqs/tones?  The manufacturers of the cheap line of GMRS radios have already demonstrated a willingness to adopt such changes.

  -- mrgmrs

[BoxCar]

2 hours ago, mrgmrs said:

I respectfully beg to differ, but it doesn't take a $500 radio to incorporate the points I've presented.  Good documentation...$20 radio should have it, $500 radio should have it.  And most of the other points do not involve expensive changes nor hardware changes.  Most of these are cases of making simple, good decisions when programming the radio anyway.  So why not do things such as not imposing an arbitrary limit regarding how many of the abundantly provided memories one can program with multiple occurrences of repeater freqs/tones?  The manufacturers of the cheap line of GMRS radios have already demonstrated a willingness to adopt such changes.

  -- mrgmrs

Quality isn't free. It takes time and money to develop many of the things you believe should be available in a $20 radio. Some of those features may, at some point, trickle down to bottom tier radios but it would only happen after the costs of the initial development and testing had been paid for. Bottom end radios are just that, bottom end. Many are poor reverse engineered copies of more expensive offerings by other manufacturers but then again, they are poorly engineered copies that will not have any quality components or testing other than it powered up - sometimes.

[pcradio]

It does not require $500 to produce the requested radio. It may require talent, with which the company that has it will survive.

[WRNA236]

24 minutes ago, pcradio said:

It does not require $500 to produce the requested radio. It may require talent, with which the company that has it will survive.

I agree that it shouldn't take $500 to get some of this stuff but I do think it's unreasonable to expect all the way down to a $20 radio.  Bubble pack radios aren't even made to be repaired or aligned, they are use-and-toss.  So expecting more than a basic user manual is at best hopeful. 

Also the talent you allude to is not limitless.  If you want a radio to hit a price point there's only so many NRE hours they can afford to throw at it.  So if you want the time spent writing manuals it will likely come at the expense of design or quality in the actual device. 

Same with including CPS.  I'm one who thinks a radio should have free or reasonably priced software to program it but I also don't expect it to be a feature-rich experience.  A basic tool to get the job done is fine. 

[IanM]

On 9/2/2021 at 3:12 PM, WRNA236 said:

I agree that it shouldn't take $500 to get some of this stuff but I do think it's unreasonable to expect all the way down to a $20 radio. 

Agreed, but on some of these CCRs I think a lot of it comes down to editing the firmware for better functionality. I'm thinking of the OP's first few points—TX locked to specific channels and blanket codes across channels. I bought a whole handful of different CCR HTs to test for my purposes, and the GMRS-V1 and UV-5G are good examples of this. They're based on the UV-82 and UV-5R, both fairly capable radios (if the hardware leaves a lot to be desired). As many of us know (and I discovered the hard way), the V1 is locked in and can't add additional TX channels in the memory. The 5G originally shipped with pre-programmed and unchangeable tones. We know that fixing these isn't a matter of re-engineering a new device, and, for the 5G, a new firmware set was released unlocking those limitations. It's entirely possible, and it's still a ~$30 radio. 

But I agree that work is not free, and for GMRS I don't think there's a huge impetus for it—if things are selling well, why change it? I think we have to keep in mind that the use for the vast majority of GMRS sets is just basic communication between a pair of them, i.e. the bubble-pack sets.  And then there's the tinkerers who don't really care, and just want something throwaway for a limited use.

That said, I'm also really impressed with the Wouxuns so far for my purposes—solid hardware, fairly capable software and a decent user guide, well worth the premium. It sounds like, at the very least, distributors like BTWR.com are listening to guys like Randy, and Wouxun is listening to their distributors. 

[plarkinjr]

Ya know, a radio could be created which is simple for casual users who never want to touch a computer, and may only really be interested in simplexing with other GMRS users who may or may not be using the same equipment, but at the same time give it the capability to do more advanced things via programming software like: 

• Repeaters of same frequencies but different tones
• Repeaters with split tones
• Scan out of band (e..g. 2m/70cm HAMs, Police, Fire, etc)
• DTMFs per channel
• Power level per channel
• etc etc

Such things could be hidden behind an "expert" menu from the keyboard, or even ONLY programmed via computer software (Mac, Linux, Windows, etc).

That being said, @pcradio mentioned "CHIRP is not much better" ... Well, I've got to say it is worlds better than the Wouxun software for KG-935G!   While CHIRP has its frustrations, the Wouxun software is absolutely horrendous as far as the channel memory editor is concerned.   I have some 10 year old LED Sign software which looks like WindowsXP with menus completely in Chinese, but it is much easier to use than the Wouxun KG-935G software.  But there's a wait-list for Wouxuns, so nobody there sees any benefit in fixing/making-usable their programming software.

I've not checked into RT Systems software, but with a proprietary cable, and no trial system that I can see, I'm not sure it is any better than CHIRP.  Plus, it does not support some of the weird radios I have (which are  supported by CHIRP).   Until a radio manufacturer produces quality software to program their under-$200 radios, CHIRP is the way to go.   So, not counting RT systems, here's how I see it:

1. horrible factory software
2. frustrating (but consistent) CHIRP
3. wonderful factory software

#1 is the norm, #3 I've never seen.  So focusing my effort on #2 (CHIRP) is the forced compromise. It provides a fairly consistent interface across radios, so I don't have to learn the unique design quirks from the various software "engineers" at Baofeng, Retevis, Wouxun, etc.   (Why, for example, did Wouxun choose to put the channel label in the 11th column, way over on the far right of the screen, vs CHIRP which puts it in column 2, on the left side of the screen, right next to the frequency, and one hop from the channel number?  Why?? WHY???    And "Hello:  Copy/Paste" from another program like, I dunno, Excel?  Nope, sorry.)

ETA:  (I forgot to mention before I hit SEND)   It wouldn't seem unreasonable to me at least that a manufacturer couldnt release a "basic" radio for under $100, but sell an add-on "subscription" (if you will) for another $50 to provide great programming software to unlock advanced features and/or long-term support.  Missed revenue opportunity on their part I guess.

[MichaelLAX]

18 hours ago, plarkinjr said:

It wouldn't seem unreasonable to me at least that a manufacturer couldnt release a "basic" radio for under $100, but sell an add-on "subscription" (if you will) for another $50 to provide great programming software to unlock advanced features and/or long-term support. 

Not unreasonable for you as the consumer, but obviously unreasonable or at a minimum not worth the effort from the point of view of the manufacturers. 
 

The manufacturers know going in that odds are that CHIRP will get ahold of one of their radios and develop a driver for it. 
 

I remember in 2010 the UCLA Entertainment Symposium had a panel entitled: “Piracy: How Can We Compete With FREE?”

While CHIRP is not piracy, it is still difficult to compete with FREE!

so by its very nature you are only going to get baseline software included by the manufacturers.

 

[Lscott]

18 hours ago, plarkinjr said:

Ya know, a radio could be created which is simple for casual users who never want to touch a computer, and may only really be interested in simplexing with other GMRS users who may or may not be using the same equipment, but at the same time give it the capability to do more advanced things via programming software like: 

• Repeaters of same frequencies but different tones
• Repeaters with split tones
• Scan out of band (e..g. 2m/70cm HAMs, Police, Fire, etc)
• DTMFs per channel
• Power level per channel
• etc etc

Such things could be hidden behind an "expert" menu from the keyboard, or even ONLY programmed via computer software (Mac, Linux, Windows, etc).

That being said, @pcradio mentioned "CHIRP is not much better" ... Well, I've got to say it is worlds better than the Wouxun software for KG-935G!   While CHIRP has its frustrations, the Wouxun software is absolutely horrendous as far as the channel memory editor is concerned.   I have some 10 year old LED Sign software which looks like WindowsXP with menus completely in Chinese, but it is much easier to use than the Wouxun KG-935G software.  But there's a wait-list for Wouxuns, so nobody there sees any benefit in fixing/making-usable their programming software.

I've not checked into RT Systems software, but with a proprietary cable, and no trial system that I can see, I'm not sure it is any better than CHIRP.  Plus, it does not support some of the weird radios I have (which are  supported by CHIRP).   Until a radio manufacturer produces quality software to program their under-$200 radios, CHIRP is the way to go.   So, not counting RT systems, here's how I see it:

1. horrible factory software
2. frustrating (but consistent) CHIRP
3. wonderful factory software

#1 is the norm, #3 I've never seen.  So focusing my effort on #2 (CHIRP) is the forced compromise. It provides a fairly consistent interface across radios, so I don't have to learn the unique design quirks from the various software "engineers" at Baofeng, Retevis, Wouxun, etc.   (Why, for example, did Wouxun choose to put the channel label in the 11th column, way over on the far right of the screen, vs CHIRP which puts it in column 2, on the left side of the screen, right next to the frequency, and one hop from the channel number?  Why?? WHY???    And "Hello:  Copy/Paste" from another program like, I dunno, Excel?  Nope, sorry.)

ETA:  (I forgot to mention before I hit SEND)   It wouldn't seem unreasonable to me at least that a manufacturer couldnt release a "basic" radio for under $100, but sell an add-on "subscription" (if you will) for another $50 to provide great programming software to unlock advanced features and/or long-term support.  Missed revenue opportunity on their part I guess.

Selling an "add on" software by the manufacture for their own radios? A company has to make a decision, are they primarily a hardware vendor or a software services provider. Some try to do both and end up doing neither well.

What is being proposed is the business model used by example Motorola, now Kenwood looks like they too are moving in that direction. You pay for the basic software, then again for each additional feature. You can end up paying on a per unit basis too. Now you have to keep track of which radio(s) have what licensed features enabled and so on. Even the code plugs are directly tied to an individual radio by serial number. You simply can't take a code plug for one and directly load it in to another radio identical hardware wise because the enabled features may be different.

If the radio programming software is a for purchase type option, well it had better work and the vendor needs to be quick about fixing bugs. Forget about "feature creep" I want what's there already to "just work", no excuses. One way to kill a great hardware product is crappy to non existent support. I have a low threshold for buggy software and even less for vendor excuses why it's not fixed or have no intention of fixing it, ever.

The danger with any third party software are several.

One most likely the hardware vendor doesn't document the communication protocol nor the code plug content structure. With CHIRP its all done through lucky guess work, reverse engineering and experimentation. No guarantee that a later hardware version won't break to software. Even worse that a bug in the software won't "brick" your radio. A few have had that unfortunate experience.

Second while CHIRP presents a consistent user interface across multiple radios you can loose access to features that are specific to a particular model. In that case you're back to using the hardware vendor's software anyway. Remember CHIRP can only implement what can be reversed engineered, and even then the developer may choose to note it's just experimental so any bugs discovered may never get fixed because they don't have the time, lost interest or just don't have the radio to experiment with any longer. Remember it's free, so what did one expect for zero cost, so there is little motivation for the developer to spend heaps of time on it.

 

[mrgmrs]

I have also added (by editing) the following new item to the running list of my Sept. 2 entry, located earlier above.

HTs should be designed so they can sit vertically on end without tipping over.  Without mentioning names, I'm aware of at least two HTs made by two manufacturers which are tippy when set on a table.  Slightly brushing them makes them fall down, which can illicit some of the seven words that George Carlin stated cannot be said over the air.

Note that the aforementioned radios are prone to tipping due to their ends having a rounded style with nubs added in an insufficient attempt to provide standing stability.  BTW, the two manufacturers involved are in the top-tier of 2-way radio manufacturers.

As Randy from NotaRubicon might say, "For the love of Xenu, don't make tippy radios." 
 

[WRFP399]

Lets keeps this in perspective. Midland's radios are marketed towards your basic user who wants to talk between their kids while at a park and/or for off roaders who want to talk between machines. The people on this board are "more advanced" users of GMRS in general w/ things like repeaters and linked nets. Midland isn't marketed at us.

[Ian]

For the love of Xenu, why isn't the 275 programmable like the 400?  I should __not__ have to ditch handheld-control-head mounting convenience for the sake of PC programmability.  For Midland, it would be easy to hide advanced features behind a PC programming cable, but for anyone __but__ midland, implementing them is simply __impossible.__

 

They're __so close__ to actually making a __really great__ radio, and not just "Eh, good enough" radios…

[OffRoaderX]

3 hours ago, Ian said:

For the love of Xenu...

Xenu shall reward you handsomely.