[USRP-users] request for "PROBE" n x310

[STEFANI, Maurizio (External) via USRP-users]

HI,
after loaded a fresh copy of FPGA on our x310, I issued the command:

-  uhd_usrp_probe
the results of this are:

mau@mau-Vostro-3500:~$ uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 10.2.1 20201207; Boost_107400; 
UHD_3.15.0.0-4build1
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 1472 bytes.
[INFO] [X300] Radio 1x clock: 200 MHz
Error: AssertionError: Failed to find a valid XML path for RFNoC blocks.
Try setting the environment variable UHD_RFNOC_DIR to the correct location
mau@mau-Vostro-3500:~$

I do not know how to proceed, set the environment variable or other.

Thank you
maurizio

The information in this e-mail is confidential. The contents may not be 
disclosed or used by anyone other than the addressee. Access to this e-mail by 
anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and 
delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of 
this e-mail as it has been sent over public networks. If you have any concerns 
over the content of this message or its Accuracy or Integrity, please contact 
Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus 
scanning software but you should take whatever measures you deem to be 
appropriate to ensure that this message and any attachments are virus free.
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] error to use ettus repository

[STEFANI, Maurizio (External) via USRP-users]

HI,
I am trying to download some ettus uhd test program (firsto of all benchmark)
I issued the following command
mau@mau-Vostro-3500:/usr/local/bin$ sudo add-apt-repository 
ppa:ettusresearch/uhd

the answer to it is
Repository: 'deb http://ppa.launchpad.net/ettusresearch/uhd/ubuntu/ impish main'
More info: https://launchpad.net/~ettusresearch/+archive/ubuntu/uhd
Adding repository.
Press [ENTER] to continue or Ctrl-c to cancel.
Found existing deb entry in 
/etc/apt/sources.list.d/ettusresearch-ubuntu-uhd-impish.list
Adding deb entry to /etc/apt/sources.list.d/ettusresearch-ubuntu-uhd-impish.list
Found existing deb-src entry in 
/etc/apt/sources.list.d/ettusresearch-ubuntu-uhd-impish.list
Adding disabled deb-src entry to 
/etc/apt/sources.list.d/ettusresearch-ubuntu-uhd-impish.list
Adding key to /etc/apt/trusted.gpg.d/ettusresearch-ubuntu-uhd.gpg with 
fingerprint 463896EF9B898A846C7EC0E109FE61056169358E
Trovato:1 http://old-releases.ubuntu.com/ubuntu impish InRelease
Ignorato:2 http://ppa.launchpad.net/ettusresearch/uhd/ubuntu impish InRelease
Trovato:3 http://old-releases.ubuntu.com/ubuntu impish-security InRelease
Trovato:4 http://old-releases.ubuntu.com/ubuntu impish-updates InRelease
Errore:5 http://ppa.launchpad.net/ettusresearch/uhd/ubuntu impish Release
  404  Not Found [IP: 185.125.190.52 80]
Lettura elenco dei pacchetti... Fatto
E: Il repository "http://ppa.launchpad.net/ettusresearch/uhd/ubuntu impish 
Release" non ha un file Release.
N: L'aggiornamento da tale repository non può essere eseguito in modo sicuro ed 
è quindi disabilitato come impostazione predefinita.
N: Consultare la pagina man apt-secure(8) per la creazione di un repository e 
la configurazione utente.
mau@mau-Vostro-3500:/usr/local/bin$

I am using ubuntu release 21.10, codename impish

Any suggestions?

Thank you in advance
Maurizio Stefani (External)
The information in this e-mail is confidential. The contents may not be 
disclosed or used by anyone other than the addressee. Access to this e-mail by 
anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and 
delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of 
this e-mail as it has been sent over public networks. If you have any concerns 
over the content of this message or its Accuracy or Integrity, please contact 
Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus 
scanning software but you should take whatever measures you deem to be 
appropriate to ensure that this message and any attachments are virus free.
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: RFNOC module sending back (or receiving) data in the wrong order

[Rob Kossler]

Maybe can you just change the streamer OTW & CPU format to "sc8" such that
no byte swapping will occur?

On Tue, Mar 7, 2023 at 10:31 PM Wade Fife  wrote:

