search

betaflight / betaflight

Open Source Flight Controller Firmware
GNU General Public License v3.0
8.06k stars 2.87k forks source link

No SBus on "revolt V2" [problem confirmed] [work-around-fix in comments] #2953

Closed wolpor closed 6 years ago

wolpor commented 7 years ago

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.

beachbreak commented 7 years ago

I am also having same issue

DrAculaJabroni commented 7 years ago

I am having this issue as well

JUCAMOFPV commented 7 years ago

Has anyone tried setting up an XM+ with the V2? I am hearing that the issue might be with the XSR only.

wolpor commented 7 years ago

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

JUCAMOFPV commented 7 years ago

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 GitHubhttps://github.com/betaflight/betaflight/issues/2953#issuecomment-298647656, or mute the threadhttps://github.com/notifications/unsubscribe-auth/Aa990c2nAheUt2ZWyowKpulTcFmz864cks5r1zoDgaJpZM4NH7uM.

kmitchel commented 7 years ago

I am having this issue as well with x4r-sb. I have worked around it by using uninverted sbus hack with rx3.

DrAculaJabroni commented 7 years ago

giphy

wolpor commented 7 years ago

http://eleccelerator.com/wp-content/uploads/2014/10/instructions.jpg

DrAculaJabroni commented 7 years ago

giphy 1

also, i gots xsr. was hoping it was a easy cli or quick solder jib...that looks gross

lindi2001 commented 7 years ago

