dji_droneid
dji_droneid copied to clipboard
proto17
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:
https://github.com/proto17/dji_droneid/issues/1#issuecomment-1107517128
You cannot run the graph at arbitrary sample rates unless you take care of resampling to a valid rate (multiple of 15.36 MSPS.) Unfortunately I don't own a hackrf anymore, so I can't test here. I have been told that the DC spike on the hackrf is really strong compared to other SDRs. So you might have to do use offset tuning to get the spike out of the signal. The 8-bit sample depth will also make things more challenging when using a hackrf. You'll want to make sure you have a good strong signal.
Can you post a video of the fosphor display when you think there are droneid bursts? Can you also share a screenshot of your graph? The droneid bursts are very infrequent and hop over a large range of frequencies. It's very possible to wait for over a minute for bursts to show up, and even then you'll only see maybe 20 bursts before it changes frequency.
@proto17 "Unfortunately I don't own a hackrf anymore", just donated you one. Should be there Tuesday. Enjoy! Thanks for everything you've done here, and all the help you've given to folks asking questions. I appreciate ya! Hollar if you need anything else.
@proto17 "Unfortunately I don't own a hackrf anymore", just donated you one. Should be there Tuesday. Enjoy! Thanks for everything you've done here, and all the help you've given to folks asking questions. I appreciate ya! Hollar if you need anything else.
Thank you!!! :heart:
From a first test with the HackRF I see that there is quite a center frequency offset with the HackRF. It seems to be off by more than one carrier spacing (15 KHz) which I don't currently support. I am working on a way to deal with integer frequency offsets in the MATLAB branch (main)
The good news is that I was able to demod with the HackRF when I manually dealt with the integer frequency offset.
Just for educational purposes (and to be publicly corrected if wrong) the HackRF's oscillator supposedly has ~ 20 ppm stability/accuracy [1]. At 2.4 GHz that's 2.4e9 * 20e-6 or +/- 48 KHz [2] of frequency offset. The carrier spacing of the DroneID signal is 15 KHz, so that's ~ 3 carriers worth of error. For the only burst I've looked at I needed to correct for 2 carriers of frequency offset.
[1] https://github.com/greatscottgadgets/hackrf/issues/379 [2] https://www.sitime.com/ppm-calculator
From a first test with the HackRF I see that there is quite a center frequency offset with the HackRF. It seems to be off by more than one carrier spacing (15 KHz) which I don't currently support. I am working on a way to deal with integer frequency offsets in the MATLAB branch (
main)The good news is that I was able to demod with the HackRF when I manually dealt with the integer frequency offset.
Just for educational purposes (and to be publicly corrected if wrong) the HackRF's oscillator supposedly has ~ 20 ppm stability/accuracy [1]. At 2.4 GHz that's
2.4e9 * 20e-6or +/- 48 KHz [2] of frequency offset. The carrier spacing of the DroneID signal is 15 KHz, so that's ~ 3 carriers worth of error. For the only burst I've looked at I needed to correct for 2 carriers of frequency offset.[1] greatscottgadgets/hackrf#379 [2] https://www.sitime.com/ppm-calculator
Very interesting, thank you, I suppose this settles the discussion as far as the HackRF itself its concerned then!
But out of curiosity do you frequent any servers or such? As there's a couple of things I'd like to discuss but would be off topic for this particular issue.
Apologies for the delay. I wrote up a response and then never sent it :(
I need to find a way to deal with integer frequency offsets. It's not just a matter of the HackRF not being a great radio for the application. The demod could fail if the offset of the oscillator on the drone and the SDR combined cause too much of a frequency offset. This can happen with any SDR hardware. I've personally had this issue with Ettus radios when used to demod other drones in the past. It's not just a matter of having a great SDR =\
I've been experimenting with offset estimation techniques over the last week or so but haven't landed on anything that works in the presence of noise and channel just yet. If you have any ideas or know anyone that could help out, I would definitely welcome the assistance!!
This problem is my #1 priority with the DroneID work as it prevents people from using cheaper hardware as well as just being an incomplete implementation.
I ran some tests and I think I can get the starting time offset (STO) problem fixed using the cyclic prefixes [1] of all of the OFDM symbols. With a solid starting offset I can hopefully get better readings for the integer frequency offset (IFO) which is what this ticket is ultimately about.
[1] https://github.com/proto17/dji_droneid/blob/main/matlab/updated_scripts/cyclic_prefix_sto_test.m
I think I've got something that will work for IFO [1]. It seems to work reasonably well in simulation. Fractional time offsets still cause it trouble, but I think that can be solved by the equalizer or by upsampling the burst, then autocorrelating to find the best starting sample, then downsampling back to critical rate. Hopefully the equalizer will just take care of that problem for me. I hope to get a chance to test that Friday.
EDIT: The script linked will not work in Octave as it uses the MATLAB OFDM modulator and demodulator. I'll probably come back later and change those to work with Octave, but I was being lazy and also didn't want to risk dorking up my OFDM mod/demod methods thus making my tests invalid.
[1] https://github.com/proto17/dji_droneid/blob/main/matlab/updated_scripts/test_integer_freq_offset.m
@proto17 Do you have a recommendation on best way to play back the recorded IQ w/ b205mini? I wanted to test capture what I recorded again with a LimeSDR mini to see if it’s capable of getting the bursts. I tossed a LimeSDR source in the flow graph in place of the uhd one, seems like it’d work fine. I can then also follow along with the testing you’re doing with the hackrf.
edit: unrelated but I just realized you also have the helicopterdemod repo which I used like 2 years ago (mentioned on rtlsdr blog).
First off, I recommend creating a file with multiple bursts. Then create a GNU Radio flow graph with a file source, scaling block (to scale the output samples up or down to keep them between -1.0 and 1.0), and a UHD sink. The file source should be configured to repeat. You should then be able to TX the bursts. Just make sure to set the sample rate of the graph to match the sample rate of the generated bursts (probably 15.36e6). I might be able to write up a dumb example this weekend.
One important thing to remember is that if your radio has a really strong DC spike, you might have issues receiving.
I tried playing the entire IQ file as recorded back by adding a uhd sink to the flow graph connected directly to the file source. I removed offsets and messed around with gain. I couldn’t seem to figure out the right settings on another computer receiving with the LimeSDR, probably user error. I did however replace the LimeSDR with a bladerf and was seeing the bursts being transmitted by the b205mini. So on the bright side, I think the bladerf can do the job. I also think I have a setup that’ll allow me to test the hackrf without having to go borrow another drone.
FYI, Kismet is providing DJI Drone ID detection : https://www.kismetwireless.net/development/droneid/
Yup! Kismet doing as Kismet does and being on top of new protocols :star:
The difference between what Kismet does and what this repo aims to do is that Kismet is processing the WiFi version of DroneID. This repo looks at the non-WiFi bursts. As far as I know Kismet does not currently support the non-WiFi bursts.
Yup! Kismet doing as Kismet does and being on top of new protocols ⭐
The difference between what Kismet does and what this repo aims to do is that Kismet is processing the WiFi version of DroneID. This repo looks at the non-WiFi bursts. As far as I know Kismet does not currently support the non-WiFi bursts.
I would be very interested in your work being integrated in Kismet to support the OcuSync type bursts !
Yup! Kismet doing as Kismet does and being on top of new protocols star The difference between what Kismet does and what this repo aims to do is that Kismet is processing the WiFi version of DroneID. This repo looks at the non-WiFi bursts. As far as I know Kismet does not currently support the non-WiFi bursts.
I would be very interested in your work being integrated in Kismet to support the OcuSync type bursts !
I don't know if Kismet supports SDR platforms. My understanding is that Kismet uses COTS WiFi adapters to listen for all manner of WiFi frames. Since the variation of DroneID this repo targets doesn't use WiFi, I don't think it can be integrated into Kismet. That being said, it's probably possible to demod frames using the code in the repo and feed the resulting bytes into Kismet.
As far as OcuSync, this repo does not work for OcuSync uplink or downlink bursts. The DroneID bursts have a similar physical layer structure, but it's my understanding that the underlying bits for OcuSync are very different and likely encrypted.
Yup! Kismet doing as Kismet does and being on top of new protocols ⭐
The difference between what Kismet does and what this repo aims to do is that Kismet is processing the WiFi version of DroneID. This repo looks at the non-WiFi bursts. As far as I know Kismet does not currently support the non-WiFi bursts.
I'd spoken to the author a while back regarding hackRF integration. It is doable. Mike always has 1000 irons in the fire, so probably not on deck any time soon. I know this droneID stuff has been a minor headache too because everyone wanted detection, but no one could deliver him the sniffs he needed of various craft to make it accurate.
FYI, Kismet is providing DJI Drone ID detection : https://www.kismetwireless.net/development/droneid/
Both @proto17 & I worked with the kismet Author when that was created. We were all 3 working at a counter drone company. Is was released alongside this white paper that we all collectively wrote up with help from the "Slack OG's".
https://github.com/MAVProxyUser/CIAJeepDoors/blob/main/Anatomy-of-DJI-Drone-ID-Implementation1.pdf
I never followed up on this, but I found a way to do integer frequency offset detection that works with my HackRF (thanks @MAVProxyUser!). The code is currently only in MATLAB/Octave though :( I am in the process (albeit very slowly) of rewriting gr-droneid from the ground up using GNU Radio 3.10. Almost certainly not going to have anything in the next month =\
The rewrite branch will use the updated integer frequency offset code. One day I'll get back to work on that branch :\
@V0rt nice script. I think You were a bit lucky to get such descent looking constellation diagrams without phase and delay (sample rate offset) compensation. The cp based CFO estimation seems to work nicely.
This whole project aims to get DJI drone IDs and more informations like drone and pilot geo-locations. Conner Bender seems to be able to extract all these informations. Unfortunately not enough details (at least for me) are given in his paper : https://www.researchgate.net/publication/362230301_DJI_drone_IDs_are_not_encrypted/fulltext/62de5c68aa5823729ee0b01e/DJI-drone-IDs-are-not-encrypted.pdf
Actually, for me and maybe others, wouldn't it be sufficient to have a scanner script running 24/7 with HackRF hopping through all possible frequencies (2.4595 GHz,...,5.7965 GHz) and give alert once a DJI drone is seen ? Background : My neighbor has a DJI Air 2S (Ocusync 3.0) and I want to close all shutters automatically once he takes off the beast.
Maybe someone could help me with that ? Also it might be good to have such a script as an initial step for further automated investigation/handling (ID demodulation, jamming, logging, etc...)
Conners paper cites this repo, even the Wifi detail was covered here: https://github.com/proto17/dji_droneid/issues/8
The paper is in essence based on my work, David's work, Kismetwireless work, Cryptos's work, and other Slack OG members work, Andreas, and Freak, etc.
Yes, I read that. But for me it seems that OcuSync 3.0 can no longer detected by a Wifi-Scanner. Or do you think Air 2S in OcuSync mode can still be detected with the "Enhanced Wi-Fi Detection" (=Atheros monitor moded card with half or quarter rate clock modification). I already tried a "standard" Wi-Fi scanner btw (alert when DJI MACs are seen), but could not detect neither Air 2S, nor a DJI Mini.
I think you need to go back and do a bit more homework, and try to understand the foundation of what you are discussing.
You've never been able to detect an OccuSync based drone with a wifi card. These are two parallel technologies with "droneID" implemented on top of them.
You are lacking some fundamental understanding on how this all works at this point. Wifi and Occusync are not compatible, period.
Wifi and Occusync are not compatible Actually this is what I wrote before. I know hat Wifi is a standard protocol and OcuSync is different, proprietary, based on similar frequencies but implementing own DJI protocol. I mean, hey, are we in school here and this is a test ? My question was simply if there would be a simple way using HackRF to detect the presence of a DJI drone. Sorry for disturbing.
Your questions have been answered a few times. The last one specifically: https://github.com/proto17/dji_droneid/issues/3#issuecomment-1314490486
You are here to learn, right? You failed the reading test. ;)