Update README.md

README.md

@@ -45,10 +45,32 @@ This is super simple and just requires being time and frequency aligned with kno
 
 ## Turbo Product Code Removal
 It is assumed that the demodulated data contains an LTE standard TPC.  There are libraries that can handle this (hopefully)
+A new wrinkle here is that under the Turbo code is going to be "Rate Matching" bits.  I have no idea if that's going to be a standard process that doesn't vary depending on link parameters that aren't already known.
 
 ## Descrambling
 Rumor is that there is a scrambler in use.  It's not clear to me if the scrambler is before or after FEC, but it will need to be dealt with.  Supposedly it's LTE standard.
+Update: the scrambler is definitely before the FEC.  I found a really nice writeup about it at https://www.sharetechnote.com/html/Handbook_LTE_PseudoRandomSequence.html.  The scrambling sequence seems to be made out of two Linear Feedback Shift Registers (LFSRs) combined together.  The intital state of the first LFSR is a constant value, but the second LFSR needs certain parameters that relate to the link.  Unfortunately I don't have those parameters.  The only good news is that is *only* a 31-bit exhaust to brute force.  So ~ 2.5 billion attempts and you're assured success!  In the event that the Turbo decoder parameters are magically known then maybe this won't be so bad.
 
 ## Deframing
 The underlying data should be in a known DJI format.  If so then this step should be pretty simple
 
+# Known Values
+## Frequencies
+Look in 2.4 GHz for the Drone ID frames.  Might be best to go into the DJI app and tell the downlink to use 5.8 GHz.  This will keep the downlink (and probably uplink) out of 2.4 GHz.  Drone ID will not move from 2.4 GHz
+Some frequencies I have noted thus far:
+- 2.4595 GHz
+- 2.4445 GHz
+- 2.4295 GHz
+- 2.4145 GHz
+- 2.3995 GHz
+There might be others, but that's just what I've seen
+
+## Burst Duration/Interval
+The Drone ID bursts happen ~ every 600 milliseconds
+The frequency varies and I've heard that there is a pattern to it, but cannot validate with my SDR as the bandwidth isn't high enough
+Each burst is 9 OFDM symbols with two symbols using a long cyclic prefix and the others using the short sequence
+
+## OFDM Structure
+As mentioned above, there are 9 OFDM symbols.  
+The 4th and 6th symbols (1-based) appear to be Zadoff-Chu (ZC) sequences (these are used in LTE and I know for a fact they are present in the uplink signal for Ocusync).  The parameters for the ZC sequences are not known.  I have first hand knowledge that the sequences are almost certainly not following the standard.
+The remaining OFDM symbols carry just a QPSK.  If there are pilots they are either QPSK pilots or a 45 degree offset BPSK.  As pointed out by https://github.com/tmbinc/random/tree/master/dji/ocusync2 the DC carrier appears to always be sitting around 45 degrees with a much smaller amplitude than the data carriers.  Not totally sure what's going on there.