Choix protocole de communication (Projet LED)

[JulienT]

Bonjour,

Je sollicite votre aide pour un projet qui me tient à cœur. Je souhaite réaliser un mur composé de plusieurs modules LED. Chaque module serait constitué d'une bande LED de 40 cm. Mon objectif est de pouvoir contrôler tous les modules composant mon mur simultanément, sans aucune latence entre l'allumage du premier et du dernier module de la chaîne. Pour cela, il est essentiel d'utiliser le bon protocole de communication. C'est pourquoi je sollicite vos retours d'expérience ainsi que vos recommandations concernant le protocole de communication idéal pour éviter toute latence à l'allumage. Une difficulté supplémentaire réside dans le fait que le protocole de communication doit être bidirectionnel. En d'autres termes, je dois pouvoir contrôler les LED de mes modules tout en recevant les retours d'états de chacun d'eux.

Pour récapituler, le protocole de communication doit être bidirectionnel, comporter deux entrées de contrôle et deux sorties de données, le tout transitant sur le bus de communication. De plus, je souhaite pouvoir contrôler jusqu'à 600 modules simultanément. Malgré ces critères exigeants, j'espère que ce projet est réalisable.

Je vous remercie d'avance pour vos idées, conseils et précieuse aide. Si vous avez des suggestions concernant des cartes de développement et des langages de programmation, je suis aussi preneur.

Merci à vous.
-----

[Murayama]

Bonjour!

sans aucune latence entre l'allumage du premier et du dernier module de la chaîne.

Ou bien nous n'avons pas la même compréhension de l'expression "sans aucune latence",
ou bien vous rêvez tout debout. Que voulez-vous dire exactement? Quelle est la durée
maximale de ce "sans aucune latence"?

