Dumb question

If you copy a protocol folder from a nightly build into 4.01 will they function or is there more to the process. What I am trying to do is to get syma put into the 4.01 build without loading the whole nitely

It almost certainly won't work. While you might be able to get away with taking a protocol from one nightly back a a build or two, we don't test that, and assume that you're going to install the protocol folder with the DFU. And by "won't work", I mean anything from "won't bind" to "will brick your Tx in the middle of a flight."

@Gatonini.
If you are talking of protocol folder, we can assume you are using a 7e.
I tried once on my 7e and it didn't work. In fact the TX becomes unresponsive until I flashed a valid build or change protocol folder to the correct one.
BTW, I think at this moment nightly builds are as safe to use as 4.0.1

Thank You

Durete wrote: BTW, I think at this moment nightly builds are as safe to use as 4.0.1

Well, maybe. Depends on the build. I noticed that my V323 is unflyable with the latest nightly build, but works fine if I go back to 4.0.1 (well, actually, I copied the V202 protocol source to the nightly tree, tweaked it so it built, and fly that, but you get the idea).

So I recommend not going to the nightly build unless you need something it's got that 4.0.1 doesn't have. Needing a new protocol is a perfect example of a good reason to go to the nightly build.

PhracturedBlue wrote: Is there a bug report on that mwm?

deviationtx.com/mantisbt/view.php?id=613

mwm, I have flown for months at least 6 different v2x2 Quadcopters (v636 x 2, jxd385, jjrc jj1000 x 3) almost every day using almost all nightlies, and never noticed any problem with v2x2 protocol. I have a Devo 7e with nRF24L01+ module from Banggood.
Could be something related with your nRF24L01 module?

I don't have V323 - I'm aware of bug report but need to think what can be done for remote debugging. The most cruel (for mwm) method of dichotomy of releases and finding one which has this defect is apparently unsustainable - too many releases to build. We just did this at work and it worked perfectly, but I can't request this in clear conscience .

Well, a linear search would be a problem, but a binary search looking only at changes to the V202_nrf24l01.c file shouldn't be to bad. Since it didn't fail for you, I can try that.

Also, did you test with one of the larger outdoor WLToys - V262/V393/V666/etc? I'd expect a problem with the V323 (which is basically a hex version of the v262) to be more likely to show up in that than in the indoor micro & nano quads.

Ok, I've isolated a single patch that causes the problem. Details (including a patch that backs out the break) in the issue.

@mwm, I just came back from a trip, can look into it now.

Can you tell me the module you use in your Devo, is it nRF24L01+ or Beken?

nrf24L01. Actually, I have two of them that fail the same way, and both work with the patch. One is this thing from amazon:
www.amazon.com/gp/product/B007ZZANPA?psc...ui_search_detailpage

I still have the second one, and could send it to you if it would help. PM me for details.

The other is the nrf24l01 ufl linked from the module list page.