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
connections with version 2.27
connections with version 2.27
Dan - F6FLU
Log4OM V2.32.1.0 - Windows 11 - i9-11900K - SSD 512Go - 32 Go
FTdx101D - Hexbeam - Wired dipole 40-30M
https://F6FLU.org
Log4OM V2.32.1.0 - Windows 11 - i9-11900K - SSD 512Go - 32 Go
FTdx101D - Hexbeam - Wired dipole 40-30M
https://F6FLU.org
- G4POP
- Log4OM Alpha Team
- Posts: 10803
- Joined: 21 Jan 2013, 14:55
- Location: Burnham on Crouch, Essex UK
Re: connections with version 2.27
I will re word this to be 'Ensure the port number MATCHES that selected in JTDX/WSJT'1) Page 221: Enter port number 2334 in the port field
but in the screenshot it is port 2234
Its a PDF file use zoom to enlarge2) 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
I will remove all references to port numbers and state 'Ensure the port numbers match those selected in......'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
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.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?
No the port numbers must match and not be used in other areasif 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?
The sreen shots are just examples its a user choice of which numbers to use to match those selected in their JT software
73 Terry G4POP
- G4POP
- Log4OM Alpha Team
- Posts: 10803
- Joined: 21 Jan 2013, 14:55
- Location: Burnham on Crouch, Essex UK
Re: connections with version 2.27
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
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
73 Terry G4POP
Re: connections with version 2.27
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
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
Dan - F6FLU
Log4OM V2.32.1.0 - Windows 11 - i9-11900K - SSD 512Go - 32 Go
FTdx101D - Hexbeam - Wired dipole 40-30M
https://F6FLU.org
Log4OM V2.32.1.0 - Windows 11 - i9-11900K - SSD 512Go - 32 Go
FTdx101D - Hexbeam - Wired dipole 40-30M
https://F6FLU.org
- G4POP
- Log4OM Alpha Team
- Posts: 10803
- Joined: 21 Jan 2013, 14:55
- Location: Burnham on Crouch, Essex UK
Re: connections with version 2.27
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
73 Terry G4POP
Re: connections with version 2.27
Yes Terry I agree
Dan - F6FLU
Log4OM V2.32.1.0 - Windows 11 - i9-11900K - SSD 512Go - 32 Go
FTdx101D - Hexbeam - Wired dipole 40-30M
https://F6FLU.org
Log4OM V2.32.1.0 - Windows 11 - i9-11900K - SSD 512Go - 32 Go
FTdx101D - Hexbeam - Wired dipole 40-30M
https://F6FLU.org
Re: connections with version 2.27
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
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
Dan - F6FLU
Log4OM V2.32.1.0 - Windows 11 - i9-11900K - SSD 512Go - 32 Go
FTdx101D - Hexbeam - Wired dipole 40-30M
https://F6FLU.org
Log4OM V2.32.1.0 - Windows 11 - i9-11900K - SSD 512Go - 32 Go
FTdx101D - Hexbeam - Wired dipole 40-30M
https://F6FLU.org
Re: connections with version 2.27
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
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
Dan - F6FLU
Log4OM V2.32.1.0 - Windows 11 - i9-11900K - SSD 512Go - 32 Go
FTdx101D - Hexbeam - Wired dipole 40-30M
https://F6FLU.org
Log4OM V2.32.1.0 - Windows 11 - i9-11900K - SSD 512Go - 32 Go
FTdx101D - Hexbeam - Wired dipole 40-30M
https://F6FLU.org
Re: connections with version 2.27
other examples
Dan - F6FLU
Log4OM V2.32.1.0 - Windows 11 - i9-11900K - SSD 512Go - 32 Go
FTdx101D - Hexbeam - Wired dipole 40-30M
https://F6FLU.org
Log4OM V2.32.1.0 - Windows 11 - i9-11900K - SSD 512Go - 32 Go
FTdx101D - Hexbeam - Wired dipole 40-30M
https://F6FLU.org
Re: connections with version 2.27
@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
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