T8SGV2+ E015 protocol cannot bind to Eachine E015

[Tygrys-1]

I set the E015 protocol on Jumper V2 plus, mapped channels for arming and other stuff and tried to bind with the new E015 with no success. I tried "Re-Init" and switching off-on the transmiter with no effect. E015 copter is working ok with it's original transmitter.

What am I missing?

[goebish]

This is a known issue with HS6200 emulation (E012, E015) in current nightly builds. It might be fixed in further 5.x releases.

[Tygrys-1]

Wow. New releases ! :-)

Thank you, goebish. I thought it was me or Eachine made some changes. AFAIK it was working before, at least on YT there are some films with the Jumper and E015.

[goebish]

you can try this build from last november, I think it works but obviously it's lacking new stuffs ... https://www.dropbox.com/s/zjed8eyt245gpfx/deviation-t8sg_v2_plus-v5.0.0-f5ae311.zip?dl=1

[Tygrys-1]

I'll give it a try. Is there a chance to merge this into the current nightly?

[goebish]

The protocol is the same in the nightly, but there's something else that prevents it from working (timing ?). HS6200 emulation is tricky, I wasn't able to get it working properly on Multi Module either.

[Tygrys-1]

Strange, as it was once working and now do not. Well, thank you for trying. Is E016H also affected?

[goebish]

No, the E016H is using a xn297l compatible transceiver, only the E012 & E015 protocols have this problem.

[Tygrys-1]

Thank you for the explanation. I hope this can be solved somehow in the future.

[Tygrys-1]

Just checked the multiprotocol module with Taranis X9 lite. It binds to E015 and some functions do work. However it is not useable because of arming/throttle not working as expected.

[pascallanger]

Can you elaborate on what's not working correctly with the multi module? I'm thinking it's the same problem as deviation with the emulation layer meaning that it's randomely working (lag, slow response...) or something else?

[Tygrys-1]

Hi Pascal, great job on the multiprotocol module.

So: I can bind E015 I can switch LED ON/OFF. I can switch Headles mode on/off (led blink). If I can manage to get it into the air the roll/pitch/yaw works ok. But: I switch the ARM channel and nothing happens. Throttle up does not spin the motors. I can do some stick magic like stick arming or random movements and sometimes (I do not know when and why) I get motors to spin - and sometimes they are spinning slow on the whole throttle range, and on rare cases they work as expected and the quad seems to fly well for a while. At least I tried basic movements and managed to find the right channel inversions on Yaw an Ailronn, but since then I cannot repeat the succesfull launch.

Or maybe I do not undertand how it should work? I hoped for arm, throttle up and away she goes! ;-) There is no "Option" choice for this protocol on OpenTx 2.3 radio setup.

With Deviation I cannot even bind. I may do some investigation if you direct me.

[pascallanger]

I'm not sure anyone ever tested it so let me review the code. Pascal

[goebish]

I tested it with the same result (rx can demodulate only a small percentage of the packets), I've spent quite some time on it already but iirc I can't do anything better.

[pascallanger]

Ok... Strange that he can do almost everything except arming. I've checked quickly the code and arming seems to be the same as deviation...

[goebish]

Maybe arm command works only if throttle stick is strictly at center position (this is an auto alt hold quad). But that's not a problem since there's a stick combination for arming as well.

[goebish]

I'll give it another attempt tonight or during the week-end, but I don't expect anything ...

[pascallanger]

I can easily add a deadband on the throttle channel. The centered value is 112, correct? It's so strange to have a 0..225 range.

[Tygrys-1]

E015 is acting strange with arming. On the original controller there is a launch button, which starts the motors and punches up about 1m and then hoover. If you do the stick arming, motors starts to spin and with throttle in the middle they also spin at idle. Moving the stick up punches the copter up and then you have controll. Further tests suspended as I have one motor with degraded performance and cannot achive a stable flight. The car option works ok.

To initiate the car option you have to: 1) switch on the transmitter. 2) move throttle stick up with the copter level. 3a) move throttle stick down with the copter standing on the nose. 3b) if you move throttle stick down with the copter at level position, it will start at flying mode.

Steering in the car option: Throttle works at the upper half of the range, it is 0 in the middle, down movement does nothing. Elavator does not work. Rudder does not work. Function buttons does not work. Aeilron stick turns left-right, acting as normal roll action.

[goebish]

I made some tests (with Multi module), arm channel is working fine (throttle needs to be > -100) but the quad is uncontrollable because of the latency due to missed packets ... Since this protocol is using nrf24l01 @ 1Mbps there's not much we can do. This is probably a problem with center frequency (which is not tunable on nrf24l01), I made a software defined radio E012 TX some time ago (same transceiver as E015) and it's working perfectly, without longer preamble or double packet trick: https://github.com/goebish/E012-SDR-transmitter

[Tygrys-1]

Can this protocol be emulated by CC2500? It was done for E010 AFAIK.

[Tygrys-1]

I made some tests (with Multi module), arm channel is working fine (throttle needs to be > -100) but the quad is uncontrollable because of the latency due to missed packets ...

Got arming to work - THR>-100 did the trick. But just after arming the copter tries to fly up on high throttle and the throttle stick movement does nothing in this state. I think it is trying to fly just as the "Launch button" on the originall controller was pressed and reach about 1m hoover, but due to the failed motor it just bump the ground.

On Deviation it cannot bind, so there must be something different in implementation.

[goebish]

It cannot be emulated with the cc2500 because its max bitrate is 500kbps while this protocol requires 1Mbps. (E010 = 250kbps) A difference in crystal accuracy can explain that it works somehow with a radio and not another one. The implementation is the same, this is a very simple protocol, without frequency hopping.

[goebish]

I even tried to use the cyrf6936 to emulate this HS6200 transceiver, but that didn't work: https://www.deviationtx.com/forum/protocol-development/7150-eachine-e012?screenMode=desktop&start=40#63021

[jay88hh]

Guys after I tried to bind my jumper multi to e015, my quad is only flipping with the original remote when pressing the take off button, or arming and then trying to take off. Can this be a result of the binding try?

[goebish]

No, that can't be related.

[jay88hh]

Thanks! Amazing fast reply! :)

[goebish]

I'd try to recalibrate the accelerometer first (sticks in outer or inner bottom borders ?). Or maybe that's just a bad motor or mosfet ...

[jay88hh]

I tried to recalibrate but I found no way to do it. Outer bottom does arm, the other combinations are not doing anything visible.4

[Tygrys-1]

The calibration is done by both sticks to the bottom right, it then beep or flash - I do not remember exactly. After a few seconds it returns to the normal mode. The manual page 5, par. 6.1.3.C.

I had the same flipping problem. Had to ask BG for replacement. I tried changing the motor and swaping the motors - with no effect. So maybe ESC? However in boat/car mode everything is working ok, all motors spin with full strength. So maybe calibration? But recalibration also had not worked.

It looks like the quad has it's own idea of "beeing level". I can equalize the motor speed by holding it by hand and turning forward and roll to the right. This is however possible only for a few seconds, because the start button logic requires the quad to gain >1m of height after startup and if this is not achived in a few seconds then motors are turned off.

I think, that it might be the software issue, or the hardware Accelerometer fault on 1 axe.