Chris and I finally finished Mind Over Melon! For anyone who hasn’t heard us talk about this, this is a device that allows the user to explode watermelons with his/her mind!  We took it out to Bernheim Forest for Bernheim CONNECT, and let 40 people blow up 40 melons.  It was immensely popular!  Special thanks to Bernheim for fronting the cost of the melons.  40 melons is a whole lot to fit in the back of a small hatchback!

I finished up the base station hardware at the very last minute, and Chris managed to get the thing on TV: http://www.whas11.com/great-day-live/video/Connect-Festival-at-Bernheim–167188425.html

We’ve posted some instructions on the LVL1 wiki.  The instructions are rudimentary, but I’m happy to answer any questions if you want to build your own melon popping device.  In version 2, the melon will fight back!

My friend Jon has been working on Laser Taser tag, modifying perfectly ordinary toy laser guns to provide an electric shock when you get hit.  As he was working on this game for Makerfaire Detroit 2012, I noticed that these guns are really freaking cool.  10 years ago, I paid good teenage summer job money to play laser tag, and it wasn’t as good as this.  You can now buy a $30 toy that rivals the fanciest laser tag equipment of the previous decade.

This is one of the rifles you can buy for the Wowwee Light Strike game.  They’ve got a bunch of capacitive touch button on the side to change gun settings, LED lights to indicate health, team, and who you got hit by, a reload button, an IR receiver and transmitter, and a couple of ports for add-on accessories.  Jon did a lot of the ground work for what I’m summarizing in this post.  The guns (and accessories) send out 38 kHz IR.  The guns use a custom packet format, and each message is 32 bits.

After taking a look inside these guns, I realized that they have a lot of potential.  They’re a really great sensor platform for a laser tag game, with a great form factor, but the electronics inside don’t offer a lot of flexibility in game mode, and players have to use the honor system to keep score.  My end goal is to provide drop in replacement electronics, which allow for more teams, additional game modes, zigbee scorekeeping, custom guns, custom sounds, and provide a standard data output, so people (like Jon) can build accessories a little easier.

Light Strike rifle with all screws highlighted

These guns are really easy to get into.  Just regular phillips head screws, nothing special.  A bunch of them are hidden under the sticker on the side opposite the buttons.  These can be hard to find, so to the left is a picture with all the screws circled (click to embiggen).  Once you get inside, the main feature is a really well-labeled PCB that connects all the different sensors and outputs.  Of  course, the microcontroller is covered in a big blob of epoxy, but I’m going to replace the entire board, so it isn’t going to be a problem in the long run.

 Ultimately, I want the new electronics to be backwards compatible with the old electronics, so I need to decode all the messages that are sent out by the stock rifle.  Fortunately, the rifle comes with a little target practice toy.  Taking it apart reveals an IR decoder, RGB LED, and a speaker. I added a Teensy, wired the IR decoder in, and added an IR LED to output my own codes.  The IR decoder is connected to pin D7 on the Teensy (arbitrary choice), while the IR output is connected to pin C7 (this is the PWM output from the high-speed timer/counter on the Atmega32U4).  I started out using the Arduino IR Remote library from Ken Shirrif, just outputting raw timing values from the IR input.  This ended up being frustrating, and I used a logic analyzer to confirm.  Getting a graphical view of the IR output helped a lot.

As you can see from the logical analyzer output, there are a few different marks and spaces (marks are where the LED is active).  There’s a long header mark at the start of the message, followed by equal-length inter-bit marks, with either a short space (for 0) or a long space (for 1).  Timings are as follows:

  • Header Mark: 6750 us
  • Inter-bit Mark: 900 us
  • Zero Space: 900 us
  • One Space: 3700 us

At this point, I modified the IRRemote library to decode the incoming messages.  I had to add the mark and space timings above, and write functions for decoding and encoding data.  I also had to modify some #defines for the Teensy to tweak the outgoing IR into a 50% duty cycle, and adjust the timings: The guns send out ~37.8 kHz IR, but the default settings sent out ~38.2 kHz IR.  This shouldn’t matter, but a simple tweak made everything work as it should.  The most difficult part was getting the IR send function working.  Here’s my new IR Send:

In order to get the gun to accept the header, I had to send out a 0 length space after the header pulse, then begin sending data.  This took a while to nail down. I’ve put the code on GitHub here: https://github.com/LightStrikePlusPlus/LightStrikeDecode

Amazingly, after decoding some data packets, it appeared that everything was just a 32 bit output packet, and some obvious patterns emerged once I fired a few shots with different weapons and different teams.  Of the 4 bytes in the message, Byte 3 indicates the team (0x07 for Blue (default), 0x04 for Red, 0x05 for Yellow and 0x06 for Green), Byte 2 indicates a count of some sort (only used for the turret bomb mode.  It increases by one every time the bomb goes off, but any number of “count” will trip the gun, except 0.), and Bytes 0 and 1 indicate the weapon.  Below are the weapons:

  • Laser Strike: 0x0502
    • 12 hits to kill from full health

      Inside of the target, with the stock electronics, modified with wires for power and sensor input to the teensy.

  • Stealth Strike: 0x0602
    • 12 hits to kill from full health
  • Pulse Strike: 0x0703
    • 8 hits to kill from full health
  • Rail Strike: 0x0806
    • 4 hits to kill from full health
  • Sonic Strike: 0x908
    • 3 hits to kill from full health
  • Bomb: 0x0E18
    • MUST include a non-zero “count” field
    • 1 hit to kill
  • Sentry: 0x0F08
    • 3 hits to kill from full health
  • Health: 0x08–
    • MUST be used with team 0x08
    • Final byte is team byte for healing pulse (0x07 for blue, etc)
    • 3 hits to full health

Target with Teensy installed

Interestingly enough, the guns appear to be more particular about the codes they receive than the sentry or the target module.  Both of these devices will activate on codes that don’t activate the gun.  The target, in particular, treats team codes 0x0D, 0x0A, 0x0B and 0x0C as Blue, Red, Yellow, and Green, respectively.

Now I think I’ve got enough data to build a protocol for the new electronics that will be backwards compatible, but add a whole lot of functionality. If you’d like to mess around with this on your own, check out the Arduino code I’ve uploaded here: https://github.com/LightStrikePlusPlus/LightStrikeDecode.

 
 
 
 
 
 
 
 

By now, almost everyone’s managed to acquire a bajillion cheap ARM dev boards, and there are always more coming.  As these chips get cheaper, and available in more hacker-friendly packages, they’re going to overtake chips and boards like the AVR and the Arduino, it’s just a matter of time.  Unfortunately, the ARM ecosystem isn’t as simple to work with as the AVR or PIC ecosystem.  With both of these 8-bitters, you’re working in the manufacturer’s walled garden.  ARM manufacturers, on the other hand, are free to glue whatever crazy stuff they want onto the ARM core.  As a result, peripheral sets and their use vary widely, even within the same manufacturer.  Efforts like the CMSIS ameliorate this effect to some degree, but this isn’t a cake-walk.  Add on to that the difficulties in simply getting a toolchain up and running, and anyone with mere Arduino experience is lost (even more experienced 8-bit devs are going to have some tough going).

So, here’s a short guide to getting a toolchain for the STM32 series up and running quickly.  These instructions will be specific to Linux, but should translate to OSX or Windows fairly easily.

First, I downloaded the Linaro Bare-Metal ARM toolchain (http://www.linaro.org/downloads/).  It’s important to get the Bare-Metal toolchain.  Other toolchains generate binaries that aren’t capable of running sans operating system. The bare-metal toolchain is at the bottom of the page.  This package contains the compiler, linker, debugger, and other tools used to turn source code into machine code.  I used the precompiled package from Linaro because it’s a simple off-the-shelf method to get up and running quickly.  Unlike Codesourcery/Sourcery Tools, the Linaro toolchain supports the Cortex M4 with FPU right out of the box.

In the past, I have attempted to compile their own toolchain (https://github.com/esden/summon-arm-toolchain/), but this is not a simple process.

In Linux, I just extracted the tar.gz file to the folder I wanted it to live, and added that folder to my PATH.

Next comes OpenOCD.  OpenOCD is an open source debugger/flash utility for lots and lots of different chips.  I had to get the latest dev version from the git repo, (http://openocd.sourceforge.net/repos/), as the latest stable release does not include STLink code.  If a version beyond 0.5.0 is released by the time you’re reading this, download that instead.

Installation was pretty easy.  I installed the dependencies using “sudo apt-get build-dep openocd”, then ran “./bootstrap”, followed by “./configure –enable-maintainer-mode –enable-stlink”, followed by “make” and “make install”.

Once I had the toolchain and debugger up and running, I downloaded some software to compile.  This github repository (https://github.com/nabilt/STM32F4-Discovery-Firmware) includes the test firmware provided by ST, with a Makefile capable of building it using GCC. Chibios (http://chibios.org/dokuwiki/doku.php) also includes demo files for all the discovery boards.

The first time I attempted to build the STM32F4 firmware, it didn’t quite work out.  Due to the varied nature of the ecosystem, a separate linker script is needed for each chip.  Furthermore, different compilers need different sections to their linker scripts, so it might not be possible to simply yank one from somewhere else.  The linker script tells the linker where different memory sections map into real, physical memory on the chip.

Here’s the linker script I eventually got working for my STM32F4-Discovery:

Makefiles themselves are beyond the scope of this post (and beyond the scope of my brain, in a lot of ways), but taking a peek at the Makefile used in the STM32F4 Demonstration firmware from above, there are  a boatload of dependencies from outside the project.  These are all CMSIS drivers, or required startup code.  This is a big part of why ARM chips are more difficult to use than ARM or PIC chips.  Fortunately, most manufacturers release some boilerplate startup code for their chips.  As long as it’s included in the makefile, everything will work as it should.

And those are the basics of going from nothing, to compiling demonstration code.  Right now, I’m looking heavily at the ChibiOS platform to develop some projects.  This abstracts a lot of the hardware stuff, although it isn’t nearly as simple as Arduino for getting up and running.  Hopefully with the upcoming release of the Arduino Due, there will be some development in making a really easy-to-use ARM platform.

Get the code here: https://github.com/Zuph/AVRQueue

Introducing the Arduino Simple Task Scheduler.  This is part of the balloon flight computer code I wrote for White Star, with some more polish. This library allows you to create a schedule queue of functions to be executed at specified times, on specified intervals.  For example, say you’re trying to log some sensor data and update a display in the same program. With the task scheduler, you can simply write a function to gather sensor data, write a function to update the display, add them to your queue, and let the library handle the rest.

This isn’t really useful for blinking LEDs, but it’s great for complex systems. For example, the balloon computer was gathering sensor data, sending short reports, sending long reports, monitoring vertical speed, monitoring GPS Status, monitoring flight state, managing ballast, and managing a backup high-frequency radio at the same time.  Halfway through development, it was obvious that we would need to integrate a watchdog timer to keep other systems from freezing the flight computer.  If all of these tasks had been occurring simultaneously, spread throughout spaghetti code, it would have been very difficult to add watchdog resets in all the right places.  With the task queue, I simply defined another function that reset the watchdog, and put it in the queue.  Two minutes, tops!

You can find extensive documentation and examples in the Github project.  To install, just copy the “Arduino” directory contents to the “Libraries” folder of your Arduino IDE install.  Restart your IDE, and it should pop right up.  Here’s a really simple example program:

 

 This will print “Hello: X” where X is the number of milliseconds since startup, starting 5 seconds after startup, and repeating every 1 second.
The Arduino library has some limitations, so I’ve also included an AVR “library” (just a couple of source files to include in your project).  This one’s a little easier to tweak to your specific application, and doesn’t suffer some of the same drawbacks as the Arduino library.  That said, the Arduino library will be find for almost every project out there!  The limitations are listed in more detail at the Github site.
If you find any bugs, let me know! Submit a Github issue, fork, fix and submit a pull request, or contact me directly!  If you find this useful, let me know!  It isn’t a lot, but I hope it’s well documented, and easy to use/read/understand.

This post is cross-posted from the White Star Balloon Blog

Flying across the ocean is no small feat.  It takes the concerted efforts of dozens of people, working hard at lots of difficult problems, from modeling balloon volume and flight dynamics, to planning interactions with air traffic control.  The diagram above gives a little bit of an idea of the effort involved in getting across the ocean.  Any single block represents tens to many hundreds of man-hours worth of effort.

Components in Purple represent things which will actually be flying across the ocean.  This hardware and software must perform flawlessly at all times.

Components with a red heptagon represent significant software efforts.

The red square shows the components which lie on amazon EC2, spread across three instances, with a total cost of $100 a month (during flight season) to maintain.

Pink commands are sent using PubNub, a service without whose generosity our public page would not be possible.

All of these systems are in the critical path, and a failure of any single flight system will compromise science data.  Fortunately, we always have positive control of our craft, thanks to a dead-man cutdown, which operates entirely autonomously, and a 9602 modem which will respond with rough location coordinates even if all other flight systems have failed.  Our ground systems all have hot-backups, and can all be operated from anywhere on the Internet, so these systems are as redundant as they can be.

 

Lately, most of my free time has been devoted to the White Star Balloon project.  One of the parts of the project I have become involved with is the tracking page.  This was a major portion of the project a year ago, when we still had lots of buzz and momentum going.  Unfortunately, it was a huge disaster, and we had to cobble something terrible together at the very last moment. Since then, a lot has changed. We’ve become more skilled, new technologies have matured, and new hosting solutions have become cheaper.

White Star’s tracking needs are somewhat unique among the amateur balloon community. Most balloons end up using sites like aprs.fi and spacenear.us.  These sites are great, and the guys working on them are better web programmers than I’ll ever be.  Unfortunately, they don’t meet our needs.  aprs.fi is designed to used with devices carrying APRS transmitters (which we cannot use over the ocean), and spacenear.us is designed to be used with a distributed network of receivers, which doesn’t fit our model very well.  We also wanted to plan for a contingency of getting a large number of visitors very suddenly, in case we hit CNN or Reddit.

This year’s tracking page is run entirely on the client side.  All telemetry processing is done by the client, and displayed on maps, gauges and graphs. This allows us to use static hosting for everything. I used the following resources to make this happen:

  • Twitter Bootstrap – A super quick and easy CSS framework.  Looks good out of box, if a little cookie-cutter.  Don’t have the time or the design skill to go further, though.
  • OpenLayers – More fully-featured than anything from Google. Switched to this when we thought Google was going to price us out of GMaps. One downside: It’s huge!
  • HighCharts – Very pretty, easy to use charts.
  • jsgauge – The best JavaScript gauge I could find.  There aren’t a lot out there, and most suck pretty hard.  This one isn’t great, but it gets the job done.
  • JQuery
  • Amazon S3 – Used to store all static files.
  • PubNub – Push data provider with javascript client.  Super easy to use, super nice company that really helped us out.
  • Crockford’s “JavaScript: The Good Parts” – An alarmingly thin, amazingly effective JavaScript book.

Everything is up on GitHub, and ready for inspection and shed painting. More about the specifics below.

» Read more…

Introducing a useful SOPA- The Stop Online Productivity Avoidance box.

After having an extremely productive day on January 18th, I had a thought: What if every day were January 18th? Well, at the push of a button, now it can!

The button, switch, and display are wired to an Arduino.  The Arduino communicates with a python script running on the router, which controls a Squid3 proxy blacklist.  In SOPA mode, the whole of the internet is my oyster.  In NOPA mode, however, distracting websites like reddit, hacker news, and hackaday are blocked.  This isn’t very useful without a great deal of self control, however.  In weaker instances, nuclear mode must be employed.  Turn the key switch and press the button and all distracting sites are blocked for one hour.  The only recourse is to restart the router, but the router requires 15 minutes to restart, blocking the entirety of the web for the duration.  Overriding nuclear mode is not appealing.

All code is posted online at https://github.com/Zuph/SOPA-Box

A video demonstration and more pictures of construction lie below the break.

» Read more…

Eventually, hand soldering surface mount components becomes a pain, especially if you’re doing small manufacturing runs. It’s much easier to work with solder paste and a hotplate.  Joints are higher quality, and you can manufacture more boards at once.  If it was good enough to get Sparkfun started, it’s certainly good enough for us! Working with solder paste does require a stencil, though.  The stencil contains precisely sized holes which allow solder paste to be precision applied to the metal pads on your PCB.  There are many companies which will provide cheap and high quality stencils, but if you have access to a laser cutter, there’s no reason you can’t do this yourself.

There are a lot of guides out there for creating SVG stencils from Eagle, so I’ll be covering KiCad in this tutorial.  Additionally, the laser cutter I have access to at the LVL1 Hackerspace is a Full Spectrum laser which can cut directly from Inkscape, so I’ll be basing this tutorial on Inkscape.

Step 1

Generate gerbers from your completely routed KiCad PCB project.  There are a lot of good guides out there for getting to this point in KiCad.

http://reprap.org/wiki/KiCad

http://code.google.com/p/opendous/wiki/KiCADTutorialCreatingGerberFiles

and a collection of resources here: http://meatandnetworking.com/w/Kicad_Resources

Step 2

Open your PCB in a program like Gerbv.  Any gerber viewer capable of outputting to SVG is alright for this, but I like gerbv the best.  You’ll want to open the solder paste layer, which KiCad names by default to something like “pcbFileName-SoldP_Front.gtp”.

Export to SVG, put the file anywhere you like. In Linux, you have to manually add the SVG file extension.

Step 3

Open the file in Inkscape.

Ungroup the objects by right-clicking on a pad or line and selecting “Ungroup.”

Open the “Fill and Stroke” menu.

Clear the “Fill”.

Turn on “Stroke” and set it to a color that your laser cutter likes.

Our full spectrum laser will try to cut the inside and the outside of the stroke if it’s too thick.  .1mm is thin enough that our laser cutter software will only cut the outside of the stroke.

Step 4

Before proceeding, you can delete the board outline, since it’s unnecessary.

Select all the objects, and open the “Transform” menu under “Object.”  Under the “Scale” tab, MAKE SURE that “Apply to each object seperately” is CHECKED.  This maintains the centroids of all your pads.  You’ll have to play around a little bit to get this value just right. Decreasing the size of the features is necessary due to the thickness of the stencil material.  The thicker the material, the more you’ll need to reduce the size of each feature.  For overhead transparency plastic, 90% is just about right.

Now you’ve got a finished stencil SVG, suitable for lasering.  In a future post, I’ll show off how to soldering using paste and a hotplate.

This list will be kept up to date on the wiki: http://meatandnetworking.com/w/Kicad_Resources

KiCad is an Electronic Design tool, similar to EagleCAD. KiCad is free, open source software, and runs on OSX, Linux and Windows. KiCad is unrestricted. All features may be used for hobbyist or commercial works.

Here are some features of KiCad that might appeal to the hobbyist:

  • No restrictions on board size
  • No restrictions on number of layers
  • On-the-fly DRC test
  • Nested schematic sheets
  • No restrictions on commercial use
  • Completely open source
    (We should use open source software to build open source hardware!)

Getting Started

  • Kicad Project Homepage
    KiCad can be downloaded here. KiCad support on OSX is alright, but not as good as the other platforms.
  • kicad-testing-daily
    For Ubuntu users: Adam Wolf maintains a launchpad PPA for the KiCad daily build. This build is generally stable, and months ahead of the “official” release.

Basic Tutorials

  • Curious Inventor KiCad Guides
    These guides are very comprehensive, and will get you up and running in no time at all. Unfortunately, they’re a little out of date. For example, they still refer to KiCad as having no “undo” functionality, which it now does.
  • WikiBooks
    This isn’t the best tutorial in the world, but it’s got a great, thorough FAQ.
  • Dr. Johnathan Hill’s Kicad Tutorials
    Dr. Hill takes readers through an example project, which is a great way to get a good understanding of the workflow of KiCad.
  • KicadHowto.org
    This is the new tutorial on the block. It’s not very well organized, but the information contained therein is very good.
  • TransTronics Wiki
    Again, poorly organized, but there’s a lot of good info about general KiCad use here. Some parts are also a bit out of date.

KiCad Libraries

EagleCad users are familiar with having large parts libraries available instantly. With companies like Adafruit, Sparkfun and DangerousPrototypes publishing high-quality Eagle libraries, it can be tough to transition. These resources should help you overcome that hump.

  • KiCadLib.org
    A highly respectable collection of library components.
  • QuickLibGen
    When you have to make your own part, this can really speed up the process. Provide some basic info, and download your schematic symbol.
  • Footprint Builder
    A Java program for quickly creating certain types of land patterns for KiCad components.

Another PCB design gets shipped off to China for manufacture!

This is a tiny balloon computer.  Without battery or GPS, it weighs less than 40 grams.  It can transmit RTTY or CW at 25 mW on the ham 2M and 70cm bands, and will last up to 16 hours on a single AA.

This board will be Arduino compatible, and the primary goal will be to support White Star‘s superpressure balloon experiments.  A superpressure balloon maintains some pressurization above ambient in order to maintain altitude.  In order to figure out how to design the balloon envelopes, and to verify our math, we need to know what’s going on inside the balloon.  It’s difficult to pierce the balloon without generating leaks. The ideal solution is to place a second balloon computer inside.  Both will transmit pressure to the ground, and we’ll be able to compare pressure inside the balloon to ambient pressure for model verification.  The pressure sensor can sense a change as small as 4×10-4 PSI, so this should work.

This is my first attempt at real RF design.  Fortunately, operating within the ham radio bands means I don’t have to worry too much about spurious transmissions or leaky harmonics.

» Read more…