Compass mount orientation - should this be runtime-configurable? #10557
egorsiniaev
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
While adding MPU-9250 / RAK1905 support in #10556 I noticed something that affects all three magnetometer drivers we have (BMX160, ICM20948, MPU9250) but isn't fixable from the client app.
The problem
The compass heading code assumes the sensor chip is mounted flat (Z axis pointing up). That's true when the WisBlock baseboard lies horizontal. But many cases mount the board vertically - for example when the LCD is perpendicular to the board. In those cases the chip's "up" axis is now sideways, and the compass needle jumps around during any small rotation.
I verified this on a RAK1905 in a vertical case. The fix is to tell the driver which physical axis is up. The existing "config.display.compass_orientation" setting can't do this - it only rotates around the up axis, not which axis is up.
What's in PR #10556
A build-time MPU9250_UP_AXIS define. Works for variant maintainers and DIYers, but not for end users on pre-built firmware.
Question
How should this be exposed to end users? Some options:
A. New config field (e.g. compass_up_axis) with a dropdown in the apps. Most flexible, but needs changes in the protobufs repo + at least one client app (iOS / Android / web).
B. On-device setup step - add an option in the existing Compass menu like "Set Orientation": user holds device in their normal use position, taps confirm, firmware samples gravity for a moment and saves which axis is up to
/prefs/. Reuses the Compass Calibration UX pattern. All-firmware, no protobuf or client changes.C. Auto-detect at boot - same idea as B but without explicit user trigger. Simpler UX but unreliable if device is moving on boot.
D. Keep the build flag - document it, ship it, leave it to variant maintainers / DIYers.
I prefer Option B as straightforward and works the same as Calibration. But happy to implement whichever direction the team prefers, especially since the same fix should apply to BMX160 and ICM20948 too - those users hit the same problem today but probably just live with it.
Any thoughts?
Beta Was this translation helpful? Give feedback.
All reactions