pocitadlo

Author: ibisek

Posted on

Jak nastavit KRT2BT v LK8000, XCSoaru a SkyDémonovi

Spousta lidí se opakovaně ptá, zda lze adaptér KRT2BT použít k odesílání frekvencí přímo z navigačních aplikací LK8000, XCSoar nebo SkyDemon. A odpověď zní Ano, jde to! Zde je tedy popsáno, jaké konfigurační kroky provést, aby vám fungovalo.

Párování přes modrý zub

Tento krok je specifický pro každé konkrétní zařízení. Funguje na PDA se systémem Windows CE nebo telefonech se systémem Android. Dobré je zde upozornit, že zařízení s obrázkem ovoce bude většinou ignorovat všechna zařízení bez specifického Apple ID – tj. včetně našeho krtkomodrozubu.

Obecně se to dělá tak, že zapnete/aktivujete v telefonu/PDA bluetooth a necháte jej vyhledávat modrozubová zařízení ve vašem blízkém okolí. Ta vysílají po zapnutí (včetně KRT2BT) paket, kterým ohlašují svou přítomnost, nicméně pouze za přepokladu, že nejsou v tu chvíli již připojena k jinému telefonu/PDA. Po spárování a připojení se tyto beacony nevysílají a tudíž tato zařízení nejsou vidět(!). Adaptér KRT2BT se při vyhledávání ohlašuje jménem KRT2-BLUETOOTH (nebo KRT2BT) a pro spárování vyžaduje tajný pin 1234.

Před následujícími kroky se tedy ujistěte, že párování proběhlo úspěšně.

Nastavení LK8000

Spusťte LK8000 a ťupněte na (M)enu -> Nastavení -> Nastavení -> Nastavení LK8000 -> Nastavení zařízení. Zde jdou pod kartami A-F vidět již nakonfigurovaná zařízení, přičemž hned po instalaci jsou pod A nastaveny interní snímače / zdroje dat jako GPS a baročidlo (pokud jej tam máte). Zde zvolte nepoužitou kartu (v případě na obrázku níže jsem zvolil C) a ťupněte na volbu Jméno (Name), kde vyberete ‘Dittel KRT2’. Dále pokračujte volbou portu, kde zvolíte již dříve spárovaný krtomodrozub. Na různých telefonech/PDA to může vypadat různě, v tomto případě to bylo BT_SPP:KRT2BLUETOOTH. Určitě na to přijdete ,)

Name..
Port..
Finito!

Zde lze i vidět, že podobně lze připojit i dalčí zařízení, jako například OGN Cube, díky kterému pak lze spatřit okolní provoz ostatních letadel vybavených OGN krabičkami různých výrobců 🙂

Jakmile je toto nastavení hotovo, opusťte menu zpět na náhled mapy. Mělo by dojít k automatickému znovunačtení komunikačních portů a v případě úspěšné detekce rádia se zobrazí hláška, RADIO DETECTED (nebo podobně). Pokud by nedošlo k automatickému resetu portů, je třeba aplikaci restartovat. Jak to přibližně vypadá, vidíte zde:

After app restart
Automatic port restart

Krtek je tedy připojen a je možné jej ovládat z LK8000. V menu se objeví nové volby pro poslání frekvence letiště (uložena v seznamu otočných bodů) a ručního zadání frekvence, přičemž tu je možné nastavit jako aktuální (horní řádek na rádiu) nebo záložní (spodní řádek).

Nastavení XCSoaru

Toto je velmi podobné postupu u LK8000. Ťupnutím na obrazovku se objeví menu, zvolte Konfigurace -> Zařízení, přičemž zde je opět seznam nastavených a prázdných slotů A-F.

Nastavení zařízení
Rádio není připojeno..
.. a teď už jo!

Vyberte si prázdný slot a nastavte spojení tak, jak je na nastíněno na obrázcích nahoře. Dokud nebylo rádio detekováno, je zde zobrazeno ‘No data‘ – znamená to, že spojení buď nefunguje, nebo ještě nedorazil paket, kterým krtek oznamuje svou existenci. Jakmile se spojení povede, zobrazí se zde ‘Connected’.

