Le chiffre « 4K » suggère d'habitude des millions de minuscules éléments répétés sur une dalle. Scanwheel arrive au même nombre de colonnes avec vingt trous dans un tambour et cinq LEDs.12

Sa définition actuelle est de 4 096 × 20 pixels. Le premier nombre vient surtout du temps : le Raspberry Pi Pico change très vite la luminosité des LEDs pendant qu'un trou se déplace devant elles. Le second est inscrit dans la matière : le modèle OpenSCAD du tambour contient vingt lignes de scan.12

Cela produit un écran où un pixel supplémentaire n'a pas le même prix selon l'axe.

Vingt lignes réelles

Scanwheel reprend le principe des premières télévisions mécaniques, mais remplace le grand disque de Nipkow par un petit tambour de 60 mm de diamètre.2

Le fichier drum.scad du projet est explicite : diamètre 60 mm, hauteur 12 mm, zone scannée 8 mm et scan_lines = 20.2 Les vingt ouvertures sont réparties autour du tambour et décalées verticalement. À chaque rotation, elles balaient successivement les vingt lignes de l'image.

Cette géométrie n'est pas un simple support. Elle est une partie de la définition verticale.

Comparaison entre la résolution verticale inscrite dans les trous du tambour et la résolution horizontale créée par le timing des LEDsLa résolution verticale est encodée par la géométrie du tambour ; la largeur est synthétisée dans le temps. Synthèse IRZ d'après le code Scanwheel

Le README insiste d'ailleurs sur la qualité d'impression du tambour : petite hauteur de couche, vitesse réduite, paroi unique et éventuellement buse de 0,2 mm. Les défauts des petites ouvertures deviennent immédiatement visibles dans l'image.2

Pour passer à quarante lignes, il ne suffit donc pas de changer une constante d'affichage. Il faut générer puis imprimer un autre tambour, trouver assez de hauteur pour les ouvertures et conserver une géométrie propre.

4K dans le temps

Horizontalement, la situation s'inverse.

Chaque trou traverse une fenêtre. Pendant ce déplacement, la luminosité de la LED peut être modifiée des milliers de fois. Ces variations successives deviennent autant de positions horizontales perçues.

James Brown explique dans IEEE Spectrum que son système fonctionne aujourd'hui à 4 096 pixels de large et qu'il a dépassé 8 000 pixels lors d'essais.1 La limite qu'il cite n'est pas la taille des trous : c'est principalement la mémoire disponible pour le framebuffer.1

Le code confirme cette logique. ScanWheel crée un framebuffer GS8 dont la taille est largeur × nombre de lignes.2 À 4 096 × 20, cela représente 81 920 octets rien que pour les pixels du frame. Le RP2040 dispose de 264 kB de SRAM au total.4

Doubler la largeur à 8 192 porte ce seul tableau à 163 840 octets, avant le reste du programme et ses buffers.

Ce « 4K » ne doit donc pas être lu comme la densité d'une dalle LCD. Les colonnes n'existent pas simultanément sous forme de cellules physiques. Elles sont des instants de modulation le long d'un balayage.

Le PIO fait le sale travail

Cette résolution temporelle serait beaucoup moins pratique si les deux cœurs du RP2040 devaient eux-mêmes décider, pixel après pixel, quand changer chaque LED.

Le microcontrôleur possède des blocs PIO, des petites machines d'état programmables conçues pour gérer des entrées-sorties avec un timing précis.4 Scanwheel les utilise avec le DMA pour lire le framebuffer et piloter les sorties pendant que le CPU MicroPython s'occupe surtout de la configuration.12

Le projet pilote cinq zones côte à côte avec le même tambour : quatre LEDs blanches et une LED RGB dans la version documentée.2 Chaque fenêtre fait environ 9 × 8 mm et partage les mêmes vingt lignes de scan.2

C'est là que l'architecture devient plus moderne que nostalgique. Le composant mécanique produit le balayage ; le matériel spécialisé du microcontrôleur fournit la régularité temporelle.

Une vieille idée, autre compromis

Les téléviseurs de John Logie Baird utilisaient déjà un disque perforé pour convertir une rotation en balayage d'image. Le modèle C de 1929 conservé par le Science Museum utilisait trente ouvertures et affichait trente lignes avec une lampe au néon.5

Scanwheel en possède moins : vingt.

Pourtant, sa lisibilité peut être étonnamment bonne parce que la largeur logique est sans commune mesure avec celle des systèmes historiques.1 Hackaday soulignait déjà en juillet le contraste entre quelques LEDs, un moteur pas à pas, un Pico et une image qui semble beaucoup plus élaborée que la liste des pièces.3

La miniaturisation des LEDs change aussi la mécanique. IEEE note qu'un tambour compact devient possible parce qu'une source lumineuse moderne peut être placée près de la zone de balayage, là où les premières machines devaient composer avec des sources beaucoup plus encombrantes.1

Choisir l'axe bon marché

Le fichier OpenSCAD est peut-être la partie la plus transférable du projet. Le nombre de lignes, la hauteur de scan et le diamètre sont paramétriques.2

Cela permet de poser la question avant de reconstruire : quelle dimension mérite réellement d'être augmentée ?

Plus de hauteur impose davantage de fentes, une fabrication plus fine et potentiellement un tambour plus haut. Plus de largeur demande davantage de mémoire et un timing plus rapide. Les deux améliorent un chiffre appelé « résolution », mais elles sollicitent des ressources totalement différentes.

C'est une leçon utile au-delà des écrans. Dans un système hybride, certaines capacités sont chères parce qu'elles demandent de la matière ; d'autres parce qu'elles demandent du calcul, de la mémoire ou du temps précis.

Scanwheel paraît absurde avec ses 4 096 × 20 pixels.

C'est justement ce format qui montre le mieux où chaque pixel est réellement fabriqué.