RUDAK - the next generation

digitale Kommunikation auf P3-D

von Peter Gülzow, DB2OS

RUDAK-U Design Team


Inhalt


Hot News!

Phase-3D wird nun doch einen "echten" digitalen HighSpeed-Link bekommen. Die Weichen dazu wurden im September auf einem Meeting in Marburg getroffen, bei dem, neben dem unten genannten RUDAK-Team und Dr. Karl Meinzer (DJ4ZC), auch Matjaz Vidmar (YT3MV) anwesend war. Matjaz selbst betreibt in Slovenien einige Digipeater mit 1,2 Mbit/s Biphase-PSK im 13cm Band und konnte mit praktischen Hinweisen zur Diskussion beitragen. Er tritt insbesondere für eine einfache Modemtechnik ein. Als Ergebnis des Treffens wurde für AMSAT Phase-3D ein HighSpeed-Link mit 153,6 Kbit/s in Biphase-PSK beschlossen. Beide RUDAK-Computer werden jeweils ein solches 153,6 Kbit/s Modem verwenden, sodaß zwei HighSpeed Uplinks und Downlinks zur Verfügung stehen. Übrigens erfordert diese Modulationstechnik nicht viel mehr Aufwand bei der Sende/Empfangsanlage, als die 9600 Baud FSK-Modulation nach G3RUH!! Über die verwendete Modemtechnik und erforderlichen Bodenanlagen werden im AMSAT-DL Journal beschrieben. Durch diesen HighSpeed-Link werden sich auch neue Anwendungsmöglichkeiten für interkontinentale Satellitengateways und einen bodengestützte Fileserver ergeben.

Einleitung

Außer einigen Angaben im Bandplan und kurzen Andeutungen auf der AMSAT-DL Mitgliederversammlung, haben wir an dieser Stelle schon längere Zeit nichts mehr über den Fortgang der Arbeiten am RUDAK-Experiment für den neuen P3-D Satelliten berichtet. Dies wollen wir mit diesem Bericht nun nachholen. Wie sie lesen werden, hat sich einiges getan, aber durchaus nicht alles so wie ursprünglich von allen Beteiligten geplant bzw. erhofft.

Entscheidungen

Personelle und berufliche Belastungen einiger Mitarbeiter hatten leider auch Auswirkungen auf deren ehrenamtliche Mitarbeit bei diesem Projekt, so daß das gesamte Konzept für eine digitale Nutzlast auf AMSAT P3-D neu überdacht werden mußte. Dazu gehörte dann auch die schmerzliche Entscheidung des Projekt-Managments, das RUDAK-E Experiment gänzlich fallen lassen zu müssen. Mit dem noch verbliebenen Manpower war es nicht mehr möglich die gesteckten Ziele einer umfassenden digitalen Nutzlast für P3-D zu erreichen. Schon frühzeitig hatte man sich jedoch nach einer Alternative umgesehen und es war zunächst vorgesehen RUDAK in zwei Teile aufzusplitten. RUDAK-E sollte mehr den experimentellen Charakter widerspiegeln, hingegen sollte der sogenannte RUDAK-U Teil die Benutzerseite stärker berücksichtigen. Das 'U' steht hier also für die 'User' und 'E' stand für Experiment. Trotz aller Bemühungen, mußte RUDAK-E jedoch aufgegeben werden. Den noch verbliebenen Aktiven der ehemaligen RUDAK-Gruppe war es einfach zeitlich nicht mehr möglich den eigenen hohen Ansprüchen gerecht zu werden und schon zuviel Zeit war leider verstrichen. Aus Tradition und in Anerkennung der erbrachten Leistungen der AMSAT-DL RUDAK-Gruppe bei AO-13 und AO-21, wurde die Bezeichnung "RUDAK" (Regenerativer Umsetzer für Digitale Amateurfunk Kommunikation) beibehalten.

RUDAK-U