Po připojení rádia se podobně jako v LKčku v menu objeví nové možnosti jak poslat zvolenou frekvenci do krtka.

Nastavení SkyDémona

Jak použít bezdrátové spojení krtka a SkyDémona najdete na youtubu v těchto videích:

No a to je všechno! 🙂

Samozřejmě nezapomeňte, že ke krtkomodrozubu ještě existuje skvělá aplikace KRT2Bluetooth pro androidí telefony, přes kterou si můžete nastavit frekvence přímo v paměti vašeho krtka. Více se o ní dozvíte tady!

Posted on

Encounters

It doesn’t matter whether you fly a little ultralight, heavy GA airplane or a shiny glider – some weeks it happens rarely, others more often or even every flight depending on your activity. You meet another plane. It might be a pleasant surprise when flying along similar course for a while, circle a 5-meter thermal with a incredibly-long-winged fella or taken aback by a hostile Messerschmitt or a Hurricane which suddenly emerged from the sun disk. In such situations you may wonder who was that guy/gal, what type that airplane was or where the sky waves have taken them after you waved on each other and set sail towards you own adventures. To give you some hints there is a new lovely feature in the logbook’s map which I venture to call “Encounters“!

The blue circle indicates you have met an UFO in this location.

Since mid February you might have already spotted a small blue dots on the map. The blue circles indicate where you might have met someone – another plane that was around a near location and at a similar time to yours (or the one whose flight-recording map you are just reading).

By clicking the blue dot you get an identification (if known to logbook).

There might be gazillions of blue dots meaning you have probably met a contestants in a thermal, a single one when the tug plane was first encountered airborne during the tow or just a few random encounters along the track. Or just none.

The track of the other airplane can be added to the map to view both (or multiple) flights on one screen.

Current thresholds are configured to 500m apart in distance within 10 seconds-long time window. The next (repeated) encounter marker may appear after 20 minutes the earliest – hence if you fly in formation your path shall not be marked by blue little dots all the way. Furthermore, the detection is active for OGN and FLR traffic only as the ICAO beacons were causing too much confusion.

As of this moment the encounters-detection seems to work rather nicely, however, as the lookup is considerably CPU-intensive we will see how it behaves once the season begins. 🙂

Posted on

OGN Logbook IV

There are some new nifty features in the OGN Logbook that you had not been told about. They are two rather nice and useful details some other fellow pilots already asked for or you might have desired.

Top Altitude During a Tow

For over two years you could have downloaded a .csv file in FlightOffice format that can also be opened in LibreOffice Calc or in any other spreadsheet tools. This file contains an summary of air traffic for each particular field for given day. The .csv file is available for download at top of the page in the page header as highlighted in the following screenshot.

Let’s assume you are from the Benalla airport, Victoria, AU (YBLA) and you have just started there as a tug pilot and local procedures require to record the maximal tow altitude for each flight. You can either note it down onto your kneepad every time upon tow release or alternatively check the appropriate column (col. H, MAX_ALT) in the .csv file where the logbook has recorded it for you (assuming you start the descend right after the glider release, the tow plane is equipped with well working OGN, transponder or other device and the OGN network coverage at your location is good).

