Log4OM

k1cvh wrote: 08 Nov 2023, 02:51 Follow-up to my previous post.
Apparently after reviewing my UDP Inbound connections setup on Log4OM and checking my WSJT-X and Gridtracker setup, I am still having a problem with QRZcom auto-upload from Log4OM. Log4OM uploads automatically to QRZ if not using Gridtracker but with Gridtracker on, the new log enrty is never uploaded. The logbook entry status column for QRZ stays at no. I can manually upload using the QSL manager though. Perhaps a bug?

--Chris K1CVH

Chris,

Short of "testing" I never use 'auto-uploads' for my QSOs. I like to have more personal control over them and I also double-triple-check them before I do upload them.

That being said I always upload via QSL Manager. It is easy, convenient and allows me to do a quick review.

So ... why don't you try to send up one or two of the QSOs that are still labeled with "N" and see if they do upload OK.

I've worked with some OMs who have noted a somewhat similar experience, but they also noted that the QSO actually had been uploaded, but (for reasons yet unknown) the "N" label was not flipped to a "Y". And such happened only with QRZ.com uploads. The difference is that a couple of the OMs I've been working with are CW only and do not have any FTxx APPs installed/running on their computers.

Give that a test a go and see what you may find. And 'maybe' the QSOs are uploaded, but the "N" is not flipped to "Y"??

KI5IO wrote: 08 Nov 2023, 12:17 Short of "testing" I never use 'auto-uploads' for my QSOs. I like to have more personal control over them and I also double-triple-check them before I do upload them.

That being said I always upload via QSL Manager. It is easy, convenient and allows me to do a quick review.

So ... why don't you try to send up one or two of the QSOs that are still labeled with "N" and see if they do upload OK.

I've worked with some OMs who have noted a somewhat similar experience, but they also noted that the QSO actually had been uploaded, but (for reasons yet unknown) the "N" label was not flipped to a "Y". And such happened only with QRZ.com uploads. The difference is that a couple of the OMs I've been working with are CW only and do not have any FTxx APPs installed/running on their computers.

Give that a test a go and see what you may find. And 'maybe' the QSOs are uploaded, but the "N" is not flipped to "Y"??

Hi Nolan.

Thanks again for the reply. Much appreciated.
I can upload via QSL manager successfully. I do appreciate that manually uploading affords one to check the data before uploading.
I can also confirm that the QRZ flag is not being flipped to Yes from No. Also can confirm that no upload is occurring to QRZ regalrdless of how long I wait.
If I stop Gridtracker from running then auto upload in Log4OM will work as expected. This seems to manifest only when I have Gridtracker running with Log4OM and WSJT-X.

Incidentally, I notice the same exact behavior not only with QRZ but uplaods to eQSL.

Regards,
--Chris K1CVH

Chris,

Methinks then there is something that Gridtracker is seizing control of in Log4OM and/or some value is being set in the GT configuration that is causing the anomaly.

I'm guessing some parameter in GT telling the UDP data packet to "not be sent" or rather "uploaded" to the External Service (IE: QRZ and eQSL).

Do a close review of the GT configuration outbound settings for QSOs and see if there is anything there than can give you a clue.

Also ... review again the parameter settings you have set up in Log4OM for the GT UDP Inbound Connection.

Don't want/need any conflicts in those parameters in the UDP Inbound Connections.

As I often say ... go back to basics and peel the onion one layer at a time and the hiccup will be discovered.

.

KI5IO wrote: 09 Nov 2023, 03:01 Do a close review of the GT configuration outbound settings for QSOs and see if there is anything there than can give you a clue.

Also ... review again the parameter settings you have set up in Log4OM for the GT UDP Inbound Connection.

Don't want/need any conflicts in those parameters in the UDP Inbound Connections.

I don't think I have any conflicts. Not that I can tell at least. Here's my UDP configurations for WSJT-X, Log4OM, and GT.

Might be hitting a bug somewhere. It's not critical of course since I can still use QSL manager in Log4OM to update QRZ. I prefer to let Log4OM perform the uploading to external services versus using GT. GT can do the upload to QRZ but that leaves my log entries in Log4OM with a QRZ status = no. I should run more verbose troubleshooting logging in Log4OM to see why Log4OM will not initiate the upload to QRZ if GT is running.

Thanks,
--Chris K1CVH

Chris,

What options have you selected "inside" the UDP Inbound Parameters?

There are 4 to choose from in each UDP Inbound Connection.

'Sample' below just to show the 4 options you can enable or not enable.

.

KI5IO wrote: 10 Nov 2023, 19:01 Chris,

What options have you selected "inside" the UDP Inbound Parameters?

There are 4 to choose from in each UDP Inbound Connection.

'Sample' below just to show the 4 options you can enable or not enable.

.

Hi Nolan.
Here are my Inbound Connection settings for each of the 3 entries.
--Chris

Has this been acknowledged as an issue or resolved?

I too have the latest version of Log4OM 2.30.1.0. LOTW uploads automatically when I close the program. I recently subscribed to the XML service on QRZ.com and can successfully upload and download confirmations but only when I manually use Utilities\QSLManager.

I have the settings under External Services correct, I think, as I would expect it to error on a manually initiated upload. I have my API key, Callsign and the Automatic upload on new QSO checked.

Do I need to have any UDP rules? I found reference earlier in this thread that did not make sense to me as it was an inbound rule but the issue I am having is outbound.

Does anyone have a link to a document or youtube video that focuses on the steps needed to automate QRZ uploads?

Thanks,

I see this was an older post, but I found this thread while trying to figure out my own issue. For the sake of any other people who find this from the future, here's what worked for me:

You do want the "UPLOAD_QSO" option ticked in your UDP INBOUND "GRID TRACKER LOG". While you're seeing this as an "outbound" issue because Log4OM isn't pushing data out, the "inbound" perspective in this case is "inbound to Log4OM" (from Grid Tracker). <-- That's what I'd left unticked on my own setup, and that single change sorted things out for me.

The other blockage I think I can see from the previous screenshots, if Chris, K1CVH is still stuck with manual-only uploads, is your port selections.
In the images from November (which you may well likely have changed since then), WSJT-X's "Secondary UDP Server" is pointed to port "2337" while Log4OM is listening for "INCOMING JT MSG" on port "2237" -- that said, I think you probably want Log4OM to be listening for WSJT-X's "ADIF MSG" to update the log instead of the JT MSG.

If you've figured it out, I'll clean up my speculation here for the sake of leaving a clean record of resolution--if you haven't, try setting WSJT-X's Secondary UDP Server to port "2236", and in Log4OM do tick the "UPLOAD_QSO" parameter in "GRID TRACKER LOG" for port 2236 and see if that makes things work.