Re: [Discuss-gnuradio] audio underrun when bad signal quality

[Marcus Müller]

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 rational resampler, your sampling rate is already 2MS/s
/ 4=500kS/s, but then you feed it to a Low Pass filter that you
calculate for 2MS/s; that means that in fact, you're cutting off all
signal above 25kHz instead of the 100kHz you specified. Probably even a
good thing, in your case :)
I love playing around with filters, so maybe it's something you want to
try later on, too: To optimize SNR, fire up gr_filter_design, and try to
build a filter that best selects your channel -- the only limit is your
CPU speed; at 2MS/s and with a decimation of 4, you can probably use a
lot more taps than your current filter has, so you can make the
transition between pass- and stopband much steeper.

Best regards,
Marcus

On 23.09.2015 11:24, Markus Heller wrote:
> 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 rtlsdr stick for a while and there were no audio
> underruns today. 
>
> Let me observe some more time and I will come back on this if I have new
> insights. 
>
> best73
> markus
>
> Am Dienstag, den 22.09.2015, 21:28 +0200 schrieb Markus Heller:
>> Hi Marcus,
>>
>> I have been reading from you more frequently on this list than you've
>> been reading from me :-)
>>
>> I have my setup in my office computer, so I will send the setup to this
>> list tomorrow.
>>
>> Thanks ahead!
>>
>> vy73
>> markus
>> dl8rds
>>
>> Am Dienstag, den 22.09.2015, 19:56 +0200 schrieb Marcus Müller:
>>> Hi Markus,
>>>
>>> nice to be hearing from you!
>>>
>>> I'm making assumptions about your RX flow graph here:
>>>
>>> osmocom source --> squelch of some sort --> FM demod/ AM demod of sorts
>>> --> Audio sink
>>>
>>> If the squelch is set to stop the flow of samples as long as there's not
>>> enough signal, then downstream, the audio sink doesn't get any samples,
>>> though it always needs the same amount of samples per second. Hence,
>>> Underflows.
>>>
>>> Hopefully, that explains the issues you're having; if not, please
>>> explain your receiver in a little more detail,
>>>
>>> Best regards,
>>> Marcus
>>>
>>> On 22.09.2015 18:34, Markus Heller wrote:
 Hi,

 playing around with my RTLSDR stick (RTL2832U / Rafael Micro R820T
 tuner) I observed that whenever the reception (signal quality) is bad, I
 am getting Audio Underruns and glitches in the accoustics. 

 How can that happen? I always thought the sample rate was constant? When
 designing the sketch I took good care that the sample rates were fine.
 Whenever I get good signal quality I have no underruns at all. 

 Thanks in advance,

 br
 markus


 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Function Probe and OOT Blocks

[David Halls]

?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 this fashion so that they are not fixed at runtime?


Regards,


David



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio installation script

[Mike Gilmer]

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%] Building CXX object
volk/apps/CMakeFiles/volk_profile.dir/volk_profile.cc.o
mc++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [volk/apps/CMakeFiles/volk_profile.dir/volk_profile.cc.o] Error 4
make[1]: *** [volk/apps/CMakeFiles/volk_profile.dir/all] Error 2
make: *** [all] Error 2
make failed
Exiting Gnu Radio build/install

The complete output is at http://pastebin.com/jpA005nP  <-- sorry
about the control chars- next time maybe!

Mike

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio installation script

[Mike Gilmer]

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
> number of parallel compilation threads or at least swap storage to
> successfully compile GNU radio. I recommend getting more RAM - that is
> always a good thing to have, especially if planning to do some buffer
> intense signal processing.
>
> Best regards,
> Marcus
>
> Am 23. September 2015 15:48:37 MESZ, schrieb Mike Gilmer
> :
>>
>> 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
>>  mc++: internal compiler error: Killed (program cc1plus)
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See  for instructions.
>> make[2]: *** [volk/apps/CMakeFiles/volk_profile.dir/volk_profile.cc.o]
>> Error 4
>> make[1]: *** [volk/apps/CMakeFiles/volk_profile.dir/all] Error 2
>> make: *** [all] Error 2
>> make failed
>> Exiting Gnu Radio build/install
>>
>> The complete output is at http://pastebin.com/jpA005nP  <--
>> sorry
>> about the control chars- next time maybe!
>>
>> Mike
>>
>> 
>>
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Function Probe and OOT Blocks

[Marcus Müller]

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, and has a message handler that 
updates the factor used internally for multiplication in a thread-safe manner.

