Reverse-Engineering the TT34 Balloon Sensor

The TT34 is an envelope temperature sensor for hot air balloons, and has been around for at least 15 years, so many people own one. It was intended to be used together with the (now discontinued) Flytec 3040 Vario:

The Flytec TT34 temperature transponder

I got curious if one could receive the sensor values from the TT34 with other hardware, maybe a small microcontroller with a suitable receiver for the 433Mhz band (or 418Mhz for USA). So I had a look at the transmission and protocol messages sent by the TT34. For a start, I disassembled the TT34 and the Flytec 3040 and had a look at the electronics.

A particular TT34 and an 3040 are “paired” with a serial number, so any 3040 will receive data only from it’s paired counterpart. The serial is printed on the case, in my case it is a 4-digit number (5850 or 0x16DA hex).


The TT34 has an AM-RT4 transmitter module and the Flytec 3040 has a Philips UAA3201T receiver. Both are for AM (amplitude modulation) – the RT-4’s “data input” pin is really a “transmitter on/off” pin. So the transmission method is really a glorified morse code – the receiver manual describes it as “AM Return-to-Zero (RZ) Amplitude Shift Keying (ASK) modulation”. So – step1: record the signal:

Transmission signal

I recorded the transmission with an old scanner radio to a wav file – it looks like so in Audacity:

TT34 signal after AM reception

This is how it sounds:

There’s clearly a bit pattern maybe 5 or 6 bytes long, but decoding that looks challenging. So I opened the TT34 and connected a logic analyzer to the data pin of the transmitter chip – much clearer picture:

TT34 transmit signal before RF module

Timing and packet structure

With a bit of staring at the display and playing with decoding parameters it became clear:

  • The duration of the bit pattern is 1mS.
  • The overall transmission length is about 60 bits or so.
  • The signal can be decoded as an asynchronous bit stream, 8bits, 1 stop bit, no parity (so total 10 bits/character) which makes the message 6 bytes long – this fits with the 60 or so bits mentioned above.
  • The RS232 decoder of my LogicPort Analyzer can decode the message fine when setting the bitrate to 1000bps (not 1200bps!), so it looks like an async transmission with a non-standard bitrate.
  • There is a fixed pattern at the beginning (0x55) and varying bytes thereafter.
  • The first two bytes correspond to my serial number (0x16DA)
  • The two following bytes are the temperature encoded as two decimal numbers – the value in the picture (63h 02h) is displayed as 26.3° on the Flytec 3040.
  • there is a trailing byte of varying content. I assumed it might be a checksum to guard against transmission errors, but it is not – none of the 8bit checksum algorithm in the Python crccheck package revealed any clues.
  • After studying the manual I noticed that the TT34 can report a broken sensor, and that fact is displayed by a special symbol in the temperature display field. I disconnected and reconnected the sensor and observed how the trace changes: it turns out that a broken sensor toggles bit 0x04 in the last byte of the transmission – if it is set, this indicates a broken sensor. The other fields have a known purpose, so the last byte is some flag field.
  • I was unable to guess the meaning of the remaining bits in the last byte – they do change between transmissions.

I did try to decode the TT34’s transmission with a SX1278 chip operating in the “OOK” (on-off-keying) mode, but was unable to detect or decode any transmission so far – so, as the say: “more research is needed..”.

Decoding the radio transmission

I recently found an interesting tool to reverse-engineer digital radio transmissions: Universal Radio Hacker (urh) and decided to give the RF side a spin with my HackRF software-defined radio while exploring urh.

Investigate the radio spectrum

The Spectrum analyzer view makes it easy to detect the radio transmissions:

Record the transmission

we record at 2M samples/second and capture two transmissions:

When done, close the record signal window and we’re off to interpretation:

Interpretation view

urh has a phenomenal autodetection code – it recognizes bit timing really well and tries to decode the bit stream.

Analysis view

The analysis enables us to annotate the bits and their meanings. Luckily the results are identical to the logic analyzer view!

The urh project and sample file can be found on github.


With the findings above it should be possible to receive and decode the TT34’s transmissions, match a given serial number, and detect a broken sensor.

If anyone in the know has more details on the TT34 protocol: drop me a note and I will update this post.

Update: a TT34 decoder does exist

It turns out the formidable Oliver Wipfli has written such a decoder. The code can be found here.

Field report: Windy at the Gordon Bennet Cup

Kolja Packard was member of the ground support team for the Belgian, Spanish and US teams at the Gordon-Bennet-Cup 2019 – the most prestigious gas ballon race in the world. He used – among other tools – and in particular traj – the trajectory plugin – to aid pilots with weather information and tactical advice.

Kolja writes:

Experiences with the Windy Trajectory Plugin

Hello Michael,

find below a summary of the experiences and impression of the trajectory plugin for I used it in the – rather particular – setting of planning and supporting a long-distance (and long time!) race with gas balloons during this year’s Gordon Bennet race starting from Montbéliard.

Usually with gas balloon rides a duration of 6-12 hours is of interest. But in competitions, flights lasting several days are possible. With this year’s Gordon Bennet Race – which is about maximum-distance-flown, due to the overall weather situation, flight times of up to 72 hours and much more were possible.

For the average – and much more common – hot air balloon pilots flights of around 1-3 hours in the morning and in the evening are more typical.

We looked into possible tracks while supporting three teams (BEL1, ESP1 and USA1) and those were quite long-lasting flights. Our strategy – and therefore the search for relevant information – looked at 80 hours onward from the start even before takeoff!

By using windy’s traj plugin, we gained the following advantages:

1. trajectories based on additional weather models – only windy could provide data for ECMWF and IconEU beyond the GFS-based HYSPLIT and the GFS-derived NEMS model by Meteoblue

2. it was straightforward to model long duration trajectories with changing altitudes and represent those in a single screen view

ad 1) especially during diverging forecasts there is value in having data from different models at hand, so as to get at least a rough tendency of weather development

ad 2) example below: multilevel trajectory produced 22 hours before takeoff (actually this are 4 partial trajectories following each other with different altitudes assembled into a single view):

Detail view of how partial trajectories are assembled:

See below for details on tagging and coloring trajectories, for instance by model

For developing such a “multi-level trajectory”, you start with a single parameter set (height, model etc) and just start another trajectory at a certain point with a different set of parameters.

One can add aribtrary trajectories at arbitrary points of an underlying trajectory so as to estimate the impact of altitude changes at different points into the flight given a location, and develop a strategy based on the result.

Using all available models, views become confusing quickly. Here we show a forecast based on a single model while varying the altitude. Takeoff locations and times are subject to pilot’s discretion – and mistakes.
Three models displayed simulataneously.

I did not use the ascent/descent simulation provided by the traj plugin – trajectories at a given altitude for extended periods of time were more relevant to us.

Further into the race, we were faced with short-term decisions beyond the long-range planning. Here some features of the traj plugin proved useful.

For instance, for short-term forecasts the age of a forecast is relevant – it makes a difference if it is a new iteration or several hours old.

There was no clear “winner” in terms of models as for accuracy – generally the ECMWF model provides reasonable results, on short-term IconEU also got some best suiting forcasts to actual conditions.

Adding airspace information to trajectory tracks is very helpful (even if available as a separate windy plugin).

Here the goal was to steer the BEL1 team around, or within the airspaces encountered, only at certain altitudes. The blue trajectories correspond to an hour of flight at current altitude, based on three models. Thereafter, a simulation at different altitudes based upon the – then – most current model.

The following features proved useful:

– the resulting trajectories can be overlaid with all data provided by windy. By clicking on a point in a trajectory, forecast time is automatically adjusted, as is the altitude. That makes it straightforward to estimate conditions at a certain point into the flight.

– map display in windy is very flexible, for instance scaling and import of non-standard geodata.

– exporting trajectory data from the plugin is very useful.

During intense use of traj, I’ve encountered some restrictions and issues, and I have some suggestions for further development.

I encountered two issues during 5 days of use – which I generally would rate as “explainable”:

1. Looking ahead over 40 hours, I ran into a problem with IconEU – forecasts got stuck some 3 days into the future – the site got stuck and required a restart in a new browser window.

This did not occur with other models, and also did not reoccur during later phases of the flight when we only looked at shorter time spans.

2. On and off the trajectory computation appears delayed as – according to a message on-screen – there was no connection to the server. Certainly this is attributable to our makeshift Internet hookup for our “Control Center”. Nice to see that the job did not fail but rather eventually continue once network connectivity was reestablished. And this is only was an issue because it took quite some time to compute the trajectories – more below.

The only real downside to the traj plugin – and then only compared to some commercial alternatives and when computing long-lasting flights, and therefore not neccessarily felt by many users is its low speed of computation.

