Difference between revisions of "Projets:Perso:2015:LedTube:ReflexionTechnique"
(→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. | ||
| − | == | + | ==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 | + | 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 | + | 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 | + | 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. | ||
| − | + | 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== | ==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 | + | 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. | 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
Contents
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.
