locked Re: LAST QSO API - UDP function


w4lde
 

Laurie,


I tested the API - UDP port #52001 log output with HamQTH data add running several different setups trying to determine where the data stream stopped.

Ist - regardless of the port selections and methods selected for logging the internal WSJT-x and JTAlert logging worked100% of the time during my tests.

The logging program I use which is Logger32 has both TCP and UDP capabilities.  For my initial test I select the UDP port in Logger32 to match the port number from either WSJT-x in standalone, #2237,  WSJT-x and JTAlert using the API-UDP port #52001 and finally the Relay of WSJT-x data stream via the relay data selection under the WSJT-s setup in JTAlert I used port number #2234

1.Using only running WSJT-x on port 2237 and Logger32 in monitor UDP every time we hit the log QSO it logged to two (2) places, WSJT-x and Logger32.  The data in the log was as provided by WSJT-x..  JTAlert was not operating.

2. I then started JTAlert which is set to auto start WSJT-x.  The Last QSO API UDP port setting was #52001.  I set the Logger32 UDP port to monitor 52001.  When manually set to log, no data was transferred to Logger32 but did log WSJT-x and JTAlert correctly.

3.  I then changed the UDP port in Logger32 to 2234  and set the API UDP port to 2234 after I had disabled the WSJT-x relay function in JTAlert. When manually set to log both JTAlert and WSJT-x logs logged as expected but no data was transferred to Logger32.  So now we had two (2) UDPports set in the Last QSO API UDP port and neither would transfer the data.

4.  I then tried to use the TCP server function in Logger32 using SOCAT to convert UDP to TCP. 
The port setting was 52001 under Last QSO AOI and also Socate, no logging data was transmitted.  I closed that API Last QSO and 52001 and opened the relay port data under the JTAlert setup for WSJT-x and selected port 52001
.  I then changed the port input on SOCAT to agree with 52001 and logging data was transferred to all three programs.

5.  I then disabled the HamQTH lookup in JTAlert thinking that just maybe the timimg of lookup by JTAlert and transfer to the UDP port #52001 maybe a the cause but no it didn’t make any difference.


Conclusion unless you want me to test something else is:

UDP Data is correctly transferred from WSJT-x to either Logger32 or JTAlert with correct port settings.

UDP Data is correctly transferred via the relay function in WSJT-x setup in JTAlert to Logger32 with all three logging correctly, hoever no call book services are available.

UDP data from the relay function in WSJT-x in JTAlert port #52001 is correctly read by the Logger32 TCP server.  All three programs correctly logged the data, no call book data is avaiable.

UDP data from port with in the Last QSO API port seems to work occasionally on startup but is not consistent and for all practial means "dead" on my system.

I am going to continue to test various port settings and methods and will as you may suggest.  I will also in the enxt few days set the debug functions as per your earlier request.

TU for all your help and recommendations.

73 de Ron W4LDE

Join Support@HamApps.groups.io to automatically receive all group messages.