[Top][All Lists]

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

Re: [Discuss-gnuradio] Packet Transmission

From: David Tisza
Subject: Re: [Discuss-gnuradio] Packet Transmission
Date: Sun, 03 May 2009 10:45:24 -0400
User-agent: Thunderbird (Windows/20090302)


William Sherman írta:

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

reply via email to

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