[yashuone]

Hi folks, I just set up a new quad and am having some issues. Equipment is as follows; X210 frame, Emax 2206 II 1900kv motors, dys XSD20A ESCs running oneshot, Matek XT60 PDB, CC3D Atom FC, FS-iA6b Rx running ibus and an FS-i6s Tx. I have flight mode on channel 5, three position switch, arm/disarm on channel 6, two position switch and ASWA on channel 7, two position switch. I had this same setup on a 250H frame with a regular CC3D and different, generic PDB and the same settings with no issues so the only differences are the frame, PDB and Atom.

My problem is this, when connected to the computer via USB all checks out and functions correctly EXCEPT that on the firmware tab the input box is orange and when clicked states that the model may be in failsafe or that a channel is unassigned. Once the model is disconnected from GCS arming and disarming becomes erratic and inconsistent. It may take some time to arm or not arm at all and more worrisome is that it will not disarm when the channel 5 switch is flipped back to the disarm position. I have not tried a test flight to see if anything else is off as the safety of this current configuration is questionable at best.

Any ideas?

[yashuone]

Well I have been fiddling with this and seem to have worked things out at least a little bit. First off I went into my Tx and disabled channels 8, 9 and 10 as they serve no function right now though I don't know how they might have interfered while activated but unused. I also saved my settings then erased and reinstalled the firmware and then reapplied my settings. After disconnecting from USB and cycling the battery power things appear to be behaving as they should.

On a related note, how can I have the disarm function react more immediately? It takes a full two seconds for the motors to cut out after the switch is disarmed and for safety's sake and to preserve my motors in the event of a crash (I am running "motors spin at idle" for use with ASWA) I would like this to happen with a little more haste.

[yashuone]

Ok, looks like I have to wake this thread up again not that I'm holding out much hope for a response


This new Atom FC is still giving me some issues. Sometimes it arms and operates without issue and then, on occasion, I will get the rapid flashing like it's loading but then it settles into a "dot dot dash" pulse (picture Morse code here) and the quad is unresponsive to arming or any other function. It will go back to the rapid flash occasionally but generally goes right back to dot dot dash after several seconds of rapid flash. It did however change to a dash, dash, dash, dash etc pattern after several minutes of the dot dot dash pattern and allowed me to arm. This only occurred once though. I have left the quad alone for several minutes when the dot dot dash state was present on a couple of other occasions to see if it would repeat this behavior (to no avail).

I am completely baffled by the inconsistency with this issue. Most of the time everything functions perfectly but about 20% of the time this issue pops up. Nothing else is changing in the configuration or in my pre flight routine. Any ideas would be welcomed

I should also mention that this is the first FC I have loaded and programmed with my mac as I was having issues getting GCS to find the FC when connected via USB on this machine. LP running on this machine has a glitch on opening in that the "loading core plugin" message on the splash screen gets stuck and won't progress until I hit the "esc" key. This machine is an older iMac running OSX 10.7 as that was the last
OS supported on this platform. Besides the splash screen issue the program appears to function normally.

Don't know if these things are related but I want to give as much info as possible in the holes of resolving my problem.

[FischerZ]

Hi!

I had an similar config (Flysky Tx and ia6b Rx - but I use PPM cause i wanted to use the Flexi and Main for an GPS with MAG) and similar Problems.
Reason for the Problems was, that the 5V-Output from the Matek PDB only delivered 4,6-4.7 V - not more!

I have built in a BEC directly to the 12V from the Battery and now it works without Problems. I think, that the 4,7 V are too low for the ia6b-Rx....

Perhaps this is the Resolution for your Problems too?!

[yashuone]

Thanks. This will give me someplace to start. I guess I now have an excuse to go search down the odd little battery for my multimeter. This definitely sounds plausible and I was wondering if I was experiencing a voltage issue as all my searches resulted in the same "if the blue LED is functioning, the board is good". I will check this out and let you know.

[yashuone]

While I'm not hitting 5V I can't imagine this is not enough...

[yashuone]

I'll check the voltage next time it starts acting up. Is there any precedent for a BEC on a PDB to have voltage fluctuations?

[TheOtherCliff]