> You could swap the bytes in your block, or swap them in software on the
> host. The data gets rearranged by the streamer depending on the data type
> configured (e.g., sc16) and the endianness of the host machine.
>
> Wade
>
> On Tue, Mar 7, 2023 at 2:45 AM Vermeulen, Bas (Consultant) via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi,
>>
>> We are developing an RFNOC module that takes I/Q data, and turns that
>> into two 8 bit values.
>> I have a test program that sends data to the RFNOC module, and receives
>> the modified data.
>>
>> The RFNOC module treats the two 8 bit values as one signed 16 bit value.
>> When I read the data from the test program, I get it in the wrong order:
>>
>> Send: Re0 Im0 Re1 Im1 Re2 Im2 Re3 Im3
>> Receive: Val1 Val0 Val3 Val2
>>
>> Does anyone have any idea how to fix the order of the received values?
>>
>> Regards,
>>
>> Bas Vermeulen
>>
>> --
>>
>>
>>
>> CONFIDENTIALITY NOTICE: This message (including any attachments) may
>> contain Molex confidential information, protected by law. If this message
>> is confidential, forwarding it to individuals, other than those with a need
>> to know, without the permission of the sender, is prohibited.
>>
>> This message is also intended for a specific individual. If you are not
>> the intended recipient, you should delete this message and are hereby
>> notified that any disclosure, copying, or distribution of this message or
>> taking of any action based upon it, is strictly prohibited.
>>
>> English | Chinese | Japanese
>> www.molex.com/confidentiality.html
>> ___
>> 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 mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: error to use ettus repository

[Marcus D. Leech]

On 08/03/2023 05:36, STEFANI, Maurizio (External) via USRP-users wrote:


HI,

I am trying to download some ettus uhd test program (firsto of all 
benchmark)


I issued the following command

mau@mau-Vostro-3500:/usr/local/bin$ sudo add-apt-repository 
ppa:ettusresearch/uhd


the answer to it is
Repository: 'deb http://ppa.launchpad.net/ettusresearch/uhd/ubuntu/ 
impish main'
More info: https://launchpad.net/~ettusresearch/+archive/ubuntu/uhd 


Adding repository.
Press [ENTER] to continue or Ctrl-c to cancel.
Found existing deb entry in 
/etc/apt/sources.list.d/ettusresearch-ubuntu-uhd-impish.list
Adding deb entry to 
/etc/apt/sources.list.d/ettusresearch-ubuntu-uhd-impish.list
Found existing deb-src entry in 
/etc/apt/sources.list.d/ettusresearch-ubuntu-uhd-impish.list
Adding disabled deb-src entry to 
/etc/apt/sources.list.d/ettusresearch-ubuntu-uhd-impish.list
Adding key to /etc/apt/trusted.gpg.d/ettusresearch-ubuntu-uhd.gpg with 
fingerprint 463896EF9B898A846C7EC0E109FE61056169358E
Trovato:1 http://old-releases.ubuntu.com/ubuntu 
impish InRelease
Ignorato:2 http://ppa.launchpad.net/ettusresearch/uhd/ubuntu 
impish InRelease
Trovato:3 http://old-releases.ubuntu.com/ubuntu 
impish-security InRelease
Trovato:4 http://old-releases.ubuntu.com/ubuntu 
impish-updates InRelease
Errore:5 http://ppa.launchpad.net/ettusresearch/uhd/ubuntu 
impish Release

  404  Not Found [IP: 185.125.190.52 80]
Lettura elenco dei pacchetti... Fatto
E: Il repository "http://ppa.launchpad.net/ettusresearch/uhd/ubuntu 
impish Release" non ha un file Release.
N: L'aggiornamento da tale repository non può essere eseguito in modo 
sicuro ed è quindi disabilitato come impostazione predefinita.
N: Consultare la pagina man apt-secure(8) per la creazione di un 
repository e la configurazione utente.

mau@mau-Vostro-3500:/usr/local/bin$

I am using ubuntu release 21.10, codename impish

Any suggestions?

Thank you in advance

Maurizio Stefani (External)

The information in this e-mail is confidential. The contents may not 
be disclosed or used by anyone other than the addressee. Access to 
this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus 
immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or 
completeness of this e-mail as it has been sent over public networks. 
If you have any concerns over the content of this message or its 
Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated 
virus scanning software but you should take whatever measures you deem 
to be appropriate to ensure that this message and any attachments are 
virus free.


___
USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-le...@lists.ettus.com
Doesn't look like a PPA was ever created for the "Impish" release of 
Ubuntu -- this was a transitional, NOT LTS release.  If you
  upgrade to Ubuntu 22.04, very-recent Gnu Radio and UHD are already 
packaged and can be installed just with

  "apt".

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

[USRP-users] Re: request for "PROBE" n x310

[Marcus D. Leech]

On 08/03/2023 03:37, STEFANI, Maurizio (External) via USRP-users wrote:


HI,

after loaded a fresh copy of FPGA on our x310, I issued the command:

-uhd_usrp_probe

the results of this are:

mau@mau-Vostro-3500:~$ uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 10.2.1 20201207; Boost_107400; 
UHD_3.15.0.0-4build1

[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 1472 bytes.
[INFO] [X300] Radio 1x clock: 200 MHz
Error: AssertionError: Failed to find a valid XML path for RFNoC blocks.
Try setting the environment variable UHD_RFNOC_DIR to the correct location
mau@mau-Vostro-3500:~$

I do not know how to proceed, set the environment variable or other.

Thank you

maurizio

The information in this e-mail is confidential. The contents may not 
be disclosed or used by anyone other than the addressee. Access to 
this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus 
immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or 
completeness of this e-mail as it has been sent over public networks. 
If you have any concerns over the content of this message or its 
Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated 
virus scanning software but you should take whatever measures you deem 
to be appropriate to ensure that this message and any attachments are 
virus free.


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

UHD_RFNOC_DIR=/usr/share/uhd/3.15.0/rfnoc
export UHD_RFNOC_DIR


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

[USRP-users] Re: RFNOC module sending back (or receiving) data in the wrong order

[Marcus D. Leech]

On 08/03/2023 11:42, Rob Kossler wrote:
Maybe can you just change the streamer OTW & CPU format to "sc8" such 
that no byte swapping will occur?
I know that on the default X3xx builds, there's no sc8 format 
implemented on the USRP end.





On Tue, Mar 7, 2023 at 10:31 PM Wade Fife  wrote:

You could swap the bytes in your block, or swap them in software
on the host. The data gets rearranged by the streamer depending on
the data type configured (e.g., sc16) and the endianness of the
host machine.

Wade

On Tue, Mar 7, 2023 at 2:45 AM Vermeulen, Bas (Consultant) via
USRP-users  wrote:

Hi,

We are developing an RFNOC module that takes I/Q data, and
turns that into two 8 bit values.
I have a test program that sends data to the RFNOC module, and
receives the modified data.

The RFNOC module treats the two 8 bit values as one signed 16
bit value.
When I read the data from the test program, I get it in the
wrong order:

Send: Re0 Im0 Re1 Im1 Re2 Im2 Re3 Im3
Receive: Val1 Val0 Val3 Val2

Does anyone have any idea how to fix the order of the received
values?

Regards,

Bas Vermeulen





CONFIDENTIALITY NOTICE: This message (including any
attachments) may contain Molex confidential information,
protected by law. If this message is confidential, forwarding
it to individuals, other than those with a need to know,
without the permission of the sender, is prohibited.

This message is also intended for a specific individual. If
you are not the intended recipient, you should delete this
message and are hereby notified that any disclosure, copying,
or distribution of this message or taking of any action based
upon it, is strictly prohibited.

English | Chinese | Japanese
www.molex.com/confidentiality.html

___
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 mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-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: RFNOC module sending back (or receiving) data in the wrong order

[Rob Kossler]

Oh yeah, I forgot.  Does this imply that there is no way to keep UHD from
swapping bytes in an rx_streamer (using X310)?  If so, this seems like a
problem for RFNoC development since the data coming across the wire can be
in any format the designer chooses.  And, swapping in the FPGA is not a
good solution because you don't know the Endianness of the host.
Rob

On Wed, Mar 8, 2023 at 12:07 PM Marcus D. Leech 
wrote:

> On 08/03/2023 11:42, Rob Kossler wrote:
>
> Maybe can you just change the streamer OTW & CPU format to "sc8" such that
> no byte swapping will occur?
>
> I know that on the default X3xx builds, there's no sc8 format implemented
> on the USRP end.
>
>
>
> On Tue, Mar 7, 2023 at 10:31 PM Wade Fife  wrote:
>
>> You could swap the bytes in your block, or swap them in software on the
>> host. The data gets rearranged by the streamer depending on the data type
>> configured (e.g., sc16) and the endianness of the host machine.
>>
>> Wade
>>
>> On Tue, Mar 7, 2023 at 2:45 AM Vermeulen, Bas (Consultant) via USRP-users
>>  wrote:
>>
>>> Hi,
>>>
>>> We are developing an RFNOC module that takes I/Q data, and turns that
>>> into two 8 bit values.
>>> I have a test program that sends data to the RFNOC module, and receives
>>> the modified data.
>>>
>>> The RFNOC module treats the two 8 bit values as one signed 16 bit value.
>>> When I read the data from the test program, I get it in the wrong order:
>>>
>>> Send: Re0 Im0 Re1 Im1 Re2 Im2 Re3 Im3
>>> Receive: Val1 Val0 Val3 Val2
>>>
>>> Does anyone have any idea how to fix the order of the received values?
>>>
>>> Regards,
>>>
>>> Bas Vermeulen
>>>
>>> --
>>>
>>>
>>>
>>> CONFIDENTIALITY NOTICE: This message (including any attachments) may
>>> contain Molex confidential information, protected by law. If this message
>>> is confidential, forwarding it to individuals, other than those with a need
>>> to know, without the permission of the sender, is prohibited.
>>>
>>> This message is also intended for a specific individual. If you are not
>>> the intended recipient, you should delete this message and are hereby
>>> notified that any disclosure, copying, or distribution of this message or
>>> taking of any action based upon it, is strictly prohibited.
>>>
>>> English | Chinese | Japanese
>>> www.molex.com/confidentiality.html
>>> ___
>>> 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 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 mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: RFNOC module sending back (or receiving) data in the wrong order

[Marcus D. Leech]

On 08/03/2023 13:36, Rob Kossler wrote:
Oh yeah, I forgot.  Does this imply that there is no way to keep UHD 
from swapping bytes in an rx_streamer (using X310)?  If so, this seems 
like a problem for RFNoC development since the data coming across the 
wire can be in any format the designer chooses.  And, swapping in the 
FPGA is not a good solution because you don't know the Endianness of 
the host.

Rob
The "doctrine" has been to represent data types in their "natural 
network-byte-order" on the wire, and the host code
  can do whatever it needs to do.   This is consistent with practice in 
nearly-all other disciplines that send data over
  the network (whether that's the Internet or other ethernet networks, 
etc).


For little-endian hosts, UHD has to do the swap.

But UHD allows you to register your own converter methods.  I've never 
done it myself, but I don't think it's that hard.





On Wed, Mar 8, 2023 at 12:07 PM Marcus D. Leech 
 wrote:


On 08/03/2023 11:42, Rob Kossler wrote:

Maybe can you just change the streamer OTW & CPU format to "sc8"
such that no byte swapping will occur?

I know that on the default X3xx builds, there's no sc8 format
implemented on the USRP end.




On Tue, Mar 7, 2023 at 10:31 PM Wade Fife 
wrote:

You could swap the bytes in your block, or swap them in
software on the host. The data gets rearranged by the
streamer depending on the data type configured (e.g., sc16)
and the endianness of the host machine.

Wade

On Tue, Mar 7, 2023 at 2:45 AM Vermeulen, Bas (Consultant)
via USRP-users  wrote:

Hi,

We are developing an RFNOC module that takes I/Q data,
and turns that into two 8 bit values.
I have a test program that sends data to the RFNOC
module, and receives the modified data.

The RFNOC module treats the two 8 bit values as one
signed 16 bit value.
When I read the data from the test program, I get it in
the wrong order:

Send: Re0 Im0 Re1 Im1 Re2 Im2 Re3 Im3
Receive: Val1 Val0 Val3 Val2

Does anyone have any idea how to fix the order of the
received values?

Regards,

Bas Vermeulen






CONFIDENTIALITY NOTICE: This message (including any
attachments) may contain Molex confidential information,
protected by law. If this message is confidential,
forwarding it to individuals, other than those with a
need to know, without the permission of the sender, is
prohibited.

This message is also intended for a specific individual.
If you are not the intended recipient, you should delete
this message and are hereby notified that any disclosure,
copying, or distribution of this message or taking of any
action based upon it, is strictly prohibited.

English | Chinese | Japanese
www.molex.com/confidentiality.html

___
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 mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-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 mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: RFNOC module sending back (or receiving) data in the wrong order

[Rob Kossler]

Agreed, but it doesn't seem too much to expect that UHD should natively
supply a "non-swapping" converter so that each user who needs one doesn't
have to develop it.
Rob

On Wed, Mar 8, 2023 at 1:45 PM Marcus D. Leech 
wrote:

> On 08/03/2023 13:36, Rob Kossler wrote:
>
> Oh yeah, I forgot.  Does this imply that there is no way to keep UHD from
> swapping bytes in an rx_streamer (using X310)?  If so, this seems like a
> problem for RFNoC development since the data coming across the wire can be
> in any format the designer chooses.  And, swapping in the FPGA is not a
> good solution because you don't know the Endianness of the host.
> Rob
>
> The "doctrine" has been to represent data types in their "natural
> network-byte-order" on the wire, and the host code
>   can do whatever it needs to do.   This is consistent with practice in
> nearly-all other disciplines that send data over
>   the network (whether that's the Internet or other ethernet networks,
> etc).
>
> For little-endian hosts, UHD has to do the swap.
>
> But UHD allows you to register your own converter methods.  I've never
> done it myself, but I don't think it's that hard.
>
>
>
> On Wed, Mar 8, 2023 at 12:07 PM Marcus D. Leech 
> wrote:
>
>> On 08/03/2023 11:42, Rob Kossler wrote:
>>
>> Maybe can you just change the streamer OTW & CPU format to "sc8" such
>> that no byte swapping will occur?
>>
>> I know that on the default X3xx builds, there's no sc8 format implemented
>> on the USRP end.
>>
>>
>>
>> On Tue, Mar 7, 2023 at 10:31 PM Wade Fife  wrote:
>>
>>> You could swap the bytes in your block, or swap them in software on the
>>> host. The data gets rearranged by the streamer depending on the data type
>>> configured (e.g., sc16) and the endianness of the host machine.
>>>
>>> Wade
>>>
>>> On Tue, Mar 7, 2023 at 2:45 AM Vermeulen, Bas (Consultant) via
>>> USRP-users  wrote:
>>>
 Hi,

 We are developing an RFNOC module that takes I/Q data, and turns that
 into two 8 bit values.
 I have a test program that sends data to the RFNOC module, and receives
 the modified data.

 The RFNOC module treats the two 8 bit values as one signed 16 bit value.
 When I read the data from the test program, I get it in the wrong order:

 Send: Re0 Im0 Re1 Im1 Re2 Im2 Re3 Im3
 Receive: Val1 Val0 Val3 Val2

 Does anyone have any idea how to fix the order of the received values?

 Regards,

 Bas Vermeulen

 --



 CONFIDENTIALITY NOTICE: This message (including any attachments) may
 contain Molex confidential information, protected by law. If this message
 is confidential, forwarding it to individuals, other than those with a need
 to know, without the permission of the sender, is prohibited.

 This message is also intended for a specific individual. If you are not
 the intended recipient, you should delete this message and are hereby
 notified that any disclosure, copying, or distribution of this message or
 taking of any action based upon it, is strictly prohibited.

 English | Chinese | Japanese
 www.molex.com/confidentiality.html
 ___
 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 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 mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: RFNOC module sending back (or receiving) data in the wrong order

[Marcus D. Leech]

On 08/03/2023 14:41, Rob Kossler wrote:
Agreed, but it doesn't seem too much to expect that UHD should 
natively supply a "non-swapping" converter so that each user who needs 
one doesn't have to develop it.

Rob
In this case, the RFNOC code is kinda pretending that it's sending int16 
integers, but the actual semantic is somewhat different.
  So a non-swapping converter would happen to work in this case, but 
it's kind of subverting the "object model" a bit.


Perhaps some kind of "raw" converter in which there's no implied object 
semantics.




On Wed, Mar 8, 2023 at 1:45 PM Marcus D. Leech 
 wrote:


On 08/03/2023 13:36, Rob Kossler wrote:

Oh yeah, I forgot.  Does this imply that there is no way to keep
UHD from swapping bytes in an rx_streamer (using X310)?  If so,
this seems like a problem for RFNoC development since the data
coming across the wire can be in any format the designer
chooses.  And, swapping in the FPGA is not a good solution
because you don't know the Endianness of the host.
Rob

The "doctrine" has been to represent data types in their "natural
network-byte-order" on the wire, and the host code
  can do whatever it needs to do.   This is consistent with
practice in nearly-all other disciplines that send data over
  the network (whether that's the Internet or other ethernet
networks, etc).

For little-endian hosts, UHD has to do the swap.

But UHD allows you to register your own converter methods. I've
never done it myself, but I don't think it's that hard.




On Wed, Mar 8, 2023 at 12:07 PM Marcus D. Leech
 wrote:

On 08/03/2023 11:42, Rob Kossler wrote:

Maybe can you just change the streamer OTW & CPU format to
"sc8" such that no byte swapping will occur?

I know that on the default X3xx builds, there's no sc8 format
implemented on the USRP end.




On Tue, Mar 7, 2023 at 10:31 PM Wade Fife
 wrote:

You could swap the bytes in your block, or swap them in
software on the host. The data gets rearranged by the
streamer depending on the data type configured (e.g.,
sc16) and the endianness of the host machine.

Wade

On Tue, Mar 7, 2023 at 2:45 AM Vermeulen, Bas
(Consultant) via USRP-users 
wrote:

Hi,

We are developing an RFNOC module that takes I/Q
data, and turns that into two 8 bit values.
I have a test program that sends data to the RFNOC
module, and receives the modified data.

The RFNOC module treats the two 8 bit values as one
signed 16 bit value.
When I read the data from the test program, I get it
in the wrong order:

Send: Re0 Im0 Re1 Im1 Re2 Im2 Re3 Im3
Receive: Val1 Val0 Val3 Val2

Does anyone have any idea how to fix the order of
the received values?

Regards,

Bas Vermeulen






CONFIDENTIALITY NOTICE: This message (including any
attachments) may contain Molex confidential
information, protected by law. If this message is
confidential, forwarding it to individuals, other
than those with a need to know, without the
permission of the sender, is prohibited.

This message is also intended for a specific
individual. If you are not the intended recipient,
you should delete this message and are hereby
notified that any disclosure, copying, or
distribution of this message or taking of any action
based upon it, is strictly prohibited.

English | Chinese | Japanese
www.molex.com/confidentiality.html

___
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 mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-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] Tx/RX vs RX2 Ettus N320

[jmaloyan]

Hello,

I am a little confused about the naming regarding the TX/RX ports on the Ettus 
N321/N320. If I specify a channel(i.e channel 0) for receive, does that mean 
RX2 will be active, or will TX/RX port be actively receiving? And if TX/RX can 
recieve, does that mean the N320/N321 has up to 4 RX channels?

Thanks

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

[USRP-users] Re: Tx/RX vs RX2 Ettus N320

[Marcus D. Leech]

On 08/03/2023 21:41, jmalo...@umass.edu wrote:


Hello,

I am a little confused about the naming regarding the TX/RX ports on 
the Ettus N321/N320. If I specify a channel(i.e channel 0) for 
receive, does that mean RX2 will be active, or will TX/RX port be 
actively receiving? And if TX/RX can recieve, does that mean the 
N320/N321 has up to 4 RX channels?



Thanks

Joe


___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
Any given RX channel can either be connected to the corresponding RX2 
*OR* TX/RX port.    A TX channel can only ever

  be connected to its corresponding RX/TX port.

It's just an antenna switch for a receive channel.   For half-duplex 
communications techniques it's often the case that a

  single antenna is used and alternates between TX and RX when required.

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