IC-9700 PTT CAT on 2nd COM port

[Michael Black]

On PTT port add ability to send CAT commands for PTT.
Also add long version of FA and advanced MD commands.

[Michael Black]

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:

1. When this new interface is activated, then PTT related CAT commands shall not sent via the rig CAT interface.
2. 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.
3. 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).
4. 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.
5. If that interface supports also other CAT commands parallel to the rig CAT commands, then the "confirmation" part of the protocol is totally open.
6. 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

[Michael Black]

#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.

[FI3ma]

Mike, Some further comments although at the moment I don’t see a real benefit to add serial mode PTT signaling to the “second” USB connection for PTT.

Not sure we need to disable the PTT on the rig while doing this.

#3 What I want to achieve is a single PTT control on the rig. For that reason there should not be any PTT related CAT commands to the rig via the current CAT connection. The new serial connection should do all PTT control to sequencer. The next issue is how reliable that serial connection should be. Currently it is a signal RTS or DTR. I have no knowledge, whether wsjt-x tries to check that the PTT signal has activated transmission on before starting to send audio; perhaps after the delay defined in wsjt-x Settings | Advanced | TX delay: setting. If there is no checking that rig is ready to accept audio (only a delay), then I think that your protocol proposal #3 is an overkill. I assume that the reliability of the serial communication should be high enough and we don’t need to check whether the sequencer got the message. The only need for the polling TX could be, if the sequencer can indicate that now the audio can be sent and HamLib can tell that to wsjt-x. By the way does any rig give an indication that a PTT action for transmission is completed? If so, is it a response message or does HamLib do it by polling? #4 and #6 Sure we can leave for operator to select in wsjt-x RTS for PTT and not DTR in the case of Arduino. Of course we could change wsjt-x MMI, e.g. RTS, DTR and CAT(TX), but that may not be needed at the end. #7 If we go on with this enhancement, should we set a requirement for the sequencer to tell back, when the PTT actions are completed and wsjt-x may start sending audio? #8 As Joe W4TV clearly pointed this enhancement request is only a software correction to a missing RTS wire in Arduino. Personally I still can do soldering although hands a shaking and would just add the missing wire! #9 Another possibility is Sam’s proposal that the sequencer does all this and takes the full CAT control and delivers to rig other CAT commands directly and catch PTT issues and deliver those only after completing sequencing. Best solution unless sequencer can accept RTS signal. 73, Reino OH3mA From: Michael Black ***@***.*** Sent: Sunday, March 31, 2024 5:40 PM To: Hamlib/Hamlib ***@***.***> Cc: FI3ma ***@***.***>; Manual ***@***.***> Subject: Re: [Hamlib/Hamlib] IC-9700 PTT CAT on 2nd COM port (Issue #1534) #1 <#1> Sounds like a good idea. #2 <#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 <#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 <#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 <#5> See #3 <#3> #6 <#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. — Reply to this email directly, view it on GitHub <#1534 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA7PNP4SQMI7CTDIVDVA6HTY3AN25AVCNFSM6AAAAABFONN5T6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRYG43TMNBSGQ> . You are receiving this because you are subscribed to this thread. <https://github.com/notifications/beacon/AA7PNP57NP7B7DN5TWBGLMDY3AN25A5CNFSM6AAAAABFONN5T6WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTY5SV6Q.gif> Message ID: ***@***.*** ***@***.***> >