pat
pat copied to clipboard
la5nta
hamlib: Use PTT value 3 (TX data) by default
I can't use pat with a Kenwood TS-480, which is a very common rig. The problem is that the TS-480 (and presumably other rigs) has data audio in/out which is meant to be used with digital applications but pat makes a hard assumption that the hamlib PTT state is always either 0, meaning "don't transmit", or 1, meaning "transmit using audio from the mic input". That does not allow for PTT state = 3, which in hamlib means "transmit using audio from the data port, or else from the mic input if there is no data port on this rig". So with PTT state 1 you can only transmit using mic audio on a rig with a data audio input.
I have simply bludgeoned the relevant part of the code in rigctld.go/setPTT() to set PTT state to 3 instead of 1, which gets me past the problem for now but it should be fixed for others. I think the right solution is to add a config, perhaps in hamlib_rigs.
Thanks!
It sounds to me like the default should be "state 3" then, and users should be able to override this in the config.
From man rigctld:
T, set_ptt 'PTT'
Set 'PTT'.
PTT is a value: `0' (RX), `1' (TX), `2' (TX mic), or `3' (TX data).
This does not mention that "level 3" will fallback to TX mic when the data port is missing.
Can you provide us with the relevant references from the hamlib documentation?
Yes, the documentation for ptt_t, http://hamlib.sourceforge.net/manuals/3.0.1/group__rig.html#ga95f3c5dc1ea1e120cad829b7151a8bfe has the enum defining the PTT state for a VFO, as follows:
enum ptt_t Enumerator
RIG_PTT_OFF | PTT desactivated RIG_PTT_ON | PTT activated RIG_PTT_ON_MIC | PTT Mic only, fallbacks on RIG_PTT_ON if unavailable RIG_PTT_ON_DATA | PTT Data (Mic-muted), fallbacks on RIG_PTT_ON if unavailable
I think RIG_PTT_ON_DATA (==3) would be a more logical choice, assuming that people who are using rigs with a data port actually use that port to interface to their computers. That assumption seems plausible for the Kenwood TS-480 since the interface is easy and it even ships with the necessary connector. However, it may be much more convenient to use the mic input on other rigs that I am not aware of, in which case, RIG_PTT_ON_DATA would be a bad choice.
That means that it's probably best to put in the config but default it to 3 instead of 1.
It's hard for me to imagine that there's a rig out there with a data audio input but no mic input, which would make 2 useful. Whatever.
Thank you for the detailed response :)
I agree. State 3 seems to be a more reasonable default, and we should include a config option for it per "rig".
I will investigate this further soon, but I'm thinking we should switch to "state 3" and add an extra attribute to override it in the HamlibConfig struct... possibly a boolean or a custom "enum" type which are more understandable to the average user than the raw integer.
Hopefully I'll have some time this weekend to work on this.
Thanks!
It would be great if we could verify that "state 3" is indeed a better default for most rigs out there. If someone is willing to do some testing with various rigs, that would be very helpful in resolve this issue.
I believe rigctld.go#L169 is where we need to change from 1 to 3, and possibly also update GetPTT to support reading the other response values.
@DougCollinge The next release will include a "PTT state 3" experimental feature, which can be enabled by setting an environment variable. My plan is to encourage users to run Pat with the "PTT state 3" experiment enabled to test if this would break anyone's setup. If it does not, then we can default to state 3 PTT in the release after that.
To run Pat with the experiment enabled: EXPERIMENTAL_HAMLIB_PTT3=true pat http
The hamlib package will print a log line on startup when the experiment is enabled, so users can verify.
As might be expected (;-) it works perfectly on my TS-480. No-one else seems to have filed a bug so it looks like a print, I guess.
On another matter I am into the code you put in for this item. It doesn't seem right to me. The method: func (v *tcpVFO) SetPTT(on bool) error in rigctld.go:166 is supposed to turn PTT on or off according to the value of 'on' but if experimentalPTT3Enabled() returns true then it sets PTT to 3 regardless of the state of 'on'. I don't know how that actually works because it seems to anyway.
Hmm... I agree. This does not make any sense. Nice catch 👍
We need to get to the bottom if this before changing the default value. Maybe the experimental code is not triggered somehow...
Here is log output showing what is sent to rigctld:
martinhpedersen@tirreni:pat (develop *)$ EXPERIMENTAL_HAMLIB_PTT3=true go run . connect ardop:///foo
2020/10/20 21:08:33 Experimental PTT3 enabled (https://github.com/la5nta/pat/issues/184)
2020/10/20 21:08:33 \get_freq
2020/10/20 21:08:33 dummy ready. Dial frequency is 145.000.00 MHz.
2020/10/20 21:08:33 ARDOP TNC (ARDOP TNC_1.0.4.1i-BPQ) initialized
2020/10/20 21:08:33 \get_freq
2020/10/20 21:08:33 Connecting to FOO (ardop)...
2020/10/20 21:08:33 \set_ptt 3
2020/10/20 21:08:36 \set_ptt 3
2020/10/20 21:08:38 \set_ptt 3
2020/10/20 21:08:39 \set_ptt 3
2020/10/20 21:08:42 \set_ptt 3
@DougCollinge Are you sure that this works? It does not make any sense 🤣
The only explanation I can think of is that hamlib handles subsequent \set_ptt 3 as some sort of toggle.
@DC7IA - Can you confirm that you saw the "Experimental PTT3 enabled..." line in your log output when testing this?
@DougCollinge:
Let's say we simply replace RIG_PTT_ON (1) with RIG_PTT_ON_DATA (3) and don't provide a way for users to override it in Pat's config. That would be bad for the few (if any) users that for some reason are using e.g. TS-480 and have interfaced with the mic port for audio.
However, it looks like hamlib provides a way for users to override this and force "normal" MIC PTT, through the ptt_type config option. Can you test this on your setup? rigctld -C ptt_type=RIG ... should trigger the same behaviour as RIG_PTT_ON (1) even if Pat sends RIG_PTT_ON_DATA (3).
If this approach works, I think it is best to avoid a "configurable hamlib ptt magic number" option in Pat's config that probably only leads to confusion for most users. We could instead add a footnote in the wiki for those few people that might be affected by this change.
I already patched it, just by moving the \set_ptt 3 code into the "experimental" branch. But I have switched to VOX as a PTT method because, for some reason, the ardopc PTT when using CAT is much slower than the ARDOP.EXE running in wine, which makes it connect only sporadically with many stations that turn around quickly. Using VOX it works perfectly but I would still like to use CAT so that's another issue to look into sometime.
If you would like, I can revert my PTT method to CAT temporarily for testing.
I would agree with the idea of using the rigctld option if that gives the same result. But I don't think that the option you mentioned has anything to do with the data port. It just determines where the PTT on/off comes from, not which port the TX audio is taken from:
-P, --ptt-type=type Use type of Push-To-Talk device. Supported types are RIG (CAT command), DTR, RTS, PARALLEL, NONE.
I have just reviewed the documents and there just doesn't seem to be any way to instruct the radio to use the data port audio for TX other than sending TX1; through CAT. PTT also can come through the data port DTS line and it is plausible that asserting that line would cause the radio to take audio from the data port - but I can't find that behaviour actually documented anywhere.
Possibly apropos of this discussion: one of the stations I connect to frequently has a single radio attached to two interfaces. The data port is connected to a PACTOR TNC and a computer running ARDOP is connected to the mic input using VOX for PTT. I don't know what type of radio it is but it could be a TS-480. This setup works, though they have some trouble getting the VOX sensitivity just right because ARDOP changes audio level as the modes change.