Thanks for the feedback Erwin. Glad its’s working for you. I’ll look at this a bit closer.
Erwin, a close look at the boot log (serial monitor), comparing the two scenarios for FrSky port type
- hard settings
- auto detect
should shed light on why 1) did not work. If you get the time could you post the logs here?
where do i get the logs?
Copy and paste the serial monitor log the displays the progress after the board boots, and paste it into a new .txt file.
Starting MavToPass version:2.67.05
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 read and adopted
No FrSky port support selected or built in
Target Board is ESP32 / Variant is Heltec Wifi Kit 32
Mavlink Serial In
Mavlink WiFi Out - WiFi mode is STA>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:115200
WiFi mode set to STA sucessfully
Trying to connect to DragonLink…
WiFi connected!
Local IP address: 192.168.4.2
WiFi RSSI:-85 dBm
Begin UDP using STA UDP object read port:14550 send port:14555
UDP for STA started, local 192.168.4.2 remote 192.168.4.255
Web support active on http://192.168.4.2
192.168.4.1 inserted in UDP client table
UDP client identified, remote IP: 192.168.4.1, remote port: 14555
Thanks for this information Erwin
I think what happened is that your board is picking up the eeprom settings of the older version by default.
This has been an ongoing issue for a while, so I have uploaded v2.67.6 which will refresh the eeprom settings if the firmware version changes. This should fix the issue of picking up old settings when the eeprom structure might have changed in between versions.
oh, i’ll try this out 
Thanks eric!
Eric,
On my heltec relay setup, I still get RSSI 70% stuck… I did try to work around, commenting the line:
#define RSSI_Override 70 // Only if (RSSI == 0) force it to value, but only sent when Mavlink good.)
The Rssi changed to 69, not sure if this is really working? or should I expect a value higher than this? since my dragonlink tx and rx are just near each other?
Hi Erwin
The subject of rssi, including for relay mode, is explained at length here
If still have an issue after reading the link, I’ll help with pleasure.
update:
it’s working now 
Ah, great to hear. Can I ask what the problem was?
Im actually not sure hahah! i’ll try to dig into this. but yesterday, i found something odd… im getting wrong information on the yaapu script. wrong flight modes indicated… not sure if it is due to the firmware update on the mav2pt. but i’ll still look into the details, i will try to replicate the issue.
edit:
i tried to boot the setup today, everything seems normal… weird. haha!
Hello, this may have been answered before but I couldn’t find anything in this topic or the repo.
What is the difference between MavToPass, MavToPass_Receiver, and MavToPass_Sender located within the source directory in the github repo?
Thank you!
Hi Kyle
One of the guys needed to relay FrSky telemetry from the back of a FrSky transmitter, so MavToPass_Receiver and MavToPass_Sender are simply MavToPass configured (ports etc in config.h) for him to do that task, and binaries created. I guess I can drop them off with the next minor version update.
Eric
I am attempting to use MavToPass in relay mode with the SIYI HM30 video/telemetry unit and an Archer RS in FPort mode. I intend to use an ESP32 connected to the UART and RC ports of the HM30.
The HM30 requires SBus on the RC port, and according to the wiki:
With a few tweaks Mav2PT can decode the RC control telemetry and output it as SBUS, PPM or PWM.
It looks like those “tweaks” are not yet implemented - is that correct?
Is the intent to implement those tweaks in the presently empty #ifdef macros for Support_SBUS_Out?
Yes I tested the code in another application and it works fine, but I cut and pasted into mav2pt so it will maybe need some testing. I’ll take a closer look tomorrow.
1 Like
Thanks much! I’ll await your reply rather than diving into the code further just yet.
Hey @Eric_Stockenstrom, another Q for you. I can’t seem to find a definitive answer for this either.
In the config.h code where you define mvBaud.
It states 57600 for a dragonlink link transmitter, however when you go down and look at the actual settings for the platform dependent setups. In there you can see that the mvBaud variable is overwritten with a baud rate of 115200. If you wouldn’t mind clarifying this.
And also, In a situation where a dragonlink is being used, Is mvBaud supposed to match the baud rate (SERIALx_BAUD) coming from ardupilot/mission planner? Lets say the baud rate coming from ardupilot is 57600, is there something I should be aware of for the reason of the switch to mvBaud 115200 in the source code.
Cheers
Hey Kyle
Line 57 in config.h. (Ctrl/F is your friend 
) The reason it’s a variable is to accommodate the optional auto baud rate detection.
Some of the others contributed substantially during the Dragonlink setup for V3 slim, so I guess that’s where the contradiction came in. If I remember correctly, we started at 57600 but eventually had it working at the higher speed. The baud rate should naturally match all the way through or you will have a bottleneck, but U(S)ARTS, where two devices talk to each other, must have the same baud rate (or they won’t talk, right?). The speed of the radio link is the limiting factor, where you trade off bandwidth for range (link budget), then you have U(S)ARTS at each end that must match each other. I remember adjusting the radio link baud rate somewhere in the DL setup interface.
EDIT. At the the Pixhawk (or equivalent) end, you should wire for hardware flow control. RTS/CTS etc
@Yuri_Rage: SBUS out
I remember now why I did not complete SBUS out. The ESP mpus only have 3 UARTS, and I need an extra UART to implement SBUS out. I can’t use SoftwareSerial for SBUS because of timing issues (I think|), but I can look at using SoftwareSerial for Mavlink serial, then use that UART. Decisions, decisions.
I assume you want to use the ESP32?