Re: QSO dates missing in HRD from JTAlert UDP/2333 #HRD


Russ Ravella
 

Here’s my chime FWIW.  I used HRD for a long time; started with it many years ago and stayed stuck with it. I finally gave up and was able to wean myself off the last piece of it and complete the move to the spectacularly superior (and free) DXLab Suite. Why anyone would voluntarily use it at this point, let alone actually waste money on it is beyond me. Among a host of other things, they seem to have alienated a large number of developers they should be cooperating with in addition to Laurie.  I agree with every word you said.

I am totally ok with anyone who disagrees and I sincerely hope it’s working better for you than it did for me.  But as far as I’m concerned, it’s software junk second only to Flex Radio SmartSDR in poor quality.  Thank good for the likes of DXLS and JTAlert.


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

Join Support@HamApps.groups.io to automatically receive all group messages.