S.Bus on RevoMini not working

[torn...@gmail.com]

Recently switched from OpenPilot to Taulabs, but I can't get my X9R SBus Receiver working on the Mainport on the RevoMini target with the current master version. I enabled S.Bus for the MainPort, mapped the channels to S.Bus for the Inputs, but it simply does not get any data, the chanel uav objects do  not show any changes at all for stick movement.
Same connection, cable etc. just work fine with the original OpenPilot firmware, so it's not a Hardware problem.

I took a short look through the pios_sbus source code for openpilot and taulabs and I could not really find any real difference except for some checks for the hardware inverter.
If I now take a look at the at the board_hw_Defs.c for the RevoMini it does not set the gpio_clk_periph* anywhere, for the CopterControl and the old Revolution target it is set.
and PIOS_INCLUDE_SBUS is not enabled on the RevoMini.

This looks for me like a bug.

[Carsten Böhme]

I believe he is right. I am a little puzzled because I *think* I had it working once, but I do not remember the circumstances.

[peabody124]

Yeah I just looked into it and you're right. It wasn't enabled for RevoMini

If you are running code from "next" (jenkins.taulabs.org/artifacts) then you can try this firmware https://dl.dropboxusercontent.com/u/6645063/fw_revomini_sbus.tlfw

which should fix the issues (I hope).  If you are running a different version then let me know which and I'll backport the fix for testing.

The PR is here https://github.com/TauLabs/TauLabs/pull/1116

Just in general we seem to be getting some adopters with RevoMini so please bear with us as we make sure catch little issues with that. Since it is closed hardware it hasn't been as actively developed as other targets like Quanton, FlyingF* and Sparky but we'll try and help you guys out :)

[torn...@gmail.com]

Thank you for providing a firmware for me to test, but it does not yet work.
You've enabled the

#define PIOS_INCLUDE_SBUS
but the same file does not include the necessary struct definitions, namely 
pios_usart_cfg pios_usart_sbus_auxsbus_cfg and pios_sbus_cfg pios_sbus_cfg, like for the revolution target at https://github.com/peabody124/TauLabs/blob/sbus_fix/flight/targets/revolution/board-info/board_hw_defs.c line 1150+
I think you have to copy the struct defs too.

Thanks in advance,
Torni

[peabody124]

No, I don't think the name of the structure matters. In revolution it is called auxport because is what the port is called. On RevoMini that port with an inverter was called the MainPort, which is why the configuration is sbus_main etc.

Did you confirm what version of the GCS you are running on? If it is different enough the board might just not be talking to the system properly.

[torn...@gmail.com]

Thank you for looking into the issue, I've used taulabs_next_20140222_021634_233afad32e_win32.

I'm still quite certain that the necessary values are not yet initialized, which is done in that struct I mentioned.
Let me explain:
The sbus code snippet looks like this:

		(*cfg->gpio_clk_func)(cfg->gpio_clk_periph, ENABLE); // not defined for RevoMini

	if (cfg->inv.gpio != NULL)

	{

		GPIO_Init(cfg->inv.gpio, (GPIO_InitTypeDef*)&cfg->inv.init);

...

basically if the functor is zero and the gpio is null the inverter is not enabled. These two values are enabled in the struct I mentioned and are defined in

pios_sbus_cfg in https://github.com/TauLabs/TauLabs/blob/41b3774acb57880b18c50708769009eafc8b3c09/flight/PiOS/inc/pios_sbus_priv.h
This values in the struct are defined [1] for the coptercontrol and the old revolution target. Both have hardware inverters onboard.
Without the definition the hw inverter does not work and the sbus won't work.

[1] https://github.com/TauLabs/TauLabs/search?q=gpio_clk_periph&ref=cmdform

That's why I'm quite certain that it is necessary RevoMini target to define something like this, which is currently missing

.gpio_clk_func = RCC_AHB1PeriphClockCmd,

.gpio_clk_periph = RCC_AHB1Periph_GPIOB,

Thanks again,
Torni

[peabody124]

Gotcha. My recollection was that we actually enable all the peripherals but just in case I tried adding that to the PR.  Here is another firmware to test too 

https://dl.dropboxusercontent.com/u/6645063/fw_revomini_sbus.tlfw

[torn...@gmail.com]

Thank you for your new firmware, it still does not work, but I still think your firmware is correct now:
1. The hw_def now looks like the openpilot one, I compared it manually
2. The Taranis does not tell me "Telemetry lost" every few seconds.

Unfortunately Taulabs still does not react on the stick movements. Looks like a bug on my side somewhere, maybe I can find someone who has a Taranis to try that firmware too. Or I need to setup the development system and debug it.

Thanks again for your help

[Carsten Böhme]

Tried https://dl.dropboxusercontent.com/u/6645063/fw_revomini_sbus.tlfw with GCS taulabs_next_20140222_021634_233afad32e_win32 without success. I set receiver port to disabled and main port to SBUS, but ManualControlCommand/Connected stays FALSE. Same procedure works with OP 14.01. Taranis and X8R.

[peabody124]

Can you try SBus on Quanton. Try and confirm the SBus code hasn't picked up a bug.

[Carsten Böhme]

SBus is working fine on Quanton with taulabs_next_20140207_140643_bd27ba6ff5

[torn...@gmail.com]

In the PR i saw another sbus related fix, something about an end byte for frame checks. Maybe it is this one.
@James: could you please build a Fw without commit a270d033971bcc2e9e575fb797d704161444fa8e?

[peabody124]

Thanks Carsten. 

torn - done https://dl.dropboxusercontent.com/u/6645063/fw_revomini_sbus2.tlfw

[peabody124]

Also check this version https://dl.dropboxusercontent.com/u/6645063/fw_revomini_sbus.tlfw - I think the remap was missing

[torn...@gmail.com]

Thank you for building both firmwares, unfortunately I still don't get any receiver activity with both firmwares, neither the sbus2, nor the remap firmware.

[peabody124]

Any recommendations on a cheap PPM to SBus module? I might need to look into this myself then.  I'll try and look more closely at the code this weekend though.

[Carsten Böhme]

You are using Spektrum, right? Maybe this is more useful than a ppm to sbus encoder: http://www.hobbyking.com/hobbyking/store/__20684__OrangeRx_R710_Spektrum_DSM2_Compatible_7Ch_w_Failsafe_.html

(just a google result, I have no experience with Spektrum)