Posts Tagged ‘RS485’

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

Happy New Year! 2012 is here and I have some new code to celebrate the holiday!

The Dexter Industries dWifi sensor has opened up a whole new world for LEGO MINDSTORMS. For those of you who have looked at the sensor, you will notice it requires that a “newline” character (decimal 13). The dWifi also likes each byte to be sent individually. To cope with these requirements, I have posted a block that does all the work for you. As you can see from the screen capture on the right, there is a simple loop to send each byte (including the newline byte added to your string). The file is posted and is live now on the Files page of my blog. You can use the regular Set Speed and Read VIs that come with the RS485 2.0 download.

Stay tuned for more dWifi LabVIEW and NXT-G updates!

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.

 

In celebration of the release of their new WiFi sensor, Dexter Industries has been blogging and posting example code of how to use it. While the code is written for RobotC, the same commands can be sent with the original RS485 block (or VIs) posted on the Files page. In support of this new sensor, I will be re-posting some of the examples using these blocks! You can head over to Dexter Industries’ blog and read more on this cool new sensor! Then check out some of the projects Xander did over at BotBench! The sensor is now on sale via the Dexter Industries website. I highly recommend this sensor as it fairly easy to use and really expands the MINDSTORMS platform!

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.

So RS485 has been a hit and I am happy to report 0 reported bugs to date. (At least I have not been made aware of any.) The real question is what to do now. Well I have been working on yet another block! This time the sensor isnt out quite yet. As you know Dexter Industries is developing a wifi sensor (pictured here). Xander has already demonstrated its great power with RobotC. I have been working on a block and I am happy to report that I have an alpha build.

In case you are not a software developer, traditionally and alpha build is a “stable” build for the first round of testing. The code is more or less in good style and should be ready to be put to the test. In contrast, a beta is much more final and should be close to, if not completely, working. Following a beta comes a release candidate. A release candidate or RC build could be the final product should no bugs be found.

A development build is generally hacked together and while it does work, it likely has a lot of bugs. As I said I have an alpha build (so higher quality than a dev build with some light testing). If you have a DI Wifi sensor and would be interested in helping test, please email me at edrocket734ATgmailDOTcom. I use dropbox for sharing my code, so you must also have (or be willing to get) a dropbox account. I will provide further instructions via email to those interested.

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!

NXT-G Block Update

Posted: July 15, 2011 in News
Tags: ,

As posted on Mindboards, I have been working on more complete blocks for the NXTBee and RS485. I am happy to report that I have made a lot of progress last night, but have some UI bugs to work through. My goal is to get them posted at a reasonable time tonight (I will write a blog post when they are all up).

In the mean time, if you have found any bugs with the current files posted, please send me an email or post a comment below. I would like to try an update everything in one go tonight!

Happy Friday!

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.