Changing frequency dynamically in benchmark_rx.py

GNU Radio
1

Hi,

As far as I could understand, rx_callback function in benchmark_rx.py
executes only when a packet is received.
If the tranmitted freq is 460e6 while the reciever is set at 459e6, no
packet would be received. I want this ‘no packet being received for a
certain amount of time’ as an indication to set the frequency of the
receiver to another value; 460e6 in my case!
How and where in the code should I put this logic?

Looking for help!
Ali

2

On Thu, Jun 18, 2009 at 12:50 AM, ali siddiqi[email protected] wrote:

Looking for help!
Ali

The first thing that comes to mind is to use threads and a join with a
timeout or a condition with a wait or a timer object.
See: threading — Thread-based parallelism — Python 3.11.4 documentation

You would implement this in benchmark_rx.py.

Tom

3

On Thu, Jun 18, 2009 at 6:29 PM, Tom R. [email protected]
wrote:

The first thing that comes to mind is to use threads and a join with a
timeout or a condition with a wait or a timer object.
See: threading — Thread-based parallelism — Python 3.11.4 documentation

You would implement this in benchmark_rx.py.

Tom

But how would i come to know in the benchmark_rx.py whether the data is
being received or not.
As far as i see, this is being done at tb.wait

Thanks

4

On Sat, Jun 20, 2009 at 2:42 PM, ali siddiqi [email protected] wrote:

Tom

But how would i come to know in the benchmark_rx.py whether the data is
being received or not.
As far as i see, this is being done at tb.wait

Let me rephrase. When benchmark_rx.py is run, lets say initially there
is no
transmission being carried out, so benchmark_rx.py waits for
transmission. I
would like to know where is this happening in the code? tb.wait() is
called,
but i don’t see the code in wait() function which actually senses if a
transmission is being carried out on the specified frequence or not? Can
someone please help me locate the transmission sensing code in
benchmark_rx.py?

5

Jason U. wrote:

Jason

Yes.

In rx_path you will see the demod path. If you follow this down far
enough, you’ll come to the simple framer block. This pulls in bits and
correlates it against the known access code. If the correlation hits, it
then goes through and packs together the frame. When the frame is built
(it knows this because it gets the frame’s length after the access
code), it sends it as a message to the callback function defined. The
callback function is located in benchmark_rx.

Hope that gets you going.

Tom

6

would like to know where is this happening in the code? tb.wait() is called,
but i don’t see the code in wait() function which actually senses if a
transmission is being carried out on the specified frequence or not? Can
someone please help me locate the transmission sensing code in
benchmark_rx.py?

tb.wait() only allows the previously defined flowgraphs to do their
work. You need to look in the tx_path and rx_paths that are built
before tb.wait() is called

Jason

7

Hope that gets you going.

Tom

I tried to locate the simple framer, but not able to find it. Greping
for it
takes me to the c code of gr_simple_framer but I am not able to make
much
sense of it. Can you please elaborate a bit more…? Where does the
correlations takes place within the python code.

Regards,
Ali

8

I tried to locate the simple framer, but not able to find it. Greping for it
takes me to the c code of gr_simple_framer but I am not able to make much
sense of it. Can you please elaborate a bit more…? Where does the
correlations takes place within the python code.

The framer sink is a block implemented in C, which is why there is no
python code for it, the actual correlating happens in
gr_correlate_access_code (also implemented in C), they are connected
together to do the demodulating in pkt.py, which is modulation
independent.

(from:
http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-core/src/python/gnuradio/blks2impl/pkt.py)

141 self.correlator = gr.correlate_access_code_bb(access_code,
threshold)
142
143 self.framer_sink = gr.framer_sink_1(self._rcvd_pktq)
144 self.connect(self, self._demodulator, self.correlator,
self.framer_sink)

correlate_access_code takes a stream of bits from the demodulator and
tries to find the code prepended to each packet, when it does it sets
the second LSB (because each demodulated bit is in the LSB and the
other 7 are 0). The framer_sink_1 watches for this flag and blindly
collects the packet starting from that point.

If you want to get a better idea of what’s happening and understand C
you can look here:

http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-core/src/lib/general/gr_correlate_access_code_bb.cc

http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-core/src/lib/general/gr_framer_sink_1.cc

(Note that if you have an old version of the trunk checked out you
might be better off looking at those files in your local repository)

Jason