Updated Home (markdown)

master
proto17 2022-04-12 22:35:50 -04:00
rodzic 03788ccc85
commit fe48a18350
1 zmienionych plików z 22 dodań i 2 usunięć

24
Home.md

@ -21,7 +21,7 @@ It was also known that the signal looked a lot like LTE, and used some LTE featu
Also, the signal was known to come from the drone and not the controller
[1] https://www.rfwireless-world.com/Terminology/LTE-bandwidth-vs-sampling-frequency-vs-resource-block.html
[1] https://www.sharetechnote.com/html/Handbook_LTE_PhyParameter_DL_FDD.html
# Signal Collection
I used a DJI Mini 2 for my analysis. Please keep in mind that not all drone models or firmware versions are always going to generate the same signal structure!
@ -232,4 +232,24 @@ These numbers were determined by moving the mouse in the plot and looking at the
This means that the FFT size is almost certainly `2,048` samples. The cyclic prefix length is a little harder to guess as it doesn't need to be any specific multiple. Thankfully we know that the signal supposedly follows LTE, so that value is known.
Assuming for a moment that the cyclic prefix length is not known, there are ways to find it. You can take advantage of the fact that the cyclic prefix is a repeat of the last `N` samples of the OFDM symbol. You can use autocorrelation over a range of samples and values of `N` to figure out which value of `N` ends up with the highest correlation score. It's a little out of scope here as we know that the signal follows *some* of the LTE spec.
Assuming for a moment that the cyclic prefix length is not known, there are ways to find it. You can take advantage of the fact that the cyclic prefix is a repeat of the last `N` samples of the OFDM symbol. You can use autocorrelation over a range of samples and values of `N` to figure out which value of `N` ends up with the highest correlation score. It's a little out of scope here as we know that the signal follows *some* of the LTE spec.
Going back to [1] you can see that for a signal that occupies 10 MHz of bandwidth (as this signal does) the FFT size should be `1024`. But we have `2048`... What gives? *Oversampling*
The recording was taken at 30.72 MSPS, while the signal only *needed* to be recorded at 15.36 MSPS. This doubles the number of samples, and for OFDM systems means that our FFT size and cyclic prefix lengths are doubled in the recording we made. This doesn't cause any issues thanks to how an FFT works.
So, since the file was oversampled by 2x we are going to use an FFT size of `2048`. As for the cyclic prefix, well, there are two lengths:
- Long
- Short
The chart in [1] shows that the long cyclic prefix should be 5.2 microseconds, and the short prefix 4.69 microseconds. Multiplying the sample rate with the cyclic prefix duration in seconds will give you the number of samples:
- `30,720,000 * 0.0000052` = `159.744` or `160`
- `30,720,000 * 0.00000469` = `144.0768` or `144`
According to the LTE spec, the first OFDM symbol should use the long cyclic prefix, but the remaining symbols in the `slot` use the short cyclic prefix.
So, lets check to see if this math works out. From the MATLAB plot earlier the OFDM symbol seemed to end (far right of the white box) around sample number `9,760`. Assuming that each symbol after the first is `2048 + 144` or `2192` samples, the end of the previous OFDM symbol should be `9760 - 2192` or `7,568`
![Screenshot from 2022-04-12 22-35-22](https://user-images.githubusercontent.com/4240543/163088581-9057c90a-8254-4b88-a12d-b22b2b2ef08d.png)
The