Log4OM

Seems like this is one of the main bugs at present I also have this issue, but only using WSJT-X 2.1.2 using an older 2.1.0 that is modified it works correctly??


I just set everything to run as admin as I hadn't previously and it made no difference for me,


Trevor
EI2GLB

'Morning/Evening All

Well I'm not quite sure what I have done, maybe it was the threat of beating the computer to death with a bloody big hammer and setting fire to the remains that did it, but everything is working here

What have I changed? Absolutely no damn idea.

Running Log4OM/Omnirig/WSJT-X all without admin privileges.

Setting are same as the book (as they had been a billion times before).

Ports all back to "as per the book".

As said, I have absolutely no damn idea why it suddenly decided to work but I'm certainly not complaining.

The laptop still isn't working so the plan for today is to sit with both in front of me and compare settings to see what the difference is. If I find anything I will report it back here.

But for the moment everything (including cluster) is working fine - Yippee!!!

Thank you Doug/Terry/Phil and everyone else for your suggestions - they were very much appreciated.
I hope those that are still having problems magically have them fixed too

Cheers
David
VK7YUM

That’s awesome David. I too made threats to the PC and I ended up blowing the PC OS away and redoing it. Also running all applications with elevated privileges’admin’ made no difference. I’ll try again this morning. I’ve since received notification from friend here and overseas that too are having the same issues.... damn computer!!

Cheers all, thanks for the support.

Phil - VK1HX

Still no change and the cluster is not working, no filters applied so uninstalling V2 and will try again. As I posted before when I run wsjtx and Log4OM with the UDP settings as outlined in the manual as soon as wsjtx does a decode cycle it populates the callsign field in Log4OM with the digi mode I’m running. I can clear it however on the next cycle it’s back.

EDIT - UPDATE:
Ok with a complete removal of Log4OM V2 and reinstall, the cluster is working again.

Further testing. It seems that there is a connection from WSJT-X however as soon as I type any letter in the DX CALL box on WSJT-X it sends a command to Log4OM showing the MODE that is set on WSJT-X. If I clear the information on Log4OM and do not type anything in DX CALL box, once WSJT-X completes a cycle and decodes it populates the Callsign box on Log4OM with the mode again.

I have completely reset both Log4OM and WSJT-X and it still does it. It does exactly the same when running the apps in Admin mode or not.

73'
Phil - VK1HX

Edit: So it only relates to the primary UDP Server port number set in WSJT (it doesnt matter what the port number is either. If the IP and UDP are the same for the UDP Connection in Log4OM and the connection type is JT_MESSAGE it is only picking up the mode. You can untick all check boxed in reporting on WSJT and it will still just return the mode. I'm completely stumped on this. Any ideas from the design team?

Cheers, 73 Phil - VK1HX

Phil,

Here are some details of the "Status Out" message which WSJTx and JTDX send out for every change of the DX Call field, and every decode cycle. If you know how to sniff with a program like WireShark, you can watch the traffic from WSJTx.

In the Status Out messege is the following information:
Msg Type - 1 = Status Out, 2 = Decode info (one msg for each decoded line)
Name of program - WSJT-X
Freq
Mode
DX Call
And other info about your settings, your call and Grid settings.

So if WSJTx and Log4OM V2 are setup to send/receive Status Out messages, then the Callsign, mode and frequency will be updated in Log4OM main UI.

The way I read your post, what you are observing is normal behavior for the programs. I don't understand why you would not want the current WSJTx mode to be set in Log4OM. What am I missing?

Edit: Phil, I went further up this thread and reread your ealier posts. Are you saying that the mode is populating the Callsign field?

If that is the case, what version of WSJTx are you running?

Doug
W7DRM

Hi Doug,

Yes that is correct. The band mode selected in WSJTx is only thing being sent (automatically and every time it cycles a decode) to the Callsign box in Log4OM, as per my photos.
As for the version of WSJTx I am running the latest version wsjtx-2.1.2-win32 (and I have tried the win64 version also with the same results). Its also the same in wsjtx-2.1.0-win32 and 64. Log4OM is only picking up the mode data coming from WSJTx.

Cheers
Phil - VK1HX

EDIT: I have installed swjtx and log4OM V2 on the laptop, no cluster connection, no omnirig, no lookup details or external logbook sending etc, very basic settings as there is no radio connected to the laptop and its working as it should on the laptop. Both PCs are running the same OS. As I enter the first couple of letters of a callsign into the DX CALL box it drops across to Log4OM for lookup. SO!! there is something on my PC causing the issue. Maybe omnirig rig control ini file is causing the issue? I'll have to investigate.

Phil,

That is really weird. I've been using JTDX for a while and had not moved to WSJTx 2.1.2, so just installed it and tested the DX Call - works fine here. No mode in Callsign field - just the callsign. Seems the parsing of the message or the message itself is getting messed up and the mode is in the wrong place.

Have you ever used WireShark? Would love to sniff that Status message, and capture the entire message and have a look.

Can you try changing ports - make same on each end, but just to test in case some other process is messing with things. Try something like 3555 on both sides. or 5622. I've seen crazy things where a band of port addresses were corrupted by something...

Let us know.

Doug
W7DRM

Well its not Omnirig causing it. I just installed in on the laptop and its all still running normally. I've removed Omnirig off the main PC and it still does it. I really don't want to have to rebuilt by OS again!!

The only difference between the latop and the main PC (besides the main PC being and i9 9900K running 32GB ram and an m.2NVMe drive) is the main PC runs the OS (Windows 10 ENT) in UEFI mode. I'll try running in non UEFI mode and see how that goes....

I found the issue.

I run 2 wsjtx sessions for my ICOM 7300 and ANAN200D SDR. Each desktop shortcut Target is named C:\WSJT\wsjtx\bin\wsjtx.exe --rig-name=ICOM. This seems to be the issue with reporting the DX Call in the Callsign box on log4OM.

When I run just the basic wsjtx shortcut everything works perfectly. Im not sure why this happens when running the rig name wsjtx shortcut.

Hopefully this info helps others and a solution might be found.

Cheers
Phil - VK1HX