IC-9700 PTT CAT on 2nd COM port
mdblack98 opened this issue · comments
On PTT port add ability to send CAT commands for PTT.
Also add long version of FA and advanced MD commands.
This is all handled by the PTT line going into an amplifier that does not get asserted until the sequencer tells it to.
But...WSJT-X needs to have a delay also on sending the audio -- as it has no idea when PTT actually gets asserted.
So WSJT-X would send "TX;" for example, wait 500ms, and start transmitting hoping the sequencer did it's thing to not miss the beginning of the FT8 waveform.
Not sure we need to disable the PTT on the rig while doing this. And Hamlib doesn't know it's an Arduino connected so DTR blocking really isn't feasible....other than no DTR/RTS if using CAT commands perhaps...make them exclusive.
Mike W9MDB
Hi Mike,
May I set some minimum requirements to the new interface as I have understood it for the sequencer purposes:
- When this new interface is activated, then PTT related CAT commands shall not sent via the rig CAT interface.
- I assume that the new interface is using the same serial protocol as the rig CAT interface and at least RTS signal will be available in addition to the minimum PTT related CAT commands.
- Open issue is whether the CAT PTT commands should be "confirmed" and related timing issues or should those be one directional (as RTS/DTR signals are in PTT usage).
- There could be a lockout so that the DTR signal is not used to prevent Arduino misbehavior. I don't know whether is shall be constantly at low or high state.
- If that interface supports also other CAT commands parallel to the rig CAT commands, then the "confirmation" part of the protocol is totally open.
- How this new interface will be selected/activated is open, but could be simply activated by selecting either RTS or DTR as then there is no need to modify wsjt-x at all.
73, Reino OH3mA
#1 Sounds like a good idea.
#2 Was thinking I would use TX; and RX; to make this standard so clients can rely on that and not 300 rig definitions (in other words we abstract the PTT actions)
#3 PTT commands are not confirmed by any Yaesu or Kenwood rig with at "TX;" command. But...perhaps we can poll for PTT status which may be preferable but the Arduino would have to respond to it. That would best be done with they Yaesu protocol so we would now have:
"TX1;" PTT On
"TX0;" PTT Off
"TX;" Return PTT status of 0 or 1
"FAXXXXXXXXX;"
"FBXXXXXXXXX;"
#4 I don't see why we would automatically lock out DTR but the way this is done now only 1 mode can be selected so CAT/DTR/RTS are exclusive.
#5 See #3
#6 It will be from a --set-conf option which can be put in the hamlib_settings.json file and enabled automatically then....but would be nice to have WSJT-X add that to the RTS/DTR options.