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?
on 2009-05-03 11:12
on 2009-05-03 11:13
transmit_path as in from gnuradio-examples/transmit_path.py used in benchmark_tx.py.
on 2009-05-03 16:46
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: <David.Tisza.email@example.com>, <firstname.lastname@example.org>
on 2009-05-03 23:51
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?
on 2009-05-04 07:24
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.Tisza.email@example.com>, <firstname.lastname@example.org>
on 2009-05-04 21:18
David Tisza wrote: > You could, but how do you define your concept of a packet "had been > transmitted" ? This: > is it when your signal waveform's end is converted into electromagnetic > wave at the antenna >
on 2009-05-05 01:08
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...
on 2009-05-05 01:20
and how are you supposed to use these mblocks
on 2009-05-05 07:14
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.