[USRP-users] How to add gcc compile argument in Makefile for UHD CPP for E312?
Hi there, Good evening. I have a special need to embed python code in CPP for my E312 because I want to do some data processing and generate a waveform. In order to do so, must be included as header, however it requires changing the gcc compiler argument. Could someone point me in which file I can add the gcc arguments? The argument needed to be added should be something like below. Thank you in advance. gcc mycode.cpp -o mycode -lpython2.7 -lm -L/usr/lib/python2.7/config/ -I/usr/include/python2.7/ Best James ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] E310 filter settings and LO lock question
The sample stream is continuous.
Sent from my iPhone
> On Sep 16, 2019, at 9:38 AM, Skorstad,Jørn via USRP-users
> wrote:
>
> Many thanks for your answers. Do you know if the E310 will halt the data
> stream while changing filter/frequency, or do I need to take this into
> account in the software while changing frequencies?
>
>
> Jorn,
>
> regarding your other question, filter selection on the E310 is handled by
> UHD, internally.
>
> Cheers,
> Julian
>
>> On 15.09.19 20:54, Marcus D Leech via USRP-users wrote:
>> My recollection is that the AD9361 RF chip doesn’t have an external lock
>> indicator.
>>
>> Sent from my iPhone
>>
>>> On Sep 15, 2019, at 9:17 AM, Skorstad,Jørn via USRP-users
>>> wrote:
>>>
>>> Hi all,
>>>
>>>
>>>
>>> I am currently working on a project using a USRP E310 to output an FFT plot
>>> over a given frequency range (usually bigger than the possible sample
>>> rate). The program is written in C++ using the UHD library. Frequency range
>>> is achieved by changing the LO frequency regularly. The program seems to
>>> work, however I have two questions I can’t find the answer to in the UHD
>>> manual:
>>>
>>>
>>>
>>> The E310 has analog filters on the RX and TX ports. The documentation is a
>>> little short on how these filters are controlled. Are they selected
>>> automatically based on the LO frequency, or do they need to be manually
>>> selected? If so, how? And what would be the (estimated) changeover time
>>> between filters?
>>>
>>>
>>>
>>> LO lock – I tried to detect if LO is locked after a tune request using the
>>> UHD manual as a reference. If I include the following directly after a tune
>>> request nothing is printed:
>>>
>>> while (!usrp->get_rx_sensor("lo_locked").to_bool()) std::cout <<
>>> "PLL unlocked!" << std::endl;
>>>
>>>
>>>
>>> Is there some other way to detect LO lock?
>>>
>>>
>>>
>>> Regards,
>>>
>>> Jorn
>>>
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] E310 filter settings and LO lock question
Jorn,
while tuning, samples will continue to flow from the device to your host
(if your recv loop is running in a separate thread).
However, while UHD is processing your call to 'set_rx_freq' there will
be some transient behavior visible in the received samples.
Thus, you should probably discard all received samples while waiting for
'set_rx_freq' to finish.
The tuning process on the E310/B210 is actually relatively involved
(calibration wise). The front-end IC has to perform calibration of
several stages when changing frequency. Some of those calibration steps
only happen every 100 MHz which is why you will notice that some calls
to 'set_rx_freq' will take considerably longer than others.
While 'set_rx_freq' is blocking during this calibration process, there
are other parts in the front-end that might (depending on you input)
take some more time to settle (the DC offset and IQ imbalance
correction, for example).
So it's not a bad idea to give the device some extra time after
'set_rx_freq' is done before processing samples again.
Hope this helps. Let me know if you have any further questions.
Cheers,
Julian
On 16.09.19 15:38, Skorstad,Jørn via USRP-users wrote:
Many thanks for your answers. Do you know if the E310 will halt the data stream
while changing filter/frequency, or do I need to take this into account in the
software while changing frequencies?
Jorn,
regarding your other question, filter selection on the E310 is handled by UHD,
internally.
Cheers,
Julian
On 15.09.19 20:54, Marcus D Leech via USRP-users wrote:
My recollection is that the AD9361 RF chip doesn’t have an external lock
indicator.
Sent from my iPhone
On Sep 15, 2019, at 9:17 AM, Skorstad,Jørn via USRP-users
wrote:
Hi all,
I am currently working on a project using a USRP E310 to output an FFT plot
over a given frequency range (usually bigger than the possible sample rate).
The program is written in C++ using the UHD library. Frequency range is
achieved by changing the LO frequency regularly. The program seems to work,
however I have two questions I can’t find the answer to in the UHD manual:
The E310 has analog filters on the RX and TX ports. The documentation is a
little short on how these filters are controlled. Are they selected
automatically based on the LO frequency, or do they need to be manually
selected? If so, how? And what would be the (estimated) changeover time between
filters?
LO lock – I tried to detect if LO is locked after a tune request using the UHD
manual as a reference. If I include the following directly after a tune request
nothing is printed:
while (!usrp->get_rx_sensor("lo_locked").to_bool()) std::cout <<
"PLL unlocked!" << std::endl;
Is there some other way to detect LO lock?
Regards,
Jorn
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] E310 filter settings and LO lock question
Many thanks for your answers. Do you know if the E310 will halt the data stream
while changing filter/frequency, or do I need to take this into account in the
software while changing frequencies?
Jorn,
regarding your other question, filter selection on the E310 is handled by UHD,
internally.
Cheers,
Julian
On 15.09.19 20:54, Marcus D Leech via USRP-users wrote:
> My recollection is that the AD9361 RF chip doesn’t have an external lock
> indicator.
>
> Sent from my iPhone
>
>> On Sep 15, 2019, at 9:17 AM, Skorstad,Jørn via USRP-users
>> wrote:
>>
>> Hi all,
>>
>>
>>
>> I am currently working on a project using a USRP E310 to output an FFT plot
>> over a given frequency range (usually bigger than the possible sample rate).
>> The program is written in C++ using the UHD library. Frequency range is
>> achieved by changing the LO frequency regularly. The program seems to work,
>> however I have two questions I can’t find the answer to in the UHD manual:
>>
>>
>>
>> The E310 has analog filters on the RX and TX ports. The documentation is a
>> little short on how these filters are controlled. Are they selected
>> automatically based on the LO frequency, or do they need to be manually
>> selected? If so, how? And what would be the (estimated) changeover time
>> between filters?
>>
>>
>>
>> LO lock – I tried to detect if LO is locked after a tune request using the
>> UHD manual as a reference. If I include the following directly after a tune
>> request nothing is printed:
>>
>> while (!usrp->get_rx_sensor("lo_locked").to_bool()) std::cout <<
>> "PLL unlocked!" << std::endl;
>>
>>
>>
>> Is there some other way to detect LO lock?
>>
>>
>>
>> Regards,
>>
>> Jorn
>>
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] cannot load fpga to b205mini from wandboard
thanks a lot, I've used external usb hub supplied with external power and it works. thanks again, this was very helpful. On Sun, Sep 15, 2019 at 11:47 PM Philip Balister via USRP-users < usrp-users@lists.ettus.com> wrote: > On 9/15/19 11:38 AM, Marcus D Leech via USRP-users wrote: > > My guess is the Wandboard doesn’t supply enough power, so it’s getting > taken off the bus. > > > > Might need one of those Y cables to supply external power. > > Also a good guess, my pi thing has issues with the b205 also. > > Philip > > > > > Sent from my iPhone > > > >> On Sep 15, 2019, at 8:09 AM, Philip Balister via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> > >>> On 9/15/19 7:55 AM, Wael Ali via USRP-users wrote: > >>> Dear all, > >>> please help me with this issue, > >>> > >>> I've built a poky distro. with yocto project for wandboard and uhd > package > >>> is pre-installed. > >>> > >>> the problem is, when I tried to use "uhd_usrp_probe" with (three > different > >>> usrp 205mini) I faced the following error > >>> > >>> root@wandboard:~# uhd_usrp_probe > >>> linux; GNU C++ version 7.3.0; Boost_106600; UHD_003.010.002.000-release > >>> > >>> -- Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex... > >>> -- Detected Device: B205mini > >>> -- Loading FPGA image: /usr/share/uhd/images/usrp_b205mini_fpga.bin... > >>> 39%Error: EnvironmentError: IOError: load_fpga: cannot write bitstream > to > >>> FX3 (-4: LIBUSB_ERROR_CODE -4) > >> > >> A quick google suggest error -4 is No device, are you sure the USB is > >> working? Do you seen messages when you insert/remove the b205? What does > >> ls usb say? > >> > >> Philip > >> > >> > >> > >>> root@wandboard:~# uhd_usrp_probe > >>> linux; GNU C++ version 7.3.0; Boost_106600; UHD_003.010.002.000-release > >>> > >>> -- Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex... > >>> -- Detected Device: B205mini > >>> -- Loading FPGA image: /usr/share/uhd/images/usrp_b205mini_fpga.bin... > >>> 38%Error: EnvironmentError: IOError: load_fpga: cannot write bitstream > to > >>> FX3 (-4: LIBUSB_ERROR_CODE -4) > >>> root@wandboard:~# uhd_usrp_probe > >>> linux; GNU C++ version 7.3.0; Boost_106600; UHD_003.010.002.000-release > >>> > >>> -- Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex... > >>> -- Detected Device: B205mini > >>> -- Loading FPGA image: /usr/share/uhd/images/usrp_b205mini_fpga.bin... > >>> 38%Error: EnvironmentError: IOError: load_fpga: cannot write bitstream > to > >>> FX3 (-4: LIBUSB_ERROR_CODE -4) > >>> > >>> As you can see, uhd: 3.10.2 > >>> also, I faced the same problem after re-downloading fpga image from > ettus > >>> website > >>> > >>> thanks in advance > >>> > >>> > >>> ___ > >>> USRP-users mailing list > >>> USRP-users@lists.ettus.com > >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > >>> > >> > >> ___ > >> USRP-users mailing list > >> USRP-users@lists.ettus.com > >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > > ___ > > USRP-users mailing list > > USRP-users@lists.ettus.com > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
