[{"id":4801,"date":"2026-06-12T15:48:18","date_gmt":"2026-06-12T13:48:18","guid":{"rendered":"https:\/\/www.kernel-error.de\/?p=4801"},"modified":"2026-06-12T15:48:18","modified_gmt":"2026-06-12T13:48:18","slug":"von-seo-zu-aeo-kassensturz-maschinenlesbare-identitaet","status":"publish","type":"post","link":"https:\/\/www.kernel-error.de\/2026\/06\/12\/von-seo-zu-aeo-kassensturz-maschinenlesbare-identitaet\/","title":{"rendered":"Von SEO zu AEO, der Kassensturz: was eine maschinenlesbare Identit\u00e4t wirklich bringt"},"content":{"rendered":"
\n
\"Visualisierung<\/a><\/figure>\n<\/div>\n\n\n

Am 1. Januar habe ich hier einen Beitrag geschrieben, der eine Wette war. Die These: Web-Optimierung verschiebt sich. Weg von SEO, dem Kampf um die beste Platzierung bei Google, hin zu etwas, das ich AEO genannt habe. Answer Engine Optimization. Also nicht mehr \u201ewie komme ich auf Platz eins“, sondern \u201ewie liefere ich die beste maschinenlesbare Antwort“. Ich habe damals llms.txt eingebaut, ein bisschen \u00fcber JSON-LD geschrieben und ehrlich dazugesagt, dass niemand wei\u00df, ob das langfristig relevant bleibt. Der letzte Satz war: ich bin gespannt, was passiert.<\/p>\n\n\n\n

Jetzt ist ein gutes halbes Jahr vergangen. Zeit f\u00fcr einen Kassensturz. Was davon hat sich gehalten, was war naiv, was hat sich differenziert? Und vor allem: ich habe in den letzten Monaten tats\u00e4chlich daran gearbeitet, mich f\u00fcr eine Maschine sauber beschreibbar zu machen. Nicht als Theorie, sondern an der eigenen Seite, mit allen Fehlern, die dabei sichtbar wurden. Genau diese Fehler und die Abw\u00e4gungen dahinter sind der eigentliche Inhalt dieses Beitrags. Wer den Vorg\u00e4ngerpost noch nicht kennt, findet ihn hier: Von SEO zu AEO, warum llms.txt, JSON-LD und Answer Engines das Web ver\u00e4ndern<\/a>.<\/p>\n\n\n\n

Die Suche wird zur Antwortmaschine<\/h3>\n\n\n\n

Fangen wir mit dem an, was sich gerade wirklich ver\u00e4ndert, unabh\u00e4ngig von meinem Blog. Wer heute etwas googelt, bekommt immer \u00f6fter die Antwort direkt auf der Ergebnisseite. Eine zusammengefasste KI-Antwort, darunter vielleicht ein paar Quellen. Der Klick auf eine Webseite entf\u00e4llt. Daf\u00fcr gibt es einen Begriff: Zero-Click-Suche. Die Information erreicht den Menschen, ohne dass er die Seite besucht, von der sie stammt.<\/p>\n\n\n\n

Das ist keine Vermutung, das l\u00e4sst sich messen. Das Pew Research Center<\/a> hat Daten aus dem Fr\u00fchjahr 2025 ausgewertet, ver\u00f6ffentlicht im Juli 2025: das Surfverhalten von rund 900 erwachsenen US-Nutzern, knapp 68.900 Google-Suchanfragen. Das Ergebnis: bekamen die Leute eine KI-Zusammenfassung angezeigt, klickten nur noch 8 Prozent auf einen weiterf\u00fchrenden Treffer. Ohne KI-Zusammenfassung waren es 15 Prozent, fast doppelt so viel. Auf die in der KI-Antwort verlinkten Quellen klickte \u00fcberhaupt nur 1 Prozent. Fairerweise dazugesagt: Google h\u00e4lt die Methodik dieser Studie f\u00fcr nicht repr\u00e4sentativ, hat aber keine eigenen Gegenzahlen vorgelegt. Zur Einordnung der Gr\u00f6\u00dfenordnung: schon bei der ganz normalen Google-Suche endet ein gro\u00dfer Teil ohne Klick. Die Zero-Click-Studie von SparkToro<\/a> (Rand Fishkin, 2024, Datenbasis Datos, das zu Semrush geh\u00f6rt) kommt auf rund 58 Prozent in den USA und knapp 60 Prozent in der EU, neuere Auswertungen f\u00fcr 2026 eher Richtung zwei Drittel. Und ein Hinweis zur Vorsicht, weil die Zahl gern falsch zitiert wird: die oft genannten 93 Prozent Zero-Click gelten ausschlie\u00dflich f\u00fcr Googles AI Mode, also den dialogorientierten Chat-Modus der Suche (Semrush<\/a> ma\u00df dort 92 bis 94 Prozent), nicht f\u00fcr die normale Suche. Wer diese Schlagzeile unbesehen \u00fcbernimmt, vergleicht \u00c4pfel mit Birnen.<\/p>\n\n\n\n

Wie stark der Effekt kausal ist, hat ein randomisiertes Feldexperiment<\/a> von Saharsh Agarwal (Indian School of Business) und Ananya Sen (Carnegie Mellon University) untersucht, Feldphase Januar und Februar 2026, 1.065 ausgewertete US-Desktop-Nutzer von Chrome. Auf den Suchanfragen, bei denen tats\u00e4chlich eine KI-\u00dcbersicht erschien, sanken die organischen Klicks um etwa 38 Prozent, die Zero-Click-Rate stieg von 54 auf 72 Prozent. Wichtig f\u00fcr die Einordnung: das ist ein noch nicht begutachtetes Arbeitspapier, online seit April 2026, und die Stichprobe sind aktive Desktop-Chrome-Nutzer aus einem Panel, nicht alle Google-Nutzer. Das Studiendesign war immerhin vorab registriert, was die Aussagekraft st\u00fctzt. Trotzdem bleibt es ein Befund mit klaren Grenzen. Die Pointe ist nicht, dass die Suche stirbt, sondern etwas N\u00fcchterneres: Sichtbarkeit entkoppelt sich vom Klick. Man kann als Quelle einer Antwort auftauchen, ohne dass jemand die eigene Seite \u00f6ffnet.<\/p>\n\n\n\n

Vom String zum Ding<\/h3>\n\n\n\n

Jetzt wird es interessant, denn hier liegt der Mechanismus, der mitentscheidet, ob man in so einer Antwort \u00fcberhaupt vorkommt. Schon 2012 hat Google den Knowledge Graph eingef\u00fchrt, unter dem Slogan \u201eThings, not strings“<\/a>. \u00dcbersetzt: Dinge, nicht Zeichenketten. Davor war eine Suchmaschine im Kern ein Textabgleich. Du tippst Buchstaben, sie sucht Seiten mit denselben Buchstaben. Seitdem versucht Google, hinter den Buchstaben das tats\u00e4chliche Ding zu erkennen. Eine Entit\u00e4t. Ein eindeutig identifizierbares Etwas mit Beziehungen zu anderen eindeutig identifizierbaren Etwas.<\/p>\n\n\n\n

Das klassische Beispiel ist das Wort Jaguar. Tier, Auto oder Betriebssystem? Ein Mensch erkennt aus dem Zusammenhang sofort, was gemeint ist. Eine Maschine muss disambiguieren, also die Mehrdeutigkeit aufl\u00f6sen. Und genau dasselbe Problem gilt f\u00fcr mich. Welcher Sebastian van de Meer? Es gibt mehr als einen Menschen mit diesem Namen. F\u00fcr eine Maschine ist mein Name erst einmal nur eine Zeichenkette, die zu mehreren Personen passt. Eindeutigkeit wird belohnt. Es gibt dazu einen vielzitierten Datenpunkt, den ich ehrlich einordnen muss: laut einer Auswertung von Kalicube<\/a> (Jason Barnard, ver\u00f6ffentlicht bei Search Engine Land im August 2025) verschwanden im Juni 2025 \u00fcber drei Milliarden Eintr\u00e4ge aus dem Knowledge Graph, ein R\u00fcckgang von rund sechs Prozent, verteilt auf zwei Stichtage. Google hat das nie offiziell best\u00e4tigt, und die Deutung, dass hier Klarheit \u00fcber Masse gewinnt, ist die des Analysten, nicht Googles erkl\u00e4rter Grund. Also ein Indiz, kein Gesetz. Der Knowledge Graph selbst speist sich nach Googles eigenen Angaben unter anderem aus Wikipedia, Branchenquellen nennen erg\u00e4nzend Wikidata, und er ist das Bindeglied zwischen klassischer Suche und KI-Antworten. Googles KI-Suche, die auf Gemini basiert, greift nach eigener Darstellung auf den Knowledge Graph als Echtzeit-Quelle zur\u00fcck. Wer dort als saubere Entit\u00e4t existiert, ist f\u00fcr beide Welten greifbar.<\/p>\n\n\n\n

Wie man sich einer Maschine als Entit\u00e4t vorstellt<\/h3>\n\n\n\n

Damit sind wir beim Herzst\u00fcck. Wie sage ich einer Maschine glaubw\u00fcrdig, wer ich bin? Das Werkzeug daf\u00fcr hei\u00dft JSON-LD nach dem schema.org<\/a>-Vokabular. Vereinfacht: ein maschinenlesbarer Steckbrief, der direkt in der Seite liegt und Fakten ausdr\u00fccklich beschriftet. Das ist der Autor, das ist sein Beruf, das ist das Erscheinungsdatum. Statt die Maschine alles aus Flie\u00dftext erraten zu lassen, legt man ihr die Fakten getypt hin. Eine Klarheits- und Extraktionshilfe, mehr nicht. Keine Garantie auf ein Ranking und keine Garantie, zitiert zu werden. Diese Erwartung muss man sofort d\u00e4mpfen, sonst baut man Luftschl\u00f6sser.<\/p>\n\n\n\n

Aus der abstrakten Ansage von damals ist bei mir eine ziemlich durchdachte Identit\u00e4ts-Architektur geworden. Und ehrlich: das Spannende waren nicht die Zeilen, die ich geschrieben habe, sondern das, was ich dabei gelernt habe. Neun Punkte, die ich so vorher nicht auf dem Schirm hatte.<\/p>\n\n\n\n

Erstens, eine Identit\u00e4t, eine kanonische Adresse.<\/strong> F\u00fcr eine Maschine sollte eine Person genau ein Ding sein, mit einer stabilen Kennung, die \u00fcberall identisch auftaucht, nicht auf jeder Seite neu erfunden. Maschinen l\u00f6sen Identit\u00e4t \u00fcber stabile Identifier auf, nicht \u00fcber Namen. Lose Namensnennungen ohne gemeinsame Kennung werden als verschiedene Menschen gelesen oder gar nicht zusammengef\u00fchrt. Der Preis ist weniger Flexibilit\u00e4t. Der Gewinn ist ein zusammenh\u00e4ngender Knoten statt vieler Splitter.<\/p>\n\n\n\n

Zweitens, eine Wahrheitsquelle statt \u00fcberall dasselbe reinkippen.<\/strong> Die vollst\u00e4ndige Selbstbeschreibung steht bei mir an genau einer Stelle, auf der \u00dcber-mich-Seite. Alle anderen Seiten tragen nur eine schlanke Referenz darauf. Der Grund ist unromantisch: dieselbe Definition \u00fcberall zu duplizieren erzeugt Drift. Man \u00e4ndert eine Stelle, vergisst die anderen, und am Ende widerspricht sich der eigene Datensatz selbst. Die Abw\u00e4gung: die schlanke Referenz darf nicht zu d\u00fcnn sein, sonst findet ein Crawler, der zuf\u00e4llig nur eine Artikelseite erwischt, keinen Anker zur\u00fcck zum Profil.<\/p>\n\n\n\n

Drittens, Privates geh\u00f6rt nicht in den maschinenlesbaren Broadcast.<\/strong> Das war f\u00fcr mich die wichtigste Einsicht. Telefonnummer, Adresse und \u00e4hnliches haben f\u00fcr die maschinelle Identifikation exakt null Wert. Disambiguiert wird \u00fcber verlinkte Profile, nicht \u00fcber die Handynummer. Auf jeder einzelnen Seite ausgestrahlt w\u00e4ren solche Daten dagegen eine ideale Fl\u00e4che zum Abgreifen. Also stehen die privaten Angaben jetzt bewusst nur dort, wo sie hingeh\u00f6ren, und sind nicht mehr auf rund 470 Seiten als sauber beschriftete Schl\u00fcssel-Wert-Paare maschinenlesbar verteilt. Das ist die zentrale Abw\u00e4gung zwischen Datenschutz und Maschinenlesbarkeit, und sie f\u00e4llt klar zugunsten Datenschutz aus. Das Sch\u00f6ne: man verliert dabei kein einziges Identit\u00e4ts-Signal.<\/p>\n\n\n\n

Viertens, externe Anker sind die eigentliche Beweiskette.<\/strong> Eine Behauptung \u00fcber mich wird erst dann pr\u00fcfbar, wenn sie auf unabh\u00e4ngige Profile verweist und diese zur\u00fcckverweisen. Bei mir sind das unter anderem GitHub<\/a>, ein Eintrag im BSI-B\u00fcrger-CERT-Netzwerk<\/a>, Mastodon<\/a> und die Bluesky-Br\u00fccke<\/a>, dazu Identifier wie ORCID<\/a> und ein Wikidata-Eintrag<\/a>. Entscheidend ist die Wechselseitigkeit. Ein Verweis z\u00e4hlt nur, wenn die Gegenseite zur\u00fcckzeigt. Anfangs lagen diese Anker nur auf der Profilseite. Das war ein Single Point of Failure: wenn ein Crawler genau diese eine Seite nicht erwischt, ist die Identit\u00e4t nicht mehr belegbar. Also geh\u00f6ren die st\u00e4rksten Anker auf jede Seite. Und die Disziplin dabei: unverifizierbare oder tote Profile l\u00e4sst man weg, weil sie das Signal nur verw\u00e4ssern.<\/p>\n\n\n\n

F\u00fcnftens, innere Widerspruchsfreiheit ist selbst ein Qualit\u00e4tssignal.<\/strong> Ein Beispiel aus der eigenen Seite, das mich erst ge\u00e4rgert und dann \u00fcberzeugt hat: der Herausgeber des Blogs und der Herausgeber der einzelnen Artikel zeigten auf zwei verschiedene, nirgends sauber definierte Stellen. F\u00fcr eine Maschine sieht so etwas aus wie ein Datenfehler und untergr\u00e4bt das Vertrauen in den gesamten Datensatz. Die Lektion war, lieber einen sauber benannten zus\u00e4tzlichen Knoten einzuf\u00fchren, hier die Marke \u201eKernel-Error“ als eigene Herausgeber-Instanz, als zwei sich widersprechende Halbwahrheiten stehen zu lassen. Das ist \u00fcbrigens keine technische Petitesse, sondern eine echte Identit\u00e4ts-Entscheidung: gilt \u201eKernel-Error“ als eigene Marke neben der Person? Ich habe mich daf\u00fcr entschieden, und pl\u00f6tzlich ergab der ganze Rest Sinn.<\/p>\n\n\n\n

Sechstens, einen Wissensgraphen kann man nicht bel\u00fcgen.<\/strong> Das klingt pathetisch, ist aber sehr praktisch gemeint. Alle externen Quellen, auf die ich verweise, sind crawlbar. Jeder Status l\u00e4sst sich gegen das echte Upstream-Projekt pr\u00fcfen. Also habe ich offene Beitr\u00e4ge ehrlich als offen gekennzeichnet, statt sie als erledigt zu verkaufen. Zwei meiner Patches f\u00fcr eine Fingerabdruckleser-Bibliothek sind eingereicht, aber noch nicht gemerged, und genau so steht es da. Behauptungen, die ich nicht belegen kann, etwa angebliche CVEs, die sich \u00f6ffentlich nicht auffinden lassen, habe ich komplett weggelassen. Ein als \u201eerledigt“ deklarierter, in Wahrheit offener Beitrag ist ein sofort widerlegbarer Fehler, und der besch\u00e4digt die Glaubw\u00fcrdigkeit des gesamten Profils. Die Abw\u00e4gung ist unbequem: das Profil sieht weniger beeindruckend aus. Aber ein einziger entlarvter Fake-Claim ist teurer als zehn ehrliche kleine. Vertrauen entsteht aus Pr\u00fcfbarkeit, nicht aus Behauptung.<\/p>\n\n\n\n

Siebtens, Expertise belegt man mit Artefakten, nicht mit Adjektiven.<\/strong> Niemand muss mir glauben, dass ich etwas kann. Sie k\u00f6nnen es nachsehen. Konkrete, von Dritten kontrollierbare Arbeiten sind der st\u00e4rkste maschinenlesbare Beleg. Ein in ein fremdes Projekt aufgenommener Patch verankert mich im Linkgraph dieses fremden, autoritativen Projekts. Ein eigenes Repository ist \u00fcberpr\u00fcfbarer Code, kein Selbstlob. Die Disziplin dahinter: nur real Existierendes, korrekt zugeschrieben. Fremde Maintainer-Arbeit f\u00fchre ich nicht als meine. Bei einem Rezensions-Artikel \u00fcber ein Tool, das mir nicht geh\u00f6rt, bleibt die Urheberschaft beim Upstream. Und F\u00fcllmaterial wie Trivia oder Verzeichnis-Eintr\u00e4ge bleibt bewusst drau\u00dfen, um das Signal nicht zu verw\u00e4ssern.<\/p>\n\n\n\n

Achtens, wer alles kennt, l\u00f6st auf nichts auf.<\/strong> Meine Themenliste hatte \u00fcber 40 mehr oder weniger beliebige Schlagworte. Das habe ich auf eine Handvoll fokussierte Kernthemen zusammengestrichen, m\u00f6glichst als eindeutige Referenzen statt als nackte W\u00f6rter. Der Grund: zu viele Themen verw\u00e4ssern das Signal so sehr, dass man f\u00fcr kein einziges Feld als Autorit\u00e4t erkennbar ist. Die Wette dahinter ist, dass ein scharfes Profil in wenigen Feldern f\u00fcr eine Antwortmaschine wertvoller ist als eine lange, unscharfe Stichwortliste. Der Preis ist Breite bei Nischen-Anfragen. Den zahle ich gerne.<\/p>\n\n\n\n

Neuntens, jede Seite soll sagen, was sie ist.<\/strong> Profilseite, Kontaktseite, Artikel, Autorenarchiv: jeder Seitentyp deklariert jetzt seine Rolle und welche Rolle ich dort spiele. Das st\u00e4rkste Signal \u201ediese Adresse ist das kanonische Profil dieser Person“ entsteht erst dadurch, dass die Profilseite sich auch als Profilseite zu erkennen gibt. Vorher sah sie f\u00fcr eine Maschine aus wie jede beliebige andere Seite und verschenkte diese Aussage komplett. Die Abw\u00e4gung: mehr Fallunterscheidung im Code, daf\u00fcr pr\u00e4zise, rollenrichtige Signale.<\/p>\n\n\n\n

Wie Antwortmaschinen ihre Quellen w\u00e4hlen<\/h3>\n\n\n\n

Eine einzelne perfekte Seite reicht nicht. KI-Systeme kreuzpr\u00fcfen eine Entit\u00e4t \u00fcber mehrere unabh\u00e4ngige Quellen, bevor sie zitieren. Im schema.org-Vokabular hei\u00dft das Stichwort sameAs, frei \u00fcbersetzt der Verweis auf denselben Ausweis anderswo. Konsistente, echte Verweise erh\u00f6hen die Vertrauensw\u00fcrdigkeit, garantieren aber nichts. Es braucht \u00fcbereinstimmende Spuren an mehreren Orten. Und Vorsicht vor dem Trugschluss \u201emehr ist besser“: tote oder inkonsistente Verweise schaden, nur gepflegte, echte Profile z\u00e4hlen.<\/p>\n\n\n\n

Der vielleicht wichtigste Befund f\u00fcr alle, die keine Marketing-Abteilung haben: Zitierw\u00fcrdigkeit ist nicht dasselbe wie Ranking. Ahrefs<\/a> hat im August 2025 rund 15.000 Long-Tail-Anfragen ausgewertet und KI-Assistenten wie ChatGPT, Gemini und Perplexity dieselben Fragen gestellt. Ergebnis: im Schnitt ranken nur rund 12 Prozent der von diesen Tools zitierten URLs in Googles Top 10, rund 88 Prozent also nicht. Etwa 80 Prozent tauchen f\u00fcr die urspr\u00fcngliche Anfrage \u00fcberhaupt nicht in Googles Ergebnissen auf. Ein Detail der Ehrlichkeit halber: das ist ein Durchschnitt, und Perplexity schert mit knapp 29 Prozent \u00dcberschneidung deutlich nach oben aus, h\u00e4ngt also st\u00e4rker an der klassischen Suche als die anderen. Die Botschaft bleibt trotzdem: Antwortmaschinen w\u00e4hlen nach antwortfertig, glaubw\u00fcrdig und strukturell sauber, nicht prim\u00e4r nach Suchplatzierung. Genau deshalb kann ein Nischenblog ohne Spitzen-Rankings trotzdem zitierf\u00e4hig sein. Wer nur in Keyword-Rankings denkt, greift zu kurz.<\/p>\n\n\n\n

Und was steigert nun messbar die Sichtbarkeit in generativen Antworten? Eine viel zitierte akademische Arbeit<\/a> von Forschenden der Princeton University und des IIT Delhi, dazu zwei unabh\u00e4ngige Autoren, hat genau das untersucht, vorgestellt auf der KDD 2024. Sie gilt als die erste Arbeit, die den Begriff Generative Engine Optimization gepr\u00e4gt hat. Die Antwort ist herrlich unspektakul\u00e4r, und das ist die eigentliche Pointe. Was hilft, ist: w\u00f6rtliche Zitate einbauen (in der Studie der st\u00e4rkste Hebel mit rund 41 Prozent mehr Sichtbarkeit), Statistiken nennen (rund 33 Prozent), Quellen angeben (rund 28 Prozent), fl\u00fcssig und gut lesbar schreiben (\u00e4hnliche Gr\u00f6\u00dfenordnung). Insgesamt bis zu rund 40 Prozent mehr Sichtbarkeit. Zwei Einschr\u00e4nkungen geh\u00f6ren dazu: gemessen wurde nicht Traffic oder Klicks, sondern eine positionsgewichtete Sichtbarkeit innerhalb der KI-Antwort, und die Prozente sind relativ zu einer unoptimierten Ausgangsversion. Das Schlusslicht, mit deutlichem Abstand: klassisches Keyword-Stuffing senkte die Sichtbarkeit sogar, um rund 8 bis 9 Prozent. Die Botschaft ist also kein Geheimtrick, sondern fast schon eine Erl\u00f6sung: gute, belegte, lesbare Substanz ist die Strategie. Das ist auch der Kern von E-E-A-T, also Erfahrung, Fachkenntnis, Autorit\u00e4t und Vertrauen. Kein Algorithmus-Schalter, sondern ein Signalb\u00fcndel. Und genau hier zahlt die verifizierte Identit\u00e4t ein: echte Werke, externe Best\u00e4tigung und Konsistenz machen Erfahrung und Expertise \u00fcberhaupt erst maschinell nachvollziehbar.<\/p>\n\n\n\n

Ehrlicher Kassensturz<\/h3>\n\n\n\n

Bleibt die unbequeme Frage: hat das alles etwas gebracht? Fangen wir mit der Korrektur meiner eigenen Anfangs-Wette an, der llms.txt. Die l\u00e4uft live, der Aufwand f\u00fcr die Datei ist billig und harmlos. Aber sie ist kein bewiesener Hebel. Auf der Search Central Live im Juli 2025<\/a> stellte Gary Illyes klar, dass llms.txt keine Google-Initiative ist und Google nicht plant, das Format zu unterst\u00fctzen. John Mueller<\/a> hatte sie schon im Fr\u00fchjahr 2025 mit dem l\u00e4ngst ignorierten Keywords-Meta-Tag verglichen, weil sie vom Seitenbetreiber kontrolliert und damit letztlich eine Selbstauskunft ist, die man genauso gut direkt an der Seite \u00fcberpr\u00fcfen k\u00f6nnte. Im Dezember 2025 tauchte eine llms.txt kurz in Googles eigener Entwickler-Dokumentation<\/a> auf und war am selben Tag wieder weg, allem Anschein nach ein automatischer Rollout des Redaktionssystems, keine Kurs\u00e4nderung. Wie es mit der Nutzung auf Anbieterseite wirklich steht, ist un\u00fcbersichtlich: formell als Standard zugesagt hat es keiner, Google lehnt ausdr\u00fccklich ab, OpenAI hat sich nicht festgelegt. Von einzelnen Anbietern hei\u00dft es, sie ber\u00fccksichtigten das Format in ihren Abl\u00e4ufen, aber diese Angaben stammen aus SEO-Quellen, nicht aus offiziellen Hersteller-Mitteilungen. Ich verkaufe das also nicht als Wundermittel. Es schadet nicht, es ist schnell gemacht, aber es ist eher eine H\u00f6flichkeitsgeste an Maschinen als ein Garant f\u00fcr irgendetwas.<\/p>\n\n\n\n

Anders sieht es bei der strukturierten Identit\u00e4t aus. Hier ist aus \u201eich habe da mal was erw\u00e4hnt“ etwas Substantielles geworden. Nicht weil ein Schema magisch wirkt, sondern weil mich der Prozess gezwungen hat, meine eigene Online-Existenz aufzur\u00e4umen, Widerspr\u00fcche zu beseitigen und nur noch Pr\u00fcfbares zu behaupten. Das w\u00e4re auch ohne jede Maschine eine gute \u00dcbung gewesen.<\/p>\n\n\n\n

Und meine selbstironische Prognose von damals, dass klassische Blogs seltener werden? Die stimmt und stimmt nicht. Dieser Blog schreibt weiter, sehr aktiv sogar. Aber die Verteilung verschiebt sich tats\u00e4chlich. Neue Beitr\u00e4ge gehen \u00fcber ActivityPub ins Fediverse und \u00fcber eine Br\u00fccke nach Bluesky, nicht mehr in erster Linie \u00fcber die Suchmaschine zum Leser. Insofern st\u00fctzt die Realit\u00e4t die Prognose, sie widerlegt nur das \u201eBlog ist tot“-Pathos. Es ist kein Sterben, es ist ein Umzug der Verteilwege.<\/p>\n\n\n\n

Hat die Maschinenlesbarkeit messbar etwas gebracht? Differenziert betrachtet ja und nein. Die KI-Crawler holen die strukturierten Daten nachweislich ab, das war meine Anfangsprognose und sie hat sich best\u00e4tigt. Aber Abruf ist nicht gleich Klick. Die Klick-Konversion aus diesen Kan\u00e4len ist niedrig. Das ist kein Widerspruch, das ist genau der Punkt des ganzen Themas, siehe Zero-Click weiter oben. Sichtbar zu sein und besucht zu werden sind zwei verschiedene Dinge geworden.<\/p>\n\n\n\n

Damit zum Kerngedanken, der f\u00fcr mich am Ende \u00fcbrig bleibt: Man kontrolliert nicht, ob eine KI einen zitiert. Man kontrolliert nur, ob man zitierbar ist. Das ist die ganze Aufgabe. Fehlende oder widerspr\u00fcchliche Daten machen ein Zitat fast unm\u00f6glich. Saubere, konsistente, belegbare Daten machen es wahrscheinlicher. Mehr Versprechen gibt es nicht, und jeder, der mehr verspricht, verkauft etwas. SEO ist dabei \u00fcbrigens nicht tot, das w\u00e4re \u00dcbertreibung. Technische Hygiene, Crawlbarkeit und gute Inhalte bleiben die Basis. Es verschieben sich nur die Gewichte.<\/p>\n\n\n\n

Vor einem halben Jahr habe ich geschrieben, ich sei gespannt, was passiert. Daran hat sich nichts ge\u00e4ndert. Ich wei\u00df heute ein paar Dinge genauer, ich habe meine eigene Anfangs-Euphorie an einigen Stellen kassiert, und ich habe vor allem gelernt, dass der ehrlichste Weg auch der robusteste ist. Ob das langfristig der richtige war, wei\u00df ich immer noch nicht. Ich bin weiterhin gespannt.<\/p>\n\n\n\n

Siehe auch:<\/strong> Von SEO zu AEO, warum llms.txt, JSON-LD und Answer Engines das Web ver\u00e4ndern<\/a> (der Vorg\u00e4ngerpost mit der urspr\u00fcnglichen Wette).<\/p>\n\n\n\n

Gegenmeinung, eigene Erfahrungen oder ein Befund, der meinem widerspricht? Immer her damit, einfach fragen<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"

Ein gutes halbes Jahr nach meinem Beitrag von SEO zu AEO der ehrliche Kassensturz: was sich gehalten hat, was naiv war und was eine maschinenlesbare, verifizierbare Identit\u00e4t wirklich bringt. Dazu Zahlen zu Zero-Click und KI-Antworten, jeweils mit Quelle und Grenze, und warum llms.txt kein Wundermittel ist.<\/p>\n","protected":false},"author":1,"featured_media":4803,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"activitypub_content_warning":"","activitypub_content_visibility":"","activitypub_max_image_attachments":4,"activitypub_interaction_policy_quote":"anyone","activitypub_status":"federated","footnotes":""},"categories":[13,276],"tags":[403,256,336,429,440,402,332,441],"class_list":["post-4801","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-kernel-error-blog","category-self-hosting-infrastruktur","tag-aeo","tag-ai","tag-ai-search","tag-fediverse","tag-knowledgegraph","tag-llm","tag-seo","tag-structureddata","post-preview"],"_links":{"self":[{"href":"https:\/\/www.kernel-error.de\/wp-json\/wp\/v2\/posts\/4801","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kernel-error.de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kernel-error.de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kernel-error.de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kernel-error.de\/wp-json\/wp\/v2\/comments?post=4801"}],"version-history":[{"count":1,"href":"https:\/\/www.kernel-error.de\/wp-json\/wp\/v2\/posts\/4801\/revisions"}],"predecessor-version":[{"id":4804,"href":"https:\/\/www.kernel-error.de\/wp-json\/wp\/v2\/posts\/4801\/revisions\/4804"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kernel-error.de\/wp-json\/wp\/v2\/media\/4803"}],"wp:attachment":[{"href":"https:\/\/www.kernel-error.de\/wp-json\/wp\/v2\/media?parent=4801"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kernel-error.de\/wp-json\/wp\/v2\/categories?post=4801"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kernel-error.de\/wp-json\/wp\/v2\/tags?post=4801"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}},{"id":4699,"date":"2026-06-08T18:54:23","date_gmt":"2026-06-08T16:54:23","guid":{"rendered":"https:\/\/www.kernel-error.de\/?p=4699"},"modified":"2026-06-08T18:54:23","modified_gmt":"2026-06-08T16:54:23","slug":"fr24feed-ntp-bug-1-0-57-fix-timesyncd","status":"publish","type":"post","link":"https:\/\/www.kernel-error.de\/2026\/06\/08\/fr24feed-ntp-bug-1-0-57-fix-timesyncd\/","title":{"rendered":"ADS-B-Feeder, Teil 2: der NTP-Bug in fr24feed ist in 1.0.57 gefixt, nur anders als gedacht"},"content":{"rendered":"

\n
\"Raspberry<\/figure>\n<\/div>\n\n\n

Im ersten Teil dieser kleinen ADS-B-Saga hatte ich am Ende eine Sache offen gelassen und sie sogar fett in die Was-noch-kommt-Liste geschrieben: MLAT aktivieren, sobald Flightradar24 den NTP-Bug fixt. Heute ist es soweit. Der Fix ist da, er kam mit Version 1.0.57, und er kam ganz anders als ich erwartet h\u00e4tte. Statt den kaputten NTP-Client zu reparieren, hat FR24 ihn einfach rausgeworfen.<\/p>\n\n\n\n

Wer den ersten Teil noch nicht kennt, holt das am besten kurz nach: Eigener ADS-B Feeder: Flugzeuge tracken mit Raspberry Pi, RTL-SDR und selbstgebauter Antenne<\/a>. Dort steht das komplette Setup, die selbstgebaute Antenne und eben die Geschichte mit dem NTP-Bug, der meinen Feeder \u00fcber Wochen am Online-Gehen gehindert hat. Den Bug selbst erkl\u00e4re ich hier nur noch in ein paar S\u00e4tzen, die lange Version steht dr\u00fcben.<\/p>\n\n\n\n

Worum es ging, ganz kurz<\/h3>\n\n\n\n

Seit Version 1.0.55 hatte der fr24feed<\/code>-Daemon einen internen NTP-Client, der schlicht nichts tat. Kein einziges Paket auf Port 123, also keine Zeitsynchronisation, und ohne synchronisierte Zeit l\u00e4sst FR24 den Feeder nicht online gehen. Man h\u00e4ngt in einer Endlosschleife aus Failed to synchronize<\/code> fest und kommt nie \u00fcber dieses Sync-Gate hinaus. Mein Workaround war die letzte funktionierende Version 1.0.54 mit apt-mark hold<\/code> festzunageln und auf einen Fix zu warten.<\/p>\n\n\n\n

Im M\u00e4rz hatte ich FR24 einen Bug-Report mit strace- und tcpdump-Belegen geschickt. Die Antwort von Muazzam aus dem Support: auf ihrer Seite nicht reproduzierbar, Verdacht auf eine Regression durchs Build-System und nicht durch eine \u00c4nderung am NTP-Client selbst. Ich blieb hartn\u00e4ckig, lieferte am 6. Juni eine syscall-genaue A\/B-Analyse nach, und am 8. Juni kam die erl\u00f6sende Mail (Ticket #741092): \u201eshould be fixed in v 57 which will be released later today“. War es dann auch, noch am selben Tag lag 1.0.57-1 im Repo.<\/p>\n\n\n\n

Warum ich nicht einfach apt upgrade tippe<\/h3>\n\n\n\n

fr24feed ist closed-source, propriet\u00e4r, kein GitHub, keine Quellen. Ich kann ein Release also nicht am Code beurteilen, sondern nur an seinem Verhalten. Und ein blindes Upgrade auf dem laufenden Produktiv-Feeder kam nicht in Frage. Wenn 1.0.57 genauso kaputt gewesen w\u00e4re wie 1.0.56, h\u00e4tte ich mir den Feeder zerschossen und m\u00fcsste erst wieder zur\u00fcckrollen, bevor \u00fcberhaupt wieder Daten fliessen.<\/p>\n\n\n\n

Die saubere Variante: das Binary aus dem .deb<\/code> extrahieren und als isolierte Wegwerf-Instanz gegen eine Wegwerf-Config unter strace laufen lassen. Eigener Fake-Key, ein toter Receiver-Port, der echte Feeder l\u00e4uft dabei unber\u00fchrt weiter. Erst wenn der Testlauf sauber durchkommt, fasse ich die Produktion an.<\/p>\n\n\n\n

Der Testaufbau, eine Wegwerf-Instanz unter strace<\/h3>\n\n\n\n

Die Test-Config ist bewusst minimal gehalten. Sie muss nur weit genug kommen, dass der Feeder die Zeitsynchronisation versucht, alles danach interessiert f\u00fcr diesen Test nicht:<\/p>\n\n\n\n

fr24key=0123456789abcdef\nreceiver=beast-tcp\nhost=127.0.0.1:39999    # absichtlich toter Port, fuer die NTP-Phase egal\nbs=no\nraw=no\nmlat=no\nlogmode=0<\/pre>\n\n\n\n
Dann sehen, ob der Pi die neue Version \u00fcberhaupt schon sieht, und das Paket herunterladen ohne es zu installieren:<\/p>\n\n\n\n
apt-cache policy fr24feed\n#   Installed: 1.0.54-0\n#   Candidate: 1.0.57-1\n#      1.0.57-1 500 https:\/\/repo-feed.flightradar24.com flightradar24\/raspberrypi-stable arm64\n\napt-get download fr24feed\ndpkg-deb -x fr24feed_1.0.57-1_arm64.deb extract57<\/pre>\n\n\n\n
Erst die Toolchain vergleichen<\/h3>\n\n\n\n
Bevor ich \u00fcberhaupt gestartet habe, ein kurzer Blick in die .comment<\/code>-Section der ELF-Binaries. Die verr\u00e4t, mit welchem Compiler gebaut wurde, und genau das war FR24s Verdacht:<\/p>\n\n\n\n
readelf -p .comment extract57\/usr\/bin\/fr24feed | grep -i gcc\n#   GCC: (Debian 14.2.0-19) 14.2.0                       1.0.57 (und 1.0.56)\nreadelf -p .comment \/usr\/bin\/fr24feed | grep -i gcc\n#   GCC: (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0           1.0.54 (funktioniert)<\/pre>\n\n\n\n
Das ist der interessante Punkt: 1.0.57 ist mit derselben GCC-14-Toolchain<\/strong> gebaut wie das kaputte 1.0.56. \u201eNeu kompiliert“ allein ist also noch kein Fix, sonst w\u00e4re 1.0.56 ja schon heil gewesen. Genau das machte den strace-Test erst spannend, denn ich konnte nicht aus der Versionsnummer ableiten, ob sich am Verhalten wirklich etwas ge\u00e4ndert hat. Der Sprung von GCC 11 auf 14 plus der Distro-Wechsel von Ubuntu 22.04 auf Debian ist gross. GCC 14 ist deutlich strenger bei Undefined Behaviour und uninitialisierten Daten, und ein latenter Bug im NTP-Transmit-Pfad konnte unter GCC 11 unsichtbar bleiben und unter GCC 14 dann brechen. FR24s Build-System-Theorie war im Nachhinein also gar nicht so abwegig.<\/p>\n\n\n\n
Der A\/B-Lauf<\/h3>\n\n\n\n
Beide Versionen, die neue 1.0.57 und die installierte 1.0.54 als Kontrolle, laufen durch denselben Harness, auf derselben Maschine, am selben Tag. Ich tracke nur die Netzwerk-Syscalls, das reicht um zu sehen ob da etwas auf Port 123 geht:<\/p>\n\n\n\n
timeout -s INT 125 strace -f -tt -e trace=%network -yy -o v57_today.strace extract57\/usr\/bin\/fr24feed --config-file=test.ini > v57_today.log 2>&1<\/pre>\n\n\n\n
Das Ergebnis, und es \u00fcberrascht<\/h3>\n\n\n\n
Mein Abnahmekriterium war simpel formuliert: sendto<\/code> auf Port 123 muss wieder feuern, dann ist der NTP-Client repariert. Das Ergebnis war eine kalte Dusche und gleichzeitig die ganze Pointe dieser Geschichte:<\/p>\n\n\n\n
<\/th>1.0.54 (Kontrolle)<\/th>1.0.56 (kaputt)<\/th>1.0.57-1 (neu)<\/th><\/tr><\/thead>
NTP sendto<\/code> auf Port 123<\/td>3x (eigener Client)<\/td>0x<\/td>0x, Client entfernt<\/td><\/tr>
Source-Address-Discovery<\/td>ja<\/td>ja<\/td>ja (Rest-Code)<\/td><\/tr>
Zeitsync-Log<\/td>offset +0.001 s<\/td>Failed to synchronize<\/td>confirmed with timesyncd<\/td><\/tr>
Failed-to-synchronize-Loop<\/td>nein<\/td>ja, endlos<\/td>nein<\/td><\/tr>
Kommt \u00fcber das Sync-Gate?<\/td>ja<\/td>nein<\/td>ja<\/td><\/tr>
Toolchain<\/td>GCC 11.4.0<\/td>GCC 14.2.0<\/td>GCC 14.2.0<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\u00dcber den gesamten 125-Sekunden-Lauf von 1.0.57 hinweg gab es kein einziges Paket<\/strong> auf Port 123. Null. Genau wie beim kaputten 1.0.56. Nach meinem urspr\u00fcnglichen Kriterium h\u00e4tte ich das Release durchfallen lassen m\u00fcssen. Und trotzdem war der Bug weg. Der entscheidende Hinweis steht eine Zeile vorher im Log:<\/p>\n\n\n\n
[time][i]Time synchronization confirmed with timesyncd\n[feed][i]Downloading configuration\n[main][i]Feed Network client started\n[feed][d]Fetching configuration\n[feed][e]Result: failure, message: Not found, check your key!<\/pre>\n\n\n\n
Der einzige Fehler im ganzen Testlauf ist \u201echeck your key!“, und der ist erwartet, weil meine Test-Config absichtlich den Fake-Key 0123\u2026<\/code> benutzt. Das heisst: der Feeder l\u00e4uft komplett durch bis zur Feed-Registrierung. Genau vor<\/strong> diesem Punkt hingen 1.0.55 und 1.0.56 endlos in ihrer Sync-Schleife fest. Bug also weg, nur eben nicht so, wie ich gedacht hatte.<\/p>\n\n\n\n
Zum Vergleich der Beweis aus dem 1.0.54-Kontrolllauf, wo der eigene NTP-Client noch feuert. Hier sieht man das sendto<\/code> auf Port 123 schwarz auf weiss:<\/p>\n\n\n\n
sendto(5<UDP:[25798]>, \"33...\", 48, 0,\n       {sa_family=AF_INET, sin_port=htons(123),\n        sin_addr=inet_addr(\"85.10.204.50\")}, 16) = 48\n[time][i]Time synchronized correctly, offset +0.001 seconds<\/pre>\n\n\n\n
Pragmatischer Workaround statt echtem Fix<\/h3>\n\n\n\n
Was FR24 gemacht hat, ist kein Reparieren des NTP-Clients, sondern ein Umgehen des Problems auf Architektur-Ebene. Der kaputte interne Client ist raus, \u00fcbrig geblieben ist nur noch etwas Rest-Code f\u00fcr die Source-Address-Discovery. Die eigentliche Zeitsynchronisation delegiert der Feeder jetzt an systemd-timesyncd<\/code>, also an den NTP-Dienst des Betriebssystems. Statt selbst Pakete auf Port 123 zu schicken, fragt er das OS einfach: ist deine Zeit synchron? Und wenn ja, geht es weiter.<\/p>\n\n\n\n
Ehrlich gesagt finde ich das eine vern\u00fcnftige Entscheidung. Ein eigener NTP-Client in einer Feeder-Software war ohnehin Reinventing the Wheel, das Betriebssystem kann das besser und macht es sowieso schon. Dass der eigentliche Bug damit nie wirklich gefunden wurde, ist aus Ingenieurssicht ein kleiner Wermutstropfen, aber f\u00fcr den Anwender z\u00e4hlt nur, dass der Feeder l\u00e4uft. Und das tut er.<\/p>\n\n\n\n
Das Upgrade mit Sicherheitsnetz<\/h3>\n\n\n\n
Erst nachdem der Testlauf sauber durch war, ging es an die Produktion. Vorher noch das alte Paket und die Config wegsichern, damit ein Rollback jederzeit ein Einzeiler bleibt:<\/p>\n\n\n\n
cp \/var\/cache\/apt\/archives\/fr24feed_1.0.54-0_arm64.deb \/tmp\/fr24test\/rollback\/\nsudo cp \/etc\/fr24feed.ini \/etc\/fr24feed.ini.bak-20260608-161113\n\nsudo apt-mark unhold fr24feed\nsudo apt-get install -y --only-upgrade fr24feed   # 1.0.54-0 auf 1.0.57-1\n\n# Stolperstein: das Paket STOPPT den Dienst beim Upgrade, startet ihn aber nicht neu\nsudo systemctl start fr24feed\n\n# Wieder pinnen, jetzt auf die verifiziert gute Version\nsudo apt-mark hold fr24feed<\/pre>\n\n\n\n
Der Stolperstein mit dem nicht neu gestarteten Dienst ist eine Kleinigkeit, kostet aber Nerven wenn man es nicht weiss und sich wundert warum der Feeder nach dem Upgrade tot ist. Ein systemctl start<\/code> sp\u00e4ter lief alles. Die Verifikation kam aus der monitor.json<\/code> und dem Journal:<\/p>\n\n\n\n
\"build_version\":\"1.0.57-1\"\n\"feed_status\":\"connected\"\n\"feed_num_ac_tracked\":\"92\"\n\n[time][i]Time synchronization confirmed with timesyncd\n[reader][i]Timestamp source changed from UNKNOWN to SYSTEM-VALIDATED\n[feed][n]connected via UDP (fd 6)\n[feed][n]working\n[feed][i]sent 46,0 AC<\/pre>\n\n\n\n
feed_status: connected<\/code> und 92 getrackte Flugzeuge. Nach Wochen auf der festgenagelten 1.0.54 ist der Feeder endlich wieder auf einer aktuellen Version und kommt sauber \u00fcber das Sync-Gate. Genau das wollte ich.<\/p>\n\n\n\n
Die Kehrseite, eine neue Abh\u00e4ngigkeit<\/h3>\n\n\n\n
Wer einen eigenen Feeder betreibt, sollte das hier auf dem Schirm haben: 1.0.57 spricht selbst kein NTP mehr, also braucht es jetzt einen laufenden NTP-Dienst im Betriebssystem<\/strong>. Auf dem Standard-Pi24-Image ist das systemd-timesyncd, und damit funktioniert es out of the box. Kurz pr\u00fcfen schadet trotzdem nicht:<\/p>\n\n\n\n
systemctl is-active systemd-timesyncd     # active\ntimedatectl show -p NTPSynchronized       # NTPSynchronized=yes<\/pre>\n\n\n\n
Wer timesyncd oder chrony bewusst deaktiviert hat, oder ein abgespecktes Image ganz ohne NTP-Daemon f\u00e4hrt, k\u00f6nnte mit 1.0.57 jetzt ein neues<\/strong> Sync-Problem bekommen. Das ist der Preis des pragmatischen Fixes: FR24 hat die Verantwortung f\u00fcrs Zeit-Setzen ans OS abgegeben, und damit muss das OS sie auch wahrnehmen.<\/p>\n\n\n\n
Bonus-Fund: 1.0.57 bringt native GPS-Unterst\u00fctzung<\/h3>\n\n\n\n
Beim St\u00f6bern im neuen Binary ist mir noch etwas aufgefallen, das f\u00fcr die MLAT-Frage aus Teil 1 hochinteressant ist: 1.0.57 bringt einen PositioningNmeaDecoder<\/code> und eine ganze Reihe neuer gps-<\/code>-Direktiven mit. Das k\u00f6nnte heissen, dass sich der VK-162 endlich f\u00fcr das MLAT-Timing nutzen l\u00e4sst, das ja bislang auf NOT-PERMITTED<\/code> stand.<\/p>\n\n\n\n
strings \/usr\/bin\/fr24feed | grep -oE 'gps-[a-z-]+' | sort -u\n#   gps-altitude gps-antenna-connected gps-base-timestamp gps-ip gps-latitude\n#   gps-longitude gps-mode gps-status gps-time ...\n\n# Welcher gps-mode-Wert ist gueltig? Durchprobiert:\n#   gps-mode=serial  -> [e]Unsupported gps-mode=serial!\n#   gps-mode=nmea    -> akzeptiert (einziger gueltiger Wert)<\/pre>\n\n\n\n
So weit, so vielversprechend. Mit gps-mode=nmea<\/code> plus mlat-without-gps=no<\/code> \u00f6ffnet das Binary dann aber \/dev\/ttyACM0<\/code> nicht<\/strong> selbst, sondern loggt nur stoisch:<\/p>\n\n\n\n
[main][i]Waiting for GPS time<\/pre>\n\n\n\n
An der Hardware liegt es nicht, die liefert nachweislich einen sauberen Fix mit 9 Satelliten, parallel mitgelesen:<\/p>\n\n\n\n
$GPGGA,161727.00,5034.69002,N,00656.93035,E,1,09,0.86,384.0,M,...   # Fix, 9 Sat, 384 m<\/pre>\n\n\n\n
Meine erste Vermutung war, dass 1.0.57 die NMEA-Daten gepusht erwartet, also \u00fcber die Beast- und Decoder-Strecke oder \u00fcber eine Netzwerkquelle per gps-ip<\/code> statt \u00fcber ein direktes Serial-Open des Dongles. Statt auf der Produktion herumzuraten habe ich FR24 aber lieber direkt gefragt, welche fr24feed.ini<\/code>-Schl\u00fcssel zu einem seriell angeschlossenen NMEA-GPS geh\u00f6ren, Device-Pfad, Baudrate und so weiter.<\/p>\n\n\n\n
Update vom 9. Juni 2026:<\/strong> Die Antwort von Muazzam aus dem Support (weiterhin Ticket #741092) kam am n\u00e4chsten Tag und war kurz, aber unmissverst\u00e4ndlich:<\/p>\n\n\n\n
\n
No, a local gps won’t help with mlat. For good mlat you need nano second timestamps that fpga provides. Also, we dont have an support for it.<\/p>\n<\/blockquote>\n\n\n\n
Damit ist die Frage abschliessend beantwortet, wenn auch anders als erhofft. Ein lokal angeschlossener Serial- oder NMEA-GPS ist f\u00fcr MLAT schlicht keine g\u00fcltige Timing-Quelle, und fr24feed unterst\u00fctzt diesen Fall auch gar nicht. Der Grund steckt in der Physik der Multilateration: MLAT rechnet Flugzeugpositionen aus den Laufzeitunterschieden desselben Signals an mehreren Empf\u00e4ngern aus. Damit das aufgeht, m\u00fcssen die Empf\u00e4nger ihre Empfangszeitpunkte im Nanosekunden-Bereich stempeln, und solche Zeitstempel liefert nur dedizierte FPGA-Hardware der Radarcape-Klasse. Ein NMEA-GPS \u00fcber USB-Serial hat dagegen Jitter im Millisekunden-Bereich, aus der USB-Latenz und dem Timing der NMEA-S\u00e4tze. Das sind gut sechs Gr\u00f6ssenordnungen daneben, und selbst mit einem sauberen PPS-Signal kommt man an die FPGA-Genauigkeit nicht heran.<\/p>\n\n\n\n
Das ordnet auch mein gps-mode=nmea<\/code>-Experiment von oben sauber ein. Die GPS-Direktiven in 1.0.57 dienen faktisch nur der Positionsangabe, nicht dem MLAT-Timing. Das beobachtete [main][i]Waiting for GPS time<\/code>, ohne dass der Feeder \/dev\/ttyACM0<\/code> \u00fcberhaupt \u00f6ffnet, war also kein Konfigurationsfehler meinerseits, sondern schlicht fehlender Support f\u00fcr genau diesen Anwendungsfall.<\/p>\n\n\n\n
F\u00fcr mich heisst das, der GPS-Dongle der seit M\u00e4rz f\u00fcr genau diesen Moment bereitliegt, bleibt vorerst in der Schublade. Etwas schade, aber die Begr\u00fcndung ist nachvollziehbar und technisch sauber. Und f\u00fcr alle mit dem gleichen Setup ist die Lehre eindeutig: mit einem reinen RTL-SDR plus USB-GPS l\u00e4sst sich MLAT bei FR24 nicht aktivieren, egal welche fr24feed.ini<\/code>-Verdrahtung man probiert. MLAT bleibt dauerhaft auf NOT-PERMITTED<\/code>. Wer MLAT wirklich will, kommt um Timing-Hardware mit FPGA nicht herum.<\/p>\n\n\n\n
Fazit, und die eigentliche Lehre<\/h3>\n\n\n\n
Die sch\u00f6nste Lektion steckt nicht in der Versionsnummer, sondern in meinem Abnahmekriterium. Ich war so auf den einen Syscall fixiert, dass ich beinahe das richtige Ergebnis als Fehlschlag abgehakt h\u00e4tte. sendto<\/code> auf Port 123 war nie das eigentliche Ziel, das war nur die zuf\u00e4llige Art, wie 1.0.54 die Zeit synchronisiert hat. Das richtige Erfolgskriterium war die ganze Zeit ein anderes: kommt der Feeder \u00fcber das Sync-Gate, ja oder nein. Ein bestimmter Syscall ist Mittel zum Zweck, nicht der Zweck selbst. Wer Verhalten testet statt Implementierung, l\u00e4uft seltener in so eine Falle.<\/p>\n\n\n\n
FR24 bekommt von mir Lob f\u00fcr die schnelle Reaktion am Ende und einen pragmatischen Fix, der das Problem zuverl\u00e4ssig erledigt. Ein kleiner Kritikpunkt bleibt, dass der eigentliche Bug nie gefunden wurde, sondern nur umgangen. Aber Hand aufs Herz: ein funktionierender Feeder ist mir lieber als ein vollst\u00e4ndig aufgekl\u00e4rter, der nicht l\u00e4uft. Mein Beitrag war am Ende vor allem die Reproduktion auf genau der arm64-Hardware, die FR24 im M\u00e4rz nicht zum Fehler bringen konnte. Dass der Fix jetzt auf eben dieser Maschine h\u00e4lt, habe ich dem Support noch einmal zur\u00fcckgemeldet, damit sie die Regression sauber abschliessen k\u00f6nnen. Manchmal ist der wertvollste Teil eines Bug-Reports, dass man hartn\u00e4ckig bleibt und sauber misst.<\/p>\n\n\n\n
Siehe auch:<\/strong><\/p>\n\n\n\n