Unable to capture with HackRF #3
Comments
|
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. |
Thank you!!! ❤️ |
|
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 ( 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 [1] greatscottgadgets/hackrf#379 |
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 : |
|
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 ! |
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. |
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. |
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 =\ |
|
So hot right now! https://www.youtube.com/watch?v=CV_hDyfmEw4 |
|
@proto17 did you ever bang this cheaper solution out? |
|
The rewrite branch will use the updated integer frequency offset code. One day I'll get back to work on that branch :\ |
|
Zero stress brother! Just hadn't thought about it in a while. salute |
|
for quick testing |
|
@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. 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 ? Maybe someone could help me with that ? |
|
Conners paper cites this repo, even the Wifi detail was covered here:
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. |
|
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. |
|
|
Your questions have been answered a few times. The last one specifically: You are here to learn, right? You failed the reading test. ;) |
|
I saw the post. Problem is Master Kenobi was not really communicative in the readme and the force still is hidden in the dark for novices like me. |
|
"My question was simply if there would be a simple way using HackRF to detect the presence of a DJI drone." |
|
We are approaching. Then it is as i feared : it is not enough to look for the presence of a sufficiently strong signal on certain frequencies, but it is definitely necessary to analyze the signals further in order to be able to say with a certain probability that a drone is present ? |
|
In reply to the comment about looking for the presence of a signal:
Oh yeah, for sure. You *might* be able to get away with just correlating or even just looking at burst interval, burst
duration, and signal bandwidth, but that won't tell you if the drone is close to you, or give you *any* information about the drone
The simple cross correlation with the ZC sequence and an estimation of duration using power to tell when the signal came up and went down will give you a decent idea of there being a DJI DroneID supporting device being present. But that would only work for decently strong received signals due to needing to use the power estimation (think SNR) to test how long the signal was up for. This gets difficult when the SNR is low. The correlation against the ZC sequence might not work as other signals might use that same root index. But, it's likely okay to tinker with. So, in short, correlating for the ZC sequence is probably the least you could do to tell if a drone is present or not.
…On Thu, Dec 15, 2022 at 11:31 AM Vinylrider ***@***.***> wrote:
We are approaching. Then it is as i feared : it is not enough to look for
the presence of a sufficiently strong signal on certain frequencies, but it
is definitely necessary to analyze the signals further in order to be able
to say with a certain probability that a drone is present ?
—
Reply to this email directly, view it on GitHub
<#3 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABALJH4AQ2IAZIR5OGRPMJ3WNNBXNANCNFSM5VKTORRQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Can you currently use hackrf to detect dji drones? |
|
The issue was never that it wouldn't work, just that the odds were against
you due to the oscillator. If you have a hacked, give the graph a try. It
might work. Definitely don't go out and buy one just for this though!
The code in the Matlab directory should work for SDRs with large frequency
offsets. That code is not in the gnu radio oot module. There is a rewrite
of the module that still needs a lot of work that should address the
problem. Unfortunately between work and outside obligations, it hasn't
been touched in quite a while. I hope to be able to get back to it mid
Feb, but that depends on some other things 😕
…On Sun, Jan 22, 2023, 8:18 AM DienoX ***@***.***> wrote:
Can you currently use hackrf to detect dji drones?
—
Reply to this email directly, view it on GitHub
<#3 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABALJH4GC3TEAFRUUCCDSZLWTUXT7ANCNFSM5VKTORRQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Thank you very much |
|
Good afternoon. I'll try to understand this project. Only HackRF is available. So far, it is not possible to decode the signal of the drone. Can someone share the recorded signal that gives the results on this project, to see where I am wrong when receiving the signal. |
|
I think you'll find that there's a bit of an aversion to sharing IQ collects of DroneID. It contains the coordinates of the location of the drone which can give away the address the recording was taken. I recommend that people not send IQ collects unless they are okay with the receiving party knowing their address. Is your issue that you don't see any burst detections? Or are you seeing detections, but no decoding? |
|
another fun of your work with a borrowed hackRF. still learning. |
|
I have a dji drone, a working hackrf One and a working GNURadio setup. |
Hi, i am curious whether you were able to get this working. i have a Adalm Pluto sdr and want to do the same. Community please help me out |
The PlutoSDR likely cannot be used for this. The min sample rate is ~ 15 MSPS [1] and the PlutoSDR can't usually pass more than ~ 5-8 MSPS unless the processing happens in the FPGA which is not the case for this code. [1] https://github.com/proto17/dji_droneid/wiki#information-known-ahead-of-time |
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 text was updated successfully, but these errors were encountered: