[USRP-users] b200: BBPLL not locked / Catalina not responding on custom fpga image

[Sylvain Munaut via USRP-users]

Hi,


I'm working on a custom fpga image for the B210 running UHD 3.9.5 (and
associated fpga code).


I'm now faced with a problem that I cannot explain :

-- Initialize CODEC control...
terminate called after throwing an instance of 'uhd::runtime_error'
  what():  RuntimeError: [ad9361_device_t] BBPLL not locked

When digging a bit further, it seems the AD9361 isn't responding to
SPI. I tried adding a read of the ID register 0x037 first thing in the
init, and it works fine in a vanilla build and doesn't work when my
logic is present.
But I also exported the catalina SPI signals and reset to the mictor
connector and plugged that to a logic analyzer and the signals sent
_to_ the catalina look identical, the only difference is that the miso
line stays at 0 with my custom image, and I don't see what I could
possibly have done that causes that ...

A few things I tried :
 - Power with external power in case the added logic was causing USB
power to be insufficient
 - Remove the logic for Radio 1 to save some logic and possibly power
 - Slow the catalina SPI down


My custom logic doesn't modify anything in the control of the fpga, it
just "taps off" the sample_rx bus in radio_b200.v and process the
samples. The output of the block isn't even going anywhere yet, just
to a chipscope probe.


Anyone see how some seemingly unrelated logic could prevent the
catalina from talking to the fpga ?!?


Cheers,

 Sylvain

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] b200: BBPLL not locked / Catalina not responding on custom fpga image

[Sylvain Munaut via USRP-users]

Hi Ian,


> Ironically, the thing you described that I think is most likely to break the 
> system is exporting those signal to the Mictor to look at them!

Hehe, well, there isn't much test points for me to probe them directly :)

But as you said :
 - It wasn't working before
 - I also built an image without my logic, but with those debug
signals routed and that works fine.


> I really can’t see how your new logic in radio could cause this (Unless it 
> silently broke synthesis…did timing close ok?).

Yes me either, I'm really at a loss here :(
And I'm not even sure what would break in synthesis that would make me
observe the right SPI commands being sent and the catalina not
responding.

The synthesis  & implementation worked fine and it reports all
constraints were met.

One additional result I just tried :  My block uses both radio_clk and
bus_clk. Basically captures some samples to a BRAM then another part
will process them at a much higher clock rate.
I just tried feeding radio_clk to both side of the process and this
resulted in a working init. Although I'm not sure how that helps me.
I've followed all the rules for clock-domain crossing (and there is
very few signals crossing anyway) and even if I had screwed up
something, I can see how my logic would be misbehaving but not how
that would have any influence on the AD9361 init.


> Have you reordered any operations in the UHD driver etc doing your user_reg 
> hack?

No. Also, using the exact same UHD but just a image I built but with
my logic disabled, the init works just fine.


Cheers,

Sylvain

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Using ZMQ

[Marcus Müller via USRP-users]

Hey Steve,

so, how much sampling rate do you need? If this is a local network,
directly using the USRP from Windows might just work. But: An X310 can
generate significantly more data per second than fits through gigabit
ethernet, so this can even theoretically only work if sampling rates
are relatively benign (i.e. below ca 30 MS/s). So: What's the sampling
rate you and your colleague are trying to achieve? WHat's the network
speed?

Also note that high rates, no matter how you encapsulate these, will
put a high load on your router - and that might or might not work out
well. 

Best regards,
Marcus

On Wed, 2018-05-30 at 14:54 -0400, Keith k wrote:
> Hey Steve
> 
> Do you have to use 2 computers? Can you run linux with a windows VM
> for processing? Your ZMQ performance of piping samples within the
> same computer may be faster and more deterministic, but may not work
> for your situation. Also, Ive used ZMQ lots. I recommend using
> ROUTER/DEALER or DEALER/DEALER architecture. Its worked the best for
> me. 
> 
> 
> On Tue, May 29, 2018, 10:05 shachar J. brown via USRP-users,  e...@lists.ettus.com> wrote:
> > Hi Marcus,
> > 
> > Thanks for replying.
> > 
> > To make the story short - I am trying to collaborate with a
> > colleague of mine. He has some serious signal processing
> > capabilities on his Windows PC and I would like to extract the data
> > for him from the X310 (with some minor processing). His tools don't
> > work well under Linux environment.
> > 
> > If I use a local router, which is connected to the X310 and two
> > computers alone (and NOT to the web) - do you think that would
> > solve anything?
> > 
> > Thanks again,
> > Steve
> > 
> > 
> > 
> > On Mon, May 28, 2018 at 11:45 PM, Marcus Müller  > us.com> wrote:
> > > Hi Steve,
> > > 
> > > > Do you know what is the max rate of data possible to send via
> > > xmlrcp
> > > > / zmq / dpu socket?
> > > 
> > > Speed is mostly a function of your connection , not of the
> > > protocol, so
> > > there can't be a definite answer. I'd recommend just considering
> > > the
> > > overhead of any sensibly packaged piece of samples as "small",
> > > and then
> > > add a solid oversizing (2×?), because internet connections aren't
> > > deterministic.
> > > 
> > > > Which of the three options is more efficient?
> > > 
> > > The three are pretty different; XMLRPC certainly is least well-
> > > fitting
> > > to transport samples. I'd go with the ZMQ.
> > > 
> > > >  (BTW, is it possible to connect the X310's ethernet cable to
> > > the
> > > > internet and control it remotely, or do I have to connect it
> > > directly
> > > > to a host computer?)
> > > 
> > > Directly to a host computer; while, in theory, the X310 is a
> > > pretty IP-
> > > standards conformant networking device, I simply can't, on very
> > > many
> > > levels, recommend exposing one to the internet. Also, the latency
> > > over
> > > an internet connection is completely unusable for UHD. 
> > > 
> > > Can you please describe your use case, and the kind of internet
> > > connection you have? I feel like you're trying to implement
> > > something
> > > that will, simply by virtue of the math behind it, relatively
> > > hard, and
> > > it might be helpful to give you early feedback on the concept.
> > > 
> > > Best regards,
> > > Marcus
> > 
> > ___
> > 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] UHD and process forking

[Marcus Müller via USRP-users]

Hello Keith,
Sorry for the long silence  - this problem really needed mulling over
in my head, and then I postponed that...
So, yes, I'd see why you want fine-tuned control over threading.

Would modifying UHD be an option for you? I could imagine the following
to be a viable approach:

1. in zero_copy_recv_offload_impl, add a new setter for _recv_thread'
CPU affinity
2. in x300_impl, add a new property tree property with a subscriber
that calls that setter

In effect, you'd then have a new property that you'd see with
`uhd_usrp_probe --tree`, and you could access that from your software
to change the right thread's properties.

Does that sound like it makes sense to you?

Best regards,
Marcus 
On Tue, 2018-05-22 at 16:15 +, Keith k wrote:
> Hello Marcus
> 
> I'm trying to run 16 N200s with LFTX/LFRX boards. I want to use all
> 16 TX channel and 20 RX channels at 10 MHz sampling rate. I will be
> streaming continuous on RX and sending bursts on TX. The problem I'm
> having is that the RX threads really don't like being preempted too
> often or they go into a unstable state where they continually drop
> samples. I've got a computer with a core i9 and I've isolated 70% of
> the cpu cores purely to my process, but when it comes to scheduling
> the threads the best I can do is evenly distribute them since I'm not
> aware of a mechanism to get the TID of only the UHD RX threads. Using
> isolcpus and taskset with basic round robin cpu affinity, I can get
> all 16 TX channels and 12 RX channels working for a period of a few
> hours, but I think if I could properly schedule the RX threads, I
> would be able to get them all working without dropped samples. In
> theory the fork would work for me since I could use a child process
> for only TX or RX threads and I could manually schedule them, but
> practically I know there would be problems with the multi-usrp
> object.
> 
> Right now I'm scheduling using command line utilities once my
> application is running, but I've now been considering querying the OS
> for TIDs before and after each streamer is created from within my
> application. I should be able use this information to isolate which
> set of threads are for RX or TX. Do you have any thoughts on the best
> approach to scheduling for UHD or operating high data rate multiusrp
> configurations? 
> 
> On Sat, May 19, 2018 at 9:05 AM, Marcus Müller  com> wrote:
> > Hi Keith,
> > 
> > in principle, you could continue using the multi_usrp in **one** of
> > the processes. The real problem stems from the question of who
> > inherits the sockets (in the case of network USRPs), the USB
> > handles, or kernel ring buffer handles.
> > In the end, only one process might react to packets coming from the
> > USRP. Also, this is C++, so if you don't watch out in your main
> > process, and your multi_usrp loses scope, its destructor would be
> > called, with devastating effects on the state of your USRP.
> > 
> > On the other hand, there is, at least as far as I can remember from
> > the top of my head, nothing to react to until you start a streamer.
> > But I wouldn't recommend relying on that as kind of API; I don't
> > think we guarantee usability of a multi_usrp after forking, but the
> > last word on that is Martin's.
> > 
> > Maybe if you described your use case, we could chime in with
> > approaches.
> > 
> > Best regards,
> > Marcus
> > 
> > On 14 May 2018 18:09:51 GMT+02:00, Keith k via USRP-users  > r...@lists.ettus.com> wrote:
> > > Hello all
> > > 
> > > My intuition tells me this would be a bad idea, but before I try
> > > anything with this, does anyone have any thoughts about how the
> > > multi-usrp object would react in a situation where the process
> > > has been forked? I know that the call to create a multi-usrp
> > > object will fail if called in a second process, so I imagine it
> > > won't like being in 2 separate address spaces.
> > 
> > -- 
> > This was written on my cellular phone. whilst an impressive piece
> > of engineering, this might not be the perfect device to write
> > emails on - please excuse my brevity.
> 
> 
> 

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] IQ transmission using grc

[Marcus Müller via USRP-users]

Hi ben,
On Sat, 2018-03-24 at 05:32 +, Benny Alexandar wrote:
> on USRP N210 is 100 MHz / 2 = 50 MHz. Is that correct ? 
> Can USRP sample at such high rates ? 

Yes. But it's impossible to fit 50 MS/s · 32 b/S through a 1 Gb/s link,
so you need to reduce the sample depth to 8 b, so that a complex sample
only takes 16 b/S.

> 
> If I need a bandwidth of say 500kHz,  from USRP then I need to set N
> = 200, is my math correct
yes.

Best regards,
Marcus

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] IQ transmission using grc

[Marcus Müller via USRP-users]

That's a bit of a GNU Radio more than a USRP question, but
nevertheless:
You can't do that with the existing file_source. You'd need to extend
the file_source's C++ or write your own block that does that cycling.

Best regards,
Marcus

