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.