Note – this blog-post discusses the use of the 13553 – 13567KHz band under FCC Part 15 regulations in the US. Although it is a worldwide allocation, rules vary according to where you are. Off the top of my head, I do know that there are HiFER beacons operating in some countries on the European continent, but that is the extent of my knowledge of this type of operation outside the US.
Also – this post describes a rather cumbersome method for compiling and flashing the code. Atmel Studio is a bit overkill for this application. My defense is that I was (and still am, actually) very new at this stuff! An easier way to program the ATTiny13 is to download the Arduinio I DE (if you don’t already have it). You don’t even need an Arduino board if you have an AVR programmer and a target/adapter board. You can just paste the code into the Arduino IDE, and use that to upload the program (it will compile it in the same step). You will need to download the definitions for the ATTiny 13 as described here.
Before saying anything else, I must note that even though the earlier projects which were named after my cats were not my designs, I did at least contribute enough of my own input that I could perhaps get away with naming them. I’m not sure that is the case with this venture, as I simply re-purposed it for a slightly different band and usage. However, the urge to name things around here after my cats is strong, so what I am calling The Sproutie Beacon, is really an original Hans Summers QRSS TX, modified slightly for the 15553 – 13567KHz HiFER band.
I have long been fascinated with clandestine and pirate radio stations. The UK has a long and hallowed history of pirate operation, since Radio Caroline and the other pirate ships began to grace the airwaves in the 1960’s. When I was in my teens in the 70’s, Caroline was still on the air, as was a newcomer to the pirate ship scene, a station called Laser 558. Laser 558 was, like the other pirate ships before it, stationed just outside British territorial waters, in international waters. It differed from the other pirates in one very noticeable detail though – it had American DJ’s, and was programmed like a US Top 40 station. To a British listener who was used to DJ’s talking quite a lot, the sound of American accents and near-continuous music, as dull as it might sound to a Stateside listener, was quite thrilling to these teenage British ears in the 1980’s. London is well-known for it’s many land-based pirate broadcasting stations on the FM band, but there weren’t too many outside the big cities. As a teen in the 80’s growing up in the Midlands, we did have a fairly high-powered pirate station on the AM MW broadcast band, with a wide coverage area, called Sunshine Radio, which I enjoyed listening to greatly.
When living in Los Angeles in the 1990’s, I was asked to DJ on a local FM pirate by one of the resident presenters, but politely declined, as I was already working in my chosen career, doing DJ, voice-over and production work. I was getting my DJ jollies for about 50 hours a week – and getting paid for it at that point, so said no to an opportunity that a few years earlier, I would most likely have jumped at. Los Angeles was not known for pirate activity at all – the area was almost entirely devoid of it, but this one station was a notable exception. It was known as KBLT. The founder, Sue Carpenter, even wrote a book about it, called “40 Watts From Nowhere”. Written from her perspective, and relating the trials and tribulations of running a pirate radio station that was on the air nearly 24/7 out of her apartment in the Silverlake district of Los Angeles, it’s a good read for anyone interested in the subject of pirate broadcast stations.
Then, in 2008, after moving to San Francisco, I was tuning around the shortwave bands in CW mode from my apartment in Ocean Beach one day, and heard a series of dits on approximately 4096KHz, Further investigation revealed that it was one of a cluster of unlicensed (and not legal) beacons operating from various locations in the California deserts on various frequencies centered around ~4096/4077KHz and 6626KHz with powers of the order of a few 100mW’s. All of them operated from solar power. Some also had batteries and could transmit 24/7, while others had only solar panels and were daytime only beacons. Even Jason NT7S could hear one of them from his QTH in Portland, Oregon – propagation was good on a regular basis back then. There are a number of these beacons, most of them in the deserts of the south west. Some send dits at various speeds, some send letters in Morse code. There is also one that sends the ambient temperature in Morse. They are discussed, with reception reports, over on the HF Beacons forum at HF Underground.
If, from all of this, you conclude that I would still be interested in running some kind of pirate operation, you’d be partially correct. I say partially because, in truth, although I enjoy listening to the clandestine activities of others, I wouldn’t want to do anything that might, even in theory if not in practice, jeopardize my ham license. I’d love to take a QRP solar-powered HF beacon out into the desert and leave it there, sending it’s valiant little signal, day after day, year after year, and checking the online reception reports from time to time. It would be interesting to see how long it would last. I read a report from someone who did install such a beacon, and his description was quite lyrical. He described how, whenever he was out hiking, fishing, or otherwise enjoying the great outdoors, he would take his portable shortwave radio and listen out for his beacon, thinking of the little transmitter out in the remote desert, courageously sending it’s diminutive signal across the great expanses of wilderness. Very evocative stuff.
It turns out that there is a way to operate an unmanned beacon on the HF bands below 28MHz, and to do so legally. The details, in the US, are contained within the FCC Part 15 regulations. These are the regulations which set out the requirements for unlicensed transmitters, among them baby monitors, cordless phones, toy walkie talkies, garage door openers, WiFi and Bluetooth devices, to name a few. In much of the spectrum in which operation is allowed, the power limits are very low, though there are a few bands where the allowance is more generous. The band with the most easily-attainable DX potential is the 14KHz-wide ISM band centered around 13.56MHz. Power limits are specified not in terms of the device output power, but as a maximum field strength at 30 meters. Medical diathermy machines operate in this band hence, I presume, the reason for a field strength stipulation rather than actual power into an antenna. This band is also inhabited by RFID devices. If you listen, you may well hear a variety of odd beeps and carriers, particularly near the center frequency of 13.56MHz. The maximum field strength allowed under FCC Part 15 regulations is 15,848 microvolts/meter at 30 meters. Few among us have access to accurate field strength meters, but John W1TAG has written this very informative paper, in which he runs the calculations, and comes to the conclusion that 2.3mW into a ground plane, or 4.6mW into a dipole would produce the maximum allowed field strength. Now 4.6mW isn’t a whole lot of power, but the WSPR and QRSS folk will tell you that DX results can be had, even within those limitations. In fact, the beacon activity on this band is divided between folk who run beacons sending CW at speeds that can be read by ear, and QRSS transmissions. A few people do run grabbers on this band, and report the results. Beacon activity in this ISM band is a very niche pursuit, but there is a good discussion forum over at the Longwave Message Board. As the title suggests, this site was set up for LF operators, but there is HiFER discussion there too,
My first “proof of concept” at putting together a beacon for this band was to connect an N0XAS PicoKeyer in beacon mode to my Pixie 2 transmitter. With the PiicoKeyer, if you insert the prosign BN at the end of stored message #1, it will automatically repeat. Unfortunately, my older version of the PicoKeyer will not power up again in beacon mode if power is lost. This was taken care of in later versions, but it meant that I wouldn’t be using this particular version of the PicoKeyer in the final version of the beacon. My Pixie 2 put out about 170mW on it’s original frequency of 7030KHz when powered by 12V, but this dropped to an encouraging 5-10mW at 3.6V (3 x 1.2V NiMH cells in series).
For the final version, I wanted all the electronics to be on one single board. At that point, I was thinking about purchasing a PicoKeyer chip from N0XAS and building the keyer, Manhattan-style onto the same board as a Manhattan-built transmitter. Then I remembered the Hans Summers QRSS Transmitter that I had built a few years ago. After a brief flirtation and a lot of fun with QRSS on 30M, the board sat languishing in a box. A little experimentation showed that it would still work down to voltages below 5V, and with the drive trimpot, I figured I’d be able to adjust the drive to give an appropriately low output power. Even better was the fact that on the QRP Labs website, there were details of a mod by Aldo IW2DZX for altering the output from FSK to straight on-off modulation, which I happened to want with this beacon.
Getting the QRP Labs QRSS TX on the HiFER band was straightforward. A pack of 5 x 13.56MHz crystals was purchased from an eBay seller. I chose HC49/U crystals over the more popularly available HC49/S, as I have read that the former tend to pull over a wider frequency range, due to the crystal cut. Receiving this pack of crystals in the mail was exciting. Think of the possibilities!
Here’s the final schematic for Hans’ little beacon transmitter, modified for straight on-off keying, and with values appropriate for the 13553 – 13567KHz HiFER band –
The jumpers on pins 5, 6 and 7 of the ATtiny13 are used for programming the sending speed. Refer to the original kit instructions for programming the speeds. Hans’ firmware allows 6wpm, 12wpm, and 6 QRSS speeds ranging between QRSS1 (1 second dits) and QRSS20 (20 second dits). The original schematic didn’t include the 3 x 10K pull-down resistors on these pins. I included them, as my TX wasn’t transmitting the selected modes. If these pins are left without pull-down resistors, then an unconnected pin might be incorrectly interpreted as “high” by the chip. The original circuit used a reverse-biased red LED to provide frequency-shift keying. This was removed, along with a 470K resistor and a “gimmick” capacitor, and a 2N3904 transistor, 22K resistor, and 0.1uF capacitor added to key the PA transistor. Also changed were the values of inductance and capacitance in the output low-pass filter. To cap off the mods, a 3.3V regulator was added. Because of the strict power limitations on this band, I wanted to ensure that the TX was running close to the maximum allowed power at all times, with minimal variation due to power supply fluctuations.
Although I modified my existing QRP Labs original QRSS transmitter, if you don’t have one to modify, you could build it from the schematic above, Ugly-style or Manhattan-style. A little transmitter built using MeSQUARES and MePADS would look quite nifty, methinks. The values in the schematic are the final values for the HiFER band. If you decide (with the help of the info on Hans’ site) to build it for QRSS operation as an MEPT on a ham band, you can run it from 5 – 6V for increased TX power output. I believe it can put out up to 150mW. On the HiFER band, of course, we don’t want anywhere near that much power, so a 3.3V regulator does the trick nicely.
Here is a top view of the modified board, with both new inductor and capacitor values for the HiFER band, and the IW2DZX mod for straight on-off keying completed. The speed selection jumper holes to the right of the ATtiny chip have been drilled out to accept a header block. With the original TX, you had to solder a wire between 2 holes to select a given speed. Now, the speed selection is accomplished by plugging in a jumper block (or a combination of jumper blocks). You can also see the 3.3V regulator at the far left edge of the board, in the middle. 3 old parts to the left of the trim cap have been removed, and 2 new ones added. I’ll leave you to figure out what they are 🙂 –
The underside of the board, showing the extra transistor (a 2N3904) for the straight on-off keying mod is visible in the next photo. You can also see the 3 x 10K pull-down resistors, as well as a 1pF NPO capacitor added across the trimcap to tweak the frequency coverage. The new values of capacitors required in the output low-pass filter were larger than I had on hand, so I made them up by placing smaller values in parallel. You can see 2 of those parts in the photo, placed on the underside of the board, in parallel with capacitors on the topside. I cleaned the board with flux cleaner, but ended up with a white residue. Not sure what it is. It bugs me, but I decided to let it go. (Note – I have since discovered that the residue was the result of my not washing the board thoroughly enough. If you don’t wash well enough, the flux cleaner will simply dissolve the flux goop and spread it thinly around the board.) –
A few more views of the board –
If at this point, you don’t have a functioning keyer chip, you can verify that the transmitter is working by connecting pin 3 of the DIP socket to pin 8 (the +3.3V supply), which will activate the keying transistor and turn the PA on. You can listen to the little transmitter on a nearby receiver, or look at the output on an oscilloscope (or both).
Now to decide on a callsign, or other beacon ID that you want to send. There are no ID requirements when operating under Part 15 regulations. Indeed, this band isn’t even intended for these types of communications, though this usage does fall within the rules. This leaves you, the fledgling HiFER control operator, free to transmit any ID you want. I decided that I wanted the letters “SPT” in honor of my youngest kitty, Sprout. But how to go about changing the firmware? This was no mean feat for a person like myself, who has studiously avoided all types of non-analog electronics my entire life.
This next part of the narrative will be blindingly simple for many, but is directed at people like myself, who are fairly new to the task of compiling and flashing code to a micro-controller. You have to search around a bit to find this fairly basic information in a form that we newbies can understand, so I thought I’d attempt to provide a tutorial of sorts here. For those who know what they’re doing in this area, please feel free to add comments and correct me.
The code, written in C, is posted on Hans’ personal site here. The general page on the keyer chip on his site is here. By the way, if you haven’t seen Hans G0UPL’s personal site, you’re in for a treat. It’s a treasure trove of personal projects and just screams “home-brewer/experimenter”. There are many happy evenings of reading on it!
Somewhere online, (in a Yahoo group, I think), I read a message from Yan XV4Y to the effect that he hadn’t been able to compile Hans’ code, and had made a slight modification to it to correct that, as well as making an addition, to allow spaces to be included in the sent message. Later, Hans told me that he had been using Atmel Studio 4 on an older version of Windows, and that it was possible that some folk might have had trouble compiling it with newer programs. He also said that he wasn’t sure whether the code on his site had been updated or not. I sent an e-mail to Yan, asking if there was any chance of him sharing his code with me. He responded very quickly in the affirmative, and also said it was fine for me to share it here. Please note that Hans’ code, as posted on his site, may very well compile and work fine. It’s just that I used Yan’s version. Yan was quick to point out that this is really Hans’ code with just a few minor mods from him. Many thanks to Hans for allowing me to post it here, and to Yan for allowing me to post his slightly modified version. For the slightly clueless people like me, the instructions at the beginning tell you what to do in order to insert your own custom callsign. For the record, Yan said that this code compiles perfectly on Mac OS X with Xcode using Crosspack-AVR. I’m a Windows person, so I’ll relate it the way I did it. In the following piece of beacon code, I set the callsign to be GRC. If you’re a fan of grilled cheese sandwiches and bacon, the idea of a “grilled cheese beacon” might be appealing, hence the callsign GRC. I know it’s a bit corny, but it will suffice for this example –
Please note that I have removed the code from this page, as I was having trouble getting it to display correctly. If you had pasted the code from this page, it would not have worked. Please feel free to e-mail me (I am good in QRZ) – or leave a comment underneath with your e-mail address, and I can send it to you.
Copy and paste the code directly from into a simple text editor, such as Notepad, if you’re using Windows. You can include the instructions at the beginning if you want – the compiler will know to ignore them. In the text editor, you can alter the code to include the callsign/message of your choice (no more than 8 characters, including spaces), then save it. You can name the file whatever you want, but make sure that the file extension is .c so that the compiler knows what it is.
Before compiling and flashing this code onto the ATtiny13 micro-controller, the other thing you will need to know is how to set the fuses on it. This beacon circuit uses an ATtiny13V, but I believe the ATtiny45 or ATtiny85 could also be used, as the only significant way in which they differ is that the later versions have more memory. The fuses determine basic operating parameters of the chip, and only need to be set once, though they can be reset, if you wish. After setting them you can re-flash the firmware as often as you like, and the fuse settings will remain the same, unless you purposely change them.
To find the fuse settings, you can use a fuse calculator such as this one. I used the default settings, with the exception that I disabled the internal divide-by-8 divider for the internal clock, and set the BOD (brown-out detection level) to 1.8V. The piece of code we are using assumes use of the internal 9.6MHz clock. If you don’t disable the internal divide-by-8-divider, your keyer will send the code 8 times too slow. You can read elsewhere as to why the BOD level is set at 1.8V – try this page, under the heading “Brown-Out Detect (BOD). The resulting command line argument to set the fuses, as given by this calculator, is -U lfuse:w:0x7a:m -U hfuse:w:0xfd:m
The code for the beacon, as written in c, cannot be flashed to the ATtiny – the chip wouldn’t have a clue what to do with it. Before it can be flashed, the program has to be converted into a format that the micro-controller can recognize, through a process called compiling. It might be overkill to use such a big suite simply to compile a program, but Atmel Studio was the first free one I came across, and it worked, so I used it. Download the latest version of Atmel Studio (at the time of writing, it is version 7). It’s a big download – several hundred MB, if I remember correctly, so depending on the speed of your connection, it may take a while.
After opening Atmel Studio 7, select File>New>Project
A dialog box appears. On the left-hand side, under “Installed”, select “C/C+++” and then on the right-hand side, select “GCC C Executable project”. At the bottom of the window, you can name the project “grc-beacon” (or whatever you want to call it), and select where you want the generated files to be stored, unless you want to stick with the default location. Then click “OK”. Then a device selection box appears. You’ll want to pick ATtiny13, unless you’re using an ATtiny45 or ATtiny85. I haven’t tried the latter 2 devices, but believe they will work for this application. Then click “OK”.
You can insert your code where indicated, but at this point, I chose to completely delete everything that appears on this screen, and paste the code into the window. If you have already edited the code in a text editor to include your desired callsign, then no further changes will be necessary. If you are still using the code exactly as displayed on this page, you can at this point edit callsign “GRC” out and replace it with your callsign. Remember to also alter #define MSGMAX to match the number of characters in the callsign +1 (if a change is necessary). For the callsign GRC, that will be 4. If, for instance, you were using “DOGGIE” you would set it to 7. That’s it. Simple!
In the next step, we will generate the hex code that can be flashed onto the valiant little micro-controller chip in our beacon. Go to Build>Build Solution. As soon as you click “Build solution”, you should see all sorts of activity in the window at the bottom of your screen, as the compiler goes about the business of compiling the code. Hopefully, after the bottom window has finished scrolling, you should see –
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========
Then, towards the top right-hand side of your screen, in the solution explorer, after clicking on the little arrow next to the “Output Files” section, you should see the coveted hex file. Note that I called this project “grc-beacon-3” (I think the original version was called “grc-beacon” but this was my 4th attempt at getting it right) –
If you double-click on the hex file in the Output Files section, a new window will open up, and you’ll see the code in hexadecimal format. Mine looked like this. This is the code for the “grilled cheese beacon” 🙂 –
Now you have the code in hex format, and the command line argument for setting the fuses. All that remains is to flash this onto the ATtiny micro-controller. SparkFun make a Tiny AVR Programmer that includes the target board for plugging in the ATtiny chip. I already had a USBTinyISP AVR Programmer from AdaFruit, so decided to make a target board, which cost me nothing extra, as I already had the parts on hand –
The ribbon cable that connects the AVR programmer to this target board can be inserted the wrong way, as the header connectors are not polarized. I opened up my AVR programmer and traced the pins from the ATtiny45 in the programmer to ensure that they would be connected to the correct pins on the ATTiny chip plugged into the DIP socket on the target board. Like goes to like, i.e. reset pin is connected to reset pin, MISO is connected to MISO, MOSI to MOSI, SCK to SCK, +vcc to +vcc, and gnd to gnd.
Here’s what my version looked like when finished (made with Rex’s MePADS). The thin strip of solder at the top left-hand side of the board in the next shot was put there as a visual reminder of which way to plug in the ribbon cable from the USBTinyISP –
Here’s the target board plugged into the AdaFruit USBTinyISP –
P.S. – when programming the ATtiny chips, I don’t fully insert them. With high quality machined sockets, a gentle push makes good enough contact, and makes it easy to remove the chip without deforming the pins. In fact, I did the same when plugging the chip into the beacon board and it has been running fine now for a few weeks. I do this in case I decide to reprogram the chip a few times before deciding on the final callsign. Another way of treating the pins gently would be to use a zero insertion force (ZIF) socket when programming the chip. Tayda have them for a low price, or you could use this target board from John KC9ON, and his company, 3rd Planet Solar.
(Note – all my instructions here are for Windows. I know next to nothing about Macs, but if you’re a Mac person, the AdaFruit instructional linked below can help you out.)
AdaFruit have a useful instructional on how to use their AVR programmer, which applies to any USBTiny ISP. If you haven’t done this before, refer to their instructional, install WinAVR, and become familiar with it’s use. I’ll assume you know this stuff in the following paragraphs.
I burn the fuses first, in a separate operation. That way, I know they are set, and it makes subsequent programming operations simpler (with fewer things to potentially mistype at the command prompt). With the USBTinyISP plugged into your computer via a USB cable, as well as the target board, make sure the ATtiny13 (or ATtiny45 or ATtiny85) is plugged in to the 8-pin DIP socket on the target board, and you are ready to flash.
At the command prompt, navigate to the directory where your hex file is located. If it is on the desktop, for example, at the command prompt, you type
– and just to the left of the blinking cursor, you should see
– indicating that the Windows Desktop is the current directory. You’ll also see some other stuff to the left of the word “Desktop” but exactly what, will vary, depending on your particular set-up, so I won’t confuse you.
Just to check that your programmer is working, with it plugged into a USB port on your computer, type
and you should get a list of all the commands that it recognizes. It should look something like this –
Then, at the command prompt, type
avrdude -c usbtiny
Then hit return, and because you didn’t specify the target part, the programmer will tell you so, and give you a long list of all valid parts. I’m not showing it here, because the list is too long to fit on the screen without scrolling but near the bottom, you’ll see the ATtiny13, and it’s abbreviation, which is simply “t13”.
Now that avrdude has slapped your wrist for not specifying the part, let’s give it what it wants, by typing
avrdude -c usbtiny -pt13 (or -pt45 if you are using an ATtiny45, or -pt85 for an ATtiny85)
Hit return, and you should get something like this, which indicates that your USBtinyISP is accepting commands, and recognizes the ATtiny device. In other words, it is ready to flash the firmware –
Then to set the fuses, type
avrdude -c usbtiny -pt13* -U lfuse:w:0x7a:m -U hfuse:w:0xfd:m
*(or -pt45 if you are using an ATtiny45, or -pt85 for an ATtiny85)
Hit return, and if you get something like the following, it means you have successfully written the fuses. Congratulations – you don’t have to do it again!
If you want, you can set the fuses when you are flashing the hex file, but there is the potential to goof up, set the fuses incorrectly, and render the ATtiny incapable of further use. I’d rather do it in a separate operation and then not have to worry about it again.
Now to flash the beacon firmware onto the chip. At the command prompt, type –
avrdude -c usbtiny -pt13 -U flash:w:grc-beacon-3.hex
The above example assumes that your hex file is already in the directory that you have navigated to (in these examples, I have navigated to the Desktop), and that your hex file is called grc-beacon-3.hex It probably won’t be called that, so make sure to substitute the name of your hex file. After hitting return, if you get something like this, you have hit the jackpot, and it looks like you are in business –
If you have already built/modified the beacon transmitter, you can plug the ATtiny chip into it, and should hear the sweet sounds of your beacon ID being sent repeatedly on a nearby receiver (with a brief pause between ID’s). You can also connect a crystal earphone or other piezo-electric transducer to pin 2 of the chip to hear sidetone, as a check.
Tayda Electronics is now carrying a small range of enclosures, including some diecast ones, and they have great prices. I ordered a couple of sizes to see how they were, and ended up using the smaller one for this beacon. Here’s the board mounted inside it’s enclosure –
Once you have this little powerhouse in an enclosure, you’re ready to set the output power with the 2.2K drive trimpot. Ideally, you’d be able to accurately measure the field strength at 30 meters from the antenna and use that as your yardstick. This is what K6FRC did when setting up his “FRC” HiFER beacon. IIRC, he runs 1.8mW into a groundplane. I saw an online posting from him in which he said that he was running very close to the maximum permitted field strength at that power level (he has access to a field strength meter). As I don’t have an FS meter, I chose to go with the results from W1TAG’s paper and chose 4.6mW into a dipole as my goal.
If you have an oscilloscope with a bandwidth high enough to measure voltages at such frequencies, it is a useful tool for measuring the output power of your beacon. As the power is specified in terms of the field strength it generates, there is no need to locate the transmitter close to the antenna feedpoint in order to minimize losses. If the regulations specified a maximum power out of the transmitter final, then this would be a worthwhile approach. This is the case with some Part 15 allocations (such as the one for the MW AM broadcast band). However, in this band, we are free to calculate the loss of the feedline and adjust the transmitter power accordingly. This means that the transmitter can be located indoors, and away from the extremes of weather and temperature.
With my MFJ-259B, I measured the loss of my 50 feet of RG8-X at about 0.7dB, and figured that a transmitter output power of 5.4mW should result in about 4.6mW at the antenna. Using this online calculator, 5.4mW translates into a peak-to-peak voltage of ~1.47V into 50 ohms. With the 3.3V regulator in circuit, the maximum power output was only 10mW,so adjusting the drive to produce 1.47V peak-to-peak on the scope was fairly easy.
Incidentally, the backwave is very audible when you are close to the transmitter. The backwave is the carrier that is still radiated from the antenna when the keying is off. This happens because we are keying the final, so that when the key is “up”, some of the signal from the oscillator still leaks through the PA and into the antenna. I measured the backwave on this transmitter as 01.mW, and it remains at the same level regardless of where the output power is set. Granted that at lower output levels, such as 5.4mW, it is a greater fraction of the power when the key is “down”, but although I could hear the backwave in my immediate neighborhood, it gets lost in band noise pretty quickly. 0.1mW is about 34dB lower than 5.4mW, meaning that if someone is hearing the beacon at S9 +30dB, then the backwave will be a little over S8. Realistically though, anyone who is not really close to it will not be hearing the mighty 4.6mW signal at anything more than a few meager S-points at most, relegating the backwave into the noise. If it really bothers you, you could run the transmitter from a 5V regulator, set the output power higher, and then reduce it with an attenuator pad in the output circuit. That would lead to less backwave in the antenna. I didn’t bother about it.
Here’s the antenna – a Buddipole vertical element, mounted on a painter’s pole on the balcony of my house, putting the base of the L-shaped dipole at aobut 25 feet above ground level. The other element of the dipole is a length of wire. It’s a pretty good take-off to the north and east, but it is blocked by the house to the west and south –
This is what the beacon sounds like on the K2 in my shack. I purposely took steps to reduce the signal level into the receiver, so as to get an idea of what it would sound like at a distance –
Here’s Mingus the neighborhood cat, listening to the Sproutie beacon on my K2, from across the street. Apologies for the cat butt! You can hear the backwave in this video –
The “SPT” Sproutie Beacon is now sitting in my shack, pumping it’s plucky little signal into the ether 24/7, and has received 2 “DX” reports so far. The first was from Jeff KF7RPI, who heard it at his QTH in Portland, Oregon, briefly at a 239 – 339, before it faded back into the noise. He is about 530 miles from me as the crow flies, which is pretty good for such a QRPp signal. The second report was from Bill Hensel on the LWCA message board. He was hiking in Pike National Forest when he heard SPT one day at 1845utc (also briefly) on his KA1103 portable receiver. Bill was about 900 miles distant from me, so that is also exciting. These are the only 2 reports SPT has received so far, but it is encouraging. Some folk do run grabbers on this band and look for QRSS signals. I’m thinking that if SPT’s 4.6mW signal can be heard at 900 miles while at 6wpm, it could go a lot further if it were sending much slower. However, I do like being able to decode it with my own ears, so will keep it at 6wpm (or maybe 12 wpm) for the time being.
Incidentally, if you want to put a HiFER beacon on the air with the minimum of fuss, the Ultimate 3S QRSS/WSPR transmitter kit from QRP Labs will operate on any frequency in the HiFER band, thanks to it’s Si5351 frequency synthesizer. The LPF for 20M should work fine for attenuating harmonics. As this kit is capable of producing far more power than Part 15 regulations allow, it is your responsibility to limit the output power if you operate this transmitter on the HiFER band. The Ultimate 3S will do multiple modes and bands – it’s a do-it-all-in-one MEPT, really, and at a very affordable price.
If you hear the SPT beacon on 13558KHz, please send a report – either to the e-mail address listed on my QRZ account, or as a comment underneath this post. Reception reports will be very eagerly received. One gentleman in Seminole County, FL, reported that the area around the SPT frequency was a cacophony of noise in his area, and he stood no chance of hearing it. Those kinds of reports are useful too. If you put your own HiFER beacon on the air, do introduce yourself on the LWCA message board, and John can include you on the list of known active HiFER beacons.
The SPT HiFER beacon is currently off the air.