need some help i keep getting this error
Compilation error: ‘D6’ was not declared in this scope
Marc, I have been pondering the situation you describe, but I just can’t figure why STA and AP should be different. I retrieved Horus, receivers and test gear from storage yesterday but I have quite a taxing schedule right now.
Colin, this looks like you are building for an ESP8266, but you need to tell me more. When you choose a variant in your IDE, a particular pins_arduino.h is selected by the IDE. In that pins file GPIOs are mapped to pin names (usually by #defined xx). For some variants they are not defined, for example if you select the generic 8266, then I define them in the config.h, FOR THE VARIANT SELECTED IN MY CODE. So, there are two possible places where you select a variant, 1) the IDE (arduino or (say) PIO plaformio.ini), and 2) in Mav2PT config.h.
If you remind me what your setup is, and/or give me a .zip I can look at it here when I get the chance
You definitely do not need to stress. I have a working configuration at least. I too have been busy. I am going to chip away at this issue when I get some time. I do agree that it is pretty puzzling though. I have another Dragonlink Transmitter so I will setup another system on the bench and see if i can find more information.
worked it out dumb windows update it was stopping ever program i ran as an Administrator 
so it could not wright to a temp folder
That’s a new one, and good to know about. Glad you found it.
Hi Eric,
I have encountered an issue with your converter running on my TXMOD inside an X10S to feed yaapu´s windget. My radio keeps reporting “motors armed” and “motors disarmed” in rapid succession in flight and if on the ground the current flight mode repeatedly.
I also think I know the cause, because it started doing this after I have connected a mavlink based parachute system to the UAV. This device has the same sysID as the FC and only a different compID. I suspect the following is happening: your converter processes both streams at the same time and my device reports 0 for the MAV_MODE_FLAG but the FC uses this flag properly. Your converter must use the last heartbeat message, regardless of sysID/compID to determine the armed state and thus the rapid armed-disarmed messages.
I am still running an older version (2.65.4), so it might have been fixed. I don´t know how cour code handles different mavlink systems and components, but it would be nice if it would only process data from the actual autopilot.
You could achieve this by only processing data from a specific sysID and compID, that you determine from the heartbeat messages. You could check for a valid autopilot by looking at the MAV_AUTOPILOT value inside heartbeat packages for supported autopilots.
Is this something you could/would implement, or should I search for alternative solutions for my problem?
Hi David, I think you are correct in your hypothesis, and yes I should be able to solve your issue in the way you describe.
I’m presently on vacation. If you want to code a PR in the meantime I would happily approve it, otherwise give me a week or two to get onto this.
No rush. Maybe I´ll code a PR for you, but I´m on holiday on the next two weeks. Have a nice vacation in the meantime!
Eric so my issues with ACCST RXs in my relay setup seem to be receiver-dependent. I am getting different results depending on what kind of D16 receiver I use. An old (but firmware updated) Frsky X6R was simply not working with a one wire diode mode on the ESP32 while a Frsky R-XSR was working on my ACCST Horus X10S – latest firmware. Just changed the receivers and made no firmware changes to the ESP32. Thus far nothing is working on my Radiomaster TX16S but I have a Radiomaster D16 RX on order to see if this solves the issue. It is interesting that different receivers are behaving quite differently. The ES32 OLED always reports that SPort has been successfully read.
As a matter of interest, we are on vacation on the Wild Coast of South Africa, and surf fishing with a drone to carry the line out beyond the breakers. Works like a charm.
2 Likes
I created two PRs for you when you get back from vacation. One should fix the issue we spoke about before, however I can’t test it for at least two weeks (the hardware is at work and we are closed for the holidays).
The other one fixes an issue, where the code wouldn’t compile on targets other than ESP32.
Ok David, i received them thank you. I can release them as beta in the inerim, and test them before moving them to stable.
1 Like
Hi Marc, I’m back at the office.
Hmm. That’s interesting. I assume in both receiver cases you use the regular pin or pad, not the “inverted” one. As you know, a regular S.Port signal is already inverted, so the esp32 should not invert. Regarding the Radiomaster, I guess I need to bite the bullet and get one to add to my collection, despite the law of diminishing returns. 
I did all my testing using R-XSR. My TS16S mk2 arrives on Wednesday.
David, I have numbered your updated version 2.68.05 and will test as soon as things settle down and I get some time.
It was nothing to do with inverting for sure… I have tested all of that. One other thing with EdgeTX I have discovered is that my issues were entirely related to using an existing model after upgrading firmware. That blocked me for months.
In summary I have everything working now. It took a long time to get my Radiomaster deployed.
What is frustrating is FrSkys assertion of patent means there are no D16 ACCST receivers easily purchasable. Everyone is gravitating towards flavors of CRSF now.
- Could you check line 214 in config.h, otherwise let me know and I’ll dig a little further
#define RSSI_Override 70 // Only if (RSSI == 0) force it to value, but only sent when Mavlink good.)
- Yeah, I noticed that back in Dec 2021, and moved the jquery into flash in V2.67.8
V2.67.08 2021-12-03 Fix OTA in AP mode with embedded jquery (acknowledgement M.Mastenbroek)
See line 83/84 of websupport.ino
- The libraries are still there, but inside a separate folder per platform/core
Yes, I should add a folder for Teensy.
So I`m back at work and my PR works as expected. As an added bonus you now have more resources available for other things, since we only process mavlink from the FC. You can include it into stable if you have no more concerns.
I have however noticed a few things:
-
After the update (from v2.61.0) the rssi value is fixed at 70 and is no longer updating. Did you change something since then regarding the rssi?
-
This is probably not something you can easily fix, but it would be nice if you could do an OTA update without an active internet connection. I have noticed, that the OTA update screen accesses some google api and the update doesn´t work if I don´t have an active internet connection.
-
You seem to have removed the libraries from GitHub. Why?
-
Ah, yes RSSI override is defined by default. I disabled it, but now I only see 69, which means there is no rssi data.
edit. We get no RSSI, because we only listen to mavlink from the AP.
I´ll try to come up with a solution.
edit 2. Problem fixed, you´ve got another PR. -
OTA update now works offline, thanks!
-
I see. The Arduino IDE does not support subdirectories inside the libraries folder, so we have to copy everything inside All to libraries. Also you might want to move ArduinoOTA from All to ESP32 (see PR).
-
I now have a different issue, where the S.Port telemetry only starts after I have connected MissionPlanner through wifi/UDP. Any ideas?
I have tried resetting the EEPROM. The only changes I made in config.h is to select ESP8266_Variant 2 for TXMOD, disabled MavAutoBaud and RSSI_Override and changed wifi SSID, password.
Can you please help me figure out why I’m not getting the passthru telemetry on my EdgeTx radio?
Dragonlink Tx Firmware: 3.326
Pre-built MavToPassthrough for Dragonlink V3 with internal Wifi v 2.60.2
I am following the instructions from here:
http://www.dragonlinkrc.com/instructions/v3equipment/taranistelemetry/
I selected the instructions for MavToPassthrough from the 1st link on the above page:
As the instructions say, I was able to flash the internal module with the ESP32 download tool, and was able to connect to the settings page and updated the STA SSID and STA Password, so my module is correctly connecting to my wifi network.
I also setup the external connections per the instructions, to Bluetooth and Wifi to be Radio Modem
Expansion con to ESP32 GPIO 1
Baudrate 57600
and USB is set to GUI config
Enable Mavlink decoding is unchecked
I can connect via UDP to the DL system and it is sending telemetry to Mission Planner, which is my GCS software. My linkquality is between 85 and sometimes up to 99
The problem is that there is no passthrough telemetry being sent to my radio… I did connect the pin from the UEXP port to the bottom pin on the module bay per the instructions but get no telemetry
I do believe the connection is on the correct pin, since if I go change the Expansion con to Taranis Telemetry, then I see a bunch of sensors, but those seem to come from the DL system itself, not the passthru telemetry ones. I do have the Yaapu telemetry working on my radio and I’m hoping to get it working with this receiver, but I’m not getting the telemetry.
Any help you can provide will be greatly appreciated.
