Home Site Map Sonstige Aufsätze Weblog und Gequassel counter

Web Log Teil 432: 11.7.2015 - 14.7.2015

11.7.2015: Die wiederverwendbare Rakete

Tr(e)ue Blockleser wissen ja, ich halte nicht viel von wiederverwendbaren Raketen. Bisher gab es ja auch nicht viele Erfolge mit dem Konzept. es wurde zahlreiche Male theoretisch untersucht so wollte mal die S-I Stufe der Saturn V verwenden. Dei ESA untersuchte das für die erste Stufe der Ariane 1 und den Triebwerksblock der Ariane 4. (Erfolgreich) eingesetzt wurde es nur bei den Shuttle Solid-Rocket Boostern. Die Ariane 5 Booster wurden eine Zeitlang auch geborgen aber nur zu Inspektionszwecken. SpaceX Versuche die erste Stufe bergen scheiteten bei zwei Konzepten - dem reinen ballistischen Bergen bei der Falcon 1 und zwei Falcon 9 Flügen und dem gesteuerten Flug bei den folgenden Falcon 9 Flügen. Dabei weiß man wenn es gelingt immer noch nicht ob es wirklich wirtschaftlich ist. Beim Space Shuttle hat sich das wiederverwendbare Raumfahrtgefährt als nicht wirtschaftlich herausgestellt.

Doch ich muss eingestehen ich habe mich geirrt: Es gibt ein wiederverwendbares Raketensystem. Es ist wirtschaftlich, es hat eine hohe Nutzlast, niedrige Transportkosten und ist umweltverträglich

Das folgende System hat einige Vorteile gegenüber anderen Konzepten der wiederverwendbare Rakete, die man wie folgt zusammenfassen kann:

Nun werdet ihr euch fragen, was das für eine Rakete ist und wie ich darauf komme? Nun ich kannte diese Rakete bisher auch nicht, obwohl ich seit Jahren in Besitz dieser Rakete war! Alles fing damit an, dass ich das schöne Wetter nutzen wollte mal einiges zu streichen und ich dachte mir, unser alter Handkarren/Leitrwagen den wir haben, seit ich denken kann, also bestimmt seit 40 eher noch mehr Jahren, könnte auch mal einen Neuanstrich vertragen. Als ich da erstmals die Vorder- und Hinterplatte der Plattform sah, die sonst immer vom Überbau verdeckt wird, entdeckte ich dieses Schild:

Rakete Leiterwagen

Das ist doch mal eine Rakete oder? Und sie ist wiederverwendbar, preiswert, hat eine hohe Nutzlast und verwendet nur ökologische Treibstoffe. (sie nutzt sogar nur nachwachsenden Treibstoff und braucht keine Erdölprodukte). Sie ist sogar noch gut für die Gesundheit. Eine Internetrecherche ergab, das diese wohl in den fünfziger Jahren gefertigt wurden was auch dazu passt, dass wir danach ein Auto hatten und man damit vielleicht bequemer, aber sicher nicht umweltfreundlicher etwas transportieren kann. Ich fürchte nur es ist die einzige so umweltfreundliche Rakete. Da die Höchstgeschwindigkeit auf etwa 10 km/h beschränkt ist und sie nur innerhalb der Erdatmosphäre arbeiten kann, ist sie leider keine Alternative für den Satellitentransport.

Immerhin fanden ähnliche energiesparende Konzepte schon in der Raumfahrt Anwendung. So setzten die Missionen Apollo 13 und 14 ähnliche Transportvehikel ein.

2.6.2015: Nochmal 5 Tage durch die Crossplattform-Entwicklungshölle

Ich hatte ja schon mal einen Teil 1 verfasst. der sich mit meinem Projekt einer Wetterstation beschäftigt. wer es noch nicht getan hat, dem rate ich diesen Teil zuerst zu lesen. Teil 2 knüpft nämlich daran an.

Ich habe mir das Ziel gesetzt eine eigene Wetterstation zu betreiben die automatisch eine Webseite aktualisiert und die Meßwerte dort laufend publiziert. Die Meßwetgeber stammen von Tinkerforge. Dazu gibt es auch einen separaten Testbericht. Die Steuerung erledigt ein Raspberry Pi. Er generiert auch die Bilder und die Webseite und lädt sie auf meinen Server hoch.

Stand Ende letzter Woche war, das die Anwendung im Prinzip lief, es aber noch einige Bugs auszuräumen gab und ich konkrete Pläne zur Verbesserung und Weiterentwicklung hatte. Auch war noch nicht geklärt ob ich die Charts selbst zeichne oder nicht eine Komponente nehme die Lazarus mitbringt.

Inzwischen hatte ich auch die Entwicklungskette im Griff: Die Entwicklung erfolgt zuerst auf einem Windows PC. Ohne Meßwertgeber geht dort die Hauptschleife mit einem Einlesen über einen Timer nicht, aber die war eigentlich auch erprobt und lief. Das Auswerten der Daten die auch auf die Disk geschrieben werden geht aber auch vom Windows PC aus. Danach wird das Programm von einem Raspberry PI 2 Model B übersetzt. Erst danach auf einen Raspberry Pi Model B+ (also mit nur einem CPU-Kern) überspielt. Das hat seinen Grund: Der Raspberry Pi 1 war nicht über Remote Desktop erreichbar, nur über Putty. Der Compiler läuft aber auf der grafischen Oberfläche. Zudem ist das Kompilieren auf dem Rechner mit nur 600 MHz und einem Kern ein echtes Geduldsspiel.

