I take it 4.1.0-DEV lacks the CRSF tele passthrough functionality at the moment?
It occurs to me that I should perhaps try an even earlier FW to see if the crossfire failsafes continue, like the stable 4.0.7. I’ll try that next, as a troubleshooting step, and just deal with the lack of telemetry long enough to collect a failsafe (or not, hopefully).
CRSF is only supported on 4.1 and is compiled out on the KakuteF7 anyway - I recommend you upgrade to a different board if you can as that one is at the very bottom of the pile in terms of features. The Matek board is a good choice
ok sounds good I’m going to get the Matek H743-SLIM, keep everything else as much the same as I can, and report back here after I’m up and running again.
wait, one more thing to clarify: when you say “CRSF is only supported on 4.1” you mean the CRSF pass-through telemetry, correct? CRSF rc protocol still works on earlier versions (e.g. 4.0) right?
No, CRSF support is new to 4.1. In 4.0 you would need to use SBUS or mavlink RC.
tentatively good news. It may have been the “RC over mavlink” setting on the crossfire setup, as @andyp1per suggested.
Reminder on my last attempt I had updated to latest beta FW but that build strips out the CRSF for my 1mb Kakute, so I didn’t get out of the gate on that one.
This attempt I reverted to the custom stripped-down build that @yaapu provided for me in january over on this thread. I know that version is a bit dated now but I lack the ability to build my own from the latest beta. Reverting to that FW got me back to my known state of experiencing radio failsafes.
Then I made a single other change: I disabled the “RC over mavlink” option on the crossfire. I did a really short test flight this morning in heavy wind and got no radio failsafes. I’m not fully convinced yet so I’ll try again when the wind dies down and report back with a definitive answer. I’m enthused enough to post about it though.
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:
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.
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.
