Ein von Eltern gebautes Radar für ein Kleinkind, das Flugzeuge liebt

 (jacobbartlett.substack.com)
2 Punkte von GN⁺ 2023-11-28 | 1 Kommentare | Auf WhatsApp teilen
  • Nachdem seine zweijährige Tochter Flugzeuge ins Herz geschlossen hatte, baute er an ein paar Abenden als Side Project die iOS-App Aviator, die umliegende Flugzeuge wie ein Radar auf dem Handy anzeigt
  • FlightRadar24 zeigt Flugzeugpositionen auf einer Karte, aber in welche Richtung man am echten Himmel schauen muss und welche Flugzeuge für ein Kind leicht zu entdecken sind, musste man selbst beurteilen
  • Die App kombiniert Richtungsdaten aus Core Location, die nicht-kommerzielle REST API von OpenSky Network, MapKit-Anmerkungen und eine SwiftUI-Oberfläche, um Flugzeuge passend zur Geräteausrichtung darzustellen
  • Nach MVP-Tests, bei denen App-Anzeige und echte Flugzeuge übereinstimmten, kamen ausgeblendete Karte, Vergrößerung niedrig fliegender Flugzeuge, Radaranimation, CRT-Effekt, Sound/Haptik und Farbeinstellungen hinzu
  • Die fertige App wurde im App Store veröffentlicht; als spätere Verbesserungen bleiben Zoom-Stufe, die erweiterte OpenSky-API, Anzeige von Abflug-/Ankunftsland, bessere Metal-Shader, Distanz-/Höhenfilter und ein „zany mode“

Vom Flugzeugbeobachten zu App-Anforderungen

  • Die Tochter freute sich vor einer dreistündigen Auslandsreise im Sommer auf das Fliegen und war nach einem Blick ins Cockpit auf Hinweis der Crew nach dem Boarding noch begeisterter von Flugzeugen
  • Danach bat sie oft darum, Flugzeuge am Himmel zu finden, und es kam sogar vor, dass er sie eine Stunde lang auf den Schultern im Garten trug, um Abendflugzeuge zu suchen
  • FlightRadar24 zeigte zwar Flugzeugpositionen auf der Karte, aber in welche Richtung man am echten Himmel schauen musste, musste der Nutzer selbst herausfinden
  • Auf einer 2D-Karte können ein Learjet in 40.000 Fuß und ein gerade vom London City Airport gestarteter AirBus ähnlich wirken, aber am echten Himmel ist ein großes Flugzeug in geringer Höhe viel leichter zu finden
  • Was ein zweijähriges Kind brauchte, war keine Karteninterpretation, sondern einfaches Flugzeugefinden
  • Das ursprüngliche Problem ließ sich in drei Punkte gliedern
    • Ausrichtung: Die Flugzeugpositionen müssen je nach Geräteausrichtung zur tatsächlichen Richtung am Himmel passen
    • Größendarstellung: Die Größe auf dem Bildschirm muss sich mit der Flughöhe ändern
    • Benutzbarkeit: Es sollte keine Business-Flugtracking-App sein, sondern eher wie ein Retro-Spielzeug wirken

Das ursprüngliche Design von Aviator

  • Die App-Idee war, „nahegelegene Flüge auf einem Radar anzuzeigen“, und der Projektname wurde auf Aviator festgelegt
  • Es gab drei zentrale Anforderungen
    • Wenn sich das Gerät dreht, muss sich auch der Bildschirm mitdrehen, damit Flugzeuge in der richtigen Richtung erscheinen
    • Je nach Flughöhe muss sich die angezeigte Größe des Flugzeugs ändern
    • Die App soll ein spaßiges Retro-Spielzeuggefühl vermitteln, das für Kinder gut geeignet ist
  • Für die Richtungsbehandlung wurden Heading-Updates der iOS-Core Location API verwendet
    • In didUpdateHeading von CLLocationManagerDelegate wird die Geräteausrichtung übernommen
    • Mit CurrentValueSubject aus Combine wird der Richtungswert an SwiftUI-Views weitergegeben
  • Für Flugdaten wurde OpenSky Network genutzt
    • Eine einfache REST API liefert Echtzeit-Flugdaten für einen bestimmten Breiten-/Längengradbereich
    • Nicht-kommerzielle Nutzung ist kostenlos
    • Für einen realistischen Radar-Sweep war geplant, den Endpoint alle paar Sekunden aufzurufen
  • Standortdaten kommen aus Core Location; abgefragt wird ein Breiten-/Längengradbereich rund um den Nutzerstandort
    • In der frühen Idee sollten Breite ±1 Grad und eine Positionsgenauigkeit von 0,1 Grad den Nutzerstandort auf ungefähr 10 km ausreichend verschleiern
    • Im tatsächlichen API-Beispielcode wurde ein Bereich von 0,5 Grad Breite und 1 Grad Länge verwendet, damit es in britischen Breitengraden ungefähr quadratisch wird
  • Da die OpenSky Network API auf nicht-kommerzielle Nutzung beschränkt ist und die App ebenfalls kein kommerzieller Dienst ist, wurde in SwiftUI eine einfache MV-Struktur verwendet und nur Kerndienste wie API und Location getrennt

PoC: Richtung, Flugdaten und Kartenvalidierung

  • Der Richtungs-PoC nutzt ein LocationManager-Singleton, das Standortberechtigung anfragt, den Delegate setzt und Heading-Updates startet
  • Die SwiftUI-View abonniert per .onReceive das rotationAngleSubject und erzeugt einen kompassartigen Rotationseffekt, indem Rechtecke kreisförmig angeordnet werden
  • Auf dem Testgerät reagierte das gut auf echte Richtungsänderungen, aber weil 0 Grad und 360 Grad in der Animation als verschiedene Werte behandelt wurden, entstand beim Passieren von Norden ein visueller Glitch, bei dem sich die Rechtecke einmal komplett drehten
  • Die OpenSky-REST-API gibt mit einer GET-Anfrage über einen Breiten-/Längengradbereich ein Array regionaler Flüge zurück
    • Beim Beispiel-Endpoint werden an states/all die Parameter lamin, lamax, lomin, lomax angehängt
    • Die REST-API-Dokumentation ist gut, aber die Antwort hat keine Keys, daher mussten JSON-Felder der Reihe nach geparst werden
    • Mit Swifts UnkeyedContainer werden icao24, callsign, origin_country, time_position, last_contact, longitude, latitude usw. dekodiert
  • Der erste Versuch, Flugzeuge zu zeichnen, platzierte ein SF-Symbol-airplane auf Basis der Breiten-/Längengrad-Differenz zwischen Nutzer und Flugzeug multipliziert mit einem festen Bildschirmmaßstab
    • Die reale Distanz von 1 Grad Breite oder Länge variiert je nach Standort und kann daher nicht exakt sein
    • Als Ausgangspunkt war es trotzdem nützlich
  • Zur Genauigkeitsprüfung wurde eine SwiftUI-Map in den Hintergrund gelegt und Flugzeuge sowie Kompass darübergelegt
    • Im Vergleich zur FlightRadar-Projektion passten Anzahl und Cluster der Flugzeuge ungefähr, die Positionen wichen aber deutlich ab
    • Danach wurde auf direkt auf der Karte gezeichnete Flugzeug-Annotationen umgestellt

