One stop Arduino-shield for Grbl!

Riley Porter and Alden Hart of Synthetos has just announced their Grbl-shield, an Arduino shield purpose built for working with Grbl! Ours is in the mail, and we can’t wait to try it out. (Featured in the blogs of Make and Adafruit)

  • Plug and play compatible with grbl 0.6
  • Three stepper motors supporting X, Y and Z axes
  • 8x microstepping
  • 2.5 amps per winding (bipolar steppers)
  • 12v-30v motor voltage supported
  • Independent current control per axis
  • Motor connectors plug compatible with RepRap and Makerbot electronics
  • Uses TI DRV8811 stepper drivers

Teardown time! Interfacing "Pocket Radar"

Having children warps your perspective. Totally. And last summer I spent an unhealthy amount of time being annoyed at cars racing up our narrow residential street while rambling incoherently, “Heathens! Think of the children!”

So what does one do? I think some friendly automated neighborhood traffic surveillance would go a long way. So a while back I therefore got hold of a Pocket Radar. While it does evoke the stray ‘is that a radar in your pocket’-joke it is in fact a precise, yet tiny unit. The interface is admirably simple – one big red button (BRB) which starts metering and upon release displays the speed of anything substantial hurtling towards you to within a couple of km/h. So how does it interface?

HEED THIS JOURNEYMAN: According to Pocket Radar the device is very sensitive to static discharge – mostly the pins on the RF board – so if you intend to poke around one of these you should consider an ESD work mat and proper grounding. I did my probing in winter, wearing wooly socks while sliding around on hardwood floors with nothing for protection apart from my sanguine temperament. Stupid luck, most probably.

Promisingly the unit breaks out a few pins right over the battery compartment behind a little sticker. These however proved not to actually carry data, and are probably just diagnostics. Meh.

So here we go.

Broadly the front of the board carries:

  • 1 16-bit TI microcontroller – MCU MSP430F21x2
  • 1 TI programmable DSPTMS320LF2401A
  • 4 8-bit shift registers for driving the display – "SN74AHC595PW":
  • A slew of analog electronics for powering and filtering whatever comes back from the antenna.
  • 2 L324 op-amps

The back has fat pads connecting to the LCD and a light sprinkling of analog components. The bold 7 segment LCD display seems pure oldskool as do the shift registers. It doesn’t have hidden vias or mutiple layers. It’s a USPS truck. It’ll keep on truckin’ till long after the apocalypse.

Photoshop grants me x-ray specs:

Anyways, poking about a bit reveals that the DSP does signal acquisition from the op-amp / RC grid while the shift registers hang off the other MCU and do display refresh. So given:


we might just be lucky and find an available digital signal between the DSP and the MCU. Unfortunately finding out what the unit is doing could be somewhat difficult as the antenna is affixed to the back plate of the unit. The same back plate you remove in dissasembling it. Doh. But hey, the unit still powers up and pressing the BRB still still produces a random speed reading every once in a while. I’m guessing this is just noise from the hanging pins usually connected to the antenna.

Probing the DSP while staying far away from the sensitive op-amps reveals that pin 3, SCITXD, unsurprisingly sends something digital and serial to the MCUs RX pin. The TIs support normal UART, but after doing 3 captures I’m left with this:

2 different lengths of signal. Yet a total of 12 changes in sign for all of them.

The display can be set to meters/sec, feet/sec, km/hour and mi/hour. For all we know the data is coming off the DSP in a fifth intermediate format. Hoping that it’s one of the four above and counting.

The width of each pulse is 122µs = 0.122ms = 8196,7 baud. Now, 8196,7 / 2 is 4098 which seems just too much of a coincidence.

Transcribing the bits as clocked out gives us:

1. low -> 1010101011100010101000 -> high
2. low -> 10101010111011100010001110 -> high
3. low -> 1010101000101110001010 -> high

While the display readings in binary are:

86m/s –– 1010110 / lsb 0110101
283f/s –– 100011011 / lsb 110110001
311km/h –– 10011011 / lsb 11011001
193mi/h –– 11000001 / lsb 10000011

81m/s –– 1010001 / lsb 1000101
267f/s –– 100001011 / lsb 110100001
293km/h –– 100100101 / lsb 101001001
182mi/h –– 010110110 / lsb 01101101

136m/s - 10001000
304mi/h - 100110000

The repeats seem to be carrying information, but how? I stare unblinkingly at it for half an hour to grok pattern, but give up at 1:30AM. Next day I give Simen a call. He remembers a blog post he happenend upon describing an unclocked serial protocol where the recipient meters the baud-rate, by looking at the initial pulses. The repeats then carry a specific truth value regardless of their being high or low. This very quickly gets results.

1. low -> 1010101 011100010101000 -> high
mi/h 0 0 0 0 1 100000 1

2. low -> 1010101 0111011100010001110 -> high
mi/h 0 0 0 0 10 1 10 1 10

3. low -> 1010101 000101110001010 -> high
mi/h 0 0 0 1 00 1 10000

The protocol starts with 7 bits of toggling, presumably to establish a bit rate, 9 bits of data follow. Repeats are signal true, any other toggle is false. The data is in miles per hour.

This snippet of ruby will run the decoder for you – raising an error for repeats that aren’t threes is left as an exercise to the reader:

pulses = ["1010101000101110001010", "10101010111011100010001110", "1010101011100010101000"]
should_equal = [304, 182, 193]

def decode pulse
# chop first 7 bits. sync pulse
pulse = pulse[7..-1]
result = "" and cnt = 0
while cnt < pulse.length do
if pulse[cnt] != pulse[cnt+1]
result << "0"
cnt += 1
result << "1"
cnt += 3
return result.to_i(2)

pulses.each_with_index do |pulse, index|
puts "= #{decode(pulse)} // #{should_equal[index]}"

Open source laser cutter Lasersaur using Grbl*

Sweet laser glasses!

Stefan and Addie or Nortd Labs are creating an open source laser cutter. Looking for a suitable firmware they happened across Grbl and dared to try out the ultra-beta acceleration branch which turned out nicely for them:

Initially we wanted to write our own firmware from scratch for an ARM Cortex M3. Then we started playing with some open source AVR firmwares. Man, these 8-bit hackers have done some impressive work. […] In the end we only got grbl to perform smoothly (after updating to the super cutting edge code of Feb 3).

We appreciate their enthusiasm and look forward to assist them in adapting Grbl for laser cutting as much as we look forward to being able to build our own open source laser cutter from their plans.

(Also, if you’d like one, consider pitching in via the paypal links at the bottom of this page)

*) Grbl is our free, open source, high performance CNC controller written in optimized C that will run on a straight Arduino. More

Hello Kitty Stencil

When my first daughter was born 2.5 years ago I attempted shielding her from the insiped, trite garbage that is marketed to their bracket. Pink was not to be worn. Unisex garb in earth tones mandated. And indeed, as resistance proves to be futile, today I milled her a Hello Kitty stencil. So she can wield a clone army of pink little kitties and bomb her way to day care.

Shot and edited on my phone. The volume tends to vary.

Optimizing the cornering algorithm for the Grbl acceleration code.

Attempting to discover the best algorithm for determining optimal speed reduction in order to pass a corner at maximum speed but within a set jerk limit.

Red: The jerk-limit, Yellow: The actual jerk, Transparent blue: The sum of incoming and outgoing feed rate. The intersection between the red and yellow is the set of candidate cornering factors, the optimum one is the one where the speed is the highest, i.e. where the blue transparent layer is at its tallest.

The final optimizing algorithm must run on the AVR328 in a matter of milliseconds.

Mad professor control unit

We are experimenting with real time controls for the milling operation and came up with this unit cobbled together from dumpster spoils and the Big Dome Push Button. Now we can tweak the feed rate in real time using the sliding pot, see if we suffer buffer underruns because of poor serial comms and we have two buttons for pause and emergency stop. There is an experimental branch up on github if you want to experiment with real time feed rate tweaking: Control. (Warning: The pins had to be remapped. Be sure to check config.h for the updated pin out.)

In related news: We finally have gotten through most of the code for a look ahead optimizing acceleration manager for Grbl. It is completely untested yet, but if you are so inclined you can have a look at the code in this experimental branch. The details will be explained in a proper blog post later.

While diving our favorite dumpster: a clutch of more than 300 vintage 7400-series logic chips! Previously we have scored stepper motors to last a life time in this very dumpster.

If Norwegian Road Spending was Elevation

After seeing Doug McCune’s playful visualization of public data, If San Fracisco Crime were Elevation I was tempted to do the same for a Norwegian data set.

After casting about for something to make heat maps out of I came upon KOSTRA, the official statistics from Norwegian municipalities. While not exactly as spectacular as prostitution in the Tenderloin, Norwegian road spending per capita is a political hot potato (or at least, a semi-lukewarm potato). Here follows a few renders from last night. Like Doug I have to emphasize that this is close to useless as strict infoviz, but it does make for nice eye candy.

Bildeserie med 3 bilder — bla ved å trykke på pilene
  • Crib stand mk II
  • Crib stand mk II
  • Milling crib stand mk I
  • Crib stand mk I

Twist-strap build platform. Friction Fit – Subtracted 0.10mm from magnet diameter to size the holes. The fit is ridiculously tight and exact. Same goes for center hole for stepper axle. HPDE – cut depth 1mm – feed rate 500mm/min – ⌀ 4.67mm @ ≈ 15k RPM



Følges av 26 medlemmer.

As Bengler we build intangible assemblies of code and people. Dank is our wide-eyed excursions into fabrication, electronics and robotic control systems. Mer om sonen


Grbl — The free, open source, high performance CNC milling controller written in optimized C that will run on a straight Arduino. Read more

Nye bilder