Phil's lockdown project - a 4ch propo NRF24 set
Posted: 01 Apr 2020, 13:27
Edit: this hybrid-hopping project is obsolete now, see the full FHSS version here: http://mode-zero.uk/viewtopic.php?f=42&t=971
Edit 8/4/20: Added a form of frequency hopping, see bottom of this post. This hopping/scanning puts it a step up from the usual fixed channel sets you see on the net, It has good range, its solid around other transmitters, the code is simple to follow and its easy to build - even easier if you use an RFnano for the receiver - just add servos! The set is working out really well, have a go, its cheap enough!
This is one of my lockdown projects - entertaining myself using bits I already have to hand
I was pondering options now that RF modules are hard to come by, and remembered that Tobe had kindly sent me some NRF24L01+ boards which I'd not done much with. Its been a while so I did a bit of revising and set about a simple project purely for interest. The NRF24s are buttons cheap and really easy to use, if a bit messy with their extra wiring.
The encoder body is adapted from the 7ch encoder with some changes and has the usual S/C escapement emulation, rates, expo, hardware & soft throttle locks, Vtail & elevon mixers, minute-minder, inactivity alarm, etc. I had to find a few more pins as the NRF24 interface needs seven (rather than the pos, neg, ppm we're used to) so theres no S/C sequential, but I've never seen anyone use that yet so its no loss!
I settled on a 4ch version, it could easily be extended but 4 is enough for me, its less birdsnest wiring and ultimately I didnt want to drill more holes in the Pico Theres room in each NRF packet for 16 or more full resolution channels, so one packet can conveniently hold everything we need.
The NRF handling was originally pinched straight from the simple library examples found in the IDE - but as always it has developed since then. Initially for example I didnt do any channel setting at all, whereas now it hops.
The receiver is a 3v3 promini with another NRF24 piggy-backed, the promini 3v3 vcc regulator supplying the Promini and the radio board. It has a built-in aerial and programmable failsafe on all channels set by momentarily placing a link on the rx. There are no spare LEDs so it confirms failsafe has been stored by wiggling a servo
For ease I chose the servo leads like old retro receivers used to have rather than a header block, it keeps the receiver nice & small. Having the aerial on-board is neat, though obviously the usual rules apply, dont hide it behind a battery, etc.
These are the low-power NRF modules, I have some high power (LNA+PA) ones on order from Banggood but they've not arrived yet. [Edit: yes they have!] Range on the low power ones I found was at least 200 yards where I ran out of space, everything was still working and no failsafes. I'd happily use it in a boat as it is, but I'm waiting for the higher power versions to arrive before trying it in a plane.
Besides the "NRF24L01+" theres an older NRF24L01 (no plus) which I'd avoid except for experiments, they both have the 1M and 2M datarates but the later 'plus' version also does a lower datarate of 250khz which gives more range.
The diagrams below show the essential connections, the rest follows the usual "7ch+S/C" principles, though note some pins have had to be moved. It was very much a make-it-up-as-you-go-along project
There are a few similar projects on the net but I did find what might be a common misunderstanding about the NRF24L01... I noticed that often the author goes to some length to reduce the payload to 32 bits, by limiting the resolution to 8 bits and the channels to 4, 8x4=32. However, this isnt the case, the NRF24 maximum packet size is 32 bytes not bits, so they could have avoided all the downgrading and had 16 or more full resolution channels like we have here. I dunno, is it a misunderstanding or did I miss something?
Cheers
Phil
The remaining connections are similar to the "7ch+s/c" document but with the following pin assignments:
D2 is the DC buzzer
D3 is the minute minder button pin
D4 is the optional faster S/C escapement emulation pin
D5 is the 50:50 Vtail mixer
D6 is the 75:25 elevon mixer
D7 is the throttle-lock toggle
D8 is the pushbutton for s/c compound, & stick calibration
Any 328P board is suitable but for convenience I used an old ebay Redboard for the tranny, by isolating vref with a track-cut the vref pin was in a convenient place for 3.3v to the NRF24, so all its connections are in a row - I used a single 7-way header strip across the seven signal pins. On these headers the pos & neg rows are not used, just 3v3, gnd, and D9 to D13 signal pins:
I quite fancy doing a single-channel 'button' version at some stage, plenty of free time at the moment...
Important (thanks Mike!!!)
I forgot to say, if anyone fancies playing with this do change the pipeOut line in the tx (and the pipeIn line in the rx) to your own unique number, I suggest using the last 5 digits of your phone number, as this is almost certain to be unique amongst our little group.
The 'number' idea is just to simplify addressing, so instead of the usual complicated-looking:
const uint64_t pipeOut = 0xEEEE0000F1LL; // same in rx 'pipeIn' line
we can use:
const byte pipeOut[] = "39965"; // last 5 digits of your phone number, make rx the same
Also, less vital but beneficial, change the channels to six widely-spaced numbers between 1 and 125:
eg in the tx:
/************* Radio config - make it unique! **********************************/
const byte pipeOut[] = "39965"; // same as rx, last 5 digits of your phone number
const byte mychannels[] = {117, 99, 57, 71, 35, 13}; // choose 6 widely-spaced 'hopping' channels
/*******************************************************************************/
and use the same values in the rx:
/************* Radio config - make it unique! **********************************/
constbyte pipeIn[0] = "39965"; // same as tx, last 5 digits of your phone number
const byte mychannels[] = {117, 99, 57, 71, 35, 13}; // choose 6 widely-spaced 'hopping' channels
/*******************************************************************************/
Edit 8/4/20:
Wahoo, after a lot of experimentation I've got a rudimentary but functional form of hopping working.
Its slightly unconventional in that the transmitter is FHSS but the receiver only hops when it needs to.
So overall its not classical FHSS like Werners bjt works perfectly. To explain:
The transmitter reads the joysticks, assembles that data into a packet, then sends the same data on six RF channels in sequence. These six channels are widely spaced through the 2.4g band and no channel has preference.
The receiver sits on one channel and whilst everything is working it stays there. If it loses a couple of packets, it moves to the next channel and so on. At this point it picks up where it left off, but if not it keeps trying the next channel in sequence, eventually scanning the six channels and settling on the first one it finds with a good signal. If you like, as an option on the rx you can add three 5v LEDs on D14, D15 & D16 (A0, A1 & A2) which show in 3-bit binary which channel slot is in use. Or use a TIL311 for a numeric display.
I dont know if this particular channel-swapping concept has a name, someone may have done it before I dont know, I certainly couldnt find anything similar.
Its a little bit like Spektrums DSM2 but with six channels to choose from instead of two. I settled on six after looking on the spectrum analyser, any more than six looks greedy and probably isnt necessary. Spekky were happy with 2!
In practise the single fixed channel is super reliable and I would happily have flown with it, but this should make it even more solid in a noisy environment. I'm really quite chuffed with it
_
Edit 8/4/20: Added a form of frequency hopping, see bottom of this post. This hopping/scanning puts it a step up from the usual fixed channel sets you see on the net, It has good range, its solid around other transmitters, the code is simple to follow and its easy to build - even easier if you use an RFnano for the receiver - just add servos! The set is working out really well, have a go, its cheap enough!
This is one of my lockdown projects - entertaining myself using bits I already have to hand
I was pondering options now that RF modules are hard to come by, and remembered that Tobe had kindly sent me some NRF24L01+ boards which I'd not done much with. Its been a while so I did a bit of revising and set about a simple project purely for interest. The NRF24s are buttons cheap and really easy to use, if a bit messy with their extra wiring.
The encoder body is adapted from the 7ch encoder with some changes and has the usual S/C escapement emulation, rates, expo, hardware & soft throttle locks, Vtail & elevon mixers, minute-minder, inactivity alarm, etc. I had to find a few more pins as the NRF24 interface needs seven (rather than the pos, neg, ppm we're used to) so theres no S/C sequential, but I've never seen anyone use that yet so its no loss!
I settled on a 4ch version, it could easily be extended but 4 is enough for me, its less birdsnest wiring and ultimately I didnt want to drill more holes in the Pico Theres room in each NRF packet for 16 or more full resolution channels, so one packet can conveniently hold everything we need.
The NRF handling was originally pinched straight from the simple library examples found in the IDE - but as always it has developed since then. Initially for example I didnt do any channel setting at all, whereas now it hops.
The receiver is a 3v3 promini with another NRF24 piggy-backed, the promini 3v3 vcc regulator supplying the Promini and the radio board. It has a built-in aerial and programmable failsafe on all channels set by momentarily placing a link on the rx. There are no spare LEDs so it confirms failsafe has been stored by wiggling a servo
For ease I chose the servo leads like old retro receivers used to have rather than a header block, it keeps the receiver nice & small. Having the aerial on-board is neat, though obviously the usual rules apply, dont hide it behind a battery, etc.
These are the low-power NRF modules, I have some high power (LNA+PA) ones on order from Banggood but they've not arrived yet. [Edit: yes they have!] Range on the low power ones I found was at least 200 yards where I ran out of space, everything was still working and no failsafes. I'd happily use it in a boat as it is, but I'm waiting for the higher power versions to arrive before trying it in a plane.
Besides the "NRF24L01+" theres an older NRF24L01 (no plus) which I'd avoid except for experiments, they both have the 1M and 2M datarates but the later 'plus' version also does a lower datarate of 250khz which gives more range.
The diagrams below show the essential connections, the rest follows the usual "7ch+S/C" principles, though note some pins have had to be moved. It was very much a make-it-up-as-you-go-along project
There are a few similar projects on the net but I did find what might be a common misunderstanding about the NRF24L01... I noticed that often the author goes to some length to reduce the payload to 32 bits, by limiting the resolution to 8 bits and the channels to 4, 8x4=32. However, this isnt the case, the NRF24 maximum packet size is 32 bytes not bits, so they could have avoided all the downgrading and had 16 or more full resolution channels like we have here. I dunno, is it a misunderstanding or did I miss something?
Cheers
Phil
The remaining connections are similar to the "7ch+s/c" document but with the following pin assignments:
D2 is the DC buzzer
D3 is the minute minder button pin
D4 is the optional faster S/C escapement emulation pin
D5 is the 50:50 Vtail mixer
D6 is the 75:25 elevon mixer
D7 is the throttle-lock toggle
D8 is the pushbutton for s/c compound, & stick calibration
Any 328P board is suitable but for convenience I used an old ebay Redboard for the tranny, by isolating vref with a track-cut the vref pin was in a convenient place for 3.3v to the NRF24, so all its connections are in a row - I used a single 7-way header strip across the seven signal pins. On these headers the pos & neg rows are not used, just 3v3, gnd, and D9 to D13 signal pins:
I quite fancy doing a single-channel 'button' version at some stage, plenty of free time at the moment...
Important (thanks Mike!!!)
I forgot to say, if anyone fancies playing with this do change the pipeOut line in the tx (and the pipeIn line in the rx) to your own unique number, I suggest using the last 5 digits of your phone number, as this is almost certain to be unique amongst our little group.
The 'number' idea is just to simplify addressing, so instead of the usual complicated-looking:
const uint64_t pipeOut = 0xEEEE0000F1LL; // same in rx 'pipeIn' line
we can use:
const byte pipeOut[] = "39965"; // last 5 digits of your phone number, make rx the same
Also, less vital but beneficial, change the channels to six widely-spaced numbers between 1 and 125:
eg in the tx:
/************* Radio config - make it unique! **********************************/
const byte pipeOut[] = "39965"; // same as rx, last 5 digits of your phone number
const byte mychannels[] = {117, 99, 57, 71, 35, 13}; // choose 6 widely-spaced 'hopping' channels
/*******************************************************************************/
and use the same values in the rx:
/************* Radio config - make it unique! **********************************/
constbyte pipeIn[0] = "39965"; // same as tx, last 5 digits of your phone number
const byte mychannels[] = {117, 99, 57, 71, 35, 13}; // choose 6 widely-spaced 'hopping' channels
/*******************************************************************************/
Edit 8/4/20:
Wahoo, after a lot of experimentation I've got a rudimentary but functional form of hopping working.
Its slightly unconventional in that the transmitter is FHSS but the receiver only hops when it needs to.
So overall its not classical FHSS like Werners bjt works perfectly. To explain:
The transmitter reads the joysticks, assembles that data into a packet, then sends the same data on six RF channels in sequence. These six channels are widely spaced through the 2.4g band and no channel has preference.
The receiver sits on one channel and whilst everything is working it stays there. If it loses a couple of packets, it moves to the next channel and so on. At this point it picks up where it left off, but if not it keeps trying the next channel in sequence, eventually scanning the six channels and settling on the first one it finds with a good signal. If you like, as an option on the rx you can add three 5v LEDs on D14, D15 & D16 (A0, A1 & A2) which show in 3-bit binary which channel slot is in use. Or use a TIL311 for a numeric display.
I dont know if this particular channel-swapping concept has a name, someone may have done it before I dont know, I certainly couldnt find anything similar.
Its a little bit like Spektrums DSM2 but with six channels to choose from instead of two. I settled on six after looking on the spectrum analyser, any more than six looks greedy and probably isnt necessary. Spekky were happy with 2!
In practise the single fixed channel is super reliable and I would happily have flown with it, but this should make it even more solid in a noisy environment. I'm really quite chuffed with it
_