QRSS/WSPR band befuddlement...

I know that on 30 metres, the dial frequency of 10.1387 plus
1300 Hz is the bottom of the QRSS band and plus 1400 Hz is the bottom of the WSPR
band.  Is this true on all bands?

Here are the WSPR dial frequencies(USB) for everything below
60 MHz (limit of the DDS-60) according to http://www.wsprnet.org.

// WSPR standard frequencies

// Shown are the dial frequencies plus 1500 Hz to put in the
// middle of the 200 Hz WSPR band

long rgWSPRFreq[] =

{
    502400 + 1500,    // 500 KHz
   1836600 + 1500,    // 160 meters
   3592600 + 1500,    //  80 meters
   5287200 + 1500,    //  60 meters
   7038600 + 1500,    //  40 meters
  10138700 + 1500,    //  30 meters
  14095600 + 1500,    //  20 meters
  18104600 + 1500,    //  17 meters
  21094600 + 1500,    //  15 meters
  24924600 + 1500,    //  12 meters
  28124600 + 1500,    //  10 meters
  50293000 + 1500     //   6 meters
};

enum

{
  WSPR500KHZ, WSPR160M, WSPR80M, WSPR60M,
  WSPR40M, WSPR30M, WSPR20M, WSPR17M,
  WSPR15M, WSPR12M, WSPR10M, WSPR6M
};

So, as I have defined them, I can set the DDS frequency to
the centre of the WSPR band with the array above.  Are these WSPR/QRSS
band relationships consistent across all these bands as they are on 30M ?

I see from the KnightQRSS blog that there appears to be a more scattered set of standard frequencies, though I am not certain I understand the decision making process and therefore don't have much confidence in this list:

* 137.6 - 137.8 kHz
* 1.8432
* 3.500, 3.575, 3.579, 3.5999
* 7.000, 7.0402, 7.0599
* 10.140
* 14.000, 14.0989, 14.31818
* 18.1089
* 21.000, 21.1489
* 24.9289
* 28.000, 28.188, 28.322
* 50.294,400-600

On a side note, the 60 metre WSPR frequency surprises me as I thought only USB transmissions are available on 60 metres.  Granted, most people typically inject tones into their SSB transceiver to transmit WSPR.  What you get out when you do that however is FSK, so I am not so certain WSPR on 60 metres makes sense.  What did I miss?

On a similar note, it is a bit "funny" to note the number of times I hear computer annunciation beeps and even an occasional VOIP phone call or MP3 tracks that makes its way into the SSB transceiver MIC input when in digital modes in "non-voice" portions of the ham bands, especially 30 metres...

I2C LCD performance

I am a bit disappointed in the performance of the Arduino LCD driver, especially with the I2C interface enabled.  I am not sure how much time I want to spend optimizing the standard Arduino libraries, especially since a beacon in operation really doesn't need a display.  Realistically, it is just convenient for me while developing this project.  I think what I will do is just optimize the display usage to only update what actually changes rather than repainting everything whenever anything changes.  If that is insufficient, I will turn off the frequently updated portions of the LCD when doing time critical operations such as when transmitting signals with critical timing criteria such as WSPR.

WSPR Beacon update

Now that I have liberated GPIO pins for the RTC clock, I have incorporated it into my breadboard design.  I have the code to the point where it will begin transmitting on the next even minute.  I now need to implement the TX percent control, however I am uncertain what it means.  Obviously, TX percent set to 100% will transmit every 2 minute window and 0% will not transmit at all (Idle).  However, what does 50% mean?  Does it mean I will transmit every other 2 minute window?  Don't think so, but not sure...  I did see one online reference that 20% means transmitting every 10 minutes or so.  This came from the WSPR 2.0 user manual.  Here is that text:

WSPR uses two-minute time slots for transmitting and receiving. The slider labeled

Tx fraction sets the average proportion of time allocated for transmitting. The default setting of 20% is a good compromise under typical conditions: it means that you will transmit approximately once every ten minutes and receive the rest of the time. The exact T/R sequence will be randomized so as to maximize your chances of receiving other WSPR stations. For receive-only operation, set the Tx fraction slider to zero

My brain refuses to understand this for some reason...

I think what is intended here is the following:

transmit time = (1/transmit percent) * 2 min

If I round this up to the nearest integer, the following transmit times result:

100% - every 2 minutes
90% - every 4 minutes
80% - every 4 minutes
70% - every 4 minutes
60% - every 4 minutes
50% - every 4 minutes
40% - every 6 minutes
30% - every 8 minutes
20% - every 10 minutes
10% - every 20 minutes
0% - never transmit

I am not sure this is precisely what Joe Taylor intended, but I think it will be adaquate for the beacon project.  I will further randomize the precise amount of time between transmissions up to the calculated value to better match what Joe Taylor suggests for minimizing collisions between transmitting stations.

GPIO Liberation

I have been endeavoring to liberate I/O pins on my Arduino project.  To that end, I have moved to an I2C LCD interface.  This is necessary to enable integration of an RTC (real-time clock) for WSPR timing.  The new setup looks like this:

I have some concerns about the performance of the LCD driver so I may have to do some customization of the driver.  The good news is that the beacon in operation is unlikely to have or need a display or rotary encoder as the set of operational frequencies will be fixed.  Calibration of the DDS-60 can be accomplished with a test setup that includes a rotary encoder to set the clock and then disconnected for day-to-day operation.

So, hopefully I can get the RTC integration done soon and have a fully functional WSPR/QRSS beacon breadboard completed.

Many thanks to the good folks at Adafruit for the excellent work on the I2C LCD interface.

WSPR Beacon with Arduino and DDS-60

Today I got my WSPR beacon code running for the most part.  I have the WSPR encoding all done and the Symbol transmission bits are complete.  The setup is the same as for the previous post.

I added a WSPR mode to the controller software and can trigger the transmission manually at this point.  Watching the received signal on Spectran, I can see the normal WSPR four tone pattern.  The test however is can Joe Taylor's fine WSPR program decode what I am transmitting?  I am happy to say the answer is yes!  Click on the image below for a full size version that can be read.

I am using just a cheap Grundig G6 receiver which only has 1 KHz resolution on the dial.  Since the entire 30 metre WSPR band is only 200 Hz wide, I used Spectran to set received audio tone to around 1450 Hz.  With Joe Taylor's application set with a dial frequency of 10.138.700 this put me in the band.  I then waited for an even minute to come around and pushed a button to initiate the WSPR transmission.  As you can see above, it decoded just fine!  Whoo hoo!

So, now I need to implement the RTC clock in order to have transmissions begin 2 seconds into even minutes and to implement the percent of the time the beacon is transmitting.

Geting close to having a software solution on breadboarded hardware.  It will then be time to build a custom PCB hardware solution.

QRSS with a DDS-60

I have been having fun messing around with an old DDS-60 board that I obtained some time ago.  I have cabled it up to the Arduino.  Here is the setup:

The DDS-60 is plugged into the Arduino breadboard.   I have a small four line LCD display on a separate board below.  The LCD is certainly not necessary for this project, but is nice to have.

Looking at the DDS-60 output on around 10 MHz, we see a nice clean signal.

A little more code and we have a simple QRSS beacon putting out about 1.4 V peak-to-peak signal into a 50 ohm load.  Hooked up a simple Grundig G6 portable radio and cabled the audio out to the computer audio in.  Using Spectran, we can see the 6 hertz FSK signal on 10.140 Mhz sending my call sign (KO7M).