er9x development

[MikeB]

er9x is correct, according to the spec. for the MULTI protocol. ersky9x is displaying the value incorrectly, due to being a 32-bit processor.

Mike.

[kaos]

Hmm, according to Midelic, it should be 2600 + option number for ch frequency. OK, I will ask him at rcgroups.

[flybabo]

If LRS doesn't need the Frsky telemetry, we can "recylce" the RAM used by the telemetry code by disabling the telemetry function when the LRS protocol is selected.

[Leesicin]

Hi Mike,
You just incredible, and all of you! I just ask you to try to include S.Bus to ER9X, and you begining to do this!
No bla, bla ,bla. You Just start to do this. I'm really impresed!
Sorry for so many complement, but I just have no words!!! Thank you all!
Mike, do you need more information?

[MikeB]

I already had code to generate SBUS data in ersky9x, used to provide trainer operation over bluetooth in ersky9x, so I 'only' had to copy that code to the correct place and add an option to be able to select SBUS as a protocol option.
I'll hopefully post a test version of er9x with this in later today.

Mike.

[jhsa]

ABBC3_OFFTOPIC

Mike, could eepe/eepskye receive this sbus signal via a bluetooth adapter or a serial adapter like a FTDI?
Thanks
João

[MikeB]

No, it is at 100000 baud, which is a non-standard baudrate. BT modules and FTDI adapters cannot be set to this baudrate.

Mike.

[jhsa]

Hmmm, ok.. but we do receive sbus from eepskye via FTDI and bluetooth to an arduino, or directly to the radio (ersky9x only).. so it works one way but not the other?

João

[MikeB]

These are not working at 100000 baud, but the SBUS protocol output MUST be at 100000.
If you use 'SBUS' from eepskye, it is running at 57600 baud I think.

Mike.

[MikeB]

I've just posted, on the test versions thread copies, of standard and '2561 er9x, with SBUS available as a protocol output.
I have checked the out on a 'scope, but don't have a module to test they are correct.

Mike.

[jhsa]

These are not working at 100000 baud, but the SBUS protocol output MUST be at 100000.
If you use 'SBUS' from eepskye, it is running at 57600 baud I think.

Mike.

Ahhh,that explains it then.. thanks

João

[Leesicin]

Mike you BEST! Could you, please, drop .hex on er9x.com ? I'll try to test, and ask people to check with osciloscop?

[Leesicin]

I find it Mike, Thanks a lot!!! I shared it on Russian RC forum. Another THANK YOU!!!

[jhsa]

Be careful when flying with it.. It is a test version.. Test it very well on the ground first..

João

[Leesicin]

Of course João! People YOU GREAT!!!

[Leesicin]

Mike hi again,
I flashed my Turnigy 9x (M64, er9xSbus.zip (er9x.hex - this file )) and connect TX module , then I switch SBUS protocol make 10 channels, and switch ON. And nothing happend. So I look what happend via CLI , TX module don't start (CLI whrite "wating module start"). I switch PPM 8CH, and TX module start Transmit (Cli show all Channels and Channels level) and CLI show every thing OK. I played a lot, but coudn't start Transmit via SBUS (with PPM all OK). Could you, please, check the code again?
Thanks in advance!
Leesicin

[MikeB]

Ahhh! 'Proper' Sbus needs to see EVEN parity in each byte, I'm not sending any parity. That could need more RAM!

Mike.

[Leesicin]

Where we can find more RAM? 2561 ?

[MikeB]

New test version posted!
After careful calculation I don't think it will use any more RAM. The amount needed depends on the number of transitions in each byte. Adding even parity cannot increase this number in the worse cases (0x55 and 0xAA).
The RAM will only become a problem for the FrSky version for the M64 and for the M128.
It needs 86 bytes more, but I did save 24 bytes elsewhere, so only 62 more bytes. I'll keep looking for more savings!

Mike.

[flybabo]

Mike, is there any possible situation where both SBUS RF module and FrSky telemetry co-exist?
If not, you may share the RAMs with FrSky telemetry code such as FrskyHubData[] which alone is 76 bytes.
All you need is defining an union structure and disabling the telemetry code when the SBUS protocol is selected.

[MikeB]

That may well be possible. Just need a struct/union to combine the PPM/PXX/MULTI/SBUS pulses array with the telemetry data so the RAM is contiguous.
There may be a knock-on problem as the telemetry display code will still be looking at the same RAM.

Mike.

[Leesicin]

"New test version posted!"
OK Mike, I try this versoin in the evening, and inform you.
Leesicin

[Leesicin]

MIKE! It's works!!! One man test it today, hi say it's work. I"ll test in the ivening!

[Leesicin]

Hi Mike, I have test S.Bus. Transmitter see S.BUS and staring to transmit! Resiver work as nesessry! All Ok. Later I will check with autopilot, and report to you.
And now litile more details , see pictures in link (http://forum.rcdesign.ru/blogs/222828/blog21049.html), if you can understand (my Engish of cours). Program what I use (Baychi soft - this is the same as OpenlrsNG soft, but understand S.BUS) give some dubug information. So, I can see "Maximum time of analysis inputing protocol" - M= 640 mS( some time 580, some time 680, but average 640. with PPM input M=324!), "average cycle time" -A=30-104 (its jumping all time, PPM input A=31 stable). Next "limit (or margin) loading of the input buffer" B=39-182 (some time 39, 52 but some time 180-182), and last "the number of broken packages S.BUS) E=1-17 (some time 1, some time 8, some time 17).
Parameters T-temperature of RFM23BPS and Tc -Thermal compensation (now it's not impotrant).
If you understand some thing, please comment
Catch donation [email protected], drink some beer!
Thanks in advance, Leesicin

[MikeB]

Probably need to look closely at the SBUS signal. We don't have a UART to send this, it is all done in an interrupt that sets the output signal high or low. It may be the interrupt is getting delayed sometimes, causing the SBUS signal to be upset.

Mike.

[flybabo]

Sounds like the better way is to reroute UART0 to SBUS RF since it doesn't need FrSky telemetry

[MikeB]

I'll need a bit of time, but I might be able to check the quality of the SBUS signal. Other transmiters support SBUS as a trainer input, so I can probably use one of them to analyse the signal.

Mike.

[Leesicin]

Hi Mike, One man from Kazakistan (it's near with Russia) take some statistic from Futaba. We some where near!
TX -Fut T10CHG
RX -Fut R6303SB
(6=3)
SBUS mode: T=19 Tc=1 M=476 A=30 B=22 E=10
SBUS mode: T=19 Tc=1 M=548 A=30 B=24 E=10
SBUS mode: T=20 Tc=0 M=548 A=30 B=26 E=10
SBUS mode: T=20 Tc=0 M=548 A=29 B=27 E=10
SBUS mode: T=20 Tc=0 M=548 A=30 B=28 E=10
SBUS mode: T=20 Tc=0 M=548 A=29 B=31 E=10
SBUS mode: T=20 Tc=0 M=548 A=29 B=32 E=10
SBUS mode: T=20 Tc=0 M=548 A=30 B=33 E=10
SBUS mode: T=20 Tc=0 M=548 A=30 B=35 E=10
SBUS mode: T=20 Tc=0 M=548 A=30 B=37 E=10
SBUS mode: T=21 Tc=0 M=548 A=30 B=38 E=10
SBUS mode: T=20 Tc=0 M=548 A=30 B=42 E=10
SBUS mode: T=21 Tc=0 M=548 A=29 B=42 E=10
SBUS mode: T=21 Tc=0 M=584 A=29 B=42 E=10
SBUS mode: T=21 Tc=0 M=588 A=29 B=42 E=10
SBUS mode: T=23 Tc=0 M=588 A=29 B=42 E=10
I understand it's not very helped, but just for inforamation.
Also, how you planing to analize S.BUS signal from other transmitter, without oscilloscop? You have a special program? Give me the link for this program, and I check the signal, and ask people to check it from Futaba.

[MikeB]

The 'other transmitter' will be either a SKY board, 9XR-PRO, Taranis, a 9X with an AR9X board, or a 9X with 9Xtreme. I will need to add some code to check the SBUS signal is OK, and count possible errors. The signal looked OK on my digital storage 'scope.

Mike.

[Leesicin]

Ok Mike! Do your Best!
Leesicin