One way to connect an RFM12B to a Raspberry Pi is to simply plug in a JeeLink, using the built-in USB capabilities of the RPi. But that’s a bit of a detour – why go through USB?
Since the JeeNode’s FTDI connector can use 5V power and has TX/RX pins at 3.3V logic level, it’s actually a perfect match for directly connecting to a Raspberry Pi. Let’s do it.
I’ll be using the command shell on the RPi, using a network SSH connection, but this could also be done from the console with a keyboard, of course.
There are a couple of hurdles we’ll need to overcome. First one is to figure out which pins to use on the RPi’s 26-pin I/O connector. I found a good schematic on elinux.org:
We’re going to use 4 pins: 5V, Ground, TXD, and RXD. But first, let’s figure out how to reach those pins in Linux. I found out that the serial port we need is “ttyAMA0”:
$ ls -l /dev/ttyAMA0 crw-rw—- 1 root tty 204, 64 Sep 16 17:13 /dev/ttyAMA0 $
That port is only accessible by users in access group “tty” (and root). So first, let’s make sure user “pi” can access it, by adding ourselves to that group:
sudo usermod -a -G tty pi
Now logout and log back in to make these changes take effect.
> Note: not all RPi Linux distro’s are set up in the same way. If ttyAMA0’s group is “dialout” instead of “tty”, chances are that you’re already a member (type “id” to find out). In that case, skip the above usermod command.
But that’s not all. By default, there’s a “getty” process running on this serial port:
$ ps ax | grep getty 2126 tty1 Ss+ 0:00 /sbin/getty –noclear 38400 tty1 2127 tty2 Ss+ 0:00 /sbin/getty 38400 tty2 2128 tty3 Ss+ 0:00 /sbin/getty 38400 tty3 2129 tty4 Ss+ 0:00 /sbin/getty 38400 tty4 2130 tty5 Ss+ 0:00 /sbin/getty 38400 tty5 2131 tty6 Ss+ 0:00 /sbin/getty 38400 tty6 2132 ? Ss+ 0:00 /sbin/getty -L ttyAMA0 115200 vt100 2292 pts/0 S+ 0:00 grep getty $
This lets you connect to the serial port and login. Very convenient, but in this case we don’t want to log in, we want to take over control of this serial port for talking to the JeeNode. So we have to disable getty on ttyAMA0:
- edit the file /etc/inittab as root (I used “sudo vi /etc/inittab”)
- change this line:
T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100to
#T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100. I.e. comment it out, and save these changes.
- run the command “sudo kill -1 1” to pick up these inittab changes
And that’s it. There is no longer a process trying to respond to our serial port.
> Note: again, this may not be needed if you don’t see “ttyAMA0” listed in the ps output.
You also have to make sure that the kernel doesn’t log its console output to this serial port. Look in the file “/boot/cmdline.txt” and remove the text
console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 if present. Then reboot.
Now we’re ready for a quick loopback test:
Connect a single jumper as indicated (a little jumper block would also work), connecting RXD with TXD. This means that everything sent out serially will be sent back and received serially as well. A very convenient test that we’ve got all the Linux stuff set up properly.
Oh, wait – first let’s get the utility installed which lets us type to the serial port:
sudo apt-get install screen
Now we can test the serial port, at last:
$ screen /dev/ttyAMA0 57600 …
You should see a blank screen, and whatever you type in should show up on the screen. If this is indeed the case, then there is data going out and back into the serial port. To really make sure, disconnect the jumper and the echoing will stop. Excellent. Almost there.
Screen is a very convenient utility, but you need to remember how to get back out of it. The key sequence is CTRL+A followed by “\” (the backslash key).
For now, you can leave it running, or start it up again later. The last step is to hook up the JeeNode. This requires 4 wires:
Note carefully the order of these female-to-female jumper wires, top to bottom:
- on the RPi: green, white, black, gap, blue
- on the JeeNode: gap, green, white, blue, gap, black
I used a JeeNode, pre-loaded with the standard RFM12B sketch, and set to receive packets from my main home monitoring setup here at JeeLabs. I also enabled “collect mode (“1c”) so that it wouldn’t try to acknowledge packets, just lurking and reporting what comes in. And sure enough, it works:
Easy! (once you know how to overcome all the software and hardware hurdles, that is…)
Update – additional