Hi,
I've been working with N210 for a long time now with very successful story.
I recently buy an x300 with TwinRX and I try do run the demo examples (so I am
in the very
first stage of testing).
I compiled the uhd 3.010.003 with succes and I can pinf the X300 at ip
192.168.10.2.
I upload the f
yes, I have a /usr/share/uhd/rfnoc/blocks directory with several xml files.
matis
Le 23/03/2018 à 16:20, Marcus D. Leech via USRP-users a écrit :
> On 03/23/2018 10:32 AM, Matis Alun via USRP-users wrote:
>>
>> Hi,
>>
>> I've been working with N210 for a lo
. 2016 radio_x300.xml
-rw-r--r--. 1 root root 3432 2 nov. 2016 siggen.xml
-rw-r--r--. 1 root root 1170 2 nov. 2016 window.xml
Le 23/03/2018 à 17:18, Marcus D. Leech via USRP-users a écrit :
> On 03/23/2018 11:30 AM, Matis Alun via USRP-users wrote:
>>
>> yes, I have a /usr/
PM, Matis Alun via USRP-users wrote:
>>
>> yes of course:
>>
>> total 76
>> -rw-r--r--. 1 root root 1433 2 nov. 2016 addsub.xml
>> -rw-r--r--. 1 root root 363 2 nov. 2016 block.xml
>> -rw-r--r--. 1 root root 2944 2 nov. 2016 ddc_single.xml
>>
UHD uses RFNoC internally at all times since the 3.10.0.0 release.
> The XML files
> are needed for standard operation. It does not expose the full API or
> set of
> features unless the rfnoc-devel branch is used.
>
> Regards,
> Derek
>
&g
Hi,
The TwinRx frequency specifications is from 10MHz to 6GHz.
However, some tests shows that I can select the center frequency around 10 MHz
with a
sampling frequency of 25MHz
which allows to make some acquisitions in the HF band (3-30 MHz) with a very
good quality.
My question is: why the sp
yes, its seems that we loose several dBs but which can be widely compensated by
the
extremely large TwinRx gain range.
Le 24/03/2018 à 06:38, Marcus D. Leech via USRP-users a écrit :
> On 03/24/2018 12:41 AM, Matis Alun via USRP-users wrote:
>> Hi,
>>
>> The TwinRx freque
_Band
>
> Regards,
> Derek
>
> On Sat, Mar 24, 2018 at 6:15 AM, Matis Alun via USRP-users
> <mailto:usrp-users@lists.ettus.com>> wrote:
>
> yes, its seems that we loose several dBs but which can be widely
> compensated by the
> extremely large TwinRx g
Hi usrp users,
Using an older release of UHD, I was able to build 2 rx streams (in order to
process data of
each stream in a separate process) using this kind of code:
usrp->set_rx_subdev_spec((std::string)"A:0 A:1");
uhd::stream_args_t stream_args("sc16",wire_format);
stream_args.channels.push
Sorry, don't take account my last message on this subject.
I made an error constructing the subdev spec string.
Sorry and thanks.
Matis
--
Hi usrp users,
Using an older release of UHD, I was able to build 2 rx streams (in order to
process data of
each stream in a separate process) using this
Hi usrp users,
I experienced some problem using my X300 + TwinRx over 1 Gb/s link.
The following code example shows that after the iteration number 253, the
program stops
with the following traceback:
terminate called after throwing an instance of 'uhd::io_error'
what(): EnvironmentError: IO
Le 05/04/2018 à 16:29, Marcus D. Leech via USRP-users a écrit :
> On 04/05/2018 04:55 AM, Matis Alun via USRP-users wrote:
>>
>> Hi usrp users,
>>
>> I experienced some problem using my X300 + TwinRx over 1 Gb/s link.
>>
>> The following code example shows t
gging and pastebin the output?
>
> Jonathon
>
>
> On Fri, Apr 6, 2018, 4:28 PM Matis Alun via USRP-users
> <mailto:usrp-users@lists.ettus.com>> wrote:
>
> Le 05/04/2018 à 16:29, Marcus D. Leech via USRP-users a écrit :
>> On 04/05/2018 04:55 AM, Matis Alun
Hi everybody,
I saw that a /tmp/uhd.log is created when running a sampling program and it is
becoming
very large
if the program runs during a long time.
How can we disable the logging messages ?
I tried to set the environment variable UHD_LOG_LEVEL or the pre-processor
-DUHD_LOG_LEVEL
directive
Le 09/04/2018 à 23:20, Martin Braun via USRP-users a écrit :
> On 04/09/2018 07:35 AM, Matis Alun via USRP-users wrote:
>> Hi everybody,
>>
>> I saw that a /tmp/uhd.log is created when running a sampling program and it
>> is becoming
>> very large
>>
Le 11/04/2018 à 02:16, Martin Braun via USRP-users a écrit :
> On 04/09/2018 02:48 PM, Matis Alun via USRP-users wrote:
>> Le 09/04/2018 à 23:20, Martin Braun via USRP-users a écrit :
>>> On 04/09/2018 07:35 AM, Matis Alun via USRP-users wrote:
>>>> Hi everybod
Hi,
I remark that the "time_spec" passed to the "recv" method of an rx_streamer is
not in
exact relation
with the length of the received vectors. For example, when receiving buffers of
length
16384 at Fs=362319 Hz,
the buffer length should be equal to (16384+1)/362319=0.0452225 seconds, while
t
17 matches
Mail list logo
