Synergy on Raspberry Pi

This article was written while Synergy version 1.7.4 was the latest version, I'll try to keep this up to date with new Synergy released, check the end of the article for a change log.

The latest version of Synergy at the last update of this article is: 1.7.6

I love to use Synergy when I'm working on multiple PC's at the same time. It lets you control multiple computers with a single keyboard and mouse. You just move your cursor off one side of your monitor and it appears on the device next to it and keyboard redirects keyboard input as well, neat!
So when I ended up with a second pair of input devices on my desk because of my new Raspberry Pi, having it use Synergy was pretty high on my wish list :)

The standard Synergy client you can get using apt-get is pretty old. It's version 1.3.something whereas the current version is 1.7.4, so that's not going to work. I found this tutorial on how to compile Synergy from source, but that article is outdated as well. Fortunately compiling it isn't that difficult. It's a pretty well documented process, but it doesn't exactly specify which dependencies there are. So here we go!

Step 1: update apt-get

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install gcc cmake libx11-dev libxtst-dev qt4-dev-tools libcurl4-openssl-dev libssl-dev libavahi-compat-libdnssd-dev

The documentation also mentions python and gmake as a dependency but I think those are included in a clean Raspbian installation. I also ran into some problems related to ZeroConf (missing headers), those seem to be included with libavahi.

Step 2: get the source code

Even though you'll need to pay for Synergy nowadays (if you want binaries) you can still get the source code for free: https://github.com/synergy/synergy or you can get a tar.gz from the download page (after a login).
If you have git installed, you can do

git clone https://github.com/synergy/synergy.git

Or get the tar.gz and run

tar -xzf synergy-v1.7.4-stable-c734bab-Source.tar.gz

Enter the folder that was created.

Step 3: build it

Start by configuring the build

sudo ./hm.sh conf -g1

This will generate the needed build script and will check if all prerequisites are present. When that completed successfully you can start the actual build.

sudo ./hm.sh build

This took about an hour to complete on my RPi 2B, so grab some lunch or diner while it's compiling. When it completed successfully, the binaries will be in the ./bin folder.

Step 4: deploy it

This is just a matter of copying the binaries:

sudo cp -a ./bin/. /usr/bin

Step 5: configure it

From this point on you can just follow the adafruit article. The only difference is that I didn't have a ~/.config/lxsession/LXDE folder, it's called LXDE-pi on my RPi instead.

sudo touch ~/.config/lxsession/LXDE-pi/autostart
sudo nano ~/.config/lxsession/LXDE-pi/autostart

And add the following content to the autostart file:

~/.startsynergy.sh

Exit nano (ctrl + x) and make sure you save the changes. This calls the startsynergy script whenever you start LXDE (Lightweight X11 Desktop Environment).
Now create the startsynergy script:

sudo nano ~/.startsynergy.sh

And add the following content:

#!/bin/bash

killall synergyc
sleep 1
synergyc --name pi 192.168.0.16
exit 0

This stops all running Synergy clients. It then starts a new Synergy client. "pi" is the name of the client, you'll need this name when you configure the Synergy server. The IP address needs to match that of your Synergy server.
Finally you'll need to set the rights on the newly created script:

sudo chmod 777 ~/.startsynergy.sh

Step 6: use it!

startx

 RPi on the leftmost monitor, showing the Jenkins dashboard in the browser. The other four are from my main PC (left to right: SourceTree, Eclipse, Jira and Notepad++). And one keyboard/mouse to rule them all! :)

Changelog:
2016-01-05: v 1.7.5 tested, no changes needed.
2016-03-29: v 1.7.6 tested, no changes needed.

How do they do it?

Just got some more parts in the mail:

10 nRF24L01+ boards for a whopping $8.12 and free shipping. Seriously, how do they do it and make a profit? I wouldn't be able to send an empty envelope to China for that kind of money...
A couple of years ago I ordered 4 of those boards for $10.40, that's $2.60 each, and now they cost $0.81...

First prototyping board assembled!

Got the last pin headers in the mail today!

It's annoying that I still have to rely on wires for this to work properly, but that's the price I pay for not double checking the footprints. The next version (almost done) will have a nice socket header to plug the nRF in.

Colorful pin headers

While waiting for the female pin headers and a few small components to arrive, I partially populated one of the messed up boards to get an impression on how the final board will look. The result is colorful :)

