Almost all of the week was spent trying to read the SPI bus on the Quadcopter remote control to try to understand as well as decipher the communication protocols and the reading addresses for the Quadcopter. There were some useful reading from the Quadcopter remote which are discussed in detail but some possible hardware issue also propped out.
Using the Logic Analyzer
During the week, a logic analyzer was used to try and eavesdrop on the exact SPI communication between the MCU on the remote control and the RF board used on the board itself. As this was my first real experience with a logic analyzer, it took some getting to know about the device before I could confidently plug it in to the remote and use it. The most efficient method to connect to the SPI channels seemed to be to use the test probes that came with the unit.
The biggest trouble in trying to use the logic analyzer was the firmware for the logic analyzer itself as it didn’t seem to be picked up by my computer automatically. The next issue was finding a suitable software that would be able to use the logic analyzer effectively. After a few trial and errors on both Windows and the open-source environment, the USBEE Suite was settled upon as after some settings tweaks, it was able to pick up the logic analyzer as a valid device (initially it was unable to detect it).
The best feature of the USBEE Suite software that helps the case of this project is that the software comes equipped with a SPI decoder, where given the correct connections to the SPI channels, can decode and compile a data table for the hex values of the data being transmitted.
Figuring out the SPI channels and connections
One of the biggest issues with the previous quadcopter remote was the non of the pin-connections were labeled, so it took a lot of digging to figure out the SPI channels for the RF module. Fortunately, this particular remote had some of the connections labelled, in particular, the CSN, MISO and MOSI pins together with the 3.3V line. With this information, and the use of a multi-meter to find the GND and the datasheet of the MCU on the remote, the SCK pin was derived. These were the 5 pin-connections that were needed to use the SPI decoder on the USBEE Suite.
RF board and connections
Reading the SPI channels
Having connected the logic analyzer, the SPI decode mode was setup and the Sample rate was set to 12Msps, and the trigger buffer size was set to 20M to allow for about 5 seconds of data capture. The following is an example of the logic levels detected by the analyzer and a further zoomed image of the data sent over the SPI channel.
Reading the SPI Channel using the logic analyzer.
Initially it looks like the remote control takes a bit of time to setup its register once the remote is switched on and the then goes into a loop sending information to the quadcopter every few milliseconds. After taking a closer look at the exact data sent over the channels, the following table (partial table image) can be acquired and using the datasheet for the NRF24L01+, an approximation of the actions can be obtained. The highlighted region is the data of interest at this point that can be implemented on the NRF24L01+.
SPI Decoded data table (partial)
A lot of the setup commands seem very similar to the NRF24L01+ at first glance. A deeper look at the data sheets may reveal a lot more about the later commands which are not clear yet. Once the power-up takes place, there are a few more commands sent after the above set which is also recorded down and being checked up. After that the, the remote goes into a loop of commands that are sent with a 16-byte long data, with a preceding command byte, about the different parameters for the flight of the quadcopter. Some of the readings are confusing so more study needs to be done on the actual data in conjunction with datasheets to figure out what commands are being sent in the loop.
Loop data and corresponding table
Some of the data is confusing but once again, more study is needed to directly replicate these commands on the NRF24L01+. The idea is to try and replicate most of these commands on the NRF24L01+ via the Arduino.
The confusing data may also be caused by the differences in the bots themselves, in particular the way they work. From the previous posts, it is assumed that this toy follows the same communication techniques as mentioned in DZL’s post, but it should be considered that the actual procedure of operation for these bots may be completely different.
Glitches and bugs with the NRF24L01+ chip:
It seems like the bugs with these communication chips have re-surfaced. Initial attempts were made to replace the handset ID on the previous binding code being used but after connection there was no response from the bot. Further testing showed that although there is connectivity between two NRF24L01+ modules, it seems sporadic and the modules turns off for long periods. This problem does not related to the distance between the modules. Either the modules are duds, or my Arduinos aren’t working well with them. Adding different values of capacitor (as recommended online) didn’t really help much and communication is still buggy. So a solution needs to be found for this problem. Perhaps the problem is just that these modules were cheap and thus do not work well with with my arduinos. A trip to the electronic shop to get better ones, is planned for the near future and also getting another Arduino is on the shopping list to help sort out the problem.
It was good to finally have a look at the SPI data being sent from the MCU in the remote to the RF module. The data seems pretty similar to the one is DZL blog’s posts. However, this week will be spent trying to totally understand the unknown commands being sent from the MCU to the RF board and figuring out what exactly is going on between the handset and the quadcopter. Unfortunately for me, this is taking me longer than I had hoped so I am considering my plan B already (trying to get the same quadcopter being used for the Dzl hacking post). More to come on this matter very soon.
0 Comments