Start_rx_streaming_at patch problems

Hi,

I’ve been using the latest git version of gnuradio and trying to get
Doug’s
start_rx_streaming_at patch (now merged with the git version) to work. I
don’t think there’s any support via gr-usrp2 so I’ve modified
usrp2_source_base (temporarily) to call start_rx_streaming_at(0,0,0)
(i’ve
tried using 1 as well as I’m not sure if the fpga starts at 0 or 1)
instead
of start_rx_streaming(0).

When I do this everything compiles and I can start a flowgraph,
unfortunately no samples ever seem to be outputted from the block.

I’ve been testing with the following flowgraph (and with usrp2_fft.py
etc
which shows the FFT window but no data)

usrp2.source_32fc() -> gr.file_sink(gr,sizeof_gr_complex,“output”)

The file remains empty.

The produced file is empty. (I’ve left running for a while in case the
timestamp was missed and also added sync_to/every_pps but the result is
the
same)

The USRP2 is using firmware compiled from the git sourcecode – looking
through the code I think using the incorrect firmware would just cause
the
start_rx_streaming_at command to act like the normal start_rx_streaming
command.

Has anyone got any ideas on what I might have missed?

Thanks in advance,

Tim

On Tue, Jan 12, 2010 at 01:07:33PM +0000, Tim P. wrote:

unfortunately no samples ever seem to be outputted from the block.
same)
Tim
You’re probably trying to start “In the past”. That is, your start_at
time has already passed (the clock starts ticking when the USRP2
powers up). I think we’d need to add a “get_current_time” command to
give you a clue as to when to start. You’d need to add a suitable
offset to the returned value to account for the time required to
process the previous reponse and start_at command.

Eric

Eric B. wrote:


Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

To expand on that a little bit, I’ve found that it works best if I call
sync_to_pps, wait a short interval (I’ve been calling nanosleep with at
least 1e6 nanoseconds - but usually just over one second), then call
start_rxstreaming_at(0, <desired # of samples, I just use
USRP2_MAX_RX_SAMPLES here - setting it to zero should have the same
effect>, ), where the fpga start time is
at least something greater than the nanosleep interval. However, the
real problem here is that you don’t have any idea how far into the
future the next 1PPS signal is going to arrive (i.e. it could be just
under one second into the future, or it could be essentially zero time
in the future), unless you have some way of getting the signal into the
host PC as well. So I typically sleep for just over a second, and set
my fpga start time to be something fairly large (i.e. greater than one
second), but not too large. I have found that if it’s too far into the
future, the command will ‘disappear’ from the command queue in the
USRP2. Perhaps a better solution will come along WRT synchronizing the
host PC and the USRP2, but in the meantime I’m able to get it to work
with this fairly hack-ish method.
As far as using it in gr-usrp2, I ended up writing my own custom source
block, which started out life as a copy of the
gr-usrp2/usrp2_source_32fc block.
Doug


Douglas G.
Code 5545
U.S. Naval Research Laboratory
Washington, DC 20375
(202) 767-9048
[email protected]

On Tue, Jan 12, 2010 at 05:07, Tim P. [email protected]
wrote:

I’ve been using the latest git version of gnuradio and trying to get Doug’s
start_rx_streaming_at patch (now merged with the git version) to work.
[…]
When I do this everything compiles and I can start a flowgraph,
unfortunately no samples ever seem to be outputted from the block.

There was a bug discovered in the merged patch that resulted in
symptoms similar to what you are describing. It has been fixed as of
git 165f4bc5.

Please let me know if this corrects your problem.

Johnathan

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs