locked Re: LAST QSO API - UDP function


HamApps Support (VK3AMA)
 

On 5/08/2018 8:19 AM, w4lde wrote:

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

Ron,

Good to see some extensive testing. I don't have an answer to what your observing until I get some debug data to analyse.

A couple of points.
  1. Regardless of the UDP settings, HamQTH lookups should not be affected. The XML lookups are done using standard http (port 80) or https (port 443) web access. Missconfigured UDP ports should not be affecting them. The XML lookups are independent and if they are breaking then something significant is happening, likely some sort of application interference in the lookup mechanism. XML lookups are only executed at the time the DX Call in WSJT-X is changed so are finished long before any logging actions are performed.

  2. I don't know if Logger32 is expecting TCP or UDP. If it is TCP, then that will be a problem as the last QSO API is UDP only, there is none of the handshaking required with TCP, the packet is simply sent regardless of the ready status of any application waiting for a packet of the port.

  3. There is no port configuration involved in JTAlert logging of WSJT-X QSOs, the port used is determined by examining the UDP port settings within the WSJT-X config file and is not related to the last QSO API port.

de Laurie VK3AMA

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