Kraft 2 - Sport Series homebrew FHSS conversion

[Phil_G]

This Kraft 2 was kindly donated by Mel D, thanks Mel !
As a sport flyer I'd always liked the look of these simple sets but here in the UK they were seldom if ever seen - at the time we were all Skyleader, Fleet, Waltron, Macgregor, Horizon, RCS etc. This one is in great cosmetic and mechanical condition for its age (45 years?) but as 72Mhz is not a legal band over here, I've used the homebrew 'lockdown' FHSS project to convert it to 2.4ghz. I took the opportunity to add a "+1" sequential throttle channel though I rarely fly anything but gliders - the big advantage of this project being that I can fly any of my models with any of my transmitters without changing or selecting anything. With 2 channels its absolutely perfect for sport slope-soaring. As soon as the weather permits the Kraft 2 will be out on the slope, most probably (of course!) guiding a Veron Impala.







Here are the homebrew FHSS threads, all use my 'lockdown' FHSS core on the NRF24L01:
Propo & background story: viewtopic.php?f=42&t=971
Talisman: viewtopic.php?f=27&t=1043
Cannon: viewtopic.php?f=42&t=971&p=15700
Reeds: viewtopic.php?f=26&t=1909
S/C button: viewtopic.php?f=42&t=968
RS Navigator: viewtopic.php?f=24&t=1032
OS Pixie: viewtopic.php?p=8332#p8332
One-plus-one: viewtopic.php?f=42&t=1782
Two-plus-one: viewtopic.php?f=27&t=1885
Flight-Link 'Duette': viewtopic.php?f=27&t=1547
Smallest Transmitter: viewtopic.php?p=5591#p5591
Receiver: viewtopic.php?p=15761#p15761

[Phil_G]

In the FHSS Reeduino thread I suggested an easier way of mounting the 3v3 regulator onto the NRF module, by simply not removing the two power header pins and mounting the regulator on the other side to the can. Shaun did his FHSS Reeduino this way and did find it much easier.
However for some weird aesthetic reason I prefer the regulator on the can side which means removing all the header pins including the power pair.
Of the eight header pins they're the most difficult to remove since the ground-plane sucks the heat away, but it can be done without too much trouble.
Clearing the two power holes of solder so they will accept two pins on the can side is for the same reason more awkward.

However...
For my retro computing projects I use these thinner round header pins, designed to fit turned-pin sockets. Being thinner and round they need much less clearance and so make the task of mounting the regulator can-side much easier:

This how the Kraft 2 is done and I must say it was much easier and quicker. How I wish they would just stop fitting header plugs, also the DIYMore boards are only available pre-soldered with headers now and they're not even soldered straight. Its a real pain & I just wish they wouldnt!

[GardenGate]

Hi Phil:
Cool to see this conversion; I just received a very similar Tower Hobbies 3 channel which I intend to convert to 2.4 Ghz so this post is good inspiration!

Couple of questions:

• NRF FHSS RF usable range - I see you've done and flown whole bunch of units - have they all been park flyers or slope airplanes, or have you used them in any thermal soaring applications where range might be more challenging as the glider specks out in a thermal? Of the different recevier designs, have you found one having better effective range than the others?

• NRF FHSS and vintage encoders - I see in your nice comprehensive PDF summary document that you use them with your DIYMore Pro Strong Mini encoders - have you (or anyone) used them with the PPM coming out of a vintage encoder? Other than making sure the vintage encoder's signal is not putting out too much voltage, are there any "gotchas" or other considerations I should be thinking about?

Thanks!

[Phil_G]

Hi Bill,

Couple of questions:

• NRF FHSS RF usable range - I see you've done and flown whole bunch of units - have they all been park flyers or slope airplanes, or have you used them in any thermal soaring applications where range might be more challenging as the glider specks out in a thermal? Of the different recevier designs, have you found one having better effective range than the others?

All I can say is that I've range tested them on the longest straight road I could find which is just over a mile, 100% reception.
Initially I'd done a quick range test nearer home and ran out of space at 700 metres, again 100%
http://mode-zero.uk/viewtopic.php?f=42& ... t=10#p8017
...but... these are all single-receiver, single antenna tests, it has no diversity. I could resurrect my old dual-receiver adapter (as stolen by HK!) but for sport flying its not been necessary. I can only give a definite answer based on my own findings but you'll find many youtube videos showing NRF modules at ranges of several km!

