https://github.com/jewbetcha/openlaunch/blob/be4a36a58096c2dc94ea8f8fa9affe5269eb4e6b/launch_monitor.py#L10
The built in checks / debug tools here are not very useful. The issue-space for RF systems is too broad for simple checks like this, in my opinion. My recommendation is that you develop a method called .run_data_capture(time_sec, nfft, optional: sample_rate_hz), that returns a figure equivalent to a waterfall plot (https://en.wikipedia.org/wiki/Waterfall_plot) where:
-
Data is sampled from the front-end module by the ADC at a rate of sample_rate_hz for time_sec seconds. A power-of-2 nfft value of, for example, 1024 determines the length of the coherent processing interval (CPI), or, the length of time over which to compute velocity estimates. The length in time of the CPI should be determined based on the expected length of time that the target golf ball will be in motion and illuminated by the radar transmitter.
-
Along the X-Axis, the Doppler bins of the FFT are plotted. The value of the Doppler bins can be computed as a function of the size of the FFT (nfft) and the sample rate.
-
Along the Y-Axis, plot the FFT values of the processing intervals in dBm scale. The unit along the Y-Axis is time, where the time-step of each processing interval is equivalent to nfft * ts, where ts is the sampling period. ts = 1/fs, where fs is the sampling rate. The time step of a processing interval represents how much time it takes to capture one frames worth of data, where a frame is defined as being nfft samples long.
-
Colorbar labeled Relative Power (dBm).
The dimensions of the plotted array should be nfft X nProcessingIntervals, where nProcessingIntervals = (time_sec *sample_rate_hz)/nfft. << Enforce that time_sec * sample_rate_hz is divisible by nfft.
Such a tool will allow you to monitor the frequency spectrum over time, and allow you to observe visual changes in the spectrum as a function of time and objects in the scene. They will also be useful for documentation.
https://github.com/jewbetcha/openlaunch/blob/be4a36a58096c2dc94ea8f8fa9affe5269eb4e6b/launch_monitor.py#L10
The built in checks / debug tools here are not very useful. The issue-space for RF systems is too broad for simple checks like this, in my opinion. My recommendation is that you develop a method called .run_data_capture(time_sec, nfft, optional: sample_rate_hz), that returns a figure equivalent to a waterfall plot (https://en.wikipedia.org/wiki/Waterfall_plot) where:
Data is sampled from the front-end module by the ADC at a rate of sample_rate_hz for time_sec seconds. A power-of-2 nfft value of, for example, 1024 determines the length of the coherent processing interval (CPI), or, the length of time over which to compute velocity estimates. The length in time of the CPI should be determined based on the expected length of time that the target golf ball will be in motion and illuminated by the radar transmitter.
Along the X-Axis, the Doppler bins of the FFT are plotted. The value of the Doppler bins can be computed as a function of the size of the FFT (nfft) and the sample rate.
Along the Y-Axis, plot the FFT values of the processing intervals in dBm scale. The unit along the Y-Axis is time, where the time-step of each processing interval is equivalent to nfft * ts, where ts is the sampling period. ts = 1/fs, where fs is the sampling rate. The time step of a processing interval represents how much time it takes to capture one frames worth of data, where a frame is defined as being nfft samples long.
Colorbar labeled Relative Power (dBm).
The dimensions of the plotted array should be nfft X nProcessingIntervals, where nProcessingIntervals = (time_sec *sample_rate_hz)/nfft. << Enforce that time_sec * sample_rate_hz is divisible by nfft.
Such a tool will allow you to monitor the frequency spectrum over time, and allow you to observe visual changes in the spectrum as a function of time and objects in the scene. They will also be useful for documentation.