Hi,
My question is:
is there a way in gnuradio to know if transmit_path has finished
transmitting a packet?
I was just reading a thesis by Alice Crohas where she implements a
cognitive radio. Her transmitter uses transmit_path to transmit packets
in Gnuradio. A power detector is used to detect primary users. During
transmission she writes in her paper that she gets so her detector to
discard measurements for a period of time. If this period of time is too
low the transmitter could sometimes be transmitting, causes a false
sensing.
I think I’m misreading this.
If it were me I would just detect after finishing my transmission,
instead of waiting an unreliable time.
But is there a way in gnuradio to know if transmit_path has finished
transmitting a packet?
transmit_path as in from gnuradio-examples/transmit_path.py used in
benchmark_tx.py.
Hello,
William Sherman Ãrta:
Hi,
My question is:
is there a way in gnuradio to know if transmit_path has finished
transmitting a packet?
No, there is not. Generally even the concept of packet does not exist in
the general gnuradio workflow.
To help on this issue and many more, they started to develop m-blocks
(see http://gnuradio.org/trac/wiki/MessageBlocks )
If it were me I would just detect after finishing my transmission,
instead of waiting an unreliable time.
But is there a way in gnuradio to know if transmit_path has finished
transmitting a packet?
I haven’t read that paper, but I assume you suppose that you could know
“somehow” in your high level thread which assembles packets and gives
out the order to send them if the transmission is finished.
By itself there is no such feedback mechanism, but you could of course
generate one manually, but that’s a workaround. For example having a
block at the end of your chain eg, before the usrp and if you can detect
there what is a “packet end” you could use another message queue to
signal back to the python thread, but then you won’t be informed about
the true packet transmission end but the time when your packet left the
computer through the usb.
What happens normally for example in the benchmark is that the python
thread gives out the order to send this and that, and that function
which inserts that packet into the message queue returns afther the
insertion was successful, but at that point in time the packet is not
transmitted yet, but the python thread continues it’s run further as if
he had already got rid of his packet. You generally don’t know how long
will it take to get out from the rf.
Hope this answered your concern.
–
David Tisza
University of Notre Dame
Department of Electrical Engineering
e-mail: [email protected], [email protected]
William Sherman Ãrta:
Thinking through the problem: couldn’t you detect when the packet had
been transmitted by inserting a packet of ‘voltage 0’s’ after your real
packet into transmit_path’s flowgraph.
You could, but how do you define your concept of a packet “had been
transmitted” ?
Is it when it leaves the python thread where your packets are formed or
is it when a stream representing your packet (whatever it may be) leaves
a specific block and enters another block in the computer, or
when it leaves the computer through an interface (eg usb) or
is it when your signal waveform’s end is converted into electromagnetic
wave at the antenna or ???
And there are more efficient ways to determine where the packet started
and where it ended in a stream than just appending 0-s at the end, if
you still want to use the conventional streaming concept of the gnuradio
and not switch to mblocks. Eg. you could introduce a control flow where
you label every data sample with a state,(like packet start, packet end,
packet middle, sample does not belong to packet etc) and thus you could
determine packet ends and starts if you are consistent through your
flow, but with this method you have to do the correct synchronization
manually between the data and the control stream (eg when you use
decimators or interpolators or variable rate blocks).
And there are others as well.
But that does not solve your problem of not knowing when is the
transmission exactly happening at the RF frontend.
Then you could poll the msgq in
message_source until the queue is empty. Then you know your real packet
has been actually transmitted, while your “0 packet” could still be in
the process of transmitting (but as transmitting 0 voltage equivalent to
not transmitting). Thus you could perform sensing/receiving as soon as
the queue was empty.
Would this be the correct approach to solving the problem I had in the
original post?
I have the impression that you don’t exactly know how a message is
leaving from a message queue, and at a lower level how conventional
gnuradio blocks communicate and pass data to each other in their
streaming fashion, so I would encourage you to dig yourself into it by
for example examining the existing code and trying to debug a gnuradio
transmission from the benchmark and see how data flows through blocks
and how is it processed.
Because I think your approach could work as well but it seems to me it’s
too complicated for what you want to do and this is probably just coming
from a misunderstanding of how the gnuradio is managing it’s job in it’s
inside.
–
David Tisza
University of Notre Dame
Department of Electrical Engineering
e-mail: [email protected], [email protected]
Well that certainly makes things trickier.
Thinking through the problem: couldn’t you detect when the packet had
been transmitted by inserting a packet of ‘voltage 0’s’ after your real
packet into transmit_path’s flowgraph. Then you could poll the msgq in
message_source until the queue is empty. Then you know your real packet
has been actually transmitted, while your “0 packet” could still be in
the process of transmitting (but as transmitting 0 voltage equivalent to
not transmitting). Thus you could perform sensing/receiving as soon as
the queue was empty.
Would this be the correct approach to solving the problem I had in the
original post?
and how are you supposed to use these mblocks
The more I think about the more I think how impossible it is.
David Tisza wrote:
And there are more efficient ways to determine where the packet started
and where it ended in a stream than just appending 0-s at the end, if
you still want to use the conventional streaming concept of the gnuradio
and not switch to mblocks.
I had not realised mblocks were implemented yet? What is the status of
mblocks and can they be used in a cognitive radio testbed yet? Can
mblocks be used alongside a regular flowgraph performing sensing?
I guess I should be using the svn version of gnuradio…
Hmm:
I have a working program which has a USRP perform TX & RX on the one
radio, using transmit_path & receive_path. With two USRPs I can do
RTS/CTS and transmit a packet with ACK. My receive_path was not picking
up its own transmit_path’s packet transmissions erroneously. This was
even though both flowgraphs were running (in parallel) at the same time.
I only became aware of the problem that my RX should be picking up the
TX from the same radio after reading Crohas’s paper. My RX doesn’t pick
up my TX though (I never get “packet has wrong address” - I only
sometimes get bad packets due likely to noise interference).
I did have problems before when I didn’t have real time scheduling: in
that case my receiver was not able to receive anything.
So um what’s going on in gnuradio. According to Crohas my RX should be
picking up TX from my own radio, but it’s not. Does USRP only allow one
RX or TX operation at the same time or what? (I have tried with -R -T on
the same antenna, and -R -T on different antennaes). Or is it something
to do with scheduling???
I am very confused. My program is working but it shouldn’t be working
according to the literature. Is there good documentation in this area?
Are there other implementations of TX/RX on the same USRP? If so they
should have encountered the same problem of erroneous self-pickup, and
found some way to deal with it.