• NRF FHSS and vintage encoders - I see in your nice comprehensive PDF summary document that you use them with your DIYMore Pro Strong Mini encoders - have you (or anyone) used them with the PPM coming out of a vintage encoder? Other than making sure the vintage encoder's signal is not putting out too much voltage, are there any "gotchas" or other considerations I should be thinking about?

I use the same physical DIY-More board Bill but its different software on there, I deliberately avoided PPM as the concept is that apart from reading the sticks, its digital end-to-end. If you're replacing the encoder in an old set, why would you use PPM encoder software rather than the FHSS encoder, and have to decode the PPM again before driving the NRF? Pure digital was the intent from the start
However...
Once you've posted into the public-domain these projects take on a life of their own and Mike has in fact done a PPM version, Tobe has done a PCB for it, but persoally that wasnt a direction I wanted to follow, and since then as can be seen in recent posts both Mike & Tobe have moved on to greater things so I dont know if they continued with it For me, these projects start as a learning adventure for personal interest, and if they generate sufficient curiosity for someone else to try them then thats a huge bonus for which I'm always grateful even if they diversify outside my own interests. Quite a few have given this one a whirl, though fewer than with the more conventional PPM encoders.

Above all I dont want to complicate it, in its current form its a simple system that is easy to assemble, that anyone can understand, works well, & has some unique features which are particularly useful to Retro R/C fans. Ok its not Jeti but as a cheap-as-chips DIY project its been well flown with 100% reliability for over 4½ years now It hasnt escaped criticism regarding power levels, hopping sequence length, MU, packet size, etc but I made reasoned decisions at the time (happy to discuss by PM). With hindsight of course there would be some things I'd change, but it is, like most things, what it is...
Cheers Bill
Phil

[Mike_K]

Once you've posted into the public-domain these projects take on a life of their own and Mike has in fact done a PPM version, Tobe has done a PCB for it, but persoally that wasnt a direction I wanted to follow, and since then as can be seen in recent posts both Mike & Tobe have moved on to greater things so I dont know if they continued with it For me, these projects start as a learning adventure for personal interest, and if they generate sufficient curiosity for someone else to try them then thats a huge bonus for which I'm always grateful even if they diversify outside my own interests. Quite a few have given this one a whirl, though fewer than with the more conventional PPM encoders.

A belated Happy New Year to All, my R/C projects are only now starting up again after the Christmas holidays and I'm catching up with what has been happening on the forum for the past few weeks.

Yes, Tobe and I have done a lot more development with a nRF24L01+ protocol, albeit using a Tobe-designed “ppm in nRF24L01+ protocol” module used together with my multi-model LCD encoders, not a combined encoder/nRF24L01+ transmitter. The first transmitter I used for development was the homemade “MiTo” set (MiTo = Mike/Tobe), with Tx, Rx and servo’s built by Tobe using my encoder design, module firmware and servo firmware, with the 2.4GHz protocol based on the original.

viewtopic.php?p=14166#p14166

There are so many modifications to both the Tx and Rx. I'll publish it in a few posts, each with the modification and why. I don't plan to publish the code until I'm complete and then only if Tobe is planning to sell his modules, otherwise the code has no easily made hardware.

Tobe's nRF24L01+ ppm in module next to a LemonRx for size comparison

Development One

Before I started using the “MiTo” transmitter I wanted to ensure it would be EU-compliant with EN 300 328 V2.2.2. There are a number of ways a transmitter can conform, those commonly used by R/C are:
1. “Frequency Adaptive” (LBT - “listen before talk/transmit” in R/C parlance) as used by Futaba, FrSky and others
2. “Medium Utilisation” ratio where you can only transmit for <10% of the time as used by Spektrum
3. Transmit at low power (<10mW effective) as used by most brands of R/C telemetry receivers

The original protocol is not “Frequency Adaptive” (i.e., it does not use “LBT), so it needed to conform to the “Medium Utilisation” and transmit less than 10% of the time if transmitting at 100mW (“MU” is analogous to the duty cycle in PWM). The eBytes FCC certification for the nRF24L01+ module confirms 100mW EIRP when used with the supplied 2dB gain antenna.

I haven’t got a spectrum analyser to check the 10% “MU”, so I built a simple 2.4GHz monitor, basing it on an RCgroups rf field strength monitor using a 1N5711 high-frequency Schottky diode, but rather than fit the output smoothing caps to feed a meter, I used a small pF cap and monitored it directly on my scope, the packets are visible as an envelope.

