Irregular sampling of input stream

[David Knox]

I want to sample (aperiodically) a contiguous set of samples from the USRP based on subsequently analyzed data content of demodulated samples, processed at a packet level.  I have looked at the gr_squelch_base routine and/or the general_work routines for doing this.  

I am interested in storing and then examining with fine granularity signals that occur exactly before the beginning of the first received packet in a particular packet transmission.  I don't need to store too many samples beforehand, but I want to get all of them in that short window.

Any suggestions on existing code to review or for the best approach to take from a run-time perspective?  I don't want to miss samples from the hardware.  However, I need to do some higher-level processing (packet data extraction and so on) before I can tell which samples that I actually want to store permanently to disk.

I believe that I will need to have some high-level python or C++ code processing demodulated data and which then continues on to process the I/Q data samples that occured directly before a particular packet data was received (gathered by a low-level C++ routine).  I had considered creating sets of files in the lower level signal processing routines.  This would occur whenever signals were classified as being above noise thresholds in the squelch routine.  Then, the higher-level routine could process the files, erasing the extraneous ones to avoid the disk being filled up.  

Some experimentation showed that files got big quickly and that excessive processing delays were an issue too.  My approach relied on timestamps, but absolute time accuracy is not as important as associating the right set of samples with the right packet data.  Essentially, the problem is communicating state machines, where one machine is working much faster than the other and being told to latch data processed in recent history by the slower machine.  The gr_connectivity abstraction doesn't help me understand the scheduling/blocking nature of thread execution between the C++ routines.

The code in the general_work and gr_squelch_base routines refers to the input/output vectors as in[i]/out[i].  If I try to fprintf in[i] using %f or %d it complains of an illegal instruction and dies.  Therefore, these must be C++ pointers or classes ... or other..., right?   Can anyone give me example code (or point me to it) to print such values.  I am a C++ novice.

Are there routines to print the I/Q value of received USRP samples that I could use in gr_squelch_base.  Is there an equivalent of cfile.py written in C++?  Ideally, I'd like to pass pointers/references to record/array data structures from the lower-level to the higher-level routines, rather than using the file system as shared memory.

/ David Knox

[David Knox]

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

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


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@...
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio