Topics

locked Did not log exchange correctly to Log4OM v2 #FT8


me@...
 

The exchanges for field day when I worked FT4/8 were in the pop up log window in JtAlert.  however they did not get into the log4om log correctly.  I have do go manually fix them.
I check all the settings and don't see anything I need to change.
Should this work or is this a Log4OM issue.
There was only a 1D etc. in RST and Sent.  The contest exchanges were populated correct on the jtalert pop up but were blank in the Log4OM log.

Thanks for all the good work on JTalert!    let me know if there is something I need to do on this issue I had.

Thanks,
Will


Michael Black
 

Yup...but the STX_STRING is correct....the RST_RCVD and RST_SENT are supposed to be signal reports...not contest exchange information.  There is no RST for field day exchanges so it really ought to be blank.

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.

WSJT-X ADIF
<call:5>K5JAZ <gridsquare:4>EM32 <mode:4>MFSK <submode:3>FT4 <rst_sent:2>1D <rst_rcvd:2>1D <qso_date:8>20200628 <time_on:6>121653 <qso_date_off:8>20200628 <time_off:6>121722 <band:3>20m <freq:9>14.080312 <station_callsign:5>W9MDB <my_gridsquare:6>EM40HV <tx_pwr:2>50 <contest_id:14>ARRL-FIELD-DAY <SRX_STRING:5>1D LA <class:2>1D <arrl_sect:2>LA <eor>

JTAlert SQL insert
INSERT INTO data VALUES(2869952,1593346656.0000000278,'2020-06-28 12:17:36:900',0,'UDP QSO Logged : WSJT-X : <CALL:5>K5JAZ <FREQ:9>14.080312 <MODE:3>FT4 <GRIDSQUARE:4>EM32 <QSO_DATE:8>20200628 <QSO_DATE_OFF:8>20200628 <TIME_ON:6>121653 <TIME_OFF:6>121722 <RST_SENT:2>1D <RST_RCVD:2>1D <STX_STRING:5>1D IL <SRX_STRING:5>1D LA <TX_PWR:2>50 <STATION_CALLSIGN:5>W9MDB <MY_GRIDSQUARE:6>EM40HV <EOR>');

Mike W9MDB




On Monday, June 29, 2020, 08:25:56 AM CDT, me@... <me@...> wrote:


The exchanges for field day when I worked FT4/8 were in the pop up log window in JtAlert.  however they did not get into the log4om log correctly.  I have do go manually fix them.
I check all the settings and don't see anything I need to change.
Should this work or is this a Log4OM issue.
There was only a 1D etc. in RST and Sent.  The contest exchanges were populated correct on the jtalert pop up but were blank in the Log4OM log.

Thanks for all the good work on JTalert!    let me know if there is something I need to do on this issue I had.

Thanks,
Will


me@...
 

My log4om log record had only 1D or 1E etc in both the RST sent and RST received.
The STX and SRX strings were all blank in every one and the contest ID was blank.

maybe the insert needed the contest ID to be included for the stx strings to get set.  I don't see the contest ID in the insert command that you found...
  
Will


Michael Black
 

That was my point...that data isn't being carried along....

Log4OMV2 also had just the 1D/1E which should be blank.  That is not a signal report.

Mike




On Monday, June 29, 2020, 08:53:49 AM CDT, <me@...> wrote:


My log4om log record had only 1D or 1E etc in both the RST sent and RST received.
The STX and SRX strings were all blank in every one and the contest ID was blank.

maybe the insert needed the contest ID to be included for the stx strings to get set.  I don't see the contest ID in the insert command that you found...
  
Will


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


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


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


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