Needless to say, everyone had a great time, and walked out with some working 3D printers.  I’ve since gotten my Prusa home and had some time to play with it.

I’ve already got plans to make it better.  Tonight, I’m going to redo all the wiring to make it nicer, more reliable, and better looking.  Next, I intend to scrounge a server power supply out of the basement of LVL1.  Currently, it’s attached to a 200W Dell Power supply, which can only push out 200W.  This is fine for most things, but it just can’t put our the juice needed for heating the build platform to ABS temperatures.  I was able to get some calibration cubes of ABS to stick to the build platform, but nothing bigger. After that, sky’s the limit.  I’m also going to use this printer to print parts for another 3D printer, a Rostock.

Unfortunately, I’ll be missing the Midwest RepRap Fest this weekend, but I’ll be there in spirit!

The only change made to the original is the addition of a .1 uF capacitor on the DTR line of the FTDI header.  Some of the traces are a little closer together, but they’re still spaced out enough that etching this board is a cinch.

Here are the files:

Diptrace Schematic for Nanino

Diptrace PCB for Nanino

PDF of Nanino from the Back

You can use this PDF to etch directly.  No mirroring is needed.

Can be printed. 1200 DPI.

Can be printed. 1200 DPI. No mirror needed for etching.

DXF of Nanino

And, because the original Nanino is licensed CC-BY-NC-SA, this one is also:

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

It works!

Good toner transfer

The etch was drama-free

For example, I’m building a 3D printer:

This is the start to my Rostock 3D printer.  I started printing the parts for this way back in October, and I’ve just now gotten to the point where it’s starting to come together. Unfortunately, a much better version has come out in the mean time.  A couple of people have already come through LVL1 building the improved, extruded aluminum delta bot.  It was almost enough to make me start over and try again, but not this time!  I’ve tried to build three other printers in the past, but they never got further than printing some plastic parts.  This time, I’ve spent real money on the project, so I’m going to forge ahead!

So far, I’ve run into two major setbacks.  The first: the printed arms an u-joints are really, really terrible. Threading an M3 bolt into the U-joint as instructed is painfully difficult, and the result isn’t particularly smooth motion.  I’m going to have to buy a set of real rods before I can continue.  Second, the specced GT2 belting and pulleys were completely unavailable in the lengths I needed, so I had to switch to HTD 3M belting and pulleys.  It was expensive!  The company I bought the stuff through charged me $15 for shipping, on top of $35 for the belt.  Then I cut the belting wrong, so I have to buy even more!

I’ll be using a Printrboard Rev. D to drive the whole thing, unless it blows up in my face.  Then I’ll probably just buy a nice reliable RAMPs setup, or a fully assembled printrboard.  And then, I’ll be off to the races!

This is the wrong way to cut the belting. Instead, leave a long tail, loop it back on itself, and zip tie it together.

.

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:

void IRsend::sendLS(unsigned long data, int nbits)
{
  enableIROut(38);
  mark(LS_HDR_MARK);
  space(0);
  for (int i = 0; i < nbits; i++) {
    if (data & TOPBIT) {
      mark(LS_BIT_MARK);
      space(LS_ONE_SPACE);
    } 
    else {
      mark(LS_BIT_MARK);
      space(LS_ZERO_SPACE);
    }
    data <<= 1;
  }
  mark(LS_BIT_MARK);
  space(0);
}

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 (0×07 for Blue (default), 0×04 for Red, 0×05 for Yellow and 0×06 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: 0×0502
  • 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: 0×0602
  • 12 hits to kill from full health
• Pulse Strike: 0×0703
  • 8 hits to kill from full health
• Rail Strike: 0×0806
  • 4 hits to kill from full health
• Sonic Strike: 0×908
  • 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: 0×08–
  • MUST be used with team 0×08
  • Final byte is team byte for healing pulse (0×07 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.

 
 
 
 
 
 
 
 

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:

/* Entry Point */
ENTRY(Reset_Handler)

/* Highest address of the user mode stack */
_estack = 0x20020000;    /* end of 128K RAM on AHB bus*/

/* Generate a link error if heap and stack don't fit into RAM */
_Min_Heap_Size = 0;      /* required amount of heap  */
_Min_Stack_Size = 0x400; /* required amount of stack */

/* Specify the memory areas */
MEMORY
{
  FLASH (rx)      : ORIGIN = 0x08000000, LENGTH = 1024K
  RAM (xrw)       : ORIGIN = 0x20000000, LENGTH = 192K
  MEMORY_B1 (rx)  : ORIGIN = 0x60000000, LENGTH = 0K
}

/* Define output sections */
SECTIONS
{
  /* The startup code goes first into FLASH */
  .isr_vector :
  {
    . = ALIGN(4);
    KEEP(*(.isr_vector)) /* Startup code */
    . = ALIGN(4);
  } >FLASH

  /* The program code and other data goes into FLASH */
  .text :
  {
    . = ALIGN(4);
    *(.text)           /* .text sections (code) */
    *(.text*)          /* .text* sections (code) */
    *(.rodata)         /* .rodata sections (constants, strings, etc.) */
    *(.rodata*)        /* .rodata* sections (constants, strings, etc.) */
    *(.glue_7)         /* glue arm to thumb code */
    *(.glue_7t)        /* glue thumb to arm code */
  *(.eh_frame)

    KEEP (*(.init))
    KEEP (*(.fini))

    . = ALIGN(4);
    _etext = .;        /* define a global symbols at end of code */
    _exit = .;
  } >FLASH

   .ARM.extab   : { *(.ARM.extab* .gnu.linkonce.armextab.*) } >FLASH
    .ARM : {
    __exidx_start = .;
      *(.ARM.exidx*)
      __exidx_end = .;
    } >FLASH

  .preinit_array     :
  {
    PROVIDE_HIDDEN (__preinit_array_start = .);
    KEEP (*(.preinit_array*))
    PROVIDE_HIDDEN (__preinit_array_end = .);
  } >FLASH
  .init_array :
  {
    PROVIDE_HIDDEN (__init_array_start = .);
    KEEP (*(SORT(.init_array.*)))
    KEEP (*(.init_array*))
    PROVIDE_HIDDEN (__init_array_end = .);
  } >FLASH
  .fini_array :
  {
    PROVIDE_HIDDEN (__fini_array_start = .);
    KEEP (*(.fini_array*))
    KEEP (*(SORT(.fini_array.*)))
    PROVIDE_HIDDEN (__fini_array_end = .);
  } >FLASH

  /* used by the startup to initialize data */
  _sidata = .;

  /* Initialized data sections goes into RAM, load LMA copy after code */
  .data : AT ( _sidata )
  {
    . = ALIGN(4);
    _sdata = .;        /* create a global symbol at data start */
    *(.data)           /* .data sections */
    *(.data*)          /* .data* sections */

    . = ALIGN(4);
    _edata = .;        /* define a global symbol at data end */
  } >RAM

  /* Uninitialized data section */
  . = ALIGN(4);
  .bss :
  {
    /* This is used by the startup in order to initialize the .bss secion */
    _sbss = .;         /* define a global symbol at bss start */
    __bss_start__ = _sbss;
    *(.bss)
    *(.bss*)
    *(COMMON)

    . = ALIGN(4);
    _ebss = .;         /* define a global symbol at bss end */
    __bss_end__ = _ebss;
  } >RAM

  /* User_heap_stack section, used to check that there is enough RAM left */
  ._user_heap_stack :
  {
    . = ALIGN(4);
    PROVIDE ( end = . );
    PROVIDE ( _end = . );
    . = . + _Min_Heap_Size;
    . = . + _Min_Stack_Size;
    . = ALIGN(4);
  } >RAM

  /* MEMORY_bank1 section, code must be located here explicitly            */
  /* Example: extern int foo(void) __attribute__ ((section (".mb1text"))); */
  .memory_b1_text :
  {
    *(.mb1text)        /* .mb1text sections (code) */
    *(.mb1text*)       /* .mb1text* sections (code)  */
    *(.mb1rodata)      /* read-only data (constants) */
    *(.mb1rodata*)
  } >MEMORY_B1

  /* Remove information from the standard libraries */
  /DISCARD/ :
  {
    libc.a ( * )
    libm.a ( * )
    libgcc.a ( * )
  }

  .ARM.attributes 0 : { *(.ARM.attributes) }
}

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.

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.

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.

Up the the tracking page, the telemetry system works something like this:  The balloon sends us an email, we decode the email and put the data in a private back-end SQL database.  Once this happens, a parsing program triggers, which converts the SQL data into a GPX formatted track. This track has our sensor data added.  The data is uploaded to Amazon S3, and a PubNub message is sent out, informing the clients that new data is available.

At this point, the client downloads the new data, parses it, and displays it on the map, graphs and gauges.  Other commands include an “update predicted path” command.  This downloads a new path prediction, and displays it on the map.  The data held on Amazon S3 is not retained, since it’s just a duplicate of the stuff that’s already in our database. A file named “init.gpx” is also updated.  When clients load the initial page, they download this larger init file, and receive incremental updates thereto.

There are just a few major components to the client-side system.

• index.html - Just a shell for gauges, and a few links.
• wsbdata.js - Contains initialization code and command processing.
• wsbparse.js - Parses data for graphs and gauges.
• wsbsensors.js - Turns sensor specifiers into rendered graphs and gauges.
• wsbmaps.js - Parses data destined for the maps, initializes map layers, and handles point-click callbacks.
• settings.json - Contains defaults for graphs and map settings.
• sensors.json - Maps XML tags to graph divs, adds human-readable metadata

As an embedded guy, this was a really interesting learning experience.  White Star is an incredibly complex system, and I’ve had the good fortune to be involved at all levels.  There’s nothing like a big project to help you understand the “full stack.”

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.

The output filter is the most poorly designed section.  It’s surrounded by vias, made up of the linear arrangement of inductors and capacitors.  I wouldn’t be surprised if I ended up with RF coupling across the inductors, bypassing the filter entirely.  This design is *probably* good enough for 434MHz operation, but not 800MHz.

More information, and design files can be found here: http://projects.meatandnetworking.com/trac/meatandnetworking_tinyballoon

I expect this board to go through a redesign.  Schematic capture and PCB layout were done using KiCad, with which I have very little experience.  KiCad requires a different workflow from Eagle.  I’ll post a KiCad tutorial here later.

I ended up with a double-Pi filter on the output stage, and all the inductors are place linearly.  The RF might simply couple with the inductors, and bypass the filter entirely.  If that happens, I’m not too concerned.  Without any fancy RF analysis equipment, it’s a shot in the dark anyway.

LVL1 has a small rivalry with a few of the regional hackerspaces.  Back in October 2010, when we were but a fledgling space, we hosted a Sumo Bot tournament.  Hive13 and Bloominglabs came by, and we kicked their butts.  Hive13 held the rematch a few months ago, and I started work on my SumoBot.  Unfortunately, I didn’t finish in time, but the effort itself is worthwhile, and my bot will live to see the next match.

Sumobots are robots which seek to push each other out of a small ring.  The ring is black, with a white boundary circle.  Two robots enter, one robot leaves. Our competitions use the Mini-Sumo class of rules, allowing for a Sumobot which can fit inside a 10cm by 10cm rectangular tube, weighing under 500 grams.  I decided to print my SumoBot on our makerbot.

Thingiverse is a great website for finding models of parts to print.  Unfortunately, they aren’t always well-tailored for the machine you’ve got.  In this case, LVL1′s makerbot, Veruca, just couldn’t handle some of the parts from this model: SumoBot Chassis.  The motor mount and the connector printed out after about a half dozen tries each (The Makerbot is not a fool-proof technology), but the scoop failed over and over again.

In the end, I just designed my own in Google Sketchup, and exported it to an STL file.  This one only took two attempts to print, although the leading edge is weaker than the design from Thingiverse.

I had some motors from Solarbotics, but I got the rest of my parts from Pololu.  The Baby Orangutan controller was a great choice, with a build in 2A H-Bridge, and AtMega328 microprocessor.  I also got their cheapest sonar distance sensor, and some line sensors.

The board was developed in house, and includes headers for motors, sensors, and a servo.  The plan is that the sonar will sit on top of a servo, and scan back and forth for enemies.  This will allow for fast response to laterally moving targets.

Unfortnately, I never got beyond assembling the PCB.  But some day, she will taste blood.