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?
Makes sense!
Yes, I intended to use an ESP32.
Ok, I added SBUS out of v 2.16.11 in Source/Experimental folder
Use this option in config.h
//=================================================================================================
//============================ F R S K Y S E T T I N G S ==========================
//=================================================================================================
#define Support_SBUS_Out // Derive SBUS from F.Port and present it on a uart tx pin
A bunch of changes had the be made to switch UARTS around, so it needs testing. I ran out of time. 
EDIT: I coded for ESP32 variant 5 only for now. Added
#define sbus_rxPin 99 // not used - don't care
#define sbus_txPin 12 // Optional SBUS out pin - not 16
so I still need to select an unused pin for sbus_txPin on the other variants
Thank you so much for the quick response! I will try and give it a go very soon. My board is probably “variant 1,” but with your note regarding pin selection, I can probably make that work.
EDIT:
I must admit that I may have jumped the gun with this feature request, as the receivers I intend to use have SBus Out pins that will probably suffice. I will still try to test the experimental feature for you at some point soon, but it may not be necessary for my application.
Hey Eric,
I think my question was worded a bit oddly, I’m aware why mvBaud is a variable. I was actually wondering why mvBaud defined on line 57 states that it should be 57600 for dragonlink. And then on line 551 mvBaud is re-defined as 115200 for dragonlink. I was wondering if there was some sort of gotcha for mvBaud of 115200 with the dragonlink units. Sorry for the confusion.
Hey Kyle, your question was just fine. I would try 115200, and if you run into problems revert to 57600.
I have had some measure of success with the following configuration:
- v2.67.10 in Relay Mode
- SIYI HM30 MAVLink UART → Teensy 3.2 pins 9, 10, 115200 baud
- Archer RS “inverted” FPort pin → Teensy 3.2 pin 8 (hardware serial 3)
- Archer RS SBus Out → SIYI HM30 RC
- Archer RS bound to a Horus X12S in ACCESS mode, FPort v2, Yaapu v1.9.6-dev
- SIYI HM30 RSSI on RC channel 15 - seems to be reliably reporting good values via MAVLink
MAVLink ingestion seems to be working extremely well in all cases.
I’ve seen multiple notes in this thread regarding no need for inversion or 2-wire conversion for the Teensy, but this note remains in the Wiki:
While testing using a Teensy 3.2, my Archer M+ and Teensy did not work reliably in one-wire mode at 115200 b/s. I resorted to normal 2 wire (rx/tx cross over), with a two-wire to one-wire converter.
The config above is reasonably good with #define Send_status_Text_3_Times uncommented, but text messages are still garbled at times, and occasionally the telemetry link is simply lost (while RC/SBus still works fine).
I got slightly worse results with this conversion module connected to the Archer RS FPort out pin (the one labeled non-inverted) and FPort v2, and 2-wire serial on the Teensy.
FPort v1 seems even less reliable with or without the conversion module.
And all of the configurations performed worse on an ESP32, variant 1 (data seen intermittently and eventually stops altogether).
To summarize:
- Best results with Teensy 3.2, serial 3, FPort v2, one wire, but still unreliable
- Unreliable on Teensy 3.2, serial 3, FPort v2, two wire (with an Amazon sourced converter)
- Very unreliable on Teensy 3.2, serial 3, FPort v1, one or two wire
- Very unreliable on ESP32, variant 1, regardless of config
I have attempted to scour this thread for info, but 600+ posts are a lot to digest, and there is some conflicting info. What is the latest recommended configuration for reliable results? Should I be soldering up a 2-wire converter per your schematic much earlier in this topic? Is it possible that the R-XSR simply works better than the Archer series in this application?
Yuri_Rage: Thanks for the detailed feedback. I made the comment below after a particularly frustrating session trying the make the Teensy work on F.Port in OneWire mode at 115200 b/s. EDIT: There is no problem with S.Port at 57600 b/s. I was pushed for time and resorted to my homebrew half-duplex one-wire inverter/converter. The intention was to go back and try to understand the problem, but alas, as the proverb goes, the road to hell is paved with good intentions 
This circuit has worked well for me over the years, and usually works when all else fails:
EDIT2: Others, including Alex (yaapu) reported poor performance with FPort1, and I believe that was one of the reasons the protocol changed in F.Port2.
My experience is that the “conversion modules” with the RS232 board and reverse diode don’t work very well or don’t work at all. On the other hand, when signal inversion is not required, or has already been done by the mpu, a simple Schottky high-speed signal diode has generally worked well for me to achieve a “onewire” signal from a two-wire signal. I use a 1N5822. Here is an example on a Heltec board for use with S.Port. Pin 13=rx and pin 14=tx
and here is an example for F.Port
Note that the diode is now reversed because the pulses are “normal” idle high, not reversed.
I’m surprised that your experience with the ESP32 and FrSky telemetry was poor. This is not generally the case, so I’m wondering if there is some other issue.
Finally, I guess you have seen this, but you should see packet loss reported on the monitor every 2 minutes.
//=================================================================================================
// O T H E R U S E R O P T I O N S
//=================================================================================================
#define Report_Packetloss 2 // Report S.Port & F.Port packet loss every n minutes
Yuri, I have been pondering over your post. Both ends of your HM30 will be transmitting relatively powerful RF. Have you taken care to shield and decouple the add-on bits like the Teensy and wiring in your relay setup?
Thanks again, Eric, for your quick response. Reported packet loss while the connection remains active is typically reported quite low (fractions of a percent).
I have not yet tried SPort - it requires a firmware change on the receiver that I was attempting to avoid. Glad to know that it may be a good solution.
I have a few signal diodes in stock, so it’d be easy to give that a try.
As for shielding - I really haven’t done anything there. Everything is just inside a makeshift enclosure that I cobbled together from some plastic retail packaging that was about the right size. Is there a particular method you’d recommend?
As for the ESP32, it’s possible that I did not have the correct one-wire connection and only tested properly with the conversion module that you mention as unreliable. I may revisit that.
Given the unreliability so far, I’m less motivated to try the SBus out feature, especially since I’ve found a solid means to avoid it.