Posts Tagged ‘NXTBee’

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.

Advertisements

Joey over at Techn’xt posted a new video. This special video features an interview with me. Joey is a great friend and has an excellent blog. Check it out! I have reposted the video below.

 

RS485 NXT-G Block Beta

Posted: November 4, 2011 in LEGO, News
Tags: , , , ,

For those of you who have been waiting for an update for the NXT-G RS485 block, today is your day! I have posted a new download for a beta of the upcoming block (currently version 2.28) on the Files page of my blog. The big advantage is the implementation of a timeout for sending and receiving data. Basically the block will try to receive data 10 times (total of 10 ms) before moving on. It will also have a max timeout of 100 ms. I suspect the block will change a bit over the next 24 hours as comments come in, so watch for updates and a new version change. (I have several known bugs already.) I wanted to get this out there so people can play with it and let me know! Give it a try and leave your comments 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.

NXTBee Blocks Updated

Posted: August 24, 2011 in LEGO, News
Tags: ,

There have been a few minor bugs found with the NTBee block. I have corrected these and they are live on Files page. Note the version has changed on the blocks. The current version is 2.12. If you are running an older version I suggest you update. This update addresses an issue with setting the type of data you intend to send or receive. Thank you Alan for finding these! If anyone else finds something not quite right with the block, please let me know!

Also, there has been some confusion on how the read works. It will wait until it receives a message. You must start to read before you send, otherwise the message may be lost.

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.