• Müller-Licht 42850¹, défectueuse après un choc mécanique
• Osram AC01190², avec un clignotement aléatoire après quelques années

Autant les ouvrir pour voir ce qu’il y a dedans.

Spécifications

Comme chaque lampe est fournie avec une datasheet, on va pouvoir les comparer avant de les démonter.

Les spécifications des deux lampes sont assez comparables, regardons ce qui est remarquable :

• La puissance nominale et l’intensité lumineuse sont légèrement différentes par construction
• Le coefficient de rendu des couleurs diffère, mais le spectre de chaque lampe est très similaire. Il est possible que les conditions des spécifications diffèrent
• L’angle de projection de la lampe Müller est quasiment plat (estimé), parce que la lampe contient plusieurs LEDs à plat derrière un diffuseur. Celui de la lampe Osram est plus directif, avec une ou plusieurs LEDs derrière une lentille, pour imiter le comportement de lampes à incandescence à réflecteur parabolique (PAR)
• La différence de durée de vie est surprenante. Il est possible que les conditions des spécifications diffèrent
• Le facteur de puissance de la lampe Osram est très faible, ça suppose la présence d’une capacité directement derrière le redresseur. La lampe Müller a probablement une architecture différente, ou un filtre
• Le fait qu’aucune des lampes ne soit dimmable suppose la présence d’une capacité d’assez forte valeur pour lisser la tension du secteur

Osram AC01190

Le boitier s’ouvre en séparant la lentille du corps de la lampe, sans outil. Les fils sertis dans le connecteur GU10 et sur le PCB cassent.

De façon surprenante, le corps de la lampe est en verre partiellement recouvert d’aluminium, comme sur les lampes à incandescence PAR, alors que le traitement de surface n’est pas utile.

Il faut casser 3 pions pour séparer le PCB de la lentille en plastique et du radiateur en aluminium.

On y découvre une seule LED et un dissipateur thermique derrière la lentille.

Inspection visuelle

Aucun composant n’est visuellememt abimé, et l’assemblage semble de bonne qualité, avec la présence d’une plaque d’aluminium qui sert de dissipateur thermique.

Il y a quelques traces de chauffe :

• Les residus de flux autour de chaque soudure sont marron au lieu de transparent à jaune clair
• Quelques soudures sont sèches et possiblement fissurées (C2, F1)
• R4 est oxydée avec de reflets violets

Marquages

Le PCB a les marquages suivants :

BOM

La datasheet du contrôleur indique le courant dans la LED en fonction de la valeur des résistances de shunt, ici, avec R2 et R3 en parallèle.

$$I_{LED} = \frac{600 mV}{2 \cdot R_{CS}} = \frac{600 mV}{2 \cdot 2.08 \Omega} = 144 mA$$

Schéma

Le schéma est très proche de celui donné en exemple de la datasheet du contrôleur.

Test

Lampe

L’alimentation buck est simple, et la datasheet ne mentionne pas de tension minimale autre que pour le régulateur de tension interne.

On peut brancher une alimentation de labo sur les pins L et N, et augmenter progressivement la tension. La LED commence à éclairer faiblement vers 20V, puis éclaire de façon nominale à partir de 28V.

LED

On peut aussi alimenter directement la LED avec une alimentation limitée en courant, pour caractériser la LED.

En observant la LED et en l’alimentant avec une très faible tension, on distingue plusieurs dies dans un seul package, on peut s’attendre à une tension de seuil largement plus élevée que 3V. On mesure $V_f = 20V$ en pratique.

Or, la datasheet de la LED indique $V_f = 9.6V$. Il est possible qu’il y ait eu plusieurs révisions de lampe et de datasheet qui ne correspondent pas.

Müller-Licht 42850

Le boitier s’ouvre en séparant la lentille du corps de la lampe, puis en séparant un premier PCB sur lequel sont montées 8 LEDs, et donne accès à un autre PCB d’alimentation qui est serti dans le boitier.

Il peut-être nécessaire d’utiliser une lame pour enlever la colle de la lentille et du premier PCB. Il faut faire attention à ne pas casser le connecteur blanc en soulevant le premier PCB, mais il n’y a pas d’alternative autre que de casser les fils sertis dans le connecteur GU10 pour démonter le second PCB.

Sans surprise, le boitier est en plastique, mais la lentille est aussi en plastique, et le PCB sur lequel les LEDs sont assemblées utilise un substrat en aluminium pour améliorer la dissipation thermique.

L’assemblage semble de qualité moyenne, il reste des traces de colle et même des traces d’étain laissées lors de la soudure par vague.

Marquages

Le boitier et l’emballage ont des logos CE, TÜV et GS conformes, on peut s’attendre à un niveau de sécurité minimal.

Le PCB contenant les LEDs a les marquages suivants :

Le PCB de l’alimentation a les marquages suivants :

BOM

Schéma

Le schéma est très proche de celui donné en exemple de la datasheet du contrôleur, et utilise une structure inhabituelle.

Test

Lampe

L’alimentation à l’air simple et ne devrait pas avoir de chute de tension de plus de quelques volts. On devrait pouvoir l’alimenter avec une tension proche de celle des LEDs.

On peut brancher une alimentation de labo sur les pins L et N, et augmenter progressivement la tension. Les LEDs commencent à éclairer vers 48V, puis éclairent encore faiblement à 50V, la tension maximale de mon alimentation.

LED

On peut aussi alimenter directement le PCB de LEDs avec une alimentation limitée en courant, pour caractériser les LEDs.

J’ai mesuré un $V_f$ total supérieur à 45 V, ce qui suppose qu’il y a deux LEDs par package, soit 16 LEDs au total.

Résultats

Les spécifications de la lampe Müller semblent optimistes pour la qualité des composants et leur assemblage, et la lampe Osram à l’air d’avoir été construite avec des restes de lampes halogènes. L’échantillon de test ne permet pas de conclure sur la durée de vie réelle, décevante dans les deux cas.

Références

Six Easy Pieces

J’avais lu plusieurs livres de Richard Feynman l’an dernier, et je me suis dit que ça serait intéressant de continuer.

Ici, ce n’est plus de la vulgarisation, mais des chapitres extraits cours de sciences physiques destinés à des élèves en première et deuxième année d’études en sciences physiques à Caltech.

À mon avis, il faut quelques bases en sciences pour comprendre les explications, même si les calculs simplifiés et les schémas permettent d’éviter les maths complexes en se limitant aux ordres de grandeurs. Les sujets sont expliqués de façon simple, puis développés en systèmes complexes avec une approche bottom-up.

Asif m’avait aussi conseillé le cours Quantum Physics I du MIT¹, comme complément à ce livre, que je recommande à mon tour.

Automotive Handbook

J’ai souvent feuilleté ce livre que j’avais vu dans plusieurs entreprises où j’ai travaillé, y-compris éloignées de l’automobile, et que beaucoup de gens du domaine considèrent comme une bible de la science et de l’ingéniérie appliquée à l’automobile.

Le livre commence par des définitions, principes et règles physiques et mathématiques, puis continue avec de l’ingéniérie de base : matériaux, usinage, accouplements. Ensuite, il est possible d’expliquer la physique appliquée à un véhicule, puis toute l’ingéniérie embarquée dans une voiture : châssis, transmission, types de moteurs, fluides, dépollution, électrification, électronique embarquée, sécurité, assistances.

C’est un livre destiné à n’importe quelle personne avec des besoins précis ou généraux à propos d’ingéniérie, et qui n’est pas restreint à l’automobile. Le livre est très complet et mérite sa réputation.

Lumière et Luminescence

C’est un livre de vulgarisation scientifique dont le contenu est, à mon avis, intéressant et présenté de façon intéressante.

Une caractéristique inhabituelle est que le sujet soit présentée de plusieurs façons différentes pour attirer le lecteur en fonction de ses intérêts. Par exemple, la lumière y est abordée par l’optique avec les approches des particules et des rayonnements, mais aussi par la chimie, la biologie, et aussi l’histoire des découvertes/inventions et les langues.

Les explications sont assez claires avec des schémas en plus du texte et ressemblent beaucoup à celles présentes dans les livres de sciences physique des années 2000. Le fait que l’auteur soit à la fois chercheur et impliqué dans l’enseignement n’est probablement pas un hasard.

À mon avis, les explications sont abordables avec un niveau de lycée, vu que tout est expliqué de façon qualitative. Et si le lecteur a quelques bases en sciences, il est possible de comprendre quelques explications quantitatives dans des parties encadrées.

Sciences et Vie

J’ai trouvé des magazines Sciences et Vie datant de 1950.

C’est un magazine encore publié, et réputé pour vulgariser la science et la technologie, avec des sujets souvent futuristes.

C’est l’occasion de voir comment certaines technologies futuristes des années 50 ont vieilli. Beaucoup d’articles n’ont pas eu les applications présentées, par exemple, l’énergie nucléaire nécessite des contraintes de sécurité, et les éoliennes actuelles ont des caractéristiques mécaniques et électriques totalement différentes des suppositions de l’époque.

D’autres articles présentent des technologies expérimentales qui se sont développées de la même façon qu’elles ont été présentées dans les articles, plusieurs décennies après, comme les réacteurs d’avions (post-combustion, injection d’eau/MW50, “high-bypass”).

Il reste des articles que j’ai trouvés remarquables :

De Havillant Comet

Un article décrit l’avion De Havilland Comet, qui était le premier avion de passagers moderne, avec des moteurs à réaction et une cabine pressurisée, sans différence majeure avec les avions actuels. Une des caractéristiques remarquables mentionnées dans l’article est la présence de grands hublots.

Or plusieurs années après la publication du magazine, cet avion a causé des dizaines d’accidents mortels dus à sa structure fragile² :

• Les larges hublots concentrent les efforts dans certaines zones de la structure
• L’alumimium utilisé pour la structure est sensible à la fatigue
• La cabine de l’avion étant pressurisée, une fissure peut déclencher une décompression explosive et détruire l’avion en vol

Photographie

L’article y présente plusieurs améliorations techniques concernant la photographie :

• Photographie sous-marine : éclairage artificiel, papier/film/filtres corrigeant l’absorption du spectre lumineux par l’eau, mise-au-point affectée par l’indice de réfraction de l’eau, appareils photo résistants à la pression
• Lampes flash :
  • Lampes à décharge ou éclateurs à air
  • Plusieurs lampes synchronisées
  • Impulsion la plus puissante possible pour des expositions courtes (30MW pendant 1us, soit 30J)
  • Possibilité de photographier une balle de pistolet à 300m/s
• Fluographie : ajout d’une poudre fluorescente à un objet éclairée uniquement par de la lumière UV, pour en photographier son relief, et potentiellement le superposer à une photo en couleur
• Photographie monochrome : permet d’utiliser du papier et du film plus simple, sans distortion, et d’utiliser un éclairage puissant et efficace sans être dérangé par leur mauvais rendu de couleurs
• Améliorations de la partie optique des appareils photo :
  • Verres à l’épaisseur et au stigmatisme contrôlés par interférences
  • Précision de mesure de l’ordre de 1um, précision d’assemblage de l’ordre de 10um
  • Ajout d’un télémètre à mire pour ajuster la mise-au-point, l’ancêtre de l’autofocus

Les systèmes actuels à capteurs numériques sont différents, mais partagent des contraintes : lentilles précises, surface photosensible, compromis éclairage/durée-d’exposition/sensibilité, zoom, mise-au-point précise. Il est aussi intéressant de voir que des systèmes similaires servent à la lithographie de circuits intégrés.

Approche thermomécanique de la tribologie à grande vitesse - Application au freinage

Je me suis longtemps posé des questions sur le rodage des freins à disques de vélo et de voiture.

L’approche qualitative est simple : il faut que le disque et les plaquettes se pré-usent pour que chaque objet prenne la forme de l’autre, pour que toute la surface de la plaquette soit en friction sur le disque. Mais on entend aussi parler de procédures de rodage plus complexes, incluant notamment des cycles thermiques.

Ces procédures de rodage fonctionnent mais manquent d’explications : comment est-ce que ça fonctionne et pourquoi un rodage relativement complexe est-il nécessaire ?

La thèse présente différentes explications :

• Modélisations des différents éléments de freinage
• Approche tribologique :
  • Friction
  • Adhésion
  • Dépôts de matière des plaquettes vers le disque, permettant l’adhésion
• Approche thermique :
  • Rayonnement
  • Transferts thermique dans la matière et sur la surface de contact
  • Points-chauds
• Approche combinée :
  • Coefficient de frottement dépendant de la température, et aussi légèrement de la pression
  • Usure croissante avec la température
  • Validation du comportement de différents matériaux de frictions
  • Caractérisation de matériaux de friction

La thèse permet de comprendre la procédure de rodage :

1. Usure abrasive à vitesse réduite et faible température :
   • Usure de la couche d’oxyde/peinture du disque
   • Usure de la surface des plaquettes à la forme de la surface du disque, pour éviter l’apparition de points-chauds plus tard
2. Usure et adhésion avec des cycles thermiques progressifs, à vitesse plus élevée et sans arrêt complet :
   • Fin progressive de la pré-usure
   • Mise-en-place des plaquettes à chaud
   • Transfert de matériau de friction des plaquettes vers le disque
   • Refroidissement progressif, évitant de déformer le disque et de coller les plaquettes

Elle permet aussi de comprendre ce qu’il ne faut pas faire en utilisation normale :

• Une température trop élevée lorsque le rodage est incomplet glace les plaquettes par l’apparition de points-chauds
• Un rodage partiel empêche le transfert de matériau de friction, et rend les freins peu efficaces
• Une température de fonctionnement trop élevée dégrade le coefficient de friction mais use extrémement vite les matériaux organiques, et peut les dégrader de façon irréversible
• Un refroidissement non-uniforme déforme les matériaux et peut éventuellement les fissurer

This AD906WA/01 wireless receiver came with a LX3950W/01 home theater system and was paired to an AD906WT/01 transmitter¹.

Around the mid-2000s, wireless transmitters were offered for home theater systems, as a way to connect the rear speakers without long cables going across a room².

The wireless transmitter was connected to a specific output on the audio player or amplifier, and it was paired to a matching wireless receiver + amplifier that could power two speakers.

PCB markings are included for SEO, in case someone else might find this while playing with their Philips wireless systems.

Inside view

There are 3 PCBs :

• Switching PSU
• Power amplifier
• RF receiver

PSU

This is a 150mm*75mm, single-layer PCB. It looks like there are 2 flyback supplies, one with a small transformer, likely for a low-power output, and one with a larger transformer and two outputs, likely for the power amplifier.

Interestingly, there’s no monolithic IC. The control-side only has semiconductors in SOT-23 package.

Specifications

The sticker specifies the following data:

• Model: AC6121
• Input 100~240V 50-60Hz 0.34A
• Output:
  • +29.5V/0.16A
  • -29.5V/0.16A
  • 10V/0.2A

Connectors

There are 3 connectors on the PCB:

• J1: AC input, unearthed
• J2: Power output
• J3: Standby output

J2 pinout

J3 pinout

The signal on the pin 1 seems to act as a power good signal. This would need to be confirmed.

PCB markings

• Sticker:
  • AC6121
  • P42859578
• Top side:
  • TF-03
  • 94V0 UL
  • SIDE A
  • 855D-016K
  • PI ELECTRONICS
• Bottom side:
  • SIDEB
  • U.S. PAT 5,986,905

Amplifier

This is a 100mm*90mm, dual-layer PCB with a heatsink.

Connectors

1100 pinout

1. Power output L
2. GND
3. GND
4. Power output R

1104 pinout

Warning the markings are reversed compared to the PSU.

1. +29.5V
2. GND
3. GND
4. -29.5V

1106 pinout

1. Audio input R
2. GND
3. Audio input L
4. 10V output
5. GND
6. ?
7. Red LED input

1107 pinout

1. 10V input
2. GND
3. PG input?

BOM identification

LEDs

• 6109: Green, Power-on
• 6110: Red, receiver paired

PCB markings

• Top side:
  • PS 2002
  • 94V-0 UL (PCB substrate flammability rating)
  • 2004 (datecode)
• Bottom side:
  • 3104 123 4365. 2

Receiver Board

This is a 90mm*68mm, 4-layer PCB that has one JST connector, one antenna, one RF ASIC in a metal shield, one opamps, one MCU, two analog ASICs, and one unknown chip.

1790 connector pinout

1. Audio output R
2. GND
3. Audio output L
4. 10V input
5. GND
6. ? (3V when powered-on)
7. Red LED output

BOM identification

PCB markings

• Sticker:
  • 864MHz
  • 07520
  • SV0430
  • 04091554
• Top side:
  • 3522 2
  • 2002-12-09
  • 2
• Bottom side:
  • 94V-0 UL, PCB substrate flammability rating
  • ELEC-5
  • E3330BM

Usability

The transmitter isn’t designed to operate without its Philips LX3950W/01¹⁰, which I don’t have, so using the receiver as intended looks compromised.

However, the amplifier works without the RF part, by connecting analog audio signals on the connector 1106: L-R signals on pins 1 and 3, and GND on pin 2.

Funnily, the specsheet gives the “Output power (RMS): 5 x 45 W”¹¹ and the amplifier’s datasheed specifies a maximum power of 70W for each channel, when the receiver can only draw 25W from the power outlet and its PSU delivers 9.44W on its +/- 29.5V rails. That looks questionable.

This is a Class D amplifier, which explains why there’s a low-pass filter on the output, and why the heatsink is rather small for the advertised power.

References

This AD906WT/01 wireless transmitter came with a LX3950W/01 home theater system and was paired to an AD906WA/01 receiver¹.

Around the mid-2000s, wireless transmitters were offered for home theater systems, as a way to connect the rear speakers without long cables going across a room².

The wireless transmitter was connected to a specific output on the audio player or amplifier, and it was paired to a matching wireless receiver + amplifier that could power two speakers.

PCB markings are included for SEO, in case someone else might find this while playing with their Philips wireless systems.

Inside view

This looks like analog RF, pre-dating digital protocols. Stickers specifies that the transmitter operates at 864MHz.

There are 2 PCBs, a complex one connected to the antenna, and a simpler one that seems to be here for interconnection with the RJ45 cable.

Interface board

This is a 95mm*35mm, dual layer PCB that has 4 JST connectors, and only a few analog components around an dual opamp. Many components are unpopulated.

BOM Identification

Connectors pinouts

1100 pinout

1. +12V input
2. GND

1110 pinout

1. ACH1
2. AGND1
3. ACH2
4. AGND2

1120 pinout

1. ACH1
2. GND
3. ACH2
4. +12V output
5. GND
6. GND
7. SCL
8. SDA

1121 pinout

1. SCL
2. SDA

Testpoints

Board overview

• ACH1: 1130.1 -> filters -> Opamp -> filters -> 1120.1
• ACH2: 1130.3 -> filters -> Opamp -> filters -> 1120.3

All other signals are directly connected from the RJ45 to the 1120 connector. It looks like this board was intended to be used in similar standalone products, looking at the unpopulated components that include footprints for a power jack, a switch and RCA inputs.

There’s an unusual amount of filters, including signal transformers. This rather simple board seems to have been designed with EMC considerations.

PCB markings

Bottom side:

• 3104 133 3001.2
• 3104 137 3003.1
• 3104 137 3004.1
• 3104 137 3010.1
• 2104 (datecode)
• 1 94V-0 UL (PCB substrate flammability rating)

Transmitter board

This is a 80mm*65mm, 4-layer PCB that has one JST connector, one antenna, one RF ASIC in a metal shield, 2 opamps, one analog ASIC, one analog multiplexer and one clock generator.

All components seem to be populated.

BOM Identification

1101 connector pinout

1. ACH1
2. GND
3. ACH2
4. +12V input
5. GND
6. GND
7. SCL
8. SDA

PCB markings

• Sticker:
  • 864MHz
  • 07890
  • SV0429
  • 04087553
• Top side:
  • PHILIPS
  • 2003-01-17
  • 3521 4
  • Transmitter
  • Closed side
  • 6
  • 3104 213 3521.4
• Bottom side:
  • 94V-0 UL (PCB substrate flammability rating)
  • ELEC-5
  • E3330E
  • 3104 217-07110-07120-07130
  • 3104 217-07210-07220-07230
  • Philips

RJ45 Cable

1. ACH2
2. AGND
3. ACH1
4. +12V
5. GND
6. GND-shield
7. SCL
8. SDA

Conclusion

This doesn’t seem to be usable without its original equipment or without deeper reverse-engineering, due to the fact the PLL needs I²C data to operate.

References

Le firmware original n’est pas utilisable ni modifiable, il va falloir le remplacer par une distribution de Linux, avec quelques contraintes :

• Mémoire flash limitée à 128MiB, de nombreux cas de mémoire corrompue sont rapportés avec d’autres NAS qui utilisent les mêmes puces
• U-Boot non-modifiable : les sources originales sont modifiées par Nuuo/Promise, et ne sont pas disponibles, ni adaptables pour autre-chose que le firmware original

Installation de Debian

J’ai suivi le guide de Alexei Colin² qui correspond au même système hardware, mais avec un firmware et un environnement différents :

• Mon NAS a un firmware Nuuo avec un kernel compilé sans NFS, contrairement au firmware Patriot Javelin S4 et sûrement au Promise NS4600p
• Mon réseau local était assez simpliste, sans serveur NFS au moment où j’ai installé Debian

On peut commencer avec le matériel suivant :

• NAS Nuuo/Patriot/Promise
• UART USB 3.3V (FTDI 232 ou similaire)
• Clé USB >=1GiB
• PC utilisant Linux avec l’adresse 192.168.3.250
• Routeur avec l’adresse 192.168.3.1 (optionnel)

Installation du système Debian de base

On va installer un système de base Debian avec debootstrap³, avec une machine Linux, de la même façon que proposée par le guide⁴, avec quelques différences :

apt-get install debootstrap
mkdir nuuo-rootfs
debootstrap --arch=powerpc --foreign --keyring=/usr/share/keyrings/debian-archive-removed-keys.gpg wheezy nuuo-rootfs/ http://archive.debian.org/debian/

La dernière version de Debian disponible avec l’architecture powerpc est Jessie 8.0, mais j’ai rencontré des soucis de compatibilité avec des noyaux plus récents que le 2.6.32, alors j’ai installé Wheezy 7.0.

Comme il s’agit d’une architecture powerpc, on ne pourra pas utiliser chroot sur la machine hôte, qui est un PC avec une architecture amd64.

Pour continuer, on crée les fichiers de périphériques pour la console série, nécessaires pour la suite de l’installation :

mknod nuuo-rootfs/dev/ttyS0 c 4 64

On utilise l’init par défaut :

cp nuuo-rootfs/usr/share/sysvinit/inittab nuuo-rootfs/etc/inittab

Que l’on modifie pour utililiser la console série, en commentant les lignes concernant les consoles clavier/écran et en décommentant la lignes concernant une console série vt100, avec un baudrate configuré à 115200 bit/s : T0:2345:respawn:/sbin/getty -L ttyS0 115200 vt100.

On choisit le hostname :

echo "nuuo" > nuuo-rootfs/etc/hostname

On configure les systèmes de fichiers en éditant le fichier nuuo-root/etc/fstab

echo "LABEL=tmp / ext3 defaults 1 1" >> nuuo-rootfs/etc/fstab
echo "proc /proc proc defaults 0 0" >> nuuo-rootfs/etc/fstab

Ensuite, on ne suit pas le reste du tutoriel de Alexei Colin puisqu’on ne va pas utiliser NFS.

Spécificité de Devuan

Si le système hôte utilise Devuan au lieu de Debian, il est possible que la commande debootstrap échoue et retourne une erreur à propos de clés introuvables E: Couldn't find these debs: devuan-keyring.

Il est possible de modifier le fichier d’installation du dossier /usr/share/debootstrap/scripts/ correspondant à la distribution, pour y remplacer les clés de Devuan par celles de Debian et corriger l’erreur. On peut par exemple utiliser les regex suivantes avec vi : :%s/devuan-keyring/debian-keyring/g et :%s/devuan-archive-keyring/debian-archive-keyring/g.

Préparation de clé USB

Partitionnement

On choisit arbitrairement une partition de 200 MB en FAT, pour y stocker les images de boot, et une partition de >800MB pour le système temporaire.

Dans mon cas, la clé USB est partitionnée de façon suivante, le boot flag n’est pas nécessaire :

Device     Boot  Start      End  Sectors  Size Id Type
/dev/sdb1  *      2048   411647   409600  200M  6 FAT16
/dev/sdb2       411648 15728639 15316992  7.3G 83 Linux

Partition boot

On va formater la partition en FAT, utilisable par U-Boot, puis copier les fichiers que l’on a récupérés précédemment⁵ en copiant le contenu de la mémoire flash originale :

mkfs.vfat -a /dev/sdb1
mount /dev/sdb1 /mnt
cp nuuo_mtd/mtd{0,1,2,3,4,5} /mnt/
umount /mnt

Partition root

On va formater la partition en ext3, utilisable par Linux, puis copier l’installation temporaire debootstrap :

mkfs.ext3 -L tmp /dev/sdb2
mount /dev/sdb2 /mnt
cp -a nuuo-rootfs/* /mnt/
umount /mnt

Syncronisation

Il est probable de rencontrer des erreurs qui nécessitent de modifier le contenu de la clé USB, ou le système pré-installé sur le système hôte. Rsync permet de ne copier que les fichiers qui ont été modifiés.

Pour copier du système hôte vers la clé usb, on utilise la commande suivante :

rsync -av --delete-after nuuo-rootfs/ /mnt/

Et pour syncroniser de la clé USB vers le système hôte, on utilise la commande suivante :

rsync -av --delete-after /mnt/ nuuo-rootfs/

Attention à ne pas se tromper de sens, au risque d’écraser des modifications.

Premier démarrage

On connecte la console série au connecteur J1⁶, on alimente le NAS, et on appuie sur Ctrl-C quand U-Boot le propose.

On peut connecter la clé USB sur le port USB du NAS⁷, et taper la commande usb start :

(Re)start USB…

USB: scanning bus for devices… 2 USB Device(s) found

scanning bus for storage devices… 1 Storage Device(s) found

On va ensuite définir les variables d’environnement de U-Boot nécessaires au démarrage, puis charger les images en mémoire et booter :

setenv bootargs root=LABEL=tmp rw console=ttyS0,115200
fatload usb 0:1 0x1200000 mtd4; fatload usb 0:1 0x1b00000 mtd5; fatload usb 0:1 0x1a00000 mtd1
bootm 1200000 1b00000 1a00000

Difficultés

Le fonctionnement est aléatoire, j’ai essayé différentes clés USB, différentes tailles/alignements de partitions et différentes options de FAT. Il est possible que ça ne soit pas assez fiable.

J’ai aussi testé les images de Patriot Javelin et une image compilée par Alexei Colin⁸, cette dernière a le plus de fonctionalités.

Seconde tentative

U-boot permet de récupérer des fichiers avec le protocole TFTP. J’ai déjà le serveur tdtpd-hpa installé sur ma machine avec l’adresse 192.168.3.250, à la racine /srv/tftp/.

Il reste à copier les images :

cp nuuo_mtd/mtd{0,1,2,3,4,5} /srv/tftp/
cp javelin-alexeicolin/*.img /srv/tftp/

Il peut être nécessaire de définir les variables suivantes pour pré-configurer le réseau si on n’utilise pas le protocole DHCP :

setenv ipaddr 192.168.3.181
setenv serverip 192.168.3.250
setenv bootargs root=LABEL=tmp rw console=ttyS0,115200 init=/bin/sh

On peut ensuite charger les fichiers dans la RAM du NAS et démarrer :

tftpboot 0x1200000 192.168.3.250:kernel.img; tftpboot 0x1b00000 192.168.3.250:ramdisk.img; tftpboot 0x1a00000 192.168.3.250:dtb.img
bootm 1200000 1b00000 1a00000

Si tout fonctionne correctement, la machine doit démarrer et retourner un shell root.

Suite de l’installation

On va poursuivre l’installation et choisir un mot-de-passe root :

mount -o remount,rw /
debootstrap/debootstrap --second-stage
passwd

On redémarre pour continuer l’installation avec une init normale :

setenv ipaddr 192.168.3.181
setenv serverip 192.168.3.250
setenv bootargs root=LABEL=tmp rw console=ttyS0,115200
tftpboot 0x1200000 192.168.3.250:kernel.stock.img; tftpboot 0x1b00000 192.168.3.250:ramdisk.stock.img; tftpboot 0x1a00000 192.168.3.250:dtb.img
bootm 1200000 1b00000 1a00000

On peut se logguer en tant que root, avec le mot-de-passe choisi précédemment, et commencer par régler la date :

# date 111614302025

Sun Nov 16 14:30:00 UTC 2025

La pile de l’horloge RTC semble défectueuse, on va installer ntp et la remplacer à la prochaine occasion.

Puis on va configurer le réseau :

echo "nameserver 192.168.3.1" >> /etc/resolv.conf
ifconfig eth0 192.168.3.4
route add default gw 192.168.3.1

On va rajouter les informations correspondantes dans le fichier /etc/network/interfaces, pour rendre la configuration permanente. Ensuite, on va s’assurer que les paquets net-tools ifupdown udev util-linux mtd-utils soient bien installés, et on va installer les paquets ssh screen.

SSH permet d’utiliser le réseau plutôt que la console série, le débit y est plus rapide, et screen permet d’utiliser plusieurs terminaux.

Installation sur un disque-dur

On arrête le NAS, puis on connecte la clé USB sur le système hôte, pour la monter, copier et ensuite archiver son contenu :

mount /dev/sdb2 /mnt
rsync -av --delete-after /mnt/ nuuo-rootfs/
tar cf nuuo-rootfs.tar nuuo-rootfs/
cp nuuo-rootfs.tar /mnt/
umount /mnt/

On peut ensuite reconnecter la clé USB sur le NAS, en s’assurant que le disque dur est bien branché, et ajoutant la commande scsi init en plus des commandes du démarrage précédent :

setenv ipaddr 192.168.3.181
setenv serverip 192.168.3.250
setenv bootargs root=LABEL=tmp rw console=ttyS0,115200
scsi init
tftpboot 0x1200000 192.168.3.250:kernel.img; tftpboot 0x1b00000 192.168.3.250:ramdisk.img; tftpboot 0x1a00000 192.168.3.250:dtb.img
bootm 1200000 1b00000 1a00000

On peut ensuite se logguer en tant que root et s’intéresser aux périphériques de stockage avec la commande blkid.

# blkid

/dev/sda1: LABEL=“qwerty-123” UUID=“55b5f9b0-8b69-4ae3-ba6d-e88e97298a06” TYPE=“ext4”

/dev/sda3: LABEL=“qwertz-456” UUID=“ee406156-dd46-4d0c-a867-ce8179e49ac5” TYPE=“ext4”

/dev/sdb1: SEC_TYPE=“msdos” LABEL=“BOOT” UUID=“65FB-66D9” TYPE=“vfat”

/dev/sdb2: LABEL=“sys” UUID=“70e37124-f816-4da0-b41c-09a51ea9c273” TYPE=“ext3”

On va effacer la table de partitions et le début du disque dur avec la commande suivante :

dd if=/dev/zero of=/dev/sda bs=1k count=1k

Attention à bien identifier le disque dur et à s’assurer qu’il ne contienne pas de données utiles. Cette commande est destructrice.

On va utiliser parted pour partitionner le disque dur :

parted /dev/sda --align optimal mktable gpt
parted /dev/sda --align optimal mkpart primary 0% 200MB     # boot
parted /dev/sda --align optimal mkpart primary 200MB 20GB   # sys
parted /dev/sda --align optimal mkpart primary 20GB 22GB    # swap
parted /dev/sda --align optimal mkpart primary 22GB 100%    # storage

mkfs.ext3 /dev/sda2 -L sys
mkfs.ext3 /dev/sda4 -L storage
mkswap /dev/sda3 -L swap
mkfs.vfat /dev/sda1 -L boot

Il reste à vérifier que le disque est correctement partitionné avec blkid:

# blkid |grep sda

/dev/sda1: LABEL=“boot” UUID=“9EA9-6FD2” SEC_TYPE=“msdos” TYPE=“vfat”

/dev/sda2: LABEL=“sys” UUID=“7553bf9a-f2ca-48b2-ba04-336a2d49984e” SEC_TYPE=“ext2” TYPE=“ext3”

/dev/sda3: LABEL=“swap” UUID=“30a216ca-b0fa-4ec0-901f-326c3fe0d8cb” TYPE=“swap”

/dev/sda4: LABEL=“storage” UUID=“938d68d2-c0e9-44e5-a2e6-eb0c0a9f31f3” SEC_TYPE=“ext2” TYPE=“ext3”

C’est correct, il reste à monter la partition sda2 et extraire l’archive que l’on avait préparée :

mount /dev/sda2 /mnt/
cp /nuuo-rootfs.tar /mnt/
cd /mnt; tar xf nuuo-rootfs.tar
mv /mnt/nuuo-rootfs/* /mnt/
rm /mnt/nuuo-rootfs* -r

Il reste à configurer une subtilité : le fichier /mnt/etc/fstab :

LABEL=sys / ext3 defaults 1 1

LABEL=boot /boot vfat defaults 1 2

LABEL=swap none swap sw 0 0

LABEL=storage /media/stuff ext3 defaults 1 2

proc /proc proc defaults 0 0

Et on peut redémarrer le système et débrancher la clé USB en adaptant le nom de partition racine :

setenv bootargs root=LABEL=sys rw console=ttyS0,115200
setenv ipaddr 192.168.3.181
setenv serverip 192.168.3.250
scsi init
tftpboot 0x1200000 192.168.3.250:kernel.img; tftpboot 0x1b00000 192.168.3.250:ramdisk.img; tftpboot 0x1a00000 192.168.3.250:dtb.img
bootm 1200000 1b00000 1a00000

On peut se logguer en tant que root et vérifier que la machine fonctionne.

Configuration de U-Boot

Maintenant, on va configurer U-Boot pour se passer de serveur TFTP et de clé USB.

setenv bootargs root=LABEL=sys mtdparts=nand0:1024K(u-boot),512K(dtb),3072K(safe-k),8192K(safe-r),3072K(kernel),8192K(rootfs),16384K(usr),2048K(data),1024K(oem),87552K(app) console=ttyS0,115200

setenv newnandboot "run bootargs; scsi init; nand read.e 1200000 kernel 300000; nand read.e 1b00000 rootfs 800000; nand read.e 1a00000 dtb 3000; bootm 1200000 1b00000 1a00000"

setenv newscsiboot "run bootargs; scsi init; fatload scsi 0:1 0x1200000 kernel.img; fatload scsi 0:1 0x1b00000 ramdisk.img; fatload scsi 0:1 0x1a00000 dtb.img; bootm 1200000 1b00000 1a00000"

setenv bootcmd run newnandboot
saveenv

On a défini la commande newnandboot qui va initialiser les disques durs, puis charger les images de noyau et de ramdisk dans la mémoire flash, et on a défini cette commande de démarrage par défaut. La dernière commande permet de sauvegarde la configuration de U-Boot.

Maintenant, on va démarrer une dernière fois avec TFTP :

setenv ipaddr 192.168.3.181
setenv serverip 192.168.3.250
scsi init
tftpboot 0x1200000 192.168.3.250:kernel.img; tftpboot 0x1b00000 192.168.3.250:ramdisk.img; tftpboot 0x1a00000 192.168.3.250:dtb.img
bootm 1200000 1b00000 1a00000

On va se logguer en tant que root, et on va copier les images de Alexei Colin⁹ que l’on avait copiées sur la clé USB :

mount /dev/sdb1 /mnt
cp /mnt/{kernel, ramdisk}.img /root/

Puis on va les écrire dans la mémoire flash. Attention, il faut s’assurer de ne rien écraser et d’écrire dans la bonne section.

nandwrite -p -m /dev/mtd4 /root/kernel.img
nandwrite -p -m /dev/mtd5 /root/ramdisk.img

Les redémarrages suivants fontionnent automatiquement, en tapant simplement la commande boot, sans qu’une clé USB ni qu’une connexion réseau ne soit nécessaire.

Alternative

Comme la mémoire flash n’est pas réputée fiable et n’est pas aussi facile à modifier qu’une partition de disque dur, on a crée une partition /boot formatée en FAT, et on a défini la commande newscsiboot précédent, qui charge les images depuis le disque dur.

Il suffit de copier les fichiers kernel.img, ramdisk.img et dtb.img dans /boot/, et de taper les deux commandes U-Boot :

setenv bootcmd run newscsiboot
saveenv

Suite de l’installation

Le NAS Nuuo est utilisable comme n’importe quel NAS ou serveur. Il peut-être utile de regarder l’article précédent¹⁰ pour corriger les problèmes de U-Boot.

Il est possible de suivre les articles suivants pour ajouter des fonctionalités :

• Serveur hébergé - 2025
• Serveur DIY - 2016
• Serveur DIY - 2007

Comme la distribution Debian Wheezy est ancienne et n’a plus de mises-à-jour de sécurité, il est recommandé de ne pas trop l’exposer à internet. L’utilisation de chroot avec des programmes plus récents et cloisonnés peut convenir.

Références

J’ai aussi lu ces autres guides. Ils ne sont pas applicables directement à mon cas, mais ils confirment des informations utiles :

• Promise SmartStor - Dobrica Pavlinušić’s random unstructured stuff
• yop0382/ns4600p - Github
• Heavy duty Javelin hacking - Patriot Memory

Pour des raisons inexpliquées, U-Boot n’alimente pas les périphériques SATA ni les périphériques USB lors du démarrage. Ça peut fonctionner avec le firmware original qui n’utilise que la mémoire flash, mais pas dans mon cas : seuls le noyau et l’initrd sont stockés dans la mémoire flash. Le reste de l’OS est stocké sur un disque-dur SATA.

Sauf qu’il est possible de démarrer lorsque l’on interrompt le démarrage automatique de U-Boot, puis que l’on tape une commande pour continuer son exécution.

Test manuel

On branche un PC avec un adaptateur USB-Série 3.3V sur le connecteur J1¹, on alimente le NAS, et on regarde ce qu’il affiche dans un terminal :

U-Boot 1.3.4 (NS4600p - 014 - 800MHz) (Nov 04 2010 - 14:03:07)

CPU:   AMCC PowerPC 431EXr at 800 MHz (PLB=200, OPB=100, EBC=100 MHz)
    Security/Kasumi support
    Bootstrap Option F - Boot ROM Location NAND (8 bits), booting from NAND
    Internal PCI arbiter disabled
    32 kB I-Cache 32 kB D-Cache
Board: NS4600p - PROMISE 4-bay NAS Target Board, 1*PCIe/1*SATA
I2C:   ready
DRAM:  256 MB
Enclosure: Load fan configurations from VPD
NAND:  128 MiB
eth0 MAC = 00:01:55:31:1f:21
eth1 MAC = 00:00:00:00:00:00
PCI:   Bus Dev VenId DevId Class Int
PCIE1: successfully set as root-complex
        01  00  105a  3f20  0104  00
SCSI:  Net:   ppc_4xx_eth0

Hit Ctrl + C to stop autoboot: 10

Si on n’appuie pas sur Ctrl-C, U-Boot charge le noyau et l’initrd en mémoire, mais n’alimente pas les disques, le noyau ne trouve pas de disque-dur et plante².

Si on appuie sur Ctrl-C, U-Boot exécute quelques commandes avant de donner un shell :

Leave clock generator PD mode... OK
Leave net PHY PD mode... OK
Turn on all activity LED power... OK
FAN_SET mode... OK
Turn off all status LED... OK
Turn on disk power... OK
=>

On entend bien les disques SATA démarrer, on peut taper boot, et la machine démarre correctement, puisque le noyau est capable de détecter les disques-durs.

Automatisation

Exécuter une opération manuelle à chaque démarrage n’est pas très pratique, surtout en cas de re-démarrage imprévu. Comme l’opération est simple, on va utiliser un microcontrôleur.

Il faut les spécifications suivantes :

• Alimentation 3.3V
• UART 115200 bits/s 8N1

Arduino

Par habitude, l’environnement de développement Arduino est pratique pour des prototypes simples, et la variante hardware Pro Mini³ est compacte et s’alimente en 3.3V.

Je rencontre quelques soucis : il m’est impossible de faire fonctionner l’UART correctement à 115200 bit/s, puisque les cartes alimentées en 3.3V ont un quartz à 8MHz, et des diviseurs d’horloge qui ne permettent pas à l’UART de fonctionner à la bonne fréquence⁴.

J’avais commencé par suspecter les bibliothèques Arduino, avant d’utiliser le MCU bare-metal. Le code est plus long à écrire, mais l’exécution est plus rapide et on contrôle précisément ce que l’on fait. Comme mon problème d’UART était matériel, il n’a pas été résolu.

MSP430

J’ai une carte d’évaluation de MSP430 et un MSP430G2553 en stock, qui correspondent aux besoins⁵, avec l’intérêt supplémentaire d’avoir un oscillateur interne assez précis pour qu’aucun quartz ne soit nécessaire.

Energia

Energia est un port d’Arduino pour MSP430, qui permet de prototyper rapidement⁶.

L’intérêt est surtout de fournir une chaîne de développement quand les paquets ne sont plus présents dans Debian depuis 2019⁷.

Pour utiliser la chaîne de développement sans l’IDE, il suffit d’adapter la commande suivante à l’endroit où les fichiers de Energia sont présents :

export PATH=$PATH:/opt/energia-1.8.10E23/hardware/tools/msp430/bin/

Le fonctionnement de Energia est correct, mais j’ai rencontré le même problème qu’avec le bibliothèques Arduino : le fichier exécutable est volumineux, et son exécution est lente. Ça fait une bonne excuse pour utiliser le MCU bare-metal.

Code

Le programme est construit avec deux machines d’état, et la réception des caractères se fait par interruptions.

On utilise un scheduler minimaliste⁸, où une interruption de timer va exécuter ce scheduler à 1kHz, qui va utiliser des variables (milliseconds et seconds) pour exécuter d’autres tâches. Ça permet de désactiver le CPU hors des interruptions, pour consommer moins d’énergie⁹.

__attribute__ ((interrupt(TIMER0_A0_VECTOR))) void timer_A_ISR(void) {
    milliseconds++;
    if(!(milliseconds % 1000)) {
        seconds++;
    }
    if(!(milliseconds % DELAY_FSM)) {
        fsm();                  // 100 Hz
    }
}

On utilise une machine à 4 états pour recevoir les commandes et envoyer les commandes correspondantes.

void fsm() {
    /*
    * 0: default, listening for 1st string
    * 1: 1st string matched, waiting 100ms, sending '^C'
    * 2: listening for 2nd string
    * 3: 2nd string matched, waiting 100ms, sending "boot\n"
    */
    static unsigned long delay = 0;
    switch(state) {
        case 1:
            if(delay == 0)
                delay = milliseconds;
            if(milliseconds - delay >= 100) {
                putchar(0x03);      // ^C
                delay = 0;
                state = 2;
                //toggle_LED();
            }
            break;
        case 2:
            listening_cond(str2);
            break;
        case 3:
            if(delay == 0)
                delay = milliseconds;
            if(milliseconds - delay >= 100) {
                puts("boot\n");
                delay = 0;
                state = 0;
                clearbuf();
                //toggle_LED2();
            }
            break;
        default:
            listening_cond(str1);
            break;
    }
}

