discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] [EXTERNAL] Re: [USRP-users] B210 GPSDO Operation


From: Martin Braun
Subject: Re: [Discuss-gnuradio] [EXTERNAL] Re: [USRP-users] B210 GPSDO Operation
Date: Fri, 25 Jul 2014 11:32:43 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

Just to clarify,

are you saying that when you use sc16 as CPU format, you get overflows,
but for fc32, you don't? It seems that in both cases you were using sc16
as the wire format, which is what surprises me.

Martin



On 07/24/2014 09:49 PM, Knee, Peter A wrote:
> Hey Martin,
> 
> Thanks for pointing out the rx_timed_samples example to me...I was
> not aware that was there.  Interestingly the rx_timed_samples does
> work for me at the rate I would like to achieve (50 MHz).  I started
> looking at the differences in the way things were implemented in the
> two scripts and I noticed that the cpu argument in the stream args in
> the rx_timed_samples was hardcoded to fc32.  When I went ahead and
> used the float type in the rx_samples_to_file, it worked very well.
> 
> 
> Is there perhaps additional overhead in the conversion between cpu
> formats that may be causing overflows?
> 
> As our intended application involves writing data to a file, doing 50
> MHz with double precision is not an option.
> 
> Thanks, Peter
> 
> -----Original Message----- From: USRP-users
> [mailto:address@hidden On Behalf Of Martin Braun
> via USRP-users Sent: Thursday, July 24, 2014 3:25 AM To:
> address@hidden Subject: [EXTERNAL] Re: [USRP-users] B210
> GPSDO Operation
> 
> Peter,
> 
> does the rx_timed_samples.cpp example work?
> 
> Martin
> 
> On 07/24/2014 08:12 AM, Knee, Peter A via USRP-users wrote:
>> All,
>> 
>> I've run into an issue that I can't seem to resolve.  I'm currently
>>  using a B210 with the board-mounted GPSDO.  I have modified the 
>> rx_samples_to_file example script to start streaming sometime in
>> the future so that I can receive accurately timestamped data.
>> 
>> The problem that I have found is that when I issue a stream command
>> to start streaming continuously at some time in the future, I
>> receive an overflow very quickly for larger data rates.  When I
>> immediately start streaming data, I don't have this issue.  I have
>> been able to stream data at rates up to 50 MHz.
>> 
>> I have attached my modified script.  Can anyone provide any
>> assistance? Is this an issue on my end or is there something on the
>> backend that may be causing this?
>> 
>> Thanks in advance, Peter
>> 
>> Note:  When I run the script, I am just dumping the data.  The
>> command line where I receive an immediate overflow is shown below.
>> 
>> $ ./rx_samples_to_file --args="master_clock_rate=50e6" --rate=25e6 
>> --freq=425e6 --null
>> 
>> 
>> _______________________________________________ USRP-users mailing
>> list address@hidden 
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> 
> 
> 
> _______________________________________________ USRP-users mailing
> list address@hidden 
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 




reply via email to

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