I am also having same troubles with Revolt Sbus and Betaflight :(( PLS HELP

ajs14197 commented 7 years ago

Same problem also.

DrAculaJabroni commented 7 years ago

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?

kmitchel commented 7 years ago

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.

kmitchel commented 7 years ago

Bridging rx1 and tx1 on bottom of board works.

ajs14197 commented 7 years ago

Awesome. Would you mind posting a picture?

kmitchel commented 7 years ago

https://drive.google.com/open?id=0B5fFGD7QYC-lVFBkT0dLV3Y2ekZId0RWTFV2ci1FWVNFNTlJ

ajs14197 commented 7 years ago

Thanks. Easy enough. Finally get to try this board out.

wolpor commented 7 years ago

@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

kmitchel commented 7 years ago

Kind of makes it look like serialrx half duplex isn't really doing anything.

On May 8, 2017 4:57 AM, "wolpor" notifications@github.com 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 https://github.com/betaflight/betaflight/issues/2953#issuecomment-299811333, or mute the thread https://github.com/notifications/unsubscribe-auth/AB8ZYLaRL7a85fAkaYe7zebnx1ofw65Lks5r3tjlgaJpZM4NH7uM .

mikeller commented 7 years ago

@kmitchel: serialrx_halfduplex = on changes the pin that the UART is receiving data on from RX to TX (on MCUs that support this). If you have bridged the RX and TX pins, this will obviously not make a difference.

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.

kmitchel commented 7 years ago

@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.

mikeller commented 7 years ago

Ah, if the bridging is happening on the MCU side of the inverter then that makes sense.

kmitchel commented 7 years ago

@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?

mikeller commented 7 years ago

@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.

kmitchel commented 7 years ago

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" notifications@github.com 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 https://github.com/betaflight/betaflight/issues/2953#issuecomment-300350571, or mute the thread https://github.com/notifications/unsubscribe-auth/AB8ZYGRD0B8CvrKbj6BPCK6mWqkDH-XCks5r4RdXgaJpZM4NH7uM .

mikeller commented 7 years ago

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.

kmitchel commented 7 years ago

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?

mikeller commented 7 years ago

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 

#define USE_UART4
#define UART4_RX_PIN            NONE
#define UART4_TX_PIN            PA0

to src/main/target/REVO/target.h and doing a make REVOLT.

kmitchel commented 7 years ago

I will try it out. Ty.

On May 9, 2017 10:24 PM, "Michael Keller" notifications@github.com wrote:

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

define USE_UART4

define UART4_RX_PIN NONE

define UART4_TX_PIN PA0

to src/main/target/REVO/target.h and doing a make REVOLT.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/betaflight/betaflight/issues/2953#issuecomment-300355200, or mute the thread https://github.com/notifications/unsubscribe-auth/AB8ZYKBJtL-0khLHu_JW0tvb6AQg1Tfuks5r4R9OgaJpZM4NH7uM .

kmitchel commented 7 years ago

@mikeller I added

define USE_UART4

define UART4_RX_PIN PA1

define UART4_TX_PIN PA0

Bridged tx4 and rx4 test pads, bridged tx4 inv pads, and sbus works! Going to try the half duplex stuff with uart4 just in case. Can this be added to the target?

mikeller commented 7 years ago

Sure can! Getting an additional UART is always an improvement! Do you want to create a pull request for this?

kmitchel commented 7 years ago

I suck at Git. Probably better someone who knows what they are doing should take care of it.

Removing tx4/rx4 bridge, setting serialrx_halfduplex=on, and no sbus. Resolder bridge with halfduplex on and sbus works. If half duplex is working, uart rx shouldn't be listening right?

mikeller commented 7 years ago

Yes. I am a bit puzzled as to where these bridges are on the board schematic. But if we've identified a config that works for serial RX then that's already an improvement that's well worth adding.

You could always use this as an opportunity to get better at git. It's simple enough, and I'm happy to help. ;-)

Just create a fork of the betaflight repo in the web UI (if you haven't done so already), then create a branch for your change, apply the changes, commit, push. Then back to the web UI, find your branch, 'Create pull request', select betaflight / master, 'Create', and you're done.

turbosi92 commented 7 years ago

I've been using the revolt V2 for a while and for the life of me can't find where the 3rd UART is (Betaflight shows it as UART 6 in ports tab). where is this port located? I have telemetry working and SBUS using the wiki steps but I can't get smart audio to work because I can't find the 3rd UART. I see in the original post Microminim OSD works on Softserial UART5 (Tx6/RX6)

Where are the TX6/RX6 pads located? Also, UART 5? I show UART 1, 3, and 6 in BF ports tab.

Thanks

kmitchel commented 7 years ago

@turbosi92 Uart6 pads are on the bottom of the board near BEC5v and GND pads. They are tiny, but its not too hard to solder. Dont confuse them with CH5 and CH6, like I did on my first try.

turbosi92 commented 7 years ago

OMG i see them. TX6/RX6. all i need is TX6 for smartaudio....unfortunately, will be a nightmare to get mine apart...lol. THanks!

kmitchel commented 7 years ago

@mikeller I think I did it.

kmitchel commented 7 years ago

I think I found a problem. According to http://www.hanese.nl/STM32/stm32f4stdlibrary/html/group___u_s_a_r_t___group5.html#gaaa23b05fe0e1896bad90da7f82750831 proper order is usart_cmd, the usart _halfduplexcmd. src/main/drivers/serial_uart.c line 95 has them flipped. Will try to test after work.

edit: Test failed.

Drilon01 commented 7 years ago

greta guys thank you now my sbus works with tx/rx 1 bridget. i would love to use tx/rx 4.

mikeller commented 7 years ago

@Drilon01: You can get the latest build from http://andwho.sytes.net:8080/job/BorisB_BetaFlight/lastSuccessfulBuild/artifact/obj/ . Support for UART4 on REVOLT is in there.

(Please report back if you find problems, we appreciate the feedback.)

Drilon01 commented 7 years ago

ok thank you, is this the same as this one in rcgroups?

Link: https://www.rcgroups.com/forums/showthread.php?2464844-Betaflight-Flight-Controller-Firmware-Discussion-Thread/page3003

Because i tried this and it was very bad my motors had really bad oscillations then i flashed it back to 3.1.7 and bridget the rx/tx 1 like you mentioned and everything worked.

and with yours do i have to bridge rx/tx for inverted sbus or does it work right away?

Thank you for your time and i definatelly will report back if i find any problems

mikeller commented 7 years ago

No, 'this one' is based on the latest build on master (i.e. what will be 3.2.), whereas the RCGroups post is a couple of months old.

(Side note: The URL I gave you always points to the latest successful build of Betaflight, so there will be new and exciting stuff to be found there almost every day. Just what you want to do if you're living on the edge. ;-))

For what I know (I don't own a revolt, the PR is @kmitchel's), RX / TX have to be bridged, and the inverter enable has to be bridged as well.

Drilon01 commented 7 years ago

ok i tried the 3.2.0 and i had very bad iscillations (again) i tried uart 4 and uart 1 and both same problem now i went back to 3.1.7 and everything is normal again. the oscillations occur on the bench with no props. My FC is mounted upsidedown so i switch motors in CLI then i reflashed with 3.2 and tried without switching motors and no oscillations occured. but i need to switch motors what can i do? Or does it switch motors automatically when i change gyro alignment?

Edit: it was my mistake in GYRO Alignment you have to select CW 180 flip ( i selected CW 180 without FLIP) now everything works thx guys

kmitchel commented 7 years ago

@Drilon01 Be sure to do a DIFF and save your working config to a text file. Makes testing different firmware a breeze, and still have a flyable quad whenn your done.

I've gone back and tried the revoltv2_rx branch, and sbus doesn't work (unless I bridge the pads). I've been working with the assumption that the original patch worked, and sometime later it was broken. I'm doubting it ever worked at all. Has anyone verified a XM+ working? Everything works as intended with RaceFlightOne. It would be great if someone could test serialrx_halfduplex on another F4.

buzzsaw66 commented 7 years ago

Hey guys, I'm new to this so bare with me. I read over the thread and see what I think is the fix for SBUS not working with the Revolt V2. I tried bridging rx1 and tx1 on bottom of board (using the picture provided by kmitchel) and still no SBUS. I wasn't sure in the ports tab what to selected..tried serial Rx on all the 3 ports UARTS...No SBUS. Any ideas??? Thanks in advance!

mikeller commented 7 years ago

@buzzsaw66: Apparently there are solderpads for UART1 inversion as well, and these have to be bridged as well for SBus to work.

wolpor commented 7 years ago

@mikeller I tried the new 3.2 batch... (1272)

UART4 is appears now in the configurator, but

The "Vbat" thing is kind of a "downer" wich raises the question: "Do Vbat and UART4 exclude each other, or is Vbat just not working in the "3.2" yet?

mikeller commented 7 years ago

@wolpor:

I could not get the "inverter" to work on UART4 (worked around it)

The inverters on the REVOLT seem to be activated by closing solder pads - no way the firmware can break / fix this.

VBat is not working now... (using onboard Vbat)

Are you sure it's not just VBat display in the configurator not working? You'll have to run the latest configurator from GitHub to get the battery tab to work with 3.2.

kmitchel commented 7 years ago

@mikeller Thanks for vbat info. Are the development versions of the configurator always backwards compatible, or is it best to run both production and development versions?

@wolpor For TX4 the tx4 and rx4 pads need to be bridged on the bottom as well. It seems that the inverters are unidirectional input, and connected to tx which is out bound. Need to test to get a better understanding of how they work. Really limits the usefulness of the hardware inverters, but there are 4 uarts if you don't mind the tiny pads.

mikeller commented 7 years ago

@kmitchel: They are backwards compatible most of the time. At the moment the GitHub version breaks battery support on older firmware versions, which is the reason it has not been updated in the Chrome web store.