Sometimes I get the service bulletin warning - sometimes I dont

I need help determining if my Cube is actually affected. My problems started the other day when I was trying to setup Yaapu telemetry (

I set my serial port protocol - but if the FRSky converter is plugged in, my cube does a bit of a soft brick and the orange LED under the cube flashes orange and my MAVLed lights produce a pattern I have never seen. Connectivity is unreliable and erratic over USB and these symptoms persist even after unplugging the FrSky Smart Port converter. When I am successful at connecting, I get the “Failed to Init Cube Black: Check BRD_TYPE” errors. I started looking at the params and noticed that INS_USE3 had been set to 0, target temp was set to -1. Still no service bulletin warnings at this point, but the board wont fully boot.

In order to get things working again, I have to install rover, then re-install copter. I previously had 3.6.8 installed, but updated to 3.6.9 when reinstalling copter. At this point, the service bulletin message pops up. However - when I load the CUBE_BLACK.param file @philip provided, then the service bulletin message does not show up upon bootup and everything seems fine. I didnt get the service bulletin warning prior to all of this through countless power cycles and MP connects. (on 3.6.8). Im confused.

Is it possible that altering the params (ie - edit INS_USE3 to 1, EK2_MASK to 7, etc) AFTER getting the service bulletin warning can trick mission planner into thinking that everything is OK? Is everything actually OK if the service bulletin DOESNT show up?

Is it possible that if this hardware fault is transient, it wouldn’t show up until the operator updates to the next release? (when the params would be set back to their defaults; maybe that allows the service bulletin check to function correctly?)

it seems like under some conditions, the service bulletin shows up and it doesnt show up under other conditions.

If it shows up, ground the cube. End of story

Sure. No problem. I’m not flying it, but I am 85% sure in this case the service bulletin warnings I get are false positives. Hear me out.

I did some more bench testing:

At the time, I also had some mavlink leds connected:

So, i had these serial devices connected; all essentially being powered through the pixhawk and everything was humming along just fine, no problems:
Serial 1: Telem Radio
Serial 2: Mavlink LEDs
Serial 3: GPS1
Serial 4: NC
Serial 5: NC

Like I said: I was trying to set up frsky telemetry pass through with this cable on Serial 4:

…So I set SERIAL4_PROTOCOL==10 for Frsky Pass Through and connected the cable. Again - I was expecting it to be powered through the pixhawk. I assumed powering through the pixhawk was OK because the receiver itself is powered through the Sbus and the Smartport/pass through port specifically only has a signal and ground wire. I assumed there would be negligible power draw.

Once I had the serial port configured and the pass through cable connected, I powered the cube through USB to test. At this point, the Cube didnt fully boot, no startup jingle and “Failed to Init Cube Black” errors started popping up, PID tuning page was grayed out, temp target was “-1”, INS_ACC_ID and INS_GYR_ID all 0s, USB connection was unreliable and erratic and a few other anomalies.

At first, I thought I may have fat fingered some parameter, so I re-installed copter3.6.9. Upon a fresh install, the service bulletin warning popped up UNTILL I UPLOADED THE CUBE_BLACK.param file provided in the SB thread. After uploading the CUBE_BLACK.param, there were no more bulletin warnings. To reiterate - I followed these instructions and did not get the service bulletin warning once complete:

  1. You MUST run Latest Ardupilot RELEASE CUBE BLACK code.
  2. You must use latest Mission Planner or Latest QGC
  3. Set the following parameters
    CUBE_BLACK.param (98 Bytes)

(or EK3_IMU_MASK == 7 if using EKF3)
INS_USE == 1
INS_USE2 == 1
INS_USE3 == 1

  1. Save the parameters
  2. Reboot the cube
  3. reconnect mission planner
  4. If Mission planner flags your code, contact your local re-seller, and log the issue. DO NOT FLY TILL I HAVE PERSONALLY CHECKED YOUR LOGS, and either given the go ahead, or, organised what we will do next in your case.
    8.Further flight is only to be conducted where you have carried out a full risk assessment on the implications of a failure occurring, the new code is good… but it should not be relied upon as your only means of protection. You must not fly over people, you must not fly over critical infrastructure, you must also take responsibility for your payload and vehicle.

…Then I noticed this bit in the description of the Mavlink LEDs:

Notice: When more than 12 LED beads are used, the telem port of Pixhawk can not supply enough power, so you need power the Mavlink controller from an external 5V source.

I was using exactly 12 LEDs (2 per, 6x modules as shown)

So I tried disconnecting the Mavlink LEDs and leaving the FrSky Pass through cable connected. And it worked!

One of the weirdest things is that the ACC_ID and GYR_ID parameters are 0 when the cube is in an overloaded state - which is where and why I think Mission planner might identify a false positive.

TL:DR - I think I was overloading the Cube’s power dist capacity.

These results are repeatable for me after several attempts:

  1. Configure Serial ports
  2. Connect the following:
    Serial 1: Telem Radio
    Serial 2: Mavlink LEDs
    Serial 3: GPS1
    Serial 4: FrSky passthrough
    Serial 5: NC
  3. Bootup fails; orange blinky light; Cube becomes potato; ACC_ID,GYR_ID==0;IMU Temp==-1; grayed out PIDs; Failed to Init. Service bulletin warning does not always come up. (When it does; CUBE_BLACK.param corrects it?)
  4. Disconnect any 1 of the above serial ports
  5. wait some time (not exactly sure how long since i didnt time it i just walked away for a while; an hour?)
  6. boot up and everything boots up fine; all parameters back to normal (including ACC_ID!); no service bulletin warning

I am already in contact with my reseller (robotshop) - they are not any help and frankly I shouldnt have bought from them. They just direct me to the SB thread. :roll_eyes:

I think I am seeing symptoms similar to the peripherals brownout:

…but my Cube takes nearly an hour to reset.

Please RMA it anyway just to be sure, but please post a link to this topic on a sticker on the cube, so the team can follow up.

Better safe than sorry

Got my replacement RMA unit - noticed that INS_USE3 = 0 by default when loading copter 3.6.9 - is this expected?

Load the parameters listed in this bulletin.

We do not control Ardupilot