Then, you'd write something that is a stream sink, I.e. only has an input for 
samples, but based on some condition, sporadically sends a message to the 
aforementioned block. That way, you get asynchronous cooperation in GNU radio. 
I'm on my phone, currently, but if you look for the "GNU radio guided 
tutorials", you'll find a section on message passing. In the GNU radio doxygen, 
you'll find a reference for the typical command syntax that GNU radio devs 
usually agree on using.

Best regards,
Marcus

Am 23. September 2015 13:12:20 MESZ, schrieb David Halls 
:
>?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 this fashion so that they are not fixed at
>runtime?
>
>
>Regards,
>
>
>David
>
>
>
>NOTE: The information in this email and any attachments may be
>confidential and/or legally privileged. This message may be read,
>copied and used only by the intended recipient. If you are not the
>intended recipient, please destroy this message, delete any copies held
>on your system and notify the sender immediately.
>
>Toshiba Research Europe Limited, registered in England and Wales
>(2519556). Registered Office 208 Cambridge Science Park, Milton Road,
>Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
>---
>This email has been scanned for email related threats and delivered
>safely by Mimecast.
> For more information please visit http://www.mimecast.com
>---
>
>
>
>
>___
>Discuss-gnuradio mailing list
>Discuss-gnuradio@gnu.org
>https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio installation script

[Marcus Müller]

"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 good thing 
to have, especially if planning to do some buffer intense signal processing.

Best regards,
Marcus

Am 23. September 2015 15:48:37 MESZ, schrieb Mike Gilmer 
:
>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%] Building CXX object
>volk/apps/CMakeFiles/volk_profile.dir/volk_profile.cc.o
>mc++: internal compiler error: Killed (program cc1plus)
>Please submit a full bug report,
>with preprocessed source if appropriate.
>See  for instructions.
>make[2]: *** [volk/apps/CMakeFiles/volk_profile.dir/volk_profile.cc.o]
>Error 4
>make[1]: *** [volk/apps/CMakeFiles/volk_profile.dir/all] Error 2
>make: *** [all] Error 2
>make failed
>Exiting Gnu Radio build/install
>
>The complete output is at http://pastebin.com/jpA005nP  <-- sorry
>about the control chars- next time maybe!
>
>Mike
>
>___
>Discuss-gnuradio mailing list
>Discuss-gnuradio@gnu.org
>https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Submitting OOT Module Questions

[Richard Bell]

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/Development#Contributing-to-GNU-Radio-FAQ

1) My first question relates to documentation. Up to now, I've added
documentation into my XML files as  tags. To use Doxygen, am I
correct to put them in the public *.h file? Is this the only place it
should go, or should I add it to the XML as well? I've never been able to
get my documentation to propagate through to the GRC block without putting
it into the XML, is this a sign of a problem?

2) If I understand the above link correctly, I should fork GNU Radio,
create a new branch which I might call Log_AGC, add my code to that branch
and then make a pull request. Am I misunderstanding anything?

3) As far as code style goes, should I avoid using

#define DEBUG
#ifdef DEBUG
std::cout << "Debug stuff" << "\n";
#endif

statements to hide debug code? That is what I currently do but I know it's
not prevalent in the source.

4) I currently have an Optimize option in the GRC block which picks between
the way you would write the block if you just used standard C++ statements
(not optimized) and if you use Volk (optimized). Using control ports to
compare the two, there is an improvement with volk. But I like that someone
looking into the block can see how not to do it and then how to do it. Good
for beginners jumping into GNU Radio.

Thanks,
Rich
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Submitting OOT Module Questions

[Marcus D. Leech]

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 :)



On Wed, Sep 23, 2015 at 1:54 PM Martin Braun > wrote:


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:
>

https://gnuradio.org/redmine/projects/gnuradio/wiki/Development#Contributing-to-GNU-Radio-FAQ
>
> 1) My first question relates to documentation. Up to now, I've added
> documentation into my XML files as  tags. To use
Doxygen, am
> I correct to put them in the public *.h file? Is this the only
place it
> should go, or should I add it to the XML as well? I've never
been able
> to get my documentation to propagate through to the GRC block
without
> putting it into the XML, is this a sign of a problem?

You should only need to put your docs in the Doxygen block.

> 2) If I understand the above link correctly, I should fork GNU
Radio,
> create a new branch which I might call Log_AGC, add my code to that
> branch and then make a pull request. Am I misunderstanding anything?

That's the way to go. See also
http://gnuradio.org/redmine/projects/gnuradio/wiki/Development

