[chirp_users] CHIRP 0.1.11b7
Hi all,
I just posted v0.1.11b7 with the following changes:
- Add Icom IC-W32A support (Thanks to Daniel for the loan) - Add Icom IC-T70A support (Thanks to John for the loan) - Fix the CSV driver ignoring D-STAR fields.
Unless anyone can find a show-stopper bug in this, I'm going to release it as the official 0.1.11, hopefully before next week.
If you're an "official tester" for a specific model, please, now is the time to give your "thumbs up" or "thumbs down" on this version's ability to work with your radio. Even if you're not an official tester, feel free to run through these tips and let us know how it works for you:
http://chirp.danplanet.com/content/testing-guidelines
Thanks!
On Sat, Mar 19, 2011 at 7:55 AM, Dan Smith dsmith@danplanet.com wrote:
Hi all,
I just posted v0.1.11b7 with the following changes:
- Add Icom IC-W32A support (Thanks to Daniel for the loan)
- Add Icom IC-T70A support (Thanks to John for the loan)
- Fix the CSV driver ignoring D-STAR fields.
Unless anyone can find a show-stopper bug in this, I'm going to release it as the official 0.1.11, hopefully before next week.
If you're an "official tester" for a specific model, please, now is the time to give your "thumbs up" or "thumbs down" on this version's ability to work with your radio. Even if you're not an official tester, feel free to run through these tips and let us know how it works for you:
http://chirp.danplanet.com/content/testing-guidelines
Thanks!
I've verified that 1.11b7 works with my VX-8DR both upload download and cvs export.
Grant.
- Add Icom IC-W32A support (Thanks to Daniel for the loan)
- Add Icom IC-T70A support (Thanks to John for the loan)
Has anyone had a chance to try either of these radios? I'd like at least a sniff test before I post the official version.
Thanks!
I'll see if I can test the W32A sometime today if no one else has.
On Mar 22, 2011, at 9:25, Dan Smith wrote:
- Add Icom IC-W32A support (Thanks to Daniel for the loan)
- Add Icom IC-T70A support (Thanks to John for the loan)
Has anyone had a chance to try either of these radios? I'd like at least a sniff test before I post the official version.
Thanks!
-- Dan Smith www.danplanet.com KK7DS
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
On Mar 23, 2011, at 5:24, Debbie Fligor wrote:
I'll see if I can test the W32A sometime today if no one else has.
I'm running behind, the kids and I were sick and things are just all slow here. I got a download out of the radio, but some of the memory names just showed boxes with "X" in the middle, probably a font issue, maybe on my system.
I brought the radio with me to work today to do more checks. I saw the release went on out, I'll pull it down and test against that instead, and let you know how it goes.
sorry for the delay.
-debbie
on the released code version, I had no problems downloading, making a small change and uploading to my ic-w32a. I do see some names inside Chirp as a square with an X inside. As best I can tell these are programmed memories, that have no name set (as opposed to empty memories). They show up as blank in my radio, but may be some special character that X isn't rendering as a blank.
I notice that even if I check "Special Channels" I can't see/edit Memories 1A, 1B, etc. I don't know if I was supposed to be able to or not.
Other than that, it seems to have basic functionality and works for up, down and save.
I think with this release, you've gotten nearly all my radios, and all of the ones I had just programmed by hand (or with other free software) because I didn't think it was worth $50 for the software and having to boot to windows to use it.
now if CHIRP could only fix the VHF side of my W32 so it transmits again I'd really be set :-)
thanks again for all the handy software.
-debbie
on the released code version, I had no problems downloading, making a small change and uploading to my ic-w32a. I do see some names inside Chirp as a square with an X inside. As best I can tell these are programmed memories, that have no name set (as opposed to empty memories). They show up as blank in my radio, but may be some special character that X isn't rendering as a blank.
Ah, okay, can you send me an image to look at?
I think with this release, you've gotten nearly all my radios, and all of the ones I had just programmed by hand (or with other free software) because I didn't think it was worth $50 for the software and having to boot to windows to use it.
Sweet!
now if CHIRP could only fix the VHF side of my W32 so it transmits again I'd really be set :-)
Hmm, I probably can't help with that :)
On Mar 18, 2011, at 2:55 PM, Dan Smith wrote:
I just posted v0.1.11b7 with the following changes:
Testing this against my Kenwood TH-F6A on Linux (I have still not been able to get CHIRP to run correctly on my Mac), I note the following:
1. the memory names are not populated in CHIRP's display. 2. when trying to set a new (previously empty) memory, entering a new value for the frequency results in this message:
Job Args: (Memory[90],) Job KWArgs: {} Editing new item, taking defaults PC->D7: MW 0,0,090,00146620000,0,2,0,0,0,0,08,08,000,000600000,0,0 D7->PC: N Exception running RadioJob: Radio refused 90 -- Exception: -- Traceback (most recent call last): File "/net/nis1/srv/home/japeterson/Personal/source/chirp-0.1.11b7/chirpui/common.py", line 71, in execute result = func(*self.args, **self.kwargs) File "/net/nis1/srv/home/japeterson/Personal/source/chirp-0.1.11b7/chirp/kenwood_live.py", line 172, in set_memory raise errors.InvalidDataError("Radio refused %i" % memory.number) InvalidDataError: Radio refused 90
after this message, CHIRP shows the memory as programmed, but checking it on the radio itself does not show it.
3. deleting this memory line successfully removes it from CHIRP's display, but prints the following message:
Job Args: (90,) Job KWArgs: {} PC->D7: MW 0,0,090 D7->PC: N Exception running RadioJob: Radio refused delete of 90 -- Exception: -- Traceback (most recent call last): File "/net/nis1/srv/home/japeterson/Personal/source/chirp-0.1.11b7/chirpui/common.py", line 71, in execute result = func(*self.args, **self.kwargs) File "/net/nis1/srv/home/japeterson/Personal/source/chirp-0.1.11b7/chirp/kenwood_live.py", line 183, in erase_memory raise errors.RadioError("Radio refused delete of %i" % number) RadioError: Radio refused delete of 90
Note that the driver seems to think it's talking to a D7, but I've really got an F6.
I went back to 0.1.10 to see if it could read my radio, but it came back with no memories populated (trying to read as a D7 as it didn't have a generic Kenwood or F6 option).
Anybody else got CHIRP talking to a Kenwood TH-F6A?
-jan-
Hi Jan,
- the memory names are not populated in CHIRP's display.
Just to be sure, you are using 0.1.11b7, right? I think this was fixed already for the F6A in a previous beta.
Did you do a from-source install previously and maybe now are running directly from the source tarball? That could be part of the problem. I'd either do an install of this one to overwrite the old one, or clean out the files installed in the rest of the system so you know that you're running the current version.
- when trying to set a new (previously empty) memory, entering a new value for the frequency results in this message:
This might be related to the above as well. Are you able to make changes to existing memory channels?
Note that the driver seems to think it's talking to a D7, but I've really got an F6.
That's just the debug code being silly, it wouldn't be getting this far if it didn't know it was an F6A :)
When you try the above, if it still doesn't work, it would be helpful to see the whole debug log. If you're running from the command line, something like:
./chirpw >file_for_dan.txt 2>&1
would work.
I went back to 0.1.10 to see if it could read my radio, but it came back with no memories populated (trying to read as a D7 as it didn't have a generic Kenwood or F6 option).
Yeah, 0.1.10 didn't support it at all.
Thanks!
Just to be sure, you are using 0.1.11b7, right? I think this was fixed already for the F6A in a previous beta.
Yes, I definitely have 0.1.11b7.
Did you do a from-source install previously and maybe now are running directly from the source tarball? That could be part of the problem. I'd either do an install of this one to overwrite the old one, or clean out the files installed in the rest of the system so you know that you're running the current version.
I had not previously installed it, and was running from the source directory. I'll try doing an install...
Okay, ran through the install process, not running it from the tarball directory. Still not showing the channel names. :-(
- when trying to set a new (previously empty) memory, entering a new value for the frequency results in this message:
This might be related to the above as well. Are you able to make changes to existing memory channels?
No, I'm getting the same errors when trying to modify an existing channel as when trying to configure an empty channel slot. I'll grab the whole debug log so you can see what's going on.... I looked through it, though, and unless the protocol is just wrong, I don't see what would be causing the problem.
http://dl.dropbox.com/u/6647867/chirpw.log
-jan-
Ah, okay, I think I spotted the problem. This is really hard without a radio to work with, but lets give this a shot.
Save the attached file into your chirp source directory (i.e. wherever your chirpw file is). Then do the following:
$ zcat f6a.patch.gz | patch -p1 patching file chirp/kenwood_live.py
If you see the "patching file" message, then that means you should be good. See if you can then make a change to a memory channel.
I'm still slightly puzzled by the name issue, but lets resolve this one first.
Thanks!
On Mar 22, 2011, at 4:12 PM, Dan Smith wrote:
Ah, okay, I think I spotted the problem. This is really hard without a radio to work with, but lets give this a shot.
I've applied the patch and I can now edit existing memories and add info to previously empty ones. Cool.
Also of note, I can now enter a name for the memory in CHIRP and it shows up on the radio! The existing names of memories in the radio still don't show up in CHIRP, though.
This brings up a feature request... when using "live" radios, it would be nice to have an option to update CHIRP's idea of the contents of a particular memory. For example, say I fiddle with a radio setting on the radio, while it's connected to CHIRP. I want to refresh CHIRP's row for that memory. I think the right-click popup on the memory row would be the right place for this kind of option.
-jan-
I've applied the patch and I can now edit existing memories and add info to previously empty ones. Cool.
Sweet, I'll commit that to the tree. Can you send me a log of you setting the memory name? That might give me a clue about why it's not being read properly.
This brings up a feature request... when using "live" radios, it would be nice to have an option to update CHIRP's idea of the contents of a particular memory. For example, say I fiddle with a radio setting on the radio, while it's connected to CHIRP. I want to refresh CHIRP's row for that memory. I think the right-click popup on the memory row would be the right place for this kind of option.
Yes, that's a valid request. Some of the live radios do caching and some do not. I have some work in progress to unify them all so they use the same scheme, which will then allow me to make a generic cache dump like you're talking about.
Thanks!
On Mar 22, 2011, at 4:34 PM, Dan Smith wrote:
I've applied the patch and I can now edit existing memories and add info to previously empty ones. Cool.
Sweet, I'll commit that to the tree. Can you send me a log of you setting the memory name? That might give me a clue about why it's not being read properly.
Nothing too exciting. Here's the segment of the log showing me setting the name of memory 90 to "bar":
PC->D7: MW 0,090,00146620000,0,2,0,0,1,0,18,18,000,000600000,0,0 D7->PC: MW PC->D7: MNA 090,bar D7->PC: MNA 090,bar
Previous changes to memory 90 looked like this:
PC->D7: MW 0,090,00146620000,0,2,0,0,1,0,18,08,000,000600000,0,0 D7->PC: MW PC->D7: MNA 090, D7->PC: MNA 090,
looks like they would set the memory name to nothing.
For kicks, I made a change to a memory that has an existing name, memory 254 has (had) the name "FRS 14". I set the memory to turn tone on (from "(none)") and now the memory name on the radio is unset. Here's the relevant bit of the log:
PC->D7: MW 0,254,00467712500,5,0,0,1,0,0,08,08,000,005000000,0,0 D7->PC: MW PC->D7: MNA 254, D7->PC: MNA 254,
You can see that it specifically sets the name to nothing, and the radio dutifully sets it that way internally.
Looking back earlier in the log, when CHIRP was reading in the memory data from the radio initially, it doesn't seem to be getting the name:
PC->D7: MR 0,254 D7->PC: MR 0,254,00467712500,5,0,0,0,0,0,08,08,000,005000000,0,0 PC->D7: MNA 0,254 D7->PC: N
possibly something wrong with that MNA directive? The radio is responding with "N", which I believe means it didn't understand what it was asked. I looked through the TH-F6A protocol doc and it looks like the syntax should be something like this:
MNA 254
to retrieve the memory name (note the lack of the trailing comma). The radio should respond with something like this:
MNA 254,FRS 14
The driver seems to be setting the name correctly:
MNA 254,FRS 14
which gets the response:
MNA 254,FRS 14
Shouldn't be too hard to fix this one. :-)
-jan-
On Mar 22, 2011, at 5:12 PM, Dan Smith wrote:
Shouldn't be too hard to fix this one. :-)
Yep, good spotting. Try the attached (on top of the previous) to see if it works.
Your patch looks very similar to mine! :-)
I think yours is a little wrong, though, as you continue to pass two args to the formatter:
return "MNA", "%03i" % (self._vfo, number)
I think should be just
return "MNA", "%03i" % (number)
While my python-fu is weak, I think I'm getting stronger every day. Thanks for your help.
-jan-
Here's a stab at a patch that seems to fix it. This patch is against the patched kenwood_live.py that you already sent me. It seems to work okay now. I'll play around with it some more.
-jan-
participants (4)
-
Dan Smith -
Debbie Fligor -
Grant Diffey -
Jan L. Peterson