On 4/30/24 21:40, Gary Schafer wrote:
> Sorry about my misunderstanding. I recreated a portion of your flowgraph
> just to see what it would do. I left the 16 kHz sample rate but with a
> 2^15 time record size. Once I ran the flowgraph, it was 17.5 seconds
> before the Number Sink updated, and 34 seconds before the spectral
> display (vector sink) updated. However, after that time, each update
> roughly twice per second. Is that different from what you're seeing?
I disabled the rational resample so I'm using 500 samples/sec and 500
bins rather than 512/512, and that has broken the vector sink,. It's
getting late here so let me experiment more tomorrow and get back with
some results.
Thanks!
John
Tuesday, April 30, 2024
Re: Rational resample before FFT, and FFT rate
"I do understand the relationships between sample rate, FFT depth, time resolution, and frequency resolution. I used 512 samples/512 bins/1 second as a simple test case for the problem that I'm not getting one data point per frame, regardless of the frame rate."
Sorry about my misunderstanding. I recreated a portion of your flowgraph just to see what it would do. I left the 16 kHz sample rate but with a 2^15 time record size. Once I ran the flowgraph, it was 17.5 seconds before the Number Sink updated, and 34 seconds before the spectral display (vector sink) updated. However, after that time, each update roughly twice per second. Is that different from what you're seeing?
Gary
On 4/30/24 20:17, John Ackermann N8UR wrote:
> On 4/30/24 18:35, Gary Schafer wrote:
>
>> "I need data points at convenient intervals for time series plotting, e.g., 512 samples/second going into a 512 bin FFT to provide one maximum amplitude value per second."
>>
>> Let me answer that one at the same time as "Ultimately I want to plot both the amplitude and any frequency change to sub-Hz resolution."
>>
>> Okay, you've hit a contradiction. You can NOT get "sub-Hz" resolution using a sample rate, in Hz, that equals your time record size, in samples.
>
> Hi Gary -- sorry if my message was confusing. I do understand the relationships between sample rate, FFT depth, time resolution, and frequency resolution. I used 512 samples/512 bins/1 second as a simple test case for the problem that I'm not getting one data point per frame, regardless of the frame rate. Given how noisy this data is, I may well end up with something like one frame per 10 seconds, but before I can play with that I need to understand what is wrong with my processing to get the amplitude of the maximum bin per frame.
>
> John
Sorry about my misunderstanding. I recreated a portion of your flowgraph just to see what it would do. I left the 16 kHz sample rate but with a 2^15 time record size. Once I ran the flowgraph, it was 17.5 seconds before the Number Sink updated, and 34 seconds before the spectral display (vector sink) updated. However, after that time, each update roughly twice per second. Is that different from what you're seeing?
Gary
On 4/30/24 20:17, John Ackermann N8UR wrote:
> On 4/30/24 18:35, Gary Schafer wrote:
>
>> "I need data points at convenient intervals for time series plotting, e.g., 512 samples/second going into a 512 bin FFT to provide one maximum amplitude value per second."
>>
>> Let me answer that one at the same time as "Ultimately I want to plot both the amplitude and any frequency change to sub-Hz resolution."
>>
>> Okay, you've hit a contradiction. You can NOT get "sub-Hz" resolution using a sample rate, in Hz, that equals your time record size, in samples.
>
> Hi Gary -- sorry if my message was confusing. I do understand the relationships between sample rate, FFT depth, time resolution, and frequency resolution. I used 512 samples/512 bins/1 second as a simple test case for the problem that I'm not getting one data point per frame, regardless of the frame rate. Given how noisy this data is, I may well end up with something like one frame per 10 seconds, but before I can play with that I need to understand what is wrong with my processing to get the amplitude of the maximum bin per frame.
>
> John
Re: Rational resample before FFT, and FFT rate
On 4/30/24 18:35, Gary Schafer wrote:
> "I need data points at convenient intervals for time series plotting,
> e.g., 512 samples/second going into a 512 bin FFT to provide one maximum
> amplitude value per second."
>
> Let me answer that one at the same time as "Ultimately I want to plot
> both the amplitude and any frequency change to sub-Hz resolution."
>
> Okay, you've hit a contradiction. You can NOT get "sub-Hz" resolution
> using a sample rate, in Hz, that equals your time record size, in
> samples.
Hi Gary -- sorry if my message was confusing. I do understand the
relationships between sample rate, FFT depth, time resolution, and
frequency resolution. I used 512 samples/512 bins/1 second as a simple
test case for the problem that I'm not getting one data point per frame,
regardless of the frame rate. Given how noisy this data is, I may well
end up with something like one frame per 10 seconds, but before I can
play with that I need to understand what is wrong with my processing to
get the amplitude of the maximum bin per frame.
John
> "I need data points at convenient intervals for time series plotting,
> e.g., 512 samples/second going into a 512 bin FFT to provide one maximum
> amplitude value per second."
>
> Let me answer that one at the same time as "Ultimately I want to plot
> both the amplitude and any frequency change to sub-Hz resolution."
>
> Okay, you've hit a contradiction. You can NOT get "sub-Hz" resolution
> using a sample rate, in Hz, that equals your time record size, in
> samples.
Hi Gary -- sorry if my message was confusing. I do understand the
relationships between sample rate, FFT depth, time resolution, and
frequency resolution. I used 512 samples/512 bins/1 second as a simple
test case for the problem that I'm not getting one data point per frame,
regardless of the frame rate. Given how noisy this data is, I may well
end up with something like one frame per 10 seconds, but before I can
play with that I need to understand what is wrong with my processing to
get the amplitude of the maximum bin per frame.
John
Re: Rational resample before FFT, and FFT rate
Let me answer some of your questions in reverse order:
"My main question is why the displayed maximum bin value is updating much more slowly than once per second when FFT size = sample rate."
That could be due to an issue in Gnu Radio. I've noticed that if the bin width (sample rate / N) is close to or less than 1 Hz, my flowgraphs will either crash or just stop running (freeze up). Perhaps that's an issue with this. I'd love to hear someone more knowledgeable than I on Gnu Radio chime in. Otherwise, you may have to resort to Python (or something similar) programming.
"I need data points at convenient intervals for time series plotting, e.g., 512 samples/second going into a 512 bin FFT to provide one maximum amplitude value per second."
Let me answer that one at the same time as "Ultimately I want to plot both the amplitude and any frequency change to sub-Hz resolution."
Okay, you've hit a contradiction. You can NOT get "sub-Hz" resolution using a sample rate, in Hz, that equals your time record size, in samples. The most common measure of resolution for FFTs is the equivalent noise bandwidth (ENBW), and RBW = fs*B/N, where fs = sample rate, B = NENBW (normalized equivalent noise bandwidth) of the window used, and N = number of samples in the time record fed into the FFT. You can achieve sub-Hz *binwidth* by zero-padding the data, but that just really smooths out the spectral data. It doesn't really give you "sub-Hz resolution".
Thinking it through, the ONLY way I can see you getting your sub-Hz resolution AND maintain a data point collection of 1 sample / second is to use overlapping FFTs. For example, see https://karc.ca/sites/default/files/EUCARA-2018%20-%20EUCARA2018_Dwingeloo_goes_SDR.pdf. Pe1nut (aka Paul Boven, the author of that presentation) is truly gifted in using Gnu Radio to do some great things in radio astronomy. That would require you to create multiple flows for your samples that allow for the data to overlap between FFTs. With four overlapping FFTs, for example, and with a window type that has a relatively small NENBW (Hamming, for example), you could get a resolution of roughly 0.33 Hz.
Make sense?
Gary
On 4/29/24 22:18, John Ackermann N8UR wrote:
> Hi Gary --
>
> Thanks for getting back to me. Maybe I can explain better what I'm doing. The data is 16 ksps complex IQ centered at 50.080 MHz. The target signal is an essentially unmodulated CW carrier about 427 below that. I have about 8 hours of recorded data to analyze.
>
> Ultimately I want to plot both the amplitude and any frequency change to sub-Hz resolution. To get sufficient resolution I decimate down to a bandwidth of only a few hundred Hz. That would put the target signal outside the passband, so the frequency translation first shifts it to the center.
>
> I need data points at convenient intervals for time series plotting, e.g., 512 samples/second going into a 512 bin FFT to provide one maximum amplitude value per second. I resampled so I could get that one-frame-per-second pacing with a power-of-two FFT size. If that's not a real concern, I can happily remove the resampling and work with the natural sample rate, e.g., 500 bin FFT fed by 500 samples/second.
>
> My main question is why the displayed maximum bin value is updating much more slowly than once per second when FFT size = sample rate. It's more like one per five seconds. In particular, am I doing something wrong with the stream and vector conversions around the FFT and MAX blocks?
>
> Thanks,
> John
> ----
> On 4/29/24 19:06, Gary Schafer wrote:
>> It sounds to me as if you're trying to move the signal to the center of a FFT bin so that you don't have to deal with scalloping loss. Is that correct? If so, I strongly recommend that you skip all of this resampling and just use a "flattop" window in the FFT. That will allow you to measure the maximum amplitude with very high accuracy (roughly within 0.01 dB) regardless of where the signal resides within the spectrum.
>>
>> If that's not satisfactory, then I recommend that you skip the "having a sample rate that is a power-of-2 Hz" and just move the signal to the center of a frequency bin with whatever sample rate you have. The bin frequencies are simply (sample rate)/N, where N is the number of samples in the FFT. So with a sample rate of 16 kHz and a 512 pt FFT, you'd select a frequency that was an integer value of 16000/512 = 31.25 Hz. So, if you want to move it to, say, the 10th bin, move it to 31.25*10 = 312.5 Hz. Done.
>>
>> Good luck!
>>
>> Gary
>>
>>
>> ************************************
>> I am reading Digital RF data at 16k samples/second, and my goal is to
>> get the power of the maximum frequency once per second.
>>
>> I start by resampling to a power-of-two rate, then translating to move
>> the desired frequency to the center with further decimation, then doing
>> an FFT, converting to log power and finally extracting the power of the
>> loudest bin. The decimation and FFT size are calculated to yield one
>> FFT per second. I'm not sure if I'm doing this correctly and I've
>> attached the flowgraph.
>>
>> (a) Should the FFT use only a power-of-two bin size? I am resampling
>> to go from 16k to 8192 samples/second so that I ultimately decimate to
>> 512 samples/second rather than 500 samples/second.
>>
>> Is that the right thing to do? Should I resample up to 16384
>> samples/second rather than down to 8192? Or should I just use a 500 bin
>> FFT?
>>
>> (b) Given that the final sample rate and FFT depth are equal (512), I
>> expected to get one vector per second, and thus one maximum value per
>> second. Instead, I see a much slower update rate, about once per five
>> seconds.
>>
>> I added a QT vector sink and while that takes a long time to get
>> started, once going it does update about once per second. Am I doing
>> something wrong that the maximum value doesn't update with each new vector?
>>
>> Thanks,
>> John
"My main question is why the displayed maximum bin value is updating much more slowly than once per second when FFT size = sample rate."
That could be due to an issue in Gnu Radio. I've noticed that if the bin width (sample rate / N) is close to or less than 1 Hz, my flowgraphs will either crash or just stop running (freeze up). Perhaps that's an issue with this. I'd love to hear someone more knowledgeable than I on Gnu Radio chime in. Otherwise, you may have to resort to Python (or something similar) programming.
"I need data points at convenient intervals for time series plotting, e.g., 512 samples/second going into a 512 bin FFT to provide one maximum amplitude value per second."
Let me answer that one at the same time as "Ultimately I want to plot both the amplitude and any frequency change to sub-Hz resolution."
Okay, you've hit a contradiction. You can NOT get "sub-Hz" resolution using a sample rate, in Hz, that equals your time record size, in samples. The most common measure of resolution for FFTs is the equivalent noise bandwidth (ENBW), and RBW = fs*B/N, where fs = sample rate, B = NENBW (normalized equivalent noise bandwidth) of the window used, and N = number of samples in the time record fed into the FFT. You can achieve sub-Hz *binwidth* by zero-padding the data, but that just really smooths out the spectral data. It doesn't really give you "sub-Hz resolution".
Thinking it through, the ONLY way I can see you getting your sub-Hz resolution AND maintain a data point collection of 1 sample / second is to use overlapping FFTs. For example, see https://karc.ca/sites/default/files/EUCARA-2018%20-%20EUCARA2018_Dwingeloo_goes_SDR.pdf. Pe1nut (aka Paul Boven, the author of that presentation) is truly gifted in using Gnu Radio to do some great things in radio astronomy. That would require you to create multiple flows for your samples that allow for the data to overlap between FFTs. With four overlapping FFTs, for example, and with a window type that has a relatively small NENBW (Hamming, for example), you could get a resolution of roughly 0.33 Hz.
Make sense?
Gary
On 4/29/24 22:18, John Ackermann N8UR wrote:
> Hi Gary --
>
> Thanks for getting back to me. Maybe I can explain better what I'm doing. The data is 16 ksps complex IQ centered at 50.080 MHz. The target signal is an essentially unmodulated CW carrier about 427 below that. I have about 8 hours of recorded data to analyze.
>
> Ultimately I want to plot both the amplitude and any frequency change to sub-Hz resolution. To get sufficient resolution I decimate down to a bandwidth of only a few hundred Hz. That would put the target signal outside the passband, so the frequency translation first shifts it to the center.
>
> I need data points at convenient intervals for time series plotting, e.g., 512 samples/second going into a 512 bin FFT to provide one maximum amplitude value per second. I resampled so I could get that one-frame-per-second pacing with a power-of-two FFT size. If that's not a real concern, I can happily remove the resampling and work with the natural sample rate, e.g., 500 bin FFT fed by 500 samples/second.
>
> My main question is why the displayed maximum bin value is updating much more slowly than once per second when FFT size = sample rate. It's more like one per five seconds. In particular, am I doing something wrong with the stream and vector conversions around the FFT and MAX blocks?
>
> Thanks,
> John
> ----
> On 4/29/24 19:06, Gary Schafer wrote:
>> It sounds to me as if you're trying to move the signal to the center of a FFT bin so that you don't have to deal with scalloping loss. Is that correct? If so, I strongly recommend that you skip all of this resampling and just use a "flattop" window in the FFT. That will allow you to measure the maximum amplitude with very high accuracy (roughly within 0.01 dB) regardless of where the signal resides within the spectrum.
>>
>> If that's not satisfactory, then I recommend that you skip the "having a sample rate that is a power-of-2 Hz" and just move the signal to the center of a frequency bin with whatever sample rate you have. The bin frequencies are simply (sample rate)/N, where N is the number of samples in the FFT. So with a sample rate of 16 kHz and a 512 pt FFT, you'd select a frequency that was an integer value of 16000/512 = 31.25 Hz. So, if you want to move it to, say, the 10th bin, move it to 31.25*10 = 312.5 Hz. Done.
>>
>> Good luck!
>>
>> Gary
>>
>>
>> ************************************
>> I am reading Digital RF data at 16k samples/second, and my goal is to
>> get the power of the maximum frequency once per second.
>>
>> I start by resampling to a power-of-two rate, then translating to move
>> the desired frequency to the center with further decimation, then doing
>> an FFT, converting to log power and finally extracting the power of the
>> loudest bin. The decimation and FFT size are calculated to yield one
>> FFT per second. I'm not sure if I'm doing this correctly and I've
>> attached the flowgraph.
>>
>> (a) Should the FFT use only a power-of-two bin size? I am resampling
>> to go from 16k to 8192 samples/second so that I ultimately decimate to
>> 512 samples/second rather than 500 samples/second.
>>
>> Is that the right thing to do? Should I resample up to 16384
>> samples/second rather than down to 8192? Or should I just use a 500 bin
>> FFT?
>>
>> (b) Given that the final sample rate and FFT depth are equal (512), I
>> expected to get one vector per second, and thus one maximum value per
>> second. Instead, I see a much slower update rate, about once per five
>> seconds.
>>
>> I added a QT vector sink and while that takes a long time to get
>> started, once going it does update about once per second. Am I doing
>> something wrong that the maximum value doesn't update with each new vector?
>>
>> Thanks,
>> John
Monday, April 29, 2024
Re: Rational resample before FFT, and FFT rate
Hi Gary --
Thanks for getting back to me. Maybe I can explain better what I'm
doing. The data is 16 ksps complex IQ centered at 50.080 MHz. The
target signal is an essentially unmodulated CW carrier about 427 below
that. I have about 8 hours of recorded data to analyze.
Ultimately I want to plot both the amplitude and any frequency change to
sub-Hz resolution. To get sufficient resolution I decimate down to a
bandwidth of only a few hundred Hz. That would put the target signal
outside the passband, so the frequency translation first shifts it to
the center.
I need data points at convenient intervals for time series plotting,
e.g., 512 samples/second going into a 512 bin FFT to provide one maximum
amplitude value per second. I resampled so I could get that
one-frame-per-second pacing with a power-of-two FFT size. If that's not
a real concern, I can happily remove the resampling and work with the
natural sample rate, e.g., 500 bin FFT fed by 500 samples/second.
My main question is why the displayed maximum bin value is updating much
more slowly than once per second when FFT size = sample rate. It's more
like one per five seconds. In particular, am I doing something wrong
with the stream and vector conversions around the FFT and MAX blocks?
Thanks,
John
----
On 4/29/24 19:06, Gary Schafer wrote:
> It sounds to me as if you're trying to move the signal to the center of
> a FFT bin so that you don't have to deal with scalloping loss. Is that
> correct? If so, I strongly recommend that you skip all of this
> resampling and just use a "flattop" window in the FFT. That will allow
> you to measure the maximum amplitude with very high accuracy (roughly
> within 0.01 dB) regardless of where the signal resides within the spectrum.
>
> If that's not satisfactory, then I recommend that you skip the "having a
> sample rate that is a power-of-2 Hz" and just move the signal to the
> center of a frequency bin with whatever sample rate you have. The bin
> frequencies are simply (sample rate)/N, where N is the number of samples
> in the FFT. So with a sample rate of 16 kHz and a 512 pt FFT, you'd
> select a frequency that was an integer value of 16000/512 = 31.25 Hz.
> So, if you want to move it to, say, the 10th bin, move it to 31.25*10 =
> 312.5 Hz. Done.
>
> Good luck!
>
> Gary
>
>
> ************************************
> I am reading Digital RF data at 16k samples/second, and my goal is to
> get the power of the maximum frequency once per second.
>
> I start by resampling to a power-of-two rate, then translating to move
> the desired frequency to the center with further decimation, then doing
> an FFT, converting to log power and finally extracting the power of the
> loudest bin. The decimation and FFT size are calculated to yield one
> FFT per second. I'm not sure if I'm doing this correctly and I've
> attached the flowgraph.
>
> (a) Should the FFT use only a power-of-two bin size? I am resampling
> to go from 16k to 8192 samples/second so that I ultimately decimate to
> 512 samples/second rather than 500 samples/second.
>
> Is that the right thing to do? Should I resample up to 16384
> samples/second rather than down to 8192? Or should I just use a 500 bin
> FFT?
>
> (b) Given that the final sample rate and FFT depth are equal (512), I
> expected to get one vector per second, and thus one maximum value per
> second. Instead, I see a much slower update rate, about once per five
> seconds.
>
> I added a QT vector sink and while that takes a long time to get
> started, once going it does update about once per second. Am I doing
> something wrong that the maximum value doesn't update with each new vector?
>
> Thanks,
> John
Thanks for getting back to me. Maybe I can explain better what I'm
doing. The data is 16 ksps complex IQ centered at 50.080 MHz. The
target signal is an essentially unmodulated CW carrier about 427 below
that. I have about 8 hours of recorded data to analyze.
Ultimately I want to plot both the amplitude and any frequency change to
sub-Hz resolution. To get sufficient resolution I decimate down to a
bandwidth of only a few hundred Hz. That would put the target signal
outside the passband, so the frequency translation first shifts it to
the center.
I need data points at convenient intervals for time series plotting,
e.g., 512 samples/second going into a 512 bin FFT to provide one maximum
amplitude value per second. I resampled so I could get that
one-frame-per-second pacing with a power-of-two FFT size. If that's not
a real concern, I can happily remove the resampling and work with the
natural sample rate, e.g., 500 bin FFT fed by 500 samples/second.
My main question is why the displayed maximum bin value is updating much
more slowly than once per second when FFT size = sample rate. It's more
like one per five seconds. In particular, am I doing something wrong
with the stream and vector conversions around the FFT and MAX blocks?
Thanks,
John
----
On 4/29/24 19:06, Gary Schafer wrote:
> It sounds to me as if you're trying to move the signal to the center of
> a FFT bin so that you don't have to deal with scalloping loss. Is that
> correct? If so, I strongly recommend that you skip all of this
> resampling and just use a "flattop" window in the FFT. That will allow
> you to measure the maximum amplitude with very high accuracy (roughly
> within 0.01 dB) regardless of where the signal resides within the spectrum.
>
> If that's not satisfactory, then I recommend that you skip the "having a
> sample rate that is a power-of-2 Hz" and just move the signal to the
> center of a frequency bin with whatever sample rate you have. The bin
> frequencies are simply (sample rate)/N, where N is the number of samples
> in the FFT. So with a sample rate of 16 kHz and a 512 pt FFT, you'd
> select a frequency that was an integer value of 16000/512 = 31.25 Hz.
> So, if you want to move it to, say, the 10th bin, move it to 31.25*10 =
> 312.5 Hz. Done.
>
> Good luck!
>
> Gary
>
>
> ************************************
> I am reading Digital RF data at 16k samples/second, and my goal is to
> get the power of the maximum frequency once per second.
>
> I start by resampling to a power-of-two rate, then translating to move
> the desired frequency to the center with further decimation, then doing
> an FFT, converting to log power and finally extracting the power of the
> loudest bin. The decimation and FFT size are calculated to yield one
> FFT per second. I'm not sure if I'm doing this correctly and I've
> attached the flowgraph.
>
> (a) Should the FFT use only a power-of-two bin size? I am resampling
> to go from 16k to 8192 samples/second so that I ultimately decimate to
> 512 samples/second rather than 500 samples/second.
>
> Is that the right thing to do? Should I resample up to 16384
> samples/second rather than down to 8192? Or should I just use a 500 bin
> FFT?
>
> (b) Given that the final sample rate and FFT depth are equal (512), I
> expected to get one vector per second, and thus one maximum value per
> second. Instead, I see a much slower update rate, about once per five
> seconds.
>
> I added a QT vector sink and while that takes a long time to get
> started, once going it does update about once per second. Am I doing
> something wrong that the maximum value doesn't update with each new vector?
>
> Thanks,
> John
Re: Rational resample before FFT, and FFT rate
It sounds to me as if you're trying to move the signal to the center of a FFT bin so that you don't have to deal with scalloping loss. Is that correct? If so, I strongly recommend that you skip all of this resampling and just use a "flattop" window in the FFT. That will allow you to measure the maximum amplitude with very high accuracy (roughly within 0.01 dB) regardless of where the signal resides within the spectrum.
If that's not satisfactory, then I recommend that you skip the "having a sample rate that is a power-of-2 Hz" and just move the signal to the center of a frequency bin with whatever sample rate you have. The bin frequencies are simply (sample rate)/N, where N is the number of samples in the FFT. So with a sample rate of 16 kHz and a 512 pt FFT, you'd select a frequency that was an integer value of 16000/512 = 31.25 Hz. So, if you want to move it to, say, the 10th bin, move it to 31.25*10 = 312.5 Hz. Done.
Good luck!
Gary
************************************
I am reading Digital RF data at 16k samples/second, and my goal is to
get the power of the maximum frequency once per second.
I start by resampling to a power-of-two rate, then translating to move
the desired frequency to the center with further decimation, then doing
an FFT, converting to log power and finally extracting the power of the
loudest bin. The decimation and FFT size are calculated to yield one
FFT per second. I'm not sure if I'm doing this correctly and I've
attached the flowgraph.
(a) Should the FFT use only a power-of-two bin size? I am resampling
to go from 16k to 8192 samples/second so that I ultimately decimate to
512 samples/second rather than 500 samples/second.
Is that the right thing to do? Should I resample up to 16384
samples/second rather than down to 8192? Or should I just use a 500 bin
FFT?
(b) Given that the final sample rate and FFT depth are equal (512), I
expected to get one vector per second, and thus one maximum value per
second. Instead, I see a much slower update rate, about once per five
seconds.
I added a QT vector sink and while that takes a long time to get
started, once going it does update about once per second. Am I doing
something wrong that the maximum value doesn't update with each new vector?
Thanks,
John
If that's not satisfactory, then I recommend that you skip the "having a sample rate that is a power-of-2 Hz" and just move the signal to the center of a frequency bin with whatever sample rate you have. The bin frequencies are simply (sample rate)/N, where N is the number of samples in the FFT. So with a sample rate of 16 kHz and a 512 pt FFT, you'd select a frequency that was an integer value of 16000/512 = 31.25 Hz. So, if you want to move it to, say, the 10th bin, move it to 31.25*10 = 312.5 Hz. Done.
Good luck!
Gary
************************************
I am reading Digital RF data at 16k samples/second, and my goal is to
get the power of the maximum frequency once per second.
I start by resampling to a power-of-two rate, then translating to move
the desired frequency to the center with further decimation, then doing
an FFT, converting to log power and finally extracting the power of the
loudest bin. The decimation and FFT size are calculated to yield one
FFT per second. I'm not sure if I'm doing this correctly and I've
attached the flowgraph.
(a) Should the FFT use only a power-of-two bin size? I am resampling
to go from 16k to 8192 samples/second so that I ultimately decimate to
512 samples/second rather than 500 samples/second.
Is that the right thing to do? Should I resample up to 16384
samples/second rather than down to 8192? Or should I just use a 500 bin
FFT?
(b) Given that the final sample rate and FFT depth are equal (512), I
expected to get one vector per second, and thus one maximum value per
second. Instead, I see a much slower update rate, about once per five
seconds.
I added a QT vector sink and while that takes a long time to get
started, once going it does update about once per second. Am I doing
something wrong that the maximum value doesn't update with each new vector?
Thanks,
John
Re: Transmitting a waveform, and recording input, at an adjustable rep rate
Interesting, thanks, I'll check that out.
And no, I don't need precise timing control.
If I do have to do this with Python I might copy the data counting example in the Python Block wiki and connect the message output to the Message To Variable block which could be used to set the state of the recording-Boolean used in the previously mentioned example design.
On Mon, Apr 29, 2024, 3:13 PM Paul Atreides <maud.dib1984@gmail.com> wrote:
You might have luck modifying this tutorial.This gives you the ability to change parameters via a separate python script where simple logic may be easier to implement. Not precise timing, but simple.
Re: Transmitting a waveform, and recording input, at an adjustable rep rate
You might have luck modifying this tutorial.
This gives you the ability to change parameters via a separate python script where simple logic may be easier to implement. Not precise timing, but simple.
<end transmission>
On Apr 29, 2024, at 14:16, Jameson Collins <jameson.collins@gmail.com> wrote:
I'm trying to use GNU Radio to build a test/measurement rig.At a user-defined interval I want to perform two actions:1) Transmit an FM sweep with user definable properties like frequency2) And record to a file for a fixed duration.For the transmitter I was able to adapt the demo case for the lambda function found here: https://wiki.gnuradio.org/index.php/PDU_Lambda. This seems to work great.For the recording feature I started with the example "Pushbutton IQ Recorder with descriptive filenames" (https://wiki.gnuradio.org/index.php?title=Pushbutton_IQ_Recorder_with_descriptive_filenames). This works by creating a new file, and recording, whenever a user presses and holds a button. That button sets a variable to true which enables the recording.But, short of using custom python blocks, I can't figure out a way to trigger the recording at the same time I perform the transmit and I can't figure out a way to stop the recording automatically after a fixed amount of time / samples.
Transmitting a waveform, and recording input, at an adjustable rep rate
I'm trying to use GNU Radio to build a test/measurement rig.
At a user-defined interval I want to perform two actions:
1) Transmit an FM sweep with user definable properties like frequency
2) And record to a file for a fixed duration.
For the transmitter I was able to adapt the demo case for the lambda function found here: https://wiki.gnuradio.org/index.php/PDU_Lambda. This seems to work great.
For the recording feature I started with the example "Pushbutton IQ Recorder with descriptive filenames" (https://wiki.gnuradio.org/index.php?title=Pushbutton_IQ_Recorder_with_descriptive_filenames). This works by creating a new file, and recording, whenever a user presses and holds a button. That button sets a variable to true which enables the recording.
But, short of using custom python blocks, I can't figure out a way to trigger the recording at the same time I perform the transmit and I can't figure out a way to stop the recording automatically after a fixed amount of time / samples.
Re: Debugging Existing C++ Blocks with VS Code & GDB
Thanks Walter
I realized that I had multiple gnuradio versions installed even though I thought I checked that. I completely wiped all my gnu radio files, pulled in the latest version 3.10.10.0 and built using the -DCMAKE_BUILD_TYPE=Debug, and now I can successfully debug the existing DTV code. The python code must have been importing a module from gnuradio in another directory, which caused it to not recognized any of my edits or breakpoints in the file I was working on.
Matt
On Tue, Apr 23, 2024 at 7:41 PM walter <walter@hacktuary.ai> wrote:
Hi Matt,I'm not sure if this is an apples-to-apples situation, but your issue sounds exactly like something I've run into while abusing Python snippets.It was easy to avoid after understanding order-of-events for block creation.I suspect this is language-independent, and you can quickly create a python flowgraph / review the code - it will illustrate the principles:1. Create a python flowgraph 'FOO.grc' with minimal blocks (e.g. [signal source] --> [throttle2] --> [null sink]).2. Add four [Python Snippet] blocks - one for each type of [Section of Flowgraph] param: 'Init - Before Blocks', 'Main - After Start', etc.3. For each Python Snippet block, add a one-line snippet distinct to the [Section of Flowgraph], for example:print("Hello IAMA Init - Before Blocks")# NOTE: it's important to have a least one line of code or nothing will be generated for the snippet!4. Set the Title param of the [Options] block (top block) to "FOO".5. Press [F5] to generate the flowgraph code, which will be called FOO.py (in same directory as FOO.grc).6. Examine the resulting FOO.py script in VSCode - in particular, where each of the snippets are invoked.The most obvious example is that in 'Init - Before Block' it's possible to reference a block or variable self.X before self.X has been instantiated.More subtle cases are possible, depending on how clever one tries to be when using this mechanism.- WAttached: screencap of example error (take my word that the block 'radio' exists). I can send a shot of the flowgraph, but it probably wouldn't shed further light.On Apr 23, 2024, at 13:46, Matt Clemons <mattclems11@gmail.com> wrote:Hello,I've walked through tutorials and successfully set breakpoints and debugged OOT modules in Gnu Radio using the DCMAKE_BUILD_TYPE=Debug option. However, I'm trying to debug local changes I've made to existing gnuradio/dtv/ files and not having success.I've followed the steps in a similar question/email chain here: https://lists.gnu.org/archive/html/discuss-gnuradio/2021-08/msg00008.html (I wasn't sure if replying to this old chain with a question or referencing it was better, let me know if there is a preference for future scenerios).I also tried recompiling all of the gnu radio source code on my machine with the DCMAKE_BUILD_TYPE=Debug option and still can not get VScode to stop on my set breakpoint within the dtv/dvbt_demod_reference_signals_impl.cc file. The flowchart runs, and completes but when I hover over the break point it just says "Module containing this breakpoint has not yet loaded or the address could not be obtained".Any suggestions? I don't like the option of copying this into an OOT module just to debug. I'm not sure I understand the difference either.Thanks,Matt
NEWSDR 2024 on Friday May 31 at WPI in Worcester, MA, USA
The New England Workshop on Software Defined Radio (NEWSDR) is being held
at Worcester Polytechnic Institute (WPI) on Friday May 31, in Worcester, Massachusetts, USA.There will also be a tutorial session on the evening before on Thursday May 30.
The event is free, but advance registration is required.
To learn more about this event, as well as to register for free,
please visit our website at the link below.
Please also consider submitting a poster presentation for the networking sessions.
We are actively looking for submissions.
https://newsdr.org/workshops/newsdr2024/
Sunday, April 28, 2024
Rational resample before FFT, and FFT rate
I am reading Digital RF data at 16k samples/second, and my goal is to
get the power of the maximum frequency once per second.
I start by resampling to a power-of-two rate, then translating to move
the desired frequency to the center with further decimation, then doing
an FFT, converting to log power and finally extracting the power of the
loudest bin. The decimation and FFT size are calculated to yield one
FFT per second. I'm not sure if I'm doing this correctly and I've
attached the flowgraph.
(a) Should the FFT use only a power-of-two bin size? I am resampling
to go from 16k to 8192 samples/second so that I ultimately decimate to
512 samples/second rather than 500 samples/second.
Is that the right thing to do? Should I resample up to 16384
samples/second rather than down to 8192? Or should I just use a 500 bin
FFT?
(b) Given that the final sample rate and FFT depth are equal (512), I
expected to get one vector per second, and thus one maximum value per
second. Instead, I see a much slower update rate, about once per five
seconds.
I added a QT vector sink and while that takes a long time to get
started, once going it does update about once per second. Am I doing
something wrong that the maximum value doesn't update with each new vector?
Thanks,
John
get the power of the maximum frequency once per second.
I start by resampling to a power-of-two rate, then translating to move
the desired frequency to the center with further decimation, then doing
an FFT, converting to log power and finally extracting the power of the
loudest bin. The decimation and FFT size are calculated to yield one
FFT per second. I'm not sure if I'm doing this correctly and I've
attached the flowgraph.
(a) Should the FFT use only a power-of-two bin size? I am resampling
to go from 16k to 8192 samples/second so that I ultimately decimate to
512 samples/second rather than 500 samples/second.
Is that the right thing to do? Should I resample up to 16384
samples/second rather than down to 8192? Or should I just use a 500 bin
FFT?
(b) Given that the final sample rate and FFT depth are equal (512), I
expected to get one vector per second, and thus one maximum value per
second. Instead, I see a much slower update rate, about once per five
seconds.
I added a QT vector sink and while that takes a long time to get
started, once going it does update about once per second. Am I doing
something wrong that the maximum value doesn't update with each new vector?
Thanks,
John
Friday, April 26, 2024
Re: Audio source - device or resource busy error - PROBLEM SOLVED
Marcus,
I have discovered a solution to this issue but I don't understand why.
The 'main()' of FT8_Receive contains lines related to sig_handler which were
included in the original file created by GNU Radio as shown below:
def main(top_block_cls=FT8_Receive, options=None):
tb = top_block_cls()
now = float(datetime.now().strftime('%S.%f'))
print ("RX main = ", now)
def sig_handler(sig=None, frame=None):
tb.stop()
tb.wait()
sys.exit(0)
signal.signal(signal.SIGINT, sig_handler)
signal.signal(signal.SIGTERM, sig_handler)
check_time(cycle)
print("\nReceiving...")
#Receiving = time.time()
#now = float(datetime.now().strftime('%S.%f'))
#print ("After Receiving = ", now)
tb.start()
#start = time.time()
#print ("start = ",start)
tb.wait()
In desperation I removed those lines to see what the effect would be. I am
no longer getting the resource busy error and the code is running as I
intended.
Why are those lines included and why did their removal fix the problem?
Jim
-----Original Message-----
From: Elmore Family
Sent: Monday, April 15, 2024 11:01 AM
To: GNURadio Discussion List ; Marcus Müller
Subject: Re: Audio source - device or resource busy error
Marcus,
The following is the config.conf file as modified per your request:
[audio_alsa]
audio_module = portaudio
default_input_device = portaudio
default_output_device = pulse
nperiods = 32
period_time = 0.010
verbose = false
Did I do this correctly?
I wasn't sure what to use for the Device Name so I tried portaudio - didn't
recognize it. Used default - it ran but produced exactly the same error as
pulse after 6 iterations.
Note for reference:
Prior to calling the FT8_Receive.main() as I do now I was using either
os.system or subprocess calls to call FT8_Receive. These did not result in
any audio errors but the time to start of execution (1.2 secs) is excessive
rendering the application unusable due to critical timing constraints.
Jim
-----Original Message-----
From: Marcus Müller
Sent: Monday, April 15, 2024 4:55 AM
To: Elmore Family ; GNURadio Discussion List
Subject: Re: Audio source - device or resource busy error
Hi Jim,
so, that's an interesting problem with your sound system. I don't see why it
*should* fail
at six created sources (my suspicion is that the non-deterministic
destruction of objects
that is inherent to Python means there's six parallel endpoints active, from
a perspective
of ALSA and pulseaudio).
Sadly, we don't have a test that covers this (yet?).
Maybe this is a problem specific to the way the ALSA source works.
Would be able to test the portaudio sink? For that, we'll have to force GNU
Radio to use
it (because it uses ALSA by default). You can do that by adding
[audio]
audio_module = portaudio
to your GNU Radio configuration, so to a file ending in .conf (e.g.,
audio.conf) in the
directory that `gnuradio-config-info --userprefsdir` shows.
Best regards,
Marcus
On 15.04.24 02:18, Elmore Family wrote:
> Marcus,
>
> I first tried:
> For ALSA users with audio trouble, follow this procedure ( which I
> followed):
>
> The result was the same.
>
> Then I selected pulse as the device name. it worked for 6 iterations of
> the loop and then gave the following error:
>
> mmap() failed: Cannot allocate memory
> mmap() failed: Cannot allocate memory
> gr::log :ERROR: audio_alsa_source6 - [pulse]: Input/output error
> Traceback (most recent call last):
> File "/home/pi/gr-ft8_rxtx/python/ft8_rxtx.py", line 337, in <module>
> main()
> File "/home/pi/gr-ft8_rxtx/python/ft8_rxtx.py", line 320, in main
> FT8_Receive.main()
> File "/home/pi/gr-ft8_rxtx/python/FT8_Receive.py", line 205, in main
> tb = top_block_cls()
> File "/home/pi/gr-ft8_rxtx/python/FT8_Receive.py", line 85, in __init__
> self.audio_source_0 = audio.source(samp_rate, 'pulse', True)
> RuntimeError: audio_alsa_source
>
> Jim
>
> -----Original Message----- From: Marcus Müller
> Sent: Sunday, April 14, 2024 3:45 PM
> To: discuss-gnuradio@gnu.org
> Subject: Re: Audio source - device or resource busy error
>
> Hi Jim,
>
> try not using the direct hardware device, but the device provided by your
> sound system;
> see the "for users wiht audio trouble" section on the Audio Source
> documentation page.
>
> Best regards,
> Marcus
>
> On 14.04.24 18:02, Elmore Family wrote:
>> I am getting the subject error when running a Python script called
>> repeatedly from another script.
>> The snippet_ft8_rxtx.py shows the call, FT8_Receive.main(), in the while
>> loop.
>> FT8_Receive.py shows the called script.
>> FT8_Receive.pdf is the flowgraph used to generate the called script which
>> as you can see has been modified in main() and with check_time added.
>> The first call to the script is OK but the second call results in the
>> error shown in audio_error.txt.
>> Why is the audio source busy when the flowgraph is stopped (or is it not
>> stopped?) and how do I fix the issue?
>> Jim
>>
>> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>> Virus-free.www.avg.com
>> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>
>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
>
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
I have discovered a solution to this issue but I don't understand why.
The 'main()' of FT8_Receive contains lines related to sig_handler which were
included in the original file created by GNU Radio as shown below:
def main(top_block_cls=FT8_Receive, options=None):
tb = top_block_cls()
now = float(datetime.now().strftime('%S.%f'))
print ("RX main = ", now)
def sig_handler(sig=None, frame=None):
tb.stop()
tb.wait()
sys.exit(0)
signal.signal(signal.SIGINT, sig_handler)
signal.signal(signal.SIGTERM, sig_handler)
check_time(cycle)
print("\nReceiving...")
#Receiving = time.time()
#now = float(datetime.now().strftime('%S.%f'))
#print ("After Receiving = ", now)
tb.start()
#start = time.time()
#print ("start = ",start)
tb.wait()
In desperation I removed those lines to see what the effect would be. I am
no longer getting the resource busy error and the code is running as I
intended.
Why are those lines included and why did their removal fix the problem?
Jim
-----Original Message-----
From: Elmore Family
Sent: Monday, April 15, 2024 11:01 AM
To: GNURadio Discussion List ; Marcus Müller
Subject: Re: Audio source - device or resource busy error
Marcus,
The following is the config.conf file as modified per your request:
[audio_alsa]
audio_module = portaudio
default_input_device = portaudio
default_output_device = pulse
nperiods = 32
period_time = 0.010
verbose = false
Did I do this correctly?
I wasn't sure what to use for the Device Name so I tried portaudio - didn't
recognize it. Used default - it ran but produced exactly the same error as
pulse after 6 iterations.
Note for reference:
Prior to calling the FT8_Receive.main() as I do now I was using either
os.system or subprocess calls to call FT8_Receive. These did not result in
any audio errors but the time to start of execution (1.2 secs) is excessive
rendering the application unusable due to critical timing constraints.
Jim
-----Original Message-----
From: Marcus Müller
Sent: Monday, April 15, 2024 4:55 AM
To: Elmore Family ; GNURadio Discussion List
Subject: Re: Audio source - device or resource busy error
Hi Jim,
so, that's an interesting problem with your sound system. I don't see why it
*should* fail
at six created sources (my suspicion is that the non-deterministic
destruction of objects
that is inherent to Python means there's six parallel endpoints active, from
a perspective
of ALSA and pulseaudio).
Sadly, we don't have a test that covers this (yet?).
Maybe this is a problem specific to the way the ALSA source works.
Would be able to test the portaudio sink? For that, we'll have to force GNU
Radio to use
it (because it uses ALSA by default). You can do that by adding
[audio]
audio_module = portaudio
to your GNU Radio configuration, so to a file ending in .conf (e.g.,
audio.conf) in the
directory that `gnuradio-config-info --userprefsdir` shows.
Best regards,
Marcus
On 15.04.24 02:18, Elmore Family wrote:
> Marcus,
>
> I first tried:
> For ALSA users with audio trouble, follow this procedure ( which I
> followed):
>
> The result was the same.
>
> Then I selected pulse as the device name. it worked for 6 iterations of
> the loop and then gave the following error:
>
> mmap() failed: Cannot allocate memory
> mmap() failed: Cannot allocate memory
> gr::log :ERROR: audio_alsa_source6 - [pulse]: Input/output error
> Traceback (most recent call last):
> File "/home/pi/gr-ft8_rxtx/python/ft8_rxtx.py", line 337, in <module>
> main()
> File "/home/pi/gr-ft8_rxtx/python/ft8_rxtx.py", line 320, in main
> FT8_Receive.main()
> File "/home/pi/gr-ft8_rxtx/python/FT8_Receive.py", line 205, in main
> tb = top_block_cls()
> File "/home/pi/gr-ft8_rxtx/python/FT8_Receive.py", line 85, in __init__
> self.audio_source_0 = audio.source(samp_rate, 'pulse', True)
> RuntimeError: audio_alsa_source
>
> Jim
>
> -----Original Message----- From: Marcus Müller
> Sent: Sunday, April 14, 2024 3:45 PM
> To: discuss-gnuradio@gnu.org
> Subject: Re: Audio source - device or resource busy error
>
> Hi Jim,
>
> try not using the direct hardware device, but the device provided by your
> sound system;
> see the "for users wiht audio trouble" section on the Audio Source
> documentation page.
>
> Best regards,
> Marcus
>
> On 14.04.24 18:02, Elmore Family wrote:
>> I am getting the subject error when running a Python script called
>> repeatedly from another script.
>> The snippet_ft8_rxtx.py shows the call, FT8_Receive.main(), in the while
>> loop.
>> FT8_Receive.py shows the called script.
>> FT8_Receive.pdf is the flowgraph used to generate the called script which
>> as you can see has been modified in main() and with check_time added.
>> The first call to the script is OK but the second call results in the
>> error shown in audio_error.txt.
>> Why is the audio source busy when the flowgraph is stopped (or is it not
>> stopped?) and how do I fix the issue?
>> Jim
>>
>> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>> Virus-free.www.avg.com
>> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>
>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
>
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
Tuesday, April 23, 2024
Re: Debugging Existing C++ Blocks with VS Code & GDB
Hi Matt,
I'm not sure if this is an apples-to-apples situation, but your issue sounds exactly like something I've run into while abusing Python snippets.
It was easy to avoid after understanding order-of-events for block creation.
I suspect this is language-independent, and you can quickly create a python flowgraph / review the code - it will illustrate the principles:
1. Create a python flowgraph 'FOO.grc' with minimal blocks (e.g. [signal source] --> [throttle2] --> [null sink]).
2. Add four [Python Snippet] blocks - one for each type of [Section of Flowgraph] param: 'Init - Before Blocks', 'Main - After Start', etc.
3. For each Python Snippet block, add a one-line snippet distinct to the [Section of Flowgraph], for example:
print("Hello IAMA Init - Before Blocks")
# NOTE: it's important to have a least one line of code or nothing will be generated for the snippet!
4. Set the Title param of the [Options] block (top block) to "FOO".
5. Press [F5] to generate the flowgraph code, which will be called FOO.py (in same directory as FOO.grc).
6. Examine the resulting FOO.py script in VSCode - in particular, where each of the snippets are invoked.
The most obvious example is that in 'Init - Before Block' it's possible to reference a block or variable self.X before self.X has been instantiated.
More subtle cases are possible, depending on how clever one tries to be when using this mechanism.
- W
Attached: screencap of example error (take my word that the block 'radio' exists). I can send a shot of the flowgraph, but it probably wouldn't shed further light.
On Apr 23, 2024, at 13:46, Matt Clemons <mattclems11@gmail.com> wrote:Hello,I've walked through tutorials and successfully set breakpoints and debugged OOT modules in Gnu Radio using the DCMAKE_BUILD_TYPE=Debug option. However, I'm trying to debug local changes I've made to existing gnuradio/dtv/ files and not having success.I've followed the steps in a similar question/email chain here: https://lists.gnu.org/archive/html/discuss-gnuradio/2021-08/msg00008.html (I wasn't sure if replying to this old chain with a question or referencing it was better, let me know if there is a preference for future scenerios).I also tried recompiling all of the gnu radio source code on my machine with the DCMAKE_BUILD_TYPE=Debug option and still can not get VScode to stop on my set breakpoint within the dtv/dvbt_demod_reference_signals_impl.cc file. The flowchart runs, and completes but when I hover over the break point it just says "Module containing this breakpoint has not yet loaded or the address could not be obtained".Any suggestions? I don't like the option of copying this into an OOT module just to debug. I'm not sure I understand the difference either.Thanks,Matt
Debugging Existing C++ Blocks with VS Code & GDB
Hello,
I've walked through tutorials and successfully set breakpoints and debugged OOT modules in Gnu Radio using the DCMAKE_BUILD_TYPE=Debug option. However, I'm trying to debug local changes I've made to existing gnuradio/dtv/ files and not having success.
I've followed the steps in a similar question/email chain here: https://lists.gnu.org/archive/html/discuss-gnuradio/2021-08/msg00008.html (I wasn't sure if replying to this old chain with a question or referencing it was better, let me know if there is a preference for future scenerios).
I also tried recompiling all of the gnu radio source code on my machine with the DCMAKE_BUILD_TYPE=Debug option and still can not get VScode to stop on my set breakpoint within the dtv/dvbt_demod_reference_signals_impl.cc file. The flowchart runs, and completes but when I hover over the break point it just says "Module containing this breakpoint has not yet loaded or the address could not be obtained".
Any suggestions? I don't like the option of copying this into an OOT module just to debug. I'm not sure I understand the difference either.
Thanks,
Matt
Howto Tutorial: Python Module Not Found in Unit Testing
Hello,
Any suggestions?
I was working through some of the Gnu Radio tutorials to understand the python unit testing and I'm having an issue where the python module can't be found.
I'm following the tutorial here: https://wiki.gnuradio.org/index.php/OutOfTreeModules
When I run `make test` it fails and when I run `ctest -V` for more details it shows 'ModuleNotFoundError: No module named 'howto'.
I'm not savvy with the build process, but it seems this python module is not being built/installed for python correctly?
I followed the instructions here: https://wiki.gnuradio.org/index.php/ModuleNotFoundError , but I'm still getting the same error on the unit test.
I'm running GnuRadio 3.10.7.0
I'm running GnuRadio 3.10.7.0
Any suggestions?
Thanks,
Matt
Monday, April 22, 2024
Release v3.10.10.0
GNU Radio v3.10.10.0 is available (https://github.com/gnuradio/gnuradio/releases/tag/v3.10.10.0). There were just a few fixups since the RC. The Qt front end to GRC can be tested using gnuradio-companion --qt. Most things work, but this is still a work in progress.
Saturday, April 20, 2024
Re: Passing Tags or Additional Port Data to Change Parameters of Downstream Blocks
Hi Matt,
++props for Ron's example of PMT tagging in C++ :-)
Quick tip: as a person with strong/current Python skills and C++ expertise that's 20 years out-of-date, I've found that I can get "best results per unit time" by reading the C++ code/docs but coding my blocks and snippets in efficiently-written Python.
I've found that well-written Python doesn't introduce bottlenecks, and I can apply the time saved to high-level organization of flowgraphs that optimizes throughput and latency.
Getting acceptable performance in Python requires being comfortable with loop-free vector coding in numpy, as well as judicious use of itertools, functools, and other "straight-to-C" mechanisms.
A nice feature to be aware of is that GR sidesteps the Python GIL at a high level. This provides a level of efficiency unavailable in ordinary Python environments.
Hope this helps.
- W
Matt wrote:
(and earlier)> Thank you Ron! This does look like exactly what I need. ...
....> data called out in the spec. Implementing this in the c++ code is
> where I'm running into issues and where I'm looking for help/advice.
> I am fairly new to GnuRadio and C++ these modifications seem difficult
> to me, hoping someone with more experience in both could point me in
> the right direction.
----------
On Apr 19, 2024, at 08:13, Matt Clemons <mattclems11@gmail.com> wrote:Thank you Ron!
...
MattOn Thu, Apr 18, 2024 at 6:33 PM Ron Economos <w6rz@comcast.net> wrote:Matt,
Take a look at ...
https://github.com/drmpeg/gr-dvbs2
It implements exactly what you're talking about to achieve VCM (Variable
Coding and Modulation).
...
https://github.com/drmpeg/gr-dvbs2/blob/master/lib/bbheader_bb_impl.cc#L496
Then it's sent downstream and all the subsequent blocks use it for
configuration (and also pass it downstream to the next block).
Ron
On 4/18/24 09:39, Matt Clemons wrote:
> Hello,
>
> I've been using the dtv/dvbt blocks in GnuRadio Companion to decode
Friday, April 19, 2024
Re: Passing Tags or Additional Port Data to Change Parameters of Downstream Blocks
Thank you Ron! This does look like exactly what I need. I almost reached out to you directly, seeing all the DrMpeg commits related to gnuradio DTV blocks.
Thanks for your help and all the contributions you've made to the community.
Matt
On Thu, Apr 18, 2024 at 6:33 PM Ron Economos <w6rz@comcast.net> wrote:
Matt,
Take a look at my DVB-S2 OOT. This is a different version of the DVB-S2
transmitter that implements VCM (as opposed to the regular CCM version
included in GNU Radio).
https://github.com/drmpeg/gr-dvbs2
It implements exactly what you're talking about to achieve VCM (Variable
Coding and Modulation). In VCM, the coding and modulation parameters can
change on a frame by frame basis. To accomplish this, the parameters are
sent as stream tags.
To get you started, here's where the stream tag is first created. It bit
packs a 64-bit PMT with all the parameters.
https://github.com/drmpeg/gr-dvbs2/blob/master/lib/bbheader_bb_impl.cc#L496
Then it's sent downstream and all the subsequent blocks use it for
configuration (and also pass it downstream to the next block).
Ron
On 4/18/24 09:39, Matt Clemons wrote:
> Hello,
>
> I've been using the dtv/dvbt blocks in GnuRadio Companion to decode
> dvbt signal recordings. I noticed a lot of the blocks in the RX chain
> require the user to select the modulation parameters (Constellation,
> Hierarchy, Code Rate, etc.). My goal is to remove a lot of these user
> parameters with the use of Transmission Parameter Signals (TPS) data
> called out in the DVB-T spec. This would make the DVBT receiver more
> autonomous, and be better than brute forcing all the modulation
> settings until you get a recovered transport stream in the cases where
> you don't know the transmitter settings. This solution seems to be a
> worthwhile improvement to the current DVBT blocks by utilizing the TPS
> data called out in the spec. Implementing this in the c++ code is
> where I'm running into issues and where I'm looking for help/advice.
>
> In the DVB-T spec the Transmission Parameter Signals (TPS) data can be
> recovered which will tell you all the modulation parameters of the
> main signal. As long as you know the TX mode and Guard Time, you can
> configure the OFDM Symbol Acquisition block and the FFT block, which
> are the only 2 required blocks before the Demod Reference Signals
> (DRS) block. The DRS code already decodes the TPS data but is only
> looking at 2 of the total 68 bits to determine what the frame index
> is, and then clears the std::deque of TPS data.
>
> My goal is to use all of the TPS data and either pass it in a tag or
> pass through a new port so that all the remaining downstream blocks
> can get the modulation parameters from that data rather than a user.
> I've dug into the tags and the PMT types required to pass data, but I
> can't wrap my head around how I would configure the modulation
> parameters of the downstream blocks from the port or tag TPS data
> passed to it.
>
> For example, a lot of the DRS modulation parameters are not needed for
> the DRS block to work, and when you recover Constellation Type,
> Hierarchy Type, and Tx Mode you could then pass these parameters to
> the DVB-T Demap block instead of having to create the block with those
> parameters.
>
> If there are any examples of other blocks using tags or ports to
> change the functionality of another block, that would be useful. Since
> I am fairly new to GnuRadio and C++ these modifications seem difficult
> to me, hoping someone with more experience in both could point me in
> the right direction.
>
> thanks!
Re: DMR tier III trunking base station transceiver using GNU Radio as lower physical layer
One other important limitation I found and I forgot to mention.
At the start of the execution of the flowgraph, there is a phenomenon which I
interpret like this: before all downstream buffers are filled, there is no
constraint on the speed of execution of the work() function in the source
block, probably due to lack of back-pressure?
So this resulted in lots of timeslot samples created in a very short amount of
time (microseconds?) that push the initial latency to 10 seconds or more.
So I've constrained the execution of the work() function at the startup which
adds those 30 msec which are not caused by the flowgraph. Unfortunately I
could not figure out how to lift that limitation once back-pressure takes effect
(all downstream buffers are full).
I hope that makes sense.
Adrian
At the start of the execution of the flowgraph, there is a phenomenon which I
interpret like this: before all downstream buffers are filled, there is no
constraint on the speed of execution of the work() function in the source
block, probably due to lack of back-pressure?
So this resulted in lots of timeslot samples created in a very short amount of
time (microseconds?) that push the initial latency to 10 seconds or more.
So I've constrained the execution of the work() function at the startup which
adds those 30 msec which are not caused by the flowgraph. Unfortunately I
could not figure out how to lift that limitation once back-pressure takes effect
(all downstream buffers are full).
I hope that makes sense.
Adrian
Re: DMR tier III trunking base station transceiver using GNU Radio as lower physical layer
On Friday, 19 April 2024 14:43:44 EEST Marcus Müller wrote:
> Hi Adrian,
>
> that's definitely quite cool! Thanks for sharing it with us :)
>
> I gave it a quick skim, and it's a bit surprising how much latency you get;
> this might have to do with GNU Radio's buffer sizes. The growing latency on
> UHD does in fact worry me, but I think it would indeed need more
> investigation (the good news is that there's no space for the USRP to store
> that much signal for it to have that much latency on the hardware side, so
> this must be something on the host).
>
> Out of interest: how long are these timeslots?
>
Hi Marcus,
Thank you for your interest in this. I'm sure some improvements can be made to
the latency, based on previous experience with TDMA type transmissions.
One DMR timeslot is 30 msec long, including the start and end guard times.
That is quite a lot, certainly longer than TETRA or GSM.
It should translate to 7200 samples per timeslot at my final sample rate (240
ksps).
The latency figures I quoted (350 - 500 msec) are end-to-end, so this includes
two rounds of passing through ZeroMQ buffers (which for MMDVM algorithm reasons
need to be one full timeslot worth of samples), pseudo-TTY communication both
ways, and two IP hops (not necessary on the same LAN host).
I think the most meaningful figures here are experimentally determined burst
delays required in the PMT timestamps, which cover only the flowgraph + the
rest of the stack including USB transmission.
I found the USRP to generally require less added delay, 40 msec worked, but
not 100% reliable. The LimeSDR required 60 msec or more, with 100% reliability
achieved for both at 80 msec delay. The LimeSDR stays at 0 % FIFO fill rate all
the time, I'm not sure how to determine that number for gr-uhd.
Out of these numbers, 30 msec are not related to actual delay, it is a
requirement atm. in the source block to gather all timeslot samples and fill
with zeros the carriers which are not used.
So that leaves around 50 msec of actual latency for both types of devices.
I was hoping based on experiences with GSM (Osmocom and gr-gsm) to see a delay
of less than 5 to 10 msec per transmitted burst. I'm still trying to determine
what causes this delay, I even tried setting some custom buffer sizes,
unfortunately due to some legacy support required on my machines all the tests
were done with GNU Radio 3.8 so far, so I may be missing some later
optimizations.
Best,
Adrian
> Hi Adrian,
>
> that's definitely quite cool! Thanks for sharing it with us :)
>
> I gave it a quick skim, and it's a bit surprising how much latency you get;
> this might have to do with GNU Radio's buffer sizes. The growing latency on
> UHD does in fact worry me, but I think it would indeed need more
> investigation (the good news is that there's no space for the USRP to store
> that much signal for it to have that much latency on the hardware side, so
> this must be something on the host).
>
> Out of interest: how long are these timeslots?
>
Hi Marcus,
Thank you for your interest in this. I'm sure some improvements can be made to
the latency, based on previous experience with TDMA type transmissions.
One DMR timeslot is 30 msec long, including the start and end guard times.
That is quite a lot, certainly longer than TETRA or GSM.
It should translate to 7200 samples per timeslot at my final sample rate (240
ksps).
The latency figures I quoted (350 - 500 msec) are end-to-end, so this includes
two rounds of passing through ZeroMQ buffers (which for MMDVM algorithm reasons
need to be one full timeslot worth of samples), pseudo-TTY communication both
ways, and two IP hops (not necessary on the same LAN host).
I think the most meaningful figures here are experimentally determined burst
delays required in the PMT timestamps, which cover only the flowgraph + the
rest of the stack including USB transmission.
I found the USRP to generally require less added delay, 40 msec worked, but
not 100% reliable. The LimeSDR required 60 msec or more, with 100% reliability
achieved for both at 80 msec delay. The LimeSDR stays at 0 % FIFO fill rate all
the time, I'm not sure how to determine that number for gr-uhd.
Out of these numbers, 30 msec are not related to actual delay, it is a
requirement atm. in the source block to gather all timeslot samples and fill
with zeros the carriers which are not used.
So that leaves around 50 msec of actual latency for both types of devices.
I was hoping based on experiences with GSM (Osmocom and gr-gsm) to see a delay
of less than 5 to 10 msec per transmitted burst. I'm still trying to determine
what causes this delay, I even tried setting some custom buffer sizes,
unfortunately due to some legacy support required on my machines all the tests
were done with GNU Radio 3.8 so far, so I may be missing some later
optimizations.
Best,
Adrian
Re: DMR tier III trunking base station transceiver using GNU Radio as lower physical layer
Hi Adrian,
that's definitely quite cool! Thanks for sharing it with us :)
I gave it a quick skim, and it's a bit surprising how much latency you get; this might
have to do with GNU Radio's buffer sizes. The growing latency on UHD does in fact worry
me, but I think it would indeed need more investigation (the good news is that there's no
space for the USRP to store that much signal for it to have that much latency on the
hardware side, so this must be something on the host).
Out of interest: how long are these timeslots?
Best,
Marcus
On 17.04.24 17:50, Adrian Musceac wrote:
> Hello,
>
> I would like to share with you the following page containing details of a
> project to create a DMR tier III trunked radio base transceiver station
> (usable for amateur radio digital voice comms and experimentation) in software
> defined radio:
> http://qradiolink.org/DMR-tier-3-trunked-radio-BTS-software-defined-radio.html
>
> It involves GNU Radio since the lower physical layer, concerned with frequency
> modulation and demodulation, filtering, resampling, as well as frequency
> division and time division multiplexing are performed in GNU Radio C++
> flowgraphs and also using some custom blocks created for this purpose.
>
> I hope you find this interesting and on-topic for this list, and thanks for all
> the help received in the community discussion channels. Since it is likely the
> page and code may contain mistakes, I would welcome any corrections or
> additions.
>
> Best regards,
> Adrian YO8RZZ
>
>
>
that's definitely quite cool! Thanks for sharing it with us :)
I gave it a quick skim, and it's a bit surprising how much latency you get; this might
have to do with GNU Radio's buffer sizes. The growing latency on UHD does in fact worry
me, but I think it would indeed need more investigation (the good news is that there's no
space for the USRP to store that much signal for it to have that much latency on the
hardware side, so this must be something on the host).
Out of interest: how long are these timeslots?
Best,
Marcus
On 17.04.24 17:50, Adrian Musceac wrote:
> Hello,
>
> I would like to share with you the following page containing details of a
> project to create a DMR tier III trunked radio base transceiver station
> (usable for amateur radio digital voice comms and experimentation) in software
> defined radio:
> http://qradiolink.org/DMR-tier-3-trunked-radio-BTS-software-defined-radio.html
>
> It involves GNU Radio since the lower physical layer, concerned with frequency
> modulation and demodulation, filtering, resampling, as well as frequency
> division and time division multiplexing are performed in GNU Radio C++
> flowgraphs and also using some custom blocks created for this purpose.
>
> I hope you find this interesting and on-topic for this list, and thanks for all
> the help received in the community discussion channels. Since it is likely the
> page and code may contain mistakes, I would welcome any corrections or
> additions.
>
> Best regards,
> Adrian YO8RZZ
>
>
>
Announcing the 2024 European GNU Radio Days at FAIR, Darmstadt, Germany
The 2024 edition of the European GNU Radio Days will be held at the
international accelerator facility FAIR in Darmstadt, Germany's
'City of Science', from August 27 to 31, 2024:
https://events.gnuradio.org/event/23
The conference aims at fostering collaboration between users and
developers of the free and open-source GNU Radio framework by helping
scientific, academic, industrial and hobbyist alike to discuss the
latest developments.
Focus of the Conference:
This edition is centered on the release of GNU Radio 4.0, with
tutorials designed to train newcomers on the advancements of this
framework reboot. We invite contributions on various topics, including:
* Digital Communication
* Satellite communication and space vehicle attitude analysis
* RADAR and Base-Band Signal Processing
* Hardware Enhancements, RF Frontend, and Backend accelerators (i.e.
SIMD, GPU, etc.) Advanced Signal Processing and Control
* Synchronization of distributed coherent SDR frameworks
Special Features of the Workshop:
The workshop will offer both plenary talks and introductory tutorials,
and two parallel tracks highlighting hands-on sessions specifically
tailored for GNU Radio users and C++ developers. To ensure personalized
guidance and effective learning, tutorials will be conducted in small
groups (4-8 participants). Due to this format, space is limited --
register early to secure your spot!
Registration and Contributions:
Early registration is encouraged as spaces are limited. The
registration deadline is July 15, 2024. Submit your contribution
proposals directly through the conference website at
https://events.gnuradio.org/event/23/abstracts/#submit-abstract
using the https://www.gnuradio.org/grcon.tar.gz template.
Submissions must be made by June 14, 2024.
For detailed calls for contributions and more information, visit:
https://events.gnuradio.org/event/23
The registration fee is set at 100 euros, covering the conference
reception and supporting GNU Radio's Educational Fund. Student
discounts and fee waivers are available for individuals who otherwise
would not be able to attend. Please contact us at info@gnuradio.org to
request a discount on your attendance. Proceedings will be published on
https://pubs.gnuradio.org/.
We look forward to welcoming you to Darmstadt for an engaging and
productive week at the European GNU Radio Days 2024.
Your European GNU Radio Days Organising Committee
international accelerator facility FAIR in Darmstadt, Germany's
'City of Science', from August 27 to 31, 2024:
https://events.gnuradio.org/event/23
The conference aims at fostering collaboration between users and
developers of the free and open-source GNU Radio framework by helping
scientific, academic, industrial and hobbyist alike to discuss the
latest developments.
Focus of the Conference:
This edition is centered on the release of GNU Radio 4.0, with
tutorials designed to train newcomers on the advancements of this
framework reboot. We invite contributions on various topics, including:
* Digital Communication
* Satellite communication and space vehicle attitude analysis
* RADAR and Base-Band Signal Processing
* Hardware Enhancements, RF Frontend, and Backend accelerators (i.e.
SIMD, GPU, etc.) Advanced Signal Processing and Control
* Synchronization of distributed coherent SDR frameworks
Special Features of the Workshop:
The workshop will offer both plenary talks and introductory tutorials,
and two parallel tracks highlighting hands-on sessions specifically
tailored for GNU Radio users and C++ developers. To ensure personalized
guidance and effective learning, tutorials will be conducted in small
groups (4-8 participants). Due to this format, space is limited --
register early to secure your spot!
Registration and Contributions:
Early registration is encouraged as spaces are limited. The
registration deadline is July 15, 2024. Submit your contribution
proposals directly through the conference website at
https://events.gnuradio.org/event/23/abstracts/#submit-abstract
using the https://www.gnuradio.org/grcon.tar.gz template.
Submissions must be made by June 14, 2024.
For detailed calls for contributions and more information, visit:
https://events.gnuradio.org/event/23
The registration fee is set at 100 euros, covering the conference
reception and supporting GNU Radio's Educational Fund. Student
discounts and fee waivers are available for individuals who otherwise
would not be able to attend. Please contact us at info@gnuradio.org to
request a discount on your attendance. Proceedings will be published on
https://pubs.gnuradio.org/.
We look forward to welcoming you to Darmstadt for an engaging and
productive week at the European GNU Radio Days 2024.
Your European GNU Radio Days Organising Committee
Thursday, April 18, 2024
Re: Passing Tags or Additional Port Data to Change Parameters of Downstream Blocks
Matt,
Take a look at my DVB-S2 OOT. This is a different version of the DVB-S2
transmitter that implements VCM (as opposed to the regular CCM version
included in GNU Radio).
https://github.com/drmpeg/gr-dvbs2
It implements exactly what you're talking about to achieve VCM (Variable
Coding and Modulation). In VCM, the coding and modulation parameters can
change on a frame by frame basis. To accomplish this, the parameters are
sent as stream tags.
To get you started, here's where the stream tag is first created. It bit
packs a 64-bit PMT with all the parameters.
https://github.com/drmpeg/gr-dvbs2/blob/master/lib/bbheader_bb_impl.cc#L496
Then it's sent downstream and all the subsequent blocks use it for
configuration (and also pass it downstream to the next block).
Ron
On 4/18/24 09:39, Matt Clemons wrote:
> Hello,
>
> I've been using the dtv/dvbt blocks in GnuRadio Companion to decode
> dvbt signal recordings. I noticed a lot of the blocks in the RX chain
> require the user to select the modulation parameters (Constellation,
> Hierarchy, Code Rate, etc.). My goal is to remove a lot of these user
> parameters with the use of Transmission Parameter Signals (TPS) data
> called out in the DVB-T spec. This would make the DVBT receiver more
> autonomous, and be better than brute forcing all the modulation
> settings until you get a recovered transport stream in the cases where
> you don't know the transmitter settings. This solution seems to be a
> worthwhile improvement to the current DVBT blocks by utilizing the TPS
> data called out in the spec. Implementing this in the c++ code is
> where I'm running into issues and where I'm looking for help/advice.
>
> In the DVB-T spec the Transmission Parameter Signals (TPS) data can be
> recovered which will tell you all the modulation parameters of the
> main signal. As long as you know the TX mode and Guard Time, you can
> configure the OFDM Symbol Acquisition block and the FFT block, which
> are the only 2 required blocks before the Demod Reference Signals
> (DRS) block. The DRS code already decodes the TPS data but is only
> looking at 2 of the total 68 bits to determine what the frame index
> is, and then clears the std::deque of TPS data.
>
> My goal is to use all of the TPS data and either pass it in a tag or
> pass through a new port so that all the remaining downstream blocks
> can get the modulation parameters from that data rather than a user.
> I've dug into the tags and the PMT types required to pass data, but I
> can't wrap my head around how I would configure the modulation
> parameters of the downstream blocks from the port or tag TPS data
> passed to it.
>
> For example, a lot of the DRS modulation parameters are not needed for
> the DRS block to work, and when you recover Constellation Type,
> Hierarchy Type, and Tx Mode you could then pass these parameters to
> the DVB-T Demap block instead of having to create the block with those
> parameters.
>
> If there are any examples of other blocks using tags or ports to
> change the functionality of another block, that would be useful. Since
> I am fairly new to GnuRadio and C++ these modifications seem difficult
> to me, hoping someone with more experience in both could point me in
> the right direction.
>
> thanks!
Take a look at my DVB-S2 OOT. This is a different version of the DVB-S2
transmitter that implements VCM (as opposed to the regular CCM version
included in GNU Radio).
https://github.com/drmpeg/gr-dvbs2
It implements exactly what you're talking about to achieve VCM (Variable
Coding and Modulation). In VCM, the coding and modulation parameters can
change on a frame by frame basis. To accomplish this, the parameters are
sent as stream tags.
To get you started, here's where the stream tag is first created. It bit
packs a 64-bit PMT with all the parameters.
https://github.com/drmpeg/gr-dvbs2/blob/master/lib/bbheader_bb_impl.cc#L496
Then it's sent downstream and all the subsequent blocks use it for
configuration (and also pass it downstream to the next block).
Ron
On 4/18/24 09:39, Matt Clemons wrote:
> Hello,
>
> I've been using the dtv/dvbt blocks in GnuRadio Companion to decode
> dvbt signal recordings. I noticed a lot of the blocks in the RX chain
> require the user to select the modulation parameters (Constellation,
> Hierarchy, Code Rate, etc.). My goal is to remove a lot of these user
> parameters with the use of Transmission Parameter Signals (TPS) data
> called out in the DVB-T spec. This would make the DVBT receiver more
> autonomous, and be better than brute forcing all the modulation
> settings until you get a recovered transport stream in the cases where
> you don't know the transmitter settings. This solution seems to be a
> worthwhile improvement to the current DVBT blocks by utilizing the TPS
> data called out in the spec. Implementing this in the c++ code is
> where I'm running into issues and where I'm looking for help/advice.
>
> In the DVB-T spec the Transmission Parameter Signals (TPS) data can be
> recovered which will tell you all the modulation parameters of the
> main signal. As long as you know the TX mode and Guard Time, you can
> configure the OFDM Symbol Acquisition block and the FFT block, which
> are the only 2 required blocks before the Demod Reference Signals
> (DRS) block. The DRS code already decodes the TPS data but is only
> looking at 2 of the total 68 bits to determine what the frame index
> is, and then clears the std::deque of TPS data.
>
> My goal is to use all of the TPS data and either pass it in a tag or
> pass through a new port so that all the remaining downstream blocks
> can get the modulation parameters from that data rather than a user.
> I've dug into the tags and the PMT types required to pass data, but I
> can't wrap my head around how I would configure the modulation
> parameters of the downstream blocks from the port or tag TPS data
> passed to it.
>
> For example, a lot of the DRS modulation parameters are not needed for
> the DRS block to work, and when you recover Constellation Type,
> Hierarchy Type, and Tx Mode you could then pass these parameters to
> the DVB-T Demap block instead of having to create the block with those
> parameters.
>
> If there are any examples of other blocks using tags or ports to
> change the functionality of another block, that would be useful. Since
> I am fairly new to GnuRadio and C++ these modifications seem difficult
> to me, hoping someone with more experience in both could point me in
> the right direction.
>
> thanks!
Re: Passing Tags or Additional Port Data to Change Parameters of Downstream Blocks
Hi,
That's a great idea! You may take a look at several blocks that are already in GNU Radio and are configurable through messages. Signal Source comes to my mind. More "sophisticated" blocks also use messages for configuration. For instance, UHD USRP Source, or some blocks of our OOT module gr-tempest (e.g. fine sampling synchronization).
You should take a look at those, but it should be as "simple" as adding a setter method on the block for the parameter you want to change, and call it from the function that "listens" to messages.
Hope that helps.
best
Federico
El jue, 18 abr 2024 a las 13:40, Matt Clemons (<mattclems11@gmail.com>) escribió:
Hello,I've been using the dtv/dvbt blocks in GnuRadio Companion to decode dvbt signal recordings. I noticed a lot of the blocks in the RX chain require the user to select the modulation parameters (Constellation, Hierarchy, Code Rate, etc.). My goal is to remove a lot of these user parameters with the use of Transmission Parameter Signals (TPS) data called out in the DVB-T spec. This would make the DVBT receiver more autonomous, and be better than brute forcing all the modulation settings until you get a recovered transport stream in the cases where you don't know the transmitter settings. This solution seems to be a worthwhile improvement to the current DVBT blocks by utilizing the TPS data called out in the spec. Implementing this in the c++ code is where I'm running into issues and where I'm looking for help/advice.In the DVB-T spec the Transmission Parameter Signals (TPS) data can be recovered which will tell you all the modulation parameters of the main signal. As long as you know the TX mode and Guard Time, you can configure the OFDM Symbol Acquisition block and the FFT block, which are the only 2 required blocks before the Demod Reference Signals (DRS) block. The DRS code already decodes the TPS data but is only looking at 2 of the total 68 bits to determine what the frame index is, and then clears the std::deque of TPS data.My goal is to use all of the TPS data and either pass it in a tag or pass through a new port so that all the remaining downstream blocks can get the modulation parameters from that data rather than a user. I've dug into the tags and the PMT types required to pass data, but I can't wrap my head around how I would configure the modulation parameters of the downstream blocks from the port or tag TPS data passed to it.For example, a lot of the DRS modulation parameters are not needed for the DRS block to work, and when you recover Constellation Type, Hierarchy Type, and Tx Mode you could then pass these parameters to the DVB-T Demap block instead of having to create the block with those parameters.If there are any examples of other blocks using tags or ports to change the functionality of another block, that would be useful. Since I am fairly new to GnuRadio and C++ these modifications seem difficult to me, hoping someone with more experience in both could point me in the right direction.
thanks!
Passing Tags or Additional Port Data to Change Parameters of Downstream Blocks
Hello,
thanks!
I've been using the dtv/dvbt blocks in GnuRadio Companion to decode dvbt signal recordings. I noticed a lot of the blocks in the RX chain require the user to select the modulation parameters (Constellation, Hierarchy, Code Rate, etc.). My goal is to remove a lot of these user parameters with the use of Transmission Parameter Signals (TPS) data called out in the DVB-T spec. This would make the DVBT receiver more autonomous, and be better than brute forcing all the modulation settings until you get a recovered transport stream in the cases where you don't know the transmitter settings. This solution seems to be a worthwhile improvement to the current DVBT blocks by utilizing the TPS data called out in the spec. Implementing this in the c++ code is where I'm running into issues and where I'm looking for help/advice.
In the DVB-T spec the Transmission Parameter Signals (TPS) data can be recovered which will tell you all the modulation parameters of the main signal. As long as you know the TX mode and Guard Time, you can configure the OFDM Symbol Acquisition block and the FFT block, which are the only 2 required blocks before the Demod Reference Signals (DRS) block. The DRS code already decodes the TPS data but is only looking at 2 of the total 68 bits to determine what the frame index is, and then clears the std::deque of TPS data.
My goal is to use all of the TPS data and either pass it in a tag or pass through a new port so that all the remaining downstream blocks can get the modulation parameters from that data rather than a user. I've dug into the tags and the PMT types required to pass data, but I can't wrap my head around how I would configure the modulation parameters of the downstream blocks from the port or tag TPS data passed to it.
For example, a lot of the DRS modulation parameters are not needed for the DRS block to work, and when you recover Constellation Type, Hierarchy Type, and Tx Mode you could then pass these parameters to the DVB-T Demap block instead of having to create the block with those parameters.
If there are any examples of other blocks using tags or ports to change the functionality of another block, that would be useful. Since I am fairly new to GnuRadio and C++ these modifications seem difficult to me, hoping someone with more experience in both could point me in the right direction.
thanks!
Wednesday, April 17, 2024
DMR tier III trunking base station transceiver using GNU Radio as lower physical layer
Hello,
I would like to share with you the following page containing details of a
project to create a DMR tier III trunked radio base transceiver station
(usable for amateur radio digital voice comms and experimentation) in software
defined radio:
http://qradiolink.org/DMR-tier-3-trunked-radio-BTS-software-defined-radio.html
It involves GNU Radio since the lower physical layer, concerned with frequency
modulation and demodulation, filtering, resampling, as well as frequency
division and time division multiplexing are performed in GNU Radio C++
flowgraphs and also using some custom blocks created for this purpose.
I hope you find this interesting and on-topic for this list, and thanks for all
the help received in the community discussion channels. Since it is likely the
page and code may contain mistakes, I would welcome any corrections or
additions.
Best regards,
Adrian YO8RZZ
I would like to share with you the following page containing details of a
project to create a DMR tier III trunked radio base transceiver station
(usable for amateur radio digital voice comms and experimentation) in software
defined radio:
http://qradiolink.org/DMR-tier-3-trunked-radio-BTS-software-defined-radio.html
It involves GNU Radio since the lower physical layer, concerned with frequency
modulation and demodulation, filtering, resampling, as well as frequency
division and time division multiplexing are performed in GNU Radio C++
flowgraphs and also using some custom blocks created for this purpose.
I hope you find this interesting and on-topic for this list, and thanks for all
the help received in the community discussion channels. Since it is likely the
page and code may contain mistakes, I would welcome any corrections or
additions.
Best regards,
Adrian YO8RZZ
Tuesday, April 16, 2024
Re: Discuss-gnuradio Digest, Vol 258, Issue 10
Please do not reply to digest messages. It makes it really hard to keep conversations straight.
On Tue, Apr 16, 2024 at 1:56 AM Jiya Johnson <jiyajohnson10@gmail.com> wrote:
Hi Marcus Müller,Please find the attached file for your reference, I think this will work.On Sat, Apr 13, 2024 at 9:32 PM <discuss-gnuradio-request@gnu.org> wrote:Send Discuss-gnuradio mailing list submissions to
discuss-gnuradio@gnu.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
discuss-gnuradio-request@gnu.org
You can reach the person managing the list at
discuss-gnuradio-owner@gnu.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."
Today's Topics:
1. Re: Determining number of dropped samples from USRP Sink in
TX chain (walter)
2. Modulation and demodulation issues (Jiya Johnson)
3. Re: Modulation and demodulation issues (Marcus Müller)
----------------------------------------------------------------------
Message: 1
Date: Fri, 12 Apr 2024 15:42:41 -0700
From: walter <walter@hacktuary.ai>
To: Adrian Winter <Adrian.Winter@sintef.no>
Cc: "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org>
Subject: Re: Determining number of dropped samples from USRP Sink in
TX chain
Message-ID: <7926F395-F024-44DE-A6C5-E48B1799841A@hacktuary.ai>
Content-Type: text/plain; charset="utf-8"
Hi Adrian -
You wrote:
> I'm wondering if there is any possibility to programmatically check how long an underrun event in a flowgraph that uses a USRP sink lasted.
I believe the usrp/uhd attempts to treat each underrun as a one-sample event, and report accordingly. There's a cogent definition in the Ettus Driver Manual, see the section header "Underrun notes":
https://files.ettus.com/manual/page_general.html#:~:text=has space again.-,Underrun notes,mean the host machine can't keep up with the requested rates.,-Threading Notes <https://files.ettus.com/manual/page_general.html#:~:text=has%20space%20again.-,Underrun%20notes,mean%20the%20host%20machine%20can't%20keep%20up%20with%20the%20requested%20rates.,-Threading%20Notes>
If we define dt = 1/samp_rate ... then (ignoring buffering and queueing), one underrun event means:
1. the usrp started waiting for a sample from your program at time t=t0, but
2. no sample was provided after dt seconds had elapsed, and
3. at time t=t0+dt the usrp issued a timestamped message (asynchronously) about the event. SO ...
> I do get messages from the sink when and that an underrun happened, but I can't see if that was for 1 ms or 20 seconds.
NOTE: the 'event' is a point-in-time, rather than an interval of time. It takes place at a time t0 + 1/samp_rate as described above, and - although it's printed in a format that looks weird in trace output - you have all the info you need:
> > message_debug :warning: Message: (uhd_async_msg (channel . 0) (time_spec 1333 . 0.277859) (event_code underflow))
> > Umessage_debug :warning: Message: (uhd_async_msg (channel . 0) (time_spec 1333 . 0.280334) (event_code underflow))
What you're seeing above are two underruns being reported about 2ms apart ...
- the U on the second line is stderr - you'll always see one U for each underrrun (or a summary, depending on config)
- the Message:... is because you're routing the message output of the USRP to a Message Debug block.
- the time_spec_t object tuple(int, double) contains whole seconds (1333) and fractional seconds (0.280334) since the USRP 'started'.
- Rule of thumb re t=0: a B200/B210 finishes initializing (messages like '[INFO] [B200] Actually got clock rate 16.777216 MHz') at around (time_spec 2 , 0.1000).
What to do??
The event 'duration' of each underrun is 1/samp_rate, and those stamps should be accurate - time deltas to be computed between two time_spec_t objects.
You probably care most about the average time between events.
Pro tip: a better way to monitor those messages is to send them to a ZMQ Message Sink block and process them in a separate flowgraph or python script that subscribes or pulls the messages. You can then consume them as numbers at your leisure. This adds minimal blocking / backpressure to your flowgraph.
> Is there any way to query the USRP for further information on the event?
Yes there is:
1. You're already getting the 'cue' of when to look by subscribing to the message source.
2. To dig into the details, have a look at the 'answer to my own question' posted under this subject earlier this week:
Re: How to get UHD 'rx_time' / 'rx_freq' after 'tune'? (Python)
The post includes (poorly edited) code examples, I'm happy to answer questions (or to be corrected by those more knowledgeable :-)
Cheers,
W .--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20240412/0f1470a5/attachment.htm>
------------------------------
Message: 2
Date: Sat, 13 Apr 2024 14:23:50 +0530
From: Jiya Johnson <jiyajohnson10@gmail.com>
To: GNURadio Mailing List <discuss-gnuradio@gnu.org>
Subject: Modulation and demodulation issues
Message-ID:
<CANaw2Ut_zLA-siAErzb1xF78QTeoGRMeoSdXvaAdWwWo4H4gXQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Greetings everyone,
Done with BPSK,PM modulation with some doppler effects but not able to the
effective demodulation back with the gnuradio not able to trace back ASM
after decoding the data bits are completely different.
[image: image.png]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20240413/855bb935/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 168035 bytes
Desc: not available
URL: <https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20240413/855bb935/attachment.png>
------------------------------
Message: 3
Date: Sat, 13 Apr 2024 16:29:32 +0200
From: Marcus Müller <mmueller@gnuradio.org>
To: discuss-gnuradio@gnu.org
Subject: Re: Modulation and demodulation issues
Message-ID: <a02a33e4-e5a8-412a-9be0-e620a14d855f@gnuradio.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Jiya,
that image is too small. I can't read anything. You could use the "Screen Capture" Feature
of GRC to export an arbitrary zoomable PDF document.
Best regards,
Marcus
On 13.04.24 10:53, Jiya Johnson wrote:
> Greetings everyone,
> Done with BPSK,PM modulation with some doppler effects but not able to the effective
> demodulation back with the gnuradio not able to trace back ASM after decoding the data
> bits are completely different.
> image.png
>
------------------------------
Subject: Digest Footer
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------
End of Discuss-gnuradio Digest, Vol 258, Issue 10
*************************************************
Monday, April 15, 2024
Re: Discuss-gnuradio Digest, Vol 258, Issue 10
Hi Marcus Müller,
Please find the attached file for your reference, I think this will work.
On Sat, Apr 13, 2024 at 9:32 PM <discuss-gnuradio-request@gnu.org> wrote:
Send Discuss-gnuradio mailing list submissions to
discuss-gnuradio@gnu.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
discuss-gnuradio-request@gnu.org
You can reach the person managing the list at
discuss-gnuradio-owner@gnu.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."
Today's Topics:
1. Re: Determining number of dropped samples from USRP Sink in
TX chain (walter)
2. Modulation and demodulation issues (Jiya Johnson)
3. Re: Modulation and demodulation issues (Marcus Müller)
----------------------------------------------------------------------
Message: 1
Date: Fri, 12 Apr 2024 15:42:41 -0700
From: walter <walter@hacktuary.ai>
To: Adrian Winter <Adrian.Winter@sintef.no>
Cc: "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org>
Subject: Re: Determining number of dropped samples from USRP Sink in
TX chain
Message-ID: <7926F395-F024-44DE-A6C5-E48B1799841A@hacktuary.ai>
Content-Type: text/plain; charset="utf-8"
Hi Adrian -
You wrote:
> I'm wondering if there is any possibility to programmatically check how long an underrun event in a flowgraph that uses a USRP sink lasted.
I believe the usrp/uhd attempts to treat each underrun as a one-sample event, and report accordingly. There's a cogent definition in the Ettus Driver Manual, see the section header "Underrun notes":
https://files.ettus.com/manual/page_general.html#:~:text=has space again.-,Underrun notes,mean the host machine can't keep up with the requested rates.,-Threading Notes <https://files.ettus.com/manual/page_general.html#:~:text=has%20space%20again.-,Underrun%20notes,mean%20the%20host%20machine%20can't%20keep%20up%20with%20the%20requested%20rates.,-Threading%20Notes>
If we define dt = 1/samp_rate ... then (ignoring buffering and queueing), one underrun event means:
1. the usrp started waiting for a sample from your program at time t=t0, but
2. no sample was provided after dt seconds had elapsed, and
3. at time t=t0+dt the usrp issued a timestamped message (asynchronously) about the event. SO ...
> I do get messages from the sink when and that an underrun happened, but I can't see if that was for 1 ms or 20 seconds.
NOTE: the 'event' is a point-in-time, rather than an interval of time. It takes place at a time t0 + 1/samp_rate as described above, and - although it's printed in a format that looks weird in trace output - you have all the info you need:
> > message_debug :warning: Message: (uhd_async_msg (channel . 0) (time_spec 1333 . 0.277859) (event_code underflow))
> > Umessage_debug :warning: Message: (uhd_async_msg (channel . 0) (time_spec 1333 . 0.280334) (event_code underflow))
What you're seeing above are two underruns being reported about 2ms apart ...
- the U on the second line is stderr - you'll always see one U for each underrrun (or a summary, depending on config)
- the Message:... is because you're routing the message output of the USRP to a Message Debug block.
- the time_spec_t object tuple(int, double) contains whole seconds (1333) and fractional seconds (0.280334) since the USRP 'started'.
- Rule of thumb re t=0: a B200/B210 finishes initializing (messages like '[INFO] [B200] Actually got clock rate 16.777216 MHz') at around (time_spec 2 , 0.1000).
What to do??
The event 'duration' of each underrun is 1/samp_rate, and those stamps should be accurate - time deltas to be computed between two time_spec_t objects.
You probably care most about the average time between events.
Pro tip: a better way to monitor those messages is to send them to a ZMQ Message Sink block and process them in a separate flowgraph or python script that subscribes or pulls the messages. You can then consume them as numbers at your leisure. This adds minimal blocking / backpressure to your flowgraph.
> Is there any way to query the USRP for further information on the event?
Yes there is:
1. You're already getting the 'cue' of when to look by subscribing to the message source.
2. To dig into the details, have a look at the 'answer to my own question' posted under this subject earlier this week:
Re: How to get UHD 'rx_time' / 'rx_freq' after 'tune'? (Python)
The post includes (poorly edited) code examples, I'm happy to answer questions (or to be corrected by those more knowledgeable :-)
Cheers,
W .--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20240412/0f1470a5/attachment.htm>
------------------------------
Message: 2
Date: Sat, 13 Apr 2024 14:23:50 +0530
From: Jiya Johnson <jiyajohnson10@gmail.com>
To: GNURadio Mailing List <discuss-gnuradio@gnu.org>
Subject: Modulation and demodulation issues
Message-ID:
<CANaw2Ut_zLA-siAErzb1xF78QTeoGRMeoSdXvaAdWwWo4H4gXQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Greetings everyone,
Done with BPSK,PM modulation with some doppler effects but not able to the
effective demodulation back with the gnuradio not able to trace back ASM
after decoding the data bits are completely different.
[image: image.png]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20240413/855bb935/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 168035 bytes
Desc: not available
URL: <https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20240413/855bb935/attachment.png>
------------------------------
Message: 3
Date: Sat, 13 Apr 2024 16:29:32 +0200
From: Marcus Müller <mmueller@gnuradio.org>
To: discuss-gnuradio@gnu.org
Subject: Re: Modulation and demodulation issues
Message-ID: <a02a33e4-e5a8-412a-9be0-e620a14d855f@gnuradio.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Jiya,
that image is too small. I can't read anything. You could use the "Screen Capture" Feature
of GRC to export an arbitrary zoomable PDF document.
Best regards,
Marcus
On 13.04.24 10:53, Jiya Johnson wrote:
> Greetings everyone,
> Done with BPSK,PM modulation with some doppler effects but not able to the effective
> demodulation back with the gnuradio not able to trace back ASM after decoding the data
> bits are completely different.
> image.png
>
------------------------------
Subject: Digest Footer
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------
End of Discuss-gnuradio Digest, Vol 258, Issue 10
*************************************************
Subscribe to:
Posts (Atom)