I can use the COMMAND FRAME while I wait for an official “position” on this from TBS, or I can use the MSP custom frame used by betaflight
It was on a MatekF405-Wing
Edit: I tried the same on a CubeOrange and I get 159Hz on UART1, UART2 and UART4 no problem
I measured the rate of 0x32 frames while in mode 1, it’s around 4Hz, so my idea is to create a big frame (crsf has a 64byte frame limit) and pack an array of passthrough frames in a single bigger frame and send that one, at 3Hz I would get an equivalent passthrough rate of 8x, so plain enough
So maybe something to do with DMA sharing or something on the Matek
do we see the same UART vs. baudrate issues when using native crsf telemtery only? i don’t think i do.
Just set RC_OPTIONS -= 256, I tried and get the same numbers
Hi vierfuffzig, here are the relevant portions of my config.
GPS in uart1
DJI FPV in uart3
CRSF in uart 5
RC_OPTIONS,288
SERIAL1_BAUD,57
SERIAL1_OPTIONS,0
SERIAL1_PROTOCOL,5
SERIAL3_BAUD,115
SERIAL3_OPTIONS,0
SERIAL3_PROTOCOL,33
SERIAL5_BAUD,57
SERIAL5_OPTIONS,0
SERIAL5_PROTOCOL,23
Yaapu: I didn’t realize the power level was already there! Thanks!
…it’s not that was just a rendering 
@Kija thanks, with those settings i do see a packet rate of 1 - 3, but telemetry hasn’t completely stalled for > 20 mins now. best results i’ve got so far.
I am a non programmer and am totally over my head in this conversation but I am trying to get a quad to work using CRSF and am experimenting with this stuff (I know - dangerous but fun). I have set up my protocols like the above and the quad works but I am not getting any telemetry. I think the RC_Options may be the problem and I don’t really understand that parameter. The widget script works but no data is showing up and no sensors are being discovered. If this is too complicated to explain just say so and don’t waste your time (I’m sure there will be a video available once it is all working) but any suggestions would be appreciated. This post says to set the RC_Options to 288 but one back at the beginning say to set it to 1. Neither seem to work for me. My board is a Kakute F7 with big Crossfire transmitter. I’m using serial 3 for GPS and serial 6 for the crossfire connection.
Thanks very much
Hi, set RC_OPTIONS to it’s current value +256, usually it’s at 32, so correct value should be 286.
Before setting the RC_OPTIONS bit, try to get CRSF protocol working by setting SERIALn_PROTOCOL=23 on one of your UARTS, once the regular crossfire telemetry is ok you can enable the custom telemetry by changing RC_OPTIONS, just remember to use the custom builds I provided as neither master nor stable releases support crossfire custom telemetry
Thanks Alex,
My CRFS protocol is working but still no telemetry. I get GPS data though and the yaapu widget works. Possibly I’m not using the correct build. Would you point me toward that download to make sure I get the latest. Here is what I am using taken out of the “latest” directory.
arducopter_with_bl.hex Tue Oct 13 13:39:03 2020
Thanks
Richard Powell
@vierfuffzig how have you got WiFi setup? I can’t get anything at all out of WiFi - I am only using CRSF right now and hoping MAVEmu works, but it does not appear to. Does it work over mavproxy?
After figuring out nearly all possible permutations of
bad SD card,
broken switch on T16,
wrong setting for RC_OPTIONS,
wrong settings for the SERIAL port or
wrong unrelated custom FW on the board
I got it working with Micro-TX-V1 and the big TBS-TX on both OpenTX radios (Jumper T16 and Frsky xLite).
All running on old CRSF FW2.42 as well and FW4.03 too.
Two screen shots:
I am still curious what is the meaning of the numbers in the lower right corner?
@andyp1per imho it is workin only partially. i assumed it would be working correctly on the fullsize TX (aren’t you using a fullsize?).
on the microTX it requires using a fw version 3.80 and newer, so you’ll actually need to use a 4.0x beta as there is no release type fw above 3.78… i couldn’t spot any difference between the available 4.0x betas, using 4.05 right now.
additionally you’ll need the wifi module at fw 1.17.
i’ve set the UDP port to 14550 for convenience (why 8888 as default???).
you’ll need to manually turn the wifi’s MAVLink “on” on every power-up, it falls back to “off” on power cycle.
you can opt for both AP or STA mode, both work equally bad.
now you’ll be able to connect and see a both a vehicle’s and the radio’s IDs with a basic message set.
if you now turn on your Rx and add a telemetry feed, you’ll see some more messages pop up:
i was expecting all basic CRSF tlm items to be emulated, but right now it is the GPS data only. so you’ll only really notice with a GPS fix. attitude, batt etc messages do pop up as well, but the actual data payload is not ever populated and stays at zero. i don’t know if this is intentional to only allow feeding an antenna tracker or showing position on your mobile mavlink GCS. that’s at least how far i’ve come with this.
on a sidenote i’ve tried opening a ticket at TBS to give some beta test feedback, but the ticket system is down.
Thanks. Does it work for you if you try mavproxy? I’ve not had much luck with APM planner and cannot connect via bluetooth or wifi from my windows machine (with MP)
i haven‘t actually tried with mavproxy yet, only MP on windows (successfully) and QGC on iphone (does NOT work).
will check mavproxy now.