[chirp_users] Thoughts on TH-F6A support and looking for D710 support
Hello Everyone,
KI6ZHD here. I just discovered Chirp as I was looking for some way of synchronizing the memories across my F6A, two D710s, and a VX5 in a Linux-only environment. I did some tests and it seems that the Kenwood TH-F6A support is close but it's missing the memory's NAME which is very important to me. I then tried the Kenwood D710 which communicated but didn't support and a Yaesu VX5 didn't work at all. I also noticed I couldn't save any downloaded data nor upload anything back to the radios (see below). The F6A and D710 are the priority radios for me and the VX5 is a backup. Any thoughts on getting the F6A and the D710 working?
Taking it a step further, I'm ideally looking for is a memory syncronization tool across different radios. I'm not looking for full backups (though that would be nice like Kenwood's Windows applications) but memories is good enough.
Any possibility of coming up with a system that would:
- load multiple radio's data at the same time - merge and navigate conflicts (move memories I added in the Car or at Home) and allow me to move them into free slots - come up with a new master file - program them back into each of the radios
I know that I could manually do this with Chirp with say CSV files but I think a merging feature like this would be a fantastic.
--David
Chirp 0.11.b4 Running on Centos 5.5 GTK 2.10.4 PyGTK 2.10.1
Three radios here are tested - Kenwood TH-F6A - Kenwood TM-D710 - Yaesu VX-5
------------------------------------------- Kenwood TH-F7A -------------------------------------------
Recognizes TH-F6A fine !! does NOT download memory's names !! cannot select File --> Save As !! cannot Radio --> Upload to radio
recognition sequence -- [dranch@hampacket chirp-0.1.11b4]$ ./chirpw PC->V71: ID V71->PC: ID TH-F6 PC->D7: ID D7->PC: ID TH-F6 Talking to a TH-F6 PC->D7: AI 0 D7->PC: ? Starting memedit Bank Index supported: False Bank supported: False DTCS Code supported: True DTCS Pol supported: False Mode supported: True Offset supported: True Name supported: True Tune Step supported: True Name supported: True ToneSql supported: True Cross Mode supported: False Started PC->D7: MR 0,000 D7->PC: N PC->D7: MR 0,001 D7->PC: MR 0,001,00145390000,0,2,0,1,0,0,12,08,000,000600000,0,0 PC->D7: MNA MNA 0,001 . . . --
------------------------------------------- Yaesu VX5 (non-R) -------------------------------------------
Selecting Radio VX3
Program reports 000: 98 80 06 18 78 86 80 60 ....x..` 008: 78 06 00 00 00 00 00 00 x.......
Selection of VX3, VX6, and VX7 does not work:
VX5 commander (Windows) DOES work for me:
http://www.kc8unj.com/vx5.html
--> Cancel does NOT work
program shows -- Traceback (most recent call last): File "/usr/src/archive/Chirp/chirp-0.1.11b4/chirpui/cloneprog.py", line 58, in <lambda> cancel_b.connect("clicked", lambda b: cancel()) File "/usr/src/archive/Chirp/chirp-0.1.11b4/chirpui/clone.py", line 200, in cancel self.kill(CloneCancelledException) File "/usr/src/archive/Chirp/chirp-0.1.11b4/chirp/chirp_common.py", line 765, in kill import ctypes ImportError: No module named ctypes --
------------------------------------------- Kenwood D710 ------------------------------------------- PC->V71: ID V71->PC: PC->V71: ID V71->PC: PC->V71: ID V71->PC: ID TM-D710 --- Exception Dialog: Unsupported model `TM-D710' --- Traceback (most recent call last): File "/usr/src/archive/Chirp/chirp-0.1.11b4/chirpui/clone.py", line 153, in run cs.radio_class = detect.DETECT_FUNCTIONS[vendor](cs.port) File "/usr/src/archive/Chirp/chirp-0.1.11b4/chirp/detect.py", line 117, in detect_kenwoodlive_radio raise errors.RadioError("Unsupported model `%s'" % r_id) RadioError: Unsupported model `TM-D710' ----------------------------
Hi David,
I did some tests and it seems that the Kenwood TH-F6A support is close but it's missing the memory's NAME which is very important to me.
Hmm, I recall that working as expected. When you set a name the radio just ignores it? If you close CHIRP and re-read the radio, does it show the name you set in CHIRP, or is it blank? Is it possible that it's setting the name, but not the bit to have the alpha name displayed instead of the frequency on the radio panel?
Unfortunately, I don't have an F6A and had to borrow one to write the driver. Can you send me the output that CHIRP generates after trying to set a memory name so I can see if something obvious is breaking?
I then tried the Kenwood D710 which communicated but didn't support and a Yaesu VX5 didn't work at all.
Yep, neither of these are supported yet, although I have a D710 on loan right now so support will come for that very soon. I don't have a VX5, nor do I know of anyone that has one for me to borrow. Selecting one of the other radio models definitely won't work, as they're all different. That's why the "Commander" software programs are all different for each model.
I also noticed I couldn't save any downloaded data nor upload anything back to the radios (see below).
You can. The F6A is a "live" radio which makes it behave a little different (it communicates with the radio in real-time and does not download an image). Any changes you make in the editor go back to the radio immediately. That's why there is no "upload" option and no "save" option, because it's manipulating the radio directly.
Once you've loaded it up, go to Radio->Export and save it to a CSV file. You can then import this into any of the other radios (like the 710 when it's supported), or load it directly in chirp for offline editing, or edit in a spreadsheet, etc.
Taking it a step further, I'm ideally looking for is a memory syncronization tool across different radios. I'm not looking for full backups (though that would be nice like Kenwood's Windows applications) but memories is good enough.
That's the purpose of CHIRP, synchronizing the memories. I have a single CSV file that I import into all of my radios to keep them identical.
- load multiple radio's data at the same time - merge and navigate
conflicts (move memories I added in the Car or at Home) and allow me to move them into free slots - come up with a new master file - program them back into each of the radios
That's doable, but wouldn't be very high on my list of priorities at the moment. I'll be glad to keep it in the back of my mind going forward.
Thanks!
Hello Dan,
Thanks for the reply and see inline..
Unfortunately, I don't have an F6A and had to borrow one to write the driver. Can you send me the output that CHIRP generates after trying to set a memory name so I can see if something obvious is breaking?
When Chirp reads the F6A and completes the download, the resulting table doesn't show it's name and the STDERR output from shell where I run the Chript Python script doesn't show the names of the memories either. Would the memory name not show but actually be getting captured?
Any thoughts on why the cancel doesn't work on the Yaesu radios? Is my Python environment missing something?
Yep, neither of these are supported yet, although I have a D710 on loan right now so support will come for that very soon. I don't have a VX5, nor do I know of anyone that has one for me to borrow. Selecting one of the other radio models definitely won't work, as they're all different. That's why the "Commander" software programs are all different for each model.
Great news on the D710 and I'll help test if if you'd like! Curious, will you only be capturing memories or will your tool also capturing all other user settings for say APRS, etc? It sure would be nice to be able to use Chirp for full backups, etc.
Have you chatted with the author of the VX commander software? It seems like he's been busy for a long time and he might be willing to send you his source code for that alpha version of the tool. Regardless, I'd be willing to work with you on this one if you want (if that works for how you develop things) and, if it came down to it, I could loan you my VX5.
You can. The F6A is a "live" radio which makes it behave a little different (it communicates with the radio in real-time and does not download an image). Any changes you make in the editor go back to the radio immediately. That's why there is no "upload" option and no "save" option, because it's manipulating the radio directly.
Oh.. interesting and thanks for setting me strait. There has to be a way to make a change to the GUI that would maybe give a pop-up about this fact.
That's doable, but wouldn't be very high on my list of priorities at the moment. I'll be glad to keep it in the back of my mind going forward
Thanks for considering it! I do understand that this can be manually done and that might be the best method. I do have some ideas of how the UI would function though if you do ever get to it:
- When a radio's data is downloaded, load it's data into the table but have say the first column naming which radio it came from
- When the next radio's data is downloaded, merge that into the table. If a given row is identical from both radios, change the 1st row cell's name to reflect both radios - If a given row (memory slot) are different (conflict), add an additional row reflecting the 2nd radio's name, it's data, and maybe put it in a different color - alternatively, maybe these radios have a unique ID like a serial number, user setable name, etc. so use that
- offer a pulldown for this conflict row and ideally REMEMBER this decision (maybe this remembering would be more troublesome than what it's worth): - override the master row - move to memory slot: ### (drag and drop would be slick but that might be hard in Python) - keep unique to this radio - delete
The reason for the "keep unique to this radio" would be say on my two D710s, one has an APRS SSID of "KI6ZHD" and another that has "KI6ZHD-9". If I could use this tool to merge data while keeping some settings unique would be ideal.
--David
When Chirp reads the F6A and completes the download, the resulting table doesn't show it's name and the STDERR output from shell where I run the Chript Python script doesn't show the names of the memories either. Would the memory name not show but actually be getting captured?
Do you mean the column is missing or the values are blank? If the column is missing, add it in the View menu. However, you should be seeing them in the stderr output, as you mentioned.
Any thoughts on why the cancel doesn't work on the Yaesu radios? Is my Python environment missing something?
Oh, right, I meant to mention that. Apparently you're missing the 'ctypes' module. What Python and OS version are you running?
Great news on the D710 and I'll help test if if you'd like! Curious, will you only be capturing memories or will your tool also capturing all other user settings for say APRS, etc? It sure would be nice to be able to use Chirp for full backups, etc.
CHIRP has mostly focused on just memories in the past, although it does support more options for D-STAR.
The Kenwood radios are really a lot easier to do than the other types, so I wouldn't be opposed to starting down that road on some of those. The only problem is that I have a D700 in my car, but that's my only one, so it's not very convenient for development.
Have you chatted with the author of the VX commander software? It seems like he's been busy for a long time and he might be willing to send you his source code for that alpha version of the tool.
I haven't, but other people have reportedly solicited some input from him and have not been very pleased with the results.
Regardless, I'd be willing to work with you on this one if you want (if that works for how you develop things) and, if it came down to it, I could loan you my VX5.
Your call. I'd be glad to do the work and get it back to you if you want to send it. I'm able to reverse engineer most radios in about 48 hours (wall clock time) depending on what else I have going on.
Oh.. interesting and thanks for setting me strait. There has to be a way to make a change to the GUI that would maybe give a pop-up about this fact.
Well, I could. It used to be that the live radios were treated a little differently in the UI than the clone types, and it generated confusion for a lot of people. Moving to a more unified approach has made it a lot easier to use. Maybe a "FYI this is live" pop-up with a "don't show me this again" checkbox would be appropriate.
- When a radio's data is downloaded, load it's data into the table but
have say the first column naming which radio it came from
- When the next radio's data is downloaded, merge that into the table.
If a given row is identical from both radios, change the 1st row cell's name to reflect both radios
- If a given row (memory slot) are different (conflict), add an
additional row reflecting the 2nd radio's name, it's data, and maybe put it in a different color
- alternatively, maybe these radios have a unique ID like a serial
number, user setable name, etc. so use that
- offer a pulldown for this conflict row and ideally REMEMBER this
decision (maybe this remembering would be more troublesome than what it's worth):
- override the master row
- move to memory slot: ### (drag and drop would be slick but that might
be hard in Python)
- keep unique to this radio
- delete
Feel free to document the above in a tracker item to (a) remind me and (b) preserve it for when we get there. You can do that here:
http://trac.chirp.danplanet.com
Thanks!
Your call. I'd be glad to do the work and get it back to you if you want to send it. I'm able to reverse engineer most radios in about 48 hours (wall clock time) depending on what else I have going on.
On second thought, let me use the software to emulate the radio, and then I'll let you test it with the real radio to make sure it works. The yaesus are extremely sensitive to timing (compared to the Icom and Kenwood radios), so it's not uncommon for me to need to do some tweaking after the protocol is in place.
So, stay tuned for some beta code for the VX5 and lets see how it goes, okay?
Hello Dan,
Do you mean the column is missing or the values are blank? If the column is missing, add it in the View menu. However, you should be seeing them in the stderr output, as you mentioned.
the column is blank as is the output of STDERR. Please see my original post for an example of what's seen in the STDERR output.
Any thoughts on why the cancel doesn't work on the Yaesu radios? Is my Python environment missing something?
Oh, right, I meant to mention that. Apparently you're missing the 'ctypes' module. What Python and OS version are you running?
Also mentioned in the first email: Centos 5.5. I have two versions of Python installed but, by default, it will run the 2.4.3 version which is the Centos stock version. python-2.4.3-27.el5_5.3 python25-2.5.1-bashton1
If I try to use the 2.5 version, it seems like many of my other modules are no longer found. I've seen this before but I don't know how to populate one version of Python's modules into a different version of Python: -- $ /usr/bin/python2.5 chirpw Traceback (most recent call last): File "chirpw", line 24, in <module> import gtk ImportError: No module named gtk --
The Kenwood radios are really a lot easier to do than the other types, so I wouldn't be opposed to starting down that road on some of those. The only problem is that I have a D700 in my car, but that's my only one, so it's not very convenient for development.
Yeah.. I can understand that and they aren't all that cheap either. I would assume they are fairly similar but maybe that's a bad assumption.
Have you chatted with the author of the VX commander software? It seems like he's been busy for a long time and he might be willing to send you his source code for that alpha version of the tool.
I haven't, but other people have reportedly solicited some input from him and have not been very pleased with the results.
Hmmmm... maybe that's when he still had time for things.. maybe things have changed? I can try if you'd like.
Your call. I'd be glad to do the work and get it back to you if you want to send it. I'm able to reverse engineer most radios in about 48 hours (wall clock time) depending on what else I have going on.
Well, like I mentioned, the VX5 is the bottom of my list so I rather you spend your time on the D710 first and then, if you're willing, I can ship it up.
Well, I could. It used to be that the live radios were treated a little differently in the UI than the clone types, and it generated confusion for a lot of people. Moving to a more unified approach has made it a lot easier to use. Maybe a "FYI this is live" pop-up with a "don't show me this again" checkbox would be appropriate.
That would help though I think most people won't understand what a "live" radio means. Most programs that people have used like Kenwood's radios, VX commander, etc. are batch download/upload tools. I prefer this live approach though!
Feel free to document the above in a tracker item to (a) remind me and (b) preserve it for when we get there. You can do that here:
Will do!
On second thought, let me use the software to emulate the radio, and then I'll let you test it with the real radio to make sure it works. The yaesus are extremely sensitive to timing (compared to the Icom and Kenwood radios), so it's not uncommon for me to need to do some tweaking after the protocol is in place.
So, stay tuned for some beta code for the VX5 and lets see how it goes, okay?
Did you notice in my original email that there was some data output when I selected the VX3 mode? Does that help at all?
--David
the column is blank as is the output of STDERR. Please see my original post for an example of what's seen in the STDERR output.
Your initial email shows the output of it trying to fetch a name. I want you to edit the name field and show me the output of it trying to set it (to see if the radio reports anything different).
Also mentioned in the first email: Centos 5.5. I have two versions of Python installed but, by default, it will run the 2.4.3 version which is the Centos stock version.
Okay, yeah, python 2.4 apparently didn't have ctypes. So, you won't be able to cancel a blocking operation on older versions. I'll have to make it handle that more gracefully.
If I try to use the 2.5 version, it seems like many of my other modules are no longer found. I've seen this before but I don't know how to populate one version of Python's modules into a different version of Python:
You need to install them specially for the newer version. For the XML and GTK libraries you need to use, that will likely be more trouble than it's worth.
Yeah.. I can understand that and they aren't all that cheap either. I would assume they are fairly similar but maybe that's a bad assumption.
They are the most similar of any of the brands, but as you can see from your F6A experience, they do differ enough to break things now and then. For the most part, the F6A driver uses all the same code as the D700, D7, and (soon to be) the D710. However, some of the command strings are formatted just a bit different.
Hmmmm... maybe that's when he still had time for things.. maybe things have changed? I can try if you'd like.
He was solicited within the last couple of months, but feel free to try again :)
Well, like I mentioned, the VX5 is the bottom of my list so I rather you spend your time on the D710 first and then, if you're willing, I can ship it up.
Okay, I'll let you know.
That would help though I think most people won't understand what a "live" radio means. Most programs that people have used like Kenwood's radios, VX commander, etc. are batch download/upload tools.
Yeah, I was just being short. The box would need to explain the situation.
I prefer this live approach though!
Yeah, a lot of people want to be able to script interaction with the radio so that they can automate a base station.
Did you notice in my original email that there was some data output when I selected the VX3 mode? Does that help at all?
It depends. It looks like it might be the 10-byte identification block that most of the Yaesu handhelds use to initiate a clone, but it's not as obvious as most of the other models. Regardless, *all* of them use a completely different in-memory format, so there's a *lot* of work to be done for each new model :)
Thanks!
Hey Dam,
Your initial email shows the output of it trying to fetch a name. I want you to edit the name field and show me the output of it trying to set it (to see if the radio reports anything different).
When I try to write a memory's name, the new name shows up in the UI and STDERR shows: -- PC->D7: MW 0,055,00224040000,0,0,0,0,0,0,08,08,000,000600000,0,0 D7->PC: MW PC->D7: MNA 055,test D7->PC: MNA 055,test --
The Radio-->Upload to Radio option is greyed out (expected as this is a "live" radio)
If I restart the chirp program, the memory name is missing in UI after the radio memory load as well as STDERR: -- D7->PC: N PC->D7: MR 0,055 D7->PC: MR 0,055,00224040000,0,0,0,0,0,0,08,08,000,000600000,0,0 PC->D7: MNA MNA 0,055 D7->PC: N --
Interestingly enough, the memory NAME *is* programmed into the radio! Tthis seems to be a display bug in the UI and STDERR.
Yeah, a lot of people want to be able to script interaction with the radio so that they can automate a base station.
That's cool! I wish the D710 could do this via the TNC connection but it actually requires a second serial connection to the base to control the frequency control. Grrrr...
Btw... few more things to report on the TH-F6A:
1) I cannot save the download memories. The File --> Save and "Save As" are greyed out. Maybe these options aren't used as there is Radio --> "Export to" ?
2) By default, when downloading the memories on a THF6A, it downloads memories 0-399 but displays 0-25. If I change the "Memories Memory range" to say 0-399 and click on go, it re-downloads all 400 memories which takes a long time. This re-download should be suppressed.
3) If I try to edit an entry, say memory slot 55, and I type in a repeater name and then hit enter, I get a dialog box saying "Error setting memory: Frequency 0.000000 is out of range." It then proceeds to re-read the entire radio's memory which take a while (this re-download should be suppressed. The UI should either require the user to enter in the frequency FIRST or it should let the user enter in the memory's name but not upload the name it until a frequency is also entered in.
4) I'm also curious, I imagine that these LIVE radios are using NVRAM which has limited writes before the memory will begin to fail. Is it wise to send lots of little writes like this vs. suppress all updates until the data set is complete?
5) When I was doing some testing (I think I accidentally tried to write to an empty memory slot: -- Exception running RadioJob: 54 -- Exception: -- Traceback (most recent call last): File "/usr/src/archive/Chirp/chirp-0.1.11b4/chirpui/common.py", line 70, in execute result = func(*self.args, **self.kwargs) File "/usr/src/archive/Chirp/chirp-0.1.11b4/chirp/kenwood_live.py", line 174, in erase_memory del self.__memcache[number] KeyError: 54 ------
6) I've also seen error like the following where chirp is working fine and then it breaks. Notice that the radio's name in STDERR goes from D7 to E7 which might be expected but I'm not sure. -- PC->D7: MR 0,357 D7->PC: N PC->D7: MR 0,358 D7->PC: N PC->D7: MR 0,359 E7->PC: N E't sure what to do with this: `N Exception running RadioJob: Unexpected result returned from radio -- Exception: -- Traceback (most recent call last): File "/usr/src/archive/Chirp/chirp-0.1.11b4/chirpui/common.py", line 70, in execute result = func(*self.args, **self.kwargs) File "/usr/src/archive/Chirp/chirp-0.1.11b4/chirp/kenwood_live.py", line 129, in get_memory raise errors.RadioError("Unexpected result returned from radio") RadioError: Unexpected result returned from radio ------ Job Args: (359,) Job KWArgs: {} PC->D7: MR 0,360 E7->PC: E E't sure what to do with this: `E Exception running RadioJob: Unexpected result returned from radio -- Exception: -- Traceback (most recent call last): File "/usr/src/archive/Chirp/chirp-0.1.11b4/chirpui/common.py", line 70, in execute result = func(*self.args, **self.kwargs) File "/usr/src/archive/Chirp/chirp-0.1.11b4/chirp/kenwood_live.py", line 129, in get_memory
6) Erasing say memory #55 grey's out the entry in the UI and the status field gets stuck on "[1] Erasing memory 55". Nothing happens to the radio's memory.
If I restart the chirp program, the memory name is missing in UI after the radio memory load as well as STDERR: -- D7->PC: N PC->D7: MR 0,055 D7->PC: MR 0,055,00224040000,0,0,0,0,0,0,08,08,000,000600000,0,0 PC->D7: MNA MNA 0,055 D7->PC: N
Ah, I see the problem. That second-to-last line should be "MNA 0,055". It has an extra "MNA" in there and the radio NAKs it with 'N'. I should be able to fix that here and shoot you an update to verify.
- I cannot save the download memories. The File --> Save and "Save As"
are greyed out. Maybe these options aren't used as there is Radio --> "Export to" ?
Correct. "Save" means "Save an image". There is no image for a live radio, so you can't do that.
I've already added the aforementioned notice dialog, which explains this. You should see that in the next round.
- By default, when downloading the memories on a THF6A, it downloads
memories 0-399 but displays 0-25. If I change the "Memories Memory range" to say 0-399 and click on go, it re-downloads all 400 memories which takes a long time. This re-download should be suppressed.
It's cached on some of the other live radios, and I can do the same for the kenwood ones. You are, I believe, the first person to attempt using the kenwood driver(s) other than myself and a small circle of friends :)
- If I try to edit an entry, say memory slot 55, and I type in a
repeater name and then hit enter, I get a dialog box saying "Error setting memory: Frequency 0.000000 is out of range." It then proceeds to re-read the entire radio's memory which take a while (this re-download should be suppressed. The UI should either require the user to enter in the frequency FIRST or it should let the user enter in the memory's name but not upload the name it until a frequency is also entered in.
That has been fixed in the repository already, since the beta you are using was posted.
- I'm also curious, I imagine that these LIVE radios are using NVRAM
which has limited writes before the memory will begin to fail. Is it wise to send lots of little writes like this vs. suppress all updates until the data set is complete?
I guess I can't really speak to that. However, I can say that all of the radios I've ever looked at do a lot of "scratch pad" type operations on the same memory that stores all of this data. Even powering on the radio generates a write. Every click of the dial in VFO mode generates a write. I think that if the NVRAM was likely to wear out (like flash does), the radios would be more frugal.
- When I was doing some testing (I think I accidentally tried to write
to an empty memory slot:
Exception running RadioJob: 54 -- Exception: -- Traceback (most recent call last): File "/usr/src/archive/Chirp/chirp-0.1.11b4/chirpui/common.py", line 70, in execute result = func(*self.args, **self.kwargs) File "/usr/src/archive/Chirp/chirp-0.1.11b4/chirp/kenwood_live.py", line 174, in erase_memory del self.__memcache[number] KeyError: 54
Ah, good one, thanks. Can you file a tracker item for that?
- I've also seen error like the following where chirp is working fine
and then it breaks. Notice that the radio's name in STDERR goes from D7 to E7 which might be expected but I'm not sure.
Hmm, yeah, that's interesting for sure. That might be one I have to reproduce locally.. That's pretty strange.
- Erasing say memory #55 grey's out the entry in the UI and the status
field gets stuck on "[1] Erasing memory 55". Nothing happens to the radio's memory.
Yeah, this is related to #5.
I sure am glad someone is finally giving the kenwood driver(s) a workout, thanks! :)
Ah, I see the problem. That second-to-last line should be "MNA 0,055". It has an extra "MNA" in there and the radio NAKs it with 'N'. I should be able to fix that here and shoot you an update to verify.
Cool. Curious, can I download directly from your repository (CVS, SVN, GIT, etc.)? I haven't seen any URLs, instructions, etc. to do so. Probably intentional.
- When I was doing some testing (I think I accidentally tried to write
to an empty memory slot:
Exception running RadioJob: 54 -- Exception: -- Traceback (most recent call last): File "/usr/src/archive/Chirp/chirp-0.1.11b4/chirpui/common.py", line 70, in execute result = func(*self.args, **self.kwargs) File "/usr/src/archive/Chirp/chirp-0.1.11b4/chirp/kenwood_live.py", line 174, in erase_memory del self.__memcache[number] KeyError: 54
Ah, good one, thanks. Can you file a tracker item for that?
Done: TRAC #78
Fyi...
1) if I go to http://trac.chirp.danplanet.com/trac and click on "See open tickets". Nothing happens. If I go to "View tickets" in the navigation bar, that works
2) When creating a new bug, the TRAC interface doesn't know anything about 0.1.11
- I've also seen error like the following where chirp is working fine
and then it breaks. Notice that the radio's name in STDERR goes from D7 to E7 which might be expected but I'm not sure.
Hmm, yeah, that's interesting for sure. That might be one I have to reproduce locally.. That's pretty strange.
Btw.. if the vrious Kenwood radios are a little different, shouldn't the STDERR show something like PC->F6 instead of PC->D7? Little misleading if that's supposed to represent the radio.
Yeah, this is related to #5.
I sure am glad someone is finally giving the kenwood driver(s) a workout, thanks! :)
I'm glad I can help out as I've been looking for something like this for some time now! I'm going to add your tool to my HamPacket documentation which is a Step-by-Step guide for creating a Linux-base HAM shack for VHF/UHF/HF TNC and "soundcard" packet, FLdigi, JT65, etc.
http://www.trinityos.com/HAM/index-ham.html
--David
Cool. Curious, can I download directly from your repository (CVS, SVN, GIT, etc.)? I haven't seen any URLs, instructions, etc. to do so. Probably intentional.
It's mercurial, and it's here:
I sent you instructions directly for getting a snapshot without having to use mercurial.
- if I go to http://trac.chirp.danplanet.com/trac and click on "See
open tickets". Nothing happens. If I go to "View tickets" in the navigation bar, that works
Yes, sorry about that.
- When creating a new bug, the TRAC interface doesn't know anything
about 0.1.11
Yes, I'm lazy, sorry about that :)
Btw.. if the vrious Kenwood radios are a little different, shouldn't the STDERR show something like PC->F6 instead of PC->D7? Little misleading if that's supposed to represent the radio.
They all use the common routines, of which the TH-D7 was the first. The user(s) aren't supposed to see the stderr output, of course, and I know better :)
I'm glad I can help out as I've been looking for something like this for some time now! I'm going to add your tool to my HamPacket documentation which is a Step-by-Step guide for creating a Linux-base HAM shack for VHF/UHF/HF TNC and "soundcard" packet, FLdigi, JT65, etc.
http://www.trinityos.com/HAM/index-ham.html
Great, thanks!
Ah, I see the problem. That second-to-last line should be "MNA 0,055". It has an extra "MNA" in there and the radio NAKs it with 'N'. I should be able to fix that here and shoot you an update to verify.
Ok, let me know when you find some time to change that and I'll test it.
- I cannot save the download memories. The File --> Save and "Save As"
are greyed out. Maybe these options aren't used as there is Radio --> "Export to" ?
Correct. "Save" means "Save an image". There is no image for a live radio, so you can't do that.
I've already added the aforementioned notice dialog, which explains this. You should see that in the next round.
I just tried out the chirp-hg-6e6ab5a16f39 TIP and that dialog box is perfect! That helps a lot!
- By default, when downloading the memories on a THF6A, it downloads
memories 0-399 but displays 0-25. If I change the "Memories Memory range" to say 0-399 and click on go, it re-downloads all 400 memories which takes a long time. This re-download should be suppressed.
It's cached on some of the other live radios, and I can do the same for the kenwood ones. You are, I believe, the first person to attempt using the kenwood driver(s) other than myself and a small circle of friends :)
If you download all 400 memories, why limit the display to only the first 25? Why not make the default display be 0-399?
Anyway, I'll keep the comments coming and I intend them only to be constructive.. by no means am I nitpicking at this fantastic and appreciated tool!
- If I try to edit an entry, say memory slot 55, and I type in a
repeater name and then hit enter, I get a dialog box saying "Error setting memory: Frequency 0.000000 is out of range." It then proceeds to re-read the entire radio's memory which take a while (this re-download should be suppressed. The UI should either require the user to enter in the frequency FIRST or it should let the user enter in the memory's name but not upload the name it until a frequency is also entered in.
That has been fixed in the repository already, since the beta you are using was posted.
This newest tip of tree still shows the same behavior but there is a new bug. It seems to be sendingsomething which freaks out the radio out and again, the name is shifting from D7 to E7: -- was D7->PC: N PC->D7: MR 0,053 D7->PC: MR 0,053,00224040000,7,2,0,1,0,0,12,08,000,001600000,0,0 PC->D7: MNA 0,053
now PC->D7: MR 0,059 D7->PC: N PC->D7: MR 0,060 D7->PC: N PC->D7: MW 0,054,00224000000,0,0,0,0,0,0,08,08,000,000600000,0,0 E7->PC: E PC->D7: MNA 054, E7->PC: E PC->D7: MW 0,054,00224000000,0,0,0,0,0,0,08,08,000,000600000,0,0 E7->PC: E PC->D7: MNA 054, E7->PC: E PC->D7: MW 0,054,00224000000,0,0,0,0,0,0,08,08,000,000600000,0,0 E7->PC: E PC->D7: MNA 054,test E7->PC: E PC->D7: MR 0,000 E7->PC: E E't sure what to do with this: `E Exception running RadioJob: Unexpected result returned from radio -- Exception: -- Traceback (most recent call last): File "/usr/src/archive/Chirp/chirp-hg-6e6ab5a16f39/chirpui/common.py", line 70, in execute result = func(*self.args, **self.kwargs) File "/usr/src/archive/Chirp/chirp-hg-6e6ab5a16f39/chirp/kenwood_live.py", line 129, in get_memory raise errors.RadioError("Unexpected result returned from radio") RadioError: Unexpected result returned from radio ------ Job Args: (0,) Job KWArgs: {} PC->D7: MR 0,019 E7->PC: E E't sure what to do with this: `E Exception running RadioJob: Unexpected result returned from radio -- Exception: -- Traceback (most recent call last): File "/usr/src/archive/Chirp/chirp-hg-6e6ab5a16f39/chirpui/common.py", line 70, in execute result = func(*self.args, **self.kwargs) File "/usr/src/archive/Chirp/chirp-hg-6e6ab5a16f39/chirp/kenwood_live.py", line 129, in get_memory raise errors.RadioError("Unexpected result returned from radio") RadioError: Unexpected result returned from radio ------
I'm also seeing a behavior that I don't know is the radio, the USB cable, or something Chirp is doing but the serial system is getting corrupt and I have to disconnect the radio from the USB cable, the computer from the cable, let it deplete all it's energy and then things work again: -- info on the cable itself from Dmesg:
usb 3-1: new full speed USB device using uhci_hcd and address 14 usb 3-1: configuration #1 chosen from 1 choice pl2303 3-1:1.0: pl2303 converter detected usb 3-1: pl2303 converter now attached to ttyUSB0
When I start either Chirp 0.1.11b4 or the TIP of tree version:
PC->V71: ID V71->PC: PC->V71: ID V71->PC: f?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff?ff? PC->V71: ID V71->PC: x?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx???xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?xx?x PC->V71: ID V71->PC: ??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? --- Exception Dialog: Unable to probe radio model --- Traceback (most recent call last): File "/usr/src/archive/Chirp/chirp-hg-6e6ab5a16f39/chirpui/clone.py", line 150, in run cs.radio_class = detect.DETECT_FUNCTIONS[vendor](cs.port) File "/usr/src/archive/Chirp/chirp-hg-6e6ab5a16f39/chirp/detect.py", line 101, in detect_kenwoodlive_radio raise errors.RadioError("Unable to probe radio model") RadioError: Unable to probe radio model ---------------------------- --
--David
Ok, let me know when you find some time to change that and I'll test it.
I've already fixed it, and it's in the version you downloaded with the dialog box. Did that not make it work?
I just tried out the chirp-hg-6e6ab5a16f39 TIP and that dialog box is perfect! That helps a lot!
Cool.
If you download all 400 memories, why limit the display to only the first 25? Why not make the default display be 0-399?
Because on radios with 1200 memories, the processing and display can get a little slow. With the new preference store I just added to track your dialog box, I will be able to make it remember the last used value.
This newest tip of tree still shows the same behavior
You're right, my patch for that is queued behind something else that isn't in the tree yet. I'll be there soon :)
but there is a new bug. It seems to be sendingsomething which freaks out the radio out and again, the name is shifting from D7 to E7:
This looks the same as the other issue you pointed out. I'm working on getting an F6A to borrow so I can try to reproduce this.
I'm also seeing a behavior that I don't know is the radio, the USB cable, or something Chirp is doing but the serial system is getting corrupt and I have to disconnect the radio from the USB cable, the computer from the cable, let it deplete all it's energy and then things work again:
<snip>
V71->PC: f�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�ff�f
Hmm, that looks *very* strange. What kind of USB adapter is it? Do you use it for other things successfully?
[resend from the right identity]
Ah, I see the problem. That second-to-last line should be "MNA 0,055". It has an extra "MNA" in there and the radio NAKs it with 'N'. I should be able to fix that here and shoot you an update to verify.
Cool. Curious, can I download directly from your repository (CVS, SVN, GIT, etc.)? I haven't seen any URLs, instructions, etc. to do so. Probably intentional.
- When I was doing some testing (I think I accidentally tried to write
to an empty memory slot:
Exception running RadioJob: 54 -- Exception: -- Traceback (most recent call last): File "/usr/src/archive/Chirp/chirp-0.1.11b4/chirpui/common.py", line 70, in execute result = func(*self.args, **self.kwargs) File "/usr/src/archive/Chirp/chirp-0.1.11b4/chirp/kenwood_live.py", line 174, in erase_memory del self.__memcache[number] KeyError: 54
Ah, good one, thanks. Can you file a tracker item for that?
Done: TRAC #78
Fyi...
1) if I go to http://trac.chirp.danplanet.com/trac and click on "See open tickets". Nothing happens. If I go to "View tickets" in the navigation bar, that works
2) When creating a new bug, the TRAC interface doesn't know anything about 0.1.11
- I've also seen error like the following where chirp is working fine
and then it breaks. Notice that the radio's name in STDERR goes from D7 to E7 which might be expected but I'm not sure.
Hmm, yeah, that's interesting for sure. That might be one I have to reproduce locally.. That's pretty strange.
Btw.. if the vrious Kenwood radios are a little different, shouldn't the STDERR show something like PC->F6 instead of PC->D7? Little misleading if that's supposed to represent the radio.
Yeah, this is related to #5.
I sure am glad someone is finally giving the kenwood driver(s) a workout, thanks! :)
I'm glad I can help out as I've been looking for something like this for some time now! I'm going to add your tool to my HamPacket documentation which is a Step-by-Step guide for creating a Linux-base HAM shack for VHF/UHF/HF TNC and "soundcard" packet, FLdigi, JT65, etc.
http://www.trinityos.com/HAM/index-ham.html
--David
participants (3)
-
Dan Smith -
David A. Ranch -
David Ranch