Unexpected new "ping pong" issue (again)

[IU1IPB]

Hello Peter,

I'm working with ardopcf (last "not developer" version), driven by an up-to-date pat on an ARM64 PI/OS on Raspberrypi 3 since about 6 months. You fantastic fork solved for me the long lasting "ping pong" issue that the Kernel 6.1 introduced two years ago, and I was really happy of this. Unfortunately, in the last 15 days, something seems to have happened and the "ping pong" problem was again there. Of course "ping pong" means : TX starts handshake, gateway station answers but without connection and again till timeout. I have attached the debug logs of the last good transmission and of the "ping pong" one of today. Tested on my usual two gateway stations in Switzerland, with 599 signal. I'm a bit confused because in the meantime no hardware or radio landscape has changed, excluding the installation, from tarball of SDR++ Can you help me in understanding where the issue is located ? If necessary, I will post this note also on groups.io.

Thank-you for your valuated activity My best 73s IU1IPB Ugo

ARDOPDebug8515_20240608.log ARDOPDebug8515_20240531.log

[martinhpedersen]

@IU1IPB @pflarue - FYI, running Pat with the env variable ARDOP_DEBUG=1 might also be useful for debugging issues like this. It enables debug logging of the Pat <-> ARDOP host protocol, providing insights from Pat's point of view. 😊

[IU1IPB]

Hello everyone,

I tried to set ARDOP_DEBUG=1 but the Ardop debug file has the same data. Is the pat debug mode waiting other log file, and, if yes, in which folder (nothing in .config/pat)...

Tnx Ugo

Il giorno 8 giu 2024, 08:39, alle ore 08:39, Martin Hebnes Pedersen @.***> ha scritto:

@IU1IPB @pflarue - FYI, running Pat with the env variable ARDOP_DEBUG=1 might also be useful for debugging issues like this. It enables debug logging of the Pat <-> ARDOP host protocol, providing insights from Pat's point of view. 😊

-- Reply to this email directly or view it on GitHub: https://github.com/pflarue/ardop/issues/53#issuecomment-2155838505 You are receiving this because you were mentioned.

Message ID: @.***>

[IU1IPB]

Forget the last message : log found. Sorry Ugo

Il giorno 8 giu 2024, 20:04, alle ore 20:04, IU1IPB @.***> ha scritto:

Hello everyone,

I tried to set ARDOP_DEBUG=1 but the Ardop debug file has the same data. Is the pat debug mode waiting other log file, and, if yes, in which folder (nothing in .config/pat)...

Tnx Ugo

Il giorno 8 giu 2024, 08:39, alle ore 08:39, Martin Hebnes Pedersen @.***> ha scritto:

@IU1IPB @pflarue - FYI, running Pat with the env variable ARDOP_DEBUG=1 might also be useful for debugging issues like this. It enables debug logging of the Pat <-> ARDOP host protocol, providing insights from Pat's point of view. 😊

-- Reply to this email directly or view it on GitHub: https://github.com/pflarue/ardop/issues/53#issuecomment-2155838505 You are receiving this because you were mentioned.

Message ID: @.***>

[pflarue]

@IU1IPB,

I want to make sure that I am correctly understanding your problem. Tell me if any of the following are wrong.

From your log files, I think that you are having this problem with both v1.0.4.1.1 and v1.0.4.1.2.

I think that your problem is connecting normally to a Winlink station, not anything related to Ping/PingAck frames used by some FEC hosts.

The newer failure log file does not show any evidence that ardop is detecting any response from the KB9PC or KB9AK, but you wrote "TX starts handshake, gateway station answers but without connection and again till timeout." I assume that you mean that you could hear a response received by your radio.

I notice a difference between the two log files that may be important. In the older one, I see "Input Peaks = -32768, 32767". This means that the settings on your radio and/or your sound card made the audio from the radio to ardop too loud. It worked, but probably would have worked better if you reduced the audio levels. In the newer log file I see "Input Peaks = -591, 306" between your transmissions. This is much lower. So, maybe your problem can be fixed by increasing the audio levels from your radio to ardop. Maybe while you were installing or using SDR++ you changed your volume levels. The newer v1.0.4.1.2 does not show Input Peaks regularly. Maybe that was a mistake (my mistake), since this info is only when you were still using v1.0.4.1.1. However, a better indication of this is now available in the WebGui.

I recommend using the WebGui with v1.0.4.1.2, enabled by including -G 8514 on the command line and then pointing a web browser to port 8514 (or another port of your choice). Watch the "Rcv Level:" indicator on that screen while trying to connect. Itis OK if it is very low when you are not hearing anything, but when you are receiving a 599 signal, you should see something on this indicator. Both very low and very high can cause problems decoding received signals. No ardopcf settings will change the display of Rcv Level. You must make changes to your radio and/or soundcard settings if this is the problem.

If that does not help, let me know. It may be useful to create a more detailed log file using --hostcommands "LOGLEVEL 8" or create an audio recording of what ardop is hearing while you try to connect with --writewav.

[pflarue]

@martinhpedersen,

Thank you for telling us about the ARDOP_DEBUG=1 env variable for Pat. I don't think it will help in this case because Ardop is not detecting or decoding the incoming signals. However, it may be very useful for understanding other problems, and I did not know that it was available.

[IU1IPB]

Hello Peter,

trying to answer to your questions.

1) in the ARDOPDebug8515_20240531.log is shown successful connection at 13:41 as follow :

2024/05/31 13:41:35 ARDOP TNC (ardopcf_1.0.4.1.1) initialized 2024/05/31 13:41:35 Connecting to HB9PC (ardop)... 2024/05/31 13:42:05 Connected to HB9PC (ardop) RMS Trimode 1.3.53.0 WINLINK NYON IU1IPB has 120 daily minutes remaining with HB9PC (JN36DJ) {SFI = 175 On 2024-05-31 09:00 UTC} [WL2K-5.0-B2FWIHJM$] ;PQ: 18820096 CMS via HB9PC >

FF

Generally speaking, since today, I found no special issue in connecting, after having installed your fork. I found also empirically an increased number of connection in PSK mode compared to the John's original version

2) attached you can find the log file with the PAT dialogue made this evening 3) regarding the Input Peaks value : I was not aware that this value was correlated to the audio volume. I have always worked with audio at about 20% on radio and 8% on soundcard, and this is the today situation also. I will in any case test decreasing it. 4) also this evening I found the "ping pong" situation (calling "ping pong" the situation that we had last year with the new kernel) : my station call, HB9AK answer (I can ear the short transmission), my station call again, new transmission...and so on till timeout. On Monday, I will provide the dialogue sniffing from an external web SDR after having verified again the audio volumes. 5) I have always avoided pat web interface, using small script (one for each possible gateway), called from command line. I will try to use your suggest way of tuning audio volume.

I will let you know the results. Thank-you Ugo

patardop20240608.log

[pflarue]

@IU1IPB,

Input Peaks shows the largest negative and positive digitized sound values received by ardop. These are 16-bit integers. They have a maximum range of -32768 to +32767. When these maximum values are shown, it means that part of the received signal was too big to accurately convert from analog to digital so it shows the largest possible values. I see this in the log from 20240531. In the log from today, 20240608, maybe I see the opposite problem, values that are too small. I think that now maybe you need to try increasing your input audio volume.

The ardopcf WebGUI is unrelated to the Pat web interface. The Webgui shows a lot of information that you don't need when everything is working correctly, but that may be useful for identifying problems. If your scripts for Pat also start ardopcf, you will need to start it manually for this test that I suggest. You must have time to open the ardopcf gui with a web browser before pat starts trying to connect so that you can watch the "Rcv Level:" display.

You wrote "I have always worked with audio at about 20% on radio and 8% on soundcard". From your log files, it looks like your radio or soundcard settings have changed. Maybe SDR++, that you said you recently installed, changed your soundcard settings, and you did not know it?

[IU1IPB]

Hello Peter,

thank-you for having made me aware of some unknown (to me) topics : I will go deep in ARDOP web interface soon. I have in any case to beg your pardon : I found this morning the reason of the problem, that was a quite trivial hardware issue related to a bad connected mic-in plug. Changing it solved the issue. The "ping pong" was due to the impossibility, for ARDOP, to "listen" the transmissions from the gateway, still being able to transmit the connection requests. I was finally able to connect very well my usual gateways and I have also reduced the radio volume, keeping better under control the Input Peaks, as you suggested, planning to make some tests soon.

Again, excuse me for having asked and thank-you very much for your support and for you valuable activity, so useful for the "open source" HAMs

Best regards Ugo

[pflarue]

I'm happy to offer diagnostic suggestions. Often determining what isn't the cause of the problem is a useful step toward determining what is.

I also understand that the ardop debug log isn't particularly easy to understand. So, asking for help from someone that has spent time getting to know them makes sense.