- 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 :)
- 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.
- 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")