Failed while building gr-droneid
lobart opened this issue · 39 comments
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!
What version of gr did you use?
Apologies for the delay. I just took a crack at this. I have moved on to GNU Radio 3.10 and totally forgotten what the original code was written for. Turns out it was written for 3.8. Using the Dockerfile below I can successfully build with GNU Radio 3.8. But, that is not true for 3.9 or 3.10 as GNU Radio moved to pybind11 which means that CMake will bomb on the GrSwig dependency.
You can change the version of GNU Radio by modifying the checkout command in the GNU Radio section.
# Builds VOLK, GNU Radio, and gr-droneid using GNU Radio 3.8
#
# Has one build argument:
# threads => Number of threads to use for building VOLK, GNU Radio, and gr-droneid
#
# Example docker command:
# docker build . -t gr-droneid:3.8 --build-arg threads=$(nproc)
FROM ubuntu:22.04
RUN apt-get -y update
RUN apt-get -y upgrade
# Annoying timezone fix for Ubuntu 22.04 and unattended apt installs
# (https://serverfault.com/questions/683605/docker-container-time-timezone-will-not-reflect-changes)
ENV TZ=America/New_York
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
# From https://wiki.gnuradio.org/index.php/UbuntuInstall for 20.04 and 3.8.x/3.9.x
RUN apt install -y git cmake g++ libboost-all-dev libgmp-dev swig python3-numpy \
python3-mako python3-sphinx python3-lxml doxygen libfftw3-dev \
libsdl1.2-dev libgsl-dev libqwt-qt5-dev libqt5opengl5-dev python3-pyqt5 \
liblog4cpp5-dev libzmq3-dev python3-yaml python3-click python3-click-plugins \
python3-zmq python3-scipy python3-gi python3-gi-cairo gir1.2-gtk-3.0 \
libcodec2-dev libgsm1-dev
RUN apt install -y pybind11-dev python3-matplotlib libsndfile1-dev python3-pip libsoapysdr-dev soapysdr-tools
RUN pip install pygccxml
RUN pip install pyqtgraph
# Controls the number of threads used for building
ARG threads
# Build VOLK
WORKDIR /opt
RUN git clone --recursive https://github.com/gnuradio/volk.git
RUN cd volk && mkdir build && cd build && cmake .. && make -j $threads && make install && ldconfig
# Build GNU Radio
WORKDIR /opt
RUN git clone https://github.com/gnuradio/gnuradio.git
RUN cd gnuradio && git checkout maint-3.8 && git submodule update --init --recursive && mkdir build && cd build && cmake .. && \
make -j $threads && make install && ldconfig
# Build gr-droneid from dji_droneid repo
WORKDIR /opt
RUN git clone https://github.com/proto17/dji_droneid
RUN cd dji_droneid && git checkout gr-droneid && cd gnuradio/gr-droneid && mkdir build && cd build && cmake .. && make -j $threadsHi!
Thank you for reply!
But my pc is overload when i try to build this Dockerfile :(
I wanted to use version 3.10 too.
Do you have RC or minor version of your soft for gnuradio 3.10, i can test it on mavic mini?
Regards!
Unfortunately no, there's nothing in the 3.10 branch (local to my desktop right now) that can be used. I will try to convert the 3.8 code to 3.9 and 3.10 when I get a chance. I can't promise when that will happen :(
I created a gr-droneid-3.10 that has all of the blocks converted to GNU Radio 3.10. Unfortunately something is wrong with pybind11 and the utils class. This breaks the flow graph (which also isn't updated). I'll have to poke more at it as I have time. Currently all I can say for certain is that the code compiles with two of the modules working (demodulation and time_sync)
Just realized that all the porting I did was for the wrong code 😭 so ignore that last comment...
There’s someone out there that’d probably love to help convert to 3.10. I’ll shoot them this link.
@alphafox02 Reping. Porting should be no problem. As I've already ported hundreds of gr modules, I can port yours as well @proto17, if you want.
Oh wow, thank you very much @bkerler and @alphafox02!! 🥂
I merged @bkerler's changes that move the gr-droneid branch to 3.10. So now gr-droneid is 3.10 and the gr-droneid-3.8 repo is available for those that are running an older version of GNU Radio.
Additionally I created a 3.10 version of gr-droneid-update as it's the latest version of the OOT module. But, it currently sucks for demod as it doesn't do a good job of freq offset adjustment and start time offset calculation. It's only real use at the moment is to save off bursts for processing with MATLAB/Octave. I'm not sure if I will try to fix it or just wait until the rewrite is complete.
Thank you! @proto17 @bkerler !
Now i'm testing this with b210 and mavic mini with rc.
I see packets on waterfall and i write file, but matlab cant find any burst in my file.
https://drive.google.com/file/d/1dYA-reV4AwjP_MJ47m3JivZkVaDy8ssV/view?usp=sharing
All parameters is default, only frequency is 2.422GHz.
Is this tool work with mavic mini?
I downloaded the file. I recommend that you delete that file from your drive or at least unshare it. There is potentially personal information contained in that collect. I'll try to take a look tonight, but my weekend is really busy and I will be at the GNU Radio conference all next week.
As for whether or not the code can process a Mavic Mini, I'm not sure. I've seen a collect of the Mavic 3 and it uses a different structure of ZC sequences so it will not work at all [1]. Your drone might be the same.
[1] https://github.com/proto17/dji_droneid/wiki/DJI-Mavic-3-DroneID-Analysis
@lobart The file you provided does not contain any DroneID bursts. You didn't say what the sample rate was and the frequency you specified is not known to me to have DroneID bursts. At first I thought you might have captured the uplink, but that usually hops. The only one that stays stable is the downlink. But that one is usually pretty wide. That is unless you have a drone that is using WiFi and you recorded the 5 MHz WiFi signal. If you recorded at 15.36 MSPS that would make sense as I see a signal that's ~ 5 MHz wide at that rate (10 MHz if you sampled at 30.72 MSPS). I also see 12 pilots (or at least what I think are pilots) which would definitely exist in WiFi. All of that is guesswork though.
Here is a screenshot of baudline with your file open.
In fact, I think that the Mavic Mini might be a WiFi only drone.
I was super curious about the signal you posted so I ran it through MATLAB a little.
Here is the time domain (10 * log10(abs(samples).^2)) of one of the bursts
I have labelled the center of each OFDM symbol. Handily it looks like all of the symbols are BPSK which has this really neat feature that when looking at the time domain power squared you can see symmetry in each OFDM symbol that contains nothing but BPSK samples.
The first two labeled points show the training sequence repetition rate. 507-458 is 49 which is really close to 48 which is 3x the normal WiFi short training sequence.
The next two labeled points are the long training sequence. This one is a bit strange. 950-754 is 196 which should be the FFT size in WiFi since this sequence does not have a cyclic prefix. But 196 is a strange FFT size. This hints that the sampling rate was not correct. Which kinda makes sense because WiFi doesn't operate on the strange LTE sample rates.
The remaining points show the individual data symbols. The FFT size here is 196 with a 50 sample cyclic prefix. The cyclic prefix can be determined by again exploiting the symmetry of the BPSK samples. The cyclic prefix will show up as a symmetry of it's own. Honestly, it might not just be a feature of BPSK, but it definitely shows up with BPSK samples. Anywho, Looking point 1195 as an example, there is another symmetry to the left of it at ~ 1098. 1195-1098 is 97 which is really close to half of the FFT size (196 / 2 == 98). Then, you calculate the end of the preceeding symbol (the one marked by 950) by adding half the FFT size (98) to 950 which gives 1048 which is 50 away from 1098. That holds true through the burst.
As final proof that the cyclic prefix and FFT size are likely close (can't be correct because the sampling rate isn't right and I didn't bother trying to guess the correct resampling rate) here is a screenshot of all 7 OFDM data symbols
I haven't done any frequency correction or equalization, so there's a lot of drift. Thankfully your collect was with a good SDR so there's not a lot of freq offset :)
If you'd like to try it yourself here's the MATLAB script (dunno if it will work with Octave). Make sure to change the path to the collect. Also, I used my read_complex function from the Git repo so you'll need to make sure that's in your path.
clear all
samples = read_complex('~/example.fc32', 3064, 2846, 'single');
figure(1);
plot(10 * log10(abs(samples).^2));
title('Time Domain Abs Squared (10 log10)');
fft_size = 196;
cyclic_prefix = 50;
figure(10);
starting_offset = 1096;
for idx = 1:7
offset = starting_offset + (fft_size * (idx - 1)) + (cyclic_prefix * (idx - 1));
symbol = samples(offset:offset + fft_size - 1);
subplot(3, 3, idx);
plot(fft(symbol), 'o');
title(['Data Symbol ', num2str(idx)])
end@proto17 Cool, thank you a lot!
I try decode Mavic Mini signal, but i have not success.
Today i try to decode Mavic 2 pro.
2.4265Ghz, 10MHz BW, 15.36M sample rate, 1024 FFT size
But bursts are not found again.
I dont know what is wrong.
https://drive.google.com/file/d/16qCLnAGjVzK9R6Cs7a6FmVyO5W-v2m8L/view?usp=sharing
@lobart
It seems, you have recorded video signal, apart of beacons
Compare you signal
and beacon record
Look here
@V0rt But i dont see signal another of this.
I recorded new samples on all of frequency in your table.
And only on 2.4145Ghz was signal.
But process file didnt see any bursts.
Other frequency like this:
what does the correct signal look like?
Ok, sorry. I read DJI_drone_IDs_are_not_encrypted and saw, that frequencies for droneid belong range 2399.5 MHz to 2474.5 MHz. I wrote all FC in this range with step 5MHz.
I set frequency on my dji mavic 2 pro manually on 2407MHz with 10MHz BW.
Only in this window from 2402 MHz to 2412MHz was pronounced signals.
I was interested for this samples:
10mS duration
600mS
I wrote this part of samples to file:
And process_file answered:
[ERROR] CRC did not zero out. Got c0693d after calculation
warning: Failed to run the final processing step
.......................
[ERROR] CRC did not zero out. Got {another code} after calculation
warning: Failed to run the final processing step
FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME: FRAME:
File with data - https://drive.google.com/file/d/1CgqFmSiSSiXcNPp9U7XJnvMX1s32HHJh/view?usp=sharing
Another one signal of mavic 2 pro.
Another one signal of mavic 2 pro
BW 10MHz
Frequency 2.459GHz
Sample rate 30.72MHz
@lobart that last image you posed looks like DroneID. Did that work with the Octave/MATLAB? The other images you posted do not look like DroneID.
@proto17 Yes, this works with process_file, but doesn't work with gnuradio decode block.
I get this signal from big dump file by hand, then i do process_file in octave, then i do dji_decode.py from DragonOs.
And all is good, but all steps is manually.
@lobart That's not terribly surprising. The GNU Radio code is not up to date with the MATLAB (from the main repo). The equalization is atrocious, and the integer frequency offset correction is non-existent. It will be a while before I have time to really bring those two up to date with one another =\
Another one signal of mavic 2 pro
BW 10MHz Frequency 2.459GHz Sample rate 30.72MHz
what is name of this software?
I use the data file you given, but can not find any bursts.
Anything wrong?
@kyz20 You can send me your burst in WeChat wxid_9wghuvmb3w3712
is this a right WeChat ID? I can not search it. And my WeChat ID is Younidefenma
@kyz20 You can send me your burst in WeChat wxid_9wghuvmb3w3712
is this a right WeChat ID? I can not search it. And my WeChat ID is Younidefenma
Hi there, did you manage to find burst? I tried to sample all the frequencies in the paper at the same time, but found very few bursts, and cost a lot of time in calculating NCC.