Date   

Re: DXK Update To 16.1.0. Issue

Dave AA6YQ
 

+ AA6YQ comments below

-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Bud Governale
Sent: Friday, April 30, 2021 10:52 AM
To: DXLab@groups.io
Subject: [DXLab] DXK Update To 16.1.0. Issue

Did the update to DXK to 16.1.0. last week

It then developed issues on opening:

"This log requires significant updating:should a backup be created beforehand? Yes No"

"unable to open QSL Queue table:
c:\dxlab\dxkeeper\databases\w3ll.mdb

"unable to opendatabase:c:\dxlab\dxkeeper\dxdatabasees\w3ll.mdb"

I have a complete adi logfile to replace it with but can't.

+ Please place the file

c:\dxlab\dxkeeper\databases\w3ll.mdb

+ in a zip archive, attach the zip archive to an email message, and send the message to me via

aa6yq (at) ambersoft.com

73,

Dave, AA6YQ


DXK Update To 16.1.0. Issue

Bud Governale
 

Did the update to DXK to 16.1.0. last week 
 
It then developed issues on opening:
 
"This log requires significant updating:should a backup be created beforehand? Yes No"
 
"unable to open QSL Queue table:
c:\dxlab\dxkeeper\databases\w3ll.mdb
 
"unable to opendatabase:c:\dxlab\dxkeeper\dxdatabasees\w3ll.mdb"
 
I have a complete adi logfile to replace it with but can't.

73,
 
Bud W3LL
W3LL@...


Re: UDP Network Service error message has wrong reference indicator.

Dave AA6YQ
 

Congrats on 5BDXCC !!!

73,

Dave, AA6YQ

-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Jon Gefaell
Sent: Thursday, April 29, 2021 8:28 PM
To: DXLab@groups.io
Subject: Re: [DXLab] UDP Network Service error message has wrong reference indicator.

Ooops! I meant to have typed Commander, of course. Thank you sir!

By the way, I completed 5 band DXCC last week. DXL has been at my side since 2013 and though I couldn't have done it without, I've only begun to scratch the surface. Thanks for having us in your shack, and letting us use your tools!

Very 73, from K6OJ.

On Thu, Apr 29, 2021 at 05:06 PM, Dave AA6YQ wrote:


+ Thanks, Jon. I see that defective behavior in Commander, and have corrected it in the next version. DXKeeper only provides one address/port setting pair.




________________________________

AVG logo <https://www.avg.com/internet-security> This email has been checked for viruses by AVG antivirus software.
www.avg.com <https://www.avg.com/internet-security>


Re: UDP Network Service error message has wrong reference indicator.

Jon Gefaell
 

Ooops! I meant to have typed Commander, of course. Thank you sir!

By the way, I completed 5 band DXCC last week. DXL has been at my side since 2013 and though I couldn't have done it without, I've only begun to scratch the surface. Thanks for having us in your shack, and letting us use your tools!

Very 73, from K6OJ. 


On Thu, Apr 29, 2021 at 05:06 PM, Dave AA6YQ wrote:
+ Thanks, Jon. I see that defective behavior in Commander, and have corrected it in the next version. DXKeeper only provides one address/port setting pair.


Re: UDP Network Service error message has wrong reference indicator.

Dave AA6YQ
 

+ AA6YQ comments below

In DXK Network Service configuration, UDP Network Service.

If you enter invalid values, you receive a popup message with a UDP # one less than the one you are setting.

That is, if you enter 0.0.0.0 and 12065 in the third field pair in the dialog, marked UDP #3 the effort message will indicate UDP #2.

+ Thanks, Jon. I see that defective behavior in Commander, and have corrected it in the next version. DXKeeper only provides one address/port setting pair.

73,

Dave, AA6YQ


UDP Network Service error message has wrong reference indicator.

Jon Gefaell
 

In DXK Network Service configuration, UDP Network Service. 

If you enter invalid values, you receive a popup message with a  UDP # one less than the one you are setting.

That is, if you enter 0.0.0.0 and 12065 in the third field pair in the dialog, marked UDP #3 the effort message will indicate UDP #2.

Severity lowest, priority lower. ;) 


Re: TS590SG

Jamie WW3S
 

Lol, we must have both hit send at the same time!! Now i need to figure out if inwant the latest JT Alert


On Apr 29, 2021, at 5:27 PM, Dave AA6YQ <aa6yq@...> wrote:



Thanks for the WSJT-X screen shots, Jamie.

 

When Commander is controlling your control your TS-590, use the "DTS transmission using  ANI input" setting on the General tab of Commander's Configuration window to select the transmit audio source. Enable this option to use audio from the TS-590's backpanel ANI input instead of its front MIC input.

This is step 3 in

 

https://www.dxlabsuite.com/dxlabwiki/TranceiverControlKenwood

 

       73,

 

              Dave, AA6YQ


Re: Serial Port RTS Error upon startup Commander

Dave AA6YQ
 

+ AA6YQ comments below

Sorry for not responding earlier, wanted first to sit behind the radios and run few scenarios

This only happens with the Yaesu and Kenwood radios.

The Icom (Via MK3) does not do it. In another word, i can start commander, with the Icom radio already preselected, while the Icom radio is off, and not get the warning message.

If i do the same as above with the Yaesu (Via MK2) or Kenwood (Direct) , while the appropriate radio is preselected in Commander. I get the warning if the radio is off when i launch Commander, i don't get the warning if the radio is on when i launch commander

I have both Yaesu and Icom with RTS selected as "X" and hey work fine

For the Kenwood, i have to have "RTS" set as yes for commander to communicate with it

Now you may ask why do you start Commander before you start the radio, which can be an easy fix by reversing the sequence. The problem is that one radio may had been selected when i terminated Commander last time, and next time i want to operate this will happen if i choose to turn on a different radio than preselected or if i plain forgot (happens alot) what last radio i used and turn on a different radio, either case will trigger this issue and i have no precautions

Its really not a huge issue except that its annoying, plus as i mentioned before if i accidently click "yes" i will usually spend the next hour chasing my tail and spinning my wheels trying to figure out why the radio is stuck in TX or some weird behavior like that till i remember to go to Config and revert to "X"

+ Thanks, Saad.

+ So the scenario is

1. You're using a radio that when directly connected requires RTS to be set to 'On'

+ but

2. You're using an interface that require RTS to not be set to 'On'

+ and

3. You sometimes direct Commander to select that radio while that radio is not powered on

+ so

4. After 5 seconds, Commander notices that it has not received any data from the radio and displays a warning noting that RTS is not set to "On" and asking if you want it enabled

+ but

5. You sometimes erroneously click "Yes", which when you power up the radio puts it in "transmit" mode until you set the RTS Selector to "TX"


+ I have sent you a new version of Commander that in the above scenario will only display the warning if RTS is set to "Off". Since you have RTS set to "TX", the warning will not appear in step 4. This preserves the warning for new users who have left the RTS selector in its default state of "Off".

73,

Dave, AA6YQ


Re: TS590SG

Dave AA6YQ
 

Thanks for the WSJT-X screen shots, Jamie.

 

When Commander is controlling your control your TS-590, use the "DTS transmission using  ANI input" setting on the General tab of Commander's Configuration window to select the transmit audio source. Enable this option to use audio from the TS-590's backpanel ANI input instead of its front MIC input.

This is step 3 in

 

https://www.dxlabsuite.com/dxlabwiki/TranceiverControlKenwood

 

       73,

 

              Dave, AA6YQ


Re: wsjt with TS590SG

Jamie WW3S
 

I found my error Dave......in Commander, on the General tab, I had to check the Data transmission from USB box......

73

------ Original Message ------
From: "Dave AA6YQ" <aa6yq@ambersoft.com>
To: DXLab@groups.io
Sent: 4/29/2021 3:18:02 PM
Subject: Re: [DXLab] wsjt with TS590SG

+ AA6YQ comments below

trying to get wsjt working with dxlabs and the latest addition to my shack, a TS590SG.....Commander works fine with the rig, and WSJT works fine, with the rig, if I configure WSJT to use the rig....my problem comes when I go to configure WSJT to use DX commander as the transmitter.....when I do, the transmit audio source is greyd out, and I have no transmit audio (rx is fine), if I simply change WSJT to use the Kenwood cat instead of commander, it all works.....somehow, when Commander is chosen, I'm not getting the transmit audio to the rigs codec via USB.....any thoughts?

+ On what panel of what window of what application is "the transmit audio source is greyed out" ?

Is there a way to log to DXkeeper without using Commander as the rig control?