In particular, when using multiple models over an extended period of time, the job might take 10 minutes or more. But if I understand it right, the traj plugin just queries wind info on the current location and time from windy and trajectory computation happens locally, not on the server.

Given 3 models, maybe 3-4 altitude levels and – for example -40 hours lookahead, that’s 480 data snapshots taken by the client, and that takes its time. And I had to forecast 80 hours in different variants… For a free service, that is something one can live with – especially since most users are likely interested in much shorter forecast timespans.

Here is some feedback on usability and suggestions for further development based on my experience gained during this race:

1. Setting the starting time of a trajectory happens in local time. We used UTC throughout also with other tools, and that is asking for mistakes (by the user). Also because we were busy around the clock and have produced countless trajectories. To avoid simple mistakes it would have proven useful to see or adjust trajectory starting time in UTC in the settings menu (given a completed trajectory, UTC times can be had by clicking on points of the curve).

2. The capability to simulate many trajectories (different altitudes, times, models, locations) and have them displayed in the same screen is a major advantage of the traj plugin. One can work out an optimal path pretty well (best takeoff time and location, altitude, change of altitude etc). Along the way you’d compute quite a few trajectories, most of which you’d throw away. Others you will like to keep. It’d be super useful to selectively discard trajectories without erasing them all. I have not discovered such a function.

3. Clicking on a point in a trajectory displays information on the computaion settings of the trajectory and the chosen point. This also selects the windy current time and location for a following trajectory calculation-very useful!

A suggestion: total trajectory duration is displayed in minutes (e.g. 2400 minutes in our case) other than in hours:minutes as selected in the Settings display. Display in hh:mm format would be more useful.

4. When calculating three altitudes with three models, this will result in 9 trajectories displayed – this becomes confusing pretty quickly. Two suggestions:

4.a) trajectories of identical altitudes by different models have the same color. Marking trajectories additionaly by model would be very useful. Now, only when clicking the curve you see the underlying information.

4.b) For better representation I chose higher-contrast colors than default. That is currently only possible by pressure altitude which is somewhat cumbersome. Adding altitudes in meters/feet would be a plus:

5. Not sure if it is possible to read out the last update time for a given model in windy with a plugin. But it would be super useful to display this to rate its relative value. One can find that information, but it takes several clicks and not in direct comparison of the trhee models. It would be great to see this for instance in the Settings menu where you select models.

Wrapping up: I certainly did not use all features of windy or the traj plugin for that matter, since I encountered this only recently (and through your blog, by the way). But then in the days before and during the race I guess I used it for 12 hours a day and I am very impressed by its potential!

ps: as I was writing this up, I tried to access the plugin. But it seems it is currently unavailable, as are other plugins. Never happened before!

Attached below find some recordings – I hope you find it useful!

best regards


Erfahrungsbericht: Einsatz von Windy beim Gordon-Bennet-Cup

Kolja Packard war im Rahmen des Gordon-Bennet-Cup 2019 beim Bodenteam für Mannschaften aus Belgien, Spanien und USA. Er hat – und insbesonders traj, das Trajectory-Plugin – verwendet, um die Piloten taktisch zu unterstützen. Kolja schreibt mir:

Eindrücke zum TrajektorienPlugin für Windy

Hallo Michael,

im Folgenden findest du eine Zusammenfassung über meine Erfahrungen und Eindrücke zum Trajektorien-Plugin für, die ich im ganz speziellen Anwendungsfall für die Planung und Betreuung von Langzeit- bzw. Distanzfahrten von Gasballonen im Rahmen des diesjährigen Gordon Bennett Rennens in Montbéliard machen konnte.

Für eine gewöhnliche Gasballonfahrt sind Fahrtzeiten von 6 – 12 Stunden von Interesse. Im speziellen Falle von Leistungs- oder Wettbewerbsfahren sind auch Fahrtzeiten von mehreren Tagen möglich. Im ganz speziellen Falle des diesjährigen Gordon Bennett Rennens (eigentlich ja über die maximale Distanz, was aber natürlich auch eine lange Fahrzeit impliziert) kam es bedingt durch die Wetterlage zu Fahrten von deutlich über 72 Stunden, sogar bis zu 90 Stunden.

Ich gehe davon aus, dass bei der zahlenmäßig weit stärker vertretenen Fraktion der Heißluftballöner eher kurze Fahrten im Bereich 1-3 Stunden in einem definierten Zeitfenster in der Früh oder am Abend interessant sind.

Die möglichen Fahrtverläufe, die uns bei der Unterstützung dreier Teams (BEL1, ESP1 und USA1) bei diesem Rennen interessierten, waren also von beträchtlicher Dauer und unsere Strategie und somit die gesuchten Informationen beliefen sich schon vor dem Start auf über 80 Stunden!

Bei diesen zeitlich weiträumigen Strategieentwicklungen vor dem Start waren bereits zwei deutliche Informations- Hinzugewinne durch das Plugin ersichtlich:

1. Trajektorien basierend auf zusätzliche Wettermodellen möglich (NEMS mit Meteoblue, GFS mit windy+plugin und HYSPLIT und zusätzlich ECMWF und IconEU ausschließlich mit windy+plugin)

2. Strategien mit wechselnden Fahrthöhen waren ohne größeren Aufwand zu berechnen und auch direkt zusammen darstellbar

Zu 1.: Wie auch sonst, wenn man bei nicht eindeutigen Vorhersagelagen gerne mehrere Modelle zu Rate zieht, um zumindest über die grobe Tendenz einer Entwicklung eine zuverlässigere Auskunft zu erhalten, war es auch bei der Trajektorienberechnung ein Gewinn weitere Wettermodelle zu Rate ziehen zu können.

Zu 2.: Hier ein Beispiel zu Multilevel-Trajektorie etwa 22 Stunden vor dem Start gerechnet (eigentlich 4 Teiltrajektorien mit unterschiedlichen Höhen direkt aneinander gefügt):

Das Aneinanderfügen von Trajektorien im Detail:

(Zur Farbgebung und Kennzeichnung der Trajekorien, z.B. nach zu Grunde liegendem Modell, Weiteres unten)

Beim Rechnen solcher “Multilevel-Strategien” bzw. “Multilevel-Trajektoerien” rechnet man einfach eine Trajektorie und fügt danach eine weitere mit abweichenden Parametern an usw.

Dabei ist es sehr nützlich an einer vorhandenen Trajektorie eine Vielzahl neuer Trajektorien ansetzen zu können, und zwar nicht nur am Ende sondern an jedem beliebigen Punkt, und somit die Auswirkung von möglichen Höhenänderungen zu jedem Zeitpunkt der Fahrt (am vorausberechneten Ort) abschätzen und somit eine mögliche Strategie entwickeln zu können.

(Berechnet man alle drei Modelle, wird es schnell unübersichtlich. Hier nur ein Modell genutzt mit verschiedenen Höhen. Farben kontrastreicher gewählt. Ausgangspunkte und dazugehörige Startzeiten von Trajektorien sind ausschließlich in der Kontrolle und somit auch Fehleranfälligkeit des Benutzers.)

(drei Modelle parallel berechnet)

Da es für unsere Vorausberechnungen von vielen Stunden nicht relevant war, habe ich die Funktion des Steigens/Fallens, die das Plugin ja schon mitbringt, nicht verwendet. Uns interessierte was in einer bestimmten Höhe über längere Zeit zu erwarten war.

Je weiter wir in das Rennen kamen und sich somit parallel zur längerfristigen Vorausplanen auch kurzfristige Fragestellungen ergaben, desto mehr zeigten sich noch weitere Funktionen des Plugins als nützlich.
Für kurzfristige Vorhersagen kann es z.B. eine Rolle spielen, ob ein Wettermodell auf dessen Basis eine Trajektorie berechnet wird, schon viele Stunden alt ist oder eben kürzlich neu zur Verfügung gestellt wurde.  Die Genauigkeit der Vorhersagen der verschiedenen Modelle war im Übrigen nicht eindeutig bei einem Modell größer. Tendentiell erschienen die Trajektorien mit dem ECMWF-Modell eine gute Vorhersage zu erzielen. Im Kurzfristigen Bereich war bei größerer Aktualität das IconEU Modells auch mal näher an den eintretenden Verhältnissen gelegen.

Im Verlauf der Langfahrt war das Einblenden der Lufträume (im Plugin integriert, sonst auch über separates Plugin möglich) eine große Hilfe.

(Ziel: BEL1 am Luftraum vorbei, bzw. im Luftraum nur mit bestimmten Höhen, zu dirigieren. Die blauen Trajektorien entsprachen einer Stunde vom Berechnungszeitpunkt in der aktuellen Fahrthöhe gerechnet mit drei Modellen. Als Kontrolle dazu andere Höhen. Danach mögliche Optionen mit dem zu dem Zeitpunkt aktuellsten Wettermodell.) 

Folgende weitere Punkte sind positiv aufgefallen:
– Die Trajektorien können auf Windy mit allen von Windy zur Verfügung gestellten Daten überlagert dargestellt werden. Durch klicken auf einen Punkt der Trajektorie springt die Darstellung automatisch zu dem entsprechenden Zeitpunkt und, z.B. bei der Darstellung des Windes, auch in die entsprechende Höhe. So ist sehr gut abzuschätzen, welche Verhältnisse zu welchem Zeitpunkt der Fahrt herrschen.
– Die Handhabung der Kartendarstellung ist in Windy sehr komfortabel. Skalierbarkeit, Import anderer Geodaten,…
– Das Exportieren der Trajektorien direkt aus dem Plugin ist ebenfalls ein plus.

Natürlich habe ich durch die intensive Nutzung auch die ein oder andere Einschränkung oder ein Problem erfahren und kann mir daher auch ganz konkrete Weiterentwicklungsmöglichkeiten vorstellen.

Zwei Probleme sind im Laufe der 5 Tage aufgetreten, die ich aber beide als “erklärbar” einstufe.
1. Bei einer Berechnung von über 40 Stunden hatte ich einmal das Problem mit dem Modell IconEU, dass eine Trajektorienberechnung immer am selben Zeitpunkt (etwa 3 Tage in der Zukunft) hängen blieb und die Seite dadurch nicht mehr reagierte und ein neues Browserfenster gestartet werden musste. Mit den anderen Modellen tauchte das Problem nicht auf. Es ist ebenfalls zu einem späteren Zeitpunkt nicht mehr aufgetaucht, als nur noch kürzere Zeitspannen gerechnet wurden.
2. Das ein oder andere Mal war die Trajektorienberechnung verzögert, da, laut windy-Bildschirmmeldung, keine Verbindung zum Server bestand. Dies ist aber mit Sicherheit dem Internetanschluss in unserem provisorischen “ControlCenter” geschuldet gewesen. Positiv war hier, dass das Plugin dadurch nicht in einen Fehler lief sondern die Berechnung dann weiterführte, wenn die Verbindung wieder möglich war. Zu diesem Effekt kam es aber natürlich auch erst dadurch, dass das Berechnen der Trajektorien verhältnismäßig lang dauerte. Näheres dazu im Folgenden.

Der einzige für den Nutzer negative Punkt in der Nutzung des Plugins – und dies aber auch nur im Vergleich zu anderen teils kostenpflichtigen Angeboten und speziell bei Berechnungen von Trajektorien sehr langer Zeitdauer – ist die verhältnismäßig langsame Berechnung der Trajektorien.
Zur Berechnung von Trajektorien, vor allem mit mehreren Modellen gleichzeitig, um auch den Vergleich zu haben, und über eine längere Zeitdauer, benötigt  man dann schon mal 10 Minuten und mehr. Dies aber ebenso nachvollziehbar, da ich annehme, dass das Plugin einfach die jeweiligen Vorhersagezustände abruft, um die Trajektorie zu errechnen und die Berechnung ja nicht auf dem Server geschieht. Bei 3 Modellen, mit 3-4 Höhenleveln und z.B. 40 Stunden Dauer sind das dann ganz schnell mal 480 Istaufnahmen, die in Windy aufgerufen werden! Dies kommt natürlich vor allem beim Rechnen von langen Zeitdauern zum tragen. Und für die ganze Strategie musste ich 80 Stunden mit verschiedensten Varianten berechnen…
Für ein Gratistool aber immer noch ein verschmerzbarer Nachteil, der für die meisten Nutzer, die viel kürzerer Trajektorien interessieren dürfte, nicht so erheblich sein wird.

Im folgenden noch ein paar Feedbackpunkte über Fehleranfälligkeit (in der Benutzung) und Anregungen zu möglichen Weiterentwicklungen auf Grund der erfahrenen Einschränkungen:
1. Das Einstellen der Startzeit einer Trajektorie geschieht durch den Zeitregler in Windy. Diese Zeit ist “local”. Da wir generell und auch mit anderen Tools mit UTC gearbeitet haben, gab es hier immer potential sich zu vertun. Wir waren natürlich rund um die Uhr damit beschäftigt und haben unzählige Trajektorien gerechnet. Zum vermeiden einfacher Fehler wäre es aber nützlich gewesen, wenn die Startzeit der Trajektorie in UTC zumindest im Settings-Menü ersichtlich oder sogar einstellbar wäre. (Bei der fertigen Trajektorie lässt sich der Zeitpunkt dann einfach in UTC ablesen durch anklicken der Trajektorie).
2. Der Vorteil dieses Plugins liegt vor allem darin, dass man viele Trajektorien (unterschiedliche Höhen, Modelle, Startzeiten, Startorte) nacheinander berechnen und in der gleichen Oberfläche anzeigen lassen kann. So kann man ein gewünschtes Ergebnis sehr gut herausarbeiten (bester Startzeitpunkt oder -ort, Fahrthöhe, Fahrthöhenwechsel…). Auf dem Weg dahin berechnet man in der Regel einiges an Trajektorien, die man gerne wieder verwerfen möchte, andere wiederum unbedingt behalten. Den größten Zusatznutzen hätte ich darin empfunden, wenn man einzelne Trajektorien wieder löschen könnte ohne alles zu löschen. Eine solche Funkion habe ich zumindest nicht gefunden.
3. Wählt man einen Punkt auf einer Trajektorie aus, bekommt man Informationen zur Berechnung der Trajektorie und Zeitpunkt des Punktes angezeigt. Außerdem kann man den gewählten Punkt auf der Trajektorie direkt als Ausgangspunkt für weitere Berechnungen nutzen. Sehr nützlich! Kleine Verbesserung der Nutzbarkeit: Die Gesamtdauer der Trajektorie wird hier in Minuten angezeigt, also z.B. 2400 Minuten, statt in Stunden:Minuten, wie man sie vorher auch in “Settings” ausgewählt hat. Die Darstellung in hh:mm wäre praktischer.
4. Berechnet man z.B. drei verschiedene Höhen mit allen drei Modellen erhält man 9 Trajektorien. Da wird es schnell unübersichtlich. Hierzu zwei Anregungen:
4.a) Da die Trajektorien einer gleichen Höhe verschiedener Modelle immer die gleiche Farbe haben wäre eine zusätzliche Kenntlichmachung der Trajektorie nach zu Grunde liegendem Modell nützlich. (Wird die Trajektorie angeklickt, erhält man die Information dieser einen Trajektorie. Das ist aber wenig praktikabel.)

4.b) Zur besseren Unterscheidung der verschiedenen Höhen habe ich jeweils kontrastreichere Farben als die Vorauswahl gewählt. Dies ist nur nach Druckhöhen im Bereich “settings->colours” möglich, was es etwas umständlich gemacht hat. Nach Höhen in Metern wäre ebenfalls wünschenswert. Evtl. wäre direkt bei der Auswahl der “levels” die Farbauswahl praktisch.

5. Ich weiß nicht, ob es einen Weg gibt die letzte Aktualisierung eines Wettermodells aus Windy herauszulesen und mit einem  Plugin anzuzeigen. Das Wissen um den letzten Aktualisierungsstand ist zumindest sehr hilfreich um den Wert eines genutzten Modells im Vergleich zu einem anderen genauer einzuschätzen. In Windy lässt sich die Info herausfinden, nur eben mit mehreren Klicks verbunden und nicht in direkter Gegenüberstellung. Eine solche Info z.B. dort, wo man die Modelle auswählt in “Settings” wäre grandios.

Abschließend sei zu bemerken, dass ich bei Weitem nicht alle Möglichkeiten von Windy und in dem Zusammenhang auch von dem Plugin einsetzen konnte, weil ich erst sehr kurz vor dem Rennen mit dem Trajektorienplugin (übrigens über deinen Blog) in Berührung gekommen bin. In den Tagen vor und während dem Rennen habe ich mich aber wohl geschätzte 12 Stunden am Tag damit auseinander gesetzt und bin von dem Potential mehr als beeindruckt!

P.S.: Übrigens, als ich diese Zeilen schrieb wollte ich noch mal auf das Plugin zugreifen. Es war bei Windy aber nicht mehr möglich ein Plugin auszuwählen. Dies kam aber bisher noch nie vor.

Im Anhang noch ein paar “Aufzeichnungen” etc. falls von Nutzen.

Liebe Grüße,