Scavenge RF module from Toy grade TX?

I just bought a 7e and hope to control an Eachine H8 mini, also on order. The H8 needs an nRF24L01 RF module.

I have some spare UDI U839 transmitters with Beken 2423 chips inside (nRF24L01clones I understand) . It looks like it would be easy to remove the sticks/gimbals from the TX, cut the SPI data lines between the Beken and the micro, and connect it up to the Devo 7e just like all the module installation instructions describe.

Is this possible? Has anyone done it? It seems easy to do, but my searches can't find any info. Can anyone help?

Thanks!

Yes you can used scavenged radio modules. I've used several Beken 2421 modules from yd717 transmitters. You'll likely want to power it from the devo also. Google has 2423 datasheets. The wiring is the same as for nrf24l01.

Thank you. Have you ever seen any pictures, descriptions, tutorials or the like describing this? I'd like to see how others have done it.

Once you identify the pinouts of the module by tracing the copper tracks against the datasheet or capturing the signals by a logic analyzer, it is nothing different from a commercial module.
If you think this is too much work then pay a few bucks for a module from BG.

I read the datasheet and found the pinouts before I posted. I was just interested in seeing if other people cut power to the microcontroller, and how they removed the gimbals. I assume they cut the SPI traces to isolate the RF chip, but did they hot melt glue down the wires to prevent them from pulling up traces. Did they cut the board up and remove a portion not needed, or did they put the entire board into the 7e case. Did they add an external antenna. Basically, I was just interested in seeing what other people did, but I can't seem to find other posts on this subject.

The purpose isn't really to save money. It's just an interesting hack, and it will save me some time waiting for shipment from BG.

The modules I used were all separate from the main board. Never tried to reuse one that's integrated - just waited on the mail.

It is more troublesome if your transceiver and MCU are both mounted on the same board. You will have to cut the portion where the transceiver resides. Depending on the layout the resultant portion could be an irregular shape. I have seen similar things people did on the disposable camera but I have not seen similar things on transmitter board. What if you post a picture of your board for further discussion?

I'm sorry if I wasn't clear that I was interested in scavenging an integrated board with MCU and RF chip.

I took photos before even considering this project. I wanted to know what was in the TX and RX.

Here are two of the TX at a scale showing the entire board. The main 3.3 LDO is on the top. The Beken is on the bottom and the SPI traces are easily accessed.

I planned to cut the SPI traces, MOSI, MISO, etc. between MCU and Beken, and cut power trace to the MCU and remove the sticks. I'd test with the wire antenna it has on it, and later add a removable antenna.

I can't seem to upload my jpg photos. They are less than 1mb? [attachment=undefined]U839%20Top%2020161126_122733.jpg[/attachment]
[attachment=undefined]U839%20Bottom%2020161126_122636.jpg[/attachment]

I get a Kunena internal error?

I tried 6 times and finally succeeded using an 8.3 filename.

If I were you I would chop the transceiver portion off the board, see attachment. Keep the crystal and antenna as is and connect the SPI and power to 7e with thin hookup wires.
The gimbals could be destoyed by a pair of sharp nippers as desoldering would be quite time consuming.
For you to get an idea here is a video about cutting a useful portion off a disposabe camera board:

Thanks for the link. Yes, it's possible to cut the board up. I'd like to keep the on board 3.3 regulator, and it appears to be pretty far from the Beken, so cutting it smaller may require moving the LDO. That may not be worth it.

My initial procedure is going to be:

Remove gimbals, LED, buzzer and all seven switches.

Then I'll cut the SPI traces and solder on 30 gauge wires to the Beken side of the cut traces and power/grnd leads.

Then I'll cut the power lead to the MCU and the Atmel EEPROM.

That should leave me with power for the Beken when I connect up power from the 7e. If it works and fits into the 7e, I may just leave it. I don't see any PA power amp circuitry at the Beken output , so eventually I may want to replace the Beken, but right now I can only fly indoors, so range isn't an issue.

BTW, do you know if I can run the Devo 7e on a 1S LiPo at 3.7 to 4.2v? Or, do I need 4.8 to 5v? The Beken runs fine on a 1S.

Sorry I am not sure if 1S works for 7e since I don't own one. However your Beken chip has no PA so it will draw a small current. I suppose you can share the same power as the stock CYRF6936 module without overloading the 3.3V supply.

An update:

I lifted the power traces on the MCU. I didn't bother isolating the LED as it is only powered by the MCU.

I cut the 5 traces between the Beken 2423 and the MCU. Those traces were CE, CSN, SCK, MISO and MOSI. The 7e has no CE chip enable pin, so I followed instructions for other Nrf24l01 chips and wired CE to VDD-B+. I note that doing this means the Beken can only be a TX, never an RX. I'm not familiar enough with the system to know if the copter ever sends data back to the 7e.

The other pins, CSN, SCK, MISO and MOSI, were wired as per instructions. Initially, I connected ground, but not PWR, and used the battery connected to the board I was scavenging. I did this because the power to the Beken was measured at 3.0v and the 7e power is 3.3v.

The 7e booted fine and recognized the nRF24L01/Beken, but never bound to my H8. I tried another H8 mini, but no luck.

I then tried connecting PWR from the 7e to the module. The Beken specs say it can handle up to 3.6v. Now the 7e says "Missing Module CYRF6936". I suspected that I was drawing too much power from the 7e, causing it to fail to initialize the CYRF6936.

To reduce power draw by the module, I disconnected the EEPROM and cut the power trace to one gimbal. I couldn't easily cut power to the 2nd gimbal. I still got "Missing Module CYRF6936".

That's where it stands now. Any suggestions?

To where did you connect the CSN of the Beken chip and did you modify the hardware.ini file accordingly? I suppose you have done it right if the module has been properly recognized by 7e.
Will the CYRF6936 missing message go away once you disconnect the new module?

CSN went to TMS.
Hardware.ini is set to A13.
Has_pa-nrf24l01 is still commented out.

Yes, disabling the module by disconnecting it completely eliminates the "Missing Module CYRF6936", but then I get a missing Nrf24l01. If I disconnect only the power connection between 7e and module (leaving GND and other connections), I get no errors, but still no binding.

Does anyone know how the 7e detects the module? Is there a digital communication/handshake or does it just detect a simple low or high on one pin? How confident can I be that it's really talking to the Beken chip?

Also, has anyone seen a "Missing CYRF6936" message like this? Is it likely to be a power drain problem? With some effort, I can reduce current drain by removing the last gimbal. It has two 5K pots, drawing a total of 1.3 mA. Is that likely to be a significant load on the 7e's 3.3 vreg that could cause the "missing" message?

The 5.0 and nightly builds do attempt to read from the chip and check it's really there.

Don't have a 7e but others have posted about solving the missing module issue by enhancing the power supply by different methods.

Only suggestion I have is to try binding something other than the H8.

As hexfet stated you probably can only play with the power for the moment since we don't have the 7e. You might remove the MCU off the Beken board to reduce the current consumption further. I know this is doubtful because the 7e should be able to supply enough current for CYRF6936 to transmit up to 100mW and during the module detection phase all modules should not be transmitting and hence power drain is low.

Just a thought: would the additional parts causing a change in the rise time of the supply voltage which in turn affects the reset of the CYRF6936? If you do not see any warning message nor an * before the protocol you choose, that associated module should have been properly detected.

One more trick clumsy though:
you connect the power input of the Beken board power to 7e via a switch and connect it to 7e after successful detection of CYRF6936. You can make use of the switch on the Beken board by connecting the battery input wires to the power supply of the CYRF6936 module.

Regarding the failure to bind, you probably need to test more quads to see if the problem is caused by the Beken board.

I originally lifted the MCU power and ground leads, so it should not be drawing power. The power lead to the Atmel 2wire serial EEPROM was lifted next. Then the power to one gimbal. Last night I disconnected the second gimbal.

I still get the same behavior - the nRF24L01 is recognized (no Nrf24l02 error message and no asterisk for Nrf24l01 protocols ) when the module is connected (but a CYRF6936 error) and the reverse when it's disconnected.

I've tried two H8s and an E010. I noticed that when it starts and tries to bind it only attempts for 0 seconds.

For CMOS devices, disconnecting VDD and VSS alone does not mean current will not flow into other I/O's.

I got the E010 and binding time is really short almost immediately.

Sorry I do not have further clues for you.

All traces frim Beken to MCU have their MCU pins lifted, so I can't see where current might be entering the MCU.

Options:
1. Disconnect CE to VDD wire.
2. Put 10-20K pullup resistor between CE and VDD.

These two explore possible problems in CE.

3. Measure current draw from 7E to module. This might help find out why the CYRF6936 isn't recognized. Is it due to an overload?
4. Go back to config in which VDD wire from 7E is disconnected and I use a separate battery on the module to provide local VDD. I believe in this config both modules Nrf24l01and CYRF6936 are recognized.
5. Disconnect other wires from 7E to module. This might verify if one of those pins is the problem.
6. Lift the MCU completely. I don't see how it can be causing a problem now, but...?

Anyone want to choose a debug option above or suggest another?