Date   
Re: Future platforms for DXLab

Norman Heyen
 

I too throw my hat into the ring of having the application and database local. Various reasons but I can do backups to the cloud (although having a 'button' to do that in DXLabs Suite would be appreciated).

The idea of a complete settings backup where it would be a matter of loading the app on a new computer, then just restoring the settings backup would be great. I have to update the shack PC soon. And like all MS apps, I dread doing this because of the hassles and uncertainty of getting everything back to like it was.

Having DXLabs platform independent would be nice but I'm probably going to be a Windows user for a long time.

Just my two cents worth (probably inflated), your support and work is greatly appreciated.

Thanks for letting us share and vent,
Norman
KC9NVN

On October 11, 2018 at 12:17 PM Dave AA6YQ <aa6yq@...> wrote:

  • more AA6YQ comments below


+ As part of the transition to a "next platform", it would make sense to start by updating the existing DXLab applications to employ the "settings management mechanism" that will be employed in that "next platform".

And there is the crux of the problem, and one I'll maintain has no good, long-term, answer. During the DOS days, no one could have envisioned the Windows ecostructure as it is today. However, as we've all learned one does not bet against Microsoft. It may take them 3 or more versions to get something "right", but eventually they do turn out good, solid software. Whether any of us agrees with their direction makes no difference. Microsoft has its own reasons for doing things and they are only somewhat affected by the marketplace.

I think the important thing to remember is that no matter what decision is made, over time it will turn out to be "wrong". Remember when client-server was the thing? Now look at the directions of the industry, and client-server is rarely even mentioned.

My advice would be to look at when you think you need to start development for the next-gen DXLab and make your best decision then and push ahead with all deliberate speed. Just don't change horses, either in development environment or goals, in mid-stream. I was once involved in a project that did both on multiple occasions during the time between conception and delivery, a period of nearly 4 years. It ended very badly. Thankfully I was long gone and therefore well outside the blast radius.
  • Good advice.

  • To Microsoft's credit, they did not disable the Registry-based settings storage mechanism that was not just recommended, but built into the language runtimes. Thus I was never forced to divert developer cycles away from DXLab's primary objective in order to annually reposition the furniture to be consistent with that year's security posturing.

  • I still have high-level contacts at Microsoft, and will seek their views of where things are headed before making final decisions. Even though DXLab is small potatoes for Microsoft, they intrinsically hate the prospect of losing *anything*, and if made aware will exert themselves to prevent it.


73,

Dave, AA6YQ


Re: Future platforms for DXLab

Dave AA6YQ
 

+ AA6YQ comments below

I too throw my hat into the ring of having the application and database local. Various reasons but I can do backups to the cloud (although having a 'button' to do that in DXLabs Suite would be appreciated).

+ You can do that now, using the "Backup folder" panel on the Configuration window's Log tab; specify a folder on DropBox or GoogleDrive or ...


The idea of a complete settings backup where it would be a matter of loading the app on a new computer, then just restoring the settings backup would be great.

+ You can also do that now. See

<https://www.dxlabsuite.com/dxlabwiki/CreateUpdateWorkspace>

73,

Dave, AA6YQ

New Command for UDP Broadcast

Stefan AF6SA
 

Recently i build an WiFi antenna switch/tuner with 24 outputs and a Forward/Reflected power meter.
It has a WEB server, telnet server and UDP listener.
Information about operating frequency and antenna selected is extracted from N1MM+ UDP packet <TXFreq> and <Antenna> tags:
// N1MM+ UDP packet example:  http://n1mm.hamdocs.com/tiki-index.php?page=UDP+Broadcasts
    <?xml version="1.0" encoding="utf-8"?>
    <RadioInfo>
        <StationName>HAMSHACK</StationName>
        <RadioNr>1</RadioNr>
        <Freq>714965</Freq>
        <TXFreq>714965</TXFreq>
        <Mode>USB</Mode>
        <OpCall>AF6SA</OpCall>
        <IsRunning>True</IsRunning>
        <FocusEntry>395636</FocusEntry>
        <Antenna>9</Antenna>
        <Rotors></Rotors>
        <FocusRadioNr>1</FocusRadioNr>
        <IsStereo>False</IsStereo>
        <ActiveRadioNr>1</ActiveRadioNr>
    </RadioInfo>

N1MM+ allows for up to 16 antenna combinations on each frequency segment and it is working well for switching/tuning antennae in my station.

On other hand DXLab UDP is missing <Antenna> tag, limiting to only one antena combination per frequency segment.
//  DXLabs UDP packet:
    <?xml version="1.0" encoding="utf-8"?>
    <RadioInfo>
        <RadioNr>1</RadioNr>
        <Freq>183821</Freq>
        <TXFreq>183820</TXFreq>
        <Mode>USB</Mode>
    </RadioInfo>

It will be good to have a new command to fill and add <Antenna> tag, something like:
    <UDPAntenna N> where N is the antenna number
Addding <FocusRadioNr>, <ActiveRadioNr> and <IsStereo> tag's can make DXlab more compatible with N1MM+ users.

73 de Stefan/AF6SA

Re: Future platforms for DXLab

Bill Seward
 

If your findings are something you can share, I'd be interested in hearing about them. I may be out of the game, but I still enjoy the role of spectator.

Bill

* I still have high-level contacts at Microsoft, and will seek their views of
where things are headed before making final decisions. Even though DXLab is
small potatoes for Microsoft, they intrinsically hate the prospect of losing
*anything*, and if made aware will exert themselves to prevent it.

73,

Dave, AA6YQ

TQSL update available

Greg Waits
 

For a long while, when I have started DXLab with Launcher, I get a message "New TQSL release (v 2.4.1) is available.  So I hit "Run TQSL and update, and I see the LOTW dialog box which indicates that it has been successfully updated.  I keep getting this message on startup - am I overlooking something?
Thanks,
Greg K4OY

Re: Still TQSL questions

eddy on5jk
 

Thanks Dave.

Now i know what to do in a week or so.

It’s almost midnight here now, but could’nt go to bed before reading your answer.

To Mister  Al Groff:My new certificate does work already.

I must have done something stupid, as i am not a nerd.

(Never studied PC’s) If not so, i do not know why te “Request” keeps staying there.

In a week i will delete it, as Dave wrote.

Thanks to Dave and all OM’s.

Eddy ON5JK

 

Verzonden vanuit Mail voor Windows 10

 

Van: Dave AA6YQ
Verzonden: donderdag 11 oktober 2018 21:13
Aan: DXLab@groups.io
Onderwerp: Re: [DXLab] Still TQSL questions

 

+ AA6YQ comments below

 

Dave they are both for ON5JK.

 

I suppose i did a mistake somewhere.

 

Could i have asked twice for a renewal?

 

Did i not have enough patience?

 

+ Only you can answer those questions.

 

 

The good one begins 2018-20-09 and expires 2021-10-08.

 

I requested a renewal following on the received message, that the former certificate expired.

 

My request must be sent one or two days before2018-10-09.

 

+ I suggest that you wait a week. If no new Callsign Certificate arrives from the ARRL during that time, then at the end of the week, delete the Callsign Certificate marked in TQSL as "awaiting response from ARRL".

 

      73,

 

               Dave, AA6YQ

 

Van: Dave AA6YQ <mailto:aa6yq@...>

Verzonden: donderdag 11 oktober 2018 18:48

Aan: DXLab@groups.io

Onderwerp: Re: [DXLab] Still TQSL questions

 

 

+ AA6YQ comments below

 

 

Thanks to Hans and Kenneth, i no longer receive error-messages concerling LotW or TQSL cert.

 

 

However, when i open TQSL, Callsign certificates, i see two items:

 

 

First is my new certificate (in yellow key-hole) expiring

 

 

2021-10-08. So far so good.

 

 

Underneath i see a second icon, in red, looks like a”forbidden”-sign. Looking to the properties of it, i read : <Certificate Request, awaiting Responce from ARRL>.

 

 

Is it normal? Do i leave it there? Is another action needed?

 

 

+ For what callsign is the "Certificate Request awaiting response from ARRL"?

 

 

+ When did you last request a Callsign Certificate for this callsign?

 

 

         73,

 

 

               Dave, AA6YQ

 

 

 

 

 

 

 

<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>            Virusvrij. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>                

 

 

 

 

 

 


Virusvrij. www.avg.com

Re: TQSL update available

Dave AA6YQ
 

+ AA6YQ comments below

For a long while, when I have started DXLab with Launcher, I get a message "New TQSL release (v 2.4.1) is available. So I hit "Run TQSL and update, and I see the LOTW dialog box which indicates that it has been successfully updated. I keep getting this message on startup - am I overlooking something?

+ One possibility: the pathname to TQSL.exe that you specified in the TQSL panel on the "QSL Configuration" window's LoTW tab does not point to the instance of TQSL that you just upgraded. What version number is shown in this panel (in blue font, after the word TQSL)?

73,

Dave, AA6YQ

Import Log Errors

William Liporace WC2L
 

Where do I find the import adif log error files?
Or is in one of the log fields

Will WC2L

-- 
William Liporace WC2L
http://www.wc2l.com or http://dxc.wc2l.com
AR-Cluster Node  telnet dxc.wc2l.com or 144.93 MHz
wc2l@...

Re: Future platforms for DXLab

w6de
 

I like this thought of Norman Heyen:

The idea of a complete settings backup where it would be a matter of loading the app on a new computer, then just restoring the settings backup would be great. I have to update the shack PC soon. And like all MS apps, I dread doing this because of the hassles and uncertainty of getting everything back to like it was.

 

