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.

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.

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

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

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

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

Converting from Arduino IDE is pretty straight forward:

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

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

New RTC and data logging shield for beacon project

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

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

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.