Just to be clear, you must put the quad on a firm (doesn't have to be level) surface for the gyros to init correctly.  You can't hold it in your hand and expect a good init.

-----------------------------------

Try disabling Attitude -> Settings -> WaitUntilTheBoardIsSteady

Some clone sensors have a little more noise and that makes it think you are moving the board.

If that fixes it you can increase System -> Settings -> AttitudeSettings -> BoardSteadyMaxVariance
try 7 or 10.

[TheOtherCliff]

I now have a Sparky2 that is doing the strange LED behavior: two quick orange blips, a longer blue, then blue and orange alternating for about a second.  USB or FC power.

It is a new FC that was flying fine (2 flights) before on 16.09.  I flashed a version of next onto it to test some oplink stuff, while there I changed the oplink uavo.  Then I flashed 16.09 back and manually put the oplink uavo back to what it was.  I exported settings and verified that the are the same as the flying version (which I luckily saved when it was working).

Nothing I have tried so far will fix it:
- reflash with 16.09 (again) and erase settings and restore to the old working settings
- disable WaitUntilTheBoardIsSteady

Using default settings works though, so I will change things back to default one at a time and see what fixes it.

[yashuone]

Interesting... I think that I usually set the quad down immediately after connecting the battery but to be honest I really don't recall if I allow it (wait too long) to init before setting it on the ground. I will pay more attention and maybe do a few experiments to see if holding the model after battery connection results in the behavior I'm experiencing (before disabling WUBIS). My concern is that since the erratic board behavior only occurs every so often that I'm not quite sure how many times to cycle the board before being satisfied that the issue has been isolated.

Considering what you said I'm assuming that gyros are initializing during the rapid flash. Is this correct? The LED also does this upon arming but only for a moment.

That seems like quite a process with the Sparky2 having to basically punch list all the settings. I hope you isolate the issue earlier in the process rather than later  I wish I could be more than moral support but I'm still a newb at all this stuff. Thanks for your input, I feel fortunate to have the superb knowledge base this forum provides.

[TheOtherCliff]

I have found that when I have it happening consistently, cooling it with freeze spray makes it go away.  That could be caused by a bad component, a bad solder joint, or even a code issue (but I imagine a code issue is unlikely).  For a code issue, some things run a little faster or slower if the temperature is different, especially where analog is involved.  It's possible that the code runs right if A finishes before B, but not if B finishes before A.  The issue is in startup because I can freeze spray it when it is happening and it never straightens out, but if I power off/on after freezing it, it works correctly immediately on boot up.

Revo class FC's have a baro, but not CC3D class FC's.  You must be careful not to get the baro wet or blast it with too much pressure.

This is likely to be an issue that can only be recreated on a very few FC's and you and I have one.  I will test my "bad" config file on an authentic Sparky2.  The one I have used so far is a clone.

Let me know if you find you can make it come and go with gentle warming or cooling.  If everyone finds that it happens when warm, not cool then it is less likely to be a solder joint which would probably be random.  If it turns out that it is recreateable on a significant percentage of high quality FC's than it may even be a code issue or something that can be worked around with a code change.

Also, I have found that changing any of several settings back to default makes it stop happening.  The settings I found were all Revo class only (not CC3D) and I didn't look for more.

[TheOtherCliff]

The next time it happens, how about saving the settings and posting them here?  Or just a settings uav file that you know has the issue.

Even better, make sure you can recreate the issue from power on with everything unplugged except the power.  Post that uav file (if changes are needed) and I can try to recreate with my CC3Ds.

Right now the thing I can think of that fits most of the facts is voltage regulators.  Powering from the flight battery uses the ESC BEC which has a slightly different voltage than the computer USB, if just from manufacturing tolerances.  Different temperatures cause the regulators to act a little differently too.

It is fairly easy to add some capacitance or swap out regulators to test this.

[yashuone]

I get my power from the BEC on the PDB as the DYS XSD20A are "opto" or no BEC... Anyway, I have had time to mess around with this quite a bit now and it seems that Occam's Razor prevails. I have been able to recreate the "issue" consistently by holding onto the quad after battery connection and have found that every time I set the quad on the ground IMMEDIATELY after the battery is connected the issue is gone. It seems I had created a habit of holding the darn thing in my hand as I was messing with the settings (no props and still connected to the computer) and just hanging onto the quad since there was little room to place it down on the disaster I call my desk.

Soooooo... in summery, user error 

I'm not really sure why this has not come up with me before. The only thing I can think is that my other builds were on frames with much more room and accessibility and this X frame is very tight with access to the USB and other ports not as easy as my "H" frame so I tend to hang onto it while I'm fiddling around. Thank you though for both pointing out the obvious I was missing and coming up with other possibilities for me to check into.