I agree.  This will be of immediate help to the whole DXLab user community.  It could be used to enhance the user experience from not only the inevitable crash; but the intentional upgrade experience that users perform.  In addition,  build a new interchange message in the new Launcher to receive messages from the other DXLabs modules/apps to remind the operator of settings changes and ask if they wish to save them at shutdown?  Give three choices, Yes-save changes and shutdown, No-don’t save changes and shutdown, No-don’t save changes and abort shut-down.  Sometimes I experiment with changes and forget to change back the ones I didn’t like.  When I later rediscover the change I made, I’ve already forgotten where the setting was.

 

Thanks for your support all these years,

Dave w6de

 

From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Norman Heyen
Sent: 11 October, 2018 20:28
To: DXLab@groups.io; Dave AA6YQ
Subject: Re: [DXLab] Future platforms for DXLab

 

I too throw my hat into the ring of having the application and database local. Various reasons but I can do backups to the cloud (although having a 'button' to do that in DXLabs Suite would be appreciated).

The idea of a complete settings backup where it would be a matter of loading the app on a new computer, then just restoring the settings backup would be great. I have to update the shack PC soon. And like all MS apps, I dread doing this because of the hassles and uncertainty of getting everything back to like it was.

Having DXLabs platform independent would be nice but I'm probably going to be a Windows user for a long time.

Just my two cents worth (probably inflated), your support and work is greatly appreciated.

Thanks for letting us share and vent,
Norman
KC9NVN

On October 11, 2018 at 12:17 PM Dave AA6YQ <aa6yq@...> wrote:

  • more AA6YQ comments below



+ As part of the transition to a "next platform", it would make sense to start by updating the existing DXLab applications to employ the "settings management mechanism" that will be employed in that "next platform".

And there is the crux of the problem, and one I'll maintain has no good, long-term, answer. During the DOS days, no one could have envisioned the Windows ecostructure as it is today. However, as we've all learned one does not bet against Microsoft. It may take them 3 or more versions to get something "right", but eventually they do turn out good, solid software. Whether any of us agrees with their direction makes no difference. Microsoft has its own reasons for doing things and they are only somewhat affected by the marketplace.

I think the important thing to remember is that no matter what decision is made, over time it will turn out to be "wrong". Remember when client-server was the thing? Now look at the directions of the industry, and client-server is rarely even mentioned.

My advice would be to look at when you think you need to start development for the next-gen DXLab and make your best decision then and push ahead with all deliberate speed. Just don't change horses, either in development environment or goals, in mid-stream. I was once involved in a project that did both on multiple occasions during the time between conception and delivery, a period of nearly 4 years. It ended very badly. Thankfully I was long gone and therefore well outside the blast radius.

  • Good advice.

 

  • To Microsoft's credit, they did not disable the Registry-based settings storage mechanism that was not just recommended, but built into the language runtimes. Thus I was never forced to divert developer cycles away from DXLab's primary objective in order to annually reposition the furniture to be consistent with that year's security posturing.

 

  • I still have high-level contacts at Microsoft, and will seek their views of where things are headed before making final decisions. Even though DXLab is small potatoes for Microsoft, they intrinsically hate the prospect of losing *anything*, and if made aware will exert themselves to prevent it.



73,

Dave, AA6YQ

Re: Import Log Errors

Dave AA6YQ
 

+ AA6YQ comments below

Where do I find the import adif log error files?

+ In the folder that contains the ADIF file you imported. If you imported X.adi, the error file will be named X_error.txt.adi

+ This presumes you checked "Record import errors in error file" box on the Main window's "Import QSOs" tab.

+ DXKeeper will import any ADIF record that at least contains a valid callsign and a valid "QSO Begin" date and time. Clicking the Broke button in the Filter panel at the bottom of the Main window's "Log QSOs" tab will filter the Log Page Display to contain only QSOs that DXKeeper considers "broken". For a definition of what "broken" means, see

<https://www.dxlabsuite.com/dxkeeper/Help/LogIntegrity.htm>

73,

Dave, AA6YQ

Re: New Command for UDP Broadcast

Dave AA6YQ
 

+ AA6YQ comments below

Recently i build an WiFi antenna switch/tuner with 24 outputs and a Forward/Reflected power meter.
It has a WEB server, telnet server and UDP listener.
Information about operating frequency and antenna selected is extracted from N1MM+ UDP packet <TXFreq> and <Antenna> tags:
// N1MM+ UDP packet example: http://n1mm.hamdocs.com/tiki-index.php?page=UDP+Broadcasts
<?xml version="1.0" encoding="utf-8"?>
<RadioInfo>
<StationName>HAMSHACK</StationName>
<RadioNr>1</RadioNr>
<Freq>714965</Freq>
<TXFreq>714965</TXFreq>
<Mode>USB</Mode>
<OpCall>AF6SA</OpCall>
<IsRunning>True</IsRunning>
<FocusEntry>395636</FocusEntry>
<Antenna>9</Antenna>
<Rotors></Rotors>
<FocusRadioNr>1</FocusRadioNr>
<IsStereo>False</IsStereo>
<ActiveRadioNr>1</ActiveRadioNr>
</RadioInfo>

N1MM+ allows for up to 16 antenna combinations on each frequency segment and it is working well for switching/tuning antennae in my station.

On other hand DXLab UDP is missing <Antenna> tag, limiting to only one antena combination per frequency segment.
// DXLabs UDP packet:
<?xml version="1.0" encoding="utf-8"?>
<RadioInfo>
<RadioNr>1</RadioNr>
<Freq>183821</Freq>
<TXFreq>183820</TXFreq>
<Mode>USB</Mode>
</RadioInfo>

It will be good to have a new command to fill and add <Antenna> tag, something like:
<UDPAntenna N> where N is the antenna number Addding <FocusRadioNr>, <ActiveRadioNr> and <IsStereo> tag's can make DXlab more compatible with N1MM+ users.


+ Commander provides no concept of "antenna selection". If such a concept were to be added, DXView would be the logical application, as it is responsible for antenna rotation. That said, it would be possible to enable a Commander user-defined sequence to set a "current antenna" variable, the value for which would presumably be indicated in the sequence name; is that what you are suggesting?

+ As I understand them, RadioFocusNr and ActiveRadioNr are parameters employed in SO2R contesting, which is out-of-scope for DXLab. I suspect that IsStereo falls into the same category.

73,

Dave, AA6YQ

Re: New Command for UDP Broadcast

Joe Subich, W4TV
 

On 2018-10-11 7:19 PM, Dave AA6YQ wrote:

+ As I understand them, RadioFocusNr and ActiveRadioNr are
parameters employed in SO2R contesting, which is out-of-scope for
DXLab. I suspect that IsStereo falls into the same category.
ActiveRadioNr would be equivalent to selected radio. RadioFocusNr
would always be equal to ActiveRadioNr and IsStereo always off.

Selected Radio is already emitted for the SO2R (radio select) Serial
Port along with the single antenna select value per band (ACC Outputs).

73,

... Joe, W4TV


On 2018-10-11 7:19 PM, Dave AA6YQ wrote:
+ AA6YQ comments below
Recently i build an WiFi antenna switch/tuner with 24 outputs and a Forward/Reflected power meter.
It has a WEB server, telnet server and UDP listener.
Information about operating frequency and antenna selected is extracted from N1MM+ UDP packet <TXFreq> and <Antenna> tags:
// N1MM+ UDP packet example: http://n1mm.hamdocs.com/tiki-index.php?page=UDP+Broadcasts
<?xml version="1.0" encoding="utf-8"?>
<RadioInfo>
<StationName>HAMSHACK</StationName>
<RadioNr>1</RadioNr>
<Freq>714965</Freq>
<TXFreq>714965</TXFreq>
<Mode>USB</Mode>
<OpCall>AF6SA</OpCall>
<IsRunning>True</IsRunning>
<FocusEntry>395636</FocusEntry>
<Antenna>9</Antenna>
<Rotors></Rotors>
<FocusRadioNr>1</FocusRadioNr>
<IsStereo>False</IsStereo>
<ActiveRadioNr>1</ActiveRadioNr>
</RadioInfo>
N1MM+ allows for up to 16 antenna combinations on each frequency segment and it is working well for switching/tuning antennae in my station.
On other hand DXLab UDP is missing <Antenna> tag, limiting to only one antena combination per frequency segment.
// DXLabs UDP packet:
<?xml version="1.0" encoding="utf-8"?>
<RadioInfo>
<RadioNr>1</RadioNr>
<Freq>183821</Freq>
<TXFreq>183820</TXFreq>
<Mode>USB</Mode>
</RadioInfo>
It will be good to have a new command to fill and add <Antenna> tag, something like:
<UDPAntenna N> where N is the antenna number Addding <FocusRadioNr>, <ActiveRadioNr> and <IsStereo> tag's can make DXlab more compatible with N1MM+ users.
+ Commander provides no concept of "antenna selection". If such a concept were to be added, DXView would be the logical application, as it is responsible for antenna rotation. That said, it would be possible to enable a Commander user-defined sequence to set a "current antenna" variable, the value for which would presumably be indicated in the sequence name; is that what you are suggesting?
+ As I understand them, RadioFocusNr and ActiveRadioNr are parameters employed in SO2R contesting, which is out-of-scope for DXLab. I suspect that IsStereo falls into the same category.
73,
Dave, AA6YQ

Re: New Command for UDP Broadcast

Larry K8UT <k8ut@...>
 

Stefan,

Wow - your band decoder/switch sounds wonderful. I also built one recently (www.hamprojects.info/freqez) which is not as sophisticated as yours, except mine detects whether the source of the UDP packets is DXLab or N1MM. When the packets are from N1MM it uses the N1MM configuration; when from DXLab it uses its own frequency-driven table to select various antennas. Perhaps that would work for you.

BTW - the UDP IsStereo tag is also for SO2V/R operation. It toggles between having the selected Active Radio in both ears (mono) or having the Left radio in Left ear and Right radio in Right ear (stereo).

-larry (K8UT)


