Sensor Polling via USB-RS485 Serial Interface stuck at 16ms, even though it should be faster

Question

I have a setup, connecting a Razor IMU sensor board, with a RS-485 Breakout board, to a USB-RS485 Serial Interface via USB-cable into my laptop. I run a software on the laptop (Max/MSP) that sends out polling messages to the sensor, waits for the response data, and on receiving the response triggers automatically a new polling message. It's a constant loop:

1. send out a polling message
2. wait for a response
3. on response go to 1.

I want this polling to be as fast as possible, as i'll have to hook up 21 of these sensors to the same RS485-bus. The firmware on the Razor is programmed with the Arduino IDE, and according to the code there should only be a ~2ms delay between the polling message and the writing of the response. The firmware also spends 12ms every 20ms on sensor-allocation-and-calculation. This calculation sometimes delays the response to the polling. I am aware of that and all results are accordingly.

My problem right now is that the polling of the sensor is stuck at an update-rate of average 15 milliseconds. I looked at the data with my small usb-oscillosope and made a diagram (>PDF).

My oscilloscope sits directly on the USB-RS485-interface and sees the polling go out, and the response message come in. The delay between these two lies between 2 to 13 ms. This difference is explainable with the fact that sometimes the razor is busy doing its sensor-math-calculations. The weird fact is, that even though the responses come in with different delays, the polling always seems to go out at the same interval of about 15ms.

We also implemented the same setup with

• coding the firmware in C and programming the Razor with avr-dude
• doing the software-polling in Python code
• on Mac OSX and PC Windows 7

All possible combinations resulted in the same 15ms interval. So the problem is neither in the Arduino-code, nor within Max/MSP. I have the suspicion that the problem could be due to the USB-RS485 Serial Interface and/or the necessary FTDI driver.

Does this problem sound familiar to anyone??

Answer 1

It's due to the 16ms latency timer of the FTDI driver, and the fact that my polling responses were not long enough to fill the 64-byte buffer to automatically trigger the buffer emptying. Read AN232B-04_DataLatencyFlow.pdf if you are interested, or simply go to your Device Manager, and change the settings in your USB-Serial-Port properties.

Answer 2

Without knowing lots of details (which I don't really want to know), I would blame the USB to RS-485 adapter. We had a similar issue on an Intel Q7 processor running Linux with one of those adapters.

We were using the adapter temporarily until our custom hardware was ready. Our custom hardware use a PCIe link and an FPGA to do the same RS-485 interface (and a lot more). The software remained the same for the adapter and our custom hardware. When we switched to the custom hardware the problem went away.