KO7M - Ham Radio Blog

Update to Propeller keyer/transmitter

2012-03-03T17:11:00.001-08:00

After getting some much needed feedback on my keyer implementation, I have done several revisions to the keyer software, shortly to be posted on gitHub. Here is the current revision history list.

Revision History
----------------
Rev 1.1 - Thanks to Eldon, WA0UWH for pointing out a logic flaw in my
           sendData method
Rev 1.2 - Updated to make into a proper object. Implemented get/put methods.
Rev 1.3 - Implemented Iambic A and Iambic B modes and one element memory.
          Made Iambic B mode default
Rev 1.4 - Added bug mode (dits are automatic, dahs are not)
            Added straight key mode (dit key input keys transmitter manually)
            Added initPins(dit, dah, key, rf) to allow setting of pin assignments.
          Defaults to 0, 1, 2, 27
            Added public method swapPaddles to allow switching dit and dah paddles

I think the keyer is in pretty good shape now. I welcome any feedback on version 1.4 from anyone that may find it useful. Reminder that with the addition of proper low pass filters, this code functions as a full fledged CW transmitter for ham radio usage. Power output is approximately 5-7 mW putting it squarely in the QRP category. See my previous blog post for a simple amplifier to raise the output power sufficiently for beacon or CW operation.

Working on the lab/shack today

2012-03-03T17:00:00.000-08:00

Still trying to reclaim my shack from the clutches of ever expanding clutter. Managed to get the corner of one work table cleaned off and the microscope, hot air rework and soldering stations up and running.

I keep the LCR metre and signal tracer close at hand. Nice to have one place to do close work again. I cannot stress sufficiently my opinion that purchasing whatever equipment you need in order to be able to clearly see what you are doing is critical to your ability to enjoy electronics and ham radio hobbies.

Propeller Receiver

2012-02-28T19:26:00.001-08:00

In a previous blog posting I have demonstrated an extremely simple transmitter / keyer implementation on the propeller platform. The next logical step was to build a receiver to go with it.

What I have implemented is a very simple direct conversion receiver based on the NE602 Gilbert Cell mixer and a LM386 audio amplifier. The circuit is based on the famous sudden receiver design from the Rev George Dobbs G3RJV many years ago and looks something like this:

My implementation removes all the tuned circuit stuff from pins 6 and 7 of the NE612 (NE602 in my circuit) and injects the RF generated by the propeller via a blocking capacitor directly into pin 6 to set the receive frequency.

Here is a photograph of the lash-up with the receiver built manhattan-style on a little 5x7 cm PCB scrap.

Right now I am sitting here listening to a 75 metre net running on 3.98 MHz LSB (The Oregon Emergency Net).

Obviously, I have a lot of work to do on user interface code...

Now as you might well imagine, there are a number of problems with playing at RF frequencies with bits of wire lashing all the bits and pieces together stuck into protoboards. For example, I had to move the RF pin as far from the encoder pins as I could in order to not confuse the encoder code. The frequency kept changing on its own until I turned off the RF. There is a fair amount of "hash" in the receiver audio being generated by the LCD controller chip. But as far as a proof-of-concept impelementation, I could not be happier.

With this success, I plan to put together a complete (simple) all-band transceiver using a propeller as the controller as well as RF generation component for both the transmitter oscillator as well as the local oscillator for the receiver.

Rotary Encoders on Propeller

2012-02-27T23:30:00.000-08:00

This evening, I have been playing with Eldon's code to handle rotary encoders. Works nicely as long as the encoder inputs to the propeller have pull-up resistors and a capacitor to ground to make a little integrator. Helps with debouncing the encoder output.

So far the LCD driver is working nicely for both I2C displays and parallel displays. Eldon seems to have switched over to using mine.

I will next work up some code to use the encoder for frequency selection. Everyone else is well beyond this point, but I have focused mostly on the WSPR encoder solution whilst everyone has been continuing on with UI and other concerns. I will catch up here soon...

Propeller LCD and RTC work (cont.)

2012-02-26T23:55:00.002-08:00

In a previous post, I mentioned that I was working on an I2C LCD driver. I have decided to support both I2C and parallel interfaces to common LCD displays that utilize the popular Hitachi HD44780 controller chip.

This work is largely completed at this point although there is some clean-up work to be done. One of the dilemmas I face is the question of how to implement cursor positioning. It is simple enough to envision an API that sets the cursor to some row/column pair, but should those rows and columns be zero-based or one-based values?

I have worked forever on systems wherein all such values are zero based. There does appear to be however some precident for using one-based values. For the moment, I have implemented two APIs, one that is zero-based and the other one-based. Perhaps that is an acceptable, albeit confusing solution.

I welcome any thoughts anyone might have on the topic.

Propeller Beacon on the air on 30 metres

2012-02-25T11:58:00.001-08:00

I am waging war on the amount of clutter in my shack this weekend. It has gotten to where I could hardly get in the place. I have put the propeller beacon up on 30 metres on WSPR, QRSS and Opera. It runs on a 10 minute cycle, WSPR first, QRSS then Opera and then it waits for the end of the 10 minute cycle and repeats.

Let me know if you "hear" it on the air.

Propeller LCD and RTC work

2012-02-23T00:35:00.000-08:00

Sorry for no updates for a while as I have been ill unfortunately. Starting to feel better now however so I am back playing around with propeller. I have a DS1307 real-time clock module (RTC) and the I2C LCD module from my Arduino beacon project that I have been wanting to get working.

The RTC was a complete no-brainer, it just works. I plan to use it to allow atonomous operation of my beacons that need accurate time information such as WSPR.

The LCD however was a bit of a problem as I am not happy with the display drivers that are out there and have not found an acceptable I2C implementation for any display that I care for.

So, I ported the driver I was using for Arduino to spin and have it working now at least at a macro level. I have not tested the functionality fully yet. I am quite pleased with the initial performance.

The plan is to make a rather comprehensive driver that will work with either I2C or parallel mode, though I only will be using I2C. Above you can see it driving my 20 character by 4 line display. The I2C bit is implemented in the driver via bit-banging. This allows the driver to be independent of any other I2C library. The SDA and SCL pins can be specified with the default to share the I2C pins with the EEPROM.

On other fronts I am putting together a low pass filter module that uses six relay selectable low pass filters for the HF Bands 160 - 10 metres. 10 bands are covered with 6 filters. Attenuation in the stop band should exceed -40dB. I anticipate using an 8 bit I2C I/O expander, six bits of which will be used select the appropriate filter for the following bands: 160, 80, 60/40, 30/20, 17/15, 12/10 metres. I anticipate using the remaining bits for transmit/receive switching and antenna auto-tuner control. More to come on this.

Keyer / Transmitter bugs found by Eldon, WA0UWH

2012-02-18T12:58:00.000-08:00

In my previous post about my Propeller keyer / transmitter, my friend Eldon has been kind enough to point out a logic error that I had in my sendData code. The effect of the bug would be felt if you attempted to change the pin numbers that the dit and dah paddles were connected to. Nice catch Eldon!

I have updated the code to fix this error. At the same time, at Eldon's suggestion, I have also updated the code to make it more of a spin object. I have added start and stop methods that allow it to run on a separate cog. I have also made most of the keyer parameters externally readable and writeable by adding get and put methods for each. For example the frequency can be read or written with getFreq/putFreq. Have a look at the code for the entire list of get/put functions. I also renamed the file from keyer.spin to ko7mKeyer.spin in order to try and avoid naming conflicts.

Eldon has implemented a UI in front of this code using a propeller USB prototype board. Here is his implementation. Pretty nice, I think. He can change the frequency and keyer speed through his rotary encoders and display everything on an LCD. Nice little transmitter, Eldon.

FM Receiver with Propeller

2012-02-15T21:29:00.000-08:00

Today I received by the evening post a package containing a little break-out board containing an RDA5807SS FM receiver chip. This is a very cute little module that implements a complete FM sterero receiver.

The device sports a standard 3.5mm stereo audio jack on the top.

Hookup is completely trivial with only I2C SDA/SCL pins, VDD/VSS power connections. Four wires and you are done. Could not be simpler, no soldering involved unless you want to.

Fun little project, if you want immedicate success, give it a go! I leave it playing in the background whilst I work on other programming projects. The product information page at the Parallax site is here where you can find all the documentation as well.

Iambic Keyer / Transmitter update

2012-02-15T08:05:00.000-08:00

I have posted a simple update to the keyer / transmitter project on Github. The change allows you to specify which sideband you wish to use for the transmitter offset. You specify the frequency the receiver will use and how much you want to offset your transmit frequency. The idea is to be able to hear your own transmitter in the receiver as a sidetone. By default I use 600 Hz offset from the receiver frequency. When I drop down below 30 metres, I typically use lower sideband (LSB) and offset 600 Hz below the receiver frequency and on 30 metres or above, I offset 600 Hz above. This can now be changed by setting the sideband value to LSB or USB as appropriate. Previously to achieve the same effect, you would have had to change the toneOffset value to +600 or -600 as appropriate.

Propeller Iambic Keyer or Transmitter

2012-02-12T01:39:00.000-08:00

I have put together a simple keyer or CW transmitter using the Parallax Propeller board. This is sample code that you may find useful for your own experimentation.

To use as a keyer, set Frequency to zero and attach a keyer circuit to the pin defined by keyPin. I suggest using a 2N7000 or VN10 to drive most modern commercial CW transmitters. Something like this should be adequate. The code supports active high or active low keying.

A speaker can be used on RFPin in this mode to allow hearing a sidetone if desired. By default a 600 Hz tone should be heard. A two paddle key is attached between ditPin/dahPin and ground. I use P0, P1 for the paddle, P2 for the keyer output and P27 for RF/Speaker output. Please change to suit your needs.

To use as a transmitter, set Frequency to the transmit frequency. A 600 Hz offset is used by default to allow the transmitter to be heard in the receiver as sidetone. Change the toneFreq constant if you wish to have a different offset. Change ErrorOffset to correct for any transmit frequency error your propeller may experience. This tuning to set the ErrorOffset value should only need be done once by zero beating a frequency standard such as WWV.

A low pass filter for the transmit frequency should be connected to RFPin in order to clean up the square wave output sufficiently to meet regulations about signal purity. I recommend a minimul of a 5 pole filter as described in earlier posts.

Currently only Iambic Mode A is supported. Future versions will include the ability to set the keyer parameters such as keying speed, character speed, frequency and RF pin assignments as well as changing Iambic modes via the paddles.

Here is a photograph of the current lash-up with my Vibroplex paddles hooked to P0 and P1.

The source code can be obtained from https://github.com/ko7m/Keyer. As always comments and suggestions are solicited.

A very interesting chip

2012-02-09T06:30:00.000-08:00

I have been poking around looking at floating point processors and have come across a very interesting chip that I have bookmarked for future investigation, the Micromega uM-FPU64. So far I have not been able to find anyone with stock on this chip other than the earlier V3.1 32 bit version. For USD25.00 in single unit quantities, this is quite the bargain.

Features

64-bit and 32-bit Floating Point

A comprehensive set of 64-bit and 32-bit floating point operations are provided.
See the uM-FPU64 datasheet for details.

64-bit and 32-bit Integer

A comprehensive set of 64-bit and 32-bit integer operations are provided.
See the uM-FPU64 datasheet for details.

User-defined Functions

User-defined functions can be stored in Flash memory. Flash functions are programmed through the SERIN/SEROUT pins using the uM-FPU64 IDE. A high level language is supported, including control statements and conditional execution.

Matrix Operations

A matrix can be defined as any set of sequential registers. The MOP instruction provides scalar operations, element-wise operations, matrix multiply, inverse, determinant, count, sum, average, min, max, copy and set operations.

FFT Instruction

Provides support for Fast Fourier Transforms. Used as a single instruction for data sets that fit in the available registers, or as a multi-pass instruction for working with larger data sets.

Serial Input / Output

When not required for debugging, the SERIN and SEROUT pins can be used for serial I/O. A second asynchronous serial port, with hardware flow control, is also available as a local device using the DEVIO instruction.

NMEA Sentence Parsing

The serial input can be set to scan for valid NMEA sentences with optional checksum. Multiple sentences can be buffered for further processing.

String Handling

String instructions are provided to insert and append substrings, search for fields and substrings, convert from floating point or long integer to a substring, or convert from a substring to floating point or long integer. For example, the string instructions could be used to parse a GPS NMEA sentence, or format multiple numbers in an output string.

Table Lookup Instructions

Instructions are provided to load 32-bit values from a table or find the index of a floating point or long integer table entry that matches a specified condition.

MAC Instructions

Instructions are provided to support multiply and accumulate and multiply and subtract operations.

A/D Conversion

Multiple 12-bit A/D channels are provided (six on 28-pin device, nine on 44-pin device). The A/D conversion can be triggered manually, through an external input, or from a built-in timer. The A/D values can be read as raw values or automatically scaled to a floating point value. Data rates of up to 10,000 samples per second are supported.

Real-Time Clock

A built-in real-time clock is provided, for scheduling events or creating date/time stamps.

Timers

Timers can be used to trigger the A/D conversion, or to track elapsed time. A microsecond and second timer are provided.

External Input

An external input can be used to trigger an A/D conversion, or to count external events.

Foreground/Background Processing

Event driven foreground/background processing can be used to provide independent monitoring of local peripherals. The microcontroller communicates with the foreground, while background processes can be used to monitor local device activity.

Local Device Support

Local peripheral device support includes: RAM, 1-Wire, I2C, SPI, UART, counter, servo controller, LCD, and VDrive2 devices. The uM-FPU64 can act as a complete subsystem controller for GPS, sensor networks, robotic subsystems, IMUs, and other applications. Local devices are assigned to digital I/O pins at run-time, and controlled with the DEVIO instruction.

Low Power Modes

When the uM-FPU64 chip is not busy it automatically enters a power saving mode. It can also be configured to enter a sleep mode which turns the device off while preserving register contents. In sleep mode the uM-FPU64 chip consumes negligible power.

Firmware Upgrades

When updates become available, the uM-FPU64 firmware can be upgraded in the field using the uM-FPU64 IDE software.

WSPR Encoder - Version 1

2012-02-07T11:48:00.000-08:00

Updated this posting 8 Feb 2012

I have decided not to release my WSPR encoder for Propeller on the Object Exchange at the Parallax web site and instead I created a Github project repository for it. I am releasing it free of charge under the same MIT License that is used at the Object Exchange however.

You can obtain the files at https://github.com/ko7m/WSPR. Looking at this web page, you will see the following:

By clicking on any of the files you can examine them or you can get it all in one go by clicking on "ZIP" near the top and it will bundle up a zip archive and push it down to you.

As always, I welcome feedback or questions. I hope you find it useful.

Another flying diversion

2012-02-06T12:46:00.000-08:00

Last week was a total bust for me mostly due to being sick all week. I think I get to blame my grandson for the cold I caught and the associated sinus infection.

Saturday however was one of those phenomenal clear sky, million-mile visibility days with low wind speeds. I decided that if I had to hire someone to fly me, I was going to take to the skies.

Fortunately, a good buddy of mine has a 1948 NAvion L-17-B and had a shout out to anyone wanting to ride along. Sold! My poor little super cub will have to stay in the hanger a little longer until my head is more clear I am afraid.

We left our home field (Harvey Field - S43) in Snohomish, WA and flew to the Olympic Penninsula and cruised the length of Hood Canal stopping for lunch at Shelton (KSHN) at the cafe in the parachute jump centre.

Hood canal runs against the east side of the Olympic Mountains, which I think are particularly beautiful.

After a nice lunch, we decided to head on out to the Pacific Ocean coast and head north. We flew the length of the Washington coast from about Pacific Beach all the way to Neah Bay.

The wind was a bit brisk onshore as evidenced by the breakers on the shallow beach.

We had to circle a few islands off the coast. Pretty rugged coastline with very few options for an emergency landing.

Here we are rounding the bend around Tatoosh Island off Cape Flattery. This is the most north-western point of the United States. I am actually surprised that any of these pictures turned out because as we made this turn, we were just getting slammed around by the wind. Thousands of miles of Pacific Ocean winds from Canada and the Washington coast converging and trying to stuff through the Straits of Juan de Fuca. We picked up a lot of ground speed as we turned east down the Straits.

Looking back south down the Pacific Coast. Sun is dropping towards the horizon.

Crossing Puget Sound from the West, Mt. Rainier in the distance about 10 miles from Harvey Field. On days like this, there is no finer place to fly than the Pacific Northwest.

If you would like to see all of my pictures of the trip, here is a link. About three hours of flying and endless beauty.

WSPR Encoder for Propeller - Update

2012-02-06T09:49:00.000-08:00

I have decided to implement the main interface to the WSPR encoder such that you just pass in a single string containing the WSPR message you desire to encode. The object will return a pointer to a byte array containing the symbol set for that message. So the calling sequence will look like this:

OBJ
WSPR : "ko7mWSPREncode"

VAR
LONG Symbols

Symbols := WSPR.encodeWSPR(string("KO7M CN87 27"))

I think this will be the most intuitive and least error prone. The returned value will point to an array of 162 bytes containing the symbol set.

VAR
BYTE ich

repeat ich from 0 to 161
sendSymbol(BYTE[Symbols][ich])

You can reference each byte with byte[Symbols][<index>] or you can treat the entire thing as a single string.

sendSymbols(Symbols)

Things may change again, but I think this is the direction I am going. I plan to publish the final encoder in the Propeller Object Exchange at the Parallax site. I am investigating this opportunity now.

Learned something new about Spin

2012-02-04T23:36:00.000-08:00

I did a little study related to my previous post where I was befuddled about parameter passing in Spin for the Propeller. To review...

Passing parameters to a method looks like this

VAR
BYTE a
WORD b
LONG c

foo(a, b, c)

On the receiving end, we declare foo like this

PUB foo(x, y, z)

This is confusing to me when compared to other languages. On the calling end, I can declare the size of the data. I am passing a byte, word and long to foo. On the receiving end, x, y and z are all longs. Furthermore, if you declare any local variables, they are longs too. For example:

PUB FOO(x, y, z) | i, j, k

So, when you pass a parameter, regardless of the size of the data, it is first converted to a long and the called method will receive it as a long.

However, you can also pass an address as a parameter. Remember, my example was passing my callsign, locator, power and the symbol table to my encodeWSPR method. This example is working:

VAR
BYTE sym[162]

OBJ
WSPR : "ko7mWSPREncode"

WSPR.encodeWSPR(string("KO7M "), string("CN87"), 27, @sym)

While this version yielded different results:

DAT
mycall BYTE "KO7M ", 0
myloc BYTE "CN87", 0
mypwr BYTE 27

WSPR.encodeWSPR(@mycall, @myloc, @mypwr, @sym)

The issue here is that I am trying to make this same method handle two different format parameters. Namely, the third parameter is the WSPR power setting. In the first example, I am passing the value 27 in the parameter list. This gets converted to a long and assigned to the third parameter in the call to encodeWSPR. It then needs to be treated as a long value in the method. In the second example, I am passing the address of a byte containing the power value. The address gets converted to a long and assigned to the third parameter. In the method, I have to then treat it as the address of a byte rather than as a long value. For example:

encodeWSPR(call, loc, power, sym) | pwr

pwr := BYTE[power]

So, the reason my encodeWSPR was returning different results is that I was using the power parameter in different ways while the method was expecting to receive a long containing the value, not the address of it. Bonehead...

So, I have to decide which way it is going to be as it cannot be both in the same method. I can provide other methods that allow either kind of parameter to be passed or separate methods to set each parameter even. My inclination is to pass the power by value rather than by reference. Any preferences?

WSPR Encoder for Propeller Beacon Update

2012-02-04T00:35:00.000-08:00

Well, after a bit of hair tearing, I have managed to get my WSPR encoder running on the propeller platform. I am doing some cleanup of the code and will post it as soon as I have completed the changes. I implemented it as a separate object, so to use it you would do something like this:

VAR
   BYTE sym[162]
OBJ
   WSPR : "ko7mWSPREncode"

This declares a byte array to hold the encoded WSPR symbol set and includes the WSPR encoder in your code. You would then call this WSPR object to encode your call, locator and power setting and provide the address of the sym BYTE array so it can fill it up with your message. Typically this would be done in your initialization code.

WSPR.encodeWSPR(string("KO7M "), string("CN87"), 27, @sym)

Then in you would in your main loop send each symbol returned.

PUB Main | iSym
doInitialize
repeat
    repeat iSym from 0 to 161
      sendSymbol(sym[iSym])
    noTone
    Sync := nextSync
    repeat while SecondCnt // Sync
      delay(100)

Pretty simple and it works quite well. I have a couple of caveats that are important in the current implementation.

Only standard WSPR messages are supported currently. No six digit locators or calls with prefixes or suffixes such as KO7M/5 or JA2/KO7M. I have more work to do to support these special message formats.
Call signs must be exactly 6 characters and the third character must be a numeric. This is according to Joe Taylor's specifications. The point of this is that my routine does not do any error checking to be sure you passed in the call sign with the numeric aligned in the third character and that it is padded with spaces to make it exactly 6 characters. You will need to attend to this in the parameter you pass to encodeWSPR or the results will not be predictable. For example, my call is passed as KO7M<space><space>. If you had a call like one of the special even calls of "K7S", it would need to be passed in as <space>K7S<space><space>. I may attend to this in future versions if I get inspired to do the work.

I also ran into a caveat that I cannot yet explain. I am looking for insights into why this is happening.

If I pass the parameters like so:

DAT
mycall BYTE "KO7M ", 0
myloc BYTE "CN87", 0
mypwr BYTE 27

WSPR.encodeWSPR(@mycall, @myloc, @mypwr, @sym)

The results are not encoded correctly. Changing to use the "string("...") format rather than BYTE data block constants with exactly the same data shown above works correctly. So, you will have to stick to this format until I figure out why there is any difference. Any thoughts on this from any of you propeller hackers out there appreciated.

WSPR Encoder for Propeller Beacon

2012-02-03T11:36:00.000-08:00

In my previous post, I was thinking out loud about my WSPR encoder for the propeller-based beacon project. Dave, G4FRE posted a couple of comments, one of which was quite useful entitled WSPR Coding Process and was instrumental in enabling me to fix my WSPR encoder implementation. I was in fact encoding the locator incorrectly. This document gives the following information for locators:

Locator

Designating the four locator characters as [Loc 1] to [Loc 4], the first two can each take on the 18 values ‘A’ to ‘R’ only so are allocated numbers from 0 – 17. The second pair can take only the values 0 – 9.

Another integer M is formed from:

M1 = (179 - 10 * [Loc 1] - [Loc 3] ) * 180 + 10 * [Loc 2] + [Loc 4]

Which gives a range of values from ‘AA00’ = 32220 to ‘RR99’ = 179, which comfortably fit into a 15 bit representation (2^15 = 32768), leaving spare codes for further enhancements.

The useful bit here was the information that AA00 = 32220 and RR99 = 179. The algorithm above is not quite correct however. The corrected form should be:

M1 = (179 - 10 * ([Loc 1]-10) - [Loc 3] ) * 180 + 10 * ([Loc 2]-10) + [Loc 4]

This appears to give me the correct results for these end cases, so assuming that useful bit is accurate, I should be good to go. I will be testing against the WSPR application and posting the final code bits for those interested very soon.

WSPR Encoder - "Thinking Out Loud"

2012-02-02T23:54:00.000-08:00

I have been pondering why my WSPR encoder routine could be giving me incorrect results. When I encode my message "KO7M CN87 27" and let the WSPR 2.11 application decode it, I get the following:

<...> KO7M 27

In reading the specification, I see the following:

Special Message Formats

Normal WSPR messages consist of a callsign, 4-digit grid locator, and power level in dBm. These messages are always preferred when appropriate. However, compound callsigns (i.e., callsigns with add-on prefix or suffix) cannot fit into the 28 bits allocated in a standard message. Similarly, 6-digit locators cannot fit into 15 bits. Messages using these components are therefore sent using a two-transmission sequence. For example, if the callsign is PJ4/K1ABC, the 6-digit grid locator is FK52UD, and the power level 37 dBm, the following messages will be sent in alternating transmissions:

PJ4/K1ABC 37
<PJ4/K1ABC> FK52UD 37

If you have special need to use a 6-digit locator with a normal callsign, check the box

Force transmission of 6-digit locator. If the callsign is K1ABC, the 6-digit grid locator FN42AX, and the power level 37 dBm, the following messages will then be sent in alternating transmissions:

K1ABC FN42 37
<K1ABC> FN42AX 37

Callsigns enclosed in angle brackets are actually sent as 15-bit hash codes. If such a code is received by another station before the full callsign has been received, it will be displayed as

<...>

on the decoded text line. Once the full callsign has been received, the decoder will thereafter recognize the hash code and fill in the blanks. Two very different callsigns might have the same hash code, but the 15-bit hash-code length ensures that in practice such collisions will be rare.

Please note that messages with compound callsigns or 6-digit locators will not be properly decoded by WSPR versions earlier than 2.0. Further details on message formats can be found in Appendix B, and in the WSPR source code.

Hmmm... So, if I am reading this correctly, in a normal format message, I am supposed to encode the message as follows:

28 bits encodes a normal 6 character callsign
15 bits encodes a 4 character locator
7 bits encodes the power in dBm.

The special message format from the description above encodes in two messages, the content depends on the format of the data being encoded and whether or not the "Force transmissions of 6-digit locator" checkbox is set to "checked".

Case 1:
Callsign with slash character in it
In this case, the normal (up to) 6 character callsign is augmented with a slash character (front or back) and up to 3 additional characters. For example WA0FOO/7, JA2/KJ7ABC, etc. The 28 bit callsign field and the 15 bit locator are large enough to contain this data while the power is sent in its own normal 7 bit field. Here is my hypothesis:

