1.28 firmware needed

[h-elsner]

and don't want to dispose of them in Hopes of a Fix, I would think they could be salvaged, and possibly be used again

Yes, you are right. Maybe some of the boards have really HW issues but I think some of them not. It is worth to try a SW solution before HW replacement. I would be happy to do some tests with different HW although probably not all modules will survive this ;-).
I will send you a PM.

br HE

 

[Kevin788]

New FC board fitted,,, GPS ready in 2 mins,, inside a building sitting on a car! Happy days, flight test tomorrow

 

[h-elsner]

During some tests regarding the GPS-Aquiring problem today I found following indications for this fault:
- GPS state remains in Aquiring forever (OK, that's clear), motors do not start, sends disargee sound.
- Change of GPS module or GPS backup battery did not help.
- Change of flight controller helps in otherwise untouched system.
- Motor do also not start, when GPS was switched off. Sends disagree sound too.
- Baro height in GUI is near zero, but altitude on ST16 is always some meters below zero and do not initialize to zero.
- When start button was pressed, the green arrow shows up for a short time. The direction of the arrow changes when position of the ST16 changes. Seems ST16 uses both positions, drone and RC.
- Flash FC back and forward with different firmware including V1.28 did not help. I have also flashed with a destroyed FW. It say CRC mismatch and will not start anymore. But this also not helped.
- The values for geofence will be kept during flashing with different FW. That means there are memory areas untouched when flashing FW. Found no way to identify and clear this memory area.
- Shortcut of NRST pin to ground reboots the system but did also not help.

Would be good to doublecheck it with other MCU boards. Tomorrow I will proceed...

br HE

 

[Vaklin]

I have a defective board and I'm able to test everything.
Promiseable idea is to modify 1.28 to do something different for the first time, doesn't matter what exactly is.

SRAM area is defined in the datasheet. Not a good idea is to wipe it in the first tests. The target is to read it. Soon I'll have probably working FC for tests too.

 

[h-elsner]

Now, after I got some MCU modules spent from generous people I have a final conclusion attached.

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 tries.
• Sometimes it helps to downgrade the flight controller firmware. Not for all is an upgrade to latest firmware successful after that, but sometimes this is possible.
• Replace the flight controller module (MCU-board) is the ultimate solution.

As by-product, I have an application to extract flight controller firmware (and others) from original Yuneec firmware. I will make a shoer description and upload it somewhere maybe today or tomorrow.

br HE

 

[h-elsner]

The Typhoon H Firmware Tool to extract parts fom the firmware files:

Microsoft OneDrive

1drv.ms

br HE

 

[Vaklin]

A look inside...

 

[h-elsner]

The MPU6050 has a temperature sensor. Data will be provided via I²C bus.

br HE

 

[Vaklin]

The device should be checked on stand to define is the 6050 problematic, or just the FC decides to doesn't believe to it.

 

[h-elsner]

Another intresting thing: If you power on the drone tipped 90° then the altitude goes down to zero and keep there. Motors still not able to start when GPS is off. When you then set it back horizontal (0°) the Altitude at the ST16 goes slowly down to some meters below zero.

The (wrong) altitude depends on the orientation of the IMU at start. Strange.

br HE

 

[h-elsner]

The device should be checked on stand to define is the 6050 problematic, or just the FC decides to doesn't believe to it.

The values in the GUI for Height Estimate from pressure sensor, accelerometer Z, accelerometer Magnitude and Gyro Z are looking plausible. But the output Altitude and Yaw are wrong.
The question is, where the wrong values come from? I guess due to wrong BIAS settings for the IMU in FC or IMU BIAS runs out of the range that FC has given for it.

br HE

 

[Vaklin]

Probably high current consumption from the heating circuit and not enough power for the 6050?

I checked some logs from my defective FC and the yaw drift is more noticeable in the millisecond interval. Altitude remains positive, so if the 6050 is a candidate to be guilty there are different variants to broke it.

 

[Vaklin]

The values in the GUI for Height Estimate from pressure sensor, accelerometer Z, accelerometer Magnitude and Gyro Z are looking plausible. But the output Altitude and Yaw are wrong.
The question is, where the wrong values come from? I guess due to wrong BIAS settings for the IMU in FC or IMU BIAS runs out of the range that FC has given for it.

br HE

Something in relation to this, I read about the IMU in the DJI. If the accelerometer calibration is done in some temperature, in another the difficulties to obtain fix have a place.

 

[Vaklin]

BIAS settings

They should be written in the calibration phase or not?

 

[h-elsner]

Today I tried a stress calibration test with MCU-board #7 (the one that has the "Aquiring" problem still). Acc calibration on top, with 90° tilt, other tilt angles and acc cali during movement done. Nothing helps to set back the IMU settings.

Next try was done with a real drone and the MCU-board #3 in it, the one I have reflashed with PX4 firmware "Thunderbird". This thing also remains in "Aquiring" state. QGroundControl said: "Pre-flight check failed, Altitude estimation unstable". Exact that what I think it is the reason why Typhoon H could not be armed. I did Gyro calibration and level horizon, no success. Then I did Accelerometer calibration in 6 axis (as QGC demands). After that pre-flight check was successful and the drone could start.

From my point of view the one axis acc calibration that Typhoon H is doing is not enough to catch drift of the IMU if it was gone too far. As result we have the need to replace the whole MCU-board or at least the IMU on the board which is difficult and dangerous.

To exchange the calibrated IMU from board #3 to #7 did not help. I expected that because I think the bias parameter are stored in the flight controller, not in the IMU chip itself.

Unfortunately still no way out if "Aquiring" problem occurred. Refer to attachment in thread #45.

br HE

 

[h-elsner]

I can't forget this IMU related problem. Now it seem to appear at Q500 too and I have read about the same problem with DJI Phantom 3 (IMU calibration error - code 50). Seems to be a problem with storage of MPU6050, maybe it it is stored in 90° angle for a long time.

Now I have made an adapter for the IMU in order to connect it to another device, in my case a Raspberry Pi.

Installed a program to calibrate a MPU6050 from here: GitHub - Blokkendoos/mpu-calibration: Calibration procedure for the MPU6050 accelerometer/gyroscope, and the HMC5883 magnetometer, using a Raspberry Pi. Then calibrated the IMU some times but without success. The problem persists .

I wonder what those spikes means which appear during calibration without touching the IMU. Is there someone out there who knows more about handling of MPU6050? I'm thinking also about writing values to the registers manually.


I tried to calibrate another MPU6050 from a CGO3+ camera. This looks much better:

Hmm, what else can we try?

br HE

 

[Vaklin]

If you connect the PCB from the camera to the copter instead of the original module what happens? The more wide question is how to prepare a stock 6050 to use with the FC? If there is a procedure to replace it, the topic is solved.

 

[h-elsner]

I wrote a program that can read all registers of a MPU6050 and write to all that are R/W. This helps me to better understand the IMU stuff.

I found out the IMU from the FCs that stuck in "Aquiring" state show ~0.65g in z-axis. But we have 1g on earth as far as I know.
~1g will be shown in all other axis (X, Y) when those are set in direction to gravity.
The MPU6050 from CGO3+ didn't show this problem, ~1g in all axis depending on direction.

Edit: If I opened my eyes I could have seen that also in the GUI the Z-axis of the Accelerometer shows values far below 1000mG. Magnitude should always show a value around 1G no matter how the drone is directed as long as it will not leave the earth.
So, we have a 5th symptom for the diagnosis of our problem that poits directly to the root cause.

For the MPU from my only defect Flight Controller, calibration did not help, reset all register to zero did not help. Seems the self test at the beginning went wrong.

To connect the CGO3 IMU to the FC I need to solder the flexi cable - huhh. Up to now withot success and it become shorter and shorter...

br HE

 

[Vaklin]

Solder it on the connector or directly on the processor pins. Flexible PCB is not solderable with a soldering iron. The joint is made with a special solder paste and trafaret. The soldering iron is with a rubber flat nose.

 

[Vaklin]

X, Y and Z register are switchable or selectable? My question is related to GB203 and CGO3+. The IMU module in both is the same but is displaced 90 degrees clockwise. It is possible to reprogram it instead of rotating it?