I applied it to my own source. . Last resort if I can t find a way to make it work will be for me to add a card ESP32 for MAVLink to passthru, but definitely will prefer your fix !
Thanks
of course, the piās uart is peculiar we need to send some data to wake it up,
you only need the code from the ap_frsky_telem.cpp ignore the rest of that commit.
After having posted the problem on April 2017, please see here:
ā¦what was my good surprise too see that the issue has been finally fixed today,
2 years and half later ! And for sure not by emlid but by a nice guy called Richard (wooshy1).
So why do I re-open the topic ? Just to say thank you so much to Richard !!!
Obviously emlid did not care at all about this issue, the only thing they have done is asking
stupid questions and saying that they were investigating the issueā¦
Furthermore emlid closed the topic on the same day as Richard gave the commit to fix it,
without giving us the chance to discuss further on the topic, probably without even testing
it and for sure without even saying thank you, what a shame.
Thank you again Robert !
Hi Patrick,
Iāve re-opened the thread so you can continue the discussion here.
Please remember to follow community guideline:
https://community.emlid.com/faq
1 Like
Regarding the issue with this hardware, according to our tests, both Navio2 and Edge can be used with FrSky telemetry in the standard mode and work fine with it. The passthrough feature isnāt supported on Navio2 and Edge right out of the box and we never advertised it should work.
Hi Dimitri,
Thank you for having re-opened the thread and for these clarifications.
Hi Richard, here is the new code in the module .
As you can see hal.scheduler delay (1) , where in your code you have hal.scheduler delay (5)
Nicolas
void AP_Frsky_Telem::loop(void)
{
// initialise uart (this must be called from within tick b/c the UART begin must be called from the same thread as it is used from)
if (_protocol == AP_SerialManager::SerialProtocol_FrSky_D) { // FrSky D protocol (D-receivers)
_port->begin(AP_SERIALMANAGER_FRSKY_D_BAUD, AP_SERIALMANAGER_FRSKY_BUFSIZE_RX, AP_SERIALMANAGER_FRSKY_BUFSIZE_TX);
} else { // FrSky SPort and SPort Passthrough (OpenTX) protocols (X-receivers)
_port->begin(AP_SERIALMANAGER_FRSKY_SPORT_BAUD, AP_SERIALMANAGER_FRSKY_BUFSIZE_RX, AP_SERIALMANAGER_FRSKY_BUFSIZE_TX);
}
_port->set_unbuffered_writes(true);
while (true) {
hal.scheduler->delay(1);
if (_protocol == AP_SerialManager::SerialProtocol_FrSky_D) { // FrSky D protocol (D-receivers)
send_D();
} else if (_protocol == AP_SerialManager::SerialProtocol_FrSky_SPort) { // FrSky SPort protocol (X-receivers)
send_SPort();
} else if (_protocol == AP_SerialManager::SerialProtocol_FrSky_SPort_Passthrough) { // FrSky SPort Passthrough (OpenTX) protocol (X-receivers)
send_SPort_Passthrough();
}
}
}
ahhh right I see that is arducopter 4.0? I have not tried it in the 4.0 code yet but it looks like they added a 1 tick delay before sending the telem data and they also got rid of the uart initialised check.
I would put my code after:
_port->set_unbuffered_writes(true);
but crucially before:
while (true) {
see if that works.
I would also like to say that this problem is actually not anything to do with the navio/edge etc the Linux board hardware overlay in ardupilot was sending the telemetry updates out every 100us hence why this problem was limited to Linux based boards, which was one problem i.e. the first fix I posted. The second was that the navio simply passes the raspberry pi 1st uart straight out the side and the piās uart has always been funny to deal with it often does not show as being connected to anything until you send some data I believe something to do with them using the uart for the kernel console on boot up in the earlier piās hence my second fix which simply sends some data out the port when it is first initialised. I have to give credit to the original GCS mavlink library coder for as I took it from the serial control handling section of that library. So essentially the 2 problems where with ardupilot and raspberry pi.
ignore this only the code in the while (true) section is sent every time
I tried again yesterday, but still not workingā¦
I have checked to cable (loopback on the RS232 side) and I read what it sent on the Uart so the cable in not the issue.
I also put the protocol at 4 , but I don t detect any sensor, Except if I connect also a sensor (vario) in the loop and connect the navio to the second entry of the vario sensorā¦
I see a lot of them , but they don t refreshā¦ and I loose them after few secondsā¦
Very strangeā¦
With protocol 10 passtrhu, nothing detected on the Taranisā¦
I am using a S8r with s.port. Not a x8r, may be this is causing the issue, but I doubtā¦
any thought ?
Thanks again hope we can fix it !
I will get my build environment setup and give it a go tomorrow
Do the built on your Pi or another one with Strecht in order to share the same resources than Emlid distribution.
I had a try with my Pi4 and compiled arducopter doesnāt run on the Navio2 Pi.
So after additional tests, it seems that the ArduPilot does not send anything to UART port itself.
I tested the UART with a script and connect it to Arduino. I can send and receive from the PI on ttyAMA0 , no issue.
I have checked the configuration on ArduPlane (telem2 = ā-C /dev/ttyAMA0ā) and the right param in the GCS (serial1 at 57 ) . I put also the protocol to 2 (MAVLink) and this time connect to an ESP32 with MAVLINKpasstru , but nothing is sent to the ESP32 (the ESP Is working well when connected to Arduino with a sketch that simulate MAVLink data)ā¦
I start to thing that there is an issue with navio 2 and pi3B+ using the UART properly ā¦ or maybe I completely missed somethingā¦
I might try to use my zoon radio that currently works on USB and try if it works on the UART port.
Nicolas
Hello Dimitriy, thank you for the clarification.
Could you be me more specific on how to make the connection between EDGE and the receptor and how to configure the software?
Accourding to Ardupilot (FrSky Telemetry ā Copter documentation) itās possible to get flight data like GPS location, does it come from EDGE or from an external module attached to the RC receiver?
Hi Gabriel,
Sorry for the delayed response!
Itās possible to obtain the flight data such as GPS location in GCS software. However, the passthrough feature that allows getting the same data directly on the RC transmitter is not supported on Edge out of the box.
Still, Edge can be used with FrSky telemetry in the standard mode.
You can connect the RC receiver directly to the RC input port marked as R on the servo rail. Check the pinout in Edge docs.
For information, I have managed to get passthrough working on the Navio2.
Using version 4.05 of Ardupilot, and just patching AP_HAL_Linux/Scheduler.cpp as proposed by Richard.
It works without the patch, but refresh lag 2 to 3 secondsā¦ So barely useable.
Using now Navio2 and Yaapu lua script on Horus x10sā¦
Anyone tested FPort? Is there also the issue? Tried it a bit but didnāt work for me.
Hi @eckinga,
Iām afraid that Navio2 does not support the communication via the FPort. However, it can be still used in the standard mode.
Dear All,
Iāve been trying for days to read Telemetry from my Navio2 to my FRSKy X9D, my wiring looks like this:
i set TELEM2=ā-D /dev/ttyAMA0ā in arducopter file (tried successfully regular mavlink2 HF telemetry to computer).
My X9D receives āCellā informations from my module through the XSR so seems this work.
Now i put Protocol 10 & Baud 57 in serial2, set SR2 parameters (in ardupilot) as:
I tried to swap Rx/Tx on my adapter
Obviously no data are transmitted from Serial2 to S-Port
So :
- Serial2 works fine with a 3DR temeletry connected (mavlink2) & communicates to Mission Planner
- S-Port reads fine Cell voltage from FrSky battery module received in X9D transmitter
- Transmission Cable Conversion Line cannot provide S-Port signal (either Tx/Rx are swapped or not)
=> I read all this exchanges could not find a hint.
Does anyone knows if Navio2 Can support this UART=> S-Port converter ?