Date
1 - 19 of 19
Locked QSO dates missing in HRD from JTAlert UDP/2333
|
Ronald Panetta, WB2WGH
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 |
|
|
|
JTAlert Support (VK3AMA)
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. 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.  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 |
|
|
|
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.
toggle quoted message
Show quoted text
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:
|
|
|
|
Ron-- Please note that in WSJT, Secondary UDP 2333 box is not checked off in the Reporting Tab I found that when the box was checked (as needed for Gridtracker) the QSO dates did not get recorded in the HRD log. (I no longer use Gridtracker) |
|
|
|
Roger M <ac6bw@...>
Laurie, Please do not discontinue logging to HRD 6.x. It works perfectly fine for most of us, and we appreciate all of your efforts.
-- 73, Roger AC6BW |
|
|
|
kk7h@...
Hi Laurie.
I agree with Roger, as you know I been around for some time. I have not had an issue with logging to HRD for years now. I was there for the dust up a few years ago with HRD, and you have done a great job for the HRD users since. Thank you for all that you do for the Ham Community. 73 Mike H. KK7H |
|
|
|
I use the latest versions of WSJT, JTALERT, GRIDTRACKER and HRD without any problems. They work well together.
I echo Roger’s plea for HRD support to continue despite the underlying problems! Carry on the good work Laurie and team. 73, Antony G4CUS |
|
|
|
Ronald Panetta, WB2WGH
Bill: First let me start out by saying I just installed a new PC in the shack. Prior to this I did not do much digital as they old machine was way too slow. So with the new machine, I installed the latest software as a baseline so I don't have any history of past issues.
When I set things up the way you have it (my original config) I was missing dates as:  When I check the secondary logging box I get dups as expected and HRD easily cleans those up.  I get the correct behaviour when I log from WSJT (secondary logging box) and disable logging in JTAlert. The concern is two fold:
Ron On Wed, Jan 13, 2021 at 11:21 AM William W1WAB <wab.w1wab@...> wrote:
--
|
|
|
|
There is a known defect in HRD Logbook where UDP broadcasts received on the QSO Forwarding for WSJT-X port may not log correctly depending upon the ADIF field order. Of course, the field order in ADIF formatted UDP payloads shouldn't matter, and the defect has been fixed and will be released in the next update of HRD. In the meantime, you can use the HRD V5/V6 logging interface in JTAlert, until the next release of HRD when you can revert to using the Last QSO API broadcasts again. Stay safe and healthy. 73 Chris |
|
|
|
Ronald Panetta, WB2WGH
Thanks for that insight. I just last week opened up a ticket with HRD and here is their response. Ronald, 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. --- You can view the details of your service request at: https://support.hamradiodeluxe.com/helpdesk/tickets/11210 --- 73, Ferry PD9FER Ham Radio Deluxe Support Technician Ron, WB2WGH On Wed, Jan 13, 2021, 10:05 PM Chris VK2BYI <chris@...> wrote:
|
|
|
|
Ronald Panetta, WB2WGH
And below is another response from HRD support. Neither message touches on a HRD defect. Wish they would admit to it as it is causing a lot of effort on others trying to fault isolate. Ronald, You need to disable that option in WSJT-X and in JTAlert (port 2333) Let JTAlert write to the Database (also disable QSO Forwarding in Logbook) Then there are no issues at all. --- You can view the details of your service request at: https://support.hamradiodeluxe.com/helpdesk/tickets/11210 --- 73, Ferry PD9FER Ham Radio Deluxe Support Technician  On Tue, Jan 12 at 5:15 AM , Ronald Panetta <ron@...> wrote: On Wed, Jan 13, 2021, 10:05 PM Chris VK2BYI <chris@...> wrote:
|
|
|
|
Dave AA6YQ
+ AA6YQ comments below
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. + Whoever wrote that lacks even a basic understanding of software. 73, Dave, AA6YQ |
|
|
|
JTAlert Support (VK3AMA)
On 14/01/2021 2:05 pm, Chris VK2BYI
wrote:
Tnx Chris. An ADIF parser that depends on field order (when the adif spec has no such requirement) is crazy. What did they get a first year student programmer to write the code? Treating an adif record like some sort of csv record where order is critical, I have no words except to shake my head and reiterate what I have said before, "sloppy programming". de Laurie VK3AMA |
|
|
|
JTAlert Support (VK3AMA)
Ron,
Your best option is to enable HRD logging in JTAlert. This avoids the QSO forwarding mechanism and has several benefits. You get full access to the alerting facilities and B4 reporting of JTAlert and the additional content that is logged by JTAlert that are not provided by the WSJT-X QSO forwarding mechanism (but still available via the JTAlert mechanism) like dxcc, zones, states, names & addresses (if you have an xml service enabled). Having JTAlert set to use a logger also allows for one-click updating of the Alert databases rather than manually maintaining them individually which is very tedious and error prone. To correct the HRD support comment, JTAlert does not write to the HRD database. All logging to HRD is done via their TCP interface, it never directly modifies the HRD Log, that is handled internally by HRDLogbook when it receives the TCP instruction from JTAlert. The only time that JTAlert writes directly to a HRD log is for HRD V5 and old HRD pre V6.2 where the TCP logging interface does not exist for either. de Laurie VK3AMA On 14/01/2021 3:19 pm, Ronald Panetta wrote: And below is another response from HRD support. Neither message touches on a HRD defect. Wish they would admit to it as it is causing a lot of effort on others trying to fault isolate. |
|
|
|
JTAlert Support (VK3AMA)
On 15/01/2021 4:54 pm, HamApps Support
(VK3AMA) via groups.io wrote:
Your best option is to enable HRD logging in JTAlert. Another benefit of Logging direct to HRDLogbook from JTAlert, any QSOs that are logged when JTAlert/WSJT-X is not being used, say your RTTY, PSK, SSB & CW QSOs, will still be available to JTAlert when it performs B4 checks, displays QSO histories and Alert Database rebuilds (for when you're not tracking by individual or digital only mode) de Laurie VK3AMA |
|
|
|
Ronald Panetta, WB2WGH
Chris is 100% correct. The issue is an HRD defect and will be fixed in the next release. I received the following directly from Mike VK4EIE (WA9PIE):
----Begin Quote---- Ron,
Ferry is absolutely incorrect here. I'll take it up with him later. We DO support UDP broadcasts from ANY software that is capable of producing them... including JTAlert.
We fully support JTAlert and its use with Ham Radio Deluxe.
.
----End Quote----. [non-relevant text omitted] . We do have this problem fixed already and it will be part of the next release (which is pending completion on a couple other changes). . . [non-relevant text omitted] . Dr. Michael (Mike) Carper, VK4EIE (WA9PIE) HRD Software, LLC Makers of Ham Radio Deluxe Sounds like Mike is trying to mend previously broken fences based on some additional insight he shared with me. Given there is light at the end of the tunnel with this logging issue, I have a workaround in place and will test the new HRD version for the fix upon release. Thanks all and 73, Ron, WB2WGH |
|
|
|
Ronald Panetta, WB2WGH
Mike, Not sure if you have visibility into the JTAlert forum. In the event you don't attached is the response I posted. The reference to Chris (VK2BYI) is regarding his post stating this was a known HRD defect to be corrected in the next release. 73, Ron On Fri, Jan 15, 2021 at 10:07 AM Ronald Panetta <ron@...> wrote: Chris is 100% correct. The issue is an HRD defect and will be fixed in the next release. I received the following directly from Mike VK4EIE (WA9PIE): --
|
|
|
|
Jack Plum
Hey Ron!
I always let JTALERT handle everything and have never had an issue except when I forget to start it
Just have it send to HRD and turn off sending from wsjtx
Hope to catch you in the VHF contest. I’ll be qrp/p as always
Jack WX3P
On Jan 15, 2021, at 10:13 AM, Ronald Panetta <ron@...> wrote:
|
|
|
|
Jack. I have set JTAlert to auto start wsjt and gridtracker when I click on JTAlert’s shortcut. This means I can’t forget to start JTAlert which I sometimes did!
73, Antony G4CUS |
|
|