-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compiled binary? #2
Comments
binary is in folder uf2. It is file Application.uf2. |
Thank you, can you help me with wiring, where should i connect s.bus,s.port and rx tx from elrs receiver? |
It is explained in main.cpp. |
// SPORT (TX and RX) uses PIO0 and pin 5 |
it is pin 5. |
Can you also add extra PPM output, i can donate you some money for beer) |
I developed this project on request of someone. |
Why do you want a PPM output? |
I want to connect 433mhz as backup channel, but you're right, I can buy converter |
Do you remember link?) |
You can also search on "relay" in DIY Electronics section |
I can't get a connection with either an ELRS TX or a Crossfire TX ...
Questions: Checkup:
It looks to me like the program is not running on the RP2040 Zero. For testing, can you maybe make the LED flash red when there is no SBUS signal and green when CRSF is output? |
The S.Port connection to the ELRS TX was not ok ... Now the connection is there, RC works. The ELRS telemetry works actually also, but with dropouts. Many entries are updated at , then data is missing, it is updated again etc. With Crossfire RC works, but just like @DangerD1024 no telemetry comes. |
Did you already try to change the telemetry rate inside ELRS. I am not sure that this is the reason of the issue but it is good to try first. |
I currently have ELRS set to 50 Hz and 1:8 TLM rate (for Long Range). I can probably reduce the TLM rate on a test basis. Do you have an idea why no telemetry arrives at the Crossfire? As RC connection the Crossfire Full-TX reports "CRSF v2", so it should actually work. However, during the test yesterday I only operated the CF TX and did not have a CF RX active. I wanted to test that today. By the way, the goal in my case is to be able to run the Yaapu Script on the transmitter. I use ArduPlane and here S.Port Passthrough is transmitted which also works with a pure CRSF system (ELRS or Crossfire). Since the Yaapu Script has become a certain standard, if you as an ArduPlane user do not necessarily want to use a GCS with Mavlink, it would be very interesting if your relay could implement this directly for ELRS and Crossfire. |
How many beer bottles or how much $$ you want for fixes?) |
Or better to make CSRF->CSRF relay |
I do not have an installation to test the relay project. |
Let's make them |
I just put on github a version in "test-without-wizio" branch that should display a line on the PC for each telemetry frame received from the ELRS TX module. |
A picture posted here above shows some telemetry fields with a code staring with 0C0x. In the handset it is possible to change the setup of those telemetry fields in order to get a meaningful name instead of the code. |
I can't find where you've uploaded it... |
@mstrens : why do you use special codes, if you can simply use the S.Port Passthrough protocol, which @Yappu uses in his script for the conversion of ELRS CRFS or Crossfire CRSF? You would solve 2 points: the source is ready and tested and every station with FrSky S.Port can handle it. That would be just perfect for a relay. |
This project receives 5 types of CRSF telemetry frames from a ELRS receiver. Each frame contains different types of fields. Still, as far I know, there is no specific Yaapu frsky Sport format defined to transmit the ELRS Tx/Rx link quality data. |
Do you know the Yaapu script? This is primarily used to display various telemetry information. It replaces a GCS on a small scale, so to speak. Furthermore, it decodes the S.Port passthrough data stream and "creates" the individual telemetry entries in the transmitter. Without Yaapu script there is no telemetry data when S.Port Passthrough is used. This is a disadvantage at first sight, but in the end you only have to install the script, which is hardly any effort. A relay is primarily of interest for long range. I fly mainly LR and am of course interested in telemetry info. Without relay I have a lot of necessary information with the Yaapu script. With Relay only the RC connection works at the moment. I could now use Mavlink and use QGC or Mission Planner for display, but that always means additional hardware/effort. So it would be very nice if CRSF data (no matter if from ELRS or Crossfire) is translated directly from your project to S.Port Passthrough. I realize that S.Port Passthrough has no format for Tx/Rx link quality data yet which is important for relay operation. I think @yaapu will not be averse to implement this as well. I myself would sponsor the implementation with 250 EUR and also be available as a tester. |
One more thing comes to my mind ... I can use ELRS or Crossfire in a relay and currently have only RC control available there. Basically I take full duplex UART from the ELRS/CF RX and convert that to half duplex to feed an ELRS or Crossfire TX. This works. What is not clear to me is why in this case is the telemetry not converted as well? What is different if I have the TX plugged into the transmitter? (in this example I use 2x TX, once in the transmitter, with 10 mW to the relay and there the 2nd TX is driven. S.Port is here outside) |
I'll test that at evening, i've got non working Pixhawk 6C, imu heats up to 120* o_O and pc doesn't recognize it... |
Tried to connect it to Crossfire module, there's no debug output at all, except "start" |
I think I understood a bug I made. In ELRS, when a value is coded on several bytes, the most significant byte is put first in the frame. I decoded the values in the opposite order. |
can you also output extra csrf tx on pin0 (TXD0)? |
I propose first to try to get telemetry working. I expect it should be better. |
Thank you, works fine now =) Just Yaapu script doesn't works, i'll investigate why =) |
What about Crossfire and extra PPM output on unused TX? |
I expect that Yaapu script expects that the data are transmitted in the condensed format (grouping several field into a single packet and using the Yaapu code ID to identify the telemetry packets. |
I put a new version this morning where I adjust scaling of telemetry fields (e.g. voltage is in 0.1V in ELRS and in 0.01V in sport). |
? =) I can provide you any debug info with TBS crossfire |
It is not clear for me what you expect. |
You should really take a closer look at the project. IMHO you are doing work that is actually already done (except for things like remote RSSI etc.). The Yaapu script works with S.Port passthrough, so the condensed format. But I don't know exactly how this works with CRSF, because in the setup of the Yaapu script you have to select CRSF specifically, so that the script also works with Crossfire and ELRS. Maybe Alessandro can say some things about this, I'll send him a message => @yaapu |
S.Port Passthrough protocol specs: https://docs.google.com/spreadsheets/d/1oFv5zSl10wyR0LOcCChDdy9peIRNkbaEBrsHDQ0ZdmE/edit#gid=0 Passthrough over CRSF: https://github.com/yaapu/FrskyTelemetryScript/wiki/Passthrough-over-CRSF-and-ExpressLRS |
I put on github in "test_without_wizio" a version that is supposed to generate a ppm signal on pin 0 |
something is not right, transmitter can't read it... |
tried on TBS crossfire and Arkbird 433, both was unable to identify it |
have you finally got your retransmitter working? I also would like to implement the same schema |
Works fine, but better use elrs-elrs yappuu script will work |
I can't install Wiz-IO package as it looks like outdated or something...
Wiz-IO/framework-wizio-pico#54
Can you share compiled binary?
The text was updated successfully, but these errors were encountered: