His work is accessible from strandbeest.com. I find his creations amazingly cool.

And others do as well, even hamsters (although cats seem less impressed):

But while I’ve found these things fascinating, I didn’t spend a lot of time researching the exact mechanism, nor thought about fabricating my own. And now I don’t need to!

Check out this awesome link to get code to design variants, visualize them, and even OpenSCAD source code go generate actual 3d printed models. That’s just too cool.

Pretty neat!

If you are interested, you can check out the Long Wave Club of America website to learn more about Part 15 operation. If any of my readers have any other up-to-date or interesting LF/MF part 15 links, I’d love to see them added to the comments.

In the recent SolderSmoke Podcast #152, Bill, N2CQR recently took a tiny step into that overlap himself. He got himself Arduino, probably the most popular microcontroller platform, and used it to send out Morse, and then control an inexpensive DDS module to serve as a cool little VFO, complete with a rotary encoder to tune and a little LCD module to give the readout. Check it out:

Pretty darned cool. And both economical and useful. Bill was pretty sheepish about this tiny step into the digital world. In the past, he has expressed a greater comfort with radio circuits that are built from discrete components, such as diode mixers constructed with trifilar coils rather than the NE602 integrated circuits. After building radios with just a handful of discrete transistors, using even the simplest microcontroller which has tens of thousands (if not more) can seem like crass extravagance.

But I think he should cut himself some slack. Actually, not just cut himself some slack, but revel in the new direction his hobby has taken him.

In the strictest sense, QRP radio is just any communication which takes place with less than 5 watts of radiated power. But in the broader, more ideological sense, it means constructing radios which are simple, inexpensive and well optimized, without a surplus of useless features of whistles. There is a certain economy of design. When you look at VK3YE’s design for his “Beach 40″ DSB rig, you have to marvel at the coolness of the design. Only 8 transistors, nicely documented in his videos. He draws the entire schematic out from memory while on the beach.

If your aesthetic finds this kind of circuit pleasing, the idea of injecting a microcontroller into the mix may seem like drawing telephone wires in the background of the Mona Lisa. But I’d submit that you can find aesthetic uses for microcontrollers in radios, even while being able to appreciate these great discrete, analog designs.

First of all, microcontrollers enable new and useful features. Even the simplest microcontroller can be used to send automated signals for things like QRSS beacons. Hans Summers super low power QRSS beacon can send a nice “shark fin” signal using only three transistors, but if you want to send your callsign, it rapidly becomes more difficult. Sure, you could strap a laptop or desktop computer to generate the modulating signal, but that seems very unaesthetic: hundreds of dollars and tens of watts of compute power just to drive a $5 transmitter with only a few milliwatts of output power? He actually sells a little preprogrammed microcontroller that will do the work, or you could get a K1EL keyer chip, but you are injecting a black box in your design, without any understanding or modifiability. But you could open that box up yourself. For the price of a pizza, you can get a dev board that will hook up to your laptop for programming, pull a few milliwatts of power, and dutifully key your transmitter. Once you get familiar with that kind of work, you can then make an embedded controller using just the raw chips: for instance, I have a few of these Atmel ATTINY85s that I got for $1.15 each (about the same as a 555 timer from our local Radio Shack) lying around for such applications. Add a crystal and two caps (or maybe even do away with the crystal, and use its internal oscillator) and your beacon becomes more flexible and more useful. Want to change the message? Have it send the current temperature or battery voltage as well? Piece of cake.

Second, microcontrollers are the easiest step into understanding computers. When I got my first computer back in 1980, it was already pretty difficult to understand the innermost workings of computers, although I did fairly master most aspects of my Atari 400. With modern desktops or laptops, it seems basically impossible. They have dozens of subsystems, with all sorts of interface and operating systems complexity. But these microcontrollers don’t have any operating systems, and because they are mostly self-contained, the total amount of stuff you have to learn is relatively limited. You tell the microcontroller to flip a voltage from low to high, and it does it, without drivers or intermediate layers. It allows the same kind visceral understanding and exploration that QRP is meant to stimulate.

Thirdly, just like the QRP community, it allows you to participate in a robust, vibrant community of experimenters. The people who are experimenting with Arduinos are kindred spirits to the homebrew radio enthusiasts. They want to take simple, cheap building blocks, and through the power of their understanding construct new, useful and novel applications. Even when their area of interests may differ from ours, you can learn from their skills and draw inspiration from their enthusiasm. And we might even find some potential hams in their ranks.

Don’t feel bad Bill: embrace your new digital skills. The more you goof around, the more applications you’ll find, and the more empowered you’ll be. Computers and QRP can co-exist, and even enhance each other.

A lot of it can be constructed with just Dollar tree foam and packing tape. But i recently got access to a 3D printer, and I thought it might be cool to fabricate some parts using that. A good candidate was the motor mount: we wanted the motor to be firmly held, with the appropriate 5 degrees of down angle. I just recently started teaching myself how to design simple parts using OpenSCAD. It bills itself as the “Programmer’s Solid 3D Cad Modeller”, and I couldn’t agree more: it plays right into my skillset. I’ve made an printed a few objects, and for these kind of purely functional 3D objects, I found it to be easy and straightforward.

The basic idea is to make a little plastic bracket that can be mounted at the end of a piece of 5/8″ square wood which is held with mounting tape inside the main fuselage. It took me about twenty minutes to design, and it went through a couple of minor tweaks before it got to it’s final form. And here it is, mounted in my student’s plane:

Mark H. thought it might be of interest to others in the builder/RC community, so I placed it up on thingiverse. Feel free to download it and print it, and let me know of you find it of value.

Motor Mount for the Axon

If all goes as well, we’ll have our first maiden flight of our resulting aircraft, and video and pictures coming soon.

I find a lot of editorializing about amateur radio to be, well, curiously off the mark. For instance try checking out Dan, KB6NU’s well meaning article about why you should upgrade to a General. I mean, that’s what the title is: Why you should upgrade to a General. The reason I find this article so astounding is that despite the title, Dan doesn’t actually provide any reasons why you should upgrade to a General. The entire article presumes that whatever reasons you think you have for not upgrading, they aren’t valid. I find that a tiny bit presumptuous. But what’s really odd to me, is that there certainly are reasons to upgrade, he just didn’t bother to tell you any.

The most important difference (which underlies most of the others) is that you have access to spectrum which is unavailable to Technician class licensees. While Technician class licensees have all you can eat privileges above 50Mhz, they are pretty lean on the HF bands. With a General, you get full access to big hunks (but not all) of the spectrum below 6m, and this opens up a bunch of possibilities for communication. From SSB to RTTY to digital modes, you can participate more fully in the broad range of HF activity. The General exam is not a particularly difficult test, and you get a big bang for the buck. I’ve enjoyed WSPR, JT65 and beacon activity. And of course building and QRP operation. And just a lot of shortwave listening too (hey, no license required!)

But perhaps you don’t want to do any of that. Perhaps EMCOMM on VHF+ is your thing. Or maybe you like mountain-topping with 2m SSB. Or microwaves. Or APRS. Or D-Star. Or satellites. Or ATV. Or meteor scatter. Or EME. Or just hiking with an HT, or keeping in touch while on the road. I’m frankly okay with that, and I wish more hams were less concerned about what other people were doing, and simply got on with doing more of what they like in ham radio. Then, we wouldn’t have to scold and cajole people into upgrading: they would either be interested, or not. With the wide variety of interesting activity accessible to hams with Technician class licenses, it does not strain my credulity to think that it might be enough for someone.

When someone asks you why you don’t have your General or Extra class license, ask them how many moonbounce contacts they’ve made. If it is zero, urge them to upgrade their skills.

Pixar gave a nod to Harryhausen by naming a restaurant (curiously a sushi restaurant) after him in our 2001 film, Monsters, Inc. I doubt that there is anyone in the animation or visual effects industry who wouldn’t name Harryhausen as inspiration for what they do. So long Ray, and thanks for the films.

The truth is, I haven’t done a lot with the Propeller board. I must admit that a lot of it is simply inertia: if something you already know fairly well serves your needs, then learning something new is often a distraction from your task at hand. But there are things about the Propeller that I do find interesting and compelling.

It’s fast. The chip can be clocked up to 80Mhz, and has 8 cogs, each a 32 bit core with 2KB of local storage for instructions and data.

It has a built in byte code interpreter for SPIN, a high level language. Each cog can execute about 80,000 of these high level byte codes per second, or about 640,000 max if all cogs are funning. I have mixed feelings about Spin, but it’s a cool idea nonetheless.

It avoids interrupts, preferring to use cogs to process events. Interrupt processing is challenging for new programmers (and in some cases, even experienced ones) and the cog model might be easier and more flexible for many real time tasks.

It avoids dedicated hardware peripherals, instead providing “virtual” peripherals as software. Because the chip is fast, and there are many cogs, it’s possible to implement many devices such as UARTS, PWM, servo drivers and even video as code which runs on a particular cog in parallel with the user program. This gives the programmer a great deal of flexibility. SPIN supports a library of user-contributed objects which can really lend to the flexibility of the Propeller.

So, there is lots to like! So, for the second year in a row, I’ve shuffled off to meet some of my friends from tymkrs.com at the Official Propeller Conference. It’s a fairly small get together of Propeller enthusiasts, hosted by Parallax and featuring short presentations on Propeller hardware and software techniques. I had a lot of fun. Parallax is a remarkably small company, run by Ken and Chip Gracey, and having maybe forty employees. Besides the Propeller, they manufacture a bunch of other items, including sensors and robotics items. The highlight of the day was a talk by Chip about the upcoming Propeller 2. Chip’s talk was remarkably informative, and so devoid of normal marketing bull that I actually blinked several times at his honesty.

Propeller 2 looks very cool. To me, the most exciting thing is that it one ups the flexibility of the Prop 1 in allowing any pin to be configured as digital or analog, and an input or output. The Prop 1 has been used by hams to directly generate beacon signals but the new capabilities would seem to open a variety of demodulation as well as modulation techniques. Chip said that the first actual silicon for the Prop 2 will be arriving at Parallax this Monday, and that he’ll let us know via the Parallax forums how that goes. I’ll be paying attention.

I had a great time, culminating with a BBQ dinner with Atdiy, Whisker, Roy, Joe, and some of the Parallax crew. It’s inspired me to actually dig in and start learning Spin. I’m staring over at my Parallax board, happily blinking LEDS. It’s a start.

More details on the Propeller as I goof around.

Over on the Open Emitter blog (sorry, don’t know whose blog this is) there is a twist on this basic idea: instead of using a separate oscillator, use the oscillator that drives the microcontroller as the emitter (probably of just a few microwatts into a short wire antenna). To on-off key the oscillator, the Atmel chip is put into power-down mode, and woken up via the watch dog timer. I think it’s a cool idea, and worthy of experimentation. I’ve got some ATTINY85 chips on sale (just $1.10 each) which will probably be breadboarded into a test circuit, using either some of my 10.140Mhz crystals or maybe some of the 80m or 20m crystals that I have lying around.

Check out the article:

Tiny Beacon

His post that apparently uses my code to send Morse which is tracked by the Reverse Beacon Network

Awesome. It’a actually pretty gratifying to see how often this simple (at least for me) code has been used and reused by people. I think of this code as being almost too trivial to worry about, but it’s clear that there are lots of people who are using the Arduino to try to get into some very simple code and electronics projects. I think that’s awesome! There are a number of authors/technocrats/philosophers who are saying that those who don’t learn to write programs are simply going to be left behind: appliance operators in life, and that those that do will be able to achieve. I don’t know that it’s true, but I do think some passing knowledge of programming can be leveraged into cool projects, and I’m glad to see that Bill has taken his first steps into the world of Arduino, and glad that I could be a part of it.

Addendum:

You can get my code from this blog post.

I made a couple of different videos using variations of this code. I was inspired to make this video after seeing Steve Weber’s “Temp2Morse” project, which basically keys a small oscillator powered directly from the pin of an ATTINY processor (in his case) or an Arduino in mine.

I used another variation of this code to interface a PS/2 keyboard to the Arduino, and then used it to key my FT-817:

(Apologies if you all have seen these before, but I thought they might be new to some of you.)

Apologies to my loyal readers (reader?) for the lack of recent updates. A combination of work pressure, family visits, general lassitude and other distractions have caused the writing muse to flee, and every time I sit down to write something down, I have just felt physically tired and unable to write stuff down. But the good thing is: the days are getting longer, my project at work is shipping, and I’m hoping that May will mark the beginning of some good new projects.

Some things I have in the works:

• A number of Raspberry Pi related projects. In particular, I’ve got most of the parts for a little robotic platform that will carry a Raspberry Pi and a webcam. It’s my first real complete homebrew robotics project, which is kind of cool.
• I’ve been experimenting with 3D printing, and hope to do some more.
• Weather is improving, so the urge to get my RC airplanes back in the air.
• I need to get back to some radio projects. I was up to 43 states on my WAS via JT65, it would be great to polish that off this summer.

Stay tuned!

And so, I printed it out. I use the Makerbot software, set for the Replicator 2, once using medium quality (with a print time of about sixteen minutes) and once using the high quality (print time of nearly an hour). I used 25% infill for both, I wanted to make sure the outer and inner shells were sufficiently bonded. I then printed it!

But there were a few issues.

First of all, my Arduino bumpers were a pretty tight fit.

I coded in a clearance of 0.008″ around the nominal board size, but that was simply not enough. I think I’ll expand that to 0.012″ or even 0.015″ next time around. I was able to press fit one of my OSEPP Arduino boards into it, but just barely, and only by shaving a small amount off one corner of the board with an Exacto knife. I also think I should thicken the bottom slightly: if you used this shield to bolt against a conductive surface, some of the solder joints on the bottom of the board could still short out. I am also thinking of widening the channels cut for the USB and DC jack a small amount, they fit, but just barely. An additional 0.02″ of an inch would make them more comfortable. I also noticed that one of the prints had a corner which seemed to pull up and not be level/coplanar with the rest of the print. Not sure what that was about. But overall it worked! I’ll make these changes to the design, and then try another set of prints, and then you should be able to see it on Thingiverse.

I also printed this model of the chicken from Minecraft. It comes in four parts (body, head, two feet) which you can assemble and paint. The model is quite simple, I printed it with medium quality settings and 10% infill. It worked rather well, except that the parts do not assemble easily: the head is slightly too wide to fit into the slot in the body and the feet do not fit into the holes left in the bottom. I think a little judicious belt sanding will make the head fit, and I’ll measure and redrill out the holes to make the legs fit. But in general, the issue of clearances seems to be one I need to explore more. Does anyone have any good references/hints/guides they would like to share?

module arduino_outline() {
	polygon([[0, 0],
				[0, 2100],
				[2540, 2100],
				[2600, 2040],
				[2600, 1590],
				[2700, 1490],
				[2700, 200],
				[2600, 100],
				[2600, 0]]) ;
}

px = 2505.512 ;
py = 1198.031 ;

module icsp() {
		translate([px, py-200, 31.25]) minkowski() {
			cube([100, 200, 62.5]) ;
			cylinder(r=50) ;
		}
}


eps = 0.001 ;


s = 25.4/1000. ;

cl = 8 ;
th = 62.5 ;

module os() {
	linear_extrude(height=250) 
		minkowski() {
			arduino_outline() ;
			circle(r=th+cl) ;
		}
}

module is() {
	translate([0, 0, -eps]) linear_extrude(height=250 + 2 * eps) 
		minkowski() {
			arduino_outline() ;
			circle(r=cl) ;
		}
}

module final() {
	difference() {
		os() ;
		is() ;
	}
}

module neg() {
	union() {
		intersection() {
			minkowski() {
				difference() {
					translate([-200, -200, eps]) cube([3000, 3000, 62.5]) ;
					os() ;
				}
				cylinder(r=200+th+cl*2) ;
			}
			os() ;
		}
		final() ;
	}
}

module holes() {
	union() {
		translate([550, 100]) cylinder(r=125/2., h=500, center=true) ;
		translate([600, 2000]) cylinder(r=125/2., h=500, center=true) ;
		translate([2600, 300]) cylinder(r=125/2., h=500, center=true) ;
		translate([2600, 1400]) cylinder(r=125/2., h=500, center=true) ;
	}
}

off = 31.25 ;
d = 31.25 ;
w = 31.25 ;

module relief() {
	translate([1100, 100, 62.5]) translate([-w, -w, -d]) 
		cube([1400+2*w, 2*w, 2*d]) ;
	translate([740, 2000, 62.5]) translate([-w, -w, -d]) 
		cube([1740+2*w, 2*w, 2*d]) ;
}
 
module slots() {
	union() {
		translate([-100, 125, 63+off]) cube([550, 350, 500]) ;
		translate([-250, 1275, 63+off]) cube([625, 500, 500]) ;
		translate([-cl, 125, 0]) cube([450+cl, 350, 500]) ;
	}
}



$fn = 24 ;
scale([s, s, s]) difference() { neg() ; holes() ; slots(); relief() ; icsp() ; }

Here’s a quick picture:

It might be a few days before I can get this printed. If anyone uses this to generate STL and print it, I’d love to hear about what you think.

If not, stay tuned. I’ll get there eventually.

module arduino_outline() {
	polygon([[0, 0],
				[0, 2100],
				[2540, 2100],
				[2600, 2040],
				[2600, 1590],
				[2700, 1490],
				[2700, 200],
				[2600, 100],
				[2600, 0]]) ;
}

module edge () {
	difference() {
		minkowski() {
			arduino_outline() ;
			circle(62.5) ;
		}
		minkowski() {
			arduino_outline() ;
			circle(8) ;
		}
	}
}

module bands() {
	minkowski() {
		square([2600, 200]) ;
		circle(10) ;
	}
	minkowski() {
		translate([0, 1900]) square([2600, 200]) ;
		circle(10) ;
	}
	minkowski() {
			polygon([[2600, 1590],
				  [2700, 1490],
				  [2700, 200],
				  [2600, 100],
				  [2500, 200],	
				  [2500, 1490]]) ;
		circle(10) ;
	}
}

d = 31.25 ;
w = 16 ;

module bumper() {
difference() {
	union() {
		linear_extrude(height=250) edge() ;
		linear_extrude(height=62.5) bands() ;
	}
	union() {
		translate([550, 100]) cylinder(r=125/2., h=500, center=true) ;
		translate([600, 2000]) cylinder(r=125/2., h=500, center=true) ;
		translate([2600, 300]) cylinder(r=125/2., h=500, center=true) ;
		translate([2600, 1400]) cylinder(r=125/2., h=500, center=true) ;
	}
	translate([-75, 125, 63]) cube([525, 300, 500]) ;
	translate([-250, 1275, 63]) cube([625, 500, 500]) ;
	translate([1100, 100, 62.5]) translate([-w, -w, -d]) cube([1400+2*w, 2*w, 2*d]) ;
	translate([740, 2000, 62.5]) translate([-w, -w, -d]) cube([1740+2*w, 2*w, 2*d]) ;

}
}

scale([25.4/1000., 25.4/1000., 25.4/1000.]) bumper() ;

I haven’t had the chance to print it yet, so it might not be exactly right for fit, but I’ll let you know how it works out.

Addendum: I found a model for an Arduino in OpenSCAD, and tried merging it with my bumper. That revealed that I had made a mistake in the code listed above: the DC connector should be 350 mils wide: the slot as coded would be too narrow. I also decided to widen the relief channels for the pins which stick out the bottom, and provide an extra depth relief to support the DC and USB jacks. When I get a chance to print this out, I’ll probably upload the kit-n-kaboodle to thingiverse once I’m happy with it.

Until then, here’s the tease:

Addendum²: I experimented a bit with export options. I projected the bumper down to 2D, exported it as DXF, and then imported it into Inkscape, where I could convert it to a 300dpi bitmap. Voila.

It’s a cute little package, much smaller than I expected, about 8x10mm. It has three pins, but didn’t come with a datasheet. Some queries among my buddies on the #tymkrs channel on afternet turned up this datasheet which appears to be the part. That was good enough to sort out the pinouts: the pin labeled + is the supply voltage, the pin on the opposite side is ground, and the middle pin is the sense pin. When the sensor detects motion, that pin goes high, and remains so for two seconds after the motion halts. And that’s about it.

It was tremendously simple to wire it up to an Arduino for testing. I wired the sense pin to pin 8, and then used this simple sketch…

const int pin = 8 ;
const int ledPin = 13 ;

void
setup()
{
  Serial.begin(9600) ;
  pinMode(pin, INPUT) ;
  pinMode(ledPin, OUTPUT) ;
}

void
loop()
{
  Serial.println("NO MOTION DETECTED") ;
  digitalWrite(ledPin, LOW) ;
  while (digitalRead(pin) == LOW)
    delay(100) ;
  digitalWrite(ledPin, HIGH) ;
  Serial.println("MOTION DETECTED") ;
  while (digitalRead(pin) == HIGH)
    delay(100) ;
}

It will turn on the LED wired to pin 13 when motion is detected, and also prints a message to the serial port. Simple.

I haven’t done any testing with this, but it appears they might be sensitive enough to detect the motion of my cat, which seems like it could be interesting. Stay tuned.

The driver for the webcam already existed. The USB driver lists the maximum power from this webcam at 200ma, which seemed modest enough, so I configured my Raspberry Pi with the WiPi and webcam plugged in directly, without any powered hub. Technically, the combination of the WiPi and the Pi might be over the reasonable limit, but I have seen others do a similar setup, so I decided to step boldly. This is nice, because it means that you just have one plug, and the resulting package is quite compact and mobile.

Experimentation using ffmpeg to read from the v4l2 device showed that the camera needed to capture a few frames before the automatic exposure would yield a decent image, so I grumbled a bit and experimented. After 10 minutes of inconsistent results, I recalled hearing about a different but simple webcam server program called fswebcam. It’s a simple little program, and was in the package repository, so a simple “sudo apt-get install fswebcam” and I had the software installed. It’s got a pretty good man page too. Fswebcam doesn’t stream video, but it can do one-shot and periodic captures, and has a lot of the essential features that I wanted, including capturing and skipping a bunch of frames, and capturing and averaging a bunch of frames for output.

This morning, I left my camera aimed at the bed in our guest room, which is where my cat Scrappy likes to take his naps. I hoped that later in the day, I’d be able to get a picture of him. The room has some direct sun during the day, which makes for some harsh lighting, which makes the picture pretty unimpressive.

Nope, he wasn’t napping there. Or was he? I loaded the image into gimp, and stretched the contrast with the Levels adjustment:

Ahah! Hiding next to the wall! (That’s a cloud painted on the wall above and to the right of him).

Pretty neat.

Oh, incidently, I didn’t have an http server installed on the Pi, but then remembered that it does have python. If you run “python -m SimpleHTTPServer” it will create a webserver that can serve files out of the current directory on port 8000.

Later, I may try to use ffserver or motion to do something fancier, but I’m happy with this setup so far.