at the beginning - my goal is not to get help in reducing vibrations or find their cause, which is why I don't attach files with configuration and logs.
I bought a brand new Brain 2 for a brand new XLPower 380 and from the very beginning I have been struggling with huge logged vibrations, never going below 500 (global) even when hovering, while the heli behaves correctly. I spent a lot of time trying to find and eliminate the rc. Fortunately, I found people who face the same problem (high vibrations in logs) and after a brief investigation we concluded that the problem may be related to the motion tracking sensor change to ICM-20689.
So my question is: are you aware of this problem and when should we expect a fix?
We changed the accelerometer chip early last year, twenty months ago because the previous chip was no longer available except by buying it from unreliable sources and at ten times the price.
Although twenty months have passed, only about a month ago some reports about vibration measurement appeared on HeliFreak (Note: HF it is not our official forum), but still the users who made these reports can be counted on the fingers of one hand and only one have sent a log.
This is the first message our company receives.
Considering the tens of thousands of units sold in the last twenty months, it is really strange that before a month ago there were never any reports.
Without having any files and technical data, as far as we have read it could also be really high vibrations of the models transferred to the flight controllers without being filtered out by the double-sided tapes for thousands of possible reasons.
So we think the problem only happens on a very, very small percentage of flight controllers, and perhaps all belonging to the same batch of chips.
The problem is that so far we have never received even a single flight controller returned to us for this type of defect, so we don't even have one to be able to do any testing and verification.
Obviously we are alert and very careful about this issue, but so far we have only been able to introduce additional checks at the end of production.
Until we have one of these flight controllers, besides worrying and distressing, there is very little we can do.
However, thank you for your report (However, without any file documenting the actual existence of the problem).
We changed the accelerometer chip early last year, twenty months ago because the previous chip was no longer available except by buying it from unreliable sources and at ten times the price.
Although twenty months have passed, only about a month ago some reports about vibration measurement appeared on HeliFreak (Note: HF it is not our official forum), but still the users who made these reports can be counted on the fingers of one hand and only one have sent a log.
This is the first message our company receives.
Considering the tens of thousands of units sold in the last twenty months, it is really strange that before a month ago there were never any reports.
This twenty-month career of the new sensor may shed a slightly different light on the problem. However, we should bear in mind that not all users of this flight controller (I would be tempted to say a minority) use the logging functionality, so others may not have noticed the problem. It seems that in my Brain user community I am of the few who have observed and taken this problem seriously 😉 This is probably because, as I mentioned, the model behaves normally (despite logging a huge vibrations).
Without having any files and technical data, as far as we have read it could also be really high vibrations of the models transferred to the flight controllers without being filtered out by the double-sided tapes for thousands of possible reasons.
(...)
However, thank you for your report (However, without any file documenting the actual existence of the problem).
Of course your right - without any logs this topic looks like baseless accusation.
I collected logs throughout my time fighting vibrations; I replaced all shafts, blades (balanced many times), tail servo, tail blade holders, tail box and some bearings; the double-sided tape is still the same - the original 3M from the box.
So I will collect the config and log files and maybe ask other pilots in my community for the data and share it with you.
So we think the problem only happens on a very, very small percentage of flight controllers, and perhaps all belonging to the same batch of chips.
The problem is that so far we have never received even a single flight controller returned to us for this type of defect, so we don't even have one to be able to do any testing and verification.
Obviously we are alert and very careful about this issue, but so far we have only been able to introduce additional checks at the end of production.
Until we have one of these flight controllers, besides worrying and distressing, there is very little we can do.
I fully understand your position and agree with it. Of course, I take into account the need to send the FCU to you, however, due to the ongoing season (excellent weather), I keep postponing it. Flights, even test ones, are still great fun 🙂
1st package (Brain_logs_1.7z) is mine, including config and events dump, several log files and... I don't know... checksums? (msh files);) Most of the logs taken from the controller mounted with the original 3M tape, the last two (21st and 23rd) using a custom, thicker 2 mm tape (even worse results); HW: XLPower 380 V2, Hobbywing Platinum 60A, XLPower 3215 920 kV, 3x GDW DS920IG, 1x KST DS515MG, MB Tarot 380 mm, TB Align 69 mm, RCV GR-16 HoTT, gov from FCU. At least twice a 111 event was caught, but it definitely wasn't caused by a crash; maybe by a less soft landing (IMO this shows how sensitive the sensor is). And I have no idea why the 22nd flight is skipped.
2nd package (Brain_logs_2.7z) comes from another guy (not from HF) who also has a relatively new controller (XLPower 380 V1, double Tesa tape 2x 1 mm).
Finally someone talking about a problem by documenting it.
However, it is not clear from your post what the difference is between the two files. In the post you write "1st package is mine...." but then you don't say whose package it is and what is different about the second package which we assume unlike the first is not yours. In fact we see that these are two different FCUs with two different serial numbers and two different first activation dates, and the configuration files are very different (standard receiver, 760us tail servo, Tail Reverse, ESC governor, main & tail gear ratio, 3D style, etc.).
We can finally compare for the first time the only files posted so far on HeliFreak with yours to see what is in common between yours and those posted on HeliFreak and what is different instead. It took almost two months before someone else posted data but patience, better late than never.
From the vibration graphs, it is interesting to note that the highest amplitude vibrations are not those at the fundamental frequencies (Main Rotor, Tail Rotor, Motor) but instead seem to be at the harmonic frequencies of the fundamental frequencies especially that of the main rotor.
Are you sure that the tracking is calibrated correctly and that cannot unregulated in flight due to a crooked spindle rotating at each pitch change?
Have you tried setting the Global Vibrations value among the parameters to be logged? Since the loggable parameter "Global Vibrations" is calculated internally by the FCU firmware while the Global Vibrations value in the "Vibrations" graph tab is instead calculated by the software based on the vibration graph curves, it would be interesting to see if the two values are similar or if there are significant differences.
The other interesting values to check are the signal amplitudes of the three accelerometers X, Y and Z. By zooming in on log 4p (what is the difference between log 4 and log 4p?) where it can be seen that the model is now landed and stationary on the skids, the average values of the X and Y accelerometers turn out to be at 0.007g and 0.04g and these are normal values caused by very small lateral and longitudinal tilts of the model when it was stationary and resting on the skids, and the average value of the vertical accelerometer Z corresponds to 1.00g which is the correct value of the Earth's gravity acceleration:
So there do not seem to be any errors in the correct readings of Earth's acceleration by the three accelerometers, and this is good news that already allows us to be able to rule out many possible types of problems.
Finally, we noticed that both you and the HeliFreak user who has the problem are using the latest firmware 3.4.126 released on July 19, 2023. Since the problem over the twenty months (now 21) since we started using the new chip has only begun to be reported in the last month and a half, it raises the question that it could be caused by the changes introduced in the latest firmware. Have you tried loading an earlier firmware into the FCU such as, say, 3.4.122 or 3.4.116 or 3.4.103 or 3.4.094 or 3.4.059 to see if other changes may have unintentionally affected the calculation of the vibration graphs?
From the vibration graphs, it is interesting to note that the highest amplitude vibrations are not those at the fundamental frequencies (Main Rotor, Tail Rotor, Motor) but instead seem to be at the harmonic frequencies of the fundamental frequencies especially that of the main rotor.
That's right, these were my observations too. And I wondered if they came from the tail servo (21k RPM is close to 333 Hz) but definitely not, because they follow the main rpm.
Are you sure that the tracking is calibrated correctly and that cannot unregulated in flight due to a crooked spindle rotating at each pitch change?
I hope so - I spent a lot of time on it. The spindel is straight; I verified this by rotating it and checking whether the distance of the blade from the tail boom doesn't change. I had some issues with the main hub, but after corrections I didn't notice any improvement in the logs. Pls keep in mind that last two logs (21 and 23) were collected with a different, not original tape.
Have you tried setting the Global Vibrations value among the parameters to be logged? Since the loggable parameter "Global Vibrations" is calculated internally by the FCU firmware while the Global Vibrations value in the "Vibrations" graph tab is instead calculated by the software based on the vibration graph curves, it would be interesting to see if the two values are similar or if there are significant differences.
Oh, ok, now I get it! I didn't catch the difference between "Vibrations graph / Global Vibrations" as a fixed "Log Parameter 12" and selectable "Global Vibrations".
I found somewere information that it is good to "erase all logs" after modifying logged parameters. I didn't know that this would also reset logs numbering. So at some point I had duplicated names.
BTW, this might be a good candidate for improvement - to avoid resetting the log numbering. The log number could be the same as "Main Flight Count".
Finally, we noticed that both you and the HeliFreak user who has the problem are using the latest firmware 3.4.126 released on July 19, 2023. Since the problem over the twenty months (now 21) since we started using the new chip has only begun to be reported in the last month and a half, it raises the question that it could be caused by the changes introduced in the latest firmware. Have you tried loading an earlier firmware into the FCU such as, say, 3.4.122 or 3.4.116 or 3.4.103 or 3.4.094 or 3.4.059 to see if other changes may have unintentionally affected the calculation of the vibration graphs?
Nope, I havn't. But I can try. AFIK FW downgrade has to be done manually. So please share the relevant binary and I will try to apply it.
We always take our users' problems seriously. However, as we have already written here, and thousands of other times (almost once a day in the first ten years of activity = 3,650 times), without being able to have in our hands the transmitter and the model with the flight control unit with which the reported problem occurs, and without even having received the data files with as much information as possible necessary to be able to remotely attempt to make evaluations and analyses of the data we ask for each time, what could we do? You, yourself, wrote no less than three posts here before you sent us files on which we could reason.
That's right, these were my observations too. And I wondered if they came from the tail servo (21k RPM is close to 333 Hz) but definitely not, because they follow the main rpm.
The vibrations are not related to the refresh frequency of the servos (333Hz) which has nothing to do with the vibrations, but are instead generated by the rotating parts: Main Rotor, Tail Rotor, Motor, belt, etc. The rotational frequencies of these parts of the model are always related to each other through the Main Gear ratio and Tail Gear ratio. So when the motor slows down the other frequencies also slow down at the same rate because they are mechanically correlated with each other, vice versa when the motor accelerates the rotation frequencies of the main rotor and tail rotor also accelerate. Only in models that have an electric motor in the tail that rotates the tail blades at a fixed pitch, in this case there is no correlation between the tail rotor frequency and the main rotor and main motor rotation frequency (however, the main rotor and main motor rotation frequencies remain mechanically correlated with each other).
I hope so - I spent a lot of time on it. The spindel is straight; I verified this by rotating it and checking whether the distance of the blade from the tail boom doesn't change. I had some issues with the main hub, but after corrections I didn't notice any improvement in the logs. Pls keep in mind that last two logs (21 and 23) were collected with a different, not original tape.
The double-sided tapes used in RC modeling are not made of random materials like those found in hardware stores but use materials that absorb well-determined frequencies with well-determined attenuation factors. In tests done by us and our Beta Testers, the double-sided tapes that best filter the vibrations of our Eli RC combustion-powered (Nitro/Gasser/Turbine) Eli are the Nitto, Sekisui and Futaba ones, but they are not found at all RC modeling stores. Using double-sided tape sold in hardware stores can make filtering much worse as you yourself noted by using one not specifically made for RC modeling.
Oh, ok, now I get it! I didn't catch the difference between "Vibrations graph / Global Vibrations" as a fixed "Log Parameter 12" and selectable "Global Vibrations".
I found somewere information that it is good to "erase all logs" after modifying logged parameters. I didn't know that this would also reset logs numbering. So at some point I had duplicated names.
BTW, this might be a good candidate for improvement - to avoid resetting the log numbering. The log number could be the same as "Main Flight Count".
The numbering of Recorded Logs cannot be related in any way to the Main Flight Count because sometimes it can also be useful to make Recorded Logs not in flight but on the workbench during setups and in this case the Main Flight Count does not advance. However, the number of Recorded Logs is shown in the Events which can then easily be correlated with each other as well as the vibration graphs where the seconds shown correspond to the seconds shown in the recorded logs graphs and you can see how the vibrations are correlated to the commands given in flight to the model.
Nope, I havn't. But I can try. AFIK FW downgrade has to be done manually. So please share the relevant binary and I will try to apply it.
It is impossible that you have never updated the Firmware. When you update the firmware, you will have seen that the window appears for selecting available firmware that can be written to the flight controllers.
When it is an automatic update, the bottom box already automatically proposes the new / latest Firmware to be written into the flight controller and you only need to press the "Upload Now" button.
On the other hand, when you manually update the sign using the "Manual Firmware Upload ..." command found in the "File" menu (top left), you can select the firmware line you want to write into the control unit and then press the "Upload Now" button. Nothing could be simpler.
Although twenty months have passed, only about a month ago some reports about vibration measurement appeared on HeliFreak (Note: HF it is not our official forum), but still the users who made these reports can be counted on the fingers of one hand and only one have sent a log.
I would not expect these kinds of hidden issues to get exposed immediately. From my own experience I would say this issue existed at least as early as July 4th last year, when I bought and flew my unit in a Fireball. Mine was also indicating extreme vibrations but I never suspected the FBL itself as being the problem. I spent a little bit of time trying to sort it out but as it was flying fine and there we're no visible vibrations I chose to just sit on the issue soon afterwards. It wasn't until about 4 months ago when someone with the resources and patience to test two different iKons on a "problematic" machine, one being older, that I began to have suspicions that it might be the FBL. But I still wanted to believe that it was just his new unit that was defective, mainly because I don't just have an older iKon laying around, nor the money and patience to track one down. Then it wasn't until last month when someone suggested taking a closer look at what chips were being used on the FBLs in "problematic" aircraft that dots start to be connected. This is but one way a problem can go unnoticed for so long.
I've since acquired two pre-crashed OXY2s that came with micro Brains with MPU6000 inside that have rather obvious vibrations but vibrations were reported as being well within tolerable ranges according to those units. This is in stark contrast to my situation with the pristine Fireball with no perceptible vibrations with the IC2689 equipped FBl. How much sense does that make?
@customercare well the question was how the problem could go unreported for about a year. I was giving insight on why that would be. I could provide a file later today if it really is necessary. You will see that it has the latest firmware, but let me assure you that it is reporting the same amount of vibrations it does now as it did back last July 4th when it fresh out of box. I think firmware has little to do with it, at least since last July 4th until now.
2nd package (Brain_logs_2.7z) comes from another guy (not from HF) who also has a relatively new controller (XLPower 380 V1, double Tesa tape 2x 1 mm).
I have an update to these logs above (shafts and bearings replaced with factory new ones, main blade balanced twice, original 3m tape used, fw downgraded to 3.4.103):
No HW changes; SW downgraded, Global Vibrations added to the logs (log 7 looks corrupted, I have no idea why, it was not even the first one after formatting the log memory, I made 7 flights then); the vibration looks terrible, but the heli was flying properly:
2nd package (Brain_logs_2.7z) comes from another guy (not from HF) who also has a relatively new controller (XLPower 380 V1, double Tesa tape 2x 1 mm).
Every critical part has been replaced; the model was flying well, the rescue worked properly, despite many 111 events!
Just chiming in here since I was one of the ones who posted about this issue on helifreak, once I explained that I mounted an older Ikon and a newer one to the same heli, at the same time, the new one showed 700 global vibration, the older one showed 12 ya'll never responded to the thread again. https://www.helifreak.com/showthread.php?t=934113#post8652875 I get that you need to rule out user error when people report problems but there's clearly a defect here.
It's pretty obvious why it would take some time for this to show up in customers hands, who knows how much old stock retailers were sitting on, plus builds can take months, and I for one didn't consider that the fbl unit was faulty and spent months and hundreds of dollars trying to troubleshoot the vibration as if it were a mechanical issue. It wasn't until MUCH later and after a lot of trial and error I realized the vibration sensors are either faulty or not properly calibrated.
More and more people are having the same problem MSH, you must address it properly. I'll send you my faulty unit for analysis myself, just send me a shipping label.
