Irregular sampling of input stream

GNU Radio
1

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

View this message in context:
http://old.nabble.com/Irregular-sampling-of-input-stream-tp26157717p26157717.html
Sent from the GnuRadio mailing list archive at Nabble.com.

2

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

View this message in context:
http://old.nabble.com/Irregular-sampling-of-input-stream-tp26157717p26228225.html
Sent from the GnuRadio mailing list archive at Nabble.com.

3

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.

specific with my questions.
on/off
between blocks or otherwise) like this?

pointers_to_similar_examples would all be appreciated.