Mode Zero

Phil, there was no offending code, and your question is certainly relevant and pertinent, especially given Mike's and my recent quiet spell.

Mike and I share similar backgrounds, though in different fields. Our combined experience allows us to take projects from concept to finished product, and we both understand the importance of working within established rules and regulations. We share a drive to push boundaries and measure our achievements against commercial products, always looking for innovative approaches.

Like you and many of us, we tackle projects based on what we need or want to achieve. It's personal stuff, and each of us decides if and how much we want to share with others.

In workshops everywhere, there's this familiar cycle - developing, building, testing, and yes, sometimes things don't work out, but sometimes they do. Those setbacks are just part of learning, and since we all come from different backgrounds, we naturally approach our projects in different ways.

My background as a product developer, working with different teams and disciplines, shapes how I handle any project - whether it's work that pays the bills or our shared hobby. Working across different fields has taught me that collaboration is essential in thinking things through and planning ahead, which naturally carries over into my hobby projects.

These professional habits stick with me - breaking down problems, trying different approaches, learning from each step. While this comes from my work experience, it's proven just as useful in our hobby world. It's great to see how everyone brings their own expertise into their projects, making our community richer with different ways of solving problems.

I really enjoy seeing how others tackle their projects differently. Everyone's background, whether in engineering, crafts, arts, or anything else, adds something valuable to our community. And while Mike and I tend to challenge ourselves by aiming for commercial-grade quality and innovative solutions, we recognize that every approach has its own merit and adds to our collective knowledge.

Enough of this and let us go back to what is going on, let me introduce you to the next generation of MiTo transmitters, you have probably seen the new
viewtopic.php?f=27&t=1914

...but of course there is a more Mike&Tobe version!

Here comes the MiTI MKII that match the above RX
....and for those going light there is a mini version:

Thoughts.
Some of the points Mike has raised about compliance are definitely valid and parallel my own thoughts for a "version 2" which has been simmering for a long time, in fact bits of it have been flying for over a year. The legality of homebrewing has been uncertain since the introduction of 35Mhz, its never bothered me before but we should at least be compliant, even if untested. To this end there are some of Mikes developments where we've both unknowingly coincided, some I'm not sure about, and some I'm actually at odds with.
To explain:

I'm open to correction but as yet I'm not convinced LBT is in itself a better way of complying than by simply keeping the MU below 10%. although Mike now does both, which is great.
The NRF in particular is I think less than ideal for LBT for a few reasons:
It can be happily operating on a channel with signals from -64db right down to -94db, when another NRF declares the channel 'free' and transmits over it, because the NRF only has a one-bit busy/free threshold fixed at -64db.
More generally, the occupier of a channel deemed 'busy' could be a couple of miles away with little possibility of mutual interference.
LBT uses an instantaneous sample taken just before transmitting, and a 'busy' channel could well be free a microsecond after sampling - or busy a microsecond after being declared 'free' causing a collision in an LBT environment
A theoretical situation where theres -63db of noise across the entire band would be perfectly flyable with a non-LBT system, whereas LBT wouldnt find any free channels. Other systems can choose the relatively quietest of the channels - not so the one-bit, 'busy or free' NRF.
The CRC provides collision detection whether LBT or not and in practise, measured throughput in a busy RF environment has been extremely high.

Mikes early mods to the lockdown project were only configuration changes rather than code updates - extending the hopping array, reducing packet size, changing a timer value, a 3-byte pipe - whilst effective in achieving compliance these are all just simple configuration changes rather than software developments. Throughout, I've had some of my own "version 2" ideas in the pipeline, the NRF project was a learning exercise and there are definitely things I'd do differently had I known what we've learned along the way. Simple things, like the payload size - my initial thought on reading the datasheet for the first time was 'wow we can have 16 channels or more!' rather than any compliance thoughts. I'd seen the option to reduce the payload size option early on in the project but too late for the many receivers I and others had built which were regularly flying, reprogramming would mean disassembling them so I left things be - it works perfectly as it is, with many in regular use. However, with the recent advice from the BMFA and this peer-pressure its time to press on.

Version 2 (most of which I've been flying for a couple of years) has 6 propo plus one or two switched channels, with model memory in the receiver as usual saving mix, reversing & trims. To reduce packet size I also use byte stuffing but using a different method to Mike.
I will never need 8 propo channels and transmitting a second aileron channel is pointless if you're trying to reduce packet size - the receiver can do the second aileron including any differential, crow etc. Retaining the 5ms repetition rate gives an MU of 9.6%, compared to the old 25% (coincidentally FASST was 25% MU) I intend to keep the fixed GUID/hops idea as thats my preference over a 'bind' exchange, it suits me and the way I mix models & transmitters.

Mostly our parallel development paths have coincided, but there are of course areas where we dont concur. Mike says:

Mike wrote:Further investigation found that the nRF24L01+ uses a stop bit after transmitting every byte, so it “transmits” 9 bits, not 8 for every byte. Now my measurements agree with the calculations allowing for measurement errors.

This isnt my understanding, the RF output transmits a continuous bit-stream from the FIFO with no encoding, just simple bit-by-bit GFSK. It literally clocks the contents of the transmit FIFO out a bit at a time as a shift-register, there is no inserted 9th 'stop' bit. Before posting this contradiction, I thought I'd better double check so submitted a ticket to Nordic (I have a Nordic DevZone account) and they confirmed, there are no extra bits, all MU calculations should be done using only the actual number of bits assembled into the packet, ie 8 bits per transmitted 'byte' (again, its really a bit-stream rather than separate bytes). Consequently I think all Mikes MU calculations are a bit overstated (by 9/8). Off the top, I wonder if the scope envelopes are stretched by too large a capacitor on the microwave diode?
I cant agree that reducing the packet repetition rate will increase range because there are fewer packets to be clobbered in the ether.

One significant difference in our approaches is that all the way through development, to maintain a conversational, friendy thread and to encourage others to join in, I have always shared my code. Mike & Tobe haven't, so I cant help but feel the disparagement (shown in the previous posts and in the 5 posts following this) is a tad one-sided. I find it quite discouraging.

Further thoughts:
Polar-opposite to the machine-gun approach, I've been thinking of a 'delta' system that only transmits changes and only when there is a change. If the sticks arent moved, there is no reason to send anything, other than a relatively infrequent short heartbeat packet so we can use that for failsafe. The MU in flight would be tiny.
Alternatively I had in mind a delta system transmitting at the normal rate but where a lower resolution delta change is transmitted which contributes to a cumulative high resolution channel value at the receiver. Theres plenty of time for several packets to convey even a limit to limit change in one frame. A third idea was incremental resolution, where large stick movements are converyed initially at low resolution, then moved to their final position at high resolution in a following frame. Idle pondering at the moment.

A far as Nordic are concerned, the NRF is obsolete. But its cheap, its easy to DIY and in almost 5 years exclusive flying I've a lot of faith in it.
Theres a reason its one of the most cloned chips on the planet. Having had my 5 minutes on the soapbox however, I'll slink away now.

Cheers
Phil

I'm happy to stand corrected on the nRF24 rate calculations using 8 bits, not 9 bits, I didn't read it from an official Nordic site and I was just trying to match what I measured with theory. My test gear was fairly primitive, one microwave Schottky diode, one cap and a loop of wire, a total cost of around £1 and definitely not calibrated. If it is over-reading, then thankfully I'm on the correct side of the 10% MU, which is what I was trying to achieve. However, it served its job of approximately measuring the MU percentage and determining something was amiss from my initial calculations.

I agree 100% that a lower rate doesn't give a longer range. From my tests what does give a longer range is a shorter packet. I used a shorter packet but still had to keep <10% MU, I went to 10mS to ensure I complied. I found a shorter packet (17 bytes total) at 10mS rate gives a better range than a longer packet (40 bytes) at a 5mS rate. Obviously, if you can make the packet <0.5mS, so you can send packets every 5mS, it may give a better range but didn't in my tests.

To get down to a 5mS transmission rate, I tried using two separate packets, one for channels 1-4 and another packet for 5-8, transmitting them alternately, then I could transmit every 5mS, but this didn't improve the range, so I dropped it. Maybe in a noisier environment, it would have increased the range?

To get to a packet rate every 5mS and comply with <10% MU, you have to have a packet that transmits =<0.5mS. Therefore compared to my 8-channel setup, the packets have to have less information, either splitting the data into two or more smaller packets or packing the data at a lower resolution, I'm using 10 bits, you could go down to 8 or 9 bits for 256/512 resolution, (Futaba/FrSky use 11-bit s-bus to give 2048 resolution) or fewer channels. I wanted to keep 8 channels @1024 resolution so I don’t think you can go below 17 bytes with nRF24L01+ overheads (without splitting data across 2 or more packets) so the minimum transmission time is 17 * 8 * 0.004 = 0.544mS, so I could never have a 5mS packet rate, I’ll stick to 10mS as it works nicely with the Rx timing, outputting servo channels 1-4, receive a packet (@10mS) output channels 5-8, receive a packet (@10mS) and repeat - I don’t use the Arduino servo library this way 4 servo channel outputs fit in nicely between each received packet and if packets are lost everything keeps in sync with the transmitter timings.

The nRF24L01+ RSSI sucks, as mentioned, it only has a Boolean signal/no signal @64dB. I agree that LBT is not a better method than MU to comply, just different. Many commercial protocols use LBT to comply as it was an easy “add-on” to an existing protocol that pre-dates the latest EU regulations. Just use the original protocol, add LBT and it complies using the same packet repetition rate.

I didn't add LBT to comply, I was already complying using MU <10%. I added LBT to try to improve the number of received packets in a busy environment. To receive a signal @ >64dB with our nRF24L01+PA+LNA, the other transmitter has to be fairly close, probably like when a group of you are flying together. If a transmitter is transmitting, if it detects the channel is busy, it delays transmitting until the other transmitter has finished and then sends the packet, as long as it's still within the 10mS “window” before the next packet is due to be sent. Is it worth doing? I think a delayed packet is better than transmitting blindly, getting an rf collision and therefore neither of you receiving a packet. But if you are flying on your own or in a small group, then there is little point in implementing.

Another thing I’m not certain about other R/C LBT protocols, is if the intended channel is busy, do they delay transmission or just not transmit at all? By delaying and using small packets I hope I’m getting the best of both LBT and MU worlds.

The other feature I added I don't think I previously mentioned is a reduced power “Range Check” test. A range check first appeared in the BMFA handbook and CAA CAP658 in 2012 (I think), so has been a legal requirement and not a “nicety” or optional extra for over 10 years and my local club has had the requirement to range check every flying session (though we sometimes overlook this…) since its inception in the 1980s. And walking up the road two miles is not considered a satisfactory method, even if it is important during development.

Finally how I implemented 41 channels is not just a parameter change in my opinion. I did not choose 41 channels pseudo-randomly as then you could get the same channel repeating more than once in each sequence. I start with 41 channels (1-41), pseudo-randomly “shuffle” them (like you would shuffle 52 cards in a card pack) using the pipe address as the seed, doubling the values to get channels in the range 2-82, then pseudo-randomly adding 0 or 1 (unless its 82), so I finish with 41 channels in the range 2 to 82 with no duplicates and a mix of odd and even channels. Channel 1 has been “reserved” for binding and I don’t use channel 0 or 83 to keep a buffer at the end of the frequency ranges. At binding it uses channel 1 with a fixed pipe-address so any Rx can be bound to the Tx. All that is exchanged is the shared pipe address, the Tx and Rx will generate the same “hop sequence” from the same pipe address. You could choose the 41 channels manually, but why do it manually when a microcontroller can do it? I chose 41 channels as a compromise between a fast initial connection from power-up and as many channels as possible, and 41 channels fitted well into the 84 available legal channels of the nRF24L01+ (0-83 = 2.400 - 2.483)

Hi Phil

I wrote This test program to pack the 8 channels into 10 bytes at 10-bit resolution and then unpack them again and use the serial monitor to ensure it was working as expected. It was then used in the Tx and Rx to shorten the transmitted packet. Feel free to adapt it for your own use.


If you have 7 channels and are happy to use 9-bit resolution, the channels could be packed into 7*9 = 63 bits, in a similar method to what Tobe and I do. Therefore you would pack it into 8 bytes and have one bit spare. That spare bit could indicate fail-safe, so you wouldn't need a header byte like I have to use. If you used a 3-byte pipe address like Tobe and me, you would transmit a total of 8+6=14 bytes = 14 * 8 * 0.004 = 0.448mS, so yes you could keep using 5mS rate and keep below the 10% MU and not lose any resolution as the resolution from a joystick connected to an Arduino is usually around 200 to 280, as the joystick only moves around 60 degrees of the potentiometers total 270 or 300 degrees (depending on the joystick mechanics and the pot used).

And here is the test program I wrote to test the 41-channel pseudo-random "hop sequence", it prints them out via the serial monitor, but just use the function in the Tx/Rx without the serial output.

All you have to do is have the same pipe address in the Tx and Rx, the function takes care of the rest, a lot easier than doing it manually. And if you want to know what channel sequence your Tx/Rx is using, just run this program with a serial monitor and they will be printed out.

It obviously can be modified to work with a different number, 41 worked well for what I intended, but you could use any number, but then it would not be so simple to just multiply by two ie 41*2 = 82 which is near the number of legal nRF24 channels. You could use 20 hops and times by 4 = 80, or keep 16 hop channels and use a map() function to get back to 83 or whatever, but that is just complicating things.

At the end of the day we all have our own preferences, ideas and views to achieve a similar goal. It's great that so many other modellers are enjoying building and flying our widgets and long may it continue

Did some math around my version for nRF24_FHSS, so this is based on my code with the packeting as Mike with failsafe flag for 8 channels:

NRF24L01+ Single Packet Transmission Timing Analysis
1. SPI Communication (Pre-transmission)

SPI Clock: 8MHz
Command bytes to NRF24: ~10 bytes
Time per byte: 1µs
Command transmission: 10µs
Mode switching delays: 90µs
Total SPI Setup: 100µs

2. NRF24 Internal Processing

TX FIFO loading via SPI: 50µs
Packet Assembly:

Preamble (1 byte): 32µs
Address (4 bytes): 20µs
Control field: 10µs
TX settle time: 40µs
Total Internal Processing: 150µs

3. RF Transmission

Payload: 17 bytes = 136 bits
Data rate: 250kbps
Calculation: 136/250,000 = 0.544ms
Total RF Time: 544µs

4. Post-transmission Processing

Status register read: 10µs
Flag clearing: 10µs
Mode switching: 80µs
Total Cleanup: 100µs

Total Theoretical Minimum Time
CopyPre-transmission: 100µs
Internal Process: 150µs
RF Transmission: 544µs
Post-transmission: 100µs
------------------------
Total: 894µs (0.894ms)
The total theoretical minimum time for a single packet transmission is 0.894ms under ideal conditions, not accounting for any environmental interference or retries.