On Wed, Nov 22, 2023 at 09:44:39AM +1300, Al Grant wrote:
>
> Have not investigated what options are available to stream it from within
> python as JSON but it still relies on peak detection within GR.
No just an AM demod. The peak detection can be done later, off-line.
Ciao,
--
FA
On Tue, Nov 21, 2023 at 08:31:30PM +0100, Fons Adriaensen wrote:
> * lowpass filter the result, 400 Hz or so,
> * resample to 200 Hz, and save that to a file or
> some stream output that can be read by another
> application.
Correction: if you downsample to 200 samples per
second then the lo
Hi Al,
(Please reply to the list)
> The Rpi could be in the field for months - haven't decided yet if I
> will set up remote access, so let's assume for now it's offline and
> whatever I save will be to locally attached storage.
Even if you store the signal amplitude at 200 Hz, 1 byte per sample
On Tue, Nov 21, 2023 at 11:11:04AM -0500, Jeff Long wrote:
> Data will not be huge (from a computer perspective) if you log every beep.
> Logging a lot of data and post processing allows you to try out different
> algorithms without going out and collecting data every time you want to
> change so
Please keep the discussion on the mailing list so everyone can help or
benefit.
There are 3 different Peak Detector blocks available in GNU Radio. These
block output a "1" byte when a peak is detected, and "0" otherwise.
https://wiki.gnuradio.org/index.php/Detect_Peak
https://wiki.gnuradio.org/ind
I'd suggest that you just log the times you saw a peak in GNU Radio to a
file. Then use a completely separate program to measure intervals, do
statistics, etc. There shouldn't be any need to use tags in GNU Radio for
this project.
Even the "debouncing" can be done externally. Just log the times wh
