[chirp_devel] #551 Add support for IC-7000 banks

[Dan Smith]

>  1. Yes, that's what I thought I'd try as well.  Does Chirp include a
>     tool to send random CI-V commands to the IC-7000, and display the
>     results?  I thought I remembered seeing such a tool somewhere ...

Nope, but I'd take it if you want to add it :)

>  2. On the Icom D-Star radios, you treat the successive 100-entry
> memory banks as one large contiguous bank;  a good idea for those
> radios. However, the IC-7000 has five 99-entry banks, so I think
> making them contiguous might make for confusing numbering of the
> memory.  The alternative of creating a bogus entry to make the
> numbers "match" (which is what I would do if it was just me using the
> software), would work but could introduce confusion as well.
> Creating a separate memory tab for each bank would be best, but I
> don't know how to do that, and that involves an architectural design
> issue that should be consistent across radios, I'd think.

Chirp has architectural support for devices with multiple chunks of
main memory. It calls these "sub devices" as this is usually needed for
sub-vfos. The way this is reflected in the UI right now is really
annoying, and would be especially so if you were to add more than two
for a given model. I've mostly been ignoring the problem because I hate
radios that have different memories for the two VFOs and tend not to
use them. However, perhaps your case here is a good reason to fix that.

If you want to expose the banks as five sub-devices, I'll commit to
trying to fix the UI in the way I think should be done in hopes of
ending up with something sane.

The IC9x driver behaves this way, but don't look at it as an example --
it is an embarrassing mess. The FT7800/8800/8900 driver does this as
well, but it is a mess for various other reasons, so don't look at it
either. Probably the best option would be the new ft350 driver, which
is probably the cleanest one I can think of at the moment.

>  3. I haven't done anything to my Chirp repository since I submitted
>     id51.py.  While I can blow away the repository and get a new copy,
>     my guess is that's not the best way.  What method do you
> recommend? HG "revert" or "update"?

If you had it as a mq patch, then you can just qpop it off the stack
(so that hg qapplied shows nothing) and then update your local repo
from mine with "hg pull -u")

-- 
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/20130224/a6994e4a/attachment-0001.bin