diff --git a/tipe_ldpc_coaching_v2.html b/tipe_ldpc_coaching_v2.html new file mode 100644 index 0000000..c9bcf88 --- /dev/null +++ b/tipe_ldpc_coaching_v2.html @@ -0,0 +1,1129 @@ + + + + + +TIPE – Codes LDPC · Guide Oral + + + + +
+ + + + +
+

Guide Oral TIPE
Codes LDPC

+

Analyse complète de ta présentation, script mot-à-mot pour chaque slide, minutage précis et points techniques à maîtriser pour les 15 minutes d'exposé.

+
+
Slides : 35
+
Durée cible : 15 min 00s
+
Format : Anthony PERRONI · n°49871
+
Outil : Typst — Annexes Rust
+
+
+
+ + +
+
+ 01 +

Analyse globale

+
+ +
+

⚠ Point critique de rythme

+

35 slides en 15 minutes = ~26 secondes par slide en moyenne. C'est tendu mais tenable à condition de traiter certaines slides en "animation rapide" (15s) et de garder les 50-60s pour les slides cruciales (Sum-Product, Shannon, LLR). Le minutage slide-à-slide ci-dessous a été calibré pour tomber pile à 15 min.

+
+ +
+
+

✅ Ce qui fonctionne très bien

+
    +
  • Ouverture par des applications concrètes (drone FPV, satellite Athena-Fidus) — accroche excellente, le jury est immédiatement dans le concret.
    • +
  • Narration « Shannon → NP-hard → LDPC » — le fil conducteur est limpide : on pose le problème, on montre le mur théorique, on propose la solution. Très bien construit.
    • +
  • Démonstration par image (slide 30/35) — extrêmement frappante visuellement, c'est le point fort mémorable de toute la présentation.
    • +
  • Courbe waterfall comparative (slide 32/35) — climax parfait de la partie analyse : trois algorithmes sur le même graphe, un seul regard suffit.
    • +
  • Progression hard → soft décoding — la transition Bit-Flipping → LLR → Sum-Product → Min-Sum est pédagogiquement très claire.
    • +
  • Code source Rust en annexe — montre une implémentation sérieuse et complète ; atout fort si le jury pose des questions sur la mise en œuvre.
    • +
  • Illustration du LLR (slide 27/35) — axe signé avec valeur et confiance, très bien visualisé.
    • +
+
+ +
+

⚠️ Ce qu'il faut corriger ou renforcer

+
    +
  • Slide 35/35 (Conclusion) trop creuse — « QC-LDPC / FPGA / Test Réels » : trois mots sans bilan. Il faut absolument improviser un résumé fort oralement (voir script).
    • +
  • Slide 34/35 (Méthode de génération) — trois noms listés sans comparaison ni résultat. La slide semble incomplète. Compenser dans le discours avec un mini-tableau comparatif oral.
    • +
  • Slide 26/35 (Syndrome et Analyse) — courbe intéressante mais difficile à expliquer en 20s. Si tu manques de temps à l'oral, zapper après deux phrases.
    • +
  • Encodage dense (slide 22) — tu soulèves le problème de la densification de G mais la solution (Richardson-Urbanke, QC-LDPC) n'est qu'en annexe. Mentionner explicitement oralement.
    • +
  • Slide 1 (Utilisation) sans légendes — les URLs seules ne parlent pas au jury. Tout repose sur ton discours oral ; le script ci-dessous comble ce vide.
    • +
  • Slides 8–9 (Exemple code (5,2)) — deux slides pour un exemple basique, c'est serré en temps. Objectif : 15–20s par slide, aller vite, ne pas s'attarder.
    • +
  • Lien explicite Shannon ↔ algorithmes manquant à l'oral — quand tu présentes la slide waterfall comparative (32/35), dis explicitement les distances à la limite : Sum-Product à 1–1.5 dB, Bit-Flipping à 5–6 dB.
    • +
+
+
+
+
+ + +
+
+ 02 +

Guide de minutage

+
+ +

Chaque section doit consommer exactement ce temps. Les barres sont proportionnelles. Garde un œil sur ta montre aux transitions de section.

+ +
+
+
Intro · slides 1→4
+
+
1:30
+
+
1:30
+
+
+
Codes linéaires · 5→9
+
+
2:10
+
+
2:10
+
+
+
Shannon + NP · 10→11
+
+
1:05
+
+
1:05
+
+
+
Déf. LDPC · 12→15
+
+
2:10
+
+
2:10
+
+
+
Tanner · 16→21
+
+
1:20
+
+
1:20
+
+
+
Encodage · 22
+
+
30s
+
+
0:30
+
+
+
Bit-Flipping · 23→26
+
+
1:40
+
+
1:40
+
+
+
Soft decoding · 27→32
+
+
2:40
+
+
2:40
+
+
+
Analyse · 33→34
+
+
1:00
+
+
1:00
+
+
+
Conclusion · 35
+
+
45s
+
+
0:45
+
+
+ +
+
15:00
+
Durée totale cumulée.
Marge de ± 30s acceptable. En cas de retard, compresser slides 8-9 (exemple) et 26 (syndrome chart).
+
+ +
+
Intro / Plan
+
Codes linéaires
+
Shannon / Complexité
+
Déf. LDPC + Tanner
+
Décodage hard
+
Décodage soft
+
Analyse / Girth
+
Conclusion
+
+
+
+ + +
+
+ 03 +

