Re: [USRP-users] examples using N310 with ext LO

2018-04-07 Thread Robin Coxe via USRP-users 
Hi Rob.  You are specifying use of the RX external LO correctly via device
arguments.   Each of the daughtercards on the N310 contains a single Analog
Device AD9371 2 TX x 2 Rx RF integrated transceiver.   The two Tx channels
share an LO and the 2 Rx channels share an LO.  Consequently, the TX or RX
frequency of RF channel 0 and RF channel 1 are constrained by the RFIC to
be the same and the TX or RF frequency of RF channel 2 and RF channel 3
must be the same.   The AD9371 is capable of FDD operation, so the TX
frequency does not need to be equal to the RX frequency.

The LO tuning code for the N310 daughterboard in UHD is (not obviously)
located here and, as you correctly point out, is handled differently from
previous USRPs:
https://github.com/EttusResearch/uhd/tree/maint/host/lib/usrp/dboard/magnesium

Magnesium is the internal code Ettus Research name for the N310
daughterboard.We will make this obscure fact more obvious in the
documentation.

-Robin


On Sun, Apr 8, 2018 at 2:31 AM, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 04/07/2018 10:39 AM, Rob Kossler wrote:
>
> Hi Marcus,
> No, I haven't fooled with LO level adjustments.  I set the LO at about 3
> dBm and did not change it.  The LO freq is indeed 2x (LO at 4884MHz with
> center freq at 2442MHz).  I suspect that my custom software, which was
> developed for first B210 and then X310 with several daughterboard variants,
> may be sending tune commands in a way that is not ideal for an external LO
> configuration.  There was a similar issue when I first started using TwinRx
> with "companion" or "external" LO and UHD would issue warnings about tuning
> one channel first and then the other when both channels had to be at the
> same freq because they shared an LO.  So, my request for examples was to
> help me see if I am issuing the tuning requests correctly for this external
> LO config.
>
> Rob
>
> Understood.
>
> Hopefully, one of the R folks will chime in here.  I don't currently
> have one in my inventory, so running a bit blind.
>
>
>
> On Fri, Apr 6, 2018 at 7:32 PM, Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 04/06/2018 05:14 PM, Rob Kossler via USRP-users wrote:
>>
>>> Hi,
>>> Are there any examples for using the N310 with external LO?  I have
>>> gotten some strange results (strange spectral mirror-ing) when using as
>>> just a 4 channel receiver.  I am using the "args" argument to set
>>> rx_lo_source, but my code is setting the individual channel frequencies as
>>> I do for other USRPs and I noticed various warnings in the terminal window
>>> for each channel that I tune.
>>>
>>> On a separate note, I get some strange results if I set the clock_source
>>> to external in the args (using with OctoClock). If I leave it internal, no
>>> problem. For now, I am leaving it internal until I can solve the problem
>>> above with LO source.
>>>
>>> Rob
>>>
>>>
>>> Rob, just shooting from the hip here, since I haven't "lived" with an
>> N310 yet...
>>
>> Have you tried adjusting the LO levels let's say 2dB in either direction
>> to see if that changes the imaging behavior?  Also, remember that the
>> external LO input
>>   on the N310 must be a 2XLO -- at twice the desired Fc, and only up to
>> 8GHz (giving a 4GHz antenna frequency).
>>
>>
>>
>>
>> ___
>> 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] examples using N310 with ext LO

2018-04-07 Thread Marcus D. Leech via USRP-users 

On 04/07/2018 10:39 AM, Rob Kossler wrote:

Hi Marcus,
No, I haven't fooled with LO level adjustments.  I set the LO at about 
3 dBm and did not change it.  The LO freq is indeed 2x (LO at 4884MHz 
with center freq at 2442MHz).  I suspect that my custom software, 
which was developed for first B210 and then X310 with several 
daughterboard variants, may be sending tune commands in a way that is 
not ideal for an external LO configuration.  There was a similar issue 
when I first started using TwinRx with "companion" or "external" LO 
and UHD would issue warnings about tuning one channel first and then 
the other when both channels had to be at the same freq because they 
shared an LO.  So, my request for examples was to help me see if I am 
issuing the tuning requests correctly for this external LO config.


