October 2008 - Users - lists.chirpmyradio.com

Re: [chirp_users] CHIRP 0.1.7b5
by David Tilson 20 Oct '08

20 Oct '08

> One thing I can do is cache the information in the radio driver, which > will make the handhelds behave similarly in speed to the other radios, > when fetching memories that we should already know. It has the > potential to widen the exposure of differing information in the radio > and CHIRP (like if you're playing with the radio itself while editing > with CHIRP) but maybe that's not a big deal. I don't know how often that would be perceived a potential problem, but I suspect not often. From my experience the only time I have been playing with the radio at the same time as editing is when we've been trying to find possible problems. The rest of the time the handheld just sits in the background while I play with CHIRP. Now to see if I can break anything with the 2820 :) Cheers, Davidt, VK3UR

1 0

Re: [chirp_users] CHIRP 0.1.7b5
by David Tilson 20 Oct '08

20 Oct '08

> /Then/, if your currently-opened radio already > has a location 25, then it will complain. OK, that's clear now :) > The problem that I see with that is this: > You have a radio with 400 memories programmed, and open another to > import from, which also has all 400. It asks you once, and you have to > say "don't ask me again" because otherwise your finger will die from > clicking "No" 400 times. Then, when you've got them all up, you decide > to import a memory into an unused location (328) in your current radio, > but actually type 238, but it doesn't warn you because you told it not > to... See what I mean? :) OK, I would have thought that chirpw would only try to import the entries that are ticked, so you wouldn't have the 400 No clicks. The only entry it should prompt you for, in your example, would be memory 238 as it has been ticked but when prompted due to a conflict the operator should say No to. At which time once the rest of the processing has been completed the operator can then reassign the memory to 328. I can live with it either way, it just appeared a bit odd to me. Cheers, davidt

1 0

Re: [chirp_users] CHIRP 0.1.7b5
by David Tilson 20 Oct '08

20 Oct '08

G'day Dan, >> If we can get rid of the dependence of having to have the radio >> sitting on a DV memory before any transfers take place I think that a >> lot of headaches would be minimised :) > Yeah, I agree. I've spent quite a bit of time working on this with no > progress. It's pretty freaking annoying, but I don't want to just spend > all of my time on it. No dramas. >> I then unchecked the Confirm Overwrite field and >> tried again, but once again it overwrote the data without prompting. > That checkbox makes it prompt you when you change the location of a > memory to something that conflicts with something already in the radio. > If you're just doing an import without moving things around, then it > never does that check. That didn't occur in this case. I tried to overwrite an existing memory with different data (in this case a different frequency (all other data was the same) and it didn't prompt either way. > I'd prefer it to do that check when you change a memory, instead of all > at once when you click the OK button or something. So: How about this concept, if it is not too difficult... Prompt at the time the first record conflict is encountered. Display the old and proposed entries and offer the options "Replace Yes, No, Yes to All, No to All" If Yes or No options are selected the same prompt will occur on the next conflict. The "to All" options would remove the requirement for further prompts for the rest of the Import. This concept would allow you to remove the checkbox all together. Cheers, Davidt, VK3UR

2 1

Re: [chirp_users] CHIRP 0.1.7b5
by David Tilson 20 Oct '08

20 Oct '08

G'day Dan, > So, I take this to mean that when you open up your handheld, > the first thing you do is change the range to 0-400 > and then go get coffee while it loads the entire radio > onto the screen? Yep, I like to stress test things for you (and pass the stress back to you) :) And just to keep up with the Aussie stereotype it gives me time to go off and get a beer and a vegemite sandwich :) The beer also helps with testing, though it can add the odd eroneous message during the latter parts of testing. >> Functionally this works, but it is quite slow. > Well, it's instantaneous on all the other radios, and it > would only take a few seconds if you didn't have your > view set to 0-400 :) I guess one of the things that makes it more noticeable is that some other software only works in banks of 100 memories at a time, so it takes less time to resynch. That being said, for me personally, the advantage of being able to insert / delete a row that spans over 100 memories (before a gap is found) far outweighs the time factor and in reality probably takes less time than having to try and manipulate memories from one bank to another. > Try this on your 2820, and I'll see if I can come > up with something I'm comfortable with to avoid > the re-sync :) No probs. Cheers, Davidt, VK3UR

2 1

Re: [chirp_users] CHIRP 0.1.7b5
by David Tilson 20 Oct '08

20 Oct '08

G'day Mark, Great to hear from you and trust all is well in VK4 land. > I cant get V1.6 or 1.5 to connect to my radio it just sits there waiting to download. OK a couple of clues that might assist. 1/ If you are using either an IC-92AD or a IC-2820H then you need to ensure that GPS TX MODE is set to DISABLED and that GPS AUTO TX is set to OFF. 2/ Additionally if you are using either an IC-91AD or a IC-92AD the radio must be set for Band B and the mode must be set as DV. If you are using a different type of radio please let us know, but I certainly know that the above settings (currently) cause CHIRP to sit there, or not transfer information properly. Also if you've tried to perform a download, prior to confirming the above settings, it is wise to close / restart chirpw or csvdump. Hope this helps. Cheers, Davidt, VK3UR

1 0

Re: [chirp_users] CHIRP 0.1.7b5
by David Tilson 20 Oct '08

20 Oct '08

Further to my last Dan, > I deleted Mem 50 from my radio and tried to > Import Mem 50 from my ic2820.img file (created in 0.1.7b4). > I was able to select the appropriate memory but when I pressed > the go button chirpw crashed and the entry was not written to the radio. I suspect the reason why chirpw crashed was that when I deleted Mem 50 (through chirpw) that the chirpw could no longer talk to the IC92AD as it was no longer in DV mode on that memory. I discovered this when I tried to restore using csvdump and it complained as well. Setting the radio to another memory, in DV mode, sorted this out. I then repeated the experiment, by deleting Mem 50 again, but before I tried the Import From File function I made sure the radio was set on a different DV memory. This time the Import was successful. If we can get rid of the dependence of having to have the radio sitting on a DV memory before any transfers take place I think that a lot of headaches would be minimised :) I then tried to overwrite an existing Memory using the Import function. The Confirm Overwrite button was ticked. When it got to the appropriate memory it overwrote the existing memory without prompting. I would have thought having this field ticked would have prompted before overwriting. I then unchecked the Confirm Overwrite field and tried again, but once again it overwrote the data without prompting. The really good news though is that this version confirms that I was able to import ic2820 DV memory information into an IC92, which is great! Cheers, Davidt, VK3UR

2 1

Re: [chirp_users] CHIRP 0.1.7b5
by David Tilson 20 Oct '08

20 Oct '08

G'day Dan, > I just posted 0.1.7b5 in the usual spot if you're interested in trying it out: Here are some of my initial tests on the IC-92AD. > Please remember to backup your radios before playing. I really think this should be your standard disclaimer :) > - Added some better logging to help debug issues Hopefully this will tell you why it crashed here :D > - Added All/None/Inverse select buttons to import dialog Confirmed. Thanks for adding that. I deleted Mem 50 from my radio and tried to Import Mem 50 from my ic2820.img file (created in 0.1.7b4). I was able to select the appropriate memory but when I pressed the go button chirpw crashed and the entry was not written to the radio. I've sent you the debug log separately and it is the last set of entries in the log. > - Added editing of the MYCALL list in the radio MYCALL entries are now displaying correctly, which they weren't in previous versions. Although I can Add/Remove entries to the list, I can't Edit an existing entry. The same occurs for both the Your Callsign and Repeater Callsign fields. As soon as I make a change in the MYCALL field then CHIRP re-reads all 400 of the memories again, which can take a couple of minutes to complete in the background. If I make 2 changes then it re-reads the complete contents twice. > - Added memory shifting, which lets you insert a hole in the middle of > contiguous memory locations. Also allows deleting a hole and shifting > everything up to fill it. Yep, CHIRP inserted a new line and incremented all of the memories until it found a blank space at Mem 31. In this case I had 400 memories displayed on the IC92AD Band B and I inserted a new line at memory 29. What surprised me though was that it then re-read all of the memories eg: Mems 001 - 400 which took quite a lot of time. Given the content didn't change below Mem 31 (in this example) does CHIRP need to re-read all of the other memories? The same occurred when I deleted (and shift up) a memory. Functionally this works, but it is quite slow. Now to restore my backup :) Cheers, Davidt, VK3UR

3 2

[chirp_users] CHIRP 0.1.7b5
by Dan Smith 19 Oct '08

19 Oct '08

Hi all, Thanks for joining this list. We've got a pretty healthy number of people here now, which is really cool. I just posted 0.1.7b5 in the usual spot if you're interested in trying it out: http://chirp.danplanet.com/download/beta/ Please remember to backup your radios before playing. For what it's worth, doing a download of your radio (assuming it's not a handheld) with chirpw and storing the file somewhere safe is a pretty good way to backup the radio, as it's a complete image of the memory. Since this is the first public beta of 0.1.7, I'll include a rough list of changes since 0.1.6: - Fixed up a File->Save bug - Made changes to the D-STAR tab update the Memories tab - Added some better logging to help debug issues - Fixed up some ID800 tone setting parsing - Added a preliminary radio-neutral file format (and File->new to create one) - Added import/export functions to allow importing of a set of memories from one radio file to another. - Added IC-2200 D-STAR support and since 0.1.7b4: - Added All/None/Inverse select buttons to import dialog - Added more sanity checking for in-list and in-memory duplicates on import - Added editing of the MYCALL list in the radio - Fixed a regression that was preventing editing memory location numbers - Added memory shifting, which lets you insert a hole in the middle of contiguous memory locations. Also allows deleting a hole and shifting everything up to fill it. Have at it. Thanks! -- Dan Smith dsmith#danplanet.com, s/#/@/ www.danplanet.com KK7DS

1 0

[chirp_users] csvdump Browse Window - ver 0.1.7b4
by David Tilson 18 Oct '08

18 Oct '08

G'day Dan, Well done and thanks for setting up this list. I think it will be great to see everyone's input on CHIRP. When using csvdump, on a Windows platform, and the user presses the Browse button, to load an existing CSV file, the new window defaults as if it is a "Save As" screen and offers a Save button. This may cause confusion if the user doesn't realise that they can just double click on the filename to load it, rather than wanting to create a new filename and save it. I realise that it has probably always been like this, but it really only caught my eye recently and thought it might be problematic for new users. Regards, davidt, VK3UR

2 1