On 2018-10-11 7:19 PM, Dave AA6YQ wrote:
+ AA6YQ comments below

Recently i build an WiFi antenna switch/tuner with 24 outputs and a Forward/Reflected power meter.
It has a WEB server, telnet server and UDP listener.
Information about operating frequency and antenna selected is extracted from N1MM+ UDP packet <TXFreq> and <Antenna> tags:
// N1MM+ UDP packet example:
http://n1mm.hamdocs.com/tiki-index.php?page=UDP+Broadcasts
<?xml version="1.0" encoding="utf-8"?>
<RadioInfo>
<StationName>HAMSHACK</StationName>
<RadioNr>1</RadioNr>
<Freq>714965</Freq>
<TXFreq>714965</TXFreq>
<Mode>USB</Mode>
<OpCall>AF6SA</OpCall>
<IsRunning>True</IsRunning>
<FocusEntry>395636</FocusEntry>
<Antenna>9</Antenna>
<Rotors></Rotors>
<FocusRadioNr>1</FocusRadioNr>
<IsStereo>False</IsStereo>
<ActiveRadioNr>1</ActiveRadioNr>
</RadioInfo>

N1MM+ allows for up to 16 antenna combinations on each frequency segment and it is working well for switching/tuning antennae in my station.

On other hand DXLab UDP is missing <Antenna> tag, limiting to only one antena combination per frequency segment.
// DXLabs UDP packet:
<?xml version="1.0" encoding="utf-8"?>
<RadioInfo>
<RadioNr>1</RadioNr>
<Freq>183821</Freq>
<TXFreq>183820</TXFreq>
<Mode>USB</Mode>
</RadioInfo>

It will be good to have a new command to fill and add <Antenna> tag, something like:
<UDPAntenna N> where N is the antenna number Addding <FocusRadioNr>, <ActiveRadioNr> and <IsStereo> tag's can make DXlab more compatible with N1MM+ users.


+ Commander provides no concept of "antenna selection". If such a concept were to be added, DXView would be the logical application, as it is responsible for antenna rotation. That said, it would be possible to enable a Commander user-defined sequence to set a "current antenna" variable, the value for which would presumably be indicated in the sequence name; is that what you are suggesting?

+ As I understand them, RadioFocusNr and ActiveRadioNr are parameters employed in SO2R contesting, which is out-of-scope for DXLab. I suspect that IsStereo falls into the same category.

73,

Dave, AA6YQ






Re: New Command for UDP Broadcast

Dave AA6YQ
 

* more AA6YQ comments below

+ As I understand them, RadioFocusNr and ActiveRadioNr are
parameters employed in SO2R contesting, which is out-of-scope for
DXLab. I suspect that IsStereo falls into the same category.
ActiveRadioNr would be equivalent to selected radio. RadioFocusNr would always be equal to ActiveRadioNr and IsStereo always off.

Selected Radio is already emitted for the SO2R (radio select) Serial Port along with the single antenna select value per band (ACC Outputs).

* Commander already emits <RadioNr> in <RadioInfo> packets. If <RadioFocusNr> and <ActiveRadioNr> are the same as <RadioNr>, what's the point?

... Joe, W4TV


On 2018-10-11 7:19 PM, Dave AA6YQ wrote:
+ AA6YQ comments below

Recently i build an WiFi antenna switch/tuner with 24 outputs and a Forward/Reflected power meter.
It has a WEB server, telnet server and UDP listener.
Information about operating frequency and antenna selected is extracted from N1MM+ UDP packet <TXFreq> and <Antenna> tags:
// N1MM+ UDP packet example: http://n1mm.hamdocs.com/tiki-index.php?page=UDP+Broadcasts
<?xml version="1.0" encoding="utf-8"?>
<RadioInfo>
<StationName>HAMSHACK</StationName>
<RadioNr>1</RadioNr>
<Freq>714965</Freq>
<TXFreq>714965</TXFreq>
<Mode>USB</Mode>
<OpCall>AF6SA</OpCall>
<IsRunning>True</IsRunning>
<FocusEntry>395636</FocusEntry>
<Antenna>9</Antenna>
<Rotors></Rotors>
<FocusRadioNr>1</FocusRadioNr>
<IsStereo>False</IsStereo>
<ActiveRadioNr>1</ActiveRadioNr>
</RadioInfo>

N1MM+ allows for up to 16 antenna combinations on each frequency segment and it is working well for switching/tuning antennae in my station.

On other hand DXLab UDP is missing <Antenna> tag, limiting to only one antena combination per frequency segment.
// DXLabs UDP packet:
<?xml version="1.0" encoding="utf-8"?>
<RadioInfo>
<RadioNr>1</RadioNr>
<Freq>183821</Freq>
<TXFreq>183820</TXFreq>
<Mode>USB</Mode>
</RadioInfo>

It will be good to have a new command to fill and add <Antenna> tag, something like:
<UDPAntenna N> where N is the antenna number Addding <FocusRadioNr>, <ActiveRadioNr> and <IsStereo> tag's can make DXlab more compatible with N1MM+ users.


+ Commander provides no concept of "antenna selection". If such a concept were to be added, DXView would be the logical application, as it is responsible for antenna rotation. That said, it would be possible to enable a Commander user-defined sequence to set a "current antenna" variable, the value for which would presumably be indicated in the sequence name; is that what you are suggesting?

+ As I understand them, RadioFocusNr and ActiveRadioNr are parameters employed in SO2R contesting, which is out-of-scope for DXLab. I suspect that IsStereo falls into the same category.

73,

Dave, AA6YQ








---
This email has been checked for viruses by AVG.
https://www.avg.com

Re: New Command for UDP Broadcast

Joe Subich, W4TV
 

On 2018-10-11 8:33 PM, Dave AA6YQ wrote:
* Commander already emits <RadioNr> in <RadioInfo> packets. If <RadioFocusNr> and <ActiveRadioNr> are the same as <RadioNr>, what's
the point?
If Commander already emits <RadioNr>, the third party hardware should
accept <RadioNr> as *both* <RadioFocusNr> and <ActiveRadioNr> and treat
<IsStereo> as False.

That makes DXLab and N1MM+ equivalent. The only question is whether you
want to add the capability of user selected alternate antennas for each
band. (If you do, please also add the ability to read the "antenna map"
(per band antenna options) and select from among those antennas using
the microHAM SO2R protocol (usable for Station Master and Station Master
Deluxe).

73,

... Joe, W4TV


On 2018-10-11 8:33 PM, Dave AA6YQ wrote:
* more AA6YQ comments below

+ As I understand them, RadioFocusNr and ActiveRadioNr are
parameters employed in SO2R contesting, which is out-of-scope for
DXLab. I suspect that IsStereo falls into the same category.
ActiveRadioNr would be equivalent to selected radio. RadioFocusNr would always be equal to ActiveRadioNr and IsStereo always off.
Selected Radio is already emitted for the SO2R (radio select) Serial Port along with the single antenna select value per band (ACC Outputs).
* Commander already emits <RadioNr> in <RadioInfo> packets. If <RadioFocusNr> and <ActiveRadioNr> are the same as <RadioNr>, what's the point?
... Joe, W4TV
On 2018-10-11 7:19 PM, Dave AA6YQ wrote:
+ AA6YQ comments below

Recently i build an WiFi antenna switch/tuner with 24 outputs and a Forward/Reflected power meter.
It has a WEB server, telnet server and UDP listener.
Information about operating frequency and antenna selected is extracted from N1MM+ UDP packet <TXFreq> and <Antenna> tags:
// N1MM+ UDP packet example: http://n1mm.hamdocs.com/tiki-index.php?page=UDP+Broadcasts
<?xml version="1.0" encoding="utf-8"?>
<RadioInfo>
<StationName>HAMSHACK</StationName>
<RadioNr>1</RadioNr>
<Freq>714965</Freq>
<TXFreq>714965</TXFreq>
<Mode>USB</Mode>
<OpCall>AF6SA</OpCall>
<IsRunning>True</IsRunning>
<FocusEntry>395636</FocusEntry>
<Antenna>9</Antenna>
<Rotors></Rotors>
<FocusRadioNr>1</FocusRadioNr>
<IsStereo>False</IsStereo>
<ActiveRadioNr>1</ActiveRadioNr>
</RadioInfo>

N1MM+ allows for up to 16 antenna combinations on each frequency segment and it is working well for switching/tuning antennae in my station.

On other hand DXLab UDP is missing <Antenna> tag, limiting to only one antena combination per frequency segment.
// DXLabs UDP packet:
<?xml version="1.0" encoding="utf-8"?>
<RadioInfo>
<RadioNr>1</RadioNr>
<Freq>183821</Freq>
<TXFreq>183820</TXFreq>
<Mode>USB</Mode>
</RadioInfo>

It will be good to have a new command to fill and add <Antenna> tag, something like:
<UDPAntenna N> where N is the antenna number Addding <FocusRadioNr>, <ActiveRadioNr> and <IsStereo> tag's can make DXlab more compatible with N1MM+ users.


+ Commander provides no concept of "antenna selection". If such a concept were to be added, DXView would be the logical application, as it is responsible for antenna rotation. That said, it would be possible to enable a Commander user-defined sequence to set a "current antenna" variable, the value for which would presumably be indicated in the sequence name; is that what you are suggesting?

+ As I understand them, RadioFocusNr and ActiveRadioNr are parameters employed in SO2R contesting, which is out-of-scope for DXLab. I suspect that IsStereo falls into the same category.

73,

Dave, AA6YQ


Re: New Command for UDP Broadcast

Dave AA6YQ
 

# more AA6YQ comments below

* Commander already emits <RadioNr> in <RadioInfo> packets. If
<RadioFocusNr> and <ActiveRadioNr> are the same as <RadioNr>, what's
the point?
If Commander already emits <RadioNr>, the third party hardware should accept <RadioNr> as *both* <RadioFocusNr> and <ActiveRadioNr> and treat <IsStereo> as False.

# Or I should just make the next version of Commander issue Radio messages with the <RadioFocusNr>, <ActiveRadioNr>, and <IsStereo> tags set as you suggest -- which would take about as much of my time as completing this sentence.

That makes DXLab and N1MM+ equivalent. The only question is whether you want to add the capability of user selected alternate antennas for each band. (If you do, please also add the ability to read the "antenna map" (per band antenna options) and select from among those antennas using the microHAM SO2R protocol (usable for Station Master and Station Master Deluxe).

# Where is this "antenna map" located? Are you referring to the "N1MM Rotator Selection by Band" panel that DXView displays on its Configuration window's "Rotator Control" tab when the Rotator Model is set to "N1MM Current" or "N1MM V12.11"?

73,

Dave, AA6YQ



On 2018-10-11 8:33 PM, Dave AA6YQ wrote:
* more AA6YQ comments below

+ As I understand them, RadioFocusNr and ActiveRadioNr are
parameters employed in SO2R contesting, which is out-of-scope for
DXLab. I suspect that IsStereo falls into the same category.
ActiveRadioNr would be equivalent to selected radio. RadioFocusNr would always be equal to ActiveRadioNr and IsStereo always off.

Selected Radio is already emitted for the SO2R (radio select) Serial Port along with the single antenna select value per band (ACC Outputs).

* Commander already emits <RadioNr> in <RadioInfo> packets. If <RadioFocusNr> and <ActiveRadioNr> are the same as <RadioNr>, what's the point?

... Joe, W4TV


On 2018-10-11 7:19 PM, Dave AA6YQ wrote:
+ AA6YQ comments below

Recently i build an WiFi antenna switch/tuner with 24 outputs and a Forward/Reflected power meter.
It has a WEB server, telnet server and UDP listener.
Information about operating frequency and antenna selected is extracted from N1MM+ UDP packet <TXFreq> and <Antenna> tags:
// N1MM+ UDP packet example: http://n1mm.hamdocs.com/tiki-index.php?page=UDP+Broadcasts
<?xml version="1.0" encoding="utf-8"?>
<RadioInfo>
<StationName>HAMSHACK</StationName>
<RadioNr>1</RadioNr>
<Freq>714965</Freq>
<TXFreq>714965</TXFreq>
<Mode>USB</Mode>
<OpCall>AF6SA</OpCall>
<IsRunning>True</IsRunning>
<FocusEntry>395636</FocusEntry>
<Antenna>9</Antenna>
<Rotors></Rotors>
<FocusRadioNr>1</FocusRadioNr>
<IsStereo>False</IsStereo>
<ActiveRadioNr>1</ActiveRadioNr>
</RadioInfo>

N1MM+ allows for up to 16 antenna combinations on each frequency segment and it is working well for switching/tuning antennae in my station.

On other hand DXLab UDP is missing <Antenna> tag, limiting to only one antena combination per frequency segment.
// DXLabs UDP packet:
<?xml version="1.0" encoding="utf-8"?>
<RadioInfo>
<RadioNr>1</RadioNr>
<Freq>183821</Freq>
<TXFreq>183820</TXFreq>
<Mode>USB</Mode>
</RadioInfo>

It will be good to have a new command to fill and add <Antenna> tag, something like:
<UDPAntenna N> where N is the antenna number Addding <FocusRadioNr>, <ActiveRadioNr> and <IsStereo> tag's can make DXlab more compatible with N1MM+ users.


+ Commander provides no concept of "antenna selection". If such a concept were to be added, DXView would be the logical application, as it is responsible for antenna rotation. That said, it would be possible to enable a Commander user-defined sequence to set a "current antenna" variable, the value for which would presumably be indicated in the sequence name; is that what you are suggesting?

+ As I understand them, RadioFocusNr and ActiveRadioNr are parameters employed in SO2R contesting, which is out-of-scope for DXLab. I suspect that IsStereo falls into the same category.

73,

Dave, AA6YQ


Re: New Command for UDP Broadcast

Stefan AF6SA
 

I probably took a shortcut and didn't explain properly... 
 
Back in the days i used LPT port to switch between 'Vertical' 'Deltaloop' and 'W8JK' antennae.
Band / antenna map was set in N1MM+ Configurer>Antennas tab.
Changing bands will switch antenna and using ALT-F9 you can select between available antennae for that band.
This information (TXFreq + Antenna code) is send with UDP packet.
 
In DXlab Commander i had defined a 'frequency-dependent' device named 'LPT'.
It was configured to set parallel port bits based on current TRX freq.
User-defined Control buttons where defined as follows:
[Auto]  <DataSignasEnable ON> // start automatic antenna selection using the frequency-dependant device
<LED 0, green> <LED 1, white>, <LED 2, white>,<LED 3, white> <End>
 
[W8JK]    <DataSignasEnable OFF> // stop automatic antenna selection
<ParData 0> // manually select W8JK beam
<LED 1, red> <LED 0, white> <LED 2, white> <LED 3, white> <End>
 
[DELTA]    <DataSignasEnable OFF> // stop automatic antenna selection
<ParData 160> // manually select delta loop
<LED 2, red> <LED 0, white> <LED 1, white> <LED 3, white> <End>
 
[GP]    <DataSignasEnable OFF> // stop automatic antenna selection
<ParData 128> // switch to vertical
<LED 3, red> <LED 0, white> <LED 1, white> <LED 2, white> <End>
 
This allows me to have 'AUTO' and 'MANUAL' antennae selection - just like in N1MM+ using same station setup.
 
The new WiFi switch/tuner uses 18bit for an L tuner(8bit C bank + 8bit L bank + 1bit Hi/Lo impedance and 1bit bypass).
Other 6 bits are dedicated for antenna switch.
All Frequency / Antenna number to 6bit antenna switch and 18bit LC tuner mappings are stored internaly.
You can have up to 16(limited by N1MM+ UDP <Antenna> tag) antenna/tuner combinations on each given frequency segment.
N1MM+ will send UDP packet including <TXFreq> and <Antenna> tags with antennae codes defined in Configurer>Antennas tab for that band.
Based on that frequency/antenna information, WiFi switch/tuner will set all 24bit (6 antenna select + 18 LC tuner) from its memory.  
Pressing ALT-F9 will cycle all available antenna codes for that band as defined in N1MM+.
DXlab currently is not sending the <Antenna> tag in UDP packets, WiFi switch/tuner will use the first antenna code found for that <TXFreq>.

@Dave AA6YQ
Antenna selection concept can be simulated with User-defined Control buttons - works great and thanks for that!
I'm suggesting to set <Antenna> UDP tag by User-defined Control buttons with a new command like:
 <UDPAntenna N> where N is the antenna number.
This will enable same functionality and compatibility with N1MM+.
Contesting with N1MM+ and DXing with DXlab using same station setup.
 
About the other SO2R tags in UDP packet...
The benefit of using UDP broadcast is that you can have many switches as you like.
Currently i have two:
  TunerV    -  that is the switch/remote tuner located in my backyard
  ShackSW -  A-B coax switch located in my shack. 
A goes to TunerV - 160M-40M antenae
B goes to house roof 20M-6M tri-bander + 6M addon
 
I'm planning to use ShackSW (or another one) to route my headset/mike between two radios for SO2R with N1MM+ by decoding <FocusRadioNr>, <ActiveRadioNr> and <IsStereo> tag's.
Implementing additional commands to handle those in DXlab commander will allow to use this setup.
It will be not real SO2R, but you can switch audio between RIG's with Commander buttons.
 
Hope that answers most of your questions... 
 
73 de Stefan / AF6SA
 

Re: New Command for UDP Broadcast

Dave AA6YQ
 

+ AA6YQ comments below

snip<
@Dave AA6YQ
Antenna selection concept can be simulated with User-defined Control buttons - works great and thanks for that!
I'm suggesting to set <Antenna> UDP tag by User-defined Control buttons with a new command like:
<UDPAntenna N> where N is the antenna number.
This will enable same functionality and compatibility with N1MM+.
Contesting with N1MM+ and DXing with DXlab using same station setup.

+ Wouldn't it be better to provide a User-defined Sequecce command that specifies the Name and Control of a frequency-dependent device whose current value should be emitted in the <Antenna> UDP tag ?


About the other SO2R tags in UDP packet...
The benefit of using UDP broadcast is that you can have many switches as you like.
Currently i have two:
TunerV - that is the switch/remote tuner located in my backyard
ShackSW - A-B coax switch located in my shack.
A goes to TunerV - 160M-40M antenae
B goes to house roof 20M-6M tri-bander + 6M addon

I'm planning to use ShackSW (or another one) to route my headset/mike between two radios for SO2R with N1MM+ by decoding <FocusRadioNr>, <ActiveRadioNr> and <IsStereo> tag's.
Implementing additional commands to handle those in DXlab commander will allow to use this setup.
It will be not real SO2R, but you can switch audio between RIG's with Commander buttons.

+ If Commander emits the same value for <FocusRadioNr> and <ActiveRadioNr> as it does for <RadioNr>, will that be acceptable?

+If Commander always emits <IsStereo>False</IsStereo>will that be acceptable?

73,

Dave, AA6YQ

Re: TQSL update available

Greg Waits
 

Thank you, Dave.  The blue number is 2.3.1
Greg

Re: TQSL update available

Joe Subich, W4TV
 

tQSL 2.3.1 (versions 2.2.0 - 2.3.1) has a bug that prevents it
from running the update installer directly. Download the
installer here: <http://www.arrl.org/tqsl-download> and run
it to install the newest version of tQSL (2.4.1).

73,

... Joe, W4TV

On 2018-10-12 6:25 AM, Greg Waits wrote:
Thank you, Dave.  The blue number is 2.3.1
Greg