New pot support requires calibration code

[JaimeLeon2]

Is your feature request related to a problem? Please describe. Pots are all different, giving different ranges of values instead of the standard 0-1023. This requires a calibration to be done for each pot, which currently needs to be included as user code.

Describe the solution you'd like Provide fields for pot calibration in the pot input config wizard. A minimum value and maximum value for 0-1023 input range calibration. A translate range would recalibrate the pot for the sim expected range, which is normally different than what arduino handles. Something like this below:

Calibrate pot? YES Input Range: Min Value 13 Max Value 1023

Translate range? YES Translate Range: Min Value _0 Max Value _16383

Describe alternatives you've considered This could also be done in the firmware, but probably is more cumbersome for the users and may add runtime load.

The new calibration routine should also check that the ranges are not exceeded before returning, e.g. the pot sometimes reads a minimum of 0, which would return negative numbers.

Additional context None

[pizman]

The Inpuut Calibration may is needed ( Not test this out myself) The Output side should be possible already within the NCalc Syntax .... isn´t it ?

E.g. Poti gives 0-1023 ..... Sim need 0-16383
16384/1024=16 (multiply factor) So ....
Input Value "@" occure in 0-1023 . If we use "@*16" then we got 0-16383.

[MobiFlight-Admin]

(@-minReading/(maxReading-minReading))*MaxValue

for @JaimeLeon2

(@-13)/(1023-13)*16383

[JaimeLeon2]

Yeah, I am familiar with the calibration calculation and translation to other ranges. The point is that something that each pot requires to function would be better if provided by MF as part of its support. There have been many questions from other users about how to do this.

[tigert]

Two thoughts:

• [x] Reverse direction checkbox

• The ranges could have a preset dropdown where you could have the most common ones, and an option to set your own.

• Also one more thought for this topic (but more like 10.0 milestone or even further down the road) - to specify the expected range as some kind of metadata in HubHop events, and have Mobiflight automatically select a correct potentiometer range preset for you when a simulator preset is selected.

[DocMoebiuz]

ideally a pot tool like on hubhop could be built into mobiflight. I would however postpone this until I do a UI overhaul. As a workaround we have the tool on the website.

What do you guys think?

[tigert]

The web tool works, but it is kind of annoying having to set hardware specific potentiometer ranges into configs, for example if you make a community panel design, and then everyone makes one and their pots are not 100% the same.

I think it would be good to have all devices conform to certain defined ranges from the events mapping side, and all adjustments for that should happen in the device configuration. So that a pot reads always 0-1023

I see the point of wanting to rework the ui first too though. But pot caluibration could also be automatic: just have a button to start, and move the whole range through and record top and low end.

[elral]

I know this from radios for RC models. In older days a special maintance menu (only accessible from the manufacturer) had to be called, since introduction of the 2.4GHz technology and some open source projects have implemeted it. For RC its much more important to have this as the pots are only using 90°.

My first ideawas when I read this, to do a calibration within a firmware by sending a command from the connector and store this values into the EEPROM. But then a loat of float calculation is needed to convert the pot hardware range e.g. 15-1012 to 0-1023. However it is a try worth. The other way could be to make this calibration and stroring the min/max value in the EEPROM like above but sending these values to the connector when the config gets loaded (part of the information of each pot).

[tigert]

From the device's perspective, it would be good to store the calibrated endpoints in the firmware, since they might be dependant on the actual physical potentiometer used, and being analog devices, might change between units.

@DocMoebiuz @elral what if the firmware had a "calibrate this pot" command, where it then expects the potentiometer to be moved through the full range, until a "store calibration" command is given, at which point it would store the highest and lowest recorded value in the eeprom as the endpoint? I mean that would basically be what is needed, right? Maybe needs a way to reset the calibration range too, but thats pretty much it.

Another question is, should the pot then have its range as 0 to 100%? Many things in MSFS are 0-100% and it might make more sense especially now that the value can be float, so there is no issue with precision.

[tigert]

Would it be silly to do the 0 to 100 range mapping and calibration in MF Connector? What if the calibration points were sent to Connector when the Arduino is queried for devices?

Now the protocol seems to do this:

11.54.20.Lighting Knob

Where 11 is pot, 54 is pin and 20 is the sensitivity. We could save calibration endpoints and send then the same way:

11.54.20.5.782.Potentiometer name

In this example the calibration endpoints would be 5 and 782 from 0 - 1023 range.

If endpoints are not sent, it would be either uncalibrated or old firmware version?

The mapping would be done in Connector side if it's expensive to do on the Arduino?

Would this make sense? I am aware my understanding of coding or the current architecture is not that great, but I am trying to think what would be needed from firmware / connector to support this.

The UI on Connector could be:

Uncalibrated [ Calibrate this analog input ]

Calibrating [ Move axis to lowest end click here ]

Calibrating [ Move axis to highest end click here ]

Calibrated min: [ 12] max: [ 1003 ] [ save values ]

[elral]

I see also the mapping done by the connector. There are too much float calculations for the Arduinos. And as already above mentioned, I would prefer to have a function call to move the pot within a defined time to get the min/max values and store them in the EEPROM. By another function call theses values are transferred to the connector. I wouldn't send the calibration values as part of the config. Both I have already tested.

Another approach would be to assume that each pot has a min value of 12 and a max value of 1012 (the min value fits pretty good to my pots which are 13 - 14). So from the analog value 12 is subtracted (or maybe a liitle bit more) and checked that the value is not negative and not above 1000. The min value will be in a small one digit range and the max value (1000) will be reached for the most pots. I would expect only a very small movement of the pot at the end and beginning where the values might not change.

[DocMoebiuz]

This is a good use case for:

• Smooth-modifier
• Being able to apply modifiers in the context of inputs