Tag Archives: avr

OpenBeacon Miscellany

7 Replies

WA4KBD OpenBeacon in enclosure

I've got a quick grab bag of OpenBeacon updates for your reading pleasure tonight.

First off is the wonderful find and awesome mechanical construction skills of WA4KBD. He posted a message on the Etherkit forum about an extruded aluminum enclosure that he found on eBay that works perfectly for OpenBeacon. He brought pushbutton S1 and the TX and FSK indicator LEDs out to the same panel as the connectors, leading to the cleanest and best build of an OpenBeacon that I've seen yet. Bill also reported much greater frequency stability once OpenBeacon was housed in the enclosure. FB Bill!

There is also some new OpenBeacon firmware available for testing to those who have the ability to in-system program AVR microcontrollers. This update will correct some minor bugs, including a bug in the msgdelay function in CW mode. Importantly, there is also the addition of CW ID mode in the non-CW modes to give better compliance with FCC Part 97 ID rules. All of the details can be found on the Etherkit blog.

Finally, due to some unexpected and unsolicited blowback that I received on the KnightsQRSS listserv regarding the suitability of crystal oscillators in QRSS applications, I decided to look into methods of increasing frequency stability for OpenBeacon. To that end, a crystal heater seemed like the best bet, but they don't seem to be manufactured anymore (at least to my knowledge). Some investigations let me to discover that one type of heater was simply a thermistor mounted to a metal clip which slipped over a HC-49 crystal. So a bit of research at Mouser led me to a candidate thermistor which gets to about 80°C when connected to 13.7 VDC. I've mounted it using epoxy (JB Weld, to be exact) to a heat sink (rumor is that it might be a coin...but that might be of questionable legality). Then the heat sink/thermistor combo was secured to the side of the crystal with 3/4" diameter heat shrink. I'm in the middle of running tests right now, but initial results look promising. If I have a winner, I'll post instructions on how you can build your own cheap crystal heater, and might even offer a "kitlet" for sale.

Catching Up With Etherkit

4 Replies

The year is not starting out as well as I had hoped. Back during the beta test of the CC-20 I had set a goal to complete my revisions and be ready to sell production kits by 1 January 2012. Obviously that date has come and gone and I'm still not on the market. A few circumstances have contributed to this situation. First, the days available for me to work exclusively on Etherkit has been cut from 4 per week to less than 2 due to family member's work schedules being changed. Second, it took me longer than expected to tackle the bugs in the CC-20 beta; the worst being the high number of spurs in the receiver.

So where does thing sit right now? The next CC-20 board revision is just about ready to be implemented. I've had to move to a DDS with a higher master clock frequency and change out the product detector from a dual-gate MOSFET to a diode-ring mixer. One advantage of the new DDS is that I can greatly simplify the transmitter circuitry, but this will require the trade-off of a fairly significant revision of the PCB.

I have been getting my PCBs manufactured in China, and right now many of the manufacturing firms (my board house included) are shutting down for two weeks to observe the Spring Festival (Chinese New Year). So even if I do send my Gerber files to the board house, they probably won't be back for at least a month. In the meantime, I've decided to work on a side project that's been rattling around in my head for a while: a QRSS/CW/Feld Hell/Etc. beacon. Also, in response to a lot of positive response that I have received from my simple Twin-T code practice oscillator, I also spent a few days revising the circuit to make the output a bit more robust and then created a PCB for the circuit in Kicad so I could transition my EDA to an actively developed software package (I was using TinyCAD/FreePCB previously, which seems to be pretty much a dead end).

OpenBeacon Prototype

OpenBeacon Prototype

So allow me to tell you a bit more about the beacon project. For now, I've decided to dub it OpenBeacon (I know, so very original). But there is a decent reason for the name. Much like the CC-Series, I intend for this project to fill a niche in the market that is very empty right now. The list of notable open source/open hardware kits out in the market is very small. The only one I think of off the top of my head is OpenQRP. As far as QRSS kits, I'm only aware of the one from the talented Hans Summers. My goal for this project is to provide a kit that is open, extensible, relatively inexpensive and simple, and ripe for user modification. Let me tell you a bit more about the project specs and how they fit into this goal.

Let's start with the bare hardware. The transmitter is a standard, vanilla Colpitts oscillator followed by an emitter follower buffer, which feeds a class A PA with fully adjustable output power (provided by a very cheap and cheerful part, the BD139). At full-bore with 13.8 VCC, the transmitter can put out about 300 mW into 50 Ω. The brains of the operation is an Atmel ATtiny85 microcontroller. The way that it interacts with the transmitter is via its PWM output, which can generate a voltage from 0 V to 5 V after proper filtering. This control voltage is fed to a reversed-biased LED which acts as a varactor to tune the oscillator in very tiny amounts (< 10 Hz). The PWM output is essentially an 8-bit DAC, so not only can the varactor be flipped between 0 V and 5 V, but it can be set to many intermediate values, which allows for things like Feld Hell and just about any kind of graphic or glyph you can think of to be transmitted. The transmitter PA is also keyed with a PNP transistor which is controlled by the ATtiny85, which allows the OpenBeacon to operate in standard CW beacon mode.

The main way in which this project will meet the goals I stated above is in its user interface. There is a handy open source project called V-USB which gives USB interface capability to AVR microcontrollers that do not have USB built-in. This allows me to wire a USB port to the ATtiny85 and have the V-USB firmware take care of all the ugly business behind the scenes so that I can focus on interfacing the OpenBeacon to a PC. With a simple command line program, the user will have the ability to switch between the many operating modes available, set his own callsign and beacon message without having to have the microcontroller programmed for him, upload custom glyphs to be transmitter, and monitor the status of the beacon. No need to mess with jumpers or in-circuit programmers (although the ISP port will be available for those who want to hack their OpenBeacon). The client program is written in C and should be able to be compiled for Linux, Windows, and OS X machines.

KI6FEN Grabber Capture

KI6FEN Grabber Capture

Right now, the prototype is pretty much complete save a few minor tweaks. Yesterday, I got the code for the CW modes completed and put the beacon on the air in DFCW 6 second dit mode just above 10.140010 MHz. Conditions weren't great, but I did manage to get a few weak captures on the KL7UK grabber and one from KI6FEN via Twitter. The signal was way too wide and extremely drifty, but I've solved those problems by changing the coupling capacitor between the LED varactor and the oscillator and by creating a rudimentary thermal chamber for the beacon out of pink antistatic foam. I'll be leaving the beacon on for the next few days when I'm not working on the project (which will be most of the day). Any reception reports would be greatly appreciated!

So the plan is to get the CC-Series PCB revisions hopefully done by next weekend so that they can be sent off to the board house before their vacation is over. In my little bits of downtime, I'll continue work on the code for the OpenBeacon. The plan for this project is to get the PCBs cranked out very quickly. Now that I'm familiar with Kicad, I think it won't be too difficult or take too long to design the boards. I'm also going to be trying out a new PCB vendor which promises much cheaper prices and faster turnaround times on smaller boards such as this. With any luck, I can fast-track OpenBeacon testing and production and have it out while the CC-Series is in it's final beta test. Stay tuned, this is make-or-break time!

A Hellschreiber Clock!

1 Reply
Hellschreiber Clock Display

Hellschreiber Clock Display

I don't know if the guy who created this is a ham (he does say he's an engineer), but it's a neat application of some old-school technology. He uses a PIC 12F510 to output a Hellschreiber modulated square wave right to his PC's sound card line in port. I really get a kick out of seeing one of these "obscure" ham technologies escaping out into the Maker universe. The hardware is dead simple, as you can see in the instructions. If you wanted to try to create a Hellschreiber beacon, I don't see why you couldn't just take this same design and plug it into your rig's sound card interface instead of a PC. I'm already thinking about how cool this would be to try...there's a good chance I will give it a shot (with an AVR) after I finish up my latest DC transceiver. Watch out for more aliens infecting the bands.

BCD Switch Goodness

Leave a reply
DDS-60 Controlled by BCD Swtiches

DDS-60 Controlled by BCD Swtiches

A blog that I follow on a regular basis is from Aussie ham Peter Marks, VK2TPM. He posts from the perspective of an experienced ham who is really starting to get bitten by the homebrewing bug, so it's a real pleasure to see him discover some of the things which make that aspect of the hobby fun. In his latest post, he introduces us to his DDS-60 controlled by a bank of BCD switches. The whole shebang is tied together with an ATmega32 using C code compiled by the avr-gcc toolchain (my favorite).

I love this for a couple of reasons. First off, it reminds me of the first major homebrewing project that I attempted, the W8DIZ MultiPig. One of my favorite aspects of it was the PLL controlled by BCD switches exactly like this. As a side note, I never did successfully complete the MultiPig. Not for lack of effort (or ability, I think), but because I went and made some stupid life choices. However, I'm happy to say that I was able to cannibalize the remnants of my MultiPig for many successful homebrew projects later on. The second reason is just the cool factor. I guess it's the retro, 70s look and feel of the swtiches, but there's something alluring about the whole tactile experience of using BCD switches. FB job Peter!

Programming AVR Microcontrollers in Eclipse

Leave a reply

Lately, I have been using my Ubuntu Hardy Heron box for coding and programming my AVR projects using the simple combination of gedit, the avr-gcc toolchain and the USBtinyISP. It's a little bit of a pain to get set up correctly, but it works very well once it's up and running. I've been pretty happy with editing code in gedit then compiling and programming the AVR via command line. It's pretty easy to quickly make changes to the code and save the C file in gedit, then use the command history of the terminal to re-run make and avrdude.

However, I recently ran across this posting when browsing the AVR Freaks forum. The author kindly gives instructions on how to set up the Eclipse IDE for use in AVR development on the Ubuntu platform. This looked really promising, since I've always been a sucker for nice IDEs (yes, I know that probably lowers my geek cred a few notches). So I gave it a go and found that the instructions worked nearly flawlessly. The only hiccup I encountered was at the very end of the build process when Eclipse was waiting for the sudo password for avrdude (oddly enough, you have to run avrdude as root to access the USB programmer, unless you implement a little workaround that I'll show you in a second). I didn't see any way to enter the root password into a terminal, so I had to cancel the whole process.

A bit of thought and much more searching brought me to the answer to the problem. There is a way to get non-root access to the USBtinyISP. You have to create a udev rule to tell the kernel to change permissions on the USBtinyISP. The documentation on the ladyada website tells you to do this, but it only gives you half of the story. First of all, it doesn't mention exactly where to place the new rule that you are creating. Her documentation stated that I needed to put the rule in a file in /etc/udev/rules.d/. The problem is that this doesn't state whether I need to place the rule in an existing file or create a new one. After a bit of trial-and-error and yet some more Google searching, I found out that I needed to create a new file for the USBtinyISP. So a new file named 50-usbtinyisp.rules was created. The other problem is that the actual rule given on the ladyada site seems to have a typo in the MODE parameter. Comparing this rule to some other rule examples, it appears that the correct rule is:

SUBSYSTEM=="usb", SYSFS{idVendor}=="1781", SYSFS{idProduct}=="0c9f", GROUP="users", MODE="0666"

Once you get the udev rule set up correctly, you no longer need root to access the USBtinyISP, and the entire build process in Eclipse works flawlessly.

So far, using Eclipse as an AVR development platform has been a real pleasure. There's a lot of nice little touches, like having quick access to all of the special function registers of each device and easy configuration of the build parameters via GUI. If you are like me and like the convenience that an IDE gives you, then the AVR/Eclipse environment is an excellent choice, and may even be better than WinAVR.