Coding, Cool Stuff, Etherkit, Wideband Transmission

Wideband Transmission #8

Another 10 mW WSPR Beacon

I enjoy writing up my projects, but it’s much better to get feedback to see that someone was actually able to take my writing and successfully duplicate my project. Via the Etherkit Twitter account, I received this from Tom Hall, AK2B regarding my last posted project:

Awesome work! Tom has been a great supporter of Etherkit from the beginning and I’d like to thank him for sharing his neat creations with the rest of us. It’s wonderful to see such a minimalist design perform so well!

More Coding Resources for Fun

I haven’t had a ton of free time here, but I do get snippets of time occasionally where I can sit with my notebook PC for a bit and mess around. As mentioned in some recent posts, I’ve been revisiting coding for fun, and I’ve stumbled upon quite a bit of new resources that are new to me and that I thought would be good to share.

The first one I’d like to mention is called Scratchapixel. I was curious about the mathematical methods behind 3D rendering, and some searching brought me to this exhaustive tutorial site. It’s not 100% complete yet, but most of the fundamentals of 3D graphics are already well-explained there. A fantastic resource if you are curious about the first principles of 3D rendering like me.

A related site is called Shadertoy. Not by the same people, but also related to the topic of learning 3D programming. Shadertoy is a web application that lets you play with shaders in C++ inside a web IDE that can be updated on-the-fly. It takes a bit of CPU and graphics horsepower to run comfortably, but if you’ve got the capacity, it’s worth browsing the demos on the site just to see the cool stuff you can create with it. This tool was created by Íñigo Quílez, who also has a really cool home page with lots of tutorials and whitepapers. If you like demoscene stuff, then definitely check it out.

Another neat find that I only recently discovered goes by the name of Rosetta Code. It bills itself as a programming chrestomathy site, which basically means that it’s a way to learn how programming languages are related in a comparative way. There is a large directory of different programming tasks, and each task page lists ways to implement a solution in a wide variety of languages. It’s a wiki, so not every page has every language implementation, but there’s obviously a ton of work put into the site, and most tasks have implementation in the major languages. Really fascinating and useful at the same time.

Finally, there’s The Nature of Code. This site hosts a free e-book download of the content, and provides a link to purchase a dead tree version if you wish. Here’s how the website describes the book:

How can we capture the unpredictable evolutionary and emergent properties of nature in software? How can understanding the mathematical principles behind our physical world help us to create digital worlds? This book focuses on the programming strategies and techniques behind computer simulations of natural systems using Processing.

That sounds right up my alley. I haven’t read the book yet, but I have skimmed it a bit, and it looks like the kind of things that I love: non-linear systems, physics simulations, fractals, and the like. When things settle down here a bit, I may tackle the book and re-write the sample code into Python. That would give me some more Python practice and force me to really think about the algorithms behind the text, not just blindly copying, pasting, and executing the scripts.

Let me know in the comments if you found any of these links useful or fascinating, or better yet if you know of other links in the same vein.

New Miles-Per-Watt Record Opportunity?

If you regularly follow science news, you may have heard of the Breakthrough Starshot initiative. In short, this is a study to create pathfinding technology that would allow the eventual launch of micro-lightsails with tiny mass to the Alpha Centauri system at a significant velocity (0.2c!) with a ground-based laser array. It’s probably a serious effort, as it is being privately funded to the tune of a whopping $100,000,000. No doubt, an extremely audacious undertaking.

Sounds interesting, but what does this have to do with radio? Well, obviously there’s the issue of how you can get a usable signal back to Earth across a distance of 4-and-a-half lightyears from a craft that masses in 10s of grams. I was wondering about that exact engineering challenge when I came across this article in my feed reader today. It turns out that someone has studied how one might use the Sun as a gravitational lens for lightwave communication across interstellar distances. Claudio Maccone, an Italian physicist, has run an analysis and has determined that putting a receiver at distance of at least 550 AU from Sol will give the desired lensing effect for optical communications.

Speaking before Maccone at the Breakthrough Discuss meeting, Slava Turyshev (Caltech) pointed out that the gain for optical radiation through a FOCAL mission is 1011, a gain that oscillates but increases as you go further from the lens. This gives us the opportunity to consider multi-pixel imaging of exoplanets before we ever send missions to them.

That’s kind of amazing. Maccone calculates that the bit error rate of optical communication from at any significant distance from Sol quickly degrades to around 0.5. However, by using the Sun as a lens, the BER stays at 0 out to a distance of 9 LY. Here is a graph of the effect of standard comms and those enhanced by using the Sun as a gravitational lens, as calculated by Maccone:

fig024

What’s really crazy is this next paragraph:

But as Maccone told the crowd at Stanford, we do much better still if we set up a bridge with not one but two FOCAL missions. Put one at the gravitational lens of the Sun, the other at the lens of the other star. At this point, things get wild. The minimum transmitted power drops to less than 10-4 watts. You’re reading that right — one-tenth of a milliwatt is enough to create error-free communications between the Sun and Alpha Centauri through two FOCAL antennas. Maccone’s paper assumes two 12-meter FOCAL antennas. StarShot envisions using its somewhat smaller sail as the antenna, a goal given impetus by these numbers.

So that would have to rate as the ultimate QRP DX, eh? I’m not sure how realistic any of this is, but I’m pretty sure the physics are well-established by now. Kind of makes the Elser-Mathes Cup look like small potatoes.

 

Etherkit, Microcontrollers

200,000 Miles Per Watt

If you wouldn’t mind, I would like to draw your attention to my latest post on the Etherkit App Notes blog. In it, I detail how to create a 10 milliwatt WSPR beacon using nothing more than the Etherkit Si5351A Breakout Board, an Internet-connected PC, and a low-pass filter. A simple project, but one that gives quite a bit of fun testing the ionosphere given the cost and complexity.

Selection_104

I don’t want to take away from the post, so I will advise you to go there to read it, but the bottom line is that with about 10 mW, I was able to get a signal decoded over 2000 miles away. I remember reading the old exploits of the QRPp gang in books like QRP Power, where you had to be really dedicated, organized, and good at decoding CW in the worst conditions. Now, we have the luxury of a mode like WSPR, which lets us do milliwatt propagation experiments without breaking a sweat.

One idle thought I had about this is whether it would be feasible to put this transmitter on the 13 MHz HiFER band (check out Dave AA7EE’s excellent treatment on the matter) and whether that would be something that would be fun and useful for schoolkids to experiment with. Of course, it’s technically feasible, but I would want to be sure that 1) it’s legal and 2) there would be interest in doing it. A single PCB could be made with one Si5351A output attenuated to around 4.6 mW and low-pass filtered for transmit, while another output could be used to drive a simple fixed-frequency receiver based on the SA612. Let me know what you think about this in the comments.

Etherkit, Homebrewing, Microcontrollers, QRP, Wideband Transmission

Wideband Transmission #6

Happy New Year 2015!

2014 was a bit of a mixed bag here. It’s been a transition year for Etherkit, as I reorganize and reorient the business for a renewed push to get the CC1 and other new products to market. I believe that good things are beginning to happen there.

On a personal level, my two boys have been doing fantastic. Noah started preschool and is really enjoying it. Eli is at a bit of a difficult age (the Terrible Twos) and is between baby and little kid, but he’s got an amazing personality and is growing up so quickly. Jennifer and I celebrated five years of marriage and 11 years since our first date! Things haven’t been perfect in the extended parts of our families, but at least in our household we’ve all been pretty healthy and have been able to enjoy many blessings.

Si5351A Breakout Board Campaign

There have been a fair number of neat projects I’ve seen using the Si5351A Breakout Board that I posted on OSHPark, along with my Si5351 Arduino library, which is absolutely wonderful. However, I realize that it’s a pain to order PCBs and all of the parts separately, and that a kit or a finished board would be ideal.

I’ve decided to try something new in order to bring the Si5351A Breakout Board kit to market: we’re going to try crowdfunding the first batch of kits. I’m going to set a modest goal to trigger the funding, but all orders will be welcome over the goal amount. In fact, I intend to set a stretch goal at some higher funding level to devote a certain number of hours to improving the Si5351 Arduino library, including:

  • Add tuning from 8 kHz to 1 MHz
  • Add tuning from 150 MHz to 160 MHz
  • Fix the bug that does not allow output over 125 MHz
  • Implement access to the phase register
  • Implement sub-Hz tuning for modes like WSPR
  • Other bug fixes

I also intend on lowering the BOM cost by removing the broadband output transformers, and offering multiple variants of the kit, including the option to add SMA connectors and a TCXO. I’m composing the campaign on Indiegogo right now, and I’m shooting for a launch in about 10 days. I’m hoping to gain experience with this campaign with the goal of using it to fund CC1 kitting later in the year.

Why am I telling you this now? Because I would like to let those of you are are interested in purchasing one (or otherwise interested in supporing Etherkit) get advance notice so that you can order on the first day that the campaign goes live. This will help to give the campaign more momentum and perhaps help to spread the word further. I will be sure to make a blog post here when the campaign goes live and tweet about it as well, so keep an eye on those channels if this is something that intrigues you.

Simple WSPR Transceiver using Si5351A

I came across this simple WSPR transceiver from KC3XM driven by one of my Si5351A Breakout Boards via @wm6h and Dangerous Prototypes. The WSPR transmitter is simply a BS170 driven by one of the Si5351 outputs, which is buffered by a logic gate and keyed by a standard PNP keying switch. Control of the Si5351 and keying of the transmitter is performed by a plain vanilla Arduino Uno (the code has been posted to GitHub).

This looked so simple to build that I had to give it a try. I quickly built up the transmitter portion, tacked on a 10 meter LPF (the original version is for 30 meters), modified the code for my callsign and grid, and changed the Si5351 output frequency to the 10 meter band. The transmitter put out nearly exactly 1 watt of RF (with only about 1.2 watts of DC input total) into 50 ohms and ran quite cool. Hooked up to my Moxon, it had no problem generating spots when pointed east and started on an even minute so as to properly synchronize. Fun stuff!

Generating PSK with an Arduino

If you haven’t been following the blog of KO7M, you should be. Jeff has been doing a lot of experimentation with with NB6M and other home experimenters in Washington state, especially with stuff like the Minima and using microcontrollers in ham radio projects.

Lately, Jeff has been working on getting an Arduino to output PSK audio. He has a series of recent posts about it, but these two are probably the most important. The character timing is not quite right yet, but the basics of how to generate PSK via PWM audio signals are here. Good stuff!

Si5351 and Raspberry Pi

Another really great homebrewer blog is M0XPD’s Shack Nasties (oh you Brits and your silly names) blog. Paul has been doing a lot of work with the Si5351 as well, and his latest post about the Si5351 is details of how he interfaced it with the Raspberry Pi. Excellent information to have, as the RPi is of course much more powerful than your garden variety Arduino.

Design, Homebrewing, Microcontrollers

Si5351A Investigations Part 3

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.

GrabberRXBlockDiagram

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.

grx1 grx2

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.

DSCN0641

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.

WSPR

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!

Homebrewing, Test and Measurement

Si5351A Investigations Part 1

Sometime not too long ago, I was tipped off (sorry, I don’t remember by whom) to a potential rival to the popular Si570 called the Si5351. This PLL-based clock generator IC has a few points in its favor over the Si570: it is significantly less expensive (even with the required external crystal or clock) and it can output multiple independent clock frequencies from 8 kHz to 160 MHz at the same time (3 or 8 output ports, depending on which version you get). You could potentially generate a stable VFO and BFO signal from the same tiny IC, or perhaps build a multi-channel grabber receiver or MEPT/WSPR transmitter.

These capabilities looked too good to pass up, so I ordered a few of the Si5351A variety, which is the MSSOP-10 package with 3 output channels and a 10 ppm 25 MHz crystal to pair with it. A bit of searching on the Internet shows a bit of discussion about the IC in the ham radio communities, but I haven’t found any examples of the IC being used in a ham radio project yet. So, my plan of attack is to take an incremental approach in investigating this interesting IC.

The first part of this diabolical plan is to simply breadboard the bare minimum components and use a Bus Pirate to talk to the Si5351 so that I can get a handle on how it is programmed and its capabilities. That is what the rest of this blog post will be covering. Step two will involve using Si5351 as the VFO in a multiband grabber receiver (with plug-in BPF modules) that will be paired with a Raspberry Pi running LOPORA or WSPR. Assuming that works well, the final step will be to investigate whether the Si5351 can be tuned quickly and glitch-free on the fly and will be suitable for use in a proper transceiver.

As you can somewhat see in the photo above, I mounted the 5351 on a SSOP carrier board and glued that to a large piece of copper clad. The crystal needs to be mounted as close to the 5351 as possible, so I took the small 5×3 mm 25 MHz crystal and mounted it directly to the pads on the carrier board. For now, power can be conveniently provided by the Bus Pirate. It was a breeze to connect the Bus Pirate for I2C operation, start a serial console on my Linux Mint PC, and start issuing commands to the 5351. (As an aside, I can’t recommend the Bus Pirate highly enough for this type of experimentation. It’s well worth the modest price for the ability to quickly and simply start experimenting with new ICs).

5351 Start Up Spectrum

On start up, I measured the spectrum above. As you can see from the marker measurement, the fundamental is at an amazing +18.5 dBm. The output impedance of 85 ohms, so properly matched, the output power could be even higher. The good news is that there are four output level options in a 5351 register, so it can be turned down. Also, I intend to use a pi attenuator pad in order to provide a better match to 50 ohms anyway, so the high power may be a good thing. Also, you will notice the large harmonic content of the output. I don’t currently have a working oscilloscope, but I’m sure that the waveform looks quite squarish.

Having confirmed that the IC at least works on power-up, I then proceeded to issue I2C commands to the 5351 that should disable and enable the output that I was measuring. Sure enough, that worked exactly as expected. Then, by using a Windows program called ClockBuilder supplied by Silicon Labs, I generated the full register set that needed to be written in order to change frequencies and manually changed the registers via the Bus Pirate, and sure enough the output changed frequencies. But not quite to exactly the desired frequency.

After puzzling on this problem a bit, I realized that I neglected to set on of the 5351 registers which controls the load capacitance on the external crystal. I use a crystal with an 8 pF specified load capacitance, but the Si5351 defaults to 10 pF on start up. After changing this register to the proper value, the output frequency was quite a bit closer to the nominal value, but still was about 1 kHz off (at a setting of 20 MHz). At this point, I assume this is a close as I can get it, and that I will need to write a calibration routine to determine the PPM error of the output and apply that error to the calculations which determine the PLL settings for a desired output frequency. I should have more on that in my next Si5351 post.

Being able to change frequencies is wonderful, but not when you have to use a PC program to do it. So the next step of the journey was to figure out an algorithm so that the 5351 can be tuned via microcontroller.

In order to explain this, I’ll need to provide a very brief overview of the Si5351 architecture. There are two main fractional PLLs in the 5351, each of which are independently locked to the external crystal (either 25 MHz or 27 MHz). These PLLs have a VCO which runs from 600 to 900 MHz. Each output channel then has a 2nd synthesizer which is locked to the output of either of the PLLs. This is also a fractional synthesizer which divides down the 600 to 900 MHz PLL frequency to the output frequency ranging from 1 to 160 MHz. There is also a final divider which can get that output frequency down to as low as 8 kHz if desired.

The trick then is to come up with an algorithm to determine the correct (and hopefully optimum) division ratios for each synthesizer in the 5351. PLLs are not my strong suit (the last one I built from hand was a LM 566 circuit in college), so I didn’t make much progress on my own. The Si5351 algorithm does not have the required data, but fortunately there is an application note that does have the basic algorithm. Still, that didn’t really explain a strategy for optimization of the synthesizer settings.

Fortunately, Tomas OK4BX gave me a huge bit of help in the Etherkit IRC channel. It turns out that there is an Si5351 driver in the Linux kernel, oddly enough. Not being a kernel hacker, the code conventions were a bit odd to me, but I was able to suss out enough to strip some basic tuning code out and now have a working C program (currently running on the Linux desktop) which can generate the a set of synthesizer frequencies and the register settings needed to tune to that frequency. I’m not ready to post it publicly yet, but rest assured that I will put it up on GitHub when it’s more complete and cleaned up.

That’s where things stand as of today. The next task will be to complete the C tuning program, then transfer that to an AVR microcontroller so that it can do the hard work of setting all of the registers on the Si5351. After that, I need to devise a calibration routine so that hopefully I can bring the frequency accuracy of the Si5351 to much closer than it is now (currently at 60 ppm, hopefully to within 1 Hz at 50 MHz or so). If that can be accomplished, then I should be good to go with integrating the Si5351 into a grabber receiver. Stay tuned for further updates.

Etherkit, OpenBeacon

A Few Questions

Hello Dear Readers,

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
  • Multiband
  • 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!

Design, Etherkit, OpenBeacon, Operating

OpenBeacon Update

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
Operating, QRP

1 Watt to VK-land

VK6DI spot of NT7S
VK6DI spot of NT7S

Today is our housewarming party, so that means chores, chores, and more chores for me. I figured I could still have a little ham radio fun by firing up WSPR and letting it run while I took care of stuff around the house. I didn’t really expect it, but my little 1 watt signal to the random wire is managing to haul itself to nearly the other side of the globe this morning. Both VK6DI and VK2AWD have been receiving my signal fairly reliably. I was hoping that I could hear a VK station here in Beaverton, but it doesn’t appear that either of those two are set up to transmit. Regardless, it’s still really gratifying to see your modest signal make such a spectacular trip.

NT7S Spotted
NT7S Spotted

Here’s a screen grab of the latest spots of me uploaded to the spotting page. I’m hoping to run my WSPR beacon a bit more over the next few months at various times of the day to try to get a better picture of what propagation is like at my QTH. I’ve been so constrained in my HF operations in the past, I’ve never really been able to count on working any DX and I have no grasp of what the propagation characteristics are like (other than the generic characteristics of each band). Neat stuff for sure, and I would like to try other bands. However, I think I’m going to stay off 40 meters until the agreed-upon frequency is changed. Right now the WSPR watering hole on 40 meters is just about smack dab on the QRP frequency, much to the chagrin of a few QRPers. I can’t say that I blame them, I don’t think that was the wisest choice. A lost of WSPR participants run 5 watts, so it’s not like these are microwatt beacons we are talking about. In the mean time, I’ll continue to have fun on the other bands.

Operating, QRP

Shhh…WSPR…

WSPR-EEE Python GUI
WSPR-EEE Python GUI

Like I don’t have enough ham radio interests to keep me busy, but sometimes I have the attention span of a hummingbird and want to try new things that catch my eye. Such was the case when I saw VK2TPM’s blog post about getting WSPR up and running on his Ubuntu Intrepid box (thanks for the tip of the hat on the other post, Peter!). I’ve heard quite a bit of rumbling about this MEPT stuff on the ham blogsphere, so seeing Peter’s instructions finally pushed me over the egde to try it. After a few false starts due to unresolved dependancies (I guess you could call it the Linux version of DLL Hell), I was off and running with the WSPR Python GUI. It seemed to work FB once I got it to execute, but I was having a real hard time reading the font in the widgets that showed the stations spotted. No big deal, since I could open the ALL_MEPT.TXT logfile to read them. I also can’t seem to get the spots to automatically upload to the spotting web page, but I am able to send the ALL_MEPT.TXT file manually.

WSPR Spots - 2322UTC 26 Oct 2008
WSPR Spots - 2322UTC 26 Oct 2008

Since the audio and PTT interfaces to the IC-718 were already in place, it was simple to start transmitting my own beacon packets as well. I set my power for approximately +30 dBm (1 watt) and let the program do its thing while I did other chores around the house. I came back a while later, and lo-and-behold, people were hearing me! I never crossed the pond, but did get across the continent (as you can see to the right). Not bad for a first try, but I’m hoping to haul my signal across the ocean for some DX. I’ll keep running the beacon for the next few hours to wait for the terminator to cross over me. I’m guessing I’ll have a better chance of getting my 1 watt heard in distant lands when I have the gray line working for me. Fun stuff, and easy to do if you already are set up for working digimodes.