Back to working on the beacon project

I know it has been forever since I started the Arduino beacon project and while the functionality is 90% or better complete, the project has been on the shelf for a very long time.  Between family illness, work issues and the like, ham radio has taken a bit of a holiday.

Today I drug out the beacon hardware and spent some time reviewing the software.  I made sure I could still build the code and flash the device with the image.  All is well in that department.  I spent some time tidying things up a bit in the code and removing some edge case failures.

I have reduced the functionality of the software to three modes:

1. Signal Generator - General purpose, turn the dial, set the frequency mode.
2. WSPR beacon
3. QRSS beacon

There is also a real-time clock setting mode, but that is more of a utility.

The WSPR beacon has preprogrammed all defined WSPR frequencies from 500 kHz to 50 mHz.  A single button push will cycle through all of the WSPR frequencies and sets the beacon to the centre of the band.  From there, the rotary dial will allow adjustment down to 1 Hz.

The QRSS beacon transmits on whatever frequency is set on the dial.  The beacon continually transmits until the operating mode is changed.

There are a few things to do yet to finish off version 1 of this project.

1. WSPR mode needs to allow adjustment of the TX percent value as well as the call sign and power level.  Currently it requires recompiling the code to change these values.  The TX percent value is not currently respected and the beacon currently transmits once and then enters IDLE mode until WSPR mode is reselected.

2. QRSS mode needs to allow changing the QRSS message without recompiling the code.

I think at this point the code could be declared V1 complete.  A few lower priority changes might be the definition of V2.

1. The WSPR beacon should have a mode where it cycles through all 12 WSPR bands.  The challenge here of course would be to create a 12 band antenna system from 500 kHz to 50 mHz.

2. Allowing finer control of the frequency with the rotary encoder.  Currently the resolution is 1 Hz.

3. Automatic saving/restoring of all settable parameters in EEPROM.

I am going to try and get V1 completed by the time our QRP group meets this Wednesday.  It will be a bit of a challenge, as I need to finish the packaging of the hardware, but will give it a go.

Working with new tool chain

As the Arduino beacon project has progressed, I have spent some time trying to minimize the code size.  For one thing, there are a number of components that the beacon project does not need that are drug into the final image.  To do this I have moved away from the Arduino IDE for development of this project.  I am using the GNU AVR tool chain now.  I copied all the headers and code files from Arduino install and have been modifying them to eliminate components that I do not need.  For example I don't need the serial port stuff, string classes, interrupt classes, etc.  Rather than use generic port libraries, I am moving to talk directly to the ports instead.  These kinds of changes have netted me 6-8 kb of space savings.  I need to hack on the wire libraries to eliminate the stuff I am not using.  Lastly, the Arduino boot loader is no longer necessary as I am using an in-circuit programmer (usbTinyISP) from the good folks at AdaFruit.  This saves another 0.5 kb at the upper end of flash.  The optiboot boot loader is pretty small, but others are not so compact.  All things considered, the savings in code size are significant.  Lastly, the tool chain is available for Windows, Linux and Mac platforms, so I think I will stick with it.

Converting from Arduino IDE is pretty straight forward:

1. Add #include "WProgram.h" to the top of your sketch.
2. Add a main() function at the bottom that calls setup() and loops calling loop() infinitely.
3. Provide forward declarations for all of your functions.
4. Create a Makefile to drive the build process if desired (recommended).

I copied all the components from my project into a new folder and built a Makefile to compile and link everything.  Now I can hack on the Arduino components referenced in my Beacon project without affecting my Arduino IDE environment.

New RTC and data logging shield for beacon project

I have built one of the fine data logging shields for Arduino from the fine folks at Adafruit to further clean up my beacon project rats nest.  The new setup looks like this attached to my Arduino Uno.

I need to add a socket for the DDS-60 and a couple headers to bring data GPIO lines out.  The real-time clock has been tested and is functional.  This should be my final setup until a PCB is created for this project.

Trying to spruce up the Arduino beacon project

The Arduino WSPR/QRSS beacon project has gotten to the point where it is time to try and get rid of some of the rats nest of the breadboard nature of the project so far.  To that end, I have mounted the controls and display in a panel.

Next, I will be eliminating the breadboard and using a data logger shield for the Arduino.  This shield has an SD card slot (which I do not need) as well as the same real-time-clock (RTC) I chose for my beacon project the DS1307.  There is also some breadboard space available to mount a socket for the DDS-60 and any other associated discrete components I may need.  This should tidy things up sufficiently to allow the software components to be finalized.

After the software bits are complete (as much as any software project ever is) I will be producing a PCB for the entire project.

So far, my project has grown a bit bloated as I have allowed myself to be sidetracked on numerous occasions by additional modes such as Feld Hell.  I have added some test code to experiment in geneating Hellschrieber-like displays on a QRSS waterfall such as we have in Spectran or Argo.  The resultant bloat has put the code size beyond the code size limit of the ATMega168.  Since I am using an Arduino Uno with the 328 chip, this has not been a problem, but it does increase the expense of this project for others to duplicate or leverage the code.  I will have to work on that and will try to get the code size as small as possible in the final versions.  Things like my choice to do frequency calculations for the DDS using 64 bit integers has no doubt drug in the entire 64 bit math library whereas I only need one operation.  Obviously many opportunities exist for further optimization.

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...

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).