discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] tuning while acquiring data


From: Andrew Lutomirski
Subject: Re: [Discuss-gnuradio] tuning while acquiring data
Date: Sat, 9 May 2009 00:53:04 -0400

On Fri, May 8, 2009 at 9:28 PM, Eric Blossom <address@hidden> wrote:
> On Fri, May 08, 2009 at 03:43:34PM -0400, Andrew Lutomirski wrote:
>> Hi all-
>>
>> I'm trying to re-tune a daughterboard, while acquiring samples, and I
>> seem to get an overrun every time.  (This is in C++.)
>
>> Before I start investigating really hackish ways to make this work,
>> has anyone had any success getting this to work?
>
> I'm assuming this is on a USRP2.

Whoops, should've mentioned.  This is a USRP1.

>
> The current firmware stops the streaming, does the tune, and restarts
> streaming.  This produces a discontinuity of varying length, but
> doesn't underrun.
>
> Latest versions of the FPGA and firmware:
>
>  http://gnuradio.org/releases/usrp2-bin/trunk/txrx_edk10.1_r10925.bin
>  http://gnuradio.org/releases/usrp2-bin/trunk/u2_rev3_ise10.1sp3_r10766.bin
>
>
>> I don't actually care about the data I get while tuning, but I don't
>> want to lose track of the exact time, so I'd be happy with a way to
>> ask the USRP to pause for a specified number of samples, as well, or
>> even just to know how many samples I lost due to the overrun.

My current thought is to add a new FPGA register FR_SKIP_SAMPLES.
Writing a number N to that register would cause the next N samples
that would otherwise be written to USB to be skipped.  The sequence
would be:

1. Write 1000000 to FR_SKIP_SAMPLES.  (I suspect that just a few ms
worth of samples would be plenty.)
2. Tune the USRP.
3. Hope that tuning finishes before the full batch of samples have been skipped.

Alternatively, I could try to modify the firmware to do i2c
asynchronously, but that sounds a lot more painful.

--Andy




reply via email to

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