Computing stuff tied to the physical world

Serial hookup JeeNode to Raspberry Pi

In Hardware on Sep 20, 2012 at 00:01

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

Screen Shot 2012 09 16 at 17 26 45

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:

  1. edit the file /etc/inittab as root (I used “sudo vi /etc/inittab”)
  2. change this line: T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100 to #T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100. I.e. comment it out, and save these changes.
  3. 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:

DSC 4143

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:

DSC 4144

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:

Screen Shot 2012 09 16 at 17 17 17

Easy! (once you know how to overcome all the software and hardware hurdles, that is…)

Update – additional contributed notes.

  1. @JCW, are you considering moving to the PI as your collection platform? If so, what software are you using to to collect the monitoring data?

    • No change of plans, really. I’ve always intended for some Linux board to become the central home monitor / controller, and decided a few months back to base the infrastructure on ZeroMQ. That means there’s no platform-dependence so far.

      Been exploring a couple of storage options, from plain replayable-logfile format, to my own Metakit database, to a simple set of round-robin data files I implemented earlier this year. Even the choice of storage engine is really not too important when the main infrastructure is based on “plumbing” and “protocol”, with messaging and RPC as glue mechanism.

      But to get back to your question: the RPi is not necessarily the best fit for a server – it’s half the speed of a Sheevaplug, has half the RAM, and its video may not be needed. Then again, its price is excellent.

  2. I remember that this was one of the first things I did when I got my rPi. I also added a wire from a GPIO to function as a DTR line. With a little bash script I could upload new code to the node too!

  3. This may help you: Since the Gertboard will have an Atmega on it, the above link describes how to modify the Arduino environment to program the Gertboard using the Raspberry Pi.

    • Thank you – very nice info, but that’s for SPI-programming, whereas I’m currently looking for a way to use the uploader over serial. I can toggle a GPIO and cause a reset, but it’s done before starting the (unmodified) avrdude, and that seems to cause too much delay.

  4. Another possibly relevant point about choice of platform for logging data is the video out. There’s only a practical (as opposed to hobbiest) point in having all this environmental data if the home user is aware of it – and hopefully acts on it. A £60 small HDMI monitor in the hallway (or fed to the family TV) with the data visualised in a funky way could make all the difference, for no extra money spent!

  5. I would have thought the R-Pi has more than enough power for a home monitoring system, after all people are using it for streaming HD video. Supposedly, there will be the R-Pi ‘Model A’ released Real Soon Now with no ethernet and 1 USB, but only $25. Add a $5 USB-Wifi or USB-Wired-LAN adaptor and it could serve the same purpose at lower cost (assuming those cheap ebay parts actually work…)

  6. not doubting its HA usefullness, but the reason you can stream / decode HD is that the video decode is done in dedicated hardware, bot the CPU. The little CPU does struggle on more conventional tasks like maths / web browsing etc. Possibly still enough for non high speed use – pass the realtime stuff (like radio TX/ RX) back to the little 8bit 8Mhz Jeenode to do properly

  7. Fair enough, but my Jeenodes run at 16 MHz :-)

  8. I basically used the approach you used in the nest post, and was running as root. I also didn’t write any code since it was on the python shell.

    I used adafruit’s GPIO python module to toggle a pin and directly after that I called a python[“avrdude”,”args”]).

    This worked about 1 in 4 times, so there are still lots of timing issues and it was just an experiment for me.

  9. Works perfect here! I attached my RF12 receiving JeeNode to the RasPi and just had to change my perl program to read the data from a different device. Now I will think about showing the information on the TV instead of only sending it to for visualisation! @jcw: thanks for your work!

Comments are closed.