Ok then. I think you should make it a default to have the RSSI override commented out. I never uncommented it and I read that as it injects 70 instead of zero. But that is an easy fix for me
I can shield it but I doubt this is the issue. The legacy telemetry option does not work for me (or it has not in the past). I have seen others report that only the Auto option works for them.
That said I will get logs for the legacy option. I can also try F Port again. I had no success last time I tried it. Maybe that is the answer.
Thanks again. I will report back.
OK RSSI is fine now. Pretty silly that I never thought to comment that out. I just assumed the default was to send 70 if RSSI detected was O and not to override RSSI when it was not zero.
But no joy on using #define FrSky_Port_Type 3 // S.Port / legacy
That has never worked for me using an SPort receiver - and I am not the only one I think. But I do see IDLE detected as Low.
Starting src/main version:2.68.03
Display support activated: Landscape
64x128 text_size=1 char_w_px=6 char_h_px=8 scr_h_ch=8 scr_w_ch=21
EEPROM initialised successfully
EEPROM settings version:2.68.3
RESET_NVS defined. ALL SETTINGS IN EEPROM SET TO COMPILE_TIME DEFAULTS
EEPROM settings read and adopted
Relay Mode selected
Battery_mAh_Source = 3 - Define battery capacities in the LUA script
RSSI Automatic Select
Target Board is ESP32 / Variant is Heltec Wifi Kit 32
Mavlink Serial In
FrSky Serial Out
Mavlink WiFi Out - WiFi mode is AP
Protocol is UDP IP-Targeted
No Bluetooth options selected, BT support not compiled in
Mavlink serial on pins rx:27 and tx:17 baud:57600
S.Port at 57.6kb/s selected on rxpin:13 is IDLE_LOW, inverting rx polarity
FrSky half-duplex on pins rx:13 and tx:14
For 1-wire applications a 2-wire to 1-wire converter or diode is required
WiFi mode set to WIFI_AP
AP_default_IP:192.168.5.1 AP_gateway:192.168.5.1 AP_mask:255.255.255.0
AP IP address: 192.168.5.1 SSID: Mav2P
mDNS responder started
Begin UDP using AP UDP object read port:14555 send port:14550
UDP for AP started, local 192.168.5.1 remote 192.168.5.255
Web support active on http://mavtopass.local
hb_count=1
hb_count=2
hb_count=3
Mavlink good!
And for posterity here is a log where it functions fine and my Yaapu script reads the S port telemetry.
Telemetry option is 4 (Auto) and Mode is AP.
So you said you would expect it to sense pin 13 as low. Well it only works for me when this is logged as high. For #define FrSky_Port_Type 3 // S.Port / legacy I think we need to to not invert possibly.
In any event I do not think this explains my lack of telemetry as detected by my Yaapu scripts in STA mode. My yaapu lua scripts do not skip a beat when I am connected to Mission Planner so I am not sure it is 2.4 interference.
Starting src/main version:2.68.03
Display support activated: Landscape
64x128 text_size=1 char_w_px=6 char_h_px=8 scr_h_ch=8 scr_w_ch=21
EEPROM initialised successfully
EEPROM settings version:2.68.3
RESET_NVS defined. ALL SETTINGS IN EEPROM SET TO COMPILE_TIME DEFAULTS
EEPROM settings read and adopted
Relay Mode selected
Battery_mAh_Source = 3 - Define battery capacities in the LUA script
RSSI Automatic Select
Target Board is ESP32 / Variant is Heltec Wifi Kit 32
Mavlink Serial In
FrSky Serial Out
Mavlink WiFi Out - WiFi mode is AP
Protocol is UDP IP-Targeted
No Bluetooth options selected, BT support not compiled in
Mavlink serial on pins rx:27 and tx:17 baud:57600
Sensed serial port pin 13 is IDLE_HIGH, regular rx polarity
autoBaud - sensing pin 13
autoBaud: 57600 b/s
FrSky half-duplex on pins rx:13 and tx:14
For 1-wire applications a 2-wire to 1-wire converter or diode is required
WiFi mode set to WIFI_AP
AP_default_IP:192.168.5.1 AP_gateway:192.168.5.1 AP_mask:255.255.255.0
AP IP address: 192.168.5.1 SSID: Mav2P
mDNS responder started
Begin UDP using AP UDP object read port:14555 send port:14550
UDP for AP started, local 192.168.5.1 remote 192.168.5.255
Web support active on http://mavtopass.local
hb_count=1
hb_count=2
hb_count=3
Mavlink good!
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.