THEMA:

Hi all,
Recently I have been working with some of the F3B and F3G pilots to do an app that is suitable to assist them with practicing their 150m course runs. My usual approach with apps is only to work on apps that I would use myself and are interesting in some way. The more interesting they are, the larger they tend to be! But when Harry and I decide on an app to work on, we usually don't accept as an up-front constraint that it has to run on the Gen 1 devices. If it can, then that is great .. and we put the correct codes into our repository so that Jeti studio reflects that compatibility.

Working on the F3B and F3G apps has been very interesting to me since it is not clear how to meet the goals of the pilots for 1-2m accurate turn commands while dealing with the latency of the telemetry download, sensor multiplexing at the RX and the sensors themselves. We have some ideas on what we can do and are working now to build a foundation on which to test some ideas. That is one interesting part of these apps. Also interesting would be a training app that had some analytics to help the pilots learn to fly better in competition. So lots of fun to be had there!

I learned that many glider pilots have older transmitters, and have not upgraded to the more capable new devices, so to be truly useful to the community, the F3G/B apps have to run on the G1 devices. My initial response was to be frustrated by this .. after all who wants to be so constrained in coding! But then it turned into a challenge .. to ask what tools exist in the Jeti lua implementation that might help.

The first issue I ran into was that having a lot of telemetry channels eats a lot of memory .. this tends to happen when you do the inital readSensors() and have to build the tables to put into the menus. The gps we are using is the SM Modellbau GPSLog 3 .. the code will work with any Jeti-compatible GPS but the SM unit is very fast and gives us the best chance to manage latency at the sensor end. But by default it has over 20 telemetry channels .. just for itself! Of course it comes with an app to remove channels at the pilot's discretion. Or you can delete them before loading the app in the TX sensors menu.

But as I thought about it .. we really only do this (virtually) once .. at startup of the app the first time you go into the menu and load the gps and any other sensors (e.g. alt, speed) .. and since the app saves this data .. you don't do again for a long time. So here is a function that is rarely done.

The next example might be the app setup (the init function) which by definition is only done once when the app starts .. and is not run again in that session. And there may be other examples of "one time only" code. There may also be examples of code some pilots want and others do not.

Fortunately for us, Jeti's lua implementation allow us to use the lua require facility which is a way to swap code into (and also out of!) the app at runtime. You put the code to be loaded/unloaded into modules that are separately compiled into .lc files. We keep those in the app's directory. Since we are limited to 50kb in the Gen 1 devices for lua, this can be VERY useful. So what I've done is to arrange for a lot of pieces of the code that are only used once or infrequently, to be only loaded when used, then removed ("un-required" if you wish).

For the F3G/B app this went from a "bare-bones" version that barely fit in 50k to a version with a lot of nice features that only consumes 40k! In short, it's just what we need to squeeze more functionality into the Gen 1-compatible apps. It lets us use the precious memory for critical app features and swap in and out the code for utility functions as needed.

To test this technique further, I wondered if some of the features of my big GPS Maps app (see www.jetiluadfm.app) could be made to run on a Gen 1 device. Since the mono screen is not capable of images, it would be only a GPS display app .. the screen would be a map .. a blank map .. but would be scaled to fit the flight path, and would show the aircraft flying and ideally would also show no-fly zones .. hopefully with the full no-fly zone functionality of the Maps app.

And it turns out that is IS possible to do this .. a full GPS display app, with no-fly zones defined on a per-field basis on our website .. but tailored to the GPS-only (no google map images) nature of the app which I am calling DFM-GPS to distinguish it from DFM-Maps. As some of you may know if you have used the Maps app, my son did the website for me and he's in the process of updating it to produce only the no-fly zones for the new GPS app.

I hope to release this new app soon once some more testing is done, and the website changes are ready .. but if you are also a lua coder for Jeti apps feel free to look at the dev branch of my github .. github.com/davidmcq137/JetiLuaDFM/tree/dev/DFM-GPS if you want to see how this is working in the actual code.

If anyone is still flying (given the bad weather here in the US and across the pond maybe no one is!) .. and wants to do some early testing of this GPS app please do let me know. I've attached one screenshot of the app running on the emulator, pretending to be a Gen 1 device (I "fake" the return from the lua api to tell the app it's a Gen 1 device when the black and white color scheme is selected on the emulator). It's also using my sensor emulator which creates from lua expressions for parametric equations a set of responses that mimic the gps coords coming from a Jeti gps devices flying that track. You can see it's not nearly as pretty as the second shot of the same app running on the emulator pretending to be a dc/ds-24.

If these ideas can help you in your programming .. I am happy to share them. Or, if you are more expert in these areas of lua and want to give me ideas on how to do better, I would certainly welcome that!

There are some disadvantages of course. Speed of execution might come to mind but it's really irrelevant here since we are swapping from the internal flash card which is pretty fast and we are only swapping things that happen on a human timescale. Another disadvantage is that some functions (e.g. selecting or changing telemetry devices) can only be done at app startup .. once the app is running they are unavailable .. they have been swapped out and the core app functions are there in memory instead. But that, at least in my opinion, is well worth the small headache.

Currently the GPS app, running on a DS-16 Gen 1 with the airspeed and altitude "tapes" and no fly zones etc, is running at about 46K .. close to the practical limit since some memory has to be left for lua to "breathe". Without the airspeed and alt tapes it's about 41K. Honestly I never would have believed this to be possible!

I also made a second drawing module for the app which is automatically loaded if the app is run on a newer TX .. it has full color, anti-alias drawing, long flight history ribbons which can be colored by telemetry channels etc .. all in one app. Again, I never would have believed it a month ago!

Dave