proto17 / dji_droneid Goto Github PK

License: MIT License

MATLAB 87.40% C++ 12.60%

dji_droneid's Introduction

DJI DroneID RF Analysis

THIS IS A WORK IN PROGRESS!!!

Also, the credit for this work is not mine alone. I have several people who are helping me through this process. Without their hints about how the signal is structured I would not have gotten very far in this short a time. So thank you very much to those who have assisted me to this point!!!!

To that point, huge thanks to the following people / groups:

Chair for System Security @ Ruhr-Universität Bochum / CISPA Helmholtz Center for Information Security

This project aims to demodulate DJI DroneID frames and eventually be able to craft arbitrary DroneID frames that can be sent with an SDR

The .m files in this project should work with Octave 5.2.0 and MATLAB. If using Octave, make sure to install the signal package

The IQ file used in this example will not be made available publicly as it likely contains GPS information about where the drone was when the recording was taken. The drone used in testing is the DJI Mini 2 with no modifications. Recordings were taken with an Ettus B205-mini at a sampling rate of 30.72 MSPS. The signal of interest is in 2.4 GHz and will show up every 600 ms or so. It will be 10 MHz wide (15.36 MHz with guard carriers).

How to Process Samples

You will need to record DroneID bursts with an SDR, save the samples as 32-bit floating point IQ data, and then edit the matlab/updated_scripts/process_file.m script to read your file. If there is a major frequency offset (say you recorded 7 MHz off center) you will need to specify that in the script.

List of tasks:

Identify ZC sequence (done)
Detect ZC sequence (done)
Coarse frequency offset detection/correction (done)
Fine frequency offset detection/correction (skipped)
Phase correction (done)
Equalization (done)
Symbol extraction (done)
Descrambling (done)
Turbo Product Code removal (done)
Deframing (done)
Profit!

Identify ZC Sequence

This was completed by brute forcing through all of the possible ZC sequence root indexes for 601 output samples. I was at a complete standstill until it was suggested that I try all possible combos, and it turns out that it wasn't all that difficult.

The tricky bit was that you need to generate 1 plus the number of data carriers (always 600) worth of ZC sequence, zero the center element, map the generated samples onto the center of an FFT (number of bins is based on sample rate), and compute the IFFT. The resulting time domain samples can be cross correlated against a recording of the same sample rate to find the sequence.

The root indices are

600 for the first ZC sequence
147 for the second ZC sequence

Detect ZC Sequence

This is being done using a normalized cross correlation with a golden reference. The first ZC sequence is generated in MATLAB and that copy is used to find the ZC sequence in the collect.

Coarse CFO Detection/Adjustment

Currently using the cyclic prefix of the first OFDM symbol to detect and correct for coarse frequency offset.

I don't think this will work should the CFO be very large. I suspect anything over 1 FFT bin (15 KHz) is going to fail to demodulate

Fine CFO Detection/Adjustment

It seems that the coarse offset estimate using the cyclic prefix is doing just fine and does not need help from a fine offset adjustment.

Phase Correction

This ended up being a little more difficult than expected. If the time that the first sample is plucked from the airwaves does not happen at exactly the right time, then there will be a fractional time offset. This fractional time offset will show up in the frequency domain as a walking phase offset. Meaning that each OFDM carrier has an accumulating phase offset left to right. If the first carrier might have an offset of 0.1 radians, the next 0.2 radians, then 0.3 radians, etc. Since there are no pilots, the phase offset estimate has to come from the ZC sequences. But, using the first or second ZC sequences to adjust phase for each OFDM symbol works fine for the OFDM symbols directly to the left and right (in time) of the used ZC sequence, but not so well for the others. Each other OFDM symbol will have a constellation that is rotating more the further from the ZC sequence it's located.

To deal with this, the channel for each ZC sequence is calculated, and the phase difference between those channels is calculated. This difference divided by 2 is the walking phase offset. That walking phase offset is then used to adjust each of the other OFDM symbols to get all of the constallations locked properly.

Symbol Extraction

This is super simple and just requires being time and frequency aligned with knowledge of the cyclic prefixes

Descrambling