Les LEDs permettent de surveiller l’exécution lorsqu’on va tester la carte en conditions réelles, avec le debugger débranché.

Gestion de l’UART

La pratique par défaut est de stocker les caractères reçus dans un buffer circulaire¹⁰. Ensuite, on peut les extraire dans un buffer linéaire pour le comparer avec les chaînes de caractères de référence.

Ça fonctionne, mais ça utilise beaucoup de mémoire, et le parcours puis la copie du buffer sont lents. Il faut augmenter la taille du buffer pour ne pas rater de caractère, ce qui utilise encore plus de mémoire.

On va plutôt utiliser un buffer linéaire glissant, qui sont habituellement utilisés pour des opérations de filtrage. Le glissement du tableau se fait sur lui-même, et on peut comparer directement ce buffer avec les chaînes de caractères de référence.

Conditions réelles

Une fois les fonctions unitaires et le système validés, on peut brancher la carte d’évaluation au NAS.

Une fois l’alimentation du NAS branchée, les LEDs de la carte d’évaluation s’allument, et les disques durs du NAS se mettent à tourner.

Il ne reste plus qu’à câbler tout ça sur un morceau de plaque à trous.

Le code source est disponible¹¹ sous license CC BY-NC.

Références

As previously, the code is publicly available² under CC BY-NC license.

Getting data

Convergence

One important thing is to see how long an algorithm takes to converge, and make sure they converge. This needs to take the duration of each iteration of loops, as well as the number of iterations.

First, we can simply run our code, sweeping for different iteration numbers, and types of algorithms³:

for algo in circle taylor leibniz sphere euler agm newton_gmp \
machin_gmp archimedes_gmp ramanujan chudnovsky plouffe bellard;
    do for n in 1 2 3 10 30 100 300 1000;
        do ./pi $algo $n;
    done;
done > benchmark

We also need to make the file less human-readable and more machine-readable, to something similar to CSV⁴:

sed -i 's/\,\titerations\:\ /\t/g' benchmark
sed -i 's/,\tpi\ \=\ /\t/g' benchmark
sed -i 's/,\terr\ = /\t/g' benchmark

Execution times

We can compare execution times:

hyperfine --export-json benchmark.json -N -r 10 -w 1 -L algo circle,\
taylor,leibniz,sphere,euler,agm,newton,newton_gmp,machin,machin_gmp,\
archimedes,archimedes_gmp,ramanujan,chudnovsky,plouffe,bellard \
-L n 1,2,3,10,30,100,300,1000 "./pi {algo} {n}" -i

Hyperfine returns a JSON file that’s completely different than the CSV file we built. Having both execution times and accuracy in a single file would be nicer.

We can do that using jq wrapped around some bash code:

rm benchmark2.json;
for algo in circle taylor leibniz sphere euler agm newton_gmp \
machin_gmp archimedes_gmp ramanujan chudnovsky plouffe bellard;
    do for n in 1 2 3 10 30 100 300 1000;
        do pi=$(grep ^$algo$'\t'${n}$'\t' benchmark | awk '{ print $3}');
        diff=$(grep ^$algo$'\t'${n}$'\t' benchmark | awk '{ print $4}');
        echo $(cat benchmark.json |jq -r ".results[] | \
        select(.parameters.n == \"$n\" and .parameters.algo == \"$algo\") | \
        .pi="$pi" |.diff="$diff"")$',' >> benchmark2.json;
        # match parameters.n and parameters.algo from the json file with $n
        # and $algo from the csv file, adds $pi and $diff from the CSV file,
        # adds a comma and write to benchmark2.json
    done;
done;
sed -i '1s/^/{"results": [\n/' benchmark2.json; # adds a file header
sed -i '/^,$/d' benchmark2.json;    # remove commas from blank lines
truncate -s -2 benchmark2.json      # removes the last comma and \n
echo "\n]}" >> benchmark2.json      # closes brackets at the end of the file

This builds a new JSON file based on the content of the old JSON and CSV files.

Plots

We can simply display the content of the CSV file with a line plot:

This shows everything, although it’s not easy to read.

Instead, we can build a Python script to display the data we collected into the JSON file. This gives barplots showing the execution time and the accuracy relative to the iteration number for each algorithm.

Both informations are interesting, but what’s important is actually the compromise between execution time and accuracy.

To address that, we can compute a figure of merit by multiplying the execution time and the accuracy, without any coefficients. In this case, a smaller number means that an algorithm is both quick and accurate.

First conclusions

That enables us rate algorithms, or actually their implementation, based a few things:

• Missing data:
  • Failed computation
  • Accuracy better than 64-bit numbers
• Convergence that stops: accuracy limited by implementation
• Convergence speed
• Increasing figure of merit after a number of iteration:
  • Stalled algorithm
  • Accuracy limited by implementation

Algorithm ratings

Algorithms shown in bold can be implemented again for better results.

Algorithms shown in italic have been tested with gmp_printf() to get rid of the 64-bit float limit.

Description

Le débimètre est placé juste après le filtre à air, et mesure le débit massique d’air absorbé par le moteur.

Cette mesure de débit d’air permet d’ajuster précisément la quantité de carburant injectée, pour s’adapter à différentes conditions de fonctionnement. Avec un moteur Diesel, l’utilité principale est d’éviter d’injecter plus de carburant que nécessaire pendant les phases transitoires, quand le turbo ne fournit pas encore la pression nominale, et ainsi d’éviter de polluer inutilement.

Ce type de capteurs est parfois aussi monté sur des moteurs à essence.

Documentation

D’après les documentations de Bosch²³, la référence 0 281 006 759 est un modèle aftermarket. Il utilise un capteur HFM-7R5, avec traitement de signal numérique et une sortie analogique compatible avec les versions HFM-5 analogiques, plus anciennes.

On peut en voir plusieurs choses intéressantes :

• Connecteur à 5 pins
• Tension d’alimentation : 8-17 V
• Tension de référence : 5 V
• Mesure de débit par film chaud
• Capteur de température optionnel
• Technologie MEMS

Teardown

C’est un cylindre creux de 80mm de diamètre et 110mm de long, avec un guide venturi de 35mm de diamètre.

Les vis Pentalobe ne suffisent pas à nous empêcher d’accéder au capteur.

Test

La documentation d’un autre débimètre HFM-5 donne le brochage du connecteur.

1. Capteur de température (non-présent)
2. +12V, alimentation
3. GND
4. +5V, référence
5. Signal

On va construire un banc de test, avec un ventilateur qui force un flux d’air dans le débimètre, à travers un guide en carton.

Si on regarde les spécifications du ventilateur⁴, on peut remarquer 4.84~5.38 m³/min dans des conditions nominales, qui correspondent à 334~371 kg/h.

Le moteur VW BKD est un moteur Diesel à 4 temps, qui aspire idéalement un volume d’air correspondant à la moitié de sa cylindrée à chaque rotation. Il y a aussi un turbo qui fournit une pression de 1 bar, ce qui correspond à un volume d’air deux fois plus élevé qu’à la pression atmosphérique. Ce moteur a un régime maximal de 5’000 rpm.

$$Q_m = Displacement \cdot \frac{rev}{2} \cdot (P_{Atm} + P_{Boost}) \cdot D_{Air}$$

$$Q_m = 2 \cdot 10^{-3} m^3 \cdot \frac{1}{2} \cdot 5'000 RPM \cdot 60 min/h \cdot (1 + 1) bar \cdot 1.15 kg/m^3$$

$$Q_m = 690 kg/h$$

Les ordres de grandeur correspondent : la pleine échelle du capteur est de 850 kg/h, et notre ventilateur devrait fournir autour de 350 kg/h.

Fonctionnement

On commence par clipser le débimètre et le ventilateur dans le guide en carton pour observer ce que le capteur revoie.

On lit 0.99 V avec le ventilateur arrêté, et 2.54 V avec le ventilateur tournant.

Le capteur et le système fonctionnent, on peut vérifier l’absence de fuites et tester différentes configurations.

On remarque que les valeurs mesurées sont instables et que le ventilateur consomme plus lorsqu’il souffle à travers le capteur plutôt que lorsque il aspire. Il est possible qu’il y ait des turbulences. La configuration typique aspire de l’air à travers le capteur, dans un long conduit qui évite les turbulences.

Mesure du ventilateur

Le ventilateur est placé dans un conduit qui résiste à l’air, on ne peut pas utiliser les valeurs nominales données par le constructeur⁵. On va aussi faire varier la vitesse du ventilateur, or la relation entre le débit et la vitesse n’est pas linéaire, ce qui rend les mesures indispensables.

On mesure la durée nécessaire au remplissage d’un sac étanche de volume connu pour en déduire le débit du ventilateur.

Mesure du débimètre

Le ventilateur est calibré, il ne reste plus qu’à noter les valeurs mesurées par le capteur :

La forme de la courbe correspond à celles données par tous les types de capteurs Bosch HFM-5⁶.

Résultats

D’autres personnes ont déjà produit ce type d’expériences⁷ pour corréler des capteurs entre eux, et ils utilisent aussi un capteur Bosch 0 281 006 759.

Mes mesures correspondent partiellement, je pense que ma mesure de débit du ventilateur est perfectible.

Compatibilité

Plusieurs capteurs semblent compatibles entre eux, d’après les sites de vente de pièces de voitures :

• 0 281 006 759
• 0 986 284 007
• 0 281 002 461
• 0 280 218 008⁸ caractéristiques très proches

Références

Pièces originales

La documentation de Renault donne deux références de charnières :

• 77 01 204 548 “Hinge Kit ME”
• 77 01 206 200 “Hinge Kit ME”

Deux références compatibles correspondent à la pièce [2] du schéma. La couleur du plastique semble différente, mais cette pièce n’est pas visible quand la boite-à-gants est fermée.

Les pièces originales sont encore fournies par Renault, mais à des prix exagérés, je n’ai pas trouvé de refabrications tierces. J’ai cherché ces pièces d’occasion : soit les charnières sont déjà cassées avant même d’être démontées, soit elles ont été cassées par un démontage peu soigneux.

Réparation temporaire

C’est gênant quand une boite-à-gants s’ouvre de façon imprévisible, vibre en roulant, ou bien que le contact d’éclairage de boite-à-gants vibre au point de fondre le fusible d’éclairage à force d’appels de courant répétés.

Une solution simple consiste à retirer le cadre des charnières et leur pivot, et placer une ficelle à la place des deux pivots et entre les deux cadres de charnières. Il suffit ensuite de placer une cale en carton pour limiter les vibrations.

Prototypes

Les pièces originales sont fabriquées en Polycarbonate déjà fragile à l’état neuf. Il est possible de les recoller, ça restera très fragile, mais ça peut servir de gabarit pour mesurer.

On va commencer par fabriquer une pièce identique en carton, puis on va itérer en les améliorant.

Réparation finale

J’ai trouvé des chutes de POM, qui est une matière plastique facile à usiner et avec un faible coefficient de friction à sec.

On reproduit la forme du dernier prototype :

Il ne reste plus qu’à assembler :

Alternative

Entre temps, j’ai remarqué qu’une autre personne avait eu le même problème, et l’avait résolu de façon plus furtive.

This time, I’m going to use the same programming language to compare different algorithms, just to see if some need less iterations to converge, or can have faster iterations.

Since I’m going to copy-paste some algorithms, and write some exclusively from scratch, comparing the time it takes isn’t fair, so we’re going to compare the number of lines and the execution times instead.

As previously, the code is publicly available¹ under CC BY-NC license.

Algorithms

Montecarlo

This algorithm has been described in a previous article², using both C and Python languages.

Circle

This algorithm has also been described in a previous article³, using most languages I’ve heard of.

The idea is to compute $\pi$ using the ratio of the area of a disc, and its radius squared. The bigger the radius, the more accurate the approximation should be $S = r^2 $, which gives us:

$$\pi = \frac{S}{r^2}$$

This is straightforward to translate to C:

unsigned long count = 0;
int i, j;

for(i = -n; i <= n; i++) {
    for(j = -n; j <= n; j++) {
        if(i*i + j*j < n*n) {
            count++;
        }
    }
}
return (double) count / (n*n);

Sphere

Since we can compute $\pi$ using a disc, why not compute the volume of a sphere. It’s exactly the same idea with one more dimension.

$$\pi = \frac{3}{4} \frac{V}{r^3}$$

N-Sphere

Now that we started, why stop here? We can also compute the volume of a N-sphere, actually a N-Ball⁴⁵, and find $\pi$ with a relation between its volume and its radius.

Finding the relation between the volume and the radius may not be that straightforward, so we can split it for odd and even dimensions:

$$V_n = \begin{cases} \frac{1}{(\frac{n}{2})!} \cdot \pi^{\frac{n}{2}} \cdot R^n &\text{if } n &\text{is even}\\ \frac{2^{\frac{n+1}{2}}}{n!!} \cdot \pi^{\frac{n-1}{2}} \cdot R^n &\text{if } n &\text{is odd} \end{cases}$$

The algorithm contains sections of code that need to be broken down into 3 functions:

