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
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
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.
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.
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.
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
@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.
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:
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.
@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.
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 (sbus-generator/sbus-generator.ino at master · Huibean/sbus-generator · GitHub):
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.