Mode Zero

I've lost a bit of impetus with this project so I was browsing around and you know how google suggests stuff to look at based on your recent interests? Well up popped this Elektor article:
http://houseofthings.gr/wp-content/uplo ... _05-06.pdf
...which lists an NRF24L01 R/C system!
and a link to their software:
https://www.elektormagazine.com/files/m ... 408-11.zip

I have to say that whilst its well presented (as is all Elektor stuff) the software is not hugely impressive.
I was expecting something wonderful, but basically it just transmits the positions of 4 pots and a few switches, it has no 'facilities' at all, no mixers, no gizmos, not even failsafe. RF-wise, like my own experiment above, the Elektor set uses just one fixed channel and relies on addressing for separation. It did confirm what I've found on various 'maker' sites that many users are similarly using one hard-coded channel. Theres no check to see if the channel is busy though of course a 'busy' channel doesnt mean its not perfectly usable.

Obviously Werners frequency-hopping is a far superior method, but as a compromise I wondered about a 2-channel (like DSM2) system, which on power-up finds two clear and preferably (unlike DSM2) widely spaced channels, tells the rx what they are, then constantly sends the same packet on one channel then the other, and at first I thought the receiver would also switch on every packet received or on timeout if the packet isnt received on time.
But then I thought, if the rx is hearing good packets on one channel, why switch channels, why not just switch to the other channel only if the first channel starts to drop packets? Keep the tx alternating, but the rx sticks to one channel unless it drops out, when it tries the other channel. It sounds too simple but I'll try it as a compromise. In a nutshell the tx sends on both, and the rx uses whichever channel continues to provide timely data and only changes if thats no longer the case. Its the same principle as my old dual receiver adapter, which worked well.

The first big improvement whilst it still uses one RF channel would be to listen first and choose a quiet channel rather than a fixed, hard coded one. I've made a start, the channel-scanning bit is working.
Then I'll look at the DSM2-alike two channel thing. But I keep wondering is this worth pursuing?

Cheers
Phil

Edit: a further thought, why only 2 channels? why not have the tx cycle through several channels, and the rx 'hops' only if/when a packet goes missing? We could call it DSMthirteen

Later edit: the more channels it sends on, the less theres a need to scan for quiet ones! In practise I'd guess say 10 fixed channels from above the WiFi usage would be a good start. I quite like that idea
Collisions should be infrequent as the MU is so very low, at 250kbps it takes a fraction of a millisecond to send a packet, which happens only every 20ms. I'll try it when my prominis arrive.

Link says cannot find the software but I did find this....same same..??
https://www.elektormagazine.com/magazin ... 1705/40329

Eureka Fixed a library problem that had been bugging me, somehow I'd both NRF24 libraries installed, the Maniacbug one and the (preferred) TMRh20 one.
Deleted both, reinstalled TMRh20, reloaded two nanos with the most recent code and everything is working great. I think I confused the IDE with a mix of the two libraries. Actually this rings a distant bell...

One of the problems was the IDE not compiling library changes, and I found online an easy way to force a 'rebuild all' - change the processor setting from Nano to something different - say 2560 - and recompile. Dont worry about any errors caused by the 'wrong' processor. Then change it back to Nano and recompile. It will rebuild all including the libraries. You learn summat new every day

Meanwhile I've found a couple of NRF24L01+ modules that wont do 250khz. 1M and 2M is fine. Mis-labelled non-plus chips?

bluejets wrote: 06 Apr 2020, 10:43 Link says cannot find the software but I did find this....same same..??
https://www.elektormagazine.com/magazin ... 1705/40329

Thats right Jeff, click on 'Software' about halfway down. Its a zip file. I'll correct the post.

Actually the link is correct, it seems they only allow it if you're coming from one of their own pages.

Use Jeff's link above, then click on the word 'software' on the left just above the PCB photos.
Prepare to be unimpressed though

Cheers
Phil

Hi Phil,
As you undoubtedly already know, those libraries can be a right PIA sometimes.
As one other commented on another forum for Arduino (I think it was) the idea was to find one the one version/type that worked and file it away with the rest of the sketch along with a note to remind one of the reason for doing so.
Do you still have a link to the particular one that worked? (TMRh20?)

Everything is working great, I've tried one of the high-power modules and they work really
well, the 3v3 prominis have arrived so I can make some more receivers, its all good

I've updated the files with some small changes in post #1 - to make it easier & more readable
I've changed the pipe addressing (similar to a GUID) to a five-character string, so instead
of complicated 5-byte hexadecimal numbers we can use the last 5 digits of our phone
numbers, as this is almost certain to be unique amongst our little group.
At the moment its still on one hard coded channel defined as 'mychannel' which you can
change to anything from 0 to 125. More than one system on a channel isnt a problem as long
as each tx/rx combo has different a 'phone number' - though obs its best to move elsewhere.
This is now a stable (if rudimentary) basis to work from, next step in development is to scan
for a free-channel and switch to it. We have progress!

bluejets wrote: 07 Apr 2020, 01:35Do you still have a link to the particular library that worked? (TMRh20?)

I loaded it from Library Manager Jeff. Click 'include library' then 'Manage Libraries' to load LIbrary Manager, enter NRF24L01 in the search box and you'll find it, make sure its the TMRh20 one and click install.
The process is very slow on my PC, dunno why, you need to wait for each screen.


No problems since, provided you force a 'rebuild all' once for every one of your sketches that used the old library. I like Martins method, where the .cpp and .h files are in tabs within the sketch.

I've three complete receivers and two transmitters here, I'm repeatedly testing them and no problems at all since sorting the library problem. The MPX Pico now has a high power module and sports a sassy aerial, the other tx is a loose ebay redboard on my bench for ease of tinkering. Two receivers are the small ones in the photo and one is also a redboard. For now I've used the same pipe address for everything so either transmitter works with any of the receivers. Coolio

Cheers
Phil

Phil, I believe that in the same bag there were as so called Breakout Adapter with on-board 3.3V Regulator for the NRF24 which should allow you to use regular 5 volt & 16Mhz at least in the transmitter if size of the receiver would be a concern.
Cheers
Tobe

Wahoo, after a lot of experimentation I've got a rudimentary but functional form of hopping working.
Its not 'traditional' FHSS like Werners, in fact I'm not sure if this has been done before. 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 band and theres no preference.
The receiver sits on any one of these six channels 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, 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.
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. And I like how you can use any of your transmitters with any receiver. I'm quite chuffed with it
Will upload to the first post tonight.


Hope you're doing ok over there Tobe, strange times although Swedens approach has been different to ours - who knows which will be most effective...
I did use the 5v adapters in some experiments but the Redboard has a proper 3v3 1A regulator so works out quite neatly without. For the MPX Pico I removed the pins from the module and soldered directly:


I've found that the NRF modules do need a good clean 3v3 supply, especially for the high-power ones.
I've seen some projects that use the 3v3 output from a Nano which really isnt up to the job - they seem to rely entirely on a large capacitor to prop up the supply. For those I think the 5v adapters are pretty much essential, and using one would avoid the need to modify the Redboard (repurposing vref as 3v3).

Your box of chips has provided hours of entertainment over here, thank you Tobe

Cheers
Phil

Sounds like DSM6 to me

In the early days of 2.4GHz, the original Spektrum DX6 with DSM, it only used one channel and worked fine. And it was only supposed to be a "park fly", but I used mine in a glider to near out of sight without as much as a glitch. In a quiet rf environment (like most of our flying sites that are quite remote) I'm certain you'd be OK with it as it is, though I might not initially trust it with a large heavy model.

With all of this, FrSky soon to be doing a DIY module again (XHT module - See Stuart's post in the modules section) and I've been test-flying a Spektrum DX4e module with my encoder for the last few days, we'll soon be spoilt for choice.

Mike

Phil_G wrote: 08 Apr 2020, 12:36 I've found that the NRF modules do need a good clean 3v3 supply, especially for the high-power ones.
I've seen some projects that use the 3v3 output from a Nano which really isnt up to the job - they seem to rely entirely on a large capacitor to prop up the supply.

Yes indeed! Due to the nature of the RF transmission, the power supply sees a huge swing in load: from a few microamps to suddenly 130 mA.
I usually add a 47uF/6.3V Polymer electrolytic cap directly across the power supply on the module.

Recently I designed my own PCBs. I added a separate 3.3V regulator just for the RF module (belts-and-braces approach). Just a few cents costs providing a piece of mind.

Also important: don't run the module without antenna attached, as the output amplifier may get damaged.

happy transmitting, Werner

I remembered I had some 45-year-old (yes!) TIL311 hex displays, ideal for a channel slot display instead of those LEDs. This is just for my own interest on the test receiver which is an ebay Redboard so plenty of room, the tiny receivers dont get or need a display

We 'upgraded' to these in the old 'switch & LED ' days of early homebrew microprocessors.
They were excruciatingly expensive but really neat. I've two of these on my old homebrew SC/MP system that runs Kitbug and NIBL, still works after decades in the loft
Incidentally they are still widely available either used or as a DIS1417 modern equivalent... I remembered I also used two on a 45-year-old motorola M6802 homebrew micro, it still works, it has a homebrew monitor as I didnt like Mikbug... when in the monitor the two TIL311's say: '1C' for 'input command', '1A' for 'input address' and '1D' for 'input data', '1B' for 'input breakpoint address'...
Did you find the retro computing section on here Werner? theres a lot of interest in old gear, the BBC are even running Micro-Live again!

The 'poor mans FH' set up is working really well, I just wish I could try it down at the flying field The best bit is watching the TIL311 display scanning...