On Wed, 2018-03-21 at 17:07 +, Benny Alexandar wrote:
> Hi Marcus,
> 
> Yes, I added a resampler to upsample by 250kHz and scaled the IQ
> samples by dividing it with 2**16, since each IQ is of 16bit.
> With this it started to work. 
> 
> Now, I want to keep changing the IQ file at run time. I have a lot of
> IQ files in current folder, which I want to use for transmission
> for certain time say after running one IQ file for 2 min, change the
> IQ file, this should keep continuing. 
> 
> I had a look at the python code grc generated, and it basically
> creates a class which initializes with the specified IQ file and
> creates the connection
> and runs. 
> 
> How do I change this python code so that it can loop over all IQ
> files in  the folder, any example python code available ?
> 
> Please help me in setting it up.
> 
> -ben
> 
> 
> From: USRP-users  on behalf of
> Marcus Müller via USRP-users 
> Sent: Wednesday, March 21, 2018 2:10 AM
> To: Marcus D. Leech; usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] IQ transmission using grc
>  
> Hi ben,
> 
> also, no USRP can directly deal with a sampling rate as low as 48 kHz
> –
> you'll first have to resample to a rate that your USRP can deal with.
> In case of the N210, these frequencies are integer fractions of 100
> MHz
> i.e. 100 MHz / N, with the restriction that N be an integer 3 < n <=
> 128 , an even integer 2 < n <= 256 or an integer multiple of 4 <=
> 512.
> 
> tx_samples_from_file can't resample – you should have been getting
> UHD
> warnings about impossible sampling rates; your IQ file has simply
> been
> played back at a higher rate.
> 
> Best regards,
> Marcus
> 
> On Tue, 2018-03-20 at 12:58 -0400, Marcus D. Leech via USRP-users
> wrote:
> > On 03/20/2018 12:37 PM, Benny Alexandar via USRP-users wrote:
> > > Hi,
> > > 
> > > I have an IQ file sampled at 48kHz and want to transmit through
> gnu
> > > radio. The IQ samples are each 16bit, and stored interleaved in a
> > > file
> > > ie, IQIQIQIQ... I 16 bit and Q 16bit
> > > 
> > > I tried creating a grc using iShort to Complex block and send to
> > > USRP sink block (usrp n210), but the signal received is
> distorted.
> > > Do I need to convert the short values into float -1.0 to +1.0
> > > before transmission. Please help in resolving it. 
> > > 
> > > I want to use it only through grc and not to use
> > > tx_samples_from_file which does the same.
> > > 
> > > -ben
> > > 
> >  You'll need to scale your samples into {-1.0,1.0}
> > 
> > 
> > 
> > ___
> > 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] IQ transmission using grc

[Jeff Long via USRP-users]

You can edit the auto-generated Python code to start a thread that 
periodically calls:


  file_sink.open(next_file_name, repeat=1)

for example. A tag is added whenever a repeating file restarts, if that 
helps at all. There is no way to play a list of non-repeating files with 
this block, but you could externally "cat" them into a flowgraph that 
gets samples from stdin.


On 05/31/2018 04:36 AM, Marcus Müller via USRP-users wrote:

That's a bit of a GNU Radio more than a USRP question, but
nevertheless:
You can't do that with the existing file_source. You'd need to extend
the file_source's C++ or write your own block that does that cycling.

Best regards,
Marcus

On Wed, 2018-03-21 at 17:07 +, Benny Alexandar wrote:

Hi Marcus,

Yes, I added a resampler to upsample by 250kHz and scaled the IQ
samples by dividing it with 2**16, since each IQ is of 16bit.
With this it started to work.

Now, I want to keep changing the IQ file at run time. I have a lot of
IQ files in current folder, which I want to use for transmission
for certain time say after running one IQ file for 2 min, change the
IQ file, this should keep continuing.

I had a look at the python code grc generated, and it basically
creates a class which initializes with the specified IQ file and
creates the connection
and runs.

How do I change this python code so that it can loop over all IQ
files in  the folder, any example python code available ?

Please help me in setting it up.

-ben


From: USRP-users  on behalf of
Marcus Müller via USRP-users 
Sent: Wednesday, March 21, 2018 2:10 AM
To: Marcus D. Leech; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] IQ transmission using grc
  
Hi ben,


also, no USRP can directly deal with a sampling rate as low as 48 kHz
–
you'll first have to resample to a rate that your USRP can deal with.
In case of the N210, these frequencies are integer fractions of 100
MHz
i.e. 100 MHz / N, with the restriction that N be an integer 3 < n <=
128 , an even integer 2 < n <= 256 or an integer multiple of 4 <=
512.

tx_samples_from_file can't resample – you should have been getting
UHD
warnings about impossible sampling rates; your IQ file has simply
been
played back at a higher rate.

Best regards,
Marcus

On Tue, 2018-03-20 at 12:58 -0400, Marcus D. Leech via USRP-users
wrote:

On 03/20/2018 12:37 PM, Benny Alexandar via USRP-users wrote:

Hi,

I have an IQ file sampled at 48kHz and want to transmit through

gnu

radio. The IQ samples are each 16bit, and stored interleaved in a
file
ie, IQIQIQIQ... I 16 bit and Q 16bit

I tried creating a grc using iShort to Complex block and send to
USRP sink block (usrp n210), but the signal received is

distorted.

Do I need to convert the short values into float -1.0 to +1.0
before transmission. Please help in resolving it.

I want to use it only through grc and not to use
tx_samples_from_file which does the same.

-ben


  You'll need to scale your samples into {-1.0,1.0}



___
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] UHD and process forking

[Keith k via USRP-users]

Hey Marcus

Thanks for taking a look at this for me. Im a pretty competent computer
engineer so I would be comfortable making modifications to UHD given your
starting point. It may be a couple of weeks before I can look at this
again, but I will try to look into this. I may need to pick your brain
about it at sometime when I have a chance to look at the code. Working with
so many USRPs has given me many troubles over the past few months.

On Thu, May 31, 2018, 04:28 Marcus Müller,  wrote:

> Hello Keith,
> Sorry for the long silence  - this problem really needed mulling over
> in my head, and then I postponed that...
> So, yes, I'd see why you want fine-tuned control over threading.
>
> Would modifying UHD be an option for you? I could imagine the following
> to be a viable approach:
>
> 1. in zero_copy_recv_offload_impl, add a new setter for _recv_thread'
> CPU affinity
> 2. in x300_impl, add a new property tree property with a subscriber
> that calls that setter
>
> In effect, you'd then have a new property that you'd see with
> `uhd_usrp_probe --tree`, and you could access that from your software
> to change the right thread's properties.
>
> Does that sound like it makes sense to you?
>
> Best regards,
> Marcus
> On Tue, 2018-05-22 at 16:15 +, Keith k wrote:
> > Hello Marcus
> >
> > I'm trying to run 16 N200s with LFTX/LFRX boards. I want to use all
> > 16 TX channel and 20 RX channels at 10 MHz sampling rate. I will be
> > streaming continuous on RX and sending bursts on TX. The problem I'm
> > having is that the RX threads really don't like being preempted too
> > often or they go into a unstable state where they continually drop
> > samples. I've got a computer with a core i9 and I've isolated 70% of
> > the cpu cores purely to my process, but when it comes to scheduling
> > the threads the best I can do is evenly distribute them since I'm not
> > aware of a mechanism to get the TID of only the UHD RX threads. Using
> > isolcpus and taskset with basic round robin cpu affinity, I can get
> > all 16 TX channels and 12 RX channels working for a period of a few
> > hours, but I think if I could properly schedule the RX threads, I
> > would be able to get them all working without dropped samples. In
> > theory the fork would work for me since I could use a child process
> > for only TX or RX threads and I could manually schedule them, but
> > practically I know there would be problems with the multi-usrp
> > object.
> >
> > Right now I'm scheduling using command line utilities once my
> > application is running, but I've now been considering querying the OS
> > for TIDs before and after each streamer is created from within my
> > application. I should be able use this information to isolate which
> > set of threads are for RX or TX. Do you have any thoughts on the best
> > approach to scheduling for UHD or operating high data rate multiusrp
> > configurations?
> >
> > On Sat, May 19, 2018 at 9:05 AM, Marcus Müller  > com> wrote:
> > > Hi Keith,
> > >
> > > in principle, you could continue using the multi_usrp in **one** of
> > > the processes. The real problem stems from the question of who
> > > inherits the sockets (in the case of network USRPs), the USB
> > > handles, or kernel ring buffer handles.
> > > In the end, only one process might react to packets coming from the
> > > USRP. Also, this is C++, so if you don't watch out in your main
> > > process, and your multi_usrp loses scope, its destructor would be
> > > called, with devastating effects on the state of your USRP.
> > >
> > > On the other hand, there is, at least as far as I can remember from
> > > the top of my head, nothing to react to until you start a streamer.
> > > But I wouldn't recommend relying on that as kind of API; I don't
> > > think we guarantee usability of a multi_usrp after forking, but the
> > > last word on that is Martin's.
> > >
> > > Maybe if you described your use case, we could chime in with
> > > approaches.
> > >
> > > Best regards,
> > > Marcus
> > >
> > > On 14 May 2018 18:09:51 GMT+02:00, Keith k via USRP-users  > > r...@lists.ettus.com> wrote:
> > > > Hello all
> > > >
> > > > My intuition tells me this would be a bad idea, but before I try
> > > > anything with this, does anyone have any thoughts about how the
> > > > multi-usrp object would react in a situation where the process
> > > > has been forked? I know that the call to create a multi-usrp
> > > > object will fail if called in a second process, so I imagine it
> > > > won't like being in 2 separate address spaces.
> > >
> > > --
> > > This was written on my cellular phone. whilst an impressive piece
> > > of engineering, this might not be the perfect device to write
> > > emails on - please excuse my brevity.
> >
> >
> >
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] N210 + WBX and X310 + TwinRXs sample alignment

[Steve Gough via USRP-users]

Thanks. That temporarily fixes the addressing issue. However, I am now
seeing the following error. Could you please tell me why this might be
happening?

File "/home/colosseum/Downloads/for_steve_gough.py", line 47, in __init__
self.uhd_usrp_source_0.set_clock_source('external', 1)
  File
"/home/colosseum/src/gr-prefix/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 3706, in set_clock_source
return _uhd_swig.usrp_source_sptr_set_clock_source(self, source, mboard)
RuntimeError: LookupError: IndexError: multi_usrp::mb_root(1) -
vector::_M_range_check: __n (which is 1) >= this->size() (which is 1)


It looks like with the "addr=192.168.10.5 addr=192.168.10.2" device args,
it thinks there is only 1 motherboard.
A check on  self.uhd_usrp_source_0.get_num_mboards() replies "1" .
Shouldn't it actually be 2 ?

Thanks!

On Wed, May 30, 2018 at 5:39 PM, Marcus D. Leech  wrote:

