8
\$\begingroup\$

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).

enter image description here

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??

\$\endgroup\$
  • \$\begingroup\$ So the polling is always happening from a computer running OSX or Windows 7? The delay on USB can be pretty large regardless of the programming language you use. \$\endgroup\$ – Kellenjb Mar 20 '12 at 19:53
  • \$\begingroup\$ right now we are testing on Windows 7 and on OSX. in the end it will run on Windows 7. \$\endgroup\$ – evsc Mar 20 '12 at 19:56
  • 2
    \$\begingroup\$ Instead of editing your question, you can answer your own question. This will let you select it as the answer and even get upvotes! \$\endgroup\$ – Kellenjb Mar 20 '12 at 20:37
  • \$\begingroup\$ in 7 hours i will! :) <.... Users with less than 100 reputation can't answer their own question for 8 hours after asking. You may self-answer in 7 hours. Until then please use comments, or edit your question instead.> \$\endgroup\$ – evsc Mar 20 '12 at 20:42
5
\$\begingroup\$

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.

\$\endgroup\$
2
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ yes! just figured out that i can change a bunch of stuff in the USB-Serial-port settings (especially the latency timer) and then everything speeds up ... \$\endgroup\$ – evsc Mar 20 '12 at 20:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.