Radio control not setting second VFO in TM-D710

[RhinoLance]

Environment:

Hamlib:

• Raspbian, Kernel 4.4.39-v7
• Radio: Kenwood TM-D710

Gpredict:

• Windows 10 x64
• Gpredict v2.2.1
• Configuration
• Host: <IP of hamlib RPi
• Port: 4532
• Radio type: Duplex TRX
• PPT status: None
• VFO Up/Down B↑ / A↓
• LO Down: 0
• LO Up: 0

Issue

I have hamlib set up to control a Kenwood TM-D710 which is a full duplex radio.

If I manually enter the rigctl commands, I can set frequencies across both VFOA and VFOB as required, so know that hamlib is working, and the radio is able to respond to the commands accordingly.

Gpredict however will only ever set one VFO, so either VFO1 or VFO2.

I can change which, based on which VFO is selected when rigctld is started. As can be seen by the logs, debug2.txt only sets VFOA, and debug3.txt only sets VFOB.

Any thoughts, or ideas for additional debugging would be appreciated.

debug2.txt debug3.txt

[csete]

How is gpredict configured?

Can you reproduce the full duplex operation when using hamlib through the network daemon?

[csete]

Changed the title to include TM-D710 as gpredict is known to work well with many other duplex radios.

[mikaelnousiainen]

This may be related to the limitations of TM-D710. I rewrote the Hamlib backend some months ago and discovered that it was not possible to freely set the frequency of a VFO, but the frequency range is limited to the current band selected internally in the rig. It also seems there is no way to change the selected band of a VFO other than by selecting a stored memory channel (with frequency on a different band) and then going back to VFO mode. There are some comments in the backend code here: https://github.com/Hamlib/Hamlib/blob/master/kenwood/tmd710.c

It's a really nice radio with lots of features, but CAT control is very limited.

[RhinoLance]

@csete

• I've updated the report with the Gpredict configuration. If you're looking for something else, please let me know.
• From a "telnet" session on the Gpredict computer, I can connect to the hamlib daemon, and issue the following command: VVFOA F140000000 VVFOB F440000000 VVFOA, which works perfectly.

@mikaelnousiainen

• Such an awesome surname! No idea how you pronounce it with an Australian tongue!
• Yes, I noted that limitation whilst looking through the source code yesterday, so have made sure that the respective VFOs are in the correct band for what GPredict will send.

The route cause of the second VFO not being set, is this set of commands (as shown in debug2.txt in the Kenwood protocol: 077: kenwood_transaction: cmdstr = FO 1,0436800000,1,0,0,0,0,0,08,08,000,05000000,0 117: kenwood_transaction: cmdstr = FO 1,0145850000,1,0,0,0,0,0,08,08,000,05000000,0

The first parameter (1), dictates the VFO to set. As can be seen, both are trying to set the same VFO. I would have expected something like: 077: kenwood_transaction: cmdstr = FO 0,0436800000,1,0,0,0,0,0,08,08,000,05000000,0 117: kenwood_transaction: cmdstr = FO 1,0145850000,1,0,0,0,0,0,08,08,000,05000000,0

Because of the limitation noted by @mikaelnousiainen, we then see 85: kenwood_transaction: NegAck for 'FO 1,0436800000,1,0,0,0,0,0,08,08,000,05000000,0'

My wireshark trace shows the following between Gpredict and rigctld:

i
145850000
F  436792731
RPRT -11
i
145850000
I  145850758
RPRT 0
i
145850000
F  436792736
RPRT -11
i
145850000
I  145850756
RPRT 0

With that in mind, back to the source, where I think I've found the issue.
https://github.com/Hamlib/Hamlib/blob/master/src/rig.c#L2442

if (caps->set_split_freq)
{
    retcode = caps->set_split_freq(rig, vfo, tx_freq);
}
else
{
    retcode = caps->set_freq(rig, RIG_VFO_CURR, tx_freq);
}

Looking at tmd710.c, it doesn't support set_split_freq, so always defaults to trying to only change the VFO which was active when rigctld was started.

I've been messing a bit with the source to get something working, which sort of does, but I I think I'm missing some background, as it's still a little quirky, but the functions below code does at least let the I command change the second VFO.

/*
 * tmd710_get_split_freq
 * Assumes rig!=NULL, freq!=NULL
 */
int tmd710_set_split_freq(RIG *rig, vfo_t vfo, freq_t freq) {

     if( vfo == RIG_VFO_A) {
        vfo = RIG_VFO_B;
    }
    else {
        vfo = RIG_VFO_A;
    }

    rig_debug(RIG_DEBUG_TRACE, "%s: called\n", __func__);
     return tmd710_set_freq(rig, vfo, freq);
}

/*
 * tmd710_get_split_freq
 * Assumes rig!=NULL, freq!=NULL
 */
int tmd710_get_split_freq(RIG *rig, vfo_t vfo, freq_t *freq) {

    if( vfo == RIG_VFO_A) {
        vfo = RIG_VFO_B;
    }
    else {
        vfo = RIG_VFO_A;
    }

    rig_debug(RIG_DEBUG_TRACE, "%s: called\n", __func__);
    return tmd710_get_freq(rig, vfo, freq);
}

So at least now we know it's an issue with the TM-D710 "driver". Any further thoughts on how to progress this would be appreciated.

[RhinoLance]

OK, with some more digging, it appears the issue is Hamlib's TM-D710 driver which I now have working. As such, you can close this, and I'll resolve it on the Hamlib side.

@mikaelnousiainen I'll submit a pull request with my changes.

[mikaelnousiainen]

@RhinoLance Ok thanks -- yeah it seems that split may not have been handled correctly

[csete]

Thanks for the updates.