Home Site Map Sonstige Aufsätze Weblog und Gequassel counter

Web Log Teil 431: 28.6.2015 - 5.7.2015

28.6.2015: Neues von OneWeb

Der Betreiber der zukünftigen Satellitenkonstellation OneWeb hat in der letzten Woche einige Verträge abgeschlossen und auch etwas für das Projekt die Trommel gerührt. Das erste waren die Aufträge. Airbus wird die 900 Satelliten bauen, für wie viel ist unbekannt, aber in einem Interview sprach er von einem Kistenziel von 400.000 bis 500.000 Dollar pro Satellit. Wyler hält es für erreichbar, zumindest ist er sicher das man "nahe" an diesem Ziel ankommen werde.

Die ersten 10 Satelliten wird Aribus in Toulouse bauen, die restlichen 890 werden in einer noch zu errichtenden Fabrik in den USA gebaut. Insgesamt 700 Arbeitsplätze sollen in Herstellung, Logistik und Überwachung entstehen. Das ist mir Angesichts der Größe des Projektes, das man sicherlich in dem Bereich mehrerer Milliarden ansetzen kann für mich eher wenig. Ich vermute der Bau in den USA erfolgt um zum einen Subventionen abzugreifen, das tun ja auch andere Firmen, wie ehemals Thiokol die in Nevada einem strukturschwachen Gebiet, produzieren. Zum anderen wahrscheinlich auch um "Hosted Payloads" mitzuführen - ein Trend den es seit einigen Jahren bei den Weltraumagenturen und dem Militär gibt - anstatt einen eigenen Kommunikationssatelliten zu bauen, installiert man die Hardware auf einem anderen Kommunikationssatelliten und zahlt für dessen Nutzung. Im falle dieser niedrigen Umlaufbahn dürfte die NASA vielleicht Interesse haben Instrumente für Wettersatelliten unterzubringen, sofern diese nicht zu schwer für die kleinen Satelliten sind. Das US-Militär könnte sie zur Verbindung zu Truppen im Feld nützen die aus der niedrigen Umlaufbahn leichter zu erreichen sind. Natürlich hilft beim US-Militär auch die Tatsache dass die Satelliten in den USA gebaut werden beim Verkauf von Dienstleistungen. Airbus ist nicht nur Auftragnehmer sondern auch Investor.

Den Startauftrag bekam Arianespace und Virgin Galactics. Arianespace wird 21 Sojus einsetzen, Optionen gibt es für 5 weitere Sojus und 3 Ariane 6 Starts - ja man rechnet damit dass die bis 2021 zur Verfügung steht wenn OneWeb anfangen muss die ersten Satelliten die Ende 2017 starten ersetzen muss. Der erste Sojus Start wird 10 Satelliten starten, die nächsten dann 32 oder 36 auf einmal. Was mich etwas erstaunt ist das die nur ein einen nahezu polaren Orbit in 500 km Höhe gelangen. Von dort aus sollen sie mit ihrem eigenen elektrischen Antrieb die 1200 km Höhe erreichen. Das maximiert zwar die Nutzlast, bedeutet bei 32 Satelliten pro Start aber eine Menge Arbeit für die Bodenkontrolle. Jeder Satellit soll weniger als 150 kg wiegen. Arianespace hat schon 21 Träger bestellt und wird Startrampen im CSG, Baikonur und "anderen Startbasen in Russland" nutzen - ich denke das kann nur Plessezk sein. Anders ist die hohe Startrate (Aufbau in zwei Jahren) nicht erreichbar. Die Ariane 5 hat man auch untersucht, sie hätte 60 Satelliten direkt in den Orbit bringen können, doch da die Satelliten in verschiedenen Orbitebenen befinden wäre das zu viel. Der Kontrakt soll "weniger als" 1,5 Milliarden Dollar umfassen - da hat man einen Rabatt bekommen, denn 6 Sojus für Galileo hatten dieses Jahr die EU 492 Millionen Euro gekostet. Dabei muss Arianespace noch einen Dispenser für die Flotte entwickeln.

Den zweiten Auftrag bekam Virgin Galactic, die gerade Launcher One entwickeln. Dieser Träger kann nur 225 kg in einen LEO oder 120 kg in einen höheren SSO bringen. Daher wird man nur einen Satelliten pro Start starten können. Dafür ist er richtig teuer - 10 Millionen pro Start. Das bedeutet die 39 festen Aufträge (Optionen für 100 weitere) werden dazu genutzt werden Reservesatelliten zu starten. Das System hat ja 900 Satelliten, aber nur 648 braucht man für ein operatives Geschäft. Das Spricht dafür dass man in jeder Orbitalebene eine Menge an Reservesatelliten platziert. Warum man trotzdem noch einen Träger für einzelne Ersatzsatelliten braucht entzieht sich mir. Diese ersten Aufträge werden das Netz aufbauen Arianespace wird 650 starten, Virgin Galactics 39. Die Optionen dienen dann dem Erweitern auf die 900 Satelliten. Arianespace ist die einzige größere Firma die nur Auftragnehmer ist. Auch Virgin Galactic ist zugleich Investor,

