Thanks for the feedback Marc. Could you clarify how you electrically couple the esp s.port pins to the receiver? In the meantime I’ll take another deep look at the STA code.
Maybe it’s a timing issue. In Air and Relay modes we read the frsky receiver polls, wait for the diy slot, then inject our frsky diy packet. Timing is important.
-
In our main loop, we read the FC, store messages in a ring buffer.
-
Then pick up message from ring buffer, decode it, send it to GCS.
-
Then handle the frsky (sport) reading and writing.
So in 2), we send mavlink to GCS, and if STA mode, for any reason, is taking longer than normal, 3) could be delayed. The code for 2) and 3) looks like this:
//==================== R i n g B u f f e r D e c o d e & S e n d T o G C S
// if (millis() - downlink_millis > 1) { // main timing loop for mavlink decode and to GCS
decodeRBtoGCS();
// }
//==================== H a n d l e F r S k y P o r t T r a f f i c
#if (defined frBuiltin)
FrPort.HandleTraffic();
#endif
around line 980 in the main loop. Notice that I was playing around with a timer for decodeRBtoGCS().
You could uncomment (restore) the timer loop and try a few millisecond variations:
if (millis() - downlink_millis > 1) { // main timing loop for mavlink decode and to GCS
decodeRBtoGCS();
}
Try between 1 and (say) 5 mS.
I am using the one of these: Some soldering required
It’s wired up exactly as the Relay schematic in the wiki.
Timing. Now that looks promising. I will play with this and let you know.
Ok, that’s why my assumption was wrong. We must not invert in the ESP32, because you are inverting outboard. Auto sees that correctly.
Yep. That’s what I thought!
You could save some space and wiring if you use only a diode, and invert in the esp32.
On the other hand, if it ain’t broke …
Yep! I could! Maybe just add a sentence in config.h next to S Port option.
Eric,
No joy. I tried from 1-5 ms. This is not critical at all. If you think of anything else to try I am happy to do it.
Eric,
How easy would it be to have te ESP32 boot up with Mavlink on the USB port of the ESP32. I think we are only using one of the 2 buttons on the ESP32, I was thinking that if the other one was pressed in while it was booting it could put Mavlink on the USB and kill the wifi. For longer flights I am just thinking of going with a USB cable. I code a lot but not much with micro controllers.
It is not a big deal as I have other workarounds by reverting back to Teensy with ESP8266 and connecting a USB port in serial with the mavlink out from the Teensy - and adding a power switch for the ESP8266 as well.
Marc
Marc, only a few microcontrollers can switch into usb host mode. The ESP32 is unfortunately not one of them, and it’s not trivial without the hardware part.
Marc, I just read your ST mode issue and I can confirm that Sport telemetry is working fine on my QX7 radio running Yaapu telemetry script with dragonlink (as a relay mode using Frsky R-Xsr receiver) and Heltec. Sport telemetry stops for few seconds when it gets connected to the mission planner for parameter download but it revives by itself if you wait a little.
But Mission Planner does not understand S.Port telemetry, only Mavlink …
I meant if you have a mission planner running
on a phone or a laptop connected to the flight controller like this : Flight controller----Dragonlink----Heltec—home router----laptop. S- port telemetry works on my QX7 Its connected like this: Heltec----high speed diode on heltec’s S-port out GPIO pin—R-Xsr receiver—QX7.
You need to separate two things here:
In the first case, Mavlink telemetry is output via Heltec Wifi or your home router. MP can connect to it.
In the second case S.Port Passthrough telemetry is output. This is a packed S.Port format. And for that you need the Yaapu script on the transmitter to see the sensors. If you don’t start the Yaapu script for a test, then there are no sensors.
Yeah I know they are totally 2 different channels here.
I am gonna explain it what I meant by " S-port telemetry stops for few seconds"
Lets say you are in a field with ardupilot booted and connected to Frsky QX7 radio via relay through dragonlink , Heltec and frsky R-XSR. Yaapu works and you get all the sensor data on your QX7.
And you take out your laptop and connect it to the heltec’s wifi and run mission Planner. So as soon as mission planner connects via UDP, You start getting sensor lost or telemetry lost warnings ( can’t remember which one) on QX7 but after few seconds, as parameters start downloading on the mission planner, S-port data starts flowing and yaapu script sees data again.
Same goes with being at home where heltec and your laptop are connected to your home router.
So it seems like when mission planner tries to establish connection with the flight controller, somehow it pauses the Sport data for few seconds.
Interesting. My issue has nothing to do with Mission Planner. In STA mode I get no Passthough telemetry on my Yaapu scripts and in AP mode I do. It makes no difference if I have a GCS connected or not.
Are you using a Heltec board? What version of Mav2p are you using? Are you using this in relay mode?
This never used to be a problem for me but I do not know yet if this is related to changing to a relay mode and/or a bug introduced in later versions so please do give me more details about setup.
Marc, is it possible that S.Port telemetry is output in STA mode and then S.Port passthrough in AP mode?
Can you check without active Yaapu script if sensors are displayed/found in STA mode?
Thanks. I was looking at this and it looks like some libraries exist for making Teensy act as a USB host but it is such a niche use it’s not worth the effort. I can achieve the same thing with some off the shelf hardware.
Yes, I think this is actually what is happening. I am getting only the receiver RSSI and Receiver voltage in STA mode while in AP mode I get the full set of Passthrough telemetry. I can see them in the telemetry discovery page in OpenTX. @Eric_Stockenstrom what do you think?
Also maybe somewhat related – I cannot make this setup work with a Radiomaster TX16S under STA or AP. It only sees receiver voltage and RSSI and no Passthrough telemetry. But one problem at a time.