As I have mentioned a bit earlier, I have noticed that there was an issue
trying to run a no-Os setup but was not getting ACK from the TCA9548
expander. [Curious if anyone has gone the no-Os route and found an issue
there.]
I went ahead and proceeded to make a bin file from a HG bit file (used the
Xilinx SDK gui to generate a bin file.
The entry in the swif file is the following:
//arch = zynq; split = false; format = BIN
all:
{
/home/berhas1/fluffybunny/fluffy_with_NI/usrp3/top/n3xx/build-N310_HG/n3xx.bit
}
I copied the generated file into the SDcard /primary/lib/firmware folder
and renamed the n3xx.bit.bin to n310.bin.
My thought was that this bin file should work with the dtbo already there
in the design. After loading the bin file using fpga-manager (dto method)
or even hard rebooting the machine, it looks like the kernel is panicking
and not able to correctly load some drivers or addresses.
Does this mean that, even for a generic untouched HG design, i would have
to go through the process of making a dtbo (hence generating a device tree
from Xilinx SDK)?
Here is the terminal output when the error happens at bin file writing time:
[ OK ] Started Network Name Resolution.
[ OK ] Reached target Network.
[ OK ] Started Mender OTA update service.
[ OK ] Reached target Host and Network Name Lookups.
[ 12.860517] macb e000b000.ethernet eth0: link up (1000/Full)
[ 13.889925] fpga_manager fpga0: writing n310.bin to Xilinx Zynq FPGA
Manager
[ 15.012332] libphy: nixge_mii_bus: probed
[ 15.036810] libphy: nixge_mii_bus: probed
[ 15.040902] Unhandled fault: imprecise external abort (0x1406) at
0x004f1dcc
[ 15.047895] pgd = eddec000
[ 15.050572] [004f1dcc] *pgd=00000000
[ 15.054138] Internal error: : 1406 [#1] PREEMPT SMP ARM
[ 15.055350] nixge 40000000.ethernet sfp0: renamed from eth1
[ 15.064894] Modules linked in:
[ 15.067932] CPU: 0 PID: 194 Comm: python3 Not tainted
4.12.26-yocto-standard #1
[ 15.075225] Hardware name: Xilinx Zynq Platform
[ 15.079736] task: ee0063c0 task.stack: edde8000
[ 15.084259] PC is at nixge_mdio_read+0x90/0x180
[ 15.088763] LR is at 0x2800000
[ 15.091801] pc : [<c05ed5d8>] lr : [<02800000>] psr: 80030013
[ 15.091801] sp : edde9a58 ip : 00000018 fp : edde9a7c
[ 15.103270] r10: edcb5078 r9 : 00000003 r8 : 804dd639
[ 15.108467] r7 : 00000000 r6 : 000f4240 r5 : edc9f500 r4 : 00000081
[ 15.114980] r3 : ffffffff r2 : 00000008 r1 : 00000003 r0 : 803e93f9
[ 15.121491] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment
none
[ 15.128609] Control: 18c5387d Table: 2ddec04a DAC: 00000051
[ 15.134335] Process python3 (pid: 194, stack limit = 0xedde8210)
[ 15.140324] Stack: (0xedde9a58 to 0xeddea000)
[ 15.144663] 9a40:
ffffe000 00010000
[ 15.152834] 9a60: edcb5000 00000004 40010006 edcb5058 edde9abc edde9a80
c05dcc50 c05ed554
[ 15.161005] 9a80: edde9adc edde9a90 c016df5c c016d8a4 edde9ab4 edde9af4
00010000 edcb5000
[ 15.169166] 9aa0: 00000004 00000001 00000000 edcb5078 edde9adc edde9ac0
c05dab88 c05dcbf4
[ 15.177326] 9ac0: edcb5000 00000004 edde9af4 00000001 edde9b44 edde9ae0
c05dbf98 c05dab68
[ 15.185484] 9ae0: 00000000 edc0cb80 edde9b24 edde9af8 c06ed628 00000000
00000000 00000000
[ 15.193642] 9b00: 00000000 00000000 00000000 00000000 00000000 00000000
edde9b44 edc18300
[ 15.201802] 9b20: 00000001 edcb5000 00000004 00000000 00000000 edcb5078
edde9b74 edde9b48
[ 15.209962] 9b40: c06f4144 c05dbf30 edde9b74 edde9b58 c06f4564 c06ed6bc
edcb5000 edc18f80
[ 15.218120] 9b60: edc18300 00000004 edde9bac edde9b78 c06f46e4 c06f4050
00000000 00000000
[ 15.226280] 9b80: edde9ba4 edc9f000 edcb5000 ee00c200 edc9f500 edc18f80
00000006 00000000
[ 15.234440] 9ba0: edde9bdc edde9bb0 c05ed900 c06f45dc c0146e68 00000006
ee00c210 c05ed6c8
[ 15.242599] 9bc0: ee00c210 c0d80314 00000000 c0d80314 edde9bfc edde9be0
c05701c4 c05ed6d4
[ 15.250758] 9be0: ee00c210 c0e35150 00000000 00000000 edde9c24 edde9c00
c056e330 c0570170
[ 15.258917] 9c00: c0d80314 ee00c210 edde9c70 ee00c244 c0e3512c 00000000
edde9c44 edde9c28
[ 15.267076] 9c20: c056e5a0 c056e12c edde9c70 c056e4fc 00000000 ee00c244
edde9c6c edde9c48
[ 15.275235] 9c40: c056c7c8 c056e508 ef16e06c ee6d3d38 ee00c210 ee00c210
c0d73658 00000001
[ 15.283395] 9c60: edde9c94 edde9c70 c056e068 c056c73c ee00c210 00000001
ee00c210 c0d73658
[ 15.291554] 9c80: ee00c210 ef18ee10 edde9ca4 edde9c98 c056e5d4 c056dfc8
edde9cc4 edde9ca8
[ 15.299713] 9ca0: c056d600 c056e5c4 ee00c210 ee00c218 00000000 ef18ee10
edde9d04 edde9cc8
[ 15.307872] 9cc0: c056b858 c056d5d4 40008000 4000dfff ee04d100 00000200
00000000 ee00c200
[ 15.316031] 9ce0: edc18fd0 00000000 00000000 ef18ee10 ee235b28 00000000
edde9d14 edde9d08
[ 15.324191] 9d00: c06efc34 c056b450 edde9d3c edde9d18 c06f0160 c06efbfc
edde9dfc ef18ee00
[ 15.332350] 9d20: 00000001 edde9dfc c0d7a00c ee235b28 edde9d4c edde9d40
c06f01a4 c06f00e0
[ 15.340509] 9d40: edde9d74 edde9d50 c06f096c c06f0190 c0140ac8 c0644f44
c0d8f714 ffffffff
[ 15.348668] 9d60: 00000000 00000001 edde9d9c edde9d78 c0140ac8 c06f08f8
c0d8f714 c0d8f840
[ 15.356827] 9d80: 00000001 edde9dfc ffffffff ee235b28 edde9dcc edde9da0
c014104c c0140a84
[ 15.364986] 9da0: 00000000 edde9db0 c014108c ee04dbc0 ee04dbc0 ee228214
ee228204 ede00000
[ 15.373146] 9dc0: edde9de4 edde9dd0 c014108c c0141004 00000000 c06f131c
edde9df4 edde9de8
[ 15.381306] 9de0: c06f1334 c0141070 edde9e34 edde9df8 c06f1410 c06f131c
ee6b68f4 edc18f80
[ 15.389464] 9e00: 00000000 00000000 00000000 ee228214 ee228204 ede00000
edde9e34 edde9e28
[ 15.397624] 9e20: c0817008 ee228214 edde9e6c edde9e38 c06f1bdc c06f13a4
c06f52e8 c06ed298
[ 15.405782] 9e40: ee235b00 ee228200 00000005 00000000 ee228204 ee228200
00000006 00000000
[ 15.413942] 9e60: edde9ebc edde9e70 c06f59b8 c06f1b3c 00000000 ede02780
00000014 ee22821c
[ 15.422101] 9e80: ee235b30 ee228214 dfffbe9c 0000001e c06f26ac ef33d000
00000000 00000000
[ 15.430260] 9ea0: 00000000 00000009 edde9f80 ee3b6900 edde9ed4 edde9ec0
c06f0c58 c06f5764
[ 15.438419] 9ec0: ef33c000 ef33d000 edde9efc edde9ed8 c06f0dc0 c06f0bdc
00000009 00000009
[ 15.446579] 9ee0: edc4c680 00000000 edc4c698 edde9f80 edde9f34 edde9f00
c02d633c c06f0d2c
[ 15.454738] 9f00: ee25c000 00000051 edde9f80 c02d6200 00000009 0033cd70
edde9f80 00000000
[ 15.462897] 9f20: edde8000 00000000 edde9f4c edde9f38 c026645c c02d620c
ee3b6900 00000009
[ 15.471057] 9f40: edde9f7c edde9f50 c0267894 c0266440 c02853d4 c02852e0
ee3b6900 ee3b6900
[ 15.479215] 9f60: 0033cd70 00000009 c0107ca8 edde8000 edde9fa4 edde9f80
c02685a0 c02677d4
[ 15.487374] 9f80: 00000000 00000000 b6ec2000 b6f4d4e0 00022258 00000004
00000000 edde9fa8
[ 15.495533] 9fa0: c0107a80 c026855c b6ec2000 b6f4d4e0 00000009 0033cd70
00000009 00000000
[ 15.503692] 9fc0: b6ec2000 b6f4d4e0 00022258 00000004 00000009 0033cd70
00000000 b6ec2000
[ 15.511851] 9fe0: 00000064 beee9a88 b6e14b94 b6c6c124 600f0010 00000009
00000000 00000000
[ 15.520026] [<c05ed5d8>] (nixge_mdio_read) from [<c05dcc50>]
(mdiobus_read+0x68/0x154)
[ 15.527921] [<c05dcc50>] (mdiobus_read) from [<c05dab88>]
(get_phy_c45_devs_in_pkg+0x2c/0x74)
[ 15.536426] [<c05dab88>] (get_phy_c45_devs_in_pkg) from [<c05dbf98>]
(get_phy_device+0x74/0x1b4)
[ 15.545193] [<c05dbf98>] (get_phy_device) from [<c06f4144>]
(of_mdiobus_register_phy+0x100/0x10c)
[ 15.554042] [<c06f4144>] (of_mdiobus_register_phy) from [<c06f46e4>]
(of_mdiobus_register+0x114/0x208)
[ 15.563330] [<c06f46e4>] (of_mdiobus_register) from [<c05ed900>]
(nixge_probe+0x238/0x308)
[ 15.571580] [<c05ed900>] (nixge_probe) from [<c05701c4>]
(platform_drv_probe+0x60/0xac)
[ 15.579562] [<c05701c4>] (platform_drv_probe) from [<c056e330>]
(driver_probe_device+0x210/0x2d8)
[ 15.588415] [<c056e330>] (driver_probe_device) from [<c056e5a0>]
(__device_attach_driver+0xa4/0xbc)
[ 15.597441] [<c056e5a0>] (__device_attach_driver) from [<c056c7c8>]
(bus_for_each_drv+0x98/0xa0)
[ 15.606207] [<c056c7c8>] (bus_for_each_drv) from [<c056e068>]
(__device_attach+0xac/0x114)
[ 15.614452] [<c056e068>] (__device_attach) from [<c056e5d4>]
(device_initial_probe+0x1c/0x20)
[ 15.622959] [<c056e5d4>] (device_initial_probe) from [<c056d600>]
(bus_probe_device+0x38/0x90)
[ 15.631552] [<c056d600>] (bus_probe_device) from [<c056b858>]
(device_add+0x414/0x514)
[ 15.639455] [<c056b858>] (device_add) from [<c06efc34>]
(of_device_add+0x44/0x48)
[ 15.646918] [<c06efc34>] (of_device_add) from [<c06f0160>]
(of_platform_device_create_pdata+0x8c/0xb0)
[ 15.656208] [<c06f0160>] (of_platform_device_create_pdata) from
[<c06f01a4>] (of_platform_device_create+0x20/0x24)
[ 15.666539] [<c06f01a4>] (of_platform_device_create) from [<c06f096c>]
(of_platform_notify+0x80/0xf8)
[ 15.675741] [<c06f096c>] (of_platform_notify) from [<c0140ac8>]
(notifier_call_chain+0x50/0x74)
[ 15.684419] [<c0140ac8>] (notifier_call_chain) from [<c014104c>]
(__blocking_notifier_call_chain+0x54/0x6c)
[ 15.694140] [<c014104c>] (__blocking_notifier_call_chain) from
[<c014108c>] (blocking_notifier_call_chain+0x28/0x30)
[ 15.704645] [<c014108c>] (blocking_notifier_call_chain) from
[<c06f1334>] (of_reconfig_notify+0x24/0x3c)
[ 15.714105] [<c06f1334>] (of_reconfig_notify) from [<c06f1410>]
(__of_changeset_entry_notify+0x78/0xbc)
[ 15.723479] [<c06f1410>] (__of_changeset_entry_notify) from [<c06f1bdc>]
(__of_changeset_apply+0xac/0xbc)
[ 15.733027] [<c06f1bdc>] (__of_changeset_apply) from [<c06f59b8>]
(of_overlay_create+0x260/0x388)
[ 15.741878] [<c06f59b8>] (of_overlay_create) from [<c06f0c58>]
(create_overlay+0x88/0xb8)
[ 15.750037] [<c06f0c58>] (create_overlay) from [<c06f0dc0>]
(cfs_overlay_item_path_store+0xa0/0xdc)
[ 15.759066] [<c06f0dc0>] (cfs_overlay_item_path_store) from [<c02d633c>]
(configfs_write_file+0x13c/0x16c)
[ 15.768704] [<c02d633c>] (configfs_write_file) from [<c026645c>]
(__vfs_write+0x28/0x48)
[ 15.776772] [<c026645c>] (__vfs_write) from [<c0267894>]
(vfs_write+0xcc/0x158)
[ 15.784060] [<c0267894>] (vfs_write) from [<c02685a0>]
(SyS_write+0x50/0x88)
[ 15.791086] [<c02685a0>] (SyS_write) from [<c0107a80>]
(ret_fast_syscall+0x0/0x54)
[ 15.798640] Code: e0a79001 e5953094 e593301c f57ff04f (e3530000)
[ 15.804704] ---[ end trace e7a69dd64461ce03 ]---
Alchemy 2018.04 ni-n3xx-316A5C8 ttyPS0
Message: 1
> Date: Fri, 18 Oct 2019 08:59:10 -0700
> From: Robin Coxe <c...@quanttux.com>
> To: Samuel Berhanu <samberh...@gmail.com>
> Cc: Ettus Mail List <usrp-users@lists.ettus.com>
> Subject: Re: [USRP-users] N310 generation of a project/bit file from
> Ettus design (HG version)
> Message-ID:
> <
> cakjydkls+-9dzyl04e8m8sqnvaxlk4nhkee3mgrmwun3b9f...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> What version of Vivado are you using?
> For some reason, the manual on the Ettus website is for UHD version
> 3.15.0.0-69-gc350eb5a6, which requires 2018.3 and is not actually an
> official release.
> If memory serves, the actual tagged release (v.3.14.1.1) requires Vivado
> 2017.4.
>
> I've definitely created Vivado projects for the N310 with GUI=1...with
> Vivado 2017.4. Also, I don't think the schematic is actually correct, for
> the record.
>
> -Robin
>
> On Fri, Oct 18, 2019 at 8:33 AM Samuel Berhanu via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> > https://www.xilinx.com/support/answers/68238.html. This pretty much is
> > the issue.
> >
> >
> > On Fri, Oct 18, 2019 at 11:13 AM Samuel Berhanu <samberh...@gmail.com>
> > wrote:
> >
> >> Having difficulty creating a project to actually test out the N310 HG
> >> design. (I am having problems with a no-Os setup that I am trying to
> >> execute to find out what exactly the pin assignment should be for the
> MIOs.
> >> On a side note, the issue specifically is wrt I2C0, USB and TPM pin
> >> assignments. Schematics vs PS7 design does not seem to match up. Ettus
> >> support email from about a month ago stated schematic is right but now
> I am
> >> having second thoughts about it)
> >>
> >> Usually, when working with ettus products, I generate, using ettus'
> >> script with GUI=1, a project, which afterwards I save to make a tcl
> >> script for a project to impl and resynthesize it as my own project.
> >>
> >> Through this process, (mind you i have not gotten to regenerating a tcl
> >> script yet) (and this was a relatively easy fix), the custom packaged
> ips
> >> were not found and I had to insert them from (vivado_ipi) folder.
> >>
> >> Design went through synthesis fine. At implementation, though, I am
> >> seeing this error:
> >> (sub-design 'n310_ps_bd.bd is not generated for Synthesis target.
> Please
> >> open this sub-design and generate with synth_checkpoint_mode as
> signular in
> >> original project before adding it to current project'
> >>
> >> [image: Selection_062.bmp]
> >>
> >> I have made sure to get the ip report status, all ips are not locked.
> >>
> >> I have tried to search for answers online but nothing seems to pop up.
> >> Anyone has encountered this problem?
> >>
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20191018/4e3cf6ce/attachment-0001.html
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: Selection_062.bmp
> Type: image/bmp
> Size: 438030 bytes
> Desc: not available
> URL: <
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20191018/4e3cf6ce/attachment-0001.bmp
> >
>
> ------------------------------
>
> Message: 2
> Date: Fri, 18 Oct 2019 17:02:18 +0000
> From: Jason Matusiak <ja...@gardettoengineering.com>
> To: Samuel Berhanu <samberh...@gmail.com>, Robin Coxe
> <c...@quanttux.com>
> Cc: Ettus Mail List <usrp-users@lists.ettus.com>
> Subject: Re: [USRP-users] N310 generation of a project/bit file from
> Ettus design (HG version)
> Message-ID:
> <
> bl0pr12mb2340d0029b42a30ffd0bc314af...@bl0pr12mb2340.namprd12.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I just checked the repo based on the tag you mentioned and it is indeed
> 2017.4 (based on its setupenv.sh)
>
>
> https://github.com/EttusResearch/fpga/blob/bb85bdff45cad4da5008ab0c58749ce32797cea7/usrp3/top/n3xx/setupenv.sh
>
> ________________________________
> From: USRP-users <usrp-users-boun...@lists.ettus.com> on behalf of Robin
> Coxe via USRP-users <usrp-users@lists.ettus.com>
> Sent: Friday, October 18, 2019 11:59 AM
> To: Samuel Berhanu <samberh...@gmail.com>
> Cc: Ettus Mail List <usrp-users@lists.ettus.com>
> Subject: Re: [USRP-users] N310 generation of a project/bit file from Ettus
> design (HG version)
>
> What version of Vivado are you using?
> For some reason, the manual on the Ettus website is for UHD version
> 3.15.0.0-69-gc350eb5a6, which requires 2018.3 and is not actually an
> official release.
> If memory serves, the actual tagged release (v.3.14.1.1) requires Vivado
> 2017.4.
>
> I've definitely created Vivado projects for the N310 with GUI=1...with
> Vivado 2017.4. Also, I don't think the schematic is actually correct, for
> the record.
>
> -Robin
>
> On Fri, Oct 18, 2019 at 8:33 AM Samuel Berhanu via USRP-users <
> usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> wrote:
> https://www.xilinx.com/support/answers/68238.html<
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.xilinx.com_support_answers_68238.html&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=W_MQLyUWPXWHfsF4mr51mTMqpeO4RbBBLexficV9DG8&m=3eiW44eEXen8sH4bvJLonsYOrBQlSZTtEN1f0476lHE&s=-27ilFCQOwzFKD4xO7v0coUAB_WM_p_lm9RF391SBe4&e=>.
> This pretty much is the issue.
>
>
> On Fri, Oct 18, 2019 at 11:13 AM Samuel Berhanu <samberh...@gmail.com
> <mailto:samberh...@gmail.com>> wrote:
> Having difficulty creating a project to actually test out the N310 HG
> design. (I am having problems with a no-Os setup that I am trying to
> execute to find out what exactly the pin assignment should be for the MIOs.
> On a side note, the issue specifically is wrt I2C0, USB and TPM pin
> assignments. Schematics vs PS7 design does not seem to match up. Ettus
> support email from about a month ago stated schematic is right but now I am
> having second thoughts about it)
>
> Usually, when working with ettus products, I generate, using ettus' script
> with GUI=1, a project, which afterwards I save to make a tcl script for a
> project to impl and resynthesize it as my own project.
>
> Through this process, (mind you i have not gotten to regenerating a tcl
> script yet) (and this was a relatively easy fix), the custom packaged ips
> were not found and I had to insert them from (vivado_ipi) folder.
>
> Design went through synthesis fine. At implementation, though, I am
> seeing this error:
> (sub-design 'n310_ps_bd.bd<
> https://urldefense.proofpoint.com/v2/url?u=http-3A__n310-5Fps-5Fbd.bd&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=W_MQLyUWPXWHfsF4mr51mTMqpeO4RbBBLexficV9DG8&m=3eiW44eEXen8sH4bvJLonsYOrBQlSZTtEN1f0476lHE&s=v_uR1v1M6qpcMcrnOG4j6n9EfYEJR0E78MOBZDPHgvM&e=>
> is not generated for Synthesis target. Please open this sub-design and
> generate with synth_checkpoint_mode as signular in original project before
> adding it to current project'
>
> [Selection_062.bmp]
>
> I have made sure to get the ip report status, all ips are not locked.
>
> I have tried to search for answers online but nothing seems to pop up.
> Anyone has encountered this problem?
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com<
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=W_MQLyUWPXWHfsF4mr51mTMqpeO4RbBBLexficV9DG8&m=3eiW44eEXen8sH4bvJLonsYOrBQlSZTtEN1f0476lHE&s=OoJK6KBq8fqrN-m5Sj3kVA77pT_-zkwp3z52c-wWf3o&e=
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20191018/84b4c0ec/attachment-0001.html
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: Selection_062.bmp
> Type: image/bmp
> Size: 438030 bytes
> Desc: Selection_062.bmp
> URL: <
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20191018/84b4c0ec/attachment-0001.bmp
> >
>
> ------------------------------
>
> Message: 3
> Date: Fri, 18 Oct 2019 12:05:16 -0500
> From: Sam Reiter <sam.rei...@ettus.com>
> To: Carlos Bocanegra <carlos.bocanegra.gue...@gmail.com>
> Cc: usrp-users <usrp-users@lists.ettus.com>
> Subject: Re: [USRP-users] RX Misalignment on 6x1 MISO system using
> X310 and UBX-160
> Message-ID:
> <CANf970YRfCeFXYGaum=
> y4xoujz6mopb9pemtwpyd2hyeoup...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Carlos,
>
> On the host side if you're using a single streamer, it will work to
> time-align samples from every USRP as they come in. The reason you see 1002
> received packets without a timestamp match is because 1000 was the
> threshold for maximum number of alignment failures [1]. This can be
> changed or increased with [2]:
>
> set_alignment_failure_threshold(1000);
>
> But I doubt this will solve the issue for you. Likely just delay it.
> >From the errors you included, I'd say the real problem is:
>
>
> > *ERROR] [X300] 192.168.100.2 <http://192.168.100.2/>: x300 fw
> > communication failure #1EnvironmentError: IOError: x300 fw poke32 - reply
> > timed out*
> >
>
> There is either a backup or a lack of samples coming from the radio. Do you
> see flow control errors leading up to this failure?
>
> I'd say that pulling pieces out of this system would be a good way to start
> troubleshooting:
>
> - Drop the sample rate (what is it, by the way?) and see if there's a
> threshold where things start working [3]
> - Keep the original sample rate and try removing a radio or two from the
> system. Does this help things?
>
> It sounds like this is something you can reproduce independent of your DSP
> blocks, which helps simplify things a bit. If you could go a bit further
> and find a simple example (i.e. take one of the GNURadio UHD shipping
> examples and expand it to use 3x USRPs) and get it to reproduce the
> behavior, then I'd be happy to set something up on my end try to reproduce
> the behavior you're seeing.
>
> Sam
>
> [1]
>
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-August/053986.html
> [2]
>
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-January/036210.html
> [3]
>
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-November/039561.html
>
>
> On Thu, Oct 17, 2019 at 3:46 PM Carlos Bocanegra via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> > Hello community,
> >
> > I am working on a gnuradio application that synchronously retrieves data
> > from a usrp_source, does some DSP on each of the streams and selects the
> > signal to send on a usrp_sink based on some metric computation. The
> sources
> > and sinks represent 3 USRP X310 devices, each with 2 UBX-160
> > daughterboards, and are synchronized using an Octoclock-G. Thus,
> creating a
> > 6x1 MISO system. The USRP synchronization is done using the Python API,
> as
> > well as the flowgraph. The DSP blocks are coded in C++. The flowgraph
> would
> > be something like:
> >
> > *self.connect((usrp_source, 0), my_dsp_0, (my_switch, 0))*
> > *self.connect((usrp_source, 1), my_dsp_1, (my_switch, 1))*
> > *self.connect((usrp_source, 2), my_dsp_2, (my_switch, 2))*
> > *self.connect((usrp_source, 3), my_dsp_3, (my_switch, 3))*
> > *self.connect(my_switch, another_dsp_0, (usrp_sink, 0))*
> >
> > The application runs for a while until UHD outputs a message saying that
> > the poke32 has timed out on one of the USRP. After that, a misalignment
> > error on the receiver streams is shown and the green lights on the USRP
> go
> > off.
> >
> > We are under the impression that the DSP blocks working independently may
> > be requesting samples from the source at different times, causing the
> > misalignment. Could this be the case? Is there an issue with my network
> > connection?
> >
> > I have tried to get rid of the misalignment error by increasing the
> > threshold in the file
> > *{uhd_prefix}/host/lib/transport/super_recv_packet_handler.hpp, *through
> > the function *set_alignment_failure_threshold.* That got rid of the
> > misalignment error, but the failure coming from the poke function is
> still
> > there.
> >
> > Interestingly, the exact same behavior arises when I just connect
> > file_sinks to the outputs from the usrp_source and a simple analog signal
> > to the usrp_sink. Below the flowgraph:
> >
> > *self.connect((usrp_source, 0), file_sink_0)*
> > self.connect((usrp_source, 1), file_sink_1)
> > self.connect((usrp_source, 2), file_sink_2)
> > self.connect((usrp_source, 3), file_sink_3)
> > *self.connect(analog_sig_c, (usrp_sink, 0))*
> >
> > I'd appreciate any help on this since I'm running out of ideas here.
> > Please, find below more details.
> >
> > *The error:*
> >
> > * [ERROR] [X300] 192.168.100.2 <http://192.168.100.2>: x300 fw
> > communication failure #1EnvironmentError: IOError: x300 fw poke32 - reply
> > timed out*
> >
> > * [ERROR] [X300] 192.168.100.2 <http://192.168.100.2>: x300 fw
> > communication failure #1EnvironmentError: IOError: x300 fw poke32 - reply
> > timed out*
> >
> > * [ERROR] [X300] 192.168.100.2 <http://192.168.100.2>: x300 fw
> > communication failure #3EnvironmentError: IOError: x300 fw poke32 - reply
> > timed out*
> > [ERROR] [UHD] An unexpected exception was caught in a task loop.The task
> > loop will now exit, things may not work.EnvironmentError: IOError:
> > 192.168.100.2: x300 fw communication failure #3
> >
> >
> >
> > * [ERROR] [STREAMER] The receive packet handler failed to time-align
> > packets.1002 received packets were processed by the handler.However, a
> > timestamp match could not be determined.*
> >
> > *Here are some details of my network configuration:*
> > - UHD built from source, tag v3.14.1.1.
> > - Gnuradio built from source, tag 3.7.13.5.
> > - X310 USRP, each equipped with two UBX-160 daughterboards.
> > - The communication is over Ethernet using the 1Gb port on the X310.
> > - Each USRP is connected to a dedicated NIC.
> > - The MTU is set to 1500 for the all interfaces.
> > - The USRPs are synchronized using an Octoclock-G and the parameters
> tuned
> > in the Python script. The procedure is similar to the one followed in
> > benchmark_rate (uhd), for the usrp_source and usrp_sink.
> > - The NIC ring buffers are set to the maximum for both TX and RX, to
> 4096,
> > using ethtool.
> > - The OS ring buffers are set as suggested bu Ettus, using the following
> > commands:
> >
> >
> >
> > *>> sudo sysctl -w net.core.rmem_max=33554432 >> sudo sysctl -w
> > net.core.wmem_max=33554432 >> sudo sysctl -w
> > net.core.rmem_default=33554432 >> sudo sysctl -w
> > net.core.wmem_default=33554432*
> >
> > Best,
> > Carlos
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20191018/935a1d54/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 4
> Date: Fri, 18 Oct 2019 10:16:43 -0700
> From: Nate Temple <nate.tem...@ettus.com>
> To: Jason Matusiak <ja...@gardettoengineering.com>
> Cc: Samuel Berhanu <samberh...@gmail.com>, Robin Coxe
> <c...@quanttux.com>, Ettus Mail List <usrp-users@lists.ettus.com>
> Subject: Re: [USRP-users] N310 generation of a project/bit file from
> Ettus design (HG version)
> Message-ID:
> <CAL263iy-G0HvwzJxk1F542i06g3SdvVkAY=
> o8hdrfmf2g41...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi all,
>
> As Jason mentioned, UHD 3.14.x uses Vivado 2017.4. UHD 3.15.x.x which will
> be released soon bumps the Vivado dep to 2018.3. The current manual at
> uhd.ettus.com is built off the master branch, so it's a bit ahead of the
> release at the moment.
>
> We are working on adding in an archive of all previously tagged manuals so
> they will be easily accessible for reference.
>
> Note, when building UHD, the manual (for your version) is installed at
> $INSTALL_PREFIX/share/doc/uhd/doxygen/html
>
>
>
> Regards,
> Nate Temple
>
> On Fri, Oct 18, 2019 at 10:03 AM Jason Matusiak via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> > I just checked the repo based on the tag you mentioned and it is indeed
> > 2017.4 (based on its setupenv.sh)
> >
> >
> >
> https://github.com/EttusResearch/fpga/blob/bb85bdff45cad4da5008ab0c58749ce32797cea7/usrp3/top/n3xx/setupenv.sh
> >
> > ------------------------------
> > *From:* USRP-users <usrp-users-boun...@lists.ettus.com> on behalf of
> > Robin Coxe via USRP-users <usrp-users@lists.ettus.com>
> > *Sent:* Friday, October 18, 2019 11:59 AM
> > *To:* Samuel Berhanu <samberh...@gmail.com>
> > *Cc:* Ettus Mail List <usrp-users@lists.ettus.com>
> > *Subject:* Re: [USRP-users] N310 generation of a project/bit file from
> > Ettus design (HG version)
> >
> > What version of Vivado are you using?
> > For some reason, the manual on the Ettus website is for UHD version
> > 3.15.0.0-69-gc350eb5a6, which requires 2018.3 and is not actually an
> > official release.
> > If memory serves, the actual tagged release (v.3.14.1.1) requires Vivado
> > 2017.4.
> >
> > I've definitely created Vivado projects for the N310 with GUI=1...with
> > Vivado 2017.4. Also, I don't think the schematic is actually correct,
> for
> > the record.
> >
> > -Robin
> >
> > On Fri, Oct 18, 2019 at 8:33 AM Samuel Berhanu via USRP-users <
> > usrp-users@lists.ettus.com> wrote:
> >
> > https://www.xilinx.com/support/answers/68238.html
> > <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.xilinx.com_support_answers_68238.html&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=W_MQLyUWPXWHfsF4mr51mTMqpeO4RbBBLexficV9DG8&m=3eiW44eEXen8sH4bvJLonsYOrBQlSZTtEN1f0476lHE&s=-27ilFCQOwzFKD4xO7v0coUAB_WM_p_lm9RF391SBe4&e=
> >.
> > This pretty much is the issue.
> >
> >
> > On Fri, Oct 18, 2019 at 11:13 AM Samuel Berhanu <samberh...@gmail.com>
> > wrote:
> >
> > Having difficulty creating a project to actually test out the N310 HG
> > design. (I am having problems with a no-Os setup that I am trying to
> > execute to find out what exactly the pin assignment should be for the
> MIOs.
> > On a side note, the issue specifically is wrt I2C0, USB and TPM pin
> > assignments. Schematics vs PS7 design does not seem to match up. Ettus
> > support email from about a month ago stated schematic is right but now I
> am
> > having second thoughts about it)
> >
> > Usually, when working with ettus products, I generate, using ettus'
> script
> > with GUI=1, a project, which afterwards I save to make a tcl script
> for a
> > project to impl and resynthesize it as my own project.
> >
> > Through this process, (mind you i have not gotten to regenerating a tcl
> > script yet) (and this was a relatively easy fix), the custom packaged ips
> > were not found and I had to insert them from (vivado_ipi) folder.
> >
> > Design went through synthesis fine. At implementation, though, I am
> > seeing this error:
> > (sub-design 'n310_ps_bd.bd
> > <
> https://urldefense.proofpoint.com/v2/url?u=http-3A__n310-5Fps-5Fbd.bd&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=W_MQLyUWPXWHfsF4mr51mTMqpeO4RbBBLexficV9DG8&m=3eiW44eEXen8sH4bvJLonsYOrBQlSZTtEN1f0476lHE&s=v_uR1v1M6qpcMcrnOG4j6n9EfYEJR0E78MOBZDPHgvM&e=
> >
> > is not generated for Synthesis target. Please open this sub-design and
> > generate with synth_checkpoint_mode as signular in original project
> before
> > adding it to current project'
> >
> > [image: Selection_062.bmp]
> >
> > I have made sure to get the ip report status, all ips are not locked.
> >
> > I have tried to search for answers online but nothing seems to pop up.
> > Anyone has encountered this problem?
> >
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> > <
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=W_MQLyUWPXWHfsF4mr51mTMqpeO4RbBBLexficV9DG8&m=3eiW44eEXen8sH4bvJLonsYOrBQlSZTtEN1f0476lHE&s=OoJK6KBq8fqrN-m5Sj3kVA77pT_-zkwp3z52c-wWf3o&e=
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20191018/9ff6a316/attachment-0001.html
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: Selection_062.bmp
> Type: image/bmp
> Size: 438030 bytes
> Desc: not available
> URL: <
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20191018/9ff6a316/attachment-0001.bmp
> >
>
> ------------------------------
>
> Message: 5
> Date: Fri, 18 Oct 2019 14:42:10 -0400
> From: Marcus D Leech <patchvonbr...@gmail.com>
> To: Johannes Demel <de...@ant.uni-bremen.de>
> Cc: "usrp-users@lists.ettus.com" <USRP-users@lists.ettus.com>
> Subject: Re: [USRP-users] N310 sensitivity
> Message-ID: <9607ab49-8cf9-4ac9-ae90-33d4e2ca7...@gmail.com>
> Content-Type: text/plain; charset=utf-8
>
> What antenna are you specifying and which port are you rurally plugged in
> to.
>
> Are you using offset tuning? That may be necessary for Narrow signals
> near the tuned frequency, due to DC offset removal.
>
> Sent from my iPhone
>
> > On Oct 18, 2019, at 7:06 AM, Johannes Demel via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> >
> > ?Hi all,
> >
> > I figured out how to use our new N310s.
> >
> > I ran into the next issue. Let me describe this one briefly.
> >
> > With our X310s I set TXgain=20 and RX_gain=10. Both devices are 1-2m
> > apart. I observe a really nice RX constellation with gr-gfdm and
> > XFDMSync with bursts every 1ms (burst length ~50us). With our N310s I
> > set RXgain=60, TXgain=70 and still, the constellation is very noisy.
> > My assumption is that some part of the RX chain is not configured
> > correctly. But I don't know what the problem is in particular.
> > Also, I used an X310 as transmitter and an N310 as receiver. But the
> > result is the same, the RX constellation is really noisy.
> >
> > Another observation is, that my RX sample stream in a GR time sink does
> > show quantization artifacts. i.e. I can see discrete steps which I
> > assume are due to low RX sensitivity. The RX value amplitude is around
> > 0.0005 for the samples that I get of a USRP source. I assume this should
> > be a higher value. With the X310s it was more like 0.1.
> >
> > Do I need to take special care when I only use 1 antenna port?
> > Is there another AGC setting that I need to configure for N310s?
> >
> > Johannes
> >
> > Software
> > UHD: 3.14.1.1
> > GR: 3.8
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 18 Oct 2019 18:58:26 +0000
> From: Skorstad,J?rn <joern.skors...@nkom.no>
> To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
> Subject: [USRP-users] E310 packet size
> Message-ID: <eebdb6dc-867a-46ff-92f9-89a3480d8...@email.android.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi all,
>
> Still trying to understand some parts of the USRP that probably are quite
> elementary. When using the function get_max_num_samps it always reports
> 508. Does this mean that the number of samples returned for any requested
> sample rate will be decimated down to 508? Any way to change max_num_samps?
> Not using FPGA (yet).
>
> Cheers,
> Jorn
>
> ------------------------------
>
> Message: 7
> Date: Fri, 18 Oct 2019 15:18:38 -0400
> From: Saeid Hashemi <sae...@gmail.com>
> To: Michael Dickens <michael.dick...@ettus.com>
> Cc: usrp-users <usrp-users@lists.ettus.com>
> Subject: Re: [USRP-users] uhd_fft failure
> Message-ID:
> <
> canq3h3_guexukav6gqnjeuavliomyl_waqqopl655hyrs3_...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Okay, so installing python-six fixed that, and I was able to install
> 3.7.13.5 from source.
> The sample apps like uhd_fft are not in the path like they used to be with
> binary installation. And trying it from the apps folder gives me:
>
> nuc03@nuc03:/usr/local/bin$ /home/nuc03/gnuradio/gr-uhd/apps/uhd_fft
> Traceback (most recent call last):
> File "/home/nuc03/gnuradio/gr-uhd/apps/uhd_fft", line 39, in <module>
> import sip
> ImportError: No module named sip
>
>
> On Thu, Oct 17, 2019 at 10:26 AM Michael Dickens <
> michael.dick...@ettus.com>
> wrote:
>
> > Yes sorry about the GR37 release version: 3.7.13.5 is the correct on.
> > Installing Py27-six should be pretty straight forward & should allow you
> to
> > proceed with that install. GR38 has it's own set of dependencies, some of
> > which overlap with GR37 and some of which don't. You'll want to follow
> the
> > install guide for your OS to get those dependencies. Good luck! - MLD
> >
> > On Wed, Oct 16, 2019 at 3:02 PM Saeid Hashemi <sae...@gmail.com> wrote:
> >
> >> Hi Michael,
> >>
> >> The gnuradio git repository does not have a tag for v3.17.14.5, and
> using
> >> v3.7.13.5 gives me:
> >>
> >> -- Python checking for six - python 2 and 3 compatibility library
> >> -- Python checking for six - python 2 and 3 compatibility library - not
> >> found
> >> CMake Error at volk/CMakeLists.txt:98 (message):
> >> six - python 2 and 3 compatibility library required to build VOLK
> >>
> >>
> >> -- Configuring incomplete, errors occurred!
> >> See also "/home/nuc03/gnuradio/build/CMakeFiles/CMakeOutput.log".
> >> See also "/home/nuc03/gnuradio/build/CMakeFiles/CMakeError.log".
> >>
> >>
> >> Checking out tag v3.8.0.0 results in Cmake dependency of 3.8 and up, so
> I
> >> need to install that manually.
> >>
> >>
> >> On Sat, Oct 12, 2019 at 11:02 AM Michael Dickens <
> >> michael.dick...@ettus.com> wrote:
> >>
> >>> OK. Thanks for the info Saeid. I'll look into creating a VM using
> Ubuntu
> >>> 16.04.1 to see what happens. - MLD
> >>>
> >>> On Fri, Oct 11, 2019 at 4:47 PM Saeid Hashemi <sae...@gmail.com>
> wrote:
> >>>
> >>>> It's Ubuntu 16.04.1, but yes, I will follow the source build
> >>>> instructions.
> >>>>
> >>>> On Fri, Oct 11, 2019 at 3:11 PM Michael Dickens <
> >>>> michael.dick...@ettus.com> wrote:
> >>>>
> >>>>> Hi Saeid - Thanks for the followup. I totally agree that if you just
> >>>>> "sudo apt install gnuradio", compatible versions should be
> installed. Are
> >>>>> you using Ubuntu 16.04.6 LTS (Xenial Xerus)? If you choose to
> install from
> >>>>> source, you can follow instructions such as the GR recommended way
> here <
> >>>>>
> https://wiki.gnuradio.org/index.php/UbuntuInstall#Xenial_Xerus_.2816.04.29
> >>>>> >. I have an Ubuntu 18.04 install that went very smoothly using this
> guide,
> >>>>> but maybe the guide is outdated for older Ubuntu; or, our packages
> need to
> >>>>> be updated for that OS version ... Cheers! - MLD
> >>>>>
> >>>>> On Fri, Oct 11, 2019 at 2:24 PM Saeid Hashemi <sae...@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> I will follow your advice, but it's worth mentioning I simply did
> >>>>>> apt-get gnuradio and should therefore have a compatible version of
> uhd
> >>>>>> installed automatically as a dependency. I did not install uhd
> separately.
> >>>>>>
> >>>>> --
> >>>>> Michael Dickens
> >>>>> Ettus Research Technical Support
> >>>>> Email: supp...@ettus.com
> >>>>> Web: https://ettus.com/
> >>>>>
> >>>>
> >>>
> >>> --
> >>> Michael Dickens
> >>> Ettus Research Technical Support
> >>> Email: supp...@ettus.com
> >>> Web: https://ettus.com/
> >>>
> >>
> >
> > --
> > Michael Dickens
> > Ettus Research Technical Support
> > Email: supp...@ettus.com
> > Web: https://ettus.com/
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20191018/dc28a653/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 8
> Date: Fri, 18 Oct 2019 15:35:31 -0400
> From: Carlos Bocanegra <carlos.bocanegra.gue...@gmail.com>
> To: sam.rei...@ettus.com, patchvonbr...@gmail.com
> Cc: usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] RX Misalignment on 6x1 MISO system using
> X310 and UBX-160
> Message-ID:
> <
> caejwbw184pxfcq0bnqllmrgjjv0n_oyhepdwe9jt2kkmxae...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi all,
>
> Thanks a lot Sam and Marcus for replying so quickly.
>
> Le me first include Marcus answer in this email chain for a cleaner
> communication:
> "*Gnu Radio cannot really misalign samples, unless the DSP logic arranges
> for that to happen. If you have a block with a bunch of streams, that
> blocks "work" function cannot proceed until there is equal amounts of data
> available on all streams. In the absence of the hardware dropping samples,
> coherence is maintained in that case. What you are seeing here seems to be
> a problem with your network stack losing things. What type of Ethernet
> adapters do you have? What sample rates are you running?*"
>
> *The requested extra info:*
> - The sampling rates selected are *1Msps* for the TX and *2Msps* for the
> RX.
> - The SFP connector attached to the USRP-X310s: AVAGO, 1.25GBd, 1000BASE-T,
> ABCU-5730ARZ.
> - The NIC: Intel Corporation Gigabit CT Desktop Adapter.
> - The Ethernet controller: Intel Corporation 82574L Gigabit Network
> Connection.
>
> @Marcus,
> good thing that the scheduler in each block handles that correctly. I'll
> focus on the network setup then.
>
> @Sam,
> it seems reasonable to think that the source of error is the poking
> timeout, being the misalignment the aftermath.
> When you say flow controls, do you mean the ones handled by the UHD fw
> functions? I see a couple of D's (packet drops) right before the
> misalignment error, after the UHD raises the last poking exception. But
> maybe this is just the natural behavior- to drop misaligned packets before
> either getting an alignment or timing out and rising the exception.
>
> "*Drop the sample rate (what is it, by the way?) and see if there's a
> threshold where things start working [3]*":
> Should I drop the samples below 1Msps/2Msps? I think these are pretty low
> and having lower sampling rates would rise new problems. I can go ahead and
> try it if you still thing this is the issue.
> "*Keep the original sample rate and try removing a radio or two from the
> system. Does this help things?*"*:*
> - 4RX/1TX with simplistic flowgraph (usrp_source connected to file_sinks
> and analog signal connected to usrp_sink): OK.
> - 6RX/1TX with simplistic flowgraph (usrp_source connected to file_sinks
> and analog signal connected to usrp_sink): NOK (error described
> previously).
> - 3RX/1TX with my DSP blocks: OK.
> - 4RX/1TX with my DSP blocks: NOK (error described previously).
>
> Regarding an example, I could not find one that sets up a usrp_source AND a
> usrp_sink, in the folder {gr_prefix}/gr-uhd/examples/. I created a
> simplistic python flowgraph that results in the poking and misalignment
> issue, attached in this email. For instance, the 6x1 connections would map
> to the input argumments --tx_channels 1 --rx_channels 6.
>
> Thanks a lot for your time and I hope to hear back from you soon.
>
> Best,
> Carlos
>
>
> On Fri, Oct 18, 2019 at 1:05 PM Sam Reiter <sam.rei...@ettus.com> wrote:
>
> > Carlos,
> >
> > On the host side if you're using a single streamer, it will work to
> > time-align samples from every USRP as they come in. The reason you see
> 1002
> > received packets without a timestamp match is because 1000 was the
> > threshold for maximum number of alignment failures [1]. This can be
> > changed or increased with [2]:
> >
> > set_alignment_failure_threshold(1000);
> >
> > But I doubt this will solve the issue for you. Likely just delay it.
> From the errors you included, I'd say the real problem is:
> >
> >
> >> *ERROR] [X300] 192.168.100.2 <http://192.168.100.2/>: x300 fw
> >> communication failure #1EnvironmentError: IOError: x300 fw poke32 -
> reply
> >> timed out*
> >>
> >
> > There is either a backup or a lack of samples coming from the radio. Do
> > you see flow control errors leading up to this failure?
> >
> > I'd say that pulling pieces out of this system would be a good way to
> > start troubleshooting:
> >
> > - Drop the sample rate (what is it, by the way?) and see if there's a
> > threshold where things start working [3]
> > - Keep the original sample rate and try removing a radio or two from
> > the system. Does this help things?
> >
> > It sounds like this is something you can reproduce independent of your
> DSP
> > blocks, which helps simplify things a bit. If you could go a bit further
> > and find a simple example (i.e. take one of the GNURadio UHD shipping
> > examples and expand it to use 3x USRPs) and get it to reproduce the
> > behavior, then I'd be happy to set something up on my end try to
> reproduce
> > the behavior you're seeing.
> >
> > Sam
> >
> > [1]
> >
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-August/053986.html
> > [2]
> >
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-January/036210.html
> > [3]
> >
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-November/039561.html
> >
> >
> > On Thu, Oct 17, 2019 at 3:46 PM Carlos Bocanegra via USRP-users <
> > usrp-users@lists.ettus.com> wrote:
> >
> >> Hello community,
> >>
> >> I am working on a gnuradio application that synchronously retrieves data
> >> from a usrp_source, does some DSP on each of the streams and selects the
> >> signal to send on a usrp_sink based on some metric computation. The
> sources
> >> and sinks represent 3 USRP X310 devices, each with 2 UBX-160
> >> daughterboards, and are synchronized using an Octoclock-G. Thus,
> creating a
> >> 6x1 MISO system. The USRP synchronization is done using the Python API,
> as
> >> well as the flowgraph. The DSP blocks are coded in C++. The flowgraph
> would
> >> be something like:
> >>
> >> *self.connect((usrp_source, 0), my_dsp_0, (my_switch, 0))*
> >> *self.connect((usrp_source, 1), my_dsp_1, (my_switch, 1))*
> >> *self.connect((usrp_source, 2), my_dsp_2, (my_switch, 2))*
> >> *self.connect((usrp_source, 3), my_dsp_3, (my_switch, 3))*
> >> *self.connect(my_switch, another_dsp_0, (usrp_sink, 0))*
> >>
> >> The application runs for a while until UHD outputs a message saying that
> >> the poke32 has timed out on one of the USRP. After that, a misalignment
> >> error on the receiver streams is shown and the green lights on the USRP
> go
> >> off.
> >>
> >> We are under the impression that the DSP blocks working independently
> may
> >> be requesting samples from the source at different times, causing the
> >> misalignment. Could this be the case? Is there an issue with my network
> >> connection?
> >>
> >> I have tried to get rid of the misalignment error by increasing the
> >> threshold in the file
> >> *{uhd_prefix}/host/lib/transport/super_recv_packet_handler.hpp, *through
> >> the function *set_alignment_failure_threshold.* That got rid of the
> >> misalignment error, but the failure coming from the poke function is
> still
> >> there.
> >>
> >> Interestingly, the exact same behavior arises when I just connect
> >> file_sinks to the outputs from the usrp_source and a simple analog
> signal
> >> to the usrp_sink. Below the flowgraph:
> >>
> >> *self.connect((usrp_source, 0), file_sink_0)*
> >> self.connect((usrp_source, 1), file_sink_1)
> >> self.connect((usrp_source, 2), file_sink_2)
> >> self.connect((usrp_source, 3), file_sink_3)
> >> *self.connect(analog_sig_c, (usrp_sink, 0))*
> >>
> >> I'd appreciate any help on this since I'm running out of ideas here.
> >> Please, find below more details.
> >>
> >> *The error:*
> >>
> >> * [ERROR] [X300] 192.168.100.2 <http://192.168.100.2>: x300 fw
> >> communication failure #1EnvironmentError: IOError: x300 fw poke32 -
> reply
> >> timed out*
> >>
> >> * [ERROR] [X300] 192.168.100.2 <http://192.168.100.2>: x300 fw
> >> communication failure #1EnvironmentError: IOError: x300 fw poke32 -
> reply
> >> timed out*
> >>
> >> * [ERROR] [X300] 192.168.100.2 <http://192.168.100.2>: x300 fw
> >> communication failure #3EnvironmentError: IOError: x300 fw poke32 -
> reply
> >> timed out*
> >> [ERROR] [UHD] An unexpected exception was caught in a task loop.The
> task
> >> loop will now exit, things may not work.EnvironmentError: IOError:
> >> 192.168.100.2: x300 fw communication failure #3
> >>
> >>
> >>
> >> * [ERROR] [STREAMER] The receive packet handler failed to time-align
> >> packets.1002 received packets were processed by the handler.However, a
> >> timestamp match could not be determined.*
> >>
> >> *Here are some details of my network configuration:*
> >> - UHD built from source, tag v3.14.1.1.
> >> - Gnuradio built from source, tag 3.7.13.5.
> >> - X310 USRP, each equipped with two UBX-160 daughterboards.
> >> - The communication is over Ethernet using the 1Gb port on the X310.
> >> - Each USRP is connected to a dedicated NIC.
> >> - The MTU is set to 1500 for the all interfaces.
> >> - The USRPs are synchronized using an Octoclock-G and the parameters
> >> tuned in the Python script. The procedure is similar to the one
> followed in
> >> benchmark_rate (uhd), for the usrp_source and usrp_sink.
> >> - The NIC ring buffers are set to the maximum for both TX and RX, to
> >> 4096, using ethtool.
> >> - The OS ring buffers are set as suggested bu Ettus, using the following
> >> commands:
> >>
> >>
> >>
> >> *>> sudo sysctl -w net.core.rmem_max=33554432 >> sudo sysctl -w
> >> net.core.wmem_max=33554432 >> sudo sysctl -w
> >> net.core.rmem_default=33554432 >> sudo sysctl -w
> >> net.core.wmem_default=33554432*
> >>
> >> Best,
> >> Carlos
> >> _______________________________________________
> >> USRP-users mailing list
> >> USRP-users@lists.ettus.com
> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20191018/1ceaa3f8/attachment-0001.html
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: test_multiusrp.py
> Type: text/x-python
> Size: 9963 bytes
> Desc: not available
> URL: <
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20191018/1ceaa3f8/attachment-0001.py
> >
>
> ------------------------------
>
> Message: 9
> Date: Fri, 18 Oct 2019 17:47:01 -0400
> From: "Marcus D. Leech" <patchvonbr...@gmail.com>
> To: Carlos Bocanegra <carlos.bocanegra.gue...@gmail.com>,
> sam.rei...@ettus.com
> Cc: usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] RX Misalignment on 6x1 MISO system using
> X310 and UBX-160
> Message-ID: <5daa32d5.7070...@gmail.com>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
> On 10/18/2019 03:35 PM, Carlos Bocanegra wrote:
> > Hi all,
> >
> > Thanks a lot Sam and Marcus for replying so quickly.
> >
> > Le me first include Marcus answer in this email chain for a cleaner
> > communication:
> > "/Gnu Radio cannot really misalign samples, unless the DSP logic
> > arranges for that to happen. If you have a block with a bunch of
> > streams, that blocks "work" function cannot proceed until there is
> > equal amounts of data available on all streams. In the absence of the
> > hardware dropping samples, coherence is maintained in that case. What
> > you are seeing here seems to be a problem with your network stack
> > losing things. What type of Ethernet adapters do you have? What sample
> > rates are you running?/"
> >
> > *The requested extra info:*
> > - The sampling rates selected are _1Msps_ for the TX and _2Msps_ for
> > the RX.
> > - The SFP connector attached to the USRP-X310s: AVAGO, 1.25GBd,
> > 1000BASE-T, ABCU-5730ARZ.
> > - The NIC: Intel Corporation Gigabit CT Desktop Adapter.
> > - The Ethernet controller: Intel Corporation 82574L Gigabit Network
> > Connection.
> >
> > @Marcus,
> > good thing that the scheduler in each block handles that correctly.
> > I'll focus on the network setup then.
> >
> > @Sam,
> > it seems reasonable to think that the source of error is the poking
> > timeout, being the misalignment the aftermath.
> > When you say flow controls, do you mean the ones handled by the UHD fw
> > functions? I see a couple of D's (packet drops) right before the
> > misalignment error, after the UHD raises the last poking exception.
> > But maybe this is just the natural behavior- to drop misaligned
> > packets before either getting an alignment or timing out and rising
> > the exception.
> >
> > "/Drop the sample rate (what is it, by the way?) and see if there's a
> > threshold where things start working [3]/":
> > Should I drop the samples below 1Msps/2Msps? I think these are pretty
> > low and having lower sampling rates would rise new problems. I can go
> > ahead and try it if you still thing this is the issue.
> > "/Keep the original sample rate and try removing a radio or two from
> > the system. Does this help things?/"/:/
> > - 4RX/1TX with simplistic flowgraph (usrp_source connected to
> > file_sinks and analog signal connected to usrp_sink): OK.
> > - 6RX/1TX with simplistic flowgraph (usrp_source connected to
> > file_sinks and analog signal connected to usrp_sink): NOK (error
> > described previously).
> > - 3RX/1TX with my DSP blocks: OK.
> > - 4RX/1TX with my DSP blocks: NOK (error described previously).
> >
> > Regarding an example, I could not find one that sets up a usrp_source
> > AND a usrp_sink, in the folder {gr_prefix}/gr-uhd/examples/. I created
> > a simplistic python flowgraph that results in the poking and
> > misalignment issue, attached in this email. For instance, the 6x1
> > connections would map to the input argumments --tx_channels 1
> > --rx_channels 6.
> >
> > Thanks a lot for your time and I hope to hear back from you soon.
> >
> > Best,
> > Carlos
> >
> >
> I'll note that some members of the 82574L family of controllers are
> known to unnecessarily drop packets *particularly at unexpectedly-low flow
> rates*.
>
> This may or may not be contributing to your problem.
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20191018/262c8d60/attachment-0001.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> ------------------------------
>
> End of USRP-users Digest, Vol 110, Issue 16
> *******************************************
>
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
