Arduino BeagleBone Engineering Raspberry Pi

Neutrino Platform Update

Published by:

Screen Shot 2014-07-11 at 12.37.11 AM

The Neutrino temperature, humidity, and pressure sensor has had some heavy modifications over the last few weeks. Most notably, I’ve given it the option of installing an nRF24L01+ module onboard while still providing the header for an external board. We’ve also got jumpers to select the channel, address, and encryption. It has also grown a reed switch, for use as a door/window open sensor. The Arduino library for the SI7021 pressure and humidity module has been written, and hosted on github here.

Work has commenced on the web UI, and while there’s work to do yet, this has allowed me to also flesh out the API and database. Here is a screenshot of the per-sensor and sensor group views.

Screen Shot 2014-07-11 at 12.45.57 AMScreen Shot 2014-07-11 at 12.46.23 AM


How to tell Raspberry Pi from BeagleBone Black in C

Published by:

If you’ve got a cross-platform C or C++ program and want to compile it correctly for BeagleBone Black or Raspberry Pi, you can just use the C macro that corresponds with the ARM version. For example:

#include <stdio.h>

int main(int argc,char **argv)
#if defined __ARM_ARCH_6__
printf("Hello from RPI\n");
#elif defined __ARM_ARCH_7A__
printf("Hello from BBB\n");
return 0;


Neutrino Weather Is IN!

Published by:

Note: This is a continuation of a project started earlier.


The project details are outlined in the README of the github repo at neutrino-weather github

I got my boards this weekend. Luckily, they seem to work for the most part, with the one exception being that the DFN6 package I copied from somewhere seems to be a bit too small. I have a revision 1.2 being printed now. Still, I was able to carry on with the Bosch BMP180 sensor and get the modules sending data to my Raspberry Pi.

I learned a neat trick for soldering one-off surface mount boards. If you want to learn how to do surface mount soldering, I’d suggest trying this. ┬áThe guys at SparkFun swear by hotplate soldering. I didn’t want to mess with the nasty, toxic soldering paste, or solder mask for this small job. Instead, I touched each pad with solder, leaving a little bubble of raised solder on each one.


Next, I put the board in a pan, and then carefully placed each part in its correct position. This isn’t that hard, but you do need some decent tweezers. I’d recommend curved ones like the Wiha 44510, as it’s easier to work around the parts and get into a populated board with the curved tip. Note, I used a teflon pan. You probably should not, as it will begin to smoke and release noxious gases if you get too hot. Here’s a pre-heated shot of the parts placed:


Then, just carefully place the pan on a burner, turn the heat on high, and wait 60-90 seconds for the solder to look like it is flowing, and for the parts to sink into place. You can also use the tweezers to fine tune the position during this stage. When you’re done, you should end up with a professional-looking SMD solder job.


Once done, you can solder any bigger pieces by hand. You need to ensure that all small parts are on one side of the board for this to work, of course.

Here’s a shot of the back of the board, with the battery clip and nRF24L01+ module installed.


I’m pretty excited about the progress I’m making with these little radios. I have them publishing data to my Raspberry Pi. The client publishes the data to a Zabbix server that I run at home, and also to an sqlite database. From this point, someone can do pretty much whatever they want by reading the data from the DB, and not have to mess with the radio or any C code. I’ve uploaded my work to github.

Here’s an example of two nodes publishing temperatures to Zabbix:
neutrino zabbix

Arduino Engineering

Lepton… Smallest Arduino-compatible Board?

Published by:


Update: fabbed boards are in. Waiting on parts.



I thought I’d take a shot at making my own AVR board. I wanted to see if I could fit four of them panelized on a 5cm x 5cm board, but still keep all of the features and access to the pins. This board is about the same area as a “Teensy 2.0″, but with more features. I chose an ATMega32u4, because it has USB built-in. I succeeded in cramming the design into the space, even preferring larger components for easier assembly. It even has a 3v3 regulator. The one thing I ended up cutting was a reset button, which I seem to never use anyway. The pins are accessible to wire one up if needed. My plan is to use female headers, like the BeagleBone does, so there’s no need to be breadboard compatible.Lepton

I dub thee Lepton. Now I’ve just got to get some fabbed and try them out.


Software Defined Power

Published by:

I’ve got an idea for a new project. I’ve been working on the details over the last few weeks. As networking and server control in the datacenter are evolving into cloud and software-defined solutions, we need to pay attention to power control and evolve that as well. I’d like to initiate a solution for software-defined power controls.

Software defined power would consist of things like:

* Controlling the voltage of a port
* Controlling the branch circuits or lines feeding a port
* Auto detection of hardware connected to port, with software, not proprietary hardware
* Providing an open API standard that PDUs speak for configuration and data collection

PDUs already tend to have a lot of interesting software-defined features like port groups, load shedding, limits and alerts. These are usually only controllable through a proprietary web UI on the PDU or via a separate DC management software product. As such, there will never be advancement in the area because there can be no integration of tooling with third parties. There’s not much incentive for PDU vendors to provide this, because they want to sell their own solutions, but it hampers innovation for the end user.

Right now, if I have a 208v PDU and I want it to have a 120v port, I have to order a new PDU. It shouldn’t have to be that way. If I find a circuit is running hot and need to balance the lines, I have to go physically swap plugs. That shouldn’t be necessary. If I want to know which system is plugged into which outlet, I have to go trace cables and label the PDU in software. We shouldn’t have to. We should be able to fetch statistics and configure PDUs via an easy to use API, not SNMP.

To this end, I’m designing a reference board that will enable some of these features. I’m not sure what to do with it yet, perhaps if it works well and there’s interest I can go to kickstarter with it so that others can have copies of it to play with. I’ll figure out a name later.