So, last week I worked on connecting my automatic curtain system motor unit to the control panel. Unfortunately, this wasn’t as easy as I had hoped. So after banging my head into the wall for a week, it is time do take a step back.
As told before, my curtain system will contain 4 motor units and one controller. This sums up to 5 Arduino units that will need to communicate with each other.
Apparently, communication is an issue. A thing my therapist already warned me for.
Anyway, my first approach of connecting the Arduino’s was I2C ….
I2C
As noted last week, I2C is a multi-master, multi-slave, single-ended, serial computer bus invented. It is typically used for attaching lower-speed peripheral ICs to processors and microcontrollers.
The code to use I2C is extremely straight forward, and connecting the Arduino’s only takes 2 wires. A test on my breadboard showed me the possibilities. So I was good to go! … NOT!
Fail! It turns out, I2C is extremely picky about the capacitance of the bus (the wires you use to connect the Arduino’s). The longer the wire, the higher the capacitance.
Essentially, I2C is really designed for intra-board communication. My +7 meters of cable isn’t going to work. In other words: I2C is just not an option.
So to conclude for I2C:
PROS:
- Extremely simple to implement.
- A well known standard.
CONS:
- Not suitable for projects with long wires.
Now what?
Now, with this in mind, let’s take a look for some decent alternatives …
PJON
Looking for alternatives for wired communication, I came across the newly developed PJON library. The documentation describes PJON as follows:
PJON (Padded Jittering Operative Network) is a multi-master, single wire, addressed and checked communication protocol and is designed to be an alternative to i2c, 1Wire, Serial and the other Arduino compatible protocols.
Exactly what I am looking for, right? So as you can expect, I started to play around with this library. Honestly, it is promising. The examples show nice results with 10 meters of (unshielded) wires.
But unfortunately, the project is still in early beta (or even in alpha stage). And since the documentation is far from complete, I ran into some issues for which I can’t say if they are bug or features.
Luckily, the developer of PJON, Giovanni Blu Mitolo, is an extremely nice and helpful guy, and as I’m writing this blogpost, he is working on improving both the library and the documentation.
EDIT 2015/9/23: Since I’ve wrote this blog, Giovanni did a lot of great work to improve the library! Many of the bugs are solved. Make sure to check out this awesome library!
With this in mind, I can conclude the following for PJON:
PROS:
- Uses only one wire between all the Arduino’s.
- Giovanni is a nice guy. (Hey, that counts as a pro!)
CONS:
- It’s in an early stage and thus it may contain bugs.
- The documentation is limited.
- Implementing is currently somewhat cumbersome.
XBEE
I’ve used and written about XBee before, but to give you a quick recap, let’s quote Wikipedia:
XBee is the brand name from Digi International for a family of form factor compatible radio modules. The first XBee radios were introduced under the MaxStream brand in 2005 and were based on the 802.15.4-2003 standard designed for point-to-point and star communications at over-the-air baud rates of 250 kbit/s.
In other words, they are small radio’s that could essentially make a mesh network between my motor units and the controller.
Unfortunately, using the XBee modules to set up a communication protocol would require a lot of configuration, and probably a lot of coding. And on top of that, The XBee models are a “bit” pricy.
To sum it all up:
PROS:
- Extremely reliable communication.
- Widely used. A lot of documentation available.
- Used in other pojects before.
CONS:
- Works on 3v3, so I would need level shifters.
- Connecting and setting them up is cumbersome.
- The modules would need additional electronics.
- They. Are. EXPENSIVE.
So although they might solve my issue and are extremely reliable. I don’t think XBee is the best approach.
nRF24L01
Of course, there are a lot more options when we talk about wireless communication modules. Probably the currently most used module is the nRF24L01. Simply speaking, you could compare it with the XBee mesh network mentioned before. But of course, the technique behind it is completely different.
The nRF24L01 is a 2.4GHz Wireless Transceiver capable of setting up a Mesh network. After connecting the nRF24L01 the Arduino’s SPI but, everything else is done in your Arduino Sketch.
The best part of the nRF24L01 is that they are extremely cheap! (less than a dollar per piece) And though the module itself needs to be fed 3.3v, the i/o lines on this module are 5v tolerant so no level shifter is required.
Overall, this module sounds pretty promising:
PROS:
- Cheap modules.
- A lot of documentation available.
- Reliable communication.
CONS:
- The module needs 3v3.
- All the motor units need additional electronics.
ESP8266
Of course, we can take it a step further. The ESP8266 is also a device I used and written about before. It is a cheap Wifi module with built in MCU. If I use a ESP8266 in the correct form factor, I could even totally replace the Arduino’s controlling the motors.
Just as the nRF24L01 modules, the ESP8266 modules are ridiculously cheap. So if I provide every motor unit with a ESP8266, all the motor units will be controllable by wifi independently. Although this adds some cool possibilities, it also adds some extra points of failure. Aside from this, I can conclude the following Pros and Cons:
PROS:
- Cheap modules.
- A lot of documentation available.
- Motors can be controlled without an additional controller unit.
- A lot of possibilities due to Wifi communication.
CONS:
- The module needs 3v3 and the lines need level shifting.
- All the motor units need additional electronics.
- Every motor unit will use an IP address.
- Risk of connectivity dropouts.
So, what route do I choose?
The quickest route is the PJON method. But since the library is still in development. I will probably use this as my fall-back method. By the time I’ve failed every other route, this library is probably in stable state!
The nRF24L01 look promising and should be relatively easy to implement. I will order some of this modules to experiment with, but since I still have some ESP8266 modules laying around, I’ll also give these a try. After all, how cool would it be to say I have Wifi-curtains!
If you have any other suggestions, or might have an out of the box idea, let me know by leaving a comment down below. The communication with the motor units is paramount. So a good discussion in the comments wouldn’t hurt the project.