Evolve - radio is using nRF24L01

There seems to be a lot of information online regarding the NRF24L01 transceiver and I think Evolve is using this type of control / telemetry for the new Carbon and Bamboo GTs.

note: this is not the same as bluetooth or bluetooth LE (BLE also known as bluetooth smart) - notice they never advertise on any of their websites that the remote is bluetooth or ble - those protocols have frequency hopping built in to help with interference - see this for more info on ble: Bluetooth low energy - Wikipedia


I need a better picture of the front bottom side of the currently shipping remote to confirm this - but here's what I've found in the mean time based on existing pictures on this forum. (so if someone could post a clear image that would be great)

There is a small daughter card on the bottom front of the main pcb on the remote - I think the ID on the bottom of the board is: YJ-13033 (or YJ-13039) and here is what an "off the shelf" one looks like ! (notice the similarity to the pics below):
New! NRF24L01 + PA + МШУ чип модулей/1.27 ММ/малый размер/внешний IPX/модуль передачи данных купить в магазине ShenZhen hongyi yunjia technology Co.,Ltd на AliExpress



This image better example of above also showing RFAXIS ranger extender chip



This image from an ebaylisting - this board has same PN as ours - YJ-13039
(looks identical to our radio boards - rev on nRF chip may be different)


the components on the daughter card are similar to this:
MOD-NRF24LR OLIMEX, 2.4GHz RF Transceiver Module with NRF24L01, Communicates About 62 meters in Open Air | Farnell element14



Evolve remote showing radio daughter card:



Close up from existing picture on this site:



Link on how to create a two channel remote with above:
Create a Two-Channel Remote Control with the nRF24L01+

Another project to send remote data using same transceiver and arduino:
https://arduino-info.wikispaces.com/Nrf24L01-2.4GHz-HowTo

Range test using similar tech:
NRF24L01 real life range test – Charles's Blog

Google search on the nRF24L01 chip:
nRF24L01 chip - Google Search

So now we can start researching how well these types of radios work and suitability of purpose etc.

edit: not sure if this is considered bluetooth or not - will look into it further (based on frequency its using etc)
UPDATE - its not but uses the similar frequencies and can therefore be subject to common interference

See this PDF for full specs on the NRF24L01:
https://evolveforums.com/attachment...9/?temp_hash=e6f3c2f955e61632549d4c15b53e61f0

 

Would really like to see the transceiver PCB on the board side - it must be built into the motor controller as there doesn't appear to be a separate daugherboard for the receiver (see the new YT video on replacing the motor controller - no separate receiver board like Gen2 has).

If so, both the remote PCB and the board PCB doesn't have a separate wire for the antenna like Gen2 boards have.

Would be great if there was some way to extend/improve the antenna on this board, if that's what the GTs are using, then test and see if that improves the dropouts issue.

Again, in my case, replacing the remote with a known working one did not fix the dropouts.

 

yea me too - that's what we need to confirm all this - I'm convinced that's what they are using though - I got the pics I show above from this thread: Lost USB plug of New remote

now I'm thinking they should be using something from Spektrum RC or other well known RC brand. - see this other thread:
https://evolveforums.com/threads/remote-dropouts.330/ - (where I go into details on the early DSM spec from Spektrum)

these RC companies (Spektrum, Futaba, Hitec, Jeti, Taranis) have spent years and many generations improving this stuff and it now has telemetry etc - why reinvent the wheel - I'm going to research next if any NRF24L01 applications have implemented the redundancy / failsafe / signal QOS solutions that the RC guys now have.

imagine the lead Evolve would have if they could advertise how strong and reliable the signal is (using better RC radio tech) ? - again in this day and age there is really no excuse for 99.9% of the drop outs - look what DJI has done with their drones and the reliability etc (not perfect but I think better than what we are seeing)

 

The guy who posted this thread on an Arduino forum below mentions the following (already baked in to RC DSM+ protocols)
- and just read the NRF24L01 is half duplex so can only transmit or receive at a time (not both)

My point here is that: how well an NRF24L01 radio / remote control system works seems to come down to the code your write for its application (its doesn't appear to be just built in) - so the dev decides how robust to make it.


NRF24L01 - Channel Hopping (FHSS)

I am working on a simplex design for data transfer using the NRF24L01
I have sussed a very simple pairing technique too

• It is a single transmitter, multi receiver network
• I do a full channel scan when the transmitter powers up and it selects the quietest channel for broadcast
• Channel 80 is the control channel
• The transmitter broadcasts its 40bit and quiet channel every 2 seconds
• The receivers sit and listen on 80 for the information
• The system works very well

But now I want to try and do channel hopping (FHSS) - I have read what I can on the internet but the actual application of it eludes me as I still need to keep the following in my software

• No acking
• Payload of a max of 18 bytes
• 250kbps only (best for distance)
  
  
  
  

 

Yea its the same NRF24L01+ transceiver board on the motor controller riser card - see these pics.
(seems like it would not be hard to extend the size of the antenna - not sure if tuning would be required)

heres the source:
Evolve GT | Problems & Solutions

pic showing skateboard mounted controller and riser card - then close up

the date on the board is 20160304 - so there may be a newer rev (a current picture would still be useful - not sure when that one was taken - they are likely still using the same remote control radio though)



close up:



rotated and zoomed in - shows NRF chipset

 

looks like the nRF24L01 is not considered bluetooth - but uses similar frequencies:

from this source:
Sending data over Bluetooth Low Energy with a cheap nRF24L01+ module

-quote-
"i think they just run on similar frequencies, modulation, channel width and data rate. its probably just coincidence. then you just create a packet that looks close enough like the one that ble is supposed to receive, and ble doesn't know the difference for the most part."

Also
"
Since nRF24L01+ and BTLE use the same modulation scheme and frequencies, that means the nRF can unintentionally receive BTLE data; and so it must be capable of reliably distinguishing and ignoring that data.

That’s easier if it shares the same preamble, and partial header up to the address. It can properly sync to the beginning of each BTLE packet, examine the address, see it doesn’t match, and ignore the rest of the packet.

If for example the nRF used a different preamble, it would have no idea where BTLE packets start. As a result, it would often start trying to parse BTLE packets in the *middle*, based on finding its preamble anywhere in the packet. And although the probability is low that the following data successfully mimics a valid nRF packet, it’s a still needless source of error."



==there is more on the link above==

 

We really need an EE here, to examine the receiver, take apart the motor controller, and see if the antenna can be improved/lengthened in the receiver (even if to just solder a 4-6" wire to the antenna connection, then tape it to the underside of the battery cover). Then, to test and see if this rectifies the dropouts or not.

 

So basically it's saying that we have not technically a Bluetooth receiver, but packets that are tx/rx which are very similar to BT packets. But - the receiver could possibly receive BT packets (from another BT source) and in some cases, incorrectly read those as packets coming from the transmitter?

This would explain a lot if it's true - but - some of my dropouts occurred in sparsely populated areas where it seems unlikely that I was receiving interference/signals from other BT devices. Need to ride out in the middle of NOWHERE to prove/disprove this theory.

 

Also - probably a very dumb question - but, is the battery cover on the CGT also made of carbon fiber, as is the rest of the deck?

I ask this, because I remember reading that Jason with Enertion was having huge signal loss problems with the very first Raptors that were produced. The first boards had CF battery cover plates as well as the CF board chassis itself. Signal loss was due to the receiver being completely encased in CF, and that material really shielding the receiver from getting the signal coming in.

He had to switch to a different material (ABS?) for the battery cover, instead of CF, and it improved the reliability of the receiver.

 

yes and it seems to be totally dependent on the code you write for the board side and the remote side

so the upside its it could be improved in coding (firmware upgrade)

the downside is so far they don't have an OTA (over the air or usb) method to get us new code

of course the best solution is to use something else for control (RC - also like Wiztecy just posted in the long Carbon thread)
- they could even keep the existing radio for telemetry only if they really wanted to (as long as different channels than control)

 

yea - see Wiztecy's long Carbon thread - exact same discussion

 

Regarding the antenna spec as quoted directly from the full pdf I posted in the first posting in this thread:

10.1 Antenna output
The ANT1 and ANT2 output pins provide a balanced RF output to the antenna. The pins must have a DC path to VDD_PA, either through a RF choke or through the center point in a balanced dipole antenna. A load of 15Ω+j88Ω is recommended for maximum output power (0dBm). Lower load impedance (for instance 50Ω) can be obtained by fitting a simple matching network between the load and ANT1 and ANT2. A recommended matching network for 50Ω load impedance is described in Appendix D on page 69.

and this is how someone did it (lol) - looks pretty easy:
Enhanced NRF24L01 radio with a DIY Dipole Antenna modification.


So ours could look like this:
(for entertainment purposes only)

 

Any type of antenna placement needs tuning. So when you move the antenna to a new location, I would benchmark and get data points from the old antenna location, then move the antenna location and test. Note that the testing should be conducted as if you were using the board, no parts removed, etc.

Bluetooth Antenna Design Guide Step 1

 

- agreed but how do we measure this with the radio modules installed and working both ends - its almost like you have to do it and try and see if there's an improvement / there may be registers you can read in code to get RF strengths but of course the dev would need to implement this - not practical for us to even entertain it - unless someone wants to reverse engineer and write replacement firmware (like some load on their WRT routers etc) <---- no chance - I know.

of course now we know where to solder the "curly cords" - lol - anyone want to try connecting the antenna on one to the matching side on the other ?

 

Would love to see someone re-engineer the remote to a more user friendly design.

1. Add a safety switch that needs to be pressed/gripped before the trigger will work.
2. Swap the flimsy trigger for one with a longer throw and more resistance.
3. Reconfigure the throttle curve for more gentle starts.
4. Reshape the remote to fit in the hand comfortably.

This all may be feasible without even touching the electronics beyond swapping out the potentiometer and adding a switch.

Hmmmmm....

 

look at this one - 1.1KM with SMA style Antenna
NRF24L01L Long Range Wireless Module R2 (1.1KM, PA+SMA) - ElectroDragon

not sure what "receiving the spirit" means

• Receiving the Spirit of 2Mbps mode -92 dBm
• Receiving the Spirit of 1Mbps mode -95 dBm
• Receiving the Spirit of 250Kbps mode -104 dBm
  

 

here is a search on the radio band they seem to be using:

Worldwide 2.4GHz ISM band operation - Google Search

ISM band - Wikipedia

2.4 GHz 2.5 GHz B 2.45 GHz Worldwide FIXED, MOBILE, RADIOLOCATION, Amateur & Amateur-satellite service


Wireless LAN devices use wavebands as follows:

• Bluetooth 2450 MHz band[citation needed] falls under WPAN
• HIPERLAN 5800 MHz band
• IEEE 802.11/Wi-Fi 2450 MHz and 5800 MHz bands

 

more comments

the problem with simply increasing the size of the antenna is also end up gathering more noise

also it seems sensitive regarding power (how's the voltage regulator supplying it on the remote and board sides?)

more interesting threads on this transceiver:
The, Very Frustrating, NRF24L01+
http://yveaux.blogspot.ca/2014/07/nrf24l01-sniffer-part-1.html
NRF24L01+ seems very sensitive to electric noise - Nordic Developer Zone
http://travisgoodspeed.blogspot.ca/2011/02/promiscuity-is-nrf24l01s-duty.html
low range and susceptible to noise: nRF24L01+ low range and noise
- decreasing the default data rate from 2Mbps to 1Mbps helps normally with these chips.
You might also want to increase the number of retransmits, assuming you are using Shockburst.
Do not expect too much from these modules, especially if you are using modules with a chip antenna or even one printed on the circuit board. An external antenna can increase reception notably.
You might also want to check for a channel in the 2.4GHz band which is interference free.
use as scanner: http://arduino.cc/forum/index.php/topic,54795.msg392325.html#msg39232
there are FAKE (clone?) chips: Nordic NRF24L01+ – Real vs Fake
NRF24L01 unreliability | Espruino
lots of tips in below link including shielding the module:
Fixing your cheap nrf24l01+ pa/lna module | the ugly fix
long thread - tons of info on which NRF24 modules are better than others - also mentions counterfeit:
Which are the *best* NRF24L01+ modules?

---------------------------------------------------------------------
** this one is good - sniffing nRF24 and bluetooth:
Cyber Explorer: Sniffing and decoding NRF24L01+ and Bluetooth LE packets for under $30

It mentions this:
"The NRF24L01+ (nrf from now on) uses GFSK modulation for the data."
- which corresponds to the FCC filing - see this from that 28 page pdf




then goes on to say BTLE using frequency hopping (which NRF24 does not seem to have built in) - so its harder to sniff
Taking it further
As one smart blogger explained, the physical radio of the NRF24L01+ and Bluetooth Low Energy (btle from now one) are quite similar. This allowed me to quickly adapt my code to sniff btle packets as well.


Sniffing Bluetooth Low Energy advertisement channel 38 (2,426Mhz)
The code for sniffing btle is complete for the advertisement channels, but not for the data channels, it would be my next step to add it. The main issue is frequency hopping as required by btle, which I'm not sure our lowly rtl-sdr can do fast enough.

--------------------------------------------------------------------------------------------------

Also You would think that all NRF24 modules (the chips) are the same - but not the case which may explain why swapping remotes and controller boards does help for some and not others.

There is even an RFAxis RFX2401C chip that extends the range of the NRF24 modules - not sure if ours has this or not.
(a clear pic of the nRF24L01+ they are using would show this)

Question - does anyone remember seeing a link (here or on reddit or somewhere else) that says you have to be careful with cross controlling when a Carbon GT and Bamboo GT are riding close together ? (or similar) - this is a hint at something - not sure what - more info required...

 

Tried a little testing to see if I could cause some Bluetooth interference.

First, I tried Bluetooth scanner apps on both Android (Motorola phone) and on an iPhone 5. Held the phone about 6" from both the remote and the board. Neither phone or apps detected any Bluetooth signal, when placed near the board and remote. Turned the remote and board on/off several times. This was for both the Bamboo GT and the CGT.

Then, I turned the remote and CGT on, raised the wheels and tried to hold a steady speed on the controller. Turned Bluetooth on and off multiple times on both the iPhone5 and the Motorola phone. No noticeable interference was visible, the speed appeared to stay constant and not drop out when Bluetooth was turned on and off with both phones.

However - one time when I was testing with the iPhone 5, when I turned the BT off on that phone, at exactly the same moment, the display disappeared on the CGT remote (loss of antenna icon and battery % reading, like usual). I held the speed steady and waited for it to re-connect. Took about 10 seconds. Tried doing the same thing again and again, and I could not replicate the problem. All other times I turned BT off from the iPhone, everything seemed to stay connected OK.

So from this short and definitely unscientific test, I can't say that turning on/off BT devices VERY near the board caused any noticeable dropouts with the throttle, or a stuck throttle condition.

 

In that FCC filing they are using very specific frequencies - so unless your bluetooth (frequency hopping) devices happen to jump onto the current channel (frequency) your remote and board are using I don't think you would necessarily see a problem. (hence the intermittent nature)

here are two pics and yes there is overlap
1 - from the FCC filing that Evolve presented for testing (13 Channels)


2 - the full list of bluetooth channels from this link: Disply Wiki Entry

Channelized Frequencies
Frequency Bandwidth Channel Use Service Table
2402 MHz 1 MHz 0 Bluetooth channel 0 - -
2403 MHz 1 MHz 1 Bluetooth channel 1 - -
2404 MHz 1 MHz 2 Bluetooth channel 2 - -
2405 MHz 1 MHz 3 Bluetooth channel 3 - -
2406 MHz 1 MHz 4 Bluetooth channel 4 - -
2407 MHz 1 MHz 5 Bluetooth channel 5 - -
2408 MHz 1 MHz 6 Bluetooth channel 6 - -
2409 MHz 1 MHz 7 Bluetooth channel 7 - -
2410 MHz 1 MHz 8 Bluetooth channel 8 - -
2411 MHz 1 MHz 9 Bluetooth channel 9 - -
2412 MHz 1 MHz 10 Bluetooth channel 10 - -
2413 MHz 1 MHz 11 Bluetooth channel 11 - -
2414 MHz 1 MHz 12 Bluetooth channel 12 - -
2415 MHz 1 MHz 13 Bluetooth channel 13 - -
2416 MHz 1 MHz 14 Bluetooth channel 14 - -
2417 MHz 1 MHz 15 Bluetooth channel 15 - -
2418 MHz 1 MHz 16 Bluetooth channel 16 - -
2419 MHz 1 MHz 17 Bluetooth channel 17 - -
2420 MHz 1 MHz 18 Bluetooth channel 18 - -
2421 MHz 1 MHz 19 Bluetooth channel 19 - -
2422 MHz 1 MHz 20 Bluetooth channel 20 - -
2423 MHz 1 MHz 21 Bluetooth channel 21 - -
2424 MHz 1 MHz 22 Bluetooth channel 22 - -
2425 MHz 1 MHz 23 Bluetooth channel 23 - -
2426 MHz 1 MHz 24 Bluetooth channel 24 - -
2427 MHz 1 MHz 25 Bluetooth channel 25 - -
2428 MHz 1 MHz 26 Bluetooth channel 26 - -
2429 MHz 1 MHz 27 Bluetooth channel 27 - -
2430 MHz 1 MHz 28 Bluetooth channel 28 - -
2431 MHz 1 MHz 29 Bluetooth channel 29 - -
2432 MHz 1 MHz 30 Bluetooth channel 30 - -
2433 MHz 1 MHz 31 Bluetooth channel 31 - -
2434 MHz 1 MHz 32 Bluetooth channel 32 - -
2435 MHz 1 MHz 33 Bluetooth channel 33 - -
2436 MHz 1 MHz 34 Bluetooth channel 34 - -
2436 MHz 1 MHz 35 Bluetooth channel 35 - -
2438 MHz 1 MHz 36 Bluetooth channel 36 - -
2439 MHz 1 MHz 37 Bluetooth channel 37 - -
2440 MHz 1 MHz 38 Bluetooth channel 38 - -
2441 MHz 1 MHz 39 Bluetooth channel 39 - -
2442 MHz 1 MHz 40 Bluetooth channel 40 - -
2443 MHz 1 MHz 41 Bluetooth channel 41 - -
2444 MHz 1 MHz 42 Bluetooth channel 42 - -
2445 MHz 1 MHz 43 Bluetooth channel 43 - -
2446 MHz 1 MHz 44 Bluetooth channel 44 - -
2447 MHz 1 MHz 45 Bluetooth channel 45 - -
2448 MHz 1 MHz 46 Bluetooth channel 46 - -
2449 MHz 1 MHz 47 Bluetooth channel 47 - -
2450 MHz 1 MHz 48 Bluetooth channel 48 - -
2451 MHz 1 MHz 49 Bluetooth channel 49 - -
2452 MHz 1 MHz 50 Bluetooth channel 50 - -
2453 MHz 1 MHz 51 Bluetooth channel 51 - -
2454 MHz 1 MHz 52 Bluetooth channel 52 - -
2455 MHz 1 MHz 53 Bluetooth channel 53 - -
2456 MHz 1 MHz 54 Bluetooth channel 54 - -
2457 MHz 1 MHz 55 Bluetooth channel 55 - -
2458 MHz 1 MHz 56 Bluetooth channel 56 - -
2459 MHz 1 MHz 57 Bluetooth channel 57 - -
2460 MHz 1 MHz 58 Bluetooth channel 58 - -
2461 MHz 1 MHz 59 Bluetooth channel 59 - -
2462 MHz 1 MHz 60 Bluetooth channel 60 - -
2463 MHz 1 MHz 61 Bluetooth channel 61 - -
2464 MHz 1 MHz 62 Bluetooth channel 62 - -
2465 MHz 1 MHz 63 Bluetooth channel 63 - -
2466 MHz 1 MHz 64 Bluetooth channel 64 - -
2467 MHz 1 MHz 65 Bluetooth channel 65 - -
2468 MHz 1 MHz 66 Bluetooth channel 66 - -
2469 MHz 1 MHz 67 Bluetooth channel 67 - -
2470 MHz 1 MHz 68 Bluetooth channel 68 - -
2471 MHz 1 MHz 69 Bluetooth channel 69 - -
2472 MHz 1 MHz 70 Bluetooth channel 70 - -
2473 MHz 1 MHz 71 Bluetooth channel 71 - -
2474 MHz 1 MHz 72 Bluetooth channel 72 - -
2475 MHz 1 MHz 73 Bluetooth channel 73 - -
2476 MHz 1 MHz 74 Bluetooth channel 74 - -
2477 MHz 1 MHz 75 Bluetooth channel 75 - -
2478 MHz 1 MHz 76 Bluetooth channel 76 - -
2479 MHz 1 MHz 77 Bluetooth channel 77 - -
2480 MHz 1 MHz 78 Bluetooth channel 78 - -



External Links:


Bluetooth Core Specification Version 4.0 (30 June 2010)


The first channel - 2402Mhz seems pretty common with wireless mice - its the first thing a google search shows:
2402MHz - Google Search