dji_droneid
dji_droneid copied to clipboard
proto17
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
Hmm, your results also show that each ZC sequence is only sent once which is not what I found (each sequence was repeated once and both root indices were sent back to back). The collect I used to find the different sequences was provided to me by someone else. So I don't know exactly what drone was used. Perhaps there is a firmware difference?
So long as you're okay with the fact that your location might be present I'd be very happy to have a look. One thing that would be very interesting is to see a power spectrum (waterfall) of any drones you have access to.
Thanks!
@proto17 I got this results from mavic 3 and mavic 3 mini pro. Both bursts shown, that part of algorithm for ocusync 2 before quak demodulation does not get good result for quantizing. I used several cycle_prefixes, but results not good too. I will show you tomorrow
@proto17 well, as i said
This is burst of mavic3:
This is burst of mavic 3 mini pro:
And all of this bursts get two root indices 147 and 600.
But prior qpsk quantization OFDM-symbols look like this:
When symbols of Ocusync 2 look like this:
I tried to use brute force for cyclic prefix from 1 to 100, and filter taps from 1 to 50, but a could not get result like from ocusync2.
@lobart thanks for the images! It looks like both adhere to the frame structure that is currently used in the code base: 2 data symbols, 1 ZC, 1 data symbol, 1 ZC, 3 data symbols. The ZC root indices look the same too. You can fingerprint the root index fairly easily by looking at the angle and number of stripes in the waterfall. Not sure why the first won't lock or why the second one doesn't look right in the 6th and 9th symbols.
One thing that's known to really goof up demod is a large center freq offset. I added logic to the main branch to help with detecting the integer frequency offset (IFO). Was that being used with the files that you processed? If so, what was the value of integer_offset?
@proto17 your program with my file get 0 integer_offset. I set threshold to 0.02 to detect ZC.
@lobart something goofy is happening and i don't have a good feel for exactly what. if you're okay with sending me the file, what is your preferred way to accomplish that?
@lobart one thing that might be worth trying is changing line 168 of process_file.m to something like 5 or 10. I didn't realize that I committed the code with no interpolation which is a problem. This mistake means that there is a good chance for a large fractional STO which isn't great. Also, make sure you're using main and not any of the other branches as main has the most up-to-date MATLAB.
@lobart after tinkering with the process_file.m script to force it to create a cyclic prefix plot like yours i think i know what's wrong: Double check that your sample rate is correct. the only way that I could recreate your issue was to resample the file to something like 15.38e6 or 30.74e6. i can't think of another reason that the cyclic prefix plots would lag like that.
@lobart something goofy is happening and i don't have a good feel for exactly what. if you're okay with sending me the file, what is your preferred way to accomplish that? @proto17 @boltraa in telegram
@lobart after tinkering with the
process_file.mscript to force it to create a cyclic prefix plot like yours i think i know what's wrong: Double check that your sample rate is correct. the only way that I could recreate your issue was to resample the file to something like15.38e6or30.74e6. i can't think of another reason that the cyclic prefix plots would lag like that.
@proto17 I used fft_size 1021 and got result
@proto17 I added 1 to long_cyclic_prefix
and got this results
Can you describe numbers at this lines?
That's just a way to get the cyclic prefix lengths based on the sample rate. What I probably should have done is:
long_cp_len = round(sample_rate * 5.2e-6);
short_cp_len = round(sample_rate * 4.69e-6);
The 5.2e-6 is 5.2 microseconds, and 4.69e-6 is 4.69 microseconds. Both values came from this page.
Did you happen to use a non-standard rate (ie not 15.36e6 or 30.72e6)? What SDR did you use? The existing code would likely not work for a non-standard rate. You can try replacing what's in the repo with the code above.
@proto17 I use b210 usrp with 15.36M rate
But with mavic 2 it works.
See i processed burst by hand. And i choose fft_size 1021 and angles for phase for every OFDM-symbol.
And i got this:
@proto17 I used your script with ocusync 2, and it doesnt work. But previous version of your script is correct.
if you have to lower the fft_size from 1024 to 102,1 it means that you have a STO of about 3 samples per 1024 samples (0.3%). The spectrum of the signal appears to small for you, which means that your sample rate is a bit to high. It should work with the original fft_size if you lower the sample rate about 0.3%. Do you use an original b210 or a china clone? Does it have the GPSDO option?
@catkira I use original board. https://www.ettus.com/all-products/ub210-kit/ So, do you mean that I should to use 15.14M sample rate instead 15.36M ?
yes, and also try + 0.3 %, because the fact that you have to decrease fft_size to make it work also hints that your sample rate could be too slow. Because by shortening the fft_size you also reduce the length of each symbol in time.
I would write a script that plots the distances of the CPs for the entire burst. From the cp distance you can tell what your sample rate offset is.
@catkira I don’t understand, what do you mean under distances of the CP? I did brute force CPs from 1 to 100, but lag was the same (3 samples)
Normally there should be a CP (short or long) every 1024 samples after the last CP. You can verify that thats the case using cross correlation.
You can also plot the phase of the channel estimation. If the phase has a slope thats a sign of STO. I would use the channel estimation of the first ZC symbol for that.
Its a bit difficult to explain it all with words. Can you provide your burst file? I can write a small analysis in python then when I have time (probably this weekend).