Date   

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


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

Dave Fugleberg
 

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


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

Dave AA6YQ
 

+ 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


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

Joe Subich, W4TV
 

I predict that it will be a long time before a TCP checkbox appears Commander's Radio panel independent of the selected Model.
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.

If the Flex interface requires a hardware serial number, that can
be handled exactly like the Icom "CI-V Address". Kenwood apparently
have a unique issue between the TS-890 and TS-990 ... where one uses
UTF-8 encoding and the other UTF-16 (in addition to the basic CAT
command set).

73,

... Joe, W4TV


On 2022-02-16 5:53 PM, Dave AA6YQ wrote:
+ AA6YQ comments below

snip<
But if you do decide to support K4 over Ethernet, the method used to create the sockets for the K4 is identical to that used for other radios, like the Flex, Thetis/Apache, or SunSDR.
+ 20+ years of experience implementing and supporting transceiver control leads me to consider that claim naïve. Transceiver manufacturers don't conform to their own protocol specifications, much less those of industry standards. SunSDR doesn't even use TCP!
+ To the extent that existing code can be re-used, it will be re-used. I predict that it will be a long time before a TCP checkbox appears Commander's Radio panel independent of the selected Model.
73,
Dave, AA6YQ


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

Dave AA6YQ
 

+ AA6YQ comments below

snip<
But if you do decide to support K4 over Ethernet, the method used to create the sockets for the K4 is identical to that used for other radios, like the Flex, Thetis/Apache, or SunSDR.

+ 20+ years of experience implementing and supporting transceiver control leads me to consider that claim naïve. Transceiver manufacturers don't conform to their own protocol specifications, much less those of industry standards. SunSDR doesn't even use TCP!

+ To the extent that existing code can be re-used, it will be re-used. I predict that it will be a long time before a TCP checkbox appears Commander's Radio panel independent of the selected Model.

73,

Dave, AA6YQ


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

w-u-2-o
 

Dave,

You seem to be totally misunderstanding what I'm writing about. I'm probably doing a horrible job of expressing myself. I'll try one last time, and then I'll shut up. Not my circus, not my monkeys, you do all the work, you certainly get all the say.

Using the OSI model (https://en.wikipedia.org/wiki/OSI_model) as a reference point:

CAT comprises Layers 4-7 (E.g. "ZZPC0;", etc.). How CAT gets to/from the radio are Layers 1-3 (RS232, IP sockets, carrier pigeon, etc.). Some might quibble about where that line is drawn, but that line is there.

Layers 4-7 will vary from radio to radio, i.e. CAT commands are different. RS232 is essentially the same everywhere. So are TCP/IP sockets. Those are standards. CAT is not. That is what I mean by "standard".

It is a mistake to conflate the two parts of the equation. K4 (or any other radio) CAT is not inextricably bound to how you get the CAT commands to and from the radio. 

All we are talking about is making a new option for Layers 1-3. Socket (IP + port = socket) vs. serial.

You will have to do this for the K4 over Ethernet unless you decide to only support K4 over RS232, which is certainly an option. Indeed, why bother supporting K4 over Ethernet? From the perspective of your last response, it's not really necessary. Other than IF and audio data, the K4 is 100% controllable via CAT over RS232. You can obtain COM port appearances from the K4 by simply attaching the USB cable, or by provisioning an actual serial cable if an actual, old-fashioned RS232 serial port is available. There's absolutely no need to add Ethernet socket support for it based on your previous comments.

But if you do decide to support K4 over Ethernet, the method used to create the sockets for the K4 is identical to that used for other radios, like the Flex, Thetis/Apache, or SunSDR.

If you hide the socket interface from the user as a communications option for only the K4, then one cannot use it for sending/receiving CAT any other radios. That seems like a waste.

It would seem you have the necessary code in Commander already. It's just hidden and bound to only the Flex. No need to write more socket code. Just change the UI to allow sending/receiving any sort of CAT over that socket. Flex CAT. PowerSDR CAT. Kenwood CAT. K4 CAT, whatever. Then it's just a matter of adding any K4 unique commands to the existing K3 CAT command library. And then you are future-proof. When the next radio comes along that has CAT over Ethernet all that will be done, and only the unique additions to the CAT library will be required.

73,

w - u - 2 - o




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

Dave AA6YQ
 

+ AA6YQ comments below

CAT over IP is the future. It significantly simplifies user complexity. No need to choose, configure and debug a virtual serial port solution.

+ Not having to specify baud rate, word length, and parity parameters is an advantage, but this is offset by the need to specify a host address, port, and some sort of security authentication. No one ever lost access to their transceiver because they forgot their serial port's password.

+ During the 20+ years I've been developing Commander, I've never seen anyone need to debug a virtual serial port. Driver installation can be problematic if users don't read the instructions before connecting their radio to their computer.


No need to have all those extra services, app's and ports running and sorted out.

+ To what extra services, apps, and ports are you referring? Interacting with a transceiver via a serial port just requires the appropriate serial port hardware, device driver, and cable.

snip<
At the end of the day, if you do add TCP/IP CAT comm's for the K4, please make it generic for all radio types, i.e. please don't tie it to just the K4 in the same manner it's done for the Flex Signature series. By leaving it generic, then one can opt to communicate via IP for other hardware and software that supports CAT over IP with an appropriate CAT command set chosen (e.g. Kenwood, or Flex-5000 for openHPSDR users, etc.)

+ There is no specification for "generic TCP/IP CAT". When the Elecraft K4, loaner arrives, I will extend Commander to access it via TCP, implementing whatever connection and security mechanisms that its documentation prescribes. Likely it will exploit some of the code added in support of the Flex Signature "CAT over TCP/IP", but that sharing will not be visible to users.

+ If the transceiver industry ever coalesces around a standard set of mechanisms for CAT over TCP/IP, I will extend Commander to support it. Until then, I will extend Commander to provide TCP access to individual transceivers as manufacturers make it available.

73,

Dave, AA6YQ


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

w-u-2-o
 

This does not provide the functionality requested. The point of having native, organic, IP support in a given app is, as already explained, to do away with the complexity of these sort of add-on's.

Perhaps even more important, it's kind of dumb to convert to serial to then convert to IP. I've already got VSPE on my system, and can use that to simply go serial-to-serial. The point is to get VSPE (or its equivalents com0com, VSPM, etc.) out of the configuration space and have all the various app's and hardware talk directly to each other without all this middleware.

The other nice thing about a properly implemented TCP/IP port is that a single instance can accept multiple connections. No more having to program or manage multiple serial ports, one for each app-to-app, or app-to-hardware, connection. 


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

Bill Pence
 

Does this not provide the functionality requested?



Looks simple enough to configure and no fees...


On Wed, Feb 16, 2022, 11:55 AM aa777888athotmaildotcom <scott.traurig@...> wrote:
Hi Dave--thanks for the reply!

No, I've not forgotten about any of those things. My point, FWIW, is that that comprises the entire list of what's necessary. It's not like people asking you to implement TCI, which is, as you no doubt know, an entirely different set of messages, i.e. an entirely new protocol.

CAT over IP is the future. It significantly simplifies user complexity. No need to choose, configure and debug a virtual serial port solution. No need to have all those extra services, app's and ports running and sorted out. And it makes the use of separate machines for separate functions, while still possible using some of the virtual serial port solutions, much, much easier. It also makes remote access easier.

My station is well on the way to being serial port free. Thetis (the current openHPSDR/Apache thick client software) is now CAT over IP capable. Node Red, the up and coming IoT-based station automation solution, is the same. The entire Elecraft line-up is headed in that direction, in my case the KPA1500 I have here is CAT over IP.

Not saying there is zero work for you, of course, but the K4 should prove to be a relatively small effort for CAT support. Leaving aside audio and IQ streams, the CAT command language remains identical across all of the USB serial, RS232 serial, and IP ports, and is built on the K3 command set. Once any K4 unique commands you wish to support are added, just adding the IP interface should require nothing more than, well, adding the interface!

At the end of the day, if you do add TCP/IP CAT comm's for the K4, please make it generic for all radio types, i.e. please don't tie it to just the K4 in the same manner it's done for the Flex Signature series. By leaving it generic, then one can opt to communicate via IP for other hardware and software that supports CAT over IP with an appropriate CAT command set chosen (e.g. Kenwood, or Flex-5000 for openHPSDR users, etc.)

Thanks & 73!

w - u - 2 - o

4081 - 4100 of 210373