Switching magnetometer on and off at runtime

[kitlith]

This is something that @Fishvap requested on discord, though I vaguely recall some separate discussion about doing something like this for the BNOs.

This is a cross-cutting concern, but I'm starting with an issue on the Firmware, since it doesn't matter if we add UI for it if the trackers don't support it.

The concept is that for users with trackers that have magnetometers and appropriate firmware flashed, we can eventually add a switch to the UI somewhere (per-tracker? globally?) that switches between ignoring the magnetometer or not. This would allow people to fiddle with enabling or disabling the magnetometer without having to re-flash firmware. (one potential use-case might be for someone who is travelling, their home happens to have a good magnetic environment, but wherever they are right now isn't.)

This roughly requires:

• In the firmware, a build variant which can choose this at runtime.
  • This is more difficult for things like the mpu9250, since many users in 6dof mode use the DMP, while users in 9dof mode can't and instead use our own sensor fusion. Including both sets of code might inflate firmware size.
    • This might end up being a choice of "use DMP, or have the ability to switch" at compile time.
  • This is easier for things like the BNOs, which do the sensor fusion for us and we can choose to request magnetometer vs no magnetometer, or for IMUs where we always need to do our own sensor fusion anyway.
    • Something that I haven't checked: what fusion algorithms do we support that are compatible with which modes?
• In the firmware protocol, a means for the server to communicate whether a magnetometer should be considered or not to the tracker
  • Do we already have a means for the server to communicate runtime settings to trackers?
• In the GUI, the actual toggle.

[Eirenliel]

Do we already have a means for the server to communicate runtime settings to trackers?

No. And I wouldn't call it "runtime", it should persist in the tracker's config as was mentioned in #41. Tracker though need to send the status to the server, and server should be able to send changes back.

This is more difficult for things like the mpu9250, since many users in 6dof mode use the DMP, while users in 9dof mode can't and instead use our own sensor fusion. Including both sets of code might inflate firmware size.

I believe both codes are included in 9250, but it will require some refactoring.

[kitlith]

I wouldn't call it "runtime", it should persist in the tracker's config

Well, it's not compile time configuration, therefore it's runtime configuration. Unless you'd prefer a term like config-time?

I believe both codes are included in 9250, but it will require some refactoring.

The set of code that's not necessary is removed by the preprocessor, and therefore not present at runtime, so I'd expect the firmware to grow a little.