Thanks to some kind souls this has been figured out. In the case of the 9 OFDM symbol drones, the first OFDM symbol gets zero'ed out by the scrambler, and then the scrambler starts over for the remaining 8 OFDM symbols.

Turbo Product Code Removal

There is a C++ application in the repository to handle this

Deframing

This is known, and a deframer will be added at a later date

Known Values

Frequencies

Look in 2.4/5.8 GHz for the Drone ID frames Some frequencies I have noted thus far:

2.4595 GHz
2.4445 GHz
2.4295 GHz
2.4145 GHz
2.3995 GHz
5.7565 GHz
5.7765 GHz
5.7965 GHz

There might be others, but that's just what I've seen

Burst Duration/Interval

The Drone ID bursts happen ~ every 600 milliseconds The frequency varies and I've heard that there is a pattern to it, but cannot validate with my SDR as the bandwidth isn't high enough Each burst is 9 OFDM symbols with two symbols using a long cyclic prefix and the others using the short sequence (see below for edge case)

OFDM Structure

As mentioned above, there are 9 OFDM symbols (see below for edge case) The 4th and 6th symbols (1-based) appear to be Zadoff-Chu (ZC) sequences (these are used in LTE and I know for a fact they are present in the uplink signal for Ocusync). The parameters for the ZC sequences are not known. I have first hand knowledge that the sequences are almost certainly not following the standard. The remaining OFDM symbols carry just a QPSK. If there are pilots they are either QPSK pilots or a 45 degree offset BPSK. As pointed out by https://github.com/tmbinc/random/tree/master/dji/ocusync2 the DC carrier appears to always be sitting around 45 degrees with a much smaller amplitude than the data carriers. Not totally sure what's going on there.

8 OFDM Symbol Edge Case

It turns out that some drones don't send the first OFDM symbol. Instead they skip it and end up with their OFDM symbol 1 being the 9 OFDM symbol cases 2nd OFDM symbol.

Since there's no change to the order of the symbols, and the 9 OFDM symbol case's first OFDM symbol being useless, the scripts in this repo treat all bursts as having 9 OFDM symbols and just don't do anything with the first OFDM symbol.

Current Questions

Cross Correlation

MATLAB can do a normalized cross correlation using xcorr(X, Y, 0, 'normalized') but it's crazy slow. So I wrote my own function normalized_xcorr.m that is ~ 8x faster than xcorr but over 100x slower than the filter function that was being used. If anyone has a better idea on how to do a truly normalized (0.0 - 1.0) cross correlation please let me know.

Burst Extraction

Right now the normalized cross correlation mentioned above is used to find the bursts using process_file.m. Since the cross correlation is so slow, a file that contains tens of millions of samples takes a long time in MATLAB and an even longer time in Octave. The old method of using the filter function was blazing fast, but there was no way to know what the correlation thresholds needed to be without making multiple passes through the file. Energy detection would probably work, but that falls apart in low SNR conditions. A normalized autocorrelation would likely be as slow as the cross correlation, which probably rules out autocorrelating for the ZC sequence. I'd love to hear some ideas to help speed this process up.

dji_droneid's People

Contributors

Stargazers

Watchers

dji_droneid's Issues

Got some questions

Hello
I am very interested in this project
I have some questions
For starters, are there any links to a guide to getting it started?
Secondly, I would like to run this on the bladeRF, namely the fake radiation of some random signal from the DJI drone
That is, the point is that bladeRF would pretend to be some kind of DJI drone
I was interested in this project, because apparently it can be used to spoof signals on SDR
Waiting for an answer from you)

ocysync 3

i have tried the same method on the ocusync 3 frame id and i get the frames but when i try to decode it fails have u ever tried it ?

zc_start + 6

Hi,

on the commit a731a12660eb10d352d944287b49cddf6cee2b31 a new line
zc_start = zc_start + 6; (line 196, file process_file.m) was added.

I was expecting the previous line zc_start = long_cp_len + (fft_size * 3) + (short_cp_len * 3); to be enough.
Would you mind explaining why this line was added?

Thanks

samples for tests

Hi
Having not found success in samples captured from pluto sdr ive found some samples here from a similar project, its captured with the same sdr as this project https://github.com/RUB-SysSec/DroneSecurity/tree/public_squash/samples
so wondering if anyone tried this before.? thanks BR

Low Correlation Scores

I used a sample file from https://github.com/RUB-SysSec/DroneSecurity,and then i changed the paramters of process_file.m like this:

i got low Correlation Scores.

Could someone help me?

Unable to capture with HackRF

Pretty much as the title says, I'm running into issues attempting to capture DroneID data (Occusync1.0/2.0) with the HackRF_One, irrespective of what I change with the configuration the width of the device itself appears to be too narrow.

Posting here as requested, link to:

#1 (comment)

the problem of frequency_offset

Hi, in the file of process_file.m , there is a frequency_ offset variable, while also inputting the extract_bursts_from_file function, and you also mentioned in the comment "How far off from DC the signal is in the recording", I would like to know the frequency_offset is the sampling center frequency of SDR? For example, I used USRP for sampling at 2.4445GHz with a bandwidth of 10MHz and frequency_offset is 2.4445GHz.
Thank you.

Mavic 3 DroneID descrambling

Hello everyone,
I'm trying to decode the Mavic 3 DroneID, but there's something I don't understand.
In your guide @proto17 you say that each burst contains 4 symbols with ZC sequences, and the remaining 6 symbols are data symbols, the same number as in the DJI Mini 2. However, for the Mini 2 the first data symbol is discarded before the descrambling, so in total there are 7 data symbols and 2 ZC symbols.
If I remove the first data symbol in the Mavic 3 droneID burst I end up with 5 data symbols, and the descrambling step fails because it needs 6 symbols.
So, my doubt is: for the Mavic 3, do I have to add the first data symbol for the descrambling, or the descrambling process isn't the same as the Mini 2?
Thank you

Some problem

I think that the signal was collected correctly. (CF = 5.7965GHz), sometimes I could show the target signal(drone-id burst)

Because The output of drone_id_test.grc (Found burst @ xxxx/xxxx) and I was checked that Burst was detected at regular intervals.

After that, I saved the output file collected by filesink block and ran updated_scrits/process_file.

However, only the output shows that burst is not found. I tried several times, but I couldn't check the result.

I used the "gr-droneid-update" branch.

normalized_xcorr_fast undefined

Hi! @proto17
I try follow manual https://github.com/proto17/dji_droneid/wiki/DJI-Mavic-3-DroneID-Analysis
But i cant find normalized_xcorr_fast.
May be you forget commit this file?

Signal Detection

The following is the signal I collected using USRP. May I ask if this is a DroneID burst signal?

Compiled version of the "add_turbo.cc" and "remove_turbo.cc"

I'm excited about dji_droneid. I have a USRP B200. Furthermore, I want to test the DroneID burst using these codes.
But I work with Matlab in windows. Accordingly, Please send the Compiled Windows version of the "add_turbo.cc" and "remove_turbo.cc"?
Thanks a lot 😃

How to decode the bits?

I got the bits successfully, and how to decode it to get the information?

I don't understand what is mean this results

Hi!
I need your help.
I received this output. What's mean this results? How I could get drone_id data from this results?

Found burst @ 587225372 / 587225371
7c3ff9feefc6eeebfffc60f5f57db7c1e38febffafbd5417dfffde7fbcSending message with af27952 elements (7e27952) starting at 587225371
f4Found burst @ 587253384 / 587253383
7b34b9bfcfdaec37bfffb9669deedffde8aef6ffbe65b5056dbf7bf76f17beb5fc1d8a8cffef7bafc6f6f7ff6f17fff7fb3033d97fdf4bddc95fffe6acfc1ffe77e5ed273fbfffc52891fbfd979af5efed5f9c95e5bffbfee376737b743779bfffd9fd6d415fdfecd93bc6e7efff297773f7dfa33ebbfddfb665aeed7fde4ee62f7befeeff5a3b74b77958396dfffd99
CRC Check Failed!
Sending message with 27952 elements (27952) starting at 587253383

ZC start index: 9761, est start index: 3025
Sending message with 27952 elements (27952) starting at 591369583
Found burst @ 591397563 / 591397562
Sending message with 27952 elements (27952) starting at 591397562
Found burst @ 591427851 / 591427850
Sending message with 27952 elements (27952) starting at 591427850
Found burst @ 591490373 / 591490372
f68ffffdefff57fc877ff46ac7fffbefaff72eff75b5ddfb7febfefbffd9ff7fbfed6f7cdb7bfd703becdf3b2fbffdb7eb7ee87ff7c5f9fdb9ff5fe7ed0e7ffc9fdffacb8ffffbb6ddf7bfSending message with 27952 elements (27952) starting at 591490372
fddd4fcc7dffff56b6efddf7fbfdfd3fefbbe99fe7bfbde1e9fe77cfb57e6dfffe6ffad3bbfff7febdacaeff7fefe663efbade97dacdfffbf57eb5f8f7fd59c3fffff777767ecfb5ffeb3bb77f9f57f55ddaf5dfbc63ff7a7f3e13bdaf7bcfdbe777aff47e
CRC Check Failed!
Found burst @ 591547527 / 591547526
Sending message with 27952 elements (27952) starting at 591547526

Found burst @ 1190562407 / 1190562406
Sending message with 27952 elements (27952) starting at 1190562406
35d77a616024d9daf4c571e6b6afb784068787d71b363667777a0c1a50f73efe0a7f78fb6095903f7c7161f9ea3b2be847d36be5a7d105c8accf684557a1d457e113969fFound burst @ f2b41ac8471f6c4d6714119062905751 / eae9d2a5541190629056b17ff4
32394d6b6f9c4325b97d8dc9a1758f6de6646fbfeb975493dab0beb416a42c4e771c476be35a2a50d05ece30898deb47892165a6d9f7f48033afbccfa6e917afd7df8889d07f9e37043cdb3f1a526a8bdcfb5a907fef3c09ad
CRC Check Failed!
Sending message with 27952 elements (27952) starting at 1190629056

Where is the deframing code?

DJI DroneID frames & burst generation and demodulation test

Hi there,
Very interesting work and write-up. I'd love to test proto17 /dji_droneid
First, I generated the frames with the appropriate hypothetical data and generated the DJI DroneID burst.

Then I gave that signal to the file process_file.m
But even though the correlation levels in matlab/octave is greater than 0.7, the following error was reported
I either get:

Is the issue with running the bursts through MATLAB is that some amount of padding either side of the burst is required in order to do some of the operations. , or have I configured something incorrectly?

Thanks for all your work, very interesting repo!

License

Hi,

Is this project using an MIT license?

Thanks,

some questions

Hi there,

When I am using the gr-droneid branch with a mavic air 2, gnuradio console displays offsets/phase angle etc. and i see some extracted constellation results in the QT constellation diagram which I assume corresponds to gnuradio extractor/demodulator blocks working properly. But when I check the /tmp/bursts folder I only see a zc and channel file.

I have watched the DragonOS youtube videos and in those videos it seems that thee bursts are getting recorded as well (file_1, file_2, etc.). As I mentioned I only got files named zc and channel getting created in the folder. Does this mean something is not working correctly, or is this normal behavior?

My other question is regarding computation time for the process_file.m script. I have a fairly decent machine (16 cores, 16GB RAM) and running the octave script on 2GB of fc32 recording takes a very long time. Is this normal, or have I configured something incorrectly?

Thanks for all your work, very interesting repo!

different sequence

Hi, i followed your wiki for mavic 3 pro.

I have captured a different sequence, but it is not a ZC sequence. Do you know what type of sequence this is?

AttributeError: module 'gnuradio.fosphor' has no attribute 'glfw_sink_c'

Hello, there was a problem running correlation_test.grc. My system is ArchLinux. GnuRadio 3.10 from the repository. Gr-fosphor (latest version) is taken from github. Glfw was installed according to the instructions from https://www.osmocom.org/projects/sdr/wiki/Fosphor

I ask for help in solving the problem. Thank you.

[INFO] [B200] Actually got clock rate 30.000000 MHz.
[INFO] [MULTI_USRP] 1) catch time transition at pps edge
[INFO] [MULTI_USRP] 2) set times next pps (synchronously)
Traceback (most recent call last):
File "/home/user/correlator_test.py", line 357, in <module>
main()
File "/home/user/correlator_test.py", line 335, in main
tb = top_block_cls()
File "/home/user/correlator_test.py", line 187, in __init__
self.fosphor_glfw_sink_c_0 = fosphor.glfw_sink_c()
AttributeError: module 'gnuradio.fosphor' has no attribute "glfw_sink_c"

Done (return code 1)

Zc sequence identify

Hi, I m interesting about your brute testing to get the root for drone ID zc. Have you tried that on the DJI downlink signal?
My test for downlink zc got a wired result, which has only one root answer for 1022 (I suppose there are two type of zc in one frame). There must be some errors I missed.

Can not capture the DroneID signal.

I have tried all frequencies you given on Mavic2, but I still can not find the DroneID signal. Can you give me some example picture?
You said the DroneID signal is about 10M bandwidth, and time of duration is 600ms, but I did not see such signal.
Should I turn on the controller or link the phone App to capture the DroneID signal?

cfo detection

isnt in this line the conjugate needed?

    offset_radians = angle(dot(cyclic_prefix, symbol_tail)) / fft_size;

    offset_radians = angle(dot(cyclic_prefix, conj(symbol_tail))) / fft_size;

Final step error: NO DRONE ID

Hi, in MATLAB i try a captured file but after a while i get this result
In process_file (line 330)
Warning: Failed to run the final processing step

does the drone ID structrue same in lightbridge?

Hello there

I know DJI no longer uses the lightbridge for video transmission, but there are some third parties still using it. do they transmit the drone ID too? if so, is the packet structure the same?

thanks

gr-drone-update block error

With GNU Radio 3.8.1 the following shows on loading of the drone_id_test.grc file, but not sure if it's a negative impact as the flow graph still loads.

WARNING:gnuradio.grc.core.platform:droneid_misc_utils.block.yml block: error: Value type 'NoneType' for 'parameters' not in valid types WARNING:gnuradio.grc.core.platform:droneid_misc_utils.block.yml block: error: Value type 'NoneType' for 'inputs' not in valid types WARNING:gnuradio.grc.core.platform:droneid_misc_utils.block.yml block: error: Value type 'NoneType' for 'outputs' not in valid types INFO:gnuradio.grc.core.platform:YAML schema check failed for: /usr/local/share/gnuradio/grc/blocks/droneid_misc_utils.block.yml
Does this replace the use of the turbo encoder/octave script? Just reading over all the new commits, can't wait to try again.

Detect DroneID burst without "gr-fosphor"

Hi, I have a few questions about this.

I want to capture DroneID burst via HackRF (not decoding, just burst detection). You used GNU Radio's gr-fosphor, but I can't use this module due to environmental problems (I have some error about gr-fosphor 😥).

So I want to capture it using a different visual module. Can I detect DroneID burst using "QT GUI Sink" block or other blocks? (or using a radio receiver such as gqrx)

gnuradio import droneid

Had to clone turbofec (https://github.com/ttsou/turbofec) & CRCpp (https://github.com/d-bahr/CRCpp) in order to build on Ubuntu 22.04 with gnuradio 3.10.

However when I go into the droneid_test.grc, it comes up with an error about importing droneid.

It does show the droneid grc blocks in gnuradio-companion however.

TypeError: make() missing 1 required positional argument: 'arg2'

Good evening. I switched from the gnuradio branch to the new gnuradio branch, uninstalled and then installed the latest.

While performing a quick test (on same machine the older gnuradio flowgraph ran on) I now encounter this upon starting and wondered if it's just me or if anyone else is having this issue,

`[INFO] [B200] Detected Device: B205mini
[INFO] [B200] Operating over USB 3.
[INFO] [B200] Initialize CODEC control...
[INFO] [B200] Initialize Radio control...
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
[INFO] [B200] Setting master clock rate selection to 'automatic'.
[INFO] [B200] Asking for clock rate 16.000000 MHz...
[INFO] [B200] Actually got clock rate 16.000000 MHz.
[INFO] [B200] Asking for clock rate 30.720000 MHz...
[INFO] [B200] Actually got clock rate 30.720000 MHz.
[INFO] [MULTI_USRP] 1) catch time transition at pps edge
[INFO] [MULTI_USRP] 2) set times next pps (synchronously)
Traceback (most recent call last):
File "/tmp/drone_id_demod_test.py", line 357, in
main()
File "/tmp/drone_id_demod_test.py", line 335, in main
tb = top_block_cls()
File "/tmp/drone_id_demod_test.py", line 222, in init
self.droneid_extractor_0 = droneid.extractor(samp_rate / decimation, )
TypeError: make() missing 1 required positional argument: 'arg2'

Done (return code 1)
`

Fast correlation

In README you mention:

A normalized autocorrelation would likely be as slow as the cross correlation, which probably rules out autocorrelating for the ZC sequence. I'd love to hear some ideas to help speed this process up.

If you have access to a decent GPU, it might be worth giving CuPy and CuSignal a shot.

(Question) Ubuntu 22.04 Usage

I was taking a look at updating everything from 20.04 to 22.04. There's several branches of your code now, with the gr-droneid-rewrite branch looking to be the newest (3.10).

It appears that branch may be consolidating what's in main along with the necessary GNU Radio parts? Would it be best to use that branch or hold off for now?

I was also wondering if you happened to have tested the Octave version included in 22.04 with your Matlab scripts.

parameters of descrambler

Hi proto:

I find that the parameters of descrambler have been revealed in your github repository.
May I ask how did you obtain these parameters?
via brute force or firmware reverse engineering?
Thanks!

Regards,
Stan

Ocusync 3

Hi, i followed your wiki for mavic 3.
And when i did bruteforce for root, i found 147 and 600 roots, not 385.

And graph with 147 root shows that we have symbols with width 256 samples.
And i don't know, why there are not 385 root.
I can send you samples of mavic 3 and mavic 3 mini pro

Proposal for normalized cross correlation

Hope this helps:

https://isas.iar.kit.edu/pdf/SPIE01_BriechleHanebeck_CrossCorr.pdf

Python bindings for utils.h are out of sync

Attempted to Compile the rewrite branch on Ubuntu 22.04. The following issue during Cmake is preventing me from moving forward with testing.

-- Using install prefix: /usr/local
-- Building for version: 1.0.0.0 / 1.0.0
-- No C++ unit tests... skipping
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE) 
-- PYTHON and GRC components are enabled
-- Python checking for pygccxml - found
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.10.so
-- Performing Test HAS_FLTO
-- Performing Test HAS_FLTO - Success
-- Found pybind11: /usr/include (found version "2.9.1")
CMake Error at /usr/local/lib/cmake/gnuradio/GrPybind.cmake:239 (message):
  Python bindings for utils.h are out of sync                                                                                                                  
Call Stack (most recent call first):                                                                                                                           
  python/dji_droneid/bindings/CMakeLists.txt:36 (GR_PYBIND_MAKE_OOT)

(Suggestion) Automate switching to known freqs

Would it help any to apply some of the logic here?

https://github.com/jhonnybonny/CleverJAM

Except instead of running the command to change the center freq of the transmission, use it instead to control the xmlrpc portion of
gnuradio in such a way that the receive center freq would change between known/suspected DJI Drone ID freqs.?

A set amount of time to camp on each center freq can be set, that's got to be better then trying to move around manually trying to find it.. right? I figure it's got to get lucky at some point and capture the bursts for post processing or processing in real time?

Had the thought earlier and figured I'd share it before I forgot.

Some questions and issues.

Hello, I would like to ask you several questions.

It is still maintained that it is necessary to record the IQ signal with the .fc32 file in GNURadio for Octave to process the process_file.m? The bursts that are stored when you record the signal in temp/droined_debug, which are obviously smaller files, aren't they still useful to obtain the result?
The versions that are in the branches of rewrite and update-3.10 do not work for me in octave when I execute the process_file. It gives an error that it cannot find the Turbo decoder (remove_turbo). Any idea why it gives me this error?

Thanks

(Question) drone_id_test.grc failed to output file

Very interesting work and write-up. I'd love to test against a Mavic 3, however, after installing w/ GR 3.8 and attempting to run w/ a B205mini I get the following when running the drone_id_test.

FFT SIZE: 1024, sample rate: 1.536e+07
Traceback (most recent call last):
  File "/home/dragon/dji_droneid/gnuradio/drone_id_demod_test.py", line 350, in <module>
    main()
  File "/home/dragon/dji_droneid/gnuradio/drone_id_demod_test.py", line 328, in main
    tb = top_block_cls()
  File "/home/dragon/dji_droneid/gnuradio/drone_id_demod_test.py", line 218, in __init__
    self.droneid_demodulation_0 = droneid.demodulation(samp_rate / decimation)
  File "/usr/local/lib/python3/dist-packages/droneid/droneid_swig.py", line 845, in make
    return _droneid_swig.demodulation_make(sample_rate)
RuntimeError: Failed to open output file

I suspect it's something to do with the note about 1024 FFT and maybe my use of the 205. Although the failed to open output file has me confused. I'm not super familiar with how the droneid_swig.py is generated besides what I quickly researched after reading the top of the file saying that it's automatically generated.

The correlation_test flow graph has no problems running.

Ocusync 4 cannot be resolved

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.

This DJI Drone ID Not Working for Phantom 4 Pro v2.0 Data

Hello @proto17
We have recorded the DJI Phantom 4 Pro v2.0 Data with our IQ Recording system.
We have reached till the CPP calling function in the matlab code.
But the CRC error is coming for all the frames that are decoded.

Is there any possible solution for this. Or is there any packet structure for the DJI Phantom 4 pro v2.0

baudline not available

"I am able to obtain the DroneID, but how can I retrieve the start time of the burst and determine its duration?" as baudline is not available any more

CRC.h error with gr_droneid-update

I haven't touched this in awhile but wanted to swing back around and update from gr_droneid to the update branch, but now I'm forgetting how I got the CRC.h to be seen while running make after cmake on the new branch. Do I need to place the CRC.h somewhere for it to be seen? Been moving it around with no luck, I know I got this to build before.

Cross-correlation of zc sequence and samples looks error

Hello everyone
I tried run the uav iq data in code matlab/updated_scripts/process_file.m.
The cross-correlation of zc sequence and samples looks wrong. The results dosen't have a good correlation peak.
The relevant parameters are as follows:
Data record board: usrp b210, sample rate 30.72MHz
UAV type: DJI AIR2, transmission system is DJI OCUSYNC 2.0.

edit the matlab code as follows:
file_sample_rate = 30.72e6;
chunk_size = 10e6;

Waterfalls:

Spetrum:

Result of cross correlation:

This doesn't work with Enhanced Wifi on Mini SE, Mavic Air, or Spark series

Correct, it should not, they are not occusync. Since people keep asking, this will help detect DroneID on Enhanced Wifi.
gr-ieee802-11_quiet_EnhancedWifi_v2_diff.txt

Apply to: https://github.com/bastibl/gr-ieee802-11

This is just a lazy proof of concept. You need to channel hop across the known channels for a more effective tool.

Failed while building gr-droneid

Hi!
I need help with building gr-droneid.
I did next steps:
cd gr-droneid
mkdir build
cd build
cmake ..
make

When i do last step i take error

gr-droneid/lib/extractor_impl.cc:35:21: error: could not convert ‘gnuradio::get_initial_sptr(T*) [with T = gr::droneid::extractor_impl]()’ from ‘std::shared_ptr<gr::droneid::extractor_impl>’ to ‘gr::droneid::extractor::sptr’ {aka ‘boost::shared_ptr<gr::droneid::extractor>’}
   34 |             return gnuradio::get_initial_sptr
      |                    ~~~~~~~~~~~~~~~~~~~~~~~~~~
   35 |                     (new extractor_impl(sample_rate, threshold));
      |                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                     |
      |                     std::shared_ptr<gr::droneid::extractor_impl>
make[2]: *** [lib/CMakeFiles/gnuradio-droneid.dir/build.make:63: lib/CMakeFiles/gnuradio-droneid.dir/extractor_impl.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:277: lib/CMakeFiles/gnuradio-droneid.dir/all] Error 2
make: *** [Makefile:141: all] Error 2

Please, help!

(Question) Clarification on branches

Just wanted to make sure I'm getting things setup right for another test on GNU Radio 3.8. Although there's a specific branch for 3.8, is it safe to say the gr-drone-update branch is actually the newest for 3.8? However it's a ton behind main, so git checkout the update branch, build and install and then switch back to main for all other things that are newer?