Another CPO: Cheaper Beeper

I’ve been busy plugging away at my DDS/Arduino/VFO for 630m (more on that later), however yesterday I came across a neat little circuit for a code practice oscillator.

Cheaper Beeper CPO

Cheaper Beeper CPO

I’ve still got my previous CPO, however the simplicity of this one appealed to me. It’s two transistors, two resistors and a capacitor. All on a small piece of perf board.

In the image above, you can see the 9V battery connector. At the bottom are the two wires for audio out. And then in the middle there will be two more wires for the cw key. My plan it to mount it all in a small box with two 3.5mm mono ports – one for audio out and one for the key. That way I can either feed the audio into my computer for practice or into a speaker.



I’m thinking I may still build another CPO yet, as I really would like one with a sine wave – the square wave is a bit harsh and annoying. Plus, one with a sine wave I could wire into my FM rig for some code sending practice – if I find someone else so equipped. (I think sending the tone of these guys over the air would probably drive me and my practice partner nuts – not to mention anyone listening!)

Anyway, if you’d like to build one of these little guys yourself, the instructions can be found online here at the ARRL website. However, a word of caution.

There is a minor error in the schematic. If you’re rushing through trying to build the thing up quickly after work it may bring you unstuck – as it did to me. The PNP transistor in the schematic is marked as a 2n3904, however it is in the parts list as a 2n3906. Now a quick check would show that the correct one is the 2n3906, but if you just look at the schematic and go barging in blindly, well it wont work.

Anyway, enjoy! If you build one up send me a photo! 🙂

Sacrificial transistor - should've checked.

Sacrificial transistor – should’ve checked.

The Reverse Beacon Network

I remember a few years back hearing about the Reverse Beacon Network in a presentation given at CRARC. At the time I recall it seemed interesting, but then I was sidetracked by something else before I looked into it.

More recently I heard it mentioned in a discussion around (I think) the QRP Hours Contest on vkzlqrp mailing list. That got me thinking more and so I started reading and pondering.

RBN Home Page

RBN Home Page

The RBN is a simple idea, but like many simple ideas it’s a great one. People run their receivers (ideally SDR ones for wider bandwidth coverage, but even just a normal SSB receiver) feeding their input to their computer as they would for digital modes. Then they run CW Skimmer which monitors for CW signals – and specifically CQ calls with a callsign. Once these are detected, another piece of software (the RBN Aggregator) is used to feed these into the RBN network.

The ultimate result of all this, is that you can jump on a band of interest and send out a CW CQ call and see where in the world you’re making it to. Not too different to WSPR, however using an actual mode that you also use for QSO’s. Indeed, even people with no interest in RBN will still be detected just as a matter of using CW. In affect, it’s an automatic spotting database for CW.

So having my Softrock sitting around not doing much, I wondered about the potential of setting up and giving this a go. I still don’t have my HF antenna in place, but I do have my mini-whip. It seemed like a possibility.

I looked into CW Skimmer more and it looked straight forward enough. The only problem is that it’s commercial software. That is, after a 30 day trial period you have to pay – and not just some spare change. But at least with the 30 days I could see how it was and decide whether I wanted to do this long term and if so then consider paying. I do however, mean to do more of a search to see if there are any alternatives – but so far it seems not (and that’s possibly why there’s far fewer listeners on RBN than WSPR).

After downloading CW Skimmer and having a play, the following night I downloaded the RBN Aggregator and went about setting them up in unison. It was pretty straight forward, although the Aggregator has  changed it’s UI since the instructions on the website, and I did change a field only to find it would hang. But if I had of gone with the defaults it would have been a pretty simple affair.



To my amazement, in no time at all I was loading spots up to RBN. Albeit, I did have a couple of hiccups.

Firstly, my I/Q settings for my Softrock were back to front in CW Skimmer – so all my initial spots were around 7080kHz rather than 7010kHz. Secondly, I now know my Softrock is about 200Hz off, but I was able to fix this by adjusting the centre frequency in CW Skimmer.

