[USRP-users] how to know the number of losted samples when overflow occurs ?
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 the time spec difference between two successive calls to recv is 0.0483315 and sometimes 0.033402 (with a mean value equals to 0.0452225). My first idea was that the time_spec returned by the recv method was the time stamp of the first sample of the buffer, but I realize that it is false. Is it exact ? As a consequence, how can I know the number of losted samples when an overflow occurs ? thanks. matis ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] big uhd.log
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 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 >>>> without any effect. Should I recompile all the UHD library with this flag ? >>>> >>>> I am using actually UHD 3.010.003. >>> Matis, >>> >>> in order to enable file logging, you need UHD_LOG_FILE set. If you don't >>> have the environment variable UHD_LOG_FILE set, you shouldn't be seeing >>> a log file being generated. >> This is strange: I have no such environment variable. If I set it to another >> value (like >> /tmp/uhd2.log) -> uhd.log is created. >> No effects if I change UHD_LOG_LEVEL too. >> >> It seems that another layer defines these variable ... >> For your information, I run my system on Linux fedora 27 > How did you install UHD? > > -- M I installed UHD using make install from a fresh download and compilation.(UHD 3.010.003) > > ___ > 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] big uhd.log
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 >> 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 >> without any effect. Should I recompile all the UHD library with this flag ? >> >> I am using actually UHD 3.010.003. > Matis, > > in order to enable file logging, you need UHD_LOG_FILE set. If you don't > have the environment variable UHD_LOG_FILE set, you shouldn't be seeing > a log file being generated. This is strange: I have no such environment variable. If I set it to another value (like /tmp/uhd2.log) -> uhd.log is created. No effects if I change UHD_LOG_LEVEL too. It seems that another layer defines these variable ... For your information, I run my system on Linux fedora 27 Matis > > -- M > > ___ > 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] big uhd.log
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 without any effect. Should I recompile all the UHD library with this flag ? I am using actually UHD 3.010.003. Thanks, Matis ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] bug using rx_stream constructor inside a loop ...
Hi Jonathon,
It seems that the UHD_LOG_LEVEL environment variable has no effect on the
generated uhd.log.
Here are, as attached file, the last lines of my uhd.log before the traceback:
RuntimeError: EnvironmentError: IOError: [0/Radio_0] sr_write() failed:
EnvironmentError:
IOError: Block ctrl (CE_01_Port_40) no response packet - AssertionError:
bool(buff)
in uint64_t ctrl_iface_impl::wait_for_ack(bool)
at /uhd_3.10.3.0-release/lib/rfnoc/ctrl_iface.cpp:204
regards,
matis
Le 07/04/2018 à 14:13, Jon Pendlum a écrit :
> Hello Matis,
>
> Can you turn on full UHD logging and pastebin the output?
>
> Jonathon
>
>
> On Fri, Apr 6, 2018, 4:28 PM Matis Alun via USRP-users
> <usrp-users@lists.ettus.com
> <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 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 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: IOError: [0/Radio_0] sr_write() failed:
>>> EnvironmentError: IOError: Block ctrl (CE_01_Port_40) no response
>>> packet -
>>> AssertionError: bool(buff)
>>> in uint64_t ctrl_iface_impl::wait_for_ack(bool)
>>> at /uhd_3.10.3.0-release/lib/rfnoc/ctrl_iface.cpp:204
>>>
>>> I have good news: If I move the part of the code which construct the
>>> rx_stream,
>>> there is no errors.
>>>
>>> Is someone can explain me ? Is this an uhd bug or not ?
>>>
>>> Matis
>>>
>> This should be possible, but it seems awkward and unusual to do what
>> you're doing,
>> in the way that you're doing it.
>>
>>
>> You should:
>>
>> STREAM_MODE_START_CONTINUOUS
>>
>> read as much data as you want
>>
>> STREAM_MODE_STOP_CONTINUOUS
>>
>> That is, there's no reason to keep doing the start/stop on every
>> iteration, since
>> you aren't pausing, you're basically just continuous streaming in an
>> awkward and unusual way.
>>
>> Now, this shouldn't raise that exception, but the workaround is to
>> structure your
>> code without tightly looping on START/STOP.
> yes, you're right, but this was here a small example to show you the
> traceback. My
> application is more complicated and acts like a data
> server which answer to any acquisition request. So each request could be
> at another
> frequency. So I thought we have to STOP, change the frequency
> and START.
>
> However, the problem is not that the START/STOP is inside the loop. Which
> is causing
> the traceback is the instanciation of the rx_stream inside
> the loop. Of course, I can organize my code to avoid this but I thought
> that it was
> probably an UHD bug. This is the reason why I send this message
> (and also to help people who had the same kind of problem...).
>
> Regards,
>
> Matis
>>
>>
>>> bool test2() {
>>> std::string args="addr=192.168.10.2";
>>> uhd::usrp::multi_usrp::sptr usrp =
>>> uhd::usrp::multi_usrp::make(args);
>>>
>>> std::string subdev_spec="A:0";
>>> usrp->set_rx_subdev_spec(subdev_spec);
>>> usrp->set_rx_rate(25e6, 0);
>>> usrp->set_rx_freq(1240e6, 0);
>>> usrp->set_rx_gain(50.0, 0);
>>> usrp->set_rx_antenna("RX1", 0);
>>>
>>> while (true) {
>>> uhd::sensor_value_t lo_locked =
>>> usrp->get_rx_sensor("lo_locked",0);
>>> if (lo_locked.to_bool()) {
>>> break;
>>> }
>>> usleep(1);
>>> }
>>>
>>>
>>> for (int iteration=0; iteration<1000; iteration++) {
>>> // try this block outside the loop and every thing is ok
>>> uhd::stream_args_t stream_args("sc16", "sc16");
>>> stream_args.channels.push_back(0);
>>> uhd::rx_streamer::sptr rx_stream =
>>> usrp->get_rx_stream(stream_a
Re: [USRP-users] bug using rx_stream constructor inside a loop ...
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 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: IOError: [0/Radio_0] sr_write() failed:
>> EnvironmentError:
>> IOError: Block ctrl (CE_01_Port_40) no response packet - AssertionError:
>> bool(buff)
>> in uint64_t ctrl_iface_impl::wait_for_ack(bool)
>> at /uhd_3.10.3.0-release/lib/rfnoc/ctrl_iface.cpp:204
>>
>> I have good news: If I move the part of the code which construct the
>> rx_stream, there
>> is no errors.
>>
>> Is someone can explain me ? Is this an uhd bug or not ?
>>
>> Matis
>>
> This should be possible, but it seems awkward and unusual to do what you're
> doing, in
> the way that you're doing it.
>
>
> You should:
>
> STREAM_MODE_START_CONTINUOUS
>
> read as much data as you want
>
> STREAM_MODE_STOP_CONTINUOUS
>
> That is, there's no reason to keep doing the start/stop on every iteration,
> since you
> aren't pausing, you're basically just continuous streaming in an
> awkward and unusual way.
>
> Now, this shouldn't raise that exception, but the workaround is to structure
> your code
> without tightly looping on START/STOP.
yes, you're right, but this was here a small example to show you the traceback.
My
application is more complicated and acts like a data
server which answer to any acquisition request. So each request could be at
another
frequency. So I thought we have to STOP, change the frequency
and START.
However, the problem is not that the START/STOP is inside the loop. Which is
causing the
traceback is the instanciation of the rx_stream inside
the loop. Of course, I can organize my code to avoid this but I thought that it
was
probably an UHD bug. This is the reason why I send this message
(and also to help people who had the same kind of problem...).
Regards,
Matis
>
>
>> bool test2() {
>> std::string args="addr=192.168.10.2";
>> uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);
>>
>> std::string subdev_spec="A:0";
>> usrp->set_rx_subdev_spec(subdev_spec);
>> usrp->set_rx_rate(25e6, 0);
>> usrp->set_rx_freq(1240e6, 0);
>> usrp->set_rx_gain(50.0, 0);
>> usrp->set_rx_antenna("RX1", 0);
>>
>> while (true) {
>> uhd::sensor_value_t lo_locked = usrp->get_rx_sensor("lo_locked",0);
>> if (lo_locked.to_bool()) {
>> break;
>> }
>> usleep(1);
>> }
>>
>>
>> for (int iteration=0; iteration<1000; iteration++) {
>> // try this block outside the loop and every thing is ok
>> uhd::stream_args_t stream_args("sc16", "sc16");
>> stream_args.channels.push_back(0);
>> uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args);
>> // end of block
>>
>> cout << "iteration: "<< iteration << endl;
>> uhd::stream_cmd_t
>> stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
>> stream_cmd.num_samps = 0;
>> stream_cmd.stream_now = true;
>> stream_cmd.time_spec = uhd::time_spec_t();
>> rx_stream->issue_stream_cmd(stream_cmd);
>>
>> std::vector<std::complex> buff_sc16(524288);
>> uhd::rx_metadata_t md;
>> int num_rx_samps;
>>
>>
>> for (int i=0; i<10; i++) {
>> num_rx_samps = rx_stream->recv(_sc16.front(),
>> buff_sc16.size(), md, 1.0);
>> cout << "recv:"<< num_rx_samps<<endl;
>> }
>>
>> stream_cmd.stream_mode =
>> uhd::stream_cmd_t::STREAM_MODE_STOP_CONTINUOUS;
>> rx_stream->issue_stream_cmd(stream_cmd);
>> }
>> return true;
>> }
>>
>>
>>
>> ___
>> 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] bug using rx_stream constructor inside a loop ...
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: IOError: [0/Radio_0] sr_write() failed:
EnvironmentError:
IOError: Block ctrl (CE_01_Port_40) no response packet - AssertionError:
bool(buff)
in uint64_t ctrl_iface_impl::wait_for_ack(bool)
at /uhd_3.10.3.0-release/lib/rfnoc/ctrl_iface.cpp:204
I have good news: If I move the part of the code which construct the rx_stream,
there is
no errors.
Is someone can explain me ? Is this an uhd bug or not ?
Matis
bool test2() {
std::string args="addr=192.168.10.2";
uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);
std::string subdev_spec="A:0";
usrp->set_rx_subdev_spec(subdev_spec);
usrp->set_rx_rate(25e6, 0);
usrp->set_rx_freq(1240e6, 0);
usrp->set_rx_gain(50.0, 0);
usrp->set_rx_antenna("RX1", 0);
while (true) {
uhd::sensor_value_t lo_locked = usrp->get_rx_sensor("lo_locked",0);
if (lo_locked.to_bool()) {
break;
}
usleep(1);
}
for (int iteration=0; iteration<1000; iteration++) {
// try this block outside the loop and every thing is ok
uhd::stream_args_t stream_args("sc16", "sc16");
stream_args.channels.push_back(0);
uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args);
// end of block
cout << "iteration: "<< iteration << endl;
uhd::stream_cmd_t
stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
stream_cmd.num_samps = 0;
stream_cmd.stream_now = true;
stream_cmd.time_spec = uhd::time_spec_t();
rx_stream->issue_stream_cmd(stream_cmd);
std::vector buff_sc16(524288);
uhd::rx_metadata_t md;
int num_rx_samps;
for (int i=0; i<10; i++) {
num_rx_samps = rx_stream->recv(_sc16.front(),
buff_sc16.size(), md, 1.0);
cout << "recv:"<< num_rx_samps<issue_stream_cmd(stream_cmd);
}
return true;
}
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] multiple rx streams
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 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_back(0);
rx_stream0 = usrp->get_rx_stream(stream_args);
stream_args = uhd::stream_args_t("sc16",wire_format);
stream_args.channels.push_back(1);
rx_stream1 = usrp->get_rx_stream(stream_args);
...
// launch two threads which will do rx_stream->recv
...
Today, using UHD 3.10.3, it does not work and I have the following error:
RuntimeError: On node 0/DDC_0, output port 1 is already connected.
Is it normal ?
Thanks,
Matis
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] multiple rx streams
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_back(0);
rx_stream0 = usrp->get_rx_stream(stream_args);
stream_args = uhd::stream_args_t("sc16",wire_format);
stream_args.channels.push_back(1);
rx_stream1 = usrp->get_rx_stream(stream_args);
...
// launch two threads which will do rx_stream->recv
...
Today, using UHD 3.10.3, it does not work and I have the following error:
RuntimeError: On node 0/DDC_0, output port 1 is already connected.
Is it normal ?
Thanks,
Matis
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] TwinRx frequency range
thanks a lot for these explanations. matis Le 27/03/2018 à 11:52, Derek Kozel a écrit : > Hi Matis, > > The USRPs are generally designed following the rule of thumb that the > passband is 80% of > sampling rate. That allows for filters, both analog and digital, to be > reasonable to > construct. The TwinRX is tuning its analog center frequency to 50 MHz. With > the 100 MS/s > complex sample rate frequencies from DC to 100 MHz are visible, but the > filters, > amplifiers, and other elements of the receiver will degrade the receive > performance > below 10 MHz. As you've found though, the degradation is very acceptable for > some > applications. > > Marcus actually authored an app note looking at the same question with the UBX > daughterboard. > https://kb.ettus.com/Experiments_with_the_UBX_Daughterboard_in_the_HF_Band > > Regards, > Derek > > On Sat, Mar 24, 2018 at 6:15 AM, Matis Alun via USRP-users > <usrp-users@lists.ettus.com > <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 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 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 specs limits to 10 MHz ? Is the RF part have > degraded > performances > >> under this frequency ? > >> > >> Below this question is: we have to deliver a big HF (3-30 MHz) system > to a > customer. The > >> acquisition part is actually built with > >> 2 x N210 with LFRX daughter boards. Due to the lack of chain gain of > this > configuration, > >> we add some RF pre-amplifiers > >> in order to have good RF levels at the LFRX input. > >> Maybe that this configuration can be replaced by 1x X300 + TwinRx (we > didn't make > this > >> choice because of the TwinRx specs) ? > >> > >> Regards, > >> > >> matis > >> > >> > > My guess is that signals below 10MHz can be received, but the RF > amplifiers in the > > low-band portion of the TwinRx likely fall off in gain quite a bit > > below 10MHz. > > > > > > > > ___ > > USRP-users mailing list > > USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> > > http://lists.ettus.com/mailman/listinfo/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 <mailto:USRP-users@lists.ettus.com> > http://lists.ettus.com/mailman/listinfo/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] TwinRx frequency range
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 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 specs limits to 10 MHz ? Is the RF part have >> degraded performances >> under this frequency ? >> >> Below this question is: we have to deliver a big HF (3-30 MHz) system to a >> customer. The >> acquisition part is actually built with >> 2 x N210 with LFRX daughter boards. Due to the lack of chain gain of this >> configuration, >> we add some RF pre-amplifiers >> in order to have good RF levels at the LFRX input. >> Maybe that this configuration can be replaced by 1x X300 + TwinRx (we didn't >> make this >> choice because of the TwinRx specs) ? >> >> Regards, >> >> matis >> >> > My guess is that signals below 10MHz can be received, but the RF amplifiers > in the > low-band portion of the TwinRx likely fall off in gain quite a bit > below 10MHz. > > > > ___ > 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] TwinRx frequency range
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 specs limits to 10 MHz ? Is the RF part have degraded performances under this frequency ? Below this question is: we have to deliver a big HF (3-30 MHz) system to a customer. The acquisition part is actually built with 2 x N210 with LFRX daughter boards. Due to the lack of chain gain of this configuration, we add some RF pre-amplifiers in order to have good RF levels at the LFRX input. Maybe that this configuration can be replaced by 1x X300 + TwinRx (we didn't make this choice because of the TwinRx specs) ? Regards, matis ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] X300 new user
yes, I missed the make install because I thought that it was optionnal. Tell me if I wrong: RFnoc is not used since we use multi_usrp wright ? in this case, xml files are also needed ? Thanks. matis Le 23/03/2018 à 17:35, Marcus D. Leech via USRP-users a écrit : > On 03/23/2018 12:30 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 >> -rw-r--r--. 1 root root 3875 2 nov. 2016 ddc.xml >> -rw-r--r--. 1 root root 1677 2 nov. 2016 dma_fifo.xml >> -rw-r--r--. 1 root root 2393 2 nov. 2016 duc.xml >> -rw-r--r--. 1 root root 3845 2 nov. 2016 fft.xml >> -rw-r--r--. 1 root root 899 2 nov. 2016 fifo.xml >> -rw-r--r--. 1 root root 365 2 nov. 2016 fir.xml >> -rw-r--r--. 1 root root 4500 2 nov. 2016 fosphor.xml >> -rw-r--r--. 1 root root 1374 2 nov. 2016 keep_one_in_n.xml >> -rw-r--r--. 1 root root 1262 2 nov. 2016 logpwr.xml >> -rw-r--r--. 1 root root 554 2 nov. 2016 nullblock.xml >> -rw-r--r--. 1 root root 624 2 nov. 2016 ofdmeq.xml >> -rw-r--r--. 1 root root 1531 2 nov. 2016 packetresizer.xml >> -rw-r--r--. 1 root root 1582 2 nov. 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 >> > I think what you did was you *built* the new version of UHD, but never > actually > installed it, via sudo make install, so when you are executing bits and > pieces from the built-but-not-yet-installed files, they're naturally > expecting to > find config files, and xml files, etc, in their "natural" places. > > You'll have to uninstall the UHD you already have, which was likely installed > from a > pre-packaged release (via a PPA?), and then run the > sudo make install in the source tree. > > >> >> 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/share/uhd/rfnoc/blocks directory with several xml >>>> files. >>>> >>>> matis >>>> >>>> >>> Could you do an ls -l on that directory and share it with us? >>> >>> >>>> 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 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 fpga image usrp_x300_fpga_HG.bit on the board. >>>>>> >>>>>> Runing uhd_find_device gives: >>>>>> >>>>>> -- >>>>>> -- UHD Device 0 >>>>>> -- >>>>>> Device Address: >>>>>> type: x300 >>>>>> addr: 192.168.10.2 >>>>>> fpga: HG >>>>>> name: >>>>>> serial: 31402AC >>>>>> product: X300 >>>>>> >>>>>> But runing uhd_usrp_probe gives: >>>>>> >>>>>> linux; GNU C++ version 7.3.1 20180303 (Red Hat 7.3.1-5); Boost_106400; >>>>>> UHD_003.010.003.000-0-unknown -- X300 initialization sequence... -- >>>>>> Determining >>>>>> maximum frame size... 1472 bytes. -- Setup basic communication... -- >>>>>> Loading values >>>>>> from EEPROM... -- Setup RF frontend clocking... -- Radio 1x clock:200 >>>>>> Error: >>>>>> AssertionError: Failed to find a valid XML path for RFNoC blocks. Try >>>>>> setting the >>>>>> enviroment variable UHD_RFNOC_DIR to the correct location >>>>>> [ravard@starduck utils]$ >>>>>> ./uhd_usrp_probe --args "type=x300,addr=192.168.10.2" linux; GNU C++ >>>>>> version 7
Re: [USRP-users] X300 new user
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 -rw-r--r--. 1 root root 3875 2 nov. 2016 ddc.xml -rw-r--r--. 1 root root 1677 2 nov. 2016 dma_fifo.xml -rw-r--r--. 1 root root 2393 2 nov. 2016 duc.xml -rw-r--r--. 1 root root 3845 2 nov. 2016 fft.xml -rw-r--r--. 1 root root 899 2 nov. 2016 fifo.xml -rw-r--r--. 1 root root 365 2 nov. 2016 fir.xml -rw-r--r--. 1 root root 4500 2 nov. 2016 fosphor.xml -rw-r--r--. 1 root root 1374 2 nov. 2016 keep_one_in_n.xml -rw-r--r--. 1 root root 1262 2 nov. 2016 logpwr.xml -rw-r--r--. 1 root root 554 2 nov. 2016 nullblock.xml -rw-r--r--. 1 root root 624 2 nov. 2016 ofdmeq.xml -rw-r--r--. 1 root root 1531 2 nov. 2016 packetresizer.xml -rw-r--r--. 1 root root 1582 2 nov. 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/share/uhd/rfnoc/blocks directory with several xml files. >> >> matis >> >> > Could you do an ls -l on that directory and share it with us? > > >> 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 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 fpga image usrp_x300_fpga_HG.bit on the board. >>>> >>>> Runing uhd_find_device gives: >>>> >>>> -- >>>> -- UHD Device 0 >>>> -- >>>> Device Address: >>>> type: x300 >>>> addr: 192.168.10.2 >>>> fpga: HG >>>> name: >>>> serial: 31402AC >>>> product: X300 >>>> >>>> But runing uhd_usrp_probe gives: >>>> >>>> linux; GNU C++ version 7.3.1 20180303 (Red Hat 7.3.1-5); Boost_106400; >>>> UHD_003.010.003.000-0-unknown -- X300 initialization sequence... -- >>>> Determining >>>> maximum frame size... 1472 bytes. -- Setup basic communication... -- >>>> Loading values >>>> from EEPROM... -- Setup RF frontend clocking... -- Radio 1x clock:200 >>>> Error: >>>> AssertionError: Failed to find a valid XML path for RFNoC blocks. Try >>>> setting the >>>> enviroment variable UHD_RFNOC_DIR to the correct location [ravard@starduck >>>> utils]$ >>>> ./uhd_usrp_probe --args "type=x300,addr=192.168.10.2" linux; GNU C++ >>>> version 7.3.1 >>>> 20180303 (Red Hat 7.3.1-5); Boost_106400; UHD_003.010.003.000-0-unknown -- >>>> X300 >>>> initialization sequence... -- Determining maximum frame size... 1472 >>>> bytes. -- Setup >>>> basic communication... -- Loading values from EEPROM... -- Setup RF >>>> frontend >>>> clocking... -- Radio 1x clock:200 Error: AssertionError: Failed to find a >>>> valid XML >>>> path for RFNoC blocks. Try setting the enviroment variable UHD_RFNOC_DIR >>>> to the >>>> correct location Can someone tell me what is the problem ? Thanks Matis >>> Do you have a /usr/local/share/uhd/rfnoc/blocks directory? Or a >>> /usr/share/uhd/rfnoc/blocks directory? >>> >>> >>> >>> >>> ___ >>> 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] X300 new user
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 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 fpga image usrp_x300_fpga_HG.bit on the board. >> >> Runing uhd_find_device gives: >> >> -- >> -- UHD Device 0 >> -- >> Device Address: >> type: x300 >> addr: 192.168.10.2 >> fpga: HG >> name: >> serial: 31402AC >> product: X300 >> >> But runing uhd_usrp_probe gives: >> >> linux; GNU C++ version 7.3.1 20180303 (Red Hat 7.3.1-5); Boost_106400; >> UHD_003.010.003.000-0-unknown -- X300 initialization sequence... -- >> Determining maximum >> frame size... 1472 bytes. -- Setup basic communication... -- Loading values >> from >> EEPROM... -- Setup RF frontend clocking... -- Radio 1x clock:200 Error: >> AssertionError: >> Failed to find a valid XML path for RFNoC blocks. Try setting the enviroment >> variable >> UHD_RFNOC_DIR to the correct location [ravard@starduck utils]$ >> ./uhd_usrp_probe --args >> "type=x300,addr=192.168.10.2" linux; GNU C++ version 7.3.1 20180303 (Red Hat >> 7.3.1-5); >> Boost_106400; UHD_003.010.003.000-0-unknown -- X300 initialization >> sequence... -- >> Determining maximum frame size... 1472 bytes. -- Setup basic >> communication... -- >> Loading values from EEPROM... -- Setup RF frontend clocking... -- Radio 1x >> clock:200 >> Error: AssertionError: Failed to find a valid XML path for RFNoC blocks. Try >> setting >> the enviroment variable UHD_RFNOC_DIR to the correct location Can someone >> tell me what >> is the problem ? Thanks Matis > Do you have a /usr/local/share/uhd/rfnoc/blocks directory? Or a > /usr/share/uhd/rfnoc/blocks directory? > > > > > ___ > 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] X300 new user
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 fpga image usrp_x300_fpga_HG.bit on the board. Runing uhd_find_device gives: -- -- UHD Device 0 -- Device Address: type: x300 addr: 192.168.10.2 fpga: HG name: serial: 31402AC product: X300 But runing uhd_usrp_probe gives: linux; GNU C++ version 7.3.1 20180303 (Red Hat 7.3.1-5); Boost_106400; UHD_003.010.003.000-0-unknown -- X300 initialization sequence... -- Determining maximum frame size... 1472 bytes. -- Setup basic communication... -- Loading values from EEPROM... -- Setup RF frontend clocking... -- Radio 1x clock:200 Error: AssertionError: Failed to find a valid XML path for RFNoC blocks. Try setting the enviroment variable UHD_RFNOC_DIR to the correct location [ravard@starduck utils]$ ./uhd_usrp_probe --args "type=x300,addr=192.168.10.2" linux; GNU C++ version 7.3.1 20180303 (Red Hat 7.3.1-5); Boost_106400; UHD_003.010.003.000-0-unknown -- X300 initialization sequence... -- Determining maximum frame size... 1472 bytes. -- Setup basic communication... -- Loading values from EEPROM... -- Setup RF frontend clocking... -- Radio 1x clock:200 Error: AssertionError: Failed to find a valid XML path for RFNoC blocks. Try setting the enviroment variable UHD_RFNOC_DIR to the correct location Can someone tell me what is the problem ? Thanks Matis ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
