Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

samples for tests #47

Open
pqoe opened this issue Feb 10, 2024 · 1 comment
Open

samples for tests #47

pqoe opened this issue Feb 10, 2024 · 1 comment

Comments

@pqoe
Copy link

pqoe commented Feb 10, 2024

Hi
Having not found success in samples captured from pluto sdr ive found some samples here from a similar project, its captured with the same sdr as this project https://github.com/RUB-SysSec/DroneSecurity/tree/public_squash/samples
so wondering if anyone tried this before.? thanks BR

@proto17
Copy link
Owner

proto17 commented May 27, 2024

You cannot use the PlutoSDR for capturing DJI DroneID signals as the PlutoSDR is not able to capture signals over about ~ 4 MSPS (in this case equivalent to ~ 4 MHz of spectrum). The only way that the PlutoSDR could demodulate these signals is if the bursts were detected and captured in the FPGA and then sent to the ARM and then over USB to your desktop/laptop. If someone wanted to it wouldn't be horrifically difficult.

Warning: Lots of rambling below. Many thoughts came to mind that I wanted to put out there for others to possibly polish and implement :)

In fact, here's a rough idea of what would be entailed with an FPGA detector that doesn't demodulate:

  • Instantiate a FIR filter with coefficients that are the conjugate of the first ZC sequence (this is a constant value, so nothing too tricky here)
  • The next part has two options: normalized or not
    • If normalized (which is the better option) then the normalization (power estimation mainly) functionality of [1] needs to be replicated in hardware which isn't terrible
      • Normalization allows a threshold that's between 0 and 1 which is agnostic to the amount of power present in the signal
    • If not normalized then an absolute threshold needs to be determined which will likely false trigger a fair bit and also miss lower power bursts, but it should work and is a lot easier
  • Use the filter and possibly normalization logic to find the start of the first ZC sequence and write a state machine to count until all samples in the burst have been received (this is a constant value) and write this out over DMA to the ARM cores
    • Both the normalized and non-normalized would require a separate buffer to hold onto the time domain samples while the FFT filter is running. The output of the FFT filter would just tell you when to look back by N samples into the past since the FFT takes a long time to process
  • Once the samples are sent over DMA, the ARM can do demodulation, or the data can be sent over USB to some other x86 system to demod via MATLAB (data rate would be low enough for this to be possible)

There will need to be a software component to this the FPGA portion is writing data out to DMA. There are examples on Xilinx's website/wiki about how to accomplish this and some examples that should work.

The hardest part of this IMO will be integrating into PlutoSDR block design in Vivado and writing the software to pull data from DMA.

The correlation filter might be a bit large for the PlutoSDR's FPGA, but switching off the dual channel and TDD logic in the AD9361 block will save a lot of resources. The correlation will have to be done with an FFT since the number of DSP48's is very limited in the 7010 (no way you're doing a time domain systolic FIR filter with 1024 taps on the Zynq-7010 without time sharing multipliers which gets really complicated).

[1] https://github.com/proto17/dji_droneid/blob/main/matlab/updated_scripts/normalized_xcorr_fast.m

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants