Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ocusync 4 cannot be resolved #50

Open
wanhongwu1998 opened this issue May 27, 2024 · 4 comments
Open

Ocusync 4 cannot be resolved #50

wanhongwu1998 opened this issue May 27, 2024 · 4 comments

Comments

@wanhongwu1998
Copy link

Hello, thank you very much for your sharing. Our research has found that this burst does not exist in LightBrige technology, so it is impossible to parse such a drone. In addition, although the burst can be found in Ocusync 4 technology and the constellation image can be demodulated successfully, the signal of the drone cannot be solved, as it seems to be encrypted. I wonder if you have encountered the same problem in the future.

@proto17
Copy link
Owner

proto17 commented May 27, 2024

I have not done any work with newer drones. If you have a collect that you're willing to share I would be happy to have a look (keeping in mind your physical location could be present in the collect!), but the only drone I have is a Mini 2. If the constellation comes out clean and you get data back then I would suggest looking at that data with a hex editor to see if there are any strings present. IIRC the serial number of the drone shows up in the demodulated output. If you see that serial number in the output then you can be pretty sure that the link isn't encrypted. It could be that the CRC changed, or that the format of the demodulated output changed. But it's definitely still possible that the link has been encrypted. There's been lots of calls for that to happen.

It could also be that you have a really noisy collect that's failing to properly demodulate. The process_file.m script doesn't output the frame hex if the CRC fails. You can change this by commenting out [1]. Doing so will output the hex for all frames even if they are not valid according to the CRC.

Good luck!

[1] https://github.com/proto17/dji_droneid/blob/main/cpp/remove_turbo.cc#L156

@wanhongwu1998
Copy link
Author

Thank you for your reply. I'm sorry that it is not convenient to export the data I collected to you! To be sure, CRC was successful, so I'm more confident that the format of the demodulated output changed or was encrypted.

@jianjianliu0918
Copy link

Thank you for your reply. I'm sorry that it is not convenient to export the data I collected to you! To be sure, CRC was successful, so I'm more confident that the format of the demodulated output changed or was encrypted.

DJI officially said it was encrypted, but recently a company claimed it had successfully decrypted it.

@wanhongwu1998
Copy link
Author

Thank you for your reply. I'm sorry that it is not convenient to export the data I collected to you! To be sure, CRC was successful, so I'm more confident that the format of the demodulated output changed or was encrypted.

DJI officially said it was encrypted, but recently a company claimed it had successfully decrypted it.

I doubt they can parse encrypted data. If encrypted data can still be parsed, then DJI's engineers are useless, and of course it doesn't rule out that they have superior abilities or have some special deal with DJI.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants