Topics

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


Ronald Panetta
 

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


HamApps 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. 

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.

   

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.

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


William W1WAB
 

Ron--

I have no issues with logging date/time in HRD. Setup is HRD 6.7.0.277; WSJT 2.2.2; JT Alert 2.16.8

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)

Hope this helps, 73, Bill W1WAB


Roger M
 

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


Antony
 

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
 

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. 
  • HRD: V6.7.0.323
  • WSJT: V2.2.2
  • JTAlert: V2.16.17
When I set things up the way you have it (my original config) I was missing dates as:
image.png
 
When I check the secondary logging box I get dups as expected and HRD easily cleans those up.

Logging Capture, 2021-01-13-1015 (5 QSO, Dual Logging).PNG

I get the correct behaviour when I log from WSJT (secondary logging box) and disable logging in JTAlert. The concern is two fold:
  • Secondary logging in WSJT is deprecated
  • Hate to have the logging daisy chained (JTAlert logs to WSJT which then logs to HRD). Seems cleaner if JTAlert logs to both WSJT and HRD
Ron


On Wed, Jan 13, 2021 at 11:21 AM William W1WAB <wab.w1wab@...> wrote:

Ron--

I have no issues with logging date/time in HRD. Setup is HRD 6.7.0.277; WSJT 2.2.2; JT Alert 2.16.8

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)

Hope this helps, 73, Bill W1WAB



--
Ron & Janet Panetta
7913 Walking Stick Way
Liverpool, NY 13090
315-451-4681

E-mail: ron@...


Chris VK2BYI
 

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
VK2BYI

 


Ronald Panetta
 

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:

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
VK2BYI

 


Ronald Panetta
 

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:
Ferry,
I respectfully disagree as it has everything to do with HRD and possible JTAlert.  JTAlert CAN post QSO information via UDP broadcasts to port 2333. See the attached screen snapshot of JTAlert Last QSO API settings screen. In both David's case and my case, the highlighted QSOs were passed by JTAlert to via UDP port 2333 and subsequently picked up by HRD and logged with all fields but the date. In my second post I provide the data field of a UDP/2333 packet picked up by Wireshark (Ethernet sniffer) with the QSO data. In both our cases, the date field of that QSO is missing per David's screen snapshot. 

Now it takes two to tango so JTAlert generates the UDP/2333 packet and HRD picks up the UDP/2333 so the failure could be on either end. I'm starting the query with HRD. BTW, I contacted David directly to see if he ever got a resolution, indicated he was unable to get the issue resolved so his solution was to abandon HRD.

Ron, WB2WGH


On Wed, Jan 13, 2021, 10:05 PM Chris VK2BYI <chris@...> 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
VK2BYI

 


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


HamApps Support (VK3AMA)
 

On 14/01/2021 2:05 pm, Chris VK2BYI 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
VK2BYI


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


HamApps 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.


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:
Ferry,
I respectfully disagree as it has everything to do with HRD and possible JTAlert.  JTAlert CAN post QSO information via UDP broadcasts to port 2333. See the attached screen snapshot of JTAlert Last QSO API settings screen. In both David's case and my case, the highlighted QSOs were passed by JTAlert to via UDP port 2333 and subsequently picked up by HRD and logged with all fields but the date. In my second post I provide the data field of a UDP/2333 packet picked up by Wireshark (Ethernet sniffer) with the QSO data. In both our cases, the date field of that QSO is missing per David's screen snapshot. 

Now it takes two to tango so JTAlert generates the UDP/2333 packet and HRD picks up the UDP/2333 so the failure could be on either end. I'm starting the query with HRD. BTW, I contacted David directly to see if he ever got a resolution, indicated he was unable to get the issue resolved so his solution was to abandon HRD.

Ron, WB2WGH


HamApps 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
 

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.
​.
. [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
----End Quote----

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
 

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):

----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.
​.
. [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
----End Quote----

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



--
Ron & Janet Panetta
7913 Walking Stick Way
Liverpool, NY 13090
315-451-4681

E-mail: ron@...


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:


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):

----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.
​.
. [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
----End Quote----

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



--
Ron & Janet Panetta
7913 Walking Stick Way
Liverpool, NY 13090
315-451-4681

E-mail: ron@...
<[HamApps] QSO dates missing in HRD from JTAlert UDP_2333 #HRD.pdf>


Antony
 

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