[Top][All Lists]
[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