[USRP-users] Re: Fir Filter RFNoC

[Camille Moniere]

Just a typo, I used firS in the file, and I change the first occurrence  
while pasting the file, considering my use of fir0 in my
explanations.
There it is, with only fir0 (even if it does not change the initial issue):

# General parameters
# -
schema: rfnoc_imagebuilder_args# Identifier for the schema used to  
validate this file
copyright: 'Camille Monière'# Copyright information used in file headers
license: 'SPDX-License-Identifier: LGPL-3.0-or-later'# License  
information used in file headers
version: '1.0'# File version
rfnoc_version: '1.0'# RFNoC protocol version
chdr_width: 64# Bit width of the CHDR bus for this image
device: 'x310'
default_target: 'X310_HG'
# A list of all stream endpoints in design
# 
stream_endpoints:
ep0: # Stream endpoint name
ctrl: True# Endpoint passes control traffic
data: True# Endpoint passes data traffic
buff_size: 0# Ingress buffer size for data
# A list of all NoC blocks in design
# --
noc_blocks:
ddc0:
block_desc: 'ddc.yml'
parameters:
NUM_PORTS: 1
radio0:
block_desc: 'radio_2x64.yml'
parameters:
NUM_PORTS: 1
fir0:
block_desc: 'fir_filter.yml'
parameters:
NUM_PORTS: 1
COEFF_WIDTH: 16
NUM_COEFFS: 21
COEFFS_VEC: "{ 16'h7FFF, {320{1'b0}} }"
RELOADABLE_COEFFS: 1
SYMMETRIC_COEFFS: 0
SKIP_ZERO_COEFFS: 0
USE_EMBEDDED_REGS_COEFFS: 1
# A list of all static connections in design
# --
# Format: A list of connection maps (list of key-value pairs) with the  
following keys
# - srcblk = Source block to connect
# - srcport = Port on the source block to connect
# - dstblk = Destination block to connect
# - dstport = Port on the destination block to connect
connections:
# radio0 to ep0 - RFA RX
- { srcblk: radio0, srcport: out_0, dstblk: ddc0, dstport: in_0}
- { srcblk: ddc0, srcport: out_0, dstblk: fir0, dstport: in_0}
- { srcblk: fir0, srcport: out_0, dstblk: ep0, dstport: in0}
# BSP Connections
- { srcblk: radio0, srcport: ctrl_port, dstblk: _device_, dstport:  
ctrlport_radio0}
- { srcblk: _device_, srcport: x300_radio0, dstblk: radio0, dstport:  
x300_radio}
- { srcblk: _device_, srcport: time_keeper, dstblk: radio0, dstport:  
time_keeper}
# A list of all clock domain connections in design
# --
# Format: A list of connection maps (list of key-value pairs) with the  
following keys
# - srcblk = Source block to connect (Always "_device"_)
# - srcport = Clock domain on the source block to connect
# - dstblk = Destination block to connect
# - dstport = Clock domain on the destination block to connect
clk_domains:
- { srcblk: _device_, srcport: radio, dstblk: radio0, dstport: radio}
- { srcblk: _device_, srcport: ce, dstblk: ddc0, dstport: ce}
- { srcblk: _device_, srcport: ce, dstblk: fir0, dstport: ce}

On 1/13/22 18:30, Wade Fife wrote:
> At a glance, the YML has both firS and fir0. I was expecting just  
> fir0. But I also would have expected rfnoc_image_builder to throw an  
> error for that.
>
> Wade
>
> On Thu, Jan 13, 2022 at 11:19 AM Camille Moniere  
>  wrote:
>
> Hi wade,
>
> I had already linked the FIR ce to the ce of the _device_.
>
> Also, this custom image aims only to receive data (so no duc nor
> SEP for TX). I tried to free some space, considering only one
> UBX-160 is available (so only 1 radio).
> I have read in the RFNoC guide that, for a device to host
> communication, an ingress buffer of size 0 is possible, again to
> free resources.
> A big block is expected to be added in the future...
>
> Here the YAML file I use with rfnoc_image_builder:
>
> # General parameters
> # -
> schema: rfnoc_imagebuilder_args# Identifier for the schema used to
> validate this file
> copyright: 'Camille Monière'# Copyright information used in file
> headers
> license: 'SPDX-License-Identifier: LGPL-3.0-or-later'# License
> information used in file headers
> version: '1.0'# File version
> rfnoc_version: '1.0'# RFNoC protocol version
> chdr_width: 64# Bit width of the CHDR bus for this image
> device: 'x310'
> default_target: 'X310_HG'
> # A list of all stream endpoints in design
> # 
> stream_endpoints:
> ep0: # Stream endpoint name
> ctrl: True# Endpoint passes control traffic
> data: True# Endpoint passes data traffic
> buff_size: 0# Ingress buffer size for data
> # A list of all NoC blocks in design
> # --
> noc_blocks:
> ddc0:
> block_desc: 'ddc.yml'
> parameters:
> NUM_PORTS: 1
> radio0:
> block_desc: 'radio_2x64.yml'
> parameters:
> NUM_PORTS: 1
> fir0:
> block_desc: 'fir_filter.yml'
> parameters:
> NUM_PORTS: 1
> COEFF_WIDTH: 16
> NUM_COEFFS: 21
> COEFFS_VEC: "{ 16'h7FFF, {320{1'b0}} }

[USRP-users] Re: N321 LO sharing between RF 0/1

[Rob Kossler]

Hi Paul,
Based on the block diagram
, I
think I would set both LOs to use an external source. I would set the
Tx0 export the LO on Tx Output 0 and then route it directly back into Tx
Input 1 which then goes to a 1:2 splitter to feed both inputs.  In addition
to exporting the LO and setting the LO source to external for both ports,
you also need to enable the Tx Output 0 (disabled by default). I've
forgotten the command to do so.
Rob



On Fri, Jan 14, 2022 at 1:11 AM Paul Atreides 
wrote:

> I am trying to configure the N321 to take some TX phase measurements
> between RF0 and RF1
> I have updated the file system to the latest release using the KB
> guidance.
>
> My host/software side is:
> GNURadio 3.9.5
> UHD 4.1.0.5
> Ubuntu 20.04
>
> My gr-uhd block has the LO settings:
> Channel 0 export = true
> Channel 0 LO = internal
>
> Channel 1 export = false
> Channel 1 LO = external
>
> On the hardware side am I understanding the LO diagram correctly that in
> order to achieve the highest phase accuracy between channels i need to
> share the LO between the transmit ports of RF0 and RF1?
> If so, would I do that by physically connecting the TX LO OUT0 (really
> 0-3) to TX LO IN1?
>
> Am I missing anything obvious for the settings and/or is there a more
> desirable way to do this?
>
> Thanks
>
> 
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: N321 LO sharing between RF 0/1

[Rob Kossler]

Forgot to mention, there are some nice LEDs on the LO Tx Outputs that will
tell you if you have a given port enabled.

On Fri, Jan 14, 2022 at 9:25 AM Rob Kossler  wrote:

> Hi Paul,
> Based on the block diagram
> ,
> I think I would set both LOs to use an external source. I would set the
> Tx0 export the LO on Tx Output 0 and then route it directly back into Tx
> Input 1 which then goes to a 1:2 splitter to feed both inputs.  In addition
> to exporting the LO and setting the LO source to external for both ports,
> you also need to enable the Tx Output 0 (disabled by default). I've
> forgotten the command to do so.
> Rob
>
>
>
> On Fri, Jan 14, 2022 at 1:11 AM Paul Atreides 
> wrote:
>
>> I am trying to configure the N321 to take some TX phase measurements
>> between RF0 and RF1
>> I have updated the file system to the latest release using the KB
>> guidance.
>>
>> My host/software side is:
>> GNURadio 3.9.5
>> UHD 4.1.0.5
>> Ubuntu 20.04
>>
>> My gr-uhd block has the LO settings:
>> Channel 0 export = true
>> Channel 0 LO = internal
>>
>> Channel 1 export = false
>> Channel 1 LO = external
>>
>> On the hardware side am I understanding the LO diagram correctly that in
>> order to achieve the highest phase accuracy between channels i need to
>> share the LO between the transmit ports of RF0 and RF1?
>> If so, would I do that by physically connecting the TX LO OUT0 (really
>> 0-3) to TX LO IN1?
>>
>> Am I missing anything obvious for the settings and/or is there a more
>> desirable way to do this?
>>
>> Thanks
>>
>> 
>> ___
>> USRP-users mailing list -- usrp-users@lists.ettus.com
>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: N321 LO sharing between RF 0/1

[Marcus D. Leech]

On 2022-01-14 01:11, Paul Atreides wrote:

I am trying to configure the N321 to take some TX phase measurements between 
RF0 and RF1
I have updated the file system to the latest release using the KB guidance.

My host/software side is:
GNURadio 3.9.5
UHD 4.1.0.5
Ubuntu 20.04

My gr-uhd block has the LO settings:
Channel 0 export = true
Channel 0 LO = internal

Channel 1 export = false
Channel 1 LO = external

On the hardware side am I understanding the LO diagram correctly that in order 
to achieve the highest phase accuracy between channels i need to share the LO 
between the transmit ports of RF0 and RF1?
If so, would I do that by physically connecting the TX LO OUT0 (really 0-3) to 
TX LO IN1?

Am I missing anything obvious for the settings and/or is there a more desirable 
way to do this?

Thanks


___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

This KB article may be of some help:

https://kb.ettus.com/USRP_N320/N321_LO_Distribution

___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: X310 based programs cannot run stably for a long time

[Marcus Müller]

Hi Jason,


hm, if *I* had to make I wild guess (and it's really only that), something in the network 
stack reordered or dropped packets, and now the firmware running on the softcpu can't 
reconcile that - or just the host UHD.


I bet this is hard to debug, so let's plan this a bit; I honestly don't have a great 
starting point either, but I'd first try to figure out whether this might be network:


1. have something that logs stats for IPv4. If this is Linux, (and bash, and your network 
device is called enp2s0)



while true; do netstat -s -i enp2s0 -4 > "/mylogdir/netstat.$(|date +"%s")"; 
sleep 1; done|

|
|

2. Try to note down the time of crashing.

3. Try to correlate the time with an increase of one of the statistics; if you need help 
with that, let us know.



My apologies for not having a great idea what this might be :(, but here's to hoping we 
can figure this out!



Best regards,

Marcus

|
|

|
|

DISCLAIMER: Any attached Code is provided As Is. It has not been tested or 
validated as a product, for use in a deployed application or system, or for use 
in hazardous environments. You assume all risks for use of the Code. Use of the 
Code is subject to terms of the licenses to the UHD or RFNoC code with which 
the Code is used. Standard licenses to UHD and RFNoC can be found at 
https://www.ettus.com/sdr-software/licenses/.

NI will only perform services based on its understanding and condition that the 
goods or services (i) are not for the use in the production or development of 
any item produced, purchased, or ordered by any entity with a footnote 1 
designation in the license requirement column of Supplement No. 4 to Part 744, 
U.S. Export Administration Regulations and (ii) such a company is not a party 
to the transaction.  If our understanding is incorrect, please notify us 
immediately because a specific authorization may be required from the U.S. 
Commerce Department before the transaction may proceed further.

On 10.01.22 20:37, jason pro wrote:

Hi dear Engineers of Ettus Research,

Our application written based on UHD and USRP X310 cannot run for a long time(The 
longest time did not exceed 48 hours).

The x310 is connected to the computer through a 10GbE network card (X520).
We have tried to use versions 3.15 and 4.1.0.5. UHD throws different errors:

1. UHD 4.1.0.5
X300 fw communication failure #1
EnvironmentError: IO Error:x300 fw peek32 -reply timed out
Terminate called after throwing an instance of 'uhd::assertion_error'
What():AssertionError:reply.sequence == request.sequence
in virtual uint32_t x300_ctrl_iface_enet::_peek32(uhd::wb_iface::wb_addr_type)
at/home/xxx/uhd/host/lib/usrp/x300/x300_fw_ctrl.cpp:165

2. UHD 3.15
terminate called after throwing an instance of ‘uhd:: io_error’
what() : EnvironmentError : IOError : Block ctrl(CE_01_Port_40) no response packet – 
AssertionError : bool(buff)
in uint64_t ctrl_iface_impl<_endianness> :: wait_for_ack(bool,double)[with uhd :: 
endianness_t_endianness = uhd::ENDIANNESS_BIG;uint64_t = long unsigned int] 
at/home/xxx/uhd_3.15.0/uhd/host/lib/rfnoc/ctrl_iface.cpp:151


Is there a solution?

Best regards,
Jason

___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: N321 LO sharing between RF 0/1

[Paul Atreides]

Thanks Marcus, I’ve been scouring the Rubiks cube that is the knowledge base 
for about a week now. I’ve also watched the Dan Baker GRCON2019 talk and 
followed the references there as well.

The reference you linked is very helpful in a lot of cases, but in this one it 
doesnt address (anywhere I’ve seen) that in order to have the device operate 
with local oscillator sharing between RF 0 and RF 1, physically connecting the 
radio back to itself needs to be done. I’ve seen plenty of things about 
“external LO” but to me that term is a little confusing because it sounds like 
it’s external LO to the device. 

I guess I was just thinking it might be a good idea to let N321 users know that 
in order to achieve phase coherence between INTERNAL channels, it’s going to be 
more work than a B210. 

Just my 2 cents. 



> On Jan 14, 2022, at 09:36, Marcus D. Leech  wrote:
> 
> On 2022-01-14 01:11, Paul Atreides wrote:
>> I am trying to configure the N321 to take some TX phase measurements between 
>> RF0 and RF1
>> I have updated the file system to the latest release using the KB guidance.
>> 
>> My host/software side is:
>> GNURadio 3.9.5
>> UHD 4.1.0.5
>> Ubuntu 20.04
>> 
>> My gr-uhd block has the LO settings:
>> Channel 0 export = true
>> Channel 0 LO = internal
>> 
>> Channel 1 export = false
>> Channel 1 LO = external
>> 
>> On the hardware side am I understanding the LO diagram correctly that in 
>> order to achieve the highest phase accuracy between channels i need to share 
>> the LO between the transmit ports of RF0 and RF1?
>> If so, would I do that by physically connecting the TX LO OUT0 (really 0-3) 
>> to TX LO IN1?
>> 
>> Am I missing anything obvious for the settings and/or is there a more 
>> desirable way to do this?
>> 
>> Thanks
>> 
>> 
>> ___
>> USRP-users mailing list -- usrp-users@lists.ettus.com
>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
> This KB article may be of some help:
> 
> https://kb.ettus.com/USRP_N320/N321_LO_Distribution
> 
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: N321 LO sharing between RF 0/1

[Paul Atreides]

I see what you’re saying. Are you recommending setting both to external so the 
paths are equal?



> On Jan 14, 2022, at 09:25, Rob Kossler  wrote:
> 
> 
> Hi Paul,
> Based on the block diagram, I think I would set both LOs to use an external 
> source. I would set the Tx0 export the LO on Tx Output 0 and then route it 
> directly back into Tx Input 1 which then goes to a 1:2 splitter to feed both 
> inputs.  In addition to exporting the LO and setting the LO source to 
> external for both ports, you also need to enable the Tx Output 0 (disabled by 
> default). I've forgotten the command to do so.
> Rob
> 
> 
> 
>> On Fri, Jan 14, 2022 at 1:11 AM Paul Atreides  wrote:
>> I am trying to configure the N321 to take some TX phase measurements between 
>> RF0 and RF1 
>> I have updated the file system to the latest release using the KB guidance. 
>> 
>> My host/software side is:
>> GNURadio 3.9.5
>> UHD 4.1.0.5
>> Ubuntu 20.04
>> 
>> My gr-uhd block has the LO settings:
>> Channel 0 export = true
>> Channel 0 LO = internal
>> 
>> Channel 1 export = false
>> Channel 1 LO = external
>> 
>> On the hardware side am I understanding the LO diagram correctly that in 
>> order to achieve the highest phase accuracy between channels i need to share 
>> the LO between the transmit ports of RF0 and RF1? 
>> If so, would I do that by physically connecting the TX LO OUT0 (really 0-3) 
>> to TX LO IN1? 
>> 
>> Am I missing anything obvious for the settings and/or is there a more 
>> desirable way to do this?
>> 
>> Thanks
>> 
>> 
>> ___
>> USRP-users mailing list -- usrp-users@lists.ettus.com
>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: N321 LO sharing between RF 0/1

[Paul Atreides]

Thanks Rob, I was actually wondering that!



> On Jan 14, 2022, at 09:26, Rob Kossler  wrote:
> 
> 
> Forgot to mention, there are some nice LEDs on the LO Tx Outputs that will 
> tell you if you have a given port enabled.
> 
>> On Fri, Jan 14, 2022 at 9:25 AM Rob Kossler  wrote:
>> Hi Paul,
>> Based on the block diagram, I think I would set both LOs to use an external 
>> source. I would set the Tx0 export the LO on Tx Output 0 and then route it 
>> directly back into Tx Input 1 which then goes to a 1:2 splitter to feed both 
>> inputs.  In addition to exporting the LO and setting the LO source to 
>> external for both ports, you also need to enable the Tx Output 0 (disabled 
>> by default). I've forgotten the command to do so.
>> Rob
>> 
>> 
>> 
>>> On Fri, Jan 14, 2022 at 1:11 AM Paul Atreides  
>>> wrote:
>>> I am trying to configure the N321 to take some TX phase measurements 
>>> between RF0 and RF1 
>>> I have updated the file system to the latest release using the KB guidance. 
>>> 
>>> My host/software side is:
>>> GNURadio 3.9.5
>>> UHD 4.1.0.5
>>> Ubuntu 20.04
>>> 
>>> My gr-uhd block has the LO settings:
>>> Channel 0 export = true
>>> Channel 0 LO = internal
>>> 
>>> Channel 1 export = false
>>> Channel 1 LO = external
>>> 
>>> On the hardware side am I understanding the LO diagram correctly that in 
>>> order to achieve the highest phase accuracy between channels i need to 
>>> share the LO between the transmit ports of RF0 and RF1? 
>>> If so, would I do that by physically connecting the TX LO OUT0 (really 0-3) 
>>> to TX LO IN1? 
>>> 
>>> Am I missing anything obvious for the settings and/or is there a more 
>>> desirable way to do this?
>>> 
>>> Thanks
>>> 
>>> 
>>> ___
>>> USRP-users mailing list -- usrp-users@lists.ettus.com
>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: N321 LO sharing between RF 0/1

[Marcus D. Leech]

On 2022-01-14 10:07, Paul Atreides wrote:

Thanks Marcus, I’ve been scouring the Rubiks cube that is the knowledge base 
for about a week now. I’ve also watched the Dan Baker GRCON2019 talk and 
followed the references there as well.

The reference you linked is very helpful in a lot of cases, but in this one it 
doesnt address (anywhere I’ve seen) that in order to have the device operate 
with local oscillator sharing between RF 0 and RF 1, physically connecting the 
radio back to itself needs to be done. I’ve seen plenty of things about 
“external LO” but to me that term is a little confusing because it sounds like 
it’s external LO to the device.

I guess I was just thinking it might be a good idea to let N321 users know that 
in order to achieve phase coherence between INTERNAL channels, it’s going to be 
more work than a B210.

Just my 2 cents.


You should be able to get adequate phase-coherence in a single N321 
without using LO-sharing at all--I THINK that the synthesizers support
  phase-resynch on tuning, so if the tune commands are wrapped up in 
timed commands, you should get internal phase coherence without

  resorting to LO sharing.

But I don't have one of these in my collection, so I can't test that 
hypothesis...


___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: N321 LO sharing between RF 0/1

[Paul Atreides]

Oh OK, I can see that possibly working for my application. 

 Do you happen to Have any insight on what Rob was talking about,  if gr-uhd 
Will automatically turn on the TX0 output when the export is ‘True’ Or do you 
know if that should instead be passed in a Device argument?

I can also just test this a little later and see if the output light comes on. 



> On Jan 14, 2022, at 10:28, Marcus D. Leech  wrote:
> 
> On 2022-01-14 10:07, Paul Atreides wrote:
>> Thanks Marcus, I’ve been scouring the Rubiks cube that is the knowledge base 
>> for about a week now. I’ve also watched the Dan Baker GRCON2019 talk and 
>> followed the references there as well.
>> 
>> The reference you linked is very helpful in a lot of cases, but in this one 
>> it doesnt address (anywhere I’ve seen) that in order to have the device 
>> operate with local oscillator sharing between RF 0 and RF 1, physically 
>> connecting the radio back to itself needs to be done. I’ve seen plenty of 
>> things about “external LO” but to me that term is a little confusing because 
>> it sounds like it’s external LO to the device.
>> 
>> I guess I was just thinking it might be a good idea to let N321 users know 
>> that in order to achieve phase coherence between INTERNAL channels, it’s 
>> going to be more work than a B210.
>> 
>> Just my 2 cents.
>> 
>> 
> You should be able to get adequate phase-coherence in a single N321 without 
> using LO-sharing at all--I THINK that the synthesizers support
>   phase-resynch on tuning, so if the tune commands are wrapped up in timed 
> commands, you should get internal phase coherence without
>   resorting to LO sharing.
> 
> But I don't have one of these in my collection, so I can't test that 
> hypothesis...
> 
> 
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: N321 LO sharing between RF 0/1

[Marcus D. Leech]

On 2022-01-14 10:40, Paul Atreides wrote:

Oh OK, I can see that possibly working for my application.

  Do you happen to Have any insight on what Rob was talking about,  if gr-uhd 
Will automatically turn on the TX0 output when the export is ‘True’ Or do you 
know if that should instead be passed in a Device argument?

I can also just test this a little later and see if the output light comes on.



Setting the Export control in the UHD block SHOULD be enough to make 
that LED come on :)



But I don't have one in my collection.


___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Enabling fast lock USRP N210.

[Ivan Zahartchuk]

Hello. I need to simulate a heavy RF environment. It is necessary to
generate a chirp signal in a 100 MHz band with a total speed of one run of
about 300 µs. But I only have USRP N210. In this regard, I have several
questions.
 1. Is it possible to enable fast lock using uhd 4 drivers?
2. Is it possible to generate such a structure with such time?
 I have a bad relationship with FPGA
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: N321 LO sharing between RF 0/1

[Marcus D. Leech]

On 2022-01-14 17:00, Paul Atreides wrote:

That's what I had originally.
i've Changed back to this and still getting no LED on the TX LO OUT0:
RF0
LO Source internal
LO export True
RF1
LO Source external
LO export False

the generated flowgraph code looks to be reflecting  is:
    self.uhd_usrp_sink_0.set_clock_source('external', 0)
        self.uhd_usrp_sink_0.set_time_source('external', 0)
        self.uhd_usrp_sink_0.set_samp_rate(samp_rate)
self.uhd_usrp_sink_0.set_time_unknown_pps(uhd.time_spec(0))

        self.uhd_usrp_sink_0.set_center_freq(freq, 0)
        self.uhd_usrp_sink_0.set_antenna('TX/RX', 0)
        self.uhd_usrp_sink_0.set_gain(gain_0, 0)

        self.uhd_usrp_sink_0.set_lo_source('internal', uhd.ALL_LOS, 0)
        self.uhd_usrp_sink_0.set_lo_export_enabled(True, uhd.ALL_LOS, 0)
        self.uhd_usrp_sink_0.set_center_freq(freq, 1)
        self.uhd_usrp_sink_0.set_antenna('TX/RX', 1)
        self.uhd_usrp_sink_0.set_gain(gain_1, 1)

        self.uhd_usrp_sink_0.set_lo_source('external', uhd.ALL_LOS, 1)
        self.uhd_usrp_sink_0.set_lo_export_enabled(False, uhd.ALL_LOS, 1)



I wonder if this is just a case of the LO export LED code isn't there in 
that version of UHD?


Can you confirm presence of the LO signal with a spectrum analyser or 
similar?


___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: N321 LO sharing between RF 0/1

[Paul Atreides]

doing it now. is the LO frequency the carrier freq or is it 1/2 or 2x?

On Fri, Jan 14, 2022 at 5:03 PM Marcus D. Leech 
wrote:

> On 2022-01-14 17:00, Paul Atreides wrote:
> > That's what I had originally.
> > i've Changed back to this and still getting no LED on the TX LO OUT0:
> > RF0
> > LO Source internal
> > LO export True
> > RF1
> > LO Source external
> > LO export False
> >
> > the generated flowgraph code looks to be reflecting  is:
> > self.uhd_usrp_sink_0.set_clock_source('external', 0)
> > self.uhd_usrp_sink_0.set_time_source('external', 0)
> > self.uhd_usrp_sink_0.set_samp_rate(samp_rate)
> > self.uhd_usrp_sink_0.set_time_unknown_pps(uhd.time_spec(0))
> >
> > self.uhd_usrp_sink_0.set_center_freq(freq, 0)
> > self.uhd_usrp_sink_0.set_antenna('TX/RX', 0)
> > self.uhd_usrp_sink_0.set_gain(gain_0, 0)
> >
> > self.uhd_usrp_sink_0.set_lo_source('internal', uhd.ALL_LOS, 0)
> > self.uhd_usrp_sink_0.set_lo_export_enabled(True, uhd.ALL_LOS, 0)
> > self.uhd_usrp_sink_0.set_center_freq(freq, 1)
> > self.uhd_usrp_sink_0.set_antenna('TX/RX', 1)
> > self.uhd_usrp_sink_0.set_gain(gain_1, 1)
> >
> > self.uhd_usrp_sink_0.set_lo_source('external', uhd.ALL_LOS, 1)
> > self.uhd_usrp_sink_0.set_lo_export_enabled(False, uhd.ALL_LOS, 1)
> >
>
> I wonder if this is just a case of the LO export LED code isn't there in
> that version of UHD?
>
> Can you confirm presence of the LO signal with a spectrum analyser or
> similar?
>
>
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: N321 LO sharing between RF 0/1

[Rob Kossler]

Just 1x, I believe.

On Fri, Jan 14, 2022 at 5:27 PM Paul Atreides 
wrote:

> doing it now. is the LO frequency the carrier freq or is it 1/2 or 2x?
>
> On Fri, Jan 14, 2022 at 5:03 PM Marcus D. Leech 
> wrote:
>
>> On 2022-01-14 17:00, Paul Atreides wrote:
>> > That's what I had originally.
>> > i've Changed back to this and still getting no LED on the TX LO OUT0:
>> > RF0
>> > LO Source internal
>> > LO export True
>> > RF1
>> > LO Source external
>> > LO export False
>> >
>> > the generated flowgraph code looks to be reflecting  is:
>> > self.uhd_usrp_sink_0.set_clock_source('external', 0)
>> > self.uhd_usrp_sink_0.set_time_source('external', 0)
>> > self.uhd_usrp_sink_0.set_samp_rate(samp_rate)
>> > self.uhd_usrp_sink_0.set_time_unknown_pps(uhd.time_spec(0))
>> >
>> > self.uhd_usrp_sink_0.set_center_freq(freq, 0)
>> > self.uhd_usrp_sink_0.set_antenna('TX/RX', 0)
>> > self.uhd_usrp_sink_0.set_gain(gain_0, 0)
>> >
>> > self.uhd_usrp_sink_0.set_lo_source('internal', uhd.ALL_LOS, 0)
>> > self.uhd_usrp_sink_0.set_lo_export_enabled(True, uhd.ALL_LOS, 0)
>> > self.uhd_usrp_sink_0.set_center_freq(freq, 1)
>> > self.uhd_usrp_sink_0.set_antenna('TX/RX', 1)
>> > self.uhd_usrp_sink_0.set_gain(gain_1, 1)
>> >
>> > self.uhd_usrp_sink_0.set_lo_source('external', uhd.ALL_LOS, 1)
>> > self.uhd_usrp_sink_0.set_lo_export_enabled(False, uhd.ALL_LOS,
>> 1)
>> >
>>
>> I wonder if this is just a case of the LO export LED code isn't there in
>> that version of UHD?
>>
>> Can you confirm presence of the LO signal with a spectrum analyser or
>> similar?
>>
>>
>> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: N321 LO sharing between RF 0/1

[Marcus D. Leech]

On 2022-01-14 17:30, Rob Kossler wrote:
These thare the UHD commands. I don't know how these translate to 
gnuradio.


% set both LO sources to use external
set_tx_lo_source(“external”, “lo1”, 0)
set_tx_lo_source(“external”, “lo1”, 1)

% export the internal LO to the 1:4 splitter
set_tx_lo_export_enabled(true, “lo1”, 0)

% enable the 1:4 splitter output port
get_device()->get_tree()->access("mboards/0/dboards/A/tx_frontends/0/los/lo1/lo_distribution/LO_OUT_0/export").set(true)

I don't think the current GR code has support for controlling the 
splitter, so a "code snippet" would likely be required.




To unsubscribe send an email to usrp-users-le...@lists.ettus.com

___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: N321 LO sharing between RF 0/1

[Paul Atreides]

Using a B210 at f_c of the N321. TX LO OUT0 is plugged into RX2 of the  B210
[image: image.png]


On Fri, Jan 14, 2022 at 5:32 PM Marcus D. Leech 
wrote:

> On 2022-01-14 17:30, Rob Kossler wrote:
>
> These thare the UHD commands. I don't know how these translate to gnuradio.
>
> % set both LO sources to use external
> set_tx_lo_source(“external”, “lo1”, 0)
> set_tx_lo_source(“external”, “lo1”, 1)
>
> % export the internal LO to the 1:4 splitter
> set_tx_lo_export_enabled(true, “lo1”, 0)
>
> % enable the 1:4 splitter output port
>
> get_device()->get_tree()->access("mboards/0/dboards/A/tx_frontends/0/los/lo1/lo_distribution/LO_OUT_0/export").set(true)
>
> I don't think the current GR code has support for controlling the
> splitter, so a "code snippet" would likely be required.
>
>
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>>
>>
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: N321 LO sharing between RF 0/1

[Marcus D. Leech]

On 2022-01-14 17:35, Paul Atreides wrote:
Using a B210 at f_c of the N321. TX LO OUT0 is plugged into RX2 of 
the  B210
You might want to put an attenuator inline, since the LO output is a 
couple of dBm, which is

  "loud as a heavy metal concert" from the perspective of a receiver input.

If the splitter isn't enabled in this test, then what you're seeing is 
the leakage through the RF
  switch that enables the splitter, which means that once the splitter 
is turned on, the

  signal will be even louder...



image.png


On Fri, Jan 14, 2022 at 5:32 PM Marcus D. Leech 
 wrote:


On 2022-01-14 17:30, Rob Kossler wrote:

These thare the UHD commands. I don't know how these translate to
gnuradio.

% set both LO sources to use external
set_tx_lo_source(“external”, “lo1”, 0)
set_tx_lo_source(“external”, “lo1”, 1)

% export the internal LO to the 1:4 splitter
set_tx_lo_export_enabled(true, “lo1”, 0)

% enable the 1:4 splitter output port

get_device()->get_tree()->access("mboards/0/dboards/A/tx_frontends/0/los/lo1/lo_distribution/LO_OUT_0/export").set(true)


I don't think the current GR code has support for controlling the
splitter, so a "code snippet" would likely be required.



To unsubscribe send an email to
usrp-users-le...@lists.ettus.com



___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: N321 LO sharing between RF 0/1

[Paul Atreides]

so, the LO export is confirmed to be going out of TX OUT0 from the
screenshot i sent before.
 I think i need to come back to this on monday





On Fri, Jan 14, 2022 at 5:32 PM Marcus D. Leech 
wrote:

> On 2022-01-14 17:30, Rob Kossler wrote:
>
> These thare the UHD commands. I don't know how these translate to gnuradio.
>
> % set both LO sources to use external
> set_tx_lo_source(“external”, “lo1”, 0)
> set_tx_lo_source(“external”, “lo1”, 1)
>
> % export the internal LO to the 1:4 splitter
> set_tx_lo_export_enabled(true, “lo1”, 0)
>
> % enable the 1:4 splitter output port
>
> get_device()->get_tree()->access("mboards/0/dboards/A/tx_frontends/0/los/lo1/lo_distribution/LO_OUT_0/export").set(true)
>
> I don't think the current GR code has support for controlling the
> splitter, so a "code snippet" would likely be required.
>
>
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>>
>>
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: N321 LO sharing between RF 0/1

[Paul Atreides]

Ok thanks. In my haste I was mistaken in assuming that the LO gain would track 
with the RF output gain. Silly mistake. I’m still getting used to separating 
out the LO. 

I can put this on a SpectrumAnalyzer (with an attenuator in line) on Monday.

I’m trying to take channel to channel phase measurements to determine what 
level of phase control I can have over one channel.

It’s not critical that I use GNURadio but it seemed like the logical option as 
it’s very easy to make those adjustments.

I will look at the python API and see if the commands Rob was talking about can 
be invoked using Python  instead of writing a C++ application.
Then I’ll see if that is included in gr-uhd. If not, I can submit a pull 
request with any changes.

I’ll ping the gnuradio chat later tonight.


Thanks for the help guys are in


> On Jan 14, 2022, at 17:43, Marcus D. Leech  wrote:
> 
> 
> On 2022-01-14 17:35, Paul Atreides wrote:
>> Using a B210 at f_c of the N321. TX LO OUT0 is plugged into RX2 of the  B210
> You might want to put an attenuator inline, since the LO output is a couple 
> of dBm, which is
>   "loud as a heavy metal concert" from the perspective of a receiver input.
> 
> If the splitter isn't enabled in this test, then what you're seeing is the 
> leakage through the RF
>   switch that enables the splitter, which means that once the splitter is 
> turned on, the
>   signal will be even louder...
> 
> 
>> 
>> 
>> 
>> On Fri, Jan 14, 2022 at 5:32 PM Marcus D. Leech  
>> wrote:
>>> On 2022-01-14 17:30, Rob Kossler wrote:
 These thare the UHD commands. I don't know how these translate to gnuradio.
 
 % set both LO sources to use external
 set_tx_lo_source(“external”, “lo1”, 0)
 set_tx_lo_source(“external”, “lo1”, 1)
 
 % export the internal LO to the 1:4 splitter
 set_tx_lo_export_enabled(true, “lo1”, 0)
 
 % enable the 1:4 splitter output port
 get_device()->get_tree()->access("mboards/0/dboards/A/tx_frontends/0/los/lo1/lo_distribution/LO_OUT_0/export").set(true)
 
>>> I don't think the current GR code has support for controlling the splitter, 
>>> so a "code snippet" would likely be required.
>>> 
>>> 
>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>> 
> 
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: N321 LO sharing between RF 0/1

[Marcus D. Leech]

On 2022-01-14 18:10, Paul Atreides wrote:
Ok thanks. In my haste I was mistaken in assuming that the LO gain 
would track with the RF output gain. Silly mistake. I’m still getting 
used to separating out the LO.


I can put this on a SpectrumAnalyzer (with an attenuator in line) on 
Monday.


I’m trying to take channel to channel phase measurements to determine 
what level of phase control I can have over one channel.
My guess is that if you extrude the LO out and then loop it back in, 
with equal-length, equal-type cables, the channel-to-channel phase error 
will be quite small.


If the phase-error that results is *fixed* and *characterized*, you can 
simply rotate the phase of one of the baseband signals to compensate.




It’s not critical that I use GNURadio but it seemed like the logical 
option as it’s very easy to make those adjustments.


I will look at the python API and see if the commands Rob was talking 
about can be invoked using Python  instead of writing a C++ application.
Then I’ll see if that is included in gr-uhd. If not, I can submit a 
pull request with any changes.
I think the only "missing piece" is the control for the splitter module, 
and with GR3.9+ you can use a code snippet to insert that, I think.





I’ll ping the gnuradio chat later tonight.


Thanks for the help guys are in


On Jan 14, 2022, at 17:43, Marcus D. Leech  
wrote:



On 2022-01-14 17:35, Paul Atreides wrote:
Using a B210 at f_c of the N321. TX LO OUT0 is plugged into RX2 of 
the  B210
You might want to put an attenuator inline, since the LO output is a 
couple of dBm, which is
  "loud as a heavy metal concert" from the perspective of a receiver 
input.


If the splitter isn't enabled in this test, then what you're seeing 
is the leakage through the RF
  switch that enables the splitter, which means that once the 
splitter is turned on, the

  signal will be even louder...



image.png


On Fri, Jan 14, 2022 at 5:32 PM Marcus D. Leech 
 wrote:


On 2022-01-14 17:30, Rob Kossler wrote:

These thare the UHD commands. I don't know how these translate
to gnuradio.

% set both LO sources to use external
set_tx_lo_source(“external”, “lo1”, 0)
set_tx_lo_source(“external”, “lo1”, 1)

% export the internal LO to the 1:4 splitter
set_tx_lo_export_enabled(true, “lo1”, 0)

% enable the 1:4 splitter output port

get_device()->get_tree()->access("mboards/0/dboards/A/tx_frontends/0/los/lo1/lo_distribution/LO_OUT_0/export").set(true)


I don't think the current GR code has support for controlling
the splitter, so a "code snippet" would likely be required.



To unsubscribe send an email to
usrp-users-le...@lists.ettus.com





___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: N321 LO sharing between RF 0/1

[Paul Atreides]

Agreed on all parts. I already have the loopback cables as same type, same 
length. The plan is to tweak the phase offset to 0 using some high precision 
equipment, then see what degree of control can be obtained once the channels 
are phase aligned. 
Gonna look and see if the Python API supports the splitter control, snippet may 
work!



> On Jan 14, 2022, at 18:58, Marcus D. Leech  wrote:
> 
> 
> On 2022-01-14 18:10, Paul Atreides wrote:
>> Ok thanks. In my haste I was mistaken in assuming that the LO gain would 
>> track with the RF output gain. Silly mistake. I’m still getting used to 
>> separating out the LO. 
>> 
>> I can put this on a SpectrumAnalyzer (with an attenuator in line) on Monday.
>> 
>> I’m trying to take channel to channel phase measurements to determine what 
>> level of phase control I can have over one channel.
> My guess is that if you extrude the LO out and then loop it back in, with 
> equal-length, equal-type cables, the channel-to-channel phase error will be 
> quite small.
> 
> If the phase-error that results is *fixed* and *characterized*, you can 
> simply rotate the phase of one of the baseband signals to compensate.
> 
>> 
>> It’s not critical that I use GNURadio but it seemed like the logical option 
>> as it’s very easy to make those adjustments.
>> 
>> I will look at the python API and see if the commands Rob was talking about 
>> can be invoked using Python  instead of writing a C++ application.
>> Then I’ll see if that is included in gr-uhd. If not, I can submit a pull 
>> request with any changes.
> I think the only "missing piece" is the control for the splitter module, and 
> with GR3.9+ you can use a code snippet to insert that, I think.
> 
> 
>> 
>> I’ll ping the gnuradio chat later tonight.
>> 
>> 
>> Thanks for the help guys are in
>> 
>> 
>>> On Jan 14, 2022, at 17:43, Marcus D. Leech  wrote:
>>> 
>>> 
>>> On 2022-01-14 17:35, Paul Atreides wrote:
 Using a B210 at f_c of the N321. TX LO OUT0 is plugged into RX2 of the  
 B210
>>> You might want to put an attenuator inline, since the LO output is a couple 
>>> of dBm, which is
>>>   "loud as a heavy metal concert" from the perspective of a receiver input.
>>> 
>>> If the splitter isn't enabled in this test, then what you're seeing is the 
>>> leakage through the RF
>>>   switch that enables the splitter, which means that once the splitter is 
>>> turned on, the
>>>   signal will be even louder...
>>> 
>>> 
 
 
 
 On Fri, Jan 14, 2022 at 5:32 PM Marcus D. Leech  
 wrote:
> On 2022-01-14 17:30, Rob Kossler wrote:
>> These thare the UHD commands. I don't know how these translate to 
>> gnuradio.
>> 
>> % set both LO sources to use external
>> set_tx_lo_source(“external”, “lo1”, 0)
>> set_tx_lo_source(“external”, “lo1”, 1)
>> 
>> % export the internal LO to the 1:4 splitter
>> set_tx_lo_export_enabled(true, “lo1”, 0)
>> 
>> % enable the 1:4 splitter output port
>> get_device()->get_tree()->access("mboards/0/dboards/A/tx_frontends/0/los/lo1/lo_distribution/LO_OUT_0/export").set(true)
>> 
> I don't think the current GR code has support for controlling the 
> splitter, so a "code snippet" would likely be required.
> 
> 
 To unsubscribe send an email to usrp-users-le...@lists.ettus.com
> 
>>> 
> 
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com