> On 05/30/2018 04:45 PM, Steve Gough wrote:
>
> Same error still, unfortunately even after setting the gateway and subnet
> on the N210 via usrp_burn_mb_eeprom and power-cycling.
>
> Ah!
>
> Try this in your device args:
>
> "addr=192.168.10.5 addr=192.168.10.2"
>
>
>
>
> For the N210:
> |   |   Mboard: N210r4
> |   |   hardware: 2577
> |   |   mac-addr: a0:36:fa:25:3e:96
> |   |   ip-addr: 192.168.10.5
> |   |   subnet: 255.255.255.0
> |   |   gateway: 192.168.10.1
> |   |   gpsdo: none
> |   |   serial: E9R1EQ6UP
> |   |   FW Version: 12.4
> |   |   FPGA Version: 11.1
> |   |
> |   |   Time sources:  none, external, _external_, mimo
> |   |   Clock sources: internal, external, mimo
> |   |   Sensors: mimo_locked, ref_locked
>
>
>
>
> For the X310:
>  Mboard: X310
> |   |   revision: 8
> |   |   revision_compat: 7
> |   |   product: 30818
> |   |   mac-addr0: 00:80:2f:25:c1:ec
> |   |   mac-addr1: 00:80:2f:25:c1:ed
> |   |   gateway: 192.168.10.1
> |   |   ip-addr0: 192.168.10.2
> |   |   subnet0: 255.255.255.0
> |   |   ip-addr1: 192.168.20.2
> |   |   subnet1: 255.255.255.0
> |   |   ip-addr2: 192.168.30.2
> |   |   subnet2: 255.255.255.0
> |   |   ip-addr3: 192.168.40.2
> |   |   subnet3: 255.255.255.0
> |   |   serial: 30E781A
> |   |   FW Version: 5.0
> |   |   FPGA Version: 33.0
> |   |   RFNoC capable: Yes
> |   |
> |   |   Time sources:  internal, external, gpsdo
> |   |   Clock sources: internal, external, gpsdo
> |   |   Sensors: ref_locked
>
>
>
> -
> colosseum@colosseum-ThinkPad-T430:~/wireless/lp_door/doppler/usrp_sync$
> python ~/Downloads/for_steve_gough.py
> WARNING: Config file '/home/colosseum/.gnuradio/config.conf' failed to
> parse:
> std::exception
> Skipping it
> WARNING: Config file '/home/colosseum/.gnuradio/config.conf' failed to
> parse:
> std::exception
> Skipping it
> WARNING: Config file '/home/colosseum/.gnuradio/config.conf' failed to
> parse:
> std::exception
> Skipping it
> linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_003.011.000.git-78-gf70dd85d
>
>
> UHD Error:
> Device discovery error: ValueError: Could not resolve device hint
> "addr=192.168.10.2" to a single device.
>
> UHD Error:
> Device discovery error: ValueError: Could not resolve device hint
> "addr=192.168.10.5" to a single device.
> Traceback (most recent call last):
>   File "/home/colosseum/Downloads/for_steve_gough.py", line 95, in
> 
> main()
>   File "/home/colosseum/Downloads/for_steve_gough.py", line 84, in main
> tb = top_block_cls()
>   File "/home/colosseum/Downloads/for_steve_gough.py", line 36, in
> __init__
> channels=range(5),
>   File "/home/colosseum/src/gr-prefix/lib/python2.7/dist-
> packages/gnuradio/uhd/__init__.py", line 122, in constructor_interceptor
> return old_constructor(*args)
>   File "/home/colosseum/src/gr-prefix/lib/python2.7/dist-
> packages/gnuradio/uhd/uhd_swig.py", line 2686, in make
> return _uhd_swig.usrp_source_make(*args)
> RuntimeError: LookupError: KeyError: No devices found for ->
> Device Address:
> addr0: 192.168.10.2
> addr1: 192.168.10.5
>
> 
> ---
>
> Is there any other reason why this might be happening ?
>
> Thanks!
> Steve
>
> On Wed, May 30, 2018 at 2:05 PM, Marcus D. Leech 
> wrote:
>
>> On 05/30/2018 02:00 PM, Steve Gough wrote:
>>
>> Thanks for the reply, Ian and Marcus.
>>
>> I see. Could you please tell me what should be the values I must set on
>> the host and N210 for the gateway and subnet ?
>>
>> Thanks!
>>
>> Gateway addy should all be (assuming 192.168.10.x) subnet:
>>
>> 192.168.10.1
>>
>> Subnet mask should be:
>>
>> 255.255.255.0
>>
>>
>>
>> On Wed, May 30, 2018 at 12:36 PM, Ian Buckley via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Those N210 settings are broken also…bad subnet and gateway
>>>
>>> > On May 30, 2018, at 9:26 AM, Marcus D. Leech via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>> >
>>>

Re: [USRP-users] N210 + WBX and X310 + TwinRXs sample alignment

[Marcus D. Leech via USRP-users]

On 05/31/2018 12:50 PM, Steve Gough wrote:
Thanks. That temporarily fixes the addressing issue. However, I am now 
seeing the following error. Could you please tell me why this might be 
happening?


File "/home/colosseum/Downloads/for_steve_gough.py", line 47, in __init__
self.uhd_usrp_source_0.set_clock_source('external', 1)
  File 
"/home/colosseum/src/gr-prefix/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", 
line 3706, in set_clock_source
return _uhd_swig.usrp_source_sptr_set_clock_source(self, source, 
mboard)
RuntimeError: LookupError: IndexError: multi_usrp::mb_root(1) - 
vector::_M_range_check: __n (which is 1) >= this->size() (which is 1)



It looks like with the "addr=192.168.10.5 addr=192.168.10.2" device 
args, it thinks there is only 1 motherboard.
A check on  self.uhd_usrp_source_0.get_num_mboards() replies "1" . 
Shouldn't it actually be 2 ?


Thanks!

I can't recall at this point, but is this a GnuRadio (GRC, even) flow-graph?

If so, there's a "number of Mboards" parameter -- it doesn't get 
computed automatically.





On Wed, May 30, 2018 at 5:39 PM, Marcus D. Leech > wrote:


On 05/30/2018 04:45 PM, Steve Gough wrote:

Same error still, unfortunately even after setting the gateway
and subnet on the N210 via usrp_burn_mb_eeprom and power-cycling.

Ah!

Try this in your device args:

"addr=192.168.10.5 addr=192.168.10.2"





For the N210:
|   |   Mboard: N210r4
|   |   hardware: 2577
|   |   mac-addr: a0:36:fa:25:3e:96
|   |   ip-addr: 192.168.10.5
|   |   subnet: 255.255.255.0
|   |   gateway: 192.168.10.1
|   |   gpsdo: none
|   |   serial: E9R1EQ6UP
|   |   FW Version: 12.4
|   |   FPGA Version: 11.1
|   |
|   |   Time sources:  none, external, _external_, mimo
|   |   Clock sources: internal, external, mimo
|   |   Sensors: mimo_locked, ref_locked




For the X310:
 Mboard: X310
|   |   revision: 8
|   |   revision_compat: 7
|   |   product: 30818
|   |   mac-addr0: 00:80:2f:25:c1:ec
|   |   mac-addr1: 00:80:2f:25:c1:ed
|   |   gateway: 192.168.10.1
|   |   ip-addr0: 192.168.10.2
|   |   subnet0: 255.255.255.0
|   |   ip-addr1: 192.168.20.2
|   |   subnet1: 255.255.255.0
|   |   ip-addr2: 192.168.30.2
|   |   subnet2: 255.255.255.0
|   |   ip-addr3: 192.168.40.2
|   |   subnet3: 255.255.255.0
|   |   serial: 30E781A
|   |   FW Version: 5.0
|   |   FPGA Version: 33.0
|   |   RFNoC capable: Yes
|   |
|   |   Time sources:  internal, external, gpsdo
|   |   Clock sources: internal, external, gpsdo
|   |   Sensors: ref_locked



-
colosseum@colosseum-ThinkPad-T430:~/wireless/lp_door/doppler/usrp_sync$
python ~/Downloads/for_steve_gough.py
WARNING: Config file '/home/colosseum/.gnuradio/config.conf'
failed to parse:
std::exception
Skipping it
WARNING: Config file '/home/colosseum/.gnuradio/config.conf'
failed to parse:
std::exception
Skipping it
WARNING: Config file '/home/colosseum/.gnuradio/config.conf'
failed to parse:
std::exception
Skipping it
linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_003.011.000.git-78-gf70dd85d


UHD Error:
Device discovery error: ValueError: Could not resolve device
hint "addr=192.168.10.2" to a single device.

UHD Error:
Device discovery error: ValueError: Could not resolve device
hint "addr=192.168.10.5" to a single device.
Traceback (most recent call last):
  File "/home/colosseum/Downloads/for_steve_gough.py", line 95,
in 
main()
  File "/home/colosseum/Downloads/for_steve_gough.py", line 84,
in main
tb = top_block_cls()
  File "/home/colosseum/Downloads/for_steve_gough.py", line 36,
in __init__
channels=range(5),
  File

"/home/colosseum/src/gr-prefix/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
line 122, in constructor_interceptor
return old_constructor(*args)
  File

"/home/colosseum/src/gr-prefix/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 2686, in make
return _uhd_swig.usrp_source_make(*args)
RuntimeError: LookupError: KeyError: No devices found for ->
Device Address:
addr0: 192.168.10.2
addr1: 192.168.10.5


---

Is there any other reason why this might be happening ?

Thanks!
Steve

On Wed, May 30, 2018 at 2:05 PM, Marcus D. Leech
mailto:mle...@ripnet.com>> wrote:

On 05/30/2018 02:00 PM, Steve Gough wrote:

Thanks for the reply, Ian and Marcus.

I see. Could you please tell me what should be the values I
must set on the host and N210 for

Re: [USRP-users] N210 + WBX and X310 + TwinRXs sample alignment

[Marcus D. Leech via USRP-users]

