Neo IMU Sensor Fail error on initialization

These errors have been showing up since early March on some users unit's there is a long thread on the Helifreak forum regarding this. I haven't experienced it on any of my 6 units but there appear to be more frequent reports of this.

I am starting to get concerned since I have a number of events I plan on traveling to which will involve expense, fuel, lodging and time, not to mention the potential lost opportunity to fly.

Could Mikado please speak out about what they know regarding this issue.

IMU Sensor error leading to failed init issue.

What are we supposed to do?

Fall back to Pro without Rescue? (if so 6x 89 euros wasted in my case and invalidating the primary reason for going to Neo's)

Ignore it and hope if we reinit enough times it's going to work? Is there risk in flight if we do this?

Send our units back and do without for some period of time?

Shelve the fleet until new firmware comes out?

Fall back to prior Firmware with rescue?

This is shaking my confidence in the product.

I sincerely hope that this issue gets put to bed soon so I can start to rebuild the trust in Mikado Vbars which in the past of set the bar for solid reliable products.

Hi,

well, it's still difficult to make a statement.

I would fall back to Pro _if_ I run into the issue, else I would not worry. We are working on a solution which possibly-hopefully only requires an update. So the money would not be wasted, it just requires a little patience.

Returning the devices makes no sense at the moment, since a new device on the same model as often as not shows the same symptoms, the cause of the issue seems to be vibration which interferes with one the sensors. Sometimes it recovers by itself, sometimes a tap to the device does the trick.
The sensors seem not to be damaged permanently, they just seem to hang temporarily.

Here in Germany this happens to > 90 % on TDR 2 for example, so select pilots of those are our test group.

There is no risk in flight, if the init is OK, all is well. If the sensor hangs in flight, the other one (which is not affected at all) takes over, which it already does all the time on and off, depending on the G loads.

The prior firmware would not help, to the contrary: it does not detect the issue, and if you trigger rescue with a sensor not properly initialized, that would be a risk.

Bottom line, you can trust the gyro sensors without worries, and also the rescue sensors if the VBar initializes OK.
If you want to make sure you don't run into issues e.g. on events, run Pro for the time being.
We will provide a solution once we are sure we have identified the proper cause and tested that the solution works properly and safely under all circumstances we can think of.

Kind regards

Eddi

Born to fly ...
forced to work.



Edited 2 time(s). Last edit at 05/24/2016 05:29PM by Eddi E. aus G..

Well - the medal has always 2 sides:

Thinking over a few issues with rescue (and we have way less than others) - we found out it would be a good idea to monitor the IMU sensors during startup. As soon as we detect obviously strange values we set this error. So - our new monitoring is definitely the right way to warn pilots using rescue in flight.

Some background info - we have additional high range sensors which are used in flight after calibrating them with the low range (IMU) ones. So - even if the low range sensor gets weired values in a flight - it is safe to trigger rescue because it was calibrated previously with correct values and works on the second sensor set in flight.

This is way more safety as other FBL manufacturers have - but has currently the disadvantage showing up a few IMU errors with our new pre flight checks. This IMU unit is used by all other brands too - but obviously not monitored that strong as we do. But we think - safety first.

In general - the units are not damaged and must not be replaced. It is just a question of time unless we have a solution - but testing isn't easy as most of our helis do not show up this issues. But - the reason for this issue itself depends on the heli as it seem to be now. So another reason why replacing the NEO would be only a temporary fix. All the sensors are micro mechanics inside - we just have to figure out what would be the reason to force them into wrong values into flight which are the reason for the IMU error at the next powerup.

So - if you want go flying - use pro w/o rescue, this is safe. And - as soon as we will have a fix we'll keep you informed here or by mail for registered NEO's.

regards (EN) / Gruss (DE)

Rainer Vetter

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Posting and answering - please use a PC and a standard keyboard. Answer all questions fully, take the needed time, don't forget probably requested attachments.

Für Posts und Antworten bitte einen PC und eine richtige Taststaur benutzen sowie alle Fragen vollständig abarbeiten. Nehmt Euch Zeit, beantwortet Rückfragen in Ruhe und vollständig.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Für Einzelkommunikation bitte ausschließlich Email verwenden! - PN, Messenger, Chat usw. werden nicht bearbeitet.
For single user communication please send a email only! PM, Messenger, Chat etc. won't be read.

Eddi has won!

regards (EN) / Gruss (DE)

Rainer Vetter

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Posting and answering - please use a PC and a standard keyboard. Answer all questions fully, take the needed time, don't forget probably requested attachments.

Für Posts und Antworten bitte einen PC und eine richtige Taststaur benutzen sowie alle Fragen vollständig abarbeiten. Nehmt Euch Zeit, beantwortet Rückfragen in Ruhe und vollständig.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Für Einzelkommunikation bitte ausschließlich Email verwenden! - PN, Messenger, Chat usw. werden nicht bearbeitet.
For single user communication please send a email only! PM, Messenger, Chat etc. won't be read.

Happens rarely enough

Born to fly ...
forced to work.

Thank you so much for the additional information. This is very helpful.

Please allow me to ask a follow up question.

Eddi stated

" the cause of the issue seems to be vibration which interferes with one the sensors. Sometimes it recovers by itself, sometimes a tap to the device does the trick. The sensors seem not to be damaged permanently, they just seem to hang temporarily."

Does this mean that something happened during the previous cycle or flight that then causes the sensor to fail to initialize properly the next time it is powered up?


Can the information in this thread be posted over in the thread on Helifreak forum where there are a number of vbar users that are concerned with this issue?

Thanks

Regards

Shadco



Edited 1 time(s). Last edit at 05/24/2016 05:56PM by shadco22.

Hi,

the issue comes up in flight obviously. If the sensor still hangs when you power down the model, chances are that it still hangs on the next power up and the error message is raised.

Feel free to link to this forum, but please understand that we can't be present on all the public forums (of which HF is only one) and keep track of every discussion so it does not go the wrong way by misunderstanding or inaccurate wording from us (we are not perfect ), we simply don't have the resources to stay on top of topics everywhere.

The Café is public so even people who don't have registered here or don't want to can read.

Kind regards

Eddi

Born to fly ...
forced to work.



Edited 1 time(s). Last edit at 05/24/2016 06:20PM by Eddi E. aus G..

Eddi

Thanks

I will link to this thread so that I don't confuse this topic.

Regards

Shadco22

hey guys,
a few questions, please:
1) if the sensor is micro mechanics inside and these micro moving parts are jammed, how will a new firmware fix a hardware problem?
2) can i run it with rescue safely if the unit starts up ok?

Quote:

There is no risk in flight, if the init is OK, all is well.

Quote:

If you want to make sure you don't run into issues e.g. on events, run Pro for the time being.

3) why are some guys reporting complete failure of rescue even when the unit initializes normally?
thanks.

1 - we are just doing some research, maybe Uli will write later how we can - maybe it is a company secret. For the customer side - a correct init is the counting part, not how it will be done.

2 - yes

3 - we just watch our RMA system - and there is way less with the new calibration. Reports in other forums don't have all needed infos and also the hardware wasn't in our shop for checkup. Sometimes pilots think the rescue fails - but checking the log etc. will point us to sometimes other things which are not NEO related. This isn't posted in most cases as result in other sources. Also Pilots may start threads in multiple forums instead in one "the right one" (THIS) forum.

regards (EN) / Gruss (DE)

Rainer Vetter

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Posting and answering - please use a PC and a standard keyboard. Answer all questions fully, take the needed time, don't forget probably requested attachments.

Für Posts und Antworten bitte einen PC und eine richtige Taststaur benutzen sowie alle Fragen vollständig abarbeiten. Nehmt Euch Zeit, beantwortet Rückfragen in Ruhe und vollständig.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Für Einzelkommunikation bitte ausschließlich Email verwenden! - PN, Messenger, Chat usw. werden nicht bearbeitet.
For single user communication please send a email only! PM, Messenger, Chat etc. won't be read.

1) The micromechanic is not jammed, it just hangs at the end of the travel (only one of the 6 internal sensors, and always the same one). With some interesting treatment the sensor can be released, and then it works absolutely fine again.
We still look why this happens, and then we can say if, how, and when we can solve it. The sensor manufacturer does not state this effect in the datasheet (of course not ) so we are on our own to find out the reasons. If we are not successful with this, we will confront Invensense with the issue. Please understand that this may take some time, but it will be important for all other manufacturers that use Invensense sensors in their FBL Systems as well (afaik all).
Luckily NEO has an second sensor, that is used for the rescue in flight. So the Software has some possibilitys to decide when and how the sensors are switched. So a software fix is indeed possible. The second sensor is of a different manufacturer (Analog Devices) and very different parameters, and does not have this issue at all.

so long ... Uli
http://www.vstabi.de



Edited 2 time(s). Last edit at 05/26/2016 10:26PM by ulrich.

Thanks for the information Mr. Ulrich Please keep us informed about Mikado's work on this issue..

Appearently, there might be a batch of "defective sensors" from InvenSense. Because, all Neos don't have this IMU Sensor fail error, only some of them have...

What i want to ask is; Is there a work about determining that batch? For example, you can announce something like; "Dear Vbar Neo owners who has serial numbers between .... and .... , please be careful because your rescue sensors may be distrustful."

I have two Vbar Neos. One of them came with Vbar Control and i'm pretty sure about it. It's one of the earliest production and no imu sensor error yet

Other one is quite new, and actually i'm not sure about it. I'll keep my eyes open when i'm using it.

Hi,

to my knowledge there is no relation between ranges of serial no.s and the issue. There are early production devices which have been working inconspicuously in the past, and when moved to a different heli with different layout of the electronics, different vibration levels etc. suddenly the issue comes up, and repeatable.

On the other hand, units affected often work properly again when we receive them, only the tell tale event log entries remain, and if we put them on one of our models and test fly, we do not get the error message. Sensor raw data, also when monitored during flight, are exemplary.

Once the device is back on the customer's model—zap—error message again.

It points very much to vibration and/or electrical interfering fields which are more or less built into the design of some models and not or not enough into others. Minor differences in mounting position, pad, wiring, components, whatever also seem to make huge differences: although in Europe the most cases are TDR 2 related, there are enough TDR 2 flying without any issue and there are also a few cases where the error comes up, on other models.

Quote:

rasheem
please be careful because your rescue sensors may be distrustful."

With the latest software update which most units have already installed anyway, the initialization is monitored more closely.
So if you get the error message on the ground, you don't fly, no risk (but the fact that it's annoying ...).
The mentioned tap to the device might free the sensor, and you can fly again, no issues to be expected.
If the issue comes up in flight, the other sensor takes over, so no risk to the model.
Although a guarantee for all imaginable situations is hardly possible, also because of all the other 'variables' on a model helicopter, we can pretty confidently say: if it initializes properly, all is well with this regard.

Kind regards

Eddi

Born to fly ...
forced to work.

ulrich Wrote:
-------------------------------------------------------
> We still look why this happens, and then we can
> say if, how, and when we can solve it. The sensor
> manufacturer does not state this effect in the
> datasheet (of course not ) so we are on our own
> to find out the reasons. If we are not successful
> with this, we will confront Invensense with the
> issue. Please understand that this may take some
> time, but it will be important for all other
> manufacturers that use Invensense sensors in their
> FBL Systems as well (afaik all).



Is there any progress??

Regards,

It looks like a workaround for the initialization issue has been implemented in the 6.2 release. The VBC instructions say

"In case of getting error prompts about the rescoe init at the Z-axis which can't be solved (usually stiff mechanics, vibration issues) a alternative init can be chosen here. Therfore the heli has to stand upright (+-45 deg) during the init. The swash bumps 3 times if the use of the alternative mode was necessary."

I want to make sure I understand how this works. If the NEO fails to initialize, after tracking down any mechanical issues, we can now select Standard initialization mode and then initialize with the heli stood with the tail nearly vertical. Three pumps of the swash will indicate that Standard mode was used.

Will there be any adverse effect to the rescue functionality if Standard mode has to be used?

If it is set to Standard mode, will it first try to initialize in Precise mode first and then fallback to Standard only if Precise fails?

The only adverse effect is - you can't init a model laying on the side or skids up.

Of cousrse - the virtual Z mode will only be taken if needed ;-)

regards (EN) / Gruss (DE)

Rainer Vetter

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Posting and answering - please use a PC and a standard keyboard. Answer all questions fully, take the needed time, don't forget probably requested attachments.

Für Posts und Antworten bitte einen PC und eine richtige Taststaur benutzen sowie alle Fragen vollständig abarbeiten. Nehmt Euch Zeit, beantwortet Rückfragen in Ruhe und vollständig.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Für Einzelkommunikation bitte ausschließlich Email verwenden! - PN, Messenger, Chat usw. werden nicht bearbeitet.
For single user communication please send a email only! PM, Messenger, Chat etc. won't be read.

Hi...I had this with a new White Neo when I first built my TDR2, so at the time I took it off and put on an older Blue Neo. But then I got the same error with the Blue one, so I powered it up again and proceeded to hit the Neo while it was initializing. I have realized the error usually occurs when the sensor is not part of the pcb assembly. Manufacturer should always embed it on the board because adding the separate sensor is not efficient at all.



Edited 2 time(s). Last edit at 12/16/2021 04:43PM by AnnyMore.

Ho Eddy, sorry i have a similar problem with one of my 5 VBAR NEO. Well, when i run-up the model, the vbar neo blink red, and after in the log it shown: the imu sensor fail. After many time i have tried to reset the set up but the problem l. Did you have some idea to problem solving? In apperance i have alla control of the model and the vbar work correctly; rescue work in correct mode. But the vbar blik red all time.

Thanks

Adrenalyn

Goblin Kraken/Xnova Tareq 550kv/Hobbywing 200ESC/MKS Servo’s
Goblin Kraken/Xnova Tareq 550kv/Hobbywing 200ESC/Kst
Servo‘s
Goblin Kraken Nitro/O.S. 105 HRZ/MRCI Muffler/MKS Servo’s

Mikado Vbar Control Touch/Vbar Neo Pro



Edited 2 time(s). Last edit at 07/23/2019 04:17PM by Adrenalyn.

Hi,

if you get a warning (like red or purple blinking), you should not fly. There is a reason for it, and – worst case – something can go wrong, causing damage or physical damage/injury.

By the way, you are resurrecting a year-old thread

Now, there's two things:

. if it's the known z-axis issue, switching to Standard Initialization (and leaving the setting there) will do the job. This does not just hide the error message, but actually circumvent the cause, so flying and using Rescue is safe.

. if the issue persists, and if e.g. a test with a know-reliable power supply makes no difference, we should check the unit at our service shop.

But again, please only fly if everything's safe, green light. If you run the red light, and get hit by the truck, figuratively speaking ... you know.

Kind regards

Eddi

Born to fly ...
forced to work.

Thanks Eddy for your assistance!

Ok: i have tryed to:
-Rescue in standard MODE: 3 pitch pump and have a gren light
-AGAIN: PRECISE RESCUE MODE: again bkinking RED for few moments. After it's stop the pitch pumping but persiste the red light blinking

Try start up in 45° position; 90° position but the result don' t change



Adrenalyn

Goblin Kraken/Xnova Tareq 550kv/Hobbywing 200ESC/MKS Servo’s
Goblin Kraken/Xnova Tareq 550kv/Hobbywing 200ESC/Kst
Servo‘s
Goblin Kraken Nitro/O.S. 105 HRZ/MRCI Muffler/MKS Servo’s

Mikado Vbar Control Touch/Vbar Neo Pro

Hi,

Rescue in Standard Mode is OK. The triple pitch twice informs that the alternative initialization is in effect, and that's it. Green light, go fly.
Back to Precision, the VBar is forced to have all the sensors ready, so it can not safely initialize and warns with the 30+ pitch twitch, red light.

Cause for the issue is vibration on the flight before, causing the z-axis sensor element of one of the accelerometers to temporarily stick (mechanically).
Knocking on the VBar will probably release it, but with Standard initialization, we can work with the remaining 5 out of 6 sensor elements to initialize anyway, and safely.

Nothing to worry, I would not dare saying that if it was not proven over the years, by experience.

But if Standard is in effect and the VBar warns anyway, or if you see a red or purple light on the VBar NEO, you'd have to investigate anyway.

Kind regards

Eddi

Born to fly ...
forced to work.

Hi Eddi!
The problem was solved with the Knock-Knock Technic on the vBar

Adrenalyn

Goblin Kraken/Xnova Tareq 550kv/Hobbywing 200ESC/MKS Servo’s
Goblin Kraken/Xnova Tareq 550kv/Hobbywing 200ESC/Kst
Servo‘s
Goblin Kraken Nitro/O.S. 105 HRZ/MRCI Muffler/MKS Servo’s

Mikado Vbar Control Touch/Vbar Neo Pro

Hi again,

you can skip knocking if you leave the setting to Standard

Then, two cases can occur:
a) all well, single pitch twitch, so-called Precision initialization with all 6 sensor elements
b) IMU z-axis sticks or hangs, triple pitch twitch, so-called Standard initialization with 5 sensor elements plus mathematical solution – this is just an information and a reminder that the model must stand on it's skids, not lay on it's side or stand inverted, _because_ we have to assume 'up is up'.

Green light, go fly, enjoy.

Best,

Eddi

Born to fly ...
forced to work.