What version of Ardupilot firmware are you running? It needs to be the -dev version.
omg, yes!
thank you so much, my bad, me stupid
Hello,
has anyone tested the BBBlue with that? Is it even possible?
Tried it with the SERIALx_PROTOCOL=23 and SERIALx_OPTIONS=7 on the RCIN serial and on UART1 without success.
Took an R9mm and switched FPORT / uninverted FPORT pin also.
Hi,
I did not try it myself but I remember people reporting failure for frsky sport telemetry on linux based boards, since protocol 23 is uart based just like protocol 4 and 10 I suspect it will not work as well.
FPort has even tighter timing compared to SPort 2.5ms vs 10ms it’s very well possible that the board can’t cope with such a tight timing, mine are just guesses though
Alex
I was able to get fport working on Kakute F7 with latest ArduCopter V4.0.4-dev (26c2555c) from May 23.
I’m having telemetry stability issues:it works only intermittently (using yapoo9 on Taranis X9D+). The RC inputs worked always, which is weird given that it uses the same wire.
Initially everything worked right away with these settings:
BRD_ALT_CONFIG =1
SERIAL6_PROTOCOL =23
SERIAL6_OPTIONS =7 (I have FPORT on UART6 TX pin, so no need to swap RX and TX)
RSSI_TYPE =3
Then I started to experience telemetry loss, sometimes not able to recover for hours.
The same hardware works fine in Betaflight.
Is there any logging or a way to debug? I’m able to build the code and apply changes (my job is embedded software engineer).
Hi what receiver are you using and which firmware veersion on tx and rx?
I use r9 slim plus (older model that is already discontinued) with ACCST Flex fport firmware from 2019-02-13. On Taranis I use R9M module older model, that has only one firmware published in the beginning of 2019. I used SPORT/FPORT pin to connect to T6 on Kakukte F7.
I also successfully used R9MM RX and both R9MM and R9 SLIM+ worked. I may have physically damaged R9MM while trying to measure current usage with a bench power supply (RX does not want to pair any more with TX, so switched to using R9SLIM+). Fport works and telemetry works fine on Betaflight with R9SLIM+ and intermittently with Ardupilot. After the bench power supply incident I tried using another UART3 (in case I burned pull up or something on UART6). Again RC input worked, but not telemetry. Then I have a brief period of 30min with telemetry working on UART6 with Ardupilot for no apparent reason and then it stopped again (RC input works always).
I’m looking for experiments to try and tried to look at Ardupilot code base. SHould I build firmware from arducopter-4.0 branch, which seems to be ahead of master (has 4.0.6 beta version).
I consider switching to FLEX firmware (without FPORT), soldering R6 to SBUS OUT, changing to SERIAL6_PROTOCOL=10.
BTW Initially I tried at least 3 different R9 Slim+ firmwares using Betaflight to figure what works. I found that FCC firmwares are all broken and only ACCST FLEX firmwares works. I’m disappointed with FrySky quality and would have bought crossfire components, but everything is out of stock now.
Hi Stan,
please use master.
I do have an r9mm I can test with and both an R9M 2019 and original R9M.
I did all the testing with my r9mm on flex at 100mw using the r9m 2019 flashed with accst.
TX firmware file is dated 24.01.2019, RX firmware file is dated 13.02.2019.
On the bench never had a problem provided I power the tx a couple meters away from the rx.
Frsky fport firmware is not mature at all, many receivers claim support but the protocol has broken telemetry (rc is mostly fine).
Did you try the same setup on another flight controller?
To debug it you should capture a logic trace when it’s not working, capture at 1MS/s for 10 seconds on your kakute serial port. To decode the protocol select 115k baud, 8n1 inverted half duplex.
This way we can see if ardupilot is responding to the rc frames with telemetry
FPort support is part of the plane 4.0.6beta1 release from today, and will be in copter 4.0.4beta1 shortly. I’d really appreciate some testers for the FPort feature from this group to make sure I got all the backporting from master right.
Cheers, Tridge
I will test it for you.
Do you have an exact test criteria?
I think we should publish a test check off document. Just a suggestion.
just check that RC in works and that telemetry with the yaapu scripts works.
I Have a X9D+ with R9M and will be bench testing with a R9 rx connected to a Matek F765-Wing.
LB
I used the following configuration from the online documentation, and the receiver works, but the telemetry does not. S.Port is hooked to RX6.
MatekF765-Wing
UART6 RX can now be tied to receiver FPort. This board requires a unique configuration:
- [BRD_ALT_CONFIG] =1
- [SERIAL7_PROTOCOL] =23
- [SERIAL7_OPTIONS] =15
- [RC_OPTIONS] =8
- [RSSI_TYPE] =3
I have the Yaapu 1.8.0 script on my X9D, and it says “no telemetry data”
Regards,
LB
EDIT: I have also tried hooking s.port to TX6 and using serial7_options = 7 with the same result
Actually found the answer further up in this thread. Setting [RC_OPTIONS]=0 fixes the issue for me on the F765-Wing. All working for me now. Works with the Yaapu and FlightDeck lua scripts.
Please update the documentation. 
Regards,
LitterBug
2 Likes
@tridge and @yaapu, for some reason, I cannot get the telemetry part to work on a Cube Orange. I have normal RC inputs to the vehicle, but I only discover 3 sensors; RSSI, RxBt, and F010 0. Any suggestions?
R-XSR with ACCESS 2.1.0 firmware going to an X-Lite S. Hooked up to GPS1 (serial3_parameters).
- SERIAL3_PROTCOL=23
- SERIAL3_OPTIONS=7
- RC_OPTIONS=8
- RSSI_TYPE=3
[EDIT:] Flashing back to 191107 firmware on the internal module and RXSR allowed me to find the GPS sensor… What has to be done to make this stuff work on the latest FrSky firmware?
Hi Nate, on the Cube Orange you can try with an external pull down resistor, check here or you can try disabling the inverter (SERIAL_OPTIONS=4) and use the uninvrted pad on the r-xsr (in this case should work without the external pull down)
Trying to set up Matek F405 Wing. Post 1 says set SERIAL5_OPTIONS=160. I cannot set them to any number, Mission Planner gives me a check box with 4 options that can be ticked that automatically set the value of the field to 0,1,2,3,4,6,7,16,17,19,20,21,22,23 and probably others in that range.
I am using an inverter but OpenTx does not see any sensors from the board after trying a few of these options.
I don’t know if you saw my edit; it works with an older version of the FrSky firmware without changing cabling… wouldn’t that indicate something like a protocol issue, not a pull-down issue?
Mission planners little helper boxes are often out of date and do not show all the options…assuming you are running the correct firmware, just edit the param directly, forget the box…dismiss it
1 Like
have you tried it with the PAD option? RC_OPTIONS=8? apparently different rx firmware versions and different rxs may or may not need this timing tweak…