next topic »

[on:]

So in doing lots of forum/net research little bits pop up here and there but I've not seen a thread that talks about all these things together.

I'm talking about XBee to XBee (series 1), point-to-point, serial cable replacement, sending small packets (20-30bytes of sensor data), as fast as possible with as little latency as possible.

It seems like having the max baud rate of 115200 would be ideal but as seen in this other thread (http://arduino.cc/forum/index.php/topic,74285.0.html) that can overrun the buffer very quickly. Even at 57600 I'm getting some overflow using a serial call-response setup (not ideal either).

I also recently found out about the driver settings for the FTDI chip, and that there are latency and buffer size settings to tweak there. (http://www.ftdichip.com/Support/Documents/TechnicalNotes/TN_105%20Adding%20Support%20for%20New%20FTDI%20Devices%20to%20Mac%20Driver.pdf)
I opened up my .plist file but couldn't figure out which device was my USB explorer (there must be over 100 entries in there). (Sub-question, how do I find out a plugged in device's ftdi <key>?)

There are then the XBee settings themselves. I've read some bits here and there about other settings that can be changed to improve latency and reduce dropouts. I can't find the thread at the moment but I remember it mentioning 'MAC Mode', 'API Mode', and 'Packetization Timeout'.

I also read a (couple) of threads/pages dealing with the serial latency of different Arduino devices (with the Teensy being the fastest, by far).
http://neophob.com/2011/04/serial-latency-teensy-vs-arduino/

I'm using a USB Explorer at the moment, but at some point I plan on changing to a Mega since I have two sets of XBees and want to use the hardware serial ports to merge the data into a single USB stream. So minimizing hardware latency is also a plus.

I also read some talk about USB packet size and polling speed and how it can be beneficial to force packets to send after a certain size to get things over there as quickly as possible.


So.

In order to get the fastest possible connection, with minimal latency/dropouts (of a simple point-to-point system).

Do you need to mess with the FTDI settings?
Any additional XBee settings? (other than ID/DL/MY/baud)
Any device specific adjustments? (uno vs teensy)
Force packets of a certain size to play nice with USB?

[Reply #1 on:]

I also read a (couple) of threads/pages dealing with the serial latency of different Arduino devices (with the Teensy being the fastest, by far).

That does not measure the latency of the Arduino but of the used USB2Serial combination. I'd guess that you get the same results as the Teensy with an Arduino Leonardo and the same results as with the UNO with a Mega2560. The Teensy/Leonardo is the fastest because there is no serial communication at all but it's sending the USB packets directly. That's one side of the story, the other is the used driver on the PC side. You probably get different results if the measures are made on a Windows or Linux machine.

Any device specific adjustments? (uno vs teensy)

Use a Leonardo (or Teensy) if you wanna change the USB stuff. This way you can optimise the latency for your specific needs (you have to tweek the hardware libraries though).

[Reply #2 on:]

Those devices don't use the FTDI chip then?

Would the same be the case for the new Mega ADK? Or is there a Mega-based one that sends USB packets directly?

And by tweaking the hardware libraries you mean the chips themselves, and not the Arduino code?

[Reply #3 on:]

Those devices don't use the FTDI chip then?

The UNO doesn't do that either. It's using a ATmega16U2 for this, that's why it has more latency than the Diecimilla but it's more flexible in what it's able to do with the USB interface.

The Mega2560 and the Mega2560 ADK both use the same chip (ATmega16U2) for the USB2Serial conversion and share the latency of the UNO. I'm not aware of a Mega-based board that does USB directly. A Teensy++ 2.0 is probably the board that get closest to what your expecting.

And by tweaking the hardware libraries you mean the chips themselves, and not the Arduino code?

No, I mean the libraries in the hardware directory of the IDE.

[Reply #4 on:]

I didn't realize the teensy did something different than that ATmega16U2 thing.

I suppose when it comes down to it I can have two teensy's plugged into a mini USB hub or something, if I want to get down and gritty with hardware latency.

For the moment I'm still trying to improve the reliability of just 57600 call-response over a USB explorer.

[Reply #5 on:]

I suppose when it comes down to it I can have two teensy's plugged into a mini USB hub or something, if I want to get down and gritty with hardware latency.

Take care, a USB hub is also adding latency, although much less than using different USB2Serial chips as mentioned previously.

I didn't realize the teensy did something different than that ATmega16U2 thing.

In fact the teensy is doing almost the same as the ATmega16U2 but on the Teensy the ATmega32U4 is the main CPU running the sketches while the ATmega16U2 on an UNO or MEGA2560 is just responsible for the USB2Serial conversion communicating with the main CPU (ATmega328p or ATmega2560) by a UART interface. The latency comes from the necessary conversion which always need some buffers and filling the buffers consumes some time.

[Reply #6 on:]

That makes more sense now. It's because it's all on the chip so it doesn't need to buffer over to the conversion chip and then buffer out again (or something like that).

Now that I found the device in the ftdi .plist I'm gonna mess with those numbers a bit to see if I can stop buffer overflow, and then build from there (thanks for the help in the other thread).

[Reply #7 on:]

To help you a bit further in your investigation: how do you define latency on the serial interface? Is it from the sending of the first character to receiving the first character on the other side or do you send a bunch of characters and latency is defined from sending the first character to reception the last one on the other side?

On the programmable interfaces (ATmega16U2 or ATmega32U4, so everything except the FTDI stuff) you can influence how many bytes you buffer before sending a USB packet. This number as well as the timeout when you send an even uncompleted packet out is related to the latency remarkably.

You have a buffer overflow? Where? On the PC side?

[Reply #8 on:]

At the moment I'm doing call-reponse so I'm measuring (more like "talking about") latency in the time between receiving two sensor bytes on the computer side. In the end game I don't want to use call-response at all so all my communication will one way, so latency will be the time between sending a byte and receiving a byte on the computer.

Can' you change the buffer size and latency in the FTDI driver? (That's what I've been trying to do, not put the new lines in yet).

The buffer overflow I was having (and suspect I'm still getting) is in the hardware. If I plugged in and ran the serial over USB directly there were no problems at all, it was only when the XBee was in the mix that it would overflow. I suspect that it's on the receiving XBee/USBExplorer side of things (hence all this research/testing).

[Reply #9 on:]

Ok pulling my hair out a little bit here.

I finally was able t get to editing the FTDI driver .plist as mentioned in the pdf linked above and it seems like any edit I make to the file at all greets me with the following error message:



Once I get that error I can reboot all I want and the USB explorer isn't recognized. (Actually it shows up in the system profiler but not as an available serial port in Max/MSP). I have to manually delete the .kext file from my System/Library/Extensions folder and reinstall the driver for it to show up again.

This is the entry as it originally comes:

Code:

<key>FTDI R Chip</key>
<dict>
<key>CFBundleIdentifier</key>
<string>com.FTDI.driver.FTDIUSBSerialDriver</string>
<key>ConfigData</key>
<key>IOClass</key>
<string>FTDIUSBSerialDriver</string>
<key>IOProviderClass</key>
<string>IOUSBInterface</string>
<key>bConfigurationValue</key>
<integer>1</integer>
<key>bInterfaceNumber</key>
<integer>0</integer>
<key>bcdDevice</key>
<integer>1536</integer>
<key>idProduct</key>
<integer>24577</integer>
<key>idVendor</key>
<integer>1027</integer>
</dict>

And this is what I'm trying to change it to:

Code:

<key>FTDI R Chip</key>
<dict>
<key>CFBundleIdentifier</key>
<string>com.FTDI.driver.FTDIUSBSerialDriver</string>
<key>ConfigData</key>
<dict>
<key>LatencyTimer</key>
<integer>4</integer>
<key>InBufferSize</key>
<integer>256</integer>
</dict>
<key>IOClass</key>
<string>FTDIUSBSerialDriver</string>
<key>IOProviderClass</key>
<string>IOUSBInterface</string>
<key>bConfigurationValue</key>
<integer>1</integer>
<key>bInterfaceNumber</key>
<integer>0</integer>
<key>bcdDevice</key>
<integer>1536</integer>
<key>idProduct</key>
<integer>24577</integer>
<key>idVendor</key>
<integer>1027</integer>
</dict>

I was unsure about the formatting for the XML since in the pdf it's a big ambiguous saying the following:

3.4 Latency Timer
Latency Timer helps to speed up the transfer of short packets. Changing the device's latency timer is supported through the LatencyTimer key under ConfigData, an optional field in a device entry. For example, the following entry from the info.plist file would allow the device to operate with a latency timer of 8ms.
<key>ConfigData</key> <dict>
<key>LatencyTimer</key>
<integer>8</integer>
</dict>
The latency timer value is a decimal integer in the range 1-255. Its default value is 16ms.
3.5 Read Buffer Size
Read Buffer Size can increase or decrease the speed of the transfer of packets, depending on type of the data you are transferring.
Changing the device's read buffer size is supported through the InBufferSize key under ConfigData, an optional field in a device entry. In the following example from the info.plist file, the read buffer size is set to 256 bytes.
<key>ConfigData</key> <dict>
<key>InBufferSize</key>
<integer>256</integer>
</dict>

So I wasn't sure if I needed a new <dict></dict> pair for each key/integers, but elsewhere in the .plist is the following entry:

Code:

<key>MEDSET USB</key>
<dict>
<key>CFBundleIdentifier</key>
<string>com.FTDI.driver.FTDIUSBSerialDriver</string>
<key>ConfigData</key>
<dict>
<key>InBufferSize</key>
<integer>128</integer>
<key>LatencyTimer</key>
<integer>24</integer>
</dict>
<key>IOClass</key>
<string>FTDIUSBSerialDriver</string>
<key>IOProviderClass</key>
<string>IOUSBInterface</string>
<key>bConfigurationValue</key>
<integer>1</integer>
<key>bInterfaceNumber</key>
<integer>0</integer>
<key>idProduct</key>
<integer>62705</integer>
<key>idVendor</key>
<integer>1027</integer>
</dict>

Which follows the same format of what I put in.

[Reply #10 on:]

It should also be noted that I copied/moved the .kext file manually, instead of using the terminal commands suggested in the pdf above. (I did try the terminal commands but it gave me a 'could not find directory' when referring to where the original .kext file was).