On Mon, Jun 4, 2012 at 11:02 AM, Sander Pool sander_pool@pobox.com wrote:
Hi Tom,
I will give that a try, thanks. Reading all memories seems to take a lot longer with CHIRP than with MCP-4A so I guess Kenwood has the inside track in either reading more quickly or skipping empty slots. It also does not require the 'write on change' that CHIRP does. I would prefer to load-modify-store like MCP-4A does. Any idea why CHIRP behaves the way it does with the D72? Is it considered a feature or a restriction by the developers? :)
It's a feature! MCP-4A downloads the entire memory blob from the D72, toggles some bits, then you save and/or upload back to the radio. Chirp uses a "live" driver, where instead of downloading the blob and decoding it, it just asks the D72 "what's in memory slot 1?", then slot 2, and so on. Likewise with writes, Chirp asks "please write this frequency to slot 133", and the D72 decides if it's safe/valid to write, responding with an ack or rejection. This is why Chirp does it this way--it gives the D72 a chance to detect and reject errors. If Chirp were writing bits to the memory image directly, there would be a larger potential for bugs.
For "live" drivers like this, Chirp handles the download queue from the radio intelligently. You don't need to wait for it to complete before editing channels. If you change Chirp's view to the memory range 500-525, Chirp will prioritize download of those channels so you can begin editing immediately. Then it will continue with the other channels you haven't requested yet. When you edit a channel, it will write immediately, temporarily interrupting the download queue. If you want to cancel the download queue, hit ESC.
I very rarely do a full download from my D72 because 9600 bps is so slow. Normally I jump to the channel I need to tweak (e.g., 525), edit that, and cancel the remaining download queue (ESC). The only time I need to wait for the full download is during an export.
Tom KD7LXL