---
title: "Sur cet écran, un pixel vertical coûte du plastique"
locale: "fr"
url: "https://irz.fr/fr/articles/scanwheel-pixels-cost-different-fr"
markdown_url: "https://irz.fr/fr/articles/scanwheel-pixels-cost-different-fr.md"
category: "tech"
tags: ["écran mécanique", "Raspberry Pi Pico", "RP2040", "PIO", "Scanwheel", "fabrication numérique"]
published_at: "2026-08-28T09:02:00.000Z"
author: "Léa Perrin"
translation: "https://irz.fr/en/articles/scanwheel-pixels-cost-different-en.md"
---

# Sur cet écran, un pixel vertical coûte du plastique

Scanwheel affiche 4 096 × 20 pixels avec un tambour imprimé et cinq LEDs. La largeur coûte surtout de la mémoire ; la hauteur oblige à refaire la mécanique.

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.[1](https://spectrum.ieee.org/mechanical-tv-2677767814)[2](https://github.com/AncientJames/Scanwheel)

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.[1](https://spectrum.ieee.org/mechanical-tv-2677767814)[2](https://github.com/AncientJames/Scanwheel)

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](https://github.com/AncientJames/Scanwheel)

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](https://github.com/AncientJames/Scanwheel) 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.**

> **Les deux axes ne coûtent pas la même chose**
> Comparaison entre la résolution verticale inscrite dans les trous du tambour et la résolution horizontale créée par le timing des LEDs
> - 4096 × 20, MAIS DEUX TYPES DE PIXELS
> - VERTICAL : 20
trous + hauteur + impression
> - HORIZONTAL : 4096
timing + RAM + débit
> - Ajouter une ligne modifie la pièce. Ajouter une colonne modifie surtout les données.
> La résolution verticale est encodée par la géométrie du tambour ; la largeur est synthétisée dans le temps.

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](https://github.com/AncientJames/Scanwheel)

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](https://spectrum.ieee.org/mechanical-tv-2677767814) La limite qu'il cite n'est pas la taille des trous : c'est principalement la mémoire disponible pour le framebuffer.[1](https://spectrum.ieee.org/mechanical-tv-2677767814)

Le code confirme cette logique. `ScanWheel` crée un framebuffer GS8 dont la taille est `largeur × nombre de lignes`.[2](https://github.com/AncientJames/Scanwheel) À 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](https://www.raspberrypi.com/products/rp2040/specifications/)

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

> 81 920 OCTETS
> **La largeur mange de la RAM avant de manger du plastique**
> - 81 920 octets de framebuffer GS8: 4096 × 20
> - 163 840 octets pour les pixels: 8192 × 20
> - 264 kB de SRAM totale: RP2040
> - toujours les mêmes 20 lignes mécaniques: Tambour
> Le projet rend visible un échange inhabituel : remplacer de la géométrie physique par de la précision temporelle.

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](https://www.raspberrypi.com/products/rp2040/specifications/) 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.[1](https://spectrum.ieee.org/mechanical-tv-2677767814)[2](https://github.com/AncientJames/Scanwheel)

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](https://github.com/AncientJames/Scanwheel) Chaque fenêtre fait environ 9 × 8 mm et partage les mêmes vingt lignes de scan.[2](https://github.com/AncientJames/Scanwheel)

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](https://collection.sciencemuseumgroup.org.uk/objects/co34372/baird-model-c-televisor-television-receiver-1929)

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](https://spectrum.ieee.org/mechanical-tv-2677767814) 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](https://hackaday.com/2026/07/26/scanwheel-a-pocket-sized-pov-tv/)

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](https://spectrum.ieee.org/mechanical-tv-2677767814)

## 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](https://github.com/AncientJames/Scanwheel)

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é.

## References

1. [James Brown, Make a Portable Wide-screen Mechanical TV, IEEE Spectrum, 27 août 2026](https://spectrum.ieee.org/mechanical-tv-2677767814)
2. [AncientJames, Scanwheel — code, OpenSCAD et documentation](https://github.com/AncientJames/Scanwheel)
3. [Matt Varian, Scanwheel: A Pocket-Sized POV TV, Hackaday, 26 juillet 2026](https://hackaday.com/2026/07/26/scanwheel-a-pocket-sized-pov-tv/)
4. [Raspberry Pi, RP2040 specifications](https://www.raspberrypi.com/products/rp2040/specifications/)
5. [Science Museum Group, Baird Model C Televisor Television Receiver, 1929](https://collection.sciencemuseumgroup.org.uk/objects/co34372/baird-model-c-televisor-television-receiver-1929)