Matek F765 R9m Slim plus OTA receiver Fport settings/setup.
For matekf65 with R9m Slim plus OTA Telemetry, below settings works.
Using Arduplane 4.1 Beta
SERIAL7_PROTCOL=23
SERIAL7_OPTIONS=15
RC_OPTIONS=0 (8 didnt work as developer advised)
RSSI_TYPE=3
And make sure:
Change the receiver settings from Sport to Fport.
2)Sport/Fport cable connect to RX6 ( Same as you do connect for SBUS, as Serial7_options settings swap the pins)
How to change the receiver settings in open TX
Go to Model>>Scroll down to your receiver 1 tab>>click to open and select options>>on top change sport to Fport. ( make sure you have the latest firmware)
Matek F405 Wing - FPORT
No external converter required with R9 Slim plus receiver or with any Frsky receiver, can support inverted Sport/Fport (mostly does).
R9 Slim plus:
RX1 port on the receiver need to be connected/use instead of Sport/Fport. As RX1 is inverted S.port port not the Sport/Fport. Sport/F.port is for F7 flight controller.
Make sure receiver has latest firmware and you have enable the Fport from open tx option.
Connect receiver RX1 to TX2 (UART 2)on flight controller.
Config below settings for serial7 ( serial 7 maps to Uart2 as BRD_ALT_config=1)
BRD_ALT_CONFIG =1
SERIAL7_PROTOCOL =23
SERIAL7_OPTIONS = 4 (Half Duplex) RSSI_TYPE =3
Serial7_BUD = 115 ( mine is works perfectly with 115, try 57)
Enjoy the yappu telemetry on your transmitter. Dont forget to delete all sensors and discover again under openTX system settings.
Any specific reason to connect to tx6 ? As better connect to rx6 as negative, positive and live wire all 3 aligned.
If you still want to use tx6 just uncheck the swap check box under serial 7 option.(I didn’t try it but it should word as swap check box swap the tx and rx pin, which translates rx become tx and tx become rx.
The reason I wanna use tx 6 first I wanna give a try, just for the curiosity. Second I use inav which TX on fport. So I don’t need to change the wire when I switching the firmware.
I read this entire thread twice and still spent a very long time this morning trying to successfully use FPort on a Cube Orange with an R-SXR receiver, Horus X12S (OpenTx) transmitter, and the Yaapu telemetry scripts. The Cube is presently running Rover 4.1.0-beta7.
The biggest issue is that FrSky’s ACCST 2.1.0 firmware appears to be incompatible with ArduPilot’s FPort implementation. I finally found a copy of the 1.9-series iXJT firmware for the X12S, flashed that, reverted the R-XSR to the 1.9-series as well, and everything worked immediately without any hiccups.
The receiver is wired via its DF13 connector (not the solder pads) with a 10k pulldown resistor. The following recommended settings worked on both SERIAL2 and SERIAL3:
SERIAL2_OPTIONS = 7
SERIAL2_PROTOCOL = 23
RC_OPTIONS = 8
RSSI_TYPE = 3
I’m very happy to have FPort working, but it’s slightly frustrating to have to revert my other receivers to ACCST 1.9x if I want to keep this rover working as-is.
Reference my previous post just above, I was very happy to get FPort working with the firmware reversion, but that has created another problem for me.
With the older firmware on my transmitter, I’m either forced to downgrade my X8R receivers to a version that does not support pass-through telemetry, or rewrite the firmware on my transmitter every time I switch from the R-XSR model to an X8R one (of which I have two).
Have I done something terribly wrong by downgrading to 1.9x in order to get FPort working, or is ACCST 2.1 FPort support forthcoming?
EDIT (SOLVED):
See immediately below. The issue is not an ArduPilot one, but rather a FrSky one.
Ah! I did read a bit about that bug but did not fully digest its impact (it seemed Betaflight specific). That makes perfect sense, and the developers here can disregard my somewhat ignorant request for support. Thank you much for the explanation!
A brief test with the ACCST 2.1.2-beta firmware linked in that bug report was completely successful. A word of caution to those considering this “fix” - there is a follow on post that appears to blame a copter crash on this beta receiver firmware, so it probably shouldn’t be used in any critical application. In my case, I’m using it on a small Rover that I purpose built to test things like this, so the risk is close to nil.
In the long run, perhaps it might be best to simply upgrade my transmitter with an ISRM module and transition to ACCESS.