> 3) As far as code style goes, should I avoid using
>
> #define DEBUG
> #ifdef DEBUG
> std::cout << "Debug stuff" << "\n";
> #endif

Absolutely. Please use the logging interface. See also
http://gnuradio.org/doc/doxygen/page_logger.html
>
> statements to hide debug code? That is what I currently do but I
know
> it's not prevalent in the source.
>
> 4) I currently have an Optimize option in the GRC block which picks
> between the way you would write the block if you just used
standard C++
> statements (not optimized) and if you use Volk (optimized). Using
> control ports to compare the two, there is an improvement with
volk. But
> I like that someone looking into the block can see how not to do
it and
> then how to do it. Good for beginners jumping into GNU Radio.

That's noble, but for core GNU Radio stuff it's probably best if you
stick with the VOLK implementation.

M

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org 
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

--
Very Respectfully,

Dan CaJacob


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] host format versus device format

[Jason Matusiak]

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 no other options).

The way I understand things, the host format is basically the wire
connection between blocks.  So complex float32 is I/Q with 4B for each
in float format (so 8B per sample), and complex int16 is 2B on int for
I/Q (4B per sample).  Am I still OK?  If so, I am failing to understand
the device format option...

Although, all that said, as I look at a USRP Source block, it uses the
term "output type" (which is analogous to the host format) and a "wire
format" which I am guessing is the same as the "device format"  If that
is correct, that means I don't have any idea what that wire is doing (as
I would have mentally thought that the output type is the "wire").

I tried looking for some documentation on this but came up empty (though
I am sure it is out there somewhere).

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RFNoc and data rates

[Marcus D. Leech]

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 aren't that 
wide, even with doppler spreading.




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Submitting OOT Module Questions

[Tom Rondeau]

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
> following link:
>
> https://gnuradio.org/redmine/projects/gnuradio/wiki/Development#Contributing-to-GNU-Radio-FAQ
>
> 1) My first question relates to documentation. Up to now, I've added
> documentation into my XML files as  tags. To use Doxygen, am I
> correct to put them in the public *.h file? Is this the only place it
> should go, or should I add it to the XML as well? I've never been able to
> get my documentation to propagate through to the GRC block without putting
> it into the XML, is this a sign of a problem?
>

Hi Rich,

First, awesome! (And thanks for looking at that wiki page.)

Yes, Doxygen will pull only from the public .h file. That's what goes into
the manual. This information should also be scraped to produce the doc tab
in the GRC block's parameters dialog. I forget exactly when this happens,
but it's possible you might need to run cmake again. Or there's potentially
a problem with handling this in OOT modules. I'd work on getting this into
gr-analog in your own branch and see if it works ok there. It should, and
this would reduce you having to duplicate the docs -- which will mostly be
a problem if we ever want to change/update them.



> 2) If I understand the above link correctly, I should fork GNU Radio,
> create a new branch which I might call Log_AGC, add my code to that branch
> and then make a pull request. Am I misunderstanding anything?
>

Yep, that's it!



> 3) As far as code style goes, should I avoid using
>
> #define DEBUG
> #ifdef DEBUG
> std::cout << "Debug stuff" << "\n";
> #endif
>
> statements to hide debug code? That is what I currently do but I know it's
> not prevalent in the source.
>


Indeed, avoid that. We have the logging facilities to help with that:

http://gnuradio.org/doc/doxygen/page_logger.html

For pure debug stuff, use the d_debug_logger that all blocks have.
Something like:

GR_LOG_DEBUG(d_debug_logger, "Debug stuff");



> 4) I currently have an Optimize option in the GRC block which picks
> between the way you would write the block if you just used standard C++
> statements (not optimized) and if you use Volk (optimized). Using control
> ports to compare the two, there is an improvement with volk. But I like
> that someone looking into the block can see how not to do it and then how
> to do it. Good for beginners jumping into GNU Radio.
>
> Thanks,
> Rich
>

There is a trade-off here between readability and speed. Volk kernels are
fairly straight-forward, usually, in what they do, too, so I don't see this
as a huge barrier to readability.

Still, I like your thinking on this. What I'd recommend is to remove the
"Optimize" option and only have the volk-enabled version in the code. But
take the non-volk code as a comment to describe how the code operates on
that level.

Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RFNoc and data rates

[Simon Olvhammar]

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-wise and output this as as stream. For example a input of 
1000 FFT:s with 4096 channels will result in a output of 1 averaged FFT 
with 4096 channels. I dont think we would need a iir filter for this?


Regarding stream decimation block, if it makes one item out of n items 
then what kind of processing is performed on those items? A simple 
average sum(items)/numItems or something else? Maybe it's this block 
that i'm looking for.


