Typhoon H – GPS „Acquiring“-problem
In the last few month in several drone forums Typhoon H user claim that they cannot start motors anymore. The GPS status remains in „Acquiring“ all the time. Change of GPS module did not help, change of flight controller (MCU board) seems to be the only solution. Often user reported that the problem occurred when they didn’t use the drone for month. But there also cases where the problem appears during normal use.
In this case there are strong indications that the problem starts with a behavior that the drone resits to land and could not brought down. This also a known fault that was reported lately.
I followed some of those fault reports in the forums, checked flight log data and at last got some MCU boards from generous donors. I could reproduce the “Acquiring”-problem.
The five main symptoms are:
1. GPS status stuck in “Acquiring”. The drone cannot be armed anymore.
2. Motors will also not start when GPS was switched off. This unusual behavior can be used as
quick test to identify the fault.
3. Altitude on ST16 shows some meters below zero and did not initialize. The pressure
sensor’s height estimate is OK, near zero at this time.
4. The “Yaw” output in the GUI is slowly rotating while sensor values from accelerometer and
gyroscope do not change constantly in one direction as Yaw is doing.
5. Accelerometer Z-axis has a value far below 1000mG. This is wrong because we have 1G on
Wrong
earth. This indicates the root cause of the problem: ACCEL_ZOUT of MPU < 1000mG. GPS status and Altitude value:
2022-02-15 1/6
Yaw rotation:
1drv.ms/v/s!AtiK_DeOGL5sir0A2Rbx7y7Zq4-SHg?e=UTRLzF
Wrong magnitude (acceleration Z-axis)
Investigation environment
I investigated all seven MCU-boards that I got from generous people.
2022-02-15 2/6
No 1 was fine and got GPS lock soon. It was used to compare the others with a good one.
No 2 had the fault with all four symptoms mentioned above. Flashing firmware back and forth did not help. Put it into the freezer and brought it down to -10°C. Now the Altitude shown on the ST16 was -15m. It came up to -4m while the board warmed up but never reached zero.
Now the board was flashed with customized PX4 autopilot (Thunderbird firmware from Toni Rosendahl). It cames up, could be connected to QGroundControl. After proper calibration it could be armed and all looks plausible. Due to poor test system not flight test was possible.
But during soldering on the board I have destroyed a pull-up resistor. So, this board is crap now.
No 3 had the fault with all four symptoms mentioned above and has it still. Used for further experiments.
No 4 came with a defective IMU. Fault was reported by sound and red LED.
No 5 got GPS lock and looks OK so far.
No 6 came with mechanical destroyed quartz oscillator, does never came up.
No 7 came without IMU but came up and showed the same error indication as No 4.
At this point I decided to exchange IMU modules. MCU board No 4 got the IMU from dead board No 6. As result it came up and got GPS lock. This board looks good now.
Then I replaced the IMU on MCU No7 with the one from No2. Now the fault with all four typically symptoms was moved to this MCU board. It looks like the problems travels with the IMU module. To verify this I have exchanged the IMU with the one from No 4. Now it got GPS lock and works. Change back brings the fault back.
I’m pretty sure that the IMU is the reason for the faulty behavior. I think there is a charge of IMU modules that aging and run out of some threshold in the firmware. As result the EKF output for altitude and NED orientation is implausible and the pre-flight check fails.
This assumption is supported by some observations I did during my tests. When IMU was changed it appears that accelerometer calibration could not level horizon. Also massive compass warnings occur. This could solved by firmware downgrade and stay solved after upgrade to latest version. Same was reported by some user that could get GPS lock after downgrade firmware. For the faulty modules here downgrade did not help.
Final status: Two destroyed MCU-boards, two to reproduce the fault and three that seems to be good.
The “good-ones” are only checked in the test system.
In some cases the problem could overcome by downgrade the flight controller firmware to an old version. For the MCU-boards where I could reproduce the fault this didn’t work.
2022-02-15 3/6
I never did a compass calibration with the board except the Thunderbird. Flight test are still pending to make sure it could be used in a drone.
Conclusion: Fault is probably caused by aged IMU module.
Solution:
In rare cases GPS lock came after very long time (~4h) and faster at next try.
Sometimes it helps to downgrade the flight controller firmware. Not in all cases an upgrade
to latest firmware is successful after that, but sometimes this is possible.
MPU6050 contains a Micro Electro-Mechanical System (MEMS). Sometimes it helps easy
to knock on the IMU holding it in different directions (x, y, z).
The ultimate solution is to replace the flight controller module (MCU-board).
Proper accelerometer and compass calibration is always needed before and during trouble shooting.
2022-02-15 4/6
MCU-Board No 3 was flashed with Toni Rosendahls “Thunderbird” firmware.
github.com/tonirosendahl/Thunderbird
After first power on QGroundControl reported pre-flight check error due to unstable altitude values. Calibration of all sensors was needed. IMU calibration consists of three different parts:
Gyroscope
Accelerometer • Level Horizon
All three calibrations were done and pre-flight checks passed successful. Seems that more complex calibrations as done by QGroundControl can make IMU working. Unfortunately it is not possible to use this kind of calibration for MCU-boards with original Typhoon H firmware.
External access to MPU of the IMU
I have made an adapter for the tiny IMU connector in order to connect the IMU module to another device, in my case a Raspberry Pi.
Installed a program to calibrate a MPU6050 from here:
github.com/Blokkendoos/mpu-calibration
Then calibrated the IMU some times with this external program. Program says Calibration successful. But the problem persists, unfortunately.
I tried to calibrate another MPU6050 from a CGO3+ camera and this seems to be OK.
2022-02-15 5/6
At the calibration result from Flight Controlles IMU, I wonder what those spikes mean which appear during calibration without moving the IMU.
I have checked if there are possibilities to access R/W registers in order to improve self test for Acc- Z axis value. The answer is yes, we can access but no, it will not help. There is nothing to store or overwrite bias values.
Here is a test SW for MPU6050 and some other sensors with I2C interface:
github.com/h-elsner?tab=repositories
With this tool I could go deeper into IMU functions. First finding is a problem with Z-axis of accelerometer. Measurement is wrong. The question is, why? Is it really the aging of this chip?
2022-02-15 6/6
Quelle : Stuhlkreis
In the last few month in several drone forums Typhoon H user claim that they cannot start motors anymore. The GPS status remains in „Acquiring“ all the time. Change of GPS module did not help, change of flight controller (MCU board) seems to be the only solution. Often user reported that the problem occurred when they didn’t use the drone for month. But there also cases where the problem appears during normal use.
In this case there are strong indications that the problem starts with a behavior that the drone resits to land and could not brought down. This also a known fault that was reported lately.
I followed some of those fault reports in the forums, checked flight log data and at last got some MCU boards from generous donors. I could reproduce the “Acquiring”-problem.
The five main symptoms are:
1. GPS status stuck in “Acquiring”. The drone cannot be armed anymore.
2. Motors will also not start when GPS was switched off. This unusual behavior can be used as
quick test to identify the fault.
3. Altitude on ST16 shows some meters below zero and did not initialize. The pressure
sensor’s height estimate is OK, near zero at this time.
4. The “Yaw” output in the GUI is slowly rotating while sensor values from accelerometer and
gyroscope do not change constantly in one direction as Yaw is doing.
5. Accelerometer Z-axis has a value far below 1000mG. This is wrong because we have 1G on
Wrong
earth. This indicates the root cause of the problem: ACCEL_ZOUT of MPU < 1000mG. GPS status and Altitude value:
2022-02-15 1/6
Yaw rotation:
1drv.ms/v/s!AtiK_DeOGL5sir0A2Rbx7y7Zq4-SHg?e=UTRLzF
Wrong magnitude (acceleration Z-axis)
Investigation environment
I investigated all seven MCU-boards that I got from generous people.
2022-02-15 2/6
No 1 was fine and got GPS lock soon. It was used to compare the others with a good one.
No 2 had the fault with all four symptoms mentioned above. Flashing firmware back and forth did not help. Put it into the freezer and brought it down to -10°C. Now the Altitude shown on the ST16 was -15m. It came up to -4m while the board warmed up but never reached zero.
Now the board was flashed with customized PX4 autopilot (Thunderbird firmware from Toni Rosendahl). It cames up, could be connected to QGroundControl. After proper calibration it could be armed and all looks plausible. Due to poor test system not flight test was possible.
But during soldering on the board I have destroyed a pull-up resistor. So, this board is crap now.
No 3 had the fault with all four symptoms mentioned above and has it still. Used for further experiments.
No 4 came with a defective IMU. Fault was reported by sound and red LED.
No 5 got GPS lock and looks OK so far.
No 6 came with mechanical destroyed quartz oscillator, does never came up.
No 7 came without IMU but came up and showed the same error indication as No 4.
At this point I decided to exchange IMU modules. MCU board No 4 got the IMU from dead board No 6. As result it came up and got GPS lock. This board looks good now.
Then I replaced the IMU on MCU No7 with the one from No2. Now the fault with all four typically symptoms was moved to this MCU board. It looks like the problems travels with the IMU module. To verify this I have exchanged the IMU with the one from No 4. Now it got GPS lock and works. Change back brings the fault back.
I’m pretty sure that the IMU is the reason for the faulty behavior. I think there is a charge of IMU modules that aging and run out of some threshold in the firmware. As result the EKF output for altitude and NED orientation is implausible and the pre-flight check fails.
This assumption is supported by some observations I did during my tests. When IMU was changed it appears that accelerometer calibration could not level horizon. Also massive compass warnings occur. This could solved by firmware downgrade and stay solved after upgrade to latest version. Same was reported by some user that could get GPS lock after downgrade firmware. For the faulty modules here downgrade did not help.
Final status: Two destroyed MCU-boards, two to reproduce the fault and three that seems to be good.
The “good-ones” are only checked in the test system.
In some cases the problem could overcome by downgrade the flight controller firmware to an old version. For the MCU-boards where I could reproduce the fault this didn’t work.
2022-02-15 3/6
I never did a compass calibration with the board except the Thunderbird. Flight test are still pending to make sure it could be used in a drone.
Conclusion: Fault is probably caused by aged IMU module.
Solution:
In rare cases GPS lock came after very long time (~4h) and faster at next try.
Sometimes it helps to downgrade the flight controller firmware. Not in all cases an upgrade
to latest firmware is successful after that, but sometimes this is possible.
MPU6050 contains a Micro Electro-Mechanical System (MEMS). Sometimes it helps easy
to knock on the IMU holding it in different directions (x, y, z).
The ultimate solution is to replace the flight controller module (MCU-board).
Proper accelerometer and compass calibration is always needed before and during trouble shooting.
2022-02-15 4/6
MCU-Board No 3 was flashed with Toni Rosendahls “Thunderbird” firmware.
github.com/tonirosendahl/Thunderbird
After first power on QGroundControl reported pre-flight check error due to unstable altitude values. Calibration of all sensors was needed. IMU calibration consists of three different parts:
Gyroscope
Accelerometer • Level Horizon
All three calibrations were done and pre-flight checks passed successful. Seems that more complex calibrations as done by QGroundControl can make IMU working. Unfortunately it is not possible to use this kind of calibration for MCU-boards with original Typhoon H firmware.
External access to MPU of the IMU
I have made an adapter for the tiny IMU connector in order to connect the IMU module to another device, in my case a Raspberry Pi.
Installed a program to calibrate a MPU6050 from here:
github.com/Blokkendoos/mpu-calibration
Then calibrated the IMU some times with this external program. Program says Calibration successful. But the problem persists, unfortunately.
I tried to calibrate another MPU6050 from a CGO3+ camera and this seems to be OK.
2022-02-15 5/6
At the calibration result from Flight Controlles IMU, I wonder what those spikes mean which appear during calibration without moving the IMU.
I have checked if there are possibilities to access R/W registers in order to improve self test for Acc- Z axis value. The answer is yes, we can access but no, it will not help. There is nothing to store or overwrite bias values.
Here is a test SW for MPU6050 and some other sensors with I2C interface:
github.com/h-elsner?tab=repositories
With this tool I could go deeper into IMU functions. First finding is a problem with Z-axis of accelerometer. Measurement is wrong. The question is, why? Is it really the aging of this chip?
2022-02-15 6/6
Quelle : Stuhlkreis
Sondermüll meiner Meinung nach 
