Hi.
I have had a spare uSpirit in my drawer for probably 18 months.
I have also had a spare Oxy 2, the 190-plastic kit.
Now I finally decided since I have all these spares (spare motor, esc, etc.) that I would build the Oxy2 - 190.
After fitting the uSpirit, I did a backup of the banks from my existing Oxy2-215FE with the uSpirit. I restored those banks to this new uSpirit.
I then upgraded the firmware on the new uSpirit, and since I have been trying it out in the garden I have had some very weird behaviour, and it's probably 50% of the time too.
Here's what has happened:
I was briefly pressing the rescue switch yesterday while in the air and then all of a sudden I lost all cyclic control. It just stayed flat after releasing the rescue switch. I killed throttle and it landed fine - was only 1.5m off the ground.
After that, I have powered down and back up, and found really weird cyclic behaviour, like the unit is disorientated. It wants to drift to the front or the side massively.
That was a few days ago.
and just now, I flew over the grass for a bit, then landed a bit badly (my fault), then back inside the house after checking everything over, I reconnected the power, let it stabilise/initialise, and took it in the back garden again. Right away it nearly tipped over and scrapped the edge of the blades. When I look at the swash, it will not response to back-cyclic at all. I look at it for a while, and I realise that it's because the uSpirit is holding back-cyclic all the time. I spend a while looking at it, tapping the rescue switch (which correctly gave flat-and-up to the swash), but still, it reverts to aft-cyclic by itself. So I am wondering, have my servos gone loopy and jumped teeth or something, but no, I disconnect the power, re-connect the power, and all is fine, and I fly in the garden for a minute.
WTF ? Any ideas ?
I am using a Jumper R1 receiver (FrSky clone) and am using sbus for servos, and have the FrSky integration cable attached, and the Hobbywing rpm is also connected to the uSpirit.
uSpirit, upgraded to 3.1.0, weird cyclic, lockout, disorient
Hello,
please try to perform BEC test and check what will happen.
Possibly it seems like the BEC have not enough power which can cause unit to lock as it falls under 1.8V.
With BEC test it might be easy to check if this is the case.
This should be identical with any firmware version.
please try to perform BEC test and check what will happen.
Possibly it seems like the BEC have not enough power which can cause unit to lock as it falls under 1.8V.
With BEC test it might be easy to check if this is the case.
This should be identical with any firmware version.
Spirit System developer
OK I will give it a go and let you know in a minute.ZeXx86 wrote:Hello,
please try to perform BEC test and check what will happen.
Possibly it seems like the BEC have not enough power which can cause unit to lock as it falls under 1.8V.
With BEC test it might be easy to check if this is the case.
This should be identical with any firmware version.
I am using quite a big battery, and the ESC is set to 6v output, but maybe I did something wrong somewhere. I think I have been pretty tidy and careful with wiring though.
lots of waffling, but maybe you can see some odd behaviour here:
https://youtu.be/nHXYPEPS3QA?t=471
https://youtu.be/nHXYPEPS3QA?t=471
Thank you very much for the video.
First from all I recommend to not move with the model during initialization process. The model must be absolutely without any movement once battery is connected.
And also during this process it is very important to not move with sticks at all. Because also stick centering calibration is ocurring at the same time.
There is a chance that this could be reason for the issue.
I will send you private message with another thing you can try.
First from all I recommend to not move with the model during initialization process. The model must be absolutely without any movement once battery is connected.
And also during this process it is very important to not move with sticks at all. Because also stick centering calibration is ocurring at the same time.
There is a chance that this could be reason for the issue.
I will send you private message with another thing you can try.
Spirit System developer
Thanks Tomas. I got your message and I will try the thing you said when I'm back at home tomorrow.ZeXx86 wrote:Thank you very much for the video.
First from all I recommend to not move with the model during initialization process. The model must be absolutely without any movement once battery is connected.
And also during this process it is very important to not move with sticks at all. Because also stick centering calibration is ocurring at the same time.
There is a chance that this could be reason for the issue.
I will send you private message with another thing you can try.
Now that I look at my video again, I see that I did wiggle the cyclic stick at initialisation time.
The reason I was doing this, was to check if the unit was initialised. I normally just wait for the beep, but it seemed to take a long time for the beep, so I was wiggling the stick to see if the cyclic was responding, i.e. if it was initialised or not.
I think there is a chance that, like you suggested, I may have caused a miscalibration of the cyclic centre-points by doing this.
But, it did take a long time, which is what made me do that with the sticks.
Has the time to initialise increased on startup? Maybe it's just not what I'm used to, which caused me to wiggle the stick to see what was going on ?
You can see it here..
https://youtu.be/nHXYPEPS3QA?t=482
I have just checked, and yes, this causes the behaviour every time, so it's my fault!
I still wonder what happened with the rescue getting stuck-on as well though ? that was while in the air at about 1.5m height, the cyclic stayed locked-out as though it was on rescue. I had to hit throttle hold.
I'll keep checking things over anyway!
The reason I was doing this, was to check if the unit was initialised. I normally just wait for the beep, but it seemed to take a long time for the beep, so I was wiggling the stick to see if the cyclic was responding, i.e. if it was initialised or not.
I think there is a chance that, like you suggested, I may have caused a miscalibration of the cyclic centre-points by doing this.
But, it did take a long time, which is what made me do that with the sticks.
Has the time to initialise increased on startup? Maybe it's just not what I'm used to, which caused me to wiggle the stick to see what was going on ?
You can see it here..
https://youtu.be/nHXYPEPS3QA?t=482
I have just checked, and yes, this causes the behaviour every time, so it's my fault!
I still wonder what happened with the rescue getting stuck-on as well though ? that was while in the air at about 1.5m height, the cyclic stayed locked-out as though it was on rescue. I had to hit throttle hold.
I'll keep checking things over anyway!
The initialization time is dependent on if you are moving with the model or not during this process.
If there is a model movement then it could have an impact on the flight performance, including rescue and stabilisation.
Stick movement during initialization could result even in unwanted model movement - as when you set a trim after initialization at your radio but forget about it. This could lead even to a crash.
Nothing changed from verison 2.8. or a previous in this behavior.
If there is a model movement then it could have an impact on the flight performance, including rescue and stabilisation.
Stick movement during initialization could result even in unwanted model movement - as when you set a trim after initialization at your radio but forget about it. This could lead even to a crash.
Nothing changed from verison 2.8. or a previous in this behavior.
Spirit System developer