usrp-users@lists.ettus.com
Discussion and technical support related to USRP, UHD, RFNoC
View all threadsRe: setting lenght of fft RFNoC UHD 4
On 2021-09-13 2:29 p.m., Ivan Zahartchuk wrote:
Tell me how to create a yaml file for such a graph correctly? I tried
like this but I get errors. I have not found such examples.
Please copy user-users on these e-mails. Others may have better
insights than myself on these things, and bringing in the wider
community is always a good idea.
The phrase "but I get errors" isn't terribly useful unless those errors
are included in the problem report. I MAY or MAY NOT be able
to help, since I'm not an RFNOC user or developer. But without those
errors available to the people you're asking for help,
it's pretty tough to do ANYTHING.
ср, 8 сент. 2021 г. в 02:13, Marcus D. Leech <patchvonbraun@gmail.com
mailto:patchvonbraun@gmail.com>:
On 2021-09-07 5:55 p.m., Ivan Zahartchuk wrote:
I am setting 256 points FFT with the following parameters:
fft_amplitude =
uhd.libpyuhd.rfnoc.fft_magnitude.MAGNITUDE_SQUARED fft_direction
= uhd.libpyuhd.rfnoc.fft_direction.FORWARD fft_shift =
uhd.libpyuhd.rfnoc.fft_shift.NORMAL After that I do abs and
display the data. Tell me how to do it better? And do I need to
set a different type for the array which is passed to the recv
function when setting Mag ** 2?
Actually, there IS a logpwr block in RFNOC. I don't know exactly
what scaling strategy it uses.
If I wanted to get power estimates out of an RFNOC FFT, I'd have:
FFT(with MAG2)--->MOVING_AVG--->KEEP-ONE-IN-N all inside RFNOC,
and then scale to my hearts content at leisurely rates on the host.
ср, 8 сент. 2021 г. в 00:43, Marcus D. Leech
<patchvonbraun@gmail.com <mailto:patchvonbraun@gmail.com>>:
On 2021-09-07 4:17 p.m., Ivan Zahartchuk wrote:
Hello. There is any information on my question. I also
noticed that if you take the data after the FFT, then the
sensitivity drops very much. I see a -30 dBm signal but -60
dBm is no longer displayed.
How are you scaling and displaying your FFT output? What
options do you have set on your FFT? DO you have it using
Mag**2, how do you scale it
after that?
сб, 4 сент. 2021 г. в 00:04, Ivan Zahartchuk
<adray0001@gmail.com <mailto:adray0001@gmail.com>>:
Here is my script. I am trying to read different amounts
of data from DDC and from FFT. Are there any new
statements on my question?
чт, 2 сент. 2021 г. в 10:06, Jonathon Pendlum
<jonathon.pendlum@ettus.com
<mailto:jonathon.pendlum@ettus.com>>:
Great, thanks. Can you also share your latest python
script?
Jonathon
On Wed, Sep 1, 2021 at 6:37 PM Ivan Zahartchuk
<adray0001@gmail.com <mailto:adray0001@gmail.com>>
wrote:
Yes, I can try it but next week. But I still
wanted to do FFT on FPGA. And one more question.
Is it possible to create two streamers and read
256 samples one at a time and another 8192 for
example? I want to do FFT on one channel and
start a stream with DDC for demodulation on the
other. What is possible?
ср, 1 сент. 2021 г. в 21:09, Jonathon Pendlum
<jonathon.pendlum@ettus.com
<mailto:jonathon.pendlum@ettus.com>>:
Hi Ivan,
Can you try running your script with the SPP
set to 512 and without the FFT block, i.e.
Radio -> Rx Streamer? This may be a general
issue with SPP unrelated to the FFT. I'm
getting the same "Bad CHDR packet" error on
a different device with the FIR filter
block, but it goes away when I remove the block.
Jonathon
On Mon, Aug 30, 2021 at 3:46 PM Marcus D.
Leech <patchvonbraun@gmail.com
<mailto:patchvonbraun@gmail.com>> wrote:
On 2021-08-30 2:30 p.m., Ivan Zahartchuk
wrote:
Thanks. Still trying to work this out.
In UHD 4, the interface to the FPGA
changed from a straightforward DMA
implementation--done by ADI for
their IIO subsystem, to a driver that
makes the FPGA/Radio "look" like a
network device with an MTU of 9000.
With an MTU that large, you should have
no trouble with 512-bin FFTs. But
clearly, you are.
The "int0" network interface exists only
while there's a session with the radio,
so it won't show up in "ifconfig" unless
there's a session active,
and it indeed has an MTU of 9000. So
MTU isn't your problem. It's something
else, and I'm not sure what at the moment.
пн, 30 авг. 2021 г. в 15:08, Marcus D.
Leech <patchvonbraun@gmail.com
<mailto:patchvonbraun@gmail.com>>:
On 2021-08-29 7:17 a.m., Ivan
Zahartchuk wrote:
Thanks a lot. Here is my output
with uhd_usrp_probe and my code:
Could you share with us the output of:
ip link
or ifconfig
сб, 28 авг. 2021 г. в 20:19,
Marcus D. Leech
<patchvonbraun@gmail.com
<mailto:patchvonbraun@gmail.com>>:
On 2021-08-28 10:49 a.m., Ivan
Zahartchuk wrote:
Tell me who I can turn to for
help or how can I solve the
problem with the fact that I
cannot set the number of FFT
points> 256. I apologize for
my persistence, but this is
critical for me. Thank you
for understanding.
Ivan, I've been poking around
all morning try to find where
there may be a limit. I can't
find it. I'm hampered by not
being an RFNOC expert.
I have a query in to Ettus
R&D, but it being the weekend,
I don't expect any kind of
answer until Monday.
Could you share your Python
code, and the output of
uhd_usrp_probe on your E310?
Hi Ivan,
If your issues are still the following: streaming works fine for FFT length
256, but causes streaming errors at FFT lengths 512 and above, the issue is
very likely related to the packet length that the FFT block produces.
The stock RFNoC FFT block from Ettus asserts TLAST on the final FFT sample,
which makes the packet length equal to the FFT length. For a 512 point
FFT, this means that the number of bytes in a packet is 2048+header_bytes.
This is a problem if the interface MTU is less than that (often at 1500).
So, the answer is to figure out how to get the interface MTU set to a
larger value. If that is not possible, then the answer is to modify the
FFT block so that the packet length is not dependent on the FFT size. For
example, the FFT block could assert TLAST every 256 samples, independent of
the actual FFT length. There are old posts about this if you search the
archive.
Rob
On Mon, Sep 13, 2021 at 5:30 PM Marcus D. Leech patchvonbraun@gmail.com
wrote:
On 2021-09-13 2:29 p.m., Ivan Zahartchuk wrote:
Tell me how to create a yaml file for such a graph correctly? I tried like this but I get errors. I have not found such examples.
Please copy user-users on these e-mails. Others may have better insights
than myself on these things, and bringing in the wider
community is always a good idea.
The phrase "but I get errors" isn't terribly useful unless those errors
are included in the problem report. I MAY or MAY NOT be able
to help, since I'm not an RFNOC user or developer. But without those
errors available to the people you're asking for help,
it's pretty tough to do ANYTHING.
ср, 8 сент. 2021 г. в 02:13, Marcus D. Leech patchvonbraun@gmail.com:
On 2021-09-07 5:55 p.m., Ivan Zahartchuk wrote:
I am setting 256 points FFT with the following parameters:fft_amplitude = uhd.libpyuhd.rfnoc.fft_magnitude.MAGNITUDE_SQUAREDfft_direction = uhd.libpyuhd.rfnoc.fft_direction.FORWARDfft_shift = uhd.libpyuhd.rfnoc.fft_shift.NORMALAfter that I do abs and display the data. Tell me how to do it better? And do I need to set a different type for the array which is passed to the recv function when setting Mag ** 2?
Actually, there IS a logpwr block in RFNOC. I don't know exactly what
scaling strategy it uses.
If I wanted to get power estimates out of an RFNOC FFT, I'd have:
FFT(with MAG2)--->MOVING_AVG--->KEEP-ONE-IN-N all inside RFNOC, and
then scale to my hearts content at leisurely rates on the host.
ср, 8 сент. 2021 г. в 00:43, Marcus D. Leech patchvonbraun@gmail.com:
On 2021-09-07 4:17 p.m., Ivan Zahartchuk wrote:
Hello. There is any information on my question. I also noticed that if you take the data after the FFT, then the sensitivity drops very much. I see a -30 dBm signal but -60 dBm is no longer displayed.
How are you scaling and displaying your FFT output? What options do you
have set on your FFT? DO you have it using Mag**2, how do you scale it
after that?
сб, 4 сент. 2021 г. в 00:04, Ivan Zahartchuk adray0001@gmail.com:
Here is my script. I am trying to read different amounts of data from DDC and from FFT.Are there any new statements on my question?
чт, 2 сент. 2021 г. в 10:06, Jonathon Pendlum <
jonathon.pendlum@ettus.com>:
Great, thanks. Can you also share your latest python script?
Jonathon
On Wed, Sep 1, 2021 at 6:37 PM Ivan Zahartchuk adray0001@gmail.com
wrote:
Yes, I can try it but next week. But I still wanted to do FFT on FPGA. And one more question. Is it possible to create two streamers and read 256 samples one at a time and another 8192 for example? I want to do FFT on one channel and start a stream with DDC for demodulation on the other. What is possible?
ср, 1 сент. 2021 г. в 21:09, Jonathon Pendlum <
jonathon.pendlum@ettus.com>:
Hi Ivan,
Can you try running your script with the SPP set to 512 and without
the FFT block, i.e. Radio -> Rx Streamer? This may be a general issue with
SPP unrelated to the FFT. I'm getting the same "Bad CHDR packet" error on a
different device with the FIR filter block, but it goes away when I remove
the block.
Jonathon
On Mon, Aug 30, 2021 at 3:46 PM Marcus D. Leech <
patchvonbraun@gmail.com> wrote:
On 2021-08-30 2:30 p.m., Ivan Zahartchuk wrote:
Thanks. Still trying to work this out. In UHD 4, the interface to
the FPGA changed from a straightforward DMA implementation--done by ADI for
their IIO subsystem, to a driver that makes the FPGA/Radio "look"
like a network device with an MTU of 9000.
With an MTU that large, you should have no trouble with 512-bin
FFTs. But clearly, you are.
The "int0" network interface exists only while there's a session
with the radio, so it won't show up in "ifconfig" unless there's a session
active,
and it indeed has an MTU of 9000. So MTU isn't your problem.
It's something else, and I'm not sure what at the moment.
пн, 30 авг. 2021 г. в 15:08, Marcus D. Leech <
patchvonbraun@gmail.com>:
On 2021-08-29 7:17 a.m., Ivan Zahartchuk wrote:
Thanks a lot. Here is my output with uhd_usrp_probe and my code:
Could you share with us the output of:
ip link
or ifconfig
сб, 28 авг. 2021 г. в 20:19, Marcus D. Leech <
patchvonbraun@gmail.com>:
On 2021-08-28 10:49 a.m., Ivan Zahartchuk wrote:
Tell me who I can turn to for help or how can I solve the problem with the fact that I cannot set the number of FFT points> 256. I apologize for my persistence, but this is critical for me. Thank you for understanding.
Ivan, I've been poking around all morning try to find where there
may be a limit. I can't find it. I'm hampered by not being an RFNOC
expert.
I have a query in to Ettus R&D, but it being the weekend, I don't
expect any kind of answer until Monday.
Could you share your Python code, and the output of
uhd_usrp_probe on your E310?
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
On 2021-09-14 10:24 a.m., Rob Kossler wrote:
Hi Ivan,
If your issues are still the following: streaming works fine for FFT
length 256, but causes streaming errors at FFT lengths 512 and above,
the issue is very likely related to the packet length that the FFT
block produces.
The stock RFNoC FFT block from Ettus asserts TLAST on the final FFT
sample, which makes the packet length equal to the FFT length. For a
512 point FFT, this means that the number of bytes in a packet is
2048+header_bytes. This is a problem if the interface MTU is less
than that (often at 1500). So, the answer is to figure out how to get
the interface MTU set to a larger value. If that is not possible,
then the answer is to modify the FFT block so that the packet length
is not dependent on the FFT size. For example, the FFT block could
assert TLAST every 256 samples, independent of the actual FFT length.
There are old posts about this if you search the archive.
Rob
Thanks, Rob.
But we've already covered that territory--turns out there IS a bug in
recent UHD with FFT and FIR (and other vector functions I think) lengths
256, and a bug
has been raised.
On Mon, Sep 13, 2021 at 5:30 PM Marcus D. Leech
<patchvonbraun@gmail.com mailto:patchvonbraun@gmail.com> wrote:
On 2021-09-13 2:29 p.m., Ivan Zahartchuk wrote:
Tell me how to create a yaml file for such a graph correctly? I
tried like this but I get errors. I have not found such examples.
Please copy user-users on these e-mails. Others may have better
insights than myself on these things, and bringing in the wider
community is always a good idea.
The phrase "but I get errors" isn't terribly useful unless those
errors are included in the problem report. I MAY or MAY NOT be able
to help, since I'm not an RFNOC user or developer. But without
those errors available to the people you're asking for help,
it's pretty tough to do ANYTHING.
ср, 8 сент. 2021 г. в 02:13, Marcus D. Leech
<patchvonbraun@gmail.com <mailto:patchvonbraun@gmail.com>>:
On 2021-09-07 5:55 p.m., Ivan Zahartchuk wrote:
I am setting 256 points FFT with the following parameters:
fft_amplitude =
uhd.libpyuhd.rfnoc.fft_magnitude.MAGNITUDE_SQUARED
fft_direction = uhd.libpyuhd.rfnoc.fft_direction.FORWARD
fft_shift = uhd.libpyuhd.rfnoc.fft_shift.NORMAL After that I
do abs and display the data. Tell me how to do it better?
And do I need to set a different type for the array which is
passed to the recv function when setting Mag ** 2?
Actually, there IS a logpwr block in RFNOC. I don't know
exactly what scaling strategy it uses.
If I wanted to get power estimates out of an RFNOC FFT, I'd have:
FFT(with MAG2)--->MOVING_AVG--->KEEP-ONE-IN-N all inside
RFNOC, and then scale to my hearts content at leisurely rates
on the host.
ср, 8 сент. 2021 г. в 00:43, Marcus D. Leech
<patchvonbraun@gmail.com <mailto:patchvonbraun@gmail.com>>:
On 2021-09-07 4:17 p.m., Ivan Zahartchuk wrote:
Hello. There is any information on my question. I also
noticed that if you take the data after the FFT, then
the sensitivity drops very much. I see a -30 dBm signal
but -60 dBm is no longer displayed.
How are you scaling and displaying your FFT output?
What options do you have set on your FFT? DO you have
it using Mag**2, how do you scale it
after that?
сб, 4 сент. 2021 г. в 00:04, Ivan Zahartchuk
<adray0001@gmail.com <mailto:adray0001@gmail.com>>:
Here is my script. I am trying to read different
amounts of data from DDC and from FFT. Are there
any new statements on my question?
чт, 2 сент. 2021 г. в 10:06, Jonathon Pendlum
<jonathon.pendlum@ettus.com
<mailto:jonathon.pendlum@ettus.com>>:
Great, thanks. Can you also share your latest
python script?
Jonathon
On Wed, Sep 1, 2021 at 6:37 PM Ivan Zahartchuk
<adray0001@gmail.com
<mailto:adray0001@gmail.com>> wrote:
Yes, I can try it but next week. But I
still wanted to do FFT on FPGA. And one
more question. Is it possible to create two
streamers and read 256 samples one at a
time and another 8192 for example? I want
to do FFT on one channel and start a stream
with DDC for demodulation on the other.
What is possible?
ср, 1 сент. 2021 г. в 21:09, Jonathon
Pendlum <jonathon.pendlum@ettus.com
<mailto:jonathon.pendlum@ettus.com>>:
Hi Ivan,
Can you try running your script with
the SPP set to 512 and without the FFT
block, i.e. Radio -> Rx Streamer? This
may be a general issue with SPP
unrelated to the FFT. I'm getting the
same "Bad CHDR packet" error on a
different device with the FIR filter
block, but it goes away when I remove
the block.
Jonathon
On Mon, Aug 30, 2021 at 3:46 PM Marcus
D. Leech <patchvonbraun@gmail.com
<mailto:patchvonbraun@gmail.com>> wrote:
On 2021-08-30 2:30 p.m., Ivan
Zahartchuk wrote:
Thanks. Still trying to work this
out. In UHD 4, the interface to the
FPGA changed from a straightforward
DMA implementation--done by ADI for
their IIO subsystem, to a driver
that makes the FPGA/Radio "look"
like a network device with an MTU
of 9000.
With an MTU that large, you should
have no trouble with 512-bin FFTs.
But clearly, you are.
The "int0" network interface exists
only while there's a session with
the radio, so it won't show up in
"ifconfig" unless there's a session
active,
and it indeed has an MTU of
9000. So MTU isn't your problem.
It's something else, and I'm not
sure what at the moment.
пн, 30 авг. 2021 г. в 15:08,
Marcus D. Leech
<patchvonbraun@gmail.com
<mailto:patchvonbraun@gmail.com>>:
On 2021-08-29 7:17 a.m., Ivan
Zahartchuk wrote:
Thanks a lot. Here is my
output with uhd_usrp_probe
and my code:
Could you share with us the
output of:
ip link
or ifconfig
сб, 28 авг. 2021 г. в 20:19,
Marcus D. Leech
<patchvonbraun@gmail.com
<mailto:patchvonbraun@gmail.com>>:
On 2021-08-28 10:49 a.m.,
Ivan Zahartchuk wrote:
Tell me who I can turn
to for help or how can I
solve the problem with
the fact that I cannot
set the number of FFT
points> 256. I apologize
for my persistence, but
this is critical for me.
Thank you for understanding.
Ivan, I've been poking
around all morning try to
find where there may be a
limit. I can't find it.
I'm hampered by not being
an RFNOC expert.
I have a query in to
Ettus R&D, but it being
the weekend, I don't
expect any kind of answer
until Monday.
Could you share your
Python code, and the
output of uhd_usrp_probe
on your E310?
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
<mailto:usrp-users-leave@lists.ettus.com>
Hello. Please tell me how things are with my question? Perhaps I need
some additional information?
вт, 14 сент. 2021 г. в 22:30, Marcus D. Leech patchvonbraun@gmail.com:
On 2021-09-14 10:24 a.m., Rob Kossler wrote:
Hi Ivan,
If your issues are still the following: streaming works fine for FFT
length 256, but causes streaming errors at FFT lengths 512 and above, the
issue is very likely related to the packet length that the FFT block
produces.
The stock RFNoC FFT block from Ettus asserts TLAST on the final FFT
sample, which makes the packet length equal to the FFT length. For a 512
point FFT, this means that the number of bytes in a packet is
2048+header_bytes. This is a problem if the interface MTU is less than
that (often at 1500). So, the answer is to figure out how to get the
interface MTU set to a larger value. If that is not possible, then the
answer is to modify the FFT block so that the packet length is not
dependent on the FFT size. For example, the FFT block could assert TLAST
every 256 samples, independent of the actual FFT length. There are old
posts about this if you search the archive.
Rob
Thanks, Rob.
But we've already covered that territory--turns out there IS a bug in
recent UHD with FFT and FIR (and other vector functions I think) lengths >
256, and a bug
has been raised.
On Mon, Sep 13, 2021 at 5:30 PM Marcus D. Leech patchvonbraun@gmail.com
wrote:
On 2021-09-13 2:29 p.m., Ivan Zahartchuk wrote:
Tell me how to create a yaml file for such a graph correctly? I tried like this but I get errors. I have not found such examples.
Please copy user-users on these e-mails. Others may have better insights
than myself on these things, and bringing in the wider
community is always a good idea.
The phrase "but I get errors" isn't terribly useful unless those errors
are included in the problem report. I MAY or MAY NOT be able
to help, since I'm not an RFNOC user or developer. But without those
errors available to the people you're asking for help,
it's pretty tough to do ANYTHING.
ср, 8 сент. 2021 г. в 02:13, Marcus D. Leech patchvonbraun@gmail.com:
On 2021-09-07 5:55 p.m., Ivan Zahartchuk wrote:
I am setting 256 points FFT with the following parameters:fft_amplitude = uhd.libpyuhd.rfnoc.fft_magnitude.MAGNITUDE_SQUAREDfft_direction = uhd.libpyuhd.rfnoc.fft_direction.FORWARDfft_shift = uhd.libpyuhd.rfnoc.fft_shift.NORMALAfter that I do abs and display the data. Tell me how to do it better? And do I need to set a different type for the array which is passed to the recv function when setting Mag ** 2?
Actually, there IS a logpwr block in RFNOC. I don't know exactly what
scaling strategy it uses.
If I wanted to get power estimates out of an RFNOC FFT, I'd have:
FFT(with MAG2)--->MOVING_AVG--->KEEP-ONE-IN-N all inside RFNOC, and
then scale to my hearts content at leisurely rates on the host.
ср, 8 сент. 2021 г. в 00:43, Marcus D. Leech patchvonbraun@gmail.com:
On 2021-09-07 4:17 p.m., Ivan Zahartchuk wrote:
Hello. There is any information on my question. I also noticed that if you take the data after the FFT, then the sensitivity drops very much. I see a -30 dBm signal but -60 dBm is no longer displayed.
How are you scaling and displaying your FFT output? What options do
you have set on your FFT? DO you have it using Mag**2, how do you scale it
after that?
сб, 4 сент. 2021 г. в 00:04, Ivan Zahartchuk adray0001@gmail.com:
Here is my script. I am trying to read different amounts of data from DDC and from FFT.Are there any new statements on my question?
чт, 2 сент. 2021 г. в 10:06, Jonathon Pendlum <
jonathon.pendlum@ettus.com>:
Great, thanks. Can you also share your latest python script?
Jonathon
On Wed, Sep 1, 2021 at 6:37 PM Ivan Zahartchuk adray0001@gmail.com
wrote:
Yes, I can try it but next week. But I still wanted to do FFT on FPGA. And one more question. Is it possible to create two streamers and read 256 samples one at a time and another 8192 for example? I want to do FFT on one channel and start a stream with DDC for demodulation on the other. What is possible?
ср, 1 сент. 2021 г. в 21:09, Jonathon Pendlum <
jonathon.pendlum@ettus.com>:
Hi Ivan,
Can you try running your script with the SPP set to 512 and without
the FFT block, i.e. Radio -> Rx Streamer? This may be a general issue with
SPP unrelated to the FFT. I'm getting the same "Bad CHDR packet" error on a
different device with the FIR filter block, but it goes away when I remove
the block.
Jonathon
On Mon, Aug 30, 2021 at 3:46 PM Marcus D. Leech <
patchvonbraun@gmail.com> wrote:
On 2021-08-30 2:30 p.m., Ivan Zahartchuk wrote:
Thanks. Still trying to work this out. In UHD 4, the interface to
the FPGA changed from a straightforward DMA implementation--done by ADI for
their IIO subsystem, to a driver that makes the FPGA/Radio
"look" like a network device with an MTU of 9000.
With an MTU that large, you should have no trouble with 512-bin
FFTs. But clearly, you are.
The "int0" network interface exists only while there's a session
with the radio, so it won't show up in "ifconfig" unless there's a session
active,
and it indeed has an MTU of 9000. So MTU isn't your problem.
It's something else, and I'm not sure what at the moment.
пн, 30 авг. 2021 г. в 15:08, Marcus D. Leech <
patchvonbraun@gmail.com>:
On 2021-08-29 7:17 a.m., Ivan Zahartchuk wrote:
Thanks a lot. Here is my output with uhd_usrp_probe and my code:
Could you share with us the output of:
ip link
or ifconfig
сб, 28 авг. 2021 г. в 20:19, Marcus D. Leech <
patchvonbraun@gmail.com>:
On 2021-08-28 10:49 a.m., Ivan Zahartchuk wrote:
Tell me who I can turn to for help or how can I solve the problem with the fact that I cannot set the number of FFT points> 256. I apologize for my persistence, but this is critical for me. Thank you for understanding.
Ivan, I've been poking around all morning try to find where
there may be a limit. I can't find it. I'm hampered by not being an RFNOC
expert.
I have a query in to Ettus R&D, but it being the weekend, I
don't expect any kind of answer until Monday.
Could you share your Python code, and the output of
uhd_usrp_probe on your E310?
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
On 2021-09-26 5:17 p.m., Ivan Zahartchuk wrote:
Hello. Please tell me how things are with my question? Perhaps I need
some additional information?
Jonathan Pendlum submitted a bug report. I have no way of knowing when
it will be addressed by the R&D team.
вт, 14 сент. 2021 г. в 22:30, Marcus D. Leech <patchvonbraun@gmail.com
mailto:patchvonbraun@gmail.com>:
On 2021-09-14 10:24 a.m., Rob Kossler wrote:
Hi Ivan,
If your issues are still the following: streaming works fine for
FFT length 256, but causes streaming errors at FFT lengths 512
and above, the issue is very likely related to the packet length
that the FFT block produces.
The stock RFNoC FFT block from Ettus asserts TLAST on the final
FFT sample, which makes the packet length equal to the FFT
length. For a 512 point FFT, this means that the number of bytes
in a packet is 2048+header_bytes. This is a problem if the
interface MTU is less than that (often at 1500). So, the answer
is to figure out how to get the interface MTU set to a larger
value. If that is not possible, then the answer is to modify the
FFT block so that the packet length is not dependent on the FFT
size. For example, the FFT block could assert TLAST every 256
samples, independent of the actual FFT length. There are old
posts about this if you search the archive.
Rob
Thanks, Rob.
But we've already covered that territory--turns out there IS a bug
in recent UHD with FFT and FIR (and other vector functions I
think) lengths > 256, and a bug
has been raised.
On Mon, Sep 13, 2021 at 5:30 PM Marcus D. Leech
<patchvonbraun@gmail.com <mailto:patchvonbraun@gmail.com>> wrote:
On 2021-09-13 2:29 p.m., Ivan Zahartchuk wrote:
Tell me how to create a yaml file for such a graph
correctly? I tried like this but I get errors. I have not
found such examples.
Please copy user-users on these e-mails. Others may have
better insights than myself on these things, and bringing in
the wider
community is always a good idea.
The phrase "but I get errors" isn't terribly useful unless
those errors are included in the problem report. I MAY or
MAY NOT be able
to help, since I'm not an RFNOC user or developer. But
without those errors available to the people you're asking
for help,
it's pretty tough to do ANYTHING.
ср, 8 сент. 2021 г. в 02:13, Marcus D. Leech
<patchvonbraun@gmail.com <mailto:patchvonbraun@gmail.com>>:
On 2021-09-07 5:55 p.m., Ivan Zahartchuk wrote:
I am setting 256 points FFT with the following
parameters: fft_amplitude =
uhd.libpyuhd.rfnoc.fft_magnitude.MAGNITUDE_SQUARED
fft_direction =
uhd.libpyuhd.rfnoc.fft_direction.FORWARD fft_shift =
uhd.libpyuhd.rfnoc.fft_shift.NORMAL After that I do abs
and display the data. Tell me how to do it better? And
do I need to set a different type for the array which
is passed to the recv function when setting Mag ** 2?
Actually, there IS a logpwr block in RFNOC. I don't
know exactly what scaling strategy it uses.
If I wanted to get power estimates out of an RFNOC FFT,
I'd have:
FFT(with MAG2)--->MOVING_AVG--->KEEP-ONE-IN-N all inside
RFNOC, and then scale to my hearts content at leisurely
rates on the host.
ср, 8 сент. 2021 г. в 00:43, Marcus D. Leech
<patchvonbraun@gmail.com <mailto:patchvonbraun@gmail.com>>:
On 2021-09-07 4:17 p.m., Ivan Zahartchuk wrote:
Hello. There is any information on my question. I
also noticed that if you take the data after the
FFT, then the sensitivity drops very much. I see a
-30 dBm signal but -60 dBm is no longer displayed.
How are you scaling and displaying your FFT
output? What options do you have set on your FFT?
DO you have it using Mag**2, how do you scale it
after that?
сб, 4 сент. 2021 г. в 00:04, Ivan Zahartchuk
<adray0001@gmail.com <mailto:adray0001@gmail.com>>:
Here is my script. I am trying to read
different amounts of data from DDC and from
FFT. Are there any new statements on my question?
чт, 2 сент. 2021 г. в 10:06, Jonathon Pendlum
<jonathon.pendlum@ettus.com
<mailto:jonathon.pendlum@ettus.com>>:
Great, thanks. Can you also share your
latest python script?
Jonathon
On Wed, Sep 1, 2021 at 6:37 PM Ivan
Zahartchuk <adray0001@gmail.com
<mailto:adray0001@gmail.com>> wrote:
Yes, I can try it but next week. But I
still wanted to do FFT on FPGA. And
one more question. Is it possible to
create two streamers and read 256
samples one at a time and another 8192
for example? I want to do FFT on one
channel and start a stream with DDC
for demodulation on the other. What is
possible?
ср, 1 сент. 2021 г. в 21:09, Jonathon
Pendlum <jonathon.pendlum@ettus.com
<mailto:jonathon.pendlum@ettus.com>>:
Hi Ivan,
Can you try running your script
with the SPP set to 512 and
without the FFT block, i.e. Radio
-> Rx Streamer? This may be a
general issue with SPP unrelated
to the FFT. I'm getting the same
"Bad CHDR packet" error on a
different device with the FIR
filter block, but it goes away
when I remove the block.
Jonathon
On Mon, Aug 30, 2021 at 3:46 PM
Marcus D. Leech
<patchvonbraun@gmail.com
<mailto:patchvonbraun@gmail.com>>
wrote:
On 2021-08-30 2:30 p.m., Ivan
Zahartchuk wrote:
Thanks. Still trying to work
this out. In UHD 4, the
interface to the FPGA changed
from a straightforward DMA
implementation--done by ADI for
their IIO subsystem, to a
driver that makes the
FPGA/Radio "look" like a
network device with an MTU of
9000.
With an MTU that large, you
should have no trouble with
512-bin FFTs. But clearly, you
are.
The "int0" network interface
exists only while there's a
session with the radio, so it
won't show up in "ifconfig"
unless there's a session active,
and it indeed has an MTU of
9000. So MTU isn't your
problem. It's something else,
and I'm not sure what at the
moment.
пн, 30 авг. 2021 г. в 15:08,
Marcus D. Leech
<patchvonbraun@gmail.com
<mailto:patchvonbraun@gmail.com>>:
On 2021-08-29 7:17 a.m.,
Ivan Zahartchuk wrote:
Thanks a lot. Here is my
output with
uhd_usrp_probe and my code:
Could you share with us
the output of:
ip link
or ifconfig
сб, 28 авг. 2021 г. в
20:19, Marcus D. Leech
<patchvonbraun@gmail.com
<mailto:patchvonbraun@gmail.com>>:
On 2021-08-28 10:49
a.m., Ivan
Zahartchuk wrote:
Tell me who I can
turn to for help or
how can I solve the
problem with the
fact that I cannot
set the number of
FFT points> 256. I
apologize for my
persistence, but
this is critical
for me. Thank you
for understanding.
Ivan, I've been
poking around all
morning try to find
where there may be a
limit. I can't find
it. I'm hampered by
not being an RFNOC
expert.
I have a query in to
Ettus R&D, but it
being the weekend, I
don't expect any
kind of answer until
Monday.
Could you share your
Python code, and the
output of
uhd_usrp_probe on
your E310?
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>
To unsubscribe send an email to
usrp-users-leave@lists.ettus.com
<mailto:usrp-users-leave@lists.ettus.com>