locked 2.11.1 Fails to Log to HRD Logbook


JohnB
 

Laurie,

Sorry to report that JTAlert 2.11.1 fails to log to HRD Logbook.

I'm using HRD Logbook v6 and JTDX.

. . . John


HamApps Support (VK3AMA)
 

On 3/06/2018 8:48 PM, JohnB wrote:
Laurie,

Sorry to report that JTAlert 2.11.1 fails to log to HRD Logbook.

I'm using HRD Logbook v6 and JTDX.

. . . John
There have been no reports of HRD logging failure from the Beta testers who have been using this JTAlert build for a week now.

You session file shows that not all logging events sent to HRD failed.
Of the last 3 loggings to HRD, 1 failed while 2 were successful.

2018-06-03 11:09:00 __logqso_HRD() : "VE3CIQ" : SUCCESS

2018-06-03 11:11:15 __logqso_HRD() : "AB4CQ"  : SUCCESS

2018-06-03 11:15:20 __logqso_HRD() : "W5COV"  : FAILURE


Since logging is intermittent and your running Win10, I suggest a PC Restart is in order.

de Laurie VK3AMA


HamApps Support (VK3AMA)
 

I neglected to include in my last response the following...
When a TCP logging event is sent to HRDLogook, a typical response is
[c] Found 33 Valid Fields...
Added 48 Fields to My Logbook...
[c] [c]
Of the failed logging events, HRD never responded to the TCP command. This is the problem.
As to why HRDLogbook ignored the TCP command, I have no idea at this time.

de Laurie VK3AMA


Michael Black
 

Laurie, is the HRD logging a single TCP packet?

I've been trying to write a hamlib back-end for HRD rig control and I've found throwing multiple packets at it (like is needed for WSJT-X split mode) causes TCP reset problems with HRD (done the same thing with FLRig and TRXManager without such problems).  Still trying to figure out the sleeps needed or identify enough to create a bug report for HRD.

de Mike W9MDB




On Sunday, June 3, 2018, 6:55:34 AM CDT, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


I neglected to include in my last response the following...
When a TCP logging event is sent to HRDLogook, a typical response is
> [c] Found 33 Valid Fields...
> Added 48 Fields to My Logbook...
> [c] [c]

Of the failed logging events, HRD never responded to the TCP command.
This is the problem.
As to why HRDLogbook ignored the TCP command, I have no idea at this time.

de Laurie VK3AMA





HamApps Support (VK3AMA)
 

On 3/06/2018 10:03 PM, Michael Black via Groups.Io wrote:
Laurie, is the HRD logging a single TCP packet?

I've been trying to write a hamlib back-end for HRD rig control and I've found throwing multiple packets at it (like is needed for WSJT-X split mode) causes TCP reset problems with HRD (done the same thing with FLRig and TRXManager without such problems).  Still trying to figure out the sleeps needed or identify enough to create a bug report for HRD.

de Mike W9MDB
Mike,

JTAlert sends a single TCP packet, this hasn't changed for a couple of years now and there is definitely no HRD changes in this build of JTAlert.

I don't believe it is a packet data length issue as the HRDLogbook.trace file has a 680 character command logging correctly while a 649 character packet failed (no response for HRDLogbook).

de Laurie VK3AMA



on5po
 

<br class="Apple-interchange-newline"><div></div>
112/5000
hello, for info,
With the latest version jtalert, "send date eqslcc, no longer fits, in the log of HRD





De : Support@HamApps.groups.io <Support@HamApps.groups.io> de la part de HamApps Support (VK3AMA) <vk3ama.ham.apps@...>
Envoyé : dimanche 3 juin 2018 14:22
À : Support@HamApps.groups.io
Objet : Re: [HamApps] 2.11.1 Fails to Log to HRD Logbook
 
On 3/06/2018 10:03 PM, Michael Black via Groups.Io wrote:
Laurie, is the HRD logging a single TCP packet?

I've been trying to write a hamlib back-end for HRD rig control and I've found throwing multiple packets at it (like is needed for WSJT-X split mode) causes TCP reset problems with HRD (done the same thing with FLRig and TRXManager without such problems).  Still trying to figure out the sleeps needed or identify enough to create a bug report for HRD.

de Mike W9MDB
Mike,

JTAlert sends a single TCP packet, this hasn't changed for a couple of years now and there is definitely no HRD changes in this build of JTAlert.

I don't believe it is a packet data length issue as the HRDLogbook.trace file has a 680 character command logging correctly while a 649 character packet failed (no response for HRDLogbook).

de Laurie VK3AMA



Morris WA4MIT
 

Having the same no logging issue here now along with the delay issue what next? I enabled debugging and sent a report hope it helps 
73 Morris wa4mit


Rick Johnson
 

I find the same. I need to Log QSO 3 times before it will log to DXK. 
Then go to QRZ.com and delete 2 of them.
73,
Rick W3BI


On Sun, Jun 3, 2018 at 9:09 AM, on5po <on5po@...> wrote:
<br class="Apple-interchange-newline"><div></div>
112/5000
hello, for info,
With the latest version jtalert, "send date eqslcc, no longer fits, in the log of HRD





De : Support@HamApps.groups.io <Support@HamApps.groups.io> de la part de HamApps Support (VK3AMA) <vk3ama.ham.apps@...>
Envoyé : dimanche 3 juin 2018 14:22
À : Support@HamApps.groups.io
Objet : Re: [HamApps] 2.11.1 Fails to Log to HRD Logbook
 
On 3/06/2018 10:03 PM, Michael Black via Groups.Io wrote:
Laurie, is the HRD logging a single TCP packet?

I've been trying to write a hamlib back-end for HRD rig control and I've found throwing multiple packets at it (like is needed for WSJT-X split mode) causes TCP reset problems with HRD (done the same thing with FLRig and TRXManager without such problems).  Still trying to figure out the sleeps needed or identify enough to create a bug report for HRD.

de Mike W9MDB
Mike,

JTAlert sends a single TCP packet, this hasn't changed for a couple of years now and there is definitely no HRD changes in this build of JTAlert.

I don't believe it is a packet data length issue as the HRDLogbook.trace file has a 680 character command logging correctly while a 649 character packet failed (no response for HRDLogbook).

de Laurie VK3AMA




Ron W3RJW
 

Another data point: Using HRD v6.4.0.840, WSJT-X v1.9.0 and newly installed JTAlertX v 2.11.1 ....   JTAlert logs to HRD like always ...
--
73
Ron, W3RJW


Rick Johnson
 

Reboot doesn't help.
W3BI

On Sun, Jun 3, 2018 at 9:16 AM, Morris WA4MIT via Groups.Io <wa4mit@...> wrote:
Having the same no logging issue here now along with the delay issue what next? I enabled debugging and sent a report hope it helps 
73 Morris wa4mit



Rick Johnson
 

My problem is JTA won't log to DXK on the first 2 attempts.
I must click Log QSO, acknowledge it failed to log to DXK twice and then on the third attempt it acknowledges logging.
Then I must go to QRZ.com and remove 2 of the entries. Reboot and cold start don't help.
73, Rick W3BI


On Sun, Jun 3, 2018 at 9:41 AM, Rick Johnson <w3bi.rick@...> wrote:
Reboot doesn't help.
W3BI

On Sun, Jun 3, 2018 at 9:16 AM, Morris WA4MIT via Groups.Io <wa4mit@...> wrote:
Having the same no logging issue here now along with the delay issue what next? I enabled debugging and sent a report hope it helps 
73 Morris wa4mit




Brad Penn
 

Interesting...I'm running the same versions as you, but have the logging problem.

73
Brad
KD5ZAT