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).
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.
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).
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?
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.
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.
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)?
Only the data that goes wirelessly from the RX to the transmitter/module is affected: The settings of the RX itself and the settings of a VTX that is directly connected to the RX via SA. Settings of the module/TX itself can be accessed normally.
So to sum it up again, I suspect the RX is busy due to “CRSF: requesting RX device info” and can’t handle the request from the TX/module/LUA at the same time.
If there was no such request, maybe the problem would be gone?
Just some updated info: Due to persistent binding problems with various receivers, I had to update to Crossfire 6.07 which supposedly fixes those - so far it’s looking good. Currently the update is only available via browser-based “Agent M”: https://www.team-blacksheep.com/agentm/
No change concerning the slow access to RX device settings via LUA or module stick/OLED menu. For example it takes about 10 minutes to load settings for all 12 “D.ST” channels, in order to set the last one to LQ for PWM-based RSSI. Normally it should take about 5-10 seconds.
I can’t do anything about this unless I can reproduce it. Please post as much detail as you can to help me do this including all parameters and versions of everything
F405-CTR (also observed a few weeks ago on F405-WING)
Any latest AP-dev (unclear when first appeared but definitely wasn’t always like this)
Crossfire Lite Module
- Dynamic Power On
- MyVTX/Video TX Off
- RF Power Switch Off
Nano RX (also observed on Diversity Nano)
- Output (pin) 1: CRSF TX, Output 2 RX (disconnecting these makes the problem disappear)
- Output pin 3 or 4: CH7
- 12 channel mode
- Telemetry On
- RF Profile Dynamic
- Failsafe Mode Cut
- RC by MAVlink Off
- RX Batt Sensor Off
- Channel Map: CH12 D.ST: LQ
Crossfire 3.78 or 4.11 or 6.x
TBS Agent Lite LUA 0.91
- Device Entries: 1 - XF TX LITE / 2 - XF Nano RX / 3 - ArduPlane V4.2.0dev
- 1 is normal / 2 incredibly slow or not working at all / 3 a bit slow but works
The “CRSF: requesting RX device info” message hasn’t shown up again, but I still think it must have something to do with AP requesting something from the RX at the same time, as disconnecting TX and RX (leaving only power connected) eliminates the slowdown. Maybe the code of TBS’s “Agent Lite” LUA script could reveal how those requests are made - maybe they’re in fact CRSF too and something ‘collides’?
Ok, I have reproduced something similar on 6.07 when it uses CRSFv3. It was initially using v2 and all was fine, but when it switched to v3 I see the dramatic slowdown. That doesn’t explain your 4.11 experience but might be a clue I suppose. I have a newer version of AgentLite I am going to try just to eliminate that, but I suspect its something else.
