Decimal point issue leads to a dangerous crash

Yesterday j was making some small adjustments to my small quadcopter. As it is a bit overpowered, I decided to deduce the mot_spin_arm from .1 to .07 and mot_spin_min from .15 to .10
I live in Europe and I used the decimal point from the comouters numeric pad “.” Instead of the “,” separator. At the moment of typing it there was no error nor out of range message, and the parameter is seen correctly on the screen. But when saving the values, they are stored whitout the decimal point, in my case 7 and 10. Again without any out of range advise. Some minutes later, just after arming, the motors rev to the maximun and the drone moved uncontrolled like a rocket against a wall and completely self destroyed. I was also lucky that it didn’t come towards me. I think that it is a serious and dangerous issue as it can happen on any parameter and also easy to solve.

So you used a decimal comma? I can’t get that to persist. It’s flagged in Red and after saving anyway when I return it’s back to where it was before attempting the change.

I had this problem too, with less dramatic consequences. Since I noticed this problem, I always refresh the params after writing them, to see if they got saved as I want them to be. Using the wrong seperator causes it to be ignored.

Is that a version issue I wonder? Because I can’t get it to do what he described.

I have to test it again. I made sure to use the correct seperator lately…

I can only use the quadcopter on weekends, but if possible I will show you tomorrow. I have a recent version of M.P.

Same thing happened to me a couple of times.
It’s really confusing since all options and descriptions use decimal point ("."), but you have to use a decimal comma (",") for it to work.

@dkemxr, in my case it’s always green.

Using point:
Using comma:

It’s always green.

And if I save it, using point, it get’s changed to this after refreshing parameters:

@Echo @dkemxr @andresrc @Michael_Oborne

I just did a test with a SITL copter on MP 1.3.74. Using decimal point for MOT_SPIN_MIN entering 0.15 results in 15 after refreshing the parameters.
I was also able to reproduce the crash @andresrc had by setting MOT_SPIN_ARM to 0.1 resulting in 1. After arming, the SITL copter shot up in the air and after the disarm timer had elapsed it fell down again.
I guess this is a problem with systems set to use decimal comma as a seperator by country default.
Missionplanner does issue a warning when using the full parameter list, but this should be catched by an additional check in MP.

Interesting, I use Beta (1.3.74 (Build 1.3.7700.1763)) And it color the value red and does not update it if I use comma instead of period or vica versa. I recommend to update to latest beta and try again.

I updated to build 1.3.7735.18819 and still no red warning for a decimal point value.

Before posting I was looking in the forum, for other users with the same issue, and I found people that had MOT_BAT_VOLT_MAX=124 and some other values with out the decimal point. I think that those wrong values come from the same issue. I have the same problem with any parameter, not only with the MOT_SPIN_XXX

As every windows app, MP relies on regional settings for correct decimal format.

As integrator of UAS with multiple clients PC’s with different settings, I use a simple but working tip for peace of mind.

I copy a decimal value from another parameter or just leave the decimal intact point or comma while change the desired value. I follow this tip also when I tune in the field with my own gear, since I don’t want let’s say a rate p from 0.150 end up 150!

Better/smarter tips like the red marking would be great to have.

It is definitely a strange behavior of the .NET framework handling international formats.
A quick workaround (which is defintely not a solution) to DO NOT USE zero in front of number smaller than zero.
comma, period handling seems to work normally with no trailing zeros.
Unfortunately with numbers larger than zero it does not work. :frowning:
I’ll check what can be done.

The common denominator. Now I can reproduce that.

Ok, found the bug and submitted PR’s to fix it.

Hope @Michael_Oborne will check and merge them soon. After that you will be able to update to newest beta and test it.