Forma completa de indicar el código de error mediante un solo LED

Si todo lo que realmente tiene es un LED, la mejor manera de hacerlo (desde la perspectiva del usuario final) es usar un conjunto de parpadeos contados.

Considere el siguiente esquema, por ejemplo:

• Divida el código de 5 bits en grupos de 2, 2 y 1 bits. (3 bits darían lugar a un grupo de hasta 8 destellos, que está demasiado cerca del límite de lo que un usuario puede contar de manera confiable).
• Agregue 1 al valor de cada grupo, dando como resultado números del 1-4, 1-4 y 1-2 en cada grupo respectivo. (Esto es importante: ¡si alguno de los grupos se muestra como cero, la secuencia resultante será difícil o incluso imposible de leer!)
• Repita la siguiente secuencia:
  1. Enciende y apaga el LED a intervalos de 200 ms para contar el primer grupo.
  2. Espere 500 ms, solo un poco más de lo que tardaría en parpadear una vez más, para dejar en claro que esto es un vacío.
  3. Vuelve a parpadear a intervalos de 200 ms para el segundo grupo.
  4. Espere 500 ms de nuevo.
  5. Vuelva a parpadear a intervalos de 200 ms para el tercer grupo.
  6. Espere 2000 ms antes de volver a iniciar el bucle, para dejar un espacio largo y claro entre cada vez que aparezca el código.

Este es un ejemplo de cómo se vería esto en los parpadeos 4/2/2 (binario 01/11/1). Los usuarios deben poder describir esto de manera bastante confiable como "cuatro flashes, luego dos flashes, luego dos flashes más".

He utilizado un amplificador de bloqueo que destellaba su dirección IP con un solo LED. Destella 1-10 veces para codificar cada dígito decimal, con espacios entre los dígitos y espacios más largos para los grupos. No funcionó muy bien, verlo y escribirlo era bastante propenso a errores. Afortunadamente tienes 5 bits no 32 bits, por lo que debería ser más fácil. Sugerencias:

• Está intentando comunicar 5 bits, no un número de 5 bits, por lo que enviarlo en binario (como ha sugerido) es una buena idea. Si enviara un número del 0 al 32, con 32 significados diferentes, podría considerar decimal u octal o similar.
• Representar bits con destellos largos y cortos puede ser más fácil que uno / dos destellos.
• Cinco bits no son demasiados, por lo que debería ser posible para el usuario recordarlos todos, sin detenerse a mitad de camino para escribirlos. Esto significa que pueden ir más rápido de lo que has sugerido.

Mi solución inicial sería tener cinco destellos, a intervalos de medio segundo, luego una o dos segundos de espera, luego repetir. Esto significa que un 0 estaría representado por 100ms activado, 400ms desactivado y un 1 estaría representado por 400ms activado, 100ms desactivado. Si estuviera usando esa interfaz como cliente, probablemente observaría la luz varias veces mientras murmuraba para mí mismo "largo, largo, corto largo, corto", hasta que estuviera seguro de que tenía el patrón correcto, luego escribí Abajo y búscalo.

Un enfoque mucho mejor para las condiciones de error de señalización en un solo LED es utilizar un concepto de una serie de pulsos largos seguidos de una serie de pulsos cortos. A la secuencia de pulsos le sigue un tiempo de apagado más largo y luego repite la secuencia de pulsos largos y cortos hasta que el usuario comprende el código que se informa y reinicia la unidad.

En mis implementaciones, ya sea en el software MCU o en la lógica FPGA, he encontrado que los siguientes parámetros de tiempo de pulso son óptimos.

PULSO LARGO A TIEMPO = 700 mseg

ESPACIO ENTRE PULSOS LARGOS = 500 mseg

RETRASO DE LARGOS A PULSOS CORTO = 200 mseg (después del último espacio de pulso largo)

PULSO CORTO A TIEMPO = 100 mseg

ESPACIO ENTRE PULSOS CORTOS = 500 mseg

DWELL TIME TO REPEAT = 1900 msec (después del último espacio de pulso corto)

Las instrucciones para el usuario deben indicar que el conteo de pulsos largos se produce antes que los pulsos cortos.

La experiencia con este sistema muestra que el número óptimo de pulsos largos o cortos no debe exceder los cinco pulsos para las condiciones de error más comunes. Eso da un total de 25 posibles informes de errores comunes. Las condiciones de error más probables deben asignarse a combinaciones con el menor número de pulsos.

A menudo agrupo los informes de errores en clases según el número de pulsos largos y el recuento de pulsos cortos es el error dentro de la clase.

Los códigos de error están bien documentados como 11, 12, 13 .... 21, 22 ... 31, 32, 33 etc.

Nunca he encontrado una razón en un producto dado para tener más de aproximadamente 15 códigos de error. En raras ocasiones, cuando se necesitan más de 25, puede recurrir hasta 6 pulsos largos y cortos para obtener hasta 36 códigos.