Sunday, October 22, 2017

RBN Developments October 2017

Recently a friend suggested that FT8 was probably making a dent in
activity on the RBN and taking away from CW in general.  Out of
curiosity, I compared last week on the RBN (weekdays only, to avoid
contest activity) with the corresponding week in 2016, and was pleased
to see that the volume of RBN spots in 2017 was up about 8.4 percent
compared to the corresponding week in 2016.

Maybe growth would have been stronger if FT8 and WSPR had not been
introduced, but for a mature system near the bottom of the sunspot cycle
I think the continued upward trend is encouraging. The same week in 2016
was down 12.1 percent compared to 2015, which looks more like what I
would have expected this year.


I don't want to suggest that this is the last word.  I did not take into consideration 
the fact that the number of regularly-active RBN nodes increased year over
year during those two years.A much more accurate metric would to count the 
number of unique CQs reported by the RBN; I didn't do that.  Bottom line, though - 
the RBN is pretty healthy.

Looking ahead to the big DX contest weekends, Felipe made a change in
the data flow at our server this week to sharply reduce the number of
operations that need to take place after spots are received from RBN
nodes and before each individual spot is sent out. We are hopeful this
will improve the server's reliability and handling of large volumes of
spots, as well as reducing the delay in their being posted on retail
servers around the world.


Feedback would be appreciated. ARRL CW Sweepstakes will probably be the
first major test.


Friday, September 8, 2017

Beacons Revisited - a checklist

The recent initiative by the beacon folks at the NCDXF to spur competition among RBN nodes to copy all of the NCDXF beacons has prompted me to review our documentation of how to spot these beacons.  This checklist should help you set up your node to receive these beacons. You must do each listed step, or it will not work.

1.  Make sure your Skimmer or Skimmer Server is set up to cover the beacon frequencies. See this earlier blog post for the details.  Remember, you need to set both the frequency coverage and the CW decoding segments in order for Skimmer/Skimmer Server to do their thing.

2.  Create a watch.lst file containing the calls of all 18 beacons.  Details here.  Store it in the correct place.

3.  Set your Skimmer or Skimmer Server (on the Telnet tab) so that it does not send only CQ spots.

Once you have done these things, you're ready to spot the NCDXF beacons.  The Aggregator knows the callsigns, and will automatically append the NCDXF tag before sending the spot on to the RBN "mothership."


Wednesday, August 9, 2017

The RBN and the Solar Eclipse - Coming August 21

On August 21, 2017, from 1400 to 2200Z, operators of RBN nodes will have a unique opportunity to contribute to scientific understanding of the ionosphere.  That time-frame straddles the period when the solar eclipse will be visible across North America, and is also when the Solar Eclipse QSO Party will be run.


The RBN's unique contribution, in North America but also worldwide, is to provide as many data points as possible during the 1400-2200Z period.  In order to do this, two departures from our normal practice are needed:

1.  It is desirable for science to have much more frequent spots of stations active in the QSO Party than could be produced with the standard 10 minute respot interval. To this end, Alex has provided for adjustabilty in this respect in the current versions of CW Skimmer, CW Skimmer Server and RTTY Skimmer Server.  By adding a single line to the .ini file for your skimming software, you can adjust the respot interval anywhere from the original 10 minutes down to zero.  In the latter case, every repetition of a station's callsign will be reported (provided of course that the station includes CQ or TEST at least twice in each transmission).

2. The RBN archive is not the best source of the scientific data we hope to produce, because the timing is relatively imprecise (nearest minute).  So check your Skimmer computer for a file titled "spots.txt" , which will be found in C:\users\[your username]\Appdata\Roaming\Afreet\Products\Skimsrv.  The spots.txt file gives the time when a spot is actually made, to the nearest second. Regrettably, there is no comparable file in CW Skimmer. For Skimmer ops, your data are welcome too, even if still on a 10-minute scale - after all the eclipse period is hours long!


If you have been operating your node for a while, this file will be quite large - all that we need is 1400-2200Z on the 21st.  You can use a text editor to extract the part we need.  Look on the HamSci web site for the address to send your data to - it will be posted very soon now.

HamSCI is also looking for recordings of digital I/Q data from Skimmer receivers made during the duration of the Solar Eclipse QSO Party. This will allow HamSCI to replay and analyze recordings from specific receivers in greater depth following the contest. HamSCI will be publishing guides shortly on how this can be done with the QS1R or Red Pitaya and CW Skimmer Server, or with any SDR capable of sending data to CW Skimmer using its built-in recording function. Note that this will consume significant hard disk space - up to about 4GB per hour per band. The data will be accepted for upload after the contest.

If you're interested in putting your node to work on this project, you're still lacking one thing - the magic formula to put into your Skimsrv's ini file to generate more frequent, "granular" data.  Email me, and the secrets of the universe will be revealed.



I'm doing it this way because I want to have some reasonable confidence that people won't start using shorter interval settings with the RBN servers outside the eclipse period.  Even one Skimmer can make a big difference in this regard, and we will not hesitate to block anyone's spots from the RBN server if they violate this rule outside the eclipse period.

So c'mon - it'll be fun!