Re: [USRP-users] N310 with rfnoc-devel branch

[Rob Kossler via USRP-users]

Thanks for the explanation.  That make sense.  I suppose that I also could
have just pulled and recompiled MPM directly on the N310 (in lieu of
re-flashing the SD externally or using mender).

Rob

On Mon, Jul 23, 2018 at 12:55 PM Martin Braun 
wrote:

> On 07/23/2018 06:57 AM, Rob Kossler wrote:
> > Martin,
> > Re-flashing the SD card with the 3.12 image fixed my issue!
>
> Rob,
>
> that's great news, and I'm happy you're unstuck! I'm still not entirely
> sure what the exact reason is for this is, but here's a short analysis:
>
> On the N310, we use an architecture where a piece of software called
> 'MPM' runs on the device and handles most of the device-specific
> controls. Sometimes we need to fix bugs in MPM, which is a little more
> annoying than fixing bugs in UHD because it's a bit harder to update.
> However, whenever we change something which *requires* you to update
> MPM, we will bump a compat number.
> It looks like we made a change that would have required a compat number
> update, but we missed that and didn't change the compat number. The end
> result is that UHD 3.12 continued to happily work with MPM 3.11, but
> really shouldn't have. This explains why your 3.11 UHD was fine (because
> the device was running MPM 3.11), but your UHD 3.12 was only fine when
> you only updated MPM.
>
> Like I said, we normally would force users to upgrade by changing the
> compat number, which we didn't in this case. However, when issues like
> this pop up, a good thing to try is to update your SD card image. You
> don't have to remove the SD card in most cases, you can use our
> Mender-based workflow (see here:
> http://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_rasm_mender).
>
> Cheers,
> Martin
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] N310 with rfnoc-devel branch

[Martin Braun via USRP-users]

On 07/23/2018 06:57 AM, Rob Kossler wrote:
> Martin,
> Re-flashing the SD card with the 3.12 image fixed my issue!

Rob,

that's great news, and I'm happy you're unstuck! I'm still not entirely
sure what the exact reason is for this is, but here's a short analysis:

On the N310, we use an architecture where a piece of software called
'MPM' runs on the device and handles most of the device-specific
controls. Sometimes we need to fix bugs in MPM, which is a little more
annoying than fixing bugs in UHD because it's a bit harder to update.
However, whenever we change something which *requires* you to update
MPM, we will bump a compat number.
It looks like we made a change that would have required a compat number
update, but we missed that and didn't change the compat number. The end
result is that UHD 3.12 continued to happily work with MPM 3.11, but
really shouldn't have. This explains why your 3.11 UHD was fine (because
the device was running MPM 3.11), but your UHD 3.12 was only fine when
you only updated MPM.

Like I said, we normally would force users to upgrade by changing the
compat number, which we didn't in this case. However, when issues like
this pop up, a good thing to try is to update your SD card image. You
don't have to remove the SD card in most cases, you can use our
Mender-based workflow (see here:
http://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_rasm_mender).

Cheers,
Martin

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

Re: [USRP-users] N310 with rfnoc-devel branch

[Rob Kossler via USRP-users]

Martin,
Re-flashing the SD card with the 3.12 image fixed my issue!
Rob

On Thu, Jul 19, 2018 at 6:13 PM Rob Kossler  wrote:

> I think 3.11, but how do I check?
> I'm not sure if I mentioned or not, but I am running benchmark_rate from a
> host, not embedded.
>
> Rob
>
> On Thu, Jul 19, 2018 at 6:03 PM Martin Braun 
> wrote:
>
>> On 07/19/2018 02:50 PM, Rob Kossler wrote:
>> > Oops, I meant to say in the last email that I had confirmed the other
>> > fixes - sorry about my misleading remark.
>>
>> Actually, it was a misunderstanding on my part. Glad it works for you!
>>
>> >
>> > Yes, I tried with externally supplied PPS and configured with
>> > time_source arg setting.  Same result as with internal PPS.
>>
>> Hm, this isn't really telling us anything.
>> Which SD card are you using? One from 3.12, or 3.11?
>>
>> -- M
>>
>> > Rob
>> >
>> > On Thu, Jul 19, 2018 at 5:46 PM Martin Braun > > > wrote:
>> >
>> > On 07/19/2018 11:45 AM, Rob Kossler wrote:
>> > > Hi Martin,
>> > > I wanted to confirm that the recent fixes mentioned for some of
>> > the N310
>> > > issues I mentioned are indeed working well for me. These include
>> > > - Tx power output levels
>> > > - get_usrp_rx_info(), get_usrp_tx_info()
>> >
>> > Yes, these are fixed...
>> >
>> > > However, I am still stuck on this "No PPS Detected" error which
>> occurs
>> > > in the function "set_time_unknown_pps()" and is caused by
>> >
>> > ...but this, unfortunately, is not.
>> >
>> > > "get_time_last_pps()" always returning zero.  I realize that you
>> have
>> > > been unable to duplicate this behavior on your own N310
>> hardware.  Any
>> > > suggestions for me to try?
>> >
>> > What happens when you do connect an external clock/PPS and select
>> > external clock/time source? Does that make any difference?
>> >
>> > -- M
>> >
>> >
>> >
>> > > I have previously tried this using multiple workstations and
>> multiple
>> > > UHD versions.  With 3.11 or  maint, there is no error.  With 3.12
>> or
>> > > master or rfnoc-devel, the error occurs.  I have not tried with
>> > multiple
>> > > N310 because I only have one.
>> > >
>> > > rob
>> > >
>> > >
>> > > On Wed, Jul 18, 2018 at 11:54 AM Rob Kossler > > 
>> > > >> wrote:
>> > >
>> > > I just tried a separate computer and pulled the latest from
>> Master
>> > > (w/o using -DENABLE_RFNOC=ON during cmake).  Then I ran
>> > > images_downloader and image_loader and rebooted N310.  Same
>> bad
>> > > result as indicated previously (see 1st result below).  Then,
>> > > without changing anything, I used a 3.11 version (I did not
>> bother
>> > > pulling the latest), ran images downloader and image loader
>> and
>> > > rebooted the N310.  The same command line worked fine on this
>> > > version (see 2nd result below).
>> > >
>> > > *  1st RESULT 
>> > > $ benchmark_rate --rx_rate=12.5e6 --channels=0,1
>> > > [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609;
>> Boost_105800;
>> > > UHD_3.13.0.0-101-g2787e2de
>> > > [00:00:00.03] Creating the usrp device with: ...
>> > > [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
>> > >
>> >
>>   
>> mgmt_addr=192.168.160.2,type=n3xx,product=n310,serial=3144673,claimed=False,addr=192.168.160.2
>> > > [INFO] [MPM.PeriphManager] init() called with device args
>> > > `mgmt_addr=192.168.160.2,product=n310'.
>> > > [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
>> > > 0xF1F0D004)
>> > > [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1318 MB/s)
>> > > [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1347 MB/s)
>> > > [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1346 MB/s)
>> > > [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1330 MB/s)
>> > > [INFO] [0/Radio_0] Initializing block control (NOC ID:
>> > > 0x12AD10011312)
>> > > [INFO] [0/Radio_1] Initializing block control (NOC ID:
>> > > 0x12AD10011312)
>> > > [INFO] [0/DDC_0] Initializing block control (NOC ID:
>> > 0xDDC0)
>> > > [INFO] [0/DDC_1] Initializing block control (NOC ID:
>> > 0xDDC0)
>> > > [INFO] [0/DUC_0] Initializing block control (NOC ID:
>> > 0xD0C2)
>> > > [INFO] [0/DUC_1] Initializing block control (NOC ID:
>> > 0xD0C2)
>> > > Using Device: Single USRP:
>> > >   Device: N300-Series Device
>> > >   Mboard 0: ni-n3xx-3144673
>> > >   RX Channel: 0
>> > > RX DSP: 0
>> > > RX Dboard: A
>> > > RX Subdev: Magnesium
>> > >   RX Channel: 1
>> > > 

Re: [USRP-users] N310 with rfnoc-devel branch

[Rob Kossler via USRP-users]

I think 3.11, but how do I check?
I'm not sure if I mentioned or not, but I am running benchmark_rate from a
host, not embedded.

Rob

On Thu, Jul 19, 2018 at 6:03 PM Martin Braun  wrote:

> On 07/19/2018 02:50 PM, Rob Kossler wrote:
> > Oops, I meant to say in the last email that I had confirmed the other
> > fixes - sorry about my misleading remark.
>
> Actually, it was a misunderstanding on my part. Glad it works for you!
>
> >
> > Yes, I tried with externally supplied PPS and configured with
> > time_source arg setting.  Same result as with internal PPS.
>
> Hm, this isn't really telling us anything.
> Which SD card are you using? One from 3.12, or 3.11?
>
> -- M
>
> > Rob
> >
> > On Thu, Jul 19, 2018 at 5:46 PM Martin Braun  > > wrote:
> >
> > On 07/19/2018 11:45 AM, Rob Kossler wrote:
> > > Hi Martin,
> > > I wanted to confirm that the recent fixes mentioned for some of
> > the N310
> > > issues I mentioned are indeed working well for me. These include
> > > - Tx power output levels
> > > - get_usrp_rx_info(), get_usrp_tx_info()
> >
> > Yes, these are fixed...
> >
> > > However, I am still stuck on this "No PPS Detected" error which
> occurs
> > > in the function "set_time_unknown_pps()" and is caused by
> >
> > ...but this, unfortunately, is not.
> >
> > > "get_time_last_pps()" always returning zero.  I realize that you
> have
> > > been unable to duplicate this behavior on your own N310 hardware.
> Any
> > > suggestions for me to try?
> >
> > What happens when you do connect an external clock/PPS and select
> > external clock/time source? Does that make any difference?
> >
> > -- M
> >
> >
> >
> > > I have previously tried this using multiple workstations and
> multiple
> > > UHD versions.  With 3.11 or  maint, there is no error.  With 3.12
> or
> > > master or rfnoc-devel, the error occurs.  I have not tried with
> > multiple
> > > N310 because I only have one.
> > >
> > > rob
> > >
> > >
> > > On Wed, Jul 18, 2018 at 11:54 AM Rob Kossler  > 
> > > >> wrote:
> > >
> > > I just tried a separate computer and pulled the latest from
> Master
> > > (w/o using -DENABLE_RFNOC=ON during cmake).  Then I ran
> > > images_downloader and image_loader and rebooted N310.  Same bad
> > > result as indicated previously (see 1st result below).  Then,
> > > without changing anything, I used a 3.11 version (I did not
> bother
> > > pulling the latest), ran images downloader and image loader and
> > > rebooted the N310.  The same command line worked fine on this
> > > version (see 2nd result below).
> > >
> > > *  1st RESULT 
> > > $ benchmark_rate --rx_rate=12.5e6 --channels=0,1
> > > [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609;
> Boost_105800;
> > > UHD_3.13.0.0-101-g2787e2de
> > > [00:00:00.03] Creating the usrp device with: ...
> > > [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> > >
> >
>   
> mgmt_addr=192.168.160.2,type=n3xx,product=n310,serial=3144673,claimed=False,addr=192.168.160.2
> > > [INFO] [MPM.PeriphManager] init() called with device args
> > > `mgmt_addr=192.168.160.2,product=n310'.
> > > [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
> > > 0xF1F0D004)
> > > [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1318 MB/s)
> > > [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1347 MB/s)
> > > [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1346 MB/s)
> > > [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1330 MB/s)
> > > [INFO] [0/Radio_0] Initializing block control (NOC ID:
> > > 0x12AD10011312)
> > > [INFO] [0/Radio_1] Initializing block control (NOC ID:
> > > 0x12AD10011312)
> > > [INFO] [0/DDC_0] Initializing block control (NOC ID:
> > 0xDDC0)
> > > [INFO] [0/DDC_1] Initializing block control (NOC ID:
> > 0xDDC0)
> > > [INFO] [0/DUC_0] Initializing block control (NOC ID:
> > 0xD0C2)
> > > [INFO] [0/DUC_1] Initializing block control (NOC ID:
> > 0xD0C2)
> > > Using Device: Single USRP:
> > >   Device: N300-Series Device
> > >   Mboard 0: ni-n3xx-3144673
> > >   RX Channel: 0
> > > RX DSP: 0
> > > RX Dboard: A
> > > RX Subdev: Magnesium
> > >   RX Channel: 1
> > > RX DSP: 1
> > > RX Dboard: A
> > > RX Subdev: Magnesium
> > >   RX Channel: 2
> > > RX DSP: 0
> > > RX Dboard: B
> > > RX Subdev: Magnesium
> > >   RX Channel: 3
> > > RX DSP:

Re: [USRP-users] N310 with rfnoc-devel branch

[Martin Braun via USRP-users]

On 07/19/2018 02:50 PM, Rob Kossler wrote:
> Oops, I meant to say in the last email that I had confirmed the other
> fixes - sorry about my misleading remark.

Actually, it was a misunderstanding on my part. Glad it works for you!

> 
> Yes, I tried with externally supplied PPS and configured with
> time_source arg setting.  Same result as with internal PPS.

Hm, this isn't really telling us anything.
Which SD card are you using? One from 3.12, or 3.11?

-- M

> Rob
> 
> On Thu, Jul 19, 2018 at 5:46 PM Martin Braun  > wrote:
> 
> On 07/19/2018 11:45 AM, Rob Kossler wrote:
> > Hi Martin,
> > I wanted to confirm that the recent fixes mentioned for some of
> the N310
> > issues I mentioned are indeed working well for me. These include
> > - Tx power output levels
> > - get_usrp_rx_info(), get_usrp_tx_info()
> 
> Yes, these are fixed...
> 
> > However, I am still stuck on this "No PPS Detected" error which occurs
> > in the function "set_time_unknown_pps()" and is caused by
> 
> ...but this, unfortunately, is not.
> 
> > "get_time_last_pps()" always returning zero.  I realize that you have
> > been unable to duplicate this behavior on your own N310 hardware.  Any
> > suggestions for me to try? 
> 
> What happens when you do connect an external clock/PPS and select
> external clock/time source? Does that make any difference?
> 
> -- M
> 
> 
> 
> > I have previously tried this using multiple workstations and multiple
> > UHD versions.  With 3.11 or  maint, there is no error.  With 3.12 or
> > master or rfnoc-devel, the error occurs.  I have not tried with
> multiple
> > N310 because I only have one.
> >
> > rob
> >
> >
> > On Wed, Jul 18, 2018 at 11:54 AM Rob Kossler  
> > >> wrote:
> >
> >     I just tried a separate computer and pulled the latest from Master
> >     (w/o using -DENABLE_RFNOC=ON during cmake).  Then I ran
> >     images_downloader and image_loader and rebooted N310.  Same bad
> >     result as indicated previously (see 1st result below).  Then,
> >     without changing anything, I used a 3.11 version (I did not bother
> >     pulling the latest), ran images downloader and image loader and
> >     rebooted the N310.  The same command line worked fine on this
> >     version (see 2nd result below).
> >
> >     *  1st RESULT 
> >     $ benchmark_rate --rx_rate=12.5e6 --channels=0,1
> >     [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> >     UHD_3.13.0.0-101-g2787e2de
> >     [00:00:00.03] Creating the usrp device with: ...
> >     [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> >   
>  
> mgmt_addr=192.168.160.2,type=n3xx,product=n310,serial=3144673,claimed=False,addr=192.168.160.2
> >     [INFO] [MPM.PeriphManager] init() called with device args
> >     `mgmt_addr=192.168.160.2,product=n310'.
> >     [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
> >     0xF1F0D004)
> >     [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1318 MB/s)
> >     [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1347 MB/s)
> >     [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1346 MB/s)
> >     [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1330 MB/s)
> >     [INFO] [0/Radio_0] Initializing block control (NOC ID:
> >     0x12AD10011312)
> >     [INFO] [0/Radio_1] Initializing block control (NOC ID:
> >     0x12AD10011312)
> >     [INFO] [0/DDC_0] Initializing block control (NOC ID:
> 0xDDC0)
> >     [INFO] [0/DDC_1] Initializing block control (NOC ID:
> 0xDDC0)
> >     [INFO] [0/DUC_0] Initializing block control (NOC ID:
> 0xD0C2)
> >     [INFO] [0/DUC_1] Initializing block control (NOC ID:
> 0xD0C2)
> >     Using Device: Single USRP:
> >       Device: N300-Series Device
> >       Mboard 0: ni-n3xx-3144673
> >       RX Channel: 0
> >     RX DSP: 0
> >     RX Dboard: A
> >     RX Subdev: Magnesium
> >       RX Channel: 1
> >     RX DSP: 1
> >     RX Dboard: A
> >     RX Subdev: Magnesium
> >       RX Channel: 2
> >     RX DSP: 0
> >     RX Dboard: B
> >     RX Subdev: Magnesium
> >       RX Channel: 3
> >     RX DSP: 1
> >     RX Dboard: B
> >     RX Subdev: Magnesium
> >       TX Channel: 0
> >     TX DSP: 0
> >     TX Dboard: A
> >     TX Subdev: Magnesium
> >       TX Channel: 1
> >     TX DSP: 1
> >     TX Dboard: A
> >     TX Subdev: Magnesium
> >       TX Channel: 2
> >     TX DSP: 0
> >     TX Dboard: B
> >     

Re: [USRP-users] N310 with rfnoc-devel branch

[Rob Kossler via USRP-users]

Oops, I meant to say in the last email that I had confirmed the other fixes
- sorry about my misleading remark.

Yes, I tried with externally supplied PPS and configured with time_source
arg setting.  Same result as with internal PPS.
Rob

On Thu, Jul 19, 2018 at 5:46 PM Martin Braun  wrote:

> On 07/19/2018 11:45 AM, Rob Kossler wrote:
> > Hi Martin,
> > I wanted to confirm that the recent fixes mentioned for some of the N310
> > issues I mentioned are indeed working well for me. These include
> > - Tx power output levels
> > - get_usrp_rx_info(), get_usrp_tx_info()
>
> Yes, these are fixed...
>
> > However, I am still stuck on this "No PPS Detected" error which occurs
> > in the function "set_time_unknown_pps()" and is caused by
>
> ...but this, unfortunately, is not.
>
> > "get_time_last_pps()" always returning zero.  I realize that you have
> > been unable to duplicate this behavior on your own N310 hardware.  Any
> > suggestions for me to try?
>
> What happens when you do connect an external clock/PPS and select
> external clock/time source? Does that make any difference?
>
> -- M
>
>
>
> > I have previously tried this using multiple workstations and multiple
> > UHD versions.  With 3.11 or  maint, there is no error.  With 3.12 or
> > master or rfnoc-devel, the error occurs.  I have not tried with multiple
> > N310 because I only have one.
> >
> > rob
> >
> >
> > On Wed, Jul 18, 2018 at 11:54 AM Rob Kossler  > > wrote:
> >
> > I just tried a separate computer and pulled the latest from Master
> > (w/o using -DENABLE_RFNOC=ON during cmake).  Then I ran
> > images_downloader and image_loader and rebooted N310.  Same bad
> > result as indicated previously (see 1st result below).  Then,
> > without changing anything, I used a 3.11 version (I did not bother
> > pulling the latest), ran images downloader and image loader and
> > rebooted the N310.  The same command line worked fine on this
> > version (see 2nd result below).
> >
> > *  1st RESULT 
> > $ benchmark_rate --rx_rate=12.5e6 --channels=0,1
> > [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> > UHD_3.13.0.0-101-g2787e2de
> > [00:00:00.03] Creating the usrp device with: ...
> > [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> >
>  
> mgmt_addr=192.168.160.2,type=n3xx,product=n310,serial=3144673,claimed=False,addr=192.168.160.2
> > [INFO] [MPM.PeriphManager] init() called with device args
> > `mgmt_addr=192.168.160.2,product=n310'.
> > [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
> > 0xF1F0D004)
> > [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1318 MB/s)
> > [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1347 MB/s)
> > [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1346 MB/s)
> > [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1330 MB/s)
> > [INFO] [0/Radio_0] Initializing block control (NOC ID:
> > 0x12AD10011312)
> > [INFO] [0/Radio_1] Initializing block control (NOC ID:
> > 0x12AD10011312)
> > [INFO] [0/DDC_0] Initializing block control (NOC ID:
> 0xDDC0)
> > [INFO] [0/DDC_1] Initializing block control (NOC ID:
> 0xDDC0)
> > [INFO] [0/DUC_0] Initializing block control (NOC ID:
> 0xD0C2)
> > [INFO] [0/DUC_1] Initializing block control (NOC ID:
> 0xD0C2)
> > Using Device: Single USRP:
> >   Device: N300-Series Device
> >   Mboard 0: ni-n3xx-3144673
> >   RX Channel: 0
> > RX DSP: 0
> > RX Dboard: A
> > RX Subdev: Magnesium
> >   RX Channel: 1
> > RX DSP: 1
> > RX Dboard: A
> > RX Subdev: Magnesium
> >   RX Channel: 2
> > RX DSP: 0
> > RX Dboard: B
> > RX Subdev: Magnesium
> >   RX Channel: 3
> > RX DSP: 1
> > RX Dboard: B
> > RX Subdev: Magnesium
> >   TX Channel: 0
> > TX DSP: 0
> > TX Dboard: A
> > TX Subdev: Magnesium
> >   TX Channel: 1
> > TX DSP: 1
> > TX Dboard: A
> > TX Subdev: Magnesium
> >   TX Channel: 2
> > TX DSP: 0
> > TX Dboard: B
> > TX Subdev: Magnesium
> >   TX Channel: 3
> > TX DSP: 1
> > TX Dboard: B
> > TX Subdev: Magnesium
> >
> > [00:00:34.365399] Setting device timestamp to 0...
> > [INFO] [MULTI_USRP] 1) catch time transition at pps edge
> > Error: RuntimeError: Board 0 may not be getting a PPS signal!
> > No PPS detected within the time interval.
> > See the application notes for your device.
> >
> > irisheyes9@irisheyes9-Z240-SFF:~$
> >
> >
> > *  2nd RESULT 
> > $ benchmark_rate --rx_rate=12.5e6 --channels=0,1
> > [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> > UHD_3.11.1.UHD-3.11-0-gad6b0935
> > [00:00:00.03] Cr

Re: [USRP-users] N310 with rfnoc-devel branch

[Martin Braun via USRP-users]

On 07/19/2018 11:45 AM, Rob Kossler wrote:
> Hi Martin,
> I wanted to confirm that the recent fixes mentioned for some of the N310
> issues I mentioned are indeed working well for me. These include
> - Tx power output levels
> - get_usrp_rx_info(), get_usrp_tx_info()

Yes, these are fixed...

> However, I am still stuck on this "No PPS Detected" error which occurs
> in the function "set_time_unknown_pps()" and is caused by

...but this, unfortunately, is not.

> "get_time_last_pps()" always returning zero.  I realize that you have
> been unable to duplicate this behavior on your own N310 hardware.  Any
> suggestions for me to try?  

What happens when you do connect an external clock/PPS and select
external clock/time source? Does that make any difference?

-- M



> I have previously tried this using multiple workstations and multiple
> UHD versions.  With 3.11 or  maint, there is no error.  With 3.12 or
> master or rfnoc-devel, the error occurs.  I have not tried with multiple
> N310 because I only have one.
> 
> rob
> 
> 
> On Wed, Jul 18, 2018 at 11:54 AM Rob Kossler  > wrote:
> 
> I just tried a separate computer and pulled the latest from Master
> (w/o using -DENABLE_RFNOC=ON during cmake).  Then I ran
> images_downloader and image_loader and rebooted N310.  Same bad
> result as indicated previously (see 1st result below).  Then,
> without changing anything, I used a 3.11 version (I did not bother
> pulling the latest), ran images downloader and image loader and
> rebooted the N310.  The same command line worked fine on this
> version (see 2nd result below).
> 
> *  1st RESULT 
> $ benchmark_rate --rx_rate=12.5e6 --channels=0,1
> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_3.13.0.0-101-g2787e2de
> [00:00:00.03] Creating the usrp device with: ...
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> 
> mgmt_addr=192.168.160.2,type=n3xx,product=n310,serial=3144673,claimed=False,addr=192.168.160.2
> [INFO] [MPM.PeriphManager] init() called with device args
> `mgmt_addr=192.168.160.2,product=n310'.
> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
> 0xF1F0D004)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1318 MB/s)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1347 MB/s)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1346 MB/s)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1330 MB/s)
> [INFO] [0/Radio_0] Initializing block control (NOC ID:
> 0x12AD10011312)
> [INFO] [0/Radio_1] Initializing block control (NOC ID:
> 0x12AD10011312)
> [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
> [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0)
> [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2)
> [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C2)
> Using Device: Single USRP:
>   Device: N300-Series Device
>   Mboard 0: ni-n3xx-3144673
>   RX Channel: 0
>     RX DSP: 0
>     RX Dboard: A
>     RX Subdev: Magnesium
>   RX Channel: 1
>     RX DSP: 1
>     RX Dboard: A
>     RX Subdev: Magnesium
>   RX Channel: 2
>     RX DSP: 0
>     RX Dboard: B
>     RX Subdev: Magnesium
>   RX Channel: 3
>     RX DSP: 1
>     RX Dboard: B
>     RX Subdev: Magnesium
>   TX Channel: 0
>     TX DSP: 0
>     TX Dboard: A
>     TX Subdev: Magnesium
>   TX Channel: 1
>     TX DSP: 1
>     TX Dboard: A
>     TX Subdev: Magnesium
>   TX Channel: 2
>     TX DSP: 0
>     TX Dboard: B
>     TX Subdev: Magnesium
>   TX Channel: 3
>     TX DSP: 1
>     TX Dboard: B
>     TX Subdev: Magnesium
> 
> [00:00:34.365399] Setting device timestamp to 0...
> [INFO] [MULTI_USRP] 1) catch time transition at pps edge
> Error: RuntimeError: Board 0 may not be getting a PPS signal!
> No PPS detected within the time interval.
> See the application notes for your device.
> 
> irisheyes9@irisheyes9-Z240-SFF:~$
> 
> 
> *  2nd RESULT 
> $ benchmark_rate --rx_rate=12.5e6 --channels=0,1
> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_3.11.1.UHD-3.11-0-gad6b0935
> [00:00:00.03] Creating the usrp device with: ...
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> 
> mgmt_addr=192.168.160.2,type=n3xx,product=n310,serial=3144673,claimed=False,addr=192.168.160.2
> [INFO] [MPM.main] Spawning RPC process...
> [INFO] [MPM.PeriphManager] Device serial number: 3144673
> [INFO] [MPM.PeriphManager] Found 2 daughterboard(s).
> [INFO] [MPM.RPCServer] RPC server ready!
> [INFO] [MPM.RPCServer] Spawning watchdog task...
> [INFO] [MPM.PeriphManager] init() 

Re: [USRP-users] N310 with rfnoc-devel branch

[Rob Kossler via USRP-users]

Hi Martin,
I wanted to confirm that the recent fixes mentioned for some of the N310
issues I mentioned are indeed working well for me. These include
- Tx power output levels
- get_usrp_rx_info(), get_usrp_tx_info()

However, I am still stuck on this "No PPS Detected" error which occurs in
the function "set_time_unknown_pps()" and is caused by
"get_time_last_pps()" always returning zero.  I realize that you have been
unable to duplicate this behavior on your own N310 hardware.  Any
suggestions for me to try?

I have previously tried this using multiple workstations and multiple UHD
versions.  With 3.11 or  maint, there is no error.  With 3.12 or master or
rfnoc-devel, the error occurs.  I have not tried with multiple N310 because
I only have one.

rob


On Wed, Jul 18, 2018 at 11:54 AM Rob Kossler  wrote:

> I just tried a separate computer and pulled the latest from Master (w/o
> using -DENABLE_RFNOC=ON during cmake).  Then I ran images_downloader and
> image_loader and rebooted N310.  Same bad result as indicated previously
> (see 1st result below).  Then, without changing anything, I used a 3.11
> version (I did not bother pulling the latest), ran images downloader and
> image loader and rebooted the N310.  The same command line worked fine on
> this version (see 2nd result below).
>
> *  1st RESULT 
> $ benchmark_rate --rx_rate=12.5e6 --channels=0,1
> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_3.13.0.0-101-g2787e2de
> [00:00:00.03] Creating the usrp device with: ...
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> mgmt_addr=192.168.160.2,type=n3xx,product=n310,serial=3144673,claimed=False,addr=192.168.160.2
> [INFO] [MPM.PeriphManager] init() called with device args
> `mgmt_addr=192.168.160.2,product=n310'.
> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
> 0xF1F0D004)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1318 MB/s)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1347 MB/s)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1346 MB/s)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1330 MB/s)
> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10011312)
> [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD10011312)
> [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
> [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0)
> [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2)
> [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C2)
> Using Device: Single USRP:
>   Device: N300-Series Device
>   Mboard 0: ni-n3xx-3144673
>   RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: Magnesium
>   RX Channel: 1
> RX DSP: 1
> RX Dboard: A
> RX Subdev: Magnesium
>   RX Channel: 2
> RX DSP: 0
> RX Dboard: B
> RX Subdev: Magnesium
>   RX Channel: 3
> RX DSP: 1
> RX Dboard: B
> RX Subdev: Magnesium
>   TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: Magnesium
>   TX Channel: 1
> TX DSP: 1
> TX Dboard: A
> TX Subdev: Magnesium
>   TX Channel: 2
> TX DSP: 0
> TX Dboard: B
> TX Subdev: Magnesium
>   TX Channel: 3
> TX DSP: 1
> TX Dboard: B
> TX Subdev: Magnesium
>
> [00:00:34.365399] Setting device timestamp to 0...
> [INFO] [MULTI_USRP] 1) catch time transition at pps edge
> Error: RuntimeError: Board 0 may not be getting a PPS signal!
> No PPS detected within the time interval.
> See the application notes for your device.
>
> irisheyes9@irisheyes9-Z240-SFF:~$
>
>
> *  2nd RESULT 
> $ benchmark_rate --rx_rate=12.5e6 --channels=0,1
> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_3.11.1.UHD-3.11-0-gad6b0935
> [00:00:00.03] Creating the usrp device with: ...
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> mgmt_addr=192.168.160.2,type=n3xx,product=n310,serial=3144673,claimed=False,addr=192.168.160.2
> [INFO] [MPM.main] Spawning RPC process...
> [INFO] [MPM.PeriphManager] Device serial number: 3144673
> [INFO] [MPM.PeriphManager] Found 2 daughterboard(s).
> [INFO] [MPM.RPCServer] RPC server ready!
> [INFO] [MPM.RPCServer] Spawning watchdog task...
> [INFO] [MPM.PeriphManager] init() called with device args
> `product=n310,mgmt_addr=192.168.160.2'.
> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
> 0xF1F0D004)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1336 MB/s)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1340 MB/s)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1339 MB/s)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1337 MB/s)
> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1310)
> [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD1310)
> [INFO] [0/Radio_2] Initializing block control (NOC ID: 0x12AD1310)
> [INFO] [0/Radio_3] Initializing block control (NO

Re: [USRP-users] N310 with rfnoc-devel branch

[Rob Kossler via USRP-users]

I just tried a separate computer and pulled the latest from Master (w/o
using -DENABLE_RFNOC=ON during cmake).  Then I ran images_downloader and
image_loader and rebooted N310.  Same bad result as indicated previously
(see 1st result below).  Then, without changing anything, I used a 3.11
version (I did not bother pulling the latest), ran images downloader and
image loader and rebooted the N310.  The same command line worked fine on
this version (see 2nd result below).

*  1st RESULT 
$ benchmark_rate --rx_rate=12.5e6 --channels=0,1
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_3.13.0.0-101-g2787e2de
[00:00:00.03] Creating the usrp device with: ...
[INFO] [MPMD] Initializing 1 device(s) in parallel with args:
mgmt_addr=192.168.160.2,type=n3xx,product=n310,serial=3144673,claimed=False,addr=192.168.160.2
[INFO] [MPM.PeriphManager] init() called with device args
`mgmt_addr=192.168.160.2,product=n310'.
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D004)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1318 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1347 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1346 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1330 MB/s)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10011312)
[INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD10011312)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2)
[INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C2)
Using Device: Single USRP:
  Device: N300-Series Device
  Mboard 0: ni-n3xx-3144673
  RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: Magnesium
  RX Channel: 1
RX DSP: 1
RX Dboard: A
RX Subdev: Magnesium
  RX Channel: 2
RX DSP: 0
RX Dboard: B
RX Subdev: Magnesium
  RX Channel: 3
RX DSP: 1
RX Dboard: B
RX Subdev: Magnesium
  TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: Magnesium
  TX Channel: 1
TX DSP: 1
TX Dboard: A
TX Subdev: Magnesium
  TX Channel: 2
TX DSP: 0
TX Dboard: B
TX Subdev: Magnesium
  TX Channel: 3
TX DSP: 1
TX Dboard: B
TX Subdev: Magnesium

[00:00:34.365399] Setting device timestamp to 0...
[INFO] [MULTI_USRP] 1) catch time transition at pps edge
Error: RuntimeError: Board 0 may not be getting a PPS signal!
No PPS detected within the time interval.
See the application notes for your device.

irisheyes9@irisheyes9-Z240-SFF:~$


*  2nd RESULT 
$ benchmark_rate --rx_rate=12.5e6 --channels=0,1
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_3.11.1.UHD-3.11-0-gad6b0935
[00:00:00.03] Creating the usrp device with: ...
[INFO] [MPMD] Initializing 1 device(s) in parallel with args:
mgmt_addr=192.168.160.2,type=n3xx,product=n310,serial=3144673,claimed=False,addr=192.168.160.2
[INFO] [MPM.main] Spawning RPC process...
[INFO] [MPM.PeriphManager] Device serial number: 3144673
[INFO] [MPM.PeriphManager] Found 2 daughterboard(s).
[INFO] [MPM.RPCServer] RPC server ready!
[INFO] [MPM.RPCServer] Spawning watchdog task...
[INFO] [MPM.PeriphManager] init() called with device args
`product=n310,mgmt_addr=192.168.160.2'.
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D004)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1336 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1340 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1339 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1337 MB/s)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1310)
[INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD1310)
[INFO] [0/Radio_2] Initializing block control (NOC ID: 0x12AD1310)
[INFO] [0/Radio_3] Initializing block control (NOC ID: 0x12AD1310)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC1)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC1)
[INFO] [0/DDC_2] Initializing block control (NOC ID: 0xDDC1)
[INFO] [0/DDC_3] Initializing block control (NOC ID: 0xDDC1)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0)
[INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0)
[INFO] [0/DUC_2] Initializing block control (NOC ID: 0xD0C0)
[INFO] [0/DUC_3] Initializing block control (NOC ID: 0xD0C0)
Using Device: Single USRP:
  Device: N300-Series Device
  Mboard 0: ni-n3xx-3144673
  RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: Magnesium
  RX Channel: 1
RX DSP: 0
RX Dboard: B
RX Subdev: Magnesium
  RX Channel: 2
RX DSP: 0
RX Dboard: C
RX Subdev: Magnesium
  RX Channel: 3
RX DSP: 0
RX Dboard: D
RX Subdev: Magnesium
  TX Channel: 0
TX DSP

Re: [USRP-users] N310 with rfnoc-devel branch

[Martin Braun via USRP-users]

On 06/27/2018 11:31 AM, Rob Kossler via USRP-users wrote:
> Hi,
> I am getting some unexpected behavior from my N310 using the example
> 'tx_waveforms' utility and stock FPGA image using 'rfnoc-devel'.  If I
> simply switch to 'maint', things behave as expected.  Here are the issues...
> 
>  1. With 'rfnoc-devel', it is necessary for me to specify a subdev spec
> (A:0 A:1 B:0 B:1) in order to access all 4 channels. Otherwise, I
> can only see 2 channels. This is not a big problem, but wanted to
> mention it because it appears that the default subdev spec is not
> correct.  With 'maint', all 4 channels are available with default
> subdev spec.

Rob,

this is now fixed (on master, which has all the RFNoC stuff).

>  2. With 'rfnoc-devel', I get unexpected TX output power levels on the
> various channels when using the example program 'tx_waveforms' with
> the 'constant' waveform which produces a single tone at the carrier
> frequency (see table below).

Thanks for bringing this up, also, thanks for providing the graph in the
other thread. On master, this is now fixed.

>  3. With 'rfnoc-devel', I can only run 1 channel at a time. If I specify
> more than one channel (e.g., '--channels=0,1'), I get an error
> message that the PPS is not detected (even though using 'internal')
> and the example program crashes.  With 'maint', multiple channels
> work fine.

Even on the same commit hash, I don't see that issue. Can you please
check current HEAD of master again? I'd really like to get you unstuck
here, but I don't see a clear path forward.
It's very interesting this is not an issue on maint.

-- M


> 
> The table below shows the measured RF power levels (dBm) for a single
> tone output at 2400 MHz.  The tx_gain setting was 45 (20 dB below
> maximum) and there was about 31dB external attenuation.  So, for a
> measured power of -28 dBm, this implies that the maximum usrp output
> power is +23dBm (-28 + 20 + 31).
> 
> Channel    maint    rfnoc-devel
>    0   -27.8    -27.8* (some trials ~-67)
>    1   -27.9    -66.6* (some trials ~-27)
>    2   -27.6    -39.9* (some trials ~-67)
>    3   -27.6    -54.6* (consistent)
> 
> Details:
> 
>   * maint hash: ad6b0935
>   * rfnoc-devel hash: 1f8463cc
>   * command line: tx_waveforms --rate 20e6 --freq 2400e6 --gain 45
> --channels 
>   * os: ubuntu 16.04
> 
> Thank you.
> Rob
> 
> 
> ___
> 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] N310 with rfnoc-devel branch

[Rob Kossler via USRP-users]

Hi,
I am getting some unexpected behavior from my N310 using the example
'tx_waveforms' utility and stock FPGA image using 'rfnoc-devel'.  If I
simply switch to 'maint', things behave as expected.  Here are the issues...

   1. With 'rfnoc-devel', it is necessary for me to specify a subdev spec
   (A:0 A:1 B:0 B:1) in order to access all 4 channels. Otherwise, I can only
   see 2 channels. This is not a big problem, but wanted to mention it because
   it appears that the default subdev spec is not correct.  With 'maint', all
   4 channels are available with default subdev spec.
   2. With 'rfnoc-devel', I get unexpected TX output power levels on the
   various channels when using the example program 'tx_waveforms' with the
   'constant' waveform which produces a single tone at the carrier frequency
   (see table below).
   3. With 'rfnoc-devel', I can only run 1 channel at a time. If I specify
   more than one channel (e.g., '--channels=0,1'), I get an error message that
   the PPS is not detected (even though using 'internal') and the example
   program crashes.  With 'maint', multiple channels work fine.

The table below shows the measured RF power levels (dBm) for a single tone
output at 2400 MHz.  The tx_gain setting was 45 (20 dB below maximum) and
there was about 31dB external attenuation.  So, for a measured power of -28
dBm, this implies that the maximum usrp output power is +23dBm (-28 + 20 +
31).

Channelmaintrfnoc-devel
   0   -27.8-27.8* (some trials ~-67)
   1   -27.9-66.6* (some trials ~-27)
   2   -27.6-39.9* (some trials ~-67)
   3   -27.6-54.6* (consistent)

Details:

   - maint hash: ad6b0935
   - rfnoc-devel hash: 1f8463cc
   - command line: tx_waveforms --rate 20e6 --freq 2400e6 --gain 45
   --channels 
   - os: ubuntu 16.04

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