On 05/31/2018 01:24 PM, Steve Gough wrote:
Oh, I meant I edited the python from the GRC which you had sent to 
print the number of motherboards using UHD's get_num_mboards 
(https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#ae4efbbc6480fba44939b34c78d44d7e9), 
and it returned 1.  I expected 2.


The GRC and a screenshot of the same is attached.

Simply running this flowgraph gives me the error :

  File "/home/colosseum/Downloads/for_steve_gough2.py", line 43, in 
__init__

self.uhd_usrp_source_0.set_clock_source('external', 1)
  File 
"/home/colosseum/src/gr-prefix/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", 
line 3706, in set_clock_source
return _uhd_swig.usrp_source_sptr_set_clock_source(self, source, 
mboard)
RuntimeError: LookupError: IndexError: multi_usrp::mb_root(1) - 
vector::_M_range_check: __n (which is 1) >= this->size() (which is 1)


Is there any particular cause of this error ?

This should Just Work(tm).

I'd forgotten that I'd written you a flow-graph to test things. sigh.

You still have a "," between the addresses.   Use a space.   The "," 
separates parameters for a single mboard.





On Thu, May 31, 2018 at 1:02 PM, Marcus D. Leech > wrote:


On 05/31/2018 12:50 PM, Steve Gough wrote:

Thanks. That temporarily fixes the addressing issue. However, I
am now seeing the following error. Could you please tell me why
this might be happening?

File "/home/colosseum/Downloads/for_steve_gough.py", line 47, in
__init__
self.uhd_usrp_source_0.set_clock_source('external', 1)
  File

"/home/colosseum/src/gr-prefix/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 3706, in set_clock_source
return _uhd_swig.usrp_source_sptr_set_clock_source(self,
source, mboard)
RuntimeError: LookupError: IndexError: multi_usrp::mb_root(1) -
vector::_M_range_check: __n (which is 1) >= this->size() (which is 1)


It looks like with the "addr=192.168.10.5 addr=192.168.10.2"
device args, it thinks there is only 1 motherboard.
A check on  self.uhd_usrp_source_0.get_num_mboards() replies "1"
. Shouldn't it actually be 2 ?

Thanks!

I can't recall at this point, but is this a GnuRadio (GRC, even)
flow-graph?

If so, there's a "number of Mboards" parameter -- it doesn't get
computed automatically.





On Wed, May 30, 2018 at 5:39 PM, Marcus D. Leech
mailto:mle...@ripnet.com>> wrote:

On 05/30/2018 04:45 PM, Steve Gough wrote:

Same error still, unfortunately even after setting the
gateway and subnet on the N210 via usrp_burn_mb_eeprom and
power-cycling.

Ah!

Try this in your device args:

"addr=192.168.10.5 addr=192.168.10.2"





For the N210:
|   |   Mboard: N210r4
|   |   hardware: 2577
|   |   mac-addr: a0:36:fa:25:3e:96
|   |   ip-addr: 192.168.10.5
|   |   subnet: 255.255.255.0
|   |   gateway: 192.168.10.1
|   |   gpsdo: none
|   |   serial: E9R1EQ6UP
|   |   FW Version: 12.4
|   |   FPGA Version: 11.1
|   |
|   |   Time sources:  none, external, _external_, mimo
|   |   Clock sources: internal, external, mimo
|   |   Sensors: mimo_locked, ref_locked




For the X310:
 Mboard: X310
|   |   revision: 8
|   |   revision_compat: 7
|   |   product: 30818
|   |   mac-addr0: 00:80:2f:25:c1:ec
|   |   mac-addr1: 00:80:2f:25:c1:ed
|   |   gateway: 192.168.10.1
|   |   ip-addr0: 192.168.10.2
|   |   subnet0: 255.255.255.0
|   |   ip-addr1: 192.168.20.2
|   |   subnet1: 255.255.255.0
|   |   ip-addr2: 192.168.30.2
|   |   subnet2: 255.255.255.0
|   |   ip-addr3: 192.168.40.2
|   |   subnet3: 255.255.255.0
|   |   serial: 30E781A
|   |   FW Version: 5.0
|   |   FPGA Version: 33.0
|   |   RFNoC capable: Yes
|   |
|   |   Time sources:  internal, external, gpsdo
|   |   Clock sources: internal, external, gpsdo
|   |   Sensors: ref_locked



-
colosseum@colosseum-ThinkPad-T430:~/wireless/lp_door/doppler/usrp_sync$
python ~/Downloads/for_steve_gough.py
WARNING: Config file '/home/colosseum/.gnuradio/config.conf'
failed to parse:
std::exception
Skipping it
WARNING: Config file '/home/colosseum/.gnuradio/config.conf'
failed to parse:
std::exception
Skipping it
WARNING: Config file '/home/colosseum/.gnuradio/config.conf'
failed to parse:
std::exception
Skipping it
linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_003.011.000.git-78-gf70dd85d


UHD Error:
Device 

Re: [USRP-users] Cannot Install SDK on 32-bit Linux Machine - Is there work Around?

[Marcus Müller via USRP-users]

Hi Konstanti,

the most common reason for that is actually a typo in the file name or
in the path; can you verifying the file is actually readable (i.e.
ls -l
/home/rfnoc/rfnoc_tutorial/share/uhd/imagesusrp_e310_fpga_RFNOC_sg3.bit
displays read privileges)?

Best regards,
Marcus 

On Thu, 2018-05-31 at 13:44 +, Matheou, Konstantin J. (GRC-
LCI0)[ZIN TECHNOLOGIES INC] wrote:
> To All,
>  
> I went through the process of creating my own bit file using the
> rfnoc GUI tool.  I am now trying to load it to the E310 using the
> below command.
>  
> uhd_usrp_probe
> –args=’fpga=/home/rfnoc/rfnoc_tutorial/share/uhd/imagesusrp_e310_fpga
> _RFNOC_sg3.bit
>  
> See attached error screen shot.
>  
> I was told I need to install the Section “Cross-Compiling rfnoc-devel 
> UHD” to be able to upload the bit file using the above command 
>  
> https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building
> _RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source
>  
>  
> BUT, when I try to follow the instructions and install the SDK file,
> I cannot because my machine is a 32-bit processor machine. 
>  
> Is there a work around?
> 
> Thanks,
>  
> Konstantin
>  
>  
>  
>  
>  

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] N210 + WBX and X310 + TwinRXs sample alignment

[Marcus D. Leech via USRP-users]

On 05/31/2018 01:53 PM, Steve Gough wrote:
Thanks for the tip. Tried that as well, and I get the below.  Device 
address in the GRC parameter is set as : "addr=192.168.10.2 
addr=192.168.10.5" (as attached)



  File "/home/colosseum/Downloads/for_steve_gough2.py", line 37, in 
__init__

channels=range(5),
  File 
"/home/colosseum/src/gr-prefix/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py", 
line 122, in constructor_interceptor

return old_constructor(*args)
  File 
"/home/colosseum/src/gr-prefix/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", 
line 2686, in make

return _uhd_swig.usrp_source_make(*args)
NotImplementedError: Wrong number or type of arguments for overloaded 
function 'usrp_source_make'.

  Possible C/C++ prototypes are:
gr::uhd::usrp_source::make(::uhd::device_addr_t const 
&,::uhd::io_type_t const &,size_t)
gr::uhd::usrp_source::make(::uhd::device_addr_t const 
&,::uhd::stream_args_t const &,bool const)



I am not sure what else to try to get the two devices to sample-align.

Well, according your first instinct, and this doc here:

https://files.ettus.com/manual/page_multiple.html

The syntax should be:

"addr0=192.168.10.5,addr1=192.168.10.2"

BUT, there was this special mode for N210/USRP2 called "shared ethernet 
mode", and I think it keys on the two devices being on the same

  subhet, and connected by the MIMO cable.

