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..
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 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.
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?
Thanks,Sign me up, this is what I have been saying on another thread.
We use essential cookies to make this site work, and optional cookies to enhance your experience.