Hello – This is my blog about hardware hacking, technology, and the usual stuff. 7 thoughts on “About” Chalky 2 December, 2008 at 9:02 pm I can’t believe you still haven’t done anything about this damn page. Reply ↓ john 8 July, 2015 at 7:13 am Dear Jim I was reading your interesting and very impressive work done in reverse engineering. What interested me the most is what you have done to reverse engineer the Hubson X4 quadcopter. I really want to discuss more about it as currently I am trying to reverse engineer my hubson X4 and can not figure out how can I do it. Any help from your side is highly appreciable. Please reply to my email soon so we can start discussing and share our ideas . Reply ↓ Stanley Leung 18 May, 2016 at 12:55 am I have been reading your X4 TxRx protocol analysis. One thing I don’t understand is why the Flight Control Packet does not contain the Random 4-byte Session ID. Without the session ID to check, the X4 copter would respond to any Flight Control Packet sent from any X4 Handset. Reply ↓ Jim Post author19 May, 2016 at 2:38 am Hey Stanley, that’s a good question. During the handshake process, the controller starts out by setting the transmitter’s IDCODE register to a fixed value that is the same every time (0x55201041). This is probably because the quadcopter radio is always listening for data packets from that ID by default when it’s switched on and until it has bound to a controller. As part of the handshake sequence, the controller generates the random Session ID – once the handshake has completed to what I called “Level 3”, the controller and quadcopter change their IDCODE’s to match the random value (instead of the 0x55201041 value it always starts with). From that point on, the quadcopter will only listen to data packets that have the proper IDCODE (the random session ID). You can see this in my protocol spec in Section 3.1.3 (here). This means that they don’t need to send the value in the control packet itself, it’s already taken care of as part of the data “frame” that is sent by the A7015 radio transceiver. Hope that helps, Jim Reply ↓ Stanley Leung 19 May, 2016 at 2:54 am Thanks a lot Jim. It does make a lot of sense. The A7015 takes care of the packets selection at the hardware level. It must be much more efficient that way … Reply ↓ Tom Hearne 15 August, 2016 at 8:26 am Great work on the X4. I have a different Hubsan: the H301s. I’ve reviewed your spreadsheet and I believe that I should be able to leverage your work, since it’s Hubsan and the Hubsanx4 tx will in fact bind with the H301s. It looks like the raw data can be dropped into the appropriate left hand columns of a given tab and the formulas show intelligible data, much of which may be similar to the x4. The H301s has additional capabilities: video and RTH. Stabilization can be turned off. Any guidance, links to similar work, etc, you can offer would be greatly appreciated! Finally, I am assuming RTH algorithms reside in the Rx. Have you any experience with hacking the Rx side? Many thanks! Tom Reply ↓ Carlo 9 April, 2017 at 12:37 am Hi Jim, Thanks for all your detailed work. I am aiming to port your code to an Arduino Nano for a school project…Im a volunteering parent…and think the stumbling block is that the Nano does not have the same SPI as the Due..and you mention that it wont work without the Due ..prob’ly for this reason. I tried adding a manual CS strobe to every SPI interaction..but still cant get the copter RX to stop flashing..and the LEDS to stay on ..which indicates a bind. Any suggestions ? Do you think I’m heading in the right direction…or barking up the wrong tree.? Cheers, Carlo Reply ↓ Leave a Reply Cancel reply Your email address will not be published. Required fields are marked *Comment Name * Email * Website Notify me of new posts by email.