Is there anyone that has time to review this bin file to let me know what’s going on?
Since the latest update and revert to previous 3.4 unstable my aircraft has flown like garbage.
Symptoms:
Altitude hold is terrible, bounces everywhere. when armed it takes nearly full throttle to get off the ground then it wants to decend almost immediately.
Baro, is covered per instructions but I can watch alt climb and fall to like -12ft or +12ft while sitting still.
Once it gets over 50 ft it seems to hold decent but still bounces by a few feet from time to time.
The aircraft “sounds jittery” I know not a technical term but it has some slight quirky sounds coming from it as if it’s catching interference from elsewhere, like I don’t feel like it’s under 100% control.
Something is definetly wrong with it right now and if anyone has the heart to review the file and let me know what you come up with I’d appreciate it.
I feel your pain, and I wish that I could help, but I too am awaiting a response from the developers. The last I flew, I too had althold go all wonky on me, even after disabling the secondary compass. I’m assuming that it’s tied to a common compass variance issue: 3.4rc1 - #15 by i-copter
The thing that bugs me the most is that I was flying just fine about a week ago, and my foolish self hadn’t made a backup image before starting a fresh build
Edit: Your log looks okay. I think it is normal that althold results sometimes in fluctuating altitudes. Moreover, the GPS altitude matches the barometer altitude. I think it is not a sensor problem. Could it be the PIDs?
Input direct x8r sbus. Externally mounted receiver within line of sight. Was running a cheap turnigy ppm rx and TX but it would throw erroneous errors worse than this.
Would pids make the aircraft dip so poorly? I was under the impression pids was adjusted as a correction type to how you wanted the aircraft to feel from the input from the TX, not while it was under a loiter or alt hold. Please correct me if wrong, I’m open to being taught something new lol
The PIDs are the most important instance to keep the device in the air. Mistakes here can lead to a multitude of problems.
I guess you have a very big copter, so there is the fair chance that you need to tune the PIDs if not done already. I cannot exclude all potential problems, but it looks like the sensors are fine, and the most likely issue is the PID for ALT_HOLD. If your copter is overpowered, then maybe reduce it a bit and check whether the repsonse is better. Also check the GPS and Barodata in the logs.
… taking a look to the desired altitude in the log, the barometer data even matches this value. I think everything is fine, can it be that you just continuesly played with the channel 3 and wondered that the copter changed the altitude, because you shifted the target height?
The quad is approx. a 550 frame custom built you can find an image of it on black ops maiden flight under projects. It “feels” like it’s getting erroneous inputs from the TX. When I take off it climbs up as it should but then lowers back to the ground I must then counter with 100% throttle and it climbs fine back up. I can add more throttle once it levels out but it climbs sluggishly then shoots up without input or lowers on its own. Pids can correct that? Maybe I should send a link to a video so y’all can see what I physically see. I’m all about correcting it, if it’s user error I have a lot of time tied up in this build and definitely want it right, just don’t want to go on a goose chase.
The truth is, I’ve never hooked it up to see what the amp draw is. So I never did the current draw setup in mp so it never reads amperage. This AC is closer to a 2Kg with the battery and it is a 6S
I have found the solution to my problem. The RPI3 is wifi enabled standard from the factory.
I found a link to disable it and have incorporated it into my rc.local file to disable it on boot.
Interference from the wifi module was throwing everything off. I have attached some videos for you guys to view. Please don’t judge me on my Southern accent lol! It sounds worse when I hear it myself.
I’m still running 3.4 unstable until the compass issues are resolved on on 3.4-rc1.
Look in inconfig and see which wifi device is running.
Mine was wlan0.
I used command - (sudo ifconfig wlan0 down) and it terminates it. So I added it to rc local.
This is the link for the data I gathered. Let me know if it helps.
I also disabled the WiFi by setting the kernel modules into the blacklist. I use instead a 5.2 Ghz WiFi AP (using an Alfa dongle). Hope 5.2 Ghz interferes less.
These are the videos with internal Wi-Fi disabled, right? Have you noticed any correlation between Wi-Fi and radio decoding on a bench? This is a simple test to perform which will be extremely helpful.
I’ll get it this evening