The file structure is clear from the first header row and is I believe pretty self-explanatory.

    Multiple flights in the Map View

    This is a nice to have when you want to compare your friend’s flight with yours. Even when we agree to fly together in wing-to-wing formation, our paths usually split after a short while and many times it might be interesting which path the other one took. This feature is to visualise where our trails crossed without even knowing and where we joined on the cross-country flight under the same cloud again. For adding a flight just click on the large blue plus (+) symbol in the upper right corner of the map view.

    Here you can search for flights originating from the same airport (by default) of choose some other location your friend might have departed from. Furthermore, the date can also be modified if you want for example to overlay two or more flights from various days in the same map. Just remember that the flight-path retention period is not infinite, hence your early spring shenanigans won’t be probably not be available in late summer. Enjoy! 🙂

    Posted on

    OGN CUBEs Firmware Updates

    In early February, when the sunny but still freezing weather allowed, I had been testing new firmware for the upcoming season 2023. The units under test were located on the roof of our lab building where new features had to be validated in field conditions. Especially helpful was the WT9 Dynamic in performing its repeated take-offs and landings at LKCM right behind the nearby peak.

    For this firmware validations I conveniently use(d) the OGN Cube Control android app I developed some time ago for seamless upgrades without the necessity of removing the device from our gliders. Still on Monday afternoon it all worked flawlessly. On Tuesday (as I discovered months later) something happened. And finally on Wednesday morning when I wanted to apply the final firmware amendment I had just seen some Chinese symbols in the app! What the ****!? I keep my phone out of the endless Google update mayhem just to keep things consistent. Even the app was in the dev version (not installed from the Play) in order to retain full control over problems that may (and yes, they do) occur in the app. And the same issue appeared on all devices I know of at very similar time. So what was the trouble? Google had changed “something” in the very core of the Android API, pushed this improvement into all devices (even those with all updates explicitly disabled) and broke the app. And not only my app, many of them.

    The solution seemed to be obvious – upgrade the android development toolkit, Flutter, Dart and the development workspace in general, clean, rebuild, deploy, done, right? Not at all! As of now the project is irreversibly broken and the app cannot be even build. It seem the entire app needs to be re-implemented for the new API from the very bottom up 😐

    As many of you might have already guessed that is not that simple task for one summer weekend. Although the season is basically over the CUBEs still deserve firmware upgrade. The following is a step-by-step guide (for a bit more skillful readers) how to keep your CUBEs recent.

    Prerequisites: you need a computer with (*buntu) linux (but any other distro will do just fine) and bluetooth capability. This can till be done easily in the hangar without removing your CUBE from the airplane.

    Step #1: Run terminal/console app and install tools needed for communication between the scripts over bluetooth:

    sudo bash
apt install bluez git python3
hcitool scan
^D

    Provided your CUBE is powered you shall see it in the list after the scan command. If not, execute the scan again.

    Step #2: From github download the firmware upgrade scripts:

    git clone https://github.com/ibisek/firmwareLoader.git
cd firmwareLoader
python3 -m venv venv
source ./venv/bin/activate
pip install -r requirements.txt 
deactivate

    Step #3: Obtain the actual firmware file you need for your particular CUBE from a ognCubeReleases github repository. For the last step you need to know which MCU is inside your unit. To be über-certain you may want to open the box and see the type is in there. But in general, it should be like this:

    • OGN CUBE 2 -> STM32F103CBT6
    • OGN CUBE 3 -> STM32F103CBT6
    • OGN CUBE 3.5 -> STM32L152CC..

    !!WARNING!! By flashing incorrect firmware “architecture” you might be unable to perform easy re-flashing again. It can still be done on site but it is a bit more elaborate..

    The F103 (Cubes 2+3) have the aircraft type (glider/tow/uav) fixed in the bin file. Hence you want to choose the appropriate one. The CUBEs 3.5 can be configured and the fw comes as a glider by default. The configuration shall be retained during firmware upgrade but if you needed to change the type in the future I can tell you how someday later..

    cd bin-files

wget https://github.com/ibisek/ognCubeReleases/raw/master/releases/ognCube3.5.l152-2023-11-30-GLD-0x2800.bin

wget https://github.com/ibisek/ognCubeReleases/raw/master/releases/ognCube3.f103-2023-02-10-UAV-0x2800.bin

wget https://github.com/ibisek/ognCubeReleases/raw/master/releases/ognCube3.f103-2023-03-06-GLD-0x2800.bin

wget https://github.com/ibisek/ognCubeReleases/raw/master/releases/ognCube3.f103-2023-03-06-POWERED-0x2800.bin

