Nochmal 5 Tage durch die Crossplattform-Entwicklung

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

7 thoughts on “Nochmal 5 Tage durch die Crossplattform-Entwicklung

  1. Sehr interessant, aber was ich mich die ganze Zeit frage ist, ob es keinen Compiler gibt, der schon auf dem PC den Code für den enstsprechenden ARM-Prozessor erzeugt. Müsste doch eigentlich… (Ist jedenfalls bei meinen AVR-Controllern so, dass der Assembler bzw. die Compiler auf dem PC auch gleich den entsprechenden AVR-Code erzeugen, der in eine *.hex Datei (wahlweise Intel-HEX oder Motorola S-Record) gespeichert wird. Diese wird dann mit einem speziellen Tool, dem ISP (In System Programmer) auf den Chip übertragen und läuft dort, sofern keine Fehler drin sind. – Andrerseits ist es aber auch völlig unmöglich, einen Compiler auf AVR-Controllern implementieren zu wollen, weil das eben Controller für eingebettete Systeme sind, deren Speicherkapazitäten im Bereich von ein paar Kilobyte(!) liegen.)
    Oder liegt das Problem darin, dass der Raspberry Pi unter Linux läuft und das Programm deshalb darauf neu übersetzt werden muss? – Dann frage ich mich, ob es nicht sinnvoll wäre, auf dem PC eine Linuxpartition einzurichten, und den Compiler anzuweisen, ARM-Code zu erzeugen, der auf dem PC nur innerhalb eines Emulators getestet werden kann?

  2. Hallo Hans,

    Es ist natürlich nicht unmöglich Code für den Arm Prozessor zu erzeugen. Cross-Compiling gibt es wobei ich nur von Lazarus sprechen kann weil es das ist was ich nun untersucht habe. Es gibt einige „How-Tos“ wie man unter Windows crosscompilieren kann. Im wesentlichen laufen sie darauf hinaus die entsprechenden Cross-Compiler herunterzuladen und die ganzen Laufzeitbibliotheken für das System. Mir war es zu umständlich, weil ich wie im artikel beschrieben auch auf dem ARM Fehler entdeckte die es beim Windows System nicht gab.

    Es gibt dann noch das CodeTyphon Studio das auch auf Lazarus basiert. Die haben das automatisiert. Mit dem soll man crosscompilieren können für alle unterstützen Plattformen, aber obwohl ich es wie in der Dokumentation geschrieben die Toolkette durchexerzierte und es dabei keinen Fehler gab startete die Compilierung mit einem Fehler.

    Es gäbe noch einen Raspberry Simulator für Windows, aber auch das schied aus weil ich ja zwei echte zum Testen habe. Ganz trivial ist es nicht, denn das Betriebssystem ist ja auch ein anderes (eine Variante von debian Linux), sodass auch alle Api aufrufe angepasst werden müssen. Ich habe es schon aufgegeben in Texten nicht ASCII-Zeichen zu verwenden bzw. nehme die html-Umsetzung „uuml;“ weil beim hochspielen auf den Pi die Zeichen verloren gehen.

    Den neueren Compiler habe ich unter dem Raspi 1 nicht mehr zum Laufen bekommen. Wie die exe startet er mit einer Execption. Beim 1.4 kann man die Codebasis angeben doch wenn ich acuh auf armV6 zurückstelle und alle möglichen Grafikwidgets durchprobiere bekomme ich keine lauffähige Version für den Raspi 1. So macht nun der Raspi 2 den Job.

    Würde ich ein solches Projekt ernsthaft angehen, dann wäre wohl entweder ein Skriptsprache oder eine mit Bytecodeinterpretation wie Java oder die .net Sprachen die bessere Weg.

  3. Man kann einen Cross Compiler für den Arm unter Linux verwenden. Ist für die die unter Unix/Linux groß geworden sind der bevorzugte Weg. Einen Großteil der Cross Compiler, insbesondere alle gcc basierenden gibt es auch unter Windows, zumindest in der Cygwin Umgebung. Diese Cross Compiler Umgebungen sind aber immer etwas magerer in der Ausstattung wie native Umgebungen.

    Das große Problem beim Cross Compilieren ist nicht der Target Code in C/C /Pascal/Fortran, sondern (nachdem das andere API klar ist) das Build system mit dem der Target Code konfiguriert, angepasst und kompiliert wird. Ein Cross Build system muß immer klar zwischen Host und Target unterscheiden, und ein großer Teil der vorhandenen Software tut das nicht.

    Um diesem Problem Herr zu werden wird heute oft ein virtueller Rechner genommen, auf dem dann das Entwicklungssystem läuft. (z.B. QEMU) Den gibt es dann noch in unterschiedlichen Konfigurationen:
    – Hardware wird komplett emuliert, für die Entwicklung des boots, des Kernels und der Treiber
    – Alles was das Userland braucht wird komplett emuliert, I/O (Platte, Konsole, Netzwerk und ggf. Grafik) dagegen wird an das Hostsystem übergeben. (Unter Windows gibt es dafür die VmWare Treiber.) Wird für das Entwickeln von Userland Software verwendet, und oft auch für das Kompilieren des Kernels oder Treibern dafür, insbesondere wenn es Probleme mit dem Cross Environment gibt, oder wenn die Entwickler kein Cross Environment gewohnt sind.

    Ein Cross Environment zu benutzen ist immer etwas nervig, da man sich um eine ganze Reihe von Problemen kümmern muß, die in einem native Environment nicht vorkommen. Ich habe in den 1990ern ein Cross Environment (C/C ) mit aufgesetzt, und das war viel Arbeit. Wir haben dann zum Schluß sogar die nativen Compiler als Cross Compiler aufgesetzt, um auch die Bibliotheken und Includefiles unter Versionsverwaltung zu bekommen. Ziel war es ein Executable mehrere Jahre später identisch nachbauen zu können. (In kleinen Firmen (unter 15 Entwicklern) legt man sich dazu eine installierte Festplatte in den Tresor oder speichert sich ein VmWare Image dauerhaft ab.)

  4. Ah okay, ich hab’s kapiert. Das eigentliche Problem ist also nicht der Crosscompiler selbst, sondern die Laufzeit-umgebung, die nicht nur durch den Compiler sondern auch von der übrigen, verwendeten Buildsoftware berücksichtigt werden muss.
    Solche Probleme hab ich bei den AVRs in dieser Form ja nicht. Die können dort nur in abgeschwächter Form auftreten, falls ein Controller irgendwelche Hardware nicht anbietet oder die Portpins unterschiedlich belegt sind, an denen bestimmte Perepherie nach aussen geführt ist. Aber in den Fällen muss ich den entsprechenden Sachverhalt schon im zu übersetzenden Programm berücksichtigen, also bei der Entscheidung, auf welchen der inzwischen etwas über 200 unterschiedlichen Controller das Programm laufen soll. Dabei ist es dann aber auch so, dass einem einiges, das Softwaretechnisch zu berücksichtigen ist, durch das Buildsystem abgenommen wird. Bleibt also festzuhalten, dass das mit den Mikrocontrollern doch ’ne andere Welt ist.

  5. Heute morgen hing der Raspi 2 wieder einmal. Putty ging, aber kein Remote Desktop (Verbindung aber leeres Bild). Nach dem Reboot über das Terminal ging dann gar nichts mehr. Nach dreimaligen Versuchen konnte ich die Sch… Micro-SD Karte als Übeltäter ausmachen irgendwie verliert sie den Kontakt obwohl sie noch fest drin sitzt. erst beim dritten Reinschieben findet der Raspi beim Booten sein Filesystem. Wer bei der Raspi Foundation ist auf die hirnrissige Idee gekommen die zuverlässigen und gut sitzenden SD-Karten durch diese fummeligen und fehleranfälligen Mikro-SD Karten zu ersetzen?

    Wenn das so weiter geht, war es das mit dem Projekt. Ich versuche nochmal den raspi 1 zu animieren, der nach meinen versuchen einen neuen Compiler zu installieren Fehler beim alten anzeigt, aber einen weiteren Kleinrechner kaufe ich nicht.

  6. Es gibt mehrere Emulatoren für den Raspberry Pi. ggf. ist einer davon schnell genug, um die Entwicklung für den Pi 1 zu beschleunigen.
    Mit google nach „virtual raspberry pi machine“ suchen gibt Links auf:
    – qemu basierend: http://sourceforge.net/projects/rpiqemuwindows
    – virtual box basierend:

    Habe aber keinen davon ausprobiert, da mir Kodi ausreicht, und das ist fertig. (Der PC, den ich als Arbeitsplatz nutze ist zu langsam um Videos abzuspielen.)

  7. Noch ’ne allgemeine Anmerkung: Und zwar fiel mir auf, dass wenn die Wetterstation das Geschehen draussen aufzeichnen soll, dann fehlt da noch ein wichtiger Teilnehmer, nämlich der Wind. Nun hab ich gerade mal bei Tinkerforge nachgesehen und festgestellt, dass es da derzeit (noch?) keinen Windmesser gibt. Aber eigentlich gehört der mMn doch auch dazu, wobei es dabei 2 Grössen gibt, nämlich Windrichtung und Geschwindigkeit. Aus den „Zeitreihen“ der regelmässigen Messungen lassen sich dann auch Böen heraus filtern, was sicher noch mal eine Softwareaufgabe wäre…

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.