Hello G.s,
I am working on a cognitive radio application and I need to
dynamically reconfigure my receiver, switching between a detector and
the core receiver.
I found lock, unlock, connect, disconnect functions but it seems to be
almost impossible to find some documentation or a working examples to
understand how to use it.
I need to find a way to trigger the disconnect and connect. Do you
have any suggestions like some kind of callback?
Maybe you can point me to some example code. That would be nice.
Another question is: Is it possible to reconnect only parts of the
program in some hierarchical block or is it only possible from the top
block?
Anyway, I have attached a slightly modified dial_tone.py which runs
for 5 seconds, then replaces one tone with noise then runs for 5 more
seconds. As for how to trigger it, that depends entirely on the
context, but the reconf method can be called by timeout, user
interaction, external signal, …
As far as I know you can disconnect and reconnect at any level, and
even hier_block has lock and unlock methods, but I don’t know if it
makes sense to lock a flow graph anywhere else than at the top block
level.
In this document disconnect is not mentioned at all.
Your example and another example from the mailing list helped me to
understand how to basically use it.
In some post I found an example which shows that the system gets stuck
if you use lock/unlock in a hierarchical block.
see this: http://www.mail-archive.com/[email protected]/msg18108.html
“(The hang is a different bug that will be addressed soon.)” and that
was 2009 but for me the code still hangs.
So I am planning to create two hierarchical blocks and switch between
them at the top block layer.
The problem now is I have no idea how to trigger the reconfiguration
based on some “events” that occur in the hierarchical blocks.
I need to send a message/control signal to the top block to tell him
to lock and reconfigure but I don’t know how to do this.
This works well during testing. Once you get some kind of protocol or some
series of steps that you want to do, you can just test a flag, and whenever
your block finishes set it to true, then reconfigure.
What do you mean with “your block finishes” ? How do you implement this
flags?
I am now using a thread to implement the state machine.
I am using member variables in the C++ blocks to implement the flags
or to hand over certain signals/values to the control thread.
So you have to reach some state that makes you want to reconfigure, e.g.
you finished scanning some particular band or some time limit is
reached. Whenever you reach the point that you want to reconfigure, set
a flag, then check for the flag in your main application.
My typical program flow is
application
top block
hier block
So in the application level is where you want to test for a flag of some
kind. This is the simplest way that I know of. You can certainly do it
with threads, but that seems trickier.
Scott
Johannes S. wrote:
I am now using a thread to implement the state machine.
I am using member variables in the C++ blocks to implement the flags
or to hand over certain signals/values to the control thread.
Johannes
–
Scott Johnston
MIT Lincoln Laboratory
244 Wood Street, Lexington, MA 02420-9108
(781) 981-8196 [email protected]
Hi Johannes,
I think I have faced a similar problem like yours. I intend to implement
a dynamic spectrum access system: sensing on the rx side and transmit on
tx side.
I solved the problem in a dumb way: I start and stop rx and tx block
orderly in a while loop and use some global variables to store
parameters that needs to be changed. It works well in most of time, but
throw errors like “usrp2::samples() not receiving” in a few times.
I am interested in what you guys are discussing about, though something
of it seems pretty abstract and vague to me.
The way I do it is with infinite while loop, and a state machine. Once I
get to certain state, I lock the top-block and reconfigure it.
This works well during testing. Once you get some kind of protocol or
some series of steps that you want to do, you can just test a flag, and
whenever your block finishes set it to true, then reconfigure.
Scott
Johannes S. wrote:
Can anybody confirm this or tell me some other possibilities?
Oh, my problem is the same with yours: I want to change transmit
frequency according to the sensing result from rx side. I tried lock()
and unlock() but cannot work.
I solved it by creating 2 flow graphs for tx (to transmit files) and rx
(to sense the channel) sides separately and call start(), wait(), stop()
of theirs orderly.
This is a dumb solution (pretty dumb actually), but maybe it could your
reference, so I write this down to you.
Oh, my problem is the same with yours: I want to change transmit
frequency according to the sensing result from rx side. I tried lock()
and unlock() but cannot work.
You know that you can change frequency at any time, right? You don’t
have to lock the flowgraph to do
so. It’s a simple parameter change, not a flow-graph configuration
change. Reconfiguration in
the lock()/unlock() sense involves ripping blocks out of the graph and
installing new ones.
But simple parameter changes for an existing, running, graph don’t count
as “reconfiguration”.
Also, if I had this problem to cope with, I wouldn’t bother with any of
that fancy lock()/reconfigure/unlock()
stuff. I’d have my transmit chain, and my receive chain, and some
logic, and I’d simply arrange for my
transmit chain to transmit nothing while I was in the “explore the
spectrum” phase–either by sending 0s,
or using a “valve”.
–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
My mistake. I do change frequency while the transmit graph is running.
The real problem is the rx side (sensing) and tx (transmitting) side
cannot run in the same time (my rx and tx is realized with receive path
and transmit path in one top block). So I first run the rx to sense,
then stop it and start tx side to transmit with the sensing result.
I see you mention your rx and tx chains running at the same time, is it
possible?
Would you like to expand it in detail or refer me to some places I can
look for? Dose this need 2 antennas on 1 daughterboard? It would be
great if I can build a graph with rx path and tx path and run 2 paths
simultaneously.
Would you like to expand it in detail or refer me to some places I can
look for? Dose this need 2 antennas on 1 daughterboard? It would be
great if I can build a graph with rx path and tx path and run 2 paths
simultaneously.
Yes, you’ll need two antenna, and a daughtercard that supports
full-duplex (basically, any other
than the XCVR2450).
It’s easiest to create such a flow-graph using GRC initally, and then
perhaps modify it if necessary to
add your own logic, etc.
But there’s nothing inherent in Gnu Radio that says your flow-graph can
only be “all receive” or
“all transmit”. It’s willing to schedule both simultaneously.
As far as I know, the ATR logic (Automatic Transmit Receiver) in the
FPGA always switches the
RX-chain away from the TX/RX port when transmitting. What I’m not
sure of is whether sending
zeroes is enough to cause the ATR logic to go into “not transmitting”,
or whether you actually
have to interrupt the data flow.
Perhaps Josh can comment?
–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
Yea, you cannot send samples when you dont want to transmit. There isnt
really such a concept of that in GRC itself, but you certainly can
implement the blocks and control logic and connect them in grc. Someone
should make interesting use of those tagging features as well.
-Josh
Can they use a valve? Or would that create unpleasant consequences
downstream?
–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
Yea, you cannot send samples when you dont want to transmit. There isnt
really such a concept of that in GRC itself, but you certainly can
implement the blocks and control logic and connect them in grc. Someone
should make interesting use of those tagging features as well.
-Josh
So, a “hack” that could be put into UHD (or perhaps gr-uhd) is that if
we’ve sent N
consecutive blocks of zeros, we cancel the “burst”, and resume only
when we see
non-zeros. This is conceptually similar to the way analog T/R relays
that rely on
power-sensing work.
But yes, a cleaner mechanism would be if one could insert a “don’t
transmit this, I’m just keeping
the stream alive” tag in the TX datastream.
–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
Valve has an issue where it becomes a null sink rather than blocking
input it will absorb it at infinite rate. Thats something to keep in
mind. Obviously thats fine if your source is throttled. Patches are
welcome. There is also a block called copy that does basically what
valve does w/o disconnecting the fg.
