JTDX/FT8 RR73 Transmission halted by UDP


Darren Collins (G0TSM)
 

Hi Bob and friends.,

When I'm running FT8 in JTDX I quite often see that UDP halts my TX when I'm sending RR73. This coincides with auto-logging the QSO and then Logger32 backing up the log.. If I set the log backup to 1 (backup after every QSO) then the Tx is halted every time the RR73 is sent and the QSO is logged and backed up. The workaround of course is to set 'do not backup current log book after QSOs' and then the tx is never halted.

 

Typical scenario

 

CQ 8P2K GK03

8P2K G0TSM -18 (I've double clicked on 8P2K and I'm sending his report)            

 

G0TSM 8P2K R-18 (He's confirming with my report - exciting stuff!)          •

 

8P2K G0TSM RR73 (My JTDX is replying to confirm and log the QSO and then backup starts) and Logger32 tells JTDX to stop transmitting.

*** Tx is interrupted by UDP ***           

 

8P2K G0TSM RR73 (I double click on his R-18 again to confirm) 

*** Once again Tx is interrupted by UDP as the log backup is still in progress***          

 

From JTDX:

Halt Tx triggered at TX: UDP request 50.313 MHz  FT8:  8P2K G0TSM RR73        

 

Is there a way around this besides manually logging the QSO as I like to auto-backup every 10 QSOs?

 

Thank You and 73, Darren G0TSM

 


Bob
 

It is a VERY bad idea to attempt a logbook backup while the cherry-picker is actively in contact. Manual QSOs (FT4/8, SSB, CW) is no problem as you're not actually taking CPU cycles away from anything important, or anything that relies on critical timing. I'd suggest (if you have the insatiable urge to backup every QSO), you turn off automatic backups, and manually backup in periods when/where the cotton-picking little cherry-picker is inactive. 
SeventyThree(s).
 
PS. There is no cherry-picker event viewer message "Tx is interrupted by UDP".

On 06/22/2021 4:52 PM Darren Collins (G0TSM) <daz@...> wrote:
 
 

Hi Bob and friends.,

When I'm running FT8 in JTDX I quite often see that UDP halts my TX when I'm sending RR73. This coincides with auto-logging the QSO and then Logger32 backing up the log.. If I set the log backup to 1 (backup after every QSO) then the Tx is halted every time the RR73 is sent and the QSO is logged and backed up. The workaround of course is to set 'do not backup current log book after QSOs' and then the tx is never halted.

 

Typical scenario

 

CQ 8P2K GK03

 

8P2K G0TSM -18 (I've double clicked on 8P2K and I'm sending his report)            

 

G0TSM 8P2K R-18 (He's confirming with my report - exciting stuff!)          •

 

8P2K G0TSM RR73 (My JTDX is replying to confirm and log the QSO and then backup starts) and Logger32 tells JTDX to stop transmitting.

*** Tx is interrupted by UDP ***           

 

8P2K G0TSM RR73 (I double click on his R-18 again to confirm) 

*** Once again Tx is interrupted by UDP as the log backup is still in progress***          

 

From JTDX:

Halt Tx triggered at TX: UDP request 50.313 MHz  FT8:  8P2K G0TSM RR73        

 

Is there a way around this besides manually logging the QSO as I like to auto-backup every 10 QSOs?

 

Thank You and 73, Darren G0TSM

 


Darren Collins (G0TSM)
 

Hello Bob, thanks for replying.

Yes I can understand why you wouldn’t want to try and add more QSOs into the log why it’s being backed up. My log of 85K QSOs only takes 4 secs to backup whereas there will be a longer delay with bigger logs and/or slower hardware (Mine is a nerd spec PC).

 

I can see that Cherry picking is turned off when the backup window is opened but in my case I am not cherry picking but manually making QSOs by clicking in JTDX then logging into Logger32 via UDP. So Logger32 is turning off cherry picking (even when it was already off) and halting the RR73 Tx when the auto-backup starts?

I note that if you are CQing in JTDX that opening the backup window does not halt the transmission, but exiting the backup window after the backup has been completed enables cherry picking, even if you didn’t want it on,  and halts the Tx.

 

Also syncing LOTW from an ADIF file enables cherry picking when it’s complete, even if it was off before…

 

For now I have changed the backup schedule to 50 QSOs.

 

73 and Thank You, Darren G0TSM

 

 

 

 

From: hamlogger@groups.io <hamlogger@groups.io> On Behalf Of Bob
Sent: 22 June 2021 22:13
To: hamlogger@groups.io
Subject: Re: [hamlogger] JTDX/FT8 RR73 Transmission halted by UDP

 

It is a VERY bad idea to attempt a logbook backup while the cherry-picker is actively in contact. Manual QSOs (FT4/8, SSB, CW) is no problem as you're not actually taking CPU cycles away from anything important, or anything that relies on critical timing. I'd suggest (if you have the insatiable urge to backup every QSO), you turn off automatic backups, and manually backup in periods when/where the cotton-picking little cherry-picker is inactive. 

SeventyThree(s).

 

PS. There is no cherry-picker event viewer message "Tx is interrupted by UDP".

On 06/22/2021 4:52 PM Darren Collins (G0TSM) <daz@...> wrote:

 

 

Hi Bob and friends.,

When I'm running FT8 in JTDX I quite often see that UDP halts my TX when I'm sending RR73. This coincides with auto-logging the QSO and then Logger32 backing up the log.. If I set the log backup to 1 (backup after every QSO) then the Tx is halted every time the RR73 is sent and the QSO is logged and backed up. The workaround of course is to set 'do not backup current log book after QSOs' and then the tx is never halted.

 

Typical scenario

 

CQ 8P2K GK03

 

8P2K G0TSM -18 (I've double clicked on 8P2K and I'm sending his report)            

 

G0TSM 8P2K R-18 (He's confirming with my report - exciting stuff!)          •

 

8P2K G0TSM RR73 (My JTDX is replying to confirm and log the QSO and then backup starts) and Logger32 tells JTDX to stop transmitting.

*** Tx is interrupted by UDP ***           

 

8P2K G0TSM RR73 (I double click on his R-18 again to confirm) 

*** Once again Tx is interrupted by UDP as the log backup is still in progress***          

 

From JTDX:

Halt Tx triggered at TX: UDP request 50.313 MHz  FT8:  8P2K G0TSM RR73        

 

Is there a way around this besides manually logging the QSO as I like to auto-backup every 10 QSOs?

 

Thank You and 73, Darren G0TSM

 


Bob
 

You said ... So Logger32 is turning off cherry picking (even when it was already off) and halting the RR73 Tx when the auto-backup starts? I don't think so. If the cherry-picker is already off, Logger32 does not send any message to JTDX when you open the Backup window.  Easy to test, reduce your output power to zero. Double click on JTDX somewhere, no open one of the backup windows ... You will notice JTDX diligently continues to call the station you double clicked on. In the case of the cherry-picker being on, any/all messages from Logger32 are shown on the cherry-picker event viewer. SeventyThree(s).

On 06/23/2021 10:53 AM Darren Collins (G0TSM) <daz@...> wrote:
 
 

Hello Bob, thanks for replying.

Yes I can understand why you wouldn’t want to try and add more QSOs into the log why it’s being backed up. My log of 85K QSOs only takes 4 secs to backup whereas there will be a longer delay with bigger logs and/or slower hardware (Mine is a nerd spec PC).

 

I can see that Cherry picking is turned off when the backup window is opened but in my case I am not cherry picking but manually making QSOs by clicking in JTDX then logging into Logger32 via UDP. So Logger32 is turning off cherry picking (even when it was already off) and halting the RR73 Tx when the auto-backup starts?

I note that if you are CQing in JTDX that opening the backup window does not halt the transmission, but exiting the backup window after the backup has been completed enables cherry picking, even if you didn’t want it on,  and halts the Tx.

 

Also syncing LOTW from an ADIF file enables cherry picking when it’s complete, even if it was off before…

 

For now I have changed the backup schedule to 50 QSOs.

 

73 and Thank You, Darren G0TSM

 

 

 

 

From: hamlogger@groups.io <hamlogger@groups.io> On Behalf Of Bob
Sent: 22 June 2021 22:13
To: hamlogger@groups.io
Subject: Re: [hamlogger] JTDX/FT8 RR73 Transmission halted by UDP

 

It is a VERY bad idea to attempt a logbook backup while the cherry-picker is actively in contact. Manual QSOs (FT4/8, SSB, CW) is no problem as you're not actually taking CPU cycles away from anything important, or anything that relies on critical timing. I'd suggest (if you have the insatiable urge to backup every QSO), you turn off automatic backups, and manually backup in periods when/where the cotton-picking little cherry-picker is inactive. 

SeventyThree(s).

 

PS. There is no cherry-picker event viewer message "Tx is interrupted by UDP".

On 06/22/2021 4:52 PM Darren Collins (G0TSM) <daz@...> wrote:

 

 

Hi Bob and friends.,

When I'm running FT8 in JTDX I quite often see that UDP halts my TX when I'm sending RR73. This coincides with auto-logging the QSO and then Logger32 backing up the log.. If I set the log backup to 1 (backup after every QSO) then the Tx is halted every time the RR73 is sent and the QSO is logged and backed up. The workaround of course is to set 'do not backup current log book after QSOs' and then the tx is never halted.

 

Typical scenario

 

CQ 8P2K GK03

 

8P2K G0TSM -18 (I've double clicked on 8P2K and I'm sending his report)            

 

G0TSM 8P2K R-18 (He's confirming with my report - exciting stuff!)          •

 

8P2K G0TSM RR73 (My JTDX is replying to confirm and log the QSO and then backup starts) and Logger32 tells JTDX to stop transmitting.

*** Tx is interrupted by UDP ***           

 

8P2K G0TSM RR73 (I double click on his R-18 again to confirm) 

*** Once again Tx is interrupted by UDP as the log backup is still in progress***          

 

From JTDX:

Halt Tx triggered at TX: UDP request 50.313 MHz  FT8:  8P2K G0TSM RR73        

 

Is there a way around this besides manually logging the QSO as I like to auto-backup every 10 QSOs?

 

Thank You and 73, Darren G0TSM

 

 


Darren Collins (G0TSM)
 

Hello Bob, I’ve figured it out…

It’s the auto-turning on of the cherry picker which is the problem.

 

When my JTDX is sending the RR73, the QSO is logged into Logger32 and depending on the schedule the log may or may not be backed up.

If the log is backed up as soon as the backup process is complete then cherry picking is automatically turned on, which halts my Tx.

 

So even is cherry picking is off:

Completing the backup turns it on.

Syncing LOTW from an ADIF file turns it on.

Zipping user files turns it on.

 

 

This is what Logger32 sends to JTDX when the backup finishes:

 

16:30:51 Sent Tx Halt message to JTDX

 

16:30:51 Cherry-picking turned on

16:30:51 JTDX TxEnable off

16:30:51 JTDX Transmit off

16:30:59 JTDX Decoding on

 

 

73 Darren G0TSM

 

 

 

From: hamlogger@groups.io <hamlogger@groups.io> On Behalf Of Bob
Sent: 23 June 2021 16:14
To: hamlogger@groups.io
Subject: Re: [hamlogger] JTDX/FT8 RR73 Transmission halted by UDP

 

You said ... So Logger32 is turning off cherry picking (even when it was already off) and halting the RR73 Tx when the auto-backup starts? I don't think so. If the cherry-picker is already off, Logger32 does not send any message to JTDX when you open the Backup window.  Easy to test, reduce your output power to zero. Double click on JTDX somewhere, no open one of the backup windows ... You will notice JTDX diligently continues to call the station you double clicked on. In the case of the cherry-picker being on, any/all messages from Logger32 are shown on the cherry-picker event viewer. SeventyThree(s).

On 06/23/2021 10:53 AM Darren Collins (G0TSM) <daz@...> wrote:

 

 

Hello Bob, thanks for replying.

Yes I can understand why you wouldn’t want to try and add more QSOs into the log why it’s being backed up. My log of 85K QSOs only takes 4 secs to backup whereas there will be a longer delay with bigger logs and/or slower hardware (Mine is a nerd spec PC).

 

I can see that Cherry picking is turned off when the backup window is opened but in my case I am not cherry picking but manually making QSOs by clicking in JTDX then logging into Logger32 via UDP. So Logger32 is turning off cherry picking (even when it was already off) and halting the RR73 Tx when the auto-backup starts?

I note that if you are CQing in JTDX that opening the backup window does not halt the transmission, but exiting the backup window after the backup has been completed enables cherry picking, even if you didn’t want it on,  and halts the Tx.

 

Also syncing LOTW from an ADIF file enables cherry picking when it’s complete, even if it was off before…

 

For now I have changed the backup schedule to 50 QSOs.

 

73 and Thank You, Darren G0TSM

 

 

 

 

From: hamlogger@groups.io <hamlogger@groups.io> On Behalf Of Bob
Sent: 22 June 2021 22:13
To: hamlogger@groups.io
Subject: Re: [hamlogger] JTDX/FT8 RR73 Transmission halted by UDP

 

It is a VERY bad idea to attempt a logbook backup while the cherry-picker is actively in contact. Manual QSOs (FT4/8, SSB, CW) is no problem as you're not actually taking CPU cycles away from anything important, or anything that relies on critical timing. I'd suggest (if you have the insatiable urge to backup every QSO), you turn off automatic backups, and manually backup in periods when/where the cotton-picking little cherry-picker is inactive. 

SeventyThree(s).

 

PS. There is no cherry-picker event viewer message "Tx is interrupted by UDP".

On 06/22/2021 4:52 PM Darren Collins (G0TSM) <daz@...> wrote:

 

 

Hi Bob and friends.,

When I'm running FT8 in JTDX I quite often see that UDP halts my TX when I'm sending RR73. This coincides with auto-logging the QSO and then Logger32 backing up the log.. If I set the log backup to 1 (backup after every QSO) then the Tx is halted every time the RR73 is sent and the QSO is logged and backed up. The workaround of course is to set 'do not backup current log book after QSOs' and then the tx is never halted.

 

Typical scenario

 

CQ 8P2K GK03

 

8P2K G0TSM -18 (I've double clicked on 8P2K and I'm sending his report)            

 

G0TSM 8P2K R-18 (He's confirming with my report - exciting stuff!)          •

 

8P2K G0TSM RR73 (My JTDX is replying to confirm and log the QSO and then backup starts) and Logger32 tells JTDX to stop transmitting.

*** Tx is interrupted by UDP ***           

 

8P2K G0TSM RR73 (I double click on his R-18 again to confirm) 

*** Once again Tx is interrupted by UDP as the log backup is still in progress***          

 

From JTDX:

Halt Tx triggered at TX: UDP request 50.313 MHz  FT8:  8P2K G0TSM RR73        

 

Is there a way around this besides manually logging the QSO as I like to auto-backup every 10 QSOs?

 

Thank You and 73, Darren G0TSM

 

 


Bob
 

It is all changed for the next update. Atoatic backup is turned off if cherry-picking is on. 73.

On 06/23/2021 12:34 PM Darren Collins (G0TSM) <daz@...> wrote:
 
 

Hello Bob, I’ve figured it out…

It’s the auto-turning on of the cherry picker which is the problem.

 

When my JTDX is sending the RR73, the QSO is logged into Logger32 and depending on the schedule the log may or may not be backed up.

If the log is backed up as soon as the backup process is complete then cherry picking is automatically turned on, which halts my Tx.

 

So even is cherry picking is off:

Completing the backup turns it on.

Syncing LOTW from an ADIF file turns it on.

Zipping user files turns it on.

 

 

This is what Logger32 sends to JTDX when the backup finishes:

 

16:30:51 Sent Tx Halt message to JTDX

 

16:30:51 Cherry-picking turned on

16:30:51 JTDX TxEnable off

16:30:51 JTDX Transmit off

16:30:59 JTDX Decoding on

 

 

73 Darren G0TSM

 

 

 

From: hamlogger@groups.io <hamlogger@groups.io> On Behalf Of Bob
Sent: 23 June 2021 16:14
To: hamlogger@groups.io
Subject: Re: [hamlogger] JTDX/FT8 RR73 Transmission halted by UDP

 

You said ... So Logger32 is turning off cherry picking (even when it was already off) and halting the RR73 Tx when the auto-backup starts? I don't think so. If the cherry-picker is already off, Logger32 does not send any message to JTDX when you open the Backup window.  Easy to test, reduce your output power to zero. Double click on JTDX somewhere, no open one of the backup windows ... You will notice JTDX diligently continues to call the station you double clicked on. In the case of the cherry-picker being on, any/all messages from Logger32 are shown on the cherry-picker event viewer. SeventyThree(s).

On 06/23/2021 10:53 AM Darren Collins (G0TSM) <daz@...> wrote:

 

 

Hello Bob, thanks for replying.

Yes I can understand why you wouldn’t want to try and add more QSOs into the log why it’s being backed up. My log of 85K QSOs only takes 4 secs to backup whereas there will be a longer delay with bigger logs and/or slower hardware (Mine is a nerd spec PC).

 

I can see that Cherry picking is turned off when the backup window is opened but in my case I am not cherry picking but manually making QSOs by clicking in JTDX then logging into Logger32 via UDP. So Logger32 is turning off cherry picking (even when it was already off) and halting the RR73 Tx when the auto-backup starts?

I note that if you are CQing in JTDX that opening the backup window does not halt the transmission, but exiting the backup window after the backup has been completed enables cherry picking, even if you didn’t want it on,  and halts the Tx.

 

Also syncing LOTW from an ADIF file enables cherry picking when it’s complete, even if it was off before…

 

For now I have changed the backup schedule to 50 QSOs.

 

73 and Thank You, Darren G0TSM

 

 

 

 

From: hamlogger@groups.io <hamlogger@groups.io> On Behalf Of Bob
Sent: 22 June 2021 22:13
To: hamlogger@groups.io
Subject: Re: [hamlogger] JTDX/FT8 RR73 Transmission halted by UDP

 

It is a VERY bad idea to attempt a logbook backup while the cherry-picker is actively in contact. Manual QSOs (FT4/8, SSB, CW) is no problem as you're not actually taking CPU cycles away from anything important, or anything that relies on critical timing. I'd suggest (if you have the insatiable urge to backup every QSO), you turn off automatic backups, and manually backup in periods when/where the cotton-picking little cherry-picker is inactive. 

SeventyThree(s).

 

PS. There is no cherry-picker event viewer message "Tx is interrupted by UDP".

On 06/22/2021 4:52 PM Darren Collins (G0TSM) <daz@...> wrote:

 

 

Hi Bob and friends.,

When I'm running FT8 in JTDX I quite often see that UDP halts my TX when I'm sending RR73. This coincides with auto-logging the QSO and then Logger32 backing up the log.. If I set the log backup to 1 (backup after every QSO) then the Tx is halted every time the RR73 is sent and the QSO is logged and backed up. The workaround of course is to set 'do not backup current log book after QSOs' and then the tx is never halted.

 

Typical scenario

 

CQ 8P2K GK03

 

8P2K G0TSM -18 (I've double clicked on 8P2K and I'm sending his report)            

 

G0TSM 8P2K R-18 (He's confirming with my report - exciting stuff!)          •

 

8P2K G0TSM RR73 (My JTDX is replying to confirm and log the QSO and then backup starts) and Logger32 tells JTDX to stop transmitting.

*** Tx is interrupted by UDP ***           

 

8P2K G0TSM RR73 (I double click on his R-18 again to confirm) 

*** Once again Tx is interrupted by UDP as the log backup is still in progress***          

 

From JTDX:

Halt Tx triggered at TX: UDP request 50.313 MHz  FT8:  8P2K G0TSM RR73        

 

Is there a way around this besides manually logging the QSO as I like to auto-backup every 10 QSOs?

 

Thank You and 73, Darren G0TSM

 

 

 


Darren Collins (G0TSM)
 

Bob, could you change it so that if cherry picking is off it stays off, but if its on its switches off and then back on again after the backup or sync?

 

Thank You, 73 Darren G0TSM

 

From: hamlogger@groups.io <hamlogger@groups.io> On Behalf Of Bob
Sent: 23 June 2021 17:38
To: hamlogger@groups.io
Subject: Re: [hamlogger] JTDX/FT8 RR73 Transmission halted by UDP

 

It is all changed for the next update. Atoatic backup is turned off if cherry-picking is on. 73.

On 06/23/2021 12:34 PM Darren Collins (G0TSM) <daz@...> wrote:

 

 

Hello Bob, I’ve figured it out…

It’s the auto-turning on of the cherry picker which is the problem.

 

When my JTDX is sending the RR73, the QSO is logged into Logger32 and depending on the schedule the log may or may not be backed up.

If the log is backed up as soon as the backup process is complete then cherry picking is automatically turned on, which halts my Tx.

 

So even is cherry picking is off:

Completing the backup turns it on.

Syncing LOTW from an ADIF file turns it on.

Zipping user files turns it on.

 

 

This is what Logger32 sends to JTDX when the backup finishes:

 

16:30:51 Sent Tx Halt message to JTDX

 

16:30:51 Cherry-picking turned on

16:30:51 JTDX TxEnable off

16:30:51 JTDX Transmit off

16:30:59 JTDX Decoding on

 

 

73 Darren G0TSM

 

 

 

From: hamlogger@groups.io <hamlogger@groups.io> On Behalf Of Bob
Sent: 23 June 2021 16:14
To: hamlogger@groups.io
Subject: Re: [hamlogger] JTDX/FT8 RR73 Transmission halted by UDP

 

You said ... So Logger32 is turning off cherry picking (even when it was already off) and halting the RR73 Tx when the auto-backup starts? I don't think so. If the cherry-picker is already off, Logger32 does not send any message to JTDX when you open the Backup window.  Easy to test, reduce your output power to zero. Double click on JTDX somewhere, no open one of the backup windows ... You will notice JTDX diligently continues to call the station you double clicked on. In the case of the cherry-picker being on, any/all messages from Logger32 are shown on the cherry-picker event viewer. SeventyThree(s).

On 06/23/2021 10:53 AM Darren Collins (G0TSM) <daz@...> wrote:

 

 

Hello Bob, thanks for replying.

Yes I can understand why you wouldn’t want to try and add more QSOs into the log why it’s being backed up. My log of 85K QSOs only takes 4 secs to backup whereas there will be a longer delay with bigger logs and/or slower hardware (Mine is a nerd spec PC).

 

I can see that Cherry picking is turned off when the backup window is opened but in my case I am not cherry picking but manually making QSOs by clicking in JTDX then logging into Logger32 via UDP. So Logger32 is turning off cherry picking (even when it was already off) and halting the RR73 Tx when the auto-backup starts?

I note that if you are CQing in JTDX that opening the backup window does not halt the transmission, but exiting the backup window after the backup has been completed enables cherry picking, even if you didn’t want it on,  and halts the Tx.

 

Also syncing LOTW from an ADIF file enables cherry picking when it’s complete, even if it was off before…

 

For now I have changed the backup schedule to 50 QSOs.

 

73 and Thank You, Darren G0TSM

 

 

 

 

From: hamlogger@groups.io <hamlogger@groups.io> On Behalf Of Bob
Sent: 22 June 2021 22:13
To: hamlogger@groups.io
Subject: Re: [hamlogger] JTDX/FT8 RR73 Transmission halted by UDP

 

It is a VERY bad idea to attempt a logbook backup while the cherry-picker is actively in contact. Manual QSOs (FT4/8, SSB, CW) is no problem as you're not actually taking CPU cycles away from anything important, or anything that relies on critical timing. I'd suggest (if you have the insatiable urge to backup every QSO), you turn off automatic backups, and manually backup in periods when/where the cotton-picking little cherry-picker is inactive. 

SeventyThree(s).

 

PS. There is no cherry-picker event viewer message "Tx is interrupted by UDP".

On 06/22/2021 4:52 PM Darren Collins (G0TSM) <daz@...> wrote:

 

 

Hi Bob and friends.,

When I'm running FT8 in JTDX I quite often see that UDP halts my TX when I'm sending RR73. This coincides with auto-logging the QSO and then Logger32 backing up the log.. If I set the log backup to 1 (backup after every QSO) then the Tx is halted every time the RR73 is sent and the QSO is logged and backed up. The workaround of course is to set 'do not backup current log book after QSOs' and then the tx is never halted.

 

Typical scenario

 

CQ 8P2K GK03

 

8P2K G0TSM -18 (I've double clicked on 8P2K and I'm sending his report)            

 

G0TSM 8P2K R-18 (He's confirming with my report - exciting stuff!)          •

 

8P2K G0TSM RR73 (My JTDX is replying to confirm and log the QSO and then backup starts) and Logger32 tells JTDX to stop transmitting.

*** Tx is interrupted by UDP ***           

 

8P2K G0TSM RR73 (I double click on his R-18 again to confirm) 

*** Once again Tx is interrupted by UDP as the log backup is still in progress***          

 

From JTDX:

Halt Tx triggered at TX: UDP request 50.313 MHz  FT8:  8P2K G0TSM RR73        

 

Is there a way around this besides manually logging the QSO as I like to auto-backup every 10 QSOs?

 

Thank You and 73, Darren G0TSM