Posts Tagged ‘Dexter Industries’

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!

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!

image

Today is off to a great start here in Fort Wayne. Lots of people and lots of LEGO! I am doing some live demos of the NXShield and DI IMU. Be sure to stop by if you are in the area! Check back later for more pics!

DI IMU: Coming Soon!

Posted: September 11, 2011 in News
Tags: , , , ,

Dexter Industries has new product: the DI IMU. An IMU or Inertial Measurement Unit is a sensor that can measure rotation and acceleration about the x, y, and z axis. This sensors has a ton of applications, from data logging different movements, to balancing a segway. In addition to its awesome uses, the sensor is small, so it can be easily integrated into a robot. While much of the software is still in development, you can see some initial readings on the screen (sorry for the bad picture). Just think if you couple this bad boy with NXTBee, you now have a wireless IMU.

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.

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!

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.