Category Archives: Arduino

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

Arduino Neutrino

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.

Arduino Engineering Neutrino

NeutrinoWeather 1.0 – Design

Published by:

UPDATE: Over the weekend I made a minor tweak to NeutrinoWeather 1.0, rev’ing it to 1.1. This adds a 100uF cap to buffer the coin cell’s power output, which should extend life. I also designed NeutrinoWeather 2.0, which takes a stab at integrating the wireless onto the board rather than breaking it out into a pluggable module. I almost ditched that idea until I came across an awesome little antenna from Molex (for those who don’t know, a custom designed antenna technically requires FCC approval. A PCB antenna would probably be ok for personal use, but to give/sell to others without proper approval would probably be a no-no). It’s supposed to be better than the average pcb antenna, so we’ll see. 2.0 adds .2″ to the width of the board, but 1.8″ x 1.0″ is still pretty good, I think.


I’ve had this idea for awhile that I’d put temperature sensors in every room of the house. These would drive the HVAC based on an overall average, or on the room you choose at the moment, or whatever. Perhaps eventually they’d control dampers in the ducts. To be an ideal sensor (for me), it needs to be small, low maintenance, double as a hygrometer, be inexpensive, and be capable of going unnoticed. Most importantly, it needs to work, and this means having easy feedback that it’s doing its thing.

To these ends, I began looking for solutions and ran across Nathan Chantrell’s TinyTX project. It ultimately didn’t fit the bill, but it gave me some ideas. I ultimately designed my own small wireless temperature and humidity sensor device that can be hidden away on a shelf or dropped into a tiny project box and mounted via “Command Strip”. It has LED indicators that are capable of notifying the user that it is successfully sending radio updates (or not) and a low battery indicator. It also has three jumpers that allow the user to set one of eight radio addresses per-device (in binary), so the user can deploy up to seven transmitters and a receiver, without having to hardcode the addresses and flash each one. It will run off a single CR2450 coin cell (purchasable online in 5 or 10 pack for under $.50 each), and my hope is that each one will last at least 18 months. I thought about making a device that would hang off of a wall outlet, but such a device is far less flexible, and more difficult to make aesthetically pleasing for a homebrew project.

Screen Shot 2014-06-06 at 9.33.37 PM

For wireless, it utilizes the nRF24L01+ module that I’ve mentioned in the past, attaching via header on the back side. This will radio in to the raspberry pi base station, where I’ll control the HVAC via relays and serve up the controls via web interface.

The LEDs are high-output, low power. I expect to blink them for just a few milliseconds every time a measurement is made, and I’ve included a resistor to limit the current to just a few mA. Green for ‘radio transfer succeeded’ and red for failure. Amber will indicate low battery, less noticeable than a smoke alarm chirp I suppose. Of course, all of this notification can and will probably be done via the data, but there’s something about onboard indicators that make a product feel polished and complete.

As a bonus, I added a barometer onto the package, mostly just because I could. In all, the device measures 1.6″ wide and 1.0″ tall. With the wireless module and battery attached, it should end up about 8-10mm thick.

I’ve dubbed this tiny microcontroller platform ‘Neutrino’, since it both fits in with the particle theme of my blog and rhymes with Arduino. I named this particular one ‘NeutrinoWeather’, and hope to build several other Neutrino devices based on the same microcontroller on front, coin cell on back design. I toyed a bit with making a flexible design that exposed all of the pins via headers, but opted for the smaller single purpose design because 1) it’s cheap and easy to get small boards made, and 2) if I want to build something on a board that requires jumper wires, I’ve already got quite a few ATMega328 and ATTiny microcontroller boards floating around, and 3) If I do use jumper wires, it’s probably just intended as a prototype anyway.

I drew up the prototype in Eagle, the defacto hobbyist PCB making software. I tried to use Fritzing this time around, and while I found it a bit more intuitive and liked the visuals, I had a few issues (it crashed once, defining/editing packages via SVG seemed more difficult, and much simple and limited feature set) so I switched back to Eagle. It is advertised as beta software, after all. The board prototype has been shipped off to manufacturing, and with any luck I’ll be able to write an update in a couple of weeks and cover the code it will be running.

Screen Shot 2014-06-06 at 9.34.28 PM