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!
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.
My apologies for being a bit neglectful of the blog. Since a few weeks before FDIM, I’ve been in a mad frenzy to get OpenBeacon kits into production, get the Etherkit website up and running, do a better job of completing OpenBeacon documentation, supporting the inevitable hiccups that come with a new product release, and start working on development of my next kit. Between that and taking care of two little boys during the day, I’m sure you can imagine that something has to give.
So I wanted to let my loyal blog readers know that the OpenBeacon QRSS/DFCW/Hell/CW transmitter kit is in full production and is available for you to order. Currently the kit is available on the 30 meter frequency of 10.140 MHz, but I am working on getting a batch of crystals ordered so that I can start to expand the band offerings. The slow-speed CW modes are an excellent way to experiment with propagation, and it’s a lot of fun to see how far a QRPp signal can go with these modes.
Thanks, hope to be able to give you more content soon!
After a marathon session of hacking firmware, writing documentation, fixing bugs, and setting up my Etherkit shopping cart software, I was finally able to get the OpenBeacon project to a ready-to-sell state. I had enough parts on-hand to make 10 kits, so I spent a good portion of Sunday night getting them all packaged up and ready to go. After a bit of nervous testing, I flipped the switch to the Etherkit store from “sandbox” to “live”.
Once I posted a promotional message to QRP-L and qrp-l.org, I sold all of the kits pretty quickly (within about 12 hours, I think). I wanted to post to the KnightsQRSS listserv as well, but I never did get a reply to my email to the list owner to get permission to post my message. They probably would have went quite a bit faster if I had been able to post there.
There were a few folks who missed out on the sale. I apologize for that, I wish I had more kits to sell now. I did re-invest my sales into a large batch of OpenBeacon PCBs, which should be here in about 3 weeks. There’s a small chance I might be able to sell some more before I leave for FDIM, but if not, I will have them back in stock when I return.
In the meantime, I am working on the component changes needed to get OpenBeacon on 80 meters. I also have a request for a quote on custom crystals out to a vendor, so hopefully I can start expanding the bands fairly soon. I’m looking forward to trying to adapt OpenBeacon to 500 kHz, it should be a perfect kit for the band once it’s available to us US amateurs. Stay tuned for more updates soon!
My single HF antenna (a ZS6BKW) is pretty good for multi-band use, but it is fairly lacking in the 30 meter department. So any 30 meter OpenBeacon captures that I’ve been getting have been pretty exciting to me, given that I’m running 300 mW maximum power out of the transmitter. God only knows what my EIRP is. So far all of my captures have been from North Amercian grabbers, so I’ve been craving that magical “across the pond” capture from a far away land (as a side note, why does there appear to be virtually no functioning grabbers in Asia?).
Tonight, I finally got that capture. Two days ago, I implemented QRSS and DFCW (dual-frequency CW) modes with a very long dit time of 120 seconds. This is to allow a very weak signal to be integrated over a long period, such as the 6-hour grabbers available from the few fine hams who provide them. Last night, wasn’t able to get any coherent signals from the most reliable grabber for me, the W4HBK “Pensacola Snapper”, but I could see traces of my signal present. Tonight I turned on my OpenBeacon a bit earlier in the evening and was rewarded with a very nice capture from ZL2IK after waiting about four hours.
You can see my DFCW signal right in the middle near 10.140.000 Hz, with a bit of upward drift as I opened the door to my shack midway through the transmission. As you can probably tell, all of the other visible signals are meant for much shorter capture periods, so you can’t distinguish any callsign information from them in this long capture.
For those folks with actual decent antennas for their band of choice, this mode will allow them to really push the limits of QRPp. The OpenBeacon output power can be adjusted to somewhere around 20 mW, and with in-line attenuators, the noise floor is the limit. It will be fun to see if some people take up the challenge of very QRPp operation when OpenBeacon gets to market soon.
30 Mar 2012 Edit: Here are some more captures from today. The first is from N9VN (thanks Vince!) and the second is from the Pensacola Snapper.
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.
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:
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.
I’ve got another grab-bag of miscellaneous news for this post, but I’m going to lead off with the big one: I’m going to be a presenter at the world’s preeminent QRP convention: Four Days In May 2012. The tentative topic for my presentation will be about the free and open source tools that I use in the development of my products and how you can put them to use in your own homebrewing endeavors. This will be my first time speaking to an audience larger than about 25 people, so I hope that I can provide an entertaining and informative talk at such a prestigious event. I’ll be speaking in front of a lot of people who I consider to be much more capable than I and some who I consider my virtual Elmers. It is my sincere desire to not disappoint.
I am very excited for the opportunity to go back to Dayton so soon after my last trip. I really didn’t expect to have the chance to go again for quite a few more years, so the ability to get back to the convention after only two years is a great blessing. I owe a great debt of gratitude to Jennifer, who didn’t hesitate to encourage me to go, even though she will be dealing with a 2-month-old baby and a near 2-year-old by herself for a few days while I’m away.
In other news, I feel like I’ve gotten over the steep part of the learning curve with Kicad, having successfully made PCBs for my little Twin-T code practice oscillator. You can see a short video of it in action above. The output level is suitable for modern, sensitive headphones, but if you want room-filling audio such as in my video, you’ll need to connect it to an amplified speaker. The PCB is designed to fit in the ubiquitous Altoids tin, with room to spare for a 9 V battery. I expect that this will eventually make it to my stable of products, but it’s low priority considering the long delay on the CC-Series and the need to get it ready to sell by May. If you are really interested in the project, write a comment or shoot me an email (milldrum at gmail) and I’ll see if I can’t work something out to get you hooked up with a kit early.
The OpenBeacon project is cruising right along. Now that I know that I can successfully make a PCB with Kicad, I’ve taken the plunge and decided to migrate all of my workflow there (I think this will include the next board spin of CC-Series, since there are so many changes to be made there will be no real advantage to staying with TinyCAD/FreePCB). The OpenBeacon PCB design is nearing completion. Once I get a shipment from Mouser in the next few days to verify that my newly-created PCB footprints match the actual physical components, I’ll be ready to submit my CAM files to Seeed Studio for prototype boards. With any luck, I’ll have them back within about two weeks. (Protip: it’s worth taking the time to place your component against a 1:1 printout of your Gerber to make sure it will fit. Don’t ask me how I know this.)
Once those CAM files are off to China, it will be full-bore on the CC-Series. With the deadline of mid-May staring me down hard, I figure I will have to get those CAM files out within no more than three weeks. That will put me into mid-March for getting the PCBs back, which will give a pretty slim margin of time to beta test and prepare the kit for final sale. Going to be pulling some long, late-night shifts…that I can already see.
I’ve also got a few more projects in the pipeline for after FDIM and the deployment of CC-Series and OpenBeacon. The first is a fairly simple and inexpensive VXO DC transceiver that I hope to initially kit for the high bands of 10, 12, and 15 meters. It uses a topology which is somewhat unique. The other is an extrapolation of the receiver circuitry of this rig to use as a dedicated QRSS grabber receiver. But I may be getting a bit ahead of myself. Let’s get this CC-Series launched, then see where the winds take us.
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!