that said, I’m still going to move over to a bigger/better FC, but that will take at least a week so I figured I would keep messing about
For whatever it’s worth, I’m running a Matek H743-SLIM with the following points:
- CRSF including Passthrough Telemetry on UART6/Serial7 set to RC_IN.
- BRD_ALT_CONFIG set to 1 in order for the TX side of UART6 to function.
- Nano RX set to CRSF TX and RX for ports 1 & 2.
- RC_OPTIONS bit 8 (256) is set.
- Radiomaster TX16S running latest OpenTX, and Yaapu script Horus Widget version 1.9.3 beta4 with CRSF passthrough enabled.
Hope that helps.
I flew again. It appears that with “RC over mavlink” turned off I experience great improvement but not full resolution of the issue. I flew out to 400m with no failsafes, I was prematurely counting victory, but then I got a single failsafe at a distance of maybe 50m, direct line of sight. So it’s dramatically improved, but not completely resolved.
@davidbitton great information considering my desire to move to that FC myself thank you. But are you saying you ARE experiencing failsafes, or is it all smooth flying for you with that setup?
Last flight was an autotune and she went from start to finish w/o a failsafe.
@davidbitton I’ve got my Matek H743-SLIM installed and almost fully functional. Quick question since you have experience: the documentation is confusing about the ADC current pins. The mapping document shows an “onboard current pin” as pin 11 with a 40A/V scaling, and a BATT2 current pin as pin 7, with no listing for A/V (sensibly, since that would be for an offboard sensor).
I’ve got a 4-in-1 ESC with shunt, and that signal is connected up via the 7-pin connector to the Matek “CURR” pin. Which ADC pin is that “CURR” pin wired to, 11 or 7?
I tried both: pin 11 gives me no data, pin 7 gives me nonsensical data.
And an aside: the board has almost no current-sourcing capability; is there really an onboard current shunt? That would seem a bit odd.
If you take a look at the hwdef.dat file for the Matek H743-WING/SLIM/MINI, you can see the settings for the ADCs.
These are the defaults that should work out of the box. If you are using the 4in1 connector, then you should be able to leave the settings defaulted. Yes, BAT_CURR_PIN is 11 and HAL_BATT2_CURR_PIN is 7. One of my builds in an X8. The first 4in1 uses the connector, and for the other 4in1, I use the pads on top of the board, including BAT2_CURR and BAT2_VOLT, and S5 - S8.
You should be able to make out the wiring:
https://www.evernote.com/l/AArEJyaeOwxKepVyqnJ4bQ7KGGM7wk4nMWQB/image.jpg
Also, don’t forget to setup ESC telemetry and set BATT2 to ESC_Telemetry.
oh man this hobby can be incredibly frustrating. I thought I had it all figured out, my problem with the radio failsafe seems resolved, it’s incredibly beautiful and perfect for flying outside, so I go out and start it up no problem, autotune it with my new setup, get through that, switch batteries, arm the motors, nothing. No props turning. I try a different battery, same deal, the props just won’t turn. It’s armed, it seems ready to go, and I guess the ESC isn’t having any of it? So I put it aside for ten minutes, I come back to it, it powers right up and props turn and it all works and I fly only a bit because the battery was low, so I come back and switch batteries and nothing again. So I guess I’m done with this thread for now, thanks for the advice and the resolution to the RC failsafe problem was to get a different FC with more flash, and not use the rc over mavlink. At least it seems ok for now, if I can ever get a chance to actually fly I’ll let you know. And now I’m going to search for “intermittent ESC motor start failure” so I can try to troubleshoot this new problem.
This is the problem @tridge saw a week ago. Our theory is its to do with the dshot calibration code - I have now removed this code, so if you are able to try https://firmware.ardupilot.org/Copter/latest/ and see if that fixes it that would be really good.
I will try; shall I report my findings here, or on some other thread?
I just loaded the latest .hex via, betaflight since MP won’t deal with the .hex, and I had forgotten that I lose all my parameters when I do that. I had a saved set from a day ago so all I lost was the autotune so it’s not a big deal, but it’s time for me to figure out how to do a FW update properly. What’s the least invasive way to upgrade FW, ideally without losing any parameters? Do I build the .hex to an .apj and then use MP? If so, where do I learn how to do that? Using Betaflight to flash arducopter FW is a strange kludge.
I have found that sometimes saving a parameter set and re-loading after FW upgrade does not fully reload the parameter set. In particular, I’ve twice had the experience where the dshot settings did not come through with the parameter load, and it took me some troubleshooting to figure out why my ESC was initializing as all PWM. Why is it that the saved parameter file does not contain all of the parameters all of the time? That’s a strange thing to me.
time to try the latest
Download an apj from that link and then use MP to load it. You won’t lose your settings.
Some of the “Enable” settings require you to refresh params after the first reload, then reload a 2nd time to fill in the missing ones.
1 Like
Ok I updated to latest and I had a wonderful session just now, without any problems. No RC failsafes, and no motor ESC fail-to-start experiences. I probably armed/disarmed 8 times, no issues. I’m happy about the switch to the Matek H743-SLIM, and I’m relieved that the ESC failing to spin the motors is NOT a fried ESC.
Thank you to the developers for all your hard work, when it all works it’s a beautiful thing.
3 Likes
I experienced a single failsafe during my entire session tonight, but it occurred close to launch (much closer than I had been flying) and it came as an inexplicable decrease from perfect reception. This is with the latest 4.1.0-beta1 on the Matek H743. So maybe not fully resolved quite yet…
I’m curious if anyone has had this issue on the newer V3 Nano RX? I’ve been in a month long email discussion with TBS discussing these issues. This thread is whats happening to me. I’m not sure if this belongs in copter or plane as it has occurred on both.
I’ve suffered loss of bind on both copter and plane versions 4.1.X whilst running CRSF 6.10, 6,12 and 6,13. It’s rather frustrating but ok on Copter but on Plane it is terrifying watching the plane circle above the home point with no bind. Thank god for F/S settings being correct and geo fencing for good measure.
This has only occurred on AP with the newer Nano V3 RX’s. Admittedly I have not flown my older version RX’s as much. It has occurred on the Matek 743 Slim and Matek 743 Wing V2 running the latest versions of Copter and Plane.
My older RX’s are on Betaflight and Inav so that may be the difference but I feel it is irrelevant to this issue but worth mentioning for context. I have two Diversity RX’s on a Matek F405 and a Kakute F7 Mini V2 both running the latest release of Arduplane and so far I haven’t had an issue.
A loss of bind sounds like its on the TBS side. I’ve occasionally had failsafe’s which I have put down to lack of CPU on some of the lower power flight controllers combined with my rather extreme settings. If you are using H743’s then this is not your problem.
Thanks for the vote of confidence. I even put the RX on a seperate BEC just to test if it was power related but same result.
I did provide entertainment as I ran around the farm trying to catch the plane as it circled lower and lower 
I have two setups with the same radio setup but different flight controller. The failsafe on the kakute always unexpectedly DOES NOT RTL but just immediately disarms, but on the matek board, it goes to RTL as expected. So, it seems like it might either be the kakute f7 board itself(seems unlikely), or something with the specific kakute copter ardupilot build? Or perhaps a difference between arduplane and arducopter?
Holybro Kakute F7 V1.5
arducopter 4.1.3
frsky x10 radio with Archer RS receiver
Fport telemetry
SERIAL6_BAUD,57
SERIAL6_OPTIONS,7
SERIAL6_PROTOCOL,23
FS_OPTIONS,1
FS_THR_ENABLE,1
Matek F405-Wing
frsky x10 radio with Archer RS receiver
arduplane 4.1.6
Fport telemetry
SERIAL7_BAUD,57
SERIAL7_OPTIONS,7
SERIAL7_PROTOCOL,23
If you’re testing radio failsafes on the bench then that’s the normal reaction for Copter. Plane and copter don’t react the same when ground testing radio failsafes.
From the wiki:
If the copter is disarmed, no failsafe will take place.
If the copter is armed but has landed, the copter will immediately disarm.
If the copter is armed in Stabilize or Acro modes, and the throttle input is at minimum, the copter will immediately disarm.
Otherwise, the copter will take the actions as configured in the parameters described below.
https://ardupilot.org/copter/docs/radio-failsafe.html#what-will-happen
Allister,
Thanks for the refresher on the failsafe docs. I bench retested the copter failsafe with the transmitter throttle >0 and indeed it uses Land as the failsafe mode and not immediatley disarm. I think it went to land instead of RTL because I was at my home location. At least I am confident now to test the failsafe in flight.
1 Like