EN RU CN
Interference of the external enviroment?
  • Friends, there has been strange things for some time.

    Had a brushless gimbal 3-axis with 8-bit alexmos. It worked very well. But in some flying sites, as works, near towers, buildings, the gimbal was crazy after about 30 meters high. Needed landing, turn off the gimbal and turn on again. But the problem came back after take off again and fly to a certain height.

    On the same day flight tested elsewhere (rural environment), and the problem did not occur. I did several tests and found that the gimbal was affected by the environment flying.

    Got a Zenmuse GH4 and the problem does not occur anywhere. Torres, works, machinery, do not affect the operation of the same.

    I set up a brushless gimbal for DSLR with alexmos 32-bit. Yesterday I flew in a location more "noisy" and the problem is the same. After a certain point the gimbal is crazy. The board is not a broken, as with all plates alexmos either 8 or 32 bits, and different flight platforms.

    The question is: Where exactly these noisy areas affect on the gimbal board?
  • I would suspect IMU cable, also make sure you have assigned only RC channels that are used. If for example analog inputs would be assigned and not connected, that could cause problems.
  • Exactly same problem here. After a certain height gimbal gets completely crazy, sometimes even at ground level. This happens always shooting in downtown locations, nothing happens far from the city or in the countryside.
    Once gimbal gets completely crazy there is no way to stop it unless you land and restart.
    Tried with ferrites in the sensor and motors cables, also replaced sensor cable with a 4 conductor shielded cable , nothing has worked.
    This has kept as away from shooting in downtown locations which is a big problem needing to rely on other solutions.
    This is the same for 8 and 32bits boards.
  • That is really strange problem. I do not think it can be pressure related, because then it would not be 30 meters above ground, but sea-level and at that level the pressure varies greatly too. (and there is nothing on gimbal that reacts to small pressure changes)

    It could be radio emission, but then the fields should be really strong (like right next to radio mast.) ant that should not be that much altitude related.

    I think it is most likely air turbulence related. quite often there is a layer of air around 30 meters that acts very much differently than the air below or above, and those turbulences could disturb the gimbal, but those turbulences should be also noticeable when flying. If so, the vibration dampening and tuning should be improved.

    Here is one link to the phenoma http://wattsupwiththat.com/2012/07/12/important-new-paper-on-the-nocturnal-boundary-layer-mixing-and-radiative-forcing-as-it-applies-to-ghcn-weather-stations/
  • Hi Garug,
    Thanks for your reply.
    Nothing to do with pressure or dampening. It happens 30mts or even at ground level with no wind but always near congested cities or downtown, impossible to shoot there.
    Take a look to this video (not mine, just found it in youtube), this is what it happens with their gimbal:


    As you can see once the copter takes off as it gains a few meters, gimbal gets crazy. They bring it down and up many times happening the same effect over and over at the same altitude. It seems that after clearing a few meters gimbal electronics is hit by the EMI coming from the huge city below (Rio de Janeiro in this case).
    Same happening to me and Rasec.
  • There clearly is wind and the statue causes for sure turbulence that starts the issues and it looks like the gimbal has some issues.

    What board/FW is that, is it with 2 IMUs.

    With 2 IMUs it should recover from that kind of condition.

    Also make absolutely sure the basic setup is correctly performed. Wrong motor inverted status for example can cause that kind of issues. (the gimbal can work surprisingly good with wrong inverted, but there always will be issues.)

    About EMI, A multicopter is a huge EMI source, with the motors, high currents, ESCs, often video transmitters etc. It should be really powerful source really near to cause more EMI than that. I think there is now way the city that far could cause that kind of EMI.

    And the Gimbals should not be that sensitive for EMI, except the i2C communication (IMU). Using ferrite rings on the IMU cable should avoid those problems, and most boards have filtering on board.

    I would really look the problem elsewhere than external EMI. The internal EMI could be an issue, for exactable when motors consume more power (gaining altitude). How is the gimbal powered? when I power from fight battery, I always use the balancer port. That is much more cleaner electricity than connected parallel to ESCs. That is because LiPo batteries have very low internal resistance.

    On bigger gimbals maybe better to use separate battery.

    But I still suspect turbulence is the most probable cause. Open fields do not have often much turbulence, city and forest areas have.
  • Discard the turbulence issue, it happens at ground level even removed from the copter on its own power source as well.
    There was a time that i took the gimbal to particular spot in the city where this problem occurred right after turning on not even in the air, it started as a crackling noise coming from the motors building up to total lack of control like in the video, i connected programmer showing increased number of i2c errors. This same gimbal performs perfectly well in the shop, inside a car or away from the city, zero i2c errors.
    I´d discard internal EMI too.
    I have experimented exactly the same problem on 8bits and 32bits with two sensors.
    Im leaning towards i2C line being hit by external EMI but how to be sure rings are preventing it?
    Is it a ferrite on each i2C individual cable or the 4 cables together, how many turns?
    I have installed ferrites on both ends of the i2c line but it seem not to work.

    Interesting to know inverting motors from GUI is a source of problems, so you recommend to invert motor cables rather than clicking on invert option on gui?
  • I had I2C errors until change IMU cables. I am put USB cable with ferrite core and have not problem with I2C errors!
  • Tompa,
    Did you have always i2C errors or as described above?
  • If you have I2C errors, then it is clear, those will cause problems. Some boards and IMUs are more sensitive for them. The 'BaseCam SimpleBGC 32-bit' has been very good, I have had no I2C problems with it, not even with long and unprotected cables.

    It is good to keep the IMU cables as short as possible and separate from other cables. With ferrite rings it is best just to test. Also twisting cables sometimes helps, or protecting them. I would start with one ferrite ring near the board, couple of rounds around it.

    Anyway, any place that has that much EMI, I would stay far away.
  • "Interesting to know inverting motors from GUI is a source of problems, so you recommend to invert motor cables rather than clicking on invert option on gui?"

    I am not sure what you mean. If inverting motor helps (and accordingly in GUI), then there is some problem with the motor, probably one of the wires touching the motor metal parts. Better test for this. That would cause problems and this is a problem I have met with inexpensive motors, but also with the best available ones.

    If motor cable is inverted, then also in GUI it has to be inverted. if Motor is ok, it should not make any difference what way the motor cable is, as long as the inverted status is set accordingly in GUI. (only way I know how to set it is with Auto function.)
  • CFarg, I had sometimes more, sometimes less I2C errors, for no obvious reason but after changing cables I have no errors!
  • "If you have I2C errors, then it is clear, those will cause problems. Some boards and IMUs are more sensitive for them. The 'BaseCam SimpleBGC 32-bit' has been very good, I have had no I2C problems with it, not even with long and unprotected cables.

    It is good to keep the IMU cables as short as possible and separate from other cables. With ferrite rings it is best just to test. Also twisting cables sometimes helps, or protecting them. I would start with one ferrite ring near the board, couple of rounds around it."

    I didnt have problems with i2C with the 32bits boards neither, it comes with a long cable tough. I use the stock cable it comes with, no problems in the bench or flying away from downtown.
    Now with the dual sensors layout do you think installing one ferrite near the main board is enough? what about the 2nd frame sensor which is in the middle of the cable?
    How do you protect I2c wires?

    "Anyway, any place that has that much EMI, I would stay far away."
    That place is a half of a big city which ive been experimenting all these problems, i cannot avoid shooting there.

    "I am not sure what you mean. If inverting motor helps (and accordingly in GUI), then there is some problem with the motor, probably one of the wires touching the motor metal parts. Better test for this. That would cause problems and this is a problem I have met with inexpensive motors, but also with the best available ones."
    Sorry, i misunderstood your original statement about motors being inverted.

  • It is just important that the motor inverted status is set correctly on GUI with Auto function after installation of the motors, or changing them. Though I am usually careful with this, I have had it wrong, causing strange issues.

    The gimbals are normally not sensitive for external EMI. They can tolerate video transmitters etc, next to them. If any of my gimbals would stop working because of extensive amount of RF energy on the surroundings, I certainly would not want to stay there.

    Your gimbal might have some other issues too than just the cabling. How is the IMU installed? If with metal screws to CF or metal, try installing it just with 2 sided tape. That should avoid any grounding issues and prevent noise coming in from IMU grounding.
  • Hello,
    i have customer with this frame as well you need extra vibration dampening! Yes bad cabling ca cause this as welll.
  • "It is just important that the motor inverted status is set correctly on GUI with Auto function after installation of the motors, or changing them. Though I am usually careful with this, I have had it wrong, causing strange issues."

    Will take this into account and check back on setup, this might be source of problems but i dont think the problem i described has to do with it.

    "The gimbals are normally not sensitive for external EMI. They can tolerate video transmitters etc, next to them. If any of my gimbals would stop working because of extensive amount of RF energy on the surroundings, I certainly would not want to stay there."

    I have flown really close to active cell phone & data antennas in the countryside, there were absolutely no issues with BGC nor the copter electronics.
    This is something related to a massive EMI multisource generator like a big city, it does not happen in limited areas but in almost the whole city (which is 3 million people big), some places hitting stronger than others on the ground and at different altitudes as well. It does NOT happen while you are caged inside a building/car for example or far from the city.


    "Your gimbal might have some other issues too than just the cabling. How is the IMU installed? If with metal screws to CF or metal, try installing it just with 2 sided tape. That should avoid any grounding issues and prevent noise coming in from IMU grounding."

    IMU is isolated from the gimbal, installed with metal screws to a plastic box which is screwed to the gimbal.
    This has been happening on old and new 32bit boards/sensors and different gimbal mechanics too.


    My best hint on this problem is the i2c cables resonating to this big source of IMU. Ferrites might not be enough, shielding i2C cable neither. I tried both, no help.
  • Take a look to this video, this is what it happens from the camera point of view.
    In this case i was flying the gimbal with a single rotor helicopter. I took off with the tail pointing the city, gimbal heading towards the river. EMIs coming from the city-tail side are blocked by the helicopter structure, after pirouetting towards the city gimbal gets crazy.
    This is a really old video using an 8bit 2 axis board, pan controlled by a servo not affected by interference.

  • I am 99.99 % sure that is something else than EMI from the city. EMI does not affect anything from far away.

    Also if gimbals generally would not work in cities, there would be plenty of posts of that.
  • EMI is the only thing i could correlate with the problem on the gimbals, i have followed other people in forums going thru the same problem.
    Rasec whom originated this thread described what happend with his Basecam gimbal as well (not happening with Zenmuses, same here too).
    I've been chasing this problem over the years with no luck, render my Basecam gimbal useless for work in the city, really frustrating.
    I've had dozen of problematic flights and many others with no issues following the same pattern, using different gimbals and board models.

    I remember one time shooting in a particular spot in downtown where the problem was there right after turning on, you could even hear the crackling noise of the motors while on the ground, going completely crazy after climbing up a few meters.
    After that i returned to the same spot (a congested street in downtown) with the programmer and GUI which showed lot of i2C errors, that gimbal was 0 error on the bench or somewhere else far from the city.
    Got examples like that in excess!

    If it is not EMI hitting the i2C lines what it is?
  • I2C errors are because mismatch of IMU, Board and cable and EMI. There is many IMUs that do not work that well with some boards or configurations, because they have different termination resistances etc. It is best always to use the IMUs that are designed for the board and as short cables as possible. I2C is not well suited for long cables.

    Long cables are a problem, yes they are more prone for EMI, but also crosstalk etc. Twisting one of the data cables with + and other one with - can help. Also shielding data cables can help. and the IMU cables should always be run separately of other cables.

    Yes the I2C is not ideal and among other things it is prone for EMI. However gimbal motors/board and multicopter electronics, video transmitters etc. are a huge source of EMI and right next to the IMU cable. There could be areas where external EMI is so extensive that (and on the wrong frequencies) that it could cause problems. A city as far a way as on the video above is not such EMI source. A power line next to the multicopter could be, or a radio mast.

    If the cables are well scolded it will protect them from EMI, but shielding the cables changes the cable properties and can cause problems. I have used over 1 meter cables with the 8 bit and first 32 bit boards (that were very problematic with I2C) The cables needed to be carefully shielded.

    with the 'BaseCam SimpleBGC 32-bit' I am using 70 cm cables without any shielding or ferrite rings.

  • Garug,
    I will setup a series of tests to check if theres any change in the behaviour of the impact of the interference, i will try also to install some type of telemetry in order to live monitor the i2c errors beyond bluetooth range, got a couple of 900mhz modems which i think it will work.
    I will come back with news.

    ps. all my boards now are 'BaseCam SimpleBGC 32-bit' with the long cable which i think it is 70cm too.
  • Sounds good, that should work fine, just keep IMU cables separated from other cables. Use the supplied ferrite rings on motor wires if needed and it is important that IMUs that came with 'BaseCam SimpleBGC 32-bit' are used on the setup.

    There is couple of things to check if any problems.

    1. are the motors ok. resistance between all motor pins should be about the same and there should not be any connection to motor metal parts.

    2. how is the board powered? If powering from flight battery I power the gimbal from battery balancer port. If inverters are used make sure they are good quality and not causing noise.If the board power cable is long, maybe good idea adding a 10 to 1000 uF capacitor near the board.

    3. and it is always good to keep the IMU cables shortest possible. On 2 IMU setups I have the frame IMU typically on the same box than the board, connected with very short cable, only the Camera IMU cabe is long.

  • Garug,

    "1. are the motors ok. resistance between all motor pins should be about the same and there should not be any connection to motor metal parts."
    Yes, always check resistance between phases. All ok thru all the gimbals that had the problem.

    "2. how is the board powered? If powering from flight battery I power the gimbal from battery balancer port. If inverters are used make sure they are good quality and not causing noise.If the board power cable is long, maybe good idea adding a 10 to 1000 uF capacitor near the board."

    Some were powered with their own batt, others thru the main (motor) batteries+step down regulator to 15V. Same issue with both.

    "3. and it is always good to keep the IMU cables shortest possible. On 2 IMU setups I have the frame IMU typically on the same box than the board, connected with very short cable, only the Camera IMU cabe is long"
    I have not shortened the provided wires on the 32bits, on older boards where you had to provide your own cables i chose to cut them in the lenght to let tilt/roll to operate freely, say 30/35cm long.
    Here again had problems with old and actual cables.

    Still need to test braiding +5v-SDA / GND+SCL as you recommended, i was not able to go out to test yet.

    http://picpaste.com/gimbal_blc_01-lv5kHwPq.jpg

    http://picpaste.com/gimbal_blc_02-C1X2GmDi.jpg

  • Some info about that? I have same behavior in some cities, specialy near TV HD emissor antennas. Maybe some kind of EM shield?
  • Other than this big problem my basecam gimbals work like a charm.
    I gave up on solving it on standard 32bit board with i2c IMU sensors.
    I was unable to solve the EMI problem no matter what i tried, i dedicated lot of effort but no luck.

    Having big hopes on the CAN IMU which should not be affected by EMI like the i2c line.
    Got a couple of Extended boards+CAN IMUs on order. Will test them right away,
  • Updating this thread:
    I know this has been a very dissapointing issue for those suffering it.

    I just finished testing the new Extended board with the CAN IMU sensor, it completely solved the EMI interference problem!
    I replaced the old 32bit board by the new, same gimbal mechanics and electronics.
    I flew the gimbal in a known spot with lot of surrounding EMI (where i had issues with the old board), completely successful results.

    So if you still having the problem (gimbal getting crazy in the middle of the air), switch your standard 32bit bit board + i2c IMU for the new one.
    Problem solved.

    (video tests available for those interested)
  • Hello this happen to me this week, our gimbal is 2 years old and already work on a lot of projects. This is our best gimbal. Ronin happens to be hit also but minimal, yes we did a flight near a major tv station and radio. We already tried everything by the book but still it happens in 20-30 meters altitude. What board version @Cfarg you were referring to?