Some questions and issues.

[Max-170]

Hello, I would like to ask you several questions.

1. 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?

2. 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

[proto17]

1. Those smaller files are great if the GNU Radio logic successfully detected the burst. Definitely a lot faster than chewing through gigabytes worth of IQ samples. Apologies if I am misunderstanding the question. Side note, you can use whatever format you want so long as you tell process_file.m what the type is [1]
2. At this time you need to build the remove_turbo binary yourself. I didn't realize there was nothing in the docs stating that you needed to build the program. See [2] for information about how to build the remove_turbo application.

[1] https://github.com/proto17/dji_droneid/blob/main/matlab/updated_scripts/process_file.m#L36
[2] https://github.com/proto17/dji_droneid/blob/main/cpp/remove_turbo.cc#L1-L7

[Max-170]

Thanks for answering.

This is what I have done so far:

1. I managed to compile the remove_turbo as you told me to do.

2. I have some doubts about why there are so many branches or which one I should use specifically. I am currently testing with update-3.10.

3. I have seen that just about 3 seconds of recording in IQ at 30.72 MSps implies almost 400 MB of file, therefore almost 1M samples when applying octave - process_file.

4. With the drone_id_test.grc, when I put the central frequency in the center of the burst transmission, the gnuradio informs me in the console:
   -Found burst @ 358 / 357
   -Sending message with 27952 elements (27952) starting at 357
   And so on continuously increasing the numbers each time.
   Thousands of burst_# files appear in the /temp/droined_debug folder.
   I don't know if this would be right or if you mean that the gnuradio was able to find the bursts automatically with the logic that uses.

5. I am saving with the file_sink block a .fc32 file (a few seconds) which I then use in process_file, giving it the path, the sample rate of 30.72e6 and the offset in 0e6.
   When running it in octave it takes about 10 minutes (more than 86 thousand samples) to finally get this on the screen:

• warning: Skipping burst at offset 612 as the beginning of the burst has been clipped
  -warning: called from
  extract_bursts_from_file at line 62 column 13
  process_file at line 49 column 8
  And so on consecutively increasing the numbers in the offset. Until the end shows a "Killed" ending the octave.

I keep trying but I'm running out of ideas.

Greetings.

[alphafox02]

I’m using the update 3.10 branch now and playing back my previously recorded IQ file at the settings you describe yields bursts in the temp directory. I can then either use the 2GB+ file itself or the smaller burst files (I cat them together into one file) in Octave and the end result is Frames that have been decoded. I’ll test my other IQ files and see if I can replicate what you’re seeing. Maybe it’s possible the initial capture was bad.

I was less then a few feet away in a very open area without WiFi etc around.

[proto17]

1. Yay!
2. The branch situation is terrible. I wanted to get the code up on GitHub as quickly as possible and ended up making way too many confusing branch names in the process :(
3. Yup, the process_file.m route with multi-second collects is not ideal. To help with this I created a GNU Radio graph that uses gr-fosphor to watch for DroneID bursts (they happen at an even cadence and are 10 MHz wide, so pretty easy to spot) and only record samples when the signal is active on the current frequency
4. I don't have the graph in front of me right now, but that sounds right. There will be one file for each burst found. But, if your RX parameters aren't right you can get loads of false positives. As an example, using a HackRF I can get mountains of false positives by setting the gain too high. Might be due to an issue in the cross correlation normalizer. Thousands is definitely too many and there's likely something else happening.
5. Any particular reason for the high sample rate? You only need to use 15.36 MSPS

The most likely reason for your issues is that the GNU Radio branches (aside from the rewrite branch) are behind the main branch for the MATLAB code. This is somewhat by design as the GNU Radio code was tested against the MATLAB that's in it's branch if that makes sense. Check out the main branch if you want to use the MATLAB code. It's a cluster for sure, but that's the solution for the moment. I hope to be able to fix the other branches once the rewrite is done.

[Max-170]

The burst don't show every 600ms? I see the signal is there, 10 MHz BW. This is not the burst with the remote id data?

You said: "and only record samples when the signal is active on the current frequency"

I get loss at this point :(

5. I use 30.72 sr because the gnuradio sample that you provide use that one. With 2048 FFT.

Thanks.

[proto17]

It's hard to explain, but basically there are at least 15 or so frequencies that DroneID hops around in. It only stays on one frequency for a few seconds. So, if you just tune to a frequency and collect samples for a second or so, you don't have much chance of actually catching a DroneID burst because it could be at one of the other frequencies. What I do is use gr-fosphor to watch the spectrum live at a specific frequency. When the bursts show up on that frequency I start recording those samples. I stop once the drone moves off to another frequency. Then I know the collect has DroneID samples and I won't be wasting a lot of time processing noise or random other signals (WiFi, Bluetooth, etc). But, you have to know what a DroneID burst looks like in the power spectrum for this to work, so it might not be a good path for you at this point.

The bursts are sent every 600 ms, but the signal hops around after 20 or so bursts, so your odds of catching it are slim.

I forgot that the graph uses 30.72 MSPS. That can be dropped to 15.36 MSPS if processing power is too high. Also, the higher sample rate causes increased runtime for Octave/MATLAB, so lower is better. Just happens that 15.36 MSPS is the lowest you can go.

[Max-170]

1. I have a strong signal with 10MHz BW, sometimes hops and move to other freq, but most of the time stay there. When I turn on the control, the spectrum shows a really fast freq hops around all the band (80 MHz of Wifi and with almost 15 hops), and the signal has less than 2 MHz of BW. But when I turn on the dron, then the signal of 10 MHz appears and like I said, stay in the same freq for a long time, but of course, change from time to time to another freq.
   So the signal of RemoteID is on that one, 10 MHz BW? When I record my IQ signal I put the freq in the middle of the signal. The gr-fosphor shows in the waterfall like a burst shows up and down really fast.

[proto17]

There are three signals that come from the Ocusync drones:

1. Video downlink: can be 10 or 20 MHz in bandwidth, are very frequently transmitted, and tends to stay on one frequency
2. Control uplink: usually 1.8 MHz wide, only sent once per frequency it hops across
3. DroneID downlink: always 10 MHz wide, 8 to 9 OFDM symbols long, hops around, stays on one frequency for ~ 20-30 bursts, and sends bursts at a rate of 1 every ~ 600 ms

What you're describing sounds like you are looking at the downlink. To be extra sure that's not happening, you can use the DJI app to lock the video signal (downlink) to 5.8 GHz, and only look in 2.4 GHz for DroneID signals.

[Max-170]

Thanks once again.

Now if my doubt about this question is clarified, thanks to the masterful explanation that you have just given.

Obviously I'm only looking at the Video Downlink and the Control Uplink.

I have never seen another signal in the spectrum like the DroneID, maybe because I had not paid enough attention. I'll have to look more closely.

[Max-170]

I think I already have the answer and it is not the one I would like. I have continued reading and investigating and I have realized (too late I think) that my drone does not have OcuSync, it is a Phantom 4. Could you confirm if it could be done with this drone model or is it simply for the Mavic? as in your case the Mini 2.

I read in an article that the OcuSync Protocol is used by the DJI Mavic series, Air series and Mini.

My drone does not have a way to go to 5.8 GHz. Also in the spectrum I see the 10 MHz Video Downlink signal from BW, and those from the Uplink Control with a freq hop as you say. Apart from this, no other signal is evident in the spectrum. According to what you say, should another 10 MHz burst come out every 600 ms and hop in frequency every 20-30 bursts? This means at least a permanence of this RemoteID signal of about 10 seconds in each frequency. Would it be similar to the Video Downlink, at least visually in the spectrum?

[proto17]

I'm not well versed in what drones do and do not support DroneID. It's my understanding that some of the older DJI drones have had DroneID added to them with firmware updates, but I'm not totally sure about that.

As for whether or not the Phantom 4 is Ocusync, I think it's Lightbridge 2, but I'm not sure about that statement.

Oh, and the DroneID bursts should looks somewhat similar to the video signals since they are both ~ 10 MHz wide and OFDM. The duration of each OFDM burst will likely be different between the two, but I haven't spent any time looking at the downlink in any detail. Have a look at the waterfall plots from lobart to see what DroneID should look like. You'll only be able to ID this in a recording as the live view will be moving far too fast to notice the features.

This is a good picture of what DroneID looks like too

[Max-170]

1. So it is impossible or very difficult to see the DroneID bursts with gr-phosphor in real time? In a graph of frequency against amplitude and with waterfall included?

I was looking at the video that I found now on Youtube from the cemaxecuter channel:

https://youtu.be/wAnU-4JQPXQ

Here he identifies with the fosphor the burst of the dronID. Watch it if you can. He is showing how to use your project.

3. If the drone is with Lightbridge 2, then it is not possible? This is only for OcuSync?

4. Forgive my lack of knowledge. I've seen the images and I've analyzed everything lobart has been asking and the answers you guys give it to him. With what software were these images obtained? To process the IQ signal previously recorded by the GNURadio.
   Update: I found it. Is Inspectrum

Thanks.

[proto17]

I didn't mean to imply that you couldn't identify DroneID bursts live, just that you need to know what you're looking for. Also, it's pretty easy when you have a single drone active, it's a bit more difficult with multiple drones since the cadence of the bursts might be goofy.

I don't know if the previous generation drones send out DroneID frames or not. I suspect all of the WiFi based drones do, but I don't know about the non-WiFi drones.

My analysis tool of choice is baudline. Doesn't do demodulation, but does do a wonderful job for analysis of new signals.