Saturday, August 11, 2012

Graduate school and xbee HOWTO

After many months applying for jobs and trying to figure out what I'm going to do next, Holley and I have both decided to go on to grad school!  I'll be posting about my ventures into the world of electronics design here starting with today. A part of my graduate project is going to deal with wireless communication and mesh networking.

That being said, I picked up a couple xbee modules and USB adapters to play with and get familiar with using them. Being a Linux nerd the majority of my time is spent trying to figure out how to make Windows solutions work in the Linux realm. Yesterday was no exception.

Here we have the xbee 900 pro digimesh something or other. It works on the 900 MHz band and claims a  range of up to 6 miles. Wow. That's way overkill for my needs but that is what was laying around the lab to play with. To my understanding all of the xbee products pretty much work the same with a few minor differences. I'll figure that out later down the road. First task is to get them talking.

I picked up two of the USB carrier boars along with the RF modules just so I could get them talking via USB and not have to worry about programming at first. After doing a little research I knew that getting them to work under Ubuntu wasnt going to be plug and play. The picture to the right shows the inhouse board the department made as well as an evaluation board from both work in Windows using X-CTU at a baud rate of 4800. X-CTU is the software utility that Digi uses to connect to and configure the xbee modules. Getting that up and running is a must if we want to do anything.

There is no Linux alternative to X-CTU so my first thought was WINE. Keep in mine I'm not particularly fond of WINE. It works sometimes and most of the time it doesn't. For this particular situation it does with a great deal of modification. I'm not going to pretend that I knew what to do to make U-CTU work but my googling skills are top notch. The following sites don't necessarily provide the working solution but go a long way to help piece together one that does. 

The problem with the wire.less link is that /dev/ttyUSB* is owned by root. So unless you run WINE as root all the time (dont do that) then you have to change the permissions of the device every time you plug on in. It possible and only requires one command but its a pain to remember all that. This is where the second link comes in. Its possible to set rules for specific devices. When they are plugged in you can mount them with a special name or in a special place or some other more complicated things. These are called udev rules. They reside in /etc/udev/rules.d/ . The hard thing is figuring out how to write these rules so that anytime you plug in an xbee it makes it readable and writable by users other than root.

Lets start with the easy stuff. First you want to install WINE if you don't already have it. The software manager of your distro will have it so go get it.

Nect go download the X-CTU installer from Heres the link that I used.

Open up some terminal and from your home folder

cd /.wine/dosdevices

ln -s /dev/ttyUSB0 com5

ln -s /dev/ttyUSB1 com6

ln -s /dev/ttyUSB2 com7

ln -s /dev/ttyUSB3 com8

Those steps are literally cut and pasted from the wire.less link. What they do is link the COM ports windows normally uses to the /dev/ttyUSB ports we use in Linux. So when X-CTU goes looking for COM5 its directed to /dev/ttyUSB0 which is where it needs to be looking in Linux.

Now go find that .exe installer file we downloaded. Right click on it and set the permissions to executable. Then double click on it and let it install. It should do it automatically if you installed WINE correctly.

That was the easy part. Now we need to make it to where the user can go find and use /dev/ttyUSB whenever one of these devices is plugged in. I'm big on changing permissions as little as possible. Its easy to screw something up or create a security problem you don't even know about so I only want this to change permission when an xbee is plugged in. Otherwise leave it alone.

First thing you need to find an unique id to the ftdi chip that runs the USB converter.. This allows the computer to recognize the specific device the rule is for and not just blanket the rule over every device that's plugged in. I chose to use the vendor ID but you could just as well use the product or serial ID. I actually started with the serial ID but it would require an additional line be added to the rules for each different board. This is the most specific and secure but the least convenient. 

Open up a terminal and

udevadm info -a -p $(udevadm info -q path -n ttyUSB0) | egrep -i "ATTRS{serial}|ATTRS{idVendor}|ATTRS{idProduct}" -m 3

Write the values that come up. My idVendor was 0403. If yours is different youll need to change that in the rule.

So next we want to create the rule file. In the aeturnalus link they names their rule file 10-ftdi.rules. After doing some reading I saw it was recommended to name the rule file with a letter first so it is read last and overrides any previous rule. This makes sense due to the fact that the computer would read files starting with numbers first. So the next line is slightly different that what is seen in the aeturnalus link. 

Open up a terminal and

sudo touch /etc/udev/rules.d/ftdi.rules && sudo chmod 644 /etc/udev/rules.d/ftdi.rules

This is two commands in one line. it creates the file as well as modifies its permission. Next we want to add out rule to the file. Ubuntu uses vim and kubuntu uses kate to do text editing so pick your flavor. Im using kubuntu at the moment so

Open up some terminal and

sudo kate /etc/udev/rules.d/ftdi.rules 

This should open up a graphical text editor with a blank sheet in front of you. Don't panic. We just created this file. There shouldn't be anything in it.

cut and past this line in the file

KERNEL=="ttyUSB?", ATTRS{idVendor}=="0403", SYMLINK+="XBEE", MODE="0666" 

If you idVendor was different you'll need to change that here. 

Finished. Thats it. Now every time you plug into the usb port with a xbee through an ftdi chip it should set the permissions so that X-CTU can read from it. Here's a final shot of my Linux laptop communicating to my windows machine through a pair of xbees.