Bei den Investoren finden sich unterschiedliche Firmen wie Coca Cola, Intelsat und Qualcomm. Intelsat gibt OneWeb Rückenschutz, schließlich muss gewährleistet sein, dass die Satelliten nicht geostationäre Satelliten stören. Dazu wird man am Äquator die Sendeleistung drosseln (dort schaut eine Antenne direkt in den Zenit wenn sie auf den GEO ausgerichtet ist und auch jeder OneWeb Satellit diesen Punkt passiert). OneWeb hat sich zumindest die Rechte am Ku-Ban gesichert (wie viel blieb offen) und das haben die meisten Investoren hervorgehoben. es klang fast so als wäre das ein Schlüssel so nach dem Motto "Wir haben die Frequenzen als erste, Konkurrenten müssen nun sehen das sie keine Interferenzen verursachen".

Über das Geschäftskonzept weiß man nun mehr. Wie ich schon mal schrieb gibt es den Bedarf in den industrialisierten Ländern nicht. Dort gibt es genügend Breitbandnetze oder Funknetze. Anders sieht es aus in Entwicklungsländern. Man spricht vor allem von Indien, Pakistan und Sri Lanka die jenseits der Großstädte noch eine schlechte oder gar kein Internet haben. Zum andern dann die Inselstatten im Pazifik wie Indonesien wo man nur um die Großstädte herum eine Anbindung hat weil das Gebiet einfach zu groß ist. Da auch Oneweb nicht das Internet verbilligen wird können, Satelliten sind systembedingt teurer als terrestrische Systeme, wird man die Terminals mit 0,5 bis 1 TB Speicher ausstatten, das bedeutet viel Trafik wird gar nicht über den Satelliten geleitet. Wenn ich das Konzept richtig verstanden habe dient ein Terminal in einem Dorf als Accesspoint, an dieses werden dann andere Nutzer mit kurzen Leitungen angebunden oder über einen Sendemast ermöglicht es Handynutzung in der näheren Umgebung. Das Modell ist ein anderes als bei Globalstar und Iridium. Die setzten darauf das Kunden nicht nur ihren Service nutzen sondern eigene Handys kaufen. OneWeb wird zwar auch Terminals verkaufen (Qualcomm liefert die Kommunikationstechnik für Terminals) aber an dieses werden dann viele Einwohner eines Dorfes mit normalen 3G oder 4G Handys angebunden. Hughes wird ebenfalls beteiligt als Onvestor und Auftragnehmer, wahrscheinlich an der Satellitentechnik sein. Ob es sich lohnt wird sich zeigen - den viele der potentiellen Kunden haben nicht nur kein Internet sondern auch wenig Geld. Coca Cola will ihre Filialen über das System verbinden. Ob das nur dazu dient diese an die Zentrale anzubinden oder man eine Art "Coca-Cola Internetcafe" anbieten will - meiner Ansicht nach wohl eher denkbar - blieb offen. Ein Terminal soll Tausende bis Zehntausende Kunden betreuen und einen Datenstrom mit 50 MBit zu einem Satelliten haben - der wird wenn dieser aus dem Empfangsbereich verschwindet auf den nächsten umgeleitet.

Die Gesamtkapazität des Systems wird mit 1 TBit angegeben, das wären 1,3 GBit/s. Die Satelliten tauschen untereinander Daten aus, wahrscheinlich mehrere Beams pro Satellit. Offen bleibt wie viele Bodenstationen es gibt. Das hängt davon ab wie lokal der Traffic ist - das ist ja meist gegeben, ein Inder wird wohl kaum viele Seiten auf Deutschland abrufen aber auch dem Konzept. Ich vermute mal es wird sicher pro abgedecktem Land eine Bodenstation geben, der den lokalen Traffic abdeckt. Man wird auch einige brauchen weil die 1 Terabit ja irgendwann mal zum Boden gehen müssen. Da macht es einen Unterschied ob es 100 GBit oder 10 Gbit/s sind. Zudem steigt mit weniger Bodenstationen der Intersatellitenverkehr an, da immer mehr Satelliten passiert werden müssen bis man eine Bodenstation erreicht hat. Als Vorteil wird die geringe Latenz angegeben, sie dürfte signifikant geringer als bei geostationären Satelliten oder dem O2B Netzwerk in 8000 km Höhe sein.

Bisher hat man 500 Millionen Dollar an Kapital und wird erst 2017 eine zweite Kapitalspritze von den Investoren brauchen, Zu denen gehören noch Bharti und totalPlay. Das Gesamtprojekt liegt in der Größenordnung von 2,5 bis 3 Milliarden Dollar. der größte Teil davon entfällt auf den Start.

http://spacenews.com/launch-options-were-key-to-arianespaces-oneweb-win/

http://spacenews.com/onewebs-partners-in-their-own-words/

http://spacenews.com/news-analysis-onewebs-big-announcement-should-quiet-doubters/

29.6.2015: Die ISS und ihre Abbremsung

Nachdem ich, als ich für die Gefahren des Weltraummülls mal rochiert habe wie lange ein Satellit in dieser Höhe wohl lebt und da auch einen Quelltext gefunden habe um das vereinfacht zu berechnen, dachte ich mir spielen wir mal da mal etwas rum und zwar mit einem bekannten Objekt. Für die Routine wichtig ist:

Die Fläche der ISS wird von ihren Solarzellen bestimmt. Die haben alleine 2500 m², dazu kommen dann noch 150 m² für die Module wenn sie mit der Längsachse von Bewegungsrichtung fliegt. Die Masse beträgt 420 t. Die Orbithöhe betrug mal 420 km. Die folgende Abbildung zeigt was bei einer Ausgangshöhe von 420 km und einem mittleren SFU von 130 und einem AP-Index von 20 passiert. Die Station hat ohne Maßnahmen eine Lebensdauer von 760 Tagen, wobei sie 650 Tage braucht um um 120 km auf 300 km zu sinken. Die zweiten 120 km bis sie in 180 verglüht legt sie in 50 Tagen zurück (bei 0 km stoppt die Simulation, weil die Lebensdauer nun kleiner als ein Tag ist und auch andere Faktoren starken Einfluss haben).

Nun drehen wir mal an den Werten. Angenommen, es wäre gerade ruhige Sonne oder im extrem sehr aktive Sonne, wie wirkt sich das aus? Nun wenn man den SFU-Index zwischen 70 und 220 variiert (300 wird nur über wenige Tage erreicht) so sieht man, dass der Einfluss sehr stark ist: Bei 70 SFU bleibt sie 1500 Tage im Orbit, bei 220 unter 330 Tagen. Viel geringer ist der Einfluss des magnetischen Fluxes, zudem linearer. Hier schwankt die "Lebensdauer" nur um rund 100 Tage rund um die 720 Tage.

Was kann man tun um das absinken zu verhindern - natürlich, wie bisher auch, den Orbit laufend anheben. Nach dem Ablegen der letzten ATV machen das ja nur noch die Progress tun - und seit der letzte ATV ablegte ist sie ja auch von 416 auf 400 km Höhe abgesunken. Besser wäre es die Solararrays durch effizientere zu ersetzen. Die derzeitigen haben 14% Wirkungsgrad. Flexarrays von ATK haben heute 26-28%. nimmt man nur die konservative erste Zahl, so würde die Fläche von 2650 auf 1500 m² sinken. Die Aufenthaltsdauer würde von 706 auf 1248 Tagen ansteigen.

Die wirksamste Möglichkeit ist es aber die Station möglichst weit abzuheben: Um die ersten 10 km zu sinken braucht die Station im Anfangsszenario 133 Tage. Würde man sie nur um 30 km anheben, so würde sie bedeutend länger im Orbit bleiben, nämlich 1300 Tage. Es ist effizienter als sie dreimal um 10 km sinken zu lassen und dann anzuheben, denn das bringt nur 440 Tage mehr, einmal um 30 km anzuheben dagegen 600 Tage. Das spart über die Zeit schon Treibstoff. Derzeit hat die ISS wenn man sie regelmäßig anhebt und die Bahnhöhe konstant hält einen Schubbedarf von rund 6,9 Millionen Ns, das sind bei den lagerfähigen Treibstoffen rund 2,4 t Treibstoff. (Spezifischer Impuls 2900 angenommen).

