Hello Fellow Yuneec Pilot!
Join our free Yuneec community and remove this annoying banner!
Sign up

Firmware update Ver 2.25 After you update post your outcome here.

After installing Ver 2.25


  • Total voters
    106
Did the update on one of our Typhoon Hs - it went off without a hitch and I've had no trouble in flight. Only thing I've noticed is that twice it has given me a warning to switch to angle mode and recalibrate the compass.
 
The reason I stand close to the H, when I test the Realsense, is that I simply doesn't trust its avoidance capabilities completely and it's hard to judge the proximity to danger from a distance..

Seems like that should not be a problem in Angle mode. Don't get close to it in Smart mode, or it'll be spooky.
 
I was standing fairly close, about 15-25 ft. away I would think.. Do you know why that could tricker multiple compass errors and erratic flight behavior...?? The reason I stand close to the H, when I test the Realsense, is that I simply doesn't trust its avoidance capabilities completely and it's hard to judge the proximity to danger from a distance..

I've only noticed it when I'm standing less than 5' away - and assume it's just the ST-16 radio interference.
 
One of the other post discussed the RX and TX issues and distances. I know Yuneec has stated this is the change they made going to the third antenna, to separate the RX and TX antennas. I am not very knowledgeable when it comes to the technical areas of the radio functions, but could this be where we are having problems when the H comes closer to the 16?
 
I see a lot of people posting about problems. Some new and some old. What I don't see in their post's is if they called Yuneec Tech support to let them know of all the issues even with the latest up date. Coming here and hoping Yuneec is going to read every single complaint is not going to get you action. They need to be inform from you the costumer that problems are still there so get on that phone and wake them up.

I reported problem last week to Yuneec Europe, as soon as I experienced this issues which I never had before. So far no resolution.
 
Just to update my situation. Nevertheless I explained that latest issues with Typhoon H after upgrading to FW 2.25 is not isolated case and others experienced the same, Yuneec support told me that I need to send copter to them. I just hope that this will not be standard practic whenever I upgrade firmware.
 
I upgraded my H and have no issues with several flight so far…. Are my results based on the fact that I only fly in "Angle" mode, don't use any of the auto pilot features, nor the obstacle avoidance system? Someday I will get out my wizard or use CCC mode…Just haven't found the need yet.
 
I reported problems after new firmware upgrade. Yesterday i re-installed FW 2.25 . First I made full format for the sd card, then copied file. Today was better weather so I calibrate gimbal and accelerometer and went to open field for compass calibration. Compass calibration is somehow tricky i must say. Not sure how but while I move H all around in one step I manage to hit switch button, and this is not the first time. Anyway, when dancing all around with H I learned that maybe when sometimes two opposite motor arm leds stop flashing, I made another turn on them while actually flashing is now on another motor arms. I am not sure if this is wrong way to do compass calibration but H never reported problem after calibration. nevertheless I think that this might be the problem. So I calibrated today like 4-5 times until i was satisfied.
And after that I flew two batteries and everything was perfectly fine, no drifting, no strange behaviour at all. But I need to make several more flights to be sure.
 
My initial H is on its way back from Yuneec after a flyaway and crash. While waiting I purchased a second one from Best Buy. Yesterday I updated to the 2.25 FW, today I calibrated everything and it flew strong and steady in 16-20 mph winds. No drift. Ran it up to 400', out to 1500 feet, performed numerous maneuvers, etc. Was very happy with its performance. Waiting for my other H to arrive on Monday to test it.

If you have a repaired H, new GPS board, or it is on its first flight since you received it, when you turn it on, let it sit and register/update the GPS system for at least 12.5 minutes. Then turn it off and restart it. This will ensure the GPS correctly registered. After you do this, it is not necessary to do again for future flights.
 
Gents,
There has been too many Firmware Upgrade anomalies to trust that Yuneek will properly address this issues themselves but there are some actions we can take to get to the bottom of this or at least assist Yuneek in resolving these problems.
I have some experience in the electronics hardware & software manufacturing space, not claiming to be the expert and that I can fix this, but with everyone's help on this forum we can assist getting the ball down the field with this effort.
Many problems with hardware & software rollouts originate from the use of dissimilar components and procedures in manufacturing, testing and service.
For example, the reason a firmware upgrade may not work on Unit S/N:1005, works perfectly on Unit S/N:9997 may be because S/N:1005 was manufactured with RevA board components and S/N:9997 was manufactured with RevD board components.
Believe me when I tell you that not all components on a system board react exactly the same, it is not uncommon for manufacturers, especially non ISO9001 companies to substitute components based on cost and availability. Often these substitutions are driven by bean-counters that pressure engineering to accept the substitutions usually against protest and without proper testing.
This problem becomes worse when ICs and Processors are substituted. Many of them don't have the same clock speeds, performance tolerances, and space. You might have a solid program that works flawlessly on one chip, but when ran on another chip with a different scan rate or because of space limitations routines are placed in different threads that don't update as often, the end result is the program is executed differently between the the 2 processors.

So how can we as a group counter this? Well if we could get enough members to participate in providing detailed information about their equipment, as in; SN, date of manufacture, crack open the case take pictures of the all the boards and then post the results of their Firmware performance results etc., then we can construct a database, start connecting the dots and stop relying on a coin-toss to troubleshoot or upgrade our equipment.
With enough participation, we could start concluding which SNs should perform updates, which ones will brick, what components to replace to make units compatible to except latest revision, etc.

If anyone is interested in participating in this effort, let me know?
 
Gents,
There has been too many Firmware Upgrade anomalies to trust that Yuneek will properly address this issues themselves but there are some actions we can take to get to the bottom of this or at least assist Yuneek in resolving these problems.
I have some experience in the electronics hardware & software manufacturing space, not claiming to be the expert and that I can fix this, but with everyone's help on this forum we can assist getting the ball down the field with this effort.
Many problems with hardware & software rollouts originate from the use of dissimilar components and procedures in manufacturing, testing and service.
For example, the reason a firmware upgrade may not work on Unit S/N:1005, works perfectly on Unit S/N:9997 may be because S/N:1005 was manufactured with RevA board components and S/N:9997 was manufactured with RevD board components.
Believe me when I tell you that not all components on a system board react exactly the same, it is not uncommon for manufacturers, especially non ISO9001 companies to substitute components based on cost and availability. Often these substitutions are driven by bean-counters that pressure engineering to accept the substitutions usually against protest and without proper testing.
This problem becomes worse when ICs and Processors are substituted. Many of them don't have the same clock speeds, performance tolerances, and space. You might have a solid program that works flawlessly on one chip, but when ran on another chip with a different scan rate or because of space limitations routines are placed in different threads that don't update as often, the end result is the program is executed differently between the the 2 processors.

So how can we as a group counter this? Well if we could get enough members to participate in providing detailed information about their equipment, as in; SN, date of manufacture, crack open the case take pictures of the all the boards and then post the results of their Firmware performance results etc., then we can construct a database, start connecting the dots and stop relying on a coin-toss to troubleshoot or upgrade our equipment.
With enough participation, we could start concluding which SNs should perform updates, which ones will brick, what components to replace to make units compatible to except latest revision, etc.

If anyone is interested in participating in this effort, let me know?

I agree with everything you say.

But it is not up to the consumer (Unless Yuneec actually asked for help) to undertake a task like this.
We don't even know that Yuneec would be interested or would want to use this data.

I cannot believe Yuneec does not know what is going on and if the above were true should send out a notice or a recall
to change the affected part(s).
 
Sign me up, this is what I have been saying on another thread.
Thanks,
1) The first step will be to identify & create a list of all the available data we have access to for the Th.
1.a) Identification of the data will come from;
1.b) Manufacturing labels with locations.
1.c) Pictures of all boards and components.
1.d) Electronic data gathered from Typhoon H GUI program and Controller settings.
2) Collect equipment case information for each unit, what operations work good, what operations work poor.
3) Collect application revision information, none issues vs unit SNs.
4) Collect application revision upgrade information, good/bad vs unit SNs & result comments.
2) I can assemble this information in an Excel workbook for documentation and filtering.

This should get us started, as we get more buy in on the effort, I am sure we will populate the list with more data categories from the participants.
Understand, I am not claiming to be a technical expert on the equipment, my role in this will be to collect, assemble & present information, we will need some Th Guru buy in to assist with connecting some of these dots.

Thanks again,
 

New Posts

Members online

Forum statistics

Threads
20,977
Messages
241,833
Members
27,386
Latest member
maahdevbook