Now, all appears to be going well. So the details of my setup are:

  • Receiver: Softrock Lite II (40m) – Listening to 96kHz with Audigy 4 sound card
  • Antenna: Mini-whip
  • Software: Windows XP SP3, CW Skimmer and RBN Aggregator

If you’d like to, you can view my spots on RBN. Hopefully I’ll be running for at least the next several days – depending on what else I’m doing. And whether I’ll do it long term, I’ll need to ponder whether it’s worth paying for CW Skimmer.

As you may see, I’m currently the only station listening from VK and there’s only one over in ZL. It’d be great if there were more down our way. I know of one other in VK1, but he’s currently moving house so is temporarily offline. I encourage people to give it a go – especially when you’re setup’s not in use.

Morse Code Resources

I’m still working away at learning my morse code. Practice kind of ended with the move to VK7 (as all things radio got a bit disrupted), but the last month or two it has resumed in earnest.

So I thought I’d share some of my current favourite resources that may be of use to others starting to learn or those more experienced looking to increase their speed.

I do a lot of my practice on the bus and at lunch in the library. So iPhone apps have been really useful. The main ones I use are:

  • Ham Morse – This is my main tool
  • Dah Dit – A useful tool, but probably goes against many principals of the Koch Method
  • MorseWords – A useful tool for words practice (especially seeing you can lock your phone and it will keep going)

As for online website tools, I’ve only really focused on one.

  • LCWO – Learn CW Online. Happens to be developed by one of the holders of 1000 cpm speed records and a very passionate CW op (that is, he also has an alarm clock he wrote that sends him his emails subject lines in morse code).

Computer software there is really only one I’ve used since I first thought of learning CW:

And finally some downloadable guides on how to learn/improve morse code:

Good luck to anyone out there using the above!

Beacon Keyer: Further Memory Optimisation

On the week-end I managed to further optimise my Beacon Keyer's memory use. It now looks like this:

AVR Memory Usage
Device: attiny13
Program:     712 bytes (69.5% Full)
(.text + .data + .bootloader)
Data:          6 bytes (9.4% Full)
(.data + .bss + .noinit)

The big item here is that 'Data' is now down to just 6 bytes! That is, the only data being represented is the string VK1IS plus it's null terminator – and also it happens to be using 2 byte alignment. This is due to placing all the look-up tables in PROGMEM.

Doing so is meant to add a little extra code, so in theory 'Program' should've also gone up (compared to back here when it was at 838 bytes). But at the same time I also removed a function I was using to control the PORTB pins and replaced it with two simple one line macros (one for key up, and one for key down). This simple change resulted in a good reduction in program size, and was an exercise is focusing on writing the code in the context of an MCU – rather than say a monolithic system. (Oh, and also included in this was a small bit of code to add an indicator LED for when the system is transmitting.)

Now in theory I can have the full string of "CQ CQ CQ DE VK1IS VK1IS VK1IS K". However I seem to be encountering an odd problem with the null terminator disappearing once the string gets to about 25 bytes long, so I need to look into this a bit more. Debugging MCU code is proving a learning experience in itself – as in this case the emulator does not seem to be working.

Anyway, once I sort that all out then I will consider it complete. Then hopefully I can return to my plans to play with the Arduino for a bit. 😉

Oh, and helping with all this (now being rigged up on a breadboard) is the little Sparkfun AVR Programming Adapter breakout board. For under $2, this little building block is gold!!

Arduino Arrived Today


In my playing with MCUs I finally decided to order an Arduino Uno. Originally I thought of them as a simple toy that would not equate to 'real' MCU programming, however I then realised (and it was pointed out to me) how close these are to the real thing and how great they'd be to get the basics of integration of components. To that end, I snapped one up pronto!

Today it arrived and I couldn't wait to finally attempt my first use of an LCD – in any form. Initially my plan was to try and use my LCD with an ATtiny2313, but it seemed like a bit of a way off as I'd also need to understand how to send the necessary raw data for the HD44780 protocol for an MCU. But the Arduino library has an LCD driver built in, so all I'd have to worry about is figuring out the wiring and just writing some very simple code. In other words, just learn the basics about how to connect up/integrate an LCD into a circuit and later I can focus on writing the low level code.

I'm happy to say, in my first night with my Arduino I succeeded in displaying text on an LCD within a couple of hours – and that was indeed after still making some wiring errors (thought I could skip the contrast control). To achieve the same result with a bare bones ATtiny2313 would have required significantly more effort – and when I stuffed up the wiring I wouldn't know if the problem was my code or the wiring. 😉

So, I look forward to building up a cool little radio project I have in mind that requires an LCD display and has an Arduino at it's core. Stay tuned, and consider grabbing yourself an Arduino – they're CHEAP and FUN!

CW Beacon Keyer Breadboarded

I managed to find a bit of time today and breadboard up my little CW Beacon Keyer with my ATtiny13. The idea was to simply have the MCU drive a NPN transistor to switch a key line. So  to that end, I simply wired up the circuit and then connected it to my CPO via the cable connected to my morse key. The video shows the result.

I'm pretty tickled, as this is my first MCU project so it was great to see it achieve what the intention was. It was also good that my CPO has an audio output that I can connect to my computer. With that, I ran FLdigi and it was great to see it had no trouble decoding the morse.

In the video you may also note the little SparkFun Breadboard Power Supply Stick I'm using. This provides a nice easy switchable 5V/3.3V and at the price was more convenient than me putting together a small board with just a 5V regulator. I ordered it from ProtoGear and had it on Friday just in time for the week-end. This will be rather useful for prototyping MCU and other TTL IC circuits on the breadboard.

Next step now is to draw up the simple circuit diagram and put together the full keyer – although that will also have an ISP connector. Might be harder to find time to achieve this next step though, but hey, at least the ideas there. 😉

CW Beacon Keyer V2

I’ve re-written (or, generated from my old ones) the character look-up tables and thereby the resulting encoding functions. Further, I then re-wrote the MCU control code to use the new encoding and wow! what a difference.

All now fits on a ATtiny13 (1K flash, 64B SRAM) as long as I keep the transmitted text to no more than 7 characters (more than enough for VK1IS) – keeping in mind the ATtiny13s only have 64bytes of SRAM (which also needs to store the lookup tables).

So here’s the stats when using the string ‘VK1IS’:

The old:

AVR Memory Usage
Device: attiny85
Program:    2000 bytes (24.4% Full)
(.text + .data + .bootloader)
Data:        240 bytes (46.9% Full)
(.data + .bss + .noinit)

The new:

AVR Memory Usage
Device: attiny85
Program:     838 bytes (10.2% Full)
(.text + .data + .bootloader)
Data:         48 bytes (9.4% Full)
(.data + .bss + .noinit)

As you can see, there are huge savings being made there. This is due to two key things:

  1. (SRAM) Encoding each character in 8 bits (where as previously letters were using some 5 or more BYTES each); and
  2. (Flash / Program) No longer using libc as I can encode the result in place – no need for a resulting dynamically allocated encode byte array.

This improvement also means I can now happily have an ATtiny85 send the full ‘CQ CQ CQ DE VK1IS VK1IS VK1IS K’.

There are more memory improvements that could be made to allow the ATtiny13 to support longer strings. Being coded in C, I can use the PROGMEM directive on the look-up tables so that they’re not stored in SRAM. This could result in a SRAM saving of about another 41 bytes – meaning in the above tables it would read ‘Data: 7 bytes’ (very nice). Might look into this soon.

For now though, I have a rather flexible solution for creating AVR based beacon keyers – and indeed keyers in general. I now might see if I can breadboard the basic circuit (time permitting) and hook up to my CPO. As I sit here I have a little ATtiny13 in my basic dev board flashing out VK1IS at QRSS1 speed.

Oh one thing that surprised me switching from the 85 to the 13 was the clock speed. You see both use the CKDIV8 fuse by default to divide the internal oscillator, however the 85 has an internal oscillator of 8MHz, however the 13 has an internal oscillator of 9MHz. This needs to be noted to ensure that the timings for my morse generation remain somewhat accurate.