https://www.rcgroups.com/forums/showthr ... ter-for-rc

I found the protocol was transmitting for just under 1.5mS (with 8 channels) which is non-conforming (to conform with a packet every 5mS, the packet length/transmit length should be < 0.5mS). I was confused as to why it was transmitting for so long, my calculations suggested it should be shorter, albeit still non-conforming:

250kbp and 16 bytes data + 8 bytes nRF24 overhead should have been 24 bytes = 192 bytes @ 250kbs = 192 / 250,000 = 0.768mS
To check my rf monitor was working correctly, I also monitored the input power to the nRF24 module with a small shunt resistor, assuming it takes more power when transmitting and it agreed with the rf monitor within a few per cent. What was going on? After investigation, I found the two reasons my calculations didn’t tally.

The nRF24 Arduino library used to control the nRF24L01+ makes it much easier than writing directly to nRF24 registers, but it does set some defaults that are not ideal. The main issue is when a packet is transmitted, by default it contains 32 bytes of data plus a one-byte with the packet length, a 5-byte pipe address and a 2-byte CRC. So if 8 channels are transmitted, it still transmits 32 bytes of data (40 bytes total), not 16 bytes of data (24 in total), assuming 2 bytes are needed per channel, the other 16 bytes are null.

There is a setPayloadSize() command and if set to 16 in both the transmitter and receiver, the transmit timing dropped, but still not quite to my original calculation. 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.

So with the original protocol, the actual figures are 32 bytes data + 8 bytes nRF24 overhead (1 byte header, 5 pipe address bytes and 2 byte CRC) = 40 bytes packet @ 250kbps (each byte transmitted as 8 bits + 1 stop bit) = 40 * 9 * 0.004 = 1.44mS transmitted every 5mS.
The “medium utilisation” for the Phil_G’s protocol is 1.44mS / 5mS = 28.8%.

When the setPayloadSize(16); instruction is added to the code (for both the Tx and Rx), “only” 16 data bytes + 8 nRF24 overhead = 24 bytes transmitted (for 8 channels), transmit time is: 24 * 9 * 0.004 = 0.864mS. So I modified the code to transmit the 16 bytes of data every 10mS and the “medium utilisation” is now: 0.864mS / 10mS = 8.64% so it conforms. As the Rx LED flashes at half the rate to the previous, I halved the count to flash, so the Rx LED appears to flash at the same rate.

These alterations were done before the Ponte 2023 meeting where Tobe displayed the MiTo home-built transmitter, receiver and servos, but had not been flown at that stage.

Before test-flying the modified protocol I did a range check and did it back-to-back with another “Tobe nRF24L01+” transmitter using the original protocol. I assumed the range would be adversely affected as we were only transmitting packets at half the original rate (10mS instead of 5mS), but to my surprise, the “range test” distance increased from 68 steps to 72 steps (that highly scientific unit of length, a “step”). I changed the MiTo back to the original protocol and the other transmitter to the modified protocol and the increased range check followed the modified protocol with the same results. Tobe reported the same increase in range.

The answer as to why the range would increase is because the packet length is roughly half the size/transmit time and it is less likely to suffer interference and/or an rf collision. The nRF24 uses CRC checksums and if just a single bit is lost or corrupted, the CRC check will not match and the whole packet is discarded, so the shorter the data packet the more chance of a packet getting through, even when only transmitted half as often. So I then made efforts to reduce the packet size further to see if the range would increase.

Many are worried about the original code transmitting outside of the legally permitted frequency range, yet don’t seem bothered about conforming to other regulations, which I can’t understand, especially if the firmware modifications make the transmitter protocol have a greater range.

This only needs two lines of code changing in the Tx and three lines of code changing in the Rx to get a compliant system that performs better, well worth the effort.

[Mike_K]

Development 2

At this stage I decided to start afresh with the Tx and Rx programs, to organise the code how I prefer, not based on others' work we just all have our own preferences.

The first thing I tried was to “bit pack” the 8 channels/16 bytes into 10 bytes, using a 10-bit resolution, a similar concept to Futaba s-bus (but that uses an 11-bit resolution). If using an ATmega encoder, the maximum ADC resolution is 10 bits, so it seemed wasted to use a higher resolution. My encoders have ppm in the range 900uS to 2100uS, if these values are represented by values in the range 0-1023 when two bytes are used, the most significant 4 bits are always zero. If the bits are packed together, the 8-channels only require 10 bytes, not 16 bytes.

The original protocol adds “2000” to the ppm values to signify “set fail-safe”, I’ve used a header byte with 8 possible bits to set, including the fail-safe. So we now have 10 data bytes + 1 header byte + 8 nRF24 bytes = 19 byte packet. Transmit time is:
19 * 9 * 0.004 = 0.684mS transmit time. If a packet is transmitted every 7mS the “medium utilisation” is 0.684/7 = 9.77%, but I still transmitted every 10mS as I didn’t want to make too many changes at once.

The range test slightly increased again, up to 74 steps, it looks like the shorter the data packet, the better the range and the more resilient the link. So further efforts were made to decrease the transmitted packet size still further.

[Mike_K]

Development 3

When I had been reading the nRF24L01+ datasheet, I noticed there was an option to use a 3-byte pipe address, instead of the 5. This still gives us over 16 million unique addresses, 2^24 = 16,777,216. Don't forget we don't have to use just numbers, but any ASCII value can be used, so 0xABCDEF is valid as well (0x signifies a hex value).

We now have 10 data + 1 header + 6 nRF24 bytes = 17-byte packet. Transmit time:

17 * 9 * 0.004 = 0.612mS transmitted every 10mS. Utilisation = 6.1%.

The range improved to 75 steps at home and 76 steps in the field, a small but still measurable increase in range again.


Development 4

The next step was to use more “hop” channels, I decided to use 41 hop channels spread over the legal range instead of the 16. And rather than try to work out 41 channels manually, I use the pipe address as a “seed” to a pseudo-random generator to sort the 41 channels into a pseudo-random order, the same pseudo-random order is generated in the Tx and Rx. Also, each channel at random has either a 0 or 1 added to the channel number, so there is a good spread of channels, both odd and even used.

Yet again there was a small increase in the range when tested at home up to 76 steps, but no increase when at the flying field which was the same 76 steps. The only theory I can put forward is that there is more 2.4GHz “noise” at home from wifi, Bluetooth and other 2.4GHz equipment.

Development 5

Next, I decided to add LBT. The nRF24L01+ can do “LBT”, the RSSI (received signal strength indication) is a simple binary signal/no signal (set at -60dB). If it detects the intended channel being used, there is no point in transmitting as there will be a “collision” and you would lose the packet anyway. Most commercial R/C sets have packets <3mS, so rather than not transmit, I poll the channel and if it clears within 7mS, you still have time to transmit before the next packet was due to be transmitted (10mS from the time the original packet would have been transmitted). A “delayed packet” flag is set in the header so the Rx does not try to synchronise timing with it. I was hoping it would increase the range, but it didn’t, but theoretically, it should increase resilience to other transmissions in the 2.4GHz band.

Every change needs a corresponding Rx firmware change as well, so the Tx and Rx code and protocol bear no relationship to the original code/protocol.

Development 6

Next, I wondered if I could further improve the Rx firmware. I started with the synchronisation and reconnect times. The original protocol assumes after only missing 7 packets that we need to go back to the “initial” channel and wait to reconnect. Assuming that both the Tx and Rx have xtals, their timing is accurate enough to be able to keep in sync far longer, up to and beyond the failsafe time out after 2 seconds. The code resyncs every time another packet is received (as long as it was not a delayed transmit), so the Rx should always be in sync and only need to go into the “wait at the first channel” if the Tx power is cycled on-off-on which should never happen while flying or loss of signal for 2 seconds.

The original protocol is very fast at connecting from power up as it cycles through its 16 hop channels in 16*5=80mS, so on average will reconnect in 40mS and a maximum of 80mS. But in my opinion, it “disconnects” far too quickly after only missing 7 packets. It’s a compromise about how likely you are to turn your transmitter off during flight against getting a fast initial connect time. I know when you turn on a Futaba FHSS, it can take 2 seconds to connect, but if you shield the Rx with tin foil so it loses signal, it gets going again immediately when the shielding is removed, it never actually loses its sync. In my opinion, the original protocol gives up sync too quickly but resyncs rapidly masking the issue. Which is better? I think on balance that the Futaba method is preferable as now I have 41 hop channels, my power-up connect time can be up to 41 * 10 = 410mS max (205mS average), which is still rapid, but slower than keeping in sync. So the protocol keeps looking at the next channel until failsafe after 2 seconds of no packet received, then it goes to the initial “wait” channel.

Development 7

I have taken the "start-up" another step. What if the initial “wait” channel is blocked, such as an analogue video sender or other continuous rf noise on it?

