A Race to the Bottom?

by Eric on

We’ve had a few people ask us about the design goals of Pinoccio.  We’ve also received questions around why we’re not cheaper/bigger/faster/smaller/larger/32bit/72MHz/green/etc. like other projects are.  They’re good questions, because when launching a new product into an existing market, most people want some frame of reference to evaluate the newly introduced product.

We figured the answer warrants a blog post, so posted below are the four goals we were after with developing Pinoccio.


1. It’s gotta be easy

First and foremost–it should take no more than 5 minutes from unboxing a Pinoccio starter kit, to having physical hardware pushing data to the web, receiving data back from the web, and hardware talking to each other wirelessly.  Being Arduino-compatible is a big part of this.  Compatible meaning you can plug a Pinoccio into a USB port on your computer, and it shows up in your Arduino IDE to program immediately.  You choose the “MeshPing” or “FadeRGB” example sketch, hit upload, and the hardware is doing its thing.

We realize that there are people who are more advanced than this in the hardware hacking world, and understand what JTAG is, and what a bootloader does, and how watchdog timers and interrupts work.  But there are even more people that do not.  These people are near and dear to our heart, and they should be able to get the physical and the virtual talking together with a minimum of fuss.


2. Very lightweight mesh networking

We wanted really lightweight mesh networking to be the default network stack–not Zigbee, not Bluetooth, and not WiFi, but true coordinator-less mesh.  There were a lot of projects we wanted to build that didn’t need hefty coordinator-based network architectures.   From the people we talked to early on, they wanted it too.  So that became a core piece of Pinoccio.


3.  Security

If you start connecting the physical to the virtual, security is essential.  Every part of our network stack has to be secured.  The radios we chose have hardware-based AES128 encryption, along with a true hardware random number generator.  It’s simply a matter of defining a shared secret in your code to enable encryption for the entire mesh network.  Our WiFi shield also supports TLS sockets, so encryption is complete from device to web.  This is important to us, as it’s our opinion that you can’t tack on security at a later time.


4. The last mile between physical and virtual

There’s a “last-mile” problem that most wireless hardware projects have.  Yes, it’s never been easier than now to get physical hardware talking to each other, or to the web if you build up a bridge.  However, at what URL do you push that data you’re now generating?  How do you tie it to your web or mobile app?  How do you query it for visualizations?  Probably a mix of spinning up a Heroku instance or two, writing network protocols, making an API, tying your web app to it, and perhaps interfacing with Cosm or running your own database.

This chunk *sucks* to do right now.  We’ve been hacking this part for years, and are tired of reinventing the wheel every time.  That’s why we talk about the API portion of Pinoccios as being a core part of the product.  And since the API part is wide open, if you like more inexpensive JTAG-based hardware, then you can still use those with the Pinoccio API if you wish.


To conclude…

No product that we have heard about does these four things well.  You can get close if you’re good at hardware, good at software, good at web application/mobile development, and good at database administration.  But very few people are good at all of these.  We want to make it so they don’t have to be.

We hope that this answers questions around how Pinoccio’s different.  For what it’s worth, we think these other products we’re sometimes compared to have a huge potential to get physical hardware talking to each other in a very inexpensive fashion.  If price is a more important differentiator than ease-of-use, or the web and API components, then there are probably better choices than Pinoccio.  However, we’ve received a really good response so far from people in regards to our goals above, so we think we’re onto something by not making price the only defining factor in our product.

Filed under An Open Hardware Business




  1. tz

    I thought it was wifi?

    In any case, although I can and have done all the complex stuff, I still prefer something I can plug and play in a few minutes since it is easier to go agile -I might need to coordinate a dozen sensors, but if I first do something like a distributed blinker, I know that part of the code works so I can test each piece or layer instead of whole systems.

    The way to build a bridge is to first run a string across the gap. That is often the hardest part. Once you have a string across, you can pull a rope, then cable, then add a sky-car… the pinnochio is the string.

  2. Eric

    Hi Tz – Ah yes, Pinoccios do use WiFi to bridge to the web. We specifically wanted lightweight mesh networking between boards. We’ll update that header to better mean specifically mesh networking.

  3. Sally

    And tz, I loved your bridge analogy! It’s perfect. For folks who are building things with Pinoccio, we want the majority of the effort to go into the specifics of your project, not all of the scaffolding. And just like you said, this will make projects more agile — you can play around with ideas with much less time invested.

Comments are closed.

Log In


Create an Account

With an account, you can:

  • Join in community discussions
  • Stay up to date with our email newsletter

And soon, you’ll be able to:
  • Create a public profile
  • Share your projects & code with others

Choose your username