Feature Request: Add ability to explore configurator options with NO BOARD connected

[JonnyPhenomenon]

One thing I keep wishing I could do with the Betaflight configurator is to be able to explore the GUI menus without any FC connected.

If all we could do with this is to explore the configurator menu's to get familiar with them, it would still be quite valuable.
Of course, it would be awesome to be able to choose a specific firmware, and load it up as if the board was connected, so all the board specific default options could be explored, and possibly to even make some configuration changes and export the diff to be loaded later.

[JonnyPhenomenon]

So, another reason why this would be a valuable feature is the impending issue with Google and Chrome Apps. #642 I might be way off base here, but it looks to me like a lot of the configurator code uses chrome api's to talk to the physical devices. If the necessity for BF to talk to connected boards was removed, the porting of the BFCfg chrome app to an HTML5 app should be simplified, am I right?

If one could (sans board) use the BFCfg GUI to configure all the settings desired, and then export produce a text file list of CLI commands that could then be uploaded to a FC through a putty/terminal session, then it would be one less thing to rely on the chrome api's for...

I am quite sure I have absolutely no idea what I am talking about.... I should probably just keep my mouth shut. :)

[mosvov]

Maybe faster way to implement this is add some abstraction over chrome.serial, and implement some virtual serial device that will response as real board? In this case we will be able to edit configuration and export if to file

[JonnyPhenomenon]

I hate to bump my own feature request, but I am kind of surprised this hasn't gained more traction. with the new features added to BFC and the standalone progressing along nicely, I would love to be able to explore it without needing to keep my flight controller plugged in... am I alone here?

[mikeller]

@JonnyPhenomenon: No you are most definitely not alone with this. But it looks like all other developers are busy doing other things (some of them, like the standalone app, coming with a deadline). Looks like the fastest way to get it wlll be if you implement it and open a pull request...

[JonnyPhenomenon]

@mikeller ahh yes. I understand completely. gotta have those priorities in order. Glad to see the standalone is making so much progress. Thank you for that. :)

[wyntrblue]

i would also like to see this sort of feature implemented. no idea how possible it is but would be great to be able to play around with the software.

[jflyper]

I think there has been a similar request, either here or at firmware...

Anyway, I think it's possible to make the configurator connect to an internal pseudo-board by creating a msp server inside the configurator, or even as an external http/rest/restfull server.

However, I don't see it useful except for checking out what are the configuration items are. This doesn't justify the effort of creating the pseudo-board.

EDIT I recommend to always carry a bare FC in your briefcase, or in your wallet.

[mikeller]

@jflyper: I see it as useful as a tool to look at and edit a flight controller configuration, once (parameter group based) all-in-one dump / restore of the configuration, and with it clean backup / restore outside of the CLI has been implemented. If we can load / restore the complete state of the flight controller (to actual hardware or to a file), then there is no need for anything to be connected to the configurator.

[jflyper]

@mikeller I'm not sure if it's going to be as useful as it sounds.

• The configuration fix feature may override some values.
• It may introduce another source of confusion by explicitly allowing multiple un-verified configurations to exist.
• ...

IMO, the configuration should be stored solely in FC.

[mikeller]

IMO, the configuration should be stored solely in FC.

I strongly disagree. The patchwork we have got now where every tab has to know of and pull and push all of the settings it controls (or needs access to to calculate state) is a hack, and a source of countless bugs. Furthermore, the fact that users can't switch tabs (e.g. to look up other settings) without either saving a temporary configuration, or losing any changes, is bad UX and a potential source of misconfigurations being stored on the flight controller. In my opinion, we need to move towards pulling the full state from the flight controller after connect, and storing it (or at least everything that has been changed in any tab) on a save. Parameter groups will enable us to get there.

[jflyper]

True.

But I'm not too sure if the PG based way justifies a pseudo connection to an non-exisitent board.

[mikeller]

@jflyper: I wasn't thinking of 'emulating' a flight controller for this purpose. But if the flight controller configuration is enumerated and downloaded on connect, once this is done, the flight controller itself can be disconnected and the local configuration used (obviously without having updates for things like CPU load). The same applies if this configuration is then persisted and reloaded.

[JonnyPhenomenon]

I am glad to see this feature request still getting attention.

If I understand what MiKeller was saying. - the way its coded right now, each time you load a tab, the code for that tab in the configurator has a list of hand entered value names which it has to ask the flight controller one by one to provide the settings for.

"Parameter Groups" would what? categorize various settings by some criteria, so they could know what tab(s) to appear on? (so the tab only has to say "Show me Settings Group 1"?)

So, if the entire configuration of the FC was loaded on connect, like a (Dump, or diff, etc) and all variables set from the start, the configurator could simply populate its tabs from these, am I right?

a simple parsing of the dump command could generate the variable names as well as the setting... store it in memory, and you wouldn't need to have the FC connected anymore until you want to save it... right?

I can attest to yet another reason why this would be useful. My BFF3 FC board has taken some abuse and the USB port only stays connected if I hold the cable in and squeeze it just right. (lol yeah I know). it would be nice to be able to plug it in, grab the configs off of it in a couple seconds, and be able to unplug it and perform the config changes offline. Only needing to reconnect to upload the changes. - this, as it turns out is what I end up doing anyway, with Notepad, long hand, and paste my settings changes into the CLI while holding the FC/USB just so. -

Anyway... food for thought I suppose...

[ghost]

As there's no movement with this, while it makes things much easier, I'm trying to do this myself.

How I vision this'd roll out is:

1. Add ability to emulate this while feeding defaults as data straight from the configurator code. (Mostly for devs to test new code without having to connect).
2. Add the option to feed this data from a CLI 'diff all' output.
3. Make the configurator faster by loading once, then keep using the loaded file.

I'm trying to do the first point. I think the data is finished with GUI.content_ready(callback); , however, I'm having trouble seeing how and in what form the data is read from the FC into variables.

[mikeller]

@timman2er: The problem is that the way configurator currently works is that every tab only loads the data it needs, every time the tab is entered. This is a mess, and there is overlap for some data that is loaded by multiple tabs. This means that there is no easy way to make sure all data is transferred from the flight controller to the configurator. The backup method in the Setup tab tries to do this, but new data often goes missing when new functions are added, and data that is CLI only will be missed no matter what.

As discussed above, there is no easy way out of this, and I think instead of trying to come up with a solution to allow off-line data editing with the current way configurator works, we should wait until we have parameter group based data exchange, and then leverage this to download all of the flight controller configuration at once, when a connection is established. At that point, enabling off-line data editing will be easy to implement.

[JonnyPhenomenon]

Since my last comment on the topic, I've just been keeping an old(slightly damaged) fc kicking around and exploring settings with that connected. It works perfectly well when the old fc is the same model as my drones, and adequately enough when they aren't.

[haslinghuis]

@JonnyPhenomenon we have a virtualFC option in the next release: https://github.com/betaflight/betaflight-configurator/pull/2283.

Closing this issue now as resolved.