The Rx doesn’t need to wait at the same initial “wait” channel forever, why not move to the next channel in the hop sequence after the time for 42 hops (all the hop channels + 1) if no packet has been received, that way you should sync at the initial channel if possible, if not move on and try the next channel in the hop sequence. So if no packets are received, it “slowly” works through the channels every 42*10=420mS and goes through all the channels. In practice, if you turn the Rx on first and then the Tx, it still appears to connect instantly, no different to the original protocol, but you know if some channel(s) were blocked, it should still get synchronised and working, as long as there are some channels free.

To prove this could happen, I made a “2.4GHz channel jammer”, using an nRF2401+. It effectively continuously transmits on a single channel (1MHz bandwidth), looping around transmitting 32 bytes of data and immediately transmitting the next, there is only a very small gap, shorter than an R/C packet. I set it to the “wait channel” of the original encoder protocol and it blocks it quite effectively. The original protocol could not connect from power up, but if powered up before the jammer, it connected and then happily skipped past the jammed channel. My modified protocol starts as if the “jammer” wasn’t there. Is it needed in the real world? Probably not, but the code costs nothing and it does give you a little more security.

[Mike_K]

Tobe has been busy too, developing in parallel, though I did help him on his way by sharing the “pack bytes” and “41 pseudo-random channel selection functions. Rather than manually setting the pipe address, Tobe has used the unique serial number of the ATmega (every ATmega has a unique serial number programmed at the factory). He then binds the Rx to the Tx similar to every commercial set, this has the benefit that the same program can be used on every Tx, you don’t have to individually set the pipe-address (or the hop code). Then there is only one Rx program as well.

He has also made a simple “ModelMatch” using spare inputs on the module to indicate different models, which then bind to the Rx with a different code.

Future Developments

Next on my list is:

Talking to the nRF24 module via serial, not PPM, it will then be digital from the encoder joystick ADC to the servo

An equivalent to Spektrum “ModelMatch” will be added, and the serial data will include the model number in the header byte. This would then ideally require binding the Rx to the Tx, something Tobe has already accomplished.

Dual diversity for the transmitter and receiver, using two nRF24L01+ modules in the transmitter, transmitting alternately and two in the receiver both working together, one on the SPI port, the other on the second SPI port (Atmega328P have two SPI ports, the second uses the UART).
Add telemetry, initially just Rx voltage and RSSI (using the method suggested by Martin using a missed packet counter and reporting a percentage based on missed packets and the nRF24 RSSI flag).

But is the nRF24L01+ the correct chip to be basing our R/C protocol on? The TI CC2500 family are much more flexible and feature-rich, it’s probably why so many manufacturers use them (FrSky, Futaba, HiTec etc). But there is also the Semtech-based ExpressLRS protocol which is EU compliant and seems to outperform FrSky and Futaba, so is it really worth doing our own protocol when ExpressLRS is open source?

Tobe is playing with LoRa at 868MHz and 433MHz. Dual 2.4GHz and an 868MHz backup would put us in the same league as Jeti, FrSky and PowerBox and ahead of Futaba and Spektrum on rf diversity. It’s probably a bit much for the models I’ll be flying with the MiTo, but if it’s possible, we will probably try, just for the fun of learning.

So in summary, with a bit of effort, the original protocol has morphed to become more resilient, keeps sync for longer, has a very fast re-connect time compared with most commercial protocols, is slightly more power efficient, and most importantly I think it’s EU compliant if it was ever tested. It's now a near-commercial system.

[Mike_K]

Oh and I nearly forgot Tobe's latest nRF24L01+ based full-range Rx, it has an onboard sounder that alarms on loss of signal (failsafe) or low voltage. The sounder is a diminutive smd 5mmx5mm (the square component just to the right of the servo connectors at the bottom and just above the onboard bind switch). I first used it on one of my forthcoming encoders and Tobe had the brilliant idea of using the same sounder for the Rx. It is an externally driven sounder, you have to switch it at 4KHz, we use TCNT2 in a PWM mode switching a transistor with a reverse/flyback protection diode. It's rated at 80dB @ 1m, the same as the typical round 12mm sounders often used on our projects.

A lost model finder/sounder incorporated into an Rx is probably a first?

I'm certain Tobe will publish more details soon.

Tobe's latest nRF24L01+ Rx with onboard sounder, next to a LemonRx Rx for size comparison

[Phil_G]

Well, that's put me back in my box!