Paramètres de clignotement des LED pour laisser clignoter au mieux un compte humain?
Je dois indiquer un code d'erreur avec une LED. C'est dans le cas où nous avons une très mauvaise erreur dans notre système embarqué où nous ne pouvons pas utiliser de manière fiable des interfaces graphiques de niveau supérieur pour indiquer un problème - je dois me rabattre sur le clignotement d'une LED.
Ce qui m'étonne, c'est la lenteur avec laquelle je dois le flasher, compter le nombre de flashs. Je teste avec 4 flashs (le code d'erreur maximum ne devrait pas dépasser 5) et je trouve que si le taux de flash est supérieur à environ 3 Hz, parfois je compte 3 flashs au lieu de 4.
Existe-t-il des règles de base pour la fréquence et le rapport cyclique pour la perception des flashs LED?
Norme de critères de conception du Département de la défense - Génie humain ( MIL-STD 1472 ) Section 5.2.1.1.4.1 Les signaux d'avertissement recommandent un taux de flash compris entre 3 et 5 Hz pour les avertissements, donc 3 Hz est certainement acceptable. Je suppose que la plage de 3 à 5 vise à optimiser la capacité d'attirer l'attention de la lumière, pas la capacité de comptage. MIL-STD 1472 ne traite pas des informations de codage dans le nombre de clignotements (pas plus que les autres normes relatives aux facteurs humains que j'ai).
La section 5.2.1.5.5 Codage Flash suggère que vous pouvez utiliser un deuxième taux de flash pour coder les informations, avec un second taux aussi bas que 0,8 Hz, ce qui me dit qu'il est acceptable de descendre aussi bas si vous le devez. (Je ne pense pas que vous souhaitiez utiliser un deuxième taux de flash dans votre application car il est probable que les utilisateurs n'auront probablement jamais besoin d'utiliser cet affichage. À moins que les utilisateurs n'aient déjà vu les deux taux de flash, comment savent-ils celui qu'ils voient est le plus lent ou le plus rapide? Cependant, différents modèles de flashs, comme dans réponse d'André , peuvent être explorés)
Je pense que la perception instantanée de plus de trois choses devient difficile. L'utilisateur doit compter mentalement les articles. Cela implique que votre taux de flash ne doit pas être plus rapide qu’une personne peut compter confortablement - environ 2 Hz, je dirais, ce qui correspond bien entre 3 et 0,8 Hz.
Il ne s'agit pas d'un affichage qu'un utilisateur pourra lire rapidement, quoi que vous fassiez. Même si les utilisateurs peuvent compter plus rapidement, ils devront probablement rechercher le code pour savoir ce que cela signifie. Si une réponse rapide est critique, vous devrez repenser le matériel pour inclure un meilleur affichage.
MIL-STD 1472 recommande un cycle d'utilisation de 50%.
Notez que cela ne repose pas du tout sur la recherche:
Il me semble que compter le nombre de flashs sera de toute façon difficile. Serait-il possible non seulement d'utiliser un certain nombre de flashs, mais des motifs distincts et répétitifs à la place? Quelque chose comme (où a. Représente un flash court et un tiret une gravure plus longue, et l'espace-temps où la led est éteinte):
...... vs - - - - - vs -.-.-.-
Vous pourriez trouver plus de modèles faciles à distinguer, je pense. Je suppose que cela dépend du nombre d'états d'erreur différents dont vous avez besoin pour communiquer, car le modèle ne peut évidemment pas être trop compliqué.
Il s'agit d'un modèle courant dans les codes d'erreur de l'équipement CVC. Voici un cas assez représentatif d'un manuel de la fournaise Carrier :
Cela peut vous sembler un cas extrême. Il y a 101 états d'erreur possibles que ce système peut représenter! Cependant, il existe certains modèles de conception clés à glaner.
Les premiers modèles de l'arbre de décision sont les plus faciles à reconnaître. La LED est-elle allumée ou éteinte ? S'il est allumé, clignote-t-il rapidement sans pause ? Ou clignote-t-il lentement avec une combinaison de flashs courts et longs ? Ces distinctions initiales sont facilement perçues par les propriétaires, peut-être au téléphone avec une technologie, et servent à gérer les cas les plus simples. Après cela, le système devient beaucoup plus complexe et implique de compter les courts et longs pour créer des codes d'erreur à deux chiffres.
La comparaison des longueurs d'impulsion est difficile. Limitez-vous à lent et long. Lent vs long est beaucoup plus facile que de comparer lent vs moyen vs long (ou d'ailleurs 4hz vs 3hz vs 2hz vs 1hz).
- Je ne trouve aucun document sur la durée exacte des impulsions, mais j'en ai rencontré une ou deux, et je suppose que le court est d'environ 0,5 seconde et le long de 1,0 seconde. (Si je suis loin de ma conjecture, je suppose que le réel est plus lent que cela. Il est fastidieux de compter les codes d'erreur.)
- Analyser tout élément complexe à partir d'une seule LED est probablement fastidieux car la "bande passante" du comptage précis des impulsions est intrinsèquement s-l-o-w. ( Les lampes de signalisation navales, un autre point de référence intéressant , atteignez un impressionnant 14 mots par minute avec le code morse, mais c'est avec du personnel hautement qualifié qui envoie et reçoit et un ensemble reconnu de conventions pour régir l'interaction ).
Donc, si vous n'avez besoin que de représenter un ou deux états d'erreur et que vous vouliez suivre le chemin HVAC bien usé, vous pouvez opter pour le premier ensemble de portes logiques (le plus simple) d'en haut, quelque chose comme:
- Voyant allumé = alimentation
- Clignotement rapide et constant = erreur critique
- Lumière clignotant lentement, avec une combinaison de flashs plus courts et plus longs = erreur secondaire
Plus vous devez représenter d'erreurs, évidemment, plus vos motifs doivent être complexes (et difficiles à analyser).