Die Wiederentdeckung des G.722: Wie PCMFlow722 die ESP-NOW-Sprachkommunikation auf HD-Niveau hebt

Autor: DerSchneider

Einleitung: Eine alte Lösung für ein neues Problem

Die Welt der Mikrocontroller-Kommunikation gleicht oft einer Reise zurück in die Anfänge digitaler Audioübertragung. Während Smartphones und Breitbandverbindungen längst High-Definition-Sprache mit breitbandigen Codecs wie Opus oder AAC selbstverständlich gemacht haben, kämpfen Bastler und Entwickler mit ESP32-basierten Systemen noch mit den Beschränkungen einfacher Funkprotokolle. Das kürzlich vorgestellte Projekt PCMFlow722 des Entwicklers Tanaka Masayuki markiert einen bemerkenswerten Wendepunkt: Es bringt HD-Sprache über das minimalistische ESP-NOW-Protokoll – und das mit einem Codec, der dieses Jahr sein 40-jähriges Jubiläum feiern könnte.

Der Clou: PCMFlow722 nutzt den G.722-Codec, einen 1984 von der ITU-T standardisierten Breitband-Audiocodec, der ursprünglich für die professionelle Telefonie und Konferenzsysteme entwickelt wurde. Die Bibliothek ermöglicht halbduplex Echtzeit-Kommunikation mit 7 kHz Audio-Bandbreite bei nur 64 kbit/s – bei gleicher Paketgröße wie das deutlich schlechtere G.711.

Dieser Artikel beleuchtet die technischen Hintergründe, historischen Entwicklungen und praktischen Implikationen dieses Projekts. Er fragt, warum ein 40 Jahre alter Codec heute plötzlich wieder relevant wird, welche Kompromisse die Entwicklung birgt und was das für die Zukunft der ESP32-Funkkommunikation bedeutet.

Teil 1: Technische Grundlagen – Was PCMFlow722 leistet

1.1 Die drei Säulen des Systems

Das Projekt basiert auf drei zentralen Technologien, deren Zusammenspiel präzise auf die Beschränkungen von ESP-NOW abgestimmt ist:

Der entscheidende technische Durchbruch liegt in der Wahl des 20-ms-Frames: Bei 16 kHz Abtastrate erzeugt G.722 genau 160 Bytes an komprimierten Daten – das sind nur 64 % der maximalen ESP-NOW-Paketgröße, bleibt also Raum für Protokoll-Overhead.

1.2 Vergleich der Audio-Codecs im ESP32-Kontext

Die folgende Tabelle zeigt, warum die Entscheidung für G.722 trotz seines Alters aus technischer Sicht brillant ist:

Besonders aufschlussreich ist der Vergleich mit Opus: Obwohl Opus objektiv den besseren Codec darstellt (bessere Klangqualität bei gleicher oder niedrigerer Bitrate), scheitert er an der ESP32-Hardware. Opus ist für Fließkomma-Berechnungen optimiert und benötigt erheblichen Arbeitsspeicher – Ressourcen, die auf dem ESP32 knapp sind. G.722 hingegen arbeitet mit einfacher Fixpunkt-Arithmetik und kommt mit minimalem RAM aus.

1.3 Halbduplex als bewusste Einschränkung

Die Implementierung ist als Halbduplex ausgelegt – wie bei einem Walkie-Talkie muss eine Taste gedrückt werden, um zu sprechen. Das ist keine technische Schwäche, sondern eine notwendige Anpassung an die Gegebenheiten von ESP-NOW:

• ESP-NOW kann nicht gleichzeitig senden und empfangen
• Vollduplex würde zwei parallele Verbindungen oder ausgefeiltes Time-Division Duplexing erfordern
• Die Latenz würde durch Pufferung und RTS/CTS-Mechanismen erheblich steigen

Für den Einsatzzweck (Walkie-Talkie-Äquivalent) ist Halbduplex jedoch völlig ausreichend.

