Date   

Re: Replacing QSL Log data with LoTW QSL data

Dave AA6YQ
 

+ AA6YQ comments below

I have been using DXLab for several years and have had DXKeeper retain the details of a QSL in DXKeeper rather than replace it with the data in LoTW. Is there a way I can replace the current details all the QSO's in my log with the details from LoTW?

+ Yes:

1. backup your log (Configuration window, Log tab, Backup button)

2. on the "QSL Configuration" window's LoTW tab, set the "Handling of LoTW QSL detail inconsistencies" panel to "Overwrite log data with LotW data..."

3. on the Main window's "Log QSOs" tab, click the Filter panel's X button so that all logged QSOs are present in the "Log Page Display"

4. on the Main window's QSL tab,

4a. set the "QSL Via" panel to LoTW

4b. click the "Update from LoTW" button

+ Depending upon how many QSLs you have in LoTW and how many QSOs are present in your log, step 4.b could take many hours -- so you might initiate this operation before retiring from radio operations for the day.

73,

Dave, AA6YQ


Re: Config for IC7300

Dave AA6YQ
 

+ AA6YQ comments below

Thanks to everybody that responded got it work finally!

+ Great! If there are improvements to the documentation that would have gotten you there faster, please suggest them here.

73,

Dave, AA6YQ


Re: Any of chance of getting a straight shot CAT over IP port option for Commander?

w-u-2-o
 

On Thu, Feb 17, 2022 at 08:41 AM, Dave AA6YQ wrote:
If the intent of this continuing request is "make it possible to control a transceiver via CAT-over-TCP even if the transceiver's manufacturer has not released a CAT-over-TCP option", I will not do that. It's hard enough to get things working correctly when the manufacturer provides a protocol specification.

If the intent is to encourage me to re-use TCP code between different CAT-over-TCP implementations, my response is "of course".
From that perspective then, Dave, let me please amend my original request to be very specific, as follows:

Apache hardware, operating under the thick client software known as "Thetis", at the present time is best served by the radio type "SDR-5000" in Commander. Thetis has recently been revised to include an IP socket interface for CAT control.

Would it please be possible to provide a variant of the SDR-5000 radio type that allows communication over an IP socket?

I will DM you the email of the currently active Thetis developer in support of this request, in case you have any questions.

Thanks,

w - u - 2 - o


Re: Config for IC7300

Holger <holger@...>
 

Thanks to everybody that responded got it work finally!

<H>

On 2/15/2022 18:01, w6de wrote:
This might help:
http://www.dxlabsuite.com/dxlabwiki/ConnectingIcom72007600

This article was found by searching for --> Icom <-- on the DXLab wiki http://www.dxlabsuite.com/dxlabwiki/TitleIndex by using the search function the upper right corner.
Save this link for quick access to DXLab how-to-do-it descriptions.

73,
Dave, w6de

-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Holger via groups.io
Sent: Tuesday, February 15, 2022 21:49
To: dxlab@groups.io
Subject: [DXLab] Config for IC7300

Can't seem to the get config right for my used ICOM IC7300 on DX LAB.

Any configuration hints on both ends would be appreciated.

I do not get a new port created when I plug in the USB cable, but it
does configure the audio, but I still get nothing.

Holger, K2HES










Replacing QSL Log data with LoTW QSL data

Stewart Lewis
 

I have been using DXLab for several years and have had DXKeeper retain the details of a QSL in DXKeeper rather than replace it with the data in LoTW.  Is there a way I can replace the current details all the QSO's in my log with the details from LoTW?


Re: Bogus N. Korea stations

Dave AA6YQ
 

# More AA6YQ comments below

That being the case, how can I block all N. Korea spots (there are at least a few every week) until such time as I learn that real operations have resumed?

+ append

and (DXCCPREFIX <> 'P5')

+ to the Spot Database Display filter(s) you are using.


# Alternatively,

1. click the Pre-filter button in the lower-right corner of the Configuration window's "Spot Database" tab

2. in the "SpotCollector Pre-filtering" window that appears,

2a. in the lower-left corner, set the first selector to P5 in the "Discard incoming spots of stations in selected DXCC entities" panel

2b. in the upper-left corner, check the Enable box; note that this will enable pre-filtering for any other bands, modes, or continents you have selected.


# The advantage of using Pre-filtering is that it eliminates the need to modify existing Spot Database Filters. The disadvantage is that if a valid P5 station becomes QRV, you will have no record of its activity in your Spot Database.

73,

Dave, AA6YQ


Re: Bogus N. Korea stations

Stephen Rabinowitz
 

TU
73, Steve K2SN

On Feb 17, 2022, at 12:44 PM, Dave AA6YQ <aa6yq@...> wrote:
+ AA6YQ comments below
That being the case, how can I block all N. Korea spots (there are at least a few every week) until such time as I learn that real operations have resumed?
+ append

and (DXCCPREFIX <> 'P5')

+ to the Spot Database Display filter(s) you are using.

         73,

                Dave, AA6YQ



Re: Bogus N. Korea stations

Dave AA6YQ
 

+ AA6YQ comments below
That being the case, how can I block all N. Korea spots (there are at least a few every week) until such time as I learn that real operations have resumed?
+ append

and (DXCCPREFIX <> 'P5')

+ to the Spot Database Display filter(s) you are using.

         73,

                Dave, AA6YQ



Re: Bogus N. Korea stations

Stephen Rabinowitz
 

That being the case, how can I block all N. Korea spots (there are at least a few every week) until such time as I learn that real operations have resumed?
73, Steve K2SN

On Feb 17, 2022, at 12:24 PM, Dave AA6YQ <aa6yq@...> wrote:
+ AA6YQ comments below
Are any of the recent N. Korea spots real?

+ I'm not aware of any valid amateur radio operations in North Korea.

+ See

https://www.ng3k.com/misc/adxo.html
 
            73,

                    Dave, AA6YQ


Re: Bogus N. Korea stations

Dave AA6YQ
 

+ AA6YQ comments below
Are any of the recent N. Korea spots real?

+ I'm not aware of any valid amateur radio operations in North Korea.

+ See

https://www.ng3k.com/misc/adxo.html
 
            73,

                    Dave, AA6YQ


Re: Bogus N. Korea stations

Stephen Rabinowitz
 

Are any of the recent N. Korea spots real?
73, Steve K2SN

On Feb 17, 2022, at 12:01 PM, Dave AA6YQ <aa6yq@...> wrote:
+ AA6YQ comments below

What override in Spot Collector would block bogus N. Korea spots ?

+ There is no way for SpotCollector to know a priori which spots of North Korean stations are bogus.

+ If you add a callsign to SpotCollector's "Special Callsign List" with no tag, incoming spots of that callsign will be ignored.

73,

Dave AA6YQ








Re: Bogus N. Korea stations

Dave AA6YQ
 

+ AA6YQ comments below

What override in Spot Collector would block bogus N. Korea spots ?

+ There is no way for SpotCollector to know a priori which spots of North Korean stations are bogus.

+ If you add a callsign to SpotCollector's "Special Callsign List" with no tag, incoming spots of that callsign will be ignored.

73,

Dave AA6YQ


Bogus N. Korea stations

Stephen Rabinowitz
 

What override in Spot Collector would block bogus N. Korea spots ?
73, Steve K2SN


Re: Any of chance of getting a straight shot CAT over IP port option for Commander?

Dave AA6YQ
 

If the intent of this continuing request is "make it possible to control a transceiver via CAT-over-TCP even if the transceiver's manufacturer has not released a CAT-over-TCP option", I will not do that. It's hard enough to get things working correctly when the manufacturer provides a protocol specification.

If the intent is to encourage me to re-use TCP code between different CAT-over-TCP implementations, my response is "of course".

73,

Dave, AA6YQ


Re: Any of chance of getting a straight shot CAT over IP port option for Commander?

Danny K5CG
 

I was about to reply that transport and application layers are not the same thing, but you did a much more eloquent job than I would have.


From: "aa777888athotmaildotcom" <scott.traurig@...>
To: DXLab@groups.io
Sent: Thursday, February 17, 2022 7:02:46 AM
Subject: Re: [DXLab] Any of chance of getting a straight shot CAT over IP port option for Commander?
On Wed, Feb 16, 2022 at 06:00 PM, Dave Fugleberg wrote:
so, just for sake of argument, suppose Dave DID implement a generic IP connection option in Commander.  Then tomorrow, your favorite radio manufacturer ships a new radio that includes IP connectivity.  Now you can send IP datagrams back and forth; if both ends implement TCP, you can even get a TCP connection. So what?  Dave STILL would need to extend Commander to support that particular radio with everything that sits atop the IP or TCP/IP stack in order to make use of that connection.  So while he's at it, he can more than likely reuse the low level IP code and wrap it all into the selection for that radio at that point.
Again, this appears to be combining the two issues, new radio commands and a new connection method, into a SINGLE issue. They are two SEPARATE issues. The only thing that is at issue is exposing an EXISTING capability, ALREADY in DXLabs for use by Flex owners, for use by other radio owners.

The "so what" is that this EXISTING capability, already used for Flex radios, can now also be used by K4 and Apache/Thetis users right now, if it were available, i.e. exposed to the user for all radio types. And potentially SunSDR users if TCI is added to DXLabs.

If we see a unique K4 implementation that allows IP socket comm's then, again, just leave the ability to send/receive over CAT exposed. It's an automatic win for Apache/Thetis and any future radio that supports CAT over IP. In other words, it's a future-proofing step.

If TCI is going to be supported for SunSDR (and that's a BIG job compared to merely exposing IP socket comm's), again, the necessary IP socket UI will already be there.

In all four cases, Flex, K4, SunSDR, Apache/Thetis, the IP socket comm's channel part of the equation are IDENTICAL. Only the strings pushed over that channel are different. Just like the serial port implementation, it is shared across all radio types that can currently utilize it, and it is unlikely to change for any future radio that supports CAT (or TCI) over IP.

Bottom line: it's really a philosophical design issue, not an engineering or technical one. The present day DXLabs design paradigm, based on the current Flex implementation, is to obscure the availability of an IP socket comm's channel on a radio by radio basis. I'm proposing that the IP socket interface be exposed. There is no downside to exposing it, and the UI development to do so is "once and done". To obscure it on a radio by radio basis is actually more work.

As for the concerns about security, there are none from a DXLabs implementation perspective. The radios in question have no security features implemented on their respective interfaces. Other equipment that implements similar interfaces, like Flex and Elecraft amplifiers, have none. There are no security features implemented on other existing IP socket interfaces that are already present in DXLabs app's, N1MM, you name it. Hence to expose the IP socket comm's channel for any radio type does not make that situation worse and there is no reason to make a security argument where none is currently possible.

73,

w - u - 2 - o


Re: commander very slow to load

Dave AA6YQ
 

+ AA6YQ comments below
Recently DXLabs Commander is very slow to load. Also when I click on a spot on Spot Collector the page turns white and then comes back to normal.
+ When a DXLab application spontaneously becomes slower, that's almost certainly the result of interference from a misconfigured or incompetent anti-malware application. The test for this -- reboot Windows into "safe mode with networking" -- unfortunately can't be used with Commander because device drivers are note loaded when Windows is booted that way. So the first step is to make certain that your anti-malware applications are configured to consider Commander to be "safe".

     73,

              Dave, AA6YQ


Re: commander very slow to load

Buck
 

"Prune" the database.  Spotcollector>Config>SpotDatabase>General>Prune

I set mine to 3 days.  If the database gets too big, it slows down the processing.

Buck, K4IA
DXCC Honor Roll
8BDXCC
Author EasyWayHamBooks.com
On 2/17/2022 10:01 AM, N4EK Ed via groups.io wrote:

Recently DXLabs Commander is very slow to load. Also when I click on a spot on Spot Collector the page turns white and then comes back to normal.
Any suggestions?
N4EK


Re: commander very slow to load

N4EK Ed
 

Recently DXLabs Commander is very slow to load. Also when I click on a spot on Spot Collector the page turns white and then comes back to normal.
Any suggestions?
N4EK


Re: Any of chance of getting a straight shot CAT over IP port option for Commander?

w-u-2-o
 

On Wed, Feb 16, 2022 at 06:00 PM, Dave Fugleberg wrote:
so, just for sake of argument, suppose Dave DID implement a generic IP connection option in Commander.  Then tomorrow, your favorite radio manufacturer ships a new radio that includes IP connectivity.  Now you can send IP datagrams back and forth; if both ends implement TCP, you can even get a TCP connection. So what?  Dave STILL would need to extend Commander to support that particular radio with everything that sits atop the IP or TCP/IP stack in order to make use of that connection.  So while he's at it, he can more than likely reuse the low level IP code and wrap it all into the selection for that radio at that point.
Again, this appears to be combining the two issues, new radio commands and a new connection method, into a SINGLE issue. They are two SEPARATE issues. The only thing that is at issue is exposing an EXISTING capability, ALREADY in DXLabs for use by Flex owners, for use by other radio owners.

