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
No SBus on "revolt V2" [problem confirmed] [work-around-fix in comments] #2953
Comments
I am also having same issue |
I am having this issue as well |
Has anyone tried setting up an XM+ with the V2? I am hearing that the issue might be with the XSR only. |
I just checked with an X4R-SB and it doesn't work either... anyway, I don't think there is a difference between Sbus on an XSR and Sbus on an X4R-SB |
Agreed... tried it and also tried an XM+ and still nothing. Maybe in the next release I guess.
Went back to RF1 and everything works as expected.
Sucks as I really wanted try it on a 6" build and the fact that some people have it working with no issue bugs me.
…Sent from my iPhone
On May 2, 2017, at 7:13 AM, wolpor <notifications@github.com<mailto:notifications@github.com>> wrote:
I just checked with an X4R-SB and it doesn't work either... anyway, I don't think there is a difference between Sbus on an XSR and Sbus on an X4R-SB
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#2953 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/Aa990c2nAheUt2ZWyowKpulTcFmz864cks5r1zoDgaJpZM4NH7uM>.
|
I am having this issue as well with x4r-sb. I have worked around it by using uninverted sbus hack with rx3. |
I am also having same troubles with Revolt Sbus and Betaflight :(( PLS HELP |
Same problem also. |
I believe that we may be lowest in priority as far as beta builders are concerned since we have revolts...my back motors be getting warm with rf1, I dont take a likin' to that. I be flyin me two kissed copters in stead, but thats not the best eh? |
I'm wondering--as a workaround--jumper rx1 and tx1 on the bottom of the FC, then use the hardware inverter on the normal tx1 pad. Serial half duplex would not be used then, and BF should just ignore tx1 like normal. I can test, but I would have to tear down quad, maybe someone can test quicker. |
Bridging rx1 and tx1 on bottom of board works. |
Awesome. Would you mind posting a picture? |
Thanks. Easy enough. Finally get to try this board out. |
@kmitchel bro... thx a lot!!! (if you are ever in Austria or close by... drinks are on me) Bridging the RX1/ TX1 works!!! (and bridging the solderpads for "inverted") I confirmed with 3 different "revolt v2" flight controler!!! |
Kind of makes it look like serialrx half duplex isn't really doing anything.
…On May 8, 2017 4:57 AM, "wolpor" ***@***.***> wrote:
@kmitchel <https://github.com/kmitchel> bro... thx a lot!!! (if you are
ever in Austria or close by... drinks are on me)
Bridging the RX1/ TX1 works!!! (and bridging the solderpads for "inverted")
It works with serialrx_halfduplex set "ON" and "OFF"
I confirmed with 3 different "revolt v2" flight controler!!!
"thumbs up" for @kmitchel <https://github.com/kmitchel>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2953 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB8ZYLaRL7a85fAkaYe7zebnx1ofw65Lks5r3tjlgaJpZM4NH7uM>
.
|
@kmitchel: On another note, bridging RX and TX pins is most likely overkill, since SBus uses unidirectional communication (RX -> FC) only. I'd separate them, and test which one needs to be connected to the RX. |
@mikeller The revolt V2 provides a bidirectional hardware inverter on tx1, raceflight
guys do not breakout rx1. So bridging the test pads let's rx1 use tx1s
inverter. Half duplex is not working for some reason, I have tried very hard. It's not a hardware config problem, raceflight is able to autodetect and use a x4r-sb on the inverted tx1 pad. Previously I've had to do the hack on the receiver, others either do not know, or are not comfortable with that solution.
|
Ah, if the bridging is happening on the MCU side of the inverter then that makes sense. |
@mikeller is there anything I can do to help troubleshoot serialrx_halfduplex? Also there is a second hardware inverter on tx4, which is not enabled in the target, any chance of getting it enabled? |
@kmitchel: Thanks for offering. Short of getting access to a schematic of the REVOLT, and finding an explanation as to why bridging is required, there is not much to troubleshoot. All that the Betaflight now supports multiple switchable inverters (but didn't when the REVOLT target was added), so enabling this inverter is just a matter of figuring out which MCU pin is used to enable it, and adding a definition for that pin and UART4 to the target. The target currently contains Do you know if the inverter on UART4 is supposed to be switchable by the MCU / firmware? If so, one test would be to check if PC0 is controlling the UART4 inverter, by toggling inversion for UART1 in the firmware, and checking if this causes a change in the behaviour of UART4. |
There are pads to enable inversion on the board...I don't believe they are
switchable. I'll try to look at the traces.
Edit: Their not bidirectional inverters, just fets.
…On May 9, 2017 9:48 PM, "Michael Keller" ***@***.***> wrote:
@kmitchel <https://github.com/kmitchel>: Thanks for offering. Short of
getting access to a schematic of the REVOLT, and finding an explanation as
to why bridging is required, there is not much to troubleshoot. All that
the serialrx_halfduplex setting does is configure the MCU to use the TX
pin instead of the RX pin for receiving, so it's kind of obvious that this
setting has no effect if the pins are bridged.
Betaflight now supports multiple switchable inverters (but didn't when the
REVOLT target was added), so enabling this inverter is just a matter of
figuring out which MCU pin is used to enable it, and adding a definition
for that pin and UART4 to the target.
The target currently contains #define INVERTER_PIN_USART1 PC0. From the
previous discussion it sounds like the inverter on USART1 isn't actually
controllable by the MCU, so it stands to reason that this define might be
bogus.
Do you know if the inverter on UART4 is supposed to be switchable by the
MCU / firmware? If so, one test would be to check if PC0 is controlling the
UART4 inverter, by toggling inversion for UART1 in the firmware, and
checking if this causes a change in the behaviour of UART4.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2953 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB8ZYGRD0B8CvrKbj6BPCK6mWqkDH-XCks5r4RdXgaJpZM4NH7uM>
.
|
If the inverter on UART4 is switchable by a solder pad, then there is no need to have it defined in the firmware, since it won't be soft switchable. Just use the pad to enable / disable it. |
UART4 is enabled at all in the target, 1,3,6 are. I thought it would be nice for sport, but it is not bidirectional. edit: cli accepted resource SERIAL_TX 4 A00, uart 4 doesn't show up in ports, it it really active? |
You could always use UART1 for SmartPort, and 4 for SBus. Not sure if the current serial code allows for addition of ports that are not defined as part of the target, I think it just allows remapping of defined ports. Are you set up to build the firmware? If so, try adding
to |
Just don't know. But AFAIK the revolt ist wired like this. The RX line ends on the testpad and the SBUS port is the TX line - I don't know the reason for that. |
I was able to test and disprove my theory on MODE_RXTX. serialrx_halfduplex works correctly with an noninverted sbus signal from an xsr connected to tx1 on a flip32 f4. So that leaves hardware, internal pull-up needs turned off/on as @Arne-W pointed out. Maybe there is a hardware difference between the sbus outputs of the xsr and x4r-sb. I no longer have a working Revolt, so I can't really contribute. I'm not planning on buying another, but i will miss it. |
@kmitchel Do you have the build file for revolt with uart4 enabled? My uart1 pads have come off the board.. I see you did a build and it worked? 3.1.7 I see 3.2 supports it but happy with 3.1.7 for now until it's finalised Thanks |
@braders2k Try https://drive.google.com/open?id=0B5fFGD7QYC-lQzc2QkVSMS1HbUk Let me know. |
That's great, thanks.. flashed and can now see uart4.. I will bridge tomoz and let you know how I get on! Will it be safe? |
I would believe you should find no difference...good luck.
On Jun 13, 2017 8:01 PM, "braders2k" <notifications@github.com> wrote:
That's great, thanks.. flashed and can now see uart4.. I will bridge tomoz
and let you know how I get on! Will it be safe?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2953 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB8ZYDL_Kj20f-1dZoZT6HYT4Q1Mspw8ks5sDyK9gaJpZM4NH7uM>
.
|
I found something in the raceflight slack channel that could explain why it could be possible that there is no other way than bridging those rx and tx pads to make the SBUS work with betaflight. |
I often wondered if they might be doing soft serial, but then the hardware
inverter shouldn't be needed. Or unless they're doing something stupid to
be annoying and help prevent the revolt from being used with other software.
@Arne-W please see src/main/drivers/io.h and src/main/drivers/serial_uart_stm32f4xx.c line ~324. Looks to me like bidirectional sets port to open drain. So push pull/ pull up, or define a new open drain/ pull up?
On Jun 14, 2017 4:37 AM, "Arne Wischmann" <notifications@github.com> wrote:
I found something in the raceflight slack channel that could explain why it
could be possible that there is no other way than bridging those rx and tx
pads to make the SBUS work with betaflight.
It seems that the raceflight Software does not rely on the Hardware uarts:
"We have the technology to be able to use any pin for any function we don't
even use them as serial ports. So any pin that has a free dma, Irq etc we
can use. So we aren't limited by inversion issues or amount of users Uarts."
I don't know what they are doing - but it could be possible that they are
NOT using the HW Uart.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2953 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB8ZYMHL8HSHG3RU06QoMn00jsUegwZmks5sD5vAgaJpZM4NH7uM>
.
|
@Arne-W Compiled both for testing. I'll try to figure out some kind of test after work. |
@kmitchel OD - OpenDrain and PP - PushPull?? |
That sounds like a very RaceFlight-y statement. Doing someting time critical and high throughput like serial RX in software, if you've got perfectly good hardware capable of doing it on board doesn't sound like good engineering to me. |
Need Help. Tx1 & Rx1 pads came off. I'm using UART4 (bridged TX4 & RX4). Everything works ok after setup on Betaflight, but when i plug in the battery the fc doesn't initialize the ESCs. It only initialize the Escs with the usb is plugged in at the same time. I was wondering if UART4 is stealing the power form the USB port. Any help is greatly appreciated. |
For $25 they will send you another. Should have mine this week.
…On Jul 5, 2017 3:10 PM, "rcquad808" ***@***.***> wrote:
Need Help. Tx1 & Rx1 pads came off. I'm using UART4 (bridged TX4 & RX4).
Everything works ok after setup on Betaflight, but when i plug in the
battery the fc doesn't initialize the ESCs. It only initialize the Escs
with the usb is plugged in at the same time. I was wondering if UART4 is
stealing the power form the USB port. Any help is greatly appreciated.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2953 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB8ZYKRfq-ivA5WJLoxjFpchaUnMCsmVks5sK9-OgaJpZM4NH7uM>
.
|
@kmitchel OD PU https://drive.google.com/open?id=0B5fFGD7QYC-laWYwdVp0ejZzRVU |
No. It's an attempt to enable the internal pull-up for uart1, so serialhalf
duplex will work right. Until I have new board I can't test. Uart4 is in
3.2. I might have posted a 3.1.7 further up the thread. Traveling so it's
hard to check at the moment.
…On Jul 5, 2017 3:31 PM, "rcquad808" ***@***.***> wrote:
@kmitchel <https://github.com/kmitchel>
I was hoping to use the board since my other V2 board works with TX1 & RX1
bridged and the ESCs does initialize. These 2 files you post are they for
test the UART4?
OD PU https://drive.google.com/open?id=0B5fFGD7QYC-laWYwdVp0ejZzRVU
PP PU https://drive.google.com/open?id=0B5fFGD7QYC-laVJUNHlfdUtZdGc
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2953 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB8ZYB9ASaXLYXqJKf6Bi-clWXF3h_fjks5sK-R0gaJpZM4NH7uM>
.
|
@kmitchel |
Safe travels btw. |
Be sure to use the configurator off of git hub ...no the app store with 3.2
On Jul 5, 2017 5:41 PM, "rcquad808" <notifications@github.com> wrote:
@kmitchel <https://github.com/kmitchel>
Okay thank you. I tried the 3.2 but the motor tab doesn't work. I tried the
one you gave @braders2k <https://github.com/braders2k> Try
https://drive.google.com/open?id=0B5fFGD7QYC-lQzc2QkVSMS1HbUk and the motor
tab works. Now just got to figure out how to get the esc to initialize
using UART4.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2953 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB8ZYGpdOjhgDeWVErDeJnk4pW4brmifks5sLAMFgaJpZM4NH7uM>
.
|
@kmitchel |
So.. I'm getting confused.. I setup 2 friends quads with revolt (V2) and XM+.. run the duplex command and works fine.. without having to bridge tx & Rx together?????? But if I try desolder the Rx/tx on my quad it don't work??? Makes no sense and wondering what the bells going on lol.. I'm getting not as smooth RC command when checking BB logs.. thinking maybe something to do with this fix? Just confusing why it works for others!!! |
What betaflight firmware you flashed and which pin did you use on the fc? |
@rcquad808 Using revolt V2 (skitzo) bf 3.1.7 with xm+.. exactly same as what I put on my friends quads but didn't need to solder the tx/Rx pads what is confusing? |
That is confusing. Yeah don't know what exaclty the problem with revolt v2. |
Hey guys, I am trying to get my revolt v2 to work with betaflight 3.2 and smartaudio and telemetry. Will this work? |
You need to get the uninverted smart port signal off of receiver. See
Jason Blackman's tutorial.
…On Aug 27, 2017 8:41 PM, "ecfarr" ***@***.***> wrote:
Hey guys, I am trying to get my revolt v2 to work with betaflight 3.2 and
smartaudio and telemetry.
From what I have gathered from this thread is this what I need to do?
sbus: bridge rx1, tx1 and invert tx1
SMARTPORT: solder smartport wire to tx3 pin
smartaudio: solder smartaudio wire from vtx to the tiny tx6 pad
Will this work?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2953 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB8ZYC6_lyBp1kdB3GgGBU14ROiofBvNks5scgyfgaJpZM4NH7uM>
.
|
OK I will do that. I will still need to bridge tx1 and rx1 pads to get the fc to receive communication from my revolt correct? |
Try it the 'right way' following the wiki, then bridge if it doesn't work.
…On Aug 27, 2017 9:10 PM, "ecfarr" ***@***.***> wrote:
OK I will do that. I will still need to bridge tx1 and rx1 pads to get the
fc to receive communication from my revolt correct?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2953 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB8ZYGL1a-dvBlyiVRa6WpDj9bhEmiU3ks5schODgaJpZM4NH7uM>
.
|
OK thanks. |
Hi guys, there might be an Issue with SBUS on the Revolt V2 with FrSky XSR.
I flashed Betaflight 3.1.7 on my Revolt V2 and I tried to get SBUS bus going.
I followed the instructions from
https://github.com/betafli…/betaflig...EVOLT-(V1-&-V2)
but SBUS doesn't work. (SBUS on TX1 with set serialrx_halfduplex=ON)
The weired thing is though I got all the other stuff to work:
I tried it with the jumper for "normal" and "inverted" (and changed the signal- inverter in CLI) (also changed serialrx_halfduplex to "ON" but...
I cleaned the jumpers and soldered the wire to the "original RX1" pin, and tried again... but...
In both cases I tried it with serialrx_halfduplex "on" and "of" and sbus_inversion (might only work on F3) "on" and "off" in all 4 Situations...
then I tried to use the "UART3" port for the SBUS and removed the SPORT- telemetry- stuff ... again in all possible variations, but still
I rouled out hardware issues for the cables, the XSR and the FC (it does work with Raceflight)
I went back and tried it again with the Version 3.1.6 and left out all the fanzy stuff (Sport telemetry, Softserial and so on).
I would be more than greatful for an answer... I added the "CLI dump" as a *.txt file (maybe it's my bad after all)
dump_317.txt
I postet the problem a view days ago in the facebook- group and also in the rcgroup- thread and could only find people with the same problem (not one who got it going).
Also, I am able to recreate the Problem with 3 different flightcontrolers (2x Skitzo version) and know personally a view pilots who failed at the same attempt.
The text was updated successfully, but these errors were encountered: