Internal errors 0x100000 I:921 flow_of_ctr Twitching motion in loiter during forward flight

This is a follow up post on:

The internal error in the title appeared along with the symptoms described in the initial post. It has come to my attention that the same internal error appeared on the new rover release as well. I got the suggestion to create a new post to bring the attention to this internal error in particular.

To read about the behavior in flight, pleas read the linked post.

This is the initial log file where the issue first appeared (the first flight of 4.3.0)

Second log file after parameter PSC_VELXY_FLTD was changed from 5 to 2.5

Flow of messages


Is a flow of control error related to the gps amd the position controller?

I use gps for altitude.

There was a parameter added to control when to use the gps value for altitude and when to fall back on barometer. I havent set this parameter.

Is the flow of control error related to gps height estimation in any way?


I switched back to using barometer for altitude. The issue of the repeating jerks is still there and the internal error is still there (the same one) although the jerk movements occur less often.

I also changed PSC_VELXY_FLTD back from 2.5 to 5 (default value)

Log file:

@xfacta @rmackay9 @dkemxr
I saw that you randy posted that this internal error of flow_of_ctr was going to be investigated. What I would like to ask you guys is if there is any value in me doing tests for you, since the issue is so apparent in my case, or if I could go back to 4.2.2 until this is resolved?

If me helping with tests would make it easier to solve this, I can assist with that, but if not, it would be
nice to be able to fly normally again.


What has happened before is a new release has a different level of error detection and there is no real “issue” just a different way, or a more stringent way, of detecting what was always there. I don’t know if this is the case with this message but the Dev’s know about it so we’ll see what happens. Personally I wouldn’t revert back. I would probably load the latest Dev version on a craft and see what happens :slight_smile:

Case in point is the “failure to level, manual tune may be required” for Auto Tune. I think some asked if this was a Bug because it wasn’t seen in the previous release when run on the same craft. Well, no…

1 Like


I’ll stick to the latest than. I thaught there was no dev versions yet. I thaught that you guys worked on 4.3 untill it was ready, than moved to make 4.3.x beta firmwares

I’ll look if there is any beta avalible.

Also, if this is a timeing error, does that mean my fc it too old? Or not precise/exact enough, so that I will have to get a new one? I’m running a cube black at the moment

The Dev/Master version is 4.4.0-dev. New features are untested by users, that happens at the Beta level. But it’s available in the “Latest” directory for the non risk averse.

So pressing the load beta firmwares in missionplanne wont give me the latest beta than?

No, but pressing Ctrl>Q will.

Pressing ctrl and Q won’t show me anything in my missionplanner

Left click anywhere in the screen and then hit Ctrl>Q and you should see this:

When you click OK they populate to this:

Heed the warning!!

1 Like

Ah! Now it worked!

Is there anywhere I can read up on what new features are being tested and report findings and resd about issues?

When do a beta firmware get it’s own topic here? I’ve seen some 4.3 beta firmware topics

I also saw this

could that be a solution, or just hide the issue in some way, or maybe it’s bad to drop the rate frequency

Hi Dave,

I haven’t got tested on 4.4.0 yet, but I wanted to ask you about the beta firmware button.

If I press it i get 4.3.0 beta. I’ve read about, see below, 4.3.1 beta1 for example. How do I get that one? And if I press the beta firmware button, what does it really do? Since ctrl+Q gets me the dev beta?

I’ve been reading a bit on github about the issues related to 4.3.0. I can see that the resolved issues has a note that says that on for example is resolved in 4.3.0 beta2 and another in 4.3.1 beta1. What does that really mean?

Are both this issues resolved in 4.4.0 than? And is the one in 4.3.0 beta2 resolves in 4.3.0 stable?


There is Beta and there is dev or Master, they are not the same. dev/Master is the development release, not really for common use by users. Developers play in this ballpark to add and test new features. Beta is generally safe to fly but that’s a personal choice. Sometimes new boards or desired features are added to Beta or dev/master and you have no choice.
Here is the best way to get the release you want:
Go here and select Stable, Beta, or Latest (which is yet another term for dev or Master)
Copter Firmware
Then let’s say you picked Beta and you have a Cube Orange and select that:
Cube Orange
Open the “git-version.txt” file and see what Beta version it is. In this case today it shows the Stable version so there is no Beta version available. But, say you want to install this anyway. Download the .apj file and then use Mission Planners “load custom firmware” option to flash the board.

I see no evidence the issue(s) has been resolved in any release.

1 Like


That bring a lot of light to things!

I’ll keep an eye on the github 4.3.0 issue list and see if/when the floew_of_crt issue gets moved to resolved and what version I need to fix it!

You can monitor the Discord channel also. It can be messy with people posting in the wrong threads but the Development> #general_dev or dev-team (which the rabble can’t post to) can offer some interesting dialog. There is some chatter about this issue.

1 Like


Thanks, I’ll do!

This is a CubeBlack running three EKF. You are getting lots of long loops and this error happens when we detect that the position controller has not been run for 5 times the normal loop time. If you disable the third IMU I think you will get enough processing time back to keep up.


See how that goes.

1 Like


Has this always been a problem? As I understand it, it only shows as an error now because the checks have been made more strict?

@rmackay9 is working on a fix.

Would tht be a fix or just make the checks less strict for less processor powerful flight controllers?

This error has a number of causes. The main one we see is during start up where initialiseation processors run long and the position controller has been started already, this is just anoying but should be fixed. We would also see this error if some process was running very slowly for some reason, this could be a serious issue.

In your case I suspect it is simply you are over loading the processor on the autopilot. Every release we make things better but also increase the memory and processor useage. I think the features you have turned on are just pushing things just a little too hard.

So this error isn’t a problem with the position controller, it is a problem with other areas that is detected by the position controller.

I hope that by going from 3 EKF to 2 EKF you will have the extra processing time to keep up.

1 Like