Die konzeptuelle Geburtsstunde von RUDAK-U war anläßlich eines Arbeitstreffens im Februar 1994 bei AMSAT-DL in Marburg. Lyle Johnson, WA7GXD hatte zugestimmt den Re-Design des Bordrechners (IHU) für P3-D zu übernehmen. Lyle und Peter Gülzow, DB2OS nutzten die Gelegenheit um weiter über verschiedene PACSAT-Amateurfunksatelliten und insbesondere AMRAD OSCAR-27 zu diskutieren, denn Lyle Johnson war hier für den Design der Bordrechner bzw. digitalen Nutzlast zuständig gewesen. Peter Gülzow unterbreitete schon früher den Vorschlag, daß ein vergleichbares System auf P3-D als benutzerorientiertes Datenkommunikationsexperiment sehr sinnvoll eingesetzt werden könnte. Dies würde die Möglichkeiten von RUDAK-E erheblich erweitern, welches eher einen reinen experimentellen Charakter hatte, z.B. für Experimente mit anderen Modulationsarten. Der P3-D Projektleiter, Dr. Karl Meinzer, DJ4ZC unterstützte diese Idee und nach einer ganzen Reihe von Diskussionen, wurde die RUDAK-U Nutzlast für P3-D manifestiert!! Unmittelbar nach seiner Rückkehr in Arizona, nahm Lyle Johnson (RUDAK-U Projektmanager) Kontakt mit Harold Price, NK6K, Jeff Ward, G0SUL und Chuck Green N0ADI auf, die einer Mithilfe am RUDAK-U Experiment sehr wohlwollend zustimmten. Neben dem Budget welches von AMSAT-NA und AMSAT-DL bereitgestellt wird, unterstützt auch die TAPR mit einem finanziellen Beitrag dieses Projekt.

Technik

Wie ja bekannt ist, fliegt P3-D in einer hohen elliptischen Umlaufbahn, so daß bei RUDAK-U besondere Maßnahmen hinsichtlich der Strahlung erforderlich sind, wie dies natürlich auch für die anderen Subsysteme in den P3-Satelliten gilt. Geeignete Bauteile mußten ausgewählt und, wo nötig, zusätzliche Abschirmungen angebracht werden. Die Strahlenbelastung in der P3-D Bahn ist mindestens 10 mal höher als bei den tieffliegenden PACSAT-Satelliten. Eine ganze Reihe von Rahmenbedingungen sind zu erfüllen, so muß z.B. alles in eine vorgeschriebene Modulbox mit 200 x 270mm Kantenlänge passen und auch die Stromaufnahme und die Masse sollte nicht zu hoch sein. Eine ganze Reihe von elektrischen und mechanischen Schnittstellen zum Satellitenbus mußten definiert und spezifiziert werden. Obwohl RUDAK-U weitgehend als autonome Nutzlast arbeiten soll, müssen bestimmte Steuermöglichkeiten über die IHU möglich sein und Sicherheitsmechanismen, wenn es zu einem internen Fehler im Modul kommen sollte (Kurzschluß, CPU-Watchdog, usw.). Weiterhin muß RUDAK-U die HF-Ressourcen im Satelliten nutzen können, wofür auf ZF-Pegel (10,7 Mhz) entsprechende Verbindungen zu den einzelnen Uplink-Empfängern und der Transponder-Matrix für die Bakensender geschaffen wurden. RUDAK-U erfüllt nicht nur einen Selbstzweck, sondern ist auch ein lebenswichtiger Bestandteil anderer Experimente, wie z.B. der GPS-, SCOPE-, CEDEX- und MONITOR-Nutzlasten. Aufgrund der anfallenden Datenmengen ist die IHU nicht in der Lage diese Experimente aktiv zu unterstützen. Oder stellen Sie sich vor, sie müßten ein Farbbild der SCOPE-Kamera mit 400 Bit/s herunterladen. Experimentatoren haben über RUDAK-U Zugriff auf Ihre Nutzlast und können neue Programme laden, Befehle ausführen lassen und die Ergebnisse anfordern. Ein lokales Netzwerk im Satelliten (CAN-Bus) sorgt bei einer maximalen Datenrate von 800 Kbit/s für den nötigen Datenaustausch zwischen RUDAK-U und den anderen Experimenten. Bei Bedarf können die Daten dann von RUDAK-U noch weiter aufbereitet und archiviert werden. Den Benutzern stehen die Daten über die Downlinkkanäle mit relativ hoher Datenrate zur Verfügung. Auf die technischen Details gehen wir später noch weiter ein.

Bodenanlagen

RUDAK-U muß nicht nur technisch kompatibel mit dem Satelliten-Bus (HF, Stromversorgung und Steuerung) sein, sondern auch zu den Bodenanlagen der künftigen Usern, die den Satelliten benutzen möchten.

Hier liegt zugleich das Problem. Nach fast 10 Jahren setzt sich der 9600 Baud FSK Standard nach G3RUH nun immer mehr durch und Hersteller bieten bereits Funkgeräte mit passenden Anschlüssen an. 1984 hatte Steve Goode, K9NG sein erstes einfaches 9600 Baud FSK Modem für Packet Radio vorgestellt. Im Gegensatz dazu hat sich z.B. das 56 Kbit/s Modem von WA4DSY aus verschiedenen Gründen nur wenig verbreitet, vermutlich weil vielen die nötigen RX/TX-Module wegen der erforderlichen Bandbreite und Frequenzen zu aufwendig erscheinen. Auch das von Karl Meinzer, DJ4ZC entwickelte RSM-Modem hat sich bisher leider nicht durchgesetzt. Obwohl die RSM-Technik idealen Wirkungsgrad bei minimaler Bandbreite bietet, findet sie bisher leider praktisch keine Beachtung. Durch das vorzeitige Ende von AO-21 konnten leider auch bisher keine praktischen Erfahrungen damit im Orbit gesammelt werden. 1200 Baud BPSK (auch als FUJI-Mode bekannt, da erstmals bei FUJI OSCAR-12 eingesetzt) hat sich unter den Satellitenbenutzern schon etwas mehr verbreitet, da diese Modemtechnik bei mehreren Satelliten (FO-12, AO-16, WO-18, LU-19, FO-20, AO-21, IO-26) zum Einsatz kam. Deutlich bevorzugt wird aber von den Usern die 9600 Baud FSK Technik (G3RUH-Modem), was sich auch zu deutlich am Betrieb über die einzelnen Satelliten bemerkbar macht. Während die PACSAT's UO-22, KO-23 und KO-25 unter den starken Benutzerzahlen ächzen, ist auf den 1200 Baud PSK-Satelliten teilweise nur wenig Betrieb. 1200 Baud AFSK (FM) Betrieb scheidet natürlich bei einem Satelliten in dieser Bahn wegen dem sehr schlechten Wirkungsgrand, dem erforderlichen Signal/Rausch-Abstand und der belegten Bandbreite vollkommen aus.

Für welche Modulationsart soll man sich unter diesen Bedingungen also entscheiden? Einerseits kommen nur leistungsmäßig effektive Modulationsarten in Frage, bei denen also genügend Reserve auf den Linkstrecken besteht und die Ressourcen im Satelliten nicht zu stark belastet werden. Auf der anderen Seite muß es etwas sein, was dem durchschnittlichen Benutzer noch in Reichweite erscheint.

RUDAK-U hat das Mandat mit der existierenden Welt kompatibel zu bleiben.

P3-D fliegt in einer hohen elliptischen Umlaufbahn, wobei der Satellit im Apogäum etwa maximal 43.000 km entfernt ist. Gegenüber den tieffliegenden LEO Satelliten mit einer durchschnittlichen Bahnhöhe von 800 bis 1300 km, bietet P3-D einige Vorteile. P3-D bewegt sich wesentlich langsamer am Beobachterhimmel und ist aufgrund seiner Bahn sehr viel länger hörbar. Hinzu kommt auch noch ein erheblich größerer Hörbarkeitsbereich. Da P3-D viel größer als die Mikrosatelliten ist und ihm aus den Solarzellen erheblich mehr elektrische Energie zur Verfügung stehen, haben die Transponder wesentlich mehr Ausgangsleistung für noch stärkere Downlinks und es können Antennen mit Gewinn verwendet werden.

Aufgrund der hohen Sendeleistung der verschiedenen Transponder im P3-D Satelliten, immerhin wurde teilweise von bis zu 250 Watt PEP Transpondern gesprochen, ist vielfach ein Eindruck entstanden, daß man auch für die digitalen Betriebsarten mit einem vergleichbarem geringen Aufwand auskommt. Leider belehrt uns die Physik aber eines anderen. Da P3-D erheblich weiter entfernt ist, als z.B. ein UO-23, ist die Streckendämpfung auch beträchtlich größer. Immerhin bedeutet eine 10-fache Entfernung, daß die Freiraumdämpfung unabhängig von der Frequenz um 20dB zunimmt! Einiges davon kann man am P3-D Satelliten durch mehr Antennengewinn und höhere Senderausgangsleistung wieder ausgleichen, aber es bleibt immer noch ein Minus übrig. Im Apogäum ist die maximale Distanz zu einem Beobachter knapp 49800 Km und bei einem Tiefflieger sind es zwischen 3500 und 4000 Km, je nach Höhe der Umlaufbahn. Dies entspricht etwa 22-23dB Unterschied im Extremfall, wobei sich die Links natürlich spürbar verbessern umso näher P3-D zur Erde kommt. Dieser Zahlen dürften auch jedem Laien klar machen, warum FM-Betrieb über P3-D nicht möglich sein wird. Wenn man also bei P3-D immer von einer deutlichen Verbesserung der Linkstrecken spricht, dann bezieht sich das selbstverständlich immer nur auf die Satelliten AO-10 (P3-B) und AO-13 (P3-C), nicht aber auf die bekannten 9600 Baud Satelliten UO-22, KO-23 und KO-25!! Viele Benutzer dieser Satelliten verwenden allerdings bereits nachführbare Antennen mit mehr als 10 dB Antennengewinn und 10 bis 100 Watt Sendeleistung, sogenannte Bodenanlagen der "OSCAR-10" Klasse. Für die LEO-Satelliten, die weniger als 2 Watt Sendeleistung und nur Rundstrahlantennen verwenden, ergibt dies eine sehr große Reserve bei den Linkstrecken. Bei P3-D schrumpft die Reserve im ungünstigsten Fall aber auf fast +/- 0 dB zusammen!!

So schön also die hohen Datenraten bei einfacher Modulationstechnik auch sind, so sieht aber die Realität oft leider ganz anders aus. Die Linkberechnungen zeigen, daß 9600 Baud FSK nach G3RUH auch für normale Benutzer noch praktikabel ist. Allerdings nur, wenn in etwa der gleiche Antennenaufwand wie er bisher bei AO-13 benötigt wurde, beibehalten wird. Bei 1200 Baud BPSK sieht die Situation schon besser aus, da PSK-Modulation schon mit geringeren S/N-Signalen auskommt.

Aus diesem Grunde kam man überein, daß RUDAK-U die Modulationsarten 1200 Baud BPSK und 9600 Baud FSK in der Grundversorgung unbedingt anbieten sollte. Auf diese Weise können die Benutzer sofort mit vorhandenen Anlagen über RUDAK-U Betrieb machen. Sie erkennen aber sofort auch die Kompromisse, die man dann in Sachen Geschwindigkeit, Sendeleistung und Aufwand der Empfangsanlage schließen muß. Ist der Einstieg erst einmal geschafft, läßt sich sicher auch ein Interesse für weitaus besser geeignete Modulationsarten wecken. Die Möglichkeiten der digitalen Signalverarbeitung (DSP) sollen RUDAK-U in die Lage versetzen sich dem aktuellen Stand und den künftigen Erfordernissen der HF- und Modulationstechnik flexibel anzupassen. Lediglich die 9600 Baud Modems werden aus Redundanz- und Sicherheitsgründen in normaler Hardware ausgeführt. Sie werden auch benötigt um nach dem Start die Betriebssoftware in den RUDAK-U Computer zu laden. Da die DSP-Modems auf 10,7 Mhz ZF-Ebene arbeiten, ist fast jede Modulation denkbar. Die erforderliche Software wird vom RUDAK-U Computer in die Modems geladen und kann bei Bedarf komplett gegen eine andere Modem-Software ausgetauscht werden. Da inzwischen auch immer mehr DSP-Modems für den Bodenbereich angeboten werden, lassen sich neue Modulationsarten und besser geeignete Übertragungsprotokolle auf beiden Seiten prinzipiell relativ schnell realisieren. "Es ist alles nur Software" ?

Nachdem die Frage nach den Modulationsarten und Linkstrecken geklärt ist ergibt sich sogleich die nächste Frage: Was wollen wir überhaupt an Serviceleistungen den künftigen Benutzern zur Verfügung stellen und welche Ressourcen gibt es dazu. Sind die Benutzer eher an einem Mailboxbetrieb, vergleichbar mit dem PACSAT-Protokoll interessiert oder wollen sie Digipeater-Betrieb machen? Entscheidend für diese Frage ist natürlich der enorm große Einzugsbereich von P3-D und die lange Hörbarkeit. Eine Mailbox mit der Speicherkapazität eines UO-22 wäre vermutlich innerhalb einer sehr kurzen Zeit abgefüllt [siehe PACSIM]. Es ist wie mit den Festplatten im Heimcomputer: "egal wie groß die Festplatte ist, sie ist immer zu klein wenn man sie braucht.." Andererseits arbeitet das PACSAT-Protokoll gerade bei einem Satelliten in der P3-Umlaufbahn sehr effizient. Es wäre auch eine ideale Möglichkeit für einen globalen S&F-Betrieb zu den Mailboxen. Eine weitere Aufgabe wäre die globale Echtzeitvernetzung von Packet Radio Netzen über Satellitengateways. Hierfür würden nur relativ wenig Speicherressourcen benötigt, jedoch sollten solche Experimente sinnvollerweise auch nur mit sehr hohen Datenraten und möglichst auf eigenen Uplink-/Downlink-Kanälen durchgeführt werden. Den Gateways dürfte es zumutbar sein, hier entsprechend höheren Aufwand gegenüber den normalen Benutzern zu betreiben.

Einer der Hauptfaktoren für einen Mailboxbetrieb ist der verfügbare RAM-Speicher. Derzeit sind etwa 16 bis 32 Mbyte RAMDISK vertretbar. In der Praxis wird dies bedeuten, daß lange Nachrichten oft nur eine relativ kurze Lebensdauer haben werden. Andererseits wird sich irgendwann ein Gleichgewicht einstellen, wenn die erste Euphorie bei den Benutzern verflogen ist und sich Normalbetrieb einstellen wird. Auf große .GIF Familienbilder müssen die User dann vielleicht verzichten. Eventuell wird man auch einfach die maximale Größe eines Files begrenzen. Ein Ausweg aus dieser Situation wäre die Verlagerung von langen Files auf einen externen Fileserver am Boden. Im Satelliten wird dann lediglich das Inhaltsverzeichnis der "Software-Bibliothek" bereitgehalten. Ein Benutzer würde nun eine Nachricht an den Satelliten bzw. den Server schicken, mit dem Namen des Files, daß er auslesen möchte. Der Server könnte dann bei nächster Gelegenheit dieses File für den User im Satelliten bereitstellen. Hier gibt es also noch viel Spielraum für neue Ideen, auch bei den Benutzern am Boden.

Zumindest die erforderlichen Software für das PACSAT Protokoll ist bereits schon jetzt vorhanden. Betriebssystem und PACSAT-Server (entwickelt von Harold Price NK6K und Jeff Ward, G0SUL) haben sich inzwischen seit mehreren Jahren auf den PACSAT-Satelliten bestens bewährt. Auch auf der Benutzerseite sind hier inzwischen äußerst komfortable Programme (z.B. WiSP für WIN3.11 und WIN95) verfügbar, die kaum noch Wünsche offen lassen. Gerade dies war ein wichtiger Aspekt für RUDAK-U. Was nutzen schöne Protokolle und eine Super-Hardware, wenn es an der erforderlichen Software bei den Usern fehlt..

