Date   

Re: LoTW download failure

nk4l
 

Same here Mike , Jose NK4L

On Monday, June 14, 2021, 12:11:08 PM EDT, Mike KC7V <mikekc7v@...> wrote:


I am getting a download failure message from LoTW this morning.  Anyone else experiencing this?

Mike

--
jose gonzalez


Re: LoTW download failure

Steve GW4BKG
 

Yes me too.
I can access the LOTW website and view my QSLs so it must just be the download function.
Steve
GW4BKG

On 14 Jun 2021, at 17:10, Mike KC7V <mikekc7v@...> wrote:

I am getting a download failure message from LoTW this morning.  Anyone else experiencing this?

Mike


Re: LoTW download failure

Rod Greene
 

Same here Mike, I tried it just now.

73, Rod/w7zrc

On Monday, June 14, 2021, 10:11:07 AM MDT, Mike KC7V <mikekc7v@...> wrote:


I am getting a download failure message from LoTW this morning.  Anyone else experiencing this?

Mike


LoTW download failure

Mike KC7V
 

I am getting a download failure message from LoTW this morning.  Anyone else experiencing this?

Mike


Re: does anyone know to where the New Zealand online callbook was moved?

David Westbrook
 

+ In the past, I reverse engineered the required data by using an application that captured the HTTP transaction when I manually queried the source using a web browser. The near-universal use of HTTPS - "secure HTTP" - makes that reverse engineering impossible, since the transactions are all encrypted. I can only develop new Pathfinder searches of HTTPS sites if the site owner documents required search parameters so that I can enable Pathfinder to issue them.

The encryption makes it impossible to reverse engineer if capturing the traffic in the middle of the network path,  but the browser devtools let you see exactly what the end client is submitting, and can determine from that how to construct the expected POST form payload.

While this callbook still may not be suitable for Pathfinder application, I was able to successfully write a script to lookup a callsign in the ZL callbook.  Unfortunately the form parameters are dynamically generated every page load, so there is not a static post data format  for pathfinder;  also there is not a single callsign field -- the prefix & suffix are separate fields in the form.

But in case it helps someone for reference, the methodology and code is below.  e.g. someone could write a little proxy server so that a simple url scheme like http://zl_callbook.example/com?callsign=zl2df   could be used, and it would do the needed logic & parsing below, and return the result.

I started at https://rrf.rsm.govt.nz/smart-web/smart/page/-smart/domain/licence/SelectLicencePage.wdk  to try and find ZL2DF, with no luck.
On that page, there's a nav item for "Search Register" -> "Search certificates and Callsigns"  and that worked! I could find ZL2DF.

Despite it being a HTTPS site,  I could still use browser devtools to capture the URL & payload.   When doing a search, the POST looks like this -- you can see the callsign fragments in the "S2175=ZL&S2178=FOLLOWED_BY&S2181=2DF" portion:

  -H "Connection: keep-alive" ^
  -H "Pragma: no-cache" ^
  -H "Cache-Control: no-cache" ^
  -H "sec-ch-ua: ^\^" Not A;Brand^\^";v=^\^"99^\^", ^\^"Chromium^\^";v=^\^"90^\^", ^\^"Google Chrome^\^";v=^\^"90^\^"" ^
  -H "sec-ch-ua-mobile: ?0" ^
  -H "Upgrade-Insecure-Requests: 1" ^
  -H "Origin: https://rrf.rsm.govt.nz" ^
  -H "Content-Type: application/x-www-form-urlencoded" ^
  -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36" ^
  -H "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9" ^
  -H "Sec-Fetch-Site: same-origin" ^
  -H "Sec-Fetch-Mode: navigate" ^
  -H "Sec-Fetch-User: ?1" ^
  -H "Sec-Fetch-Dest: document" ^
  -H "Accept-Language: en-US,en;q=0.9" ^
  -H "Cookie: JSESSIONID=J9XnzGOwoo85BGIINSKb69KztNOTaCsIc7v_wlPXhsSVMDezNpnh^!-1079729315^!1572164037; mf5=1290567109; _ga=GA1.3.140114273.1623091604; _gid=GA1.3.823959159.1623091604; visid_incap_1962811=x8WvtjTeRGy2c3BwMcd2edNqvmAAAAAAQUIPAAAAAAA0pUsAh03X6tRgob6pjT4Y; incap_ses_702_1962811=WCVXLkXHUS/qrFcCugG+CdRqvmAAAAAATQttjr42VYtDZf9fifF29A==; _gat=1" ^
  --data-raw "medClientHeight=&medClientWidth=&S2142=true&licenseeComponent=&S2154=&S2175=ZL&S2178=FOLLOWED_BY&S2181=2DF&S2205=CONTAINS&S2208=&S2220=STARTS_WITH&S2223=&locationComponent=&S2241=&S2262=&S2268=&S2118=0&S2121=0&p_access_no=&internal.wdk.wdkCommand=S2370&internal.wdk.wdkCommandArgument=&SMART_WDK_PAGE_CLASS=2XuReF7vs^%^2BbNOWTghTpzlYS2LjoiH9WkrVIjDjZ4XCCckpOWw8QyFfCJ2vsBI4dtWgwKqpg^%^2BBefpkJlY" ^
  --compressed

