Boot-up in Vplane

Good Morning,
The following scenario exist and happend over the weekend.

Touch on, power up the neo, bluue flashing. select the battery on the touch, blue still flashing, Touch bound and ready, blue flasing, move elevator stick, instant green. BUT !!! Elevator assumed a new neutral/central position, DOWN ELEVATOR. Power down the Neo.
Start again with same sequence. After batt was selected green on neo and all well.
We then tried to simulate again on my friends Vplane Neo by holding aileron when neo was powering up. Same result, Aileron has new neutral/centre position.
I was under the impression this is not possible as during the Neo booting and binding NO INPUTS are accepted from the TX.
Feedback will be great as I assume this is a BUG never highlighted.
Thanks

Hi,

well, think coming from the heli, what would/should you do?

a) leave the radio alone (you must not move the sticks so the VBar can learn the center positions)
b) leave the model alone (it must not move so the sensors will settle and we can learn the center positions)

If you move the model or the sticks, the log will show "Init failed, retrying ...".

With planes, where you are maybe used to switching on with the model and radio in your hands, or with the model wobbling on it's undercarriage, or a gilder moving on the ground with wind, it can be more challenging.

You can beat the logic, or coincidence can beat the logic, so the NEO will learn center positions with an offset, but it's very rare and difficult.

If in doubt, and/or if there's anything odd when pre-flighting your model, power cycle the NEO and be more attentive, pin down the model/fuselage if it can still move, lay a helicopter on it's side if necessary (mind standard mode initialization if w/ Rescue).

It's different, with gyros, than without, and it's different than compared to other radios, where stick positions and trims are something defined in the radio, not learned at power on by a control loop which depends on it.

Kind regards

Eddi

Born to fly ...
forced to work.

Hi Eddie,

With everything stored in the neo, settings , etc the question is why should it learn a new centre ? While booting should the RX processor not start after all critical processes has started sucsessfull ? Only asking.

I was under the impression that while the booting process is running NO inputs can affect the settings/ centre position. Are we learning new thing it looks like it ?

Your (b), yes that is true. And when the wind is blowing a plane does take longer to initialize because of movement. Specially a very lighy plane.

Hi again,

center is critical, because you want it to be precise, and you don't want to run high dead-bands.
So it's part of the drill to learn the sensor centers as well as the stick centers, at power on, at the given ambient conditions.
Could have been 20 °C at your workshop, and 5 °C when you go fly.
Plus, you could have re-calibrated the sticks between two flights, what good would stored centers do?
Plus, bind and fly, you could be using a different radio?
Too many if-thens, then.

There's one fail-safe built in: in case of brief power losses, like instantly recovered brownouts, or like loose contacts, the NEO (actually any VBar) will perform a warm start.
This means, the last-learned calibration data will be re-used, so you still have the chance to save the model.
But you could still experience some drift, if the sensor centers would deviate from their last center positions, under such adverse conditions.
Initializing the gyroscopes mid-flight would lead to certain crash.

It's never been different, so maybe the perception was a different one. If we know that even one click of trim or sub-trim, on legacy radios, can cause a small drift, because it's interpreted as a tiny stick input, the same would apply for sticks held out of center.

There's another fail-safe, by the way: at power-on-self-test, if the stick deflection is way off, or if the sensor centers are way off, compared to the expected center positions, the VBar will warn (log file, 30+ collective pitch twitches etc.).

Both fail-safes have been there like forever.

So what you are noticing is perfectly normal (to me ) and can be remedied by power-cycling the model and by making sure that the electronics get their 2-3 seconds to initialize. If the init takes unusually long, if you see repeated 'retrying' in the log, start over, because like I said in the first reply, the logic can be beat accidentally or coincidentally, that's also why a brief pre-flight-check is always a good idea, and if there's something odd, don't act a hero, better double-check.

—Eddi

Born to fly ...
forced to work.

Thank you Eddi for the detail.