Re: [USRP-users] N310 Sync With White Rabbit

[Cameron Matson via USRP-users]

Hello again,

Can anyone shed some light on this issue?  I found a similar reported issue
here that doesn't seemed to have been resolved either:

http://ettus.80997.x6.nabble.com/USRP-users-ERROR-RPC-TDC-Failed-to-reset-td15582.html

Thank you,
Cameron

On Sat, Dec 5, 2020 at 5:28 PM Cameron Matson  wrote:

> Hi all,
>
> I'm trying to use the White Rabbit switch to synchronize the acquisition
> across multiple N310s receivers.  I'm trying to use the instructions on
> this Ettus article:
>
>
> https://kb.ettus.com/Using_Ethernet-Based_Synchronization_on_the_USRP%E2%84%A2_N3xx_Devices
>
> I'm using the USRP sink block in gnuradio and set the "clock source" to
> "internal" and the "timing source" to "sfp0" as it indicates in the article
>
> [image: image.png]
> However I get the following error
>
> [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501;
> UHD_3.14.0.HEAD-0-g6875d061
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> mgmt_addr=192.168.3.2,
> type=n3xx,product=n310,serial=316A5C2,claimed=False,addr=192.168.3.2
> [INFO] [MPM.main] Launching USRP/MPM, version: 3.14.0.0-g6875d061
> [INFO] [MPM.main] Spawning RPC process...
> [INFO] [MPM.PeriphManager] Device serial number: 316A5C2
> [INFO] [MPM.PeriphManager] Initialized 2 daughterboard(s).
> [INFO] [MPM.PeriphManager] init() called with device args
> `clock_source=internal,time_source=internal'.
> [INFO] [MPM.RPCServer] RPC server ready!
> [INFO] [MPM.RPCServer] Spawning watchdog task...
> [INFO] [0/Replay_0] Initializing block control (NOC ID: 0x4E91A004)
> [INFO] [MPM.PeriphManager] init() called with device args
> `clock_source=internal,product=n310,mgmt_addr=192.168.3.2,time_source=internal'.
> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10011312)
> [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD10011312)
> [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
> [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0)
> [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2)
> [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C2)
> [INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0)
> [INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0)
> [INFO] [0/FIFO_2] Initializing block control (NOC ID: 0xF1F0)
> [INFO] [0/FIFO_3] Initializing block control (NOC ID: 0xF1F0)
> [ERROR] [RPC] TDC Failed to reset.
> Traceback (most recent call last):
>   File "/home/cmatson/data_lts/muddi_char/test_multi_radio.py", line 206,
> in 
> main()
>   File "/home/cmatson/data_lts/muddi_char/test_multi_radio.py", line 194,
> in main
> tb = top_block_cls()
>   File "/home/cmatson/data_lts/muddi_char/test_multi_radio.py", line 78,
> in __init__
> self.uhd_usrp_source_0.set_time_source('sfp0', 0)
>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> line 3067, in set_time_source
> return _uhd_swig.usrp_source_sptr_set_time_source(self, source, mboard)
> RuntimeError: RuntimeError: Error during RPC call to `set_time_source'.
> Error message: TDC Failed to reset.
> [INFO] [MPM.Magnesium-0] Re-initializing daughter board. This may take
> some time.
> [ERROR] [MPM.Sync-0] TDC Failed to Reset! Check your clocks! Status: 0x0
> [ERROR] [MPM.RPCServer] Uncaught exception in method set_time_source :TDC
> Failed to reset.
>  Traceback (most recent call last):
>   File "/usr/lib/python3.5/site-packages/usrp_mpm/rpc_server.py", line
> 182, in new_claimed_function
> return function(*args)
>   File "/usr/lib/python3.5/site-packages/usrp_mpm/periph_manager/n3xx.py",
> line 626, in set_time_source
> self.set_sync_source(source)
>   File "/usr/lib/python3.5/site-packages/usrp_mpm/periph_manager/n3xx.py",
> line 723, in set_sync_source
> skip_rfic=args.get('skip_rfic', None)
>   File
> "/usr/lib/python3.5/site-packages/usrp_mpm/dboard_manager/magnesium.py",
> line 385, in update_ref_clock_freq
> self._reinit(self.master_clock_rate)
>   File
> "/usr/lib/python3.5/site-packages/usrp_mpm/dboard_manager/magnesium.py",
> line 344, in _reinit
> self.init(args)
>   File
> "/usr/lib/python3.5/site-packages/usrp_mpm/dboard_manager/magnesium.py",
> line 293, in init
> args, self._init_args, fast_reinit)
>   File
> "/usr/lib/python3.5/site-packages/usrp_mpm/dboard_manager/mg_init.py", line
> 615, in init
> args
>   File
> "/usr/lib/python3.5/site-packages/usrp_mpm/dboard_manager/mg_init.py", line
> 555, in _full_init
> args)
>   File
> "/usr/lib/python3.5/site-packages/usrp_mpm/dboard_manager/mg_init.py", line
> 221, in _sync_db_clock
> target_offset=trace_delay_offset)
>   File "/usr/lib/python3.5/site-packages/usrp_mpm/cores/tdc_sync.py", line
> 201, in run
> self.configure(force=True)
>   File "/usr/lib/python3.5/site-packages/usrp_mpm/cores/tdc_sync.py", line
> 254, in configure
> raise RuntimeError("TDC Failed to 

Re: [USRP-users] Receiving on multiple subdevs using USRP B210

[Julian Arnold via USRP-users]

Saptarshi,

Ok, I see, you did not set set analog filter bandwidth of your USRP to 5 
MHz but your signal has 5 MHz bandwidth. This, in combination with the 
20 MHz MCR should then be absolutely fine.


I'm still not sure how you are trying to detect your signal. Maybe you 
could share the relevant parts of you flow-graph here?


I just tested what I thing you are doing (see attached image of 
flow-graph) and as far as I can tell, it is working as expected.
I'm feeding in a tone at 2.48 GHz on channel A and a tone at 2.475 GHz 
on channel B. After the message strobe triggered

(pmt.to_pmt({"chan":0, "lo_freq":2.475e9, "dsp_freq": -5e6}))
I receive both tones just fine.
I'm using GNU Radio 3.8.2 and UHD 3.15.

Cheers,
Julian


On 12/9/20 7:03 PM, saptarshiv2ha...@gmail.com wrote:

Hi Julian,

Thanks for your reply.
I am basically trying to receive signals of BW 5MHz at two different centre 
frequencies (2.475GHz and 2.48GHz) using the two subdevs of the B210.

The master clock rate gets set to 20MHz which makes me assume that the analog 
bandwidth for the USRP source is 20 MHz.
With a centre frequency of 2.475GHz, it should cover from 2.465GHz to 2.485GHz.

The main problem I have difficulty understanding is why it works in Case 1 and 
why it behaves randomly in Case 2.

Thanks,
Saptarshi


On 9 Dec 2020, at 15:49, Julian Arnold  wrote:

Saptarshi,

I'm not entirely sure I fully understand what you are doing. You probably need 
to provide some more details.

However, in general, depending on what you master-clock-rate is,
doing a 5MHz shift in the DSP does not make much sense if your
sample-rate and your analog bandwidth are only 5 MHz. There is just no signal 
at your 5MHz offset you could possibly shift down to base-band.

Cheers,
Julian

On 12/9/20 10:41 AM, Saptarshi Hazra via USRP-users wrote:

Hi,
I am trying to receive on two different centre frequencies (2.475e9 and 2.48e9) 
using the two receiver chains on B210. Since they are close by, I thought  can 
receive them by setting the “dsp_freq” parameter.
Case 1:
Subdev: A:A or A:B
Nchannel : 1
Centre Frequency: 2.475e9
Sampling Rate: 5e6
BW: 5e6
If I use the command port the USRP source block to pass a pmt dictionary:
pmt.to_pmt({“lo_freq”:2.475e9, “dsp_freq”: -5e6})
I am able to receive radio packets sent by nodes on 2.48e9 Hz
Case 2:
Subdev: A:A  A:B
Nchannel : 2
Sampling Rate: 5e6
Centre Frequency 1: 2.475e9
Centre Frequency 2: 2.475e9
BW: 5e6
I use the pmt dictionary:
pmt.to_pmt({“chan”:0, “lo_freq”:2.475e9, “dsp_freq”: -5e6})
When I do this sometimes I receive data from nodes transmitting on 2.48e9Hz.  
and sometimes on 2.475Hz. The behaviour becomes entirely random.
I would really appreciate any help in figuring out how to receive 
simultaneously on these two centre frequencies.
Thanks,
Saptarshi
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


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

Re: [USRP-users] E320 SFP speed/duplex question

[Jim Palladino via USRP-users]

Thanks again for the response and information. I'm seeing pretty much what you 
are. If I make a gnuradio flowgraph with a UHD:Usrp_Source connected to a 
Null_Sink, I can set the sample rate to 4MHz without overflows. With a sample 
rate of 5MHz, I see "O" repeating in the console. So the maximum throughput 
I am seeing is about 32*4MHz = 128Mbps. As you said, it is definitely higher 
than the 10Mbps reported by ethtool, but not as high as I need. Unfortunately, 
I don't have a 10Gbit interface available.

I started out with the SFP connected to a switch, through our company's 
network, and to my development machine. I thought maybe the extra 
infrastructure was the issue, even though an iperf throughput test (from the 
management port to my computer) showed about 480Mbps. I assumed the SFP port to 
my computer would allow for a similar throughput through the network. Anyhow, I 
ended up hooking the SFP directly to a 1gbps Ethernet port on my computer 
(taking the switch and network out of the loop). This made no difference in the 
throughput I can achieve. It's still a little over 100Mbps.

If you have any ideas what the throughput issue could be, I would greatly 
appreciate it. We really need to run at higher sample rates than I'm currently 
able to do.

Thanks,
Jim


From: Michael Dickens 
Sent: Wednesday, December 9, 2020 1:15 PM
To: Jim Palladino 
Cc: usrp-users@lists.ettus.com 
Subject: Re: [USRP-users] E320 SFP speed/duplex question

Hi Jim - Yes you are correct in the E320 FPGA image options: 1G, XG, and AA. I 
booted up my E320 to verify; forgot that there is just a single SFP+ port on 
the E320 ... I've been working with X310's and N310's for a while now, both of 
which have 2 SFP+ ports!

Since I'm on my E320, I tried out the XG and 1G FPGA images. Using "ethtool" as 
you noted, the XG image shows "Speed" of 1Mb/s, while the 1G image shows 
10Mb/s ... even though as you note the link modes are just "1000baseT/Half 
1000baseT/Full". Strange!

Using the "1G" FPGA image, I can sustain 2x2 MIMO at 1.45 M-Samples/second (but 
no 2 MS/s), with the wire format being SC16 (4 bytes per sample) ... that's 
92.8 Mb/s bidirectional .. so, clearly more than the 10 Mb/s noted by "ethtool" 
... much closer to 100 Mb/s link speed expect throughput (about 90% of 
theoretical) but nowhere near 1 Gb/s! Admittedly I had to move to a 1Gb link 
via a possibly-ill-configured-switch to get this to work at all, since my 
internal USRP testing network is a mix of SFP+ 10 Gb and QSFP+ 40 Gb links.

Using the "XG" FPGA image, I can sustain 2x2 MIMO at 60+ MS/s, which is good.

I'm not sure what's going on with the 1G FPGA image, but if the link works well 
enough for your needs then that's the bottom line here!

I believe the following is correct ... and I'm sure if I'm off a bit then 
someone will chime in to correct me :)

The Aurora FPGA image is built with the free Xilinx Aurora FPGA-IP, allowing 
for FPGA to FPGA high speed serial link. Think of it as a link-layer transport 
protocol, where one needs to create the higher-layer protocols to do actual 
data transport. Aurora was used in the DARPA SC2 Colosseum for high-speed 
transfer between USRPs and other FPGA processing devices. Aurora removes the 
internet protocol layers, providing direct access to the physical networking 
interface: bits in, bits out ... No ethernet, IP, UDP handling!

We provide a little information on the UHD manual for the E320 about Aurora:

* < 
https://files.ettus.com/manual/page_usrp_e3xx.html#e320_fpga_flavours
 >

{{{
The Aurora image can be used to run BISTs on the SFP.
}}}

* < 
https://files.ettus.com/manual/page_usrp_e3xx.html#e3xx_troubleshooting_bist
 >

{{{
E320 Built-in Self-Test (BiST)
The E320 series devices have a built-in self-test that can be used to verify 
the hardware. It is not automatically run, but it can be invoked anytime by 
running the e320_bist executable. Calling

e320_bist -h
will list the available options. Tests can be run by specifying their name, e.g.

e320_bist gpsdo
will test the functionality of the GPSDO. Calling e320_bist standard will run a 
standard set of tests, verifying some base peripherals such as the RTC, the fan 
and temperature sensors, etc.

Some tests require special hardware connected. For example, for the 
sfp_

Re: [USRP-users] E320 SFP speed/duplex question

[Michael Dickens via USRP-users]

Hi Jim - Yes you are correct in the E320 FPGA image options: 1G, XG, and
AA. I booted up my E320 to verify; forgot that there is just a single SFP+
port on the E320 ... I've been working with X310's and N310's for a while
now, both of which have 2 SFP+ ports!

Since I'm on my E320, I tried out the XG and 1G FPGA images. Using
"ethtool" as you noted, the XG image shows "Speed" of 1Mb/s, while the
1G image shows 10Mb/s ... even though as you note the link modes are just
"1000baseT/Half 1000baseT/Full". Strange!

Using the "1G" FPGA image, I can sustain 2x2 MIMO at 1.45 M-Samples/second
(but no 2 MS/s), with the wire format being SC16 (4 bytes per sample) ...
that's 92.8 Mb/s bidirectional .. so, clearly more than the 10 Mb/s noted
by "ethtool" ... much closer to 100 Mb/s link speed expect throughput
(about 90% of theoretical) but nowhere near 1 Gb/s! Admittedly I had to
move to a 1Gb link via a possibly-ill-configured-switch to get this to work
at all, since my internal USRP testing network is a mix of SFP+ 10 Gb and
QSFP+ 40 Gb links.

Using the "XG" FPGA image, I can sustain 2x2 MIMO at 60+ MS/s, which is
good.

I'm not sure what's going on with the 1G FPGA image, but if the link works
well enough for your needs then that's the bottom line here!

I believe the following is correct ... and I'm sure if I'm off a bit then
someone will chime in to correct me :)

The Aurora FPGA image is built with the free Xilinx Aurora FPGA-IP,
allowing for FPGA to FPGA high speed serial link. Think of it as a
link-layer transport protocol, where one needs to create the higher-layer
protocols to do actual data transport. Aurora was used in the DARPA
SC2 Colosseum for high-speed transfer between USRPs and other FPGA
processing devices. Aurora removes the internet protocol layers, providing
direct access to the physical networking interface: bits in, bits out
... No ethernet, IP, UDP handling!

We provide a little information on the UHD manual for the E320 about Aurora:

* < https://files.ettus.com/manual/page_usrp_e3xx.html#e320_fpga_flavours >

{{{
The Aurora image can be used to run BISTs on the SFP.
}}}

* <
https://files.ettus.com/manual/page_usrp_e3xx.html#e3xx_troubleshooting_bist
>

{{{
E320 Built-in Self-Test (BiST)
The E320 series devices have a built-in self-test that can be used to
verify the hardware. It is not automatically run, but it can be invoked
anytime by running the e320_bist executable. Calling

e320_bist -h
will list the available options. Tests can be run by specifying their name,
e.g.

e320_bist gpsdo
will test the functionality of the GPSDO. Calling e320_bist standard will
run a standard set of tests, verifying some base peripherals such as the
RTC, the fan and temperature sensors, etc.

Some tests require special hardware connected. For example, for the
sfp_loopback tests, a loopback module must be plugged into the SFP+.

Tests may also load different FPGA images, if required. The aforementioned
SFP tests will load the Aurora FPGA image and use Aurora to run the BER
tests on the SFP port. This is particularly relevant if either a custom
image was loaded, or if there is an active SSH or other connection coming
in via the SFP+ ports.
}}}

I hope this is useful! - MLD


On Wed, Dec 9, 2020 at 11:25 AM Jim Palladino 
wrote:

> Hi Michael,
>
> Thanks for the response. I did load the FPGA image again using "1G". My
> options are "1G", "XG", "AA". I still have the issue where linux/ethtool is
> still reporting a 10Mbps / half-duplex link on sfp0. Again, I'm able to
> stream data, so maybe things are working fine.
>
> Thanks,
> Jim
>
> --
> *From:* Michael Dickens 
> *Sent:* Wednesday, December 9, 2020 11:07 AM
> *To:* Jim Palladino 
> *Cc:* usrp-users@lists.ettus.com 
> *Subject:* Re: [USRP-users] E320 SFP speed/duplex question
>
> Hi Jim - Just for completion: Try loading the "HG" image -- again if
> necessary: 1 Gb on SFP+ port 0 and 10 Gb on SFP+ port 1. Regardless of
> whatever Linux / ifconfig / ethtool shows, the SFP+-based networking will
> not work if the link speeds are not met on both ends. All USRPs will set
> the correct speed via the FPGA: 1 Gb or 10 Gb, depending on the FPGA image
> used. The only way to get different link speeds is a different FPGA image.
> Once configured on both ends, if data transport is working then, if Linux /
> ifconfig / ethtool still shows 10 Gb link speed then, yes, something is off
> with those tools -- but, clearly the USRP is working as desired & that's
> the bottom line here hopefully! - MLD
>
>
> On Wed, Dec 9, 2020 at 9:44 AM Jim Palladino via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hello,
> I just setup an E320 with a 1Gbps SFP. I've updated the filesystem, FPGA
> load (with the "1G" build"), etc and am using UHD 4.0. uhd_usrp_probe seems
> happy, and I created a gnuradio flowgraph and streamed samples ok. I did
> not test throughput, though.
>
> What concerns me is that when I connect to the E320 via serial console

Re: [USRP-users] Receiving on multiple subdevs using USRP B210

[Saptarshi Hazra via USRP-users]

Hi Julian,

Thanks for your reply.
I am basically trying to receive signals of BW 5MHz at two different centre 
frequencies (2.475GHz and 2.48GHz) using the two subdevs of the B210.

The master clock rate gets set to 20MHz which makes me assume that the analog 
bandwidth for the USRP source is 20 MHz.
With a centre frequency of 2.475GHz, it should cover from 2.465GHz to 2.485GHz. 

The main problem I have difficulty understanding is why it works in Case 1 and 
why it behaves randomly in Case 2.

Thanks,
Saptarshi

> On 9 Dec 2020, at 15:49, Julian Arnold  wrote:
> 
> Saptarshi,
> 
> I'm not entirely sure I fully understand what you are doing. You probably 
> need to provide some more details.
> 
> However, in general, depending on what you master-clock-rate is,
> doing a 5MHz shift in the DSP does not make much sense if your
> sample-rate and your analog bandwidth are only 5 MHz. There is just no signal 
> at your 5MHz offset you could possibly shift down to base-band.
> 
> Cheers,
> Julian
> 
> On 12/9/20 10:41 AM, Saptarshi Hazra via USRP-users wrote:
>> Hi,
>> I am trying to receive on two different centre frequencies (2.475e9 and 
>> 2.48e9) using the two receiver chains on B210. Since they are close by, I 
>> thought  can receive them by setting the “dsp_freq” parameter.
>> Case 1:
>> Subdev: A:A or A:B
>> Nchannel : 1
>> Centre Frequency: 2.475e9
>> Sampling Rate: 5e6
>> BW: 5e6
>> If I use the command port the USRP source block to pass a pmt dictionary:
>> pmt.to_pmt({“lo_freq”:2.475e9, “dsp_freq”: -5e6})
>> I am able to receive radio packets sent by nodes on 2.48e9 Hz
>> Case 2:
>> Subdev: A:A  A:B
>> Nchannel : 2
>> Sampling Rate: 5e6
>> Centre Frequency 1: 2.475e9
>> Centre Frequency 2: 2.475e9
>> BW: 5e6
>> I use the pmt dictionary:
>> pmt.to_pmt({“chan”:0, “lo_freq”:2.475e9, “dsp_freq”: -5e6})
>> When I do this sometimes I receive data from nodes transmitting on 2.48e9Hz. 
>>  and sometimes on 2.475Hz. The behaviour becomes entirely random.
>> I would really appreciate any help in figuring out how to receive 
>> simultaneously on these two centre frequencies.
>> Thanks,
>> Saptarshi
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


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

Re: [USRP-users] E320 SFP speed/duplex question

[Jim Palladino via USRP-users]

Hi Michael,

Thanks for the response. I did load the FPGA image again using "1G". My options 
are "1G", "XG", "AA". I still have the issue where linux/ethtool is still 
reporting a 10Mbps / half-duplex link on sfp0. Again, I'm able to stream data, 
so maybe things are working fine.

Thanks,
Jim


From: Michael Dickens 
Sent: Wednesday, December 9, 2020 11:07 AM
To: Jim Palladino 
Cc: usrp-users@lists.ettus.com 
Subject: Re: [USRP-users] E320 SFP speed/duplex question

Hi Jim - Just for completion: Try loading the "HG" image -- again if necessary: 
1 Gb on SFP+ port 0 and 10 Gb on SFP+ port 1. Regardless of whatever Linux / 
ifconfig / ethtool shows, the SFP+-based networking will not work if the link 
speeds are not met on both ends. All USRPs will set the correct speed via the 
FPGA: 1 Gb or 10 Gb, depending on the FPGA image used. The only way to get 
different link speeds is a different FPGA image. Once configured on both ends, 
if data transport is working then, if Linux / ifconfig / ethtool still shows 10 
Gb link speed then, yes, something is off with those tools -- but, clearly the 
USRP is working as desired & that's the bottom line here hopefully! - MLD


On Wed, Dec 9, 2020 at 9:44 AM Jim Palladino via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
Hello,
I just setup an E320 with a 1Gbps SFP. I've updated the filesystem, FPGA load 
(with the "1G" build"), etc and am using UHD 4.0. uhd_usrp_probe seems happy, 
and I created a gnuradio flowgraph and streamed samples ok. I did not test 
throughput, though.

What concerns me is that when I connect to the E320 via serial console and 
boot, I see this:
[   23.592701] nixge 4000.ethernet sfp0: Link is Up - 10Mbps/Half - flow 
control off
[   23.733169] nixge 4002.ethernet int0: Link is Up - 10Mbps/Half - flow 
control off

If I check with ethtool on the E320, I see:

Settings for sfp0:
Supported ports: [ TP MII ]
Supported link modes:   1000baseT/Half 1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: No
Supported FEC modes: Not reported
Advertised link modes:  1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Speed: 10Mb/s
Duplex: Half
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: off
Link detected: yes


I know that the SFP is directly connected to the FPGA, and the load I put on 
the FPGA is for 1gbps. Is the ethtool reported speed of 10Mbps and duplex=half 
even meaningful?

By the way, our network switch that the sfp is ultimately connected to shows a 
1gbps/full duplex connection on that port.

I'm just a little confused with what is happening between linux/ethtool/ARM vs 
the FPGA SFP connection and whether or not I actually have a speed/duplex 
problem.

Thanks,
Jim

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

Re: [USRP-users] E320 SFP speed/duplex question

[Michael Dickens via USRP-users]

Hi Jim - Just for completion: Try loading the "HG" image -- again if
necessary: 1 Gb on SFP+ port 0 and 10 Gb on SFP+ port 1. Regardless of
whatever Linux / ifconfig / ethtool shows, the SFP+-based networking will
not work if the link speeds are not met on both ends. All USRPs will set
the correct speed via the FPGA: 1 Gb or 10 Gb, depending on the FPGA image
used. The only way to get different link speeds is a different FPGA image.
Once configured on both ends, if data transport is working then, if Linux /
ifconfig / ethtool still shows 10 Gb link speed then, yes, something is off
with those tools -- but, clearly the USRP is working as desired & that's
the bottom line here hopefully! - MLD


On Wed, Dec 9, 2020 at 9:44 AM Jim Palladino via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
> I just setup an E320 with a 1Gbps SFP. I've updated the filesystem, FPGA
> load (with the "1G" build"), etc and am using UHD 4.0. uhd_usrp_probe seems
> happy, and I created a gnuradio flowgraph and streamed samples ok. I did
> not test throughput, though.
>
> What concerns me is that when I connect to the E320 via serial console and
> boot, I see this:
> [   23.592701] nixge 4000.ethernet sfp0: Link is Up - 10Mbps/Half -
> flow control off
> [   23.733169] nixge 4002.ethernet int0: Link is Up - 10Mbps/Half -
> flow control off
>
> If I check with ethtool on the E320, I see:
> 
> Settings for sfp0:
> Supported ports: [ TP MII ]
> Supported link modes:   1000baseT/Half 1000baseT/Full
> Supported pause frame use: Symmetric Receive-only
> Supports auto-negotiation: No
> Supported FEC modes: Not reported
> Advertised link modes:  1000baseT/Half 1000baseT/Full
> Advertised pause frame use: Symmetric Receive-only
> Advertised auto-negotiation: No
> Advertised FEC modes: Not reported
> Speed: 10Mb/s
> Duplex: Half
> Port: MII
> PHYAD: 0
> Transceiver: internal
> Auto-negotiation: off
> Link detected: yes
> 
>
> I know that the SFP is directly connected to the FPGA, and the load I put
> on the FPGA is for 1gbps. Is the ethtool reported speed of 10Mbps and
> duplex=half even meaningful?
>
> By the way, our network switch that the sfp is ultimately connected to
> shows a 1gbps/full duplex connection on that port.
>
> I'm just a little confused with what is happening between
> linux/ethtool/ARM vs the FPGA SFP connection and whether or not I actually
> have a speed/duplex problem.
>
> Thanks,
> Jim
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] REMINDER: GR Amateur Radio video meeting

[Barry Duggan via USRP-users]

**Saturday 12 December 2020 16:00 UTC**

Subject: Transmit / Receive switching and station control
Presenter: Gavin Jacobs VE7GSJ
Agenda:

* Requirements for TX/RX switching
* VE7GSJ Solution (hardware & GNURadio Companion)
* Demo on 2m repeater

See the details at https://wiki.gnuradio.org/index.php/Talk:HamRadio

No registration required.

73,
--
Barry Duggan KV4FV
https://github.com/duggabe

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

Re: [USRP-users] Receiving on multiple subdevs using USRP B210

[Julian Arnold via USRP-users]

Saptarshi,

I'm not entirely sure I fully understand what you are doing. You 
probably need to provide some more details.


However, in general, depending on what you master-clock-rate is,
doing a 5MHz shift in the DSP does not make much sense if your
sample-rate and your analog bandwidth are only 5 MHz. There is just no 
signal at your 5MHz offset you could possibly shift down to base-band.


Cheers,
Julian

On 12/9/20 10:41 AM, Saptarshi Hazra via USRP-users wrote:

Hi,

I am trying to receive on two different centre frequencies (2.475e9 and 
2.48e9) using the two receiver chains on B210. Since they are close by, 
I thought  can receive them by setting the “dsp_freq” parameter.


Case 1:

Subdev: A:A or A:B
Nchannel : 1
Centre Frequency: 2.475e9
Sampling Rate: 5e6
BW: 5e6

If I use the command port the USRP source block to pass a pmt dictionary:

pmt.to_pmt({“lo_freq”:2.475e9, “dsp_freq”: -5e6})


I am able to receive radio packets sent by nodes on 2.48e9 Hz

Case 2:

Subdev: A:A  A:B
Nchannel : 2
Sampling Rate: 5e6
Centre Frequency 1: 2.475e9
Centre Frequency 2: 2.475e9
BW: 5e6

I use the pmt dictionary:

pmt.to_pmt({“chan”:0, “lo_freq”:2.475e9, “dsp_freq”: -5e6})



When I do this sometimes I receive data from nodes transmitting on 
2.48e9Hz.  and sometimes on 2.475Hz. The behaviour becomes entirely random.
I would really appreciate any help in figuring out how to receive 
simultaneously on these two centre frequencies.


Thanks,
Saptarshi

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



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

[USRP-users] E320 SFP speed/duplex question

[Jim Palladino via USRP-users]

Hello,
I just setup an E320 with a 1Gbps SFP. I've updated the filesystem, FPGA load 
(with the "1G" build"), etc and am using UHD 4.0. uhd_usrp_probe seems happy, 
and I created a gnuradio flowgraph and streamed samples ok. I did not test 
throughput, though.

What concerns me is that when I connect to the E320 via serial console and 
boot, I see this:
[   23.592701] nixge 4000.ethernet sfp0: Link is Up - 10Mbps/Half - flow 
control off
[   23.733169] nixge 4002.ethernet int0: Link is Up - 10Mbps/Half - flow 
control off

If I check with ethtool on the E320, I see:

Settings for sfp0:
Supported ports: [ TP MII ]
Supported link modes:   1000baseT/Half 1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: No
Supported FEC modes: Not reported
Advertised link modes:  1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Speed: 10Mb/s
Duplex: Half
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: off
Link detected: yes


I know that the SFP is directly connected to the FPGA, and the load I put on 
the FPGA is for 1gbps. Is the ethtool reported speed of 10Mbps and duplex=half 
even meaningful?

By the way, our network switch that the sfp is ultimately connected to shows a 
1gbps/full duplex connection on that port.

I'm just a little confused with what is happening between linux/ethtool/ARM vs 
the FPGA SFP connection and whether or not I actually have a speed/duplex 
problem.

Thanks,
Jim

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

[USRP-users] Receiver error ERROR_CODE_LATE_COMMAND with txrx_loopback_to_file example.

[Dylan Baros via USRP-users]

Good morning,

I am attempting to run the txrx_loopback_to_file example with the following 
hardware:

USRP N320 @ 192.168.20.2 10g sfp+ port 1
USRP N321 @ 192.168.10.2 10g sfp+ port 0

Connection between RF1 TX/RX on N321 to the RF1 RX on N320.

My command to run is:

./txrx_loopback_to_file \
--tx-args "type=n3xx,addr=192.168.10.2,master_clock_rate=250e6" \
--rx-args "type=n3xx,addr=192.168.20.2,master_clock_rate=250e6" \
--file "txrx_const0_rate50e6_sanslo_cw500e6_march3_11am.dat" \
--settling 5 \
--nsamps 5 \
--tx-rate 50e6 \
--rx-rate 50e6 \
--tx-freq 500e6 \
--rx-freq 500e6 \
--ampl .5 \
--tx-gain 10 \
--rx-gain 40 \
--tx-subdev "B:0" \
--rx-subdev "B:0" \
--tx-bw 10e6 \
--rx-bw 10e6 \
--wave-type "CONST" \
--wave-freq 0 \
--ref "external" \
--tx-channels 0 \
--rx-channels 0


Output:

Creating the transmit usrp device with: 
type=n3xx,addr=192.168.10.2,master_clock_rate=250e6...
[INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100; 
UHD_4.0.0.0-25-g1a34ba8a
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: 
mgmt_addr=192.168.10.2,type=n3xx,product=n320,serial=31EDB79,claimed=False,addr=192.168.10.2,master_clock_rate=250e6
[INFO] [MPM.main] Launching USRP/MPM, version: 4.0.0.0-g90ce6062
[INFO] [MPM.main] Spawning RPC process...
[INFO] [MPM.PeriphManager] Device serial number: 31EDB79
[INFO] [MPM.Rhodium-0] Enabling LO distribution board
[INFO] [MPM.Rhodium-0] Successfully loaded all peripherals!
[INFO] [MPM.Rhodium-1] Successfully loaded all peripherals!
[INFO] [MPM.PeriphManager] Initialized 2 daughterboard(s).
[INFO] [MPM.PeriphManager] No QSFP board detected: Assuming it is disabled in 
the device tree overlay (e.g., HG, XG images).
[INFO] [MPM.PeriphManager] init() called with device args 
`clock_source=internal,time_source=internal'.
[INFO] [MPM.Rhodium-0] init() called with args 
`clock_source=internal,time_source=internal'
[INFO] [MPM.Rhodium-1] init() called with args 
`clock_source=internal,time_source=internal'
[INFO] [MPM.Rhodium-1.init.LMK04828] LMK initialized and locked!
[INFO] [MPM.Rhodium-0.init.LMK04828] LMK initialized and locked!
[INFO] [MPM.Rhodium-1.DAC37J82] DAC PLL Locked!
[INFO] [MPM.Rhodium-1.AD9695] ADC PLL Locked!
[INFO] [MPM.Rhodium-1.init] JESD204B Link Initialization & Training Complete
[INFO] [MPM.Rhodium-0.DAC37J82] DAC PLL Locked!
[INFO] [MPM.Rhodium-0.AD9695] ADC PLL Locked!
[INFO] [MPM.Rhodium-0.init] JESD204B Link Initialization & Training Complete
[INFO] [MPM.RPCServer] RPC server ready!
[INFO] [MPM.RPCServer] Spawning watchdog task...
[INFO] [MPM.PeriphManager] init() called with device args 
`master_clock_rate=250e6,mgmt_addr=192.168.10.2,product=n320,clock_source=internal,time_source=internal'.
[INFO] [MPM.Rhodium-0] init() called with args 
`master_clock_rate=250e6,mgmt_addr=192.168.10.2,product=n320,clock_source=internal,time_source=internal'
[INFO] [MPM.Rhodium-1] init() called with args 
`master_clock_rate=250e6,mgmt_addr=192.168.10.2,product=n320,clock_source=internal,time_source=internal'
[INFO] [MPM.Rhodium-1.init.LMK04828] LMK initialized and locked!
[INFO] [MPM.Rhodium-0.init.LMK04828] LMK initialized and locked!
[INFO] [MPM.Rhodium-1.DAC37J82] DAC PLL Locked!
[INFO] [MPM.Rhodium-1.AD9695] ADC PLL Locked!
[INFO] [MPM.Rhodium-1.init] JESD204B Link Initialization & Training Complete
[INFO] [MPM.Rhodium-0.DAC37J82] DAC PLL Locked!
[INFO] [MPM.Rhodium-0.AD9695] ADC PLL Locked!
[INFO] [MPM.Rhodium-0.init] JESD204B Link Initialization & Training Complete

Creating the receive usrp device with: 
type=n3xx,addr=192.168.20.2,master_clock_rate=250e6...
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: 
mgmt_addr=192.168.20.2,type=n3xx,product=n320,serial=31F2BA2,claimed=False,addr=192.168.20.2,master_clock_rate=250e6
[INFO] [MPM.main] Launching USRP/MPM, version: 4.0.0.0-g90ce6062
[INFO] [MPM.main] Spawning RPC process...
[INFO] [MPM.PeriphManager] Device serial number: 31F2BA2
[INFO] [MPM.Rhodium-0] Successfully loaded all peripherals!
[INFO] [MPM.Rhodium-1] Successfully loaded all peripherals!
[INFO] [MPM.PeriphManager] Initialized 2 daughterboard(s).
[INFO] [MPM.PeriphManager] No QSFP board detected: Assuming it is disabled in 
the device tree overlay (e.g., HG, XG images).
[INFO] [MPM.PeriphManager] init() called with device args 
`clock_source=internal,time_source=internal'.
[INFO] [MPM.Rhodium-0] init() called with args 
`clock_source=internal,time_source=internal'
[INFO] [MPM.Rhodium-1] init() called with args 
`clock_source=internal,time_source=internal'
[INFO] [MPM.Rhodium-0.init.LMK04828] LMK initialized and locked!
[INFO] [MPM.Rhodium-1.init.LMK04828] LMK initialized and locked!
[INFO] [MPM.Rhodium-1.DAC37J82] DAC PLL Locked!
[INFO] [MPM.Rhodium-1.AD9695] ADC PLL Locked!
[INFO] [MPM.Rhodium-1.init] JESD204B Link Initialization & Training Complete
[INFO] [MPM.Rhodium-0.DAC37J82] DAC PLL Locked!
[INFO] [MPM.Rhodium-0.AD9695] ADC PLL Locked!
[INFO] [MPM.Rhodium-0.init] JESD204B Link Initialization & Training Complete
[INFO]

[USRP-users] Receiving on multiple subdevs using USRP B210

[Saptarshi Hazra via USRP-users]

Hi,

I am trying to receive on two different centre frequencies (2.475e9 and 2.48e9) 
using the two receiver chains on B210. Since they are close by, I thought  can 
receive them by setting the “dsp_freq” parameter.

Case 1:

Subdev: A:A or A:B
Nchannel : 1
Centre Frequency: 2.475e9
Sampling Rate: 5e6
BW: 5e6

If I use the command port the USRP source block to pass a pmt dictionary:

  pmt.to_pmt({“lo_freq”:2.475e9, “dsp_freq”: -5e6})


I am able to receive radio packets sent by nodes on 2.48e9 Hz

Case 2:

Subdev: A:A  A:B
Nchannel : 2
Sampling Rate: 5e6
Centre Frequency 1: 2.475e9
Centre Frequency 2: 2.475e9
BW: 5e6

I use the pmt dictionary:

pmt.to_pmt({“chan”:0, “lo_freq”:2.475e9, “dsp_freq”: -5e6})



When I do this sometimes I receive data from nodes transmitting on 2.48e9Hz.  
and sometimes on 2.475Hz. The behaviour becomes entirely random.
I would really appreciate any help in figuring out how to receive 
simultaneously on these two centre frequencies.

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