Log4OM

Hello,
We try to base ourselves on the documentation pages 221-224
Our environment is:
JTDX-JTAlert-Log4om
We've been doing this for a very long time

1) Page 221: Enter port number 2334 in the port field
but in the screenshot it is port 2234

2) in the following screenshot we do not see the ports used, the screenshot is too small we assume that it is indeed 2237 and 2333 for the second UDP port

In the JTAlert or Gridtracker set-up part:
1) Create ADIF_Message type with port 2234
2) create JT_Message with port 1240

In JTDX part:
Primary server: 2235

AND in the JTAlert setup part:

2) set the control port to match port used in Log4OM V2 (Step1)
3) Set ADIF_MEssage to match port used in Log4OM V2 (Step2)

But setp 1 = ADIF_MESSAGE and NOT Control port
and Step2= JT-Message (control port)
So I think it's the other way around?

In summary :
if we use port 2235 in the JTDX configuration, does this mean that in Log4OM we must use this port 2235 in the 'Incoming JT Adif' connection?
But that means that JTDX and JTAlert are already using this port 2235 so in the JTAlert configuration I can't say that I'm using this port 2235 again in the "Logging/Log4OM" setting.

I guess in this case I have to use another dialog port between JTDX and JTAlert
For example, I put port 2333 in the preferences of JTDX (Primary UDP) and not 2235
is it correct ?

my connections therefore become:
in JTDX:
Primary UDP:port=2333 (for example)

In JTAlert:
Logging / Log4OM V2:
Send WSJT-X DX Call to Log4OM: port 2235 (ADIF_Message) and port 2241 (Control port)
Apps/WSJT/JTDX:
Resend WSJT-X UDP packets (received only): UDP port = 1240

In Log4OM Inbound connections:
1) Incoming JT Adif port = 2235 (ADIF_MESSAGE)
2) JTAlert Rebroadcast (JT_Message): port=1240
3) Remote Control: port: 2241 enable
4) ADIF Monitor = Not set

is that what should be done?
so that I can test today with these parameters?

Thank you very much for your help
73

1) Page 221: Enter port number 2334 in the port field
but in the screenshot it is port 2234

I will re word this to be 'Ensure the port number MATCHES that selected in JTDX/WSJT'

2) in the following screenshot we do not see the ports used, the screenshot is too small we assume that it is indeed 2237 and 2333 for the second UDP port

Its a PDF file use zoom to enlarge

In the JTAlert or Gridtracker set-up part:
1) Create ADIF_Message type with port 2234
2) create JT_Message with port 1240

In JTDX part:
Primary server: 2235

I will remove all references to port numbers and state 'Ensure the port numbers match those selected in......'

AND in the JTAlert setup part:

2) set the control port to match port used in Log4OM V2 (Step1)
3) Set ADIF_MEssage to match port used in Log4OM V2 (Step2)

But setp 1 = ADIF_MESSAGE and NOT Control port
and Step2= JT-Message (control port)
So I think it's the other way around?

Again I will make this generic so that the user must decide on port numbers and ensure they match in those in the JT software.

if we use port 2235 in the JTDX configuration, does this mean that in Log4OM we must use this port 2235 in the 'Incoming JT Adif' connection?

No the port numbers must match and not be used in other areas


The sreen shots are just examples its a user choice of which numbers to use to match those selected in their JT software

User guide updated and ready for users to download.

If a user need s to re-establish a UDP connection due to the recent changes in Log4OM the process is as follows

1. Make a note of the port number and connection type already in use
2. Delete the existing UDP connection
3. Select a new connection eith by using the preset buttons or manually - Ensuring the port numbers and connection type noted in item 1 above are employed
4. Save the connection
5. Restart Log4OM and the connected software

OK Terry
thank you for taking a few tamps to answer me

Unfortunately that doesn't answer my concerns but it doesn't matter I'll test and find out for myself
and I'm stopping this thread it's not worth continuing if we can't understand each other

thanks again

73

F6FLU wrote: 22 Mar 2023, 13:03 OK Terry
thank you for taking a few tamps to answer me

Unfortunately that doesn't answer my concerns but it doesn't matter I'll test and find out for myself
and I'm stopping this thread it's not worth continuing if we can't understand each other

thanks again

73

Just remember UDP ports work on a first come, first served basis!

The udp output port sends data and the first listening (inbound) port that receives that data consumes it.

Any other listening udp port on the same port number will receive nothing because the previous udp port has taken the data.

So a bit like com ports the UDP port cannot share data to multiple ports with the same port number

If you use port number 2334 to send data and in the other program you must use 2334 to receive that data, the numbers must match and not be used by any other apps

Yes Terry I agree

Hello
I downloaded the new version of the documentation (22/3/2023 at 10:28)
Page 222 missing item 2
Page 224:
2) set the control port ...(step1): step 1 is the creation of the ADIF MESSAGE not the control port
3) set the ADIF_MESSAGE ....(step2) step 2 no longer exists and I think it is port 1240 which is therefore the port used for JT_MESSAGE

Well I guess cause I'm still trying to figure it out
Sorry

Good morning
we switched to version 2.27.1.0 but still with incomprehension

1) we created a single "Incoming JT ADIF" connection of the ADIF_Message type and in the options we selected:
"Upload_QSO and "Update_CQ_ITUZONE"
but if you log a QSO from JTDX-JTAlert the gridsquare entered in the JTDX Log window is still modified by Log4OM
For example I contact A61NN whose gridsquare in JTDX is LL75; Log4OM records this QSO with the Gridsquare LL75rg
Same with RA9CUU I force the gridsquare in the Log window of JTDX to MO17 and well Log4om modifies this Gridsquare to MO17mq

There must be another setting somewhere that I forgot?

2) I did not make a connection with port 1240 (JTALERT REBROADCAST) of JTMessage type
but I don't see any particular problem
In which cases must this connection be validated?

In our tests we are always with JTDX-JTALERT-Log4OM

Thanks in advance for your advice

other examples

@F6FLU

Hi Dan,
I had the same issues allthough I re-set the connections, here you can read about my "solution": https://forum.log4om.com/viewtopic.php?t=8257&start=20
In my case the ADIF_MESSAGE was the problem, I changed everything to JT_MESSAGE (as it was in 2.26) and it works again like a charm.
Uploading to external sources, no more empty name fields and 4 digit locator as it comes from WSJT-X instead of the 6 digit locator (that comes from QRZ.com I guess).
I don't know why this works for me but it does

73s