MVP: MapKit-Annotationen und Nutzertests

  • Mit iOS 17 als Ziel wurden die Karten-Annotationsfunktionen von MapKit genutzt, um flugzeugförmige Marker an echten geografischen Koordinaten zu platzieren
  • FlightMapView zeichnet Flugzeug-Annotationen über Map(position:) und deaktiviert mit .allowsHitTesting(false) die Karteninteraktion passend zum Radar-Zweck
  • Die höhenbasierte Skalierung nutzte anfangs eine Log-Skala, damit hoch fliegende Flugzeuge größer erscheinen
    • true_track des Flugzeugs und die Nutzerausrichtung aus Core Location werden kombiniert, um die Richtung des Flugzeug-Icons auszurichten
  • Beim ersten MVP-Nutzertest wurden mit der Tochter tatsächlich Flugzeuge gefunden, und es wurde bestätigt, dass die in der App angezeigten Flugzeuge auch am echten Himmel sichtbar waren
  • Nach dem Test zeigten sich zwei nötige Änderungen
    • Die Skalierung war umgekehrt: Wenn man Flugzeuge zeigen will, die am Himmel mit dem Auge leicht zu finden sind, müssen niedrig fliegende Flugzeuge größer sein
    • Die Tochter wollte keine Karte, sondern nur Flugzeuge, daher musste zur Reduktion von Ablenkung die Karte entfernt werden
  • Die angepasste Skalierungsformel lautet min(2, max(4.7 - log10(flight.geo_altitude + 1), 0.7))
    • Beim lokalen Scannen des Himmels ergaben sich Werte von 0,7 bis 2,0, was auf dem Bildschirm gut verteilt wirkte

Die Radar-Oberfläche bauen

  • Die OpenSky-API lieferte häufig Timeouts, 502 Bad Gateway und auch 200-Antworten mit null-Daten
    • Da es sich um eine kostenlose nicht-kommerzielle API ohne SLA handelt, wurde clientseitig eine grundlegende Retry-Logik ergänzt
    • Am nächsten Tag funktionierte alles den ganzen Tag gut, und außer zu bestimmten Hochlastzeiten wirkte es insgesamt brauchbar
  • Um die echte Karte unsichtbar zu machen, wurde ein MapPolygon-Overlay verwendet
    • Ursprünglich ist es ein Overlay zum Hervorheben von Kartenbereichen, hier wurde es aber genutzt, um die Karte zu verdecken und nur die Flugzeug-Annotationen sichtbar zu lassen
    • Apples Overlay wird über der Karte und unter den Annotationen gezeichnet, was genau zum gewünschten Ergebnis führte
  • Der Radarbildschirm wurde mit Linien, konzentrischen Kreisen und einem rotierenden Angular Gradient mit 20 Grad Breite umgesetzt
  • Später wurde der Radarlinieneffekt auf einen 360-Grad-Angular-Gradient vereinfacht
    • Ein Gradient von Grün über transparent zu Schwarz wird rotiert, sodass er wie Sweep und Nachleuchten wirkt
    • Der „grug-brained“-Ansatz wurde als in vielen Fällen besser passend bewertet
  • Beim schnellen Drehen des Geräts gab es visuelle Artefakte, bei denen Kartenstücke an den Bildschirmecken sichtbar wurden; gelöst wurde das mit einer Reverse Mask, die den Bereich außerhalb der Radaransicht schwarz überdeckt

Produktreif machen: CRT-Effekt, Ton, Einstellungen, App Store

  • Für das Retro-Spielzeuggefühl wurde ein CRT-Bildschirmeffekt hinzugefügt
    • Verwendet wurde die eingebaute Metal-Shader-Unterstützung von colorEffect in iOS 17
    • Der Shader wendet Scanline-Werte auf Pixel an, die nicht schwarz sind
    • Mit einem time-Parameter bewegen sich die Scanlines schnell nach oben und erzeugen ein dynamisches Gefühl
  • Um zu klären, ob eine App-Store-Veröffentlichung laut OpenSky-Network-Richtlinien in Ordnung ist, wurde nachgefragt, und innerhalb von 20 Minuten kam eine Antwort
  • Für Radar-Erlebnis und Barrierefreiheit wurden bei Flug-Updates Systemton und Haptik ergänzt
    • AudioServicesPlaySystemSound(1052) erzeugt einen Beep-Boop-Sound
    • Verwendet wird sensoryFeedback(.levelChange, trigger:) von SwiftUI
  • Da der Ton störend sein kann, wurden auf @AppStorage basierende Einstellungen ergänzt
    • silent: Lautlosmodus
    • showMap: Deaktiviert das Radar-Overlay und zeigt die darunterliegende Karte
    • userColor: Wählt per SwiftUI Color Picker die Radarfarbe aus
  • Da das Midjourney-Abo beendet war, wurde mit dem kostenlosen nicht-kommerziellen Generator von Gencraft ein Aviator-Maskottchen im Stil einer Tochter mit Fliegermütze erstellt
  • Mit der erneuten Anmeldung beim Apple Developer Program wurden £79 bezahlt und die App-Store-Veröffentlichung vorbereitet
    • Zielplattform ist nur iOS 17, aber es mussten trotzdem iPhone-Screenshots für 6,5 Zoll und 5,5 Zoll eingereicht werden
    • Da das neueste 5,5-Zoll-iPhone, das iPhone 8 Plus, maximal iOS 16 unterstützt, wurden mit AppScreens Screenshots in beiden Größen exportiert
  • Die App ist nun im App Store verfügbar; der Download-Link ist Aviator — Radar on your Phone

Kandidaten für die nächste Version

  • Er war mit dem Ergebnis des Side Projects, das an ein paar Abenden entstand, zufrieden, und die Erfahrung, für seine Tochter ein Spielzeug zu programmieren, machte ihm seit Langem am meisten Spaß
  • Kandidaten für die nächste Release sind folgende Funktionen
    • Eine Karten-Zoom-Stufe hinzufügen, um das Radar auf nähere Flugzeuge zu begrenzen
    • Mit der erweiterten OpenSky Network API Helikopter, Satelliten und Flugzeuggrößenklassen anzeigen
    • Einen Schalter hinzufügen, um bei Flugzeugen Abflug- und Ankunftsland anzuzeigen
    • Den CRT-Bildschirmeffekt mit fortgeschritteneren Metal-Shadern verbessern
    • Die Bedienelemente zu einem größenveränderbaren Progressive-Disclosure-Pull-out-Modal refaktorieren
    • Distanz- und Höhenfilter per Slider implementieren, um etwa niedrige und weit entfernte Flugzeuge auszublenden
    • Einen zany mode umsetzen, der UFOs, riesige Insekten und Außerirdische auf dem Radar rendert

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-11-28
Hacker-News-Kommentare

  • Tolle Arbeit und auch gut geschrieben. Interessant ist, wie stark das Design der ursprünglichen Radaranzeige dieses Projekt prägt.
    Das Kind wird vielleicht nie ein ASR-9 mit PPI-Anzeige anfassen, geschweige denn eine echte CRT, aber es wurde ziemlich viel Aufwand betrieben, um genau das zu simulieren.
    Das liegt wohl auch an der Liebe zum Skeuomorphismus, aber vermutlich auch daran, dass der ursprüngliche Radarschirm die Frage „Ist da etwas am Himmel, und wo befindet es sich relativ zu mir?“ hervorragend komprimiert beantwortet.
    Heutige UIs zur Himmelsbeobachtung scheinen sich eher in Richtung Kontextinformationen, Links zu externen Diensten und Werbeflächen zu bewegen und dabei die Fähigkeit zu verlieren, diese Frage einfach zu beantworten.

    • Mir gefällt, dass der RADAR-Schirm zwar ein Produkt der Technik war, die ihn hervorgebracht hat, nämlich des Sweeps, zugleich aber auch eine bewusste Darstellung, die das Beobachtungsobjekt klar zeigen sollte.
      Die Entfernung des Ziels wurde als Abstand vom Zentrum dargestellt, die Peilung als Winkel am Kreisumfang.
      Der nachgeahmte Sweep könnte allerdings eine fragwürdige Designentscheidung gewesen sein; die kräftigen Farben und der kartenlose Hintergrund wirken dagegen völlig unproblematisch, weil sie den Fokus auf die Absicht des Displays lenken.
      Man sah auch, dass die Kompassverfolgung beim Drehen mit dem Telefon die Illusion des Sweeps bricht.
    • Nicht alle UIs zur Himmelsbeobachtung sind in diese Richtung gegangen. SkyMap ist ebenfalls sehenswert.
      https://github.com/sky-map-team/stardroid
    • Ein Dienst, der „Ist da etwas am Himmel, und wo befindet es sich relativ zu mir?“ immer noch gut einfängt, ist der AR-Modus von FlightRadar24.
      Ich verstehe die entsprechenden technischen Bausteine alle und betreibe auch selbst eine ADSB-Station, aber es ist immer noch erstaunlich, wenn man die Kamera auf den Himmel richtet und Metadaten zu den Flugzeugen im Sichtfeld sieht.
    • Ich glaube, der Ausgangspunkt war so schön, weil er so unverfälscht war. Es begann mit „In welche Richtung muss ich schauen, um ein Flugzeug zu finden?“ und wurde von dort aus aufgebaut.

  • Großartig. Kommt auf meine Liste der Dinge, die ich irgendwann bauen will.
    Ähnlich habe ich für meinen fünfjährigen Sohn ein Flug-Logbuch angelegt, angefangen hat das schon, als er ein Baby war. Bei jedem Flug lasse ich ihn die Crew fragen, ob der Kapitän etwas hineinschreiben kann.
    Darin stehen Route, Flugzeugtyp und was passiert ist, und die Crews lieben so etwas wirklich. Wir haben auch das Cockpit und die Crew-Ruheräume gesehen, und die eingetragenen Nachrichten waren immer herzlich.
    Jedes Mal, wenn er es zurückbekommt, strahlt er übers ganze Gesicht; für kleine Flugzeug-Nerds sehr zu empfehlen.

    • Mein Vater hat ein Logbuch für mich angefangen, als ich ein Kleinkind war, und ich aktualisiere es auch jetzt mit über 30 noch weiter. Es enthält jeden Flug, den ich je genommen habe, und ist wirklich eine großartige Idee.
    • Noch eine Stimme fürs Logbuch. Als meine Tochter etwa acht Wochen alt war, sind wir London–New York geflogen, und es gibt sogar ein tolles Foto von ihr im Cockpit mit Kapitänsmütze.
    • Genial. Selbst als erwachsener Mensch war eine Einladung ins Cockpit unglaublich cool, also werde ich beim nächsten Flug unbedingt damit anfangen.

  • Mir gefällt, dass Ändern der Anzeigefarbe als Pflichtfunktion im ersten Release dabei war. Das zeigt ein sehr solides Verständnis für die Bedürfnisse der Zielgruppe.
    Auch Dreijährige lieben jedes Spielzeug mit Farbauswahl.

    • Selbst ich als erwachsener Mann freue mich, wenn ein Color Picker dabei ist.
      Man stelle sich einfach die irrationale Aufregung vor, als ich auf HN über 250 Karma gekommen bin.
    • Eine der am meisten unterschätzten Komponenten in SwiftUI.
      Auch wenn man es Kindern heute zeigt, ist das Erste, worauf sie achten, die Farbauswahl, und sie ist außerdem gut für die Feinmotorik.

  • Die Stelle „Wir haben Flugreisen so hochgejubelt, dass das Kind überrascht war, dass man mit dem Taxi zum Flughafen fahren muss. Es dachte, man könne direkt von zu Hause zum Flugzeug laufen und einsteigen“ ist wirklich liebenswert, lustig und zugleich nachvollziehbar.

  • Bei der Stelle, dass die Crew einem niedlichen kleinen Flugzeug-Nerd gerne das Cockpit zeigt: passende orange NASA-Jumpsuits sind der Reisepass in jedes Cockpit.
    Die Crews sind noch begeisterter als die Kinder, und am Flughafen findet man das Kind auch sehr leicht wieder.

    • Genial. Dann müssen meine Frau oder ich also nur noch bei der NASA anfangen. Ob im All wohl viele iOS-Entwickler gebraucht werden?

  • Ebenfalls dazu passend ist der Artikel An app can be a home cooked meal, in dem die gescheiterte Social-Network-App Tapstack nur für die Familie nachgebaut wurde.
    https://www.robinsloan.com/notes/home-cooked-app/

    • Ein lovely Artikel, habe ihn gebookmarkt. Ich stimme zu, dass der Prozess an sich wahrscheinlich lohnend gewesen wäre, selbst bei 0 Downloads.
      Natürlich wäre es auch nicht schlecht, viral zu gehen.

  • Zwei kleine Kritikpunkte habe ich.
    Wenn sich die Flugzeugpunkte nach dem Zeichnen weiterbewegen, bricht die Immersion ein wenig. Es würde realistischer wirken, wenn die Punkte durch den Sweep „eingefärbt“ würden und bis zum nächsten Sweep fixiert blieben.
    Für noch mehr Realismus könnte man außerdem anhand früherer Datenpunkte extrapolieren, sodass sich jedes Flugzeug von Sweep zu Sweep konsistent bewegt.

    • Beides sind berechtigte Punkte. Mit gut abgestimmtem Timing und Winkel scheint der erste Punkt durchaus machbar.
      Der zweite könnte sogar einfacher sein. Da die API die Fluggeschwindigkeit zurückgibt, lässt es sich schon mit einem einzigen Datenpunkt berechnen.

  • Eine schöne Aktivität mit der Tochter: zu einer Straße, einem Parkplatz oder einem Park am Anflugende der Landebahn des nächstgelegenen internationalen Flughafens fahren.
    Das hängt meist von der Windrichtung ab, also entsprechend planen, das Auto abstellen und zusehen, wie die Flugzeuge hereinkommen und landen.
    Das Kind kann auf seinem Radar sehen, welches Flugzeug kommt; wir haben flightradar24 benutzt.
    Die Kinder waren völlig gebannt, als sie sahen, wie nah große Jets im Anflug dem Boden kommen, und man kann sich damit leicht stundenlang beschäftigen. Wir mussten verhandeln, weil sie nicht wegwollten und sehen wollten, ob das nächste Flugzeug größer oder näher ist.

    • Für den Autor wäre vermutlich der London City Airport (LCY) der passende Ort; dort ist der Anflugwinkel sehr steil.
      Dort dürfen nur mehrmotorige Starrflügler bis einschließlich der Größe eines Airbus A318 betrieben werden, die samt Crews speziell dafür zertifiziert sind, einen 5,5°-Anflug durchzuführen.
      https://www.youtube.com/watch?v=yZIDFgpT0-o
      https://en.wikipedia.org/wiki/London_City_Airport
    • In der Nähe von D.C. ist Gravely Point genau so ein Ort. Ob Start oder Landung: Es fühlt sich an, als könnte man die Nieten am Flugzeug zählen.
    • Ohrstöpsel mitzunehmen ist eine gute Idee.
    • In der Highschool gab es direkt außerhalb des Flughafenzauns am Ende der Landebahn eine geschotterte Freifläche. Wenn die Windrichtung passte und die Flugzeuge über diese Fläche starteten, war das ein guter Ort, um mit dem Auto anzuhalten und ein Date zu haben.
    • Nicht ganz dasselbe wie der Vorschlag, aber am SFO gibt es vor der Sicherheitskontrolle eine Sky Terrace, von der aus man Flugzeuge beobachten kann.

  • Diese App hat ein Problem. Auf der App-Seite steht eindeutig ab 4 Jahren, aber die Zielnutzerin ist 2.
    Gut gemacht.

    • Hoffentlich bleibt sie unter dem Radar der App-Store-Polizei.

  • Großartig.
    Eine kleine Detailfrage: Hatten CRT-Radarschirme tatsächlich eine Abtastlinie? Ich hätte gedacht, dass es Vektordisplays waren.
    Was die Liste zusätzlicher Features angeht: Da es eine App zum Flugzeugbeobachten ist, wäre es cool, wenn beim Antippen eines Punkts für ein paar Sekunden der Flugzeugtyp angezeigt würde.

    • Stimmt. Klassische Radarschirme waren im Grunde wie Oszilloskope, bei denen die X/Y-Position durch den Radarwinkel und die aktuelle Entfernung der Radarreflexion gesteuert wurde. Im Prinzip ein Polarkoordinaten-Plot.
      Durch das Nachleuchten des Phosphors blieben starke Radarreflexionen kurz auf dem Bildschirm sichtbar. Wenn sich das Radar in dieser Zeit mehr als einmal drehte, erschien dasselbe Flugzeug als neuer, leicht verschobener Punkt, also als „plot“.
      Man konnte die plots auf dem Bildschirm auch mit einem Filzstift markieren und daraus einen „track“ machen.
      Es gab auch spezielle Anzeigen, bei denen eine Filmkamera auf den Radarschirm gerichtet war, um Radarreflexionen über mehrere Stunden aufzuzeichnen und später wiederzugeben.
      Ein Beispiel ist eine beschleunigte Wiedergabe von Flugzeugen des Warschauer Pakts während der tschechoslowakischen Revolution 1968: https://youtu.be/rAUodXI4LPw?t=622
    • Es waren Vektordisplays, aber vermutlich etwas anders, als du es dir vorstellst.
      Die ursprünglichen Radarschirme tasteten vom Zentrum aus radial nach außen ab. Das Timing des Scans war so vorgegeben, dass die Entfernung skaliert wurde, und das Signal für die Strahlintensität war direkt das verstärkte Radar-Echosignal.
      Deshalb erschienen stärkere Echos als besser sichtbare „blips“ auf einem Bildschirm mit langer Nachleuchtdauer.
      Interessant ist, dass die gesamte Kathodenstrahlröhren-Emitterbaugruppe von einem Motor angetrieben wurde, der mit der rotierenden Radarschüssel synchronisiert war, damit der Radarstrahl über den CRT-Schirm scannte.
      Diese Rotation musste immer zur Geschwindigkeit und Richtung der Radarschüssel passen, sonst erschienen die blips an der falschen Stelle.
      Feste Radial- und Entfernungslinien waren auf die CRT-Röhre selbst oder auf eine transparente Abdeckung gedruckt. Solche Anzeigen wurden jahrzehntelang verwendet, vermutlich sogar bis in die 1980er- oder frühen 1990er-Jahre.
      Neuere Versionen konnten die X/Y-Richtungen mit einfacher Elektronik unabhängig abtasten, um die komplizierte rotierende Strahlerzeugerbaugruppe zu vermeiden.
      Mehr dazu: https://en.wikipedia.org/wiki/Radar_display#Plan_position_in...
    • Um das, was andere Antworten angesprochen haben, noch etwas zu erweitern: Der Strahl tastet tatsächlich radial vom Zentrum nach außen ab.
      Der Winkel kann erzeugt werden, indem man die Ablenkplatten physisch dreht oder indem man sin/cos elektronisch berechnet und auf die X/Y-Ablenkplatten anlegt.
      Die Amplitude des Rücksignals treibt direkt den Strahlstrom, daher erscheinen Ziele mit stärkerem Echo heller.
      Dazu kommt ein Speicherröhren-Effekt, der nicht wie der bistabile Modus der Speicherröhren-X-Y-Vektordisplays früher Computer funktioniert, sondern eher wie der variable Nachleuchtmodus mancher Oszilloskope.
      Diese Eigenschaft hatte auch Folgen im Zusammenhang mit frühen Versuchen, Stealth-Flugzeuge wie die SR-71 oder XB-70 zu entwickeln.
      Bei Radarröhren ist der Strahlstrom so eingestellt, dass sich „blips“ über mehrere Sweeps hinweg aufbauen; normalerweise bewegt sich ein blip zwischen den Sweeps weniger als um seinen eigenen Durchmesser.
      Wenn die Radar Cross Section eines Flugzeugs jedoch von Natur aus klein ist und es so schnell ist, dass der blip zwischen den Sweeps eine größere Strecke zurücklegt, können Radarbediener die kleinen Geister-blips als Rauschen interpretieren, besonders in hektischen Situationen mit vielen Zielen.