Hi,
I would like to view / manipulate the raw samples from the FPGA.
From what I see, in the UHD code each 32-bit word (item) is split to
form a complex float and a scaling factor is used.
Is there a way of transferring the 32-bit words from the FPGA to a C++
GR block without the UHD code modifying it?
Using wireshark I can see the bytes of interested, but I cannot see
these in the UHD item32_to_fc32 function. Should I not be able to see
the bytes as seen in wireshark (UDP payload minus VITA framing) within
this function?
MTIA
Lukasz
–
Queen’s Award for Enterprise and Innovation 2011
Roke Manor Research Ltd
Romsey, Hampshire, SO51 0ZN, United Kingdom
http://www.roke.co.uk
Part of the Chemring Group
Registered in England & Wales at:
Chemring Group PLC, Chemring House, 1500 Parkway,
Whiteley, Fareham, Hampshire PO15 7AF, ENGLAND.
Registered No: 267550
Is there a way of transferring the 32-bit words from the FPGA to a C++
GR block without the UHD code modifying it?
You can use the sc16 data type, this will involve a conversion from
item32 to complex which is basically a byte swap.
You can also use the item32 data type which will just perform endianess
conversion.
Also, both options are available in GRC.
Using wireshark I can see the bytes of interested, but I cannot see
these in the UHD item32_to_fc32 function. Should I not be able to see
the bytes as seen in wireshark (UDP payload minus VITA framing) within
this function?
All vita payload words pass through the converter function.
-josh
On 30-11-2011 9:19 AM, Suleja, Lukasz wrote:
Using wireshark I can see the bytes of interested, but I cannot see
these in the UHD item32_to_fc32 function. Should I not be able to see
the bytes as seen in wireshark (UDP payload minus VITA framing) within
this function?
MTIA
Lukasz
Given that the samples have been filtered and manipulated by the DDC and
CIC decimator code in the FPGA, and thus are only
related to what came off the ADC, I wonder why it’s important to
get the samples in something other than {-1.0,+1.0}.
Further, what goes into the ADC is only related to the physical
phenomenon that it’s measuring.
As background, I have 10 32-bit words of “metadata” prefixed to a burst
of complex samples and I need to extract (and remove) them. I noticed
recently that the trunk has some code related to tagging; in your
opinion would the transport of my “metadata” be better done using
tagging or is there an alternative method you can suggest. It is
important that the “metadata” remain associated exactly with the burst
samples.
So, a friendly note that if you’re running non-standard firmware/FPGA,
you should note that earlier, rather than later,
when you’re asking for help from this list. 99% of the folks on
this list use the as-shipped FPGA/Firmware that
is compatible directly with gr-uhd/Gnu Radio.
So when a question is asked the “context” that most answerers have is
the as-shipped FPGA/Firmware. Which is why I delivered
my “lecture” about ADC samples getting mangled by the decimators in
the FPGA, and why would you care, etc, etc.
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
Noted… but in my defence the questions were asked to aid my
understanding of what is happening in the (stock) UHD code… the
background was to explain why I was bothering.
Hi Josh,
Thank you for the answer… I can now see the data of interest in my C++
code.
Your comments, and Marcus’, have raised a few question…
Is the item32 data the same before the type conversion regardless of
which type is specified for the source in Python.
By that I mean, if I use gr.COMPLEX_INT16 rather than gr.COMPLEX_FLOAT32
will the system operate the same or does it affect other aspects of the
system? Is the only difference that the IQ samples in the (initial) C++
block will be between -32767 to 32768 rather than in the {+1.0, -1.0}
set.
As background, I have 10 32-bit words of “metadata” prefixed to a burst
of complex samples and I need to extract (and remove) them. I noticed
recently that the trunk has some code related to tagging; in your
opinion would the transport of my “metadata” be better done using
tagging or is there an alternative method you can suggest. It is
important that the “metadata” remain associated exactly with the burst
samples.
Kind regards,
Lukasz