The "so what" is that this EXISTING capability, already used for Flex radios, can now also be used by K4 and Apache/Thetis users right now, if it were available, i.e. exposed to the user for all radio types. And potentially SunSDR users if TCI is added to DXLabs.

If we see a unique K4 implementation that allows IP socket comm's then, again, just leave the ability to send/receive over CAT exposed. It's an automatic win for Apache/Thetis and any future radio that supports CAT over IP. In other words, it's a future-proofing step.

If TCI is going to be supported for SunSDR (and that's a BIG job compared to merely exposing IP socket comm's), again, the necessary IP socket UI will already be there.

In all four cases, Flex, K4, SunSDR, Apache/Thetis, the IP socket comm's channel part of the equation are IDENTICAL. Only the strings pushed over that channel are different. Just like the serial port implementation, it is shared across all radio types that can currently utilize it, and it is unlikely to change for any future radio that supports CAT (or TCI) over IP.

Bottom line: it's really a philosophical design issue, not an engineering or technical one. The present day DXLabs design paradigm, based on the current Flex implementation, is to obscure the availability of an IP socket comm's channel on a radio by radio basis. I'm proposing that the IP socket interface be exposed. There is no downside to exposing it, and the UI development to do so is "once and done". To obscure it on a radio by radio basis is actually more work.

As for the concerns about security, there are none from a DXLabs implementation perspective. The radios in question have no security features implemented on their respective interfaces. Other equipment that implements similar interfaces, like Flex and Elecraft amplifiers, have none. There are no security features implemented on other existing IP socket interfaces that are already present in DXLabs app's, N1MM, you name it. Hence to expose the IP socket comm's channel for any radio type does not make that situation worse and there is no reason to make a security argument where none is currently possible.

73,

w - u - 2 - o


Re: Any of chance of getting a straight shot CAT over IP port option for Commander?

Gregg W6IZT
 

Another alternative.

 

I have been using TCP ComBridge Pro   https://www.aggsoft.com/tcp-com/  for well over a year and it works flawlessly. I can access any serial device via TCP from anywhere. The TCP client can be configured to block upstream communications, effectively eliminating polling collisions.  A license is $80, so it may not be for everyone.

 

Gregg W6IZT

 

From: DXLab@groups.io <DXLab@groups.io> On Behalf Of Dave Fugleberg
Sent: Thursday, February 17, 2022 02:00
To: DXLab@groups.io
Subject: Re: [DXLab] Any of chance of getting a straight shot CAT over IP port option for Commander?

 

so, just for sake of argument, suppose Dave DID implement a generic IP connection option in Commander.  Then tomorrow, your favorite radio manufacturer ships a new radio that includes IP connectivity.  Now you can send IP datagrams back and forth; if both ends implement TCP, you can even get a TCP connection. So what?  Dave STILL would need to extend Commander to support that particular radio with everything that sits atop the IP or TCP/IP stack in order to make use of that connection.  So while he's at it, he can more than likely reuse the low level IP code and wrap it all into the selection for that radio at that point.

 

I understand the argument that it's just another connection/transport type and that the same CAT commands could be sent over IP as they can over a serial link.  That's likely what radios that sport both interfaces do.  However, most legacy radios have neither a NIC nor a IP stack, so having the ability to select a generic IP connection in Commander for a legacy radio has no practical value (unless there's additional hardware at the radio end of course).  And being able to select an IP interface for a new radio not yet supported by Commander is not of much value either.

 

I'm all for open standards and for networked vs point-to-point links - don't get me wrong.  I'm just trying to understand the value proposition of the original question for my own education.

 

I currently use a K3 and the Win4K3 software, plus some ComoCom virtual serial port pairs to allow several applications to access the radio,  If all of those applications AND the radio natively supported network connections and played nicely, that would certainly be preferable to all that glue...but I'm not holding my breath.  

 

73 de W0ZF

 

On Wed, Feb 16, 2022 at 5:50 PM Dave AA6YQ <aa6yq@...> wrote:

+ AA6YQ comments below

Nor should it be necessary. Simply add an xxx.xxx.xxx.xxx:yyy option
(IP Address/port) to the current serial port list. A COM# entry
triggers the current serial interface (serial.sys & SComm32x.ocx)
while an IP/Port entry triggers the IP interface.

+ Plus whatever's required for "security".

       73,

             Dave, AA6YQ

3941 - 3960 of 210241