Difference between revisions of "Projets:Perso:2015:LedTube:ReflexionTechnique"

From Electrolab
Jump to: navigation, search
(Probleme de repli, recouvrement, ouverture)
(Choix techniques & Dimensionnement)
 
(3 intermediate revisions by one user not shown)
Line 3: Line 3:
 
==Positionnement des trous : en motif carré ou hexagonal ?==
 
==Positionnement des trous : en motif carré ou hexagonal ?==
  
La coupoles des leds font un profil d'éclairage circulaire.  
+
La coupoles des leds font un profil d'éclairage circulaire. C'est ce qui a été retenu.
 
Si on veut un motif carré, il faudrait diaphragmer en carré ce qui représente beaucoup de travail. Avec le risque que ça ne tienne pas avec le temps.
 
Si on veut un motif carré, il faudrait diaphragmer en carré ce qui représente beaucoup de travail. Avec le risque que ça ne tienne pas avec le temps.
  
Line 9: Line 9:
 
*Avantage du motif hexagonal (triangles équilatéraux) : mappage du plan optimal pour un cône d'émission circulaire. Inconvénient : Nécessite d'appliquer des filtres numériques.
 
*Avantage du motif hexagonal (triangles équilatéraux) : mappage du plan optimal pour un cône d'émission circulaire. Inconvénient : Nécessite d'appliquer des filtres numériques.
  
==Probleme du motion blur==
+
==Problème du motion blur==
  
 
Si on ne fait rien, avec un affichage basique à 60Hz, avec une image en rotation à 1 tour par seconde, en suivi oculaire, le motion blur va faire que les pixels vont s'étaler sur 2 pixels de large. Pas bon.
 
Si on ne fait rien, avec un affichage basique à 60Hz, avec une image en rotation à 1 tour par seconde, en suivi oculaire, le motion blur va faire que les pixels vont s'étaler sur 2 pixels de large. Pas bon.
Line 15: Line 15:
 
Dans le cas d'images en rotation, pour limiter à un seuil fixe la sensation de motion blur, deux possibilités.  
 
Dans le cas d'images en rotation, pour limiter à un seuil fixe la sensation de motion blur, deux possibilités.  
  
1) le frame rate est constament adapté à la vitesse de rotation.<br>  
+
1) le frame rate est constamment adapté à la vitesse de rotation.<br>  
 
2) la durée d'affichage est réduite
 
2) la durée d'affichage est réduite
  
 
1) A le très gros avantage que la puissance lumineuse reste constante. Mais l'inconvénient est que la charge CPU du driver de leds est multipliée d'autant. (par exemple à 240Hz, Il va passer en proportion 4x plus de temps à filtrer et envoyer les images). Mais si on en a sous le pied en puissance de calcul, il ne faut pas hésiter.
 
1) A le très gros avantage que la puissance lumineuse reste constante. Mais l'inconvénient est que la charge CPU du driver de leds est multipliée d'autant. (par exemple à 240Hz, Il va passer en proportion 4x plus de temps à filtrer et envoyer les images). Mais si on en a sous le pied en puissance de calcul, il ne faut pas hésiter.
Si on veut par exemple limiter le motion blur à 1/4 de pixel, alors le frame rate = 60*TPS*4. (TPS=Tours par seconde). Avec une limite basse à 60Hz tout de même, dans le cas de rotation. Pas de rafraichissement si pas de rotation. Il reste que chaque arrivée d'une nouvelle image (par le lien de COM entre les 2 processeurs) doit produire un rafraichissement immédiat (si TPS=0) ou à la trame suivante. <br>
+
Si on veut par exemple limiter le motion blur à 1/4 de pixel, alors le frame rate = 60*TPS*4. (TPS=Tours par seconde). Avec une limite basse à 60Hz tout de même, dans le cas de rotation. Pas de rafraichissement si pas de rotation.<br>
2) A l'avantage de la simplicité. Effacer l'image ne prend pas de temps CPU (peut-être fait avec une PWM). Mais l'image s'assombrit. Alors il faut booster la luminosité pour compenser exactement. Ca signifie que en temps normal, la puissance pourrait avoir à être bridée à 25% pour que l'effet d'assombrissement puisse être bien compensé. J'espere pouvoir éviter cette solution.<br>
+
2) A l'avantage de la simplicité. Effacer l'image ne prend pas de temps CPU (peut-être fait avec une PWM). Mais l'image s'assombrit. Alors il faut booster la luminosité pour compenser exactement. Ca signifie qu'en temps normal, la puissance pourrait avoir à être bridée à 25% pour que l'effet d'assombrissement puisse être bien compensé. J'espère pouvoir éviter cette solution.<br>
  
 +
Donc, je dirais, à voir selon la puissance de calcul obtenue.
  
Donc, je dirais, à voir selon la puissance de calcul obtenue.
+
Solution : Actuellement, en partie parce que tout est fait sur un seul CPU, aucune de ces deux solutions n'a eu besoin d'être implémentée. Avec le frame rate à 200Hz pour les images fixes, pas vraiment de problème.
 
+
 
+
==Probleme de repli, recouvrement, ouverture==
+
 
+
Il y a malheureusement un problème assez idiot dans la façon dont le chip WS2812B gère le latch interne
+
 
+
Il n'ont pas voulu payer un tout petit peu de silicium en plus. Dommage.
+
 
+
Il aurait été bien que ce soit la commande de reset qui produise le transfert effectif vers la led des 24 bits.
+
 
+
Cela aurait permis d'avoir un affichage (quasi parfaitement) synchronisé de toutes les leds.
+
 
+
Mais en fait (si je devine bien l'information manquante dans la datasheet) la led est allumée dès qu'elle a reçu ses 24 bits.
+
 
+
Dans mon architecture cylindrique, la première led et la dernière se touchent.
+
 
+
Mais la dernière va être mise à jour avec un retard de 1.25µs*32*59 = 2.36ms
+
 
+
Avec par exemple une vitesse de rotation de l'image de 1 tour par seconde, alors, l'image se décale précisemment de 1 pixel en 16.666ms (1/60)(il y a 60 leds sur 360°).
+
 
+
Donc on avance d'un pixel en 16.666ms. Mais comme la dernière led est allumée 2.36ms après la première, en toute rigueur, visuellement il va y avoir soit un recouvrement, soit un trou.
+
 
+
Recouvrement/Séparation 2.36e-3s/16.666e-3s*16mm = 2.26mm (Résultat indépendant du refresh rate).
+
 
+
Ce qui nous sauve un peu, c'est que les pixels de ce système n'ont pas des bords nets. Ca aidera un peu à ce que l'overlap ne se repère pas.
+
  
 
==Pilotage des Leds sous DMA==
 
==Pilotage des Leds sous DMA==
Line 56: Line 32:
 
Delta T = 0.4µs
 
Delta T = 0.4µs
  
Par conséquent, l'affichage pourrait peut-être aussi être géré par le premier CPU.
+
Par conséquent, l'affichage pourrait peut-être aussi être géré par le CPU principal.
 
+
le PCB sera routé de telle sorte que les 2 processeurs aient accès au leds. Cela simplifiera aussi le developpement du firmware.<br>
+
On pourra tester un maximum de choses sans passer son temps à basculer d'un processeur à l'autre.<br>
+
Une laison série sera rebouclée. (tx vers rx). Ce qui permettra de mettre au point la com sur un seul processeur. si necessaire.<br>
+
  
 
Cette méthode a été implémentée. Cela permet de supprimer la contrainte temps réel dans le code.
 
Cette méthode a été implémentée. Cela permet de supprimer la contrainte temps réel dans le code.
  
 
Frame Rate pratique obtenu : 568Hz. 200Hz y compris filtrage gaussien et translation.
 
Frame Rate pratique obtenu : 568Hz. 200Hz y compris filtrage gaussien et translation.

Latest revision as of 15:23, 22 April 2019

Choix techniques & Dimensionnement

Positionnement des trous : en motif carré ou hexagonal ?

La coupoles des leds font un profil d'éclairage circulaire. C'est ce qui a été retenu. Si on veut un motif carré, il faudrait diaphragmer en carré ce qui représente beaucoup de travail. Avec le risque que ça ne tienne pas avec le temps.

  • Avantage du motif carré : permet de mapper directement une image standard sans filtrage. Meilleure qualité.
  • Avantage du motif hexagonal (triangles équilatéraux) : mappage du plan optimal pour un cône d'émission circulaire. Inconvénient : Nécessite d'appliquer des filtres numériques.

Problème du motion blur

Si on ne fait rien, avec un affichage basique à 60Hz, avec une image en rotation à 1 tour par seconde, en suivi oculaire, le motion blur va faire que les pixels vont s'étaler sur 2 pixels de large. Pas bon.

Dans le cas d'images en rotation, pour limiter à un seuil fixe la sensation de motion blur, deux possibilités.

1) le frame rate est constamment adapté à la vitesse de rotation.
2) la durée d'affichage est réduite

1) A le très gros avantage que la puissance lumineuse reste constante. Mais l'inconvénient est que la charge CPU du driver de leds est multipliée d'autant. (par exemple à 240Hz, Il va passer en proportion 4x plus de temps à filtrer et envoyer les images). Mais si on en a sous le pied en puissance de calcul, il ne faut pas hésiter. Si on veut par exemple limiter le motion blur à 1/4 de pixel, alors le frame rate = 60*TPS*4. (TPS=Tours par seconde). Avec une limite basse à 60Hz tout de même, dans le cas de rotation. Pas de rafraichissement si pas de rotation.
2) A l'avantage de la simplicité. Effacer l'image ne prend pas de temps CPU (peut-être fait avec une PWM). Mais l'image s'assombrit. Alors il faut booster la luminosité pour compenser exactement. Ca signifie qu'en temps normal, la puissance pourrait avoir à être bridée à 25% pour que l'effet d'assombrissement puisse être bien compensé. J'espère pouvoir éviter cette solution.

Donc, je dirais, à voir selon la puissance de calcul obtenue.

Solution : Actuellement, en partie parce que tout est fait sur un seul CPU, aucune de ces deux solutions n'a eu besoin d'être implémentée. Avec le frame rate à 200Hz pour les images fixes, pas vraiment de problème.

Pilotage des Leds sous DMA

Le transfert peut se faire par DMA (mémoire vers GPIO), sous interruption timer. Ce qui ramène le temps CPU à 0.
Et donc permet d'envisager un refresh rate pouvant aller jusqu'à 550Hz...
Delta T = 0.4µs

Par conséquent, l'affichage pourrait peut-être aussi être géré par le CPU principal.

Cette méthode a été implémentée. Cela permet de supprimer la contrainte temps réel dans le code.

Frame Rate pratique obtenu : 568Hz. 200Hz y compris filtrage gaussien et translation.