Chirping out of order question

The source code in main.c at lines 171 to 209 (the main logic for the Flight Control Board), fires off "wake up" commands to all of the BL-Ctrls that should be present on the copter. There's a timeout delay that allows up to four seconds for the BL-Ctrl boards to "wake up" (as the comment in the source code calls it).

So each BL-Ctrl has a four second window to respond. It's a bit of an electronic crapshoot as to which BL-Ctrl responds. The logic does not wait for each BL-Ctrl in turn -- it just shouts "wake up" at each BL-Ctrl board and moves on to the next, then checks that all of them have responded within the four seconds.

The amazing thing is that the actual sequence in which the BL-Ctrls respond ever is the same, not that the order varies sometimes.

So it's more important that each motor respond, chirp'n'twitch, than it is they do it in a particular order.

When you power up your copter be amazed if the order in which things happen is the same as it was the last time -- what matters is that all the motors respond!

Andy.

 

Well, Jim, recent experience has shown that the answer to that is most likely to be something physical. Certainly check the cables, also look at the FC, NC, and PDB boards and make sure there is not the minutest whisker of solder between the C and D connectors.

Then you'll need to try a process of elimination: If you have the GPS and NC board, unplug the ribbon cables that connect them to the FC board and see if you still get the errors.

Then try unplugging the PDB from the FC, connect MK Tool to the FC and see if you get the errors. You will, of course, get errors as you lop off bits of the system, but ignore those -- what you're looking for is just the I2C bus errors.

The general diagnostic strategy I'm following has the rather prosaic name of "unplug stuff until the system starts to work right" -- and then start plugging stuff back in. When what was working stops working, then what you just plugged back in is causing the problem.

This strategy is viewed as a trade secret by those in the computer business and we charge big bucks for it, but it really does come down to just what I describe. Just don't tell anyone I told you this....

Andy.

 

As Andy mentioned and has been seen in the last couple of situations, small wire whiskers that were almost invisible without a magnifier were the cause of errors.

 

Probably or something worse like a short on a power cable. After doing an board work go over it with a good light and magnifier.

 

Now I'm officially puzzled. No I2C errors in GPX files but you see them in MK Tool? Oh....wait a minute....I seem to remember there might have been a bug in the NC board firmware where the I2C errors were sometimes (or was it always?) showing as zero in the GPX files.....

It's not just the C and D pads you need to check....check the whole boards. Solder bridges/whiskers might be causing the I2C errors at other places (e.g. where the traces from the C &D pads/mini-Molex connectors go to).

Andy.

 

Andy I to remember seeing the release notes about the 0 recorded errors being fixed.

 

Yeah...I'm going from memory. Was it in the 0.X8 series firmware it was fixed?

Andy.

 

NC 0.28p (Bugfix 22.11.2012)

• FC_I2C_ErrorConter in the Logfile was always zero
• Start Logfile with 3 satelites