Tag 1

Das erste was ich erreichen wollte war, das die Versionen von Lazarus auf dem Windows PC und dem Raspberry Pi 2 die gleichen sind. Ich hatte es zwar fertig gebracht dort die Version 1.5 von Lazarus zu installieren (eigentlich eine Entwicklungsversion), aber der ignorierte einige wichtige Tasten wie []{} komplett. Ich suchte nach einer Alternative und schließlich fand ich eine Webseite, die die Kompilierung unter Windows von Lazarus 1.4 beschreibt. In einem mutigen Schritt ersetzte ich einfach die Anweisungen für die 1.5 Installation durch die dortigen und siehe da - es funktionierte. Wichtig war nur nun noch alle Pfade anzupassen die bisher auf die völlig veraltete Lazarus 0.93 Version zeigten. Auf dem Raspi 1 änderte ich nichts. Er hat viel weniger Rechenpower und RAM (schon beim Raspi 2 muss man die Swapdatei vergröbern)., Dort ließ ich den 0.93 Compiler. Das ist der einzige den man über die offizielle Pakte Verwaltung installiert bekommt. (Warum eine so veraltete Version?)

Der Sinn ist der: es gab schon in der letzten Version Probleme wenn ich das Projekt auf dem ARM lud. Eigenschaften bei Buttons waren der alten Version des dortigen Compilers unbekannt und eine Formatierung der X-Achse als Zeit wird in Version 0.93 und 1.4 völlig unterschiedlich geregelt und ergibt immer Fehler in einem der beiden Compiler. Es sollte also nur eine Version genutzt werden. Beim Raspi 2 lief nun auch die Version 1.4

Tag 2

Ich versuchte nochmal den Ansatz mit den mitgelieferten Charts. Sie sehen etwas besser aus als meine Grafiken. Nach Anpassung lief das Programm dann auch mehrere Stunden auf dem Raspi 2. Ich transferierte es auf den Raspi 1 und dort lief es über Nacht - alles kann doch so schön sein, dachte ich mir noch. endlich auf dem richtigen Weg, nun wird es sicher besser. Ich sah positiv in die Zukunft - bis morgen natürlich mein guter alter Bekannter Murphy an die Tür klopfte ...

Tag 3

Damit ich auch eine Kontrolle habe, ob die Internetseite aktuell ist und somit ob nicht der Raspi abgestürzt ist, baute ich noch das Parsen der HTML-Vorlage von einigen Variablen ein, die dann folgende Tabelle ergeben:

Gemessen am 10:49:16
Letzte gemessene Temperatur: 24,9 Grad Celsius
Letzte gemessene Objekt-Temperatur: 23,2 Grad Celsius
Letzte gemessene Luftfeuchtigkeit: 36,3 Prozent relativ
Letzter gemessener Druck: 1017,5 hPa
Letze gemessene Helligkeit (Sensor misst nur maximal bis 900 Lux) 829,3 Lux

Während das Programm auf dem Raspi 2 problemlos lief, stürzte das kompilierte Programm auf dem Raspberry 1 sofort ab. Es erscheint nicht mal die Benutzeroberfläche. Wenn man es mit dem 0.93 Compiler übersetzt läuft es, stürzt aber beim Starten der Messung ab. Man erhält nur die Meldung dass der Debugger auch abgestürzt ist - auch ein Grund warum ich die 1.4 Version haben wolle. Wie ich noch von der Lehre an der DHBW weiß ist der Debugger bei den alten Versionen von Lazarus absturzgefährdet. So war der Fehler nicht einzukreisen. Auch Reboot half nichts. Ich nahm den Raspi 1 außer Betrieb und setzte den Raspi 2 ein. Der darf nun auch einen neuen Sensor unterstützen, der die Objekttemperatur misst. Auch der Raspi 2 macht ab und an Probleme. So beschwert er sich nach einem Reboot das er die Mrrko-SD-Karte nicht findet. Rausziehen und erneut reinstecken löst das Problem, nur warum bei einem Reboot wenn er vorher stundenlang lief? Ich verstehe bis heute nicht warum man bei der Pi-Foundation nicht die SD-Karten beibehalten konnte. Die sind nicht so fummelig, robuster und man bekommt sie auch leichter in den Steckplatz rein. Leider haben nun auch die neuen Raspberry B Modelle nur einen Mikro-SD Slot. Dafür aber auch vier USB-Ports wie der große Bruder.

Tag 4

Ein blick auf die Webseite am Morgen zeigt das der Raspi knapp 2 Stunden arbeitete und dann um halb vier nichts mehr ausgibt. Er reagiert auch nicht mehr auf Remote Desktop und Tastaturereignisse. Irgendwo ist noch ein Fehler in der Meßwerterfassung. Ich fasse mehr Routinen in Try -Except Blöcke, merke mir den Indes beim Start von Ausgaberoutinen (die Meßwerterfassung läuft über einen Timer weiter) und mache Ausgaben auf der Oberfläche. Es zeigt sich das die ARM Plattform anders reagiert als Windows. So gibt es einen Runtime Fehler 216 bei der Zeile:

MittlereHelligkeit := Gesamt / (Index+1)

zuerst denke ich an eine Division durch 0, aber das kann nicht sein, denn es wird ja 1 addiert. Der Fehler kommt dann auch vor bei einem Index von 9456. Noch rätselhafter ist die Nummer des Fehlers eigentlich für eine mathematisch nicht definierte Operation wie eine Wurzel aus einer negativen Zahl steht. Wenn man den Variablentyp durch eine double ersetzt, funktioniert die Zeile. Es gibt also keine implizite Umwandlung von Integer in Float wie bei Windows Version von Lazarus. Weitere Tests laufen über Stundenm melden dann aber einen Speicherzugriff auf der Oberfläche, während die Anwendung noch weiter läuft. So am Morgen des 5-ten Tages ein Fehler um 3:21, doch die Erfassung und Ausgabe läuft noch bis 6:52. Dann steigt der Raspi 2 aus. Alles sehr rätselhaft.

Wenn es einen Fehler gibt dann scheitert auch das folgende Kompilieren an internen Fehlern von Lazarus. da hilft nur eines, wie Paso Double schon 1985 in "Computerliebe" dichtete "Schalt mich ein und schalt mich aus, die Gefühle müssen raus" oder auf neudeutsch: "Wenn nichts mehr tut hilft nur Reboot". Danach klappt's auch mit dem Compiler. Aus demselben Lied: "Erste Regel für den Notfall am Computer: Null Emotionen" ist auch ganz nützlich.

Von den Charts habe ich mich wieder verabschiedet, weil sie durch die bis zu 3600 Meßwerte pro Tag "zittrig" aussehen. Ich schreibe meine Grafikroutinen so um dass sie maximal 800 anzeigen, darüber Mittelwerte bilden und in jedem Falle noch ein 48-werte Mittel anzeigen. Die Skala passe ich dynamisch an, sodass sie X-Achse entweder bis morgens um 6, 12 18 oder 24 Uhr geht je nach Tageszeit. Nun sehen die Grafiken recht gut aus.

Tag 5

Einer der Fehler ist offensichtlich die Kommunikation mit den Bricklets. Die bricht öfters mit einem Kommunikationsfehler ab, wie ich nun bemerke. Die Unit hat einen Timeout von 2,5 s. Doch mein Timer holt jede Sekunde einen Wert ab. Das könnte eine Fehlerursache ab. Ich schalte den Timer zu Beginn der Meßwerterfassung ab und danach erst wieder ein. Erneut tritt ein neuer Fehler auf: diesmal wenn der Arrayzugriff auf ein nicht existentes Element zugreift - der Index wird offensichtlich nicht immer um Mitternacht auf 0 zurückgesetzt was auch die Fehler in den frühen Morgenstunden erklären kann. Wieder zeigt sich das der ARM Compiler irgendwie anders funktioniert, denn er bemängelt den Fehler in einer komplett anderen Zeile, die eine Datei lädt.

Ich baue nun in alle Routinen Ausgaben in eine Logdatei ein, nachdem ich schon seit Tag 4 die Objekttemperatur erfasst habe, die der neue Sensor als Zusatzmöglichkeit bietet taucht sie nun auch in den Ausgaben auf. Ein Versuch auch den Raspi 1 mit dem neuen Compiler zu beglücken scheitert. Immerhin gelingt mit einem neuen VNC.-Server eine Remote-Desktopverbindung. Die Verbindung zu dem Raspi 1 bleibt aber instabil und reist auch bei Putty immer wieder ab. Das ist kein Wlan-Pproblem sondern tritt auch auf wenn man ihn über Powerline anschließt. Zur Sicherheit, falls ich doch mal die Anwendung nicht unter der grafischen Oberfläche laufen lassen kann ersetze ich die TBitmaps durch BGRABitmaps die nicht auf der LCL beruhen. Damit könnte ich die Anwendung als Cronjob starten und zur Sicherung gegenüber Abstürze den Rechner ebenfalls über Cronjob regelmäßig neu booten. Das gilt zu diesem Zeitpunkt als letzter Backupplan.

Tag 6

Morgens der Blick auf die Webseite zeigt - der Raspi läuft noch. Ein Kontakt über remote Desktop geht ebenfalls. ein Blick ins Log zeigt nur Infomeldungen - na also es geht doch. Jetzt noch einige kleine Änderungen so führe ich auch mal die Chiptemperatur des Barometers mit, um zu sehen welchen Fehler das hat (angeblich sehr viel ungenauer als selbst der billigste Temperatursensor der nur auf 0,5 Grad genau ist) und das neue Programm um 12 Uhr überspielt. Immerhin ist der Raspi 2 nun über 18 Stunden am Stückl gelaufen und das neue startet wie die letzten Versuche auch ohne Fehler. Eigentlich müsste nach zwei tTgen ohne Probleme nun wieder ein Fehler kommen.

