FBUS to S.PORT_GPIO

[Satcomix]

Hello Mstrens, I did some tests with the FBUS protocol again today. For this I had two oXs_RP2040 in operation in parallel and at the same time with original FrSky FBUS telemetry sensors of the ADV series, of course with different Phys.IDs and App.IDs of the two oXs_RP2040. Everything worked great! While doing this I got an idea: On the oXs_RP2040 I can generate the 16 PWM channels and SBUS_out from the FBUS protocol, would it be possible to generate a S.PORT_bus GPIO on the oXs board, on which external S.PORT telemetry sensors can be operated with 57600baud??? I know it's a bit of a crazy idea, or? Greetings, Torsten

[aepub]

Hello Satcomix， Do you use the test version of 2.5.8 to test for overvoltage and current? I used it to test voltage and current, and the numbers displayed on the remote control kept bouncing, such as the current displayed between -0.1A and 2A, but I did not perform any operation. The displayed voltage value will also continuously jump, rather than staying at a specific value.

[mstrens]

If you connect the RP2040 to a PC (via USB) and sendthe "FV" command, are the displayed values also jumping? This test allows to see if the issue is in the code that performs the measurements or in the code that sent the value to the handset.

[Satcomix]

Hello everyone, I did all my tests on version 2.5.8 and apart from a 2-3mV variation in the voltage reading, which is completely normal and related to the power supply, I didn't find any problems. Greeting, Torsten

[mstrens]

Note : if the pins defined for Volt and Current are not connected, there can be some "noise" on the pins that could explain the jumps. Do you have also jumps if the pins are connected to Gnd or to 3.3V

[aepub]

hello mstrens. The jumping phenomenon of my voltage and current was observed on the display screen of the remote control! I estimate it is due to the fact that RP2040 is connected to external sensors through many wires, which may cause interference. If integrated into a circuit board, this phenomenon may not exist. I've been quite busy lately, so I'll take the test again when I have time! Thank you!

[Satcomix]

Hello everyone, Now that other issues have been fixed and I haven't received an answer to my question, I can close the post. Best regards, Torsten

[Satcomix]

Hello Mstrens, I have a question about the pin assignment on the oXs_RP2040. Since I work with several Pimoroni Servo2040, and they have always worked very well with FrSky FBUS and 16x PWM_out GPio0-15, SBUS_out, I2C1 and GPS UART Rx/Tx, I have a question??? Can I also assign the PRI=5,9,21,25 differently, e.g. GPIO19? I have already renamed the I2C1 bus to I2C0 and assigned SDA=20, SCL=21. LED GPIO=18. Everything works great. On what basis did you design the GPio pin assignment? Could I use the GPio19 for the PRI=19? I then build the oXs.uf2 builds myself, as always. Best regards, Torsten

[mstrens]

To read the Sbus, the program uses one of the RP2040 internal hardware uart. It is UART1 RP2040 allows to link UART1 to some gpio pins but not all. That is the reason why you can only use pins 5,9,21 or 25 (= UART1 RX).

You can also use SEC (instead PRI) in order to use some other pins too.

[Satcomix]

To read the Sbus, the program uses one of the RP2040 internal hardware uart. It is UART1 RP2040 allows to link UART1 to some gpio pins but not all. That is the reason why you can only use pins 5,9,21 or 25 (= UART1 RX).

You can also use SEC (instead PRI) in order to use some other pins too.

Hello Mstrens, Many thanks for your response. I already thought about the UARTs, so GPio 5,9 UART1for PRI and 13.17 UART0 for SEC What about the GPio=0 is also declared in the RPi specification as UART0. It should also work then, or? Greetings, Torsten

[mstrens]

Gpio 0 is for UART TX. Here we a speaking about UART RX (RP2040 having to read the Sbus signal) So GPIO 1 can be used but not GPIO 0

[Satcomix]

Gpio 0 is for UART TX. Here we a speaking about UART RX (RP2040 having to read the Sbus signal) So GPIO 1 can be used but not GPIO 0

I made a mistake, of course I meant GPio1=UartRX and that is already SEC= Thanks for your answer. br, Torsten

[Satcomix]

To read the Sbus, the program uses one of the RP2040 internal hardware uart. It is UART1 RP2040 allows to link UART1 to some gpio pins but not all. That is the reason why you can only use pins 5,9,21 or 25 (= UART1 RX).

You can also use SEC (instead PRI) in order to use some other pins too.

Hello Mstrens, It is not as easy with the FBUS as with the SBUS. SEC=1 was unsuccessful. I'll just change the config and swap PRI and SEC so I can use GPio1 for FBUS. br, Torsten

[mstrens]

Please note that Fbus does not use an hadware UART. It uses a PIO and so, from a technical point of view it can use all pins. If you want to use another pin (for Fbus), you would have to change (disable) some checks in param.cpp and probably a few line of code in Fbus.cpp.

[Satcomix]

Please note that Fbus does not use an hadware UART. It uses a PIO and so, from a technical point of view it can use all pins. If you want to use another pin (for Fbus), you would have to change (disable) some checks in param.cpp and probably a few line of code in Fbus.cpp.

Hello Mstrens, Just back from work. Your last statement regarding the assignment of the FBUS confuses me a bit. As you said, the SBUS must be placed on an RX UART, e.g. Pri= or SEC=, I was aware of that. But now I thought, since FBUS is nothing else like SBUS(100000baud) with S.PORT(57600baud) together on a line with 460800baud, this function should also be placed on a UART. According to your statement, I can treat the FBUS just like the S.PORT GPio TLM=0 to 29. Then I'll look at the script and compare FBUS and S.PORT so that I can also use all GPio`s. Many thanks for your response. Greeting, Torsten