Flight-Hardware

Bild 1: V53-Prozessor

Bild 1 zeigen das Blockschaltbild der RUDAK-U Flughardware. RUDAK-U besteht im Grunde sogar aus zwei kompletten unabhängigen Systemen. Im oberen Teil des Bildes ist ein Computer aus Basis der V53 CPU zu sehen, unten ein weiterer Computer mit einem 80C386EX als Herzstück. Die V53 CPU wurde bereits auf AO-27 erfolgreich im Orbit eingesetzt. Der Computer auf Basis 80C386 ist eine leistungsfähigere Neuentwicklung. Beide Computer arbeiten mit dem selben Betriebssystem und der selben operationellen Software, wodurch sich eine Redundanz bei Ausfall eines Rechners ergibt. Über ein schnelles FIFO-Puffer ist ein sehr schneller Datenaustausch zwischen beiden Computern möglich.

Beiden CPU's stehen jeweils 16 MegaByte EDAC RAM zur Verfügung, welche für die Betriebssoftware und als Fileserver genutzt werden. Die Software kann komplett vom Boden aus geladen und ausgetauscht werden. Jeder Prozessor bedient zwei 9600 Baud Hardware FSK Modems, 4 DSP-Modulatoren und 4 DSP-Demodulatoren. Insgesamt stehen also 12 Uplinks und 12 Downlinks zur Verfügung. Beide Computer teilen sich den Zugriff zu einem externen Highspeed-Modem (irgendwas zwischen 64 und 256 Kbit/s), welches aber nicht Bestandteil der RUDAK-Hardware ist. Beide Prozessoren haben über einen seriellen Port oder den CAN-Bus (oder beides gleichzeitig) Verbindungen zum GPS-Empfänger und zu den SCOPE-Kameras, sowie dem CEDEX-Strahlungsdetektor. Auf weitere Experimente besteht Zugriff über den CAN-Bus LAN mit einer Datenraten von maximal 800 Kbit/s. Auch der Bordrechner ist über den CAN-Bus erreichbar (siehe Bild 2). RUDAK-U "hört" zusätzlich auf der 400 Bit/s Engineering-Bake der IHU mit und kann z.B. die Telemetrie aufbereiten, archivieren und den Benutzern zur Verfügung stellen.

Bild 2: P3-D CAN Übersicht

Total Digital

P3-D fliegt eine ganze Flotte von DSP-Modems. Insgesamt kommen 16 DSP-Chips zum Einsatz. Da die Modems direkt auf 10,7 Mhz ZF-Ebene arbeiten, können sie praktisch an jeder beliebigen Stelle im Digitaltransponder-Durchlaßbereich erscheinen. Jeder DSP Modulator und Demodulator verwendet einen separaten ADSP-2171 Signalprozessor (siehe Bild 3). Dadurch sind die Modems in der Lage auch theoretisch sehr hohe Datenrate bis zu etwa 56 Kbit/s zu verarbeiten oder aber auch sehr stark kodierte, niedrige Datenraten. Jedem DSP stehen etwa 10 Kbyte internes RAM zur Verfügung. Da dieses RAM nicht gegen strahlungsbedingte Bitfehler geschützt ist, führen die DSP's regelmäßig einen Selbsttest durch und berechnen eine Prüfsumme über den internen Programmspeicher und teilen das Ergebnis dem RUDAK Hauptprozessor mit. Stimmt die Prüfsumme nicht oder ist die DSP-Software abgestürzt, dann wird der ADSP-2171 resetted und wieder automatisch neu mit Software geladen. Um sicher zu gehen, hat Paul Barrow, VE6ATS in Alberta/Canada für uns die DSP's des gleichen Typs einem Strahlungstest bei einer Krankenhauseinrichtung unterzogen. Mit 100 Krad Strahlungsdosis, haben die ADSP-2171 die Anforderungen für P3-D voll übertroffen, so daß die DSP-Modems auch im Orbit zuverlässig funktionieren sollten. Für die DSP-Demodulatoren werden sehr schnelle Video-Analog/Digitalwandler verwendet, die direkt vom ZF-Ausgang der Empfänger gespeist werden. Jeder Demodulator verwendet einen eigenen Harris, HSP50016 Digital Down Converter (DDC), der das digitalisierte 10,7 Mhz ZF-Signal auf das Basisband bzw. einen für die digitale Signalverarbeitung besser geeigneten Frequenzbereich umsetzt, wobei bereits das demodulierte I- und Q-Signal zur Verfügung steht. Über den programmierbaren Local-Oszillator des DDS-Bausteins kann die genaue Uplinkfrequenz beliebig im Durchlaßbereich programmiert werden. Vergleichbares gilt auch für die Downlink. Für den Modulator wird der AD7008 Direct Digital Synthesizer Baustein von Analog Devices verwendet, der ein sehr sauberes Sendesignal im 10,7 Mhz ZF-Bereich erzeugt, welches dann direkt in die Transponder-Matrix eingespeist wird. Auch hier kann man die genaue Downlinkfrequenz per Software programmieren. Die Modulation (Frequenz, Phase und Amplitude) erfolgt direkt per Software, bei extrem geringen Bauteileaufwand!!

Dank der DDS und DDC Bausteine ist jeder ADSP-2171 nicht nur auf eine einzige Uplink oder Downlinkfrequenz beschränkt, sondern er ist in der Lage gleichzeitig mehrere niedrige Bitratensignale zu bedienen. So wäre es denkbar, daß RUDAK-U mit nur 8 DSP-Demodulatoren gleichzeitig 16, 32 oder sogar 48 niedrig-ratige Uplinks oder Downlinks zur Verfügung stellen kann!! Denkbar wäre z.B. ein satellitengestützer weltweiter PAGER-Betrieb mit nur 50 Bit/s Datenrate und einem kleinen Gerät auf dem Fensterbrett. Hier dürfte allerdings noch einiger Programmieraufwand von Nöten sein.

Bild 3: DSP-Modem

Ausblick

Wenn alles planmäßig klappt, dann wird RUDAK-U auf P3-D wieder deutliche Akzente setzen. P3-D ist nicht der erste Amateurfunksatellit mit einem DSP-Prozessor an Bord, aber es gab vor ihm keinen Satelliten mit soviel geballter Rechenleistung. Hätten Sie gedacht, daß in P3-D mindesten 25 Prozessoren (davon 16 DSP's) zum Einsatz kommen? Dank seiner ZF DSP-Modems steht RUDAK-U schon jetzt an der Spitze der derzeitigen Entwicklung auf diesem Gebiet. Die Möglichkeiten dieser Technik sind enorm, andererseits stellt sie uns auch immer wieder vor neue Aufgaben. Ist die Entwicklung entsprechender Modem-Software mit den derzeitig verfügbaren Kapazitäten auf dem Amateurfunksektor überhaupt noch möglich? Bei der Entwicklung neuer Modem-Software und Protokolle gibt es viel zutun, aber hoffentlich auch viel Spaß dabei..

Derzeit befindet sich RUDAK-U noch voll in der Bauphase und manche technischen Details können sich bis zum Start von P3-D durchaus noch ändern. Zu gegebener Zeit werden wir hier über den aktuellen Stand der Flughardware und die Erprobungsphase berichten. Mitglieder im Raume Hannover werden eventuell schon vor dem Start von P3-D die Möglichkeit haben am Testbetrieb über ein RUDAK-U Ingenieursmodell teilzuhaben. Insgesamt werden mehrere Ingenieursmodelle gebaut, die den beteiligten Entwicklern für Hardware- und Softwareentwicklung zur Verfügung stehen.

Anhang:

PACSIM-Tabelle

Die folgende Tabelle ist das Ergebnis einer Simulation von Bob Diersing, N5AHD. Es wurden alle Satellitenüberflüge für das QTH von N5AHD (27.48N 97.24W) am 30. Januar 1994 berücksichtigt. P3-D wurde natürlich mit einer etwa 14-stündigen Hörbarkeit angenommen, während bei UO-22 und AO-16 etwa 6 Überflüge verzeichnet wurden. Die Zahlen repräsentieren dabei den Datendurchsatz, den N5AHD beobachten würde. Bei früheren Simulationen hat sich eine sehr gute Übereinstimmung mit der Praxis ergeben. Auch wenn die Simulation tatsächlich nur diesen einen Tag berücksichtigt und eher in eine grobe Richtung weist, so haben die Zahlen trotzdem schon eine recht große Aussagekraft über die bei P3-D zu erwartenden Datenmengen. Für P3-D wurde hier 9600 Baud Betrieb angenommen, im Vergleich zu UO-22 mit ebenfalls 9600 Baud und zu AO-16 mit 1200 Baud.

-----------------------------------------------------------------------

P-3D UO-22 AO-16

9600 BPS 9600 BPS 1200 BPS

Frames Transmitted: 164,064 : 12,637 : 2,945

Bytes Transmitted: 43,894,257 : 3,001,546 : 565,720

PBP Transaction Count: 2,667 : 253 : 128

PBP Directory Frames: 42,196 : 3,758 : 1,026

PBP Directory Bytes: 11,139,744 : 992,112 : 270,864

PBP File/Fill Frames: 84,807 : 6,281 : 515

PBP File/Fill Bytes: 22,389,048 : 1,658,184 : 135,960

FTL0 Transaction Count: 779 : 63 : 42

FTL0 Frames: 31,787 : 2,538 : 1,344

FTL0 Bytes: 9,951,456 : 346,540 : 154,186

-----------------------------------------------------------------

DL_Data_Rate: 9,600 : 9,600 : 1,200

Time_Step_Sec: 0.1 : 0.1 : 0.1

QST_Info_Size: 244 : 244 : 244

QST_Time_Slice: 10 : 10 : 10

QST_AR_Mean_D: 8.3 : 8.3 : 30

QST_AR_Std_Dev_D: N/A : N/A : N/A

QST_AR_Type_D: Exp : Exp : Exp

QST_AR_Mean_F: 6.2 : 6.2 : 30

QST_AR_Std_Dev_F: N/A : N/A : N/A

QST_AR_Type_F: Exp : Exp : Exp

QST_ST_Mean_D: 199.4 : 199.4 : 180

QST_ST_Std_Dev_D: 182.9 : 182.9 : 100

QST_ST_Type_D: Norm : Norm : Norm

QST_ST_Mean_F: 78.4 : 78.4 : 180

QST_ST_Std_Dev_F: 122.6 : 122.6 : 100

QST_SR_Type_F: Norm : Norm : Norm

QST_BC_Mean_D: 10,200 : 10,200 : 7,500

QST_BC_Std_Dev_D: 16,400 : 16,400 : 5,000

QST_BC_Type_D: Norm : Norm : Norm

QST_BC_Mean_F: 30,000 : 30,000 : 5,000

QST_BC_Std_Dev_F: 30,000 : 30,000 : 10,000

QST_BC_Type_F: Norm : Norm : Norm

Max_FTL0_Frame_Size: 275 : 275 : 275

FTL0_SCAR_Mean: 54 : 54 : 120

FTL0_UCAR_Mean: 54 : 54 : 120

FTL0_ST_Mean: 59 : 59 : 180

FTL0_BC_Mean: 5,000 : 5,000 : 5,000

FTL0_RT_Mean: 1.8 : 1.8 : 4.0

FTL0_RT_Std_Dev: 1.5 : 1.5 : 4.0


Diese Seite wurde am 16.10.1995 von DB2OS erstellt und am 4.8.1996 modifiziert.


ÜbersichtP3-D Übersicht