Soweit der Stand vom Samstag. Wie geht es weiter? Langfristig will ich den Raspi 1 wieder mit der Aufgabe betrauen. Ich brauche ihn sonst für nichts mehr.  Derzeit ersetzt er meinen Raspi 2 als Mediencenter (Openelec). Überlegenswert wäre auch die Messwerterfassung auf Callbacks umzustellen. Das wird in der Dokumentation als die bessere Möglichkeit für zyklische Abfragen beschrieben. Ich hielt das nicht für nötig, weil in Beispielen so was erschien wie der Anstieg des Lichtsensors, wenn man ihn mit einer Taschenlampe überstreift - dazu muss man im Millisekundenintervall messen und da sollte meine Messung einmal pro Sekunde wohl nicht zu viel sein. Aber nach den Kommunikationsproblemen denke ich wäre das eine Alternative. Leider melden sich Callbacks nur bei veränderten Werten nicht nach einer bestimmten Zeit. So müsste ich pro Meßgröße (derzeit 5) eine eigene Zeitbasis einführen, während ich bisher eine Zeitbasis für alle Meßwerte habe.

Auch die Indexeite bedarf noch etwas Aufhübschung. Danach wäre das Projekt auf der Raspiplattform abgeschlossen, dann ginge es an das Auswertuen unter Windoes über Tage hinweg.

Resümee

Es geht, aber es war nicht wenig Arbeit. Allerdings gehöre ich zu den Leuten die Gene Kranz Einstellung teilen: "Failure Is Not an Option ".  Aufhören kam also nie in Frage. Wenn jemand anders das angehen will, dann würde ich ihm aber ein paar Tipps geben die ich gezogen habe:

Kein Kit kaufen sondern Basisbrick, Feuchtigkeits-, Ir-Temperatur und Drucksensor. Das Gehäuse ist Schrott und nicht dicht, der Lichtsensor ist schon mit Schatten übersteuert und das LCD-Display braucht man für eine Station für draußen nicht.

Überlegen was als Rechner eingesetzt wird. Tinkerforge bietet einen ähnlichen Kleinstrechner den "Red Brick" an. Diesem soll man einfach Programme zum ausführen übergeben können. Allerdings denke ich klappt das gut nur bei Skriptsprachen oder Bytecode (Java, .net). Den Ansatz für kompilierte Sprachen wie C oder Delphi den Windows x86 Code crosszucompilieren halte ich für sehr fehlerträchtig und langsam, läuft schließlich auf eine Emulation heraus. ARM Programme sind übrigens signifikant (etwa um ein Drittel bis zur Hälfte) länger als x86 Programme.

Wenn man sich nicht damit auseinandersetzen will kann man einen ausgedienten PC nehmen oder einen der sowieso dauernd an ist (viele haben ja inzwischen eigene Mediaserver oder NAS daheim, der kann dann auch noch die Wetterstation betreuen. Da hat dann aber ein Problem mit der Witterung. Wenn man genügend Geld hat, kann man auch Intel NUC nehmen. Der kleinste Intel DN2820FYKH NUC-Kit (Intel Celeron Prozessor N2820) kostet knapp 149 Euro ohne Platte und Speicher. Mit 4 GB (für Windows) und einer 2,5 Zoll Platte ist man dann bei etwa 250 Euro. Das ist verglichen mit einem Raspberry, einer SD-Karte und einem Netzteil zwar etwa 190 Euro teurer aber man kann die Programm 1:1 von einem Desktop übernehmen. Wenn er sowieso ins Netz eingebunden ist (muss er ja wegen dem zyklischen Aktualisieren der Webseite) kann man ihn auch noch für andere Dinge nutzen. Nur muss man dann den Ruhezustand deaktivieren. Der Komfort hat einen Preis, jeder muss entscheiden wie viel ihm seine Arbeitszeit selbst wert ist.

Lazarus hat mich unter Windows überzeugt. Das Projekt hat sich in den letzten Jahren deutlich weiterentwickelt und holt gegenüber Delphi deutlich auf. Einige Sachen sind sogar besser gelöst, so wird der Suchpfad angepasst wenn man eine Datei aus einem Verzeichnis aufnimmt - so brauche ich von den Bibliotheken von Tinkerforge mehr als eine Datei. Vor allem kann man mit dem Packlage anchordockingdsn endlich das angenehme Verhalten von angedockten nicht wirr herumliegenden Fenstern einstellen.

Ich habe mal auf dem Pi 2 das Lazarusverzeichnis gezippt und hoffe das so auf dem Pi 1 doch noch installieren zu können. Wenn das klappt könnte ich es eigentlich als Download für alle zur Verfügung stellen - dann müsste keiner mehr den Compiler aus den Quellen selbst erstellen.

13.7.2015: Warum es mit der Alternative zum Raketenantrieb nicht klappt

Gestern bekam ich eine reichlich wirre Mail zum Sängerkonzept und warum dies nicht klappt. Anstatt lang und breit zu antworten, dachte ich mir mache ich dies mal zum Blogthema. Als erstes mal eine grundsätzliche Aufklärung: Sängers Konzept war das eines zweistufigen Raketensystems mit geflügelten Stufen. Der Unterschied zu den ersten Entwürfen für das Space Shuttle, die auch zwei geflügelte Stufen vorhersahen, eigentlich nur, dass es vertikal startete.

Heute verstehen viele eigentlich darunter ein anderes Konzept, das nur in der Oberstufe einen Raketenantrieb nutzt, doch das hat Sänger weder ausgearbeitet noch war es vor seinem Tod auch nur ansatzweise möglich. Trotzdem spukt die Idee den Raketenantrieb in der ersten Stufe durch etwas anderes zu ersetzen, immer wieder durch die Köpfe vieler.

Fangen wir mit dem Düsenantrieb an. Auf dem Papier sieht er dem Raketenantrieb doch enorm überlegen aus. Sein spezifischer Impuls ist z. B. zehnmal höher. Das liegt daran, dass man zum einen den Oxidator einspart - der Sauerstoff stammt aus der Luft. Das alleine macht bei Raketen zwischen 70 und 85% des Gewichts desTreibstoffs aus. Zudem besteht die Luft zu 80% aus Stickstoff, der miterhitzt wird und zum Schub beiträgt.

Das Ganze hat nur einen kleinen Haken. So sinkt die Nutzlast bei Düsenflugzeugen bei höheren Geschwindigkeiten rasch ab. Transportflugzeuge wie die C5 Galaxy können etwa ein Drittel ihrer Startmasse als Fracht transportieren. Sie sind unterschallschnell. Die Mach 2 erreichende Concorde konnte 120 Passagiere transportieren - ihr Gepäck aber flog mit einem langsameren Flugzeug. Frachtmitführung ging schon mal gar nicht. Das entspricht einem Nutzlastanteil von einem Neuntel des maximalen Startgewichts. Bei den wenigen, bekannten Mach 3 schnellen Jagdflugzeugen sinkt es auf ein Zwölftel. (Wobei sie ehrlicherweise nur ohne Nutzlast Mach 3 erreichen).

Je höher die Geschwindigkeit, desto kleiner die Nutzlast und desto höher der Treibstoffverbrauch. Der Düsenantrieb eignet sich daher nicht als alleiniger Antrieb für eine Unterstufe. Bis heute hat man maximal etwas über Mach 3 erreicht, das ist gerade mal ein Achtel der Geschwindigkeit für einen Orbit. Zudem wird gerne vergessen, dass Flugzeuge bei gleichem Schub enorm viel größer als Raketen sind. Eine C5 Galaxy ist eines der größten Flugzeuge der Erde und sie kann gerade mal eine Vega als Nutzlast transportieren. Ihre vier Triebwerke haben aber nicht mal 40% des Schubs der Vega.

Höhere Geschwindigkeiten erreicht man mit Staustahltriebwerken. Sie verwenden das gleiche Prinzip wie Düsentriebwerke - Luft wird verdichtet und mit Kraftstoff vermischt, der sich bei Staustrahltriebwerken durch die hohe Temperatur sogar selbst entzündet. Sie setzen dazu aber keine Turbine als Verdichter ein, sondern dies erfolgt alleine durch den Staudruck, indem nach dem Einlass der Passageweg verengt wird. Es gibt zwei Typen: bei denen einen erreicht die Luft Unterschallgeschwindigkeit vor dem Auslass und bein den Zweiten ist sie überschallschnell. Der Rekord eines Staustrahltriebwerks liegt derzeit bei Mach 9.6. Theoretisch wären bis zu Mach 15 möglich. Praktisch ausgelegt wurde zumindest in den Planungen die X-33 auf Mach 12. Staustrahltriebwerke, funktionieren daher erst, wenn die Luft eine gewisse Mindestgeschwindigkeit hat. Sie können somit nicht vom Boden abheben. Die Staustrahltriebwerke, bei denen die Luft Unterschallgeschwindigkeit vor der Expansion erreicht, wurden in einigen Experimentalflugzeugen und Flugabwehrwaffen getestet. Sie können bei > Mach 1 gezündet werden. Die Ramjets (überschallschnelle Expansion der Luft) brauchen noch höhere Startgeschwindigkeiten bis zu Mach 3. Mit unterschallschnellen Expansion erreicht man je nach Treibstoff nur maximal mach 5 (Kerosin) bis 7 (Wasserstoff)

Die Staustrahltriebwerke funktionieren - das ist erst mal eine gute Nachricht. Aber es gibt zwei Probleme: Die Startgeschwindigkeit, bis sie zünden, liegt deutlich über dem, was ein unterschallschnelles Transportflugzeug erreichen kann. Damit scheidet es aus, diese ökonomische Startweise zu nutzen (ein Trägerflugzeug trägt die Kombination auf Starthöhe und klinkt sie aus). Man braucht wie bisher in allen umgesetzten Konzepten eine Startrakete, dann kann ich natürlich auch gleich vom Boden aus starten - mehr noch - ich ersetze eine Raketenstufe durch eine Raketenstufe und einen Ramjet. Allerdings arbeitet man derzeit an Kombitriebwerken, die zuerst wie ein Düsentriebwerk arbeiten und später in einen Ramjetbetrieb übergehen.

Der zweite Problem ist technischer Natur. Was bisherige Pläne für überschallschnelle Raumfahrtprojekte beendete, waren die nicht gelösten Temperaturprobleme. Schon das nur Mach 3 schnelle Flugzeug SR-71 heizt sich durch die Luftreibung um bis zu 500 K auf. Das ganze Flugzeug dehnt sich aus, was vor allem für die Entwicklung von Tanks die dann keine Risse bekommen, durften sehr problematisch war. Bei höheren Geschwindigkeiten wird dies noch extremer. Bei der X-33 konnte man trotz Verwendung von keramischen Materialen und Faserverbundwerkstoffen keine Lösung  finden, die gewichtsmäßig noch tolerierbar war. Die Haut hätte sich über 1200 °C aufgeheizt. Das war schließlich die Ursache für das Ende des Projektes wie auch eines parallel verfolgten Ansatzes von Lockheed. Der Ramjet selbst war nie das Problem.

Das zeigt das Problem. Theoretisch könnte man also erst mit einer Raketenstufe auf Mach 2-3 beschleunigen, dann den Ramjet einschalten und weiter beschleunigen. Wenn der Thermalstress das Erreichen von Mach 12 verhindert, muss man früher abbrechen. Mach 10 wurden ja schon erreicht (allerdings gingen diese unbemannten Flugkörper nach Erreichen des Rekords alle verloren, eine Bergung war nie vorgesehen, sodass man über ihren Zustand nichts weiß). Den Rest bis zur Orbitgeschwindigkeit und einen Großteil der Gravitationsverluste (bei den bisherigen Tests war in 33 km Höhe Schluss - bei zu geringer Luftdichte kann auch der Ramjet nicht weiter beschleunigen) muss die Oberstufe aufbringen, die dann etwa 6 km/s aufbringen muss. 3 km/s schaffen die ersten beiden Stufen.

Für mich ist das ein einsichtiger Grund - man tauscht eine Raketenstufe durch zwei Stufen ein nur um ein Drittel der Zielgeschwindigkeit zu erreichen, Man hat einen Riesenaufwand und trotzdem muss die Oberstufe noch mehr als doppelt so viel Arbeit leisten. Anders als bei einer Rakete trägt die Unterstufe, wenn höhere Geschwindigkeiten erreicht werden müssen, auch nichts bei - es ist immer bei Mach 10 Schluss, egal wie schwer die Oberstufe ist. Das sind gravierende Nachteile. Da erscheint es einfacher eine normale Raketenstufe mit Flügeln und einem Düsentriebwerk auszustatten und wenn sie nach einem ballistischen Flug wieder in die Troposphäre Eintritt diesen in Betrieb zu nehmen und bei einem Flugplatz zu landen. Entsprechende Konzepte gab es ja auch wie die Baikal oder der LFBB.

14.7.2015: Am Anfang war das Wort

Hans lieferte mir den Aufhänger für den heutigen Artikel, der sich auch mit Prozessorarchitekturen beschäftigt. Nämlich die Frage wie man 16 Bits in der Informationstechnik bezeichnet. Schon mal der Ansatz wie Hans diese Frage löst ist interessant. Ich würde in Google Books nachschauen oder in meinem Bücherregal. Hans stellt die Frage in einem Forum, was angesichts einer Generation die mit der x86 Architektur aufgewachsenen ist und vielen Softwerkern, die meinen die Bezeichnungen in ihrer Programmiersprache wären Standardausdrücke, in etwa so ist als wenn man auf einem mittelalterlichen Markt fragt "Ist die rothaarige Frau eine Hexe?".

Also welche standardisierten Ausdrücke gibt es in der Informationstechnik? Nun als erstes gibt es mal das Bit. Ein Bit ist die kleinste Einheit, die gespeichert werden kann. Bei den meisten Computern ist es aber nicht die kleinste Einheit die sie ansprechen können, außer sie haben Bitmanipulationsbefehle. Doch Speicherbausteine waren sehr lange bitweise organisiert. Früher war das sogar noch zu sehen. Bei Ringkernspeichern entsprach das genau einem Eisenkern. Die bitweise Organisation sieht man heute noch manchmal in den Anzahl der Speicherbausteine auf DIMMs, auch wenn es hier noch die Organisation in 4 und 16 Bit Einheiten gibt die gängiger ist, weil man so weniger Chips braucht. (16 oder 4 für die heutigen DIMM die 64 Bit Datenbusse haben anstatt 64 Stück).

Schon bei den beiden nächsten begriffen, dem Byte und Nibble hört die Standardisierung auf. Unter einem Byte versteht man heute 8 Bit. Doch dem war nicht immer so. Als Byte versteht man die Anzahl der Bits die man braucht um ein Zeichen in dem Zeichensatz des Computers abzulegen. Jeder Wert steht für einen Charaktercode. Der erste Standard der sich einbürgerte, kam vom American Standards Association es war der American Standard Code for Information Interchange (ASCII). Er hatte den Zweck die vorher unterschiedlichen Zeichensätze bei verschiedenen Computern zu vereinheitlichen. Wie der Name sagte, war es ein Zeichensatz für die USA. (eigentlich nach dem Wortlaut Amerika, doch spanisch sprechende Länder die Accents brauchen ignorierte der Standard). Er enthielt in den ersten 32 Positionen keine druckbaren Zeichen sondern Steuerzeichen, die bei einem Drucker oder Fernschreiber Aktionen auslösten oder in bestimmten Programmiersprachen zweckentfremdet als Stringende (Nullzeichen) genutzt wurden. Bis heute wichtig sind Tabulator (9), Zeilenvorschub (Carriage Return - cr) (13) und Wagenrücklauf (line feed lf) (10). In Windows wird jede Zeile von Wagenrücklauf und Linefeed abgeschlossen. Das Zeilenendzeichen in Unix ist es nur der Zeilenvorschub. Das hat historische Gründe, Windows übernahm das von DOS und dieses die Codierung von CP/M die sie für die damals noch üblichen Typenraddrucker einführte. Bei Unix hat man sich wohl gedacht das ein Zeichen genügt. Das ist bis heute so, so werden beim Kopieren von Winscp meine Pascal Quelltexte auf dem Raspberry Pi kleiner – das Programm ersetzt cr/lf durch Lf.

Seit etwa der siebziger Jahre sind daher 8 Bit die Standardgröße für ein Byte. Für ASCII braucht man eigentlich nur 7 Bit, doch da Computerarchitekturen meist ein Vielfaches von geraden Bitanzahlen verarbeiten, hat man das Byte auf 8 Bit gesetzt. Bei ASCII-Codes sind die Codes von 128 bis 255 daher nicht definierte und man nutzte sie für Erweiterungen. So z. B. die Umlaute die man in den USA nicht kennt oder Blockgrafikzeichen. Diese waren dann von Computer zu Computer unterschiedlich. So gab es in den Achtziger Jahren eigene Drucker für den Apple, C64, den IBM PC oder für andere populäre Computer die sich nur im Zeichensatz unterschieden.

Die 8 Bit breite Byte gilt in etwa seit Anfang der siebziger Jahre als die US-Regierung aktiv die Anschaffung von Computern förderte die den ASCII-Zeichensatz unterstützten. Den vorher war es so das jeder Hersteller seine eigene Codierung hatte und die meisten waren auch nicht 8 Bits lang sondern nur 6, Das reicht nur für 64 Zeichen. 26 Groß- und Kleinbuchstaben und 10 Ziffern ergeben zwar 62 Codierungen, doch man braucht ja noch einige andere Zeichen wie Satzzeichen, Klammern, Leertaste, mathematische Operationen und Steuerzeichen. So hatten diese 6 Bit Codierungen keine Kleinbuchstaben. Das sieht man in zahlreichen frühen Programmiersprachen wo Befehle nur in Großbuchstaben stehen wie Fortran oder Cobol.

IBM nutzte z.b. EBCDIC, ein Zeichensatz den es in sechs verschiedenen Versionen von 6 bis 8 Bits Breite gibt. Andere Hersteller hatten andere Codierungen so CDC in den ersten Modellen von Cray. Die Dominanz von 6 Bits in der frühen Computertechnik zeigt sich auch in Architekturen die ein Vielfaches von 6 Bits waren wie 12 Bit, 18 Bit und 30 Bit Rechner bei PDP (PDP-7, PDP-9 und PDP-10). Es gab auch 24, 48,36 und 60 Bit Rechner. Die Einführung der Oktalschreibweise in C, die man heute kaum noch braucht, drückt sich auch darin aus dass 3 Bit mit den Ziffern von 0 bis 7 ausgedrückt werden können. Das leitet über zum Nibble. Ein Nibble ist per Definition ein halbes Byte. Damit ist es auch nicht konstant groß, sondern war früher 3 Bits breit (Oktalnotation) heute dagegen 4 Bit breite Da man die 16 Zustände der 4 Bits nun nicht mehr mit den Zahlen von 0 bis 9 ausdrücken kann schreibt man heute Nibbles in Hexadezimalschreibweise auf der Basis von 16, wobei man die Buchstaben A bis F für sei werte von 10 bis 15 nimmt.

Also Bytes und Nibbles sind nicht standardisiert. Daher hat man als Standard auch einen anderen Begriff für das 8 Bit Byte gewählt: Oktett. Wer Standards z.B. für Internet Protokolle durchliest, wird diesen Begriff öfters lesen. Die Franzosen wird es auch freuen, denn die haben schon in den Achtzigern per Deklaration das Byte im Sprachgebrauch durch das Oktett ersetzt. Man hat ja dort eine Abneigung gegen Fremdwörter und will die Sprache französisch „rein“ halten.

Das einzige was nach dem Bit und Oktett standardisiert ist das Wort, bzw. Vielfache davon Doppelwort, Quadwort. Ein Wort entspricht der Bitanzahl der Architektur des Computers. Wenn man von der heutigen x86-Architektur, die den Speicher byteweise anspricht, den Blick auf andere CPU-Architekturen schweifen lässt, dann herrschte früher die wortweise Adressierung vor. Das war nur logisch: Der Datenbus war wortweise organisiert und so lud man immer ein Wort ein. Als Nebeneffekt hatte man so bei mehr als 8 Bits in der Architekt auch mehr Speicher. Die Cray 1 hatte in der Standardausführung z.B. einen Speicher von 1 MWorten was bei ihrer 64 Bit Architektur 8 Megabyte entspricht. RISC Prozessoren hatten, als sie einzogen, auch nur eine wortweise Adressierung bzw. Befehle zum wortweisen Verarbeiten von Daten. (ob dem heute noch bei den neuesten Exemplaren so ist weiß ich leider nicht).

Die nur wortweise Adressierung hat einige Vorteile. Der erste ist, dass man eine Menge Opcodes spart um Bytes oder andere Bruchteile eines Wortes als Operanden zu unterstützen. Das Verarbeiten von kürzeren Operanden macht nur in wenigen Fällen Sinn. Man muss z.b. drauf achten das die höherwertigen Bits von Registern nicht verändert werden, d.h. man kann nicht einfach die 8-bit-Operation durch eine wortweise Operation ersetzen. Sinn macht es nur bei Zeichenoperationen die früher eben immer 8 Bit umfassten (heute dank weiterer Standards auch 16 Bit). Früher waren Computer fast ausschließlich zum Rechnen da und Zeichenoperationen beschränkten sich meist auf die Ein/Ausgabe von Zeichenketten. So gab es in Crays Rechnern keine Operationen für 6 oder 8 Bits. Man packte eben einfach 10 bzw. 8 Zeichen in Wort und gab sie aus. Was man nicht brauchte, füllte man mit Nullbytes auf. Lediglich der Vergleich, den man mit dem Durchsuchen von Zeichenketten braucht, geht so nicht. Bei einigen 16-Bit Prozessorarchitekturen machte die byteweise Operationen einen Sinn wenn sie nur einen 8-Bit Datenbus hatten oder ihre ALU nur 8 Bit breit war, dann wurden die 16 Bit Operationen in zwei Durchgängen erledigt.

Die heutige Dominanz des Bytes und das man Worte oft als EDV-Begriff nicht (mehr) kennt, kommt daher das heute die x86 Architektur vorherrscht und die basiert auf der 8 Bit Architektur des 8080. Der 8086 hatte daher auch alle 8 Bit Verarbeitungsbefehle und adressierte wie der 8080 byteweise. Das war nicht bei allen damals neu erschienen Prozessoren. Der TMS 9900 adressierte z.B. nur 16 Bit weise (ganz durchdacht hatte man das Konzept aber nicht, denn der Adressbus war nur 15 Bit breit, sodass er in der Praxis auch nur 64 KByte ansprechen konnte). Andere Prozessoren wie der MC68000 hatten einen universelleren Ansatz und unterstützen byte, word und long word (so heißen in Motorola Nomenklatur 8, 16 und 32 Bit).

Ein zweiter Grund war die mit den ersten Personalcomputern entstandenen Anwendungen. Eine der ersten war Textverarbeitung. Sie erleichterte zuerst das Leben von Sekretärinnen und rationalisierte sie dann später weg. Texte zu verarbeiten bedeutet Zeichenketten zu verarbeiten und deren kleinste Einheit ist eben 8 Bit breit.
Was nicht standardisiert ist auch die Bezeichnung von Typen in Programmiersprachen. Im ursprünglichen C Standard steht z.B. nur die Reihenfolge der Typen, d.h. das ein int größer als ein short int ist. Der erste von Kerningham und Ritche für eine Fremdplattform (Honeywell 6000) übersetzte C-Compiler nutzte z.B. dort einen 6 Bit Code (die PDP-11 auf der C entwickelt wurde war eine 16 Bit Maschine mit 8 Bit Bytes), da dieser Rechner eine 36 Bit Architektur hatte. Alle Datentypen waren dort anders groß als auf der PDP-11. Wer schon in DOS Zeiten C programmierte wird auch noch wissen, das damals der Int auch nur 16 Bit breit war. Es wäre interessant zu wissen ob heute auf einem 64 Bit Compiler dann int 64 bits breit ist, bei 32 Bit Windows war er zumindest nur 32 Bit breit und 64 Bit waren dort ein long int. Ähnliches gibt es bei anderen Programmiersprachen. In Pascal ist der Typ Real auch nicht standardisiert. Turbo Pascal nutzte dafür 48 Bits, doch wenn man heute ein Programm mit Real als Datentyp schreibt wird man bald feststellen das es intern ein 64 Bit Wert ist – die 48 Bit Typen wurden durch Software berechnet und heute hat jeder Prozessor die Möglichkeit Fließkommazahlen in Hardware zu berechnen.

In jedem Falle sind die Bezeichnungen aus Programmiersprachen nicht standardisiert. Standardisiert sind die Bezeichnungen für Fließkommazahlen sowie ihr Aufbau und Genauigkeit in IEEE 754, doch deren Bezeichnungen wie "Binary64" für den Typ Double (64 Bit Fließkommazahl) sind nicht allgemein üblich und Ganzzahlen hat IEEE leider nie standardisiert.

Wie bezeichnet man 16 Bits denn nun am besten? Also ich würde zu „16 Bit Wort“ greifen, schon alleine weil auch das Wort unterschiedlich groß sein kann (ich kenne Worte von 12 bis 64 Bit Größe).


Sitemap Kontakt Neues Impressum / Datenschutz Hier werben / Your advertisment here Buchshop Bücher vom Autor Top 99