Premature QSY after RMS session

[guitarpicva]

pactor_debug output below shows the sequence. The code does the QSY before the Pactor modem has finished it's session shutdown sequence, in this case by about 5 seconds, which means that the radio is transmitting that sequence on the previous frequency causing QRM.

The output shows that the WA8DED mode is dropped before declaring the session closed. I am trying to trap the state of the lights on the modem (PTC-IIex) when this happens to see if there is any indication that you can key on before dropping WA8DED mode.

mitch@rcslin:~/go/src$ pat connect pactor:///Nxxxxx?freq=5nnn.5 2019/09/17 09:46:35 ft450 ready. Dial frequency is 5.nnn.50 MHz. 2019/09/17 09:46:35 QSY pactor: 5nnn.5 2019/09/17 09:46:38 Connecting to Nxxxxx (pactor)... 2019/09/17 09:46:38 Entering WA8DED mode 2019/09/17 09:46:38 Entered host mode 2019/09/17 09:46:38 Calling Nxxxxx 2019/09/17 09:46:38 Called! 2019/09/17 09:46:38 Start main loop 2019/09/17 09:46:48 Connected to Nxxxxx () RMS Trimode 1.3.25.0 Nxxxxx has 120 minutes remaining with Nxxxxx {SFI = 069 on 2019-09-17 13:00 UTC} [WL2K-5.0-B2FWIHJM$] ;PQ: 04950423 CMS via Nxxxxx >

FF FQ 2019/09/17 09:48:52 Close called from /home/mitch/go/src/github.com/la5nta/pat/vendor/github.com/la5nta/wl2k-go/fbb/wl2k.go#272 2019/09/17 09:48:54 Stop main loop 2019/09/17 09:48:54 End WA8DED mode... 2019/09/17 09:48:54 Leaving WA8DED mode 2019/09/17 09:48:54 Left WA8DED mode 2019/09/17 09:48:54 Stopped main loop 2019/09/17 09:48:54 Disconnected. 2019/09/17 09:48:55 QSX pactor: 5nnn.500

[guitarpicva]

2019/09/17 10:43:18 Close called from /home/mitch/go/src/github.com/la5nta/pat/vendor/github.com/la5nta/wl2k-go/fbb/wl2k.go#272 2019/09/17 10:43:18 Send disconnect command to PTC 2019/09/17 10:43:19 IOError while reading channel after G-command. Cannot continue, closing already in progress. Error is: timeout while reading 2 bytes 2019/09/17 10:43:19 IOError while reading reply to G-command. Cannot continue, closing already in progress. Error is: timeout while reading 2 bytes 2019/09/17 10:43:19 RTD signal set 2019/09/17 10:43:19 RTD signal received 2019/09/17 10:43:19 Stop main loop 2019/09/17 10:43:19 End WA8DED mode... 2019/09/17 10:43:19 Leaving WA8DED mode 2019/09/17 10:43:20 Left WA8DED mode 2019/09/17 10:43:20 Stopped main loop 2019/09/17 10:43:20 Disconnected.

[harenber]

I am aware of that behaviour. The WA8DED implementation of SCS reports a connection to be closed as soon as the first disconnect frame is received (this is easier to see on Packet). I never had a problem with that, as I left it on the QRG, so the firmware took care about the HF protocol. But of course with QSYing, this is nasty. Will see if there is anything what can be done to make that better. Will need a little bit of time as my radio setup is currently in a phase of restructuring and I cannot just fire up my station at the moment.

The second problem is wired though. Never experienced that. Basically the PTC and the computer got out of sync. Is there a possibility that you had HF in your cables?

[guitarpicva]

Torsten, I did notice that the message about the disconnect happened immediately after the FQ was displayed even though the modem kept hacking.

No worries on time. I am at the radios all day every day just about, so reach out when you need testing done.

It may be as simple as NOT changing back to the original frequency. It's a very useful feature, but if the hardware does not play nicely, there may be no other workaround than to disable such a nice feature.

Notice that Winlink Express does not try to revert to the previous frequency as far as I can remember.

In reviewing the go code (I am a Qt C++ guy, so a bit of a learning curve for me) it seems that there is a second "D" disconnect command sent and in your comments there is something like "We don't really need to do this a second time, but it doesn't hurt anything." I wonder what might happen if the second one were left out? I suppose I can test that. :)

Regards, and don't hesitate to call on me for testing. Always happy to help!

Mitch

[blockmurder]

Hi Mitch The problem was, as far as I can tell, that after sending the disconnect command it has not been checked if the Pactor modem has actually sent the disconnect request to the remote station and got the request acknowledged before terminating the session.

With the refactored code this issue should be fixed.

[blockmurder]

I could not reproduce the issue with v2.0.x anymore. @guitarpicva Can you please test/confirm?

[guitarpicva]

Apologies for my tardiness. I will set up rigctld and give it a whirl. I am on the develop branch from a clone this morning. Tries with it thus far this morning have not worked for rig control, so I have some local troubleshooting to do first. Will advise asap.

[guitarpicva]

Much better! It was an orderly change from current frequency to new frequency. Then, a failed connect and a successful connect and exchange were each followed by an orderly return to the original frequency.

Thank you! Reverting to the prev frequency is a VERY useful feature.

[blockmurder]

Thanks for the report! Much appreciated!