Hooking up Logic Analyzer ....Help please

only cvs i have and already got both the 8 and 12 back together...

wont let me upload it its to big... i did zip but still to big..

On the 12 you only need to sample one line >CSN.
Do not hook the others at the saleae. If this line will not change from high to low, there is no need to upload anything.
Then the modul is not active and will not work. Simple as that.

Edit: To trace for it on the pcb the analyzer is not the right tool.
This is a part for an oscilloscope or at least a cmos logic probe.

How can it be a trace on the PCB because the module works when i load deviation 4.0.1 ?? It only does not work when i am using the nightly builds...Seems if it were something on the pcb it would never work no matter what firmware i load to the tx..

Right.
This was more meant as an example.

The nightly is working with that nRF on your Devo8 and on my Devo7e .
Who can be blamed that it is not working with your older Devo12?

Any news about the CSN signal?

haven't had time to pull it back apart and hook the anaylizer back to been a bit busy today but i will try again soon as i get a little spare time....

Could be because it is a older 12 that its just not going to support modules and i might just have to live with it or get a newer version 12s ..

Just like Devo 8 vs Devo 8S (same with 6 vs 6S) its the telemetry capable CYRF module which makes the difference between Devo 12 and Devo 12S.

The issue you describe can be caused by the wires connecting nRF with Devo. Maybe they are too old (broken, resistance), too long (building an antenna) or maybe shorting a wire when case is close.
Since the SPI is shared among modules, failing to disable a chip via CSN due to bad logic levels lets chips crosstalk, which leads to the symptoms you've described. The very same thing (wrong chip enabled) happens when you have a module connected, but not properly set up in your hardware.ini (I have a software-fix for that).

Note that you cannot really see the "logic level issue" with an logic analyzer, these usually accept a wider range as "logical 1" as the RF chips, thus you see the signal which is meant to be on the lines - but not what the actual RF chip sees. A digital oscilloscope would be great here, but possibly you can just check the level on the CE line with a multimeter to be in valid range. Not sure if that is enough to pinpoint the problem, though.

magic_marty wrote:
Could be because it is a older 12 that its just not going to support modules and i might just have to live with it or get a newer version 12s ..

You reported it working with Deviation 4.0.1.
So what is the difference? The nightlys since May have the BK protocol
included and a check whether this chip is present.
That might make a difference with your tx. I am shure that it is not the nRF
since I have the same type and it works without any issue.

BTW... btoschi is right with the logic signal, it has to be at least 0.4V(or less) to be low. But I can´t remember that the firmware has any influence on the logic signal level for "low".
Could be rather a timing problem than a logic level problem.
If the mcu did not recognise the module at check, this signal line will not be used anymore ( missing module).
So please check if this signal line goes "low" at least for one time.

I had an impression the Beken support is always included - I wrote this code, and every author of the nRF24 based protocols copied it over to their protocol modules.

So what is your opinion on this behavior of magic_marty´s Devo12?

yes it does work with Deviation 4.0.1 but soon as i load the nightly on the 12 it says missing module when powered up...both modules work perfect in the 8 so i honestly do not believe it could be a wiring issue (broken, resistance) cause it seems it should be present in the devo8 but its not ...when running deviation 4.0.1 on the 12 the module works but the controls are not as smooth as they are on the 8 but that could be cause of different firmware.. i have not tried 4.0.1 on the 8 cause there is no need it is working perfect as is with the nightly..

The story is already known. So what will you do next? Take the tx as it is or put it into the bin?

Guess i will have to wait for the next release of deviation to see if it works cause nobody knows what or why my 12 is not working with the nightly build. Not mich else i do i guess.

How could they, all Crystal Balls are to service.
If you are not providing us with some more facts, we cannot help.

I will hook the analyzer back up and try again but it doesn't show anything that i remember cause it goes straight to missin module soon as i turn it on. Im gonna just make some wires with plug in the ends and leave them hooked up so i wont have to keep taking this dang thing apart so much. I run them out the battery bay or something. That way i can just plug it in at any time

magic_marty wrote: ...when running deviation 4.0.1 on the 12 the module works but the controls are not as smooth as they are on the 8 but that could be cause of different firmware.

What nRF protocol are you running that gives "not as smooth" behavior? This can happen if the tx is not getting ack packets back from the receiver (the nRF will retransmit the same packet, giving the same control inputs for several frames). Is the nRF antenna setup the same in the 8s and 12?

Can you try other nRF protocols?

I'm also curious if the resets still occur on the nightly if the current_model in tx.ini points to a model with a non-nRF protocol.

If you can build your own, try building one from the hexfet repository at bitbucket.org/hexfet/deviation . It has fixes for the module initialization code that aren't in the nightlies. If you can't do a build, leave a note here and I'll upload one when I get home.

mwm wrote: If you can build your own, try building one from the hexfet repository at bitbucket.org/hexfet/deviation . It has fixes for the module initialization code that aren't in the nightlies. If you can't do a build, leave a note here and I'll upload one when I get home.

Oh i have never tried to do a build and pretty much have no idea on how to do it.. if it's not to much trouble could you please upload it for me to try?

Thank you so much..

hexfet wrote:

magic_marty wrote: ...when running deviation 4.0.1 on the 12 the module works but the controls are not as smooth as they are on the 8 but that could be cause of different firmware.

What nRF protocol are you running that gives "not as smooth" behavior? This can happen if the tx is not getting ack packets back from the receiver (the nRF will retransmit the same packet, giving the same control inputs for several frames). Is the nRF antenna setup the same in the 8s and 12?

Can you try other nRF protocols?

I'm also curious if the resets still occur on the nightly if the current_model in tx.ini points to a model with a non-nRF protocol.

the protocol is the YD7 which runs the cheerson cx-10 its the only model i currently have that uses the NRF module...
The Antenna on the 8 is pointing down and seems to work well that way and on the 12 i have the module mounted in the rear inside of the tx with velcro with the antenna pointing straight up...i removed the plastic covering on both them so they would fit inside the tx cases..but the ends of the antennas are not contacting anything and i used liquid electric tape to cover the tip so not to short anything in case it should touch anything...

No problem. I don't have a devo12, so can't test these. Haven't ever built the devo12 stuff before, and my 10/7e/6s builds don't need a -lib.dfu, so I've included that as well.

I don't know if this has the DSM fixes that are available but haven't gone into the nightlies yet. If you're a software developer who's going to be running nightlies, setting up a build environment should be straightforward, and is pretty useful.

Bah. Silly forum doesn't warn you about files that don't upload,just creates the post anyway.