Sondeo del sensor a través de la interfaz serie USB-RS485 atascado en 16 ms, aunque debería ser más rápido

Tengo una configuración, conectando una placa de sensor Razor IMU , con una placa RS-485 Breakout , a una interfaz serial USB-RS485 a través de un cable USB en mi computadora portátil. Ejecuto un software en la computadora portátil (Max/MSP) que envía mensajes de sondeo al sensor, espera los datos de respuesta y, al recibir la respuesta, activa automáticamente un nuevo mensaje de sondeo. Es un bucle constante:

  1. enviar un mensaje de encuesta
  2. esperar una respuesta
  3. en la respuesta ir a 1.

Quiero que este sondeo sea lo más rápido posible, ya que tendré que conectar 21 de estos sensores al mismo bus RS485. El firmware de Razor está programado con el IDE de Arduino y, según el código, solo debe haber un retraso de ~2 ms entre el mensaje de sondeo y la escritura de la respuesta. El firmware también gasta 12 ms cada 20 ms en la asignación y el cálculo del sensor. Este cálculo a veces retrasa la respuesta al sondeo. Soy consciente de eso y todos los resultados son en consecuencia.

Mi problema en este momento es que el sondeo del sensor está atascado en una tasa de actualización promedio de 15 milisegundos. Miré los datos con mi pequeño oscilosope usb e hice un diagrama (> PDF).

ingrese la descripción de la imagen aquí

Mi osciloscopio se encuentra directamente en la interfaz USB-RS485 y ve que se apaga el sondeo y entra el mensaje de respuesta. El retraso entre estos dos se encuentra entre 2 y 13 ms. Esta diferencia se explica por el hecho de que a veces la maquinilla de afeitar está ocupada haciendo los cálculos matemáticos del sensor. El hecho extraño es que, aunque las respuestas llegan con diferentes retrasos, el sondeo siempre parece salir en el mismo intervalo de unos 15 ms.

También implementamos la misma configuración con

  • codificando el firmware en C y programando la Razor con avr-dude
  • haciendo el sondeo de software en código Python
  • en Mac OSX y PC con Windows 7

Todas las combinaciones posibles dieron como resultado el mismo intervalo de 15 ms. Entonces, el problema no está ni en el código Arduino, ni dentro de Max/MSP. Tengo la sospecha de que el problema puede deberse a la Interfaz Serial USB-RS485 y/o al controlador FTDI necesario.

¿Este problema le suena familiar a alguien?

Entonces, ¿el sondeo siempre se realiza desde una computadora con OSX o Windows 7? El retraso en USB puede ser bastante grande, independientemente del lenguaje de programación que utilice.
ahora mismo estamos probando en Windows 7 y en OSX. al final se ejecutará en Windows 7.
En lugar de editar su pregunta, puede responder su propia pregunta. ¡Esto le permitirá seleccionarlo como la respuesta e incluso obtener votos a favor!
en 7 horas lo hare! :) <.... Los usuarios con menos de 100 de reputación no pueden responder a su propia pregunta durante 8 horas después de preguntar. Puede auto-responder en 7 horas. Hasta entonces, utilice los comentarios o edite su pregunta en su lugar.>

Respuestas (2)

Se debe al temporizador de latencia de 16 ms del controlador FTDI y al hecho de que mis respuestas de sondeo no fueron lo suficientemente largas para llenar el búfer de 64 bytes para activar automáticamente el vaciado del búfer. Lea AN232B-04_DataLatencyFlow.pdf si está interesado, o simplemente vaya a su Administrador de dispositivos y cambie la configuración en las propiedades de su puerto serie USB.

Sin saber muchos detalles (que realmente no quiero saber), culparía al adaptador USB a RS-485. Tuvimos un problema similar en un procesador Intel Q7 que ejecutaba Linux con uno de esos adaptadores.

Estuvimos usando el adaptador temporalmente hasta que nuestro hardware personalizado estuvo listo. Nuestro hardware personalizado usa un enlace PCIe y un FPGA para hacer la misma interfaz RS-485 (y mucho más). El software siguió siendo el mismo para el adaptador y nuestro hardware personalizado. Cuando cambiamos al hardware personalizado, el problema desapareció.

¡si! acabo de darme cuenta de que puedo cambiar un montón de cosas en la configuración del puerto serie USB (especialmente el temporizador de latencia) y luego todo se acelera...