discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Best way (architecture) to perform frequency hopping in GRC


From: Lukas Haase
Subject: Re: Best way (architecture) to perform frequency hopping in GRC
Date: Thu, 19 Dec 2019 08:29:16 +0100

Hi,

I wanted to followup on my question from last week. Probably it is not easy to 
do this just with GRC blocks. Meanwhile created various custom blocks that use 
data streams, tags and messages. Yet, I am still not clear how one would 
implement reliable frequency hopping. In my case, TX+RX need to be hopped phase 
coherently based on X310+UBX. Is it best to create the control logic outside? 
Employing tags or messages? Would I encapsulate USRP Source+Sink somehow or 
will I have to write a custom module from scratch that directly interfaces with 
UHD?

For example, is there a relation between absolute samples in gnuradio and USRP 
time? This would allow to align timed commands precicely with a 
frequency-switch control signal in gnuradio.

Thanks,
Luke

PS: My current system uses the "Function Probe" block to generate the timed 
commands for "phase coherent" hopping. A custom block splits the received 
signal according to "rx_freq" tags. For each frequency, the data is processed 
and when a full loop has been hopped, the data is combined and a message is 
passed for further processing. Issue 1: The USRP generates spurious "rx_freq" 
tags that are unexpected. Issue 2: The received samples in each interval are 
different, owing to the fact that "Function Probe" is completely asynchronuous 
to the data flow. Issue 3: I have all kinds of reliability issues starting from 
strange phase and low-frequency offsets when using faster hopping rates (I am 
not talking fast but 10-100s of ms). I assume the troubles appear because 
that's not the right way to do it.







Hi,

I am wondering what is the best way to perform frequency hopping in gnuradio on 
an *architectural* level.

I have a frequency vector [ f1 , f2 , f3 ].
GRC should tune the TX to f1, f2, f3, f1, f2, ... and the RX to 2*f1, 2*f2, 
2*f3, 2*f1, 2*f2, ...
Denote the time interval for each frequency as Tf and a complete sweep as 
Tsweep=3*Tf with Tf = Tsettle + Tvalid.
During each Tvalid, the TX sends modulated data and waits for a modulated 
response.
After processing (filtering, clock recovery, decimation etc) the response 
consists of N (e.g. N=100) bits.
After each Tsweep, the three responses acquired for each frequency (i.e. 3x100 
bits) should be passed to the next block at a rate 1/Tsweep.

What is the best way to implement this in GRC reusing as many standard blocks 
from GRC as possible?

- Is it a good idea to use "Message Strobe" to generate a message to change 
frequency for the USRP Source/Sink blocks at a rate 1/Tf?
- Is it a better idea to change a python variable "center_freq"?
- What is the best way to update such a python variable?
- Is it a good idea to create Signal Source Saw Tooth and use "Probe Signal"?
- Is it a good idea to use the "lo_locked" sensor or just make "Tsettle" big 
enough? How to use "lo_locked" from within Gnuradio?
- What is the best way to combine the results for each frequency into one item 
that is passed at a rate 1/Tsweep?
- Is it a good idea to use "Stream to Vector"?
- How do I ensure that for each frequency, exactly the same number of output 
samples are generated?


Thanks,
Luke

PS: This sounds like something fairly trivial but 99% GRC examples are using a 
straight-forward data stream flow. I worked through the tutorials but they 
really only touch on this point briefly. Now I need to dynamically change the 
behavior of the signal flow over time while ensuring that everything stays 
time-aligned properly and to combine data from very different points in time 
into a single data point.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]