Dave Richards AA7EE

November 18, 2015

The Sproutie “SPT” Beacon – A Legal, Unlicensed HiFER Beacon

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.

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 –

original25

 

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 🙂  –

original8

The underside of the board, showing the extra transistor (a 2N3904) for the straight on-off keying mod. 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 –

original9

A few more views of the board –

original10

original15

original11

original12

original13

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 –

// This is an amendment to the beacon program written by Hans Summers
// G0UPL. It adds the facility for a space character to be embedded 
// within the transmitted callsign character string
//

// To change the callsign string you have to :-

// alter #define MSGMAX to the length of the callsign string +1

// insert the callsign you want, ensuring each character is seperated by a space
// into the text between the curly brackets after int8_t msg[MSGMAX] ending the string with a _SPC

//  e.g. for AB4CDE 

// #Define MSGMAX 7


// int8_t msg[MSGMAX] = { A B _4 C D E _SPC };

// e.g. for PA5D M M 

// #Define MSGMAX 9

// int8_t msg[MSGMAX] = { P A _5 D _SPACE M _SPACE M _SPC };




#include <avr/io.h>
#include <avr/interrupt.h>

volatile uint8_t msgIndex;
volatile uint8_t timerCounter;
volatile uint8_t counter2;
volatile uint8_t audio;
volatile uint8_t key;
volatile uint8_t bit;
volatile uint8_t pause;
volatile uint8_t character;
volatile uint8_t speed;
volatile uint16_t callsign;
volatile uint8_t keyDelay;

#define PERIOD 6

#define A		0b11111001,
#define B		0b11101000,
#define C		0b11101010,
#define D		0b11110100,
#define E		0b11111100,
#define F		0b11100010,
#define G		0b11110110,
#define H		0b11100000,
#define I		0b11111000,
#define J		0b11100111,
#define K		0b11110101,
#define L		0b11100100,
#define M		0b11111011,
#define N		0b11111010,
#define O		0b11110111,
#define P		0b11100110,
#define Q		0b11101101,
#define R		0b11110010,
#define S		0b11110000,
#define T		0b11111101,
#define	U		0b11110001,
#define	V		0b11100001,
#define	W		0b11110011,
#define	X		0b11101001,
#define	Y		0b11101011,
#define	Z		0b11101100,
#define _SPACE  0b11101111
#define _SPC	0b11101111
#define _0		0b11011111,
#define _1		0b11001111,
#define _2		0b11000111,
#define _3		0b11000011,
#define _4		0b11000001,
#define _5		0b11000000,
#define _6		0b11010000,
#define _7		0b11011000,
#define _8		0b11011100,
#define _9		0b11011110,
#define _BRK	0b11010010,
#define _KEYUP	0b10000000
#define _KEYDN	0b10100000

#define MSGMAX 4
#define SHORTSTART 0
int8_t msg[MSGMAX] = { G R C _SPC };

uint8_t speeds[8] = {1, 2, 10, 30, 60, 100, 150, 200};
uint8_t dit[8] = {150, 150, 150, 150, 150, 150, 150, 150};
//uint8_t speeds[8] = {1, 1, 1, 10, 30, 60, 100, 200};
//uint8_t dit[8] = {150, 36, 30, 150, 150, 150, 150, 150};
// DIT 		SPEED	WPM 
// 150 		1		12wpm
// 150		2		6wpm
// 150		10		QRSS1
// 150		30		QRSS3
// 150		60		QRSS6
// 150		100		QRSS10
// 150		150		QRSS15
// 150		200		QRSS20
// 36		1		50wpm
// 30		1		60wpm

int main(void)
{
	DDRB = 24;
	
	TCCR0B |= (1<<CS01) | (1<<CS00);	// Prescale by 8
	TIMSK0 |= (1<<TOIE0);
	msgIndex = 0xff;
	
	sei();
	
	while(1);
	
	return 0;
}

ISR(TIM0_OVF_vect)
{
	audio++;
	
	if (audio == 1)
	{
		if (key) PORTB |= 0x08;
	}
	else
	{
		PORTB &= ~(0x08);
		audio = 0;
	}
	
	// 1500Hz here
	timerCounter++;
	
	if (timerCounter == dit[speed])
	{
		// 10Hz here
		timerCounter = 0;
		callsign++;
		
		if (keyDelay)
			keyDelay--;
		else
		{
			counter2++;
			if (counter2 >= speeds[speed])
			{
				counter2 = 0;
				
				if ((character == _KEYDN) || (character == _KEYUP)) 
				{
					key = 0xff;
					bit = 0;
				}
				else
				{
					if (!pause)
					{
						key--;
						if ((!key) && (!bit)) pause = 2;
					}
					else
						pause--;	
				}
				
				if (key == 0xff)
				{
					if (!bit)
					{
						msgIndex++;
						if (msgIndex == MSGMAX) 
						{
							msgIndex = SHORTSTART;
							if (callsign > 6000)
							{
								msgIndex = 0;
								callsign = 0;
								speed = 0;
							}
							else
							{
								msgIndex = SHORTSTART;
								speed = (PINB & 0x07);
							}
						}
						
						bit = 7;
						// Get character from message
						character = msg[msgIndex];
						// Look for 0 signifying start of coding bits
						while (character & (1<<bit))
						{
							bit--;
						}
					}
					
					bit--;
					
					if (character == _SPC)
						key = 0;
					else if (character == _KEYDN) 
						key = 1;
					else if (character == _KEYUP)
						key = 0;
					else
					{
						key = character & (1<<bit);
						
						if (key) 
							key = 3;
						else
							key = 1;
					}
					
					if ((character == _KEYDN) || (character == _KEYUP)) keyDelay = 100;
				}
				
				if (key)
					PORTB |= (0x10);
				else
					PORTB &= ~(0x10);
			}
		}
	}
	
	TCNT0 = 156;
}

Copy and paste this code directly from here 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 succeeded.
========== 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 –

original

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 –

original1

original2

Here’s the target board plugged into the AdaFruit USBTinyISP –

original3

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.

original24

The USBTinyISP Programming Adapter from 3rd Planet Solar. Photo reproduced with kind permission of KC9ON.

(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

cd desktop

– and just to the left of the blinking cursor, you should see

Desktop>

– 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

avrdude

and you should get a list of all the commands that it recognizes. It should look something like this –

original4

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 –

original5

Then to set the fuses, type

avrdude -c usbtiny -U lfuse:w:0x7a:m -U hfuse:w:0xfd:m

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!

original6

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 –

original7

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 –

original16

That’s a small dummy load plugged into the BNC connector. Once connected, you can measure the peak to peak voltage across it with an oscilloscope, and use that to calculate the output power.

original17

original18

Although you can’t see them, I fixed 4 little vinyl bumpers to the bottom of the case.

original19

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 –

original20

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.

original22

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.

original21

4.6mW of legal, unlicensed pluckiness and grandeur, hiding out in a diecast box.

Advertisements

November 11, 2015

A Few Manhattan, and General, Construction Pointers

Filed under: Amateur Radio,Ham Radio,homebrew radio,QRP — AA7EE @ 9:27 pm
Tags:

Someone recently left a comment on one of my older blog-posts asking if I could go into a little more detail about my construction techniques. It’s a question I’ve been asked a few times and although I have never detailed them in one post, if you were to read the posts for my main construction projects, you’d probably be able to glean enough info and links to pick up what you need. However, that information is scattered around this blog, so this post is an attempt to gather all the tidbits into one place. Please note that this is not a step-by-step “how-to” instructional, but more a collection of thoughts, tips, and links. It is a rough guide to how I do it, and not intended to be definitive. There are many ways to achieve a goal, and your mission is to find the way that works best for you.

I get my PCB material from seller abcfab on eBay. He has a good selection of different thicknesses of substrate, double-sided and single-sided, and even different thicknesses of copper. 0.06″ thickness is a nice stout board, good for enclosures, and also for Manhattan construction. The lesser thicknesses would probably only work for small enclosures, but would be fine for most circuit construction, unless you’re using a larger board and specifically need something inflexible (a thicker board would probably be more stable for a regen, for example). Up until now, I have used 0.06″ board for both enclosures and circuits, but a friend recently gave me some really nice pieces of thinner board (about 0.04″, I think), which I will use for building circuits on. When buying from abcfab, my standard order is for 0.06″ thickness, 1oz/ft² weight copper, single-sided, FR-4 substrate material. FR-4 is a composite of woven fiberglass cloth with an epoxy resin binder that is flame resistant (hence the FR designation). He also has a few different colors, which are fun for enclosures. I have bought red, blue, and the usual light brownish-colored boards from him. I did try to find a supplier for small quantities of other colors, such as orange, but the only way I found to do it was to buy whole sheets from a supplier and have them cut down to size, either for my own stash, or perhaps to also distribute to other home-brewers to spread the cost out a bit.

I won’t go into detail on enclosure building here, but I talk about my methods in this post. Ken WA4MNT has an excellent tutorial here. I learned most of what I know about building PCB enclosures from Ken’s tutorial. Ken uses shears to cut his material. I found that scoring it deeply on both sides with a box cutter allows it to be flexed and snapped cleanly. Running a file over the edge gives a nice result.

Anyway, a little about building circuits, which is the main subject of this post. Here are my main tools –

At the top is a 2.25mm crochet hook, used for winding toroids. I use the hook to pull the wire through the toroid, which is a great way of keeping the turns snug against the core. Beneath it, from left to right, is a tube of superglue gel. The gel form works best – the liquid is just too runny and gets everywhere. Next is a pair of round-nose pliers with round cross-section jaws (Pro’s Kit 1PK-29). I use these for bending component leads for the rounded look –

Round component leads on the Etherkit OpenBeacon

Next to the rounded pliers is a pair of green-handled Xcelite MS543J flush cutters with ESD-safe cushion grip handles, and a couple of small jewelers screwdrivers (from a cheap set bought from Radio Shack), which I use for scraping lacquer off the board in the places where Manhattan pads will be glued, as well as pressing down on the pads when gluing them to the board. Then a pair of Pro’s Kit 1PK-036S long nose pliers. I didn’t like the spring action, so I removed the spring from the handle. Next is a red-handled pair of needle nose pliers (cheap ones from Radio Shack). On the far right is a craft knife or as some call it, a box cutter. In the UK we call them Stanley knives, after the brand – in the same way that the British also call a vacuum cleaner a Hoover, and we in the US talk about Scotch tape, while the Brits refer to the same thing as Sellotape. This craft knife is used to deeply score both sides of a piece of PCB material before breaking it cleanly off. You’ll go through blades fast with this method. I bought a pack of 100 blades as typically, I find that every time I score a board enough times on both sides so that it can be broken off, I need to replace the blade. Blades are cheap when bought in bulk, and it’s not worth putting up with substandard cuts just in order to save a few pennies.

Looking at the needle nose pliers a bit closer, you’ll see that I filed flats into the ends. This has nothing to do with Manhattan construction. I needed a specialty tool to remove the nut holding a VFO encoder pot on a Yaesu FT-817, and found out that after filing a couple of flats in the jaws of these pliers, they fit the cutouts in the pot nut perfectly, allowing me to use the pliers to unscrew the nut –

The round-nose pliers in the foreground, and the needle nose pliers in the background.

I forgot to photograph my steel rules. I have 3 of them – a 12″ one marked in mm, a 6″ one also marked in mm, and an 18″ one marked in inches. They are used for scoring the lines in boards when cutting the PCB material and, of course, for all other kinds of measuring applications.

Moving along, at the top of the next picture is a T-handled reamer. This is used for making larger holes in chassis and enclosures. I start out with a drilled smaller hole, and enlarge it with the reaming tool. The brand name is General, and it is a No. 130. Then from left to right are a couple of files – a mill bastard, and a half-round bastard. The hand drill (and set of bits at the far right) is much used for drilling holes in enclosures. Finally, in the middle is a set of small files, which are very useful for finishing off all kinds of holes and rough edges. This particular one is made by General #707476 and is called a 6-piece Swiss Needle File Set –

When gluing Manhattan pads down, I first scrape the lacquer away from the board with a small jewelers screwdriver in the area where the pad will be glued. I know you’re not supposed to use screwdrivers for scraping things, but these were from a cheap set. I also roughen up the underside of the MeSQUARE or MePAD with a sharp craft knife blade to help adhesion. I put a small drop of superglue gel in the center of the area on the board where the pad will be, and lower the pad into position with the long nose pliers.

This next part is tricky. Once you begin to push down on the pad, you only have a few seconds before it is glued fast to the board. The trouble is, that as you push down on it (with a screwdriver or whatever other implement you’re using), the pad tends to slip around on the gooey gel, and change position. If you’re fast, you will have time to re-position it as it does this. You achieve this with a combination of pushing down slowly, and quickly re-positioning it by nudging it with the screwdriver. Once you start pushing down, the clock is ticking. You’ll have time to re-position the pad if necessary, but you’ll have to be fast! The good news is that if you do succeed in gluing the pad down in the wrong place, you can remove it and try again. Just wait a couple of minutes for the glue to set, then slide a sharp craft blade under the pad and pop it off the board. Be careful when doing this so that you don’t slice a finger, or slip and damage something else on the board. Once the pad is off, you can scrape away any remaining glue and go for a second try.

Component leads can be pre-cut and pre-formed with the cutters and pliers, and then placed against the pads and board to check the fit, before soldering. A few folk have asked how to actually get the parts standing up on the pads in exactly the position desired. This is the wonder of tack-soldering. Most modern components come with the leads already pre-tinned. For the purposes of tack-soldering though, it helps to have just a bit more solder on them. Once you have tinned the lead(s), you can place the part in the position you want it using a pair of pliers (or other tool), and temporarily fasten it in place with a bit of heat from your soldering iron. Then you can either tack-solder or permanently solder the other lead into place, after which you go back to the first lead and make that solder job permanent. As well as using pliers, I often use jewelers screwdrivers to coax leads into the right positions – use whatever you have, and whatever works for you. You’ll develop your own techniques over time. It can be a slow process, often taking many years, so don’t despair – enjoy the journey!

Oh, I forgot to mention the soldering iron. A temperature-controlled soldering station is preferred over a cheaper iron without temperature control. A temperature-controlled iron can deliver more heat when needed, such as when soldering to a circuit board ground plane. It’s surprising how much heat even a small ground plane on a circuit board can “sink” away from the tip of a soldering iron. The station I use is a Hakko 936. I don’t believe they make that model any longer, but there are plenty of affordable soldering stations available, for around the $100 mark. As for tips, chisel tips are good for most purposes. I use a 1/16″ chisel tip for most things, switching to a smaller 1/32″ chisel tip for the more fiddly tasks. The flat sides of a chisel tip will allow you to transfer heat more effectively to the area being soldered than will a conical tip.

Oh, and test gear. The most important piece of test gear by far, is a multimeter. I have a 20 year-old analog multimeter from Radio Shack, which used to be my main meter. Nowadays, I mainly use it for the times when I’m peaking circuits, when being able to see a needle move on a scale makes it easier to adjust a control for a peak or a null. My main meter now is a cheap manual DMM, an Extech MN35. It was a gift from my friend Antoinette last Christmas. IIRC, they are about $25 –

Most folk seem to prefer auto-ranging DMM’s. My preference is for a manual, as I like the manual control. Whether you are using a manual or an auto-ranging DMM, you should have an idea of roughly what kind of voltage you expect to find at a particular point before poking the test prods anywhere near it. Knowing what voltage (or current, or resistance) ball-park you are in, it is no trouble, in my opinion, to switch the meter to the appropriate range. That may be just be my justification for the fact that I’m rather stuck in my ways, and just happen to prefer manual meters. It’s convenient that they are cheaper too 🙂 With a DMM like this as your sole piece of test gear, you can build an awful lot of stuff. There are cheaper DMM’s out there, but the really cheap ones have low build quality and poor accuracy, in my experience. I do also have an old Tek 465 oscilloscope which a local ham very generously gave me. Combined with a signal generator, you can do all sorts of fun things with a ‘scope, such as injecting a signal into an amp stage, and seeing what it looks like when it comes out (as well as calculating the gain of the stage). I recently used it to measure the output of a 5mW QRPp transmitter, by measuring the peak to peak voltage across a 50 ohm resistor. At such low output powers, RF probes aren’t accurate, and a ‘scope is a good way to go.

My DMM doesn’t measure capacitance, so this capacitance meter does a great job. I often check values of components before installing them into a circuit, as a double-check to ensure I didn’t misread the value printed on the part. I got this one for a little under $15 from Sparkfun. It measures capacitances from just a few pF up to many uF’s –

There are some really useful cheap pieces of test gear on eBay. I plan to ask for a little frequency counter, and maybe also an ESR meter for Christmas.

Anyway, the purpose of this post was to show you the tools I use for my home-brewing activities and hopefully, to demonstrate that you don’t need a lot of expensive ones to build a lot of cool things. However, if you have the interest and can afford it, feel free to get yourself lots of cool test gear!

Those are the basics, I think. I cannot think of any more right now. If you have any questions, feel free to ask them in the comments section and I’ll do my best to answer.

Create a free website or blog at WordPress.com.