Best regards
Simon



Den 2015-09-23 kl. 10:10, skrev Sylvain Munaut:

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 weak
signals.
The current average block might not have enough internal precision for
your needs and might need to be tweaked a bit.



Also wondering if a 8k channel FFT block might be expected in RFNoc
anytime soon?

Most of the blocks currently assume that 1 vector / fft size = 1
packet. And packets have to fit within the MTU, so with 4 bytes per
sc16 sample, that's 2048 which is the current limit. And I think even
the internal RFNoC fifos are sized with this MTU size in mind.

So for larger FFTs you'll need other mechanism to synchonize the FFT
boundaries, like the EOB flag.

Cheers,

   Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RFNoc and data rates

[Marcus D. Leech]

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 could do sum(FFT:s)/(Number of 
FFT:s) element-wise and output this as as stream. For example a input 
of 1000 FFT:s with 4096 channels will result in a output of 1 averaged 
FFT with 4096 channels. I dont think we would need a iir filter for this?


A single-pole IIR is often used as a cheap way to perform integration--I 
use them all the time in radio astronomy processing.


Regarding stream decimation block, if it makes one item out of n items 
then what kind of processing is performed on those items? A simple 
average sum(items)/numItems or something else? Maybe it's this block 
that i'm looking for.
It just keeps 1 in N of the samples/vectors that are presented to it, 
without further processing.  All this DSP stuff is modular, so that
  a single-pole-IIR block does *only* that--it doesn't then also 
decimate the resulting stream/vector to a lower sample rate.  So, you'd:


[Caveat: I'm not an RFNoC person (yet), but the flow described below can 
be mapped onto existing RFNoC blocks as far as I know]:


Radio-->FFT--->complex-to-mag>single-pole-IIR--->keep-one-in-N

The precision requirements come in when considering the single-pole-IIR 
filter, which has a feedback term, so imprecision can accumulate.
  However, if you "split the work" of long-term integration between the 
host and the FPGA, you can integrate over shorter periods in
  the FPGA, retaining precision, and then do bulk, long-term, 
integration on the host, and the host only has to process averaged FFT
  results at a *much, much* lower rate than the raw sample-rate would 
imply.   One would have to experiment with parameters to
  achieve the desired results, but with the bulk of your long-term 
integration happening on the host, you shouldn't need to worry
  that much about precision issues, I would think.The RFNoC block 
*implementation team* could perhaps comment.





Best regards
Simon



Den 2015-09-23 kl. 10:10, skrev Sylvain Munaut:

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 weak
signals.
The current average block might not have enough internal precision for
your needs and might need to be tweaked a bit.



Also wondering if a 8k channel FFT block might be expected in RFNoc
anytime soon?

Most of the blocks currently assume that 1 vector / fft size = 1
packet. And packets have to fit within the MTU, so with 4 bytes per
sc16 sample, that's 2048 which is the current limit. And I think even
the internal RFNoC fifos are sized with this MTU size in mind.

So for larger FFTs you'll need other mechanism to synchonize the FFT
boundaries, like the EOB flag.

Cheers,

   Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Submitting OOT Module Questions

[Tom Rondeau]

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 level of the GNU Radio repo? I'm not familiar enough
> with CMake and how it does its thing to think this through on my own.
>
> Rich
>


You need to copy your code into gr-analog and make sure that the cmake
files and swig files are also updated accordingly.

Tom




> On Wed, Sep 23, 2015 at 11:10 AM, Marcus D. Leech 
> wrote:
>
>> 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 :)
>>
>>
>>
>> On Wed, Sep 23, 2015 at 1:54 PM Martin Braun 
>> wrote:
>>
>>> 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:
>>> >
>>> https://gnuradio.org/redmine/projects/gnuradio/wiki/Development#Contributing-to-GNU-Radio-FAQ
>>> >
>>> > 1) My first question relates to documentation. Up to now, I've added
>>> > documentation into my XML files as  tags. To use Doxygen, am
>>> > I correct to put them in the public *.h file? Is this the only place it
>>> > should go, or should I add it to the XML as well? I've never been able
>>> > to get my documentation to propagate through to the GRC block without
>>> > putting it into the XML, is this a sign of a problem?
>>>
>>> You should only need to put your docs in the Doxygen block.
>>>
>>> > 2) If I understand the above link correctly, I should fork GNU Radio,
>>> > create a new branch which I might call Log_AGC, add my code to that
>>> > branch and then make a pull request. Am I misunderstanding anything?
>>>
>>> That's the way to go. See also
>>> http://gnuradio.org/redmine/projects/gnuradio/wiki/Development
>>>
>>> > 3) As far as code style goes, should I avoid using
>>> >
>>> > #define DEBUG
>>> > #ifdef DEBUG
>>> > std::cout << "Debug stuff" << "\n";
>>> > #endif
>>>
>>> Absolutely. Please use the logging interface. See also
>>> http://gnuradio.org/doc/doxygen/page_logger.html
>>> >
>>> > statements to hide debug code? That is what I currently do but I know
>>> > it's not prevalent in the source.
>>> >
>>> > 4) I currently have an Optimize option in the GRC block which picks
>>> > between the way you would write the block if you just used standard C++
>>> > statements (not optimized) and if you use Volk (optimized). Using
>>> > control ports to compare the two, there is an improvement with volk.
>>> But
>>> > I like that someone looking into the block can see how not to do it and
>>> > then how to do it. Good for beginners jumping into GNU Radio.
>>>
>>> That's noble, but for core GNU Radio stuff it's probably best if you
>>> stick with the VOLK implementation.
>>>
>>> M
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>> --
>> Very Respectfully,
>>
>> Dan CaJacob
>>
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Convert raw I/Q to dB

[Marcus Müller]

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,
configurable to transmit at the frequencies you want to calibrate, and
then a few measurement points to find the relationship between digital
number and analog voltage/power.

Best regards,
Marcus

On 23.09.2015 02:13, Mathias Ossit wrote:
> Hello, Everyone
>
>
> i am new to gnuradio and I am creating a block to "Convert raw I / Q
> to dBm" I have: USRP Source -> Stream_to_vector-> FFT-> Complex_to_MAg
> * 2-> NEW_BLOCK, so is the sequence ??
>
> Thanks,
>
>
> Mathias
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RFNoc and data rates

[Sylvain Munaut]

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 weak
signals.
The current average block might not have enough internal precision for
your needs and might need to be tweaked a bit.


>> Also wondering if a 8k channel FFT block might be expected in RFNoc
>> anytime soon?

Most of the blocks currently assume that 1 vector / fft size = 1
packet. And packets have to fit within the MTU, so with 4 bytes per
sc16 sample, that's 2048 which is the current limit. And I think even
the internal RFNoC fifos are sized with this MTU size in mind.

So for larger FFTs you'll need other mechanism to synchonize the FFT
boundaries, like the EOB flag.

Cheers,

  Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Submitting OOT Module Questions

[Martin Braun]

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:
> https://gnuradio.org/redmine/projects/gnuradio/wiki/Development#Contributing-to-GNU-Radio-FAQ
> 
> 1) My first question relates to documentation. Up to now, I've added
> documentation into my XML files as  tags. To use Doxygen, am
> I correct to put them in the public *.h file? Is this the only place it
> should go, or should I add it to the XML as well? I've never been able
> to get my documentation to propagate through to the GRC block without
> putting it into the XML, is this a sign of a problem?

You should only need to put your docs in the Doxygen block.

> 2) If I understand the above link correctly, I should fork GNU Radio,
> create a new branch which I might call Log_AGC, add my code to that
> branch and then make a pull request. Am I misunderstanding anything?

That's the way to go. See also
http://gnuradio.org/redmine/projects/gnuradio/wiki/Development

> 3) As far as code style goes, should I avoid using
> 
> #define DEBUG
> #ifdef DEBUG
> std::cout << "Debug stuff" << "\n";
> #endif

Absolutely. Please use the logging interface. See also
http://gnuradio.org/doc/doxygen/page_logger.html
> 
> statements to hide debug code? That is what I currently do but I know
> it's not prevalent in the source.
> 
> 4) I currently have an Optimize option in the GRC block which picks
> between the way you would write the block if you just used standard C++
> statements (not optimized) and if you use Volk (optimized). Using
> control ports to compare the two, there is an improvement with volk. But
> I like that someone looking into the block can see how not to do it and
> then how to do it. Good for beginners jumping into GNU Radio.

That's noble, but for core GNU Radio stuff it's probably best if you
stick with the VOLK implementation.

M

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Submitting OOT Module Questions

[Dan CaJacob]

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: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:
> >
> https://gnuradio.org/redmine/projects/gnuradio/wiki/Development#Contributing-to-GNU-Radio-FAQ
> >
> > 1) My first question relates to documentation. Up to now, I've added
> > documentation into my XML files as  tags. To use Doxygen, am
> > I correct to put them in the public *.h file? Is this the only place it
> > should go, or should I add it to the XML as well? I've never been able
> > to get my documentation to propagate through to the GRC block without
> > putting it into the XML, is this a sign of a problem?
>
> You should only need to put your docs in the Doxygen block.
>
> > 2) If I understand the above link correctly, I should fork GNU Radio,
> > create a new branch which I might call Log_AGC, add my code to that
> > branch and then make a pull request. Am I misunderstanding anything?
>
> That's the way to go. See also
> http://gnuradio.org/redmine/projects/gnuradio/wiki/Development
>
> > 3) As far as code style goes, should I avoid using
> >
> > #define DEBUG
> > #ifdef DEBUG
> > std::cout << "Debug stuff" << "\n";
> > #endif
>
> Absolutely. Please use the logging interface. See also
> http://gnuradio.org/doc/doxygen/page_logger.html
> >
> > statements to hide debug code? That is what I currently do but I know
> > it's not prevalent in the source.
> >
> > 4) I currently have an Optimize option in the GRC block which picks
> > between the way you would write the block if you just used standard C++
> > statements (not optimized) and if you use Volk (optimized). Using
> > control ports to compare the two, there is an improvement with volk. But
> > I like that someone looking into the block can see how not to do it and
> > then how to do it. Good for beginners jumping into GNU Radio.
>
> That's noble, but for core GNU Radio stuff it's probably best if you
> stick with the VOLK implementation.
>
> M
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

Dan CaJacob
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Submitting OOT Module Questions

[Richard Bell]

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 CMake and how it does its thing to think this through on my own.

Rich

On Wed, Sep 23, 2015 at 11:10 AM, Marcus D. Leech  wrote:

> 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 :)
>
>
>
> On Wed, Sep 23, 2015 at 1:54 PM Martin Braun 
> wrote:
>
>> 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:
>> >
>> https://gnuradio.org/redmine/projects/gnuradio/wiki/Development#Contributing-to-GNU-Radio-FAQ
>> >
>> > 1) My first question relates to documentation. Up to now, I've added
>> > documentation into my XML files as  tags. To use Doxygen, am
>> > I correct to put them in the public *.h file? Is this the only place it
>> > should go, or should I add it to the XML as well? I've never been able
>> > to get my documentation to propagate through to the GRC block without
>> > putting it into the XML, is this a sign of a problem?
>>
>> You should only need to put your docs in the Doxygen block.
>>
>> > 2) If I understand the above link correctly, I should fork GNU Radio,
>> > create a new branch which I might call Log_AGC, add my code to that
>> > branch and then make a pull request. Am I misunderstanding anything?
>>
>> That's the way to go. See also
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/Development
>>
>> > 3) As far as code style goes, should I avoid using
>> >
>> > #define DEBUG
>> > #ifdef DEBUG
>> > std::cout << "Debug stuff" << "\n";
>> > #endif
>>
>> Absolutely. Please use the logging interface. See also
>> http://gnuradio.org/doc/doxygen/page_logger.html
>> >
>> > statements to hide debug code? That is what I currently do but I know
>> > it's not prevalent in the source.
>> >
>> > 4) I currently have an Optimize option in the GRC block which picks
>> > between the way you would write the block if you just used standard C++
>> > statements (not optimized) and if you use Volk (optimized). Using
>> > control ports to compare the two, there is an improvement with volk. But
>> > I like that someone looking into the block can see how not to do it and
>> > then how to do it. Good for beginners jumping into GNU Radio.
>>
>> That's noble, but for core GNU Radio stuff it's probably best if you
>> stick with the VOLK implementation.
>>
>> M
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
> --
> Very Respectfully,
>
> Dan CaJacob
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Submitting OOT Module Questions

[Ron Economos]

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_swig.i

gr-dtv/include/gnuradio/dtv/CMakelists.txt

Actually, I forgot to update that last file. Pull request imminent.

Ron

On 09/23/2015 01:55 PM, Richard Bell wrote:
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 to do and see how close I am to understanding this:


1) I can copy and paste the source code, the qa code and example files 
over to corresponding gr-analog directories
2) I have to make changes to existing swig files in gr-analog, which 
amounts to copying the various lines from my OOT swig into the 
gr-analog swig
3) I don't know if I should be copying CMakeFile stuff or touching any 
of that by hand. I need guidance here.


Am I supposed to build this and confirm its merged correctly before I 
submit a pull request?


Rich

On Wed, Sep 23, 2015 at 12:06 PM, Tom Rondeau > wrote:


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 level of the GNU Radio repo? I'm not familiar enough with
CMake and how it does its thing to think this through on my own.

Rich



You need to copy your code into gr-analog and make sure that the
cmake files and swig files are also updated accordingly.

Tom


On Wed, Sep 23, 2015 at 11:10 AM, Marcus D. Leech
> wrote:

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 :)




On Wed, Sep 23, 2015 at 1:54 PM Martin Braun
>
wrote:

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:
>

https://gnuradio.org/redmine/projects/gnuradio/wiki/Development#Contributing-to-GNU-Radio-FAQ
>
> 1) My first question relates to documentation. Up
to now, I've added
> documentation into my XML files as 
tags. To use Doxygen, am
> I correct to put them in the public *.h file? Is
this the only place it
> should go, or should I add it to the XML as well?
I've never been able
> to get my documentation to propagate through to the
GRC block without
> putting it into the XML, is this a sign of a problem?

You should only need to put your docs in the Doxygen
block.

> 2) If I understand the above link correctly, I
should fork GNU Radio,
> create a new branch which I might call Log_AGC, add
my code to that
> branch and then make a pull request. Am I
misunderstanding anything?

That's the way to go. See also
http://gnuradio.org/redmine/projects/gnuradio/wiki/Development

> 3) As far as code style goes, should I avoid using
>
> #define DEBUG
> #ifdef DEBUG
> std::cout << "Debug stuff" << "\n";
> #endif

Absolutely. Please use the logging interface. See also
http://gnuradio.org/doc/doxygen/page_logger.html
>
> statements to hide debug code? That is what I
currently do but I know
> it's not prevalent in the source.
 

Re: [Discuss-gnuradio] RFNoc and data rates

[Marcus D. Leech]

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 something?

Simon
Since you're integrating prior to decimation here, there should be no 
loss of information.





Den 2015-09-23 kl. 21:40, skrev Marcus D. Leech:

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 aren't that 
wide, even with doppler spreading.




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RFNoc and data rates

[Simon Olvhammar]

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 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
Since you're integrating prior to decimation here, there should be no 
loss of information.





Den 2015-09-23 kl. 21:40, skrev Marcus D. Leech:

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 aren't that 
wide, even with doppler spreading.




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Submitting OOT Module Questions

[Richard Bell]

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
to do and see how close I am to understanding this:

1) I can copy and paste the source code, the qa code and example files over
to corresponding gr-analog directories
2) I have to make changes to existing swig files in gr-analog, which
amounts to copying the various lines from my OOT swig into the gr-analog
swig
3) I don't know if I should be copying CMakeFile stuff or touching any of
that by hand. I need guidance here.

Am I supposed to build this and confirm its merged correctly before I
submit a pull request?

Rich

On Wed, Sep 23, 2015 at 12:06 PM, Tom Rondeau  wrote:

> 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 level of the GNU Radio repo? I'm not familiar enough
>> with CMake and how it does its thing to think this through on my own.
>>
>> Rich
>>
>
>
> You need to copy your code into gr-analog and make sure that the cmake
> files and swig files are also updated accordingly.
>
> Tom
>
>
>
>
>> On Wed, Sep 23, 2015 at 11:10 AM, Marcus D. Leech 
>> wrote:
>>
>>> 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 :)
>>>
>>>
>>>
>>> On Wed, Sep 23, 2015 at 1:54 PM Martin Braun 
>>> wrote:
>>>
 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:
 >
 https://gnuradio.org/redmine/projects/gnuradio/wiki/Development#Contributing-to-GNU-Radio-FAQ
 >
 > 1) My first question relates to documentation. Up to now, I've added
 > documentation into my XML files as  tags. To use Doxygen,
 am
 > I correct to put them in the public *.h file? Is this the only place
 it
 > should go, or should I add it to the XML as well? I've never been able
 > to get my documentation to propagate through to the GRC block without
 > putting it into the XML, is this a sign of a problem?

 You should only need to put your docs in the Doxygen block.

 > 2) If I understand the above link correctly, I should fork GNU Radio,
 > create a new branch which I might call Log_AGC, add my code to that
 > branch and then make a pull request. Am I misunderstanding anything?

 That's the way to go. See also
 http://gnuradio.org/redmine/projects/gnuradio/wiki/Development

 > 3) As far as code style goes, should I avoid using
 >
 > #define DEBUG
 > #ifdef DEBUG
 > std::cout << "Debug stuff" << "\n";
 > #endif

 Absolutely. Please use the logging interface. See also
 http://gnuradio.org/doc/doxygen/page_logger.html
 >
 > statements to hide debug code? That is what I currently do but I know
 > it's not prevalent in the source.
 >
 > 4) I currently have an Optimize option in the GRC block which picks
 > between the way you would write the block if you just used standard
 C++
 > statements (not optimized) and if you use Volk (optimized). Using
 > control ports to compare the two, there is an improvement with volk.
 But
 > I like that someone looking into the block can see how not to do it
 and
 > then how to do it. Good for beginners jumping into GNU Radio.

 That's noble, but for core GNU Radio stuff it's probably best if you
 stick with the VOLK implementation.

 M

 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

>>> --
>>> Very Respectfully,
>>>
>>> Dan CaJacob
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing 
>>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>> 

[Discuss-gnuradio] Fractional resampler eats stream tags on changes on the "ratio" input

[Piotr Krysik]

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 offset
corrector (attached flowgraph screenshot).
Short description what is going on there:
-when message comes to ppm_in port of the block "Controlled const
source" changes value of constant at the output,
-when Controlled rotator observe this change on its input, it emits
stream tag,
-for changes of about +/-50ppm (and above) on the 'ratio' input of the
Fractional Resampler, tags coming from the Controlled rotator are not
going through.

Just by looking at the Fractional Resampler implementation
(https://github.com/gnuradio/gnuradio/blob/master/gr-filter/lib/fractional_resampler_cc_impl.cc#L104)
I'm not able to locate source of the problem.

I can implement minimal working example if needed.

Best Regards,
Piotr Krysik
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RFNoc and data rates

[Simon Olvhammar]

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, skrev Marcus D. Leech:

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 aren't that 
wide, even with doppler spreading.




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] audio underrun when bad signal quality

[Markus Heller]

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 rtlsdr stick for a while and there were no audio
underruns today. 

Let me observe some more time and I will come back on this if I have new
insights. 

best73
markus

Am Dienstag, den 22.09.2015, 21:28 +0200 schrieb Markus Heller:
> Hi Marcus,
> 
> I have been reading from you more frequently on this list than you've
> been reading from me :-)
> 
> I have my setup in my office computer, so I will send the setup to this
> list tomorrow.
> 
> Thanks ahead!
> 
> vy73
> markus
> dl8rds
> 
> Am Dienstag, den 22.09.2015, 19:56 +0200 schrieb Marcus Müller:
> > Hi Markus,
> > 
> > nice to be hearing from you!
> > 
> > I'm making assumptions about your RX flow graph here:
> > 
> > osmocom source --> squelch of some sort --> FM demod/ AM demod of sorts
> > --> Audio sink
> > 
> > If the squelch is set to stop the flow of samples as long as there's not
> > enough signal, then downstream, the audio sink doesn't get any samples,
> > though it always needs the same amount of samples per second. Hence,
> > Underflows.
> > 
> > Hopefully, that explains the issues you're having; if not, please
> > explain your receiver in a little more detail,
> > 
> > Best regards,
> > Marcus
> > 
> > On 22.09.2015 18:34, Markus Heller wrote:
> > > Hi,
> > >
> > > playing around with my RTLSDR stick (RTL2832U / Rafael Micro R820T
> > > tuner) I observed that whenever the reception (signal quality) is bad, I
> > > am getting Audio Underruns and glitches in the accoustics. 
> > >
> > > How can that happen? I always thought the sample rate was constant? When
> > > designing the sketch I took good care that the sample rates were fine.
> > > Whenever I get good signal quality I have no underruns at all. 
> > >
> > > Thanks in advance,
> > >
> > > br
> > > markus
> > >
> > >
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > 
> > 
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RFNoc and data rates

[Marcus D. Leech]

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 appropriately.


Let's say you're running the FFT input at full bandwidth--200Msps, and 
you have an FFT size of 2048.  That's 97.7e3 FFTs/second
  being produced in the FFT machinery in RFNoC, including the 
complex-to-mag part.  Run that through a single-pole-IIR filter with
  an alpha value of, let's say, 0.01 (or the integer/fixed-point 
equivalent).  Then set your 'N' in keep-one-in-N to be about 100. You'll get
  roughly 97.7e1 FFTs/second into your host instead of 97.7e3 
FFTs/second.  At those low rates, even a purely-Python-based secondary

  long-term integrator should be able to keep up just fine.




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 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
Since you're integrating prior to decimation here, there should be no 
loss of information.





Den 2015-09-23 kl. 21:40, skrev Marcus D. Leech:

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 aren't 
that wide, even with doppler spreading.




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio