Mode Zero

Hi Max, thats exactly right.
To explain, the ce and csn pins can be on any digital pins, so most examples you see are different, whatever the author chose. In my case I chose 9 for ce and 10 for csn, to keep all the pins adjacent.
This was an unfortunate choice, as when we discovered the RF-Nano, it was the opposite, 10 for ce and 9 for csn. I strongly suggest we stick with the RF-Nano convention, but I'd already made several radios by then, hence the two options in the code. I will remove the 'old' reference.

That diagram above is in the RF-Nano order Max, CE on 10 and CSN on 9. the opposite of how I set up the very original project. For an RF-Nano it has to be this way, its hard wired, so to create an instance use:
RF24 radio(10,9); // ce, csn
I would use this for any new builds, but I still have four radios with
RF24 radio(9,10); // ce, csn
Crucially of course the wiring has to match the code, in the case of the RF-Nano its already wired,
but to update my working car radios to 'RF-Nano order' means dismantling and rewiring.
Getting ce and csn mixed up does no harm, it wont break anything

A bit of an update, two things:
The OS was a bit of a temporary installation, in fact the NRF+PA module was just wedged in place for the tests, but just this morning I got around to fitting it properly - and discovered something - it doesnt like the brass SMA connector to be grounded to the metal case. I tried insulated and grounded several times to confirm this, because its not what you'd expect. Insulated its fine, but when grounded I saw significant packet losses. This suggests that whilst the brass RF output connector is DC connected to ground, from an RF perspective its not a perfectly unbalanced feed as it theoretically should be. These things are not a problem once you know, so its now temporarily mounted through a plastic spacer and its fine. So its still not permanent! I'd not seen this peculiarity on the Multiplex Pico as its a plastic case.
Something to remember.

The other thing is I had one receiver lock up when running from the same supply as a noisy brushed DC motor, and I'm almost sure its the NRF that locks rather than the 328P, they do seem to be very sensitive to power supply variations/noise. So I've added 100uF and a 100nf in parallel across the RF-Nano power supply, actually on the receiver. This is whats recommended for the NRF anyway and isnt a surprise, and after repeatedly subjecting it to lots of electrical noise I cant get it to do it again so I believe thats sorted. All my PIC stuff has a watchdog timer, I'll look into adding one here too, though resetting the 328P wont reset the NRF24 so a WDT may not be of any benefit.
Cheers
Phil

Wahoo!

The FHSS set has flown at last! Got up at 6:30 thinking the Park would be empty at 7.
I'd installed the hopping NRF set in my hack Multiplex Easycub, with the OS Cougar tranny.
The RF-Nano receiver was taped externally, underneath, the idea being I could see the
LED that flashes every 20 packets received. In practise it was too sunny & not visible at all
Arrived to an empty park at 6:50am only to realise that I had no prop adapter, I'd taken the
prop off for testing! Big sigh, small cuss, back home again, picked up the propnut and back
at the park Andy S had arrived & set up. Rather than do a test flight whilst Andy was up,
I hung back until he'd landed, then a quick test and off we go. This was the first time I've
flown in ages and I was well rusty, had far too much elevator movement but soon settled down
and had three longish flights, no problems whatsoever with the radio, I'm happy as Larry with it
Tried extreme height, tried low & distant, threw it around a bit, tested the failsafe by switching
off, all perfect, I'm so pleased
Remember this is a setup that cost under a fiver for the transmitter and receiver!

Next thing I think is to try a full day flying it in a slope soarer. [Edit: Done! link ]






I had thought about doing bindy stuff but I've decided against it, at least for now- there are four things I particularly like about having the GUID and hopping scheme hard-coded:
1) theres no handshake on power-up or on resume, the initial link or reconnect after a power-cycle is absolutely instant.
2) I can use any of my transmitters with any of my models or any of my receivers. When your main interest is in restored trannies, this is a real boon. Want to fly your RET model on S/C? just pick up the S/C tranny, even mid-flight!
3) Only an enthusiast would build this anyway, it doesnt need to be numpty-friendly
4) KISS !

Phil_G wrote: 29 May 2020, 15:02 Your OS Cougar looks well eh Gary?

Yep!...you mean 'your' o.s.cougar!

