@vierfuffzig, @andyp1per and I played with DMA on the omnibusf4pro (really need to thank Andy for helping me out on this) and we can state that DMA is a requirement for CRSF to work at full speed.
The MatekF405-Wing suffers the same lack of available DMA streams, if you check
build/MatekF405-Wing/hwdef.h
after running
./waf configure --board MatekF405-Wing
you’ll see that the DMA resolver cannot find a dma stream for any UART except for UART1 (UART2 has the NODMA directive)
// Note: The following peripherals can't be resolved for DMA: ['UART4_RX', 'USART6_RX', 'USART3_RX', 'UART5_RX']
thanks @andyp1per and @yaapu for persistently tracking this down. if i understand this right it might not be easily resolvable though and limit full speed crsf support to a single uart on quite a few boards though…?
@vierfuffzig well yes, at least for F4 an F7 boards, CubeOrange (H743) on SERIAL4 (GPS2) has TX DMA disabled but I get 160Hz no problem whereas on a kakute F7 dma is required on both TX/RX to get 160Hz
Hi all,
I updated the test builds, version 0.9 is available here
This version has better rf mode detection and it’s compatible with the crossfire lua parameters script.
On non DMA uarts telemetry works fine but the crossfire lua script is kind of slow in getting the parameters from ardupilot, not much we can do about this.
I tested it with crossfire fw 3.72 up to 4.08 on a Micro TX V2.
It requires a newer yaapu script, version 1.9.1 beta1, download from here
Thanks again so much for your efforts here. These enhancements really do make ArduPilot more fun to fly!
I saw that you now have a “pr” version of the pr in addition to the test one. Is that the one we should be building off of if we’re building ourselves, or would you prefer we stick with the “test” one?
Thanks again so much for everything!
Josh
PS Any word back from Remo on Tracer supporting this enhancement?
Hi Josh,
right now the pr version is identical to the test one, I have distinct branches so I can change the pr one without affecting testing. You can compile either one.
No feedback from Remo about the tracer. Did you ever have success with it?
You should use serial protocol 23 and hopefully get RC + telemetry, use a UART with dma enabled.
Edit: The TRacer manual says it has a single rf mode (up to 15 miles in “rural” environment), and fw versioning is distinct from the TBS legacy one. I’ll need for sure a way to detect tracer vs tbs and change the way I handle rf mode switching
Hi Alex,
I have tested Your last version compiled from Your test branch ( ff56022 ).
I tested it with crossfire fw 3.72 on a Micro TX V2 - yaapu script, version 1.9.1 beta1.
Settings same as at the last test.
Working fine at distances over 1000m.
Just missing the “Air Speed”
Cheers, Markus
Hi Josh,
Telem1 and Telem2 are fine, don’t use GPS 1 (DMA on RX is disabled), GPS 2 has DMA only on RX but in my testing CRSF works fine @160Hz, so to recap:
OK, I’ll be able to get that from scripting as soon as the frsky scripting PR gets in.
Telemetry data injected from scripting will work for both passthrough over frsky and over crossfire.
Sounds great.
Kind of side entry. Is it possible to get a FrSky Sensor like this http://www.vspeak-modell.de/de/ecu-konverter to the scripting? So far I didn’t find the possibilty to input FrSky sensors to the Ardu telemetrie.
This is already possible with user sensors on my Widgets/Scripts but only with frsky telemetry, no way to make it work for crossfire if this was question
Hi Alex,
today I have a issue where I need Your help.
I installed Your latest test build, version 0.9 at a pixhawk1.
Firmware from crossfire is 3.78 on TX and microRX.
Connection is ok and the RC signals are working. So far I all relevated setings on the PH should be right.
Now the RCInput should decoding the CRSF.
I get the message “CRSF:requestig RX device info”
So the system try this about 30 times, followed by the message “CRSF: RX device ping failed” and “CRSF: custom telem init done, fw 0.00”.
At another plane with a PH1 it working well.
Any idea which direction I should go?
