Re: [Discuss-gnuradio] Re: Packet Transmission

[David Tisza]

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: <address@hidden>, <address@hidden>