search

rgerganov / rf-car

Controlling RC cars with HackRF
MIT License
140 stars 21 forks source link

add "concept" car #4

Closed alexbilevskiy closed 1 year ago

alexbilevskiy commented 1 year ago

Presenting you the concept car!

Inspired by https://xakcop.com/post/re-2.4ghz/

It is very similar to dickie car both in exterior and functionality, only difference is protocol.

image image

Signal analysis

Car's remote is labeled as 2.4G, so whe know where to start with. To find exact frequency we need to position controller near the hackrf antenna and use any sdr visualizer, with gain and amplifiers tuned to minimum. image

When exact frequency is found (2.417G) the next step is to decode signal. My go-tool for signal analysis is universal radio hacker. This is overall picture after setting correct signal parameters: image

The remote is sending signal in batches of 4 packets of 164 bits. When remote is idle it repeatedly sends one batch of 4 "sync" packets. image

When button is pressed, remote starts sending batches of another 4 packets, and after releasing the button remote continues to send sync packets.

Two-way communication

When the remote is switched on, it starts flashing with red indicator until car is turned on, after which indicator turns solid red. However, i coundn't find how it works, no packets are being transmitted. Maybe it's in another frequency. Car works fine anyway. It works even without sync packets, just control packets are enough UPDATE: yes, it's another frequency. When switched on, remote starts transmitting similar batches of 4 packets on 2.405G, only with longer pause between them, after receiving response from car it switches to 2.417G. Maybe it's some kind of strange channel negotiation... Anyway, car is working even without it.

Problems

rgerganov commented 1 year ago

Great work! I am very happy to see other people contributing to this project!

About the lag reaction -- I remember I had the same problem with my car and I fixed it by sending stop_bits after each command. The stop_bits pattern must have the same common prefix as other bit patterns, just padded with some random bits at the end. Can you try and see if this works for you?

rgerganov commented 1 year ago

Is it OK to merge this PR (it is currently marked as "draft")? I think it is a great contribution to the project.

alexbilevskiy commented 1 year ago

@rgerganov sorry for delay, i'm gonna check in the next couple days if sending stop_bits fixes laggy reaction and then convert draft to normal PR

alexbilevskiy commented 1 year ago

Yep, now it works fine.

I also accidentaly copied fwd bits as sync, fixed it too.