Kossel Adjustable Bed + Conductive Probing

The bed probing in action!

My Kossel, which I have jokingly named “Screw Loose”, left a lot to be desired when I built it.  One of the major problems I had was print adhesion- or lack thereof.  Even with a heated build plate and kapton, the printer had trouble with peeling and plain not sticking to the bed. I learned what the problem was with a simple test- I went to z0 x0 y0 and moved the head around.  On one side of the bed, the head touched the plate.  On the other side, it moved away from the plate.

After some searching (circa late 2015), I discovered that there were no RAMPS compatible firmwares that had bed tilt compensation for the Kossel, even though .  I am not sure why,  and I think since then this has been rectified in a fork of the marlin firmware.

Instead of trying to have the printer compensate based on readings, I decided to take the mechanical approach of actually making the bed flat to the plane of motion of the head.  The first thing that had to be changed was how the bed was mounted to the frame of the printer- as it was designed, it just bolted straight on with no adjustment, which was a bad decision because it almost guarantees that the build surface will be at an angle.

Bed adjuster, with thumb screws above and below the bed.

Bed adjuster, with thumb screws above and below the bed.

Making the bed adjustable was actually pretty easy.  I put a long, steel 4-40 screw through the original mounting points, and fixed it to the frame with a nut, creating a “stud”.  Using what I had on hand, I made some thumbscrews by laser cutting acrylic and putting it around hex nuts.  This let me easily adjust the bed up and down at the three points it attaches to the frame.

The next step was to set up conductive probing.  I know people have gotten good results with the servo+microswitch, but I after using a renishaw probing system I just cant deal with how floppy it looks, nevermind the extra wire routing.  Conductive probing is actually really easy- I made the mistake of thinking I would have to write some software and started writing my own M code commands, but its actually a hardware solution.

I have no desire to add more wires to this rat nest.

I have no desire to add more wires to this rat nest.

The way bed probing is normally done on the kossel is with a switch mounted on a servo, which is mounted to the print head.  This gets wired to an endstop header on the RAMPS board.  Each endstop has three pins- ground, 5v, and signal.  In order to set up conductive bed leveling, all I had to do was run a wire from the bed to ground, and add a pull up to D18, the pin connected to the “signal” of the endstop header I used.  The code in question is here:

float z_probe() {
feedrate = homing_feedrate[X_AXIS];

enable_endstops(true);                      //Turn endstops ON!
float start_z = current_position[Z_AXIS];
long start_steps = st_get_position(Z_AXIS);

feedrate = homing_feedrate[Z_AXIS]/7;   //Make the speed slow
destination[Z_AXIS] = -20;              //plan to crash into the bed on purpose
st_synchronize();                       //Actually execute crash move
endstops_hit_on_purpose();              //We crashed into the bed on purpose

Before trying this, it is critical to make sure that the bed and head are clean, and that when they touch you actually trigger the endstop.  If the endstop is not triggered, the printer will do its best to drive the print head through the bed, which will leave a dent- I know this from experience.  It’s always a good idea to implement a command like my M430 command in marlin_main.cpp to make sure it is working before running g29 (bed probing).

    case 430: //M430

This snippet lets you know that everything is working by manually moving the head into contact with the bed, and checking to see if D18 changes from high to low.  It it does not change, the the endstop is not being detected and the printer will try to destroy itself- which is bad.

Once everything is working, G29 should probe the bed, and the head should gently “kiss” the bed in a few locations and spit out a map like this:

21:40:47.704 : 0.000 0.000 -0.400 -0.438 -0.400 0.000 0.000
21:40:53.881 : 0.000 -0.337 -0.400 -0.375 -0.387 -0.438 0.000
21:41:02.489 : -0.375 -0.475 -0.400 -0.375 -0.388 -0.400 -0.413
21:41:11.061 : -0.350 -0.413 -0.338 -0.363 -0.400 -0.388 -0.375
21:41:19.624 : -0.312 -0.475 -0.400 -0.388 -0.388 -0.488 -0.388
21:41:25.760 : 0.000 -0.438 -0.375 -0.350 -0.400 -0.313 0.000
21:41:29.438 : 0.000 0.000 -0.350 -0.363 -0.313 0.000 0.000

After some adjusting, it should be possible to get all the numbers really close- as you can see in this printout.  The diameter of the “grid” for these points was ~100mm, and all the points are within about .13 mm, or about .005″, which is pretty good.  NB that there are zeroes in all the corners- with stock firmware, you will have bogus numbers there.  It is easy to change that to setting them to zero, as seen here (note to self: use git in future):

// For unprobed positions just set to zero
if (abs(y) >= 3) {
bed_level[1][y+3] = 0;
bed_level[5][y+3] = 0;
if (abs(y) >=2) {
bed_level[0][y+3] = 0;
bed_level[6][y+3] = 0;

After this, I easily made some decent prints, since it all the layers were even, and the print head never crashed into the plastic!  I highly recommend leveling the bed of your kossel if you have one.

Re-Flashing the Misfit Flash


After a thorough electrical and mechanical investigation of the Flash device, I decided I would do a little more poking around to see if I could download the firmware from the device. In the end I was not successful (although there is hope), but I did manage to put my own firmware on the device quite easily.


I took a multimeter to the tag-connect header to see which pins when where.  It doesen’t look like the normal SWD or JTAG 10 pin connector, but I did find power, ground, SWDIO/RST, and SWDCLK.  For reference, on the drawing above, the single hole of the tag connect is at the top.


I connected a few wires to the programming pins, and then wired those pins to an STLink programmer from one of the STM discovery boards.  Using OpenOCD, I first tried to download the firmware from the chip with dump image- but it came back all zeros (not shown)!  This is because the NRF51822 has a read-protection feature to prevent people from gaining access to your code.  This is configured through the second register in the UICR, RBPCONF.  The UICR starts at 0x10001000, so I started there and read a few registers.  RBPCONF was 0xffff0000, which means that all of the program memory is protected.

after erase

The values in the UICR can only be cleared if the entire program memory is erased, so that’s exactly what I did- nrf51 mass_erase.  With the memory wiped, reading the RBPCONF resulted in 0xFFFFFFFF, the default value of read back protection for code region 0 and all code regions being disabled.


Once it was erased, I checked that I could write to the chip by putting a simple blinking LED program on the chip.  All the program does is sleep and toggle all of the IO pins, but it was enough to show me that everthing was working.  Later on, I can use this program to test what pin goes to what LED, if I want to make a cool blinky display or something.

After talking to my coworker about this, I learned that there is a way to dump the firmware even with the memory protection on.  Since I was already on the prowl to find a non-destroyed flash to reprogram as a cool display, I might go ahead and buy one and see if I can get the firmware out of it after all.

Misfit Flash Teardown


Misfit Flash Teardown!

I was at an REI garage sale and found a Misfit Flash for 10 bucks.  I always loved the Misfit deadfront displays, so I picked it up figuring it would be fun to take apart, especially since I work at a company that specializes in connected devices.  I was surprised when I got home and realized that there is a big difference between the ultra-cool shine, and the much more economical flash.  I still learned a lot and I am glad I got to dive into some hardware that did not already have several big teardowns.


mec layout

Battery, PCB and ring, and bottom

The engineering in the flash is as minimalist as its design.  The almost featureless puck sits about 6mm high and is about 25mm across.  Most of the space is taken up by a battery, which is installed by popping the bottom cover off.


The bottom cover is held in by an annular snap, which is sealed against water by an o-ring that runs around its perimeter.  The snap is molded with two external actions, as you can see from the flash in the groove.  The material is almost without a doubt ABS.


Under the battery cover is the battery, which is attached to the PCB.  To prevent the PCB from falling out, a ring of plastic is heat staked to the “top” plastic which retains the PCB.  This is super obvious in the rightmost photo, where you can see that the case was accidentally melted by the heat stake tool.


I used a razor knife (x-acto #11) to sneak under the ring and cut out the heat stakes.  This let me pop the PCB out after I removed the ring.  The ring is a really small part, but it is important for holding in the PCB, locating the battery and protecting the battery clips!

This leaves the flash at a grand total of three molded parts- but one is a little more complicated than the others.  This is the “face” of the device, which is a translucent, soft-touch plastic (santoprene maybe?) overmolded on a thin piece of ABS.  This outer layer allows the fairly bright LEDS to shine through tiny holes in the ABS, creating a crisp dot on the face of the device.  In the left photo you can see thin walls of the darker soft-touch material in the light wells.  This is was caused by clearance between the ABS insert and the tool that held it.


The overmolding was done carefully to minimize the impact it had on the cosmetic outer surface.  It looks like this edge was used for injecting the plastic, and it was carefully trimmed away later.  The rest of the edge is totally smooth.



Orange: accelerometer, light green: Crystals, dark green: NRF51822 AA model, dark red: RF antenna and balancing network

Compared to something like a phone, there is not a lot going on, but that is not to say that it is not complicated.  On the east side of the board, you can see the RF block and antenna.  To the north, you see a couple of crystals.  The west side is dominated by a QFN which is likely an accelerometer.  Right in the middle, there is a button, and on the south end of the board there is a happy little sputnik.


On the back side of the board, there is a battery holder, a tag-connect 10 pin header, and a nice silkscreen that says it was designed in San Fransisco, along with the initials AR and GR- maybe the initials of the people who did the layout.  When in use, most of this is covered by a big sticker, but I love seeing cool little details like this.

In any battery operated product, less is more.  The flash uses a CR2032 coin cell, which boasts a lofty 225 mAh at 3 volts.  The best AA you can buy in stores- the energizer L91- has about six times as much energy, although comparing batteries is like trying to compare apples to bread- they both have calories but they are processed in very different ways.

To achieve its quoted 6 month lifespan, this means that it has a whopping 15 joules per diem to spend.  That’s insanely low- to put it in perspective, that’s the same amount of energy as it takes to lift a bag of about 7 apples from the floor to the top of the fridge.  Another way to put it would be 1/30,000 th of the kcalories  in an apple.  Anyway, the device has to be designed very carefully to use such a small amount of power.

The most radical part of the power saving strategy is to actually have no voltage regulator.  Many devices have started to use very efficient switching power converters to regulate power, allowing all devices to operate at the voltage they are most efficient at.  However, these converters come with three major costs- money, board space, and quiescent current (power consumed when the converter is idle).  The designers of this board decided to eschew converters, and just choose parts with a wide voltage range, from 1.8V-3V+.


The accelerometer is most likely the LIS2DH from ST Micro.  Adafruit and Sparkfun both mentioned it on their teardowns of the shine, and the package is the same.  The pinout is also identical to what I saw labeled on the board (see photo) in terms of an SPI connection between the microcontroller and the chip.  NB that SPI has a power savings over I2C in terms of not needing pull up resistors.

leds on

The choice to use red leds on the flash is not because it looks cool or sinister, but because much like the the other major components, red LEDs will still work at low voltages.  While or blue LEDs require almost 4V to work, while a nice green led would be in the range of 2.2V.  Red leds have the lowest voltage drop of any color of led, at around 1.7 volts, although they are quite a bit dimmer at low voltages.  This means they will operate down to about the voltage level that the accelerometer does.

At the heart of the device is the beloved NRF51822.  This is a frontrunner in terms of low power bluetooth, with plenty of development kits and even cheap pre-certified modules.  This SoC combines a 32 bit Arm Cortex-M0 with a power sipping 2.4Ghz transceiver.  This is the brain of the device.  Around it, there are a couple of crystals, one at 16 Mhz and one at 32 Mhz.  These allow the chip to sleep at low power for long periods of time.  Also in the constellation of parts surrounding the NRF is an antenna balancing network, and a trace antenna.

Final Thoughts


The Misfit Flash is a neat thing.  I mean that in the fullest sense of the word- it is tidy.  Everything is neatly connected, and everything has a purpose, and the effect is a simple and attractive object.  I never used it for fitness tracking, but I did have a lot of fun just playing with it and watching the LEDS blink.  People who are designing connected hardware would do well to study this exercise in minimalism.

Kossel-like Parallel Delta Robot Kinematics

A pretty weird delta

A pretty weird delta

Delta robots are cool, so I built a kossel mini.  Unlike a cartesian printer, problems with a delta printer seem a lot less intuitive to track down, and a lot harder to identify since the problems seem like they can stack/combine in strange ways. In order to see what that  I ended up writing a delta robot simulator.

  • It is difficult to get the tower base positions correct
  • It is difficult to get the towers to be parallel
  • It is difficult to home accurately
  • It is difficult to get the rods to be the correct (equal) length

Additionally, I wanted to find out what the symptoms of these problems should look like, and figure out tests to diagnose these problems so that they can be compensated (or at least tweaked).  For example, on a cartesian printer there might be a problem with the X and Y axes being not perpendicular. The symptom in the print is that if you print  huge L shape, the two ends of the L will not be perpendicular.  You can measure the angle and compensate in software, or adjust the two axes until the two ends of the L are perpendicular.


delta 2

A pretty weird delta


To this end I decided to model a parallel delta robot, complete with G0 linear interpolation, and forward and reverse kinematics.  I expect I will need G2/G3 circular interpolation as well.  In order to see what happened if a machine was built wrong, my approach will be to:

  1. Simulate a perfect machine running a set of G codes
  2. Take the tower positions from the perfect machine and run it on a simulated “bad” machine
  3. Compare the trails
Running some sample G code in the simulator

Running some sample G code in the simulator

The model works!  It has been possible to simulate tool paths with some pretty arbitrary tower rotations/arm lengths thanks to the flexible way the forward and reverse kinematics are modeled.  A lot of kinematic models for deltas simplify things early on in order to get simpler solutions that are easier to implement on a microprocessor, like the model on the marlin delta firmware.  Since this is running on a computer, and it is meant to model things that are not perfect, I did not make those assumptions.  This means that I can actually generate tower positions for really weird geometries, and this model can create “tower codes” that could be used for machines with mis-matched arm lengths, or crooked towers.  This might be a little smarter than having a tiny microcontroller generate the positions “on the fly”, but it could increase file size slightly.


16s rRNA Colony PCR – The Orange Mystery Bacteria

Orange Mystery Bacteria

Orange Mystery Bacteria

One of the scientists at BOSSLAB found a bright orange bacterial contaminant in his yeast samples.  Since I am interested in pigments and colors, I though it would be fun (since it was already growing in the lab) to sequence the 16s ribosomal DNA to try to identify the species.  I have a few notes on the protocol, troubleshooting, and what you should see if you try it.

Materials For Reaction:

Really any DNA polymerase will work, but I used the NEB 2x OneTaq mastermix.

PCR Settings:

  • Heated lid ON
  • 10 min Denaturing at 98C

35X cycles of:

  • 95 C for 30s
  • 55 C for 60s
  • 68 C for 3 min

1x final extension at 68 C for 10 min, hold at 4C.



not what you want to see.  purple dye ~300 bp

not what you want to see. purple dye ~300 bp

I ran my first attempt at this protocol with a shorter 1 minute extension.  This was bad- the region of interest here is ~1.5kb, so at 1kb/min for your typical Taq polymerase, we would require at least 1.5 minutes.  I doubled that since I had plenty of time.  As you can see in this gel, the shorter extension time meant that I got some pretty small fragments, of varying sizes.  They migrated near the dye, which is at about 300bp.


2 log ladder on left, samples in lanes 2, 3, 4

2 log ladder on left, samples in lanes 2, 3, 4

With an extension of the extension time from 1 minute to 3 minutes, you can see that my bands are now sharp, and the right size- about 1.5 kb!

Mystery Resolved!  The bacteria is closely related to Sphingomonas aquatilis!  You can read about it on microbe wiki.  It is pretty cool, and is known to break down a lot of tricky carbon compounds, particularly ones that people consider pollutants.  It is also vividly yellow/orange, from its carotenoid pigments.

For your BLAST-ing pleasure, I have included the sequencing data below.  These were generated using the 8F and 1492R primers.




BlueGene: The Re-PCRing (and Re-Digesting)

pcr gel ii crop

Following this weekends failed restriction enzyme digest, I thought I would try again with  no heated lid, and with a longer incubation time.  I am using HindIII-HF, so I can apparently let it sit overnight without too much star activity (non-specific cutting).  Since I used quite a bit of my PCR product last time around, I thought it would be a good idea to re-PCR my gblock.  After a picture-perfect gel (above)


Speaking of pictures, here is how I do my gel documentation.  I just shoot my Canon SL1 through an orange piece of acrylic, at the gel.  I set stuff up roughly like this, then I turn off all the lights and take a long exposure.  With this method, I have been able to visualize 100ng samples of DNA regularly, although you can also see bands of half that mass.  I am wary of claiming I can visualize a band below 100ng since it was very faint and I had the aid of another identical lane later in in the gel when I did it, so it was easy to pick out against the background, which let me adjust the exposure to get a better picture of the band.

Anyway, I just put in my digest to run overnight at 37C.  I will heat-inactivate it at 80C for 20 minutes when I get back to the lab, and run it on another gel!  Time to go home!

BlueGene: A Restriction Enzyme FAIL!

It actually took me a day or so to accept my restriction digest had failed, and it took me a few hours to guess why it did not work.  What I wanted to do was digest my plasmid and my gene with HindIII (in separate reaction tubes).  This would leave HindIII sticky ends on both.  At the same time that I was digesting the plasmid, I wanted to also dephosporylate it so it would not re-circularize  (stick to itself during ligation).  To verify that I cut the gene and the plasmid, I ran them on a 2% gel.  I expected that if I ran to the end of the gel, I could get separation between the cut and uncut genes, as the difference is about 150 bp.  I also expected the uncut pUC19 plasmid to run much faster than the cut pUC19.  Alas, this was not the case.

Gel Analysis:

lanes numbered from right to left.  2% agarose gel, with safe gel stain

lanes numbered from right to left. 2% agarose gel, with safe gel stain

What a mess.  Seriously, this is a pretty gnarly gel.  Anyway, from left to right the loaded lanes are:

  1. 2 log ladder
  2. un-cut bg fragment
  3. empty
  4. empty
  5. cut bg fragment 1
  6. cut bg fragment 2
  7. pUC (way overloaded…)
  8. cut pUC A
  9. cut pUCB

As you can see, the cut fragments of pUC ran faster than the uncut fragments. This is very suspect, since the supercoiled plasmid DNA should be “smaller” than the cut DNA.  It was not a small amount either, it looks like it ran somewhere between 1k or 500 bp faster.  This could be due to over loading but it is not a good sign.

The cut fragments of the gene did seem to run a little faster, but the gel is so gnarly it is hard to tell.  They do look like maybe they got cut, but it is hard to tell when the bands are so misshapen and far apart.  It would be no good to try to ligate them to an un-cut plasmid.  So I need to troubleshoot this step.

What Is Wrong:

I strongly suspect that my restriction enzyme digest was foiled by the heated lid of the pcr machine.  It heats by default to 114C or so, to prevent condensation on the lids of the tubes as you get up to 98C or so.  I had it on at full blast- the inactivation temperature for HindIII is 80C, and  I used the “time saver” protocol and only digested for 30 minutes.  So what did not get inactivated had little time to get its enzymatic work done.