Inspecting the Response content,  can see the search results in a HTML table:

            <tr class="listEvenRow">
             <td class="">
              <a id="S32524" title="137786" onclick="dispatch('S32524');return false;" href="javascript:void(0);">137786</a>
             </td>
             <td class="">Mr N M HAYTON</td>
             <td class="">ZL2DF</td>
             <td class="">2857</td>
             <td class="">GAOC</td>
             <td class="">&nbsp;</td>
             <td class="">&nbsp;</td>
             <td class="">&nbsp;</td>
             <td class="">
              <a id="S32551" title="Amateur GURL" href="https://rsm.govt.nz/licensing/frequencies-anyone-can-use/amateur-radio-operators" target="_blank">Amateur GURL</a>
             </td>
            </tr>



then I headed to a long-time go-to personal favorite tool,  perl  and the WWW::Mechanize  module, which is a programmatic web browser (HTTP client).  Some trial and error, and looking at the HTML/javascript source of that callsign search page to figure out what it does on submit,  and I was able to get it to work;  Parsing the html for the search results name then yields the hits.    In appears that the search tool does a "starts with" method of matching,  so can get multiple results, but that could be filtered to the original request.

Here is the command-line POC in action:

$ ./zl.pl zl2df
$VAR1 = {
          'Callsign' => 'ZL2DF',
          'Name' => 'Mr N M HAYTON'
        };
$ ./zl.pl zl2dx
$VAR1 = {
          'Callsign' => 'ZL2DX',
          'Name' => 'Mr C C HANNAGAN'
        };
$VAR1 = {
          'Callsign' => 'ZL2DXR',
          'Name' => ' DAVID HINDSON'
        };

And the perl source code:

#!/usr/bin/perl

use strict;
use warnings;
use HTTP::Cookies;
use WWW::Mechanize;
use Data::Dumper;
$|=1;

my $callsign = shift @ARGV or die 'need callsign, e.g. ZL2DF';

my ($pfx, $sfx) = uc($callsign) =~ /^(ZL|ZK|ZM)(\d.+)$/;

my $cookie_jar = HTTP::Cookies->new;    # in-memory cookie jar
my $mech       = WWW::Mechanize->new( cookie_jar => $cookie_jar );


my @inputs = $mech->current_form()->inputs;
foreach my $i ( 0 .. $#inputs ){
  my $v = join ' ', $inputs[$i]->possible_values;
  # Find the prefix dropbox -- it's the element with ZK, ZL, ZM as possible options.
  if ( $v =~ /\bZK\b/ && $v =~ /\bZL\b/ && $v =~ /\bZM\b/ ){
    $inputs[$i]->value($pfx);                   # Set the search prefix we want
    $inputs[$i+1]->value('FOLLOWED_BY');        # the next consectutive form element is the "Followed By"/"Contains" dropbox
    $inputs[$i+2]->value($sfx);                 # and the next consectutive form element is the search suffix.
    last;                                       # done setting callsign values
  }
}


# the "submit" isn't a form element button -- it's a link.
# Need to emulate javascript that takes the "Search" link id, and sets it in a form field.
my $link = $mech->find_link( text => 'Search' );
my ($submitId) = $link->attrs->{onclick} =~ /'(.+)'/;
$mech->submit_form(with_fields=>{ 'internal.wdk.wdkCommand'=>$submitId });

