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

From Electrolab
Jump to: navigation, search
(Probleme de repli, recouvrement, ouverture)
Line 42: Line 42:
 
Mais la dernière va être mise à jour avec un retard de 1.25µs*32*59 = 2.36ms
 
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, entre 2 images, l'image se décale précisemment de 1 pixel (il y a 60 leds sur 360°).
+
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.
 
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.
Line 49: Line 49:
  
 
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.
 
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==

Revision as of 00:27, 17 November 2015

Choix techniques & Dimensionnement

Positionnement des trous : en motif carré ou hexagonal ?

La coupoles des leds font un profil d'éclairage circulaire. 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.

Probleme 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 constament 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. 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.
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.


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


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

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 premier CPU.

le PCB sera routé de telle sorte que les 2 processeurs aient accès au leds. Cela simplifiera aussi le developpement du firmware.
On pourra tester un maximum de choses sans passer son temps à basculer d'un processeur à l'autre.
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.

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.