New Model #1287
closedKenwood TM-D710G
0%
Description
I have a TM-D710G model and can issue commands to gather data if you need so you can add it to Chirp. I have tried but it doesn't work with current version.
Updated by Tom Hayward almost 11 years ago
- Status changed from New to Blocked
Try going through the command reference for the D710A (found on the D710 Yahoo Group) and document the differences.
Updated by Tom Hayward almost 11 years ago
Any luck with this? I suspect most or all of the commands are the same, but the fields returned might be different. This was the case going from the D710 to the D72. I expect the D710G to be very similar to the D72.
Updated by John Ronan over 10 years ago
Hi,
Tried chirp last night on my TM-D710GE (with wideband TX mod), it wasn't able to recognise my Radio (Windows download), but I'll try a build from source this evening. Is there any diagnostics I can perform?
Thanks
John
Updated by Patrick Lang almost 10 years ago
I'm getting "An error has occurred. Unsupported model 'TM-D710G'" as well. Chirp 0.40
I'll look into the docs, I don't think there should be any substantial changes to the programming side from the TM-D710A or even TM-V71A from my understanding
Updated by Patrick Lang almost 10 years ago
I'm still waiting on the yahoo group membership to get the protocol document, but I added it as a new model inheriting from the existing D710 class and it seems to be working so far for reading and writing memory.
Updated by Patrick Lang almost 10 years ago
This looks like the same field order as the older TM-D710A, rather than the TM-D72. It has 16 fields, and reading/writing memory seems ok as-is.
Here's some examples I pulled using a term emulator:
ME 000,0146820000,0,2,0,1,0,0,13,08,000,00600000,0,0000000000,0,0
ME 001,0146960000,0,2,0,1,0,0,13,08,000,00600000,0,0000000000,0,0
ME 003,0147340000,0,1,0,1,0,0,12,08,000,00600000,0,0000000000,0,0
ME 004,0145490000,0,2,0,1,0,0,13,08,000,00600000,0,0000000000,0,0
ME 005,0145110000,0,2,0,1,0,0,13,08,000,00600000,0,0000000000,0,0
N
ME u0
,0144390000,0,0,0,1,0,0,29,08,000,00600000,0,0000000000,0,0
ME u1
,0144950000,0,0,0,1,0,0,29,08,000,00600000,0,0000000000,0,0
N
N
MN 000,K7LED
MN 002,K7NWS
MN 003,K6RFK
MN u0
,APRS
MN u1
,W7EFR-10
After setting lockout on #4 K7LWH
ME 004,0145490000,0,2,0,1,0,0,13,08,000,00600000,0,0000000000,0,1
Fields
ME 004, - 0 channel number
0145490000, - 1 frequency
0, - 2 tuning step
2, - 3 duplex (-)
0, - 4
1, - 5 tone
0, - 6 tone sql
0, - 7 DTCS
13, - 8 rtone
08, - 9 ctone
000, - 10 DTCS
00600000, - 11 offset
0, - 12 mode
0000000000, - 13 split tx frequency
0, - 14 - unknown
1 - 15 - lockout / mem skip
Updated by Tom Hayward almost 10 years ago
So all we need is the model detection? Are you planning to submit a patch to add this? I would also add the experimental warning since this radio has only been lightly tested.
Updated by Patrick Lang almost 10 years ago
I'm planning to submit a patch within a few days. I'm digging into the code a bit more to see if there are any other model differences that need to be addressed such as valid_name_length. I'd like to be able to make some other improvements later on and going through the normal patch/review process seems like a good first step. I also have a TH-D7 and access to a TH-D72 for testing.
Updated by Rob Ogilvie almost 9 years ago
Are there any updates to this? I have a TM-D710G (the seller reports it as the D710GA, but CHIRP reports it as the TM-D710GP) and I'm trying to work out how difficult it would be to implement support for my radio.
As I only have Mac and Linux systems available, I'm actually unable to program my radio currently, which is quite inconvenient.
Updated by A R about 8 years ago
Rob Ogilvie wrote:
Are there any updates to this? I have a TM-D710G (the seller reports it as the D710GA, but CHIRP reports it as the TM-D710GP) and I'm trying to work out how difficult it would be to implement support for my radio.
As I only have Mac and Linux systems available, I'm actually unable to program my radio currently, which is quite inconvenient.
I experienced the same issue. Simple solution: use the port on the back of the radio, not the faceplate. Then CHIRP will correctly identify the model.
Updated by Rick DeWitt almost 5 years ago
- Status changed from Blocked to Closed
- Chirp Version changed from 0.3.0 to daily
Closed to avoid showing up on Open issue search.