use HTML::TableExtract;
my $te = HTML::TableExtract->new( headers => [ qr/Name/, qr/Callsign/ ] );
$te->parse( $mech->content );
my $table = $te->first_table_found;
my @c = map { s/^\s+|\s+$//g; $_ } $table->hrow;
foreach my $row ($table->rows) {
  my %h;
  @h{@c} = @$row;
warn Dumper \%h;
}

73!
--david
K2DW (ex-KJ4IZW)


On Sun, Jun 13, 2021 at 8:35 PM Dave AA6YQ <aa6yq@...> wrote:
+ AA6YQ comments below

I have been following this up with the NZART Administration Officer.  (NZART is NZ's ARRL)     He points out that your search query is not directed to the Government Radio Spectrum Management (RSM) site but to a NZ ham's site that of ZL3AME.       This site appears to have been inactive since about 2008.      I have not been able to find any contact information for ZL3AME to confirm this

The correct site is
Search the Register of Radio Frequencies (RRF) | Radio Spectrum Management New Zealand (rsm.govt.nz) <https://www.rsm.govt.nz/licensing/how-do-i/use-the-rrf/search-the-rrf/>

Could you look here and see if you can extract the information you need. 

+ Thanks, Nigel, but that documentation explains how a user would access the information with a web browser; it does not explain how an application like Pathfinder can emulate a web browser by providing the required search parameters in the required order. For the evidently now defunct ZL3AME callbook, Pathfinder sent this "post data"

callsign={TargetCallsign}&Search+SMART=Submit

+ to this URL:

http://www.happy.geek.nz/cgi-bin/nzartsmartquery.py

+ In the past, I reverse engineered the required data by using an application that captured the HTTP transaction when I manually queried the source using a web browser. The near-universal use of HTTPS - "secure HTTP" - makes that reverse engineering impossible, since the transactions are all encrypted. I can only develop new Pathfinder searches of HTTPS sites if the site owner documents required search parameters so that I can enable Pathfinder to issue them.

       73,

                Dave, AA6YQ










Re: Commander & K3s

Jim Denneny
 

Thanks Joe.  I have had flawless communication between Commander and  K3s for a long time.  I have a new pc.  Suddenly, Commander is only able to read VFO A - not VFO B nor mode.  Commander is unable to control radio. Commander is running WSJT OK. I have checked Port setting by Device Manager (com 8, 38400, 8, None 1, None).  Radio settings look correct.  I must get past this issue before moving forward.  I really appreciate your response and I will read the wiki looking for a clue.

Jim


Re: does anyone know to where the New Zealand online callbook was moved?

Dave AA6YQ
 

+ AA6YQ comments below
I will persevere with my NZART contact.
+ Thanks, Nigel.

       73,

              Dave, AA6YQ


Re: Commander & K3s 6M

Joe Subich, W4TV
 

On 2021-06-13 8:09 PM, Jim Denneny wrote:
WSJT-x beta is responsible for reported 6M issue.
There is nothing wrong with the WSJTX beta. I've been using
it with Commander and my K3 since it was released with no
issues (much less on 6M).

However. Commander continues to be unable to sync mode from K3S
You have a configuration issue or a serial port conflict. I
strongly suggest you go over the configuration document that
I pointed you to earlier and go over it multiple times until
you work out your issue.

73,

... Joe, W4TV


On 2021-06-13 8:09 PM, Jim Denneny wrote:
WSJT-x beta is responsible for reported 6M issue.  However.  Commander continues to be unable to sync mode from K3S
jim K7eg


Re: does anyone know to where the New Zealand online callbook was moved?

Nigel ZL2DF
 

I will persevere with my NZART contact.     Unfortunately government departments are not known for being generous with favours or free information.

73,

Nigel, ZL2DF


Re: does anyone know to where the New Zealand online callbook was moved?

Dave AA6YQ
 

+ AA6YQ comments below

I have been following this up with the NZART Administration Officer. (NZART is NZ's ARRL) He points out that your search query is not directed to the Government Radio Spectrum Management (RSM) site but to a NZ ham's site that of ZL3AME. This site appears to have been inactive since about 2008. I have not been able to find any contact information for ZL3AME to confirm this

The correct site is
Search the Register of Radio Frequencies (RRF) | Radio Spectrum Management New Zealand (rsm.govt.nz) <https://www.rsm.govt.nz/licensing/how-do-i/use-the-rrf/search-the-rrf/>

Could you look here and see if you can extract the information you need.

+ Thanks, Nigel, but that documentation explains how a user would access the information with a web browser; it does not explain how an application like Pathfinder can emulate a web browser by providing the required search parameters in the required order. For the evidently now defunct ZL3AME callbook, Pathfinder sent this "post data"

callsign={TargetCallsign}&Search+SMART=Submit

+ to this URL:

http://www.happy.geek.nz/cgi-bin/nzartsmartquery.py

+ In the past, I reverse engineered the required data by using an application that captured the HTTP transaction when I manually queried the source using a web browser. The near-universal use of HTTPS - "secure HTTP" - makes that reverse engineering impossible, since the transactions are all encrypted. I can only develop new Pathfinder searches of HTTPS sites if the site owner documents required search parameters so that I can enable Pathfinder to issue them.

73,

Dave, AA6YQ


Re: Commander & K3s 6M

Dave AA6YQ
 

+ AA6YQ comments below

WSJT-x beta is responsible for reported 6M issue. However. Commander continues to be unable to sync mode from K3S

+ Jim, your sequence of recent questions began with your report of having to install DXLab on a new computer because your previous computer failed:

https://groups.io/g/DXLab/message/201873

+ Do you not have a backed up copy of a Workspace containing all of your DXLab application settings from when everything was working to your satisfaction?

73,

Dave, AA6YQ


Re: Sending every received WSKTX spot to Telnet

Dave AA6YQ
 

I mean the main display that comes up when spotcollector is invoked from DXlab Launcher.

+ Thanks, Rick. SpotCollector's Main window does not display spots, it displays entries in the Spot Database. As described in

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

+ the Spot Database contains one entry for each active station in a particular mode near a particular frequency; the Source column contains the callsign of the station that most recently spotted the Entry's callsign. SpotCollector harvests information from incoming cluster spots, packet spots, the DX Summit web cluster, and local instances of WSJT-X to create and populate the entries in this database, which can be viewed chronologically in a table, on chart whose axes are frequency and time, on a Bandspread, on a Spectrum-Waterfall (panadaptor), or on a World Map. The above article describes this in detail and is pretty much required reading for new users, as no other amateur radio application provides this functionality. For DXers, it provides DXlab's most powerful capabilities for finding and working needed DX. If you have questions about how this works, don't hesitate to post them here.

+When your instance of WSJT-X running FT8 on 14074 decodes a station C, or decodes a station R reporting that it has decoded a station C, SpotCollector either updates the existing Spot Database Entry for C in FT8 on 14074 (with C's grid square, SNR, and the location of the station that decoded C), or creates and populates a new Spot Database Entry for C in FT8 on 14074 if such an entry doesn't already exist. No outgoing spot is sent to the DX Cluster network.

+ The only ways to generate an outgoing spot are by using the "Outgoing spot" panel at the top of SpotCollector's Main window, by using the Spot button in DXKeeper's Capture window (to spot a station you're about to log), or by using the Spot button in the "QSO Info" panel on WinWarbler's Main window (to spot a station you're about to log). See

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

73,

Dave, AA6YQ


Re: Commander & K3s 6M

Jim Denneny
 

WSJT-x beta is responsible for reported 6M issue.  However.  Commander continues to be unable to sync mode from K3S

jim K7eg


Re: does anyone know to where the New Zealand online callbook was moved?

Nigel ZL2DF
 

Dave,
I have been following this up with the NZART Administration Officer.  (NZART is NZ's ARRL)     He points out that your search query is not directed to the Government Radio Spectrum Management (RSM) site but to a NZ ham's site that of ZL3AME.       This site appears to have been inactive since about 2008.      I have not been able to find any contact information for ZL3AME to confirm this

The correct site is 
Search the Register of Radio Frequencies (RRF) | Radio Spectrum Management New Zealand (rsm.govt.nz)

Could you look here and see if you can extract the information you need.      I have also been told that RSM are in the process of changing to a completely new database but when is uncertain.

73,
Nigel  ZL2DF


Re: Removing worked callsigns from bandspread

Warren Dean <fclass308@...>
 

Thanks for the clarification
--
Cheers!

Warren
KA7ESE


Re: Removing worked callsigns from bandspread

Rick Samoian <ricksamoian@...>
 

Hi Dave
I have sent U an email directly of the screen I am talking about..........de Rick

On 6/13/2021 3:34 PM, Dave AA6YQ wrote:
I have been through the online help and searched the archives for info on this.

How do I set up having DX Lab remove a spot from bandspread after I have worked it? N1MM does it and it is handy.

+ If you work a "needed"  station with whom a QSO would advance your progress from an award you are pursuing, DXKeeper will change its font color to reflect the change in status. 

+ If you have the "Spot Filter" panel set to "Need" on the Bandspread tab of Commander's Configuration window, then the Bandspread panel will only display callsigns that are "needed" for an award you are pursuing; logging a QSO with such a callsign would cause it to disappear fomr the Bandspread window because it's no longer needed.

+ There is no award for working every possible callsign, so there is no way to configure DXLab to stop displaying a callsign in the Bandspread window just because you logged a QSO with it.

+ N1MM is a contesting application; DXLab is a DXing application.

         73,

                Dave









Commander & K3s 6M

Jim Denneny
 

Currently, Commander and WSJT-x misread radio on 6. Commander is designated radio for WSJT.   Both indicate  50.313 initially, After a short period WSJT display shows a 10M freq. A short time later, Commander displays same 10M frequency. However 6M is decoding VHF Contest sigs on 6M. Strange.  Also, Commander does not read  radio mode correctly.  I must manually select U.  I am running a WSJT beta release.   I have posted this also on WSJT reflector.  I did slow down baud rate and lengthened polling to 1000ms.

If this persists, I will switch to WSJT full release followed by discontinuing use of Commander for radio in WSJT.  This would cause problems using WSJT and N1MM+ in contests.  I may switch WSJT out of beta first to isolate issue.

Jim K7EG


Re: Sending every received WSKTX spot to Telnet

Rick Samoian <ricksamoian@...>
 

I mean the main display that comes up when spotcollector is invoked from DXlab Launcher........de Rick

On 6/13/2021 1:37 PM, Dave AA6YQ wrote:
+ AA6YQ comments below

And thanks for the immediate response.

1. I have JTAlert on the computer, but I don't "believe" it is in control.  What should I search to determine that?

+ If JTAlert is running and configured as described in

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

+ then it is "in control".

+ If you have configured DXLab and WSJT-X for direct interoperation, as described in

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

+ then JTAlert is not involved.

2. The reason I'm say I'm posting is, the spots are listed in the received pane of my spot collector.  

+ By "received pane", do you mean the Main window's "Spot Database Display", or do you mean the "Spot Source" windows made visible when you uncheck a spot source's Hide checkbox on the Configuration window's "Spot Surces" tab?

       73,

               Dave, AA6YQ








Re: Removing worked callsigns from bandspread

Dave AA6YQ
 

I have been through the online help and searched the archives for info on this.

How do I set up having DX Lab remove a spot from bandspread after I have worked it? N1MM does it and it is handy.

+ If you work a "needed" station with whom a QSO would advance your progress from an award you are pursuing, DXKeeper will change its font color to reflect the change in status.

+ If you have the "Spot Filter" panel set to "Need" on the Bandspread tab of Commander's Configuration window, then the Bandspread panel will only display callsigns that are "needed" for an award you are pursuing; logging a QSO with such a callsign would cause it to disappear fomr the Bandspread window because it's no longer needed.

+ There is no award for working every possible callsign, so there is no way to configure DXLab to stop displaying a callsign in the Bandspread window just because you logged a QSO with it.

+ N1MM is a contesting application; DXLab is a DXing application.

73,

Dave


Removing worked callsigns from bandspread

Warren Dean <fclass308@...>
 

I have been through the online help and searched the archives for info on this.

How do I set up having DX Lab remove a spot from bandspread after I have worked it? N1MM does it and it is handy.
--
Cheers! and 73

Warren
KA7ESE

2881 - 2900 of 204790