On 14/03/2023 10:27, Vermeulen, Bas (Consultant) wrote:
The problem isn't so much the byteswapping in the int16, but the
int16's being swapped.
I am sending SC16's (I0 Q0 I1 Q1 I2 Q2 I3 Q3), and expect to receive
the 16 bit values in the same order (Val0 Val1 Val2 Val3).
When using sc8's, I got (I3 Q3 I2 Q2 I1 Q1 I0 Q0) which I didn't
expect at all.
Regards,
Bas Vermeulen
Like i pointed out earlier, X310 doesn't support SC8 data, so I have no
idea what it will do if you try to "force" the issue.
------------------------------------------------------------------------
*From:* Marcus D. Leech <patchvonbr...@gmail.com>
*Sent:* Wednesday, March 8, 2023 8:46 PM
*To:* Rob Kossler <rkoss...@nd.edu>
*Cc:* usrp-users@lists.ettus.com <usrp-users@lists.ettus.com>
*Subject:* [USRP-users] Re: RFNOC module sending back (or receiving)
data in the wrong order
Sent by an external sender
------------------------------------------------------------------------
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
<patchvonbr...@gmail.com <mailto:patchvonbr...@gmail.com>> 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
<patchvonbr...@gmail.com <mailto:patchvonbr...@gmail.com>> 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
<wade.f...@ettus.com <mailto:wade.f...@ettus.com>> 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
<mailto: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
<http://www.molex.com/confidentiality.html>
_______________________________________________
USRP-users mailing list --
usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>
To unsubscribe send an email to
usrp-users-le...@lists.ettus.com
<mailto:usrp-users-le...@lists.ettus.com>
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>
To unsubscribe send an email to
usrp-users-le...@lists.ettus.com
<mailto:usrp-users-le...@lists.ettus.com>
_______________________________________________
USRP-users mailing list --usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>
To unsubscribe send an email tousrp-users-le...@lists.ettus.com
<mailto:usrp-users-le...@lists.ettus.com>
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>
To unsubscribe send an email to
usrp-users-le...@lists.ettus.com
<mailto:usrp-users-le...@lists.ettus.com>
------------------------------------------------------------------------
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
