Evolve - radio is using nRF24L01

This is a great discussion. Unfortunately I think I've been educated beyond my intelligence! Thanks for the continuing research to Julian, Evolveinla and Wiztecy.

 

lol no probs - its getting cold up here - stuck inside more - arghhhhhh

Fresno I think you are right from what you said earlier - we will likely not see a dramatic improvement in control with the current version of the board (with what we have learned about the remote / radio system they are using) - hopefully near term they can improve the code a bit to help and yes I think now there is some merit in swapping remotes and controllers (to get the sweet spot of NRF24 chips that are working properly as some are better than others) - again at times its hard to produce - I guess especially on the service desk - sometimes easier for us in the field.

Anyway at least now we understand more whats happening and can come up with a "safe riding strategy" and what to watch for to keep having fun

 

This is interesting... Since I work for the Bluetooth SIG.

I don't know much about the Bluetooth Spec. I'm a web developer there, working on the testing tools manufacturers use in building Bluetooth Devices. Funny seeing the specification linked. It's a big sleeping pill of a book!

 

I found something earlier that I lost that said the original developer of the nRF24L01 was "Nordic Semiconductor" - who also helped with the Bluetooth LE (BLE spec) which is why the two protocols are so similar. (I'll post more info if I can find it - it came out of something else called bluetooth smart)
(and likely why they share frequencies to the detriment of us with our Evolve remote situation)

heres a link to their site on it: Bluetooth low energy / Products / Home - Ultra Low Power Wireless Solutions from NORDIC SEMICONDUCTOR

of course they could have been one of many companies working on it - more here:
Bluetooth low energy - Wikipedia

 

which begs the question:

going forward - what radio system are eboard makers better off using ?

Boosted Board and their bluetooth confirmed radio remote also had its fair share of issues with V1 even with the protocol inbuilt frequency hopping - (again they have added a second bt connection and now advertise bt encryption on their new V2 board with the battery problem but it will take more rider reports to hear if its a noticeable improvement)

RC style remote for control - yea as I said earlier and Wiztecy confirmed on the other thread is still likely the best choice - real nice feature on the Metroboard being able to retrofit it for reasonable money and reported as very high resolution control:
Wireless Remote Control - Metroboard Electric Skateboard

 

The FCC gives a frequency range that you can run on, hence the 13 assigned channels which is in their frequency range. Within those 13 channels / frequencies the radio will be jumping around many times per second up and down the channels/assigned frequency.

 

jumping around the channels is frequency hopping - until we see a scan there is really nothing that says they are actually doing that - many of the threads I saw today mentioned DIY types that were asking how to do it in their own code - its not automatically built into the nRF24L01 that I can tell. (again the remote / radio transceiver is not actually bluetooth - but using 13 of the same channels as bluetooth) - hopefully Evolve is doing that but we have no proof yet.

 

the nRF24L01 has been available for a long time - (the full spec pdf I attached in the first post lists July 2007 at the bottom) - its really cheap and predates bluetooth - It's also been cloned a lot (in the far east) and there's quite a few poor quality ones out there - even the brand name ones can be finicky and of questionable reliability apparently.

(I posted a link to a massive thread earlier in this thread where there is pages and pages of tech types going thru specific releases of the chip and how good or bad some were compared to another)

 

I found a listing with a similar nRF board as in our remotes / boards - the antenna is ceramic (below is a pic from an ebay listing) - this type of antenna is pretty uncommon on these boards (I've looked at hundreds of variants)

 

HERE WE Go - this is out exact model / style of nRF24L01 daughter board module (used in remote and on skateboard) - currently listed on ebay
2.4G NRF24L01+PA+LNA Wireless Module with Ceramic Antenna 1.27mm NEW | eBay

The board (YJ-13039) including RFAxis range extender chip


The full listing

 

I'm find this thread interesting... Thanks for the researching

 

What are we trying to achieve here ? I have equipment to do a spectrum sweep. I don't have access to Faraday cage I can fit the skateboard into. I could take the controller board out and power it externally and use the Microwave as a cage.

I have some nRF24L01 modules here as well I can do testing with.

Are we looking for vulnerabilities in the protocol so we can get them fixed and make our boards safer ?

I can see a opportunity to make a better remote.

To start with the system I would just capture the SPI data on decode that. You can then see what the unit is really doing and how the registers are configured.

 

Thanks Covert in advance for jumping in here it sounds like you have the skills to take this to the next level.

Myself, Wiztecy and EvolveinLA and others have a problems with the remote radio system on our GTs (mine Bamboo and theirs Carbon) where the remote has not just had a brief coasting style "drop out" with the board but actively kept the power going - or even worse keep accelerating for up to a few seconds (with a hard crash / landing in the end). (see Wiztecy's thread for plenty of info and more details on this)

The goal really is to make this safer for all and determine if the radio link based on these boards is reliable enough or if we should suggest to Evolve they switch to something else in future releases. (not sure how much input they would accept on this - but we are the ones spending the money so should have some say)

My immediate questions are centered around around how the two nRF24L01 transceiver modules are picking channels in the bluetooth range to use. From the initial FCC filing there are 13 channels (a subset of the 80 odd bluetooth ones). (now with the newest remote they made have they simply added more to try and find some in a less cluttered range that is less interfered with?)
- (its not that they are actually using bluetooth as you know but merely some of the same frequencies)

Question ?
Does the re-pairing / re-syncing process pick a SINGLE channel to use and that's it until the next re-pair ?
(or two predetermined fixed channels ? - one for remote control and one for telemetry) - since each side is a transceiver they can both send and receive single duplex - one direction at a time)
Or have they managed to code in a FHSS (frequency hopping system) where the remote and the board will automatically jump to another channel by schedule or after a certain brief amount of time if the RF link breaks down (and either side is not getting ACK for instance)
(I think a scan would show this)

FHSS seems to be built in to all Bluetooth specs - going way back (but the nRF24L01 predates that - which you likely already know)

So yea if you could scan the spectrum while you have a current board and remote turned on (and working) to see if they are sticking to one frequency (channel) or moving around - it would be a good place to start.

They have been a bit vague on what the pairing process actually does - I saw some information about channel picking in another thread that EvolveHQ commented on. Also there is some odd information about riding two Carbon's together is ok and riding two Bamboo's together is ok but if you ride one Carbon and one Bamboo next to each other they can cross control (?) - this should be a hint at something - not sure what yet. (except that it sounds like there no encryption or guid in use where a board will only talk to one specific remote - like RC Spektrum's model match feature)

Next if you are able start trying to read register information to see if any encryption is in place - which I doubt it is based on the chipset they are using. (I guess logically if the communication is encrypted we shouldn't be able to read anything beyond the (preamble?) - or initial part of the conversation.

again - appreciate the help - Julian


------I went for a 20min ride today and first tested my board in the back of my car - sitting under the hatch - the remote was bad - it was really sticky and felt like the board was receiving a new command or throttle position every second or so - not in real time. My iPhone was on - but in the glove compartment. I turned off the board and remote and went and put the iPhone in Airplane mode and tried again. The remote worked perfect! - its that type of intermittent control that makes it untrustworthy and not something you really want to ride faster than about walking speed. Next time I will leave the board and remote on - and put the iPhone in airplane mode and see if it clears up right away. (or the reboot process is required - most of the newer RC protocols will do a channel search on radio boot up and pick the most clean part of their assigned radio spectrum to use and then hop around when required to stay in the clear).


EDIT - here is the reference in the FAQ from Evolve HQ's website (with multiple boards riding together)
(BUT - not sure if they are referring to our current GT's or the previous gen)

 

Ok. I'm on the same page now. I won't bother with the Spektrum scan at the moment. It has more visual impact that practical use. I'll use a logic analyzer to look at data going to and from the RF modules. From here we can decode what channels are used, channel order, registry settings etc

The data doesn't need to be encrypted but has to be at least signed. Short of hijacking on board turn on there is no sensitive information transferred. Encryption can make it take longer to establish a connection if it is lost.

I'm very interested in how safe this system has been made. I'm sure more will come out as the protocol gets looked at.

I hope evolve will have open ears to our idea's.

Doing a channel search on bootup is pointless. The RF Environment will change as the board moves through the world. Needs good frequency hopping that is robust to a large amount of noise.

From the accounts I have read it looks like the receiver is getting corrupted information and acting on it. This is not acceptable if this is the case. The protocol should be robust enough to realize the data is corrupt and drop those commands, wait for a good command, After a timeout if no good command has arrived De-energize the motors without breaking if in a non breaking state. If breaking then hold the break at that level until stopped.

I can see another use for this research. We could man-in-the-middle the protocol and give the board a soft start and even different acceleration and breaking curves. Now that would be sweet.

 

This post is very exciting! Do you guys think that by reverse engineering the protocol you would be able to hack it to alter the acceleration curve?

 

Yes. I mentioned a man-in-the-middle approach in my previous post. What this means is we could read the command coming from the controller and adjust it as we see fit. This includes adjusting throttle and break curves and even dynamically adjusting acceleration based on current speed to allow soft start when stopped and still have the punch we want at high speeds without having a lag every time we increase the throttle.

But this is all in the future and just a possibility at this stage. We really need a "what would we change if we could thread"

Also opens up the idea for a different controller. Thumb instead of finger. Longer throw. Imagine a premiums controller in a CNC case with a long throw trigger and dead mans switch, Audible beep at events like speed reached. Target acceleration hit, now holding speed. Even haptic feedback. Getting myself all excited now

 

This is awesome. My biggest wish for my board is an exponential throttle curve in GT mode.

If this is ever achieved, I will be stoked!

 

I'm reading the data sheet to understand what this nRF24L01+ is capable of.
(chip is a nRF24L01+ on my TX module)

No FHSS - It's not going to happen with this module. There are other mode expensive modules if this is what is wanted.

CRC. 16 or 32 bit. Packets dropped in Shockburst mode if CRC is wrong. This means if not in Shorkburst mode the data is received and the Control board MCU has to decide if the packed is valid.

Single Channel - If the board picks a random channel when paired ?... Don't know yet.

4 TX power levels. Unknown what is used at this stage.

ShockBurst mode - seems more robust. Might be the only time CRC is forced to be used ?

Module has 2 datarates. Slower datarate is better IMO. Not sure what rate it's at yet.

Uses a 5 byte address. Millions of combinations. This would be shared between both modules when paired. Need to check if all boards have a fixed unique ID, Radom ID generated when paired, or something else.

Got some more questions now and I know what I want to look at. I'll answer all these thoughts soon.

So far my thoughts on one board controlling another. I can only see this is possible if one of a few things where not done right. Not using the CRC. Not using unique ID's. I honestly think the CRC might be the culprit at this stage.

What I want to see when I look behind the curtain is...

New Unique ID randomly generated when paired or a fixed Unique ID for each board.
Shorkburst mode used meaning CRC and Address is always checked.
Random channel selected when paired. (doing a spectrum scan and selecting a channel based on results would be impressive)
Low data rate giving more possible channels between boards.

Now because of the packet based protocol used in this module having multple boards on the same channel should not have any noticeable effect by the users.

This is research. There is no right or wrong here. If you think I'm wrong please tell me how.

 

so it remains to be seen what Evolve has actually implemented with this this - new shipment of boards coming down the pipeline - interested to hear the rider reports on those...

 

They started shipping out yesterday, so yes, it'll be very interesting to hear owner reports from the latest batch. I'm hoping to get a new motor controller & remote from this new batch as well, to replace the ones in my CGT. However, my Carbon has been strangely problem-free the last couple rides (did do re-pairing procedure before each ride). I'm afraid she is just playing with me....