It seems almost that the less I can fly due to bad weather, the more errors I can find:
The warning message “CRSF running on non-DMA port” is back on F405-CTR - although the Nano RX is in fact on SERIAL3/UART1 which has DMA. I had just wired the same type of RX in exactly the same way 2 weeks ago on another F405-CTR and never got that message there.
Question: This is quite old and very “used” F405, and there are some other things not working 100% either (like ESC telemetry and BLHeli Passthrough to BLHeli32Suite) - could this and the incorrect warning theoretically be an indication of “creeping” hardware failure? Apart from that it still seems to work normally, although I’m only using it for experiments atm. I never had an FC fail so far, except for one that I fried personally.
So I wanted to get on the with Kakute F7 copter build which was stalled a month ago after it was discovered that CRSF had been disabled at some point during the past months. The only way I could get CRSF then was to use an old version from October '20.
Now I tried 3 custom builds, one that I had done 10 days ago, and 2 new ones (see https://custom.ardupilot.org).
The problem is that none of them seems to bring CRSF and/or full telemetry back. I’m still getting only the first 10 sensors, and Yaapu remains silent. No CRSF messages appear at all. It’s as if I had flashed a non-custom version. Of course I also double checked the relevant parameters, all unchanged, same ones that were working with the old version.
No errors came up during any of the builds, as far as I can tell, so I’m really confused. Could it be a bug in the Firmware Builder?
Another (non-CRSF) oddity: In MP / Status, rangerfinder1 never displays anything but 0. But on the proximity radar screen, it’s working. On the other hand, switching RANGEFINDER LOW/MID/HIGH is not displayed in messages like it used to be when flipping the assigned switch.
In the meantime I tried 6 different builds, the last one reduced to nothing but CRSF. The result is always the same - basic telemetry only.
As soon as I flash the version from last October (posted here a month ago: Passthrough telemetry over CRSF (crossfire)), everything comes back to life: Yaapu GCS messages, VTX info, CRSF status messages, all suddenly working again. So it has to be something in the firmware, no config issue.
Maybe something specific to the Kakute F7 is still blocking the use of CRSF, even when it’s back in? There must be some difference between the October '20 version and everything that came later that wasn’t changed/touched on by the custom building.
The whole thing is a bit of an issue for me because I have two of these boards, both running on copter rebuilds in progress, and I can’t really get on with either of them at the moment. I guess RC would work fine even now, but especially when testing telemetry and the Yaapu script are invaluable.
That would be fantastic, thanks. Needed: CRSF (what is ‘CRSF Text Selection’, by the way?), OSD + param, PlusCode (optional), RunCam, SA (optional, not used atm), Landing Gear, RPM, I2C Display (optional), Proximity (if needed for rangefinder obstacle avoidance)
I once saw values like that in the OSD when I had wrongly configured CH12 to send RSSI instead of LQ. As long as LQ is high, I don’t think it’s a reason to be worried.
@UnknownPilot Apologies for jumping in, can I ask how you got the F405 Wing to work with CRSF on Serial 1 (TX1/RX1) - I’ve tried everything.
When using the BRD_ALT_CONFIG = 1 and connecting to TX2/RX2 and setting SERIAL7 to RCIN it works along with passthrough telemetry but I get the messages in the OSD you describe as SERIAL7 is not DMA. This is running the 4.1 Beta 6.
When I connect to the TX1/RX1 pins and change SERIAL1 to RCIN I get nothing.
Apologies - new to this format, coming from INAV.
Firstly, congrats on your decision. Secondly, as it happens I just set up a factory new F405-WSE. Did you set RC_OPTIONS to 32 + (value that’s already there), very often resulting in 288?
Even with that set, I had to reboot a few times with/without USB (battery only) until passthrough telemetry and RC control started to work (without any further changes).
Also be sure to set “ENABLE CRSF” in Yaapu Config for the script/widget to work. Good luck!
@UnknownPilot Yes, been playing with Arduplane for about 6 months on a wing and over the weekend shifted my two Mini Talons to it as well - one of those has the OG F405-W and the other the F405-WSE, no issues at all on the WSE settup it’s just the W where I get the CRSF mode messages, I have the TX locked to 50Hz as well so it’s not flicking between 150Hz and 50Hz.
INAV is good and has a very strong community about it just feel my style of flying tends more towards Arduplanes strengths.
Hi, with telemetry locked at 50Hz my widget is updated about every 3 seconds, no artificial horizon, it feels frozen. Nothing I can do about it, the CRSF protocol @50Hz is simply is too slow.
In that case I almost dare not say it, but… both Kakute F7 are in copters…
If the work you did cannot be easily applied to copter, I will just shelve these copters until I can do a build myself with the firmware builder, which would be better anyway in the long run, so I could update without needing a special build once again.
Very interesting, I better update every craft with today’s master then. I just flew the plane again that failsafed for a second last week, no problems today, but better to be sure.
As for this Kakute F7 special build to make CRSF work again - will the Firmware Builder also be able to generate builds for the Kakute again in the future, or will it always require manual work due to the board’s known ‘problematic’ architecture you mentioned (fast CPU/little flash)?
The reason I’m asking is that if I’m always heading towards more problems with these boards, I might consider selling and replacing them at some point (not now).
It will be possible with the firmware builder - after all that was the point - but I think it requires a little more work to expose the right set of options in the right way. Let me know if the firmware works as expected.
Tridge also merged his DMA contention fix yesterday which should also help in this area.
Ok, it seems I’m now officially a subscriber to CRSF problems. All I wanted to do is quickly update a plane (F405-WING) because of the failsafe fix mentioned. Now I’ve been trying for 2 hours to get RC input and CRSF telemetry to work as they did before - to no avail.
RC is not working at all, and CRSF telemetry always seems to stop after the first 3 or 4 messages. Sometimes a few more, but then it dies. I have no idea if this might be of help but these are from 3 consecutive boots (only battery connected to FC):
What I did try:
2 different versions of master, 1 of which I have been flying with yesterday with another F405-Wing plane - having no problems at all
A custom build, disabling what I don’t need
A second RX (Diversity Nano) - result was exactly the same
Rebinding RX
Of course RX is on DMA
Well, I have a feeling I won’t be flying this plane tomorrow…
The problem seems to be somehow tied to the Diversity Nano RX. I wanted to check the Kakute copter for the other features (rangefinder etc.) when I discovered that there too CRSF messages come to a halt and there is no RC (yesterday I only did a very quick check and when I heard some messages coming in I assumed all was well).
Also in both cases a pretty high CRSF rate is sometimes shown among the very few messages that sometimes get through, above 200Hz - I’m not sure I saw that before but I may be wrong.
So it looks like: Recent AP or AC version + Diversity RX (+ maybe Crossfire 6.07/CRSF V3) = intermittent/stopping CRSF telemetry and no RC.
Then I flashed the old version to the plane again (June 26th) and everything worked. Also another plane with diversity RX and an AP master from June didn’t show the problem.
The problem doesn’t occur on two other planes with Nano RX, the most recent versions can be used there without problems.
The type of board does not seem to matter in this case.
Just let me know if any more info is needed to get to the bottom of this.
It could easily be CRSFv3 issues. There have been a few. If you flash the beta on the non working board does it start working? The beta does not have v3 support.
Secondly, as it happens I just set up a factory new F405-WSE. Did you set RC_OPTIONS to 32 + (value that’s already there), very often resulting in 288?
