Author Archives: jgilbert

The evolution of an electronics hacker

EB231E38-2E37-4231-99AA-2B2BAF6AD617I’ve been thinking about how far I’ve come in the world of electronics hacking, and how far down the “slippery slope” I’ve come. From what i can tell, my journey is not that unlike many others…

Step 1: Radio Shack
You buy an Arduino and do a few simple sketches. It looks really cute and easy to use — sort of reminds you of your college EE classes. How does this thing work? Will it fry my laptop? Will I short it out if I hold it while its on? Is this weird language I write my sketches? C++?? It looks like C++ but it acts weird… A few days later you have a blinking LED and light sensor. Maybe you go back to the store and buy a few shields because they make adding new parts a lot easier. Everything is nice and tidy. You avoid hooking up your own LEDs because you’ve heard its possible to blow them out and you can’t remember enough electronics from college.

Hello world = “Blink”

Step 2: Solderless Breadboards
Suddenly, you’ve graduated to putting things on a breadboard, which you gingerly connect to the pins of your Arduino Uno. Next thing you know you’ve gotten sick of those CdS photocells and bought a real I2C light sensor from Adafruit… you’re a little scared because you haven’t soldered a connection since college 15 years ago. Of course, at this point you’ve gotten a simple multimeter and a 10W soldering iron from RadioShack. A few days later, you realize that Limor Fried is a genius for making electronic components that are low-frustration and offer high reward for low effort. You start to think about making your projects permanent, but you aren’t sure how. You now breadboard your own LEDs and resistor them with a 2.2K because thats what the wiring diagram shows you.

Hello world = “A speaker and and LCD display”

Step 3: Make something real
Gosh you think, wouldn’t it be nice if I could actually made a protoboard that does something and is more permanent. You start hacking your own little thru-hold boards with a mess of wires on both sides. Everything is a big hack but … Volia! A stand-alone project! You start buying small Arduino breakout boards like the Mini or the Trinket. Now suddenly you start having opinions about project cases. The thought occurs to you to get a 3D printer or a laser cutter so you can make better ones. You are counting your lucky stars that every sensor or tool already has a pre-built Arduino library from Adafruit.

Hello world = “A hacked together light sensor”

Step 4: Loose the wires
Overnight, you realize that your existing projects are too boring. They all have to be tethered to your computer. They can’t stand on their own and collect data. You start learning how Lipo chargers work, and develop opinions about battery technology. You realize your multimeter won’t measure microamps and upgrade. Suddently you have a Xbee, a Moteino, and a LightBlue Bean floating around your desk and you’re building wireless sensors and toys. You aren’t quite sure when this happened, but somehow the idea of a pull up resistor no longer seems magical to you. You’ve not only tried the Yun, but you’ve developed rich opinions about software serial and wish it had two UARTs.

Hello world = “A wireless sensor network”

Step 5: Software and Hardware mastery
All at once, you realize that there are a bunch of little things you need to get good at. Previously you’d put off learning python, but now you want to write a GUI that reads from bluetooth and it would be so much easier just to use the sample code. You’ve previously avoided data sheets like the plague, but now you start to devour them, trying to figure out what pins you’d need for your new wild creations. At this point you’ve read the AVR data sheet twice. You know how to put it in low power mode and which pins are connected to timers. You now regularly pop open components from Sparkfun or Adafruit into Eagle to make sure you understand how the library works, but you’re still using it in “read only mode” because the Eagle software looks intimidating. You’re now using AWG 30 wire for everything you do since its “tidier”, and you’ve come to learn the magic of teflon coated wires. You are now giving Sparkfun and Adafruit a lot of business. Limor Fried and Paul J Stoffregen occupies the same part of your brain as Richard Stallman and Linus Torvalds. You’ve learned you can avoid resistoring your LEDs if you hook them up to PWM pins. You vaguely know that some people are making their own PCBs with SMT parts, but that’s something “you’ll never do.” Your managing your Arduino projects in Github.

Hello World = “Installing a new boot loader”

