Date   

locked Re: Did not log exchange correctly to Log4OM v2 #FT8

Michael Black
 

Actually I never checked Log4OM but Log4OM2 does look like you can select the contest ID and it may well parse it.
I just didn't think to even check for that.

Mike




On Monday, June 29, 2020, 11:54:37 PM CDT, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 30/06/2020 2:23 pm, Michael Black via groups.io wrote:
Don't know what all the other loggers do but probably the same behavior I'd think.  They just put in what they receive without addiontal interpretation.

N3FJP Contest loggers parse the SRX_STRING & STX_STRING fields to pull the class and sect data out or other fields depending on the Contest.

If a general purpose logger like Log4OM has a selector to set the contest_id but doesn't utilize the exchange data provided in the correct standard format for that particular contest, that's Log4OM's problem not mine.

I certainly wont be going down the path of extracting data from the correctly formatted standard contest exchanges provided by WSJT-X to accommodate the whims of general purpose loggers that cant or wont use the data despite having a contest_id selector set in their software.

JTAlert is acting as bridge for logging, passing through the data without alteration except for minor string formatting and ensuring the frequency is of the correct format, Hz, kHz or MHz depending on the logger involved.

de Laurie VK3AMA


locked Re: WAE Sicily alert

Graham Alston
 

Hi Laurie,
I have to manually update the Marathon lists as I use MacLoggerDX, a logger which JTAlert does not support (not a criticism :)).
I am viewing the Not Wanted list for Any Band/ Any Mode.
The issue is not band specific.
I have the list set on Any Band/Any Mode.
I have only noticed this issue for WAE Sicily.
Debug and log sent.
Many thanks for your help.
73 Graham VK3GA


locked Re: JT Alert Problem

HamApps Support (VK3AMA)
 

On 30/06/2020 3:31 pm, Norm Fasoletos wrote:
Not sure if my last post got posted, but JT Alert will not log to QRZ anymore. I have a valid subscription with QRZ but just stopped working after a qso on JT alert.

Already answered here... https://hamapps.groups.io/g/Support/message/30730

de Laurie VK3AMA



locked JT Alert Problem

Norm Fasoletos <norm.k7nwf@...>
 

Not sure if my last post got posted, but JT Alert will not log to QRZ anymore. I have a valid subscription with QRZ but just stopped working after a qso on JT alert. Also, is there a User manual available for JT Alert to use for reference for all the settings?

73

Norm - K7NWF


locked Re: WAE Sicily alert

HamApps Support (VK3AMA)
 

On 30/06/2020 2:27 pm, Graham Alston wrote:
I have Wanted CQ Marathon active and I'm getting WAE Sicily alerts even though this entity is in the Not Wanted list?

73 Graham VK3GA
Not a lot of detail to go on.

How are you updating the Marathon lists? Manually or via the Scan Log operation?

When you say it is in the not wanted List, are you viewing the correct List? It is easy to be viewing the FT8 list when you may have been alerted on an FT4 decode.

How are you tracking Marathon Alerts, by individual Band/Mode or by any Band/Mode ?

If you truly believe JTAlert is incorrectly alerting on Entities that are flagged as no longer needed, I will need to get a copy of your log and a support request sent from JTAlert along with an example decoded Callsign and its Band and Mode that produced the alert.

de Laurie VK3AMA


locked Re: Did not log exchange correctly to Log4OM v2 #FT8

HamApps Support (VK3AMA)
 

On 30/06/2020 2:23 pm, Michael Black via groups.io wrote:
Don't know what all the other loggers do but probably the same behavior I'd think.  They just put in what they receive without addiontal interpretation.

N3FJP Contest loggers parse the SRX_STRING & STX_STRING fields to pull the class and sect data out or other fields depending on the Contest.

If a general purpose logger like Log4OM has a selector to set the contest_id but doesn't utilize the exchange data provided in the correct standard format for that particular contest, that's Log4OM's problem not mine.

I certainly wont be going down the path of extracting data from the correctly formatted standard contest exchanges provided by WSJT-X to accommodate the whims of general purpose loggers that cant or wont use the data despite having a contest_id selector set in their software.

JTAlert is acting as bridge for logging, passing through the data without alteration except for minor string formatting and ensuring the frequency is of the correct format, Hz, kHz or MHz depending on the logger involved.

de Laurie VK3AMA


locked WAE Sicily alert

Graham Alston
 

I have Wanted CQ Marathon active and I'm getting WAE Sicily alerts even though this entity is in the Not Wanted list?

73 Graham VK3GA

v2.16.8


locked Re: Did not log exchange correctly to Log4OM v2 #FT8

Michael Black
 

Nope...doesn't appear there's any attempt to parse that info.

Don't know what all the other loggers do but probably the same behavior I'd think.  They just put in what they receive without addiontal interpretation.

Mike




On Monday, June 29, 2020, 05:44:16 PM CDT, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 29/06/2020 11:44 pm, Michael Black via groups.io wrote:
I do see that the contest_id is being sent by WSJT-X but JTALert is not using it for it's own ADIF record along with the class and arrl_sect too.

That's because that data, "contest_id", "class" & "arrl_sect" are not included in the wsjtx UDP QSO Logged message (#5) which JTAlert has always used for logging. Only the SRX_STRING & STX_STRING fields are available in message #5.

The class and arrl_sect data are part of the standard SRX_STRING & STX_STRING fields which the Logger should use to populate based on its knowledge of the contest in question.

I see that Log4OM has a Contest mode where you tell it the contest id, does it not automatically populate the class and arrl_sect fields based on what is received in the SRX_STRING field?

With the differences in the #5 & #12 UDP messages (#12 data not available in the #5 data)
it looks like I need to change JTAlert to use the "Logged ADIF" message (#12) in future.

de Laurie VK3AMA


locked Re: Decodes window not always populating

HamApps Support (VK3AMA)
 

On 29/06/2020 8:12 am, W4WT wrote:
I'm not sure why my "friendly name" clears when I reboot the computer but it does every time.  I've tried just adding a word in front of whats there and even changing the complete name to a shorter one and it reverts every time I reboot.  Just to check and make sure I'm doing this like you are, I'm opening the Sound Control Panel, highlighting the default playback sound device, right clicking, selecting properties, and changing the name that appears above the "change icon" button, and clicking OK.

Joe

Try one of the 4 methods listed here...
https://www.tenforums.com/tutorials/128826-rename-sound-input-output-device-windows-10-a.html

de Laurie VK3AMA


locked Re: Decodes window not always populating

Laurie, VK3AMA
 

On 29/06/2020 8:12 am, W4WT wrote:
Just to check and make sure I'm doing this like you are, I'm opening the Sound Control Panel, highlighting the default playback sound device, right clicking, selecting properties, and changing the name that appears above the "change icon" button, and clicking OK.
Yes, that's how I am doing it.

After you change the name, close Control Panel and then open it again, is the friendly name still changed? If so that indicates that something that is run as part of the Windows startup is reverting the changes.

Sorry, I can't offer any concrete suggestions as to a fix.

de Laurie VK3AMA


locked Re: ACL, JTAlert, and Port 1100

Norm Fasoletos <norm.k7nwf@...>
 

Is there a JT Alert User Manual available?

Norm - K7NWF

On Jun 29, 2020, at 7:33 PM, Laurie, VK3AMA <hamapps.support@vkdxer.com> wrote:


On 29/06/2020 12:11 pm, W5BT via groups.io wrote:
The fact that ACL was working fine, I didn't realize I hadn't changed the folder location till later. I went back and opened the database and all contacts were ACL and not in the FD log.
JTAlert sends logging commands to the N3FJP logger (ACLog or FD) on the standard 1100 port. As to which logger the QSO ends up in that depends on which logger is running and has the 1100 port API service running. JTAlert doesn't know which Logger is active and receiving. JTAlert only needs to know the actual log file used, and thus the need for changing when switching loggers, is when it performs a QSO was logged check AND for all B4 checks. If you fail to switch the N3FJP log path in JTAlert after you switch loggers you will likely see previously worked Callsigns not flagged as B4s and get repeated "Unable to confirm QSO was logged" messages.

de Laurie VK3AMA




locked Re: ACL, JTAlert, and Port 1100

Laurie, VK3AMA
 

On 29/06/2020 12:11 pm, W5BT via groups.io wrote:
The fact that ACL was working fine, I didn't realize I hadn't changed the folder location till later. I went back and opened the database and all contacts were ACL and not in the FD log.
JTAlert sends logging commands to the N3FJP logger (ACLog or FD) on the standard 1100 port. As to which logger the QSO ends up in that depends on which logger is running and has the 1100 port API service running. JTAlert doesn't know which Logger is active and receiving. JTAlert only needs to know the actual log file used, and thus the need for changing when switching loggers, is when it performs a QSO was logged check AND for all B4 checks. If you fail to switch the N3FJP log path in JTAlert after you switch loggers you will likely see previously worked Callsigns not flagged as B4s and get repeated "Unable to confirm QSO was logged" messages.

de Laurie VK3AMA


locked Re: JT Alert and QRZ Problem

HamApps Support (VK3AMA)
 

On 29/06/2020 11:50 pm, Norm Fasoletos wrote:
I can go to QRZ and manually log a QSO with no problem

Manual logging does not indicate an expired or invalid XML subscription.

To programmatically upload QSOs to your QRZ logbook requires a current XML subscription, this is a QRZ, not JTAlert, requirement.

Use Windows file explorer, navigate to %localappdata%\HamApps\YOUR_CALLSIGN\session\JTAlertX\ and open the "QrzLog_1.result" file in a text editor like notepad. This file contains the results of the last QSO upload attempt. eg.
2020-06-29 20:12:55 utc
COUNT=1&RESULT=OK&LOGID=525439158

Alternatively open the "1" sub directory and view the "JTAlertV2.Manager.WebLog.Qrz.log.Info" file. This file records all recent QRZ uploads with the corresponding results.

A further alternative, if the "JTAlertV2.Manager.WebLog.Qrz.log.Error" file is present, that indicates an error has occurred, it will list the reason. eg.
2020-06-29 20:10:19.4974 | Error | STATUS=FAIL&REASON=wrong station_callsign for this logbook vk3am doesnt match book callsign VK3AMA&EXTENDED= |

Let us know what you find. If you can't locate the files in question, use the "Help" -> "Contact Support" menu, on the main JTAlert window, to send me your JTAlert files for analysis

de Laurie VK3AMA


locked Re: Logging to N3FPJ times out no matter the length set

HamApps Support (VK3AMA)
 

On 30/06/2020 12:05 am, WB5JJJ - George wrote:
Before I started on Sunday, I rebuilt the N3 LogData.mdb file from the night before adif export.  All files were now visible in the LogData.mdb file and everything worked totally as expected for the rest of the contest with JTA not generating any more warnings. 

--
73's
George - WB5JJJ
Thanks for the update George.

Corrupt MSAccess files, are rare, but when it happens it can produce unpredictable results when trying to run queries against the database, often not failing out-right which would be preferred as a total failure to access the database is easily recognized and reported by JTAlert.

de Laurie VK3AMA


locked Re: Did not log exchange correctly to Log4OM v2 #FT8

HamApps Support (VK3AMA)
 

On 29/06/2020 11:44 pm, Michael Black via groups.io wrote:
I do see that the contest_id is being sent by WSJT-X but JTALert is not using it for it's own ADIF record along with the class and arrl_sect too.

That's because that data, "contest_id", "class" & "arrl_sect" are not included in the wsjtx UDP QSO Logged message (#5) which JTAlert has always used for logging. Only the SRX_STRING & STX_STRING fields are available in message #5.

The class and arrl_sect data are part of the standard SRX_STRING & STX_STRING fields which the Logger should use to populate based on its knowledge of the contest in question.

I see that Log4OM has a Contest mode where you tell it the contest id, does it not automatically populate the class and arrl_sect fields based on what is received in the SRX_STRING field?

With the differences in the #5 & #12 UDP messages (#12 data not available in the #5 data)
it looks like I need to change JTAlert to use the "Logged ADIF" message (#12) in future.

de Laurie VK3AMA


locked Re: Flawless Interface with JT Alerts and N3FJP

HamApps Support (VK3AMA)
 

On 30/06/2020 3:41 am, Steve R via groups.io wrote:
I had a great time running QRP with my FT817ND. JT Alerts worked perfectly with AC LOG / N3FJP . I logged 108 contacts running QRP....great job Laurie!

Steve
VA3FLF
Thanks for the feedback Steve, good to hear that all went well.

It has been my experience that users who have trouble with N3FJP Contest logging with JTAlert have failed to read the simple setup instructions available or haven't followed them correctly, making assumptions along the way about how they think it should work.

de Laurie VK3AMA


locked Re: allocating memory problem #HRD #JTDX

HamApps Support (VK3AMA)
 

On 30/06/2020 7:27 am, kb5slf208@... wrote:
I have JTAlert ver 2.16.8 using Win10. Under Web Services, then Scan Log and Rebuild, the software downloads 1,900,000 files then stops, saying I have a Allocating Memory problem. Does anyone have any ideas on how to fix this??

OM (please sign with a Name/Callsign),

JTAlert doesn't download any files as part of the Scan Log process, it is reading QSO records from your log. Also Web Services settings has nothing to do with the Scanning.

Regarding this HRD problem, very likely your using an Access database for the Log, is that the case?
There have been a very small number of HRD users who have experienced very slow lookups of Scans that were ultimately fixed by creating a new HRD Log file. Do an ADIF export of your current Log, create a new Log and import the previously created ADIF data. Once you have the new log created you will need to change the JTAlert settings for the HRD logging to use that new log.

Let us know if the new log fixes the problem.

de Laurie VK3AMA


locked allocating memory problem #HRD #JTDX

kb5slf208@...
 

I have JTAlert ver 2.16.8 using Win10. Under Web Services, then Scan Log and Rebuild, the software downloads 1,900,000 files then stops, saying I have a Allocating Memory problem. Does anyone have any ideas on how to fix this??


locked Flawless Interface with JT Alerts and N3FJP

Steve R
 

I had a great time running QRP with my FT817ND. JT Alerts worked perfectly with AC LOG / N3FJP . I logged 108 contacts running QRP....great job Laurie!

Steve
VA3FLF


locked Re: Does not log exchange to Log4OMV1after leaving FD mode

John
 

Mike,

Please disregard this. The Log4OM communicator had not started, all is well now. thanks for being there

John

Virus-free. www.avg.com

2341 - 2360 of 32885