[chirp_users] Exporting D72 memories never finishes
Hi,
I did some editing of my D72 memory, unplugged the radio and attempted to export the stations to csv so I can re-import into my D710. The problem is that the 'Preparing memory list' phase never ends. This is on an i7 based laptop so it shouldn't be a performance issue. I have perhaps 100 of the 1000 memories set, spread over the 10 banks.
Any ideas?
73,
Sander W1SOP
On Tue, May 29, 2012 at 7:09 PM, Sander Pool sander_pool@pobox.com wrote:
Hi,
I did some editing of my D72 memory, unplugged the radio and attempted to export the stations to csv so I can re-import into my D710. The problem is that the 'Preparing memory list' phase never ends. This is on an i7 based laptop so it shouldn't be a performance issue. I have perhaps 100 of the 1000 memories set, spread over the 10 banks.
Any ideas?
73,
Sander W1SOP
Hi Sander,
Sorry no one has replied yet.
The only solution that comes to mind is not unplugging the D72 before exporting, if this is indeed what you did. Try this:
1. Plug in D72 USB 2. Launch Chirp 3. Download from D72 4. Export to CSV
The D72 sends data at only 9600 bps, so the export may take a while (the D710 will do 57600 bps). After exporting once, I prefer to manage memories via the csv file, so I don't have to endure another download from the D72.
Tom KD7LXL
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? :)
In any event, many thanks to the developers!
73,
Sander W1SOP
On 6/4/2012 12:47 PM, Tom Hayward wrote:
- Plug in D72 USB
- Launch Chirp
- Download from D72
- Export to CSV
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
Ah. I sat there waiting while it downloaded all 1000 channels because I didn't realize I could edit as it was working on that. I can see the benefit of having the radio verify each entry as it's being written but I don't like the idea that every modification is immediately written to the radio. I would prefer consistent behavior for each supported radio wherever possible, that of a document rather than a database approach. Just my preference of course. The desire to use channel checking by the D72 is not mutually exclusive with this approach. The changed channel would simply be queued and written when 'save' is selected.
In any event, I know I'm second guessing your efforts and that can be annoying. My apologies. I write python for a living these days so perhaps it's time to crack open the source tree.
73,
Sander W1SOP
On 6/4/2012 1:21 PM, Tom Hayward wrote:
I very rarely do a full download from my D72 because 9600 bps is so slow.
Ah. I sat there waiting while it downloaded all 1000 channels because I didn't realize I could edit as it was working on that. I can see the benefit of having the radio verify each entry as it's being written but I don't like the idea that every modification is immediately written to the radio. I would prefer consistent behavior for each supported radio wherever possible, that of a document rather than a database approach. Just my preference of course. The desire to use channel checking by the D72 is not mutually exclusive with this approach. The changed channel would simply be queued and written when 'save' is selected.
Some other folks prefer the opposite, of course. It takes several minutes to download my ID880 (for example). It's image-based, which means the minimum time to do a download, add a channel, and upload the result is probably seven minutes. If I get distracted in the middle (which I always do), it's more like thirty minutes. With one of my live radios (like your D72) I can make a change like that in less than sixty seconds.
If you prefer the image-based approach, download the entire radio, export to CSV and make your edits there. You can then make a bunch of changes to that and only push the result to your radio when you're done.
Hi Dan,
that is what I intended to do but then I got the hang. I'll try again with the radio connected. It would be nice if the export feature showed an error dialog if the radio is not connected. Actually, the entire memory was read at that time so it should simply have written the file, regardless of the radio being connected.
Thanks and 73,
Sander W1SOP
On 6/4/2012 1:45 PM, Dan Smith wrote:
If you prefer the image-based approach, download the entire radio, export to CSV and make your edits there. You can then make a bunch of changes to that and only push the result to your radio when you're done.
On Mon, Jun 4, 2012 at 11:36 AM, Sander Pool sander_pool@pobox.com wrote:
In any event, I know I'm second guessing your efforts and that can be annoying. My apologies. I write python for a living these days so perhaps it's time to crack open the source tree.
There's a broken "clone-mode" driver for the D72 in the source tree. Head on over the chirp_devel if you want to try fixing it. It was less error prone and easier for me to write the new live driver than fix the clone driver, so that's the route I took.
Many Kenwoods and Icoms support live editing, and because of the built-in error checking, this has been the preferred method for Chirp (when available).
Tom KD7LXL
I didn't realize this was common. Of course my experience with these things is limited to just two radios so I was only guessing :)
I'll have a peek at the code.
Sander W1SOP
On 6/4/2012 1:46 PM, Tom Hayward wrote:
Many Kenwoods and Icoms support live editing, and because of the built-in error checking, this has been the preferred method for Chirp (when available).
I wasn't very clear, sorry. What I meant was that I understood what it was doing (live edit) but that I was surprised that it did. At the time I didn't understand the rationale nor did I know other radios behaved the same way. Thanks for taking the time to explain.
Sander W1SOP
On 6/4/2012 8:43 PM, Dan Smith wrote:
Maybe you clicked past the BFW dialog that warned you that your radio operates in Live Mode?
I wasn't very clear, sorry. What I meant was that I understood what it was doing (live edit) but that I was surprised that it did. At the time I didn't understand the rationale nor did I know other radios behaved the same way. Thanks for taking the time to explain.
Ah, okay. Perhaps I should make this a little more obvious in the guide:
http://chirp.danplanet.com/projects/chirp/wiki/Beginners_Guide
participants (3)
-
Dan Smith -
Sander Pool -
Tom Hayward