You can't just take code from the main UHD source tree and compile it
out of that tree; you need to build them with the whole UHD repo's
build infrastructure, otherwise your linker won't know where to take
the functionality from that the program is using.
Also, you normally wouldn't use an ancient
On 04/19/2019 02:37 PM, Rob Kossler wrote:
Not sure about uhd_fft. I know that with rx_samples_to_file, it
behaved fine until I added the timed commands. That's why I sent the
source code attachment so that the problem could be easily duplicated.
Rob
Doh! Sorry. I got distracted by the (cle
Not sure about uhd_fft. I know that with rx_samples_to_file, it behaved
fine until I added the timed commands. That's why I sent the source code
attachment so that the problem could be easily duplicated.
Rob
On Fri, Apr 19, 2019 at 1:15 PM Marcus D. Leech
wrote:
> On 04/19/2019 09:44 AM, Rob K
On 04/19/2019 12:49 AM, Koyel Das (Vehere) via USRP-users wrote:
Hi,
For receiving data using usrp, sweeping a frequency range, following
the code rx_multisamples.cpp, I am setting the frequency then doing
START_CONTINUOUS; after receiving I am doing STOP_CONTINUOUS. After
the code runs fo
On 04/19/2019 09:44 AM, Rob Kossler wrote:
I had started with a mid-January version of master and that's where I
noticed the issue.
I am using:
UHD_3.14.0.HEAD-0-gf6cacec8
With an X310, using a UBX-160 V1
I'm running with the default clock rate, and getting 25Msps, using a
10MHz lo offset.
I had started with a mid-January version of master and that's where I
noticed the issue.
On Thu, Apr 18, 2019 at 6:00 PM Marcus D. Leech
wrote:
> On 04/18/2019 05:09 PM, Rob Kossler wrote:
>
> OK, so what happens if you use a *positive* LO offset?
>>
>
> It moves in the opposite direction. A fe