Teil 2: Historische Einordnung – Die Geburt des G.722 vor 40 Jahren

2.1 Der Stand der Technik 1984

Um die Bedeutung von G.722 zu verstehen, ist ein Blick in die Mitte der 1980er Jahre notwendig:

• Telefonnetze waren analog oder nutzten einfache PCM-Codierung mit 8 kHz Abtastrate (G.711)
• Audio-Bandbreite im Telefonnetz: 300 Hz bis 3.400 Hz – ausreichend für Sprachverständlichkeit, aber metallisch und nasal
• Erste digitale Konferenzsysteme scheiterten an der schlechten Sprachqualität
• ISDN (Integrated Services Digital Network) wurde gerade eingeführt, mit 64 kbit/s Kanälen

Die ITU-T (damals noch CCITT) erkannte das Problem: Für professionelle Telefonkonferenzen und Rundfunk-Übertragungen war die herkömmliche Telefonqualität unzureichend. Das Ziel war ein Codec, der bei ISDN-tauglichen 64 kbit/s eine Bandbreite von 50 Hz bis 7 kHz übertragen kann – das entspricht in etwa der Qualität eines UKW-Radios.

2.2 Die technische Innovation von G.722

G.722 nutzt ein Subband-ADPCM-Verfahren (Adaptive Differential Pulse Code Modulation) – ein für die 80er Jahre revolutionärer Ansatz:

1. Das Eingangssignal (16 kHz Abtastrate) wird in zwei Frequenzbänder aufgeteilt: ein unteres Band (0-4 kHz) und ein oberes Band (4-8 kHz)
2. Beide Bänder werden separat mit ADPCM codiert
3. Das untere Band erhält 48 kbit/s, das obere Band 16 kbit/s
4. Die Gesamtbitrate beträgt 64 kbit/s – perfekt für einen ISDN-B-Kanal

Die Besonderheit: ADPCM codiert nicht den absoluten Signalwert, sondern die Differenz zwischen vorhergesagtem und tatsächlichem Wert. Das spart Bits, ohne die Qualität stark zu beeinträchtigen, und arbeitet ausschließlich mit Fixpunkt-Arithmetik – ein entscheidender Vorteil für die spätere Implementierung auf Mikrocontrollern.

2.3 Vom professionellen Nischenprodukt zum Vergessen

Trotz seiner technischen Überlegenheit blieb G.722 lange Zeit ein Nischenprodukt:

• ISDN setzte sich im Massenmarkt nie durch (besonders nicht in den USA)
• Die benötigten 16-kHz-Audio-Hardware war in den 80er/90er Jahren teuer
• Für normale Telefonate war G.711 „gut genug“
• Mobile Netze (GSM) setzten auf eigene, schmalbandige Codecs (GSM-FR, später EFR, AMR)

Erst mit dem Aufkommen von VoIP und Wideband Voice (HD Voice) Anfang der 2000er Jahre erlebte G.722 ein kurzes Revival. Zahlreiche VoIP-Anbieter und Konferenzsysteme setzten auf G.722 – bis es ab etwa 2010 durch modernere Codecs wie G.722.1 (Polycom Siren7), AAC-LD oder Opus abgelöst wurde.

2.4 Die ironische Rückkehr: Warum G.722 heute für den ESP32 perfekt ist

Die Embedded-Welt dreht die Zeit zurück: Was als veraltet galt, ist plötzlich wieder hochmodern. Gründe für die Relevanz von G.722 im ESP32-Kontext:

1. Geringe Komplexität: G.722 kommt mit wenigen Kilobyte Code aus (geschätzt 4-8 KB), Opus benötigt 50-100 KB
2. Fixpunkt-Optimierung: Keine Fließkomma-Operationen nötig, daher schnell und deterministisch
3. Ausgelaufene Patente: G.722 ist gemeinfrei (die ältesten Patente liefen um 2004-2006 aus)
4. Bekannte Implementierungen: Zahlreiche Open-Source-Referenzimplementierungen verfügbar
5. Perfekte Paketgröße: Die 20-ms-Frames passen ideal zu ESP-NOW

In gewisser Weise wiederholt sich hier die Geschichte: Was für ISDN-Kanäle entwickelt wurde, passt heute perfekt in die ESP-NOW-Pakete – beides sind 64-kbit/s-Kanäle mit ähnlichen Latenzanforderungen.

Teil 3: Kritische Analyse – Einschränkungen und offene Fragen

3.1 Die Halbduplex-Problematik im Detail

Der Artikel und die Kommentare erwähnen die Halbduplex-Eigenschaft, gehen aber nicht auf die praktischen Konsequenzen ein:

• Kollisionen: Wenn zwei Teilnehmer gleichzeitig senden (weil beide die Taste drücken), kollidieren die Pakete im Luftraum. ESP-NOW hat zwar Bestätigungen (ACKs), aber keine ausgefeilte Kollisionsvermeidung wie CSMA/CA im WLAN.
• Push-to-Talk-Verzögerung: Die Verzögerung zwischen Tastendruck und tatsächlichem Sendestart ist im Quelltext nicht dokumentiert.
• Keine automatische Umschaltung: Der Benutzer muss manuell zwischen Senden und Empfangen wechseln – das ist nicht „Echtzeit-Kommunikation“ im engeren Sinne, sondern ein digitales Walkie-Talkie.

Ein echter Vollduplex-Betrieb würde Time-Division Duplexing (TDD) erfordern – also eine Zeitschlitz-Verwaltung, bei der abwechselnd gesendet und empfangen wird. Das wäre technisch möglich (jeder Teilnehmer sendet in einem eigenen Zeitschlitz), erhöht aber die Latenz und Komplexität erheblich.

3.2 Reichweite vs. Audioqualität – ein ungelöster Konflikt

Ein Kommentator (itchy n scratchy) weist zu Recht darauf hin: G.722 und G.711 haben identische On-Air-Bitrate von 64 kbit/s. Das bedeutet:

• Kein Reichweitenvorteil durch niedrigere Bitrate
• Für größere Reichweiten wären Codecs mit deutlich niedrigerer Bitrate notwendig (z.B. Codec2 mit 1,2-9,6 kbit/s)
• Ein solcher Codec könnte dann über LoRa (Long Range) übertragen werden – mit Kilometern Reichweite, aber roboterhafter Sprachqualität

Hier zeigt sich ein grundlegender Zielkonflikt des Projekts: HD-Qualität oder große Reichweite? PCMFlow722 entscheidet sich klar für Qualität auf Kosten der Reichweite. Das ist legitim, sollte aber kommuniziert werden.

3.3 Skalierbarkeit – Wie viele Teilnehmer sind möglich?

Der Artikel erwähnt „one or more Core2 devices“, bleibt aber vage bezüglich der maximalen Teilnehmerzahl. Basierend auf den ESP-NOW-Spezifikationen:

Die begrenzende Größe ist nicht der Codec, sondern das MAC-Layer-Design von ESP-NOW. Es ist für einfache Sensornetzwerke optimiert, nicht für Echtzeit-Audio mit mehreren Teilnehmern.

3.4 Timing und Latenz – Die unsichtbare Herausforderung

Im Artikel nicht erwähnt, aber kritisch für Echtzeit-Kommunikation: Die Latenz setzt sich zusammen aus:

• Erfassung: 20 ms (ein Frame)
• Codierung: unbekannt, aber vermutlich <5 ms
• ESP-NOW Übertragung: typisch 1-10 ms (abhängig von Interferenzen)
• Decodierung: <5 ms
• Wiedergabe: 20 ms (Pufferung)

Gesamtlatenz schätzungsweise 50-80 ms – das ist für Walkie-Talkie akzeptabel, aber am oberen Limit für flüssige Konversation. Problematisch wird es bei:

• Paketverlusten: ESP-NOW wiederholt verlorene Pakete nicht automatisch
• Schwankender Latenz (Jitter): Kein Puffer-Mechanismus im Quelltext erwähnt

