Category Archives: BeagleBone

Arduino BeagleBone Neutrino

Neutrino Lives!

Published by:

I’ve had a lot going on over the last few months, and among the bustle Neutrino has gone through several iterations. The baseboard is currently at version 3.2, and the sensor at 4.1.2. Some of the key changes include building the radio onboard both devices, pcb antenna on the sensor, changing to a better battery clip, adding pads to support the BME280 (when it becomes available, it can replace both the SI7021 and BMP180. It can save money if it costs less, and possibly power with one less device). The base now has a microcontroller onboard, which handles the relays and LEDs. This allows it to be functional standalone as a relay board, though the radio is not integrated into the microcontroller portion. The base still interfaces with either beaglebone black or raspberry pi, and the microcontroller is reachable via serial and programmable via avrdude gpio programming. The microcontroller is powered off of 5v, and as such level shifters have been added to interface with the beaglebone. I initially was able to run it off of 3.3v, but the microcontroller is essentially overclocked in this mode, and I wanted it to be reliable.

In the past two months I’ve changed jobs and moved to another state.  This home has two floors with a two zone heating system.  It’s winter, and we found that the kids’ rooms were very cold. Neutrino to the rescue!  I installed a sensor in all three rooms, and the following immediately became apparent:  1) The master was usually ~3 degrees warmer than the other bedrooms. 2)When the downstairs and upstairs were both calling for heat, the upstairs rooms heated evenly due to the CFM being spread out among the whole house. In this mode the upstairs rooms eventually equalized 3) When only the upstairs called for heat, the master got heated much more quickly than the other rooms. This was a problem because the master has the upstairs thermostat, and we want to turn the heat down in downstairs zone at night. In doing that, the other rooms would slowly drift to being ~5 degrees colder throughout the night.

On the first night it was installed as a controller (instead of just passively collecting data), we drove the upstairs heat off of the average temperature of all three rooms. This was a marked improvement. It maintained the ~3 degree difference between rooms, but put a floor on how cold it got in the kids’ rooms. It also meant a little extra heat for the master, but no big deal, we essentially split the difference between the rooms. After the data from that night was collected, we closed the vents in the master half way, and that seems to have helped significantly.  The heating is now a bit more even, regardless of which zones call for heat.

I’ve learned a few things in this new home. The first is that zoned systems seem to need Neutrino MORE than non-zoned. I had initially built the thing as sort of a poor man’s alternative to zoning, but a multi-zoned system has interesting dynamics going on, and an increased complexity in how the home heat is distributed when running in various modes. As such, one needs a way to see that information in order to tune the system, or bad things can happen. It could probably be remedied with trial and error, but having the data helps a lot. For example, my wife noticed that having the downstairs heat on made the bedrooms more evenly warm, so suggested we try leaving the downstairs heat on. I, on the other hand, surmised that the heat from the first floor was rising into the master (with our door being open and the thermostat nearby) and artificially raising the master’s temperature, thus we should turn the heat off downstairs at night. It wasn’t until we had the data that we realized that the downstairs vents being on reduced the CFM in the master to the point that the bedrooms would heat evenly if both zones were running.

I’ve ordered manufactured prototypes, 10 bases and 10 sensors.  I feel that the software needs a bit more polish, but eventually I’d like to start offering the boards as dev kits. I want to have software that will run, but I also think it would be far better if others could pitch in. I can do it all myself, but I know there are people better than me at the various aspects, particularly UI.


You’ll notice here the sawtooth, it’s due to only being able to turn the furnace on or off. We’d need variable fan speed and a furnace capable of efficiently producing lower temperatures to even that out.  Neutrino actually has a ‘hysteresis’ setting to decide how big the sawtooth will be, here it heats to 1.5 degrees above the low setting before kicking off. I could set it lower for a smaller sawtooth, at the expense of the furnace kicking on and off more often, but it’s surprisingly comfortable as-is, and more consistent than the stock thermostat.


Screen Shot 2014-12-28 at 8.58.00 AM

Arduino BeagleBone Engineering Neutrino Raspberry Pi

Neutrino Platform Update

Published by:

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


Get nRF24L01+ Radios Working on BeagleBone Black

Published by:

I have some projects that I’m planning with Raspberry Pi, Arduino, and BeagleBone Black. I’ve heard good things about the nRF24L01+ radios and they’re very inexpensive (I paid $6 for a set on Amazon), so I thought I’d give them a try. There’s no official documentation, however, and I found that while there were several resources online, many were inaccurate or had partial information for newcomers. While I have boards with stock operating systems, I didn’t know how to get the SPI bus working, how to wire them, or how to use the code, and each of those things were in a different place. This made things far more complex than they needed to be. My intent here is to provide a simple ‘jumpstart’ for someone wanting to just get it working as a starting point.

I actually have one Raspberry Pi and one BeagleBone Black, and am communicating between them. There’s not a lot of utility to this in the real world, as many other connectivity options are available and easy (e.g. ethernet, wifi), but it’s also easier than programming an Arduino, if you just want to do some testing on the platforms.

Equipment Prerequisites:

BeagleBone Black (rev B) with standard Debian image as of 5/2014 from
nRF24L01+ Radio

1. Wire up equipment

Screen Shot 2014-06-01 at 3.50.18 PM



beaglebone connectors:


2. Enable SPI on the BeagleBone Black. Note that the libraries are coded to use SPI1, and to do this we need to disable the onboard HDMI pins. Go into “/boot/uboot/uEnv.txt”, add the following line to the end (all one line!):

optargs=quiet drm.debug=7 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN capemgr.enable_partno=BB-SPIDEV1

Then shut down and restart the BBB. You should now see something like the following when you look at devices:

# ls /dev/spi*
/dev/spidev1.0 /dev/spidev1.1

3. Get the code. Do a “git clone”

4. Compile the code

cd RF24/librf24-bbb/librf24/
make install

5. Run examples

cd examples


You should now have some output that looks like this:

ROLE: Ping out
RX_ADDR_P0-1 = 0xf0f0f0f0e1 0xf0f0f0f0d2
RX_ADDR_P2-5 = 0xc3 0xc4 0xc5 0xc6
TX_ADDR = 0xf0f0f0f0e1
RX_PW_P0-6 = 0x20 0x20 0x00 0x00 0x00 0x00
EN_AA = 0x00
EN_RXADDR = 0x03
RF_CH = 0x4c
RF_SETUP = 0x07
CONFIG = 0x0f
DYNPD/FEATURE = 0x00 0x00
Data Rate = 1MBPS
Model = nRF24L01+
CRC Length = 16 bits
PA Power = PA_HIGH
Now sending 153...ok...Failed, response timed out.

If you see strange repetitions in the hex values, it might mean your pins are mis-wired, or that your SPI device is missing. If you do see the above, you’re ready to set up another node. If you do a second BeagleBone Black or Raspberry Pi, follow this but run ./pongtest for the receiver. Once you have two sides working you should see successful pings like this:
Screen Shot 2014-06-01 at 4.02.05 PM

For developers, you should now have a /usr/local/lib/RF24.h that you can include in your code and a library at /usr/local/lib/ For documentation, refer to