by Geoff Van der Wagen

Post navigation

It’s now been a couple of days since my introduction on Pinoccio. I left my Field Scout in the wilderness that is my workbench, plugging it in occasionally to charge it, and it dutifully checked in with HQ every couple of minutes and reported on its vital signs (remember I haven’t actually asked it to do anything yet!). It’s time to find out what has been happening with it. We can do this using Pinoccio HQ, some Linux command line hacking and some free online graphing tools.

So what data does the Scout report to HQ? The dashboard shows the live temperature and battery status of the currently selected Scout:

This data is logged in HQ as well, and it is possible to use the API to download a history report.

Pinoccio is an Arduino-compatible, web-enabled, wireless mesh networking ecosystem. Check out their website for more information, these little boards are awesome!!

Pinoccio Field Scout (Lego for scale)

One of the first things that amazed me about Pinoccio was its ScoutScript feature. This lets you run live commands on your Scout without recompiling! As an embedded engineer I’m so used to the code->compile->download->review process that being able to simply type a command on a microcontroller and see the result is amazing. See this demo I stole from the Pinoccio homepage:

As you can see, there are a lot of things available to play with – temperature, battery charge (that’s the 94%), an RGB LED on the Scout’s PCB, and all the digital and analogue pins are right there too.

I’m a little obsessed with the temperature of things, so I’ll be doing a couple of projects on measuring various temperatures around my home. Let’s have a look at the Pinoccio and then set it up for some data collection.

Computers should be easy, right? Well, providing someone behind the scenes is doing the grunt work, they are. Most people are unaware of the level of complexity under the surface. As an embedded engineer I am closer to the metal than most. I’ve made a living out of turning diodes, resistors, capacitors and microcontrollers into something useful. Nothing is terribly useful in isolation, so you invariably want to communicate with it. That needs computer software; I do that too. All of this takes hours. Hours and hours and hours. Then, once it works as intended (a stage I call barely working), it needs to be tested in a way NOT intended. Let’s face it, the first thing somebody is going to do is type in the wrong thing, connect the wrong wire, or connect the power backwards and blow it up. Manuals are only consulted under a cloud of blue-grey smoke (that’s the magic smoke inside the chips, it’s surprisingly expensive to put back in and this upsets most people).

Of course, in the customer’s eyes they can do no wrong. What separates an average engineer from a good one (in my opinion) is the good one tries to break his creation as soon as he’s made it. Reliability is a cornerstone of good engineering, and a device that only works when all the stars and planets align, and people use it as the designer intended, is going to take around 5 minutes on average to fall over.

The problem with consumerism is people want things yesterday, and they want it cheap. They will buy the gadget that has been rushed to market and released barely working and then have an experience like the xkcd comic above. The challenge is to find the happy medium, where barely working becomes good enough and then everybody wins. After good enough you get almost perfect and this is an excellent device that has been well-developed but took its time getting to market. It usually costs more and this is my favourite type of device because it works brilliantly. However, it seems most people shop primarily on price and few are willing to pay a premium for something amazing. This is unfortunate as excellence is what drives us forwards and it is important to seek it out. We didn’t land on the moon by being average.