Rob

Understood.

Hopefully, one of the R folks will chime in here.  I don't currently 
have one in my inventory, so running a bit blind.





On Fri, Apr 6, 2018 at 7:32 PM, Marcus D. Leech via USRP-users 
> wrote:


On 04/06/2018 05:14 PM, Rob Kossler via USRP-users wrote:

Hi,
Are there any examples for using the N310 with external LO?  I
have gotten some strange results (strange spectral mirror-ing)
when using as just a 4 channel receiver.  I am using the
"args" argument to set rx_lo_source, but my code is setting
the individual channel frequencies as I do for other USRPs and
I noticed various warnings in the terminal window for each
channel that I tune.

On a separate note, I get some strange results if I set the
clock_source to external in the args (using with OctoClock).
If I leave it internal, no problem. For now, I am leaving it
internal until I can solve the problem above with LO source.

Rob


Rob, just shooting from the hip here, since I haven't "lived" with
an N310 yet...

Have you tried adjusting the LO levels let's say 2dB in either
direction to see if that changes the imaging behavior?  Also,
remember that the external LO input
  on the N310 must be a 2XLO -- at twice the desired Fc, and only
up to 8GHz (giving a 4GHz antenna frequency).




___
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] examples using N310 with ext LO

2018-04-07 Thread Rob Kossler via USRP-users 
Hi Marcus,
No, I haven't fooled with LO level adjustments.  I set the LO at about 3
dBm and did not change it.  The LO freq is indeed 2x (LO at 4884MHz with
center freq at 2442MHz).  I suspect that my custom software, which was
developed for first B210 and then X310 with several daughterboard variants,
may be sending tune commands in a way that is not ideal for an external LO
configuration.  There was a similar issue when I first started using TwinRx
with "companion" or "external" LO and UHD would issue warnings about tuning
one channel first and then the other when both channels had to be at the
same freq because they shared an LO.  So, my request for examples was to
help me see if I am issuing the tuning requests correctly for this external
LO config.

Rob

On Fri, Apr 6, 2018 at 7:32 PM, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 04/06/2018 05:14 PM, Rob Kossler via USRP-users wrote:
>
>> Hi,
>> Are there any examples for using the N310 with external LO?  I have
>> gotten some strange results (strange spectral mirror-ing) when using as
>> just a 4 channel receiver.  I am using the "args" argument to set
>> rx_lo_source, but my code is setting the individual channel frequencies as
>> I do for other USRPs and I noticed various warnings in the terminal window
>> for each channel that I tune.
>>
>> On a separate note, I get some strange results if I set the clock_source
>> to external in the args (using with OctoClock). If I leave it internal, no
>> problem. For now, I am leaving it internal until I can solve the problem
>> above with LO source.
>>
>> Rob
>>
>>
>> Rob, just shooting from the hip here, since I haven't "lived" with an
> N310 yet...
>
> Have you tried adjusting the LO levels let's say 2dB in either direction
> to see if that changes the imaging behavior?  Also, remember that the
> external LO input
>   on the N310 must be a 2XLO -- at twice the desired Fc, and only up to
> 8GHz (giving a 4GHz antenna frequency).
>
>
>
>
> ___
> 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] bug using rx_stream constructor inside a loop ...

2018-04-07 Thread Jon Pendlum via USRP-users 
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> 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_
> 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< }
>
> stream_cmd.stream_mode = uhd::stream_cmd_t::STREAM_
> MODE_STOP_CONTINUOUS;
> rx_stream->issue_stream_cmd(stream_cmd);
> }
> return true;
> }
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://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] file_souce block for RFNoC

2018-04-07 Thread Jon Pendlum via USRP-users 
Hi,

The file_source and file_sink blocks (and corresponding RFNoC blocks) are
only useful for simulations. File I/O is not a sythensizable operation.

Jonathon

On Thu, Apr 5, 2018, 7:17 AM Xingjian Chen via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi there,
>
> I find the "file_source" block in RFNoC for X310. Is there any example or
> tutorial how to use it by either UHD C++ or GNURadio? I am new to RFNoC and
> trying to get started with transmitting a waveform from a source file in a
> host computer. Thank you!
>
> ___
> 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