Zum Schuss noch eine Frage aus dem Bereich - was wäre wenn. Was wäre wenn man bis zum Ende der Lebensdauer der ISS (2029) keine Anhebung mehr durchführen müssen? Nun wir müssten sie auf 520 km Höhe bringen. Dort hat sie eine Lebensdauer von 5097 Tagen (11.6.2029, bis Ende 2028 laufen derzeit die Planungen. Dazu braucht man rund 25,7 Millionen Ns, also einmal 8,9 Treibstoff - alternativ kann man natürlich auch 7 Jahre jeweils 2,4 t Treibstoff investieren um die Bahnhöhe zu halten. Das hätten zwei ATV geleistet.

Eine zu hohe Bahn ist aber nicht geplant, da auch die Nutzlast der Raketen abnimmt und da der Transporter dann auch mehr Treibstoff später zum verglühen braucht geht das gleich doppelt von der Fracht ab. Bei der Ariane 5 ES z.b. um 55 kg wenn die Bahn um 10 km höher. Bei 16 t Masse beim ablegen braucht ein ATV zudem 33 kg mehr Treibstoff um zu verglühen, das heißt eine 10 kg höhere Bahn reduzieren die Nutzlast um 88 kg oder 1,3% der Frachtmenge. Mann kann so leicht rechnen, wann man besser fährt. Beim einmaligen Angeben braucht man 7,9 t Treibstoff verteilt über 7 Jahre weniger. In der Zeit werden rund 210 t Frachtgüter zur Station gelangen. 1.3 % davon sind 2,6 t - das einmalige anheben wäre also die bessere Lösung.

30.6.2015: Neues von der Wetterstation

Ich hatte ja schon mal im Blog angekündigt, dass ich mal ein Hardware Projekt anfangen will - man muss dazu sagen, dass ich zwei Linke Hände habe und besonders schlecht sehe, deswegen habe ich bisher immer um fummelige Hardware einen Bogen gemacht.

Ich wollte eine Wetterstation, allerdings kein 30 Euro Discountgerät ,das nur einige Werte anzeigt, sondern eines das die Messwerte laufend protokolliert ohne das man sie dauernd abfragen muss.

Das setzte die Hürden hoch. Nur Werte zu erfassen und über Netzwerk zu transferieren hätte noch ein Arduino geleistet, doch mit dem Protokollieren wärs nur gegangen wenn man einen mit großem Speicher nimmt oder SD-Slot wobei man wenn man die auf dem PC ausliest wiederum aufpassen muss, das der Arduino nicht draufschreibt. Dazu kam, dass ich als ich nach Sensoren suchte jede Menge fand - zu viele und ob die auch alle passen oder ansprechbar sind? Kurzum. Das war nicht das was ich wollte.

Über die ct' fand ich dann Tinkerforge. Die Firma hat einen interessanten Ansatz: Ein Microcontroller "Master-Brick" überwacht bis zu 4 angeschlossene Geräte "Bricklets", das können Sensoren sein von Einfach bis zu GPS, aber auch Aktoren, Relays, Motoren oder LCD. Mehrere Bricks kann man verbinden wenn man mehr als 4 Geräte hat und es gibt auch Erweiterung für weitere Fähigkeiten wie Wlan. Die Auswahl an Sensoren ist dann eingeschränkt auf die die Tinkerforge anbietet das sind aber auch Temperatur, Druck, Feuchtigkeits- und Lichtsensoren.

Angeschlossen und mit dem Strom versorgt werden sie über USB. Sie geben sich dann als Geräte aus die man über Port 4223 ansprechen kann. Wenn man eine Wlan Erweiterung hat, dann kann man sie auch direkt übers Internet anbinden oder eben über einen Computer der an sie angeschlossen ist.

Dort entdeckte ich eine Wetterstation als Kit und die sollte man auch über den Raspberry Pi ansprechen können. Da ich gerade das Modell 2 in Betrieb habe, ist das Modell 1 etwas arbeitslos. So war auch für das eine Lösung gefunden und netterweise kann man die API auch in Lazarus/Delphi aufrufen. Und Lazarus gibt es auch für den Raspberry Pi.

Also habe ich sie mir mal bestellt - mit 120 Euro nicht ganz so billig. Der Zusammenbau war einfach, Zusammenstecken und mit Schrauben fixieren - in einer Viertelstunde erledigt. Schnell konnte ich auch den Brickviewer und Brickdämon installieren über den die Geräte angesprochen werden. Beim Raspberry blieb der Viewer verschollen, aber der Dämon taucht in der Preisliste auf und der ist der wichtige. Der Viewer ist nur eine visuelle Oberfläche für Tests und zum Auslesen der UID, die braucht man für die API. Jedes Bricklet hat eine eigene dreistellige UID.

So habe ich in den letzten Tagen an einer Anwendung geschrieben. Vorerst nur in Delphi auf dem PC. Se besteht aus einer visuellen Oberfläche in der man alles einstellen kann (knapp 20 Parameter sinds) und einer nicht visuellen Komponente die periodisch Daten liest, zwischenspeichert und in einem wählbaren Intervall eine CSV Datei und eine Webseite mit Bildern und einer Tabelle erzeugt. Unter http://www.bernd-leitenberger.de/wetterstation könnt ihr euch das mal ansehen.

Die API ging eigentlich problemlos. Die meiste Arbeit hatte ich beim Entwerfen der Routinen für das Zwischenspeichern und dem Erzeugen von Grafiken - ein Chart das es als Komponente gibt wollte ich nicht nehmen, da das bei mir in anderen Programmen wenn ich es häufig nutze irgendwann mal Laufzeitfehler bringt und die Routine sollte ja später dauernd laufen. Dann kamen noch ein paar Probleme, die auftraten wenn der PC in den Ruhezustand ging - wie das beim Raspberry wird weiß ich noch nicht. Mein Raspi hat zumindest nach längerer Inaktivität nichts mehr am Monitor angezeigt und auch nicht auf das Keyboard reagiert. Aber in Foren finde ich das er gar keinen Standby Modus hat.

Der nächste Schritt ist nun eine Konsolenanwendung für den raspberry, die die Konfiguration die man mit der visuellen Oberfläche erstellt einlädt. Dann braucht man die visuelle Komponente nur noch zum Einstellen.

Was mich als die fertige Wetterstation sah, störte war das sie anstatt einem Temperatursensor ein LCD-Feld hat. Dessen Nutzen halte ich für begrenzt, denn um was darauf anzuzeigen braucht man einen PC. Wen ich den aber schon angeschlossen habe (selbst wenn es nur ein Raspberry ist), dann kann der das Wetter auch gleich auf den eigenen PC übertragen.

So werde ich noch einen Temperatursensor nachbestellen müssen.

2.7.2015: Ihr armen Satellitenbetreiber

Erlaubt mir, dass ich euch mein tiefstes Bedauern ausdrücke. Ja´- ihr seid schon eine arme Industrie. Da habt ihr jetzt erneut nachdem SpaceX nun sicher einige Monate lang keine Starts durchführen kann und Arianespace bis Ende 2016 ausgebucht is,t ein kleines Problem. Dabei fordert ihr ja seit Jahren einen dritten LSP (Launch Service Provider) sowohl um Starts zeitnah durchführen zu können und sowohl eine Absicherung gegen eine Ausfall eines Trägers zu haben. Natürlich senkt das auch die Staatskosten durch mehr Konkurrenz. Doch ihr findet einfach keinen. Ihr seid ja so arm dran!

Okay, nachdem sich jeder Leser der eine gewisse Ahnung hat sich erst mal 5 Minuten vor Lachen auf dem Boden gewälzt haben für alle anderen ein paar Tatsachen über diese Industrie die so sehr jammert:

2012 betrug der durchschnittliche Mietpreis eines Transponders 1,6 Millionen Dollar, bei durchschnittlichen Investitionskosten von 1,0 Millionen Dollar. Auch wenn das sehr starke regionale Schwankungen hat (in Europa erzielt man 3,2 Millionen Dollar, im Pazifikraum nur 1,0) so ist das doch ein Gewinn (im Durchschnitt von 60% des investierten Kapitals - das ist eine gute Verdienstspanne, die man heute bei wenigen Anlagen noch bekommt.

Die Startkosten betragen je nach Kosten den Satelliten und des Trägers typisch 25 bis 35% der Gesamtkosten vor Versicherung. Das ist also nicht der große Kostentreiber. Würden sie 50% höher liegen so würde das bei 1,0 Investitionskosten pro Transponder um 0.125 oder 0,175 ansteigen..

Es gibt heute schon mehr als drei Launch Service Providers: ULA bietet die Atlas V an, ILS die Proton, Sealaunch die Zenit, Arianespace die Sojus und Ariane 5, Mitsubishi die H-2A. Das sind fünf Firmen mit sechs verschiedenen Trägern (eventuell werden auch Delta 4 und GSLV angeboten, darüber habe ich leider keine Informationen). Warum in den vergangenen Jahren nur zwei Firmen fast alle Starts durchführten? Die anderen waren zu teuer oder zu unzuverlässig. Während ich den letzten Punkt durchaus verstehen kann, verstehe ich den ersten nicht: wenn ihr eure Satelliten so gerne zeitnah gestartet haben wollt, dann sollte euch das einen Zusatzobulus wert sein. Derzeit verzichtet ihr auf diese Anforderung gerne, wenn der Preis stimmt.

Die Frage ist wie viele LSP verträgt der Markt? Gestartet werden pro Jahr etwa 20 Satelliten. Wenn ich mal dran denke, dass Arianespace in den Neunzigern 12 Ariane 4 pro Jahr starten konnte dann wäre das gerade mal genug für zwei Anbieter die Einzelstarts durchführen. Weniger Starts bei mehr Anbietern bedeuten auch höhere Kosten. Da beginnt eine Spirale. Die LSP die in den letzten Jahren kaum Starts durchführten haben geringe Stückzahlen, was wiederum die Starts verteuert. Darüber hinaus greift natürlich das Gesetz der Serienfertigung - sprich je mehr Träger man fertigt desto billiger wird jeder einzelne, weil man durch höhere Stückzahlen rationellere Fertigungsmethoden einführen kann oder die Erfahrung und Geschwindigkeit der Mitarbeiter steigt. Jede Fertigungsstraße wird aber auf ein Optimum ausgelegt. Wird sie nur teilweise ausgelastet so steigen die Produktionskosten an - ein sehr prominentes Beispiel war die Titan - soll man mehr produzieren als normalerweise möglich, so kann die Qualität leiden oder die Kosten durch bezahlte Überstunden ansteigen. Das bedeutet dass wenn ihr wirklich drei LSP haben wollt, so verteilt die Aufträge gleichmäßig das jeder seine Produktionsstraße weitgehend, aber nicht total auslastet um Reserven zu haben wenn mal ein LSP ausfällt.

Gibt es eine solche "Investitionssicherheit" so wirkt sich auch der Ausfall eines Trägers nicht so aus. Eine Rakete braucht meist zwei Jahre von der Bestellung bis zum Start, manchmal noch länger. Ist ein LSP sicher, das er Träger verkaufen kann, ohne einen Kunden bei Baubeginn zu haben, so kann er sie auf "Vorrat" fertigen, vielleicht findet sich ja in den nächsten Jahren noch ein Kunde. Das tat Arianespace in den Neunzigern und konnte damals auch einen Start dreieinhalb Monate nach Vertragsunterzeichnung  durchführen, als der Kunde absprang nachdem eine andere Rakete einen Fehlstart hatte.

Damit zusammenhängend ist, das man als Industrie nur das fordern kann, was man auch leisten will. Bei 20 bis 25 Starts (bisher, mit den Kleinflotten ändert sich das vielleicht dauerhaft) wären schon drei LSP gerade an einer Grenze von 7-8 Starts pro Monat. Noch etwas weniger und die Fertigung geht in Einzelfertigung über und die Raketen werden sehr teuer. Im Prinzip verlassen sich die LSP schon heute darauf, dass Regierungen ihre Starts quersubventionieren: Mit Ausnahme von Arianespace überwiegen bei jedem anderen LSP die staatlichen Starts. Sie sorgen für die Stückzahlen, damit sie Fertigungsstraßen rentabel sind. So hat die Industrie bei der Ariane 6 ja auch gefordert, dass die ESA eine bestimmte Mindestzahl an Starts pro Jahr abnimmt.

Kurzum: Jammert weniger, ihr seid an der Misere selbst schuld. Wenn ein neuer LSP auftaucht, der billiger ist lauft ihr zu dem, selbst wenn er nicht termintreu ist. Da ist dann die sonst so geforderte Termintreue nicht mehr wichtig. Wenn ihr drei LSP haben wollt, warum beauftragt ihr dann nicht einen dritten? Selbst wenn ILS und Sealaunch angesichts der Fehlschläge ausscheiden, bleiben ja immer noch H-2A, Atlas und Sojus (immerhin die gleiche 0° GTO Kapazität wie die Falcon 9). Ansonsten hört auf zu jammern!

Und wer nun erwartet hat dass ich viel über SpaceX letzten Fehlstart schreibe, den muss ich enttäuschen. Genauso wie ich Starts für normal halte sodass sich sie nicht dauernd kommentiere mach ich das bei Fehlstarts, zumal es ja nicht viel zu schrieben gibt. Details gibt es ja bisher keine. Nur zwei Dinge verwundern mich. Das eine ist technischer Natur: Die Dragon sollte eigentlich schwimmen. Ihr Innenvolumen geteilt durch die Startmasse ergibt einen Quotient von unter 1. Sie müsste da sie für einen Wiedereintritt ausgelegt ist auch einiges aushalten können. So heftig das die Dragon beschädigt wird und untergeht hatte ich die Explosion nicht eingestuft.

Das zweite waren die Kommentare hier. Das meiste ist nicht neu, wie immer viel Kindergarten "aber andere Firmen machen das doch auch so". Zahlenverdreherei zu den Gunsten von SpaceX., aber eines ist neu, was mich in der Meinung es handelt sich mehr um eine Ersatzreligion als eine Raumfahrtfirma handelt, ist bestätigt: Wenn obwohl (oder gerade weil) man nichts über die Ursache weiß, es Leute gibt die sich sicher sind, das die Nutzlast dran schuld ist. Ja das geht dann schon in Richtung unfehlbarkeitsgebot. Passt zu dem religiösen Eifer der Befürworter, ihre Herabwürdigung aller Andersdenkenden und das Verdrehen von Tatsachen. Wie bei de Inquisition haben nur sie recht. Wenn das so weiter geht werden in ein paar Monaten dann sicher die Space-Anhänger mit Fackeln durch die Straßen ziehen und die noch nicht bekehrten auf den Scheiterhaufen schleppen ....

5.7.2015: Fünf Tage durch die Hölle der Cross-Plattformentwicklung

Am vorletzten Samstag bekam ich meine Bauteile für die Wetterstation und nach einigen Versuchen ging ich an die Entwicklung der Anwendung. Was folgte waren 5 Tage in der Cross-Plattform Hölle. Doch für alle die das Projekt nicht kennen hier nochmal die Daten:

Es soll eine autonome Wetterstation sein, die regelmäßig Sensordaten abfragt und lokal in einer Datei ablegt, aber auch regelmäßig eine Seite in meiner Webseite aktualisiert. Das ist z.B. die Seite für heute. Das Projekt ist also nicht nur gedacht als reines Sensorabfragen und Aufbereiten auf dem PC - die Seiten werden von der Wetterstation erzeugt und derzeit alle 300 s aktualisiert.

Tag 1

Angesichts dessen, das es für die Bauteile von Tinkerforge Bindings für Delphi/Lazarus gibt, war die Entscheidung für die Programmiersprache schnell gefallen. Delphi "spreche" ich seit 15 Jahren, Pascal seit fast 30. Lazarus gibt es als Compiler auch für den Raspberry. Der Weg erschien recht klar - erst mal die Anwendung in Delphi entwickeln, zumal ich den Lazarus Debugger als sehr absturzgefährdet in Erinnerung habe, dann auf Lazarus übertragen - hier sind Anpassungen nötig, vor allem weil Lazarus keine eingebaute FTP-Bibliothek hat und die dazugekommene von Synapse andere Befehle haben.

Das Delphi Projekt war in einem Tag fertig - es bestand aus einer kleinen visuellen Oberfläche, um die Erfassung zu starten und die Parameter (für grafische Ausgabe, FTP-Zugang, lokale Verzeichnisse und Dateien und die UID für die Messwert-Geber zu programmieren. Der eigentliche Teil, der die Daten gewinnt, war in einer nicht visuellen Unit ausgelagert, denn geplant war eine Konsolenapplikation - ich würde schließlich den Raspberry Pi nur für diesen Zweck einsetzen und dessen einzige beiden USB-Buchsen sind schön durch Wlan-Adapter und den Brick mit den Bricklets blockiert.

Diese letztere wollte ich in Lazarus wiederverwenden, nur eben in einer Konsolenanwendung. Die Startparameter stehen in einer Einstellungsdatei, die beim Start gelesen wird - Sie ändern sich ja kaum noch, wenn das Projekt mal läuft.

Tag 2:

Nun stand die Portierung auf Lazarus an, aber noch auf dem Windows PC. Da tauchten die ersten Probleme auf. Neben einigen Problemen der FTP-Anwendung die falsche Dateinamen übermittelte, habe ich die meiste Zeit mit dem Timer mich rumgeärgert. Der Timer ist eigentlich eine nicht visuelle Standard Komponente. Er ruft eine Prozedur periodisch auf. Dass Timer auch unter Windows ihre einschränken haben, weiß ich seit ich sie vor 14 Jahren erstmals nutzte - sie taugen nicht für die Messungen von Zeilen die kleiner als 1/18 s sind. Aber für mein Intervall von 1 s sollten sie keine Probleme aufwerfen - nur konnte ich keinen Timer in Lazarus starten wenn ich als Eigentümer "Nil" für nichts angab. Bei Delphi ging dies problemlos. Der Eigentümer muss aber eine Komponente sein,. Also ging ich einen anderen Weg und schrieb eine Abwendung die auf TCustomApplication basiert einem nicht grafischen Objekt, das akzeptierte der Timer auch bei Lazarus als Eigentümer und dann lief das Programm - doch bis dahin war Tag 2 vorbei.

Tag 3:

Nun ging es an die Übersetzung in Lazarus. Erneut gab es Änderungen, vor allem weil ein Standardpackage für PNG Dateien sich nicht beim Raspberry installieren konnte, schließlich band ich die Unit für PNG Dateien die ich als einzige brauchte manuell ein. Erneut gab es das Timerproblem. Egal was ich machte, er startete nicht. Schließlich versuchte ich andere Möglichkeiten. Anstatt einen Timer zu bemühen machte ich in dem Hauptprogramm eine Endlosschleife mit "Sleep", doch das war zu ungenau. Auf 10 s eingestellt zeigten die Protokollausgaben einen Aufruf nach mal 3, mal 5 und manchmal 7 s an - nur nicht nach 10 s. Also machte ich nach einigen Versuchern eine endlosschleife in der Form

Das erzeugt 100% Prozessorlast, bei Sleep waren es noch 10%. Aber es funktioniert. Dank der Langsamkeit des Raspberrys brauchet ich aber einen Tag für die Änderungen. Es reichte noch die Konsolenanwendung in den Autostart zu installieren. Langsam genug gings, denn Lazarus auf dem raspberry Pi läuft gefühlt langsamer als Turbo Pascal unter CP/M. Beim Kompilieren sowieso und beim Eintippen erscheint auch manchmal der Tastendruck erst nach 1-2 Sekunden.

Tag 4:

Während die Konsolenanwendung unter grafischer Oberfläche läuft tut sie es beim Autostart nach dem Booten nicht. Nach dem Umschalten auf den Start nur zur Shell ist klar warum - sie bemängelt das sie nicht den X-Server kontaktieren kann. Ich verwende zwar keine grafische Oberfläche aber die Graphic Unit weil diese das TBitmap Objekt enthält auf dem ich die Grafiken zeichne - ohne das geht es also nicht.  Es nützt dann auch nichts das nach dem Starten der X-Server startet. Zwei Tage später dämmerte mir das ich mir die folgenden zwei tage Arbeit hätte sparen können, wenn ich es dann gleich im LXDR Startmenü installiert hätte.

Also zurück zum Anfang. Wenn ich nicht ohne X-Server auskomme, dann kann ich aus der Not eine Tugend machen. Ich schrieb eine grafische Anwendung - erst mal ein Lazarusklon der Delphi Anwendung, also mit Einstellungsmöglichkeiten. Dann überlegte ich mir auch ob ich nicht gleich die Charts nehmen sollte die Bestandteil von Lazarus sind. Deren Bilder sehen viel besser aus. Ich muss mich nicht um Achsenskalierungen kümmern etc. Zudem traute ich nun nicht mehr dem Timer - ich hatte bisher die Zeit nicht als Datenfeld gespeichert, sondern den Index aus der aktuellen Zeit abgeleitet - kein Problem wenn er eindeutig ist, doch nach dem Schwanken der Zeit bei Sleep mir doch zu riskant. Zudem entfallen so auch Werte die nicht gesetzt waren und die ich bisher kaschieren musste bei den Diagrammen (kamen bei Tests vor wenn der Computer in den Ruhezustand lief oder der Brick den Computer wechselte).

Nach einem halben Tag war alles umgeschrieben und Tests über Stunden zeigten auch das es unter Windows stabil war, das war vorher meine Sorge. Als ich am Band das ganze neu kompilieren wollte - diesmal weil der Raspberry Pi zu langsam ist auf dem Modell 2, gab es schon beim Laden haufenweise Fehler. Der dort installierte Compiler der Version 0,935 kann mit den Einstellungen der Version 1.4 unter Windows nichts anfangen. Ich beschloss die neuste Version zu installieren. Die gibt es aber nicht als Paket, die muss man manuell aus den Quellen kompilieren. Inzwischen hatte ich bei über 30 Grad Außentemperatur keine Lust mehr hin und her zu laufen und auf dem Raspberry Pi SSH aktiviert und einen VNC-Server installiert. Damit ging der Zugriff mit Putty, die Datenübertragungen mit Winscp und ein Remote desktopzugriff. So konnte ich neben dem Erstellen des Lazarus Compilers noch anders tun.

Danach herrschte Ernüchterung: Die Version 1.5 (also sogar noch um eine Version höher als die unter Windows) lud die Quelltexte, kompilierte, beim Start gab es aber eine Schutzverletzung die auf das Chart zurückzuführen war. Damit reicht es es mir für heute.

Tag 5:

Also nochmals umschrieben, diesmal nun über Remote Desktop auf dem Pi2. Da bemerke ich rasch, dass alle Tasten über Alt-Gr nicht gehen. wer programmiert weiß: das betrifft die geschweiften und eckigen Klammern. Häufig verwendet für Kommentare und Feldkennzeichen. Also direkt an den Pi2 - dort gibt es dasselbe Problem. Es liegt definitiv am Compiler, denn in einem Texteditor kann man die Zeichen eingeben und es ist eine deutsche Tastaturbelegung, sonst hätte ich ja auf die Tasten ausweichen können wo sie im englischen Layout liegen. Nach etwas Arbeit ist der Code um die Charts bereinigt und läuft - zur Sicherheit läuft nun der Brick über Nacht mit dem Raspi 2 ,denn ich will sehen ob er wirklich funktioniert.

Tag 6:

Erster Blick morgens auf die Webseite - neuer Eintrag für den 5.7. wird angezeigt. Ein Klick - und tatsächlich. Der Brick läuft noch. Man sieht den Sonnenuntergang und Aufgang an der Helligkeit, im Laufe des Tages erreicht sie einen Maximalwert und nimmt wieder ab, genauso wie die Luftfeuchtigkeit. Sie lag mal bei knapp 60% und ist nun bei 24 %. Also die Exe auf den Raspi 1 kopieren - der stürzt sofort ab. Ob es über den Zwischenweg des Abspeichern unter einem Windows PC lag? Das muss ich noch klären, eigentlich müsste doch eine Binärdatei auch beim alten Raspi funktionieren. Also nochmals Quelltexte aufspielen, Eigenschaften löschen die es im alten Compiler bei Editbuttons nicht gibt  und kompilieren - noch ein Fehler weil der Raspi 1 keine deutsche Oberfläche hat, und das Komma als Zahlentrenner bei den schon erstellten Daten nicht akzeptiert - doch dann gehts. Und so läuft er seit heute morgen, die erste Hälfte des Tags bis 8 Uhr hat der Raspi 2 protokolliert.

Ärgerlich ist, das kein Remote Desktop für den Raspi 1 funktioniert, auch Putty und WinSCP reißen oft ab. Ich vermute das liegt an dem Mini-Wlan Stick, aber mein größerer würde die zweite USB-buchs für die Bricks blockieren.

Tage 7 - ∞

Wie geht's weiter? Die Wetterstation ist auch als Detektor zu nutzen. Dreimal ging nachts der Druck auf enorm hohe Werte von 1173 mbar hoch - gleichzeitig stieg die gemessene Luftfeuchtigkeit an. Ich vermute meine Katzen haben untersucht was da rumbaumelt. Es leuchtet schließlich eine blaue LED. Ich habe noch morgens am sechsten tag eine Glättungsfunktion eingebaut, sonst gehen die normalen Druckschwankungen z.B. ganz unter. Die täglichen Grafiken sind nur der Anfang. Interessant ist natürlich eine Langzeitauswertung, also wie verändern sich Temperaturen, Belichtungsbedingungen etc. über ein Jahr oder mehrere Jahre. Doch das werde ich sicher nicht auf dem Raspberry erledigen. Dazu muss ich nur die erzeugten CSV-Dateien herunterladen.

Aber ein paar Dinge kann ich noch im Raspi-Projekt veränderten. Zuerst ist mal ein Temperatursensor bestellt. Ich habe mich für den teureren IR-Sensor entschieden wenn auch primär weil die 0,5 Grrad des ersten mir zu grob waren. Der kann neben der Luft- auch die Temperatur eines Objektes messen, das wäre bei mir auf dem Balkon der Boden oder die Hauswand.

Das Barometer muss noch kalibriert werden. Der Brickviewer zeit eine Höhe von 460 m an und der Aufdruck ist für ein Hoch das wir haben auch zu niedrig. An dem Parsen der HTML-Dateien kann man noch ein Paar Gedanken verschwenden auch ich denke ich werde die Ausgabe noch um eine Tagestatistik ergänzten wie detektierter Sonnenaufgang und Untergang, maximaler, minimaler Druck Temperatur und Luftfruchte und Durchschnittswerte. Das muss dann auch wieder der Pi erledigen.

Auch die Erstellungskette will ich nochmal überdenken. Ich habe mir mal CodeTyphon installiert, das ist eine Crossplattform Entwicklungsumgebung. Die Firma macht nicht viel Wind um das verschenkte Produkt: Dokumentation und Hilfe ist vor dem Kauf gleich Null. Das es nützlich sein könnte habe ich auch nur durch einen Foreneintrag gesehen. Es basiert auf Lazarus mit einigen Erweiterungen. Damit könnte ich unter Windows direkt Arm Code für den Pi erzeugen.


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