Posts Tagged ‘xBee’

I have gotten several emails over the past few months asking about my RS485 blocks and how to increase the speed or why they cannot get enough information out of the brick in time. Through that email chain I developed some good examples and content which I will share here.

For this example lets assume you are using a Dexter Industries’ NXTBee and a USB xBee receiver. Let’s step through the timing for this at 9600 baud. 9600 baud means we can transfer 9.6 bits per millisecond or just over 1 byte.

Time 0 ms: Write data to RS458 Send in NXT.
Time 1 ms: NXT processes data and prepares to send.
Time 2 ms: NXT sending 1 byte of data. (9600 baud)
Time 3 ms: USB xBee receives data and send to computer.
Time 4 ms: Data arrives on computer.

It took 4 ms to send 1 byte of data. That is slow by any account, but the real issue not not in bus speed. In fact, the NXT RS485 bus was only in use for 1 ms of that entire transfer. We also assume 0 send time for the xBee radios (which is a bit of a stretch). This means receiving a reply from the computer will take 4 ms as well. This issue is called latency. We have a minimum of 4 ms latency per RS485 send. Our throughput for this example is 1 byte and our bus speed is 9600 baud.
Now if we send 4 bytes at 57600 or 5.76 bytes per millisecond we get the following:

Time 0 ms: Write data to RS458 Send in NXT.
Time 1 ms: NXT processes data and prepares to send.
Time 2 ms: NXT sending 4 bytes of data. (57600 baud)
Time 3 ms: USB xBee receives data and send to computer.
Time 4 ms: Data arrives on computer.

Note that the time to get the data is still the same, but we were able to move 4 times a much in the same time chunk. This is why speeding up will improve your throughput. Our latency for this example is still 4 ms per transfer, but our throughput is now 4 bytes on a bus speed of 57600 baud. (And yes, we could have done 5 bytes in there, but I am keeping things in powers of 2.)

Now if we look at this in NXT to NXT communication:

Time 0 ms: Write data to RS458 Send in NXT.
Time 1 ms: NXT processes data and prepares to send.
Time 2 ms: NXT sending 4 bytes of data. (57600 baud)
Time 3 ms: NXT receives 4 bytes of data. (57600 baud)
Time 4 ms: NXT application reads data from RS485 Read.

Now we have a much higher throughput to the NXT via the xBee radios. Mind you if we used a wired connection we have a latency of 3 ms as we do not have that extra receive step. This is why a wired connection has lower latency.

I hope this helps you understand some of the magic of communication protocols. All three factors are important in determining network performance and will vary based on application.

OpenElectrons.com has made an NXT replacement of sorts. Leveraging the power of the Arduino platform, this shield allows the popular prototyping tool to interface with 8 RC servo motors and NXT motors and sensors. The shield has some integrated buttons and operates over I2C. The library for the shield contains both hardware and software I2C implementations, allowing for full support of Mindsensors products at faster speeds.

The video below shows a simple program I wrote. Using the Mindsensors LineLeader and SumoEyes. The robot is constructed out of LEGO parts and uses LEGO MINDSTORMS motors and sensors. There are axle holes to mount the shield and the NXShield is small enough to use with other Arduino shields (think xBee shield or midi shield). Watch the video for more details, but this robot doesn’t even come close to using the full power of the Arduino platform. I have a few more projects in mind with the platform. In addition, I recently ported the library to the Maple. I am still doing some final testing, but if you would like to give it a try, post a comment below!

 

I have updated the examples for the NXTBee on the files page. These updates include timing so the screen shows the correct text and updating it to work with the 2.12 version of the block. If you have any issues with the newest update, please let me know!

Next, I am planning to update a revision to the NXTBee block in the coming week. It will likely be around version 2.20. This update adds a timeout to both sending and receiving. Sending will try 10 times to send and if it does not hear back form the other NXT, it will stop. Receiving will listen for 20 ms before it times out. This should make it so the software is easier to use. If you are interested in testing this, please leave a comment or email me.

GPS Bee

Posted: July 26, 2011 in Engineering, News
Tags: , ,

Everyone has heard of the xBee, but the guys over at Seeed Studio have taken the concept to a new level. Leveraging the 20 pin Bee package used by Digi, this GPS is really easy to use. After some tinkering the GPS was able to find me. Using it with my xBee Arduino shield, I was able to talk to the bee over UART. Since power and data pins match the xBee, most Arduino shields work beautifully. Check out the pic below. I plan to interface it with the Maple and share my libraries. This cheap (45USD) GPS is great for people who are new to using embedded GPS systems.

This is my first purchase from Seeed Studio. The people there were great to work with (shipped me out a second order after the China post office lost the package). They also make a Wifi Bee and Bluetooth Bee. While I am yet to try any of these, it certainly seems like Seeed Studio is innovating and creating cool products. I will be sure to share a library for the Arduino and Maple once I have them polished.

I have officially released completed blocks for both RS485 and the DI NXTBee. They are live now on the Files page! Some things to note with these blocks:

  • NXT-G is slower to execute and the LabVIEW VIs run faster.
  • All blocks have been tested with various inputs for each data type. They “should” work.
  • Due to a physical buffer limit, you can only send integers up to 1 byte (255) and text messages up to 128 bytes (127 characters).
  • Speed ranges may change should I get enough requests but these are the most common UART speeds (NXTBee ones are limited by the NXTBee and will not change).
  • If you have any questions, as always either email me or post below. WordPress requires me to moderate your first comment, but after that you are golden. Regardless, I get an email so I will respond!

Have fun!

I am happy to announce new RS485 LabVIEW VIs and an official NXTBeeNXT-G block. After a few months of work and lots of testing, I am happy to report I have closed out all remaining bugs. The files are available now on the Files page and a new RS485 block (rev B) will be posted later this week as well as new blocks that have support for Boolean and numeric input.

Special thanks to Dexter Industries for providing the NXTBees, everyone who beta tested the blocks, and Mr. John Hansen for all his help! Included in LabVIEW download are sample VIs and there sample NXT-G code posted in the download area.

Remember that slower data speeds (and the NXTBee all together) required John Hansen’s Enhanced Firmware.  The Enhanced Firmware will still let you run NXT-G and LabVIEW code but adds support for these lower speeds. In addition, using RS485 allows you to connect to an NXT running any other firmware (Standard, RobotC, Lejos). Just make sure your speeds match! If you have any questions, email me or post below!

A few months ago Dexter Industries released the NXTBee. So far there has only been support of RobotC. Since then I have been working on making the device work in NXT-G. After a few months of a closed beta, I finally have what I hope is a release candidate (RC). Over the next day or so, check the files page or DI’s website for the download.

The block only supports higher speed settings (over 200 kbs). You will need to run a simple program to set the speed. In addition, the block will only work with the enhanced firmware produced by John Hansen. While the RS485 VIs and block will work with the standard firmware, the NXTBee cannot communicate at the speeds that the standard firmware operates. A copy of the most recent enhanced firmware will be included in the download.

I head out to Kennedy Space Center today to see the launch and help run my shuttle, so it might be a day or two before it posts. Finally I want to extend a huge thank you to everyone in the beta for finding those bugs and for Dexter Industries for sending me the sensors.