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!
Yes, a belated Happy New Year greetings! It’s hard to believe that 2013 is already well under way. I figured it was about time to give you a quick update on what’s going on in the shack right now.
First up is the discrete component grabber receiver for 14.141 MHz that I prototyped to be paired with the OpenBeaconMini project. The receiver itself consists of a roughly 2 kHz wide crystal filter on the front end, feeding into a single-balanced diode ring mixer, which drives an AF amp using 2N4401 and 2N4403 transistors. Because I’m not able to put up a proper outdoor antenna for the grabber right now, I decided to put the VE7BPO cascode active antenna on it instead. It seems to work well, but I don’t know for sure because there are basically no signals on this part of the band. I intended to use my Raspberry Pi with the receiver as a grabber, but I had no luck getting either LOPORA or QRSSVD to work properly and reliably. It may just be asking too much of the poor beast. So I’m going to try to appropriate another PC in order to get the grabber receiver QRV so that on-air testing of OpenBeaconMini can begin in earnest.
Next, I wanted to give you a very brief overview of my most recent purchase for the lab: a Rigol DS1022U arbitrary waveform generator. As far as I can tell, this appears to be pretty much the same as the DS1022A model that is sold in the US. But being a typical ham, I wanted to save a few dollars, so I purchased it off of eBay from seller who says he is an authorized Rigol dealer.
The DG1022[U|A] has two channels that can output a sine wave up to 25 MHz in 1 mHz (as in millihertz) steps. It can also provide square, ramp, pulse, noise, and arbitrary waveforms at lesser frequencies. It can modulate the waveform in a variety of ways, including AM, FM, PM, PWM, and FSK. It can, of course, also do sweeps of various parameters. The output amplitude into 50 Ω ranges from 10 Vpp on Channel 1 or 3 Vpp on Channel 2 down to 2 mVpp on both channels (or -50 dBm). The shielding on this AWG seems to be excellent. Using my HP 355C/355D attenuator combo, I can get a signal down to about -140 dBm (disclaimer: not a scientific measurement, made using my ear as a detector and listening on my IC-718). The dual outputs makes it very useful for a variety of two-tone receiver measurements, one of the big reasons driving my purchase. The Channel 2 output also doubles as a 200 MHz frequency counter input. Paired with the USB connectivity of the device (it seems to enumerate as a usbtmc device), that will be extremely handy for measuring oscillator drift. The DG1022 can also link the two channels together and give them a specific phase difference, as you can see below. This will make it very handy as a I/Q LO when I want to experiment with phasing and SDR rigs.
So far, I’ve been very pleased with my purchase. I don’t feel like I’ve had it or used it long enough to give you a full review, but I thought that this preview would at least be a bit helpful for those thinking about using it. One of my goals for the new year is to do a much better job of characterizing everything that I build. Since I intend to start selling transceivers in the near future, it’s doubly-important that I can make accurate measurements of my products so that I can properly state their specifications. To this end, I’ve decided to sell off a bunch of my unused or replaceable test equipment (please take a look at the for sale posting) in order to finance the new, calibrated test gear. Next up on my purchase list is a Rigol DSA815TG spectrum analyzer (just reviewed favorably in the February 2013 QST), but that’s going to require the sale of everything on that page!
Finally, I’ve got the CC1 prototype PCBs on their way from Seeed Studio right now. It looks like they just cleared customs in the US, so hopefully they will be in my hands in the next few days. With any luck, I’ll have the first one built by the weekend and will be well on the way to a new beta test. I’ll put up a quick post to show off the PCBs, and when the first prototype unit is completed. Stay tuned!
Sorry for the thin content on the blog once again. In the insufficient free time I have, I’ve been swamped with trying to keep OpenBeacon in stock and development of new products going. I’ve got a couple of questions for you, if you don’t mind chiming in.
First, I tried asking a question similar to this on the KnightsQRSS mailing list, but it rapidly devolved into a flamefest and I never really got much good, constructive feedback. So I put it to you. I’m interested in putting an 80 meter version of OpenBeacon on the market. There doesn’t appear to be much 80 meter activity in North America, but what there is seems to be located just above 3.500 MHz. The issue that I’m seeing is that choice of frequency excludes all American non-Extra Class hams. With 80 meters being such a large band, I don’t see any reason why another frequency could not also be used. I’m proposing to put the 80 meter OpenBeacon on 3.582 MHz. If operation was kept between 3.581800 MHz and 3.582000 MHz, I don’t believe it would interfere with any current informal band plans, but I’m not certain about that. I have a very large stock of 3.582 MHz crystals, which obviously also plays a factor (I would be willing to sell them individually to anyone who wanted the for their own homebrew endeavors). So my questions are: does this look like a decent frequency and is this something that would interest you?
The second query is in regard to a potential new product. I’m giving consideration to bringing to market a sort of companion receiver to the OpenBeacon. It could be used for a QRSS grabber or a dedicated monitor receiver for any of the digital modes with automatic propagation reporting such as WSPR, PSK31, or JT65A. I envision it being paired with a small SBC such as Raspberry Pi so that it could make a complete, stand-alone, efficient HF monitoring solution for around $100 total cost (Raspberry Pi currently costs $35). In my opinion, there is a lack of QRSS grabber stations in North America, and using OpenBeacon or other MEPT transmitters will be a lot more fun when there are more stations that can listen for your signal. If you use the receiver for the automatic reporting modes, you can build up a very nice set of data about propagation to your QTH. Here is a list of preliminary specs:
DDS or Si570/Si514 LO for wide tuning range and stability
PC tuning and control via USB (similar to OpenBeacon)
Single-signal reception (probably filter method, but maybe phasing)
Line-level output for PC consumption
So I ask you: is this something you would be interested in? Is there anything feature-wise you would like to see included?
Thanks for letting me pick your brains. I hope you stop by in the comments and leave some feedback!
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 use Google Reader to keep track off many of the websites and blogs that I’m interested in, especially the ham radio and QRP blogs. I’ve noticed that QRSS seems to be popping up quite a bit in the QRP zeitgeist lately. I suspect that Bill at SolderSmoke has been the catalyst for much of this. This post on the SolderSmoke blog appears to be the genesis of it all; many of the following posts have been QRSS related. Since this first post and all of the related discussion on the podcast itself, there’s been quite a bit of discussion out there on the Interwebs. I’ve also spotted blog posts from VK2ZAY and KF6KYI, as well as some threads on a few of the mailing lists that I subscribe to. It does seem that interest in QRSS (and beaconing in general) is on the upswing, and I wonder if our lousy propagation conditions have something to do with it (besides the attention from SolderSmoke)?
I have to admit that QRSS is one of those things that intrigues me, enough that I’ve purchased some 10.140 crystals, but you can put it on that huge pile of stuff in the corner that sounds cool but I haven’t had time to do yet. Perhaps when I get settled in the new QTH, my ham radio priorities will re-align a bit and beaconing will float up the stack a bit. I still have an experimental 10 meter beacon that I could put on the air with a bit more tinkering, and I’m sure it wouldn’t be too hard to get a QRPp QRSS beacon up and running. In the mean time, I’ll just be happy to get a regular ol’ QRP station on the air from my home!