Step 6: Down the rabbit hole
How far can we take this? Now you’re starting to write your own sensor libraries, and routinely read through library files critiquing their memory use before you include them in your project. You’ve started to fork libraries and submit pull requests. You’ve discovered bugs in the Arduino pre-processor and grouchily stab in workarounds. You’re sticking PROGMEM everywhere you can in your code to strip out every last byte of your sketches. You’ve gotten over your fear of mains current and have cut open more than your fair share of power cables to wire up something that needs a power supply. You put in your first order to Digikey, and now 50% of your components come from swap fairs and ebay. You used to ignore Bill of Materials files but now they are something you scrutinize to learn more about what kind of “inventory” you need. You decide its time to learn exactly how MOSFETs work. Low power is now essential, and you’re busy thinking about how to put everything to sleep for the greatest amount of time. 10mA now feels like an embarrasing amount of current for any project to draw when its idle…

Hello World = “Talking to a new sensor with a hand-built I2C code”

Step 7: Maybe SMT isn’t so scary after all?
Up until this point, you’ve admired SMT parts but figured that messing with them is something only “real” engineers do. Now you’re upset with how “bulky” your designs are and you dedicate yourself to learning Eagle. You order your first SMT parts and promptly loose the first few you open somewhere on the floor. Now you need tweezers, flux and magnifying glasses. You’re first order from OSH Park comes in and you’ve soldered your first board. Suddenly bootloaders and the ICSP header are now vital in every new design. You’ve learned enough of Eagle’s quirks that its now starting to feel familiar, almost like an old friend. You’ve ordered a new sensor and out of curiosity you bug wire it because you don’t have any spare breakout boards. Digikey is on speed dial, and your getting a new shipment every other week.

Hello World = “Your own customized PCB with 0805 parts”

Step 8: SMT and beyond
You buy a hot air rework station. Now when you run out of AVR chips you first consider desoldering them from old bits of junk you have laying around. You’re getting into RF, and suddenly have opinions on frequency shift keying. It occurs to you to get a Ham radio license so your creations can be more “law compatible”. Your 3D printer feels more like an appliance rather than a toy, and you get stressed when you realize that the custom power supply you built for your heated bed doesn’t work anymore. You’ve crossed the rubicon on custom wiring harnesses and now have opinions about different crimpers and the right amount of angle to use for a JST XPH crimp. You’ve got sorting systems to hold all of your SMT parts, and you’ve become a hoarder of component footprints in Eagle. You start doing research on oscilloscopes because its “only a matter of time.”

Hello world = “Soldering your own dipole antenna”

10 Things I Wish I Had Known When I Started out with Drones

Cambridge and Boston in the snow!
Cambridge and Boston in the snow!


From what I can tell 2014 seems to be the year of the drone . It’s around this year that Amazon started talking about delivering packages with drones, they’ve been in the news almost every month, we even had a crash landing of the drone on the White House lawn. More recently CNN has now been using drones to film features, and a town in Boston is using them to inspect roofs for snow removal.

Last year, I bought my own drone, a DJI Phantom 2 Vision and now have been enjoying all of the ups and downs of drone piloting. In fact, since then I’ve graduated to building my own drones from parts. In the spirit of paying it forward and paying it back, here is a brief rundown of the major things I had wish I had known when I started out.

#1: Do some homework

There is really a vast difference between a fully integrated drone like the Phantom 2 or Parrot AR, and the consumer level toy you’d get for less than $80 on Amazon. It definitely pays to do your homework on this market.

Required reading:

In my case, I went for the Phantom 2 Vision+ but in retrospect I would have been better off building a Phantom 2 and upgrading it to first person view.

#2: Flying is surprisingly (and troublingly) easy

When I first unboxed my Phantom 2 and charged its batteries, getting it into the air was dead simple. You put on the props, wait for a GPS lock, and take off. Suddenly, without any real preparation or forethought, you are now in control of a device that can fly through the air in any direction up to 30 MPH. The absolute ease of flying one of these types of drones makes it very easy to “fly too far ahead of your skis”. Taking it slow (and getting prop guards) is essential.

#3: Take precautions

Fly in open spaces, get prop guards (because you will crash no matter how careful you think you are). It is very rare for these things to fly away or drop out of the sky, but that can happen. Label your aircraft with your name and phone number. Make a pre-flight checklist to remind you of all of the things to check. Never fly without GPS lock of at least 7 sats, and avoid wind more than 20MPH. Never never never fly unless you set a home location and have verified that the drone will return if a control signal is lost.

#4: Stick time counts

Unless you’ve flown a model airplane or helicopter already, your brain does not come wired understanding how to really fly. Your unprepared to visually identify which direction the drone is flying beyond 30 feet, and your brain goes through all sorts of weird mental gymnastics to properly translate the direction you want to go into the right combination of hand movements. This takes real time to master. As of March, I probably have 30 flights under my belt and still consider myself a learning pilot.

By the way, flying crazy eights, or flying circles with yourself in the center is really great practice.

#5: If Aerial Photography (AP) or Videography is your goal, practice that separately

Videos on a properly stabilized drone are really quite amazing. They provide the impression of unfettered flight, incredibly smooth and almost buttery. Its like superman flying with a steadicam. However, like anything there is a bit of an art. The brain likes to see certain kinds of movement better than others. For instance, changing the tilt more than once during a panning shot makes the shot feel random and unplanned. Video where the camera is rotating with the direction of movement (and even 5-10% ahead of the yaw) feels more exciting and engaging. There are dozens of little things i learned about this that only started to sink in after reviewing a lot of footage.

#6: Have contingency plans

Nothing is more stressful than not being sure how to land your aircraft or trying to find it. There have been numerous times that I’ve been executing a maneuver and then lost the video feed due to interference. Now suddenly, I’m flying blind, scanning the sky trying to figure out what little point of fuzz is my drone. Even worse is loosing your sense of orientation and realizing that the bird is moving in an opposite direction.

#7: Spotters are really helpful

A spotter can keep their eye on the drone and also help redirect onlookers so you can concentrate

#8: Drones are surprisingly robust

For the first few weeks of flying I was operating under the assumption that inside my drone was a very delicate set of mechanics that were all carefully calibrated and that serious problems could occur if any one little thing went wrong. Then after a few crashes, I realized that drones are designed to compensate for all sorts of things. If the weight is imbalanced, or one of the prop rotors a little chipped, the flight control will do a remarkably good job compensating.

I’ve never had a drone just “drop out of the sky” — I think the only thing that could total and sudden failure like this is an electrical short or the battery falling out. On the other hand, if a single prop on a 4 rotor multicopter gets stopped for any reason, you have an instant disaster. This has happened to me when clipping a tree, and also when a kink in the case came loose and rubbed against the motor.

#9: Consider a flight tracker

I consider my Flytrex a very good investment for piece of mind. At any point that my drone crashes or if I loose telemetry during a flight, I can pull open an app and look at where the drone was last seen.

#10: This hobby is addictive and you can get sucked in!

I started out with a integrated consumer drone and now I am building new ones from parts. I’ve soldered and crimped more cables than I can count, and I must have more than 15 different antennas and RF parts scattered around my house. You can quickly go from casual flight to a full blown hobby!

2015-01-20 21.21.34

Wireless beacon for locating lost UAVs

After loosing my UAV a few weeks ago during a period of strong winds, I’ve decided to try building a GPS beacon and receiver. The beacon is small, lightweight, contains its own micro GPS receiver, and transmits its current location every two seconds on a 433Mhrz radio frequency. The receiver contains a display, a GPS for tracking its own location, and a flash chip for logging.2015-01-20 21.21.34


I am planning on conducting some range tests over the next few days. Here is an example export file from a walk I took around the parking lot. I parked the receiver on the second floor open area of Industry Labs and took a walk with the beacon. You can see as I get further away from the building entrance, the RSSI declines:

Screen Shot 2015-01-20 at 9.31.53 PM


Next step: a simulated search and rescue to test the transmitter range.

Wireless sensor network with Motetino R3

Today I’m going to share my designs for a wireless sensor network build using Felix Rusu’s awesome Moteino R3 platform. My network measures light, temperature and humidity in my office and I plan to use it to help me figure out how to make the temperature in here more manageable in the summer.

Enter the Moteino!

The Moteino is a low cost Arduinio-compatible ATMega328 chip bolted onto a HopeRF RFM69 radio transceiver. I’ve concluded that this is a much better platform than the Ciseco XRF for sensor networks after a few weeks of evaluating both. Moteino is a really ideal platform because:

  • The Moteino works out of the box the way you expect it to
  • Is easy to integrate into a breadboard with 0.1″ spacing
  • The wireless platform is optimized for sensor applications, not serial poirts
  • Its much better documented than Ciseco’s products (strange too, since Ciseco is a multi-employee company and LowPowerLabs is apparently being run out of a suburban home in Detroit.)
  • Shipping time is nice and quick from Detroit, MI
  • Everything you need – FTDI port, power regulator, status LED is already on-board
  • More pins!

Felix hand-assembles the Moteino’s at home — the build quality is remarkable.

Here is a photo of the front and back side of the Moteino, courtesy of Felix’s website:

Prototyping the sensors

To start with my project, I assembled a protoboard with all of the sensors I planned to hook up so I could be sure everything works electrically. Included are the following sensors:

All of this fits onto a half-size breadboard.

I wrote the control code to be modular, so that depending on the “personality” of the sensor, different libraries would be automatically linked into the sketch and transmitted. If the library is not needed, the headers are not pulled in to keep the code size manageable. The nodes emit helpful debugging information to the serial port if desired. I also added a special “LOWPOWER” mode puts the AVR and its integrated radio into a very low power sleep state until it is woken by the watchdog timer.

Each personality for the sensor platform is set with a set of C pre-processor definitions like so:

My window watcher

In addition to the prototyping board, I also designed an integrated “window watching” sensor that can detect outside light levels and compare them to indoor light levels. Its intended to be mounted on a window. When the blinds are closed, they reflect back more light than when they are open, letting me measure how open or closed they are.

This window watching sensor came out fairly well considering I’ve never made anything significant with a soldered breadboard before.

Closeup of the front:

Closeup of the front with the Moteino removed:

Back side:

The gateway

I’m using a raspberry PI as a gateway to the internet for my network. As you can see below, the wiring is very simple — just power, ground and Moteino’s D3 pin to RXD.

I originally planned to use a Arduino Yun as my gateway. After hacking with it for a few days I gave up and switched to the Raspberry Pi. The Yun does not really ready for such a task — perhaps the hardware or software is not yet mature. I kept running into unexplained crashes and missing bytes, probably a combination of the Yun missing a hardware serial port UART and some flakiness with the Bridge library that lets the Arduino interface with the chip that runs the Linux OS. This is really too bad since the Raspberry Pi is overkill for data logging and has a much less stable filesystem.


The communication protocol between the sensor nodes is dead simple and includes metadata that will maximize the utility of the data for analysis. Each packet is a comma-delimited line of text with fields like this:


The fields are:

  • 1st character: R for reading, C for command, I for info
  • A device specific sequence number for the message
  • The node name of the sender
  • A timestamp from the sender (usually # of milliseconds since start)
  • The name of the sensor
  • The sensor reading
  • The units of the reading
  • An optional memo field

When the packet is received, code on the raspberry pi gateway adds a local timestamp, the RSSI and the sending node ID.

pi@raspberrypi ~/sensornet $ tail mainlog.csv 
2013-10-25 10:51:50,R8354,Proto,1576920,LUX-Broad,1935.00,rawb,,-56,99
2013-10-25 10:51:50,R8354,Proto,1576920,LUX-Broad,1935.00,rawb,,-55,99
2013-10-25 10:51:50,R8355,Proto,1576991,LUX-Infra,729.00,rawi,,-55,99
2013-10-25 10:51:51,R8356,Proto,1577071,BMP-Temp,22.98,C,,-55,99
2013-10-25 10:51:51,R8356,Proto,1577071,BMP-Temp-F,73.364,F,,-55,99
2013-10-25 10:51:51,R8356,Proto,1577071,BMP-Temp,22.98,C,,-55,99
2013-10-25 10:51:51,R8356,Proto,1577071,BMP-Temp-F,73.364,F,,-55,99
2013-10-25 10:51:51,R8357,Proto,1577176,BMP-Pressure,101297.00,Pa,,-56,99
2013-10-25 10:51:51,R8357,Proto,1577176,BMP-Pressure,101297.00,Pa,,-58,99
2013-10-25 10:51:51,R8358,Proto,1577893,MDWIND,558.00,raw,,-59,99

The advantage of this format is that it can be easily loaded into a database or a charting package and used out of the box. Its very easy to filter, cross-tab etc. Eventually, I plan to have the receiving script insert directly into a database, in which case this format will still be useful as a way of creating “archives” of sensor readings.


Using a charting package called Tableau, I pulled some interesting charts. Tableau is one of the very best data visualization packages I know, and it an essential tool in my daily work at PatientsLikeMe. Here you can see the pattern when the window shades are opened or closed. The dip where the top line and the middle line spread apart is the point where the shades were open.

Another example, showing the Dallas, SHT15 and BMP085 each tracking my office temperature. (Note: the SHT is closer to my LCD display so is generally reading higher values.)


Gateway code

Getting the data from the serial port on the Motetino to the Raspberry Pi is a simple task, however I invested in a somewhat unusual design for the gateway script. I want my sensor network to have the option of bi-directional communication, meaning that it should be possible for the Raspberry Pi to send out commands and information back out to the nodes. One use of this might be to enable a wall display with the temperature and light levels. This means that the script must handle the back and forth traffic between the serial port a TCP connection and the file system. I decided to use a Perl script with a select statement to handle the multiplexing, a somewhat complex solution but provably the most CPU efficient mechanism at least in POSIX UNIX. In theory, a solid Pyhon coder could probably figure out how to do the same thing with threads, but I am not a full-time developer anymore and never learned Python.

Getting the source

If anyone writes to me, I’d be happy to share the code for all of the above. Its also available in my GIT repository here although its constantly evolving and not in any kind of “release”.  I’m not really sure who reads this blog or if anyone is interested in sensor networks the way I am, so I’m holding off making a formal dot release.



Cheapduino driving an 16×2 LCD

I recently put in an order to DFRobot, a Hong Kong-based supplier of hobbyist electronics and noticed that they’ve started offering <$5.00 Ardunio clones called “Cheapduinos“. I bought a pack of them under the theory that I’m always likely to run into cases where I need to add a little bit of integration logic where I would not want to pay the full cost of a full AVR circuit.

One such case is driving a 16×2 LCD screen. The Cheapduino has exactly 6 pins, and the LCD needs 6 pins. I figure I can use the remaining solder pads for TX + RX to actually talk to the LCD. This requires repurposing the A0,A4,A5 as digital pins.

Here are the working pinouts and some photos.

LCDPin      Uno    Cheapduino
 LCD 4   RS STD12  CHEAP D11
 LCD 6   EN STD11  CHEAP D10
 LCD 11 DB4 STD5   CHEAP D09
 LCD 12 DB5 STD4   CHEAP A0 (D14)
 LCD 13 DB6 STD3   CHEAP A4 (D18)
 LCD 14 DB7 STD2   CHEAP A5 (D19)

 LiquidCrystal lcd(11, 10, 9, 14, 18, 19);



A proof-of-concept wireless sensor network with Ciseco RFu + Arduino Yun

As I mentioned in a previous post, I am setting up an Arduino-based wireless sensor network at home, and evaluating a few different wireless communication options in the process. This past weekend, I completed the first phase of my project — assembling and end-to-end wireless sensor network that uploads air particulate readings, temperature, and light level readings to Xively. In this post I’ll walk through how I set this up.

I chose Cisceco’s lineup of “XRF” radios for my initial communication platform. I’ve really loved the idea of their products since I first read about their XBee replacements. Ciseco offers a really great premise — a whole lineup of well-tested XRF devices that make the “radio” work as simple as possible. I like the primacy facia simplicity  — each XRF device “transparently” relays everything it hears to all others. CRC checking and packetization is taken care of for you. Even better — it supports Ardunio compatible “over the air” updates nearly out of the box, meaning you can upload new sketches to a remote node over the wire. All communication back to the microprocessor is done using a serial interface, one of the very simplest interfaces to use on nearly any embedded device.

I have to admit that I really fell in the love with the idea of Ciseco products after doing a lot of on-line research — so much so that I went ahead and ordered quite a few components. Cisceo has has a solid lineup of different form factors for their radios. The XRF is an XBee replacement. The ERF is a FTDI replacement. The SRF is intended for surface mount. I love their URF module which is a radio + a USB interface — this makes it dead simple to observe what is being transmitted using a PC. This capability invaluable in troubleshooting and a really brilliant move on their part.

For my project, I used a combination of their tools including a URF usb serial relay (for laptop monitoring), a RFu arduino to take readings and a ERF module to relay readings to a Arduino Yun that uploads them to Xively. The integration of the Arduini compatible AVR chip and the XRF radio onto a single device is very attractive. In theory it means that you could create a wireless sensor or device with very little additional components.

My setup begins with my sensor board shown below using the Ciseco RFu to share light levels. As you can see there is quite a bit of integration components needed to get it working. The Rfu is placed on a Sparkfun Xbee breakout board to make it breadboard friendly. On the right is logic to make it talk to an FTDI connector. On the left side is an LED to visually check the “heartbeat” and a power regulator to provide 3.3 volts. The TSL2651 light sensor is mounted in the middle.

When the sensor node powers up it starts transmitting LLAP messages every few seconds. Every message is exactly 12 bytes and contains a two letter node name, a three letter sensor name and the reading. You can see this message pattern here through the serial monitor on my laptop, fed via a URF USB radio.

On the Yun, I soldered together a shield to connect the ERF radio to the Yun in a tidy way. Ciseco does make a shield for this purpose but it assumes it will talk to the Arduino using D0 and D1, which are “reserved” on the Yun. (D0 and D1 are actually the conduit between the linux distribution and the AVR.) My shield remaps the TX and RX to D10 and D11, and the sketch reads via the SoftwareSerial library.

The Yun runs a very simple sketch the receives LLAP messages and invokes a command to upload to Xively using a CURL unix command. It was a fairly simple task to integrate the existing Yun demo sketch for Xively to the LLAP demo sketch. I just had to add some glue to parse the sensor name out of the LLAP message:

 strncpy( sensor, cMessage + 1, 5 );
 sensor[5] = 0; // last value guard to null
 strncpy( value, cMessage + 6, 6 );
 value[6] = 0; // make sure last value is null 

 for( int i = 0 ; i < 6 ; i++ )
 if( value[i] == 0x2d )
 value[i] = 0;

 Serial.print( "Sensor: " );
 Serial.print( sensor);
 Serial.print( " Value:" );
 Serial.println( value );

Despite everything now being assembled, not all is rosy. First of all, somehow I have managed to fry two of my Ciseco parts; I’m not sure exactly the cause but I did have quite a lot of difficulty figuring out how the pins were mapped. Secondly, the Yun experiences numerous hangs writing to Xively — basically timeouts either in the network or the bridge protocol. I think I need to create a new infrastructure that saves the sensor readings into a local log format.

Ciseco’s radios worked well, but I’m starting to feel that the technology may not be as tuned as I’d like it for sensor networks. More on this later.


Ciseco RFu arrived today

I ordered this on September 29th — that’s about 11 days to ship airmail from the UK to the USA. This board won’t fit into any breadboard that own. Already I am feeling some apprehension around having to solder such a tight pin spacing and get this to fit with my other components.


Wireless Sensor Network – Evaluation Phase

I’ve decided to wire my office with a small wireless sensor network to learn more about hardware electronics. I’m aiming to set up 2 or 3 small temperature and light sensors and have them wirelessly beam their readings to a central collection point. Apparently there are a ton of other people who are doing this sort of thing — so many that there is an O’Reilly book dedicated to the subject. (A book which I ought to read but in typical fashion I decided to dive in on my own.)

After hacking around with an Arduino kit and buying some sensors, I’m ready to move into the integration phase of my project. For a long time I had been stymied by not being sure what radio technology to use, and so the next week or so is dedicated to evaluation. I found this really great summary of the current “state of the art” by Stuart Poulton. I have dug around on this topic quite a bit making lists of different boards and prices, and I think his review is really spot on. However, my needs go beyond just a transmitter/receiver. I am really looking for an Arduino-based platform that integrates both the RF module and an AVR microprocessor into one neat package. So what is low cost, easy to acquire, Arduino compatible and easy to integrate?

After much research, I’ve narrowed this down to the Ciseco XRF and the AVR + RFM12 boards. The XRF is based on a TI chipset and Ciseco also makes an integrated chip they call the RF Micro or RFu. I have 3 of these on order, but frankly I’m already a little worried because of the hassle factor — they (apparently) lack standard 0.1″ breadboard spaced pins, require overseas shipment to Cambridge, USA, and don’t have an onboard power regulator. On the upside, the protocol is very simple — its basically just a serial port shared among a set of devices so theoretically a really easy-to-program platform. Ciseco’s XRF takes care of error checking, retransmission, packetizing, etc.

The HopeRF RFM12 initially scared me off due to its complexity. First of all, it looked complicated to use and puts the protocol burden on the microprocessor. Two vendors have integrated AVR/Arduino and RFM modules: Jeelabs and LowPowerLabs. JC, the guy behind Jeelabs really has contributed a lot of great libraries and insights on making low power sensors. I was very temped to buy one of his Arduino + RFM packages, but he has commited to a form factor that makes use of pluggable modules that don’t suit my style of electronics hacking. LowPowerLab, run by Felix Rusu seems to have come up with the answer: The Moteino. Its basically a full Arduino Uno in a postage-stamp sized package. Felix also has some great examples and code libraries,  designed the unit for solderless breadboard 0.1″ pitch and included a power regulator to boot. I put in an order for 3 Moteinos.

So now the race is on: Moteino or XRF?

Will update more later.