- Users - lists.chirpmyradio.com

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

23 Oct '08

Hi Dan, Just to let you know, in case you haven't tried it... Using csvdump, on my IC-2820H, I was able to Import 2 csv files (with different memory ranges) prior to making a single Upload. Although I wasn't sure if csvdump would complain about 2 imports, or toss one of the imports out, everything worked fine. Cheers, davidt

2 1

[chirp_users] 1.7b5 bugs
by Dave Cooley 22 Oct '08

22 Oct '08

After running both csvdump and chirpw several of the dstar frequencies did not populate. All other analog frequncies did appear however. Attatched are the corresponding csv, debug, img and icf files. Dave Cooley 1007 Centerbrook Drive Brandon, Florida 33569

2 1

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

22 Oct '08

Hi Dan, I forgot to mention, thanks for converting the Import / Upload function into a single step in csvdump for the IC9X radios... It simplifies this process. Cheers, Davidt, VK3UR

1 0

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

21 Oct '08

G'day Dan, > Hmm, I'm not sure I understand. You went from the D-STAR tab to the > Memories tab, and instead of showing 000-400, it was showing 156-400? > Was the range at the top set that way also, or was it just inconsistent > with the view? The range was inconsistent with the view. It should have been showing 000 - 400 (eg: the two fields where you set the lower and upper limit), but the results started at 156 and went to 400. It did not allow you to see 000 - 155 unless I forced a complete re-read of the memories. Hope that makes a bit more sense. Cheers, davidt

1 0

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

21 Oct '08

G'day Dan, > I just posted 0.1.7b5 in the usual spot if you're interested in trying it out: Testing this time with my IC-2820H and focusing on the differences compared to my IC92AD tests... > - Added import/export functions to allow importing of a set of memories from one radio file to another. When I tried to Export to File it prompted me with a location and filename, however when I pressed the go button chirpw stopped working requiring a forced exit and there were some entries in the debug file, sent via separate email. > - Added more sanity checking for in-list and in-memory duplicates on import Not sure what sanity checking is in place. I tried to import the same contents from Mem 50 into Mem 49 and there were no complaints. - Added editing of the MYCALL list in the radio After adding a new entry into the MYCALL field you could see chirpw re-reading the memory contents of the .img file. Noted that you said that will be limited to the 800 and 2200 radios that need to do this, but confirming it did do this for the 2820. I tried entering a callsign in Lower Case to see what happened, as I thought I could trip you up, but you automatically convert them to Upper Case. You sneaky devil :) I did notice though that when I went from the D-STAR tab back to the Memories tab that the list started part way through the range of memories, in this case Mem 156, not at Mem 000, and the only way I could display earlier memories was to define the display range and re-read the information. I noticed this last night on the IC-92AD after a similar set of steps. > - 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, this is a lot smoother than on the IC92AD as expected due to it being in effectively an off-line mode. Cheers, Davidt, VK3UR

2 1

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