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..
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.
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.
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.
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