• nsphere(), gets all the parameters, counts the number of p-dimensions elements in a p-sphere split into n along each dimension, and computes $\pi$ based on that count and coefficients shown above
• compute_nd_sphere(), recursive function that counts elements by looping along one dimension, and calls itself for each lower dimension
• compute_1d_sphere(), non-recursive function that only loops once and is needed for all dimensions greater than one

Here’s how the main compute function looks like. It calls itself for each dimension, until it reaches the dimension 2, where it calls compute_1d_sphere().

unsigned long compute_nd_sphere(int n, int carry, unsigned short dim) {
    unsigned long count = 0;
    int i;

    if(dim < 2)
        return 0;
    if(dim == 2) {
        for(i = -n; i <= n; i++)
            count += compute_1d_sphere(-n, n, i*i + carry);
    }
    if(dim > 2) {
        for(i = -n; i <= n; i++)
            count += compute_nd_sphere(n, i*i + carry, dim-1, opt);
    }
    return count;
}

compute_1d_sphere() is exactly the same, except that it only sweeps along one dimension.

unsigned long compute_1d_sphere(int start, int stop, int carry) {
    unsigned long count = 0;
    int i;
    for(i = start; i <= stop; i++) {
        if(i*i + carry < stop*stop)
            count++;
    }
    return count;
}

Optimized N-Sphere

As we showed at the end of a previous article⁶, discs are symmetric around their center, and also along whichever axis that cuts their center.

For convenience, we can cut a disk in 4 quadrants, compute the area of one quadrant and multiply it by 4 to get the same result, using 4 times less computations.

A 3D-sphere can also be split in 8 quadrants, and going further, a N-sphere can be split in $2^N$ quadrants.

unsigned long compute_nd_sphere(int n, int carry, unsigned short dim, unsigned short opt) {
    unsigned long count = 0;
    int i;
    int start;
    if(opt == 1) {
        start = 1;

        if(dim < 2)
            return 0;
        if(dim == 2) {
            for(i = start; i <= n; i++)
                count += 4*compute_1d_sphere(1, n, i*i + carry);
        }
        if(dim > 2) {
            for(i = start; i <= n; i++)
                count += 2*compute_nd_sphere(n, i*i + carry, dim-1, opt);
        }
    }
    return count;
}

The major difference compared to the previous function, is the variable start that loops from 1 instead of -n, meaning it halves the number of computations for each dimension.

There’s one catch though. Counting discrete elements inside a shape can get tricky. We need to make sure no element is forgotten or counted twice.

On a disc, sweeping $4 \cdot n^2$ elements is straightforward, however simplifying and swiping from 0 to n on each axis means that each quadrant now overlaps, and swiping from 1 to n on each axis means that there’s a gap between each quadrant. The solution is intuitive : just add a missing cross that goes from -n to n on 2 axis, meaning $4n-1$, since we shouldn’t count the center twice.

Things start getting complex when adding dimensions. With a 3D-sphere, we need to add slices that have the shape of a disc.

A brain-twister that took some time to understand was to see that in the same way as the area of a N-dimension rectangle⁷.

After some time, I found a generic formula that works with N-dimensions, and a radius r:

$$V_{lost}(N) = N \cdot V(N-1) + \sum_{i=2}^{N-2} \binom{N}{i} \cdot V(i) + 2 \cdot N \cdot r - 2 \cdot N + 1$$

Taylor

One way of computing $\pi$ is to use trigonometric functions, especially $arctan(1) = \frac{\pi}{4}$. And since $arctan(x)$ isn’t easy to use, we’ll approximate it using series of polynoms coming from the Taylor/McLaurin method⁸.

$$arctan(x) = \sum_{n=0} ^{\infty} \frac{(-1)^n}{2 n + 1} x^{2n+1}$$

That makes it easy for $x = 1$, where $arctan(1) = \frac{\pi}{4}$, where we can simplify it and write it in C.

unsigned long i;
int a = 1;
int b = 1;
double pi_4 = 0;
for(i = 0; i < n; i++) {
    pi_4 += (double) a / (double) b;
    a = -a;
    b += 2;
}
return pi_4 * 4.0;

a is the numerator, which alternates between $+1$ and $-1$, and b is the denominator, where we can translate $2n+1$ by starting with $1$ and adding $2$ for each iteration.

Each iteration has one division, two sums and one sign change. This takes very little computing power and is very fast. Though, it takes lots of iterations to converge.

Machin

Machin’s formula can be used with Taylor’s series⁹:

$$\frac{\pi}{4} = arctan(1) = 4 \cdot arctan(\frac{1}{5}) - arctan(\frac{1}{239})$$

Merging that with the Taylor series yields to:

$$\frac{\pi}{4} \sim 4\cdot \sum_{k=0} ^{n} \frac{(-1)^k}{(2 k + 1) \cdot 5^{2k+1}} - \sum_{k=0} ^{n} \frac{(-1)^k}{(2 k + 1) \cdot 239^{2k+1}}$$

This can be translated to C:

double machin(unsigned long n) {
    // Machin formula based on Taylor series 4*arctan(1/5) - arctan(1/239) = pi/4
    // unsigned long int is the limit
    unsigned long i;
    int a = -1;
    unsigned long int b = 0;
    unsigned long int c = 0;
    double pi_4 = 0;
    for(i = 0; i < n; i++) {
        a = -a;
        b = pow(5, 2*i+1) * (2*i+1);
        c = pow(239, 2*i+1) * (2*i+1);
        pi_4 += 4.0 * (double) a / (double) b - (double) a / (double) c;
    }
    return pi_4 * 4.0;

Except there’s a catch: $239^{2i+1}$ increases fast, and means that c will quickly overflow, actually for $n \geq 5$.

Improved resolution

Let’s try a way to use larger variables. The GMP library¹⁰ seems to fit this use-case.

unsigned long i;
int a = -1;
mpz_t b, c;
mpf_t pi_4, atan5, atan239;
mpz_inits(b, c);
mpf_init(atan5);
mpf_init(atan239);
mpf_init(pi_4);

for(i = 0; i < n; i++) {
    a = -a;
    mpz_set_ui(b, 5);
    mpz_set_ui(c, 239);
    mpz_pow_ui(b, b, 2*i+1);
    mpz_pow_ui(c, c, 2*i+1);
    mpz_mul_ui(b, b, 2*i+1);
    mpz_mul_ui(c, c, 2*i+1);
    mpf_set_z(atan5, b);
    mpf_set_z(atan239, c);
    mpf_ui_div(atan5, 1, atan5);
    mpf_ui_div(atan239, 1, atan239);
    if(a == -1) {
        mpf_neg(atan5, atan5);
        mpf_neg(atan239, atan239);
    }
    mpf_mul_ui(atan5, atan5, 4);
    mpf_add(pi_4, pi_4, atan5);
    mpf_sub(pi_4, pi_4, atan239);
}
return 4.0 * mpf_get_d(pi_4);

The code looks more difficult to read and is also more difficult to write, but at least, it works for larger values of n.

Leibniz

This is actually a specific case of the Taylor series. The Leibniz formula¹¹ is meant to be set to a specific point, instead of an interval around a specific point, which yields:

$$arctan(1) = \sum_{n=0} ^{\infty} \frac{(-1)^n}{2 n + 1}$$

This time, it is translated to C in a more naive way.

unsigned long i;
int a = -1;
double pi_4 = 0;
for(i = 0; i < n; i++) {
    a *= -1;
    pi_4 += (double) a / (2*i + 1);
}
return pi_4 * 4.0;

The numerator a is multiplied by $-1$ each iteration, which is a more complex operation than simply switching a sign. The numerator is computed for each iteration, including a multiplication and a sum. Then, each terms are summed.

It should converge at the exact same rate, except that each iteration will probably take more execution time, depending on the compiler’s optimizations.

Euler

Euler’s approach to the Basel problem¹² is a specific case of the Riemann Zeta function¹³.

$$\frac{\pi^2}{6} = \sum_{n=1} ^{\infty} \frac{1}{n^2}$$

We can simply write that in C:

unsigned long int i;
double pi2_6 = 0;
for(i = 1; i <= n; i++) {
    pi2_6 += 1.0 / (i*i);
}
return sqrt(6 * pi2_6);

Each iteration has one multiplication, one division and one sum, that should need little computing power.

We still need to be careful about the square root. Its execution speed isn’t a serious issue since we only use it once. Floating-point numbers¹⁴ limited accuracy can become an issue, since LSBs are omited when the numbers become too large.

Gauss-Legendre

Let’s start with the Arithmetic-Geometric Mean (AGM), which is a series that mixes a arithmetic mean and a geometric mean¹⁵, and converges relatively quickly.

For two numbers, $a_0$ and $g_0$, this yields to:

$$\begin{cases} a_{n+1} = \frac{1}{2} (a_n + g_n)\\ g_{n+1} = \sqrt{a_n \cdot g_n} \end{cases}$$

This has found its way into the Gauss-Legendre algorithm¹⁶, using 1 and $\frac{1}{\sqrt{2}}$ as parameters, as well as some other parameters.

This gives:

$$\begin{cases} a_0 = 1\\ b_0 = \frac{1}{\sqrt{2}}\\ t_0 = 1\\ \\ a_{n+1} = \frac{1}{2} \cdot (a_n + b_n)\\ b_{n+1} = \sqrt{a_n \cdot b_n}\\ t_{n+1} = t_n - 2 \cdot (n+1) \cdot (a_{n+1} - a_n)^2 \end{cases}$$

And eventually $\pi \sim \frac{(a_n + b_n)^2}{t_n}$.

double arithmetic_geometric_mean(unsigned long n) {
    /*
    * https://rosettacode.org/wiki/Arithmetic-geometric_mean/Calculate_Pi#
    * https://en.wikipedia.org/wiki/Arithmetic%E2%80%93geometric_mean#The_number_%CF%80
    * https://mattbaker.blog/2024/03/14/pi-and-the-agm/
    */
    // n = 3
    unsigned long i;
    double olda;
    double a = 1.0;
    double b = sqrt(0.5);
    double t = 1.0;

    for(i = 1; i <= n; i++) {
        olda = a;
        a = (a + b) / 2.0;
        b = sqrt(olda * b);
        t = t - 2.0*(i+1) * (a - olda)*(a - olda);
    }
    return (a + b)*(a + b) / t;
}

That converges very fast, except there’s a similar issue as any other algorithm that uses floating point numbers, that is the variable’s limited accuracy.

For reference, the Gauss-Legendre algorithm is implemented in the famous Super PI¹⁷ program, which was developped by Professor Kanada, and used as a FPU/RAM benchmark.

Newton

Its implementation is interesting, where the factorial function increases very fast, meaning that overflows are unavoidable.

unsigned long int i;
double pi_2 = 0;
for(i = 0; i < n; i++) {
    pi_2 += pow(2, i) * pow(factorial((unsigned long) i), 2) / factorial((unsigned long) (2*i + 1));
}
return pi_2 * 2.0;

In this case, it starts overflowing when trying to compute $21!$¹⁸.

Changing long integers to long long integers sounds like a good idea. Except that won’t work here, on a 64-bit system, where both are 64-bit words, meaning no difference at all.

Improved resolution

This algorithm would probably work better with larger variables, using the GMP library¹⁹, for example.

unsigned long int i;
// A = A*B;
// pi_2 = A / C;
mpz_t a, b, c;
mpf_t pi_a, pi_c, pi_2;
mpz_inits(a, b, c);
mpf_init(pi_a);
mpf_init(pi_c);
mpf_init(pi_2);
mpf_set_ui(pi_2, 0);

for(i = 0; i < n; i++) {
    mpz_ui_pow_ui(a, 2, i);
    factorial__(b, i);
    mpz_pow_ui(b, b, 2);
    mpz_mul(a, a, b);
    factorial__(c, 2*i+1);
    mpf_set_z(pi_a, a);
    mpf_set_z(pi_c, c);
    mpf_div(pi_a, pi_a, pi_c);
    mpf_add(pi_2, pi_2, pi_a);
}
mpz_clears(a, b, c);
mpf_clear(pi_a);
mpf_clear(pi_c);
return mpf_get_d(pi_2)*2.0;

The code is more difficult to read, however it clearly does what we want without overflowing.

We’re using mpz_t as large integer and mpf_t as accurate float, both types are from the GMP library with their own arithmetic functions.

Archimedes

This algorithm is similar to the one we called circle, where we broke-down a disc into small squares, and counted the one which fit into a circle.

Here, we use polygons instead. They are centered and fit into a circle, and we can compute their circumference, and compare it to the diameter of the circle.

Starting with a square should be self-explanatory, and increasing the number of vertices should yield to better approximations of $\pi$.

We can translate that into C:

unsigned int i;
double polygon_edge_sq = 2.0;
unsigned long polygon_sides = 4;
for(i = 0; i < n; i++) {
    polygon_edge_sq = 2.0 - 2.0 * sqrt(1 - polygon_edge_sq / 4.0);
    polygon_sides *= 2;
}
return polygon_sides * (double) sqrt(polygon_edge_sq) / 2.0;

However, we run into an issue, where the approximation gets worse for $n \geq 14$, and fails for $n \geq 27$. Respectively equivalent to polygons with $2^15 = 65'536$ and $2^28 = 536'870'912$ vertices. We’re dealing with very numbers requiring accuracy, something floating point variables aren’t good at storing²⁰.

Improved resolution

Let’s improve it, using the GMP library²¹.

unsigned int i;
mpf_t polygon_edge_sq;
mpf_init(polygon_edge_sq);
mpf_t tmp;
mpf_init(tmp);
mpf_set_d(polygon_edge_sq, 2.0);

unsigned long polygon_sides = 4;
for(i = 0; i < n; i++) {
    mpf_div_ui(tmp, polygon_edge_sq, 4);
    mpf_ui_sub(tmp, 1, tmp);
    mpf_sqrt(tmp, tmp);
    mpf_mul_ui(tmp, tmp, 2);
    mpf_ui_sub(polygon_edge_sq, 2, tmp);
    polygon_sides *= 2;
}
mpf_sqrt(polygon_edge_sq, polygon_edge_sq);
mpf_mul_ui(polygon_edge_sq, polygon_edge_sq, polygon_sides/2.0);
//gmp_printf("pi: %.16Ff\n", polygon_edge_sq);
return mpf_get_d(polygon_edge_sq);

It now uses more accurate floating-point numbers with variable mantissa/exponent so the approximation only gets worse for $n \geq 50$, and fails for $n \geq 61$.

The slight downsides are that it’s more difficult to read and slower to execute.

Ramanujan

The Ramanujan-Sato²² series is an infinite sum of rational numbers that uses real coefficients to give $\frac{1}{\pi}$. One thing to note is that it’s from the $20^{th}$ century, shortly before computers were developped.

$$\frac{1}{\pi} = \frac{2 \cdot \sqrt{2}}{99^2} \cdot \sum_{k=0}^{\infty} \frac{(4k)!}{k!^4} \frac{26390k + 1103}{396^{4k}}$$

Since we see factorial and power operations that are likely to overflow with 64-bit variables, it’s a good idea to start directly with the GMP²³ library.

That converges very fast and gives 13 digits within 3 iterations, where it reaches float’s minimum accuracy.

Chudnovsky

The Chudnovsky algorithm²⁴ is an update over Ramanujan’s algorithm, that’s still used for computing large numbers of $\pi$ digits using computers.

$$\frac{1}{\pi} = 12 \cdot \sum_{k=0}^{\infty} \frac{ (-1)^k (6k)! (545'140'134k + 13'591'409) }{ (3k)!(k!)^3(640'320)^{3k+3/2} }$$

This is supposed to converge fast and be accurate²⁵, except that my implementation stopped converging after reaching 7 digits over 2 iterations.

Plouffe

The Bailey–Borwein–Plouffe formula²⁶ is also a modern algorithm based on an infinite sum of rational numbers.

$$\pi = \sum_{k=0}^{\infty} \frac{1}{16^k} (\frac{4}{8k+1} - \frac{2}{8k+4} - \frac{1}{8k+5} - \frac{1}{8k+6} )$$

One interesting thing to note is that most terms are close to negative powers of two, and if not, their bits aren’t spread apart. This means that each partial sum can be accurate, even using standard precision floating-point numbers²⁷. High resolution is only needed when summing partial sums.

This reached 18 digits accuracy after 14 iterations.

Bellard

Bellard’s formula²⁸ is an improvement over the Plouffe formula that works in a similar way, using lots of terms that are based on powers of 2.

$$\pi = \frac{1}{2^6} \sum_{k=0}^{\infty} \frac{(-1)^k}{2^{10n}} ( -\frac{2^5}{4k+1} -\frac{1}{4k+3} + \frac{2^8}{10n+1} -\frac{2^6}{10n+3} -\frac{2^2}{10n+5} -\frac{2^2}{10n+7} +\frac{1}{10n+9} )$$

This is even faster than Plouffe’s formula, where it reached 20 digits accuracy after 7 iterations.

Helping functions

Some of the previous algorithms require external functions that are generic and can be reused.

Short functions can use the inline keyword²⁹, meaning that the compiler will try to replace it in the code to avoid function calls, in a way to improve performance, with depth and length limitations.

Factorial

The factorial function is needed for N-Sphere and Newton algorithms.

By definition, $n! = \prod\limits_{k=1}^{n} k = n \cdot (n-1) \cdot ... 2 \cdot 1$, and $0! = 1$.

Iterative

Let’s translate that in C with a loop:

inline unsigned long factorial_(unsigned long n) {
    unsigned long fact = 1;
    unsigned long i = 0;
    for(i = n; i > 0; i--) {
        fact *= i;
    }
    return fact;
}

Recursive

We can also write it in this way, with a recursive function that calls itself:

inline unsigned long factorial(unsigned long n) {
    if(n > 1)
        return n*factorial(n-1);
    if(n <= 1)
        return 1;
    return 0;   // never happens
}

The reason why both ways have been tried is to compare their performances, where the recursive method is supposed to use more memory space, but executes faster.

Double Factorial

Double Factorial is called Factorial2 here, to avoid confusion with variable types. It’s very similar to factorial, except that it skips evey second iteration:

By definition, $n!! = n \cdot (n-2) \cdot ... 4 \cdot 2$ for even numbers, $n!! = n \cdot (n-2) \cdot ... 3 \cdot 1$ for odd numbers, and $0!! = 1$.

No need to compare recursive and iterative methods, let’s directly write a recursive function:

inline unsigned long int factorial2(unsigned long int n) {
    if(n > 2)
        return n*factorial2(n-2);
    if(n <= 2)
        return 1;
    return 0;   // never happens
}

Binomial coefficients

We need binomial coefficients³⁰, $\binom{n k} = \frac{n!}{(n-k)!}$, and since we already have a factorial function, the code is super easy:

inline unsigned int binomialc(unsigned int n, unsigned int k) {
    return factorial(n)/(factorial(k)*factorial(n - k));
}

References