I am having trouble establishing a connection between the XBee Series 01 and my computer.
I assembled an XBee series 01 module from Adafruit together with an adapter from Adafruit: http://www.adafruit.com/products/128 http://www.adafruit.com/products/126
Using the FTDI cable, I connected it to my computer and established that the green LED was blinking as it should. I disconnected it.
Since I run Linux, I installed Wine on my Ubuntu 11.10 system. Under home/.wine/dosdevices I ran “ln -s /dev/ttyUSB0 COM5”, “ln -s /dev/tty USB1 COM6” to link my serial ports (tty) to Windows’ COM ports.
I hooked up my XBee module and adapter to the computer again.
When I did “grep USB /var/log/syslog”, it showed:
Apr 16 17:35:57 LeNovo kernel: [14071.239717] USB Serial support registered for FTDI USB Serial Device
Apr 16 17:35:57 LeNovo kernel: [14071.240215] ftdi_sio 3-1:1.0: FTDI USB Serial Device converter detected
Apr 16 17:35:57 LeNovo kernel: [14071.243438] usb 3-1: FTDI USB Serial Device converter now attached to ttyUSB0
Apr 16 17:35:57 LeNovo kernel: [14071.243505] ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver
Apr 16 17:35:57 LeNovo modem-manager[611]: (ttyUSB0) opening serial port…
Apr 16 17:36:10 LeNovo modem-manager[611]: (ttyUSB0) closing serial port…
Apr 16 17:36:10 LeNovo modem-manager[611]: (ttyUSB0) serial port closed
Apr 16 17:36:10 LeNovo modem-manager[611]: (ttyUSB0) opening serial port…
Apr 16 17:36:16 LeNovo modem-manager[611]: (ttyUSB0) closing serial port
and it ends with ‘serial port closed’ – that is, it opens and closes it twice.
Using the X-CTU software I added the user port COM5 (corresponding to USB0, see above symlinks) but not surprisingly when I ran ‘test/query’ it was unable to open the COM port (I say ‘not surprisingly’ given the log results above).
I wonder why the serial port will not stay open?
I don’t know if I am on the right track, but after some research I learned that the standard Linux driver for the FTDI chip sets DTR when you open the serial connection. From what I read, the DTR line is normally high in Ubuntu, but normally low in Windows. Following some results in the Ubuntu forum, I used gtkterm to toggle the DTR while I had X-CTU open, but I still was not able to open the COM port.
At this point, suggestions would be appreciated! Thank you.
I run X-CTU under wine, using Fedora 15 and I documented the process in Appendix C of my XBee cookbook (see pinned posts at the top of this forum).
Unfortunately for your case, I did this with a serial development board and have never tried it with a USB board. Still, it might be worth looking there in case you find any hints. In particular, udev-rules (almost a complete mystery to me unless someone gives me a recipe) are often involved in USB situations. Example: I bought a new scanner recently and was tearing my hair out for days trying to get it to work. In the end, a one-line addition in the udev-rules fixed everyhting.
If you do get things working under USB, I for one would like to hear about it so that I can update the cookbook for the benefit of others.
Thanks, johnf. I had looked at your pinned post FAQs but I entirely missed Appendix C of the cookbook. It looks very helpful. I’ll be in touch when (I hate to say “if”) I get things going.
Hello.
I could not get X-CTU under wine to connect with my XBee, but I have a better solution, which is now working. Here it is:
Establishing a serial connection to the XBee series 1 device using linux.
(This procedure eliminates the need to run X-CTU under wine.)
I used Ubuntu 11.10 and the XBee series 1 module, adapter and FTKI cable from Adafruit.
I installed a serial terminal program called minicom from my distro’s repository. You can also use gtkterm.
When I plug in the ftdi cable+adapter/xbee module, it is detected in /dev as ttyUSB0, so I use ttyUSB0 below.
Using minicom, the steps for getting serial communication with the XBee are as follows.
(For the next step you may or may not have to run the command as root. I had to for both minicom and gtkterm.)
Enter this command:
minicom --device /dev/ttyUSB0
You will see the minicom screen. As prompted, hit Ctrl-A and Z to enter setup. (To quit at any point, hit Ctrl-A and Q.)
Hit “o” and to ‘configure minicom’. From the next screen, select ‘serial port setup’.
On the port setup screen, choose ‘E’ to set 9600 8N1
Hit and return to port setup screen. Toggle F to set hardware flow control to off.
Leave port setup and go to ‘modem and dialling setup’. Hit A and remove all the characters from init string; hit B and remove all characters from reset string so those fields are empty.
From configuration menu, select ‘save setup as dfl’.
Finally, return to the main minicom menu (‘Command Summary’).
Hit ‘A’ to add linefeed then return and hit ‘E’ to add local echo. Their actual toggled status is not displayed. Since linefeed and echo are not saved in your default settings, you may have to change these each time you use minicom.
Now you can use the minicom main screen as a serial terminal to send commands to your XBee device. Type ‘+++’ and you should get ‘OK’. The communication only stays open for a second or so. If more time elapses, enter ‘+++’ again to re-open. If you type ‘atid’ then hit enter, it should return your device’s default PAN id. From there you are ready to use AT commands to configure your device on the serial terminal.
Thanks for that post - I’ve added the information to the cookbook (though I haven’t yet republished it). I’ve added it as a new section in Appendix C and I’ve shamelessly copied your own words, with attribution of course. Is that OK with you? I’ve named you as ‘lbrothers’ - let me know if you’d like me to add your real name.
There’s one thing that might be worth looking into, and that’s the control of the USB device that gets created. You found the board at /dev/ttyUSB0 but that would change if you plugged it in after another USB serial device was already connected. Prompted by your experience I’ve beeen looking up the udev rules, and it may not be too hard to simplify the process (setting up a standard name for the device, and setting up permissions so that you don’t have to run as root to access it).
My own USB dev board is busy monitoring the temperature of the domestic hot tank so I can’t easily try this, but I wonder whether you’d be willing to carry out a little experiment?
Plug in the board and verify the port. Assuming it’s /dev/ttyUSB0, give the following command:
udevadm info -a -p /dev/ttyUSB0
That’s supposed to work in Ubuntu; for other distributions it may be
udevinfo -a -p /dev/ttyUSB0
If you post the output that the command generates I’ll see whether I can come up with any ideas.
Finally, and to go back to your original post, I imagine you’d still like to run X-CTU to avoid having to go back to Windows for firmware upgrades. Having re-read the post, your comment that the port didn’t stay open isn’t going to be the problem. The port was opened and closed twice and that’s a Good Thing. If it were left open, X-CTU wouldn’t have been able to open it for itself.
When you added the port COM5 in X-CTU, did you perhaps type COM5 into the port number box? You should only type 5.
Feel free to use my words in the cookbook. You can attribute the words to lbrothers (no other name needed), but I learned the procedure with the help of my buddies at the San Fernando Valley Linux Users Group so they should really get the credit.
I also have been looking into udev rules, since I read your Appendix C.
In my efforts prior to the LUG meeting mentioned above, I discovered http://aeturnalus.com/robotics/mapping-ftdi-to-files-with-udev/
I followed the steps there to make a new rule called 10-ftdi.rules in the rules.d directory. I gave it the devicename “XBEE”.
When my device is plugged in, XBEE shows up in /dev, and so does ttyUSB0. Readouts from /var/log/syslog tell me:
" ‘bus/usb/003/002’ and NAME=‘XBEE’ disagree, please use SYMLINK+= or change the kernel to provide the proper name " I haven’t pursued this.
Just now after reading your post, I plugged in the board and verified the port, but ‘udevadm info -a -p /dev/ttyUSB0’ gave me ‘device path not found’. (I re-typed and checked path multiple times, so I don’t know what the problem is. However, using the steps in the aeturnalus site, I was able to carry out udevadm commands so maybe there is a slight syntax issue. Afraid I am not being much help here.)
Yes, about the port closing, I do now realize it was doing just what it was supposed to do.
And I did try plain ‘5’ as well as COM5 for the X-CTU entry once I read your Appendix. But without effect.
I believe you are correct that it is just a question of setting up permissions so I don’t have to run as root to open the port with the terminal. We did play with permissions some at the meeting and this deserves another look.
I’m thinking now that the permissions issue is probably why you didn’t have success with X-CTU under wine, assuming you were running X-CTU as a normal user.
If you do this sequence of actions:
Plug in the board.
Check the port.
ls -l /dev/ttyUSBwhatever
I’ll bet the permissions part will be -rw-rw---- and the owner/group part will be either “root root” or maybe something like “root uucp”. If so:
as root, chmod 666 /dev/ttyUSB0
try X-CTU again.
If that works, the solution in both your cases is likely to be:
If the group is anything other than root, add yourself to that group. Or,
Set the permissions you want with udev-rules. Or,
Resign yourself to setting the permission manually every time you plug in the board.
And re the cookbook, I’ve added a credit to the user group. And btw, thanks for the kind comment on the book! I’m holding back from republishing for now, in the hope of being able to confirm the permissions thing.
I plugged in the board and checked ls -la for /dev:
crw------- 1 root root 188, 0 2012-05-14 21:04 ttyUSB0
As root:
chmod 666 /dev/ttyUSB0
Repeating ls -la for /dev:
crw-rw-rw- 1 root root 188, 0 2012-05-14 21:04 ttyUSB0
I was still unable to get X-CTU to access COM5.
So I changed the owner to myself and the group to dialout.
chown leslie:dialout /dev/ttyUSB0
which gave me:
crw-rw-rw- 1 leslie dialout 188, 0 2012-05-14 21:04 /dev/ttyUSB0
I still could not use X-CTU. I tried to see if I could now access the port using the minicom terminal as regular user, but I still had to be root.
Perhaps there is something about groups and permissions I am not understanding here. At least I have the serial terminal to access my XBee although I don’t have X-CTU.
I look forward to studying the link on udev rules you posted, thanks for that.
Looks as though the new permissions didn’t really take effect. I’ll leave you to look into udev rules - I think that’s going to be the answer.
for what it’s worth, and I haven’t tried this, a rule such as
SUBSYSTEM==“usb”, ATTRS{idVendor}==“xxxx”, ATTRS{idProduct}==“yyyy”, MODE=“0666”, GROUP=“xbee”, SYMLINK+=“/dev/xbee”
is what I’d expect. Replace xxxx and yyyy with the vendor and product ids for the board.
Oh, and note the difference between == and = in the rule.
