Skip to content
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

Closed
wolpor opened this issue Apr 25, 2017 · 87 comments
Closed

Comments

@wolpor
Copy link

wolpor commented Apr 25, 2017

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:

  • Smart Port telemtry works on UART3 (on TX3) (using the invert_hack)
  • Microminim OSD works on Softserial UART5 (Tx6/RX6)
  • Vbat
  • LED- Strip

I tried it with the jumper for "normal" and "inverted" (and changed the signal- inverter in CLI) (also changed serialrx_halfduplex to "ON" but...

  • no SBUS

I cleaned the jumpers and soldered the wire to the "original RX1" pin, and tried again... but...

  • no SBUS.

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

  • no SBUS

then I tried to use the "UART3" port for the SBUS and removed the SPORT- telemetry- stuff ... again in all possible variations, but still

  • no SBUS

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

  • but no Sbus

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.

@wolpor wolpor changed the title SBus on Revolt V2 No SBus on Revolt V2 Apr 26, 2017
@beachbreak
Copy link

I am also having same issue

@DrAculaJabroni
Copy link

I am having this issue as well

@JUCAMOFPV
Copy link

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

@wolpor
Copy link
Author

wolpor commented May 2, 2017

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
Copy link

JUCAMOFPV commented May 2, 2017 via email

@kmitchel
Copy link
Contributor

kmitchel commented May 2, 2017

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

@DrAculaJabroni
Copy link

giphy

@wolpor
Copy link
Author

wolpor commented May 3, 2017

@DrAculaJabroni
Copy link

giphy 1

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

@lindi2001
Copy link

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

@ajs14197
Copy link

ajs14197 commented May 4, 2017

Same problem also.

@DrAculaJabroni
Copy link

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
Copy link
Contributor

kmitchel commented May 7, 2017

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
Copy link
Contributor

kmitchel commented May 7, 2017

Bridging rx1 and tx1 on bottom of board works.

@ajs14197
Copy link

ajs14197 commented May 7, 2017

Awesome. Would you mind posting a picture?

@kmitchel
Copy link
Contributor

kmitchel commented May 8, 2017

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

@ajs14197
Copy link

ajs14197 commented May 8, 2017

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

@wolpor
Copy link
Author

wolpor commented May 8, 2017

@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

@wolpor wolpor changed the title No SBus on Revolt V2 No SBus on "revolt V2" [problem confirmed] [work-around-fix in comments] May 8, 2017
@kmitchel
Copy link
Contributor

kmitchel commented May 8, 2017 via email

@mikeller
Copy link
Member

@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
Copy link
Contributor

kmitchel commented May 10, 2017 via email

@mikeller
Copy link
Member

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

@kmitchel
Copy link
Contributor

@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
Copy link
Member

@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
Copy link
Contributor

kmitchel commented May 10, 2017 via email

@mikeller
Copy link
Member

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
Copy link
Contributor

kmitchel commented May 10, 2017

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
Copy link
Member

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.

@Arne-W
Copy link

Arne-W commented Jun 2, 2017

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 think the developers wanted to use only halfduplex and thus only the TX line was considered in layout.

@kmitchel
Copy link
Contributor

kmitchel commented Jun 4, 2017

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.

@braders2k
Copy link

@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

@kmitchel
Copy link
Contributor

@braders2k
Copy link

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?

@kmitchel
Copy link
Contributor

kmitchel commented Jun 14, 2017 via email

@Arne-W
Copy link

Arne-W commented Jun 14, 2017

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.

@kmitchel
Copy link
Contributor

kmitchel commented Jun 14, 2017 via email

@kmitchel
Copy link
Contributor

@Arne-W Compiled both for testing.
OD PU https://drive.google.com/open?id=0B5fFGD7QYC-laWYwdVp0ejZzRVU
PP PU https://drive.google.com/open?id=0B5fFGD7QYC-laVJUNHlfdUtZdGc

I'll try to figure out some kind of test after work.

@Arne-W
Copy link

Arne-W commented Jun 14, 2017

@kmitchel OD - OpenDrain and PP - PushPull??
I very curious about your results - as far as I remember I tried it already and it didn't work, but it was only a very fast hack - so I am not sure if the hack did exactly what I wanted.
However if I find the time I will do some testing too...

@mikeller
Copy link
Member

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.

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.

@rcquad808
Copy link

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.

@kmitchel
Copy link
Contributor

kmitchel commented Jul 5, 2017 via email

@rcquad808
Copy link

@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

@kmitchel
Copy link
Contributor

kmitchel commented Jul 5, 2017 via email

@rcquad808
Copy link

@kmitchel
Okay thank you. I tried the 3.2 but the motor tab doesn't work. I tried the one you gave @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.

@rcquad808
Copy link

Safe travels btw.

@kmitchel
Copy link
Contributor

kmitchel commented Jul 5, 2017 via email

@rcquad808
Copy link

@kmitchel
will do, I appreciate all your help.

@braders2k
Copy link

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!!!

@rcquad808
Copy link

@braders2k

What betaflight firmware you flashed and which pin did you use on the fc?

@braders2k
Copy link

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

@rcquad808
Copy link

That is confusing. Yeah don't know what exaclty the problem with revolt v2.

@ecfarr
Copy link

ecfarr commented Aug 28, 2017

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?

@kmitchel
Copy link
Contributor

kmitchel commented Aug 28, 2017 via email

@ecfarr
Copy link

ecfarr commented Aug 28, 2017

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?

@kmitchel
Copy link
Contributor

kmitchel commented Aug 28, 2017 via email

@ecfarr
Copy link

ecfarr commented Aug 28, 2017

OK thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests