Bonjour la communauté,
Je m’amuse actuellement à développer un montage destiné à être placé sous une avancée de toit pour simuler, entre autre, les reflets d’une piscine le long du mur lorsqu’il fait nuit.
Malheureusement, les premiers tests sur un esp8266 et un esp32 n'ont pas été concluants.
D’une part, la puissance de calcul pour créer les effets désirés limite drastiquement le nombre de leds utilisées.
Si cela suffit pour simuler les reflets du soleil sur des vagues dans un aquarium de 2 mètres de long, c’est largement insuffisant pour un mur de 12 mètres.
D’autre pas, j’ai sous estimé le temps de propagation nécessaire à la transmission des données sur le ruban.
Même si celui-ci ne comporte ‘que’ 60 leds sk6812 par mètre, il faut quasiment 30 ms pour transférer la totalité des 2880 octets de données constituant ta trame à une vitesse de 800kbps.
Je me suis donc tourné vers un raspberry Py 3 a+ (le PI 0w rame trop) pour continuer mon projet en y ajoutant un serveur Web pour la gestion des moults paramètres de l’ensemble des animations.
La seule contrainte restante est que seulement un ruban de leds peut y être connecté (limitation des DMA disponibles).
Néanmoins, un rafraîchissement des leds toutes les 30 ms sur une distance de 12 mètres suffit pour obtenir un résultat satisfaisant.
Cependant, je me pose la question de mélanger les avantages de chacun de ces composants pour obtenir une animation fluide sans pour autant limiter la longueur du ruban, et pour un prix qui restera abordable.
Le système serait composé d’un raspberry Pi (3 a+ ou 0w à voir) dont le rôle sera de :
- Fournir une interface Web avec serveur websocket pour un contrôle réactif des animations.
- Calculer les couleurs du ruban
- Transmettre les données du/des rubans en WiFi (mesh ?)
De multiples esp8266 ou esp32 qui devront :
- Fournir une petite interface Web pour le paramétrage réseau et ruban (Id, Index, longueur,..)
- Recevoir les données et les filtrer en fonction des paramètres
- Envoyer la trame sur le ruban
Et c’est la partie qui me laisse perplexe…
Je pense que le broadcasting des données du ruban par le raspberry limiterait l’occupation de la bande passante (en particulier en cas de clonage d’une partie du ruban), et limiterait la mise en place d’un protocole d’échange / demande des données par les esp.
Je sais déjà que le protocole udp n’est pas infaillible et que des packets peuvent se perdre.., que la taille des packets est limitée (=>identification des paquets)
Donc ma question est la suivante.
Avez-vous déjà utilisé le broadcasting de données sur un réseau avec des esp, et connaissez-vous des limites d’utilisation qui pourraient entrer en conflit avec l’usage décrit plus haut ?
Toutes autres suggestions ou remarques seront, bien évidemment, les bienvenues.