In 4.1 if you connect via mavproxy and do ftp get @SYS/uarts.txt - you can see both the uart and serial mapping
1 Like
@OldRaven nice to hear it worked. This page at Matek has become invaluable when it comes to setup.
http://www.mateksys.com/?portfolio=h743-slim#tab-id-5
It’s the mapping table between hardware resources and Ardupilot naming (UART6 -> Serial7)
1 Like
Ok, for the first time I’m having real trouble getting the script to work with an FC - although it should be mentioned right away that I’m not getting the full set of telemetry sensors in OpenTX either (only the first 10).
I have the widget set up just like on 4 other models, on all of which it works (3x F405-WING, 1xF405-CTR). CRSF is enabled, RC_OPTIONS set to 256+x, PROTOCOL is 23, RC by MAVLINK is off. And I just spend 2 hours moving the RX to a UART with DMA (lots of stuff was in the way) - no change.
The FC is a Holybro Kakute F7 V1.5 AIO which has DMA on UART/SERIAL 2.
Of course it’s suspicious that even though the script is not using sensors, those are missing too for some reason.
Is there anything I might have overlooked?
By the way, is the script compatible with Crossfire firmware 6.x which apparently intoduces “CRSF V3”? I’m still on 4.11 and don’t plan to upgrade anyway unless there is a benefit of some kind. Just asking.
Make sure you don’t have protocol 10 configured anywhere - this was @hwurzburg s problem
6.x should work fine although I find the binding a bit flaky at the moment. I have a PR to support CRSFv3 - which basically means more channels - but they are backwardly compatible
No protocol 10 anywhere unfortunately. I am now absolutely sure I had this working last November, as I found a video of the copter flying, and Yaapu voice messages can be heard on it. That was on UART1 (no DMA - and I had some failsafes back then, and a crash, so I wanted to move the RX to DMA anyway). This year, neither UART1 nor 2 work with Yaapu, and about 10 sensors are missing too.
Things that changed between November and now:
- Updated AC dev
- Updated Yaapu script
- Updated Crossfire
The only thing left I can think of is trying the version of AC I used back then. I already tried 3 different recent versions, because a few months ago I came across a dev version of ArduPlane that somehow disabled Yaapu (although I didn’t check if half of the sensors were disabled too).
I also found this, but it’s obsolete now, isn’t it?
With this old version from October, both Yaapu and and all sensors started to work immediately:
arducopter-yaapu-crsf.apj (829.1 KB)
It’s the one I used during the final flights of 2020. It might even be a special version provided by Mr. Yaapu himself, as I didn’t add a date to the file name like I usually do (I always keep all the versions I ever used, to trace back problems like this).
So I guess there is hope, something must have changed in AP that prevents it from working for me.
sometime along the way we changed the frame IDs to compy with TBS firmware so If it works with older ardupilot and dose not with current master you might have a too old yaapu script/widget
Thanks @yaapu , I’ve been running 1.9.5 beta1 for a while now, no problems on 3x F405-WING and 1x F405-CTR using latest versions of plane or copter, so I guess that can’t be it? Especially since I’m also missing half of the sensors.
Not being a dev, I still have a feeling this might be a target issue with the Kakute F7 which might not be up to date in general. For example it still has all OSD fonts integrated, no need to put fonts on the SD card like I recently had to do on all Matek F4’s.
Maybe full CRSF telemetry and Yaapu support was lost somewhere along the way with the Kakute F7, but nobody ever noticed it since Matek boards more far more popular (with me too).
I’m also getting the weirdest messages I’ve ever seen: “IE8388640 IEC4 TN:OSD” - “WDG: T-3 SL0 FL0 FT42 FA0 FTP0 FLR0 FICSR0 MM0 MC0”
This is the problem:
save FLASH, but leave above when flash issue is fixed
define HAL_MINIMIZE_FEATURES 1
So no CRSF support
1 Like
Would be great if you could you explain this in layman’s terms - does the Kakute F7 have less flash than the F4 Mateks? If it’s a memory issue, I’d very much prefer the additional fonts gone for example. Even NTF_DISPLAY is less important to me than CRSF and Yaapu support.
Can I somehow determine at which point CRSF was removed, so that I can use a version from exactly before that? As I still have RC via CRSF, would it be safe to even use it with the current version? In any case I guess it’s not a good idea to use the old version from October '20.
The problem is that I even have another copter waiting to be converted from iNav to AC, and I put this same FC in when I upgraded it, because I knew it could run AC later, when I had become familiar with it. (I even sold the F722-SE I had originally intended to use, since that one didn’t even have 1MB flash.)
Someone at some point added that flag to the KakuteF7 definition to save flash. The KakuteF7 is the most problematic because it is an F7 - so the sector sizes are bigger and means we waste more flash for the bootloader - and it has an SD card - which also consumes a lot of flash. The flag is a catch all for disabling lots of stuff, I don’t particularly like it because it disables lots of useful things. It’s possible that we can juggle stuff around to allow it to be switched off, but the main problem is plane. The custom firmware builder will solve these problems.
1 Like
Yeah I just tried again - copter is ok, but plane overflows by 13k and there isn’t anything obvious that can be removed. Unless you want to build your own firmware you probably need to wait for the customer firmware builder (hopefully a beta should be up this month).
1 Like
Copter is all I’d need here! I prefer dedicated WING FCs for planes due to their ease of use with servo plugs etc.
Thanks for the explanation about the F7 - I thought I’d made half a step up to 2MB F7 boards with it, but seems it’s rather the opposite. And now I also remember Basti mentioning last year something about it being a “turbo engine combined with a small trunk” or so. 
I really can’t wait to finally start a build with the 2MB F765-WING and forget about all those memory troubles - it’s been in a box for a year, but just like in this very case, editing/improving existing projects always eat up more time than anticipated…
EDIT: Ah yes, excellent news of course about the custom firmware builder being available soon - I hadn’t hoped it would be while this flying season lasts.
Is there a way to prevent these requests which started to show up using latest?
08/08/2021 00:49:48 : CRSF: requesting RX device info
08/08/2021 00:49:48 : CRSF: requesting RX device info
08/08/2021 00:49:48 : CRSF: requesting RX device info
08/08/2021 00:49:48 : CRSF: requesting RX device info
Because I’m usually setting up the RX (and the VTX which is connected directly to RX via SmartAudio) via the Crossfire module joystick/OLED or the TBS Agent Lite LUA script.
This has always worked perfectly for me, but now the info from the RX is coming in extremely slowly or not at all. I suspect the requests listed above, happening at the same time, might be the cause of this.
Just curious: What I’m usually setting up is RX channels (physical pins and the ‘virtual’ channel 12 for LQ I’m still using for now), general settings (i.e. “RC by MAVLink = Off”, “Telemetry = On”), VTX power/band/channel. Are any of the parameters supposed to show up in AP via these requests?
Looks like a bug - I have seen some weirdness with this before but could not reproduce it. What firmware version are you using?
If you are controlling your VTX from your TX you cannot use the FC to do it, so no parameters (and make sure VTX_ENABLED is 0)
I recently upgraded from 3.78 to 4.11 (which wasn’t the best decision as binding for example became more complicated), but I had observed the “slow download” of RX/VTX settings to the Crossfire module or LUA via SA direct connection even before that. Only then there wasn’t a message like the one quoted above, so I had no idea what could be causing it.
When I desoldered RX and TX from the receiver, the settings download was as fast as ever. And at the moment I really have to do that to make any changes at all - even after minutes, not all settings are fetched. The receiver is a Diversity Nano (only until a replacement Nano RX arrives).
VTX_ENABLED is already 0. I like controlling RX and VTX via that extra line, for the moment I personally don’t need control via AP of neither RX nor VTX. I might try SA for that in the future, now that it’s available. So for me it would be best if AP just ignored these device settings completely.
Do you have passthrough enabled when you see these messages? I am unable to replicate this with firmware 4.11 on latest master.
Yes passthrough is enabled and working (most of the time). Using yesterday’s commit ed4345cb3ba4728c3caaa22bc9d912d7765b85d3 of ArduPlane V4.2.0dev on F405-CTR.
RX pins 1,2,3 are set to CRSF TX, CRSF RX and CH7 (needed for a cam switcher but I doubt it plays any role in this). A VTX with SA is not connected in this case.
So you can connect to a Crossfire (Nano?) RX all the time and access its settings via module joystick/OLED or TBS Agent Lite?
Then maybe it might have something to do with it being a Diversity Nano RX (which has more outputs) - the plane I observed the slow download on a while ago also had the Div Nano.
I can compare that once I get the replacement Nano RX, probably on Tuesday.
So you get the continuous message when you try and access parameters from the lua menu?
I just tried this - do not get a continuous message.
Delays in updating are expected, there is some weirdness in the protocol implementation.
The message is not repeating forever and not showing up every time, but there are other messages that only come up occasionally too (for example, it’s been a while since I’ve seen a CRSF VTX device info request when a VTX is connected via SA to the RX).
The extreme slowdown when accessing the RX settings is permanent, actually it comes to a complete halt - some parameters cannot be accessed/set while the RX is connected to the FC.
Since the slow access to the settings has occured for me before updating from 3.78 to 4.11, I don’t think it has to do with that update and rather assume it has something to do with AP.
Would there be a way to keep using CRSF but stop it from requesting any device info (RX, VTX)?