Hi,
>> My question is, is this possible using current RFnoc blocks?, with for
>> example an average block?
One thing worth considering is the internal precision.
I'm not familiar with the requirement for RA but I assume if you do a
lot of averaging it's to get rid of the noise and dig out very w
Hi Mathias,
you'll need a multiply_const somewhere in there -- the USRPs are by no
means calibrated, so, by itself, a specific digital amplitude doesn't
mean you have a specific voltage at the input of your daughterboard.
What you'll need to do is find an adjustable source of known power,
configur
Hi Marcus,
ok, here is the sketch:
http://www.dl8rds.de/index.php/Datei:2015-09-18-gnuradio_rtlsdr1.png
There is no squelch in the data path. But thanks a lot for explaining
the effects of a squelch.
Maybe there is another reason for my observation, because I unplugged my
antenna from the rtlsd
Hi Markus,
maybe just a CPU hiccup? You can try to reduce CPU load by removing the
decimating rational resampler, and integrate the decimation into the Low
Pass (it does the same thing, with one filter less).
By the way, there might be a slight mistake in your flow graph, as it is:
After the first
?Hi guys,
I am familiar with using function probes to update values to blocks. This is
straightforward with built in blocks like Multiply Const, where the input is
underline in the GRC dialogue box.
How do I create a block, specifically a Python block, that allows me to update
parameters in
Hi David,
For these cases, I typically recommend building an adjustable block that has a
message port input, and one or multiple blocks that have message port outputs.
You can, for example, write a multiply block that has one stream in-and one
steam output, and does register_message_port_in, an
I worked my way up though the email chain and ran some of the
"updates" suggested and reran the script
It has gotten further along than before, but still fails...
Scanning dependencies of target volk_profile
[ 5%] [32mBuilding CXX object
volk/apps/CMakeFiles/volk_profile.dir/volk_profile.cc.o
"Killed" in almost all cases means "killed by the out-of-memory watchdog of
your operating system". You'll still need more RAM, need to reduce the number
of parallel compilation threads or at least swap storage to successfully
compile GNU radio. I recommend getting more RAM - that is always a go
LOL... good thing I already ordered some and am getting RAM in the mail today!
Mike
On Wed, Sep 23, 2015 at 9:53 AM, Marcus Müller wrote:
> "Killed" in almost all cases means "killed by the out-of-memory watchdog of
> your operating system". You'll still need more RAM, need to reduce the
> numbe
Hey everyone,
I'm in the process of submitting my first OOT module for merge with GNU
Radio base. It's a log gain AGC which converges much faster then the
current AGCs when the input signal energy is low. I've read through the
following link:
https://gnuradio.org/redmine/projects/gnuradio/wiki/Dev
On Wed, Sep 23, 2015 at 1:39 PM, Richard Bell
wrote:
> Hey everyone,
>
> I'm in the process of submitting my first OOT module for merge with GNU
> Radio base. It's a log gain AGC which converges much faster then the
> current AGCs when the input signal energy is low. I've read through the
> follo
On 23.09.2015 10:39, Richard Bell wrote:
> Hey everyone,
>
> I'm in the process of submitting my first OOT module for merge with GNU
> Radio base. It's a log gain AGC which converges much faster then the
> current AGCs when the input signal energy is low. I've read through the
> following link:
>
I like keeping the algorithm logic in comments. I can't count how many
times I have optimized something, overwriting the original readable code,
then come back in a few months to discover I have no idea how it works
anymore.
On Wed, Sep 23, 2015 at 1:54 PM Martin Braun wrote:
> On 23.09.2015 10
On 09/23/2015 02:07 PM, Dan CaJacob wrote:
I like keeping the algorithm logic in comments. I can't count how
many times I have optimized something, overwriting the original
readable code, then come back in a few months to discover I have no
idea how it works anymore.
Months? Weeks for me :)
When merging my OOT module with the forked GNU Radio base, should I hand
copy the *.xml, *.h, *_impl.h, *_impl.cc, qa_*.cc and qa_*.h in the
appropriate gr-analog folder locations, or should I just dump my entire OOT
module into the top level of the GNU Radio repo? I'm not familiar enough
with CMak
For some reason I got myself wrapped around the axle with what is going
on with the host and device format options. For instance, if I look at
the RFNoC Radio block, it has a host format with the options: complex
float32, complex int16, and vita word32, and a device format of complex
int16 (with n
Hello,
Thank you for your answers.
Yes we do alot of averaging to expose the signal, in some applications
we even average over several months.
Could you elaborate on the internal precision that you mentioned?
We are looking for a simple block that could do sum(FFT:s)/(Number of
FFT:s) element-
On 09/23/2015 02:49 PM, Simon Olvhammar wrote:
Hello,
Thank you for your answers.
Yes we do alot of averaging to expose the signal, in some applications
we even average over several months.
Could you elaborate on the internal precision that you mentioned?
We are looking for a simple block that
On Wed, Sep 23, 2015 at 2:38 PM, Richard Bell
wrote:
> When merging my OOT module with the forked GNU Radio base, should I hand
> copy the *.xml, *.h, *_impl.h, *_impl.cc, qa_*.cc and qa_*.h in the
> appropriate gr-analog folder locations, or should I just dump my entire OOT
> module into the top
On 09/23/2015 03:06 PM, Marcus D. Leech wrote:
On 09/23/2015 02:49 PM, Simon Olvhammar wrote:
Hello,
Thank you for your answers.
Yes we do alot of averaging to expose the signal, in some
applications we even average over several months.
Are these astronomical spectral features? They usually a
Hi all,
Fractional resampler has additional "rate" signal input for supplying
resampling ratio for each input signal sample.
Changes of the signal on the "ratio" input might result in loss of tags
that are close in time to these changes.
I observed the problem when I was implementing frequency of
Hi Marcus,
No, we also have some spectrometers for atmospheric measurements.
Regarding the keep 1 in N. It occurs to me then that by using this I
would loose (N-1)/N percent of the FFT data for a given amount of
observation time? Or am I missing something?
Simon
Den 2015-09-23 kl. 21:40, skre
Sorry if these are obvious questions, but this is very not obvious to me.
As I understand it right now, it's not even a question of copy and pasting
files over to gr-analog, because that would overwrite the code for all the
other blocks, at least when it comes to swig. So let me outline what I need
You can take a look at my last gr-dtv commit. It's very similar to what
you need to do.
https://github.com/gnuradio/gnuradio/commit/b90c574e2fbf0443e1eea2ee06779c2a85f86def
Files to consider:
gr-dtv/grc/CMakeLists.txt
gr-dtv/grc/dtv_block_tree.xml
gr-dtv/lib/CMakeLists.txt
gr-dtv/swig/dtv_s
On 09/23/2015 04:19 PM, Simon Olvhammar wrote:
Hi Marcus,
No, we also have some spectrometers for atmospheric measurements.
Regarding the keep 1 in N. It occurs to me then that by using this I
would loose (N-1)/N percent of the FFT data for a given amount of
observation time? Or am I missing s
What would be a good choice for N in this case?
However, this seems very promising and I thank you for your help!
Cheers
Simon
On 09/23/2015 11:40 PM, Marcus D. Leech wrote:
On 09/23/2015 04:19 PM, Simon Olvhammar wrote:
Hi Marcus,
No, we also have some spectrometers for atmospheric measuremen
On 09/23/2015 06:13 PM, Simon Olvhammar wrote:
What would be a good choice for N in this case?
However, this seems very promising and I thank you for your help!
Cheers
Simon
Whatever rate you're comfortable receiving integrated FFTs at. You'd
adjust the 'alpha' value for the IIR filter and N ap
27 matches
Mail list logo