Hi all, a question just out of curiosity. For the Tx, I can read from the code that the stick positions data is refreshed every 20 ms in the main loop. The ISR changes the transmitting channel every 5 ms and communicates the data packet to the NRF chip. But what I am wondering about is if that data packet is then transmitted by the NRF24 chip to the Rx only once, or multiple times within the 5 ms bracket?

Cheers,
Max.

Once Max, send one frame, change channel, next frame, change channel, next frame... etc so there will be some repetition of stick positions on subsequent channels. I need to maintain the 20ms heartbeat for timers, alarms etc, all of which were unmodified from the old ppm framecounter. I see what you're getting at but cant see any overall system benefit from changing this as the servos still get a 20ms PWM signal regardless. Or irregardless as Mr Trump would say

Update:
I've added a watchdog timer to the receiver code.
A watchdog is a safety precaution - the processor should never lock up, but most processors include a WDT just in case. The idea is your main code keeps prodding the timer to keep it going. If the code stops, the prods disappear, the WDT times out and resets the processor. Its a bit like a failsafe for the chip itself. This is nothing new, all my PIC stuff uses the WDT.

I've tidied up the files throughout the thread and everything is in one zip attached to the first post.


Further update:
I've been thinking about changing the packet timing from 5ms to 4.992ms sounds stupid I know, but it means I can use the 8-bit timer2 and free up the 16-bit timer1. I've always thought it a waste to use the only available 16-bit timer for a simple 5ms tick. Due to the numbers involved timer2 cant do exactly 5ms and whilst you might think 4.992 is near enough, timing here is everything so to maintain sync it would mean changing both tx and rx code. Another plus is that the Promini 5v, Promini 3v3 and RFNano would all use the same software build, with no need for the 3v3 Promini to use the 8mhz servotimer2 library. Theres no functional benefit, the existing setup works perfectly, but its always nice to make your code prettier [Done!]

I'm going to add an option to set failsafe from the tx, sometimes the rx is buried and you cant get to the failsafe link... you could even set failsafe positions in mid-flight after trimming for stable descending circles... [Done!]

Trouble is the more sets you have built, the more of a chore it is to update them all...
So far I've the two car transmitters, the OS Cougar, the MPX Pico, the S/C RF-Nano, my bench kluge tx, and maybe 8 or 10 receivers to update...

Edit: Done. In addition to the receiver F/S link, failsafe can also be set from the transmitter to the current control positions, this can be done at any time, on the ground, on the bench, in flight...
unforch we're running out of pins so the S/C emulation only has one speed now. "Set F/S" is a momentary button on transmitter pin D4.

...and I've changed the 5ms timer in both tx and rx code to timer2.

I did have another idea for an improvement but I'm blowed if I can remember what it was...
It might have been digital trims using a spare analogue input, that was one idea, maybe one or two switched channels... but I thought there was another...

Updated zip has been uploaded to the opening post #1.

Phil_G wrote: 04 Jun 2020, 17:03 One tip - I was using an ebay redboard with an RF-Nano for development and the two 3v3 regulators dont get along at all well. They're obviously slightly different voltages and the contention caused the RFNano to get uncomfortably hot. After removing the regulator from the redboard all was well and the redboard is a really convenient way to work with the RF-Nano.

I don't know why the redboard even has a 3.3V regulator, AMS1117. It seems like a mistake because the 3.3V pin on any Nano is an output, not an input. I wondered about keeping the regulator on my redboard just to power the row of three header pins and not the Nano. That's not straightforward though as the track to the header pins is via the Nano pin - in fact that's the only place it swaps from the top of the board to the bottom.

There's another mistake on the pins around the outside of the redboard which are arranged in Arduino UNO order so that a Nano can be used* with the common 'shield' boards designed to fit the UNO. One of the pins there, labelled NC, really does have no connection, but it's in the position where many UNO shields expect 3.3V to be supplied. The redboard designers fitted an unnecessary (and harmful) extra 3.3V regulator, and then didn't bother to connect that 3.3V, nor the one available from the Nano, to the one pin on the board where it might be useful!

Despite its flaws, I agree that the redboard is a useful way to work with a Nano - it has the convenient 'servo' pins for each input/output. Normally you could just use a DIY-more board instead, but there isn't a DIY-more with a built-in nRF24L01+ not yet anyway!

* Not used easily though, because you need to solder in mile-high sockets so that any shield board ends up high enough to clear the Nano, which is already fitted in standard height sockets. If they really wanted to provide the option to plug in a UNO shield, they should have put those outer pins in mirror image arrangement, so that the shield would then plug on the opposite side of the redboard to the Nano.

Receiver:
The RF-Nano makes the receiver easy but I've drawn it up anyway. Note that I've drawn "set F/S" on D8 to free up D7 for a possible sixth channel, whilst keeping the servo signals in a neat continuous row. The code of course needs to agree so use "#define failSafePin 8". The very original (long gone) line "#define failSafeGnd 8" is of course redundant with Tobes servo block idea, plus you can now set failsafe from the tx anyway. This and a couple more diagrams have been added to the zip in post #1.


Transmitter:
These two diagrams show how I used the high-power NRF24L01+PA with a Redboard,
and other than 'gnd' the same 'sideways plug' idea would work with the DIY-More 'strong' board too.
Note that I now power the NRF piggy-back adapter directly from the switched battery:

Martin wrote: 04 Jun 2020, 17:50 I don't know why the redboard even has a 3.3V regulator, AMS1117. It seems like a mistake because the 3.3V pin on any Nano is an output, not an input.

Very true Martin, it probably doesnt come to light with a standard Nano as the 3v3 output is so weak, but the RF-Nano has a proper regulator with a higher current output for the NRF.
With the redboards 3v3 disabled though it makes a really convenient breadboard for the RF-Nano


Since moving to timer2 the 8mhz 3v3 Prominis needed different a configuration and rather than have two versions of the code for 16mhz and 8mhz I've put a test in setup() so it knows what timing values to use without having the edit the file. The same receiver code now runs on both the 16mhz Nano, RF-Nano and 8mhz 3v3 Promini. This is the receiver for both the propo and S/C transmitter projects.
But its been a long day, I'm tired so I'll upload tomorrow
Cheers
Phil

Edit: Done First post zipfile updated

On the piggy-back adapter for the RF module; I guess all the connections like miso, mosi etc. are just through-connectors, except for the Vcc and gnd connections. So, it would not be a problem if I choose to wire these straight from the Nano to the RF module?

Cheers,
Max.

Hi guys,

while watching Phils experiments with the NRF24 radio during the lockdown phase very closely, I wanted to give it a try.
After obtaining all necessary parts I decided to build a single channel version of it. That was before Phil came up with its S/C NRF24 outfit. So I removed everything I did not need from the sketch of the propo version of the transmitter and removed all gimmicks like expo, rates, timer, mixer, propo channels etc. just leaving the single channel stuff and added a sequential throttle on a separate button, like I did on all my dual button S/C transmitters. The only extra is now a throttle led. Since I do some sequential flying also, I will add sequential rudder also to the code.
After some minor problems, all was working well and today was flighttest-time.
Using my old Pageboy, I had several wonderfull flights with the NRF24 S/C system. All was working great, no problems, no glitches, no range problems. The transmitter uses an Arduino promini and a high power unit. The case of the Futaba FT5D replica is 3D printed, the meter salvaged from an old Futaba tx. The black button on the right is the compound rudder and kick up elevator.
The white left button is the sequential three position throttle.
The receiver is a RF nano wired only for rudder and ESC.
As said before, it is working very well, no issues.
Thanks Phil for a wonderfull project, that keeps us busy.

Cheers
Frank

Edit:
Sequential rudder is now added. If you press the button upon start-up, it switches to sequential rudder.
If you just switch it on. it starts on compound incl. kick-up elevator.
The extra throttle button is very convenient when using sequential mode and allows electric power to be used with ease.
Provisions for rubber ecapements are on channel four.

Frank

Looking good Frank! I am doing just the opposite, deleting the S/C functionality, and building a 2/3 channel propo unit
The condensator you are using on the Rx seems a bit smaller (in size) than the one Phil was showing, what is it?
And by the looks of it you are using a brushed motor, any problems with electrical noise? Did you install a low nF C somewhere hidden?

Cheers,
Max.