Hello there,
can you fellows give some hints about sending back telemetry through FrSky receiver → Taranis?
The following didn’t actually help to understand where to connect to Navio:
http://copter.ardupilot.com/wiki/common-frsky-telemetry/
Hi Fabio,
you can use the UART port or USB with an USB to serial adapter.APM FrSky telemetry output only works for the older D receivers. The newer X receivers use a new protocol (s.port or smart port protocol, not to be confused with sbus).
And you will need a signal inverter like mentioned; n the website you linked.
Thanks for your reply. It sounds clear.
I own a FrSky USB adapter for updating my D4R-II receiver (I read it basically is a USBtoUART adapter). Could it be used also as interface between NAVIO+ USB port and D4R telemetry port without the needle of the mentioned signal inverter?
The inverter is necessary to connect to the FrSky SmartPort. That solution and other alternatives are discussed for native APM Planner 2 support here:
The simplest way should be to use a standard inverter (e.g. http://www.banggood.com/FrSky-Receiver-Upgrade-Lite-FUL1-p-930265.html) with the built-in APM 2 functionality and the serial (UART) port of the NAVIO+ (which I presume is mapped in correctly via their APM HAL driver).
But I think the best way, which I have personal experience of, is the Teensy solution. Because standard telemetry mapping is too limited and we have a full Pi computer, we don’t need a Teensy of course and can tweak the program to do more, for example LiPo battery cell monitoring (also described in that link).
At least I will be taking a look at this because I have the same requirement. But for me at least it’s only nice to have, because my radio is only intended to be a backup to WiFi/ground-station (phone/tablet) display.
I want to send telemetry from the navio over the uart port to my frsky x8r. I’ve put together a signal converter from the link in the top post. I believe that frsky baud rate is default 300.
Telemetry will also need to be started when arducopter is started I take it. -A is serial0 (default is 115200 baud), -C is serial1 (default is 57600 baud). I will add the command -A /dev/ttyAMA0 when I start arducopter and with the baudrate value changed via mission planner in serial0_baud to the frsky default of 300 I should be getting my telemetry data on my receiver right? Fingers crossed.
The default baudrate for the s.port to uart modules is 300baud. S.port telemetry baudrate should be 57600baud
Damn! I can’t connect via mission planner now. Would that be because I changed the baud rate to 300 on -A and -C? Nothing I’m doing allows me to connect. My usual systemd autostart using ArduCopter-quad -A udp:192.168.1.114:5760 now I can’t connect via mission planner. I’ve tried changing the baud rate in udp connection to 300 but nothing ( I imagine it’s off the usable scale). Don’t know which tree to bark up.
Well I ran the ardupilot/navio2 update/install from the command line and reinstalled ( thinking that would reset any parameters I had made). But no change, still can’t connect with any GCS. I then deleted my parameters file (I guess an update wouldn’t delete your settings) using (sudo rm -r /var/APM) and all is fine again. I’m logged back on. lesson learned sleep lost LLSL.
I’ve wired up the uart port to X8R s.port just as the ardupilot describes using the ful-1 and spc converter. I’ve upgraded the taranis to the latest version 2.1.8. Gone to discover sensors in taranis. Am I right in thinking this is all that needs to be done? I’ve been through the forums and github’s but getting hard information from them is difficult. From my understanding ardupilot 3.4 has native support?
Did you set the serial protocol to Frsky S.port? I can not remember the value right now, but only change one serial option to S.port, not both. Otherwise you will be locked out again.
Also have a look at this site:
http://ardupilot.org/copter/docs/common-frsky-telemetry.html
Yep Sebastian I changed the protocol to 4 for my x series receiver (thats the site i based my decision to to this and i’ve installed base on their instruction). I’m wondering if there is any way of checking that the signal is being transmitted? Maybe something wrong with the converters.
I had a similar issue and it turned out to be the order of the startup params. I can’t tell from your earlier posts what you’re using now. Please post the full command you are using to start ArduCopter.
Hi @Kevin_Goff . Here’s a copy of the systemd service i’ve got running. Sorry the laptop camera is a bit crap.
I’ve had no luck with connecting to mission planner via -C (I was getting nice loading but since I’ve deleted my params I get alien characters after the compass has been identified, Maybe calibration?)
So it may well be that. I’ve had no luck using tcp either, and I’ve exhausted my options with both. My navio ardu install is vanilla straight from the install guide.
@Wildtypitch when you use only -C (secondary telemetry channel) without -A (main telemetry channel) it will be set to standard input\output - console in this case. If you’re not using -A it’s better to set it to some dummy address\port.
I’ll have to confirm but I think the serial parameter needs to be in front of the TCP. In my case it worked. Would be easy to try that though.
Also, you could try using 0.0.0.0:14550 in case the ip unknowingly changed. This will allow it to connect via tcp using any ip on that port.
I’ll try to look at my setup this AM.
Well, forget what I said about order. Not sure if this helps you now, but here is my system.d service:
[Unit]
Description=ArduPilot Flight Controller
After=network.target user.slice
[Service]
ExecStart=/usr/local/sbin/ArduCopter.elf -A tcp:0.0.0.0:5760 -C /dev/ttyAMA0 > /home/pi/startup_log
ExecReload=/bin/kill -HUP $MAINPID
Restart=no
[Install]
WantedBy=multi-user.target
Alias=ardupilot.service
Cheers Kevin I’ll pay around with it in the wee hours. Noticed you have restart=no. Is there a reason why, I believe if it’s set to always it’ll restart immediately in the event of arducopter crashing.
No specific reason other than there were times that i like having the option of killing the service. I’ve never had arducopter crash in flight but I suppose it is could happen someday. I’ve had brownouts of the PI which does restart the service but because of Linux and long load times it is usually on the ground by then. 