[chirp_devel] [PATCH 1 of 3] [id31] Backport ID-51 mode logic to ID-31. Related to #553

[Dean Gibson AE7Q]

On 2013-02-21 16:12, Dan Smith wrote:
>> +MODES = {0: "FM", 1: "NFM", 3: "AM", 5: "DV"}
> The ID-31A is UHF only, and thus has no support for AM. That's why I
> had it the way I had it, although I'm fine making it indexed to better
> mesh with the ID-51A code (until/unless we find that they used that
> middle bit for something :)
>
> Thanks a bunch for tackling this!

I see Tom back-ported the relevant differences between the ID-51 and 
ID-31, which I'd already done (see multiple eMails from Monday) three 
days ago, but was saving until the ID-51 submission was accepted.  I was 
going to create a separate bug, and submit my ID-31 changes tonight;  
he's saved me the trouble, and I will discard my changes.

The only thing I would suggest for the future, is that if someone is 
going to duplicate the advertized effort of someone else, that he/she 
give notice of doing so, so that the first person doesn't continue 
working on the same thing.  Fortunately, that did not happen in this case.

As you note, the ID-31 does not have "AM" mode.  The modes table in the 
ID-51 and ID-31 follow the modes in the ID-880H:

static char const * const modulations[ 8 ] = { "FM", "FM-N", "?2?", 
"AM", "AM-N", "DV", "?6?", "?7?" };

Except of course, that the ID-51 & ID-51 radios do not support "AM-N", 
but the ID-800H, ID-880H, and IC-2820H do (in both the radio menus and 
the Icom PC software).  The tables in the IC-2820H and ID-800H are 
slightly different, but contain the same modes. Obviously, the ID-31 and 
ID-51 are using the tables (and other architectural commonalities) from 
the more modern ID-880H radio.

I'm just curious as to methodology for Chirp development:  Do we inherit 
one radio from another, or create a common "abstract" radio , and then 
inherit both from that?

-- Dean

ps: Ref your comment in bug 553, Java does not limit you to one class 
per file.