Re: Strategies to save/display low sample-rate data

On Wed, Apr 10, 2024 at 01:44:31PM -0400, John Ackermann N8UR wrote: > On 4/10/24 11:29, Fons Adriaensen wrote: > > > Both the decimation and 80 size 1024 FFTs per second should be peanuts > > for any modern PC... > > > > And of course you don't need to do the

Re: Strategies to save/display low sample-rate data

On Wed, Apr 10, 2024 at 10:38:14AM -0400, John Ackermann N8UR wrote: > I want to make waterfall displays of narrow bandwidth signals -- say +/- 20 > Hz with FFT depth of 1024. Decimating to ~80 samples/second and feeding > that into a 1024 bin FFT is... not fast. Both the decimation and 80 size

Re: SNR calculations

On Mon, Apr 01, 2024 at 01:50:32PM +1300, Al Grant wrote: > I have a block of code in my wildlife tracker that detects high/low beeps > in a frequency. It's not clear what the signal (blue trace in your png) actually represents and what exactly you are trying to do. - Detect any signal that exce

Re: Constant baseline between FFTs

On Sat, Dec 30, 2023 at 02:54:27PM +0100, Dr Cdiff wrote: > Here is an example (without division by median!): https://ibb.co/FmxZ3ZK (x > is time in h and y is frequency in weird unit) If that is kHz, the sample rate would be 48 kHz. Is your input an audio file ? Also, if the X-axis is in hours,

Re: Constant baseline between FFTs

On Sat, Dec 30, 2023 at 08:20:28AM +0100, Dr Cdiff wrote: > I have complex data in a file sink. I do File Source, Throttle, Stream to > Vector, FFT, Multiply Conjugate, So then the real part is magnitude squared. So why > Complex to Mag² which results in magnitude^4 and not "select real part"

Re: Request for Unsuscribe to this dsitribution list

On Thu, Dec 28, 2023 at 11:43:29AM +0100, c...@origosat.com wrote: >Dear GNURadio administrators, >Please, may ask you to kindly unsubscribe my email from this email > distribution list? >Many thanks and happy Christmas! Go to

Re: Wildlife Tracker (again)

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

Re: Wildlife Tracker (again)

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 sec

Re: Wildlife Tracker (again)

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

Re: Wildlife Tracker (again)

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

Re: volk questions

Hi Johannes, Thanks for your response ! > first off, we'd need to know a bit more about your setup. Could you share > the versions of VOLK and your host system, e.g. OS, version, etc. > Furthermore, do you use a VM, a container, or smth like this? VOLK was 2.5.0, now upgraded to 3.0.0, same resu

volk questions

Hello all, I've recently installed volk on two machines, both Intel i5 but different types. 1. On one of the two machines 'make' failed while 'cmake ..' ran without errors. Installing boost fixed this. Could it be that the cmake step doesn't check for boost ? 2. On one the two machines, 'volk_pr

Re: [VOLK] a += b*c ?

On Mon, Aug 15, 2022 at 12:03:25PM +0200, Marcus Müller wrote: > Just to be sure you mean, for N-long b and c, > > a = \sum_{i=0}^{N-1} b[i]c[i], I suspect the OP meant A [i] += B [i] * C [i], for i = 0...N-1 -- FA

Re: CSV file as input

On Fri, Mar 18, 2022 at 07:12:37PM +0100, Marcus Müller wrote: > CSV might or might not be convenient, but if C or assembler is your tool: > The things that the GNU Radio file source reads or the file sink writes is > exactly what you get when you take a buffer of samples and do an `fwrite` on > t

Re: Help with sweep generator

On Fri, Feb 11, 2022 at 01:36:59PM +, e heuchamps wrote: > I have read in a thread in this forum that the sampling rate (usually > denoted by the variable "samp_rate") is just a number representing how > much values are in a period of the signal. This means that, for signal > with frequency "

Re: [VOLK] Release 2.5.1

On Sat, Feb 12, 2022 at 11:40:26AM +0100, Johannes Demel wrote: > In the past, we relied on Boost for several tasks in `volk_profile`. For > years, we minimized Boost usage to `boost::filesystem`. We mostly switched > to C++17 `std::filesystem` years ago. The last distribution in our CI system > t

Re: Error "gr::vmcircbuf_sysv_shm: shmget (1): No space left on device"

On Wed, Mar 31, 2021 at 03:19:50PM +0200, Marcus Müller wrote: > This is no surprise, really: Python has non-deterministic destruction, so > your "del my_gr" doesn't instantly deconstruct the underlying object and > thus doesn't free the buffers. Maybe the gc module can help ? -- FA

Re: explaining i/q

On Wed, Nov 04, 2020 at 07:13:09PM -0600, David Hagood wrote: > > On 11/4/20 6:26 PM, david vanhorn wrote: > > "Twice the bandwidth" but that doesn't account for the 0 Hz "hole" where > > the incoming signal is exactly at the sampling rate. > > Or am I missing something? With complex samples at r

Re: explaining i/q

On Wed, Nov 04, 2020 at 05:14:00PM +0100, Kristoff wrote: > For us, "even if we would be able to look at a rotating object up-front and > from a 90 degrees angle at the same time, if the object would be frozen in > time we would still not be able to determine if the doll rotates left of > right".

Re: explaining i/q

On Wed, Nov 04, 2020 at 12:38:27AM +0100, Kristoff wrote: > So, what is iq-sampling? > IQ-sampling is like sampling a normal ("real") signal -i.e. what most people > are familiar with-, ... except that you sample the data twice for each > period: once at timer "t" and a second time 1/4 sampling p

Re: USB communication

On Sun, Oct 04, 2020 at 11:11:33AM -0400, Elmore's wrote: > Simple question: How do I use USB communication in gnuradio? > I can’t find any blocks that implement USB. I can’t find any reference to USB. > I can’t find any discussion about USB on forums. > There must be a way to implement one of the

Re: ALSAPulseAudio procedure

On Thu, Jul 02, 2020 at 06:43:21AM -0500, Barry Duggan wrote: > Probably I will create a new page for diagnosing audio problems. All > suggestions are welcome :) Depending on what exactly you are doing, there may be another problem. If you take the signal from an RF source, process and decimate

Re: Sound card input & output synchronization ?

On Tue, May 19, 2020 at 01:06:20PM +, jean-michel.fri...@femto-st.fr wrote: > as this is a new computer, I had not installed pulseaudio. It seems > the "default" Alsa backend indeed drops frames. I installed pulseaudio > and running in debug mode (-) I cannot see frame size updates but mos

Re: Complex in/Complex out Hilbert?

On Sun, Apr 19, 2020 at 07:44:00AM -0500, David Hagood wrote: > Yes, I know - "If you want it, write it yourself, then". And I may just do > that, but since I hate duplicating effort, I'd like to know if anybody else > has done that, or is doing that. I've been developing my own SDR modules (C++,

Re: Recommendation for high sample rate receiver?

On Sat, Feb 01, 2020 at 02:58:06AM -0500, Mike wrote: > The target signal of interest uses pulse modulation where each pulse is > 1 microsecond in duration, with a rise time of less than 0.1 microsecond > and a decay time of less than 0.2 microseconds.  The goal is to identify > the start (arriva

Re: Recommendation for high sample rate receiver?

On Mon, Jan 27, 2020 at 06:25:48PM +0100, Daniel Estévez wrote: > El 26/1/20 a las 21:38, Marcus Müller escribió: > > Seconding what Brian says: > > Math says *any* signal up to a bandwidth of 6 MHz can be represented by > > 6 MS/s. So, either, your signal isn't that bandlimited, or you forgot > >

Re: [Discuss-gnuradio] "Give me a ping, Vasili. One ping only, please."

BTW: nice reference to Red October :-) Although I wonder if even at that time the US navy would be using 'consumer type' tape recorders in their sonar systems... Ciao, -- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org

Re: [Discuss-gnuradio] "Give me a ping, Vasili. One ping only, please."

On Fri, Aug 10, 2018 at 02:57:34PM +0200, Markus Heller wrote: > I wonder how I could generate one single shortest possible pulse on my > USRP2 with GNURadio.  > > Normally all the blocks would always generate an entire sequence, a > continuous signal.  > > I want to generate (and analyze) the s

Re: [Discuss-gnuradio] FFT normalization issue: noise aliasing

On Sun, Oct 15, 2017 at 02:03:15PM +0200, Jean-Michel FRIEDT wrote: > Shouldn't my aliasing experiment raise the noise floor rather than keep it > constant ? By taking only every 10th sample, you also reduce the sample rate by a factor of 10. So you have the same power in 1/10th of the original

Re: [Discuss-gnuradio] Vectorized Python code overflows faster

On Fri, Jun 16, 2017 at 12:18:31PM -0700, Zach Morris wrote: > In short, my "optimized" Python code seems to run faster in testing, but > overflow more in practice. Could you help me understand why this happens? This looks like a classical example of 'fast and efficient' not being the same as 're

Re: [Discuss-gnuradio] GNU Radio Companion - ALSA

On Sun, Feb 19, 2017 at 04:25:10PM +0100, Marcus Müller wrote: > Hm, that looks like there's no HW in the list, so that would be an > initial debugging success! > So, the easiest is probably if you just use "pulse" in the Device Name > field. It must be lower case: hw:0.0 Also make sure Pulse isn

Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)

On Tue, Nov 15, 2016 at 05:14:41PM +, Benny Alexandar wrote: > >> If you mean that the internal buffer isn't needed and that the gr buffer > >> can take > its role, that's not going to work. > > This is what I'm thinking of. > All the packets which are put into the input queue of audio sink

Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)

On Mon, Nov 14, 2016 at 04:59:24PM +, Benny Alexandar wrote: > I have some questions regarding it. > How many blocks of audio the internal buffer need to store ? Enough to keep feeding samples to the audio HW until the sink's work() is called again. > When does the copy from gr buffer to

Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)

On Sun, Nov 13, 2016 at 02:46:57PM +, Benny Alexandar wrote: [ Please use the key to limit the lenght of your text lines ] > Only the receiver has to measure the drift and adjust to the incoming > rate. > ... > So my problem is how to measure the ppm drift using timestamps from > only the au

Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)

On Mon, Nov 07, 2016 at 12:48:18AM +0100, Marcus Müller wrote: > Well it doesn't have any negative effect, and it allows you to just > return the number of items you consumed (sink) or produced (source), and > you write a work() instead of a general_work(), so that's why we do it. Good news: I've

Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)

On Sat, Nov 12, 2016 at 01:41:40PM +, Benny Alexandar wrote: > Yes, but the input rate cannot be measured, It can, even if the data stream has irregular timing. That's why there is a DLL there. See the links posted before for how it works. > But the codec can use the time stamp of the input

Re: [Discuss-gnuradio] out-of-tree module without root privileges

On Sat, Nov 12, 2016 at 07:27:04AM +0100, Sylvain Munaut wrote: > Once you authorize someone to use sudo, he _is_root for all intents > and purposes, you realize that right ? In general that's not true, you can just allow some specific commands via sudo. But of course, in this case it's true si

Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)

On Thu, Nov 10, 2016 at 04:17:25PM +0100, Marcus Müller wrote: > > RF block duration is directly propotional to audio frame durations. > > 100ms of RF block duration will corresponds to 100ms of audio. > > no! And that's exactly the problem. In theory, it should be the way, but > because neither

Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)

On Wed, Nov 09, 2016 at 05:12:25PM +, Benny Alexandar wrote: > So the logic is whenever an audio compressed frame arrives at the audio codec, > it is timestamped with the current time (Ti) and after uncompressed each audio > frame blocks (24ms) is timestamped by adding 24ms ( Ti + ( frame_no *

Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)

On Sun, Nov 06, 2016 at 07:32:47PM +0100, Marcus Müller wrote: > under the hood, sinks are sync_blocks. Which is what surprises me. Sinks have no outputs, and sources have no inputs, so the whole 'sync' concept seems out of place... Ciao, -- FA A world of exhaustive, reliable metadata would

Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)

On Sun, Nov 06, 2016 at 07:34:32PM +0100, Marcus Müller wrote: > Exactly. This is where my tortoise-analogon kicks in: getting a > timestamp from some hardware clock simply takes an indeterminate amount > of time. You can only hope that time and its variance is small enough > for your estimator to

Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)

On Sun, Nov 06, 2016 at 05:08:37PM +, Benny Alexandar wrote: > Instead of relying the fourth clock on CPU, we can use a counter > from audio hardware that will be more stable than CPU timer. > I would like to explore this option of using a TimeStampCounter > (TSC) from audio hardware if it e

Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)

On Sun, Nov 06, 2016 at 03:58:43PM +0100, Marcus Müller wrote: > Well, obviously, there's interest, but I'd say we all agree that we'd > need someone to fix the Jack interface first – we simply don't have that > person at our disposal. At this point, it seems you're the one most > prolific with Ja

Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)

On Sun, Nov 06, 2016 at 02:17:17PM +0100, Marcus Müller wrote: > So the main technical problem that we have is that whilst this DLL (I'd > just call it a buffer-fillage control loop) is conceptually nice to > understand, no-one has implemented it within GNU Radio – if you found > yourself able to

Re: [Discuss-gnuradio] Delay locked loop for the two-clock problem

On Thu, Oct 27, 2016 at 10:35:32PM +, Fons Adriaensen wrote: > time constant of around 10 / B, i.e. one second. So the relativei Correction : of around 1 / (10 * B), i.e. one second. -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded

Re: [Discuss-gnuradio] Delay locked loop for the two-clock problem

On Wed, Oct 26, 2016 at 11:54:17PM +0200, Marcus Müller wrote: > > The actual frequency of the clock used to measure time doesn't > > matter as long as it has reasonable short term stability (and both sides > > use the same clock of course). > Exactly; that what was I was worried about. I don't ha

Re: [Discuss-gnuradio] Delay locked loop for the two-clock problem (was: simple mod-demod combinations doesn't work)

On Wed, Oct 26, 2016 at 01:30:19PM +0200, Marcus Müller wrote: > Now, these microsecond timestamps > will introduce a /third/ clock into our problems. I can see how the > control loop converges in case of that clock being both faster than your > sampling clock and relatively well-behaved, but: is

Re: [Discuss-gnuradio] simple mod-demod combinations doesn't work

Hi Marcus, > sorry, please believe me, no-one meant to upset you. I'm a bit surprised > you're taking this so personally! I'm pretty sure nobody wanted to upset me ! But apparently nobody is interested to make the Jack interface work as intended, not even its author... > Anyway, how do you esti

Re: [Discuss-gnuradio] simple mod-demod combinations doesn't work

On Tue, Oct 25, 2016 at 09:07:57PM +0200, Marcus Müller wrote: > So, yeah, again, two-clock problem: > If your red pitaya samples at, let's say, 4.8 MHz, and your sound card > samples at 48kHz, then you need to decimate by a factor of hundred. > Problem is that the sampling rate of the Sound card

[Discuss-gnuradio] using jack audio

Hello all, I'm a new user of gnuradio, this is my first post here. Running running 3.7.10.1 on a fully updated Archlinux system. Since I use Jack for everything audio, I've configure gr to use Jack as well (/etc/gnuradio/conf.d/gr-audio.conf). Trying out the examples and some other tests, it see