A few exciting developments here on the Si5351 front. First off, I took the C code from my Si5351 library for avr-gcc and converted it to an Arduino/C++ library, which you can find here. It replicates the functionality in the avr-gcc library, but makes it quite a bit easier to rapidly implement designs. I’ve tested this design on an Arduino Uno and an Arduino Uno clone, but I see no reason why the library shouldn’t work on other Arduino variants as well. Please give it a try and leave feedback on the GitHub page if you find bugs or have suggestions for improvements.
The other news is about the Si5351 Breakout Board that I mentioned in the last post. I just got the 3 purple PCBs back from OSHpark and they are most excellent.
I got one quickly populated with components and paired it with an Arduino in order to test the new library. As you can see in the photo at the top of the post, it’s a pretty small little board, but it’s pretty powerful for its size. All you do is connect VCC, GND, and the I2C SDA and SCL lines to the Arduino, and you get three independent transformer-isolated outputs on SMA connectors that can generate 1 to 150 MHz (in the future the library will be modified to allow the full 8 kHz to 160 MHz range)
Will I end up selling these as a kit? I’d like to but I’m uncertain at this point. Oddly enough, I just found out that it’s highly likely that Adafruit will also be selling a Si5351 breakout board. If you watch the video below at about the 6:22 mark, you’ll see it.
I’m a bit surprised by this, as RF is not something that I was aware that Adafruit was interested in. To be honest, it will be difficult to compete against the relatively much larger fish in the hobbyist pond that is Adafruit. Although, it looks as though my breakout board has something that the Adafruit board does not: isolation output transformers. Most likely, I will do one trial kitting run and see if there will be enough interest for another after that. Keep an eye on the blog for further news about that in the near future.
The Si5351 library for avr-gcc that I’ve been promising for the last four posts is finally in a state where I feel comfortable releasing it, so I’ve posted it on GitHub. I think that the documentation posted on the README file and inside the code should be enough to get you going, but if you run into problems, please comment here or file an issue on the GitHub repository.
At this point it is very basic, but it will generate frequencies from 1 to 150 MHz on any of the three outputs of the Si5351A, and you can do stuff like turn the clocks on and off and change the drive strengths of the output drivers. More features will be added as time goes on, with the priority on things which will be needed to make a functioning amateur radio transceiver.
I’d like to point out something interesting that I’ve discovered about the parts that I’ve been working with. I ordered my Si5351A parts from Mouser (P/N 634-SI5351A-B02075GT). I never had any luck communicating with them on the datasheet-specified I2C address of 0x60; instead they need to be addressed at 0x6F. Thanks to the Bus Pirate and its built-in I2C address space scan macro, that didn’t take me too long to figure out. I just chalked it up to yet another datasheet error (the Si5351 is riddled with problems), but it turns out that I may actually have some defective or custom parts which shouldn’t have made it out to Mouser.
Over the last few days, I have been corresponding via email with Ian K3IMW, who has been having a horrible time getting his Si5351 to work. After he described his symptoms to me, I suggested that he try address 0x6F, and sure enough, that worked. What confounded him was that another ham he was in correspondence with was able to talk to the Si5351 using address 0x60. It turns out that those parts that work on 0x60 were from Digi-Key and both Ian and I obtained our parts from Mouser. So, the theory is that perhaps some custom parts accidentally made it out the door to Mouser. I will try to contact Mouser in the next day or two and see if perhaps they can get it straightened out with Silicon Labs.
The moral of the story to to pay attention to where you got your parts from if you are having problems with the Si5351. Once I can get my hands on some of the same P/N from a different vendor and can confirm that it does indeed work on address 0x60, I will make the change in the library. In the meantime, you may need to change that value yourself in the si5351.h file in order to get it working.
Since the previous Si5351 Investigations post, I’ve made quite a bit of progress integrating the Si5351 into a grabber receiver. First, let’s look at the grabber receiver architecture and how the Si5351 is used in it.
Above you can see the basic block diagram of the receiver. The front end has two switchable plug-in bandpass filter modules (which is switched by a pair of TI TS5A3157 analog switch ICs controlled by the AVR microcontroller). An ADE-1 diode-ring mixer is fed directly from one of the Si5351 ports set for the lowest output level (which is about +8 dBm). The pair of IF amplifiers are TriQuint AG203-63G MMICs, and the actual IF filter is a 6-crystal ladder filter with a bandwidth of 3 kHz (filter plots provided below). Another ADE-1 is used as the product detector, with the BFO signal provided by another output port on the Si5351. Finally, the recovered audio is amplified to line level by a NE5532 op amp and delivered to a 3.5 mm stereo socket by way of a transformer in order to provide good ground isolation between the receiver and sound card.
As an interesting side note, you can see my modular bandpass filter boards below. They are your standard double-tuned circuits placed on a 20 mm x 50 mm piece of copper clad, with 0.1 in SIP headers soldered to pads cut out of the material with a rotary tool. There are some extra pins which are reserved for a future module identification system.
Happily, the receiver mostly worked as expected right out of the gate. A few minor tweaks need to be made, such as in the gain of the AF amplifier, but I’m pretty happy with the results so far. Although it’s my intention to pair this receiver with a Raspberry Pi running LOPORA in my garage, right now the receiver is sitting on my bench capturing WSPR RF on various bands, and looks to be doing a fine business job doing that. Frequency stability looks at least as good as my IC-718 on WSPR, based on an eyeball assessment of WSPR spots.
The Si5351 seems to do a bang-up job acting as both the VFO and BFO. What’s nice is that I can easily switch sidebands merely by changing the output frequency of the CLK1 BFO output with one line of code. I haven’t seen any indications of spurious products affecting the receiver yet.
My Si5351A library for avr-gcc is still pretty rough, so I’m not quite ready to publish it yet. Next up on my todo list is to get it in a state where I’m ready to put it up on GitHub, then implement the USB control protocol and client program so that the grabber receiver can be tuned via command line (especially handy when using SSH).
At this point, I’m fairly confident that the Si5351 will make a very fine oscillator system for a grabber receiver. My next line of investigation is to look at the temperature stability of the Si5351 via a thermal chamber lashup. I’ve got a nice Styrofoam cooler, an Arduino knockoff, a 120 V relay shield, a temperature sensor, and a frequency counter I can read via serial port, so I just need a heat source (probably in the form of an incandescent bulb) and I should be good to go. Keep watching for more experiments!
It has been another productive weekend with the Si5351 here in the shack. Since the last report, I’ve made significant progress in confirming that the Si5351 may be a good candidate for use as a LO in a radio.
After getting the most basic communications with the Si5351 going via the Bus Pirate, my next task was to find out if I could determine a calibration routine that eventually would be easy enough for anyone to do with even simple equipment like a digimode PC program and WWV. Recall from my previous post that there was quite a bit of error in the output frequency when uncorrected (over 1 kHz error at 20 MHz output frequency). According to its datasheet, the Si5351 has 0 PPM of inherent frequency error, which means that all frequency errors should result only from the attached 25/27 MHz reference crystal. Theoretically, if that can be measured, one calibration value should be good across the entire tuning range.
I added in a line of code to change the nominal 25 MHz reference frequency (called “parent_rate” in the above code snippet) based on an amount of error entered as a command line argument in parts-per-ten million. This reference frequency is the basis of the calculations of the two synthesizer values calculated in the program, so tweaking it to its actual oscillation frequency should give the proper output frequency wherever that output frequency is set.
After adding this simple calibration code, I first used my tuning program to output a set of registers for 10.000000 MHz oscillation with 0 correction. These tuning registers were loaded into the Si5351 and the output was measured on my Tektronix DC 503A frequency counter at 1 Hz resolution. A difference of -887 Hz was measured between the nominal 10.000000 MHz frequency requested and the actual output frequency. Next, as you can see in the screenshot above, I entered a correction factor of -887 parts-per-ten million into the tuning program and generated a new set of tuning registers. (For those who are curious, the program prints out a variety of variables for troubleshooting, then at the end spits out the hexadecimal code for the Bus Pirate to send the registers to the Si5351. I just copy and paste that string into my serial terminal).
Happily, the Si5351 output a frequency within 1 Hz of the nominal 10.00000 MHz requested frequency. Experiments with other tuning frequencies showed similar amounts of error. Up at 50 MHz, the frequency counter only showed ~3 Hz of error. This bodes very well for the use of the 5351 in amateur radio projects.
So, with calibration seemingly under control, it was time to move everything over to a microcontroller. The above photo shows the current hardware setup. I’ve added my old favorite, an Atmel ATmega328P microcontroller, with a 16 MHz crystal. I have also added a USB B jack, as I intend to make this Si5351 controlled and powered exclusively via USB. Since the Si5351 operates off of 3.3 V power, I provide power to it and the ‘328P via a LE33CZ LDO regulator fed from the USB 5 V supply. I have also added some simple resistive voltage dividers to the AVR ISP lines to convert 5 V programming signals down to 3.3 V.
Fortunately, I now seem to have enough AVR code sitting around that a lot of these new endeavors can be launched very quickly via the application of a bit of copy-and-paste. I borrowed a bit of I2C code from some CC1 development work and pasted in the rough tuning code that I originally wrote for the Linux command line. A bit of jiggery-pokery and I was able to get the ‘328P sending I2C commands to the Si5351 to set various parameters and tune to a non-default frequency in order to ensure that the I2C comms were working.
Which is where I currently sit with the project. Next up on the agenda is to write a basic Si5351 library for the ATmega88/168/328 series and then paste in the V-USB code in order to get USB control up and running. After that, it will be onward with the grabber receiver portion of this experiment. Stay tuned for updates (and yes, code will be forthcoming on GitHub once it’s in a decent state).
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.
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).
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.
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!
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.
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!
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:
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.