Paso 2: Software
Ahora para algunos programas.
A continuación se muestran un par de parcelas LSA (analizador de estado lógico) que muestran la comunicación entre los sensores y el módulo UPA.
El plan es entender estas parcelas a un punto donde puedo tener el mbed para reproducen. Si el mbed para podría crear los trenes de pulso entonces tal vez el sensor podría ser convencido para funcionar normalmente.
Echa un vistazo en la trama de osciloscopio a continuación. Es bueno me bajé mi duffs y hasta mi alcance. El alcance hace posible distinguir entre el micro y el sensor en términos de que está hablando activamente sobre el autobús. La trama de ámbito muestra un comando ping envío y respuesta inmediata del sensor. La distinción puede hacer basada en el nivel de voltaje en un nivel bajo en el bus. La UPA tira el autobús a un nivel de tensión inferior que hace el sensor. Bien, ese descubrimiento que vino práctico!
Desarrollar el código fuente de mbed para se convirtió en un mater de reproducir lentamente el tren de pulsos que capturé con la LSA.
Justo después de encender, parece que la UPA envía un montón de datos de los sensores. Los dos sensores montados en el medio de la fascia un conjunto de datos y los dos fuera de sensores diferentes. Supongo que los sensores de dos centro son configurados con un mayor valor de la ganancia que los dos sensores de exterior. También es probable que estos valores son diferentes entre plataformas de diferentes vehículos. No importa, has capturado ambos conjuntos y se pueden reproducir ya sea uno con el mbed para.
Después de la inicialización que los pulsos son otro par de pulsos. ¿Tal vez un par de comandos de reset? No estoy seguro. Otra vez, tengo código de fuente para el mbed para que puede reproducirlos.
Por último, el módulo UPA entra en modo de escaneo de sensor activo. Este modo de exploración consiste en ping y escuchando los sensores en forma de Liguilla. Tenga en cuenta que un sensor se puede manda a ping, o sólo escuchar. Por lo tanto, otro truco. En el mismo instante en el tiempo, la UPA tiene un sensor a ping mientras al mando de un sensor (o dos) para escuchar. Si un objeto está justo delante del sensor que genera el ping entonces ese sensor probablemente no escucha el eco de retorno. Esto se conoce como el problema del anillo de abajo. Cuando un sensor genera un ping hay un intervalo de tiempo antes de pueda recibir cualquier ecos detrás. Eco de regreso de un objeto cercano se pierde probablemente en este tiempo de permanencia. Un sensor de sólo escuchar no tiene un anillo de tiempo muerto. Por lo tanto, la energía ultrasónica se produce en un sensor (el sensor ping), la energía rebota en un objeto cercano y regresa a un sensor diferente. ¿¡ Cool EH?
Permítanme reafirmar el problema del anillo-abajo porque mi descripción anterior era probablemente confuso. Un sensor puede actuar como un altavoz ultrasónico, o, como un micrófono ultrasónico. Conmutación entre el modo de altavoz a modo de micrófono toma un poco de tiempo porque la cara del sensor sigue vibrando por un corto tiempo después de que el elemento piezoeléctrico se detiene. El tiempo de permanencia entre el modo se llama anillo de abajo y todos los sensores elemento tienen este problema. Anillo-abajo dicta cuán cerca que puede detectarse un objeto. Para estos sensores es de unos 16cm.
Con el hardware y el software en su lugar los sensores ahora pueden controlarse sin mayor problema. El adjunto código de mbed para inicializa los sensores y luego comienza activamente los tintineos.
El mbed para código puede modificarse fácilmente para demandar a otras aplicaciones. El objetivo era simplemente proporcionar una base de código que puede ser adaptado a otros usos.
Actualización: Después de un poco de las pruebas, he descubierto que el sensor responderá a comandos ping incluso si los datos de inicialización no se enviaron al sensor en el encendido. El sensor debe almacenar los datos de calibración en flash o EEPROM. El módulo UPA producción vuelve a enviar los datos en cada ciclo de potencia sólo para la buena medida.
