Re: [Discuss-gnuradio] Irregular sampling of input stream

[Mattias Kjellsson]

> I don't want to reconfigure the graph at run time, but I want to minimize
> the use of CPU on my parallel path.  Essentially, this extra path is 'raw'
> USRP samples which are really only required when packets are successfully
> received.
>  
>
> Otherwise, the main path is a classic digital radio one, moving from samples
> to symbols to bytes.  I just want to save time by not processing *all* of
> the raw samples all the time on the extra path.  Maybe this is not possible.
>   
One idea to do this would be to use a carrier- probe (look in
gnuradio-examples/python/digital/benshmark_rx.py), and look at it's
state. The probe is basically a power- threshold, so if you have a state
change from muted to unmuted, you may save the previous few buffers.
Have a look at the gr_message_*- classes...

I think you could do it with some sort of callback function, which looks
at the state of the probe and depending on the state drops the message
in the queue on the floor, or saves it to some other buffer, maybe puts
it in a message- source, which is connected to a file- sink or similar.

When I do testing I hook a file- sink to the output of every block in my
flow- graph. The files get very big very fast, but they should be
manageable if the measurement is "short".

Regarding real time/synchronization. There is a gnuradio real time
library, gruel, which is kind of useful, have you had a look at that? If
I remember correctly, the gruel- lib sets the priority to about 75% of
maximum priority.
> Hi,
>
> I was beginning to write an answer to your first mail, but something
> distracted me, and I suppose it never got sent.
>
> I'm still not exactly sure what you are asking, but from what I can
> recall, I was writing something about having a look at the
> gr_basic_block, gr_top_block and their likings.
>   
>> Not much of a response to my initial question, so I'll try to be more
>> specific with my questions.
>>
>> What is the best way to send a gated/non-continuous gnuradio signal stream
>> between signal processing blocks?  My main signal path is a 'standard'
>> digital radio demodulation process, where data travels through a cascaded
>> chain of processing blocks, being converted from samples to symbols and
>>     
> then
>   
>> to bytes.  However, I want to supplement this path with an auxilliary
>>     
> on/off
>   
>> gated stream of 'raw' USRP samples from the earliest block, which handles
>> samples, to one of the later ones in the chain, which handles bytes.  My
>> current approach is to create an extra output in the sample-processing C++
>> block and then hook it up (in Python) to the newly-created input of the
>> downstream C++ byte-processing block.  
>>
>> * Q1: Are there any scheduling/synchronization/real-time issues in gnuradio
>>     
>> with stopping and starting a gnuradio stream (using feedback signalling
>> between blocks or otherwise) like this?  
>>   - In my application, I need to ensure that the series of 'raw' samples is
>>     
>> the complete continuous set of samples that occured before a particular bit
>>     
>> was detected in the main demodulation path.
>>   
>>     
> With the assumption that you do not suffer from under- /over- runs, the
> samples should be in sequential order. Have a look at the implementation
> of the usrp_sink_x blocks...
>
> Regarding stopping and starting flow- graphs, do you want to reconfigure
> the flow- graph runtime? I'm not sure how much time it takes to do this,
> I have always assume it's time- consuming, since it requires you to
> pause the entire flow- graph, reconfigure and then start it again. (As I
> have come to understand this, others are welcome to correct me)
>
> I think there might be something similar in the "digital"- example
> folder, for receiving packets. There is a "carrier sense- probe", which
> _might_ do something like what you are trying to do. But since I'm not
> sure...
>
>   
>> * Q2: Should I avoid such signalling feedback and just throw away the
>> samples at the downstream bit-processing block (e.g. by selectively routing
>>     
>> to a sink or to a local data structure in the downstream processing block)
>> or is this too expensive for CPU processing time?
>> * Q3: Are there existing routines for timestamping samples/symbols/bits
>> accurately enough so that they can be accurately cross-referenced with each 
>> other?
>>
>> Answers/ suggestions/ warnings/ advice/ approaches/
>> pointers_to_similar_examples would all be appreciated.  

>> / David
>>