Home Distance symbol preview lenght

[Jetrell]

Hi guys. The configurator OSD symbol preview for Home Distance, has an extended possibility of character length. This prevents the Home Distance readout from being place any closer than 4 character spaces from the right side of the screen. This would give it a distance range of 99.9999km/Mi. Which is a long distance to be away from yourself with a quad :-)

It can be placed closer if its position is loaded into the CLI, to tell it where to be placed. But it has overflow to the next line.

The reason I noticed, was because a friend using 4.03 pointed it out to me. So it was there before the current font upgrades. Thanks

[McGiverGim]

In an earlier version of Betaflight we add padding with spaces to "erase" the possible earlier value of the element. Now it has changed and we don't need it. I will fix the firmware (there are elements where we have the padding because nobody has removed it) and I will fix all the previews.

@mikeller what is the best approach for this in the preview?

• Use a typical standard value (for example, for this element, distance to home, use two or three digits).
• Use a typical maximum value (for distance to home, this will be four or five digits).

[Jetrell]

@McGiverGim Just an observation from earlier. The Total Distance value wasn't padded at all. Yet its displayed value will always be higher than the Distance to Home value.

[McGiverGim]

Done the firmware part: https://github.com/betaflight/betaflight/pull/8416

When approved I will do the Configurator part.

[mikeller]

@McGiverGim: I think a good approach for fields like this is to try and go for a number of significant digits, and not total number length. So if we limit to 3 significant digits and use m up to 999m, then go for 1.00km up to 9.99km, and then go for 10.0km up to 99.9km this would limit the length to 4 digits (including the decimal dot). Not sure if this is also feasible for imperialistic measurements (@etracer65?).

[McGiverGim]

My question was about the preview in the Configurator only, not how to do it in the firmware. ;-)

The iNav code does that, but the function is huge and very complicated. I don't know if we want to get there.

[mikeller]

Hehe. But then I guess the preview should reflect how the real thing looks, and the core of the problem is that the real thing can look quite pointless if it is 12.3456km. So getting the OSD element into a more useful form, and then making the preview match it, will solve the problem. I can look if I can come up with a new format for this OSD element that uses a fixed number of significant digits.

[etracer65]

The "fixed number of significant digits" approach in the firmware would be useful I'd think for more than this. Also thinking about the battery voltage and current as possibilities.

[mikeller]

@etracer65: These are significantly simpler - at least as long as we do not get batteries in the kV range. :stuck_out_tongue_closed_eyes:

[mikeller]

We could probably get most of what we need for 'fixed number of significant digits' 'for free' if we switched tfp_printf() for a more fully fledged printf implementation like https://github.com/mpaland/printf/, which would allow us to simplify a bunch of other places where we are using tfp_printf() now. @etracer65, @jflyper, @ledvinap: Thoughts?

[ledvinap]

@mikeller : I created some PRs against https://github.com/mpaland/printf. I'm using it in my project too, so I'll keep it supported for some time. The changes will reduce code footprint a bit a remove some minor bugs.

One possibility is to fork the repository and use that version until it gets merged upstream ...

[mikeller]

@ledvinap: Sounds like an even better option. Which repository / branch are these changes in?

Should we stick with using custom function names, and modify printf.h accordingly, or should we use the defines to redirect the printf() calls to their equivalents?

[ledvinap]

@mikeller : I have 2 versions in my github account, one is quite minimal fixup, second is a bit deeper rewrite, but I need to think about it a bit, I'm probably overengineering it..

Give me few days ...

[ledvinap]

@mikeller : I'd prefer to remove the defines and use standard stdio names. Library functions are weak, so it should not cause any problems. And last mpaland version is almost fully standard-conforming, so it should be interchangeable for standard one ...

[Jetrell]

I have 2 versions in my github account, one is quite minimal fixup, second is a bit deeper rewrite, but I need to think about it a bit, I'm probably overengineering it..

Give me few days ...

@ledvinap Do what this left open to work on the above mentioned. Or can I close it now that this issue has a fix?

[stale[bot]]

This issue / pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within a week.

[mikeller]

@ledvinap: Is https://github.com/mpaland/printf now ready to be pulled into Betaflight?

[mikeller]

@ledvinap: Coming back to this, as I think this would be an improvement: Is https://github.com/mpaland/printf now ready to be pulled into Betaflight?

[haslinghuis]

@ledvinap is the issue still relevant?