Monday, November 14, 2011

LCD Performance and UI decisions in the beacon project

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:

  1. Provide the frequency to an external function that takes care of the magic itself and leave the details up to the implementer.
  2. 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.

Sunday, October 30, 2011

I am confused...

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

------ = .5 A primary current total or .25 A each winding

------ = 2 A secondary current total or 1 A each winding.

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

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

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.

Sunday, October 9, 2011

SW-3 is on the air!

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.

Thursday, September 22, 2011

Bogen T725 transformer

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 where you can find lots of ideas on how to use these devices.
Bogen T725 Schematic
I was able to locate a number of these little dudes online ( 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.

Friday, September 16, 2011

Playing around with APRS tonight

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.

Wednesday, September 14, 2011

ArisSat1 heard this morning

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.

Tuesday, September 13, 2011

And now for something completely different...

Reading the 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)

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.

Monday, September 12, 2011

Powering up the SW-3

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

Sunday, August 28, 2011

Back to working on the beacon project

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tuesday, July 12, 2011

New (old) lab power supply arrived

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!

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

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.

Tuesday, June 7, 2011

Sorry for no postings lately...

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.

Monday, May 16, 2011

Why I hate writing UI code...

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

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

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.

Saturday, April 16, 2011

Smoked my first ATMega328

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

Sunday, April 10, 2011

Working with new tool chain

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

Converting from Arduino IDE is pretty straight forward:

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

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

Saturday, April 2, 2011

New RTC and data logging shield for beacon project

I have built one of the fine data logging shields for Arduino from the fine folks at Adafruit to further clean up my beacon project rats nest.  The new setup looks like this attached to my Arduino Uno.
I need to add a socket for the DDS-60 and a couple headers to bring data GPIO lines out.  The real-time clock has been tested and is functional.  This should be my final setup until a PCB is created for this project.

Thanks for all the emails!

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

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.

Sunday, March 27, 2011

QRSS/WSPR band befuddlement...

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

Here are the WSPR dial frequencies(USB) for everything below
60 MHz (limit of the DDS-60) according to

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


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

Thursday, March 24, 2011

I2C LCD performance

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

Tuesday, March 22, 2011

WSPR Beacon update

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

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

I think what is intended here is the following:

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

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

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

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

Friday, March 18, 2011

GPIO Liberation

I have been endeavoring to liberate I/O pins on my Arduino project.  To that end, I have moved to an I2C LCD interface.  This is necessary to enable integration of an RTC (real-time clock) for WSPR timing.  The new setup looks like this:
I have some concerns about the performance of the LCD driver so I may have to do some customization of the driver.  The good news is that the beacon in operation is unlikely to have or need a display or rotary encoder as the set of operational frequencies will be fixed.  Calibration of the DDS-60 can be accomplished with a test setup that includes a rotary encoder to set the clock and then disconnected for day-to-day operation.

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

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

Sunday, March 6, 2011

WSPR Beacon with Arduino and DDS-60

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

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

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

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

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

Thursday, March 3, 2011

QRSS with a DDS-60

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

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

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

Sunday, February 27, 2011

Fun with DACs

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.

Saturday, February 26, 2011

Checking out the DS1307 RTC with Bus Pirate

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:
1. HiZ
2. 1-WIRE
4. I2C
5. SPI
10. LCD
(1) >4
Mode selected
Set speed:
 1. ~5KHz
 2. ~50KHz
 3. ~100KHz
 4. ~400KHz
(1) >2
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.
Searching 7bit I2C address space.
   Found devices at:
0xD0(0x68 W) 0xD1(0x68 R)
Now, I try to read four bytes from the DS1307:
I2C>[0xd1 rrrr]
READ: 0x00 ACK
READ: 0x00 ACK
READ: 0x01 ACK
So, it looks like things are working, yay!

Friday, February 25, 2011

PC-less WSPR project

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.