which is MJX use protocol ?

Ummmmhhhh, delayed controls as YD-829
Maybe now, that we have 2 XN-297 protocols with weird delayed controls we can find the solution
I tested everything (at hardware side) on my Devo 7e, without find the solution.

On yd829 I had problem with delays (but not bind) no matter of fixed id value. On this protocol - I have no problems with default value (which is on 'none') and have additional bind problems on some values.

Anyway it is the same my 7e with banggood's NRF for both. So if you can build devo10 version - I can check if delays will be still there also.

The delay is only reported for certain fixed id's. There's no delay for fixed id of none, which sets the txid to the value in the captured SPI.

What's likely happening here (don't know about yd829) is that all or some of the four rf channels used in the data phase are determined by the txid value. For the fixed ids that produce delays, some of the channels the receiver is listening on must be common to the four the protocol is sending so that some of the packets are received. Enough to control the quad but few enough to cause perceptible delay. It may be that one or more of the data phase channels is always the same as one of the bind channels, so that the quad could rebind if the tx rebooted - but that's just guessing (could be tested by pressing re-init while already bound).

I'll check for a pattern in the fixed id values that are reported to work with no delay, but it's likely we'll need SPI captures from the receiver to figure out the relationship between the txid and rf channels. In the meantime just set the fixed id to none, and don't try to fly near any other deviation user with the same model!

You are right, probably here we have a different problem than on YD829 protocol, because on YD829 I tested even a build with my stock TX id and RF channels hardcoded without solve the issue.
The weird thing about the YD829 protocol is AFAIK 5 people tested it with only 2 people successfully flying without delays, and 3 people with variable delays (sometimes not much, sometimes unflyable) without find a pattern. Even mixed hardware configurations with different results.

Anyway @Hexfet, if you can provide latest build for devo10 - I will test this ids-related delay issue on it. As I was one of those who had non delay behaviour of yd829 on my devo10 (and problems on devo7e). To make sure that those two problems are unrelated...

I've uploaded a test build for the devo10. Thanks for all the testing

hexfet wrote: I've uploaded a test build for the devo10. Thanks for all the testing

Tested it. The result is exactly the same. Only once I managed to bind with 12345 but delay was even worse than with 1234. Several attempts to reproduce were unsuccessful. Also I mentioned that with non-working ids quad may blink after bind attempt or become steady light (but still not responsive) depending on id value.

Anyway it is not the same problem as that with yd829.

Hi hexfet,

I will capture SPI data from receiver if it's necessary,please let me know!
Is it the same way like to capture SPI from TX? What kind of data you need?
bind with stock TX or 7E ?

Fixed ID=12 always delay and repeatable , none & 13 & 18 works OK!

Thanks.

Capturing the data is the same - connect to the SPI bus on the receiver. But it involves binding multiple times with different fixed ids and can be tedious (see this discussion , though we'd be recording rf channels instead of the address). If we can get a bind capture from Durete some pattern might emerge.

In the meantime would you make a capture of the trims?

I've updated the test builds to add a protocol option named "bit test". Just a guess at what may be a flag bit to control the auto-flip. The default is off and the packets will be the same as the previous version. Please try turning on the option and checking if the quad will still bind. If it binds, check if the auto-flip (at full stick) is active. Thanks!

I'll be happy to help as possible, but just ordered some days ago my X800
So probably I will receive in about 2-3 weeks.
I will ask SebyDocky, because he has the 3 new models (X600, X800, X900) and all of them share the same protocol.

hexfet wrote: But it involves binding multiple times with different fixed ids and can be tedious!

Is that mean , I use 7e with different fixed ids to bind with X600 and capture SPI from receiver right?
no need to capture stock tx binding data?
I will do it ASAP.

That's right. An SPI capture on the receiver, about two seconds after bind complete would be plenty. Then increment the fixed ID by one and repeat. And repeat

Can't predict how many captures might be needed. It might be the relationship between txid and the rf channels is obvious, or not. You could decode the captures with the deviation format_spi script and stop if you see a pattern to the rf channels. Or make as many as you can stand to and post them - it quickly becomes tedious to do by hand.

The SPI bus on the receivers often has a faster clock than the transmitters so you may need to increase the sample rate.

hexfet wrote: That's right. An SPI capture on the receiver, about two seconds after bind complete would be plenty. Then increment the fixed ID by one and repeat. And repeat

Can't predict how many captures might be needed. It might be the relationship between txid and the rf channels is obvious, or not. You could decode the captures with the deviation format_spi script and stop if you see a pattern to the rf channels. Or make as many as you can stand to and post them - it quickly becomes tedious to do by hand.

The SPI bus on the receivers often has a faster clock than the transmitters so you may need to increase the sample rate.

Got it,I will try to do it,thanks.

Hi dc59.
Be aware of you need to reset the quadcopter after every bind try.
After you change the fixed id at Devo TX, you can press the Reinit/Bind button to use the new Fixed id, no need to reboot the TX.

Durete wrote: Hi dc59.
Be aware of you need to reset the quadcopter after every bind try.
After you change the fixed id at Devo TX, you can press the Reinit/Bind button to use the new Fixed id, no need to reboot the TX.

OK,I will remember it, thanks Durete!

But now I got big big trouble!!
How can you guys solder wire on such tiny pin?
I will try to do it and hope it still alive after my suck soldering skill .......





Is there a easier way to do this job?
It will be much appreciated.

dc59 wrote:

Durete wrote: Hi dc59.
Be aware of you need to reset the quadcopter after every bind try.
After you change the fixed id at Devo TX, you can press the Reinit/Bind button to use the new Fixed id, no need to reboot the TX.

OK,I will remember it, thanks Durete!

But now I got big big trouble!!
How can you guys solder wire on such tiny pin?
I will try to do it and hope it still alive after my suck soldering skill .......

Is there a easier way to do this job?
It will be much appreciated.

Probably no
I suggest you to wait somebody capture from his TX, hopping the relation between TX id's and RF channels were obvious.
I asked Seby at RcGroups to take some captures from his TX's.

Thanks Durete!
It's a good idea, if Seby is too busy to do this, I will try to find some soldering expert to help me!

A lot of these boards have test points that we can use instead of the chip pins. Can you post a photo of the board straight on both front and back?

dc59 wrote: Thanks Durete!
It's a good idea, if Seby is too busy to do this, I will try to find some soldering expert to help me!

I will try my best but it's true I am very busy... Will start to be better from sunday

Deal57 wrote: A lot of these boards have test points that we can use instead of the chip pins. Can you post a photo of the board straight on both front and back?

Yes, Seby is always too busy , but maybe he could help us at some point.
About the test points at the back side, usually they are to program the MCU, but worth to check it. A backside photo could be helpful.