Date   

Re: DXKeeper auto populate

Joe - W9RF
 

Hi Dave,


Well that would be better than what's happening now.

Your suggestion sounds like a reasonable solution.


I thought there was a setting that allowed DXKeeper to be populated with previous qso info or not to be populated but still show previous qso info.

Since I do not subscribe to any callbooks and have primary call book set to none is that why it is auto populating?

Would subscribing to one of the callbooks and clicking the "automatically use callbook data to initialize new QSO's" eliminate my problem?


ie. NOT use old qso info but instead use data found as a new lookup?




73,

W9RF - Joe









On Saturday, March 6, 2021, 11:48:03 PM CST, Dave AA6YQ <aa6yq@...> wrote:


+ AA6YQ comments below

When clicking on a call from Spotcollector or entering a callsign on the main DXKeeper page (new call) the previous qso info is automatically populated in DXKeeper.

This is very problematic when the previous call may have been worked several years in the past.

Even more problematic is entering a special event call, 1X1 calls are very often populated with the incorrect info.


The only way I have found to stop this is the general tab of DXKeeper config, (display previous QSO's on lookup)  but if I uncheck this it will not show any previous qso's.

I need to show the previous qso but NOT to populate the new qso with old info.

+ I can extend DXKeeper so that when you double-click a Spot Database Entry with DXKeeper's "Display previous QSOs on Lookup" option disabled, the callsign will still be placed in DXKeeper's  Filter panel; you can then review previous QSOs with the Entry's Callsign by clicking DXKeeper's  Filter panel's Call button - without information from previous QSOs being used to populate the Capture window.

+ Acceptable?

      73,

                Dave, AA6YQ








Re: Commander with multiple radios

Jim W1RET
 

Thanks Dave.  All good answers.  And binary encoded is no problem.  As long as I know there is something available.

73,

Jim W1RET


2Tone 21.03a

Dave AA6YQ
 

David G3YYD announced 2Tone version 21.03a today. I asked him what changed relative to the 2Tone version 21.02a included with
WinWarbler, here is his response:

-----------------
The Writelog fix and minor changes to the source code - removing old code that is no longer used. I also added the N1MM
documentation that I had left out last time but had intended to add in to make it easier for guys who prefer pictures over words. I
trialled the picture system with some UK amateurs and they found it helpful. However there are words just not as many!

In terms of decode performance no difference.
-----------------

Thus I am not planning to include 2Tone 21.03a in a future version of WinWarbler. If anyone would like access to David's improved
N1MM documentation, it's included in the 21.03a zip archive available here:

https://www.rttycontesting.com/downloads/2tone/

73,

Dave, AA6YQ


Re: Commander with multiple radios

Dave AA6YQ
 

+ AA6YQ comments below

I have, from time to time, connected to 2 radios using Commander. Set-up as multi-radio and it has worked fine. Now I'm attempting to interconnect to 4 radios and as I get this working I've come up with some questions.

First question -- is there any way to connect to more than 4 radios? I suspect no but thought I would ask as I have one more that can be CAT controlled.

+ The limit on primary transceivers is 4.

Second question has to do with user defined controls. Seems to me I have read that as I select from one radio to the next Commander can load the appropriate file for each radio. Is that correct?

+ Yes. See " Setting up User-defined Control Sets" in

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


Third question has to do with selecting the individual radio. Can a command sequence be written so that selecting a function key can select a different radio?

+ Yes. Command sequences can be invoked via the F5 through F12 keys, and a command sequence can use the <priXcvr N> command to select a specific primary transceiver. See "Command Sequences" in

https://www.dxlabsuite.com/commander/Help/CommandSequences.htm#Command%20Sequences


The fourth and final (I hope) question is about some kind of external notification. If I remember correctly there are pins on a parallel connector, if available, that can go active when a particular band is selected. Does a similar function exist when a particular radio is selected?

+ Yes: the selected primary transceiver can optionally be binary encoded on pins 16 and 14 of the specified parallel port. See "Parallel Port panel" in

https://www.dxlabsuite.com/commander/Help/Configuration.htm#Radio%20panel%20parallel%20port


In other words an active pin for radio 1-4?

+ The selection is binary encoded, not unary encoded. You will need some simple decoding logic to derive a signal that's asserted for each primary transceiver. Let me know if you need help with this.

73,

Dave, AA6YQ


Re: QSO start time rounding problem with eQSL

Dave AA6YQ
 

+ AA6YQ comments below

Call sign, band, and mode all match the specified QSO. I am at a loss to find a cause for the error.

+ So that I can see what's going on, please do the following:

1. place your log file (probably KC1BMD.mdb) in a zip archive

2. place the file eQSLInbox.txt (from your DXKeeper folder) in the zip archive you created in step 1

3. attach the zip archive created in step 1 to an email message that specifies the callsign, band, mode, date, and time of the QSO in question

4. send the email message to me via

aa6yq (at) ambersoft.com

73,

Dave, AA6YQ
--


Commander with multiple radios

Jim W1RET
 

I have, from time to time, connected to 2 radios using Commander.  Set-up as multi-radio and it has worked fine.  Now I'm attempting to interconnect to 4 radios and as I get this working I've come up with some questions.

First question -- is there any way to connect to more than 4 radios?  I suspect no but thought I would ask as I have one more that can be CAT controlled.

Second question has to do with user defined controls.  Seems to me I have read that as I select from one radio to the next Commander can load the appropriate file for each radio.  Is that correct?

Third question has to do with selecting the individual radio.  Can a command sequence be written so that selecting a function key can select a different radio?

The fourth and final (I hope) question is about some kind of external notification.  If I remember correctly there are pins on a parallel connector, if available, that can go active when a particular band is selected.  Does a similar function exist when a particular radio is selected?  In other words an active pin for radio 1-4?  I would use this to automatically activate the various ports of my antenna/transceiver switch instead of manual selection.

Thanks in advance and 73.

Jim W1RET


Re: QSO start time rounding problem with eQSL

Norm - KC1BMD
 

Call sign, band, and mode all match the specified QSO. I am at a loss to find a cause for the error.
--
73, Norm/KC1BMD


Re: QSO start time rounding problem with eQSL

Dave AA6YQ
 

+ AA6YQ comments below

eQSL and LotW both accept time mismatches of several minutes; a few seconds is immaterial.

In your first message you quoted a message saying "no QSO matching callsign, band and mode" - if that is an exact quote, then you should be looking at callsign, band and mode. Of these, perhaps the most likely is the mode, especially for digital modes. Note that the ADIF standard for recording digital modes is not always what you might expect (e.g. FT8 is a full mode, whereas FT4 is mode MFSK, submode FT4). Some logging programs don't follow the ADIF standard exactly, adding to the confusion.

+ Rich VE3KI is correct. If an incoming eQSL confirmation matches the callsign, band, and mode of a QSO in your log, but does not match the start time within the range you've specified, an error message like this is displayed:

no matching QSO within 60 minute time window; closest match: 2003-07-08 20:09:40

+ I have the "Maximum time difference..." set to 60 minutes.

+ If the error message "no QSO matching callsign, band, and mode" is displayed, the problem is not in the QSO start times.

+ The error message displays the callsign, band, and mode reported by eQSL; filter your Log Page Display to show all QSOs with the reported callsign.

73,

Dave, AA6YQ


Re: QSO start time rounding problem with eQSL

Norm - KC1BMD
 

That setting was at default 15 min but I had already changed it to 30 min. However, that caused a different error when the partner's start time was > the time set in this box:
"no matching QSO within 30 minute time window; closest match: yyyy-mm-dd hh:mm:ss". I am not referring to that error, since my start time and partner start time are within a minute of one another and I did not receive that error.

--
73, Norm/KC1BMD


Re: QSO start time rounding problem with eQSL

Dave AA6YQ
 

+ AA6YQ comments below

I was previously logging new QSO's to the HRD Logbook and my previous process was to upload the HRD QSO to both LoTW and eQSL. (I would also download the LoTW data to the QRZ logbook to have that log in sync too, although that does not matter for this issue). This all worked fine. I transferred my logging to DXKeeper by exporting the HRD logbook to an ADIF file and importing it into DXKeeper. On investigating some errors of the type: "no QSO matching callsign, band, and mode" I find a discrepancy with the way eQSL and DXKeeper handle rounding of the QSO start time. As an example, the HRD Logbook had a QSO logged with start time: 22:21:20 (since HRD uses hh:mm:ss format). When this would uploaded to eQSL, the start time was rounded up to the nearest minute (i.e. to 22:22). DXKeeper however rounded it down to the nearest minute (i.e. to 22:21) which caused the error to be reported when sync'ing QSLs. My impresssion of the way to round would be to round up for =>30 seconds and round down for <30 seconds. DXKeeper appears to have followed this rule whereas eQSL does not appear to have followed that. To be clear, there is zero chance that I manually modified the QSO start time, so that is ruled out as a possible cause. What would be the best way to resolve this type of error?

+ Assuming that the "no QSO matching callsign, band, and mode" reports your refer to above are displayed when you invoke the "Sync eQSL QSLs" function, on the "QSL Configuration" window's eQSL tab, set the "Maximum time difference for considering a downloaded QSL to match a logged QSO (minutes)" to at least 1 (the default is 15). See the description of this setting in

https://www.dxlabsuite.com/dxkeeper/Help/QSLConfiguration.htm#Maximum%20time%20difference...



73,

Dave, AA6YQ


Re: QSO start time rounding problem with eQSL

Norm - KC1BMD
 

"eQSL and LotW both accept time mismatches of several minutes; a few seconds is immaterial."

-> This does not concern me. I am aware that there is a time difference allowed to confirm a QSO. The discrepancy that I am referring to is the discrepancy between DXKeeper and eQSL. That must match exactly, otherwise an error is produced when synchronizing QSL's in DXK. Also in my case it was CW and band, mode and start time all match.

--
73, Norm/KC1BMD


Re: QSO start time rounding problem with eQSL

ve3ki
 

eQSL and LotW both accept time mismatches of several minutes; a few seconds is immaterial.

In your first message you quoted a message saying "no QSO matching callsign, band and mode" - if that is an exact quote, then you should be looking at callsign, band and mode. Of these, perhaps the most likely is the mode, especially for digital modes. Note that the ADIF standard for recording digital modes is not always what you might expect (e.g. FT8 is a full mode, whereas FT4 is mode MFSK, submode FT4). Some logging programs don't follow the ADIF standard exactly, adding to the confusion.

73,
Rich VE3KI


On Sun, Mar 7, 2021 at 02:40 PM, Norm - KC1BMD wrote:
I could be wrong about the rounding, or at least it is not conclusive. I found another QSO uploaded to eQSL the same way as previously described. The QSO start time in DXKeeper is 21:26 and in HRD Logbook it is :21:26:29 and in eQSL it is 21:26. So there was no rounding (up) by eQSL and the eQSL time matches DXKeeper time. The QSO start time, band, mode and call sign all match between eQSL and DXKeeper. I don't see any reason (yet) for the error. What other parameter(s) must match?
--
73, Norm/KC1BMD


Re: QSO start time rounding problem with eQSL

Norm - KC1BMD
 

I could be wrong about the rounding, or at least it is not conclusive. I found another QSO uploaded to eQSL the same way as previously described. The QSO start time in DXKeeper is 21:26 and in HRD Logbook it is :21:26:29 and in eQSL it is 21:26. So there was no rounding (up) by eQSL and the eQSL time matches DXKeeper time. The QSO start time, band, mode and call sign all match between eQSL and DXKeeper. I don't see any reason (yet) for the error. What other parameter(s) must match?
--
73, Norm/KC1BMD


QSO start time rounding problem with eQSL

Norm - KC1BMD
 

I was previously logging new QSO's to the HRD Logbook and my previous process was to upload the HRD QSO to both LoTW and eQSL. (I would also download the LoTW data to the QRZ logbook to have that log in sync too, although that does not matter for this issue). This all worked fine. I transferred my logging to DXKeeper by exporting the HRD logbook to an ADIF file and importing it into DXKeeper. On investigating some errors of the type: "no QSO matching callsign, band, and mode" I find a discrepancy with the way eQSL and DXKeeper handle rounding of the QSO start time. As an example, the HRD Logbook had a QSO logged with start time: 22:21:20 (since HRD uses hh:mm:ss format). When this would uploaded to eQSL, the start time was rounded up to the nearest minute (i.e. to 22:22). DXKeeper however rounded it down to the nearest minute (i.e. to 22:21) which caused the error to be reported when sync'ing QSLs. My impresssion of the way to round would be to round up for =>30 seconds and round down for <30 seconds. DXKeeper appears to have followed this rule whereas eQSL does not appear to have followed that. To be clear, there is zero chance that I manually modified the QSO start time, so that is ruled out as a possible cause. What would be the best way to resolve this type of error?

Note: I have not checked if this is a problem with LoTW yet.

--
73, Norm/KC1BMD


Re: QRZ look up in DXKeeper

Dave AA6YQ
 

+ AA6YQ comments below
both unfortunately not :-(

+ OK. Please do the following:

1. reboot Windows into "Safe mode with networking"

2. start the Launcher

3. direct the Launcher to start DXKeeper and Pathfinder

4. type my callsign into DXKeeper's Capture window's "call" box and strike the Enter key


+ Does Pathfinder display my QRZ page?


+ Does the Capture window populated with my name, QTH, state, county, and grid square?

73,

Dave, AA6YQ


Re: QRZ look up in DXKeeper

Alex OE3JTB
 
Edited

HI Dave
both unfortunately not :-(
73 Alex
PS send you errorlog


Re: DXKeeper auto populate

Dave AA6YQ
 

+ AA6YQ comments below

When clicking on a call from Spotcollector or entering a callsign on the main DXKeeper page (new call) the previous qso info is automatically populated in DXKeeper.

This is very problematic when the previous call may have been worked several years in the past.

Even more problematic is entering a special event call, 1X1 calls are very often populated with the incorrect info.


The only way I have found to stop this is the general tab of DXKeeper config, (display previous QSO's on lookup) but if I uncheck this it will not show any previous qso's.

I need to show the previous qso but NOT to populate the new qso with old info.

+ I can extend DXKeeper so that when you double-click a Spot Database Entry with DXKeeper's "Display previous QSOs on Lookup" option disabled, the callsign will still be placed in DXKeeper's Filter panel; you can then review previous QSOs with the Entry's Callsign by clicking DXKeeper's Filter panel's Call button - without information from previous QSOs being used to populate the Capture window.

+ Acceptable?

73,

Dave, AA6YQ


DXKeeper auto populate

Joe - W9RF
 


When clicking on a call from Spotcollector or entering a callsign on the main DXKeeper page (new call) the previous qso info is automatically populated in DXKeeper.

This is very problematic when the previous call may have been worked several years in the past.

Even more problematic is entering a special event call, 1X1 calls are very often populated with the incorrect info.


The only way I have found to stop this is the general tab of DXKeeper config, (display previous QSO's on lookup)  but if I uncheck this it will not show any previous qso's.

I need to show the previous qso but NOT to populate the new qso with old info.


73,

W9RF - Joe




Re: NEED HELP IN GETTING COMMANDER WORKING

Dave AA6YQ
 

Hello Dave and thanks for the information. It worked fine

+ Does that mean that you have Commander correctly controlling your IC-7610?

and in fact I now have WinWarbler working. Or at least I think it’s working I can hear the tones and I’m producing RF and it sounds good at this end through the monitor. I still don’t have MMTTY working and I fully don’t understand because they’re almost the same thing.

+ Your first post in this thread said

"when I press the "TX" icon, it does key the radio (ICOM 7610) but it only sends one steady tone (Mark, I think)."

+ To transmit RTTY with WinWarbler, type some text in its transmit pane, and then click the "Start" button in WinWarbler's "RTTY transmit" panel. See this annotated screen shot:

http://www.dxlabsuite.com/Wiki/Graphics/WinWarbler/RTTY.jpg

+ Later, you can configure WinWarbler to "auto start".

+ A constant mark tone when transmitting RTTY is a classic symptom of having the transceiver configured for RTTY FSK transmission (for an IC-7610, mode set to "RTTY") but not supplying a FSK signal to the transceiver; for an IC-7610, that can be done via the second virtual COM port created by the transceiver, as described in this Icom manual:

http://www.icom.co.jp/world/support/download/manual/pdf/USB_Port_Setting_Ver.1.0_Eng.pdf

+ The alternative is to transmit RTTY AFSK, in which case you'd configure WinWarbler to put your IC-7610 in DATA-L mode when operating RTTY.

+ Step-by-step instructions for configuring WinWarbler for RTTY operation are here:

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


73,

Dave, AA6YQ


Re: NEED HELP IN GETTING COMMANDER WORKING

Dan Coleman <w8kmx@...>
 

Hello Dave and thanks for the information. It worked fine and in fact I now have WinWarbler working. Or at least I think it’s working I can hear the tones and I’m producing RF and it sounds good at this end through the monitor. I still don’t have MMTTY working and I fully don’t understand because they’re almost the same thing. I’ll work on that tomorrow. But thanks for your help, and let me tell you you were an a Normas help. Seven threes Dan, W8KMX



On Mar 6, 2021 at 6:09 PM, <Dave AA6YQ> wrote:

@ more AA6YQ comments below

Dave: I got up the energy to start again on DXLab software. I used "IOBot Uninstall" to get rid of everything I could find and it did remove the items we discussed in the Control Panel >uninstall etc.

I disconnected my CD/DVD drive E and my external additional hard drive F. I cleaned with CCleaner including registry, rebooted and began again.


I even deleted the file I had previously downloaded from DXLab and started all over again. I installed everything. I tried to install everything in C:\DXlab\ (which I had created) and planned to let the program create the sub folders such as "WinWarbler," "Spot Collector" etc but that did not work. Only DXKeeper and DXView were installed there and it said it could not install others there because Commander was already installed there. So, I created a Folder for each of the remaining under C:\ (i.e. C:\WinWarbler, C:\PropView etc.

Now, that seemed to work OK except when I loaded the program, I received the following message for all the rest (only the names were changed to protect the innocent).

Example: the specified Spot Database pathname

                E:\DXLab\SpotCollector\Data bases\Spots.mdb doesn't exist, and one cannot be created in this location.

So, somewhere it remembers me and the drive E. When I went to "config" it filled in some items such as my call and name etc. so there is a database somewhere hidden in my computer which I can't find.

Do you have a recommendation?

@ Evidently your effort to remove all DXLab registry entries was unsuccessful.

@ My advice is to

1. direct Windows to uninstall each of your DXLab applications

2. make sure you have a backup of all critical files

3. carefully using the Windows Registry Editor (REGEDIT), delete the following nodes in the Windows Registry

HKEY_CURRENT_USER\Software\VB and VBA Program Settings\DXLabLauncher

HKEY_CURRENT_USER\Software\VB and VBA Program Settings\CI-V Commander

HKEY_CURRENT_USER\Software\VB and VBA Program Settings\DXKeeper

HKEY_CURRENT_USER\Software\VB and VBA Program Settings\DXView

HKEY_CURRENT_USER\Software\VB and VBA Program Settings\Pathfinder

HKEY_CURRENT_USER\Software\VB and VBA Program Settings\PropView

HKEY_CURRENT_USER\Software\VB and VBA Program Settings\SpotCollector

HKEY_CURRENT_USER\Software\VB and VBA Program Settings\WinWarbler

4. Install the DXLab Launcher into the default folder C:\DXLab (the Launcher will be installed in C:\DXLab\Launcher)

5. Direct the Launcher to install Commander into the default folder c:\DXLab (Commander will be installed in C:\DXLab\Commander)

6. Configure Commander to control your transceiver

7. Repeat steps 5 and 6 for each additional DXLab application you wish to use

        73,

           Dave, AA6YQ







3321 - 3340 of 203524