[chirp_devel] Icom ID-51

[Dan Smith]

> After looking at the code for the ID-31, I think that the decoding
> for the modulation type may be wrong for that radio as well:  I just
> looked at the C++ code I have for the six Icom D-Star radios I
> included in DStarCom, and NONE of them used separate bits for "DV"
> and "FM-N" modes;  instead, the fields were all *two-bit* (literal
> meaning!) fields that indexed into an array of at least three
> different modulation modes.  The id31.py code does not reflect that,
> and I'd be very surprised if the ID-31 was any different in that
> regard (since it supports more than two modulation modes).

Sounds reasonable.
 
> So, rather than modify ID-31 code that I cannot test, I think it's
> wiser (and more bullet-proof) for me to just have a separate id51.py
> file, and get that working. 

Your call, but I could make and test the change before you get started
if you want.

> It's not like id31.py and id51.py are large files, and if after I'm
> done, someone with an ID-31 radio wants to investigate the
> differences between the two files in terms of bit processing (and
> possibly provide a body of common code), they are welcome to do so
> with my help (assuming it's not the middle of summer when I'm flying
> 4-7 hours a day).
> 
> Also, upon further examination, it appears that some of the "#seekto" 
> values may be different, which to me calls for either a separate
> file, or some renaming of existing structs (etc) in a combined file.

The way we've handled that in other files is to put some variables in
the format and fill them in when the format is passed to
bitwise.parse(). However, going with a separate file entirely is fine
if that's how you'd like to proceed.

-- 
Dan Smith
www.danplanet.com
KK7DS
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
Url : http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20130217/efa64602/attachment-0001.bin