Category Archives: Design

Wideband Transmission #1

2 Replies

This is the first in a series of blog posts covering a wide variety of topics. In the past, I have used Twitter for my microblogging needs. For a variety of reasons, I'm on a Twitter hiatus right now, so I'll be using this series to convey some of the disconnected (and possibly connected) random thoughts that I feel I need to get out there. I don't think I'll be abandoning Twitter completely, but I will be reworking the ways in which I use it once I come back.

I'm also in the process of disconnecting completely from Google, so I wanted to give fair warning to those who correspond with me via my Gmail account that I will be abandoning that service very soon. I've already deleted my Google+ profile, and will be deactivating the rest shortly. I'll probably describe my rationale for this later, but keep in mind that I've been a Google customer data mine for nearly a decade, so this is not something that I undertake lightly. I'll try to get alternate contact information to those of you who regularly correspond with me.

It is an age of new beginnings.

Clackamas 2 Prototype

With the introduction out of the way, let's get down to the good stuff. Above, you can see the latest project on the Etherkit bench. It's a re-work of the receiver from the Clackamas transceiver (the rig that I submitted to the 2010 FDIM 72-part challenge). I've decided to make this receiver into a cheap & cheerful little kit to get people warmed up for building the CC1. It's currently for 40 meters only, is a superhet, and is VXO tuned (covers 7.030 MHz plus a bit more). It is 100% discrete component (you can see a TDA7052 IC above, but I've abandoned it for a different AF amp) and will be SMT construction. The receiver itself is pretty simple, but you can see there's a fair bit of other circuitry on there. That stuff is mute and sidetone circuits. It's easy enough to design a standalone receiver, but most of them will probably just gather dust after being built unless they can interface to a transmitter easily. With this extra circuitry, you can just split off your transmitter's key line and connect it to this receiver to have built-in muting and sidetone. My goal is to make this project cheap and fun to build. I'll be fast-tracking this one so I can get back to the CC1 soon.

Oddly enough, another project from the FDIM Class of 2010 is also coming out soon. As spotted on The QRPer, the Cyclone 40 transceiver is based on the rig that Dave Cripe, NM0S submitted as his 2010 FDIM 72-part challenge entry. I recall that the rig had a very unique design and that the specs were impressive. Dave's a great designer, so be sure to buy one to get a rig unlike anything else you've seen before and to support 4SQRP.

Choking off the Internet firehose that I had previously directed at me has allowed me to devote a bit more time to enjoyable activities that I've neglected, one of those being reading. I'm currently enjoying a book I've had on my shelf for a while now called Seeing in the Dark by Timothy Ferris. It's billed about being about amateur astronomers, but it does get into the professional side quite a bit as well. It's a good read and very entertaining, and I can't help but see a lot of parallels between amateur radio and amateur astronomy.

That's a great segue to the final item, which is a bit of fun from our favorite Canuck astronaut, Cmdr Hadfield. He's leaving ISS in a few days and just released a surprisingly touching (although obviously light-hearted) rendition of Space Oddity by David Bowie (one of my guilty favorites). Cmdr Hadfield may not be on the level of Neil Armstrong or Yuri Gagarin, but he's definitely making a play for Coolest Astronaut Ever.

Stuff 'n Things

4 Replies

As a mild winter turns into an unusually nice spring here in Beaverton (last week we had multiple days with clear skies and highs in the upper 70s °F), a young ham's thoughts turn to portable activations, Field Day, SOTA, and the like. I've been looking forward to this summer for the opportunity to take the CC1 out in the field, but I may not get to be quite as adventurous as I hoped. Last winter, I slipped in a wet patch on the concrete in the garage and hurt my knee. As a typical guy, I didn't go to the doctor to have it checked out, I decided to "walk it off". It did heal, but not completely. So I finally gave in and saw my doctor about it a few weeks ago. She strongly suspects a torn meniscus, and ordered an MRI to confirm it. Unsurprisingly, my insurance company denied coverage on the MRI, instead expecting me to do a bunch of physical therapy based on at best a guess on what the problem is. Coming from a technical background such as mine, this boggles my mind. When you have a problem and you have the tools to make a measurement, you make the measurement to see what's wrong, not just take a course of action based on a guess! I understand that money is the driving factor behind this decision, but it still seems like a waste of resources for both myself and the insurance company. Not to mention that I don't have the faith in the efficacy of physical therapy that consensus medicine does.

So now I have to decide whether to shell out beaucoup bucks on physical therapy that probably won't do anything other than siphon money from our family to their coffers. And if that fails to miraculously heal the non-specific "knee pain" referred to by the insurance company, then I guess I get the privilege of paying for the MRI that I should have had in the first place.

I'm completely fed up with politics, so I have no desire for a political battle in my comments. I'm quite aware of the history of employer-provided health insurance in the US, and the effect of government distortions in the medical marketplace. There's plenty of blame to be handed out all around, so let's just leave it at that.

Anyway, I may not get to do any SOTA summits this year (except for perhaps a super-easy one such as Cooper Mountain right on the outskirts of Beaverton), but hopefully I can at least get out with the CC1 for portable ops to the park or while camping.

Speaking of the CC1, it's at a bit of a lull in its development right now. I'm waiting for all of the beta builders to complete their construction so I can be sure that I have all of the major hardware bugs worked out (which looks tentatively promising right now). I still have quite a bit of firmware coding to work on, then I'll be ready for the next (and hopefully last) PCB spin. With any luck, that should come in about 8-10 weeks.

In the meantime, I want to work on some side projects, and perhaps some opportunities to raise more capital to fund CC1 development. In that regard, I've been looking at a neat part recently. It's a MEMS VCXO from SiTime called the SiT3808. What's cool about this part is that it has linear voltage tuning, so that you don't have the uneven tuning response like you would from a varactor-tuned VCXO. The phase noise on the spec sheet also looks very good. I ordered some samples for 7.030 MHz and 28.060 MHz and breadboarded them to test the frequency stability. It was nothing short of amazing. The 7.030 MHz part had a long term drift of 5 Hz in 1.5 hours. The 28.060 MHz part drifted only about 20 Hz in 2 hours. That's pretty spectacular for CW use.

Since the 28 MHz part was so stable, I created a QRP transmitter for it by adding on a keying circuit and a couple of BD139 amplifiers. It outputs a very clean and stable 2 watt signal and has a tuning range of about 20 kHz. I also was fairly easily able to create a TX offset circuit, so that the transmitter can be paired with a direct conversion receiver (which I plan to do soon). Since tuning is linear, the offset is the same anywhere in the tuning range, unlike a typical varactor-tuned crystal oscillator.

I've been thinking about a way to introduce these parts to the ham community, since I don't believe that I've seen them mentioned by any homebrewers or used in any kits. Last week on the qrp-tech listserv, K7QO proposed a group build of the venerable NE602/LM386 direct conversion receiver (this one from chapter 1 in Experimental Methods in RF Design). Since this design is so well known, it seems like a "remix" of this design using the SiT3808 as the local oscillator might be a fun way to spread the word about the product. I breadboarded a version with the 7.030 MHz SiT3808 sample, which you can see below (the SiT3808 is in the upper-right corner, and it obscured by the tuning pot wiring).

NE602/LM386 Prototype Receiver with SiT3808

NE602/LM386 Prototype Receiver with SiT3808

It works exactly as expected. Wide open band signals directly dumped down to baseband, and a nice, stable LO. This particular SiT3808 part number only tunes about 4 kHz, but I will be able to get parts with a greater tuning range. I'm consulting with SiTime right now about bulk pricing, and hopefully I'll be able to do a kit run of at least 100 of these bad boys in the near future. Let me know in the comments if this is something that may interest you.

So that's my big rant for the day. Stay tuned for further updates on all of these projects in the near future.

Homebrewing Hangout

2 Replies

As I mentioned in the previous post, I wanted to try the Google+ Hangouts feature to attempt to do a video chat version of the old EchoLink chat that some of us used to have a few years ago on Saturdays. Today we took it for a spin, and I think I really like how it shaped up. We ended up having a total of 12 participants, with about half of the people actively participating, including AK6L, OK4BX, W0EA, LA3PNA, and WG0AT (Steve the Goathiker).

I've never used the G+ Hangouts before, so I didn't really know what to expect, other than a video chat. It turns out that it's quite a bit more useful than that. For example, you can do screensharing with your PC desktop or a particular window. Tomas OK4BX came prepared with an excellent slideshow presentation of the DDS-driven MEPT that he and his father recently put on the air. W0EA was able to show us the schematic and PCB layout of the amplifier T/R switch that he just sent out for manufacturing. You are also able to switch between multiple cams while in the Hangout, which AK6L used to give us some nice closeups of his projects. I've got a USB microscope which is basically a webcam with a high-power lens, so it would work great for showing off close-ups of things as necessary. We also got a neat treat to a live view of WG0AT's goats Rooster and Peanut, courtesy of his iPhone connection to the Hangout.

The only potential downside that I could see when compared to EchoLink is the free-for-all format versus the way that EchoLink facilitates traditional roundtables. It wasn't really a problem for our group, but I was at a bit of a loss on how to handle moderation. In the future, I think we'll start off with a sign-up queue to speak, then end with a free-form chat. There's also no native list of callsigns to call upon, but using a Hangout plugin (Lower Third), you can add a caption to your video stream with your name and callsign just like a TV chyron.

The overall impression was that the hangout went better than expected. We had some really interesting information presented and the turnout was excellent for a first time. I think this definitely is superior to the EchoLink chat. Now that I have an idea of what's going on, it should run even smoother next time. If you are not already a member, go to our Google+ Community page (Ham Radio Homebrewing) and join. The next time there is a Hangout, you'll get an invitation. We've scheduled the next one for two weeks from today due to it being close to Christmas next weekend. I'm not sure if this will continue on a weekly or every other week schedule in the future, but we will continue these Hangouts on a regular schedule.

Inkscape Manhattan Layout Template

2 Replies

I had a lot of requests for the Manhattan Layout Template that I mentioned in my FDIM seminar. Here's a quick & dirty link to the file. I consider it licensed under Creative Commons CC-BY-SA, although I haven't indicated it on the document yet. Hope you enjoy and put it to good use!

Manhattan Layout Template

OpenBeacon Update

Leave a reply

OpenBeacon Pre-production

Now that we are starting to get settled into a routine life with our new baby boy Eli, I've been able to sneak in some more work on the OpenBeacon project. The beta test is going fairly well, but I made a poor design decision in choosing a USB Micro-B connector and also made some schematic errors which needed to be patched for the beta PCBs. After we got home from the hospital and while Jennifer had her mom around to help, I was able to get back to Kicad, make the necessary changes and fixes, convert the USB Micro-B into a plain vanilla B and resubmit the files to Seeed Studio for rapid prototyping (also converted my EtherProg AVR programmer side project to USB B as well). Slightly less than two weeks later, and I had the nice circuit boards in hand!

First, I put together the EtherProg board to make sure that my new USB connector footprint was OK. A very quick assembly showed that everything was actually good this time! This gave me a bit of hope that maybe I completed the OpenBeacon PCB correctly this time. A bit nervously, I assembled the power supply and digital side of OpenBeacon, which rewarded me with some nice blinkenlights and proper USB enumeration on the PC. The analog side also went together quite nicely, although I needed to make a few component value tweaks in order to get the desired output power (about 300 mW) and enough harmonic suppression (maximum harmonic content of -45 dBc). A joyous day! Two successful PCB spins!

Now that the hardware is pretty much 100% nailed down, it's time to turn my attention completely to finishing the firmware. The basic beacon stuff is already in place, such as the QRSS, DFCW, Feld Hell, and CW modes. I still need to add extras such as multi-mode operation, custom glyphs, and multiple messages. But something has been whispering in the back of my mind lately. All of the previously mentioned modes are cool, but they lack the automatic reporting of some of the newer modes. It's particularly aggravating right now that there aren't many operational 30 meter grabbers in North America. It would be really cool to be able to add WSPR to the OpenBeacon repertoire so I can just set it and forget it. That seemed like a big challenge, but I have been following WA0UWH and KO7M having all kinds of beacon fun with their Propeller boards, and their efforts make it seem workable.

First OpenBeacon WSPR Capture

First OpenBeacon WSPR Capture

Thanks to an excellent blog post by KO7M, I was able to suss out the basics of the WSPR protocol and how to implement it in the relatively simple OpenBeacon hardware. The OpenBeacon uses non-linear varactor tuning of a VXO, while KO7M's Propeller beacon uses very precise frequency synthesis. I wasn't even sure if it would be possible to fake the necessary phase continuous 4-FSK modulation with the OpenBeacon, but I figured it was worth a shot to at least try to fake it.

Long story short, due to the robustness of K1JT's protocol and decoding software, I managed to pretty easily get a pre-generated message to transmit correctly with almost no tweaking of the transmitter. In fact, getting the transmit interval timing correct proved more challenging to me than the actual sending of the WSPR message symbols. The firmware is currently very bare-bones, with a hard-coded WSPR symbol string, hard-coded transmit interval (every 10 minutes) and the necessity to turn on the WSPR mode at precisely an even minute interval. Finishing out the firmware will require adding in the ability to change the WSPR message just like the standard message buffer, access to all of the WSPR parameters via the PC client program, and the ability to start the transmission with the pushbutton instead of doing it via the client program. Configuring the WSPR parameters will be a bit manual, but the beacon should be able to just sit there and do its thing once you've got that all setup.

So now the goal is to finish the firmware soon and get the Gerber files sent off to my PCB production house for a real production run. And get ready for my talk at FDIM! I know that these last two months are going to go awfully fast.

In the mean time, I'll be running the WSPR beacon for a while to see what captures I can get off 300 mW on 30 meters. It will also be a good test to see that the firmware can keep the transmit intervals synchronized over long periods of time. If I get any spots in the WSPR DB, I'll post them here as an update.

Edit: Here are my spots as of 0400 - 19 Mar 2012:

5 spots:

Timestamp Call MHz SNR Drift Grid Pwr Reporter RGrid km az
 2012-03-19 02:24  NT7S  10.140125  -15  0  CN85nm  0.02  NO6W  CM98  797  168
 2012-03-19 02:18  NT7S  10.140125  -24  0  CN85nm  0.02  NO6W  CM98  797  168
 2012-03-19 01:06  NT7S  10.140125  -17  0  CN85nm  0.02  NO6W  CM98  797  168
 2012-03-19 00:26  NT7S  10.140129  -24  -1  CN85nm  0.02  NO6W  CM98  797  168
 2012-03-18 22:34  NT7S  10.140126  -21  0  CN85nm  0.02  NO6W  CM98  797  168

The power is a lie, I'm actually at 200 mW, not 20 mW. Need to fix my WSPR symbol string.

25 Mar 2012 Update: I updated the firmware and client software to allow a WSPR transmission to start on command from the client. This allows me use the much more accurate PC clock to sync the transmissions. When only using the ATtiny85 timer, the best I could do was keep the beacon in sync for about 6 hours before it would drift fast or slow too much. With the PC tethering, I've been running overnight and all morning, and have managed to pick up a bunch of spots with my 300 mW.

42 spots:

Timestamp Call MHz SNR Drift Grid Pwr Reporter RGrid km az
 2012-03-25 18:24  NT7S  10.140170  -19  0  CN85nm  0.02  NO6W  CM98  797  168
 2012-03-25 18:18  NT7S  10.140169  -19  1  CN85nm  0.02  NO6W  CM98  797  168
 2012-03-25 18:12  NT7S  10.140168  -16  1  CN85nm  0.02  NO6W  CM98  797  168
 2012-03-25 18:06  NT7S  10.140167  -18  1  CN85nm  0.02  NO6W  CM98  797  168
 2012-03-25 18:00  NT7S  10.140167  -17  1  CN85nm  0.02  NO6W  CM98  797  168
 2012-03-25 17:54  NT7S  10.140168  -15  0  CN85nm  0.02  NO6W  CM98  797  168
 2012-03-25 17:36  NT7S  10.140132  -13  0  CN85nm  0.02  WA7KGX  CN85no  9  0
 2012-03-25 17:36  NT7S  10.140167  -13  0  CN85nm  0.02  NO6W  CM98  797  168
 2012-03-25 17:24  NT7S  10.140167  -18  1  CN85nm  0.02  NO6W  CM98  797  168
 2012-03-25 17:18  NT7S  10.140132  -16  1  CN85nm  0.02  VE6PDQ/1  DO33fl  1110  34
 2012-03-25 17:18  NT7S  10.140132  -16  1  CN85nm  0.02  WA7KGX  CN85no  9  0
 2012-03-25 17:12  NT7S  10.140142  -21  1  CN85nm  0.02  KC6KGE  DM05gd  1189  165
 2012-03-25 17:00  NT7S  10.140132  -18  1  CN85nm  0.02  WA7KGX  CN85no  9  0
 2012-03-25 17:00  NT7S  10.140130  -23  1  CN85nm  0.02  KL7UK  BP51ip  2468  326
 2012-03-25 17:00  NT7S  10.140131  -21  1  CN85nm  0.02  VE6PDQ/1  DO33fl  1110  34
 2012-03-25 17:00  NT7S  10.140168  -29  0  CN85nm  0.02  NO6W  CM98  797  168
 2012-03-25 16:54  NT7S  10.140131  -17  1  CN85nm  0.02  KL7UK  BP51ip  2468  326
 2012-03-25 16:48  NT7S  10.140133  -25  2  CN85nm  0.02  KC0TRX  EN34  2335  82
 2012-03-25 16:48  NT7S  10.140133  -17  0  CN85nm  0.02  WA7KGX  CN85no  9  0
 2012-03-25 16:36  NT7S  10.140145  -14  1  CN85nm  0.02  KC6KGE  DM05gd  1189  165
 2012-03-25 16:06  NT7S  10.140147  -23  1  CN85nm  0.02  KC6KGE  DM05gd  1189  165
 2012-03-25 16:00  NT7S  10.140138  -22  1  CN85nm  0.02  KC0TRX  EN34  2335  82
 2012-03-25 16:00  NT7S  10.140146  -23  1  CN85nm  0.02  KC6KGE  DM05gd  1189  165
 2012-03-25 15:36  NT7S  10.140147  -23  1  CN85nm  0.02  KC6KGE  DM05gd  1189  165
 2012-03-25 15:30  NT7S  10.140139  -21  1  CN85nm  0.02  KC0TRX  EN34  2335  82
 2012-03-25 15:24  NT7S  10.140147  -21  1  CN85nm  0.02  KC6KGE  DM05gd  1189  165
 2012-03-25 15:18  NT7S  10.140147  -23  0  CN85nm  0.02  KC6KGE  DM05gd  1189  165
 2012-03-25 15:06  NT7S  10.140135  -25  2  CN85nm  0.02  KC0TRX  EN34  2335  82
 2012-03-25 14:54  NT7S  10.140147  -20  1  CN85nm  0.02  KC6KGE  DM05gd  1189  165
 2012-03-25 14:30  NT7S  10.140147  -17  0  CN85nm  0.02  KC6KGE  DM05gd  1189  165
 2012-03-25 14:24  NT7S  10.140147  -20  1  CN85nm  0.02  KC6KGE  DM05gd  1189  165
 2012-03-25 13:48  NT7S  10.140136  -17  1  CN85nm  0.02  WA7KGX  CN85no  9  0
 2012-03-25 13:42  NT7S  10.140136  -16  1  CN85nm  0.02  WA7KGX  CN85no  9  0
 2012-03-25 13:36  NT7S  10.140136  -17  1  CN85nm  0.02  WA7KGX  CN85no  9  0
 2012-03-25 13:18  NT7S  10.140136  -17  1  CN85nm  0.02  WA7KGX  CN85no  9  0
 2012-03-25 13:12  NT7S  10.140136  -17  1  CN85nm  0.02  WA7KGX  CN85no  9  0
 2012-03-25 13:06  NT7S  10.140136  -17  1  CN85nm  0.02  WA7KGX  CN85no  9  0
 2012-03-25 11:36  NT7S  10.140134  -19  0  CN85nm  0.02  KC9NBV  EM69oe  3020  91
 2012-03-25 11:24  NT7S  10.140134  -16  1  CN85nm  0.02  KC9NBV  EM69oe  3020  91
 2012-03-25 11:18  NT7S  10.140134  -17  1  CN85nm  0.02  KC9NBV  EM69oe  3020  91
 2012-03-25 11:00  NT7S  10.140135  -2  1  CN85nm  0.02  KC9NBV  EM69oe  3020  91
 2012-03-25 09:12  NT7S  10.140136  -12  1  CN85nm  0.02  KC9NBV  EM69oe  3020  91

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!

Single-Ended Mixers and Reverse Isolation

3 Replies

Progress on CC-Series development proceeds at a reasonably-good clip right now. One of my last big hardware bugs to stamp out is some nasty microphonics that seem to be generated by the combination product detector/BFO. Today, I believe that I made some significant progress towards solving it and wanted to share what I learned.

IF Amp & Product Detector from CC-20 Beta 1

I've done a lot of reading in Experimental Methods in RF Design (EMRFD) about microphonics in DC receivers (read chapter 8!), and the number one cause of it is poor LO-RF port isolation in the mixer. The CC-Series uses a venerable old circuit which hasn't seen much use in a while. A dual-gate MOSFET is pressed into double-duty as a product detector and BFO (see above). Since the dual-gate MOSFET product detector is in a single-ended configuration, it inherently has bad LO-RF isolation. This allows VFO (or BFO in this case) signal to leak out the product detector input, and have a good portion of that signal reflect back into the product detector. So naturally, the CC-20 could be experiencing the microphonics because of this phenomena. One of the solutions mentioned in EMRFD is to put an amp in front of the mixer which has excellent reverse isolation (signals coming into the amp output don't tend to get out of the input, and therefore can't reflect back in again).

I had the suspicion that the common-source JFET amp in front of the product detector might be the culprit. So what's the best type of amp to place in front of a single-ended mixer? The common-gate JFET amp is a good and popular choice. However, VE7BPO notes on a recently published web page that the best commonly found amp configuration for this particular parameter appears to be the cascode (see the bottom of the page).

In order to test this theory, I went to work on a project that I had set aside earier: a direct conversion receiver based on the CC-Series product detector. When there was no preamp in front of it, the microphonics were unbearable. I figured that a good way to test my theory would be to put a cascode amp in front of this mixer and see how much it helped. I decided to put a dual-gate MOSFET preamp in front of it, as this is essentially a cascode amp and it fits with the dual-gate MOSFET product detector. Once the new preamp was added, the change was dramatic. The microphonics were gone.

Next, I decided to be a bit more rigorous in my study and quantify the exact difference between the common-source JFET amp and the dual-gate MOSFET amp. First I breadboarded the common-source JFET amp and ran it through the test procedure in the page linked above (at 18 MHz). The results were atrocious. Only 30 dB of reverse isolation, which is worse than the worst amp listed there (the feedback amp). Next, I dug out an old dual-gate MOSFET amp I had breadboarded for my 2008 investigations and ran it through the same test. As expected, the results were vastly superior: 68 dB of reverse isolation. This lines up nicely with Todd's measured results of >64 dB for the hybrid cascode (I used a spectrum analyzer while he used an oscilloscope, so I was able to get a pretty good measurement down to low signal levels).

So this appears to be strong evidence that the IF amp is the problem. It seems certain that the next version of the CC-Series is going to scrap those awful common-source amps for a much nicer dual-gate MOSFET amp. The lesson to take away from this is that if you are going to use a single-ended mixer for any but the most simplistic applications, it must be fronted with an amplifier with an excellent reverse isolation. While the typical common-gate JFET amp will work OK, for best results it looks like a cascode or dual-gate MOSFET amp is the way to go.

Curing Common Mode Hum in the VRX-1

5 Replies

As I've previously noted, the VRX-1 is a nifty little basic direct conversion receiver, but it has some shortcomings that could be problematic under certain circumstances. Here's a story of one of those issues and the cure that was found.

Dave AA7EE purchased and built a VRX-1 kit a while ago but was never fully satisfied with the performance due to an annoying 60 Hz hum. He and I had briefly traded comments on the topic via Twitter, but I never really seriously took the time to think about it until just recently. Dave had built and placed a peaked lowpass audio filter into the receiver thinking that would help with the hum, but unfortunately it did virtually nothing to help with it.

I was a bit surprised to hear of the hum problem, since I had never encountered any significant amount of hum, nor had I had other complaints of hum. The eureka moment came when Dave had mentioned that the hum went away when he disconnected the antenna, or it decreased in signal strength when he moved away from his home. I had assumed that the hum was a glitch in his audio circuitry, but this reminded me of the problem known as common mode hum. The best description of this phenomena is found on pages 8.8 - 8.9 of Experimental Methods in RF Design, but I can provide a brief overview. Common mode hum is the result of the LO leakage getting out of the antenna port, modulated by a mains power supply (like an old-fashioned model with rectifiers), and then re-received by the radio.

Due to the simple, single-ended mixer design in the VRX-1, I knew that LO-RF isolation was very poor. So the first suggestion to pop in my mind was to tell Dave to try a common-gate JFET preamp on the front end. Although these type of mixers have modest gain, they have a low noise figure, and even more importantly for us, excellent reverse isolation (on the order of 30 dB). This should be enough to kill any significant amounts of LO leakage.

Dave built a circuit from master homebrew experimenter, Todd VE7BPO. It's the last circuit on this page, and it looks rock-solid. A double-tuned circuit on the front and a single-tuned circuit on the output. Sure enough, that ended up doing the trick. Rather than trying to reinterpret Dave's thoughts, go visit that last link, then watch his YouTube video so you can hear the results for yourself:

I'm really pleased to hear that Dave's annoying problem is finally fixed. This makes me wonder, in retrospect, whether I should have just designed in a preamp to the VRX-1. It certainly isn't needed for noise figure purposes, but as you can see it can make a huge difference with those who might have problems with hum. There's also a well-documented problem of a loud impulse generated when the antenna is connected or disconnected during operation. I suspect at the reverse isolation of the preamp would also help this. Hindsight is certainly 20/20. If there is ever a VRX-2, then you can bet that it will get a stock common-gate preamp.

Creating PCBs with "PCB Fab-in-a-Box"

Leave a reply
G3UUR Crystal Checker

G3UUR Crystal Checker

I decided to make my initial Project X prototype PCBs at home using the old tried-and-true method of toner transfer (via Pulsar Professional paper and foil). Since I'm a novice at PCB layout, I didn't feel comfortable paying the money for a few proto PCBs from a board house, then finding out that I did something wrong and flushing that money down the drain. Instead of buying Pulsar's starter kit, I just purchased a pack of the transfer paper and a roll of the green foil. I also got the required GBC laminator from Amazon instead of paying significantly more for it from Pulsar.

Last night, it was time to give the process a whirl, so I decided to make a PCB of the G3UUR crystal checker circuit that was printed in the Fall 2010 QRP Quarterly (an excellent article, by the way). The instructions seemed clear enough, but I had about five failures before I finally figured out how to make the process work correctly. I was just about ready to chuck the whole thing in the trash bin, but I managed to keep my wits and persevere through it. For those who might be new to the process, let me help you to avoid some of the problems that I had:

  • Give yourself at least 0.5 inches of copper clad clearance on each margin of the final board edge in order to give the laminator good purchase on the board and transfer paper. Putting the toner traces too close to the edge will result in those edges failing to adhere to the board. There's just not enough heat and pressure to do the job properly at the edge.
  • When passing the copper clad plus transfer paper through the GBC laminator, I found that it worked better with four passes. Pass the board once, turn it 90°, pass it again, etc., until all four edges have been the leading edge through the laminator.
  • I didn't see this mentioned in the instructions, but after you apply the foil on top of the toner traces, you must let everything cool down to room temperature before attempting to peel the foil off the board. Failing to do so will rip most of your toner off of the board!

Once I got the bugs worked out, I was quite happy with the end result. I also decided to try out a new etching method. Instead of using ferric chloride, I used the hydrogen peroxide/hydrochloric acid recipe that I've seen touted on the Internet. Let me just say that it worked out beautifully and is waaaaay cheaper than buying ferric chloride. It only took about 3 minutes to etch my small board in a Ziploc baggie. No need to mess with expensive equipment or chemicals!

The etched board turned out very well. There are a few places with very close traces, as you can see in the photo above. These etched out perfectly, no problems at all. You might notice some bad copper on the bounding rectangle on my board, but that was because of the close clearance between that trace and the board edges. I know how to avoid that in the future.

Tonight, I got the board all soldered together and it worked perfectly on first power-up! That's always an extremely satisfying feeling. Now that I've got a handle on the process, I feel comfortable using it on the Project X prototype. Stay tuned for more progress on the new radio!

G3UUR Crystal Checker - Bottom

G3UUR Crystal Checker - Bottom

G3UUR Crystal Checker - Top

G3UUR Crystal Checker - Top

JFET Biasing Investigations

Leave a reply

I've been absent from the blog for a while because I've been knee-deep in developing the prototype for the first radio kit for my as-of-yet-unnamed open source kitbiz. The design makes extensive use of JFETs in cascode configuration. JFET cascode amps and mixers are very solid performers, but the issue of widely varying Idss in JFETs was giving me cause for concern in regard to how repeatable the design would be for mass production. In order to set my mind at ease, I did some research on the most stable way to bias JFETs for Id and did a quick experiment to confirm what I was reading.

The most common form of JFET biasing that you seem to find in homebrew QRP projects is self-biasing; where a resistor is placed between the source and ground, and the gate is tied to DC ground. This is a convenient way to bias a N-channel FET when using a single-polarity voltage supply, but it's definitely not the most stable form of biasing. According to Application Note 102 from Siliconix, using a constant current source to bias the FET will ensure a constant Id, but that seems like a bit of overkill in a simple QRP rig.

(a) Constant Voltage Bias (b) Constant Current Bias (c) Self-Bias (d) Combo-Bias

The image above shows the transfer characteristic curves for a 2N4339 biased with four different methods: constant voltage, constant current, self-bias, and combo-bias. The two Id-Vgs curves in each graph represent the normal production range of Idss. As you can see in graph (c), the load line QA-QB has a fair amount of slope, which indicates that Id will vary quite a bit as Idss varies. Graph (a) shows constant voltage bias, which provides the worst variation of Id by far. The source resistor provides the slope of the load line, so increasing Rs will flatten the slope and reduce the Id variation, but the problem is that it also chokes off Id and reduces the amplifier transconductance.

Combo-biasing (presented in graph (d)) helps to flatten the slope without losing all of your drain current. The load line in the self-bias graph has an intercept at the origin, which represents the gate at a DC voltage of 0 V. If you leave the source resistor in, and apply a positive voltage on the gate, the load line slope will flatten as seen in graph (d).

In order to see this effect for myself, I conducted a quick experiment with a batch of ten J211s that I picked from random from a bag of parts procured from Mouser. The first thing that I did was measure Idss by configuring the circuit on the left below and measuring the current through the source. Next, to measure the self-bias configuration, I placed a source resistor of 1 kΩ in the circuit and again measured the drain current. Finally, the combo-bias configuration was tested by applying 2.9 V to the gate through a 100 kΩ resistor, for a target drain current of 4 mA (the procedure for choosing the proper gate voltage is detailed in the application note).

No.Idss (mA)Id (mA) - Self Bias (Rs=1k)Id (mA) - Combo Bias (Vg=2.9)
112.282.134.40
211.831.974.24
311.151.894.16
413.202.234.48
514.222.374.61
611.581.874.15
712.782.104.36
811.951.984.24
913.012.194.43
1011.681.944.21
STDEV0.9280.1640.152
MEAN12.3682.0674.328
SD%7.50%7.93%3.52%

As you can see in the table above, self-biasing controls the drain current to a smaller range than Idss, but if you compare the standard deviation to the sample mean, you can see that it's roughly the same. The values of drain current in the self-bias circuit are roughly proportional to Idss. On the other hand, in the combo-bias circuit it's obvious that the drain currents are even more tightly controlled even though the mean is about double what it is in the self-bias circuit. The standard deviation as a percentage of the mean is approximately half of the self-bias circuit.

Note: it has been a while since I've taken Statistics, so I believe that I've made a valid comparison, but if I haven't I'm sure someone will let me know.

Now I understand one of the reasons that the string of source diodes is used in the Hycas IF amplifier. This provides the gate with a few volts of bias, which gives combo-biasing and drain current stability. The Siliconix application note shows voltage divider bias as a way of achieving this, but I've always been a fan of using diode bias where possible. This method of biasing should provide a good way of controlling for manufacturing variations when using JFETs in bulk.