Servers by jDrones

Cumulation of crashes due to seemingly weird input (Pixhawk 4)

(tridge) #41

Hi David, thanks for dropping in!

not by default, no. We do have SERIALn_OPTIONS parameter bits in master to enable RXINV, TXINV, SWAP and HDSEL, but for now we don’t turn any of those on by default on FMUv5.
You’re absolutely right that I missed the connection to PG14, and that PG14 being configured by default as USART6_TX gives it a pullup. I’ve tried changing that, and it does get rid of the pullup, but doesn’t actually improve reliability. I still find that if I use the old NuttX based IOMCU firmware that I get occasional SBUS input corruption. It is less frequent, but still happens. I don’t get any corruption with the firmware builds I linked above that switch to the ChibiOS based IO firmware.
Still, I agree that configuring PG14 as either an input or 1-wire is the right thing to do, even if it isn’t a complete soln.
One theory I have for why the NuttX iofw in older ArduPilot builds has issues is that it may lose RX interrupts on PB11 (USART3_RX) on the F1. Perhaps the default of -Os is increasing interrupt latency enough to be losing bytes, probably in the DMA callbacks for the USART2. Under our ChibiOS builds we compile the DMA callback code with -O3 to keep interrupt latency low, but we don’t do that for the old NuttX build.
That wouldn’t explain why this is different from what happens with the Pixhawk1 and Pixhawk2 though.
Which leaves just one other key difference, the one Arthur pointed out to me, which is that on the Pixhawk4 the DSM input on F1 PA10 is the same external pin as the inverted PB11 for SBUS, whereas on Pixhawk1 and Pixhawk2 the DSM input is separated. So maybe when we lock onto SBUS we should change PA10 to be an input.
Either way, the fix I’ve linked above does work reliably. I’ve run it for many hours with no issues with the above SBUS stress tester input.
Cheers, Tridge

(tridge) #42

I didn’t know about the issue at the time of release. I had done quite a bit of bench testing of my two Pixhawk4 boards and hadn’t seen the issue. Once I saw this thread I tried a lot harder to reproduce, and found I could reproduce with a SBUS stress test.
You are right that we didn’t get onto this as fast as we should have though, and I apologise for that.
Cheers, Tridge

(Helge) #43

Tridge & David: do I understand it right, that the SBus Pin PB11 has a connection to PA10 (DSM) as well as to PG14? To me that sounds a bit confusing and it increases the risk for GPIO configuration errors. If someone mods the hardware by seperating these lines that may carry another risk that there is no pullup anymore on the SBus input which means it becomes free floating. If the receiver fails, you may also get this rubbish on the input.

(Cornel Fudulu) #44

I lifted PA10 off the board, as I don’t own or use DSM. Signal now runs only thru the SBUS inverter ( 8-pin chip marked V240 ) to PB11.

(John DeVere) #45

For those like me wondering if this is released, yes, this fix is in copter 3.6.3

(Helge) #46

Summarized, I still do not see the “fix” as an elimination of the problem at the root cause. You may be able to detect irregular bytes by checking the parity bit - but what happens in that case? We see from the logs of the crashed drones that there is not only a wrong packet sporadically that could easily be dropped. When the problem occurred, the logs recorded weird values on the channels continously until the drone crashed. If the “fix” means, the controller keeps using the last valid channel value, this would mean the drone will still be out of control.

Looking at other FMUv5 controllers (Pixhack V5, Pixhawk 4 Mini), they also share DSM and S-Bus input on the same pin - but are they also connected to USART6 TX or is this a particular difference for the Pixhawk 4 (and propably the root cause)?

For me, the situation is still not cleared and this means I will not trust Pixhawk 4 until I see something official from Holybro stating that the root cause is eliminated instead of calming the symptoms.

(Helge) #47

Could someone, who made a hardware mod (seperating the S-Bus input) show a picture or drawing, please?

(Christian) #48

I plan to rebuilt my crashed copter in a few weeks. Can anyone confirm wether or not it’s safe to use the pix 4 currently? Is the problem truely solved?

Please answer honestly, I’ll rather buy a DJI controller than crashing my expensive and heavy copter once again.

(rmackay9) #49

I think it is safe to use the Pixhawk4 but it is very important to specifically load the right firmware because the bootloader on the board doesn’t allow the ground stations to know that it’s a Pixhawk4 (it just looks like every other pixhawk).

The Pixhawk4 firmware can be downloaded from here:

P.S. we want to come up with an easier solution to avoid this manual step. Our ideas are:

  • Ask the GCS developers (i.e. @meee1 for MP) to add a drop-down to allow the user to specifically set which firmware they want to load onto the board (issue is here)
  • Ask Holybro to update the bootloader so that the board can be distinguished from other Pixhawks

(Yovin Yahathugoda) #50

@tridge My Pixhawk 4 is running Arducopter 3.6.4 and this RC issue is still present. It keeps happening at random times and today it happened just before llanding. Log files are attached and i would appreciate if someone could give me a fix.

(tridge) #51

The log shows you are running the generic fmuv5 firmware, not the Pixhawk4 firmware. We only applied the change to the Pixhawk4 firmware. I can tell it is the generic fmuv5 firmware from this message in the log:

2019-01-11 15:40:55 fmuv5 00390031 30385108 38333933

that should say “Pixhawk4” not “fmuv5”

The problem is that if you let MissionPlanner choose the firmware for you it will choose fmuv5 if you have the original bootloader. To fix this we have applied the same fix to the generic fmuv5 firmware for the 3.6.5beta1 release that Randy put out today.

Meanwhile, please load this firmware:

that is the 3.6.4 release with the fix applied for Pixhawk4.

Cheers, Tridge

(Yovin Yahathugoda) #52

@tridge thanks a lot, will try with this firmware.

(Yovin Yahathugoda) #53

@tridge I flashed the firmware file you sent and used Huibean’s sbus generator code to test if the issue still comes up when an oscillating SBUS pattern is sent to the Pixhawk 4. It comes 30-40 seconds after the SBUS signal is sent to the Pixhawk, is this still supposed to happen?. Attached are the log files.

(Christian) #54

Could you test whether or not the issue appears when using this ‘sbus generator’ + Pixhawk 4 with PX4 code?

(Yovin Yahathugoda) #55

@Tuner25 Tried that too, but then all RC inputs go to 65536.

(Helge) #56

Could you please explain this a little bit more? Do they go to 65536 after some time or immediately? If immediately, this could mean PX4 does not “understand” the S-Bus signals from the generator at all.
Looking at the code of the generator (
Perhaps you could increase the update rate from 8ms (as given in the code) to 10ms (as used by FrSky for their receivers) or 14ms (originally used by Futaba).
Perhaps you could use 1500ms as initial PWM value in the setup() procedure.

(Yovin Yahathugoda) #57

It goes to 65536 immediately and i am using 15ms update rate for both Ardupilot and PX4. The issue comes up on Ardupilot after about 30-40 seconds.

(Helge) #58

If you have the option, I would try with an inverted signal and 14 ms update rate.

(Christian) #59

What does ‘65536’ mean?

(James Pattison) #60

It’s the maximum number represented by a 16 bit integer. Sometimes uint16_max is used to represent an error, but you’d need to check the code.