[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Start_rx_streaming_at patch problems
From: |
Eric Blossom |
Subject: |
Re: [Discuss-gnuradio] Start_rx_streaming_at patch problems |
Date: |
Tue, 12 Jan 2010 06:03:00 -0800 |
User-agent: |
Mutt/1.5.20 (2009-08-17) |
On Tue, Jan 12, 2010 at 01:07:33PM +0000, Tim Pearce wrote:
> 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
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