Repository navigation
SpitFW – A Modular Scale Cockpit Framework for ETHOS/FrSky (Seeking Technical Feedback) #6254
Replies: 8 comments 5 replies
|
📢 WE NEED YOUR FEEDBACK! With the new ETHOS 2.0.0 and FW 26.1.2 , the RAM issues are almost fixed and this project is close to being flight-ready. Please take 5 seconds to tell me if it interests you. Click here to join the official poll: 👉 Spitfire-developer/spitfw-presentation#1 |
|
The modular approach sounds very interesting, I have seen one screenshot, which is very nice. How is it possible to give it a try? In your place I would add a link on the first page of your project, it would redirect to the online simulator and the args would be the url of a radio backup on your github (you may keep luac files if you don't want to show the source code). Rotorflight does this and it means that only one click is needed to see your work running! |
|
Hi Bertrand, Thanks a lot for taking the time to reply, and for the suggestion — it's exactly the "one click to see it running" outcome I was hoping for. Quick update: I've packaged SpitFW as a single unified main.luac (no external lib/modules folders, just the compiled bytecode) and it's now compiling and running correctly in the Ethos simulator. The foundation is solid — a few instrument-level details still need polishing, but nothing structural. I'm publishing this compact build so people can evaluate the overall quality and direction of the project. Here's the compact backup (full X20RS simulator folder — scripts/models/bitmaps — ready to drop into the simulator or restore via FrSky Suite): One thing I couldn't quite figure out: I checked the "Ethos simulators" wiki page for the link syntax you mentioned, but it only documents the classic simulator.exe command-line arguments, not a browser-based simulator that accepts a backup URL as a parameter. Could you point me to the exact mechanism/syntax for that — the same one Rotorflight uses? I'd like to set it up correctly on the first try. If you're curious about the internals, the full modular version (separate lib/ and modules/ folders, no single-file bundling) is available too — happy to share it for a technical look. Thanks again, |
|
Hi Bertrand, Thank you for the suggestion. I finally managed to set up the one-click demo link in the SpitFW repository README. The link now launches the ETHOS 26.1.2 X20RS EU simulator and automatically loads the compact SpitFW build from the GitHub release. This makes it possible to try SpitFW directly in the browser without any manual installation. Thanks again for pointing me in the right direction — the one-click approach works very well for this project. Best regards, |
|
Excellent work! 
|
|
Screenshots taken from your work: 
|
|
I would like to press those buttons ;) 
|
|
Hi Bertrand, Thanks for trying it out and for the screenshots — glad you liked what you saw :) To be precise about the buttons: that interactivity isn't implemented yet, it's something I've had in mind for a while and would like to add. I know the mechanics involved (extra state variables, etc.), but what's held me back is a safety concern: for flight-critical functions like gear or flaps, I'd want to support control via both a touch button and a physical switch on the radio, and I'm wary of the two getting out of sync — e.g. the pilot toggles the physical switch without knowing its current logical position (since the last change came from a touch tap), and ends up triggering an unintended retraction/deployment. I've been looking into whether there's a clean way in Ethos to keep a touch-driven virtual control and a physical switch input properly in sync for the same logical function. If you know of a recommended pattern for that, I'd be glad to hear it. On the bitmap create/destroy topic: yes, I'd very much welcome a review — please go ahead. One more data point that might be relevant to what you flagged: I'm seeing some version-dependent behavior around bitmap memory handling. On Ethos 2.0.1 (simulator), a short click vs. a long click on a window seems to trigger different load/unload behavior for the instrument bitmaps — sometimes they don't reappear as expected. On the actual radio, running firmware 26.1.2, it seems to behave consistently. So there might be a version-to-version (or simulator-vs-hardware) discrepancy worth looking into alongside the create/destroy process itself. Rather than spend more time on this single-file demo build (which was really just meant to let people see it running), I'd rather give you direct access to the full modular version — happy to share it for a proper technical look whenever works for you. Thanks again, |
|
Hi @bsongis, Here is a small preview of another idea I have been working on: MultiToggle for ETHOS It shows the possibility of using touchscreen toggles directly on the display to switch channels and control additional functions, alongside the transmitter's physical switches. I am also working on bringing the same touchscreen control concept, combined with the physical switches, to the Flaps, Navigation Lights and MAGS modules of SpitFW. Have a look when you have a moment and let me know what you think. The MultiToggle concept could potentially be integrated into SpitFW in the future as another configurable control component. Thanks! |
|
Hi Bertrand, Well… you said you would like to be able to press those buttons on the screen. 😄 So I decided to give it a try. I now have a working prototype combining touchscreen controls and physical switches, with independently configurable safety/hold times for each position. It is currently implemented for MAGS, FLAPS and NAV and is already working on ETHOS. You can actually press the buttons yourself here: 👉 Try SpitFW Touch Controls in the Online ETHOS Simulator And here is the preview release: 👉 SpitFW Touch Controls — Preview It is a small experimental prototype for now, but I think the result is quite interesting and could become part of SpitFW. While testing it, I also noticed an interesting ETHOS touch behaviour: after approximately one second of continuous touch, the touch tracking seems to change/loss of focus, and in some cases the expected TOUCH_END does not appear to reach the widget. I made a small dedicated test specifically to investigate this behaviour. The test displays the raw touch event values received by the widget, so it should make it possible to reproduce and identify exactly what ETHOS is sending. I have not published that test yet, because it is really just a diagnostic tool. If it is useful for you, I can make the dedicated test available in a small repository/release so you can reproduce the behaviour directly. Also, just checking that everything is OK on your side — I haven't heard back from you regarding your kind offer to review the project and my offer to provide the source package. No rush at all, of course. 🙂 Have fun pressing the buttons! 😄 Massimo / Spitfire-developer |
And Now you have plenty of toggles to click on! 😉 |
|
Hi Bertrand, I hope you are doing well. Since our last chat about the touch buttons, SpitFW has evolved quite a bit. I now have a new compiled release ready, including a new telemetry mode for the AFG instrument and a reorganized project structure. I remember you kindly offered to review the code and help optimize resources. To make it easier for you, I have set up a private repository with the complete source code. If you still have a moment to take a look, I would be very happy to grant you access. Here is the new release link, just in case you want to see the result in action: v0.3.0-preview No rush at all — I know how busy you are with ETHOS development. Just wanted to keep you updated! Best regards, |
Uh oh!
There was an error while loading. Please reload this page.
Hi everyone,
I have been working on a personal project called SpitFW, a modular framework designed to transform FrSky transmitter displays into realistic, scale-inspired aircraft cockpits under ETHOS.
The project has evolved from individual analog instruments—starting with a Spitfire dashboard—into a structured architecture based on three pillars: a Coordination Layer (Regia), independent Modules, and centralized Libraries.
While the core logic is fully functional, I am currently exploring the memory boundaries of ETHOS when scaling up graphically intensive visual assets. I am encountering resource constraints related to bitmap rendering, simultaneous allocations, and memory spikes during initialization.
I am not looking for a commercial release, but rather seeking architectural feedback from experienced ETHOS/Lua developers. I am completely open to technical collaboration, troubleshooting, and code-level suggestions to identify the most efficient and system-compliant approach to asset and memory management.
I have put together a detailed presentation of the project, including its architecture, development journey, and cockpit screenshots, which you can scroll through directly on my GitHub page:
👉 https://github.com/Spitfire-developer/spitfw-presentation
If you are an ETHOS core developer or a technical contributor interested in evaluating the framework, I would be glad to share the private codebase for a technical discussion.
Looking forward to your feedback!
Best regards,
Massimo
Spitfire-developer
All reactions