March 2009 - Users - lists.chirpmyradio.com

[chirp_users] 2200H?
by Jeffrey Nawrot 01 May '09

01 May '09

I'm having an issue trying to import a CSV into the 2200H program file. I was able to import it into my ID800 and into my 92AD, but when I do it on the 2200H it seems to just lock up. Am I doing something wrong? Tnx in advance

2 1

Re: [chirp_users] CHIRP 0.1.9b7
by David Tilson 21 Mar '09

21 Mar '09

> Hmm, I swear it works here. I'll have to take another look. > > This is a CSV of your radio as generated with a known-working > CHIRP, is that right? Yep, I attached it previously as it had 100 memories programmed, so you'd be able to see any gaps in CHIRP. > Thanks :) No dramas. Cheers, davidt

1 0

Re: [chirp_users] CHIRP 0.1.9b7
by David Tilson 20 Mar '09

20 Mar '09

G'day Dan, > I just posted 0.1.9b7 with the following changes: You're not going to like this :( > - Fix memory numbering weirdness in 9x driver Ummm, nope. This does not appear to have changed here. On my radio (Band A) I have Mems 0 - 100 all with content in them, but CHIRP is still reporting Mems 1 - 9 correctly, then skips to show a block from Mem 16 to Mem 25 (but with Radio Mem 10 to Mem 19 content), then skips to another block from Mem 32 to Mem 35 (with Radio Mem 20 - 22 content). It has similar blocks of memory jumping throughout the remainder of the memories, but I think you get the idea. This feature also occurs on Band B as well. > - Make 9x driver cache empty memories to avoid re-checking This function looks like it is now working, as it only loads the memories once :) I've attached a CSV for Band A Mems 0 - 099 which you could import and use to confirm. Cheers, Davidt, VK3UR - still with unresolved issues :)

2 1

[chirp_users] CHIRP 0.1.9b7
by Dan Smith 19 Mar '09

19 Mar '09

Hi all, I just posted 0.1.9b7 with the following changes: - Fix memory numbering weirdness in 9x driver - Make 9x driver cache empty memories to avoid re-checking Hopefully this will actually addres most of Dave's issues. The memory numbering thing was so broken that a number of other things could have been breaking, so I decided to get another version out to test quicker. Thanks a lot to Susan who did some excellent debug work before I even got to it which made the process of fixing it much quicker :) -- Dan Smith dsmith#danplanet.com, s/#/@/ www.danplanet.com KK7DS

2 1

[chirp_users] more on getting OS X working
by Debbie Fligor 18 Mar '09

18 Mar '09

Dan and the group, I'm looking for thoughts on why d-rats works fine, and chirp doesn't for my MacBook Pro. I've tried Susan's path: export PYTHONPATH=/opt/local/lib/python2.5/site-packages using the rest of python as-is in MacOS 10.5.6 (although I might have more installed in site-packages than she does, it's where my ports drats build setup is) and am still getting the same error I do with either my fink or ports full setup (both of which work fine with d-rats). the main window opens, I can choose new, or look at the about box, but not open the serial port. I'm wondering if I've got some cache file somewhere that's messing things up, it seems to always have a problem with "list index out of range" I was pretty sure that at least once I got it to run many versions ago, but I'm not 100% sure on that. If so it was summer time frame. I tried both 1.8 (since Susan had it working on Mac) and the latest beta). Any ideas are appreciated. -debbie, n9dn here's MacOS's python with the path set to the ports site packages: 951 Mnementh> python chirpw Xlib: extension "Generic Event Extension" missing on display ":0.0". Xlib: extension "RANDR" missing on display ":0.0". Xlib: extension "Generic Event Extension" missing on display ":0.0". Xlib: extension "Generic Event Extension" missing on display ":0.0". Xlib: extension "Generic Event Extension" missing on display ":0.0". Traceback (most recent call last): File "/Users/fligor/bin/chirp-0.1.8/chirpui/mainapp.py", line 391, in mh self.do_open9x(ic9x.IC9xRadioB) File "/Users/fligor/bin/chirp-0.1.8/chirpui/mainapp.py", line 119, in do_open9x rtype="ic9x") File "/Users/fligor/bin/chirp-0.1.8/chirpui/clone.py", line 70, in __init__ self.port = miscwidgets.make_choice(ports, True, ports[0]) IndexError: list index out of range ^CTraceback (most recent call last): File "chirpw", line 37, in <module> gtk.main() here's fink's python that works just fine for d-rats: 991 Mnementh> python2.5 chirpw chirpw:41: PangoWarning: error opening config file '../Resources/etc/ pango/pangorc': No such file or directory a.show() Traceback (most recent call last): File "/Users/fligor/bin/chirp-0.1.9b5/chirpui/mainapp.py", line 391, in mh self.do_open9x(ic9x.IC9xRadioB) File "/Users/fligor/bin/chirp-0.1.9b5/chirpui/mainapp.py", line 119, in do_open9x rtype="ic9x") File "/Users/fligor/bin/chirp-0.1.9b5/chirpui/clone.py", line 70, in __init__ self.port = miscwidgets.make_choice(ports, True, ports[0]) IndexError: list index out of range

2 3

Re: [chirp_users] CHIRP 0.1.9b5
by Susan Mackay 18 Mar '09

18 Mar '09

Dan, I can only see V0.1.8 on the downloads page of your web site. Is this page still waiting to be updated or do I need to go somewhere else to get the latest beta version? Susan

2 1

Re: [chirp_users] CHIRP 0.1.9b6
by David Tilson 18 Mar '09

18 Mar '09

Howdy, > Right, that's the idea. It's downloading them in the > background if there is nothing else to do. No probs with that at all and what I expected. > > I then looked at the contents of Mem 10 (on the radio) and > it matched > > Mem 16 in CHIRP, likewise Mem 11 on the radio matched Mem > 17 in CHIRP, > > etc. I checked Mem 22 (on the radio) as the next break in > the memory > > map and it matched Mem 34 on CHIRP. > > Okay, I'm not sure I understand. Are you saying that unused > memory gaps are resulting in an incorrect ordering in CHIRP? Not quite as there were no memory gaps in the radio... Mems 00 - 100 are all in use in Band A, however CHIRP reported that Mems 10 - 15, 22 - 33, etc had nothing programmed in them and displayed incorrect Memory positions for that data. Not sure if that is clear or not, so I'll try a different description... The data is there in CHIRP, but as indicated earlier, it does not match the Memory location on the radio. CHIRP appears to be putting gaps in to the list. > > One other thing I noticed was that even though CHIRP downloaded the > > entire contents of Band A, without prompting when it was initially > > connected, if I instructed CHIRP to display 00 - 800, it would > > download the entire contents again. > > Hmm, that's not the way it's supposed to work :) I figured that would probably be the case :) > One thing that may be throwing you off is that it (yet) > doesn't cache empty memories, so it will check the radio > again to see if those have been added. Is this perhaps what > you perceived as re-downloading the memories? Understand that. No, that is not what I was seeing. It was downloading all 845 memories each time. > If not, does it do this on Band B? In all honesty, I rarely > test with Band A since Band B has more stuff to go wrong, so > perhaps I broke something with Band A specifically. OK, just tried it on Band B and had the same results, ie CHIRP indicates that Mems 0 - 09, 16 - 21, 34 - 35, 64 - 69 are displayed, whereas the radio shows that Mems 0 - 23, 40 - 45, 50 - 73 are all in use. The data is all there, but the Radio Mems don't line up with the CHIRP Mems. Hope that makes sense :) Cheers

2 1

[chirp_users] CHIRP 0.1.9b6
by David Tilson 17 Mar '09

17 Mar '09

G'day Dan, I've just installed version 0.1.9b6 on WinXP here. First set of tests. Connect to IC-92AD Band A and download memory contents. Even though CHIRP was displaying 00 - 25 as the initial range, it downloaded in excess of 800 memories (I'm guessing the 800 + 45 special mems), however it did not display all of the memories between 00 and 25 as I would have expected. It displayed 0 - 9 and then 16 - 21, followed by 34 - 37. Everything else was missing, however when I looked at the debug log it had read 845 memories. I then looked at the contents of Mem 10 (on the radio) and it matched Mem 16 in CHIRP, likewise Mem 11 on the radio matched Mem 17 in CHIRP, etc. I checked Mem 22 (on the radio) as the next break in the memory map and it matched Mem 34 on CHIRP. I then instructed the CHIRP to read mems 00 - 800 and Mem 100 (on the radio) matched Mem 258 on CHIRP. By the time I got to Mem 799 on the radio I had 1920 memories according to CHIRP. If only it were true, as I could really use the additional memories :) I repeated this exercise twice, after exiting / restarting, with the same results. One other thing I noticed was that even though CHIRP downloaded the entire contents of Band A, without prompting when it was initially connected, if I instructed CHIRP to display 00 - 800, it would download the entire contents again. I'll send the debug log to you directly, but from the few that I checked the memories match up correctly in the log. Regards, David Tilson, VK3UR

2 1

[chirp_users] CHIRP 0.1.9b5 on Cent)S 5.2
by Adrian 14 Mar '09

14 Mar '09

Have found this very good with the 92AD Dan, sorry group re; the D-Rats etc, subject line I used on previous posts. regards Adrian

2 1

[chirp_users] CHIRP 0.1.9b5
by Dan Smith 14 Mar '09

14 Mar '09

Hi all, It has been ages since I got out an update to CHIRP. My apologies for that. Other things have taken priority, as usual. Stuart Tener N3GWG has recently reignited the fire under my, um, keyboard and helped conceive and test some of the following bits. Hopefully with his help, I can go back to getting less sleep and more CHIRP work done! I just posted 0.1.9b5: - Make import action attempt to add callsigns as necessary to the incoming radio - Improve responsiveness during long import actions and offer some visual stimulation to reassure the user we're still working - Fix broken "browse" button on the image clone dialog - Fix a 2820 issue where some extra cleanup is required when moving a channel from FM to DV mode - Add MacOS build support - Pick up Prolific USB device names on MacOS - Change the way the callsign list editor works (to show all slots) - Make the callsign editor use fixed-width font for easier lining up of callsigns - Set the initial sort field to be the location column in memory editor on load - Re-write the 9x driver to be cleaner and more maintainable (shouldn't impact functionality, but plenty of testing is needed to ensure we didn't regress) - Make the radio thread work queue support multiple priorities Please do hammer the 9x driver to make sure nothing (else) was broken after the re-write. Also note that with the 9x, you can now make changes to memories before all of the memory channels have loaded and that the entire list of memories will be fetched in the background for quicker loading, but this does not prevent other activities such as callsign/bank editing, etc. If you're running on MacOS, please try out the new MacOS .app package. I can generate a PPC version if anyone needs it. If it works, thank Stuart for that. You can also thank him for making your serial ports properly populate in the clone box :) Have at it and let us know of any new issues! -- Dan Smith dsmith#danplanet.com, s/#/@/ www.danplanet.com KK7DS

2 3