Storm-proofing a cheap gazebo

The cheap 6 x 3m gazebo I use as a carport was destroyed recently during heavy rain in a storm. Unfortunately these kind of bargain gazebos explicitly state their unsuitability for heavy rain right on the box, so it’s not covered by warranty.

Like a chump I decided to get another one, and – you guessed it – it was also destroyed in the next storm. Fortunately I had enough bits left over from the previous one to repair it, but I figured this time I should beef it up a bit and make it storm-proof.

The problem – rain collecting in the cover

In heavy rain, water pools in the corners of the tarp, which eventually builds up enough and causes the whole structure to catastrophically collapse. The pooling occurs because the slope from the apex of the gazebo to the edges is unsupported, causing it to curve downwards and shed rain poorly.

The solution – add supports to the edges

The simplest solution (other than just punching holes in the tarp where the water pools) is to add some bracing that runs from the apex to the edges – this holds the tarp up and makes it much better at shedding water.

What you’ll need to buy from Bunnings

4 x 2400 x 16mm tomato stakes
2 x 20mm PVC pipe elbow pieces
8+ 3.6mm cable ties
4 x Eye screws – I have no idea which specific size I used

Build

Drill, and then screw the eye-screws into the top of the corner verticals.

These make up the lower anchor for the tomato-stake struts.

Drill a hole though the blunt end of the tomato stakes so you can pass a cable tie through them.

This will be used to anchor the strut to the eye screw.

Cut the tomato stakes to length. I found 2290mm to be suitable, but I would recommend attaching the stakes to the gazebo yourself and cutting to size.

Drill holes through either side of the PVC elbow pieces so you can pass a cable tie through both it and the tomato stakes once they have been pushed into it.

I made the mistake of putting the holes very close to the join, which means the corresponding hole on the stake must be very close to the end. Don’t do this, put them half way down the stem.

I used a drill press to get these lined up nicely, but it’s not essential.

Insert the tomato stakes into the PVC elbow, drill the corresponding holes, then zip it together with a cable tie. Make sure the holes at either end of the tomato stakes are in line with each other.

Getting the cable tie through with those holes so close together was very difficult.

Drill a hole in the plastic spreader that holds up the tarp (the pommel), then insert another cable tie to secure the PVC elbow to one of the apexes of the gazebo.

If you cut the stakes to the right length, you’ll get a snug fit under the pommel.

Finally, cable tie the other ends of the tomato stakes to their corresponding corner eye-screws, and you’re done.

This photo is a bit busy, but you can see the corner connections if you look hard enough.

One caveat to doing this: you can’t pack the gazebo up without first removing the added supports. However, if like me you’re using it as a basically permanent structure, this isn’t much on an issue.

I’m confident this was a minimal effort solution to the problem of heavy rain destroying my 6 x 3m gazebo, but time will tell. I’m already considering adding additional supports to the sides, connecting to the centre apex…

Generating a BOM rain radar gif

The Australian Bureau of Meteorology uses stacked transparent gifs for their rain radar images. This means you can’t just link to the latest radar image on their site – if you do, you get something that looks like this:

The BOM rain radar image for Brisbane, Australia. — What you get when you right-click -> copy image url on a rain radar image.

They’ve done this for entirely legitimate reasons. Because the final image you see on the page is a composit of stacked transparent layers, it means you can configure what layers you see without their servers having to deliver a slightly tweaked version of the large rainfall gif.

Annoyingly, this means it’s hard to post a rainfall gif in something like slack. To that end, I made a solution:

The full composited BOM rain radar image for Brisbane, Australia.

The script at that url (https://bom.caseyfulton.com) fetches all the requisite images and composites them into a single gif using the PHP GD library.

The full composited BOM rain radar image for Melbourne, Australia. — You can set the radar to whichever you want with the radarId param: https://bom.caseyfulton.com/?radarId=IDR023

Check out the code on GitHub: https://github.com/caseyfw/bom-gif

A comparison of cheap IoT ESP8266 boards from AliExpress

Recently I decided make an wifi “Internet of Things” sprinkler controller, and wanted to take the opportunity to get to know the plethora of ESP8266 devices better. Getting started can be a bit daunting, because although these things are ludicrously cheap (under $2 USD each!) the manufacturer of doesn’t produce the same kind of savvy, beginner-friendly documentation that’s seen the Arduino platform rocket to fame.

For example, in order to put code on the ESP-12E module linked to above, you’ll need a handful of extra components, a 3v USB to serial adpater, and a specific wiring setup. Also, you’ll have a hard time getting it on your breadboard, because the spacing between the contacts on the side is 2mm, not the standard 2.54mm. Contrast this to an Arduino Uno, which is basically plug-and-play.

A number of breakout boards have been made to make prototyping with ESP8266 chips easier, and we’re going to look at three of the cheapest ones you can buy on AliExpress.

ESP8266 Breakout Boards — From left: The Wemos D1 Mini, Witty Cloud Dev board, and a generic breakout.

1. The generic breakout (pictured right)

AliExpress: Generic Breakout

Coming in at only $0.15 each (in a 10 pack), and sometimes less than $2.00 with the chip soldered on, these boards are the cheapest option, but have their annoyances. The biggest being that they don’t actually fit on a breadboard. Well, it does, but it leaves no space either side to fit any other pins.

ESP8266 breakout not fitting on breadboard — See the way it fills up all the space? At least the Wemos D1 Mini leaves a single row.

I’ve seen some creative solutions to this where jumper wires are run out from underneath the adapter board, but it’s kind of a pain, and you’ll probably at least once put a pin in the wrong hole. Also, nothing on these boards gets you closer to programming the ESP – you’ll still need a 3v serial to usb adapter.

ESP8266 Generic Breakout — This batch came with the pads pre-tinned, so soldering was a breeze.

One other issue is that if you buy the ESP chips and breakouts separately, you’ll have to solder them yourself. I found it pretty straight forward, but I can understand why this would be a deal-breaker to some.

2. The Witty Cloud Dev Board (middle)

AliExpress: Witty Cloud Dev Board

Still insane at only $4 USD each these two-tier boards have everything you’ll need to get started. The top layer is basically just the breakout above, but the second layer acts as a bare-bones programmer, featuring a micro USB socket, reset and flash buttons.

ESP Witty Breakout

Actually, the top layer has a couple of extras on it – an RGB LED, which is pretty neat; an LDR, also neat I guess; and another USB micro socket, which can only be used for power. I suppose this means you can flash the device, then pry it off the lower part and use it independently.

Again, it won’t fit in a breadboard, and if you’re attaching other sensors, you’ll have to remove them to use the programmer. It is nice that you can use the one programmer for any number of breakouts though.

3. The Wemos D1 Mini

AliExpress: Wemos D1 Mini

Still only $4 USD and the top result when you search ‘ESP8266’ and sort by number of orders (a great way to filter the dodgy results out). Wemos have earned this spot by making a pretty user-friendly product, and publishing some documentation.

One feature that sets this board apart is auto-programming, which means you don’t have to mess around pressing buttons when you want to flash new code to it, you just click the Upload button – just like Arduino!

Unlike the breakouts above, it fits on a breadboard with enough space for a wire either side. Also, it comes with a selection of headers – standard breadboard pins, Arduino socket style, and a bizarre hybrid style that’s far more useful than you’d perhaps initially expect.

Wemos D1 Mini and three various headers — The three different header options you get.

4. The NodeMCU V3 Dev Board (still waiting)

AliExpress: NodeMCU V3 Dev Board

Still waiting on this one. Looks about as skinny as the Wemos, but with more pins. Doesn’t seem to have the auto reset/programming feature.

Breadboard Compatibility

You may wonder why breadboard compatibility is important – the answer is because your projects will end up looking like this:

Messy breadboard

Text entry on Arduino 1602 LCD display with only three push-buttons

Working on Stellarduino (an Arduino-powered telescope computer) has taught me many things about programming, especially the art of doing a lot with very little.

In this case, my Arduino sketch needed to know the date and time in order to figure out which stars are overhead, which can then be used to automatically select two ideal stars for alignment. The obvious solution was to use a Real Time Clock, which I did, and it’s great, but you still need to set it the first time, and adding an RTC to the build meant just another barrier to entry for users.

Stellarduino text entry

So, I wanted to provide a way for a user to enter the date using only a few push-buttons, and a 16 x 2 LCD display. After toying with the idea of adding numeric keypad, then writing it off as more of a barrier than just buying an RTC module, I decided to go with something akin to the way old arcade machines let you enter your initials if you get a high score.

Arduino UIs lend themselves to being implemented as a state machine, with each button press triggering a transition of states. This means you need some way of waiting for one of a number of buttons to be pressed, and to solve this I came up with probably the worst bit of code I’ve ever written:

int waitForButton()
{
  int button;

  while (true) {
    // Poor man's "wait for button to be pressed".
    while (digitalRead(OK_BTN) == 0 && digitalRead(UP_BTN) == 0 &&
      digitalRead(DOWN_BTN) == 0) {}

    // Poor man's "which button was pressed?".
    button = digitalRead(OK_BTN) ? OK_BTN :
      digitalRead(UP_BTN) ? UP_BTN :
      digitalRead(DOWN_BTN) ? DOWN_BTN : -1;

    // Poor man's debounce.
    delay(400);
    return button;
  }
}

It’s horrific, but it works.

The next challenge was creating the state machine that would allow a user to navigate across the LCD display, altering the number displayed at each location. Fortunately the Arduino LiquidCrystal library has pair of methods show and hide the underline cursor at the current location, and the position and current character can be stored as integers.

Because the text to be entered is a date, it needs a placeholder and some special formatting to guide the user in what to enter. To implement this, a placeholder answer is printed to the display first, and certain characters are designated to be skipped when the user is moving past them.

String lcdDatePrompt(LiquidCrystal lcd)
{
  char question[] = "Enter UTC Date";
  char answer[] = "YYYY-MM-DD HH:MM";
  int answerLength = 16;
  int skipPositions[] = {4, 7, 10, 13};
  int skipsCount = 4;
  char characters[] = {'0', '1', '2', '3', '4', '5', '6', '7', '8', '9'};
  int charactersCount = 10;
  int cursorPosition = 0;
  int currentCharacter = 0;
  int button;

  // Print the question to the display.
  lcd.clear();
  lcd.print(question);
  lcd.setCursor(0, 1);

  // Print the answer to the display as placeholder text.
  lcd.print(answer);
  lcd.setCursor(0, 1);

  // Enable the cursor.
  lcd.cursor();

  while (true) {
    // Write current character to screen, then reset cursor on top of it.
    lcd.print(characters[currentCharacter]);
    lcd.setCursor(cursorPosition, 1);

    button = waitForButton();

    if (button == OK_BTN) {
      // Store selected character in answer output string.
      answer[cursorPosition] = characters[currentCharacter];

      // Move cursor along, skipping cells if necessary.
      cursorPosition++;
      while (inArray(cursorPosition, skipPositions, skipsCount)) {
        cursorPosition++;
      }
      lcd.setCursor(cursorPosition, 1);

      // Reset currentCharacter.
      // TODO: Remember char when returning to a position that's already set.
      currentCharacter = 0;

      // If at end of answer, break out of loop.
      if (cursorPosition >= answerLength) {
        break;
      }
    } else if (button == UP_BTN) {
      currentCharacter--;

    } else if (button == DOWN_BTN) {
      currentCharacter++;
    }

    // Prevent currentCharacter from wrapping the characters array.
    if (currentCharacter < 0) {
      currentCharacter = currentCharacter + charactersCount;
    } else if (currentCharacter >= charactersCount) {
      currentCharacter = currentCharacter % charactersCount;
    }
  }

  lcd.noCursor();

  return answer;
}

The currentCharacter int is always wrapped to a value between 0 and charactersCount, this means selecting the next character after ‘9’ returns a ‘0’. The function inArray is just a loop through the array that returns true if the requested element is found. Very similar to the PHP equivalent.

If you’re interested, the full code to Stellarduino can be seen on GitHub. It’s very much a work-in-progress, but hopefully commented enough to be quite readable.

FPV on the Cheap

Flying RC planes and multi-rotors is fun, but strapping a camera on your plane, some video goggles on your head, and flying as if you’re on the plane fucking amazing. That’s first person view or FPV, and the best part is that if you’ve already got a plane or multi-rotor, you get everything you need for around $80 USD.

Things you need to know

Like when you first get into RC flying, there’s a lot of stuff you need to know in order to make informed decisions when buying FPV gear. Some of the terminology can be pretty indecipherable too. I’ll try to explain as much as I can, or link to others who do.

Some planes are better than others for FPV. Slow “pusher” (prop on the back) designs are better for beginners.
Video and RC frequencies (if not sure, just use 2.4GHz for RC, and 5.8GHz for video).
Antenna choices – RHCP vs LHCP, SMA vs RP-SMA.
More transmitter power does not necessarily mean more range.
Expensive goggles are a trap if you are interested in VR – once the Oculus ships, it will make a great headset!
Voltage matching camera/transmitter and power supply.

Components of an FPV system

An FPV system has two main components: the transmitter, which captures and transmits video, and is attached to your plane; and the ground station, which receives the video signal and displays it on a screen or set of goggles.

The transmitter consists of:

A camera, usually a 1/3″ or 1/4″ CMOS re-purposed security camera.
A wide-angle lens, anywhere between 110 and 150 degree field of view is good. Too small (the standard lenses are 90 degrees) and it’s like driving while looking through a pair of binoculars.
A transmitter module, which typically has a band/channel selector so you can choose the frequency it transmits at – this is useful if you’re flying with friends and don’t want to interfere with their signal.
An antenna, ideally an omni-directional circularly polarised clover-leaf antenna (three lobes).
Power supply, which can either be stand-alone, or draw from the plane’s main power in which case some filtering and/or voltage regulation is needed.

The ground station consists of:

A receiver, that’s compatible with the transmitter module (usually this comes down to transmission frequencies).
An antenna, ideally an omni-directional circularly polarised skew planar wheel antenna (four lobes).
A monitor or set of goggles, which must not show a “blue screen” when the signal gets too low like modern TVs. Usually this means you have to buy purpose-built FPV screens.
Power supply, usually somewhere in the vicinity of 12 volts, so a 3S lipo battery works well.

The baseline price

Hobbyking sells a complete FPV kit that comes with everything listed above (and some handy extras) for $95 USD. Excepting the wide-angle lens, which you’ll have to pay another $5 for.

The only cons to this system are that the transmitter portion is comparatively heavy, which is fine if you have a big plane or a powerful multi-rotor. But if you want something lightweight you can strap on a small plane, you have to DIY.

To power the transmitter portion of the kit, you can either use a separate 2S lipo battery, or wire into your plane’s main power. If you do this, I recommend using a lightweight DC step-down voltage regulator to set the voltage to 9v. This has two advantages – the transmitter and camera run cooler the lower the voltage you feed them, and “noise” created by the ESC and motor get filtered out. Plus, they’re only $0.66 USD.

A DIY lightweight FPV transmitter

If you want to go lightweight, you have to assemble the transmitter portion yourself. You could still buy the kit above to use the ground-station parts of it, and save the transmitter bits until you get a larger plane – this is what I did.

There’s lots of instructional videos on assembling the components of the transmitter, or “FPV backpack”. I started with the Kiwi guy who runs RC Model Reviews, which are a bit dated, but explain all the concepts really well. Much better is Flite Tests’ article and video, which are spot on.

There’s also this dude Arxangel who coincidentally bought the same small plane as me (the Firstar 200) and built a little FPV setup into it. His post is worth a look.

Bill of materials

Components

Camera: Tiny 1/4″ CMOS 3-5v wide-angle $14.70 from Aliexpress
Transmitter module: Boscam TX5823 200mA 5.8GHz 8 channel $9.25 from Aliexpress
Antenna: 5.8GHz LHCP RP-SMA $5.95 for a Tx/Rx pair from Aliexpress – if you only need the Tx, you might be able to find cheaper
Power supply: Mini LM2596 voltage regulator module $0.66 from Aliexpress
DIP switch: 10 pcs three pole $1.95 from Aliexpress
Fine gauge wire – just strip the cable that comes with the camera.

Total cost: $32.50 USD which includes global delivery.

Tools

Fine tip soldering iron
Solder
Glue – I recommend apoxy, though gel super-glue is ok. Hot melt glue can work, but the transmitter modules can get hot enough to re-melt the glue…
Multimeter (to set the voltage output on the regulator to 3.3v)
Third hand desktop soldering vice. If you don’t own one of these, go and buy one NOW. I didn’t for years and have regretted it ever since I got my hands on one.

Other things you might want

Velcro – to attach the module to your plane, helps with vibration and makes taking it off easier if you break it.

Build

The build is basically identical to what’s shown in the Flite Test and Arxangle articles above, with a couple of differences.

Make sure you get a transmitter module and camera that operate at 3.3v. This avoids the need for extra capacitors and voltage regulators which are a pain to solder and just add weight. They’re also less efficient too. The camera and tx module listed above are both 3.3v.
Chop the silly RP-SMA connector off the tx antenna and solder it directly onto the tx module. Don’t ever power on the tx without an antenna attached – this kills the module.

Ground station, if you don’t buy the kit

If you don’t buy the HobbyKing kit, you’ll still need a receiver module and a monitor.

HobbyKing sell the Quanum goggles seperately for $30 (not including delivery).
You can find the Boscam RC832 receiver for $21 on Aliexpress.
You’ll still need the 4-pole 2.5mm to RCA cable, and a power connectors for the goggles (the RC832 comes with one, but even then you’ll probably want to modify it).

Seriously, just buy the kit.

Bonus ground station things

When flying FPV, the best way to increase your range is to increase the height of your receiver antenna. I do this using a 2m photography light stand and a mount of my own design.

This also gets the weight of the receiver off your head, and means you can use an extension lead to give you a bit more freedom with the goggles.

Audio/sound emojis in Slack

Slack is hands-down the best team chat app there is. It’s simple, fun, incredibly easy to learn, and astonishingly powerful. However, it lacks custom audio emojis, despite the fact that they’ve been in development and “coming” for months. I can understand this. Having your chat app make annoying noises can be immensely frustrating, especially if you’re in a pod with 10 other people running Slack.

That said, sounds have a place, and has been a part of software development since the dark ages. After Mosaic was unleashed on the internet back in 1994, sound notifications let the team know when someone downloaded it:

We sat in the conference room and hooked up the big TV to one of the Indys, so that we could sit around in the dark and watch the FTP download logs scroll by. jg hacked up an impromptu script that played the sound of a cannon shot each time a download successfully completed. We sat in the dark and cheered, listening to the explosions.

When I worked at Flight Centre, one of our neighbour teams had a build server that played a sound bite of Salt-N-Pepa’s Push It when someone pushed code to integration. Our SME would hit a Bullshit button whenever she signed off a user story as completed.

So, to that end, I made a slack bot that responds to messages like ‘play pushit’ by actually playing the associated sound file. It runs on a box that sits in the corner in our office that’s hooked up to speakers. Here’s how you can set one up in your office.

Team sound emojis in Slack

On the computer you want to play the sounds, you’ll need to install python, a sound player and the tiny bot script I wrote: slack-sounds.

Assuming you’re running Ubuntu, install python-dev and python-pip:

$ sudo apt-get install python-dev python-pip

Now you can install the dependencies:

$ sudo pip install websocket
$ sudo pip install slackclient

You’ll also need an audio player – I used mpg123 because it can handle mp3 files right out of the box.

$ sudo apt-get install mpg123

Finally, you can clone the actual bot:

$ git clone git@github.com:caseyfw/slack-sounds.git

Once you’ve done all that, you can now set up the bot on slack

Create a new bot user integration in your slack team. I called ours ‘sounds’.

Copy the API token out from that page and paste it into a file called token.txt in the slack-sounds directory. The bot will use this token to authenticate with Slack.

Time to fire it up and test it out!

$ python sounds.py

Now in Slack, you can try messaging your bot. Slack-sounds will respond to messages of the format:

play <sound>

For a list of sounds, check out the sounds directory – they’re straight from Campfire.

To add sounds, just put another mp3 file in that directory.

What next?

It’d be really nice to write a method of adding sounds to the bot via Slack, like imagine if you could type:

add-sound <name> <audio url>

Feel free to fork the repo have a crack yourself 🙂

RC Tank ROV with FPV Video

A while back one of my workmates gave me an old broken RC tank, and just recently I got around to playing with it. At the same time, I wanted to test out some FPV (first person view) video gear I bought for an RC plane, so I strapped that on too.

I present, my RC Tank ROV with FPV Video:

Making it move

First, I had to gut the old electronics. It was really just a single board with some slightly interesting looking chips on it. I left the battery, motor and switch wires intact. Speaking of the motors, they are regular brushed ones, so I had to get a couple of brushed ESCs to drive them. Unfortunately, I made the mistake of buying single direction ESCs, so this tank has no reverse. Despite this, it still turns on a dime.

To control the servos, I threw an RC receiver in there I had lying around, hooked everything up and powered up my RC transmitter. This project had the added benefit of teaching me how to configure channel mixing on the 9XR Pro, I configured it so moving the throttle stick up adds power to both motors, and tilting it from side adds bias to the corresponding motor. It’s remarkably intuitive to drive.

Adding video

I recently bought an FPV kit from Hobbyking and this seemed like a good opportunity to test it out before strapping it onto a plane. I also had a tilt/pan kit I bought from DF robot, so I chucked that in there as well. The servo leads just connect straight up to the receiver. I should mention that I swapped the kit lens on the FPV camera out for a wide angle one, taking the field of view from 90 to 130 degrees. This makes it much easier get a bearing on where you are when you’re piloting the plane.

FPV transmitters should ideally be isolated from the main battery that drives the motors, because the ESCs tend to make a lot of noise. I should probably make some kind of low cut filter to smooth out the power before feeding it to the camera and video transmitter.

Video ground station

Fortunately the RS832 receiver has two video outs, so you can watch a stream on the headset while a second device does video capture. To do this I’m using a video recorder I was was given by a security guy who was doing an upgrade at my old work.

In the future I’d like to add a tower to hoist the receiver, refine the cabling, and sort out a better power supply. I’ll do a post on those once they’re done.

Bonus: Frsky telemetry

One neat-o thing the Frsky RC receiver does is telemetry. That is, it transmits information about your craft back to the transmitter in your hands. This is awesome because you can make it tell you the voltage of your battery, so you don’t accidentally ruin it by discharging it too much. It also tells you received and transmitted signal strength (RSSI/TSSI) so you can turn back before your craft gets out of range.

All of this is displayed on the screen of the transmitter with only some minor modifications to the Frsky transmitter module.

Portable cinema

So for a long time I’ve been trying to build a portable, battery-powered outdoor cinema. Why, you ask? So we can watch movies when we go hiking, in the park, anywhere!

What is a Portable Cinema?

At its most simple, a portable cinema is just these three things:

A tiny battery powered projector
A battery powered speaker
A collapsible projection screen

The projector

After a lot of looking around, I ended up settling on the AAXA P3 Pico Projector. They’re 720p resolution, 50 lumen brightness, 1:1000 contrast ratio, and can playback from USB thumbdrive or HDMI, which were my minimum desired specs. The P3 also has the benefit of 16:9 aspect ratio (no wasted pixels!), and a sick little remote control that gives you all sorts of functions, like flip-horizontal, so you can use it for rear projection.

If you have a bit more cash to throw around, consider the P4-X, which bumps up to 95 lumens, 1:2000 contrast ratio, a better focus adjustment knob, and a more standardised 12V 1.5A power supply – the P3 is 5V 3A.

Unfortunately, neither of these projectors have the battery capacity to last for an entire movie, so they need more power.

At first, I considered opening up the P3 and replacing the little 3.7V 3000mAh LiPo inside it with a much larger one, but after having a poke around inside, I decided it would be too dodgy, and probably wouldn’t play nice with the charging circuit in the P3. Anyway, when the P3 is running off internal batteries, its brightness drops down to a scant 10 lumens.

A 5V 3A external battery pack

Don’t buy this for an AAXA P3 Projector!

So I started looking for off-the-shelf battery packs, and stumbled across this BiXPower battery pack on Amazon. Its specs (5V, 3A max current draw) fit the bill, and the 13600mAh capacity is more than enough, so I bought it. Unfortunately, it didn’t work – when connected to the projector, it caused it to flicker terribly.

So my next solution was to build my own power supply.

Building your own 5V 3A power supply

I already had one of these enormous ridiculously cheap 14.8V 5000mAh LiPo batteries lying around, so all I needed was a DC regulator to drop the voltage down to 5V.

Fortunately, there’s plenty of options out there. The LM2596 voltage regulator chip is a good option, and there’s plenty of modules that use it for sale on DealExtreme, eBay, etc. I went with something similar to this one that has a built in voltmeter, which is SUPER handy because you can switch between it showing you the source (battery) voltage, and the output voltage, which you set by adjusting the big blue trimpot. Also, the components look to be relatively high quality – notice the capacitors either side of the board are 50V ones, whereas on most boards they’re 35V. This is important because the projector draws something like 12W of power, which is a fair bit for the poor little chip. You’ll need to attach a big heatsink to the back, and maybe even a tiny little one to the front of the LM2596.

Throw in some beefy wire, some high voltage connectors and a dinky little DC jack that plugs into the P3 and you’re done.

One thing to note is that during testing, I set the voltage to 5.1V, and DAMMIT, the screen of the projector flickered. I thought the regulator wasn’t able to provide enough power, but then I slowly cranked it up to about 5.6V and the flicker disappeared. Your milage may vary – be careful about delivering anything more than spec voltage to a device!

A Battery Powered Speaker

As much as I’d like something monstrous – with split speakers so you can sit them either side of the screen – you can’t really beat the Logitech Wireless Boombox for price, size, weight and performance. If you want something a little smaller, consider its little brother the Wireless Speaker Z515.

Collapsible Projection Screen

I would have thought there’d be something you could buy off the shelf to fit this description, but there just isn’t. The first time I used my projector outdoors, we set up our Coleman Event 14, which is a massive gazebo thing with huge vertical side walls that are just perfect for projecting onto. However, weighing in at 17kg, it’s not exactly portable.

One thing I did notice though, is that the Event 14 walls are EXCELLENT projection fabric – they’re ever so slightly silvered on one side (presumably for sun protection) which is perfect for projecting onto. They also work amazingly well for rear-projection, giving a clear, crisp and very bright image.

So, with that in mind, I decided to buy an extra wall from my local camping store (for like $20) and make my own screen.

DIY Projection Screen

I already had a bundle of one metre lengths of 20mm PVC pipe left over from my Fig Rig project, so I bought a bunch of T, L and straight connectors from the hardware store and assembled a 2m x 1m frame. I also used some extra lengths to get it off the ground. The best part is that because the screen will hold it together, you don’t need to glue it – which means you can disassemble it for transport.

I then cut the Event 14 wall into a 2m x 1m rectangle and sewed the sides in to make a thick ~5cm hem so that the “screen” ends up being a bit smaller than the frame. Obviously you can make it any size you want, just make sure your aspect ratio stays near 16:9.

Once the hems were sewn, I punched a MOTHERLOAD of eyelets into the perimeter of the screen, about 10cm apart. This took forever! I just used some cheapo eyelets that I picked up at Bunnings for $7, and they worked fine. The hardest part was making the initial hole for each eyelet to go through.

After that horrible experience, the screen is basically complete. The only thing to do now is to lace the screen onto its frame using some elastic cord. I used about six metres (the circumference of my screen) of some 2.5mm black stuff I found at Spotlight. The idea with lacing the screen to the frame with elastic cord is that it makes the screen stay completely taut across its entire surface. If you get any bulges or slack bits, you can just shuffle the cord around until they disappear.

The Finished Product

Everything you need for portable projection

Now that I have a portable cinema setup, I’m keen to run some “movies in the park” nights – rock up to a park somewhere, have a BBQ and then setup the screen and projector!

Remind me to upload some photos…

Stellarduino May Update

Stellarduino
An Arduino-powered telescope computer, offering two star alignment, Push-To navigation and Meade Autostar compatible serial output for displaying telescope orientation on a PC.

I’d been tinkering with the idea of building my own “telescope computer” for my Dobsonian mounted telescope since late last year (2012), and when I discovered the Brisbane Makes competition, I decided it was time for less tinkering and more making.

What is Stellarduino?

Put simply, Stellarduino is a device that when attached to a telescope, determines its orientation in the sky. It achieves (or will achieve) this using high-resolution rotary encoders attached to the telescopes axes, some moderately complex matrix transformation math, and a sprinkling of magic. Stellarduino solves an age old issue for telescopes: “What am I looking at?”

That said, it certainly isn’t the first such device. In my research I discovered many other products that solve this issue – the Wildcard Argo Navis is a perfect example. First, because it does exactly what I want Stellarduino to do, and second, because it’s over $800 AUD. Stellarduino will be fully open source, and leverage cheap, readily available components. In this way, it will be a first.

Why is this so complex?

From the description above, Stellarduino doesn’t sound like much – it just converts rotary encoder readings into coordinates, right? Unfortunately, no. Why? Well, I’ll tell you…

Much like earth’s geographic coordinates, the night sky is similarly partitioned by it’s own celestial coordinate system. It has a north and south pole that align with earth’s, and a meridian at the Vernal Equinox, in the same way Greenwich is the earth’s arbitrary meridian. Now, if you go outside and look straight up, directly above you, you’re looking at a point astronomers call your local zenith, which is sort of “north pole” of another set of coordinates – the direction you’re looking in relevant to your current viewing location.

We measure all three of these in different ways – geographic in degrees from the equator (latitude) and Greenwich (longitude); celestial in degrees from the celestial equator (declination) and hours from the vernal equinox (right ascension); and your viewing coordinates in degrees above the horizon (altitude) and from north (azimuth). In order to convert from viewing coordinates to celestial, you need to record the altitude and azimuth of the observation, the time it was made, and the geographic position on the earth of the observer, then parse these values through a complex mathematical equation.

On paper, it works perfectly, but falls over in practice because it requires the telescope to be “perfectly aligned” – that is, the base is perfectly level, and the initial horizontal orientation of the telescope is perfectly north. When you’re dealing with fractions of a degree accuracy, this is basically impossible. The solution then, is to perform an alignment procedure – take a couple of known points in the celestial coordinate system (typically bright stars), and move the telescope to those locations. Then, using some handwavy matrix magic, you can convert back and forth between the two.

If you’re interested in the math, be sure to check out Toshimi Taki’s website, and his Matrix Method for Coordinates Transformation document.

Materials

One of my big goals with Stellarduino was to use cheap components to keep the build price down. That way fellow tinkerers could build their own without breaking the bank.

High resolution rotary encoders to read the rotation of the telescope as it’s moved around. Expensive high resolution encoders are best, but lower resolution ones would work, like the kind in old ball-mice, you’d just have to gear them down. Fortunately, I already have a pair of 1000 steps-per-revolution US Digital optical encoders that I’ll be using – but CUI’s new capacitive encoders offer similar resolution for a fraction of the price ($30 each instead of $100).

16 x 2 character display to show the current orientation of the telescope, status messages, etc. I bought a cheap black-on-green one from RS for $7, but I plan on getting a snazzy red-on-black one for the final product.

Push buttons for user input – Stellarduino needs up, down and a select button for entering time, location, cycling through modes, etc.

Real time clock to avoid having to enter the time each time you power Stellarduino up.

Arduino Uno / Nano to do all the math. The Uno/Nano v3 scrapes in as barely powerful enough to do the job – the ATmega 328 chip provides only two hardware interrupt pins, which are split between the encoders, the 8-bit microcontroller barely manages single-precision floating point operations, and with the real time clock, display and buttons installed, there’s not many pins left over. That said, the Uno is probably the most ubiquitous microcontroller ever made, and using it as the backbone for this project means it’s accessible to just about anyone.

5V battery pack because any time you’ll be using this thing, you’ll be out in the middle of nowhere, beyond the harsh lights of the city.

Milestones / Where I’m starting

1. Proof of concept (complete)

Goal: A float math test on the arduino using fixed inputs for alignment, to see if it can keep up with input from the rotary encoders.

Initially I was worried that because the encoders are such high resolution, they would generate so many interrupts that it would fill up the Arduino’s interrupt buffer and “slip”, losing its place. To test this, I devised a sketch that dims an LED (via PWM) based on how much processing time is left over while it’s handling input from the encoders. The idea being that you turn the encoders, and if the LED drops to 0V, the Arduino is using 100% CPU to process interrupts and would have no time to do the computationally intensive float math.

Fortunately, when I tested it, I had to spin the encoders incredibly fast to even notice any change in LED brightness.

So, the next step was to actually have it do a set of matrix transformations based on input from the rotary encoders. The photo above is exactly that – the alignment star locations are hard coded, but the display updates live with decimal degrees as you turn the rotary encoders.

I’m now confident that the Arduino Uno is sufficiently capable to be the controller for Stellarduino.

2. Alignment using preselected stars

Goal: Useful output from alignment using preselected stars

Next up will be to add the realtime clock module to the mix (you can see it to the left of the display in the image above), and instead of using hard coded positions for alignment stars, use the actual values for preselected stars, from a preset location (my backyard). For instance, I know that Rigel and Arcturus will be visible from Brisbane all evening during June/July, so they will be suitable for the rest of the project.

At this milestone, Stellarduino will actually provide meaningful useful data, and is actually quite useful as a digital setting circle.

3. Implement Meade Autostar serial protocol

Goal: Get the output of Stellarduino to be visible as a “reticle” in Stellarium.

Another big goal of Stellarduino is to interface with the popular free planetarium software Stellarium. Meade Autostar mounts use a simple and well documented serial protocol, and when you connect this to Stellarium, come up on the screen as a reticle (aka crosshair) that shows you where the telescope is pointing. This is SUPER HANDY, and pretty much the whole reason I want Stellarduino.

4. Automatic selection of alignment stars using current location and time

Goal: Stellarduino picks the best alignment stars to use from an internal catalogue of 50 bright stars.

To achieve this, I’ll have to fill the Arduino’s EEPROM with a bright star catalogue. To determine which to use as alignment stars, it will have to calculate the altitude and azimuth of each one from the viewer’s location – that is, how far above the horizon, and in which compass direction. Once it has done this, it can discard any with altitudes below 30 degrees (too low) or above 80 degrees (too high), then pick the brightest two.

Actually getting the star catalogue onto the EEPROM is the main challenge – with 50 stars and only 1024 bytes of storage, that’s a scant 20 bytes per star.

Name: an 8 byte string, e.g. Arcturus
Magnitude: a 4 byte float, e.g. -0.04
Right ascension: a 4 byte float, e.g. 14.261 (here decimal hours, but I’ll probably end up storing it as radians)
Declination: a 4 byte float, e.g. 19.183 (decimal degrees, but again, likely to end up as radians)

5. Display mode selection

Goal: Allow the user to cycle between different display modes.

In the photo above, the display is showing current Right Ascension and Declination coordinates. It would be nice to also show calculated Altitude and Azimuth observer coordinates, and the raw integer values coming from the encoders.

That’s pretty much it. At that stage I’ll consider it done and push it all to github.

Building an Arduino telescope controller and PC interface

Recently I’ve been investigating adding digital setting circles to my Dobsonian mounted telescope.

Digital setting circles is a blanket term that refers to any electronic mechanism that provides orientation feedback for a telescope as you move it around – the most basic version is a digital spirit level, like the Moore & Wright Mini Mag. Attach one of these to the tube of your telescope, and it will tell you the altitude it’s pointing at – from zero degrees (pointing at the horizon), to 90 degrees (pointing straight up, aka the “zenith”).

That’s great and all, but what you really want is to get this information into a program like Stellarium – an open source, multi platform planetarium app that simulates the night sky. If you can connect your telescope to Stellarium, you can have it display a “reticle” – a crosshair that corresponds to where your telescope is currently pointing, which is great for helping you find things.

The plan – Stellarduino

What I want to design is a cheap (and easy to build yourself) bit of hardware that acts as an interface between a Dobsonian mounted telescope and a computer running Stellarium, or some other planetarium software. I call this Stellarduino.

Bill of materials

A set of high-resolution rotary encoders. These attach to the Dobsonian mount and convert the rotational movement into a digital signal. I’ll be using some expensive USDigital S1 and S2 encoders, purchased for ~$200 from Wildcard Solutions as part of an encoders and mount kit, though cheaper ones (like the kind you find in old optical mice) would suffice.
An Arduino, the brains of Stellarduino. Probably the larger DUE, though I’ll be using the ubiquitous $30 Uno until I run up against any limitations (floating point accuracy and no. of pins).
A 16×2 character LCD display, such as the $20 MIDAS MC21605C6W-FPTLR. This will be used to enter time and coordinates during alignment, and will display current Alt Az or RA Dec orientation once aligned.
Misc push buttons and wire.

How it will work

Using the Telescope plugin, Stellarium has been designed to consume the output from common GoTo telescope handboxes (like the Meade AutoStar) via a serial connector cable. So, in order to talk to Stellarium, Stellarduino will have to emulate one of these devices. To do this, the telescope must first be “aligned”, which means the altitude and azimuth orientation of the scope can be converted to the celestial coordinate system, Right Ascension and Declination. Alignment (from what I can tell) involves questioning the user for the telescopes’ geographic coordinates (latitude and longitude), and time (specifically UTC time). The user is then instructed to point the scope at an object of a known celestial location (typically a bright star), then at a second. By calculating the change in alt/az from the rotary encoders, it is then possible to convert between the two coordinate systems.

Project schedule

Write prototypes of the software using PHP. Build Stellarduino class library, figure out algorithms to convert RA/Dec to Alt/Az and back, figure out the alignment process and prototype it.
Port Stellarduino class library to Arduino.
Figure out best method of reading rotary encoders from Arduino.
Get LCD character display working with device so it reports telescope orientation using “dumb” alignment, that is, where the software assumes the telescope starts at zero altitude/azimuth. Dumb alignment milestone.
Port alignment process to Arduino. Stand alone alignment/push-to device milestone.
Figure out Meade AutoStar protocol, and emulate it. Final milestone.