Refactoring the entire output system has been quite a challenge. Not because the techniques used are complicated, but the foundation I build was fundamentally flawed. In the pictures of the old/new folder structures, it’s rather clear what has changed. The outputs have become modular and structured.
Single overview
The other thing that needs to be looked at is the ease of use. We currently have 3 views: Inputs, Outputs, Both. Having to switch tabs when you’re setting things up or when you want to have a quick flight can be quite the drag. Ideally, we want to have a single overview that lets you set everything up and start connections from the same place. It will make our lives easier when programming, testing but, most importantly, enjoying our flights. There will be menus where you can set up and alter settings for each mode. In reality, you probably set up your devices and don’t want to be bothered by all the settings once you got everything dialed in. Just hit GO! and we’re back into the action.
Sets
Outputs can be taxing on your boards. Having a big chunk of data flowing back and forth would make no sense. Each of your boards probably has a dedicated functionality (i.e., a board as radio, flight data, environmental information). Sending the fuel data to your radios increases the burden and the risk of data corruption. In line with setting everything up once and just press play later, I will introduce sets. In the very rough sketch below, you’ll get a quick glimpse into the flow of data.
Why isn’t it out yet?
Because it touches a large portion of the codebase I wanted to do some extensive testing before releasing it into the wild. Let me tell you it was needed. There were many CTD’s that ruined the experience. There are a few leaks left that need to be patched before it’s ready to roam freely.
