Problem ended up being the specific tag/repo version i made the bit file
from. The hash I was at was f114cfa0d. Curiously, the golden bitfile from
the Ettus server, at least for this specific version, does not load.
Colleague suggested to try it with a different bit file/version and that
seems to do the trick.
It still stumps me that I can't find out what the issue is with the I2C
expander but for now, I might have to give up on that considering the time
spent and no response.
On Tue, Oct 22, 2019 at 1:58 PM Samuel Berhanu <samberh...@gmail.com> wrote:
> 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