White pins are signal pins, connecting directly to the Nano. Red pins connect to the 5V rail. Yellow to the 3.3V rail. Black pins are ground. Blue pins connect directly to the nRF and turquoise-ish pins are used for whatever is left. Hopefully this will mistakes during wiring. The remaining four rows of connections will receive a 15 pin female header. The inner two rows receive the Nano, while the outer two rows can be used to connect jumper wires. The three large holes were supposed to hold a DC jack connector.

Arduino Nano + nRF24L01+ prototyping board and epic FAIL

I've been working on a prototyping board to connect the Arduino Nano and nRF24L01+ reliably. Bad breadboards and clumsy jumper wires have caused me a fair share of headaches and lost hours already, so I wanted something easy to use and reusable. So I designed a small prototyping board that will do just that, and a bit more.

The board not only connects the two devices, but it also breaks out all of the Arduino's pins, and adds ground and 5V pins next to those as well. So micro servos and three wire analog sensors can be connected directly to the board.

The board also lets you choose to which pin you want to connect the CS and CE pins of the nRF, although the choice is limited to digital pins 4-9. The IRQ pin can be connected to digital pin 2 or 3. And last, but certainly not least, the board has various SPI pin multiplexing options aboard which can be selected. It puts both Nerd Ralph's two wire and three wire solution at your disposal to experiment with :)

Today the first few boards arrived from OSH Park and they look gorgeous.

And the bottom features some nice schematics which explain the multiplexing options:

Nearly all the parts needed to assemble the boards have arrived as well. Of course I couldn't wait and stuck in a Nano to see how it looks.

Pretty neat eh? But. Wait. What? Noooooooooooooooooooooo. I messed up the footprint of the Nano :( I accidentally swapped the rows of pins. Now I need to stick the Nano in the back of the board...

See how the power pins align correctly now?

FAIL

If only I had messed up the nRF footprint as well :( Good thing I only ordered three and not a dozen. Oh well, back to the drawing board. Looks like I'll probably have to layout the entire board again...

I'm really happy with the quality of the boards by the way, the silkscreen is aligned perfectly and the purple board with gold finish looks wonderful. I was a bit worried that the small text would be impossible to read, but it turned out fine.

AVR Watchdog timer and Arduino Nano issues

In the past couple of day's I've tried to get the watchdog timer on my Arduino Nano to work properly. With success, eventually, but it took some time.

The watchdog timer is a stand alone timer, available in pretty much every 8 bit AVR, that has its own low power, low precision oscillator (clock) and it runs at about 128 KHz, give or take 10%. The watchdog timer can generate a reset signal after a set amount of time, ranging from 16 milliseconds to 8 seconds. You can reset the watchdog timer from your code using a special instruction ("wdr"). The idea behind this is that when your code gets stuck in a loop, or takes too long to execute for various reasons, the micro controller will reset itself, without needing any human interaction.

The watchdog timer in the more recent AVR microcontrollers (including the ones in the Arduini Nano/Uno) have the ability to generate an interrupt instead of resetting the device. Or to generate an interrupt before resetting the device, giving you a chance to store some valuable parameters.This also means you can use the watchdog timer to wake the AVR from idle/standby/power-down mode, perfect for low power applications! Let's look at the datasheet of the ATtiny13A for a second, chapter 7.1, sleep modes:

There are two sleep modes we're interested in here, the idle mode and power-down mode. The first mode has a lot of ways to wake up from, but also keeps the main clock running, meaning more power is used. The latter mode shuts down nearly everything, but can only be woken up from using an external interrupt or the watchdog timer. Now let's have a look at the supply current. Let's assume we're using the 9.8 MHz internal oscillator as clock source and use a 3.3V supply. That's chapter 19.2:

So we're looking at a bit over 2.5 milliAmps at room temperature. Not bad at all, but too much. That's what we'd be looking at if we'd just use a loop and count sheep until we had something to do again. The idle mode is a bit better, chapter 19.3:

About 0.65 milliAmps, that's a major improvement over just burning clockcycles. We'd have to use a timer to wake up though, adding about 0.1 milliAmp (chapter 19.1). Let's look at the power-down mode with watchdog timer enabled, chapter 19.4:

A bit over 4 microAmps, yes, that's MICRO amps. So in power down mode we're drawing less than 1% of the current we'd be drawing in idle mode, that's definitely worth using.

But programming an ATtiny can be a pain. To be more specific: testing and debugging can be a major pain. There's no serial port on those devices, and there are usually no spare pins left anyway. That is why I usually write and test my code with an Arduino before testing it on an ATtiny.

As with any part of the AVR I never used before, I started out simple: set up the watchdog to generate an interrupt every four seconds and toggle the LED pin on the Arduino. That worked, sort of. After four seconds the LED came on, and then turned off, and on, and off, and on, about ten times per second... What's even more annoying is that I couldn't upload any new code while it was doing that. I'd have to pull the USB cable out and plug it back in right before the new code would be uploaded. I double checked and triple checked my code, tried various stuff but couldn't get this simple bit of code to work properly. Finally I started to expect something was wrong with the fuse setting on the AVR, but the Arduino wouldn't let me read or write the fuse bits.

So after a bit of googling I found out I wasn't the only one having this problem. Apparently the fuses on the Nano have been set to always reset on a watchdog timer overflow. And to make matters worse: the bootloader doesn't handle a reset caused by the watchdog timer properly.

The solution (to both problems) is to burn the optiboot bootloader (used by the Uno) to the Nano. For this you'll need a second Arduino, in my case a Mega2560. You'll need to write the sketch "ArduinoIsp" to that Arduino.

Keep it plugged in, it will now act like a programmer. Next you'll need to wire the Nano to your programmer Arduino as described here. Now select the "Arduino as ISP" as programmer.

 As target board, select "Arduino Uno", this will make sure the optiboot boatloader and correct fuse settings will be burned.

 Finally, select "Burn Bootloader". It will burn the optiboot bootloader to the Nano and set the correct fuses!

Now disconnect the programmer Arduino, plug the Nano back in, and set the programmer setting back to "AVRISP mkII". Your board will now look like an Arduino Uno to the IDE, so remember to select that as board whenever you send a sketch to it.

As a side effect, code is now uploaded twice as fast. Yay! Oh, and the watchdog timer now works correctly: the LED now turns on and off every four seconds :)

I love OSH Park

This evening I ordered a board I designed at OSH Park. A few hours later I received the following E-mail:

Hi!  We had some free room on one of our Super Swift Service panels,
so we took the opportunity to give you an upgrade.

Your affected orders are:
  * xxxXXXXX - xxxxxxxxxxxxxxxxxxxxxx

The Super Swift Service drops your expected fabrication time from 12
calendar days to just 5 business days.  The same fabs manufacture the
Super Swift panels as our normal panels, so you can expect the same
excellent quality.

Only fabrication time is affected, so the shipping times and method will
remain the same.

Thanks for using OSH Park!

*does a little dance* (using super swift service usually costs $89)

Sensor module - shrinking

 After finishing the initial design for the wireless sensor modules I realized the placement of the connectors was far from optimal. Having the sensor connector in the middle of the board would mean I wouldn't be able to attach a socket and stick a sensor right in; I'd rather have the sensor connector on a far end of the board.
I also wanted the nRF module to stack onto the board, but as it turned out, I had placed the connector upside down, so the nRF module would stick out instead of hang over the board. So time for revision 2!

I decided to place the ICSP header on the side of the board, just like the USBASP dongles. A few components have moved to the back of the board, including the 3.3V regulator and pull down resistor for the sensor. All in all the board has shrunk about 20% in length, lowering the cost even further, although adding a shrouded connector offsets that saving... Total component cost is now down to less than $2 excluding the sensor and nRF module.

The outline shows how the nRF module is positioned on top of the board, the extra line indicates where the antenna area starts. I tried to keep the overlap of the board and antenna area to a minimum.

Meanwhile I've started programming some bits and pieces, trying out a few new techniques to keep the memory footprint to an absolute minimum. It's going to be a challenge to fit everything in 1 KiB of ROM (just 512 instructions). Interestingly enough, the code is a mix of assembler and C++ templates.

Concept: off-the-grid sensor module Part 2

Well over a year ago I wrote a bit about off-the-grid sensor modules. TL;DR: combining an ATmega328 with an nRF24L01+ and using low power mode makes battery powered sensor modules very feasible. Adding a small solar panel and a LiPo battery with charger circuit makes it awesome.

At that time it was just an idea that wasn't that high in my things-to-do-list, but in the past few weeks that idea has become more relevant. In our office I've got a bunch of plants. For those interested, we're trying to grow pepper and paprika plants here, which is a big step up from the indestructible spider plants that are infecting the office building :) I've got over a dozen plants, some of which are not in my room, but I'd still like to keep an eye on them. Now I could just walk into the other room, check on the plants daily and say hi to my colleagues while I'm at it, but where's the fun in that?

Instead of some physical and social labor, I'd rather just have a dashboard to monitor the soil humidity of my plants, because that's what any other sane person would want, right? Besides, I have a Raspberry Pi sitting on my desk that's just begging to be used for something useful.

I initially thought about having a single Arduino Uno connected to a bunch of sensors and to the RPi using SPI, but that's going to get messy with all the wires so I got rid of that idea pretty quickly. Instead I'd rather have tiny sensor modules. There's no need to integrate the nRF24L01+ and the sensor in the design; those can be bought separately for way less money than it would cost to integrate them. Instead the module should just have a socket to plug one of those cheap nRF boards in and a connector for a sensor. And we're going to need power of course. Using an ATmega would be overkill for this kind of project. An ATtiny would be a better choice since it's smaller, uses less current and is cheaper, plus I've got a few in my parts bin.

So what do we need?

• connector for a nRF24L01+ module board (2x4 pins)
• 3.3V power supply for the nRF
• connector for an analog sensor (1x3 pins)
• programming interface connector (ICSP, 2x3 pins)

Since the module needs to be as small as possible I would like to use an ATtiny in a soic-8 package, those are about 5x5mm in size and have eight pins. Two of those pins are for VCC and GND, and a third one is used for RESET (required if you ever want to (re)program it. So that leaves 5 pins for other uses. Here's a pin layout of the ATtiny I have lying around:

And here's the pin layout for an nRF module:

That's a lot of pins:

1. GND
2. VCC (3.3V)
3. CE (Chip Enable), needs to be controlled
4. CSN (Chip Select, SPI), needs to be controlled
5. SCK (SPI Clock), needs to be controlled
6. MOSI (SPI Master Out, Slave In), needs to be controlled
7. MISO (SPI Master In, Slave Out), needs to be controlled
8. IRQ, we're not going to use this.

So we're going to need 5 pins just to control the nRF, occupying all the available pins on the mcu. Fortunately, Nerd Ralph has a brilliant solution to this problem, using just a few off-the-shelf components to multiplex the CSN and SCK pins. This frees up one pin on the mcu which we can now use for other purposes. Ralph also uses an LED to drop the voltage from 5V to roughly 3.3V. That's not something I'm going to use since I also want to be able to power the module from a 6V solar panel or a 3.7V LiPo. Instead I'm going to use a LP2985-N voltage regulator. It has a very low dropout voltage of max 300 mV @ 150 mA, meaning it can deliver 3.3Vout with just 3.6Vin. At 50 mA the dropout voltage is even less than half of that, making it suitable for running off a LiPo battery. Other advantages are that it comes in a very small 5 pin SOT-23 package and costs about $0.25. The ATtiny will also be powered by this regulator since it can't handle the 6V a solar panel can deliver.

Another thing Ralph did was tie CE to VCC. However, this means the nRF can no longer transition between RX and TX mode without powering down.

So, fire up KiCad, throw in all components, wire them together and start laying out the board:

Neat eh? That's just 32 by 11 millimeters, or 1.25 by 0.45 inches. So it's even smaller than the nRF board to be plugged in. The IC1 pads and silk screen look a bit weird, that's because it actually are two footprints on top of each other. The ATtiny13A comes in two SOIC packages: a small one and an even smaller one. This board accommodates for both packages.

The ADC pin can be used as a digital or analog input, or you could use it as a digital output (for controlling a relay for example). The ICSP connector allows for changing the firmware (remember to unplug the sensor and nRF in case your programmer uses 5V).
The bare material cost per board is about $2.70, an nRF module costs around $0.80 and a three pin soil hygrometer costs $1.35. So for less than $5 you've got a wireless module to monitor your plant!

It still needs power though, but I'll leave that topic for a future post.