+ When WSTJ-X logs a QSO to DXKeeper by way of SpotCollector or JT-Alert, the ADIF record it sends includes the correct transceiver frequency, by whatever means WSJT-X acquired it. However, if WSJT-X is using something other than Commander for transceiver control, then Commander cannot be connected to your transceiver -- so none of the other DXLab applications will be aware of your transceiver's frequency. To accurately log a CW or SSB QSO, you'd have to first terminate WSJT-X, and then enable Commander to control your radio.

73,

Dave, AA6YQ






Re: wsjt with TS590SG

Dave AA6YQ
 

+ AA6YQ comments below

trying to get wsjt working with dxlabs and the latest addition to my shack, a TS590SG.....Commander works fine with the rig, and WSJT works fine, with the rig, if I configure WSJT to use the rig....my problem comes when I go to configure WSJT to use DX commander as the transmitter.....when I do, the transmit audio source is greyd out, and I have no transmit audio (rx is fine), if I simply change WSJT to use the Kenwood cat instead of commander, it all works.....somehow, when Commander is chosen, I'm not getting the transmit audio to the rigs codec via USB.....any thoughts?

+ On what panel of what window of what application is "the transmit audio source is greyed out" ?

Is there a way to log to DXkeeper without using Commander as the rig control?

+ When WSTJ-X logs a QSO to DXKeeper by way of SpotCollector or JT-Alert, the ADIF record it sends includes the correct transceiver frequency, by whatever means WSJT-X acquired it. However, if WSJT-X is using something other than Commander for transceiver control, then Commander cannot be connected to your transceiver -- so none of the other DXLab applications will be aware of your transceiver's frequency. To accurately log a CW or SSB QSO, you'd have to first terminate WSJT-X, and then enable Commander to control your radio.

73,

Dave, AA6YQ


Re: Serial Port RTS Error upon startup Commander

Saad Mahaini
 

Hi Dave

Sorry for not responding earlier, wanted first to sit behind the radios and run few scenarios

This only happens with the Yaesu and Kenwood radios.  

The Icom (Via MK3) does not do it.  In another word, i can start commander, with the Icom radio already preselected,  while the Icom radio is off, and not get the warning message.

If i do the same as above with the Yaesu (Via MK2) or Kenwood (Direct) , while the appropriate radio is preselected in Commander.  I get the warning if the radio is off when i launch Commander, i don't get the warning if the radio is on when i launch commander

 I have both Yaesu and Icom with RTS selected as "X" and hey work fine

For the Kenwood, i have to have "RTS" set as yes for commander to communicate with it

Now you may ask why do you start Commander before you start the radio, which can be an easy fix by reversing the sequence.  The problem is that one radio may had been selected when i terminated Commander last time, and next time i want to operate this will happen if i choose to turn on a different radio than preselected or if i plain forgot (happens alot)  what last radio i used and turn on a different radio, either case will trigger this issue and i have no precautions 

Its really not a huge issue except that its annoying, plus as i mentioned before if i accidently click "yes" i will usually spend the next hour chasing my tail and spinning my wheels trying to figure out why the radio is stuck in TX or some weird behavior like that till i remember to go to Config and revert to "X"

 Thanks again for all your help

73 Saad N5FF



On Thursday, April 29, 2021, 05:26:03 AM CDT, g4wjs <bill.8@...> wrote:


On 29/04/2021 04:39, Dave AA6YQ wrote:
@ more AA6YQ comments below

+ Joe, is there a way that Commander can determine that a microHam 
 > "RTS must be N" interface is involved?

It's not "RTS must be N".  It can be anything but typically RTS=Y
will lock the rig in transmit if the user is using RTS for PTT and
RTS=HANDSHAKE will lock up CAT software expecting a response on
CTS.

All of the microHAM "keyer" interfaces (CW Keyer, DigiKeyer, DigiKeyer
II, microKEYER, microKEYER II, microKEYER III, MK2R+) *require* hardware
PTT in order to perform sound card/mic audio switching and/or provide
(timed) PTT to an amplifier.

If the owner has enabled a "control" port in microHAM USB Device Router
Commander can poll that port (Ports -> SO2R Serial  Port) using the
microHAM Control Protocol. The VS; command will identify the device in
the first two characters following the VS in the response.  *HOWEVER*
the microHAM Control Protocol is not applicable to USB Interface II,
USB Interface III or DXP.

In addition, polling for a microHAM interface does not resolve the issue
with the hundreds of other CT/NA compatible interfaces (including MFJ!
and some Rigblaster models).

@ Thanks, Joe. Doing something interface-specific doesn't appear feasible.

@ I should have noted that Commander only displays the warning message if

1. the radio is a Kenwood or Yaesu that requires RTS to be asserted

@ and

2. Commander's RTS selector is not set to "On"

@ and

3. Commander doesn't receive CAT data from the Primary CAT port for 5 seconds after the radio is selected as the primary transceiver

@ It's the third requirement that has prevented an avalanche of microHam interface users from complaining about the warning message.

@ Saad, why would your primary transceiver not respond within 5 seconds of being selected?

       73,

             Dave, AA6YQ

Hi Dave,

I think Saad answered your last question in his OP, i.e. the rig may be turned off. How about a pop up question if your conditions above would lead to an error message, when multiple rigs are configured, that offers to switch to a different configured rig. While that blocks the user can decide which rig to turn on.


--
73

Bill

G4WJS.


wsjt with TS590SG

Jamie WW3S
 

trying to get wsjt working with dxlabs and the latest addition to my shack, a TS590SG.....Commander works fine with the rig, and WSJT works fine, with the rig, if I configure WSJT to use the rig....my problem comes when I go to configure WSJT to use DX commander as the transmitter.....when I do, the transmit audio source is greyd out, and I have no transmit audio (rx is fine), if I simply change WSJT to use the Kenwood cat instead of commander, it all works.....somehow, when Commander is chosen, I'm not getting the transmit audio to the rigs codec via USB.....any thoughts? Is there a way to log to DXkeeper without using Commander as the rig control? 


Re: eQSL support for the new submodes introduced in ADIF 3.1.2

Jay KA9CFD
 

Thank you Dave. All of my Q65 contacts uploaded successfully.

Jay KA9CFD


Re: Serial Port RTS Error upon startup Commander

g4wjs
 

On 29/04/2021 04:39, Dave AA6YQ wrote:
@ more AA6YQ comments below

+ Joe, is there a way that Commander can determine that a microHam 
 > "RTS must be N" interface is involved?

It's not "RTS must be N".  It can be anything but typically RTS=Y
will lock the rig in transmit if the user is using RTS for PTT and
RTS=HANDSHAKE will lock up CAT software expecting a response on
CTS.

All of the microHAM "keyer" interfaces (CW Keyer, DigiKeyer, DigiKeyer
II, microKEYER, microKEYER II, microKEYER III, MK2R+) *require* hardware
PTT in order to perform sound card/mic audio switching and/or provide
(timed) PTT to an amplifier.

If the owner has enabled a "control" port in microHAM USB Device Router
Commander can poll that port (Ports -> SO2R Serial  Port) using the
microHAM Control Protocol. The VS; command will identify the device in
the first two characters following the VS in the response.  *HOWEVER*
the microHAM Control Protocol is not applicable to USB Interface II,
USB Interface III or DXP.

In addition, polling for a microHAM interface does not resolve the issue
with the hundreds of other CT/NA compatible interfaces (including MFJ!
and some Rigblaster models).

@ Thanks, Joe. Doing something interface-specific doesn't appear feasible.

@ I should have noted that Commander only displays the warning message if

1. the radio is a Kenwood or Yaesu that requires RTS to be asserted

@ and

2. Commander's RTS selector is not set to "On"

@ and

3. Commander doesn't receive CAT data from the Primary CAT port for 5 seconds after the radio is selected as the primary transceiver

@ It's the third requirement that has prevented an avalanche of microHam interface users from complaining about the warning message.

@ Saad, why would your primary transceiver not respond within 5 seconds of being selected?

       73,

             Dave, AA6YQ

Hi Dave,

I think Saad answered your last question in his OP, i.e. the rig may be turned off. How about a pop up question if your conditions above would lead to an error message, when multiple rigs are configured, that offers to switch to a different configured rig. While that blocks the user can decide which rig to turn on.


--
73

Bill

G4WJS.


Re: Filtering SC for special callsigns by mode

Dave AA6YQ
 

# More AA6YQ comments bewlo
+ AA6YQ comments below

The current CWops roster has just under 2500 calls, although a few of them are duplicates as some members have more than one call.

+ Thanks. I suspect that's too many for a simple filter like

(MODE='CW') and (CALLSIGN in ('VK9NS', 'OH2BH','P5DX', ....))

+ which you would edit each time you log a QSO with a CWOPs member.

# You could use this SQL expression

((TAGS like '*<cwops>*') and (MODE='CW'))

# if after logging a CW QSO with a cwops station whose callsign is X, you were willing to immediately edit SpotCollector's Special Callsign List entry for X to change its tag from cwops to workedcwops.

   73,

         Dave, AA6YQ

 

 


Re: Serial Port RTS Error upon startup Commander

Dave AA6YQ
 

@ more AA6YQ comments below

+ Joe, is there a way that Commander can determine that a microHam
> "RTS must be N" interface is involved?

It's not "RTS must be N". It can be anything but typically RTS=Y
will lock the rig in transmit if the user is using RTS for PTT and
RTS=HANDSHAKE will lock up CAT software expecting a response on
CTS.

All of the microHAM "keyer" interfaces (CW Keyer, DigiKeyer, DigiKeyer
II, microKEYER, microKEYER II, microKEYER III, MK2R+) *require* hardware
PTT in order to perform sound card/mic audio switching and/or provide
(timed) PTT to an amplifier.

If the owner has enabled a "control" port in microHAM USB Device Router
Commander can poll that port (Ports -> SO2R Serial Port) using the
microHAM Control Protocol. The VS; command will identify the device in
the first two characters following the VS in the response. *HOWEVER*
the microHAM Control Protocol is not applicable to USB Interface II,
USB Interface III or DXP.

In addition, polling for a microHAM interface does not resolve the issue
with the hundreds of other CT/NA compatible interfaces (including MFJ!
and some Rigblaster models).

@ Thanks, Joe. Doing something interface-specific doesn't appear feasible.

@ I should have noted that Commander only displays the warning message if

1. the radio is a Kenwood or Yaesu that requires RTS to be asserted

@ and

2. Commander's RTS selector is not set to "On"

@ and

3. Commander doesn't receive CAT data from the Primary CAT port for 5 seconds after the radio is selected as the primary transceiver

@ It's the third requirement that has prevented an avalanche of microHam interface users from complaining about the warning message.

@ Saad, why would your primary transceiver not respond within 5 seconds of being selected?

73,

Dave, AA6YQ


Re: Help with backup suggesiton

Dave AA6YQ
 

+ AA6YQ comments below

Beware of "free" cloud storage.

While I have recently grudgingly moved certain functions of my small E-business (which was a big user of FTP, which none of the main
stream browsers support anymore as of last week ) to Dropbox. Beware that Dropbox and for that matter most cloud storage services
are not free for very long. Dropbox has a number of setup choices that can trap you into using it as a backup for your entire system
( maybe a good idea , maybe not) quickly exceeding the free data storage level. All of these services are targets ( Dropbox had a
large hack a couple of years ago) for Identity theft . They claim they are bullet proof now but caveat emptor.

+ In order to stress-test DXKeeper, I created a log file containing 1 million QSOs. It is 1 gigabyte in size.

+ A free DropBox account provides 2 gigabytes of storage:

https://www.dropbox.com/basic

+ Microsoft OneDrive provides 5 gigabytes of free storage.

+ Every Google Account starts with 15 gigabytges of free storage that's shared across Google Drive, Gmail, and Google Photos.

+ The only change I have seen in these free accounts over the past several years is that the amount of storage available has
increased. All provide more than enough storage to backup your log file.

+ To eliminate any exposure to identity theft, specify your callsign as your username, and specify a unique password -- one that
you've not employed for any other online service. If your cloud service provider is hacked and penetrated, no more information can
be released than what is already publicly available via QRZ.com.

73,

Dave, AA6YQ


Re: Filtering SC for special callsigns by mode

Dave AA6YQ
 

+ AA6YQ comments below

The current CWops roster has just under 2500 calls, although a few of them are duplicates as some members have more than one call.

+ Thanks. I suspect that's too many for a simple filter like

(MODE='CW') and (CALLSIGN in ('VK9NS', 'OH2BH','P5DX', ....))

+ which you would edit each time you log a QSO with a CWOPs member.

73,

Dave, AA6YQ


eQSL support for the new submodes introduced in ADIF 3.1.2

Dave AA6YQ
 

Dave N5UP has updated eQSL to accept Q65 and the other new submodes introduced with the recent approval of ADIF 3.1.2. DXKeeper
users can proceed to submit QSOs made with these submodes to eQSL.

Thanks, Dave!

73,

Dave, AA6YQ

3461 - 3480 of 204546