Updated Home (markdown)

Home.md

@@ -15,15 +15,18 @@ There were some very important parameters that were known going in:
 - Occupied bandwidth: ~ 10 MHz
 - Modulation type: OFDM
 - Burst duration: Very short (no actual number initially, just that it was only a few OFDM symbols)
+- Frequency: Somewhere in 2.4 GHz
 
 It was also known that the signal looked a lot like LTE, and used some LTE features.  What that ended up meaning is that the actual signal bandwidth was 15.36 MHz (LTE downlink signals with an occupied bandwidth of 10 MHz are actually 15.36 MHz wide [1].)
 
+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
 
 # 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!
 
-Once the drone was registered and powered on, I used GNU Radio with gr-fosphor to hunt for the Drone ID signal.  I knew ahead of time that it was a 10 MHz wide signal that came from the drone.  To help keep the signals from the controller from confusing me I placed the SDR next to the drone with the gain low, and the controller in another room.  Then I scrolled through 2.4 and 5.8 GHz looking for signals that were 10 MHz wide and bursty.
+Once the drone was registered and powered on, I used GNU Radio with gr-fosphor to hunt for the Drone ID signal.  To help with reducing unwanted interference I placed the SDR next to the drone with the RX gain set low, and the controller in another room.  Then I scrolled through 2.4 and 5.8 GHz looking for signals that were 10 MHz wide and bursty.
 
 What I found from that was that there were a handful of frequencies that matched the description:
 - 2.4595 GHz
@@ -34,4 +37,18 @@ What I found from that was that there were a handful of frequencies that matched
 
 This is likely not an exhaustive list, and I've heard that some drones also send DroneID in 5.8 GHz.
 
-One issue with recording Drone ID is that it transmits very infrequently (about every 640 milliseconds), and hops around from frequency to frequency (see the list above).  So, if you want to capture bursts you might have to record for several minutes, which at a sampling rate of 15.36 MSPS (more on this later) is 61.44 MBytes per second for complex shorts, or 128.88 MBytes per second for floats.
+One issue with recording Drone ID is that it transmits very infrequently (about every 640 milliseconds), and hops around from frequency to frequency (see the list above).  So, if you want to capture bursts you might have to record for several minutes, which at a sampling rate of 15.36 MSPS (more on this later) is 61.44 MBytes per second for complex shorts, or 128.88 MBytes per second for floats.  A better way to do this is to record only when the signal is active on the current frequency.  This can be done easily with `osmocom_fft` from `gr-osmosdr` [2] using `gr-fosphor` [3].  The use of `gr-fosphor` is important here as the normal FFT that you get by running `osmocom_fft` isn't going to update fast enough to see very short (in time) bursting signals.  Using `gr-fosphor` will allow you to see those bursts that the normal FFT will miss.  But, this does require either a GPU or and OpenCL supporting CPU.
+
+Unfortunately for me, `gr-fosphor` was not playing nice with my computer when running under Qt, so that made `osmocom_fft -F` useless for my case.  So, I wrote a GNU Radio flow graph (see below) that allowed me to choose when to start recording by pressing and holding a button in the Qt UI.  
+
+![image](https://user-images.githubusercontent.com/4240543/162871929-e17b73fc-2e7b-4475-9133-92a9c5c1ec70.png)
+
+Some things of note about the graph:
+- The sample rate is twice the required rate
+- The output file is going to `/dev/shm`
+-- 
+
+Using that graph I was able to collect several frames
+
+[2] https://github.com/osmocom/gr-osmosdr
+[3] https://github.com/osmocom/gr-fosphor