Et il manque des données. Que fait chaque module de 40 LEDs exactement? Ont-elles
besoin de s'allumer séparément? (dans quel cas il faut un mot de commande de 40 bits).
Ont-elle besoin de s'allumer proportionnellement à une certaine valeur, comme un pixel
dans un écran? (dans quel cas, il faut une trame de 40 bytes ou 320 bits). Ou alors
chaque module est une barre de LEDs qui ne nécessite qu'un seul bit? (tout allumer ou
tout éteindre en même temps). Est-ce que chaque module est un genre de "bargraph"?
(toutes les LEDs allumées à fond jusqu'à une certaine hauteur).

Pour votre protocole, pourquoi deux entrées de contrôle et deux sorties de données?
Je veux dire, pourquoi pas une seule, pourquoi pas trois?

Bref, si vous pouviez être un peu plus précis et décrire ce que vous voulez faire,
je crois que les conseils seraient probablement plus constructifs.

Pascal

[umfred]

Combien de module de 40 leds? (j'ai vu 600 modules en relisant)
Quelle longueur entre ton mur et la commande?
Ce sont des LED monochrome? on doit pouvoir définir leur couleur? individuellement? par bande ? le but de l'affichage ? (image/texte fixe? dynamique ? lumière ON/OFF?)

Je pense que ça devra passer par des minicartes de commandes à développer (1 carte pour x module, x à déterminer); dans une 1ère approximation, il faudra des commandes de configuration individuelle, et commande d'éxécution globale (ou individuelle selon la définition de ton "sans latence")

[jiherve]

bonjour,
c'est vraiment pas clair !
que sont capables de faire ces modules ?
pourquoi un retour ?
JR

[A voir en vidéo sur Futura]

[JulienT]

Bonjour à tous !

Tout d'abord, merci beaucoup pour vos retours.

Concernant la notion de "sans aucune latence", je précise que je vise une latence non perceptible à l'œil. Je suis conscient qu'il y aura inévitablement un délai entre l'allumage du premier module et du dernier, mais mon objectif est de minimiser ce délai autant que possible afin qu'il soit imperceptible.

En ce qui concerne les modules LED, je reconnais que ma présentation du projet n'était pas assez précise. Celui-ci est encore en cours de développement et tous les détails ne sont pas encore définis. Je compte donc sur vos conseils précieux pour encadrer l'ensemble de manière plus claire.

Cependant, pour entrer dans les détails d'un module, voici les caractéristiques envisagées :

Chaque module est constitué d'une barre de LED (30 LED).
Je souhaite pouvoir contrôler l'allumage/extinction (ON/OFF) et le changement de couleur de l'ensemble de la barre LED.
Toutes les LED d'une barre doivent avoir la même couleur (par exemple, les 30 LED d'une barre en rouge).
Chaque module doit être adressable individuellement, permettant ainsi un contrôle indépendant (par exemple, sur 30 modules, 1 en vert, 29 en rouge).
Chaque module doit être capable de renvoyer des données sur son état (par exemple, défaut/couleur/position/disponibilité) pour être visualisé dans une interface utilisateur (IHM).
Concernant les entrées de contrôle et les sorties de données, le nombre reste à préciser en fonction des possibilités, que ce soit par l'utilisation de trames ou d'E/S analogiques et numériques.

Le nombre maximum de modules dans la configuration envisagée est de 600.

La distance entre le mur et la commande est d'un mètre, donc la proximité est préférable pour éviter des câbles trop longs.

J'espère que ces précisions seront suffisantes. Je suis motivé et prêt à me former sur de nouvelles technologies. En fonction de vos conseils, je suis également prêt à développer mon propre protocole de communication.

Merci d'avance pour vos réponses !

[jiherve]

bonsoir
donc en clair tu cherches un bureau d'étude gratuit ?
JR

[JulienT]

Je m'excuse si mes messages ne sont pas assez clairs.
Je suis à la recherche de conseils, comme je l'ai déjà mentionné dans mes précédents messages.
Comme le titre de ma demande l'indique, j'aimerais des suggestions pour un protocole de communication adapté à mon projet, que j'ai détaillé précédemment en réponse à vos questions.
Merci d'avance pour vos réponses.

[ThomasV]

Bonjour à tous,

Ceci peut aider pour commencer : https://www.gotronic.fr/art-module-a...t010-26099.htm
Il est portant de prototype !
Et comme ça tu verras quelle est la meilleure solution.

Bonne journée,

[Seb.26]

Peu importe le protocole : y'a pas de protocole magique qui va supprimer toute latence ... si tu veux ne pas voir de latence, il faut ne pas en créer.

il manque une information importante : quelle fréquence de mise à jour des couleurs ?!

comme dit plus haut, il faut un module "maitre" qui envoit aux modules "enfants" les ordres un par un (toi tu seras bleu, toi tu seras vert ...etc) et une fois toutes les consignes envoyées, un ordre commun de mise à jour.

Mais effectivement, malgré la pommade, on sent bien l'enfumage ...

[tchitchou]

Bonjour à tous,
♦ protocole entre modules LED et quoi ? Ordi ?
♦ 600 modules LED, vraiment ? Pour leur faire faire quoi ?

♣ c'est un devoir ?

[antek]

Le protocole n'a pas grande importance, si les distances ne dépassent pas quelques mètres. Il faut voir du côté des réseaux en étoile avec maître unique et 600 esclaves (en une ou plusieurs grappes).
Nota : il ne faut plus dire maître/esclave . . .
Ces réseaux existent aussi en "sans fil", à voir si c'est plus commode.

Mais d'autres choix sont possibles . . .

[umfred]

apparemment tu as déjà défini ta barre de led, donc voir comment elle se commande.
Après, il te faudra sans doute développer des cartes filles adressables et une carte maitre et d'utiliser le protocole que tu veux.
Et toujours du mal à comprendre ton histoire d'entrées de contrôles et sorties de données, si tu passes par un protocole de communication, ça passera par lui

[bobflux]

Si je comprends bien :

- Chaque module est un pixel RGB (les LEDs comprenant un module affichent toutes la même couleur et ne sont pas contrôlables indépendemment)

- Il y a entre les modules une distance inconnue mais "pas trop longue" vu que c'est un mur de LEDs

- Il y a 1m entre le maître et le mur de LEDs.

> Chaque module doit être capable de renvoyer des données sur son état (par exemple, défaut/couleur/position/disponibilité) pour être visualisé dans une interface utilisateur (IHM).

- Défaut, Disponibilité : OK

- Couleur : inutile puisque le maître sait quelle couleur il a envoyé

- Position :

Pour qu'un module donne sa position il faut qu'il la connaisse. Pour cela soit il va contenir un moyen pour l'installateur de lui donner l'information (dip switch, etc, peu pratique) soit les modules sont branchés en guirlande sur un câble et le module peut déterminer son numéro dans la guirlande. Le dernier cas est le meilleur car les modules sont interchangeables puisque c'est la place du module sur le câble qui lui donne son numéro.

Ceci signifie que le moyen d'identification de la position ne peut pas être un bus. Il faut donc que chaque module reçoive le signal du précédent et l'envoie au suivant... pour savoir qui est le précédent et qui est le suivant. Sur un bus tout le monde reçoit le signal en même temps, le seul moyen de déterminer l'ordre est de faire du TDM, bonne chance.

Bref,

Alimentation

T'avais oublié l'alim dans le post.

Pour 30 LEDs blanches en série on a donc 90-100V, c'est trop. Pour la sécurité on part sur du 24V, donc les LEDs par chaînes de 6 plus résistance en série avec 5 grappes en parallèle.

Mettons 20mA par LED, x4 pour du RGBW donc 80mA par LED, donc 80mA par chaîne, donc 400mA par pixel, donc 240A pour les 600 pixels. Consommation totale 6kW avec les pertes : ça fera un bon chauffage. Prévoir donc 24 alims Meanwell ELG-240-24 produisant 10A chaque, plus le câblage tension secteur avec un bus en 6-10mm², plus le câblage en 24V en 2.5-4mm² suivant la distance. Chaque alim produit 10A et gère donc 25 pixels de 400mA.

Logistique

Si les pixels sont "smart" et contiennent les drivers de LED, il faut amener l'alimentation aux pixels. D'où un problème de connecteurs puisque la guirlande "communication" ne sera pas forcément organisée de la même façon que la pieuvre "alimentation". Ça risque de finir en quadrillage, avec les problèmes de masse associés.

Si les pixeis sont stupides et ne contiennent que des LEDs, il y aura par exemple un boîtier "contrôleur" gérant 25 pixels et contenant l'alimentation et les 25 drivers, relié aux pixels par des câbles 4 conducteurs (RGB+Commun) ou 5 conducteurs (RGBW+Commun) ce qui est foutrement plus simple. Et en plus il faudra 25x moins de câbles pour la communication.

Solution adoptée : un pixel est composé d'un morceau de strip LED RGB ou RGBW 24V du commerce, plus emballage, plus connecteur. Il est relié à un contrôleur par un câble idoine.

Une carte contrôleur pourrait gérer 4-5 pixels et avoir plusieurs cartes sur une alim, ou bien une carte contrôleur gère 25 pixels.

Le nombre de pixels géré par une alim est donc entre 4 et 25 suivant l'alimentation choisie, le nombre dépendant de ce qui est pratique, par exemple 25 permet de faire des carrés de 5x5 pixels, mais ça n'ira pas forcément avec la façon dont tes 600 pixels sont disposés. Si ça t'arrange de mettre une alim par colonne, c'est bien aussi. L'important est de pouvoir faire un module réutilisable de N pixels facile à assembler sur une table avec l'alim, la structure pour l'accrocher au mur, etc. Les câbles vers les LEDs ne doivent pas être trop longs.

Nous avons donc une structure en arbre : une alim -> un ou plusieurs contrôleurs -> plusieurs pixels par contrôleur.

[bobflux]

Autre solution : barres de LEDs adressables toutes faites (mais il faut les trouver à la bonne dimension). Mais je reste sur la précédente.


Le contrôleur

* Solution la plus simple : GS8208

Avantages : solution toute faite pour un prix ridicule, PWM 12 bits 8kHz avec gamma, tolérance de panne (un module en panne ne bloque pas la chaîne). Cela revient à fabriquer un strip de LED à GS8208 mais avec 30 leds au lieu de une sur chaque puce. Prévoir un driver pour booster le courant et la tension, le GS8208 ne générant que le PWM.

Inconvénients : communication unidirectionnelle, pas de retour.

* Les mains dans le cambouis

OK donc un microcontrôleur par module.

Option 1 : on utilise le PWM du micro directement, donc par exemple un ESP32 qui a 16 sorties PWM, va commander 5 pixels RGB ou 4 pixels RGBW, ou un micro plus simple et pas cher style Cortex-M0 va commander 1 pixel.

Option 2 : un micro commande plusieurs PCA9685 en I2C. Ils sont cadencés par une horloge commune à 40 MHz, chacun offre 16 sorties PWM 12 bits.

"The PCA9685 allows staggered LED output on and off times to minimize currentsurges. The on and off time delay is independently programmable for each of the16 channels. This feature is not available in PCA9635."

Chaque sortie commande un transistor qui commande les LED. On a donc 16 sorties (4 pixels RGBW) pour : un TSSOP28 + 8x double MOSFET SO8 + 4 connecteurs 5 pins + passifs + logistique soit 1200mm² ou 3x4cm, donc 300mm² par pixel, donc on contrôle 25 pixels avec la moitié d'une eurocarte 100x160mm. Il n'y a donc pas de raison de faire plusieurs cartes contrôleur par alim.

Donc on valide l'option 2 : carte contrôleur avec un micro, des PCA9685, des MOSFET.

Détection des défauts / court-circuits :

Une résistance de 1 ohm dans la source de chaque MOSFET, un paquet de diodes : on obtient une tension supérieure à 1V si le courant dans une sortie est anormalement élevé. Comparateur, bascule RS sur l'entrée OE des PCA9685 : si il y a un court-circuit, ils s'éteignent tous, ça devrait prendre moins de 1µs donc pas de risque de destruction. Ensuite prévoir du soft pour détecter quel sortie est en court circuit.

Détection des défauts / circuit ouvert :

On ajoute des mux analogiques pour surveiller la tension sur les résistances en question, avec un comparateur à la sortie.

Microcontrôleur

On peut mettre à peu près n'importe quoi, STM32, ESP32 pour remplacer les câbles par des ondes... ou même des Orange Pi...

Détection de la position

Si chaque contrôleur gère 25 pixels, on a divisé le problème par 25. Pour 600 pixels on n'a plus que 25 contrôleurs.

Donc il est tout à fait envisageable de les informer manuellement de leur position.

Communication

Le plus important est bien évidemment de pouvoir mettre à jour le firmware de tous les contrôleurs en même temps sans se lever de sa chaise.

Vu la tronche du projet ça sent le "one off" donc passer 3 jours à peaufiner jusqu'à la perfection un bootloader sur bus CAN (ou pire) ne me semble pas pertinent. Surtout que quand ça foire, il faut reprogrammer manuellement les 24 cartes (c'est à ce chapitre de l'histoire que certains comprennent pourquoi je veux pas qu'il y en ait 600).

Par conséquent je mettrais soit des orange pi lite (24.43€ sur aliexpress, consomme moins de 1W) ou n'importe quel SBC ARM du style Pi le moins cher possible zero nano pico etc, qui communiquent par ethernet ou wifi... ou des ESP32. Les deux sont facilement reprogrammables, mais l'orange pi est beaucoup plus difficile à briquer. Sur ESP32 si ton code crash, le bootloader wifi est désactivé, donc il faut y aller en USB. Sur un Pi tu le fais en Python, donc c'est impossible à crasher, et en plus c'est vachement plus simple et rapide à développer.

OK donc choix du pi validé.

Ça veut dire que la carte doit se contrôler en I2C pour la simplicité : je ne vois pas de problème particulier à ce sujet, un IO expander et hop.

Le protocole

Du coup, il a disparu. Comme le truc a l'ethernet et/ou le wifi, ça devient trivial : UDP, sockets, tu fais ce que tu veux.

Les machins ont NTP donc ils sont tous synchronisés à la milliseconds.

[niala72bis]

Je parie qu'en nombre de réponses il va battre le sujet des alarmes avec 3914, mais pas celui de la clarté.

Ce que l'on conçoit bien s'énonce clairement et ...

[bobflux]

Ce que l'on conçoit bien s'énonce clairement et ...

Avant j'essayais de tirer les vers du nez, maintenant si l'OP ne veut pas cracher l'info je mets ce qui me plaît à la place.

Après tout, on est là pour s'amuser

Là par exemple il a complètement oublié le plus important qui est l'alimentation, donc voilà c'est fait.

[lutshur]

Après tout, on est là pour s'amuser

Et apprendre que tout ne se fait pas toujours facilement. Surtout que l'initiateur de la discussion du LM3914 avait annoncé la couleur.
Certains ne l'ont pas intégré, curseur de tolérance placé trop bas ?