Re: [chirp_users] Kenwood TM-D710GA Issues
I'm saving this reply to my Kenwood notes, because I'm sure that I'll forget the answer by the next time I want to know. I interpret the answer to mean that I can screw up my radio with MCP, and can't with CHIRP?
~R~
On 2018-05-04 18:16:+0000, Tom Hayward wrote:
On Fri, May 4, 2018 at 3:55 AM Rich Messeder <mailto:NE1EE@hotmail.comNE1EE@hotmail.com> wrote: I recall having problems with this, too (F6A, V71A). I found that MCP was not "live" and would capture snapshots of all the memories, but CHIRP won't. I don't understand why CHIRP insists that updating must be live, when MCP doesn't. Awkward.
MCP and live mode are two completely different protocols supported by the F6, V71, and D710. The reasoning for Chirp using live mode has been discussed here many times. Chiefly, in live mode, the radio has the ability to reject a channel as invalid. This is really valuable when you're relying on guessing the protocol specification, like Chirp does. MCP toggles bits on the radio without any validation, so you better know what you're doing when toggling something. The writers of the MCP software had the advantage of being able to reference Kenwood's internal protocol documentation.
Tom KD7LXL
On Fri, May 4, 2018 at 11:31 AM Rich Messeder NE1EE@hotmail.com wrote:
I interpret the answer to mean that I can screw up my radio with MCP, and can't with CHIRP?
First let's clarify the nomenclature: MCP is both a protocol and the first part of the name of various software programs (MCP-2A, MCP-4A, MCP-6A, etc.).
There are Chirp drivers that implement both the MCP protocol and live mode protocols. For example, in Chirp you'll find the "TH-D72 (clone mode)" driver implements MCP and the "TH-D72 (live mode)" driver implements live mode (basically Kenwood's rig control protocol). There have been weird bugs in the past related to incorrect implementation of the MCP protocol that affected only the clone mode driver: https://chirp.danplanet.com/issues/1611
There have been similar bugs with data initialization in RT Systems software, which also uses the MCP protocol. Here's discussion of one: https://groups.yahoo.com/neo/groups/Kenwood_TH-D74/conversations/messages/28...
I don't know of any protocol bugs with Kenwood MCP-2A/4A/6A software, but it's still possible. The writers have the benefit of being first-party to the specifications, so it's far less likely.
And I've never heard of this sort of bug with any of the live mode drivers, since the radios do a pretty good job of rejecting bad data in this mode.
Tom KD7LXL
Is this the protocol?
https://www.magtek.com/content/documentationfiles/d99875163.pdf
On 5/4/2018 3:17 PM, Tom Hayward wrote:
First let's clarify the nomenclature: MCP is both a protocol and the first part of the name of various software programs (MCP-2A, MCP-4A, MCP-6A, etc.).
On Fri, May 4, 2018 at 12:37 PM Charles Hargrove n2nov@nyc-arecs.org wrote:
Is this the protocol?
https://www.magtek.com/content/documentationfiles/d99875163.pdf
Looks like that's the protocol, but not the memory map for the radios that shows what bits do what and what the valid combinations are.
Tom KD7LXL
Some other bits of information which might help the programmers:
https://github.com/LA3QMA/TM-V71_TM-D710-Kenwood
http://n3ujj.com/manuals/control_commands.pdf
http://www.radiomanual.info/schemi/KENW_VU/TH-F6A_TH-F7E_protocol_informatio... (might give some ideas)
On 5/4/2018 3:36 PM, Charles Hargrove wrote:
Is this the protocol?
https://www.magtek.com/content/documentationfiles/d99875163.pdf
On 5/4/2018 3:17 PM, Tom Hayward wrote:
First let's clarify the nomenclature: MCP is both a protocol and the first part of the name of various software programs (MCP-2A, MCP-4A, MCP-6A, etc.).
On Fri, May 4, 2018, 13:00 Charles Hargrove n2nov@nyc-arecs.org wrote:
Some other bits of information which might help the programmers:
https://github.com/LA3QMA/TM-V71_TM-D710-Kenwood
http://n3ujj.com/manuals/control_commands.pdf
http://www.radiomanual.info/schemi/KENW_VU/TH-F6A_TH-F7E_protocol_informatio... (might give some ideas)
This is the live mode protocol. It has been implemented in Chirp for many years.
Tom KD7LXL
I am just looking for information that might help the programmers to institute the MCP protocol to avoid the problems that you alluded to before. The goal is to get ALL of the radios to take a single programming dump and not cripple a few with "live" mode. Obviously, the Kenwood MCP software can upload everything in one shot. Why not get Chirp to do the same?
On 5/5/2018 3:34 PM, Tom Hayward wrote:
This is the live mode protocol. It has been implemented in Chirp for many years.
Tom KD7LXL
Well, a week has gone by. I ran the comms for the 5 Boro Bike Tour last Sunday with 34,000 bikes over 40 miles. Since I could not get my D710GA programmed for it, I had to use my Anytone5888 which has never given me problems. So I am back at the Kenwood problem tonight. To start things off, I hand programmed about 50 memories in the MCP software and did an upload "in one go" without this "live mode" jazz. Everything is working perfectly. Now I go to Chirp, go to Download From Radio and choose the Kenwood on the same Comm Port as the MCP and ..... NOTHING! Not one channel downloads into Chirp. Nothing on any type of scroll bar. :(
Can anyone who has used Chirp with the D710GA tell me anything? No armchair theorists please.
On 5/5/2018 3:49 PM, Charles Hargrove wrote:
I am just looking for information that might help the programmers to institute the MCP protocol to avoid the problems that you alluded to before. The goal is to get ALL of the radios to take a single programming dump and not cripple a few with "live" mode. Obviously, the Kenwood MCP software can upload everything in one shot. Why not get Chirp to do the same?
On 5/5/2018 3:34 PM, Tom Hayward wrote:
This is the live mode protocol. It has been implemented in Chirp for many years.
Tom KD7LXL
Starting with the simple solution first. Click the down arrow on Port and see if there is a different port.
I know with my Boafeng, if I plug the cable into a different USB port the COM port changes also. And sometimes the old one will still be listed and I have to manually move to the new port.
Try that first.
Dennis M. Wage
245 Corum Hill Road Castalian Springs, TN 37031 (615) 310-4242 Cell (615) 562-5128 Home http://hammondb3organ.net http://overdubs.net
On Sat, May 12, 2018 at 10:03 PM, Charles Hargrove n2nov@nyc-arecs.org wrote:
Well, a week has gone by. I ran the comms for the 5 Boro Bike Tour last Sunday with 34,000 bikes over 40 miles. Since I could not get my D710GA programmed for it, I had to use my Anytone5888 which has never given me problems. So I am back at the Kenwood problem tonight. To start things off, I hand programmed about 50 memories in the MCP software and did an upload "in one go" without this "live mode" jazz. Everything is working perfectly. Now I go to Chirp, go to Download From Radio and choose the Kenwood on the same Comm Port as the MCP and ..... NOTHING! Not one channel downloads into Chirp. Nothing on any type of scroll bar. :(
Can anyone who has used Chirp with the D710GA tell me anything? No armchair theorists please.
On 5/5/2018 3:49 PM, Charles Hargrove wrote:
I am just looking for information that might help the programmers to institute the MCP protocol to avoid the problems that you alluded to before. The goal is to get ALL of the radios to take a single programming dump and not cripple a few with "live" mode. Obviously, the Kenwood MCP software can upload everything in one shot. Why not get Chirp to do the same?
On 5/5/2018 3:34 PM, Tom Hayward wrote:
This is the live mode protocol. It has been implemented in Chirp for many years.
Tom KD7LXL
-- Charles J. Hargrove - N2NOV NYC-ARECS/RACES Citywide Radio Officer/Skywarn Coord.
NYC-ARECS/RACES Nets 449.025/123.0 PL ARnewsline Broadcast Mon. @ 8:00PM NYC-ARECS Weekly Net Mon. @ 8:30PM http://www.nyc-arecs.org
NY-NBEMS Net Saturdays @ 10AM & USeast-NBEMS Net Wednesdays @ 7PM on 7.036 Mhz USB (alt 3.536)/1500 hz waterfall spot; MFSK-16 or 32
"Information is the oxygen of the modern age. It seeps through the walls topped by barbed wire, it wafts across the electrified borders." - Ronald Reagan
"The more corrupt the state, the more it legislates." - Tacitus
"Molann an obair an fear" - Irish Saying (The work praises the man.)
"No matter how big and powerful government gets, and the many services it provides, it can never take the place of volunteers." - Ronald Reagan _______________________________________________ chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users This message was sent to Dennis Wage at dwage@dwage.com To unsubscribe, send an email to chirp_users-unsubscribe@ intrepid.danplanet.com
I have been using Chirp since shortly after it came out. Yes, I have checked and that is not the problem. If I can get a clue from other users of this radio model, maybe something changed from earlier versions of Chirp.
On 5/13/2018 11:12 AM, Dennis Wage wrote:
Starting with the simple solution first. Click the down arrow on Port and see if there is a different port.
I know with my Boafeng, if I plug the cable into a different USB port the COM port changes also. And sometimes the old one will still be listed and I have to manually move to the new port.
Try that first.
Dennis M. Wage
245 Corum Hill Road Castalian Springs, TN 37031 (615) 310-4242 Cell (615) 562-5128 Home http://hammondb3organ.net http://hammondb3organ.net/ http://overdubs.net
On Sat, May 12, 2018 at 10:03 PM, Charles Hargrove <n2nov@nyc-arecs.org mailto:n2nov@nyc-arecs.org> wrote:
Well, a week has gone by. I ran the comms for the 5 Boro Bike Tour last Sunday with 34,000 bikes over 40 miles. Since I could not get my D710GA programmed for it, I had to use my Anytone5888 which has never given me problems. So I am back at the Kenwood problem tonight. To start things off, I hand programmed about 50 memories in the MCP software and did an upload "in one go" without this "live mode" jazz. Everything is working perfectly. Now I go to Chirp, go to Download From Radio and choose the Kenwood on the same Comm Port as the MCP and ..... NOTHING! Not one channel downloads into Chirp. Nothing on any type of scroll bar. :( Can anyone who has used Chirp with the D710GA tell me anything? No armchair theorists please. On 5/5/2018 3:49 PM, Charles Hargrove wrote: > I am just looking for information that might help the programmers to > institute the MCP protocol to avoid the problems that you alluded to > before. The goal is to get ALL of the radios to take a single > programming dump and not cripple a few with "live" mode. Obviously, > the Kenwood MCP software can upload everything in one shot. Why not > get Chirp to do the same? > > On 5/5/2018 3:34 PM, Tom Hayward wrote: >> This is the live mode protocol. It has been implemented in Chirp for >> many years. >> >> Tom KD7LXL
On Sat, May 12, 2018 at 8:04 PM Charles Hargrove n2nov@nyc-arecs.org wrote:
Can anyone who has used Chirp with the D710GA tell me anything? No armchair theorists please.
The only way to avoid guessing is to check the status bar and/or log file: https://chirp.danplanet.com/projects/chirp/wiki/How_to_report_issues#Getting...
Tom KD7LXL
The status bar never shows anything. Below is the end of the log file:
[2018-05-13 18:07:34,884] chirp.ui.reporting - DEBUG: Checking for updates [2018-05-13 18:07:35,243] chirp.ui.reporting - DEBUG: Server reports version daily-20180512 is latest [2018-05-13 18:07:58,138] chirp.ui.mainapp - DEBUG: User selected Kenwood TM-D710G on port COM4 [2018-05-13 18:07:58,138] chirp.drivers.kenwood_live - INFO: Trying ID at baud 9600 with delimiter "('\r', ' ')" [2018-05-13 18:07:58,263] chirp.drivers.kenwood_live - DEBUG: PC->RADIO: ID [2018-05-13 18:07:58,388] chirp.drivers.kenwood_live - DEBUG: RADIO->PC: ID TM-D710GP Traceback (most recent call last): File "chirp\ui\mainapp.pyo", line 1582, in mh File "chirp\ui\mainapp.pyo", line 689, in do_download File "chirp\drivers\kenwood_live.pyo", line 162, in __init__ Exception: Radio reports TM-D710GP (not TM-D710G)
On 5/13/2018 5:45 PM, Tom Hayward wrote:
On Sat, May 12, 2018 at 8:04 PM Charles Hargrove <n2nov@nyc-arecs.org mailto:n2nov@nyc-arecs.org> wrote:
Can anyone who has used Chirp with the D710GA tell me anything? No armchair theorists please.The only way to avoid guessing is to check the status bar and/or log file: https://chirp.danplanet.com/projects/chirp/wiki/How_to_report_issues#Getting...
Tom KD7LXL
On Sun, May 13, 2018 at 3:11 PM Charles Hargrove n2nov@nyc-arecs.org wrote:
Exception: Radio reports TM-D710GP (not TM-D710G)
Great, thanks. Now we're getting somewhere!
You didn't happen to plug the cable into the control head, did you? The memories are stored in the RF deck, not the control head, so you'll need to plug into the main radio body to program channels.
Tom KD7LXL
Interesting. The Kenwood MCP program can use the port on the control head. Maybe some retooling of the Kenwood module is in order? I can read the memories now. I still think that if the radio can perform as any other radio with a whole memory dump, then we can dispense with the "live" mode.
On 5/13/2018 6:19 PM, Tom Hayward wrote:
On Sun, May 13, 2018 at 3:11 PM Charles Hargrove <n2nov@nyc-arecs.org mailto:n2nov@nyc-arecs.org> wrote:
Exception: Radio reports TM-D710GP (not TM-D710G)Great, thanks. Now we're getting somewhere!
You didn't happen to plug the cable into the control head, did you? The memories are stored in the RF deck, not the control head, so you'll need to plug into the main radio body to program channels.
Tom KD7LXL
Why are the following statements showing as FALSE in the debug log when the Kenwood MCP program can handle them?
[2018-05-13 18:29:24,331] chirp.ui.memedit - INFO: DTCS Rx Code supported: False [2018-05-13 18:29:24,331] chirp.ui.memedit - INFO: DTCS Pol supported: False [2018-05-13 18:29:24,331] chirp.ui.memedit - INFO: Cross Mode supported: False [2018-05-13 18:29:24,331] chirp.ui.memedit - INFO: Comment supported: False [2018-05-13 18:29:24,331] chirp.ui.memedit - INFO: DTCS Rx Code supported: False [2018-05-13 18:29:24,331] chirp.ui.memedit - INFO: DTCS Pol supported: False [2018-05-13 18:29:24,345] chirp.ui.memedit - INFO: Cross Mode supported: False [2018-05-13 18:29:24,345] chirp.ui.memedit - INFO: Comment supported: False
On Sun, May 13, 2018, 15:32 Charles Hargrove n2nov@nyc-arecs.org wrote:
Interesting. The Kenwood MCP program can use the port on the control head. Maybe some retooling of the Kenwood module is in order? I can read the memories now. I still think that if the radio can perform as any other radio with a whole memory dump, then we can dispense with the "live" mode.
Very interesting. I have the original non-G model and it doesn't have this capability. I didn't realize that was one of the changes in the G model.
Tom KD7LXL
participants (4)
-
Charles Hargrove -
Dennis Wage -
Rich Messeder -
Tom Hayward