Forum Replies Created
The menu layout I described above is for OpenTX version 2.2 and above. There have been many changes since that version so i strongly advise that you update (you may want to backup your models with Companion before updating just in case). The latest version of FlightDeck itself is designed for 2.2 or above.
When downloading the firmware with Companion, make sure the “lua” option is enabled (go to Settings >> Settings…, it’s one of the “Build Options”).
We’ve seen this happen with some microSD cards (if they are not the ones supplied with the Taranis for example). The error occurs when there are too many files somehow or the card is corrupted..
Could you please try by having only the FlightDeck files on the SD card? A workaround for faulty SD cards that we’ve found is to just have the official OpenTX sound files in the language you want (by deleting the folders for the languages you won’t use).
Yes, I should have mentioned that the OPTIONS were added to the ArduPilot code base back in November, so you must use a fairly recent version of ArduPilot. I just checked and looks like the stable still does not have that parameter, so your best bet at this time is probably to use the “latest” firmware: http://firmware.ardupilot.org/Copter/latest/
Baud rate does not need to be set since it’s hard-coded when the FrSky protocols are used. Set SERIAL2_PROTOCOL to 10 when using FrSky Native Passthrough (the protocol used by FlightDeck). Setting SERIAL2_PROTOCOL to 4 is also a viable option when you just want some basic telemetry without using a script such as FlightDeck on your Taranis.
Yes, neither Crossfire nor DragonLink has native compatibility with th eSmartPort protocol.
It would be up to the respective manufacturers to provide support.
Besides power (V+, GND) and servo signals (SBUS), for telemetry specifically, it’s as simple as connecting the inverted SPort wire to the TX pin of the serial port you want to use on your flight controller, and then configure that port for half-duplex using the corresponding SERIAL#_OPTIONS parameter. So, set SERIAL2_OPTIONS to 2 if using “TELEM2” on a Pixhawk and wire the inverted SPort to TX which is pin 2, right next to the red wire, on a Pixhawk.
FlightDeck uses the passthrough protocol found in ArduPilot, which is not implemented in the PX4 firmware.
There is a workaround which is the use of a MAVLink to passthrough converter: http://www.craftandtheoryllc.com/forums/topic/does-this-work-with-the-px4-pro-stack/
Otherwise, if you don’t have a compelling reason to be on PX4 firmware, I would certainly recommend using the ArduPilot firmware instead.
Thanks for the details. Interesting project!
Unfortunately, this has a lot more to do with the capabilities of the RFD900x and such if you want a solution fully integrated within the radio.
My proposed solution is somewhat similar to the MAVLink sniffer, where you would need some equipment on the ground side to get the passthrough telemetry from a MAVLink stream. The solution is a MAVLink to FrSky passthrough converter, consisting of a Teensy (or STM32F103C) and the following program: https://github.com/zs6buj/MavlinkToPassthru/wiki
Documentation on this project is a little scarce, but using this program in Ground Mode, you should be able to read the downlinked MAVLink stream from the RFD900 (you could simply split the TX of the ground radio’s serial port or if you don’t want wires between the ground radio and the handheld radio, use bluetooth I guess – would not personally recommend bluetooth though) and convert it to the FrSky passthrough protocol with which FlightDeck is compatible. Others have had success with this, including when using DragonLink radios.
Best of luck!
Here is Achim’s response, after I guided him to try a different microSD card (shows the limits of solid-state drives):
it was due to the SD card. Was apparently broken. New fetched and everything works. Thanks a lot for your help.
I responded to you by email as this is technical support specific to your configuration (we like to keep the forum discussion as generally applicable to all users as possible). However, if you do end up finding a solution that you think may benefit others, please post it here so that others can benefit from your findings!
There’s no easy way to test the cables without additional equipment. Do you have a spare cable you can test?
Feel free to send more information about your setup, including pictures to [email protected]
There may also be some useful tips in the troubleshooting section of the FlightDeck manual, if you haven’t already checked: http://www.craftandtheoryllc.com/downloads/FlightDeck_Manual_EN.pdf
As far as I understand, DragonLink still does not support the FrSky protocol. The workaround is to use MAVLink, and connect a board such as Teensy on the UEXP port to SPort on the transmitter radio controller. I’ve not tested this but I’ve seen some report success in doing this.
The code to use on the Teensy is here: https://github.com/zs6buj/MavlinkToPassthru
You have to use Ground Mode which converts from MAVLink to SPort on the ground…
From the main OpenTX interface, a long press on MENU will get you to a menu of (typically) 9 pages which includes RADIO SETUP, whereas a short press on MENU will get you to a different menu which contains the DISPLAY and TELEMETRY pages.
FlightDeck supports and accurately auto-detects the cell count of LiHV batteries up to 4.35V average per cell. So in your case of a 3S battery, it will detect 3 cells as long a the pack you plug in is at less than 13.05V.
That being said, we have planned to support overriding the cell count in a soon to be released version, to provide more flexibility…
Let me know if there’s anything else we can do for you, or if you have any other suggestion you would like to share.
I agree that it would be ideal if the protocol could be implemented directly in the PX4 flight stack code…
In the meantime, you can get FlightDeck to work with the PX4 flight stack using the MavlingToPassthrough project mentioned above.