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: <david.tisz...@nd.edu>, <david.ti...@itk.ppke.hu>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