When encoding WSPR messages, a the callsign field is required to have no more than 6 characters and is required to have a numeric in the third character position. If the callsign does not match these specifications, spaces are added as neeed. For example, "K7XX" is encoded as "<space>K7XX<space>". This I have previously proven before the special formats where encorporated into WSPR.
When encoding a special format callsign, I believe that the "/" character and up to three additional characters must be encoded in the 15 bit locator field while the normal callsign is encoded in the callsign field padded with spaces as necessary.
The power level goes in the normal 7 bit field.
The first message contains the special callsign and power level only.
The second message packs up to 6 digits of a locator, space padded as needed into the normal 28 bit callsign field. A 15 bit hash of the callsign is computed and sent in the 15 bit locator field. The power is sent normally in its 7 bit field.

This case should allow for adorned callsigns as well as six character locators to be sent in two messages max.

Unanswered Questions

Can the application can detect when decoding whether the callsign adornment belongs on the left or right side of the call? For example: JA2/WA0AAA vs. WA0AAA/JA2. I think this could be stored in the encoding of the "/" character.
What is the precise encoding of the "/" character?
Precisely how to calculate the 15 bit hash of the callsign?

Case 2:
Normal unadorned callsign (no slash) and 6 character locator
In this case the first message is a normal message with the extra 2 characters of the locator truncated as indicated in the documentation reference above. My hypothesis about the remainder of the message is:

The six digit locator is encoded into the 28 bit callsign field.
The 15 bit hash is computed of the callsign and sent in the locator 15 bit field.
The 7 bit power field contains the power level in dBm.

My code to encode the WSPR message doesn't know anything about special formats (yet) but is generating a symbol set that is decoding as if it was the second message a two message set, very much as would be found in case 2 above. Joe Taylor's spec says that any callsign enclosed in <...> characters is sent as a 15 bit hash. This points to the locator being incorrectly encoded. The message I am sending is being decoded as:

<...> KO7M 27

This tells me that my call sign and power are both being encoded correctly because WSPR can decode them. Since the encoding between the callsign and the locator fields is a different algorithm, the callsign must be encoded correctly and placed in the correct 28 bit callsign field of the WSPR message. What appears to be wrong is the locator encoding.

The results would match case 1 above, if WSPR thought the locator field was a 15 bit hash, not a locator and that it has not yet received the first message of the two message set. WSPR would then display precisely what I am seeing.

So, this little exercise has served to narrow my focus to the encoding of the locator field. I must have some sort of logic error in this part of the code.

More to follow.

Much better WSPR map

2012-02-02T19:37:00.000-08:00

After letting the new power amplifier run on the Propeller WSPR beacon today, I see a much more lively WSPR map:

I expect as the sun as set here that activity will wane during the evening ours, but I plan to let it run overnight to see how we get on.

Propeller WSPR Beacon Power Amp Results

2012-02-02T12:23:00.000-08:00

This morning I finished up my beacon power amp by putting in the low pass filter. I had a bit of a struggle with that however, as I had no capacitors that would work for the 5 pole filter in hand. I ended up with some rather significant changes in values in my substituted capacitors. The filter modeling still showed that I would barely meet a 40 dB supression of the harmonics, so some additional work is needed here before I can call this complete.

The final breadboard looks like this:

The Propeller Beacon with it's outboard low pass filter is putting in a nice clean signal to the input.

Checking the output with the spectrum analyzer, I can see that the harmonics are 40 dB down or better (but just barely).

So, hooking this up to the matched antenna and measuring the power output, I got found that I was putting out a solid 2 watts.

This is pushing things quite a bit and the transistor finals were getting quite warm. I backed off the bias on the driver until the power dropped to about 500-600 mW.

It seems happy at this level and the entire amplifier draws about 160 mA at this setting at 12 V.

So, we let a WSPR transmission happen on the next even minute and were immediately rewarded:

So, I am quite pleased with the initial results. I have (subsequently) changed my power setting reported to correctly reflect my new power level. More work to be done to clean up the harmonic supression to have some more margin. I am seeing some fluctuation in SWR that appears to be related to the effects of harmonics, so more work to do, but for now we are on the air at around 27 dBm.

Update on Power Amplifier

2012-02-01T21:26:00.000-08:00

Um... Ok... I lied... It is just plain ugly construction...

But, hey... We are trying to prove a concept, right? :) Well, time to see if I can let the magic smoke out of it... I have not built the output 5 pole filter yet, there will be time for that once things check out a bit.

I hooked up the 12V current limited supply and with the current limit just above the minimum current shutoff, slowly turned up the voltage to 12 VDC and there was no current draw. So far so good.

Next I hooked up a dummy load, scope to the output and my beacon on the input. Here is the lashup:

I had set the bias pot all the way down. With the beacon supplying about 1.2 V of signal to the input, I slowly adjusted the bias until the finals kicked in. There is a noticeable threshold effect from the unbiased output stage, but it kicked in at about 2.1 VDC of bias. I ran it up to around 2.8 VDC and the current limiter kicked in (remember it is set to turn off at a very low current value. For the moment I have bias set a 2.75 VDC and am seeing this on the output. Remember there are no low pass filters yet in place and the bias is just rough set. Pretty ratty looking, rather terrible really but about 5.5 V P-P into 50 ohms. There is no skipping a low pass filter on this device.

This is would represent about 75 mW, given the unfiltered output. There is quite a bit of energy going to harmonics with this waveform and we really have not explored the bias setting or allowed the entire amp to consume more than about 6 mA, so the finals are not even getting slightly warm yet. More testing to come.

So, it's time to build a low pass filter and do some more adjustments and performance tuning.

Note to self: Gorilla glue sucks... Don't use it for breadboarding circuits...

More power for Propeller Beacon

2012-02-01T18:51:00.000-08:00

While I have enjoyed the few WSPR spots I have received:

I have received no QRSS or Opera spots at all. There are times when I think (wishfully) that I see my 5 mW QRSS trace on remote grabbers, I have not been able to definatively say that I see my signal. So, I think it is time to bring the power level up to a more respectable 10-20 dBm.

I have been scouting around for some interesting designs that I might actually have parts for. I have a boatload of 2N7000 devices, so my focus has been in this area. After some searching I have decided to try out the following design taken from the Wee Willy DSB rig described over on the "popcorn" site.

Don't know how well this is going to work out, but you never know until you try it, so off I go. I am going to build this dead-bug style with a little Manhatten style thrown in for good measure. I even went out and picked up a fresh super-glue tube. Unfortunately, I got it home only to discover that it is a solid mass. Rats...

So, I had to resort to Gorilla glue, unfortunately. It will elongate my building time a bit as it takes a while to dry. But we are building again after a long hiatus.

So, I will post the build progress and performance results as I go. Should be fun!

Propeller Beacon Update

2012-01-31T19:19:00.000-08:00

I have taken the baseline beacons that I have created for QRSS, WSPR and Opera and put them together into a single beacon.

WSPR is on a 10 minute cycle (TX Percent = 20%). QRSS follows and just sends my call sign. Opera then follows and the remainder of the 10 minute cycle is idle. WSPR goes first because it has the even minute starting time requirement.

I have created each of the beacons as separate objects that the main beacon code can instantiate and call. The main beacon code looks like this:

CON
_CLKMODE = XTAL1 + PLL16X
_XINFREQ = 5_000_000
WMin     =       381        'WAITCNT-expression-overhead Minimum

OBJ
WSPR : "ko7mBeaconWSPR"
QRSS : "ko7mBeaconQRSS"
Opera : "ko7mBeaconOpera"
Clock : "ko7mClock"
Freq : "Synth"

VAR
LONG Sync

PUB Main
doInitialize
repeat
    WSPR.doBeacon               ' 2 minutes (110.6 seconds) for WSPR
    delay(10000)                ' Delay 10 seconds before doing QRSS
    QRSS.doBeacon               ' QRSS is about 3 minutes
    delay(10000)                ' Delay 10 seconds before doing Opera
    Opera.doBeacon              ' Opera is about 3 minutes
    repeat while Clock.getSeconds // Sync
      delay(100)

PUB doInitialize
Sync := 10 * 60               ' Beacons cycle every 10 minutes
Clock.Start

PUB delay(Duration)
waitcnt(((clkfreq / 1_000 * Duration - 3932) #> WMin) + cnt)

The beacon is up and running as of now. I would love to have any reports if anyone is able to spot any of my three beacons.

Randomizing WSPR TX Percent - revisited

2012-01-31T08:46:00.000-08:00

After 12 hours or so of experiencing my recent changes to how often my WSPR beacon transmits, I have decided that I am not happy with the results. As mentioned in my previous posting my recent changes have redefined TX Percent to mean the maximum amount of time that the beacon will wait between transmissions. This is not quite right because as you can see it results in an aweful lot of transmissions when the intent is to transmit "about every 10 minutes" when TX Percent is set to 20%.

I think clearly that the intent from Joe Taylor's WSPR documentation is that we actually transmit approximately every 10 minutes in this case, but that we randomly choose which 2 minute window in that 10 minutes to transmit.

So, to implement this, I need a couple of time values. The transmission time calculated from TX Percent and a randomly chosen two minute interval in that timeframe. The nextSync calculation will need changing to first wait for the randomly chosen period to arrive, transmit the symbol stream and then a wait for the remainder of the time calculated by TX Percent. The modified code looks like this:

PUB nextSync : s
s := ROUND(1.0 / TXPercent * 2.0)    ' Calculate when next occurs in minutes
case interval
    Random:
      s := (||?Rnd // s)               ' Randomize the result
      interval := Calculated           ' Next time use the calculated value
    Calculated:
      s -= (Sync / 60)                 ' Wait the remainder of calculated time
      interval := Random
s += (s // 2)                        ' Send on a 2 minute boundary
s *= 60                              ' Convert minutes to seconds

The overall effect of this is going to be to randomize the first transmission start time whilst the second will always land on the calculated TX Percent time slot. So, every other transmission will be exacly 10 minutes aligned at TX Percent of 20%.

I am not certain this is exactly what I want either, but I will give it a go and see how I like the new effect. If it does not suit me, I will go with choosing a random slot in the 10 minute window, then waiting until the end of the 10 minute window and choosing a new random slot in the next 10 minute window. The potential negative on that solution is that we could wait up to 20 minutes if the random generator chose the first 2 minute slot and then chose the last 2 minute slot in the next 10 minute window. Sort of the opposite problem I currently have. Anyone have any thoughts on this?

After much ado about nothing, I have settled on the following implementation (as much as anything is ever "settled"):

PUB nextSync : s
s := ROUND(1.0 / TXPercent * 2.0)    ' Calculate when next occurs in minutes
if interval++ & 1
    s := (||?Rnd // s) + 1             ' Randomize the result
s += (s // 2)                        ' Aalways send on a 2 minute boundary
s *= 60                              ' Convert minutes to seconds

The effect is clear enough. I randomize every other transmission. Simple enough and not being such a hog of WSPR bandwidth. The interval variable is a BYTE value that gets incremented every time we calculate the next transmission time. The least significant bit determines if we use a random or calculated next transmission time.

<Insert 3/4 of a day delay here>

So, I have reverted back to a mode where I transmit every N minutes based on TX Percent calculation only. I decided I really didn't like having the randomizing in there and have commented it out. There is sufficient randomness of folks using the same TX Percent value starting at different 2 minute timeslots and then carrying on at a consistent period for my liking. If I find I am syncing with another station that I want to copy, I can delay my start by a time slot and solve the problem that way. Bit of a wasted exercise, but so be it.

Microscope for the bench

2012-01-31T00:46:00.000-08:00

I have fought long and hard, mostly with my own pride and have finally admitted to myself that my eyesight is not what it once was. The first indication of that came with my driver's license and airman's medical that reads "Must have corrective lenses available for near vision" on the back. Oh sigh...

Trying to work with SMT electronics has been mostly an exercise in frustration simply because I cannot sufficiently see what I am doing. So, I recently aquired a binocular microscope for the bench.

Man, what a difference this makes! I can now actually see what I am doing even whilst soldering TQFP or other dense, fine pitch SMT components. Even with corrective lenses, I have trouble with anything smaller than 1206 SMT components. Since most of my components are 0805, this is a problem.

This is such a simple solution. It actually has made homebrew electronics pleasurable for me again. If you are struggling as I have with changes in vision as I have grown "wiser" (older) don't waste another minute pondering the purchase. Invest the money in such a device and see what you are doing, or at least what you have been missing! They are not cheap, but believe me, they are worth every penny you spend and will repay itself many times over.

Randomizing WSPR TX Percent

2012-01-31T00:17:00.000-08:00

My propeller WSPR beacon so far has implemented TX Percent as a constant. For example if you set TXPercent to 20% (0.20) then it will transmit every 10 minutes. Joe Taylor's WSPR specification states that in reality, it should transmit randomly within that interval in order to minimize collisions with other stations transmitting with the same TX Percent value. So rather than transmitting exactly every 10 minutes with this TX Percent value, I have implemented a routine to pick a random 2 minute period up to the value specified by TX Percent. So, TX Percent now effectively specifies the maximum amount of time to wait between transmissions.

I created a variable to hold the current random number and initialized it with a constant. The value of the constant is not important. Pick your birthday or whatever. It becomes the starting seed for the random number generator.

VAR
    LONG Rnd

PUB doInitialize
Rnd := 22041956                     ' Initialize random number seed

I then created a new procedure to calculate how long to wait before the next transmission based on TX Percent. TX Percent is declared as a constant. For me it is set to 20%

CON
TXPercent =  0.20     ' Transmit 20% of the time or about every 10 minutes

PUB nextSync : s
s := ROUND(1.0 / TXPercent * 2.0)    ' Calculate when next xmit occurs in minutes
s := (||?Rnd // s)                   ' Randomize the result
s += (s // 2)                        ' Send on a 2 minute boundary
s *= 60                              ' Convert minutes to seconds

Right. Now, in the main loop, we calculate how long to wait with each go by calling nextSync and setting the new value of Sync to the returned value.

PUB Main
doInitialize
repeat
    'Send symbol set for KO7M CN87 7
    sendCode(@mySyms)
    noTone
    Sync := nextSync
    repeat while SecondCnt // Sync
      delay(100)

This seems to do the job nicely. While it is not always the case that you may want to have the transmission start time randomized, this brings the beacon code closer to that of the WSPR 2.x specification. If you wish to have constant transmission periods, just change the Sync := nextSync line to set Sync to a constant number of seconds between transmissions. Remember to make sure this equates to an even number of minutes between transmissions.

As you can see, my transmissions are now being nicely randomized up to 10 minutes.

For those interested, here is the entire updated beacon code:

CON
_CLKMODE = XTAL1 + PLL16X
_XINFREQ = 5_000_000
WMin         =        381        'WAITCNT-expression-overhead Minimum
RFPin        =         27        ' I use pin 27 for RF output

' WSPR standard frequencies

' Shown are the dial frequencies plus 1500 hz to put in the middle of
  ' the 200 hz WSPR band
WSPR500KHz   =     502_400 + 1_500    ' 500 KHz
WSPR160M     =   1_836_600 + 1_500    ' 160 metres
WSPR80M      =   3_592_600 + 1_500    ' 80 metres
WSPR60M      =   5_287_200 + 1_500    ' 60 metres
WSPR40M      =   7_038_600 + 1_500    ' 40 metres
WSPR30M      = 10_138_700 + 1_500    ' 30 metres
WSPR20M      = 14_095_600 + 1_500    ' 20 metres
WSPR17M      = 18_104_600 + 1_500    ' 17 metres
WSPR15M      = 21_094_600 + 1_500    ' 15 metres
WSPR12M      = 24_924_600 + 1_500    ' 12 metres
WSPR10M      = 28_124_600 + 1_500    ' 10 metres
WSPR6M       = 50_293_000 + 1_500    '   6 metres
WSPR4M       = 70_028_600 + 1_500    '   4 metres
WSPR2M       = 144_489_000 + 1_500    '   2 metres

Frequency    =     WSPR30M     ' Set to 30 metres
ErrorOffset =          20     ' Specific to my propeller board - change this
symbolLength =         683     ' 8192 / 12000 * 1000 = milliseconds
TXPercent    =        0.20     ' Transmit 20% or about every 10 minutes

OBJ
Freq : "Synth"
'WSPR : "ko7mWSPREncode"
'T    : "PSM_tv_text"

VAR
    LONG SecondCnt, Stack[16]
    LONG Sync
    LONG Rnd

DAT
    ' Symbol set for KO7M CN87 7
    mySyms BYTE "33020202322033300230030333100222201023012020023033"
           BYTE "22132320011212000112303210300300303300031212302010"
           BYTE "22021203023312132013030201132002230302330002020310"
           BYTE "303320231002", 0

PUB Main
doInitialize
repeat
    'Send symbol set for KO7M CN87 7
    sendCode(@mySyms)
    noTone
    Sync := nextSync
    repeat while SecondCnt // Sync
      delay(100)

PUB doInitialize
Rnd := 22041956                    ' Initialize random seed
cognew(Clock, @Stack)               ' Start the clock COG

PUB sendCode(stringptr)
if TXPercent > 0      ' If zero, not transmitting
    repeat strsize(stringptr)
      sendSymbol(byte[stringptr++])

PUB sendSymbol(char)
case char
   "0", 0:
    sendTone(-3)
    delay(symbolLength)
   "1", 1:
    sendTone(-1)
    delay(symbolLength)
   "2", 2:
    sendTone(1)
    delay(symbolLength)
   "3", 3:
    sendTone(3)
    delay(SymbolLength)

PUB sendTone(tone)
Freq.Synth("A",RFPin, Frequency + tone + ErrorOffset)

PUB noTone
Freq.Synth("A",RFPin, 0)

PUB delay(Duration)
waitcnt(((clkfreq / 1_000 * Duration - 3932) #> WMin) + cnt)

PUB Clock              ' Runs In its own COG
repeat
    delay(1000)        ' Update second counter every 1000 ms
    SecondCnt++        ' Should be good for 2^32 seconds or about 136 years

PUB nextSync : s
s := ROUND(1.0 / TXPercent * 2.0)    ' Calculate when next TX occurs in minutes
s := (||?Rnd // s)                   ' Randomize the result
s += (s // 2)                        ' Always send on a 2 minute boundary
s *= 60                              ' Convert minutes to seconds

First WSPR spot on Propeller Board - barefoot

2012-01-30T18:20:00.000-08:00

Well, I got my first WSPR spot on my propeller beacon today from VE6PDQ. It seems there is someone listening out there to my little peanut-whistle signal, blowing down all the competition with a thundering 5 mW (7 dBm) signal... :)

Whoo hoo! I was just about to give up hope of making any contacts on this low power level. That works out to about 199,000 km (123,652 miles) per watt if my fuzzy head is doing the math correctly. Yippee!

I barely had time to post this and I got a second spot from W5OLF at 1720 km. Seems that things are picking up for me. Very cool...

This works out to about 344,000 km (213,751 miles) per watt.

Flying diversion

2012-01-28T01:14:00.000-08:00

Flew up to Friday Harbor on San Juan Island yesterday in a Columbia 400, otherwise known as a Cessna 400 Corvalis.

Specifications (Cessna 400)

Data from Columbia 400 Pilot's Operating Handbook

General characteristics

Crew: 1 pilot
Capacity: 3 passengers
Length: 25 ft 2 in (7.67 m)
Wingspan: 36 ft 1 in (11.0 m)
Height: 9 ft 0 in (2.74 m)
Wing area: 141 ft² (13.1 m²)
Empty weight: 2,500 lb (1,134 kg)
Max. takeoff weight: 3,600 lb (1,500 kg)
Powerplant: 1 × Teledyne Continental TSIO-550-C flat-6 engine, 310 hp (230 kW)

Performance

Maximum speed: 235 knots (270 mph, 435 km/h) calibrated airspeed
Cruise speed: 235 knots (270 mph, 435 km/h) true airspeed at 25,000 ft (7,600 m)
Range: 1,107 nm (1,274 mi, 2,038 km)
Service ceiling: 25,000 ft (7,600 m)
Rate of climb: 1,500 ft/min (7.6 m/s) or greater, below 16,000 ft (4,875 m)
Wing loading: 25.5 lb/ft² (125 kg/m²)
Power/mass: 0.091 hp/lb (150 W/kg)

Very fast airplane. We cruised at 185 knots up and back. Compared to flying my Super Cub, moving the stick is like trying to bend a steel rod. I guess if you are going to move that fast you are going to have a lot of wing loading and the stick was very stiff. I now understand why these guys fly with the autopilot engaged most of the time.

We landed at something above my normal cruise speed in the cub with a stiff crosswind and used every inch of the 3400 foot runway. I am used to landing at Friday Harbor and making the first turnoff.

Boeing field off the right wing whilst crossing over SeaTac International airport, climbing out of 4000 for 6000 feet.

Northbound crossing Puget Sound, punching through clouds as we go. Outside temperature was minus 13C and we were picking up some frost on the leading edges of the wings in the cloud tops.

Heading north, east of Puget Sound, north of Bremerton. Asked for 8000 feet to get above the cloud tops, but as you can see the clouds ahead are still above us. Didn't want to go much higher as we will just have to drop down through them again soon to land.

This is the Avidyne glass panel setup in the C400. Two Garmin GPS units, S-Tec autopilot and all the bells and whistles you can possibly want.

It was a fast trip and I enjoyed it greatly. I am certainly glad I was not alone as cruising at 185 knots rather than my normal 85 knots, things happen a whole lot quicker that I am used to. If you want to get someplace in a hurry, the C400 is a good way to go.

New Propeller Toys

2012-01-27T13:39:00.000-08:00

I have obtained a touch panel LCD display for my Propeller board. I am using a modification of the TV object to display text output for debugging purposes. It is nice to have this peripheral display to make debugging easier. Here is some debug output from my work on a routine to encode WSPR messages:

Nice little display. It is a 320x240, 2.4" Colour LCD with touch screen. It mounts to a prototyping board and leaves 15 IO available when connected in 8 bit mode. It can display true-colour, 24 bit images and has a controllable backlight. It also sports a full size SD card slot that can be used for offline storage. Here is an example of the graphics display.

I think this will prove to be quite useful in my projects.

7x14 Hellschreiber Glyphs

2012-01-25T21:42:00.000-08:00

I noticed that Mark Vandewettering, K6HX over at brainwagon.org recently posted an arduino Hellschreiber bit of code and decided to adapt his 7x14 set of glyphs to QRSS on the Propeller processor.

The result is not displeasing, but is a bit more bandwidth that I would feel comfortable taking up of a QRSS band that is only 100 Hz wide in the first place.

This is with 2 Hz spacing between column dots. I reduced this to 1 Hz and got the following results:

Ok, so this is a little more bandwidth friendly, but I would need to play with the inter-column and inter-character spacing a bit to be happy with it. I am not totally sold on the set of glyphs yet, but the enlarged characters allow for more interesting glyphs to be created than with my original 5x7 set.

Propeller Beacon Power Consumption

2012-01-24T10:30:00.000-08:00

I decided to take a look at power consumption during RF generation on the Propeller device. I have a power monitoring device that logs current usage over time. What I wanted to see was the power consumption that was attributable to RF generation.

The test setup is a Gadget Gangster board powered by my power monitor at 4.55 volts. This is a somewhat low voltage, but is the highest voltage that it will generate. This of course may affect my testing results, but the data is interesting nevertheless.

Since I am measuring current usage on a running processor, it is fun to look at the effect of code changes on power usage, but that is a side topic for another time.

Baseline, I wanted to see what current consumption is when the processor(s) are waiting in a delay loop with RF generation off. This appears to be on the order of 20.8 mA while continuous RF generation on a single frequency appears to consume about 23.6 mA. The script who's power consumption is graphed below loops turning the RF on and off every 5 seconds.

Now, I replace the script with a CW beacon sending at about 15 WPM my call sign and locator (KO7M CN87). The power consumption graph looks very much like a QRSS Argo display.

As you can see, my call sign is clearly visible. This script baselines at about 22.5 mA with RF off and 25.2 mA with RF on or about 3-4 mA attributable to RF generation.

WSPR Spots

2012-01-23T19:02:00.000-08:00

Well, my experience in running 7 dBm WSPR beacons thus far according to http://wsprnet.org has been far from stellar...

Spot Database

Specify query parameters
0 spots:

Timestamp	Call	MHz	SNR	Drift	Grid	Pwr	Reporter	RGrid	km	az

Query time: 0.001 sec

So, I think that I may move off 30 metres for this evening and have a go at one of the longer wave bands and see if I can improve the current score.

WSPR Beacon - Frequency and Drift Data

2012-01-23T07:05:00.000-08:00

I have been running my Propeller WSPR beacon over night and have gathered 42 data reporting points on drift and frequency as reported by WSPR 2.11 over a 7 hour period. The beacon is transmitting every 10 minutes and idle between times. The only temperature control is to wrap the device in foam.

The charts below are are showing the frequency reported by WSPR 2.11, which as I understand it will be the first frequency it decodes and the amout of drift from that frequency over the life of the transmission.

There are a few somewhat wild excursions initially, but then over time the initial frequency appears to drift upwards with each successive 10 minute period as the device cools.

The amount of drift once the transmission begins is in the opposite direction and after some initial jitter assumes asymptotic behavior at a consistent 2 hertz downward drift as the device warms up.

While none of these figures is horrific, good engineering would indicate that for this kind of application, careful attention to thermal stability is important.

Updated WSPR beacon

2012-01-22T21:09:00.000-08:00

Today I have been working on getting my Propeller WSPR beacon to obey WSPR's timing rules. I have implemented the notion of TX Percent. As mentioned in previous posts, I define TX Percent in this way as there is no clear definition in Joe Taylor's documentation on WSPR.

CON
TXPercent    =       0.20     ' Transmit 20% of the time

VAR
  LONG SecondCnt, Stack[16], Sync

PUB Init
Sync := ROUND(1.0 / TXPercent * 2.0) ' Calculate when next xmit occurs in minutes
Sync += (Sync // 2)                  ' Always send on a 2 minute boundary
Sync *= 60            ' Minutes
SecondCnt := 0        ' Reset the second counter to zero
cognew(Clock, @Stack) ' Start the clock COG

PUB Clock                      ' Runs In its own COG
repeat
    delay(1000)                ' Update second counter every 1000 ms
    SecondCnt++                ' Should be good for 2^32 seconds or about 136 years

Ok, so TX percent of 20% means you will transmit every 10 minutes. If you want to change how often you transmit, change the value of TXPercent. I modified the code to not send when TXPercent is zero as this is listen only mode.

PUB sendCode(stringptr)
if TXPercent > 0
    repeat strsize(stringptr)
      sendSymbol(byte[stringptr++])

The Clock procedure runs on its own COG and just keeps track of seconds. The presumption is that you flip on the Propeller board at precisely the start of an even minute.

Lastly, I modified the main routine to wait for the next transmit window.

PUB doInitialize
repeat
    ' Send symbol set for KO7M CN87 7
    sendCode(string("<paste in your WSPR encoded message here>"))
    noTone
    repeat while SecondCnt // Sync
      delay(100)

I have the updated code running now on 10.140.200 every 10 minutes at about 7 dBm (5 mW). Look for me in the spot database. I am seeing about -3 drift typically when running on a 10 minute cycle. I will have to experiment with better temperature control of the board to see if I can eliminate that.

For those interested, here is the entire beacon Spin code. I have removed my WSPR coded message. Please see my previous post on how to create that for your call sign, grid square and power level in dBm.

CON
_CLKMODE = XTAL1 + PLL16X
_XINFREQ = 5_000_000
WMin         =        381     'WAITCNT-expression-overhead Minimum
RFPin        =         27
Frequency    = 10_140_200
ErrorOffset =       -431
symbolLength =        683     ' 8192 / 12000 * 1000 = milliseconds
TXPercent    =       0.20     ' Transmit 20% of the time or about every 10 minutes

OBJ
Freq : "Synth"

VAR
    LONG SecondCnt, Stack[16]
    LONG Sync

PUB Main
doInitialize
repeat
    ' Send symbol set for KO7M CN87 7
    sendCode(string("<paste your own WSPR coded message here>"))
    noTone
    repeat while SecondCnt // Sync
      delay(100)

PUB doInitialize
Sync := ROUND(1.0 / TXPercent * 2.0) ' Calculate when next transmission occurs in minutes
Sync += (Sync // 2)                  ' Make sure we always send on a 2 minute boundary
Sync *= 60                   ' Convert minutes to seconds
SecondCnt := 0               ' Reset the second counter to zero
cognew(Clock, @Stack)        ' Start the clock COG

PUB sendCode(stringptr)
if TXPercent > 0             ' TXPercent of zero indicates we are not transmitting
    repeat strsize(stringptr)
      sendSymbol(byte[stringptr++])

PUB sendSymbol(char)
case char
   "0":
    sendTone(-3)
    delay(symbolLength)
   "1":
    sendTone(-1)
    delay(symbolLength)
   "2":
    sendTone(1)
    delay(symbolLength)
   "3":
    sendTone(3)
    delay(SymbolLength)

PUB sendTone(tone)
Freq.Synth("A",RFPin, Frequency + tone + ErrorOffset)

PUB noTone
Freq.Synth("A",RFPin, 0)

PUB delay(Duration)
waitcnt(((clkfreq / 1_000 * Duration - 3932) #> WMin) + cnt)

PUB Clock                      ' Runs In its own COG
repeat
    delay(1000)                ' Update second counter every 1000 ms
    SecondCnt++                ' Should be good for 2^32 seconds or about 136 years

Winter Wonderland

2012-01-19T12:04:00.000-08:00

We have had a bit of a winter storm hit over here and it has dumped about 8 inches of snow on the KO7M QTH.

The power went out this morning with the mains dropping to about 60 volts per side of the 220 mains. Not good... I pulled the main breaker and connected up my little Honda generator and am able to keep the furnace fan, refrigerator and a few lights running as well as the computer. Right now we are having freezing rain. The packed snow on the roads is rapidly turning to an ice rink. Lots of fun in Seattle.

Beacon Power Output

2012-01-18T10:39:00.000-08:00

My Propeller beacon is now on the air on 30 metres. Currently running QRSS near the bottom of the band (10.140.000) sending "KO7M CN87" in 5 hz FSK. Would love to have any reception reports. Currently running around 7 mW into a fence-mounted vertical. SWR is 1:1 fortunately. :) I will from time-to-time (on a whim) reconfigure it as I am now working on getting the WSPR beacon code to be autonomous which involves figuring out how to do the strict WSPR timing of transmissions.

More Propeller Frequency Stability

2012-01-18T10:23:00.000-08:00

After wrapping the propeller board in foam, from a cold start, after about 30 minutes the frequency stabilized at about 30 Hz lower than the cold start value.

So, it appears that my chasing of this error correction value has been a bit of a boondoggle as I had not attended to the temperature stability of the device. (Doh!) I should be able to zero in on my ErrorOffset value and be able to let it be, or so I hope.

Propeller frequency stability

2012-01-17T21:18:00.000-08:00

This evening, I have been experimenting a bit with my Propeller device. I have a small script that turns on the RF synthesizer at 10_140_000 mHz for 30 seconds, off for 10 seconds etc. I use it for calibration of the frequency of the board in use as different Propeller boards will have different amounts of error in frequency generation. The script looks like this:

CON
_CLKMODE = XTAL1 + PLL16X
_XINFREQ = 5_000_000

CLK_FREQ = ((_CLKMODE-XTAL1)>>6)*_XINFREQ
MS_001 = CLK_FREQ / 1_000

RFPin = 27

TxFreq      = 10_140_000
ErrorOffset =       -467

Frequency = TxFreq + ErrorOffset

VAR
OBJ
Freq : "Synth"

PUB Main
repeat
    sendTone(0)
    delay(30000)
    noTone
    delay(10000)

PUB delay(ms) | t
t := cnt - 1088               ' 1088 is published time for overhead
repeat ms
    waitcnt(t += MS_001)

PUB sendTone(tone)
Freq.Synth("A",RFPin, Frequency + tone)

PUB noTone
Freq.Synth("A",RFPin, 0)

This simple little script I find to be very useful when I need to generate a signal at some frequency. The on/off modulation of the signal allows me to find it more easily on uncalibrated receivers.

Viewing the output from a local receiver using Argo we find this waveform. As you can see, my board has approximately -467 Hz of error which is corrected for in this script. Nevertheless, as the board changes temperature, it does drift a bit. As can be seen below I have drifted a hertz or two lower since calibration of the board was last done.

I begin to wonder however why this ErrorOffset value seems to change when using the same board, just a different application. For example my Hellscrieber code appears to transmit about 3 Hz lower with the same ErrorOffset value. I added a 30 second carrier at the beginning of the code to see exactly what frequency it is on before launching into the transmission of FeldHell codes. With the transmit frequency set to 10_139_980 and the same -467 ErrorOffset value, the following is observed:

I am clearly 5-6 Hz low. The frequency is also different than in the previous example, so that may be related. I think however that it may just be the drift of the device. Going back to the Tune application, which should be a hertz or two low at 10_140_000, we see the following:

Hmmm... So it appears that I am just chasing a temperature drift of the Propeller board over time. Adding some thermal stabilization to it would probably help. I will wrap it up in some foam and let it run for a while and see if the frequency stabilizes.

Here is a cold start image of my QRSS signal. Out of the box, it seems that there is a significant drift:

And a few minutes later we can see it has drifted over 20 Hz:

I will let it run and see where it stabilizes.

Hellschreiber QRSS using Propeller

2012-01-16T22:41:00.000-08:00

Last evening, I shared the experience of creating a FeldHell-like QRSS beacon. The bulk of the effort was in creating an acceptable font. The Propeller chip has a rather nice font already in ROM but it is more suited for TV video output than for QRSS due to its 16x32 size. I felt that this was too much bandwidth to occupy for a single signal in the QRSS band.

I created the font definition in a text editor and decided to try a 5x7 font initially. With this format, each character is 5 bytes (one byte for each column of the font character). For example, the letter "A" is represented thus:

     XXX
    X   X
    X   X
    XXXXX
    X   X
    X   X
    X   X

Each colum of the character in the 5x7 grid is encoded as a byte where the "X" character above is encoded as a set bit and the lack of an "X" is encoded as a 0. So to create this, I defined all my characters (0..9, A..Z) as shown above in a text file. I then imported the text file into a spreadsheet and rotated the rows and columns 90 degrees using the spreadsheet "Transpose" function. This had the effect of laying all the characters down on their sides, thus:

     XXXXXX
    X X
    X X
    X X
     XXXXXX

I then exported the file back to a text file for further processing. You have to now imagine each of the font characters lying on their sides like the example above, occupying five very long lines of my text file. I then globally replaced all the space characters (there is a space in each 5x7 grid anyplace there is no "X") with a "0" character and replaced the "X" characters with "1". For the "A" character above, this resulted in:

    0111111
    1001000
    1001000
    1001000
    0111111

I then turned this mess into a valid DAT block containing binary byte values like so:

DAT
    ' FeldHell font definitions
    '             A         B         etc
    Col5 BYTE %0111111, %xxxxxxx, ...
    Col4 BYTE %1001000, %xxxxxxx, ...
    Col3 BYTE %1001000, %xxxxxxx, ...
    Col2 BYTE %1001000, %xxxxxxx, ...
    Col1 BYTE %0111111, %xxxxxxx, ...

Now I can index into this table and obtain the column data I need for each character. So now in the main loop, I can call this procedure to process the beacon text:

PUB doFeldHellBeacon
    ' Send Feld Hell beacon text
    sendFeldHellString(string("KO7M CN87xp"))

PUB sendFeldHellString(strMsg)
    repeat STRSIZE(strMsg)
      sendFeldHellChar(BYTE[strMsg++])

The code to send each character is a quick hack, so don't beat me up too much. I am still playing around with the timing to make it look nice. Each character of the message text is looked up in the DAT table above to obtain the byte containing each of the 5 column definitions. The character is sent from bottom left (least significant bit of Col1) to the top of the column and then proceeding with the next column until all five columns have been sent. I test the least significant bit of each byte of column data and send a tone if it is set and send nothing if unset. Right shift to get the next bit and continue for all 7 bits.

PUB sendFeldHellChar(ch) | i, j, iCol, columnData, Time

    Time := 300

    ' set up column index to default to space character
    iCol := -1

    case ch
      "a".."z": iCol := ch - "a" + 10
      "A".."Z": iCol := ch - "A" + 10
      "0".."9": iCol := ch - "0"

    if iCol < 0
      delay(Time*12)            ' Handle the space character specially
    else
      repeat i from 4 to 0               ' 5 columns in reverse order
        columnData := Col5[iCol+(i*36)] ' get the current column data
        repeat j from 0 to 6
          if columnData & 1    ' If the font bit is set, send a tone
            sendTone(j*2)
          else
            noTone
          columnData >>= 1     ' Right shift font data to get next bit
          delay(Time)          ' Give a little space between columns
        noTone
      delay(Time*6)            ' Give a little more space between letters

So, that is it... Simple, eh? Since the font definition is five really long lines of text, I am not going to post the entire program here. If you would like to have a copy of it however, I will be happy to email it to you if you will drop me a comment to this post on the blog.

I will be creating "a".."z" characters in the font and some punctuation, but have no plans to create any characters beyond what would be in a typical QRSS message. I am using Eldon's 10 minute QRSS sync algorithm for stacked grabbers. See his article here.

Here is what it looks like on the air:

More Propeller Madness

2012-01-16T02:58:00.000-08:00

Well, my old pal Eldon has really done it now... So much for sleep it seems with new toys to play with...

I decided to implement FeldHell mode on my Propeller based QRSS/WSPR/Opera/CW beacon. It was a bit fun figuring out the timing and the font, but here is a sample:

It is a simple 5x7 font and I draw each character from the lower left to the upper right resulting in the slight forward slant of the characters. Right now I have only defined upper case characters and numerics in the font.

I will post the complete code after I have gotten some sleep... :)

Propeller Opera beacon up and running tonight

2012-01-15T21:40:00.000-08:00

Today I have built a low-pass filter for my Propeller beacon on 30 metres. The spectrum analyzer shows the second and subsequent harmonics more than 45 db down, so I have put it on the air tonight. I am beaconing every 15 minutes using Opera mode running only 5.6 mW currently.

Here is the current setup. As you can see Eldon and I have shared the low pass filter design that he created with the aide of a design program.

I am eager, but not too hopeful that this little pennywhistle signal will be picked up somewhere this evening. We shall see. Thanks Eldon for sharing your design and the components necessary to build the low pass filter!

WSPR on the propeller

2012-01-15T00:31:00.000-08:00

Well, I could not help myself and started implementing a WSPR beacon on the propeller board. For now, I am just going to impelement the transmit portion with a precompiled message and fixed delay between beacons.

I grabbed a copy of Joe Taylors wsprcode.exe application to determine the set of channel symbols that will make up my beacon message of "KO7M CN87 20". Here is that code:

C:\bin>wsprcode "KO7M CN87 20"
Message: KO7M CN87 20

Source-encoded message (50 bits, hex): 8B CC 46 9D 56 B5 00

Data symbols:
      1 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 0 1 1 0 0 1 0 1 1 0 0 0 0 1
      1 1 1 0 0 1 1 1 0 0 1 1 1 1 0 0 1 1 1 0 1 0 0 0 1 0 1 0 0 0
      0 0 0 0 0 0 0 1 0 0 1 1 1 1 0 1 1 1 0 1 0 0 1 1 1 0 0 0 0 1
      0 0 0 1 1 0 1 0 0 1 1 1 0 1 0 0 0 1 0 0 1 1 0 0 0 0 1 0 0 1
      0 1 0 1 0 0 0 0 1 0 0 0 1 1 0 1 0 0 1 0 0 1 0 0 0 1 0 1 0 0
      1 0 1 1 1 1 1 0 0 0 0 1

Sync symbols:
      1 1 0 0 0 0 0 0 1 0 0 0 1 1 1 0 0 0 1 0 0 1 0 1 1 1 1 0 0 0
      0 0 0 0 1 0 0 1 0 1 0 0 0 0 0 0 1 0 1 1 0 0 1 1 0 1 0 0 0 1
      1 0 1 0 0 0 0 1 1 0 1 0 1 0 1 0 1 0 0 1 0 0 1 0 1 1 0 0 0 1
      1 0 1 0 1 0 0 0 1 0 0 0 0 0 1 0 0 1 0 0 1 1 1 0 1 1 0 0 1 1
      0 1 0 0 0 1 1 1 0 0 0 0 0 1 0 1 0 0 1 1 0 0 0 0 0 0 0 1 1 0
      1 0 1 1 0 0 0 1 1 0 0 0

Channel symbols:

      3 3 0 0 0 0 0 2 3 2 2 0 3 1 3 0 0 2 3 0 0 3 0 3 3 1 1 0 0 2
      2 2 2 0 1 2 2 3 0 1 2 2 2 2 0 0 3 2 3 1 2 0 1 1 2 1 2 0 0 1
      1 0 1 0 0 0 0 3 1 0 3 2 3 2 1 2 3 2 0 3 0 0 3 2 3 1 0 0 0 3
      1 0 1 2 3 0 2 0 1 2 2 2 0 2 1 0 0 3 0 0 3 3 1 0 1 1 2 0 1 3
      0 3 0 2 0 1 1 1 2 0 0 0 2 3 0 3 0 0 3 1 0 2 0 0 0 2 0 3 1 0
      3 0 3 3 2 2 2 1 1 0 0 2

Decoded message: KO7M CN87 20 ntype: 20

I then created a propeller procedure that sends this set of channel symbols based on code stolen from Eldon for his Opera beacon:

PUB Main
repeat
    ' Send symbol set for KO7M CN87 20
    sendCode(string("330000023220313002300303311002222012230122220032312011212001101000031032321232030032310003101230201222021003003310112013030201112000230300310200020310303322211002"))
    delay(120000)

For the moment I am ignoring all the timing code that requires WSPR transmissions to start on an even minute boundary. I just want to see if I can manually start this thing at the correct time and have Joe Taylor's WSPR application decode it.

So as I did in my Arduino WSPR beacon, I am setting the transmit frequency to be the middle of the four symbol set. On typical SSB transmitters a USB frequency setting for 30 metre band of 10.138.700 is used and a tone of 1500 Hz would yield a "transmit frequency" of 10.1402 at the middle of the 200 Hz WSPR band. There is no clear definition from any WSPR documentation what is meant by this "transmit frequency", so...

In the absence of clarity from Joe Taylor's documentation, I have chosen to define the transmit frequency like this:

Each symbol is 1.4648 Hz apart and the transmit frequency is mid-way between symbols 1 and 2. Band edge operations need to take this into account if you wish to stay within the defined WSPR frequency range with the entire 6 Hz spectrum occupied by the complete WSPR signal.

However, my stolen code has the ability to set the frequency with a 1 Hz resolution, so I have used 2 Hz rather than 1.4648 Hz symbol separation just for grins. Therefore, symbol offsets from the transmit frequency are as follows:

    Symbol 0    -3 Hz
    Symbol 1    -1 Hz
    Symbol 2    +1 Hz
    Symbol 3    +3 Hz

Here is the (stolen) sendCode function:

PUB sendCode(stringptr)
repeat strsize(stringptr)
    sendSymbol(byte[stringptr++])

sendSymbol offsets the frequency from the transmit frequency as appropriate for the symbol being sent (the first bit of code I have actually written):

PUB sendSymbol(char)
case char
   "0":
    sendTone(-3)
    delay(symbolLength)
   "1":
    sendTone(-1)
    delay(symbolLength)
   "2":
    sendTone(1)
    delay(symbolLength)
   "3":
    sendTone(3)
    delay(symbolLength)

symbolLength is 8192 / 12000 seconds or about 683 milliseconds.

CON
symbolLength = 683

sendTone and noTone do the work of setting the frequency (dutifully stolen from the work of others). The Freq object can be found in the Parallax object library at their web page.

PUB sendTone(tone)
Freq.Synth("A",RFPin, Frequency + tone)
PUB noTone
Freq.Synth("A",RFPin, 0)

So with all this in place, I fired up Joe Taylor's WSPR application, tuned it to my propeller beacon and flipped the switch at the start of an even minute... Here is the Argo display of the unfiltered RF on 30 metres:

Here is the WSPR application display of the reception of this signal:

It seems that WSPR is robust enough for me to get cavalier about timing and non-phase continuous FSK modulation. Nice work Joe Taylor!

So, for the curious, here is the entire WSPR beacon test code thus far. Remember it sends "KO7M CN87 20" as the message. Use Joe's application to generate your own WSPR message string and paste it into the main procedure. It also does not know when an even minute begins, so that must be done manually by powering on the Propeller board at the correct moment, but not bad for a quick hack...

CON
_CLKMODE = XTAL1 + PLL16X
_XINFREQ = 5_000_000
CLK_FREQ = ((_CLKMODE-XTAL1)>>6)*_XINFREQ
MS_001 = CLK_FREQ / 1_000
RFPin = 27
XcvrDial    = 10_138_700
TuneOffset =      1_500
Frequency = XcvrDial + TuneOffset          '10.140200 mHz
symbolLength = 683   ' 8192 / 12000 * 1000 = milliseconds

VAR
OBJ
Freq : "Synth"

PUB Main
repeat
    ' Send symbol set for KO7M CN87 20
    sendCode(string("330000023220313002300303311002222012230122220032312011212001101000031032321232030032310003101230201222021003003310112013030201112000230300310200020310303322211002"))
    noTone
    delay(120000)

PUB delay(ms) | t
t := cnt - 1088               ' 1088 is published time for overhead
repeat ms
    waitcnt(t += MS_001)
PUB sendCode(stringptr)
repeat strsize(stringptr)
    sendSymbol(byte[stringptr++])
PUB sendSymbol(char)
case char
   "0":
    sendTone(-3)
    delay(symbolLength)
   "1":
    sendTone(-1)
    delay(symbolLength)
   "2":
    sendTone(1)
    delay(symbolLength)
   "3":
    sendTone(3)
    delay(SymbolLength)

PUB sendTone(tone)
Freq.Synth("A",RFPin, Frequency + tone)
PUB noTone
Freq.Synth("A",RFPin, 0)

Next I should look at the Freq object implementation and see if I can get better than 1 Hz resolution on the numerically controlled oscillator.

First Opera reception

2012-01-14T10:26:00.000-08:00

Well, thanks to my buddy Eldon WA0UWH, I have been drug kicking and screaming into the world of Opera QRSS and the Propeller processor.

Stealing judiciously from the work of others, I have put together a beacon using the propeller processor and have Opera v1.1.0 beta up and running. This morning I heard myself first (imagine that...) and then N7VVX down in Utah. So, it seems another diversion is born... Thanks Eldon... :|

Before I can really put the propeller on the air, I will need to build a low pass filter for it as the output is a square wave. The reception of my own call (KO7M) is without any antenna on the propeller board. My idea for my low pass filter board is to have a set of switchable (via software) low pass filters on a single board that should be useful for this and my Arduino WSPR beacon.

Az-El mount

2012-01-04T23:36:00.000-08:00

Found an interesting Az-El / Pan-Tilt mount today at http://www.flir.com/mcs/products/ptu-d300/rf/Documentation/index.cfm. Quite the nice little unit. I suspect they are quite proud ($$$) of it but have not been able to find any pricing information online.

LCD Performance and UI decisions in the beacon project

2011-11-14T07:00:00.001-08:00

The beacon project is back on the front burner. Frankly, one of the reasons that it has been stalled so long is because of the lousy UI performance. The rotary encoder triggers an interrupt so I never lose control turns. However, the display updates are very laggy and the amount of lag varies considerably. I *HATE* laggy UIs and until now have not looked into why. Frankly the I2C LiquidCrystal library was apparently a hasty adaptation of the original LCD library without regard to performance. It was taking more than a dozen I2C commands for a single character to be updated, let alone the additional ones for cursor positioning and the like. Bogus. All bits are written simultaneously now and the lagginess is completely gone. Sweet! Many thanks to Kevin who pointed out the great work by falconfour in a comment to one of my previous posts. Nice to be back on track and re-energized to complete this project.

I spent a lot of time talking to my pal Eldon about UI decisions. I will be making some changes to the value setting library for alpha-numeric fields to see if the new paradigm works a little cleaner for non-numeric fields.

Another concept that we kicked around was the effect of TX percent on multi-band operation for WSPR. Since WSPR frequencies have been cleanly defined for all bands, I am considering having TX percent of 100% mean the beacon will cycle through all bands on each two minute window. A setup UI would be created to allow enable/disable of each of the bands. See my previous post for a list of bands supported by this beacon (all up to and including 6 metres). So, if you truely wanted to send 100% of the time on one band, you would have to disable all other bands as well as setting TX percent to 100%. Otherwise, the beacon would sequence through the list of enabled bands every two minute window. I am interested in feedback on this idea. I think it makes sense to enable this multi-band mode only on TX percent = 100% as otherwise, i would have to completely rethink the meaning of TX percent when multiple bands are enabled.

Also regarding multi-band operation, I plan to make some concession for external low-pass filter selection based on the currently selected band or frequency. Interested in feedback on what this might look like. Some ideas:

Provide the frequency to an external function that takes care of the magic itself and leave the details up to the implementer.
Provide an enable bit (or a counter that is decoded by external hardware) that can be used trigger external relays to select an appropriate low pass filter which is set by one of the following:

The function described in #1 above as implemented by someone else.
Providing a set of configurable cutoff frequencies for the various external low-pass filters and automatically selecting one as appropriate based on frequency.
Define one filter per WSPR band and select based on frequency. This is simple, but may be somewhat inappropriate as for example it makes little sense to have separate low pass filters for both 12 and 10 metres where one would suffice.

I have decided to replace my current rotary encoder with a different one from BI Technologies. The Model EN11 rotary encoder is a nice, inexpensive (even in single unit quantities from Mouser) item that adds a push button and detents. My current encoder had no detents and frankly, I prefer having them. If desired, it can be ordered with or without the switch or the detents. I will be using the switch to change the tuning rate rather than a separate push button. See the datasheet here. Thanks to Eldon for providing a sample of this encoder to me to try out with the beacon project.

Eldon and I also revisited the whole topic of what frequency to display on the LCD when in WSPR mode. Most folks that use the great software by Joe Taylor are used to setting the rig display (on 30 metres for example) to 10.138700 MHz and generating tones in the 1400-1600 hz range to feed into your SSB transmitter. The actual transmit frequency can be set by double clicking in the "waterfall" display or by typing it in to the "Tx:" frequency edit box. One idea kicked around was to only display the WSPR band (30 metres, 20 metres, etc) and an offset from the start of the WSPR band. The offset is only 200 hertz total. This sort of makes sense to me, but I have an uneasyness when I don't know precisely what frequency I am transmitting on. Joe Taylor's software shows the exact transmit frequency. For example, if you clicked in the middle of the 30 metre band, it will show 14.140200 in the "Tx:" frequency box. What is not clear to me is precisely what that frequency means since WSPR signals are composed of four separate tone frequencies that are separated by 1.4648 Hz. In the absence of clarity from Joe's documentation, I have chosen to define the transmit frequency like this:

Each symbol is 1.4648 Hz apart and the displayed transmit frequency is mid-way between symbols 1 and 2. Band edge operations need to take this into account if you wish to stay within the defined WSPR frequency range with the entire 6 Hz spectrum occupied by the complete WSPR signal. Anyone have further thoughts or comments on this?

Anyway, it is nice to be back on track and making progress on my beacon again.

I am confused...

2011-10-30T22:59:00.000-07:00

So, I have a transformer that has two primary windings that can be typically be hooked up in parallel for 115 VAC operation or in series for 230 VAC operation as well as a couple of identical secondary windings. It looks something like this:

Let's take the scenario where we hook up only one primary to the mains. My thinking is that I can treat the second primary winding as another "secondary" and should see the mains voltage on this winding and it would therefore act like an isolation transformer as well as a step down transformer for the secondary voltages.

Where I am confused is the following scenario. Let's say we hook the mains to 1 and 2 above and use 3 and 4 as the input voltage to a full wave bridge rectifier, filter and regulator for my B+ supply. The B+ only needs about 100 ma current capability.

So, what if the transformer is rated at 50 VA and we are drawing sufficient current from the combined secondaries to equal 48 VA including the current drawn from the second primary winding. This is obviously less than the 50 VA rating of the transformer. But, in this case does the manufacturer expect that the primaries will be always wired in parallel and actually used as primaries? Do I risk drawing too much current through the single primary wired to the mains in this scenario? Anyone have any ideas? Is it likely that each winding can handle the maximum rated VA?

If I understand this correctly, if the transformer is rated at 50VA, then each winding must handle the equivalent current (voltages chosed to make the math easy):

50VA
------ = .5 A primary current total or .25 A each winding
100V

50VA
------ = 2 A secondary current total or 1 A each winding.
25V

So, if I have this correct, I risk over-heating the single primary hooked to mains if I am running at close to the rated VA of the transformer unless the manufacturer over-engineered the windings wire size. It seems I should limit the total secondary current to 1/2 the VA rating of the transformer if only a single primary is hooked to mains.

Thoughts? Am I thinking about this correctly?

APRS rig back in the car

2011-10-30T20:42:00.000-07:00

More years ago than I care to remember I picked up a Kenwood D700 rig. Since I have recently pulled the HF rig and D-Star rig out of the car, I decided to put the Kenwood rig in for a while. Scrounging around I found a nice 5 hz GPS that has RS-232 (DB-9) output and made up an adapter cable from DB-9 to 2.5mm stereo plug to connect the GPS to the rig. It all seems to be working and http://aprs.fi is reporting my spots.

One downside of the D700 is that while it is a dual band rig, once you turn on APRS you pretty much lose the 2 metre side of the rig for communications. That's ok, since there are so many 23 cm repeaters in the area.

New speaker for the SW-3

2011-10-30T20:32:00.000-07:00

I managed to find a nice little period (sort-of) speaker for the SW-3 receiver on eBay. It is a nice little "tombstone" style cabinet with about an 8 inch speaker and impedance matching transformer. Presents a nice high impedance to the receiver and the pin connectors exactly match the connectors on the SW-3, so it plugs right in.

The cabinet is cast metal (likely "pot metal" (zinc)) and is quite brittle, though the exterior condition is quite good for something as old as this is. However, as is the case sometimes with eBay purchases, it was unfortunately damaged in shipment and one of the corners was broken off. The seller did right by me and refunded 1/2 of what I paid for it and so I kept it. Fortunately, the damage is on the back and relatively easy to hide from view.

The speaker works admirably with the SW-3 and I enjoyed imagining what it was like in 1930 to be listening to this little rig whilst running off batteries. There was a lot of activity on 40 metres as this was a contest weekend, so there was able listening material along with the 49 metre broadcast band.

Last evening, I changed out the frequency-determining coils in the SW-3 and tuned around the 80-75 metre band finally settling on 3885 khz where a group of AM enthusiasts was parked holding a round-table discussion on everything under the sun for hours on end.

Pretty fun.

SW-3 is on the air!

2011-10-09T19:08:00.000-07:00

So, today I finally sat down to see if the SW-3 is actually functional. The first order of business is to come up with 2.5 volts at 4 amps for powering the valve/tube filaments. I found a Triad transformer that provides 2.5 volts at 6 amps. I decided to try just using AC on the filaments even though it is likely to introduce some hum into the receiver. For now, I just lashed up the filament supply with a power cord and fuse.

For now, I am just clip leading the filament transformer to the power cord on the receiver. Sure as shooting, the valves/tubes all lit up as they should. The AC voltage drops to about 2.25 volts and is drawing just short of 4 amps. How did these guys ever run these puppies on batteries? Must have gone thru them like no tomorrow.

So, with all the valves/tubes lit up, it is time to deal with the audio output. Looking at the bottom of the receiver, I see that the B+ goes directly to one side of the audio output and the other goes to the plate of the audio amplifier. Bloody lovely... 135 volts across the headset... Looking at the valve/tube data sheet it looks like the output impedance will be on the order of 20K ohms. Obviously this 1930 receiver expects a magnetic, high impedance headset. One of my Bogen audio transformers to the rescue. I wired up one of them to the audio output and put a 3.5mm audio jack on the secondary to allow using a powered computer speaker.

Now for the B+ supply. I am using my Heathkit lab supply to provide 135 volts regulated. For now, just clip leading it in place.

So, I cranked up the high voltage supply a little at a time. I didn't want to have any 80 year old capacitors explode if I could help it. After an hour or so, I had the B+ up to 135 volts and no magic smoke was released into the atmosphere.

So, with everything up to temperature and up to voltage, I started trying to figure out how to tune this little gem.

The main tuning dial is very smooth with no backlash and very little yellowing of the plastics and dial card. Amazingly, the main dial also has the ability to change the turning rate from about 18 to 1 to about 4 to 1. Those guys at National did a nice job on this rig back in 1930. The dial left of the main dial is the antenna coupling. It operates very smoothly to peak the signal without introducing any frequency change. The horizontal dial below the main dial is an RF gain control. The regeneration control is the one to the right of the main tuning dial.

As is the case with most regens, they can be very sensitive. While it is tempting to turn the RF gain all the way up and crank the regen control all the way up, it is counter productive and counter intuitive. In this case, you want to peak the antenna coupling for maximum noise and then advance the regen only as far as necessary to obtain a rushing sound in the speaker. This indicates the regenerative detector has started oscillating. Strong signals will overload the receiver and really complicate trying to tune things in, so back off the RF gain nearly all the way and only turn it up sufficiently to be able to hear the signal you wish to hear. With the antenna coupler peaked, you now back off the regen until just before it starts oscillating if you want to tune an AM station or just after it starts oscillating if you want to tune a CW or SSB signal. This is the point of maximum sensitivity. Back off the RF gain until the signal is clear and free of distortion. I don't seem to have any AC hum issues, even though the filaments are running on AC. Sweet!

So, tuning around the band, it appears that the tuning coil I have covers about 5 to 9 Mhz. I was able to hear WWV at the bottom of the dial, a couple of numbers stations, an upper sideband (USB) weather station (National Weather Service - Miami FL), CW and LSB signals on 40 metres, CBCS in Vancouver BC, etc. Nice little receiver! Next, I need to package up the power supply bits and audio output transformer into a tidy external package.

Bogen T725 transformer

2011-09-22T22:09:00.000-07:00

I have found a little gem of a transformer for my radio projects: The Bogen T725 audio transformer. I basically gives you the ability to match 8 ohm loads to a high(er) impedance source from about 150 ohms to about 40k ohms. Specs below courtesy of makearadio.com where you can find lots of ideas on how to use these devices. http://makearadio.com/misc-stuff/t-725.php

I was able to locate a number of these little dudes online (amazon.com) and picked them up for future projects. In the table below, all values in the primary are relative to the black tap (blk).


     Color      Resistance     Inductance       XL @ 300 hz      Rounded Value
   White  (WH)  1424.3 ohms      24     H       45.239k  ohms      40k    ohms 
   Gray   (GRY)  886.4 ohms      12.04  H       22.694k  ohms      20k    ohms
   Violet (VIO)  516.5 ohms       6.06  H       11.423k  ohms      10k    ohms   
   Blue   (BLU)  260.1 ohms       3.04  H        5.730k  ohms       5k    ohms  
   Green  (GRN)   81.8 ohms       1.565 H        2.950k  ohms       2.5k  ohms    
   Yellow (YEL)   56   ohms         787 mH       1.483k  ohms       1.2k  ohms
   Orange (OR)    38.2 ohms         398 mH         750.2 ohms         600 ohms
   Red    (RED)   26   ohms         197 mH         371.3 ohms         300 ohms
   Brown  (BRN)   18.2 ohms          98 mH         184.7 ohms         150 ohms

   Pink to Pink    0.5 ohms        5.23 mH          9.86 ohms           8 ohms

I plan to use one of these to get the B+ voltage from my National SW-3 off of the headphones and to provide an impedance match to a more typical 8 ohm speaker or headphone.

I also found a nice transformer P-T31 at Antique Electronic Supply that does 5k to 8 ohm impedance.  These were about twice the price and no taps on the primary.

Playing around with APRS tonight

2011-09-16T00:18:00.000-07:00

I picked up my old TNC2 packet controller and dusted it off today. After finding an old Hayes modem cable I was able to wire this dude up to my laptop. About a million years ago, I registered a version of UIView32 which is a nice little APRS mapping package.

Of course there were no maps of the Western Washington area available for the software, but there is a nice feature where you can drag/drop a map bitmap onto the software and then define the lat/lon details for either the upper/left, lower/right corners of the map or by clicking on two points on the map and defining the lat/lon for those points. I took a screen shot of a google map and defined two points. Not totally precise, but close enough for giggles. Here is a peek of the map after it has had a little while to listen on 144.39 Mhz to the APRS traffic.

I have an old Alinco dual-band rig that I inherited from my dad (W7QJC) R.I.P. that I might press into service for packet radio playing around. Gotta get the transmit portion working next. Just need to set some jumpers to match the microphone wiring and plug it in.

ArisSat1 heard this morning

2011-09-14T15:53:00.000-07:00

This morning I had some fun with my Arrow antenna and an old Yaesu 2 metre hand-held transceiver. I generally track a hand-ful of Ham Radio satellites, one of which was recently launched from the International Space Station (ISS).

This morning about 10:20 Pacific Time, we had a nearly overhead pass of the satellite giving me about 10 minutes of time to to track the bird and listen to its beacons.

At the appropriate hour (and minute) I was the image of tin-foil-hat-geekdom standing out in my yard with a pair of headphones on listening to a handheld radio whilst pointing a very strange contraption (the Arrow Antenna) skyward. I live on some acreage, so I don't have neighbors withing spitting distance, but nevertheless, it was a bit of a "moment" for me wondering if anyone watching would think the old man has taken leave of his senses...

But, the sights being whatever they were, I was having fun... I had a great copy on the bird, but didn't happen to plan ahead sufficiently to enable me to record the pass. Even with the tall trees around, I had no problem copying the pass and sent off for my reception report giving two of the (english) passwords copied during the pass as proof of reception.

If you have not tried to copy ArisSat1 yet, it is very easy even with a handheld receiver and a modest vertical antenna.

The next round for me will be to try and catch some of the telemetry. I will have to look at the satellite status page to see if the transponder is still functional, but a contact or two over the bird would be fun.

And now for something completely different...

2011-09-13T23:53:00.000-07:00

Reading the brainwagon.org blog, I came across today an 8080 emulator that is implemented (of all things) in JavaScript. I can load it up in a web browser and load a working CP/M OS image and found myself soon playing Zork1.

Cracks me up to think about running an emulation of hardware that I wrote code on for a living, running a predecessor to MSDOS operating system and playing an adventure game all written in an emulated language embedded in my web browser...

Geeze, I am getting old... :\

Powering up the SW-3 (again)

2011-09-13T23:45:00.000-07:00

After discussing with my buddy Eldon, I have decided not to use the voltage divider approach to power the filaments. They are all wired in parallel and the risk from one of them opening up and thereby taking out the entire set of tubes is too great, not to mention the royal pain in the tush finding a 1.15 ohm 15 watt resistor will be. I decided to order a 2.5 volt 6 amp transformer from Mouser for $13 today and will use it to power the tubes. The other option would have been to rewire them all in series and use a voltage divider to come up with 7.5 volts from a 12 volt source. At least if a filament opens up we power everything down, plus the voltage divider would be easier to construct without having to locate 15 watt resistors.

I love a few select old pieces of equipment, but powering them can be a pain in the empennage. I have a couple sources for the B+ 135 volt supply, so we should be good to go once the transformer arrives.

Meanwhile, I am on the lookout for an old National "doghouse" power supply for the SW-3.

Powering up the SW-3

2011-09-12T22:52:00.000-07:00

A while back, I posted a note about having found an old 1930's National SW-3 receiver. The rig came without a power supply. I need to have 2.5 volts at about 3 amps to power the tube filaments. I have a 6.3 volt supply at 4 amps, but need to bring this down to 2.5 volts at 3 amps. So, I thought I would just use a voltage divider.

o--------------------+-----------------o +6.3V
                     |
                     R1       3.8 volts across R1
                     |
                     +-----------------o +2.5V
                     |
                     R2       Load = 3 amp @ 2.5 volt
                     |
o--------------------+-----------------o 0V

So, how to design a simple two resistor divider? Assuming that there is no load current:

    Vout = Vin * R2 / (R1+R2)

The problem with this is that our load DOES draw current (about 3 amps) and therefore this will not work because the load can be considered another resistance in parallel with R2.

The 10 percent rule is a standard method for selecting R1 and R2 that takes into account the load and minimizes unnecessary power losses in the divider.

So, the first thing to do is select R2 so that I2 is 10 percent of the desired load current. This resistance and current is called the bleeder resistance and bleeder current. In this example, the bleeder current is:

Ibleed = I2 = 0.1 * 3 A = 0.3 A = 300 mA

Using Ohm's law to calculate the bleeder resistance:

Rbleed = R2 = 2.5V /0.3 A = 8.3333 ohm

Now, we need to select R1 so that the output is maintained at 2.5V. To do this, we simply calculate the total current through the resistor and use Ohm's law:

I1 = I2 + Iload = 0.3 A + 3 A = 3.3 A

R1 = (6.3 V - 2.5 V) / 3.3 A = 1.1515 ohm

Now considering standard resistor tolerances and value, this would indicate the need for R1 = 8.1 ohm for a 5% resistor and R2 = 1.15 ohm.

In terms of power ratings:

   P1 = V1^2 / R1 = 3.8^2 / 1.15 = 12.55 W
   P2 = V2^2 / R2 = 2.5^2 / 8.1 = 0.77 W

Did I do this right?

I am not sure what happened, but the first time I did this exercise, I (somehow) came up with R1 = 7.5 ohm 3 watt and R2 = 5.6 ohm 5 watt...

More coffee...

Back to working on the beacon project

2011-08-28T15:59:00.000-07:00

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.

New (old) lab power supply arrived

2011-07-12T20:15:00.000-07:00

With my renewed interest in old-tyme radios, I have decided that I need to have a good adjustable lab bench power supply that will give me filament, B+ and C voltages appropriate for these old radios.

I have located a nice Heathkit supply that has 6.3 VAC at 4 amps for filaments, adjustable 0 - 400 VDC at 100 mA and 0 - negative 100 VDC.

For my SW-3 receiver, the filament voltage is too high, so I will have to build a voltage divider to bring that down to 2.5 volts. Just tested it out and everything is working perfectly.

New receiver!

2011-07-12T20:10:00.000-07:00

After a couple years of looking, I have located a National SW-3 receiver that is in good shape.

It came with a couple sets of coils, a bandset coil set for 80 metres and an unknown coil set that was hand-wound by a previous owner as well as two sets of empty coil forms for my own hand-wound coils. Subsequently, I have obtained a bandset coil set for 160 metres.

I am now looking for a period power supply, preferably one of the National "Dog-House" power supplies.

My SW-3 is one of the earlier version 2 receivers. It has a pair of 58 valves (tubes) and a 50 valve (tube). The filaments are 2.5 volt and the B+ is anything upwards of 350 volts though the National power supplies typically supply around 135 volts. Meanwhile, I plan to locate a nice high voltage lab supply to be able to test this little beast out.

No updates for too long...

2011-07-12T20:01:00.000-07:00

Wow, has it really been nearly three months since I updated this blog? Very sorry to be away so long. I have a couple of new short posts to get back into the blogging mindset.

Sorry for no postings lately...

2011-06-07T09:59:00.000-07:00

My apologies for the long time between postings. I have been a bit preoccupied with my son's cancer treatments. I hope to be able to return to my electronics and ham radio pursuits soon.

Why I hate writing UI code...

2011-05-16T17:13:00.000-07:00

Now that the Atmel CPU is back alive, I have been back working on my beacon code. The underlying beacon code is finished for the most part. What I have been working on is the user interface (UI) code. Why is it that UI code is so dang hard to write and debug? I have decided that I suck at UI design, but I have taken a first stab at it. As is typical in many of my UI projects, it quickly degenerated into an amazing snake pit of spaghetti code, especially for the code that takes care of changing the various settings on the device.

Take for example the seemingly simple problem of setting the realtime clock to WWV. Set the clock values for the next minute and wait for the tone.

So, to set the clock, I put the device into clock set mode and display the current RTC information across the bottom line of the 4 line display. I set the seconds value to zero and put the cursor on the hours value and start it blinking. In the picture above, I snapped the photo when the hours value was blanked out. Rotating the dial will change the hours value within the range of values allowed (0 - 23). To move the the next value, a button push will cycle from Hours -> Min -> Day -> Month -> Year and back to Hours again. Each value will start blinking once selected and changed with the dial. Each setting value has a minimum and maximum value. It can be an 8 bit, 16 bit or 32 bit value. There is an option to pass in an array of text strings that are displayed rather than the numeric value as was done with the month value.

Once the value has been set, we wait for the top of the current minute and press another button to save the new value. There is an option to abandon the set operation and return to normal operation. The idea was to listen to WWV or some other time standard and set the clock at the top of the next minute. I may allow setting the seconds value if I get tired of waiting.

So, this ends up being a big huge state machine. It just seems like 80% of the code in this project is related to the UI. On an embedded processor with limited code memory, this is something to keep track of.

So, I have ripped out all the spaghetti code and replaced it with my new "value setting" utility and now should be able to reuse it to do any settings for this project. For example, space permitting I could provide a way to set the WSPR/QRSS beacon text by allowing each character to be set by the dial. The code should now be easier to reuse and eliminate the exponential growth of UI code, at least for the settings utility.

High Voltage programming the ATMega328

2011-05-16T16:42:00.000-07:00

Having smoked my first AVR CPU, I now face the need to be able to reset the CPU fuses regardless of their current settings. After some searching around, I decided to purchase a kit rather than roll my own. I picked up a "HV Rescue Shield" from "MightyOhm Engineering".

http://mightyohm.com/hvrescue2

A few simple minutes with the soldering iron and quite a few more minutes purusing the ATMega328 data sheet and I determined the values for the fuses that would get me back in business. A bit after the fact, I realized I could just read the current fuses on a working CPU chip and go with them, but it was educational nevertheless.

This little gem of an Arduino shield will handle the ATMega devices along with the ATiny2313 and 8 pin ATiny CPU chips. It also generates the +12v programming voltage on-board eliminating the need to have an external programming voltage supply.

So, back in business with my original CPU.

Smoked my first ATMega328

2011-04-16T08:20:00.000-07:00

I have been having a lot of fun upgrading my toolset for building AVR applications and hardware solutions. I have been playing around with both the raw WinAVR toolset as well as AVR Studio from Atmel. I also recently obtained a JTAGICE mkII from Atmel to hopefully be able to do some realtime debugging on my projects rather than having to always put serial port print statements in for debugging purposes.

The ATMega328 does not have a JTAG interface but instead has a one-wire On Chip Debug interface called debugWire. I do all my programming of the chip using an ISP (In System Programming) interface.

The Atmel device implements the notion of "fuses" that are basically switches that control certain feature or modes of the device. One of these fuses (DWEN - debug wire enable) is used to enable/disable debug wire mode. The debugWire pin is shared with the reset pin, so automatic reset hardware has to be disconnected for debugWire to work, which according to the Arduino Uno schematic is a non-issue.

So, for debugging you start in ISP mode to set the DWEN fuse. Unlike JTAG chips which have the JTAGEN fuse enabled by default the debugWire chips have DWEN disabled by default.

Once you have used ISP to switch to debugWire mode in theory you only need two of the 6 wires in the ISP header but as you need all 6 to get the chip back from debugWire to ISP mode (you can't change fuses in debugWire mode) you might as well leave all 6 connected. While in debugWire mode, the ISP mode is completely disabled.

So, since Murphy is still on the payroll of course, my first debugging experience ended up putting my ATMega328 in a mode where it can no longer debug, but the ISP interface is disabled so I can do nothing with it.

One possibility is that I have messed up the system clock fuses somehow. If that is the case, I should be able to apply an external clock to the chip and get it back. The other option is to use high voltage programming which should be able to recover from any of these states and get the fuses back to a coherent state.

So, my next project will be to build a high voltage programming setup. Oh sigh... Probably just as well as I need to build one of these HVSP (High Voltage Serial Programming) jigs eventually anyway...

Working with new tool chain

2011-04-10T21:32:00.000-07:00

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

2011-04-02T20:27:00.000-07:00

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.

Thanks for all the emails!

2011-04-02T07:59:00.000-07:00

I created this blog originally as a place to catalogue my ramblings and notes for myself. I have been receiving quite a bit of email from around the world however expressing interest in the project, the code, hardware details and interest in the software. While the project is not yet to a place where I am ready to publish details, that is the long-term plan.

I am however happy to help in any way I can anyone with a similar interest in this kind of project and have had some fun email exchanges as a result. I appreciate all the offers to help from many folks as well.

I invite anyone with comments or suggestions to email or more ideally to post comments on the blog so that everyone can benefit from the discussion. I will initially opt to not post emails as I want to respect the privacy of those involved unless explicit permission is provided to post those emails.

Trying to spruce up the Arduino beacon project

2011-04-02T07:51:00.000-07:00

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

2011-03-27T17:48:00.000-07:00

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

2011-03-24T22:15:00.000-07:00

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

2011-03-22T16:12:00.000-07:00

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

2011-03-18T08:43:00.000-07:00

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

2011-03-06T21:41:00.000-08:00

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

2011-03-03T16:23:00.000-08:00

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

Fun with DACs

2011-02-27T10:24:00.000-08:00

Today I have been playing around with an AD5330 8 bit DAC (datasheet) and generating different waveforms. For inspiration, I am using a document from Analog Devices (MT-085 Tutorial) on the Fundamentals of Direct Digital Synthesis (DDS). This is an excellent primer on the subject and I recommend it highly.

The setup is an Arduino Uno and a breadboarded AD5330 DAC from SparkFun.

From a block diagramme perspective, I have implemented a Numerically Controlled Oscillator as shown below (from MT-085 referenced above):

The "System Clock" initially in my software implementation is just the main loop of the Arduino sketch. Each time through the loop, the phase accumulator contents is updated. The tuning word (M stored in the delta phase register) is added to the number in the phase accumulator. I use the upper 8 bits of the phase accumulator as the address of a lookup table containing the digital amplitude information for whatever waveform I am generating. This table maps the phase information from the phase accumulator to a digital amplitude word which then drives the DAC.

As you can see from the photographs below, this prototype is only a proof-of-concept implementation and the system clock will need be a much more granular (and stable) implementation. The next step is to implement the system clock in a timer interrupt handler firing at about a 32KHz rate to make the waveform output much smoother.

I can change the waveform by just filling the digital amplitude lookup table with appropriate values. I have implemented SIN, Square, Triangle, Sawtooth with a positive slope, Sawtooth with a negative slope and random waveforms. It should be a simple matter to allow for a custom waveform to be uploaded in a general purpose function generator implementation (a project for another day perhaps...).

Off to figure out Arduino timers. I have used them to generate PWM output, but now need to figure out how to just generate an interrupt a precise intervals without interfering with the various digital output pins I require for DAC purposes.

Checking out the DS1307 RTC with Bus Pirate

2011-02-26T12:57:00.000-08:00

Today I am checking out the functionality of the DS1307 with Bus Pirate. I am supplying power and clock from the Bus Pirate board so +5/Gnd, MOSI/CLK are the only required pins. Here is the setup:

I set Bus Pirate to I2C at 50khz and turned on the power:

HiZ>m
1. HiZ
2. 1-WIRE
3. UART
4. I2C
5. SPI
6. JTAG
7. RAW2WIRE
8. RAW3WIRE
9. PC KEYBOARD
10. LCD
(1) >4
Mode selected
Set speed:
1. ~5KHz
2. ~50KHz
3. ~100KHz
4. ~400KHz
(1) >2
READY
I2C>W
POWER SUPPLIES ON
I2C>

Now I should be able to search for the device on the I2C bus and it finds the device at 0xD0, 0xD1 as expected, so at least it is responding.

I2C>(1)
Searching 7bit I2C address space.
Found devices at:
0xD0(0x68 W) 0xD1(0x68 R)
I2C>

Now, I try to read four bytes from the DS1307:

I2C>[0xd1 rrrr]
I2C START BIT
WRITE: 0xD1 ACK
READ: 0x00 ACK
READ: 0x00 ACK
READ: 0x01 ACK
READ: 0x01 NACK
I2C STOP BIT
I2C>

So, it looks like things are working, yay!

PC-less WSPR project

2011-02-25T12:14:00.000-08:00

It is long past time for me to start posting to this blog. My current project is an Arduino-based WSPR tone generation module. I am currently using an Arduino Uno along with a DS1307 Real-Time-Clock (RTC) for timing of WSPR transmissions and an MCP4725 DAC.

I am currently breadboarding the circuit as can be seen above and learning a lot about I2C communications programming. I have basic DDS software written and generating tones using the PWM functionality on the Uno and an external low-pass filter. I am now moving to a hardware DAC solution.

WSPR encoding and channel symbol generation code has been completed and verified against WSPRCode.exe available from Joe Taylor, the creator of WSPR so I am confident the WSPR generation bits are functional.

Initially, I am using my software DDS code to generate WSPR tones that could be then fed into an SSB transmitter. Longer term, I plan to use a hardware DDS to generate RF at the transmit frequency for stand-alone beacon use.