In my applications, after the flow graph is initialized, I need to
dynamically control the receiving of the USRP samples, i.e, at time T1,
I
want the USRP to transfer the received samples to PC, while in T2, I do
not
allow the PC to receive these samples.
Stop receiving the unusing packets from USRP can save the traffic over
ethernet and decrease the demands of processing resource on host PC.
the gr_mute block seems only suppress the incoming packets to further
processing, but these unusing samples can still come into the flow
graph.
Also, the tb.run and tb.wait can be executed more than twice as wish,
but
it seems to be not so flexible. It would be good if there some commands
called to control the block of uhd.usrp_source to achieve such purpose?
processing, but these unusing samples can still come into the flow graph.
Also, the tb.run and tb.wait can be executed more than twice as wish, but
it seems to be not so flexible. It would be good if there some commands
called to control the block of uhd.usrp_source to achieve such purpose?
I had a post on this recently, wish I could find it in the archives…
So, the problem with stopping streaming is that the work function will
return zero and the scheduler marks the block as done.
I am testing this solution. But before I get the result, just want to
make
sure:
Does the stream command STREAM_MODE_STOP_CONTINUOUS stop the incoming
packets from the USRP to PC, or just stop the flow graph to receive the
packets from USRP while the packets are still coming into the PC thru
the
ethernet between USRP and PC?
I am testing this solution. But before I get the result, just want to make
sure:
Does the stream command STREAM_MODE_STOP_CONTINUOUS stop the incoming
packets from the USRP to PC, or just stop the flow graph to receive the
packets from USRP while the packets are still coming into the PC thru the
ethernet between USRP and PC?
Yup, the usrp->stop() calls STREAM_MODE_STOP_CONTINUOUS, which actually
stops the flow of packets from USRP to host.
-josh
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.