cd ..

    Step #4: Flash the firmware. The unit needs to be powered-on for at least 20s before executing the script below – not to be within the initial 10s-long bootloader mode (yet). The LED shall indicate it is in satellite acquisition mode (two consequent relatively short flashes –) or already transmitting (very short flashes twice a second). 

    sudo ./findAndFlash.sh

    The flashing process will reboot the unit automatically.

    Q&A:

    • How do I know which version is the CUBE on? Connect to the unit using for example the Serial Bluetooth Terminal android app to see the prompted information. Here you can spot two dates – bootloader (comes right after power-on) and firmware version (right after bootloader yields control to the actual OGN code). The latter is what matters.
    Posted on

    OGN Logbook III

    There has been some substantial movement under the logbook‘s hood. The python-based back-end regularly suffers performance problems during summer days with great soaring conditions which we all love but cause gray hair to the server’s administrator. In fact it would not be such a great deal, but when it happens it always bugs my mind.

    The OGN beacon queue has been configured to ‘unlimited’ length for over two years now and the only way the problem is demonstrated are up to 12 hour long delays to process the piled-up data during such exquisite days while no precious data is lost. Considering the code fully utilizes all of the four powerful Intel Xeon Silver 4214 CPU @ 2.20GHz cores made me think there is something really rotten in the code. Moreover, there is a (a bit forced and already ongoing) plan to move the server onto a Raspberry Pi with significantly lower performance, something had to be done.

    The decision process was clear – we need a significant speed-up for all necessary real-time operations. Python is (really, really) slow and there are only a few programming languages on top of the performance chart that could suit our needs. Based on my favourite information source Hackaday.com (and multiple others) the suitable options might be some of the following ones:

    Programming languages by their energy, performance and memory requirements. Source: https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/

    From top to bottom we may think of C, C++, Rust, Ada, Java and Pascal. C/C++ does not come into consideration as my experience with multi-threaded applications in C are not really positive (and I don’t really claim to be anywhere near to an experienced C developer even after all those years of developing the CUBEs 😉 ). Rust is really odd, Ada, Fortran (oh man, no intentions digging into those) and Java. I used to write a LOT of nice code in Java, but its memory footprint is a bit large for the little Pi. And you know what? Why not to try that Rust!!

    Despite all the praising articles and blog-posts you can find around the programming pages and after almost a year of scrambling up the learning curve I dare to say Rust is the far most gory development experience I’ve ever encountered. Rewriting the core of OGN logbook took entire two full-time months of coding, full of despair and struggle with seriously weird and unfamiliar compilation problems, syntax and the whole approach to code in general. As people say “The experience doesn’t have to be good, it must be strong!”. In the end, after yet another month of testing, replacing many tricky .unwrap()s and polishing the details we have a working rust-based OGN logbook back-end. More experienced ‘Rustaceans’ may die in horror when looking on a rust code created by an OOP developer, but it is now as good as it gets.

    Python-vs-Rust based OGN beacon traffic. Python in green, Rust in blue.

    Wait! This is still not end of the story! At this moment the logbook you use is still being driven by the python code. The reason is the amount of traffic as seen through the monitoring logs differs a bit. It might be as low as 5% in number of processed OGN beacons per minute, rising up to 10-20% during the peak hours. The APRS filters are identical (i.e. the entire world) and so are the rules for beacon filtering. Just the Rust book receives less beacons and, which is the most interesting part, also beacons for other airborne vehicles comparing to the Python client. Mostly there is and overlap but rather frequently there are planes that Rust can’t see while Python can. And vice versa. If any of you guys and gals had a clue why is this happening, please let me know! 🤓

    Another improvement of the logbook coverage is extension of the airfields database by numerous small airstrips all over Canada. On Tim’s request a lot of data has been scraped, parsed and sorted resulting into 1638 new locations. The resulting data set consists now of notable 26903 airfields under OGN logbook‘s watch! 🙂

    Posted on

    KRT2 Bluetooth Adapter

    Although it might sound like a cliché, the component shortage made me to return to one nice and long adjourned project – the KRT2 radio adapter. The motivation for this one is obvious: since we were forced to exchange our perfectly working radios for another ones supporting the 8.33kHz channel spacing it was literally a pain to store anything in the stations’ memory. Every spring the same situation occurred in all hangars around the universe where infelicitous pilots were attempting to update the for some reason ever-changing frequencies into the by-the-devil-himself designed KRT2 radios. And then the rest of the season everyone refused to make any further amendments as the frustration is simply tremendous. Something had to be done! B-)

    Luckily, the author(s) of the KRT2 radio let the option to upload frequencies from something called “KRT2 Manager WinXP” open, hence there is a chance for us to flash the channel configurations from outside – a “third party” app and not to suffer so badly anymore. The application is called KRT2 Bluetooth and thanks to a friend with an android developer account is available right from the PLAY store.

    The adapter itself is a module that belongs between the radio and the connector which is already there. No sophisticated installation is required – you just smoothly plug it in and secure both sides with compatible latches.

    After powering-up the radio, you pair your android phone with the bluetooth adapter, open up the app, configure your personal list of frequencies, select the appropriate bluetooth device and upload your configuration into the radio. Done. Finished.

    Order of the stations in the list can be changed by dragging rows in the frequency-list table up and down. Multiple lists are beneficial especially when traveling around competitions frequently or friends desire to have a different set of frequencies. Complete lists can be exported into a csv file using the share button while import needs to be done by sending the file into the application (“Send to */*”).

    I like to say one KRT2 Bluetooth module shall be present in every club so all the radios could be set-up easily at the beginning of the season and no hassle is necessary later on. I made several of these very handy units and you can get them right now! Just visit the Choose and Buy section 🙂

    Posted on

    OGN Traffic in XCSoar & LK8000

    In the invent-build-publish chain I am somewhat neglecting the last step. In middle of January I had been asked whether and how well does the XCSoar navigation perform in combination with the OGN CUBEs. I actually always wanted to try that just for fun as we all already know the LK8000 provides a neat view of the other planes in CUBE’s radio range.

    During the third week of January the temperatures were still freezingly low and the winds blew harshly but at least there finally came a rare sunny day. One of the remaining internal battery-powered CUBE3Bs was located at one side of LU’s testing facility’s roof while I climbed with the other CUBE3.5 depicted above to the other side – a bit higher and as far as it was possible. (Here you may also see the ‘new’ and experimental antenna which might deliver a better range.. but that is still unconfirmed.)

    On the left you can spot the actual situation in the OGN viewer android application while on the right there is the appropriate configuration of the CUBE-XCSoar bluetooth pairing connection. Below the right picture shows the XCSoar map view with the other ‘glider’ as a little red static arrow. I have already misplaced the terminal screenshot but the NMEA sentences are being processed well as one would expect. And you can also compare the situation with the same view on the LK8000 screen in the the right screenshot. The zoom is at its maximum as the units were rather close to each other (well the roof is really not that large).

    The screens below are older shots from the summer 2021 where LK8000 displays other gliders – one circling right above the LKKA runway (the green arrow) and two others eagerly expecting the tug plane (blue) to land and tow them to the air as well. The middle and right images are other possible modes of displaying similar situations in LK8000.

    So the conclusion is YES, the OGN trackers work just fine with both XCSoar and LK8000 and can show you situation in the air when there are other planes equipped with appropriate gear around you. In the same way as the LX9000 with Flarm.. just a bit on the budget B-)

    Posted on

    OGN logbook II

    The holiday season finally freed my hands and let me to report on some new features implemented into both the OGN logbook web and engine. You’ve surely noticed the biggest and most valuable addition already: By following the little 🔍 symbol one can explore a track of a particular flight in detail!

    Flight as recorded by the glidertracker.de (left) and the OGN logbook (right)

    There is one limitation, however. The flight-tracks can be accessed for only up to 24 hours after landing as there is a limitation imposed by the data retention policy. This (probably) prevents the logbook to keep the data any longer as I am not really certain how the handle interpretation of the “data redistribution”. Moreover retention of so much flight data for extended periods of time would quickly take up all the available server’s storage anyway, so it gets all dumped after that timeout automatically. It might be a nice to see our older flights but it could also cause harm when used inappropriately. Could somebody advise?

    Second quite useful feature can be discovered when selecting a date in the header. For the date field to appear you need select an airfield or an airplane first.

    Date selection for chosen airfield or airplane

    Originally, this should have been a versatile date-range selection tool but apparently I am not as good web-designer as I needed or hoped to be. The possibility of selecting range of days, i.e. a weekend or an even entire week, had been here for some time now but is still not accessible with no bother from straight the UI. Nonetheless, you still have the opportunity to tweak the URL manually like for example this https://logbook.ibisek.com/loc/LKSU/2021-06-13/2021-06-16. Just be aware the maximum date-span is set to 14 days at most to ease the raspberry’s database load .. at least a bit.

    Another big thing on the back-end, especially from the performance point-of-view, was to abandon the python threads in favour to the multiprocessing module. I might have known (but never realised that before) the python GIL (global interpreter lock) does not allow to run the python threads on multiple CPU cores in parallel (as one’s experience from other programming languages would suggest, right?). This was then a significant bottleneck causing long delays in beacons processing, typically when the season was at its peak. The processing capability topped at around 168k beacons/minute while all extra incoming beacons might have been queued for another (up to) 10 hours for being processed. Now the multiprocessing, on the other hand, would prevent us from stepping through the code in a debugger. For that reason, both of threads and multiprocessing are now used in the codebase depending on the mode of execution. You can get more of the details on GitHub.

    This is how performance problems of the OGN logbook are detected. Orange dots in the upper half of the chart represent number of beacons queued for processing. Notice, how the queue size suddenly skyrockets after noon when most of the gliders got airborne. Green is the current beacon rate. In the lower part of the chart you can see current beacon processing rate per second split by protocols – OGN/ICAO/FLARM.

    The front page now shows traffic from all over the world. Initially, it was limited to the region you come from based on locale of your web-browser. The folks from Finland might not really been into flights in Italy, Swedes interested about traffic in Slovakia and Frogs about Britain. But in the end some us still might want to peek into what is going on in Chile, Namibia or New Zealand, particularly now in winter.

    The airfields database has been extended to the incredible number of 25262 records by adding some extra Australian, NZ, south- and especially thousands of north-American airstrips. Thanks a lot, John! 🙂

    Finally, besides the OGN, ICAO and FLARM the SafeSky beacons are now accounted for This traffic seems to be gaining some traction and we’ll see how that goes on in the next season. And also if it is of any use for us.

    That would be all about the OGN logbook for now. News and updates about the CUBEs will come hopefully soon. Because there is also something going on! 🙂

    Posted on

    Almost There!

    It has been long three months since I’ve given some sign of life. There has been a lot going on all around and also new CUBEs caught a significant hold-up. And as the season is (again!) relentlessly passing by it was the highest time to take some time off and complete some open issues.

    Most of the PCB assembly was done by Jan Weber in his workshop while I only populated the larger modules as it is easier to spot a problem and solve it before the more complicated and expensive components are soldered down. Here we encountered some troubles with the super capacitor backing-up the GPS as they refused to solder down properly and some of those even bursted into explosion during the heat-wave process.

    Later on the most recent multi-protocol firmware was flashed into the new micro-controllers (I had written about earlier) and all CUBEs were quickly passing indoor tests one after another. During outdoor and in-flight testing some peculiar glitches were spotted but even those are gone and the code is now polished into almost perfection 🙂 Almost because there is still some ongoing work on oncoming features (which are disabled in this firmware release but will come later through the OGN CUBE Control update process at time allows.

    The manuals were also updated and are already available in the downloads section. Finalisations are thus in full swing and the new CUBES 3.5 will set off to your airfields very soon! 🙂

    Posted on

    The MCU Dilemma

    First hints of forthcoming troubles with insufficient FLASH memory size of the STM2F103CB MCU’s started to peek out near the end of the last year’s season. With the ongoing development of new features my experimental CUBE was running short of program storage. With such expansion the codebase was about to hit the memory ceiling by the end of the year at the latest. Some thoughts were already thrown in the direction of yet another change in architecture design and which MCU shall all the existing code be migrated to. This is a story of the core MCU transition that took place during the last Xmas and spanning long into new years’ days.

    As mentioned earlier in one of the previous posts the first OGN CUBE tracker prototype was born on then the all-possible-requirements-fulfilling 8-bit Atmel’s ATMEGA8-16PU RISC microcontroller. Five(!) years ago I managed to squeeze a working tracker code to 8 kB of FLASH and incredible 1024 bytes (BYTES!) of SRAM – a feat I cannot imagine today anymore. Very shortly, however, MORE memory was needed. Hence the first migration naturally went to ATMEGA328P – now widely known as the “Arduino” chip. Just imagine the unlimited possibilities of four times as much of FLASH a twice as much RAM! 32K Ought to be Enough for Anyone, right? 🙂 Well, not really but this tracker still proudly flies across the skies bearing the livery ‘PK‘.

    The third migration was natural – I already had some experience with the STM32 ecosystem (F042 and F303 in particular), own stable set of SPL I/O libraries and also some hard time with HAL (which I strongly recommend to avoid). Hence it had to be a chip with a bright future, SPL support and some other reasonable parameters. After a long thought oscillation and numerous coin flips, the CUBE’s heart became the ubiquitous STM32F103CB IC, mainly due to its availability (at that time I even had no idea the other OGN trackers were based on the STM32F103C8). With 128kB of flash (C8 has only a half of it) and 32kB of RAM new way into bright future was paved. Are you now asking what was the other option? Wait for it..

    The first Überraschung peeked out already after the first successful compilation – the binary size for equal code was twice as much in size on ARM as on the good old AVR MCU! It was a luck the -CB had been chosen instead of the -C8. But also during this new ‘ARM age’ the code was growing in size. Some optimisations had to be applied and features taken off – like for example the little-fs based SD card flight logging. The remaining FLASH was considerably quickly running out. But I am not indicating the ARM period is over 🙂

    With new support of the other protocol B-) next huge leap was inevitable. Well, but in which direction? I needed the same footprint (LQFP48; the PCBs were already made) and ideally something from ST with SPL support (which is unfortunatelly left orphaned with their new MCUs), mainly because using HAL is a quick shortcut to HELL. Or .. could I possibly tease my imagination a little bit more?

    Nordic’s NRF52 seems to be very popular with some folks. This bluetooth-equipped chip would also let me to throw away the standalone bluetooth module and save some power & space! But the ecosystem looks a bit odd to me. MSP430 from Texas Instruments? For some completely unknown reason I am being attracted to this micro but no, this would probably be a step in a wrong direction. A PIC? Oh, come on! (do you remember the Microchip vs. Atmel wars? B-) ) What about ESP8266? Not enough I/O. ESP32? FCC certified, a bit more I/O pins (still not enough), with on-chip/module Wi-Fi & bluetooth would be fantastic .. but its power consumption? Oh man! Something with RISC-V? There is nothing really useful and ‘production ready’ out there yet. And last but not least – what do you think about Teensy? .. it was getting wild! 🙂 But even after all these daydreams the CUBEs will have to remain in marriage with ST. It’s not a bad micro after all, really. So I went on a shopping spree..

    Got stocked with a range of ST Nucleo development boards 🙂

    One of the long-lasting temptations was to migrate to higher-end ST micros like the L4 (no SPL support ;( ) or F4 (SPL supported, with a floating-point unit, how sweet!). At the same time reduction in power was also one of my strong requirements. Unfortunately, they don’t make F4s in LQFP48 with 256kB of FLASH. Bugger! I had spend so many nights and even more spare time with the ST’s MCU Finder app (which has so much potential but they cannot keep it working reliably between updates; shame to you, ST!) until the final and only choice went to the same chip as two years ago when then eventually picking F103 – the STM32L152CC. It sports 256kB of FLASH, clocks up to 32 MHz (which is still ~ ok), 32kB RAM, some EEPROM to store user configuration and hopefully also some longer future 🙂

    After an entire month (mostly December) of porting the code to the L152 (there really are some nasty differences and not only the the SPL; feel free to compare the block diagram of the MCU with the F103 in the datasheet) and hunting down the very last quirk in the I/O timings I can boldly announce the new MCU of choice for the oncoming OGN CUBE generation is the ST’s L152CC!

    Long live the chip! 🙂