On Jan 12, 2021, at 7:26 PM, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:



On 13/01/2021 12:30 pm, Ronald Panetta wrote:

I encountered the same issue recently posted by David over a year ago here: https://hamapps.groups.io/g/Support/message/26679?p=,,,20,0,0,0::relevance,,hrd+udp+2333,20,2,0,67711266. Reference his screen snapshot in his post. 

I opened a ticket with HRD and they're position is this is a JTAlert issue. Here is their latest response "We only Support UDP Logging from N1MM and WSJTX not JTAlert, it has its own defects. Since QSO Forward works perfect for the 1st 2 there is an issue in JTALert."

I have captured via Wireshark the UDP/2333 packet generated by JTAlert as part of the fault isolation. The data portion of the packet is as follows: 

<CALL:5>K7RQN<QSO_DATE:8>20210111<TIME_ON:6>225145<TIME_OFF:6>225315<FREQ:9>14.075683<FREQ_RX:9>14.075683<BAND:3>20m<BAND_RX:3>20m<MODE:3>FT8<RST_SENT:3>-05<RST_RCVD:3>-08<LOTW_QSL_SENT:1>R<LOTW_QSL_RCVD:1>R<EQSL_QSL_SENT:1>R<EQSL_QSL_RCVD:1>R<STATE:2>AZ<CQZ:1>3<ITUZ:1>6<PFX:2>K7<CONT:2>NA<DXCC:3>291<COUNTRY:13>United States<GRIDSQUARE:4>DM33<DISTANCE:4>3353<A_INDEX:2>12<K_INDEX:1>4<SFI:2>73<COMMENT:25>FT8 Sent: -05 Rcvd: -08<MY_GRIDSQUARE:6>FN13VD<MY_CQ_ZONE:1>5<MY_ITU_ZONE:1>8<STATION_CALLSIGN:6>WB2WGH<QSO_COMPLETE:1>Y<EOR>

Anyone have a solution? Is this an HRD or a JTAlert issue? Versions as follow:

WSJT-X v2.2.2
JTAlert, v2.16.17
HRD Logbook v6.7.0.323

 

Thanks in advance, 
Ron WB2WGH

Ron,

I see nothing wrong with that ADIF record you captured. The QSO_DATE is set and is of the correct format. I can't explain why HRD is not accepting the <QSO_DATE> field. Is all other data being logged correctly?

What happens if you save that capture to a text file and then do an manual ADIF import into HRDLogbook? Does the imported QSO have a Date recorded?

I saved your capture to a text file, without modification a copy and paste only, and successfully imported it into my Logger (DXKeeper) without issue.

   

<TestLog.png>

FWIW, the ADIF record transmission on UDP port 2333 service first appeared with JTAlert after which N1MM started to use it for WSJT-X logging and then later WSJT-X adopted the same scheme down to the same port number. They are identical in operation.

As for HRD Supports comment "it has its own defects", I don't know to what they are referring. But then again, they have had a hatred for JTAlert and myself personally for a long time. It stems from when I publicly called them out (several years ago now) about their sloppy coding and their deliberate interference with the JTAlert process forcibly terminating it without any notification to the user that the action had been taken or why it had been taken.

If HRD support were worth their salary and the money you are paying for support they could quickly identify why the adif record was not being fully logged. But that's my opinion. Surely their software would be recording any exceptions that occurred during operation, like invalid data on logging, and they could examine that rather than dismissing a paying customer without some investigation of the problem.

Past history has shown, the mere mention of JTAlert is enough for HRD Support to disregard the support request out-of-hand, despite the problem often being within HRD Logbook and proven as such.

I really don't care about HRDLLC or their software. I only retain HRD logging support in JTAlert for the many happy JTAlert/HRD users, not for the HRD brand or its owners.

Now that I have had my rant. There are many HRD/JTAlert users perhaps one might chime in to this message thread.

de Laurie VK3AMA