Page 5 of 6

Re: Callsign look with WSJT-X

Posted: 19 Jan 2020, 13:55
by G4POP
Thats what I like someone that is prepared to drill down to the actual reason rather than blaming everything in the universe without foundation!

Thank you Phil, Well done!

Re: Callsign look with WSJT-X

Posted: 19 Jan 2020, 22:02
by NN7D
Phil,

Thanks for letting us know! That is still pretty weird. Possibly both instances were sending on the same port which mangled the UDP messages? Again, WireShark packet sniffing might help you figure out exactly what is going on with 2 instances running.

73,
Doug
W7DRM

Re: Callsign look with WSJT-X

Posted: 20 Jan 2020, 02:06
by vk1hx
Hi Doug,

I’m not running 2 instances of wsjtx at the same time. Only one at a time. The instance that uses the rig name causes the issue. Then when I run the basic instance without rigname it’s all fine. I’ll try and do screen shots when I get home from work.

Gawd: now I cant get the cluster to show information on the cluster tabs... LOL.. :lol: :shock:

Re: Callsign look with WSJT-X

Posted: 20 Jan 2020, 14:00
by vk1hx
Here are the 2 different WSJTx shortcut. The one with the "rigname" extra in it causes Log4OM to received the wrong/partial information. The other one works perfectly with sending the DX Call data to Log4OM.
Capture2.JPG
Capture2.JPG (40.43 KiB) Viewed 4571 times

Re: Callsign look with WSJT-X

Posted: 20 Jan 2020, 14:08
by HI8SMX
W7DRM wrote: 16 Jan 2020, 21:16 Hi David,

I understand the issue. The DX call field from WSJTx is not making it into Log4OM V2 Callsign field. Your settings look correct, so its something else blocking the UDP messages. I have the same settings and it is working fine here.

Are you using OmniRig? If so, you need to be running both Log4OM and WSJTx with Administrative privileges. If that does not solve the issue, try a reboot of your computer... when all else fails.

If that does not solve the issue, would you please generate a support request - follow the procedure in the manual - after trying to replicate the problem.

73,

Doug
W7DRM
I´m following that procedure but it only works for 1st instance of WSJTX. Whenever I open a 2nd instance (I use a Flex) it doesn´t send the DX call to Log4Om on that second instance. I have one reporting udp port for each instance and the corresponding connection in Log4OM, but still does not work. Any idea?

73, Santiago

Re: Callsign look with WSJT-X

Posted: 20 Jan 2020, 23:09
by EI2GLB
That must be why mine isn't working, I have my WSJT names slice A slice B ect as the are for different slices on my flex, so how can we work around this,

Thanks
Trevor
EI2GLB

Re: Callsign look with WSJT-X

Posted: 21 Jan 2020, 02:29
by HI8SMX
In the JT Alert forum, Laurie mentioned that probably the reason second instances of WSJTX are not sending dx call info is because of the name of the second instance (-rig), apparently Log4Om is not recognizing anything but WSJTX in the name. Probably that's the same reason why with Slicemaster it does not work with either slices, because SM changes the name of WSJTX instances.

I don't know if this is true or not, but that's what I was told.

Hope this helps.

Santiago

Re: Callsign look with WSJT-X

Posted: 21 Jan 2020, 15:22
by w9mdb
Log4OM should be accepting any software name/version info and not be picky about it.

Re: Callsign look with WSJT-X

Posted: 21 Jan 2020, 15:49
by G4POP
By reading your comments it would appear we screwed up royally!

However in our defence when we started the re-write of Log4OM 3 years ago we did not foresee the development or popularity of WSJT or expect users to be using multiple instances of WSJT with Flexradio slices and robotic unmanned stations but we did not have a crystal ball!

We have now ceased further development of features that we wanted to add to version 2 so that we can keep you guys happy and today commenced a complete rewrite of the UDP WSJT function with a more reliable implementation of QT protocol, this is not straightforward in C# language!

So please dont start demanding Net control, Google earth support, More awards and other features because until we finish this change its not going to happen!

Re: Callsign look with WSJT-X

Posted: 21 Jan 2020, 16:20
by IW3HMH
Hi Mike,
You are part of Beta Team, so i was expecting those comments a bit before main release. Maybe you didn't noticed that previously, but if it was hard for you noticing the issue, while working with multiple slices on a modern radio is even harder to me that i'm working with a FT-897 10 years old (with satisfaction :) )

As you know, Log4OM 2 is result of 2+ years of development, while version 1 is "alive" since 2011. It's complex to fully rewrite a codebase in 2 years with all the features we had in V1 plus everything else someone is expecting from a modern logger.

On the other side, to have everything implemented, we need some more months. Implementations that were not known when we first targeted December 2019 as release date. More, we rushed to provide a small "raw" support to WSJT-x and JTDX but we didn't have enough information about particular needs like working with multiple application instances.

So, let me say a big THANKS to Laurie VK3AMA that promptly supported Log4OM v2 on his first class JTAlert application.

Multiple special situations will be handled, but we should have priorities. As usual my priorities are bugs and "widely used" things. Stay tuned on beta group, if you can, checking new intermediate releases as we need your experience.

Daniele