Connect ELRS RX to ELRS TX - Telemetry missing #2279
Replies: 28 comments 6 replies
-
I would say the problem is most likely in the conversion from full duplex to half duplex?
After any packet is sent from gateway RX, the half duplex connection must immediately be flipped to receive to get the data. You can verify by making sure you're getting opentxsync packets from the gateway TX even when there's no model connected. The format of the telemetry is not modified receiving vs transmitting, although the destination address may be changed but (without looking it up) I believe the RX code supports receiving 0xC8 or 0xEE just fine? |
Beta Was this translation helpful? Give feedback.
-
Hi Bryan, thanks for your reply. I had first tried to make a conversion full to half duplex with a diode or resistor. That works too, unfortunately only for RC. Then I noticed that this solution is a one way street and the telemetry does not find its way back. Then I tested the bidirectional full to half duplex converter in the attachment. However, it does not work with that either. I take it from your answer that I guess only hardware can't solve the problem? So the immediate switch to receive data? What would you recommend as an alternative? RP2040 / ESP32 with appropriate programming? If the format of the telemetry is the same on both sides, this should be feasible. Then you could also send the LQ value from the gateway TX <-> model to the handset. The problem for me is, that I can handle the programming of the serial interface, but the handling of the CRSF frames is new territory for me. There I would need probably a little support ... |
Beta Was this translation helpful? Give feedback.
-
I do not know if that converter is suitable for this application, I've never used one before. You'd have to do your own testing to see if you're getting anything at LinkStats will never be passed back from |
Beta Was this translation helpful? Give feedback.
-
But that's not how our telemetry system works. It isn't a straight passthrough connection from the FC to the handset, therefore LinkStatistics won't just "pass through" from After I looked at the code this morning, I also think there are some changes needed for telemetry to pass through at all because the RX code will only recognize packets with a CRSF destination of |
Beta Was this translation helpful? Give feedback.
-
I'm pretty sure no new mode would have to be added, just some minor stuff for accepting the telem, some not-so-big changes to support half duplex RXes (at least in this form), then some major restructuring to be allow incoming linkstats to override the internal linkstats in a way that doesn't upset me. That's when you'll find the 800 other things that need to be addressed probably. Now is also not the time for me to work on this when there's more pressing things on the agenda. Aren't we messaging right now? :-D Actually this is about as far as I'm going on this journey at this time. |
Beta Was this translation helpful? Give feedback.
-
Oof this took me like an hour and half to get a test setup running, but I've made a PR that stops rejecting the telemetry received at I get a ton of "sensor lost" messages at the handset as the rate, and none of the Lua receiver(s) configuration seems to work either (they never show up), but maybe that's a better starting point than outright rejecting the data. |
Beta Was this translation helpful? Give feedback.
-
Maybe the PR is already enough so that we can use the relay to some extent ... I would like to test. What exactly do we need as hardware for the gateway TX? |
Beta Was this translation helpful? Give feedback.
-
The TX is unmodified, it is just the RX that needs updating. I tested it with a full-duplex TX because de-half-duplex-inverting a regular TX module was not an exercise I wanted to attempt to debug. If telemetry from a TX arrives at an updated RX it will now forward it, without the update it will silently discard it. So if this doesn't start forwarding telemetry for you, you're going to need to get a logic analyzer / oscilloscope on the RX's RX pin to figure out where to go next. |
Beta Was this translation helpful? Give feedback.
-
I could do tests with Happymodel EP1 (DUAL) TCXO receivers if someone will make me a firmware for it. Logic analyzer and Oscilloscope are also available ... |
Beta Was this translation helpful? Give feedback.
-
Use the Configurator. But not right now because platformio just broke everyone's builds around the world for all projects with their forced update, you will not be able to compile anything from any project right now. 😡 |
Beta Was this translation helpful? Give feedback.
-
The first test was successful! Telemetry went now immediately, although I still have to see how coherent the values are. In the next days I will do a flight test. About the binding phrase: here it makes sense to use two binding phrases? One for Handheld -> Relay RX, a second or the normally used one for Relay TX -> Plane? |
Beta Was this translation helpful? Give feedback.
-
Nice! I found that I'd get a lot of sensor lost messages on the in-car handset so you might have to tweak the TLM Ratios on each TX to find just the right combination that keeps the telemetry pipeline full without wasting too much bandwidth on it. Oh yes 100% you need to use 2x binding phrases. Two receivers on the same binding phrase will connect to one TX, and if there are two TXes it will be random which each will connect to and it could switch mid flight. Model Match isn't designed for that either (in case that was the next question). |
Beta Was this translation helpful? Give feedback.
-
Yes, I was actually wondering whether Binding Phrase or Model Match was the right one. Because I have so far only used the Binding Phrase and that works great, I then took a second phrase. Sensor lost: I once had the problem that only 10 parameters were updated (all from the TX in the handset). I just restarted the RX and it then ran normally. I must still observe whether something hangs up there. I currently use 100 Hz full and 1:4 telemetry. This is also my usual setting. |
Beta Was this translation helpful? Give feedback.
-
Regarding all the sensors not coming, if a telemetry item is in the middle of transferring (which is constant) and the connection on one end is restarted, then it can take a while to time out before resuming sending telemetry. That means sometimes it may take a bit to resync. This usually takes 20s or so if there's only one TX/RX pair and I think it shouuuuuuuld be the same even with a gateway, so if you see that happen again try waiting a minute to see if resolves itself. It is only a problem on startup from what I've seen. |
Beta Was this translation helpful? Give feedback.
-
I received various new hardware today, including RM Boxer ELRS and RM Ranger TX. Boxer connects to an RM EP1. Both are flashed with 3.x.x-maintenance. I assume above PR is included there. Now when I connect the RM Ranger TX to the EP1, the Ranger reports "No handset". Neither RC nor telemetry is transmitted. If I connect a Full Crossfire TX instead of Ranger, it immediately reports CRSF V2 as input protocol. RC and telemetry work with it. Therefore the conversion Full Duplex to Half Duplex works. Furthermore I noticed that via ELRS LUA script on the Boxer handset the menu item "Other Devices" is missing, if the converter (resistor) is connected. Currently I only have a 1k resistor on the RM EP1 from the TX output to the RX input and from there a connection to the S.Port of the Ranger TX. Currently I can not explain why it worked with the PR and now with 3.x.x-maintenance no longer ... |
Beta Was this translation helpful? Give feedback.
-
The problem could be solved ... The baudrate of Relay-TX (400.000) and Relay-RX (420.000) did not match. I have now set the RX to 400.000 baud. The baud rate of the TX can not be changed? Sure, if the TX is in the handset, but not in the WebUI and not on the hardware page (there are only options for the backpack). I have a question about the baud rates: why are they different for TX and RX? |
Beta Was this translation helpful? Give feedback.
-
The TX autobauds to any supported baudrate (400000, 115200, 5250000, 3750000, 1870000, 921600, 2250000). It can not autobaud to 420k because it is too close to 400k and as you found, if it picks the wrong one it doesn't work at all. They are different bauds because that's what TBS made it. |
Beta Was this translation helpful? Give feedback.
-
Will be a relay option officially added to elrs? |
Beta Was this translation helpful? Give feedback.
-
The change described above is included in the 3.3.0 release. So I guess you can call this official. |
Beta Was this translation helpful? Give feedback.
-
Oh cool! Can be a relay Tx also controlled with the Lua script? |
Beta Was this translation helpful? Give feedback.
-
You can simply answer the questions yourself if you read through the above discussion ... The point was that the telemetry did not work before. There is no setup guide because the setup is simple: two ELRS routes with different binding phrase. Set the RX in the relay to 400 kBaud, TX line from it via 1k resistor to RX line, from there to pin 5 of the relay TX. The TX in the relay can be set via LUA script, if you plug it shortly to a suitable transmitter. |
Beta Was this translation helpful? Give feedback.
-
Thank you. It's was too easy to believe ) For the Lua script I meant to control second tx without pluging to a radio of course. |
Beta Was this translation helpful? Give feedback.
-
In the constellation as described above, RC has always run in the relay. The only new thing is that the telemetry now also finds its way back to the transmitter, which is why I started this discussion. What you meant with the LUA script is already clear to me. But for LR you set it once and then you don't have to do it again. |
Beta Was this translation helpful? Give feedback.
-
It is "officially supported" currently, but takes some work to get set up and doesn't provide all features. Even though it works but it isn't great so I don't really recommend it. It is one of the things you can do with ExpressLRS but maybe shouldn't. The telemetry is significantly delayed, more than doubling the amount of latency in receiving telemetry items, which already isn't great due to our architecture. Link telemetry also shows just the actual link, not the relay link information. You can not control the remote TX module from the Lua and likely will never be able to. This is because they both have the same "address" on the CRSF network. I'm not sure if using scripts for configuring the flight controller on the handset will work either. Some of this could be addressed but it will never be a great solution. |
Beta Was this translation helpful? Give feedback.
-
Thanks for clarifying Capnbry! Any chance that the great solution can be ever found in the future? |
Beta Was this translation helpful? Give feedback.
-
Hello Following a suggestion from Target0815, I would like to add that I tested this setup yesterday, and worked like a charm. Thank you all :) |
Beta Was this translation helpful? Give feedback.
-
@Target0815 Telemetry works, but I encountered the following problem: telemetry from the relay overlaps telemetry from the drone. I see the RSS from relay, but I need it from a drone. At the same time, I receive RxBAT from the drone and other nonovelapping telemetry. |
Beta Was this translation helpful? Give feedback.
-
It is already written above that this is the case ... And that more programming is required for this. |
Beta Was this translation helpful? Give feedback.
-
Hi,
I would like to connect an ELRS RX with an ELRS TX for a relay setup. This is possible by converting from serial full duplex to half duplex.
Technically this is no problem and works. The problem is that RC data is transmitted, but no telemetry.
In Discord I got a tip that the CRSF packet data for ELRS RX and ELRS TX might be different. However, I have not found much on this subject.
Can someone explain me how it is with the CRSF packet data for RX and TX? Maybe @CapnBry has a little bit of time for this?
Thanks.
Beta Was this translation helpful? Give feedback.
All reactions