Teil 4: Praktische Implikationen – Für wen ist PCMFlow722 sinnvoll?

4.1 Ideale Anwendungsfälle

Das Projekt glänzt in Szenarien mit folgenden Eigenschaften:

• Kurze Distanzen (<50 m Sichtkontakt)
• Wenige Teilnehmer (2-4)
• Keine Vollduplex-Notwendigkeit
• Betonung auf Sprachqualität statt Reichweite
• Bastler-/Bildungskontext (Lernprojekt)

Konkrete Beispiele:

• Funkrufsystem in einem Maker Space (Ausstellungen, Workshops)
• Kommunikationssystem für Modellbau (RC-Fahrzeuge, Drohnen mit Sprachlink)
• Lernprojekt für Studenten (Audio-Codecs, Funkprotokolle)
• Intercom in kleinen Gebäuden (Werkstatt, Labor)

4.2 Weniger geeignete Szenarien

Das Projekt ist nicht zu empfehlen für:

• Große Gebäude oder Außenbereiche (Reichweite zu gering)
• Mehrere simultane Sprecher (Kollisionen)
• Sicherheitskritische Anwendungen (keine garantierte Paketzustellung)
• Professionelle Funkgeräte (fehlende Zertifizierung, keine Notruffunktionen)

4.3 Vergleich mit alternativen Lösungen

PCMFlow722 füllt eine Nische: Billig, gute Qualität, kurze Reichweite, kein Infrastrukturbedarf. Das ist genau das, was Maker und Hobbyisten oft brauchen.

Teil 5: Zukunftsperspektiven – Wohin könnte die Reise gehen?

5.1 Technische Weiterentwicklungen

Aus technischer Sicht sind folgende Erweiterungen denkbar:

1. Dynamische Bitratenanpassung: Die ESP-NOW-Kanalqualität messen und die G.722-Bitrate auf 48 oder 56 kbit/s reduzieren (durch Weglassen des oberen Bandes) – das erhöht die Robustheit bei schlechtem Empfang.
2. Vorwärtsfehlerkorrektur (FEC): Einfache Reed-Solomon-Codes über mehrere Pakete könnten Paketverluste ausgleichen, ohne die Latenz stark zu erhöhen.
3. Automatische Umschaltung (Voice Operated Switch – VOX): Erkennung von Sprache im Audiosignal, automatischer Wechsel zwischen Senden/Empfangen – das wäre ein echter Fortschritt gegenüber Push-to-Talk.
4. Plausible Vollduplex-Implementierung: Time-Division Duplexing mit festen Zeitschlitzen (z.B. alle 40 ms wechseln). Das würde die Nutzbarkeit massiv erhöhen, aber die Latenz verdoppeln.

5.2 Hardware-Alternativen

Die ESP32-Plattform ist nicht in Stein gemeißelt. Interessante Alternativen für zukünftige Portierungen:

• Raspberry Pi Pico W (RP2040 mit CYW43439): Ähnliche Leistung, aber weniger etabliertes ESP-NOW-Äquivalent
• ESP32-S3 (noch mehr Rechenleistung, evtl. Opus möglich)
• nRF52-Serie (Bluetooth LE, anderer Ansatz)

Besonders spannend: Der ESP32-C6 mit IEEE 802.15.4 (Thread/Zigbee) – das würde den Weg für 6LoWPAN-basierte Sprachkommunikation öffnen.

5.3 Die größere Frage: Brauchen wir G.722 oder etwas ganz Neues?

Die Wiederentdeckung von G.722 wirft eine grundsätzliche Frage auf: Ist es sinnvoll, alte Codecs zu reanimieren, oder sollten wir neue, speziell für Embedded-Systeme optimierte Codecs entwickeln?

Ein Kommentar im Artikel (itchy n scratchy) erwähnt den GSM Full Rate (GSM-FR) Codec – 13 kbit/s, einfache Fixpunkt-Implementierung, aber schmalbandig (3,4 kHz). Das wäre ein Kompromiss zwischen Reichweite und Qualität.

Die ultimative Lösung könnte ein Hybrid-Ansatz sein:

• Gutem Empfang: G.722 mit 64 kbit/s für HD-Qualität
• Schlechtem Empfang: GSM-FR mit 13 kbit/s für Basis-Kommunikation
• Sehr schlechtem Empfang: Codec2 mit 2,4 kbit/s für „Notfallmodus“

Eine solche adaptive Codec-Umschaltung ist technisch anspruchsvoll, aber durchaus machbar – und würde die Einsetzbarkeit enorm verbessern.

Fazit & Ausblick

Das PCMFlow722-Projekt ist mehr als nur eine weitere Arduino-Bibliothek. Es ist ein Paradebeispiel für technischen Pragmatismus in der Embedded-Welt: Die Wahl eines 40 Jahre alten Codecs erweist sich aus heutiger Sicht als genialer Schachzug, der perfekt zu den Beschränkungen von ESP-NOW passt.

Die Stärken liegen auf der Hand:

• HD-Sprachqualität mit minimalen Ressourcen
• Einfache Implementierung dank ausgelaufener Patente
• Perfekte Passung zu ESP-NOW-Paketgrößen
• Funktionierender Proof-of-Concept auf Standard-Hardware

Die Schwächen sind ebenso klar:

• Halbduplex mit manueller Umschaltung
• Begrenzte Reichweite (kein Vorteil gegenüber G.711)
• Schlechte Skalierbarkeit auf viele Teilnehmer
• Keine Fehlerkorrektur bei Paketverlusten

Für die Community der Maker, Hobby-Elektroniker und Studierenden ist PCMFlow722 eine absolute Bereicherung. Es senkt die Einstiegshürde für Echtzeit-Audio über ESP32 drastisch und zeigt, dass man nicht immer den neuesten, komplexesten Codec braucht.

Der kritische Ausblick: In zwei bis drei Jahren werden wir wahrscheinlich eine Opus-Portierung für ESP32 sehen, sobald die Fließkomma-Performance der Chips ausreicht oder eine optimierte Fixpunkt-Version existiert. Bis dahin bleibt G.722 die beste Wahl – ein würdiger Senior unter den Audiocodecs, der zeigt, dass gutes Design niemals veraltet.

Die eigentliche Lehre aus PCMFlow722 lautet: Technischer Fortschritt ist nicht immer linear. Manchmal liegt die Lösung nicht im Neuesten, sondern im am besten Geeigneten. Das ist eine Lektion, die nicht nur für Embedded-Entwickler, sondern für Ingenieure aller Disziplinen relevant ist.

Quellen

1. CNX Software (2026): „PCMFlow722 library enables two-way real-time HD voice over ESP-NOW with G.722 audio codec“ – Originalartikel
2. ITU-T Recommendation G.722 (1984, mehrere Revisionen): „7 kHz audio-coding within 64 kbit/s“ – International Telecommunication Union
3. Espressif Systems (2021-2026): ESP-NOW Dokumentation und API-Referenz – https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/network/esp_now.html
4. Tanaka Masayuki: PCMFlow722 GitHub Repository (angenommen, nicht direkt im Artikel verlinkt, aber als primäre Quelle genannt)
5. Atomic14 (ca. 2021): „ESP32 Walkie Talkie“ Projekt (im Artikel als historischer Vorläufer erwähnt)
6. Adafruit Industries: „ESP-NOW Walkie-Talkie“ Projekt (im Artikel als weiterer Vorläufer genannt)
7. Xiph.Org Foundation: Opus Codec Dokumentation und Vergleichswerte – https://opus-codec.org/comparison/
8. Rowetel.com (David Rowe): Codec2 – Open Source Speech Codec – https://www.rowetel.com/wordpress/?page_id=452 (für den Vergleich mit schmalbandigen Codecs)