Re: [USRP-users] using uhd_fft with usrp N210

[Kyeong Su Shin via USRP-users]

Dear Sung Bok,Lee:

You are using BasicRX/BasicTX daughterboards. These daughterboards do not
have any mixers, so they cannot 'tune' to any frequencies and you have to
supply your own RF frontends to get reasonable performances.  All these
daughterboards do for you is just buffering the ADC/DAC and then providing
SMA connectors for the connection. You have to use different daughterboards
if you do not want to come up with your own frontends and yet want to get
good signals.

If you use BasicRX/BasicTX and ask your USRP to tune to frequency x, it
will actually tune to an aliased frequency. USRP N200/N210 have native
sampling rate of 100MS/s. DAC sampling rate is rated to 400MS/s, but the
master clock is still at 100MS/s - it is just that the DAC is internally
interpolating the data you are inputting by 4x. So, if you ask it to tune
to 100MHz, it will tune to 0MHz instead - where the 100MHz signals will
alias onto.

Regards,
Kyeong Su Shin

On Mon, Nov 27, 2017 at 8:51 PM, 이성복 via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi
>
> I have 2Questions
>
> I was install Linus Ubuntu 16.04 LTS,
>
> sudo apt-get update
>
> sudo apt-get upgrade
>
> and install uhd and gnuradio (https://kb.ettus.com/
> Building_and_Installing_the_USRP_Open-Source_Toolchain_(
> UHD_and_GNU_Radio)_on_Linux)
>
> and  uhd_images_downloader
>
> uhd_image_loader --args="type=usrp2,addr=192.168.10.2"
>
> benchmark_rate --tx 10e6 --rx 10e6
>
> and test it  tx_waveforms --rate 10e6 --freq 100e6
>
> then
>
> Using Device: Single USRP:
>   Device: USRP2 / N-Series Device
>   Mboard 0: N210r4
>   RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: BasicRX (AB)
>   TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: BasicTX (AB)
>
>
>
> Setting TX Rate: 10.00 Msps...
> Actual TX Rate: 10.00 Msps...
>
> Setting TX Freq: 100.00 MHz...
> Actual TX Freq: 0.00 MHz...
>
>
>
> 1. Why Actual TX Freq is 0?? And when I run uhd_fft , I can see only 0hz
> signal. But I set center freq 100Mhz.
>
> 2.I try to example (uhd_tx_dpsk of gr-uhd) and run in gnuradio-companion
> and see flowgraph, but I measured signal using spectrum analyzer I can't
> see signal.
>
>   I put subdev A:AB in USRP SINK block and antenna is TX/RX. What should i
> do for transmit dpsk signal?
>
>
>
>
>
> Windows 10용 메일 에서 보냄
>
>
>
> ___
> 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] using uhd_fft with usrp N210

[Kyeong Su Shin via USRP-users]

Dear Sung Bok,Lee:

Forgot to mention - so, in short, all it can do is 'digitally' shifting
signals if you use BasicRX/BasicTX daughterboards. The analog frontends do
not filter any signals (although the daughterboards themselves act as poor
low pass filters with bandwidth of 250MHz), nor mix them down to any
frequencies. The 'tuning' that I mentioned in the second paragraph of the
previous e-mail is 'digitally' shifting down the signal (done by the USRP
motherboard's FPGA).

Regards,
Kyeong Su Shin

On Tue, Nov 28, 2017 at 6:41 AM, Kyeong Su Shin  wrote:

> Dear Sung Bok,Lee:
>
> You are using BasicRX/BasicTX daughterboards. These daughterboards do not
> have any mixers, so they cannot 'tune' to any frequencies and you have to
> supply your own RF frontends to get reasonable performances.  All these
> daughterboards do for you is just buffering the ADC/DAC and then providing
> SMA connectors for the connection. You have to use different daughterboards
> if you do not want to come up with your own frontends and yet want to get
> good signals.
>
> If you use BasicRX/BasicTX and ask your USRP to tune to frequency x, it
> will actually tune to an aliased frequency. USRP N200/N210 have native
> sampling rate of 100MS/s. DAC sampling rate is rated to 400MS/s, but the
> master clock is still at 100MS/s - it is just that the DAC is internally
> interpolating the data you are inputting by 4x. So, if you ask it to tune
> to 100MHz, it will tune to 0MHz instead - where the 100MHz signals will
> alias onto.
>
> Regards,
> Kyeong Su Shin
>
> On Mon, Nov 27, 2017 at 8:51 PM, 이성복 via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi
>>
>> I have 2Questions
>>
>> I was install Linus Ubuntu 16.04 LTS,
>>
>> sudo apt-get update
>>
>> sudo apt-get upgrade
>>
>> and install uhd and gnuradio (https://kb.ettus.com/Building
>> _and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_
>> Radio)_on_Linux)
>>
>> and  uhd_images_downloader
>>
>> uhd_image_loader --args="type=usrp2,addr=192.168.10.2"
>>
>> benchmark_rate --tx 10e6 --rx 10e6
>>
>> and test it  tx_waveforms --rate 10e6 --freq 100e6
>>
>> then
>>
>> Using Device: Single USRP:
>>   Device: USRP2 / N-Series Device
>>   Mboard 0: N210r4
>>   RX Channel: 0
>> RX DSP: 0
>> RX Dboard: A
>> RX Subdev: BasicRX (AB)
>>   TX Channel: 0
>> TX DSP: 0
>> TX Dboard: A
>> TX Subdev: BasicTX (AB)
>>
>>
>>
>> Setting TX Rate: 10.00 Msps...
>> Actual TX Rate: 10.00 Msps...
>>
>> Setting TX Freq: 100.00 MHz...
>> Actual TX Freq: 0.00 MHz...
>>
>>
>>
>> 1. Why Actual TX Freq is 0?? And when I run uhd_fft , I can see only 0hz
>> signal. But I set center freq 100Mhz.
>>
>> 2.I try to example (uhd_tx_dpsk of gr-uhd) and run in gnuradio-companion
>> and see flowgraph, but I measured signal using spectrum analyzer I can't
>> see signal.
>>
>>   I put subdev A:AB in USRP SINK block and antenna is TX/RX. What should
>> i do for transmit dpsk signal?
>>
>>
>>
>>
>>
>> Windows 10용 메일 에서 보냄
>>
>>
>>
>> ___
>> 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] issue with RFNoC signal generator block on X310 (TLDR)

[Dario Pennisi via USRP-users]

Hi,
A short question for which there is a larger underlying issue: if I connect a 
RX RFNoC Radio block to a TX RFNoC radio block, regardless of the presence of 
FIFOs in the middle nothing gets transmitted.
The only way it works seems to be by passing through the host by inserting two 
fifos and something like a mult const block on the host side so that data goes 
back and forth to/from the host.
Is there any reason this is happening?

Now the TL;DR part... for which I did this test:

I am developing a complex block with 3 inputs and 3 outputs. It is basically a 
transceiver block in which channels are configured this way:

In 0packet data in
In 1RF data in from RX0
In 2RF data in from RX1
Out 0 Packet data out
Out 1 RF Data out to TX0
Out 2 RF Data out to TX1

Basically I have a streaming input from the host that contains data packets 
that are modulated and output on one of the two RF ports that will be connected 
to radios.
On the opposite side I have two radio blocks connected to input ports 1 and 2 
and which are demodulated and output as packets on output port 0
Since rfnoc works at 200 MSPS by default and since bus does not have enough 
bandwidth I reduced system clock frequency to 120 MHz using device3 block in 
gnuradio. This way overall bandwidth (166 MHx x 64 bit) is still less than what 
I am handling (2x 120MSPS @ 32 bit + 1x very low bandwidth channel).
Rx side works perfectly while TX side seems to have an issue. First of all I 
want to transmit in bursts at given timestamps so my tuser packets would 
contain valid timestamp for first packet of the burst and will contain end of 
burst on the last packet. Unfortunately I have not gone as far as this since 
when I start transmitting I see that after a few packets my block receives a 
low ready which halts it after some packets (around 6).
Checking radio block I can see it receives some packets (less than the ones 
transmitted) and then it sets ready low after it sees tvalid low and 
subsequently status is set to underrun.
After this everything is locked up and I have to reprogram FPGA in order to 
restart it.
Suspecting that packets where too small I increased their size to the same of 
the signal generator block sample but with no results.
Now the question is what could be going wrong? It should not be an issue with 
bandwidth and I don't see why packets seem to be lost somewhere although I see 
that after a short while things freeze up and packets don't make it to the 
radio.
This is the reason why I tested the radio loopback and now I am suspecting 
there is some issue with UHD drivers that may not enable correctly all the 
routing paths if host is not in the loop for the tx part.

Thank you,

Dario Pennisi

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

Re: [USRP-users] Fwd: Re: USRP's B210 sluggish start of transmission

[Piotr Krysik via USRP-users]

W dniu 13.11.2017 o 11:36, Piotr Krysik via USRP-users pisze:
> Dear list,
>
> Little update on transmitting bursts and simultaneous receiving with
> USRP B210. When I connect anything that has some path between TX/RX SMA
> port's body and inner female sleeve contact (like 3dB attenuator or even
> my finger) the output signal starts to look ok. I don't know what is
> causing this and if it can be corrected with a firmware change (I'm not
> actively looking for the cause currently).

Another update:

With a log periodic antenna connected to Tx port (the 850-6500MHz one
from Ettus) everything works fine. With vertical antennas (like VERT900
or VERT2450 from Ettus) the mentioned problem appears.

I suppose that for all antennas that have connection between the active
pin and the ground it might work fine.

Best Regards,
Piotr Krysik

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

Re: [USRP-users] Ethernet over SFP+ in custom FPGA design (X3x0)

[Christian Lenz via USRP-users]

Ian and Sugandha,

thank you very much for your comments and also for the attached file.
Sadly, another three questions remain for the moment:
1. In the attached file, there is a series of 48? bits named "Ettus  
Padding". Is this an Ettus specific bit sequence and where can I find  
information on this?
2. If powering up and programming the FPGA, the clock from the PLL is  
not present because it must be programmed over SPI first. According to  
the HDL source files and pin constraints, the corresponding SPI master  
module in the FPGA is clocked  from a 125MHz clock. I assume this  
clock to be present without any configuration, is this true?
3. Do you know where to find the missing pages of the X3xx schematics  
document (13-17)? I would assume to find the 125MHz clock source on  
page 17.


Thanks a lot!

Zitat von Ian Buckley :


Christian,
CHDR packets are encapsulated in UDP/IP between Host and USRP. See  
the attachment.


PHY+ MAC functionality live under the x300_sfpp_io_core. However  
these blocks do not encapsulate/decapsulate the network packets.
All the ethernet/IP/UDP framing fields are added by chdr_eth_framer  
on egress, and will be removed on ingress by etc_dispatch (if needed).


-Ian





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

[USRP-users] RFNoC OOT Module Error with FPGA Image

[Avila, Jose A via USRP-users]

Hello we are getting the following error when probing the FPGA in X310 after 
installing the created bit file.


Error:Runtime error: Cannot get() on an uninitialized (empty) property.


The testbench runs successfully but after creating the bit file and uploading 
it into the SDR we get the error when probing.



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

[USRP-users] B210 simultaneous Tx and Rx at 32 MS/s

[Joan Olmos via USRP-users]

Hi,
I'm trying to transmit and receive simultaneously using B210 in single 
channel mode. The sampling rate for both Tx and Rx is 32 Msamples/s.


I have a recent desktop computer with USB 3 running Debian. The UHD 
version is 3.9 LTS. The Tx streamer is started first and then the Rx 
streamer (both have their own thread).


The problem is that Tx seems to work properly but the first time 
"uhd_rx_streamer_recv" function is called it returns immediately (with 
no samples) and in next call it never returns.


I'm using USRP auto setup of master clock rate. It works if I reduce the 
sampling rate to 16MS/s.


Which can be the problem?
Thanks!
These are my logs at start-up:

Creating USRP with args "type=b200,  num_recv_frames=512, 
num_send_frames=512"...

-- Detected Device: B210
-- Operating over USB 3.
-- Detecting internal GPSDO Found an internal GPSDO: GPSTCXO , 
Firmware Rev 0.929a

-- Initialize CODEC control...
-- Initialize Radio control...
-- Performing register loopback test... pass
-- Performing register loopback test... pass
-- Performing CODEC loopback test... pass
-- Performing CODEC loopback test... pass
-- Asking for clock rate 16.00 MHz...
-- Actually got clock rate 16.00 MHz.
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
-- Setting master clock rate selection to 'automatic'.
num. Rx channels reported by usrp: 2
num. Tx channels reported by usrp: 2
Subdevice Specification:
    Channel 0: Daughterboard A, Subdevice A
    Channel 1: Daughterboard A, Subdevice B

Subdevice Specification:
    Channel 0: Daughterboard A, Subdevice A
    Channel 1: Daughterboard A, Subdevice B

Device name: wicomtec-1 (30CD3EC)
Clock source reported by usrp: internal
-- 1) catch time transition at pps edge
-- 2) set times next pps (synchronously)
Corrected PC clock mismatch of: +1511908607310 milliseconds
Current Time reported by USRP: 1.001673 seconds
Current Time reported by PC: 1.001000 seconds
Normalized_rx_gain for channel 0 = 0.00
Normalized_rx_gain for channel 0 = 0.00
Setting Rate: 3200.00...
-- Asking for clock rate 32.00 MHz...
-- Actually got clock rate 32.00 MHz.
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
Actual Rate Rx(0): 3200.00...
Actual Rate Tx(0): 3200.00...
Actual Master clock rate: 3200.00

wire packet size: 2044 complex samples/packet, k: 1566
Setting frequencies: Rx: 2414.00, Tx: 2414.00 MHz...
Target RF frequency, clipped to be within system range: 241400.00
Target RF frequency, including RF FE offset: 241400.00
Frequency to which RF LO is actually tuned: 241399.761581
Frequency the CORDIC must adjust the RF: -0.238419
Frequency to which the CORDIC in the DSP actually tuned: -0.238419
Actual frequency Rx(0): 2414.00 MHz...
Actual frequency Tx(0): 2414.00 MHz...
Setting RX Gain: 50.00 dB...
Antenna reported by usrp for RX channel 0: RX2
Actual Rx(0) Gain: 50.00...
Rx: stream_args.cpu_format = fc32
Rx: stream_args.otw_format = sc16
Rx: stream_args.args = spp=2044
Rx: stream_args.channel_list = 0, 1
Rx: stream_args.n_channels = 1
max complex samps per wire packet = 2044
Available sensors:
temp
rssi
lo_locked
Checking RX: LO: locked ...
Rx buffer size in samples: 3200904
Setting TX Gain: 50.00 dB...
Antenna reported by usrp for TX channel 0: TX/RX
Actual TX Gain: 50.00...
Tx: stream_args.cpu_format = fc32
Tx: stream_args.otw_format = sc16
Tx: stream_args.args = spp=2044
Tx: stream_args.channel_list = 0, 1
Tx: stream_args.n_channels = 1
max complex samps per wire packet = 2044
Available sensors:
temp
lo_locked
Checking TX: LO: locked ...
Tx buffer size in samples: 3200904
configusrp: Success

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

Re: [USRP-users] B210 simultaneous Tx and Rx at 32 MS/s

[Marcus D. Leech via USRP-users]

On 11/28/2017 06:11 PM, Joan Olmos via USRP-users wrote:

Hi,
I'm trying to transmit and receive simultaneously using B210 in single 
channel mode. The sampling rate for both Tx and Rx is 32 Msamples/s.


I have a recent desktop computer with USB 3 running Debian. The UHD 
version is 3.9 LTS. The Tx streamer is started first and then the Rx 
streamer (both have their own thread).


The problem is that Tx seems to work properly but the first time 
"uhd_rx_streamer_recv" function is called it returns immediately (with 
no samples) and in next call it never returns.


I'm using USRP auto setup of master clock rate. It works if I reduce 
the sampling rate to 16MS/s.


Which can be the problem?
Thanks!
These are my logs at start-up:

Creating USRP with args "type=b200,  num_recv_frames=512, 
num_send_frames=512"...

-- Detected Device: B210
-- Operating over USB 3.
-- Detecting internal GPSDO Found an internal GPSDO: GPSTCXO , 
Firmware Rev 0.929a

-- Initialize CODEC control...
-- Initialize Radio control...
-- Performing register loopback test... pass
-- Performing register loopback test... pass
-- Performing CODEC loopback test... pass
-- Performing CODEC loopback test... pass
-- Asking for clock rate 16.00 MHz...
-- Actually got clock rate 16.00 MHz.
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
-- Setting master clock rate selection to 'automatic'.
num. Rx channels reported by usrp: 2
num. Tx channels reported by usrp: 2
Subdevice Specification:
Channel 0: Daughterboard A, Subdevice A
Channel 1: Daughterboard A, Subdevice B

Subdevice Specification:
Channel 0: Daughterboard A, Subdevice A
Channel 1: Daughterboard A, Subdevice B

Device name: wicomtec-1 (30CD3EC)
Clock source reported by usrp: internal
-- 1) catch time transition at pps edge
-- 2) set times next pps (synchronously)
Corrected PC clock mismatch of: +1511908607310 milliseconds
Current Time reported by USRP: 1.001673 seconds
Current Time reported by PC: 1.001000 seconds
Normalized_rx_gain for channel 0 = 0.00
Normalized_rx_gain for channel 0 = 0.00
Setting Rate: 3200.00...
-- Asking for clock rate 32.00 MHz...
-- Actually got clock rate 32.00 MHz.
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
Actual Rate Rx(0): 3200.00...
Actual Rate Tx(0): 3200.00...
Actual Master clock rate: 3200.00

wire packet size: 2044 complex samples/packet, k: 1566
Setting frequencies: Rx: 2414.00, Tx: 2414.00 MHz...
Target RF frequency, clipped to be within system range: 241400.00
Target RF frequency, including RF FE offset: 241400.00
Frequency to which RF LO is actually tuned: 241399.761581
Frequency the CORDIC must adjust the RF: -0.238419
Frequency to which the CORDIC in the DSP actually tuned: -0.238419
Actual frequency Rx(0): 2414.00 MHz...
Actual frequency Tx(0): 2414.00 MHz...
Setting RX Gain: 50.00 dB...
Antenna reported by usrp for RX channel 0: RX2
Actual Rx(0) Gain: 50.00...
Rx: stream_args.cpu_format = fc32
Rx: stream_args.otw_format = sc16
Rx: stream_args.args = spp=2044
Rx: stream_args.channel_list = 0, 1
Rx: stream_args.n_channels = 1
max complex samps per wire packet = 2044
Available sensors:
temp
rssi
lo_locked
Checking RX: LO: locked ...
Rx buffer size in samples: 3200904
Setting TX Gain: 50.00 dB...
Antenna reported by usrp for TX channel 0: TX/RX
Actual TX Gain: 50.00...
Tx: stream_args.cpu_format = fc32
Tx: stream_args.otw_format = sc16
Tx: stream_args.args = spp=2044
Tx: stream_args.channel_list = 0, 1
Tx: stream_args.n_channels = 1
max complex samps per wire packet = 2044
Available sensors:
temp
lo_locked
Checking TX: LO: locked ...
Tx buffer size in samples: 3200904
configusrp: Success



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

Do you know what type of USB 3 controller you have?


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

Re: [USRP-users] Ethernet over SFP+ in custom FPGA design (X3x0)

[Sugandha Gupta via USRP-users]

I can answer the question related to the padding. I am not sure about the
rest.

Ettus Padding: An ethernet frame has 6 bytes of destination MAC address and
6 bytes of Source MAC address. Since we use 64 bits/8 bytes of data in one
clock cycle, we add a 6 byte padding in front of the ethernet packet. The
new packet becomes:
< 6 bytes padding> 80 00
20 7A 3F 3E 80 00 20 20
and so on...

[image: Inline image 1]

We just ignore the 6 bytes of padding in the eth_dispatch block. It is used
to align the incoming packet to make classification easier.

- Sugandha


On Tue, Nov 28, 2017 at 12:09 PM, Christian Lenz <
christian.l...@freedelity.com> wrote:

> Ian and Sugandha,
>
> thank you very much for your comments and also for the attached file.
> Sadly, another three questions remain for the moment:
> 1. In the attached file, there is a series of 48? bits named "Ettus
> Padding". Is this an Ettus specific bit sequence and where can I find
> information on this?
> 2. If powering up and programming the FPGA, the clock from the PLL is not
> present because it must be programmed over SPI first. According to the HDL
> source files and pin constraints, the corresponding SPI master module in
> the FPGA is clocked  from a 125MHz clock. I assume this clock to be present
> without any configuration, is this true?
> 3. Do you know where to find the missing pages of the X3xx schematics
> document (13-17)? I would assume to find the 125MHz clock source on page 17.
>
> Thanks a lot!
>
> Zitat von Ian Buckley :
>
>
> Christian,
>> CHDR packets are encapsulated in UDP/IP between Host and USRP. See the
>> attachment.
>>
>> PHY+ MAC functionality live under the x300_sfpp_io_core. However these
>> blocks do not encapsulate/decapsulate the network packets.
>> All the ethernet/IP/UDP framing fields are added by chdr_eth_framer on
>> egress, and will be removed on ingress by etc_dispatch (if needed).
>>
>> -Ian
>>
>
>
>
>


-- 
Sugandha Gupta
Staff Software Engineer
Ettus Research
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Linux Kernel Modules for X-Series PCIe Connectivity

[john liu via USRP-users]

Hi all,
>From the manual http://files.ettus.com/manual/page_ni_rio_kernel.html ,we
know *Currently, the latest supported kernel version is 4.2.x. *
But the kernel version of ubnutu16.04 is newer than 4.2.x.So  we have a
plan to update this?

thank you.
best regards
John
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Ethernet over SFP+ in custom FPGA design (X3x0)

[Ian Buckley via USRP-users]

Christian,
If memory serves me correctly the missing pages are due to that portion of the 
design using a proprietary NI ASIC that handles the PCIe interface and the 
flash storage of the FPGA config data. Since it handles config it would be 
reasonable to assume that circuit also supplies initial clocks that enable 
config and boot. Too long ago I’m afraid for me to remember the exact details 
without going and spending time in the code to look.
-Ian

> On Nov 28, 2017, at 4:34 PM, Sugandha Gupta via USRP-users 
>  wrote:
> 
> I can answer the question related to the padding. I am not sure about the 
> rest. 
> 
> Ettus Padding: An ethernet frame has 6 bytes of destination MAC address and 6 
> bytes of Source MAC address. Since we use 64 bits/8 bytes of data in one 
> clock cycle, we add a 6 byte padding in front of the ethernet packet. The new 
> packet becomes:
> < 6 bytes padding> 80 00
> 20 7A 3F 3E 80 00 20 20
> and so on... 
> 
> 
> 
> We just ignore the 6 bytes of padding in the eth_dispatch block. It is used 
> to align the incoming packet to make classification easier. 
> 
> - Sugandha
> 
> 
> On Tue, Nov 28, 2017 at 12:09 PM, Christian Lenz 
> mailto:christian.l...@freedelity.com>> wrote:
> Ian and Sugandha,
> 
> thank you very much for your comments and also for the attached file.
> Sadly, another three questions remain for the moment:
> 1. In the attached file, there is a series of 48? bits named "Ettus Padding". 
> Is this an Ettus specific bit sequence and where can I find information on 
> this?
> 2. If powering up and programming the FPGA, the clock from the PLL is not 
> present because it must be programmed over SPI first. According to the HDL 
> source files and pin constraints, the corresponding SPI master module in the 
> FPGA is clocked  from a 125MHz clock. I assume this clock to be present 
> without any configuration, is this true?
> 3. Do you know where to find the missing pages of the X3xx schematics 
> document (13-17)? I would assume to find the 125MHz clock source on page 17.
> 
> Thanks a lot!
> 
> Zitat von Ian Buckley mailto:i...@ianbuckley.net>>:
> 
> 
> Christian,
> CHDR packets are encapsulated in UDP/IP between Host and USRP. See the 
> attachment.
> 
> PHY+ MAC functionality live under the x300_sfpp_io_core. However these blocks 
> do not encapsulate/decapsulate the network packets.
> All the ethernet/IP/UDP framing fields are added by chdr_eth_framer on 
> egress, and will be removed on ingress by etc_dispatch (if needed).
> 
> -Ian
> 
> 
> 
> 
> 
> 
> -- 
> Sugandha Gupta
> Staff Software Engineer
> Ettus Research
> ___
> 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