Perhaps someone in R&D can confirm this, and that perhaps there is some 
internal confusion in UHD when the two addresses are on the same

  subnet, but not actually a "MIMO-cable pair".

In the meantime, if you have more than one 1GiGe interface, you can 
re-address one of them, and put it on its own subnet.






On Thu, May 31, 2018 at 1:36 PM, Marcus D. Leech > wrote:


On 05/31/2018 01:24 PM, Steve Gough wrote:

Oh, I meant I edited the python from the GRC which you had sent
to print the number of motherboards using UHD's get_num_mboards

(https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#ae4efbbc6480fba44939b34c78d44d7e9

),
and it returned 1.  I expected 2.

The GRC and a screenshot of the same is attached.

Simply running this flowgraph gives me the error :

  File "/home/colosseum/Downloads/for_steve_gough2.py", line 43,
in __init__
self.uhd_usrp_source_0.set_clock_source('external', 1)
  File

"/home/colosseum/src/gr-prefix/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 3706, in set_clock_source
return _uhd_swig.usrp_source_sptr_set_clock_source(self,
source, mboard)
RuntimeError: LookupError: IndexError: multi_usrp::mb_root(1) -
vector::_M_range_check: __n (which is 1) >= this->size() (which is 1)

Is there any particular cause of this error ?

This should Just Work(tm).

I'd forgotten that I'd written you a flow-graph to test
things.  sigh.

You still have a "," between the addresses.   Use a space.   The
"," separates parameters for a single mboard.




On Thu, May 31, 2018 at 1:02 PM, Marcus D. Leech
mailto:mle...@ripnet.com>> wrote:

On 05/31/2018 12:50 PM, Steve Gough wrote:

Thanks. That temporarily fixes the addressing issue.
However, I am now seeing the following error. Could you
please tell me why this might be happening?

File "/home/colosseum/Downloads/for_steve_gough.py", line
47, in __init__
self.uhd_usrp_source_0.set_clock_source('external', 1)
  File

"/home/colosseum/src/gr-prefix/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 3706, in set_clock_source
return _uhd_swig.usrp_source_sptr_set_clock_source(self,
source, mboard)
RuntimeError: LookupError: IndexError:
multi_usrp::mb_root(1) - vector::_M_range_check: __n (which
is 1) >= this->size() (which is 1)


It looks like with the "addr=192.168.10.5 addr=192.168.10.2"
device args, it thinks there is only 1 motherboard.
A check on self.uhd_usrp_source_0.get_num_mboards() replies
"1" . Shouldn't it actually be 2 ?

Thanks!

I can't recall at this point, but is this a GnuRadio (GRC,
even) flow-graph?

If so, there's a "number of Mboards" parameter -- it doesn't
get computed automatically.





On Wed, May 30, 2018 at 5:39 PM, Marcus D. Leech
mailto:mle...@ripnet.com>> wrote:

On 05/30/2018 04:45 PM, Steve Gough wrote:

Same error still, unfortunately even after setting the
gateway and subnet on the N210 via usrp_burn_mb_eeprom
and power-cycling.

Ah!

Try this in your device args:

"addr=192.168.10.5 addr=192.168.10.2"





For the N210:
|   | Mboard: N210r4
  

[USRP-users] [UHD] Python API branch updated

[Brent Stapleton via USRP-users]

Hello all,

The python-api UHD branch has been updated. This was a forced update, so
you'll need to manually reset if you're tracking this branch on git*. There
have been a few improvements since our last announcement, which I'll
quickly go over below.

We'd like to thank everyone who has contributed, through patches, or
responses on the RFC, or through various other methods of providing
feedback. There is still plenty of room for improvement on the Python API,
so please feel free to continue to post issues either here on the mailing
list, or on our Github issue tracker. After another round of testing and
feedback, if all goes well, we intend on merging the Python API into the
UHD master branch.


Executive Summary of Changes
- Added pyuhd_benchmark_rate.py, which is intended to be a Python API copy
of the C++ utility benchmark_rate.
- Removed memory leak in send/recv calls. In our Boost.Python bindings, we
had been incrementing reference counters of NumPy arrays, but not
decrementing them. This has been fixed.
- The Python GIL is now released during calls to send, recv, and
recv_async_msg. This should allow multi-threaded Python applications to run
with far better performance.
- Other small bugfixes/updates.

Best Regards,
Brent Stapleton
Ettus Research


* The following commands should update your local copy
$ git checkout python-api
$ git remote update
$ git reset --hard @{u}
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] change timestamp through GPIO

[RizThon via USRP-users]

Good day,

I plan getting a B210. I can call set_time_now with the UHD interface but
there must be latency involved, between the time I do the call and the time
it is updated. Can I set or reset the time through the GPIO?

My idea is to have a switching network piloted by Arduino or similar. The
code receiving the samples from B210 needs to know where those samples came
from. That's why I thought of changing the timestamp, so that the code
receiving could notice something happened (eg the time was reset or
modified).

Thanks.
Riz​
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] change timestamp through GPIO

[Marcus D. Leech via USRP-users]

On 05/31/2018 10:08 PM, RizThon via USRP-users wrote:

Good day,

I plan getting a B210. I can call set_time_now with the UHD interface 
but there must be latency involved, between the time I do the call and 
the time it is updated. Can I set or reset the time through the GPIO?


My idea is to have a switching network piloted by Arduino or similar. 
The code receiving the samples from B210 needs to know where those 
samples came from. That's why I thought of changing the timestamp, so 
that the code receiving could notice something happened (eg the time 
was reset or modified).


Thanks.
Riz​



You can use set_time_next_pps(), and use the PPS input as a trigger input.

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com