Script slide par slide

+
+

Clique sur une slide pour ouvrir son script. Le texte en orange signale les mots à insister ou les formulations clés. Les encarts colorés donnent des notes de présentation.

+
+ + +
+ +
+ + +
+
+
1/35
+
Introduction : Utilisation
+
~30s
+
Introduction
+
▼
+
+
+
+ « Je vais vous présenter les codes LDPC — Low Density Parity Check. Avant d'entrer dans la théorie, voici trois contextes réels qui les utilisent quotidiennement : un module caméra de drone FPV avec OpenIPC, qui doit transmettre de la vidéo HD en temps réel malgré les interférences radio ; et le satellite Athena-Fidus, un satellite franco-italien de télécommunications haut débit. Ces systèmes partagent une contrainte commune : transmettre des données fiables à travers un canal qui introduit du bruit. C'est exactement ce problème que les codes LDPC résolvent. » +
+
+ 💡 +
La slide n'a que des images et des URLs — tout le contexte vient de toi à l'oral. Si tu manques de temps plus tard, tu peux compresser cette intro à 20s en listant juste les applications sans détailler.
+
+
+
+ + +
+
+
2/35
+
Introduction : Communication Numérique
+
~25s
+
Introduction
+
▼
+
+
+
+ « Voici le modèle classique d'une chaîne de communication numérique. Une source génère un message, un émetteur l'encode en signal, ce signal traverse un canal bruité — typiquement un canal AWGN — et un récepteur doit décoder le signal reçu pour retrouver le message original. La question centrale de mon TIPE : comment garantir que le message reçu est identique au message envoyé, malgré le bruit du canal ? » +
+
+ ✅ +
Slide simple, aller vite. Pointer le schéma du doigt (ou d'un stylo) : source → canal → destination.
+
+
+
+ + +
+
+
3/35
+
Problématique
+
~20s
+
Introduction
+
▼
+
+
+
+ « Ce qui nous amène à notre problématique : « Comment utiliser les codes LDPC pour garantir la fiabilité d'une transmission en présence de bruit ? » Je vais montrer que la réponse repose sur une structure mathématique très particulière de la matrice de contrôle, et sur des algorithmes itératifs qui permettent d'approcher la limite théorique de Shannon. » +
+
+ 💡 +
Lire la problématique à voix haute calmement, puis enchaîner immédiatement. Ne pas rester dessus trop longtemps.
+
+
+
+ + +
+
+
4/35
+
Plan
+
~15s
+
Introduction
+
▼
+
+
+
+ « Pour y répondre : j'établirai d'abord les fondements des codes linéaires, puis je définirai les codes LDPC et leur représentation graphique, j'aborderai l'encodage, les algorithmes de décodage, et je terminerai par une analyse comparative des performances. » +
+
+ ✅ +
Très court. Pointer chaque item en parlant. Enchaîner sans marque d'hésitation.
+
+
+
+ + +
+
+
5/35
+
Définition : Codes Linéaires en Bloc
+
~35s
+
Codes linéaires
+
▼
+
+
+
+ « Un code linéaire en bloc (n, k) est un sous-espace vectoriel de F₂ⁿ de dimension k. Concrètement : on encode k bits d'information en n bits, en ajoutant m = n−k bits de redondance — les bits de parité. L'encodage est une application linéaire, un plongement de l'espace des messages dans l'espace des mots de code. Cette structure vectorielle est fondamentale : elle nous permettra de détecter et corriger les erreurs introduites par le canal. » +
+
+ 💬 +
Pointer le diagramme de plongement F₂² → F₂³ sur la slide. Insister sur : « sous-espace vectoriel » et « redondance contrôlée ».
+
+
+
+ + +
+
+
6/35
+
Définition : Matrice Génératrice
+
~30s
+
Codes linéaires
+
▼
+
+
+
+ « L'encodage se formalise via la matrice génératrice G de taille k×n, dont les lignes forment une base du code. Pour un message u, le mot de code est simplement c = uG. En forme systématique, G = [Iₖ | P] : les k premiers bits du mot de code sont exactement les bits du message original — c'est ce qui rend le décodage pratique. P est la matrice de parité qui génère la redondance. » +
+
+
+ + +
+
+
7/35
+
Définition : Matrice de Contrôle
+
~35s
+
Codes linéaires
+
▼
+
+
+
+ « La matrice de contrôle H = [Pᵀ | Iₙ₋ₖ] définit l'espace dual du code : tout mot de code c vérifie Hcᵀ = 0. C'est la propriété fondamentale. Quand on reçoit un vecteur r = c + e — le mot de code plus une erreur — le syndrome s = Hrᵀ = Heᵀ est directement la signature de l'erreur. Si s = 0 : aucune erreur détectée. Si s ≠ 0 : le syndrome nous informe sur la position des bits erronés. Tout le décodage repose sur cette relation. » +
+
+ ✅ +
Slide capitale. Bien insister sur Hcᵀ = 0 ↔ « appartient au code ». Et s = Heᵀ : « le syndrome ne dépend que de l'erreur, pas du message transmis ».
+
+
+
+ + +
+
+
8/35
+
Exemple — Code (5,2) · Partie 1
+
~20s
+
Codes linéaires
+
▼
+
+
+
+ « Un exemple rapide : code (5, 2). On choisit P, on en déduit G. Pour le message u = [1 1], le mot de code c = uG = [1 1 1 0 1]. Les 2 premiers bits sont le message, les 3 suivants sont les bits de parité générés automatiquement. » +
+
+ ⚡ +
Aller très vite sur cette slide. L'exemple est illustratif, ne pas s'y attarder. Le jury connaît les codes linéaires.
+
+
+
+ + +
+
+
9/35
+
Exemple — Code (5,2) · Partie 2
+
~20s
+
Codes linéaires
+
▼
+
+
+
+ « On vérifie : Hcᵀ = 0 — c'est bien un mot de code valide. Si on reçoit r = [1 1 0 0 1] avec une erreur sur le 3ème bit, le syndrome est non nul — l'erreur est détectée. Sur un code aussi petit on pourrait même la corriger, mais c'est impraticable à grande échelle — ce qui nous amène au problème de complexité. » +
+
+ ⚡ +
Même consigne : aller vite. Finir par « impraticable à grande échelle » pour préparer la slide suivante naturellement.
+
+
+
+ + +
+
+
10/35
+
Approcher la Limite de Shannon
+
~35s
+
Shannon
+
▼
+
+
+
+ « En 1948, Shannon démontre qu'il existe une limite fondamentale : pour un canal AWGN de rapport Eb/N₀, la capacité C est le taux maximal d'information transmissible sans erreur. Ce graphe montre que pour un code de longueur n = 64 800 — c'est le standard DVB-S2 pour la télévision par satellite — on s'approche à moins de 0,5 dB de cette limite théorique. Pour n petit, on reste loin. La question est donc : comment construire des codes qui approchent la limite, avec un décodage efficace ? » +
+
+ 🎯 +
Slide très importante — c'est la motivation principale. Revenir dessus mentalement lors des slides 25 et 32 (waterfall) pour quantifier l'écart à Shannon.
+
+
+
+ + +
+
+
11/35
+
Le Mur de la Complexité
+
~30s
+
Shannon
+
▼
+
+
+
+ « Le décodage optimal — le décodage par maximum de vraisemblance — cherche le mot de code le plus proche au sens de la distance de Hamming. Le problème : c'est NP-difficile pour H quelconque, avec une complexité en O(2ᵏ). Pour k = 648, on parle de 2⁶⁴⁸ ≈ 10¹⁹⁵ opérations — totalement hors de portée. Il nous faut donc une structure spéciale sur H qui permette un décodage polynomial. Et c'est exactement ce que fournissent les codes LDPC. » +
+
+ 🎯 +
Slide pivot de la présentation. « NP-difficile → LDPC comme solution » est le cœur de la narration. Finir sur un ton légèrement dramatique pour marquer la transition.
+
+
+
+ + +
+
+
12/35
+
Définition des Codes LDPC
+
~40s
+
LDPC
+
▼
+
+
+
+ « Un code LDPC est un code linéaire en bloc dont la matrice de contrôle H est clairsemée — d'où « Low Density Parity Check ». Dans un code régulier (wc, wr), chaque colonne a exactement wc uns et chaque ligne exactement wr uns. Ici, H ∈ M₁₅,₃₀(F₂) avec wc = 3 et wr = 6 — à peine 3 uns par colonne sur 15 possibles. Cette faible densité, de l'ordre de 10%, est la clé : elle permet des algorithmes de décodage itératifs efficaces. Le rendement est R = 1 − m/n = 1/2. » +
+
+ 🎯 +
Slide définitoire centrale. Insister sur : « la matrice est creuse — c'est tout, c'est tout ce qui change par rapport à un code linéaire classique — mais ça change tout ».
+
+
+
+ + +
+
+
13/35
+
De la Matrice aux Équations de Parité
+
~30s
+
LDPC
+
▼
+
+
+
+ « Chaque ligne Lⱼ de H définit une équation de parité fⱼ. Par exemple, f₀ : r₇ ⊕ r₁₀ ⊕ r₁₅ ⊕ r₂₂ ⊕ r₂₄ ⊕ r₂₉ = 0. On vérifie le syndrome Hr^T = 0 sur le vecteur reçu. Si fⱼ = 1, un nombre impair de bits parmi ceux impliqués a été inversé — il y a eu une erreur. La faible densité de H signifie que chaque équation ne met en jeu que wᵣ = 6 bits sur 30 possibles. » +
+
+
+ + +
+
+
14/35
+
L'Entrelacement des Contraintes
+
~30s
+
LDPC
+
▼
+
+
+
+ « L'aspect crucial : chaque bit rᵢ participe à wc = 3 équations distinctes simultanément. Par exemple, r₂₄ est surveillé par f₀, f₉ et f₁₄. Si plusieurs équations échouent et pointent toutes vers ce même bit, il est très probablement erroné. C'est un mécanisme de vote croisé : la redondance n'est pas simplement répétée, elle est répartie sur le mot de code de façon à maximiser l'information sur chaque bit. » +
+
+ 💡 +
Bonne phrase-clé : « les contraintes s'entrecroisent — chaque bit est surveillé par plusieurs équations, chaque équation surveille plusieurs bits ».
+
+
+
+ + +
+
+
15/35
+
Graphe de Tanner : Définition
+
~30s
+
Tanner
+
▼
+
+
+
+ « Pour visualiser cette structure, on construit le graphe de Tanner G(H) : un graphe bipartite avec d'un côté les nœuds de variable V — un par bit — et de l'autre les nœuds de contrôle C — un par équation de parité. Il y a une arête entre vⱼ et cᵢ si et seulement si H_{i,j} = 1. Ce graphe est équivalent à H : mêmes degrés, même structure. Il va être le support géométrique de tous nos algorithmes de décodage. » +
+
+
+ + +
+
+
16→19/35
+
Construction du Graphe de Tanner (animations)
+
~50s total
+
Tanner
+
▼
+
+
+
+ [Slide 16/35 — Les nœuds] « On commence par placer les 30 nœuds de variable en haut et les 15 nœuds de contrôle en bas. »

+ [Slide 17/35 — Nœud de contrôle] « Le nœud c₀ est connecté aux bits qu'il surveille : v₇, v₁₀, v₁₅, v₂₂, v₂₄, v₂₉ — exactement les uns sur la première ligne de H. »

+ [Slide 18/35 — Nœud de variable] « Réciproquement, v₁₀ est connecté aux trois nœuds de contrôle c₀, c₅, c₁₁ — les trois équations où la colonne 10 de H vaut 1. »

+ [Slide 19/35 — Graphe final] « En répétant pour tous les bits, on obtient le graphe de Tanner complet. Sa structure bipartite reflète exactement la matrice H — c'est la représentation graphique des contraintes de parité. » +
+
+ ⚡ +
Ces 4 slides sont des animations progressives. Les enchaîner fluidement et rapidement — environ 12s par slide. Ne pas attendre entre chaque transition.
+
+
+
+ + +
+
+
20/35
+
La Contrainte de Somme Nulle — Sans erreur
+
~20s
+
Tanner
+
▼
+
+
+
+ « Dans le graphe, chaque nœud de contrôle cᵢ calcule le XOR de ses voisins. Si le mot de code est valide, tous les nœuds de contrôle obtiennent 0 : les équations sont toutes satisfaites. C'est la vision graphique de Hcᵀ = 0. » +
+
+
+ + +
+
+
21/35
+
La Contrainte de Somme Nulle — Détection
+
~20s
+
Tanner
+
▼
+
+
+
+ « Si un bit est inversé, les nœuds de contrôle qui lui sont connectés calculent maintenant 1 au lieu de 0 — l'erreur est détectée. Ici, 0 ⊕ 1 ⊕ 0 = 1 : ce nœud de contrôle est insatisfait. C'est le signal qui va déclencher la correction dans les algorithmes itératifs. » +
+
+
+ + +
+
+
22/35
+
Encodage LDPC : Calcul de G
+
~30s
+
Encodage
+
▼
+
+
+
+ « Pour encoder, on calcule la forme systématique par pivot de Gauss sur H. Mais attention : H est creuse — 20% de densité — et l'opération de pivot la rend dense — 50% ou plus. La matrice G résultante est donc dense, ce qui implique un encodage en O(n²). Pour les grands codes industriels comme DVB-S2 avec n = 64 800, c'est inaceptable. La solution : des structures QC-LDPC quasi-cycliques et l'algorithme de Richardson-Urbanke permettent un encodage en O(n), détaillés en annexe. » +
+
+ 💡 +
Ne pas oublier de mentionner Richardson-Urbanke et QC-LDPC ici, même brièvement. La slide soulève un problème ; le jury peut interroger sur la solution.
+
+
+
+ + +
+
+
23/35
+
Décodage : Bit-Flipping
+
~35s
+
Décodage hard
+
▼
+
+
+
+ « Entrons dans le cœur du décodage. Le premier algorithme, le Bit-Flipping, opère sur des décisions strictes — des bits purs, pas des probabilités. Principe : à chaque itération, les nœuds de contrôle transmettent leur verdict de parité à leurs voisins. Chaque nœud de variable compte ses équations insatisfaites. Si la majorité de ses wc équations échouent, le bit se retourne — il change de valeur. On itère jusqu'à ce que le syndrome soit nul, ou jusqu'à atteindre le nombre maximum d'itérations. » +
+
+ ✅ +
Bien faire le lien avec la slide précédente : « les nœuds de contrôle insatisfaits qu'on vient de voir vont maintenant voter pour identifier quel bit est erroné ».
+
+
+ 🎞️ +
Cette slide a deux états d'animation. Le premier montre la description textuelle du Message Passing. Le second révèle le graphe avec v₀–v₃ et les étapes VN→CN, CN→VN puis le FLIP. Pointer les nœuds en les nommant pendant l'animation — « v₁ a reçu un verdict défavorable de ses trois équations, il se retourne ».
+
+
+
+ + +
+
+
24/35
+
Bit-Flipping : Graphe de flot de contrôle
+
~25s
+
Décodage hard
+
▼
+
+
+
+ « Voici l'organigramme. Mot reçu r en entrée. Boucle : ① mise à jour des nœuds de contrôle — calcul du syndrome s = Hr^T — ② mise à jour des nœuds de variable — flip si majorité d'équations violées. À chaque itération, on teste si s = 0 : si oui, succès immédiat. Si on dépasse le nombre maximum d'itérations, échec — la trame est perdue. En pratique, on fixe Imax entre 50 et 200 itérations. » +
+
+
+ + +
+
+
25/35
+
Waterfall — Bit-Flipping LDPC (3,6)
+
~30s
+
Décodage hard
+
▼
+
+
+
+ « Voici la courbe waterfall pour un code LDPC (3,6) de longueur n = 1296. L'axe horizontal est le rapport Eb/N₀ en dB, l'axe vertical le Bit Error Rate. On voit le comportement caractéristique : une chute très abrupte du BER — le « waterfall » — autour de 5 à 6 dB. Comparé au signal non codé, le gain est substantiel. Mais on reste loin de la limite de Shannon. Pour aller plus loin, il faut du décodage soft — qui utilise non plus des bits, mais des valeurs continues. » +
+
+ 💡 +
Mentionner la distance à Shannon : « ~5 à 6 dB de la limite ». Ce chiffre sera comparé lors de la slide 31.
+
+
+
+ + +
+
+
26/35
+
Bit-Flipping : Syndrome et Analyse
+
~20s
+
Décodage hard
+
▼
+
+
+
+ « Cette courbe montre l'évolution du nombre d'équations insatisfaites au fil des itérations du Bit-Flipping, pour différents niveaux de bruit. À fort SNR, le syndrome converge vers zéro en une dizaine d'itérations. À SNR plus faible, la convergence est plus lente ou échoue. — L'avantage de cet algorithme : sa complexité minimale — seulement des XOR et des compteurs — O(n) par itération. En revanche sa limite fondamentale : il ignore complètement la confiance du récepteur physique. Un bit reçu à 0,51 V est traité exactement comme un bit reçu à 4,5 V — c'est ce qui va nous pousser vers le décodage soft. » +
+
+ 🎞️ +
Cette slide a deux états. Le premier montre uniquement la courbe de convergence du syndrome. Le second révèle les blocs Avantages / Limite présents sur la slide. Ne pas sauter la Limite (« ignore la confiance ») — elle sert de transition directe et explicite vers le décodage soft.
+
+
+
+ + +
+
+
27/35
+
Décodage Soft : Le LLR
+
~35s
+
Décodage soft
+
▼
+
+
+
+ « Pour aller plus loin, on passe au décodage soft. Au lieu de décisions binaires, on travaille avec des probabilités sous forme de Log-Likelihood Ratios. Le LLR d'un bit vᵢ est défini comme le logarithme du rapport P(vᵢ = 0 | yᵢ) / P(vᵢ = 1 | yᵢ). Le signe encode la décision sur le bit — positif vaut 0, négatif vaut 1 — et la valeur absolue encode la confiance. Un LLR de +10 : très sûr que c'est un 0. Un LLR de −0,3 : légèrement penché vers 1, mais très incertain. Cette information graduelle est précieuse pour le décodage. » +
+
+ 💡 +
Pointer l'axe gradué sur la slide : « −6 → forte confiance bit = 1 ; +10 → forte confiance bit = 0 ; +0.3 → très incertain ».
+
+
+
+ + +
+
+
28/35
+
Sum-Product : Belief Propagation
+
~45s
+
Décodage soft
+
▼
+
+
+
+ « L'algorithme Sum-Product, ou Belief Propagation, est le décodeur optimal pour les graphes sans cycles. Au lieu de bits, les nœuds échangent des LLR — des « croyances ». Deux règles fondamentales : d'abord, l'information extrinsèque — un nœud n'envoie jamais son propre avis à l'expéditeur de ce même avis, pour éviter l'auto-renforcement. Ensuite, la mise à jour des nœuds de contrôle : m_{c→v} = 2 tanh⁻¹(∏ tanh(m_{u→c}/2)), le produit portant sur tous les voisins u de c sauf v. Cette formule provient de la probabilité conditionnelle de parité — chaque nœud agrège l'information de ses voisins sans se biaiser lui-même. » +
+
+ 🎯 +
Slide la plus technique. Le jury va sûrement poser des questions dessus. Savoir dériver la formule tanh (voir la section "À réviser"). Insister sur « information extrinsèque » : c'est le concept clé.
+
+
+
+ + +
+
+
29/35
+
Sum-Product — Déroulement complet
+
~25s
+
Décodage soft
+
▼
+
+
+
+ « L'algorithme complet : initialisation des messages v→c avec les LLR de canal. Puis alternance de mises à jour : nœuds de contrôle, puis nœuds de variable — m_{v→c} = L_v^canal + ∑ m_{c'→v}. À chaque itération, on calcule le LLR apostériori Λⱼ = L_v^canal + ∑ m_{cᵢ→vⱼ} pour prendre la décision finale : v̂ⱼ = 0 si Λⱼ > 0, sinon 1. On itère jusqu'à satisfaction du syndrome ou Imax. » +
+
+
+ + +
+
+
30/35
+
Transmission d'image — Démonstration
+
~35s
+
Décodage soft
+
▼
+
+
+
+ « Voici une démonstration concrète que j'ai implémentée. J'ai simulé la transmission d'une image sur canal AWGN à Eb/N₀ = 2,3 dB. À gauche : l'image originale. Au centre : l'image reçue bruitée — pratiquement illisible, 30% des pixels sont corrompus. Et à droite : les résultats du décodage Sum-Product pour trois rendements différents — R = 1/2, 2/3 et 3/4. On voit clairement qu'un rendement plus faible, donc plus de redondance, donne une meilleure correction. C'est le compromis fondamental entre débit et fiabilité — et les codes LDPC permettent de le naviguer précisément. » +
+
+ ⭐ +
Point fort de la présentation. Prendre le temps de le présenter correctement. Le visuel est immédiatement compréhensible même sans explications techniques — c'est parfait pour le jury.
+
+
+
+ + +
+
+
31/35
+
Min-Sum — Approximation matérielle
+
~30s
+
Décodage soft
+
▼
+
+
+
+ « Le Sum-Product nécessite des opérations tanh, coûteuses en matériel. L'algorithme Min-Sum utilise une approximation : le produit des tanh est remplacé par un minimum — m_{c→v} ≈ (∏ sgn(m_{u→c})) × min|m_{u→c}|. La mise en œuvre devient triviale : seulement des comparateurs pour le minimum et des XOR pour les signes. En ajoutant un facteur d'échelle α ≈ 0,75 à 0,875 qui compense le biais, les performances restent très proches du Sum-Product, avec une fraction du coût matériel. » +
+
+ 💡 +
Relier au contexte DVB-S2 / 5G : « c'est Min-Sum qui est implémenté en FPGA dans les standards industriels, pas Sum-Product ».
+
+
+
+ + +
+
+
32/35
+
Waterfall — Comparaison des 3 algorithmes
+
~35s
+
Décodage soft
+
▼
+
+
+
+ « Ce graphique est le bilan de performance. Trois algorithmes sur le même code (3,9) — R = 2/3. Le Sum-Product est à environ 1 à 1,5 dB de la limite de Shannon — remarquable. Le Min-Sum perd quelques dixièmes de dB mais reste excellent. Le Bit-Flipping est nettement moins performant — 5 à 6 dB — mais il est beaucoup plus rapide. Le choix dépend du compromis : décodage embarqué en temps réel → Min-Sum sur FPGA ; haute qualité de service → Sum-Product. Dans tous les cas, on bat largement le signal non codé. » +
+
+ 🎯 +
Slide climax de l'analyse. Relier explicitement à la slide 10 (Shannon) en disant les distances en dB. C'est le point d'orgue de la démonstration.
+
+
+
+ + +
+
+
33/35
+
La Topologie de H : Le Girth
+
~35s
+
Analyse
+
▼
+
+
+
+ « Un paramètre clé pour les performances est le girth — la maille — longueur du plus court cycle dans le graphe de Tanner. Sur un arbre sans cycles, le Belief Propagation est exact. Mais sur un graphe cyclique, les messages peuvent revenir à leur point de départ après l cycle itérations, créant des corrélations qui dégradent la convergence. Un 4-cycle — le pire cas — crée des corrélations immédiates qui peuvent bloquer le décodage. Un girth élevé retarde l'apparition de ces effets : idéalement, girth ≥ 2·Imax pour que les cycles n'influencent pas les premières itérations. » +
+
+ 🎯 +
Question classique du jury : « pourquoi le BP n'est-il pas exact ? ». La réponse est ici : les cycles. Bien maîtriser cette notion.
+
+
+
+ + +
+
+
34/35
+
Méthodes de génération de H
+
~25s
+
Analyse
+
▼
+
+
+
+ « Pour construire H avec un bon girth, trois méthodes. Gallager (1962) : la méthode originale — simple, rapide, mais des cycles de longueur 4 sont fréquents. MacKay-Neal (1996) : construction aléatoire avec rejet actif de tout arc qui créerait un 4-cycle — girth garanti ≥ 6, performances nettement supérieures. Progressive Edge-Growth (2005) : on maximise le girth local à chaque ajout d'arête par un BFS — c'est aujourd'hui la méthode de référence, et celle que j'ai implémentée en annexe. Ces trois méthodes produisent des codes différents, mais c'est le girth qui fait toute la différence. » +
+
+ ⚠️ +
La slide ne montre que 3 noms. Tout vient de toi oralement. Préparer bien ce résumé comparatif — le jury va probablement demander : « laquelle avez-vous implémentée et pourquoi ? »
+
+
+
+ + +
+
+
35/35
+
Conclusion
+
~45s
+
Conclusion
+
▼
+
+
+
+ « Pour conclure : les codes LDPC résolvent élégamment le problème de la transmission fiable. La matrice clairsemée H rend le décodage polynomial là où le décodage ML est NP-difficile. Le graphe de Tanner fournit un cadre géométrique naturel pour les algorithmes itératifs — du Bit-Flipping simple jusqu'au Sum-Product qui approche Shannon à 1 dB. Mon implémentation en Rust — disponible en annexe — couvre la génération de H par Gallager et MacKay-Neal, l'encodage systématique, et les trois décodeurs. Les perspectives naturelles sont : les QC-LDPC pour l'implémentation parallèle sur FPGA, qui sont le standard en DVB-S2 et 5G NR, et des tests sur canal réel. Je suis à votre disposition pour vos questions. » +
+
+ ⚠️ +
La slide elle-même est quasi-vide. Ce script est impératif — il faut tout dire à l'oral pour donner une vraie conclusion. Ne pas se contenter de lire les 3 mots affichés.
+
+
+
+ +
+
+
+ + +
+
+ 04 +

Points techniques à maîtriser

+
+

Ces points reviendront en questions du jury. Savoir les expliquer rapidement à l'oral, sans notes.

+ +
+ +
+

// Mise à jour Sum-Product (CN)

+
m_{c→v} = 2 tanh⁻¹( ∏_{u∈N(c)\{v}} tanh(m_{u→c}/2) )
+

Savoir d'où ça vient : probabilité conditionnelle de parité, lemme de Gallager, passage en LLR via tanh. La dérivation complète est en annexe dans ta présentation. L'intuition : c'est le produit des « croyances » des voisins, exprimées via tanh, puis repassé en LLR via tanh⁻¹.

+
+ +
+

// Min-Sum : pourquoi ça marche ?

+
tanh(x/2) ≈ sgn(x) · e^{-|x|/2} pour |x| grand
+

L'approximation : le minimum de |m_{u→c}| domine le produit des tanh. On remplace le produit par un minimum. Le facteur α ∈ [0.75, 0.875] compense le biais introduit par l'approximation. Compromis : perte de 0.2–0.5 dB vs Sum-Product, mais implémentable avec des comparateurs et des XOR.

+
+ +
+

// Pourquoi le BP n'est-il pas exact ?

+

Le BP est exact sur un arbre (graphe sans cycles) — il converge en diamètre(G) itérations. Sur un graphe avec des cycles, les messages se propagent et reviennent à leur point de départ après ℓ itérations (ℓ = girth/2), créant des corrélations artificielles. Ces corrélations violent l'hypothèse d'indépendance des messages entrants, ce qui rend le BP approximatif. Girth élevé → indépendance maintenue plus longtemps → meilleures performances.

+
+ +
+

// LLR sur canal AWGN

+
L^canal(y_i) = 2y_i / σ²
+

Avec BPSK : bit 0 → +1, bit 1 → −1. Signal reçu y_i = x_i + n_i, n_i ~ N(0, σ²). Le LLR initial est proportionnel au signal reçu — c'est la décision soft optimale sur ce canal. σ² = N₀/2 = 1/(2Rσ_SNR).

+
+ +
+

// Pourquoi les LDPC approchent Shannon ?

+

La « Density Evolution » (Richardson-Urbanke) permet de calculer analytiquement le seuil de convergence du BP en fonction de Eb/N₀ et des distributions de degrés (λ, ρ). Pour des codes irréguliers optimisés, ce seuil peut être à moins de 0.05 dB de la limite de Shannon. En pratique, DVB-S2 (n=64800, irrégulier) est à ~0.5 dB. La longueur n → ∞ permet d'approcher la limite par la loi des grands nombres.

+
+ +
+

// Girth minimum d'un code régulier

+
girth ≥ 4 (toujours pair)
+

Girth = 4 : deux colonnes de H partagent au moins 2 positions de 1 → deux VN ont deux CN en commun → corrélation immédiate. MacKay-Neal garantit girth ≥ 6. PEG maximise le girth en construisant arête par arête via BFS. Girth = 4 est interdit : doit être évité à tout prix dans la construction.

+
+ +
+

// Encodage et complexité

+
    +
  • Gauss-Jordan sur H → G dense → O(n²) : pas viable pour n=64800
    • +
  • Richardson-Urbanke (forme ALT) → O(n + g²) avec g le « gap » très petit
    • +
  • QC-LDPC (blocs circulants) → registres à décalage → O(n) trivial sur FPGA
    • +
  • DVB-S2 : Z=360, blocs 45×90 → n=64800 avec encodage parallèle
    • +
+
+ +
+

// Questions classiques du jury

+
    +
  • « Le BP converge-t-il toujours ? » → Non : trapping sets, pseudo-codewords. On fixe Imax.
    • +
  • « Quelle différence entre Gallager-A et Gallager-B ? » → Seuil de flip : wc vs ≥ b.
    • +
  • « Pourquoi irrégulier > régulier ? » → VN de degré 2 accélèrent la convergence initiale.
    • +
  • « Complexity du BP ? » → O(n·wc·Imax) par trame — linéaire en n.
    • +
  • « C'est quoi un trapping set ? » → Sous-ensemble de VN qui font osciller le décodeur.
    • +
+
+ +
+
+
+ + +
+
+ 05 +

Conseils pour l'oral et le jury

+
+ +
+
+
🎯
+

Pointer systématiquement

+

Pour chaque matrice, graphe ou courbe, pointer avec un stylo ou le doigt. « Ici, cette colonne a wc = 3 uns » en montrant — ça ancre visuellement le discours et donne de l'assurance.

+
+
+
⏱️
+

Surveiller les transitions

+

Les points de contrôle critiques : à la fin de la partie Codes Linéaires (≈ 3min40), à la fin de Tanner (≈ 7min), à la fin de Bit-Flipping (≈ 9min30). Si tu es en retard, compresser les slides 8-9 et 26.

+
+
+
🔗
+

Faire des liens narratifs

+

Nommer explicitement les connexions : slide 25 → « on est à 5 dB de Shannon », slide 32 → « Sum-Product est à 1 dB », puis « voilà pourquoi DVB-S2 utilise les LDPC ». Le jury doit sentir une progression logique.

+
+
+
📖
+

Formuler en français courant

+

Pour les formules, ne pas lire les symboles — expliquer en mots : « ce produit porte sur tous les voisins du nœud de contrôle sauf celui à qui on envoie le message ». Ça montre une vraie compréhension.

+
+
+
💻
+

Valoriser le code Rust

+

Si le jury demande comment tu as implémenté, dire : « en Rust, avec une représentation CSR+CSC pour H — format creux qui respecte la faible densité —, et un graphe de Tanner précalculé pour le décodage ». Ne pas plonger dans le code en présentation.

+
+
+
🖼️
+

La slide image (30/35)

+

C'est ton argument visuel le plus fort. Si tu sens le jury décrocher, cette slide les raccroche instantanément. Prends le temps de laisser le visuel parler 2 secondes avant d'expliquer.

+
+
+
❓
+

Répondre aux questions

+

Si une question porte sur un concept en annexe (Richardson-Urbanke, codes irréguliers, QC-LDPC, canal AWGN, trapping sets), y répondre directement — tu as tout dans les annexes. Proposer d'y aller si besoin.

+
+
+
🤝
+

Incarner le chercheur

+

Dire « j'ai implémenté », « j'ai simulé », « j'ai observé » — pas « on voit que ». Tu es l'auteur du travail. La courbe de l'image transie — c'est toi qui l'as produite. Le girth de ton code — tu l'as calculé.

+
+
+
🏁
+

Finir en force

+

Les derniers mots de ta conclusion doivent être clairs, posés, avec un regard vers le jury : « Je suis à votre disposition pour vos questions. » Pas d'hésitation, pas de « voilà ». Une phrase ferme, un silence. Ça marque.

+
+
+
+ + + + + +