Mon, Jun 23, 2025 5:57 AM
Hi,
I am trying to get RFNOC Fosphor working on an X310. I am able to build a FPGA image containing the fosphor module, but it does not work with the GNU Radio fosphor example. Error message shows: rfnoc rx streamer :warning: Received fractional vector! Expect signal fagmentation.
I am using the lastest UHD with the latest GNURadio. I am using the XG image with two 10G ports connected. MTU is set to 9000.
Is there anything wrong with my configurations?
Please find attached my yml file for the FPGA image as well as the grc file for GNURadio.
Thanks,
Zhouzhiwen
Hi,
I am trying to get RFNOC Fosphor working on an X310. I am able to build a FPGA image containing the fosphor module, but it does not work with the GNU Radio fosphor example. Error message shows: rfnoc rx streamer :warning: Received fractional vector! Expect signal fagmentation.
I am using the lastest UHD with the latest GNURadio. I am using the XG image with two 10G ports connected. MTU is set to 9000.
Is there anything wrong with my configurations?
Please find attached my yml file for the FPGA image as well as the grc file for GNURadio.
Thanks,
Zhouzhiwen
NB
Nikos Balkanas
Mon, Jun 23, 2025 6:57 AM
Hi Zhou,
Is this a general RFNOC rx streamer problem? Do you get similar errors when
you receive other data?
If it is just with Fosphor, my guess is that you don't feed it at least
1024 complex samples.
It works with FFT, so that any less than 1024 samples will make it unhappy:(
HTH
Nikos
On Mon, Jun 23, 2025 at 8:58 AM 周智文 zhiwen_zhou@seu.edu.cn wrote:
Hi,
I am trying to get RFNOC Fosphor working on an X310. I am able to build a
FPGA image containing the fosphor module, but it does not work with the
GNU Radio fosphor example. Error message shows: rfnoc rx streamer
:warning: Received fractional vector! Expect signal fagmentation.
I am using the lastest UHD with the latest GNURadio. I am using the XG
image with two 10G ports connected. MTU is set to 9000.
Is there anything wrong with my configurations?
Please find attached my yml file for the FPGA image as well as the grc
file for GNURadio.
Thanks,
Zhouzhiwen
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
Hi Zhou,
Is this a general RFNOC rx streamer problem? Do you get similar errors when
you receive other data?
If it is just with Fosphor, my guess is that you don't feed it at least
1024 complex samples.
It works with FFT, so that any less than 1024 samples will make it unhappy:(
HTH
Nikos
On Mon, Jun 23, 2025 at 8:58 AM 周智文 <zhiwen_zhou@seu.edu.cn> wrote:
> Hi,
> I am trying to get RFNOC Fosphor working on an X310. I am able to build a
> FPGA image containing the fosphor module, but it does not work with the
> GNU Radio fosphor example. Error message shows: rfnoc rx streamer
> :warning: Received fractional vector! Expect signal fagmentation.
> I am using the lastest UHD with the latest GNURadio. I am using the XG
> image with two 10G ports connected. MTU is set to 9000.
> Is there anything wrong with my configurations?
> Please find attached my yml file for the FPGA image as well as the grc
> file for GNURadio.
>
> Thanks,
> Zhouzhiwen
>
>
> _______________________________________________
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-leave@lists.ettus.com
>
ZZ
zhiwen_zhou@seu.edu.cn
Mon, Jun 23, 2025 8:08 AM
Hi Nikos,
Thank you for responding!
I think it’s just with Fosphor since streaming from DUC works fine.
How to ensure that at least 1024 complex samples is fed into the Fosphor module? I’ve set the FFT size to 1024, and it still does not work.
Does it have something to do with my FFT set up? Since I’ve changed the old ‘fft_1x64.yml’ to 'fft.yml', is there any additional parameters required?
My current FFT config:
fft_a:
block_desc: 'fft.yml'
parameters:
MAX_FFT_SIZE_LOG2: 10
fft_b:
block_desc: 'fft.yml'
parameters:
MAX_FFT_SIZE_LOG2: 10
Zhouzhiwen
Hi Nikos,\
\
Thank you for responding!\
\
I think it’s just with Fosphor since streaming from DUC works fine.\
How to ensure that at least 1024 complex samples is fed into the Fosphor module? I’ve set the FFT size to 1024, and it still does not work.\
Does it have something to do with my FFT set up? Since I’ve changed the old ‘fft_1x64.yml’ to 'fft.yml', is there any additional parameters required?\
My current FFT config:\
\
fft_a:
block_desc: 'fft.yml'
parameters:
MAX_FFT_SIZE_LOG2: 10
\
fft_b:
block_desc: 'fft.yml'
parameters:
MAX_FFT_SIZE_LOG2: 10\
\
\
Zhouzhiwen
ZZ
zhiwen_zhou@seu.edu.cn
Mon, Jun 23, 2025 8:08 AM
Hi Nikos,
Thank you for responding!
I think it’s just with Fosphor since streaming from DUC works fine.
How to ensure that at least 1024 complex samples is fed into the Fosphor module? I’ve set the FFT size to 1024, and it still does not work.
Does it have something to do with my FFT set up? Since I’ve changed the old ‘fft_1x64.yml’ to 'fft.yml', is there any additional parameters required?
My current FFT config:
fft_a:
block_desc: 'fft.yml'
parameters:
MAX_FFT_SIZE_LOG2: 10
fft_b:
block_desc: 'fft.yml'
parameters:
MAX_FFT_SIZE_LOG2: 10
Zhouzhiwen
Hi Nikos,\
\
Thank you for responding!\
\
I think it’s just with Fosphor since streaming from DUC works fine.\
How to ensure that at least 1024 complex samples is fed into the Fosphor module? I’ve set the FFT size to 1024, and it still does not work.\
Does it have something to do with my FFT set up? Since I’ve changed the old ‘fft_1x64.yml’ to 'fft.yml', is there any additional parameters required?\
My current FFT config:\
\
fft_a:
block_desc: 'fft.yml'
parameters:
MAX_FFT_SIZE_LOG2: 10
\
fft_b:
block_desc: 'fft.yml'
parameters:
MAX_FFT_SIZE_LOG2: 10\
\
\
Zhouzhiwen
NB
Nikos Balkanas
Mon, Jun 23, 2025 2:05 PM
Hi Zhou,
Not sure about your fft.yml. I don't use RFNOC, just straight fosphor from
the shell:)
Log2(1024) = 10. that part is right, have you tried MIN_FFT_SIZE_LOG2 10?
or simple FFT_SIZE_LOG2 10 to see if they work?
Maybe smn else with more RFNOC experience can help:)
BR
Nikos
On Mon, Jun 23, 2025 at 11:10 AM zhiwen_zhou@seu.edu.cn wrote:
Hi Nikos,
Thank you for responding!
I think it’s just with Fosphor since streaming from DUC works fine.
How to ensure that at least 1024 complex samples is fed into the Fosphor
module? I’ve set the FFT size to 1024, and it still does not work.
Does it have something to do with my FFT set up? Since I’ve changed the
old ‘fft_1x64.yml’ to 'fft.yml', is there any additional parameters
required?
My current FFT config:
fft_a:
block_desc: 'fft.yml'
parameters:
MAX_FFT_SIZE_LOG2: 10
fft_b:
block_desc: 'fft.yml'
parameters:
MAX_FFT_SIZE_LOG2: 10
Zhouzhiwen
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
Hi Zhou,
Not sure about your fft.yml. I don't use RFNOC, just straight fosphor from
the shell:)
Log2(1024) = 10. that part is right, have you tried MIN_FFT_SIZE_LOG2 10?
or simple FFT_SIZE_LOG2 10 to see if they work?
Maybe smn else with more RFNOC experience can help:)
BR
Nikos
On Mon, Jun 23, 2025 at 11:10 AM <zhiwen_zhou@seu.edu.cn> wrote:
> Hi Nikos,
>
> Thank you for responding!
>
> I think it’s just with Fosphor since streaming from DUC works fine.
> How to ensure that at least 1024 complex samples is fed into the Fosphor
> module? I’ve set the FFT size to 1024, and it still does not work.
> Does it have something to do with my FFT set up? Since I’ve changed the
> old ‘fft_1x64.yml’ to 'fft.yml', is there any additional parameters
> required?
> My current FFT config:
>
> fft_a:
>
> block_desc: 'fft.yml'
>
> parameters:
>
> MAX_FFT_SIZE_LOG2: 10
>
>
> fft_b:
>
> block_desc: 'fft.yml'
>
> parameters:
>
> MAX_FFT_SIZE_LOG2: 10
>
>
> Zhouzhiwen
> _______________________________________________
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-leave@lists.ettus.com
>
ZZ
zhiwen_zhou@seu.edu.cn
Tue, Jun 24, 2025 8:02 AM
I’ve resolved this issue. As it turns out, 'spp=1024' is necessary for the ‘RFNoC RX Radio’ block. The correct yml and grc file are attached for reference.
I’ve resolved this issue. As it turns out, 'spp=1024' is necessary for the ‘RFNoC RX Radio’ block. The correct yml and grc file are attached for reference.
NB
Nikos Balkanas
Tue, Jun 24, 2025 9:04 AM
Hi Zhou,
Glad you were able to resolve your issue.
Interesting...spp = 1024, has nothing to do with fosphor, but instead
adjusts all I/O to the streamer.
It is used to set maxsps (maximun samples per second) for your streamer.
Errors to that generate
a crash in your convert functions. What is your connection MTU? With 9000
MTU you should get 1991 maxsps...
Is your hardware, cable, card OK? Check uhd_rx_streamer_max_num_samps for
more details.
HTH
Nikios
On Tue, Jun 24, 2025 at 11:03 AM zhiwen_zhou@seu.edu.cn wrote:
Hi Zhou,
Glad you were able to resolve your issue.
Interesting...spp = 1024, has nothing to do with fosphor, but instead
adjusts all I/O to the streamer.
It is used to set maxsps (maximun samples per second) for your streamer.
Errors to that generate
a crash in your convert functions. What is your connection MTU? With 9000
MTU you should get 1991 maxsps...
Is your hardware, cable, card OK? Check uhd_rx_streamer_max_num_samps for
more details.
HTH
Nikios
On Tue, Jun 24, 2025 at 11:03 AM <zhiwen_zhou@seu.edu.cn> wrote:
> I’ve resolved this issue. As it turns out, 'spp=1024' is necessary for the
> ‘RFNoC RX Radio’ block. The correct yml and grc file are attached for
> reference.
> _______________________________________________
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-leave@lists.ettus.com
>
NS
niels.steffen.garibaldi@emerson.com
Tue, Jun 24, 2025 9:29 AM
Hi,
Some RFNoC blocks which process samples in in batches can require `spp` to be set to the batch size or a multiple/divider of it.
To my knowledge the updated FFT block is one of them. At least the example specifies that the SPP should evenly divide the FFT size.
So depending on your FFT size, this would probably be my guess to why you are seeing issues when not setting `spp` according to this scheme.
Regards,
Niels
Nikos Balkanas wrote:
Hi Zhou,
Glad you were able to resolve your issue.
Interesting...spp = 1024, has nothing to do with fosphor, but instead
adjusts all I/O to the streamer.
It is used to set maxsps (maximun samples per second) for your streamer.
Errors to that generate
a crash in your convert functions. What is your connection MTU? With 9000
MTU you should get 1991 maxsps...
Is your hardware, cable, card OK? Check uhd_rx_streamer_max_num_samps for
more details.
HTH
Nikios
On Tue, Jun 24, 2025 at 11:03 AM zhiwen_zhou@seu.edu.cn wrote:
Hi,\
\
Some RFNoC blocks which process samples in in batches can require \`spp\` to be set to the batch size or a multiple/divider of it.\
\
To my knowledge the updated FFT block is one of them. At least the [example specifies that the SPP should evenly divide the FFT size](https://github.com/EttusResearch/uhd/blob/c354764c93b49c90be08958f942b9bcb7704cbd5/host/examples/python/fft_loopback.py#L577).
\
So depending on your FFT size, this would probably be my guess to why you are seeing issues when not setting \`spp\` according to this scheme.\
\
Regards,\
\
Niels
---
Nikos Balkanas wrote:
> Hi Zhou,
>
> Glad you were able to resolve your issue.
> Interesting...spp = 1024, has nothing to do with fosphor, but instead
> adjusts all I/O to the streamer.
> It is used to set maxsps (maximun samples per second) for your streamer.
> Errors to that generate
> a crash in your convert functions. What is your connection MTU? With 9000
> MTU you should get 1991 maxsps...
> Is your hardware, cable, card OK? Check uhd_rx_streamer_max_num_samps for
> more details.
>
> HTH
> Nikios
>
> On Tue, Jun 24, 2025 at 11:03 AM [zhiwen_zhou@seu.edu.cn](mailto:zhiwen_zhou@seu.edu.cn) wrote:
>
> > I’ve resolved this issue. As it turns out, 'spp=1024' is necessary for the
> > ‘RFNoC RX Radio’ block. The correct yml and grc file are attached for
> > reference.
> >
> > ---
> >
> > USRP-users mailing list -- usrp-users@lists.ettus.com
> > To unsubscribe send an email to usrp-users-leave@lists.ettus.com
NB
Nikos Balkanas
Tue, Jun 24, 2025 9:39 AM
Hi Niels,
To my experience fosphor is happier with non multiple of the FFT size, it
loops and generates a "livelier" spectrum.
When given exact multiple, it creates a static picture.
Ofc the fft block is different and has different requirements...
Check out these spectra...
On Tue, Jun 24, 2025 at 12:30 PM niels.steffen.garibaldi--- via USRP-users <
usrp-users@lists.ettus.com> wrote:
Hi,
Some RFNoC blocks which process samples in in batches can require spp
to
be set to the batch size or a multiple/divider of it.
To my knowledge the updated FFT block is one of them. At least the example
specifies that the SPP should evenly divide the FFT size
https://github.com/EttusResearch/uhd/blob/c354764c93b49c90be08958f942b9bcb7704cbd5/host/examples/python/fft_loopback.py#L577
.
So depending on your FFT size, this would probably be my guess to why you
are seeing issues when not setting spp
according to this scheme.
Regards,
Niels
Nikos Balkanas wrote:
Hi Zhou,
Glad you were able to resolve your issue. Interesting...spp = 1024, has
nothing to do with fosphor, but instead adjusts all I/O to the streamer. It
is used to set maxsps (maximun samples per second) for your streamer.
Errors to that generate a crash in your convert functions. What is your
connection MTU? With 9000 MTU you should get 1991 maxsps... Is your
hardware, cable, card OK? Check uhd_rx_streamer_max_num_samps for more
details.
HTH Nikios
On Tue, Jun 24, 2025 at 11:03 AM zhiwen_zhou@seu.edu.cn wrote:
I’ve resolved this issue. As it turns out, 'spp=1024' is necessary for the
‘RFNoC RX Radio’ block. The correct yml and grc file are attached for
reference.
USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send
an email to usrp-users-leave@lists.ettus.com
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
Hi Niels,
To my experience fosphor is happier with non multiple of the FFT size, it
loops and generates a "livelier" spectrum.
When given exact multiple, it creates a static picture.
Ofc the fft block is different and has different requirements...
Check out these spectra...
On Tue, Jun 24, 2025 at 12:30 PM niels.steffen.garibaldi--- via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi,
>
> Some RFNoC blocks which process samples in in batches can require `spp` to
> be set to the batch size or a multiple/divider of it.
>
> To my knowledge the updated FFT block is one of them. At least the example
> specifies that the SPP should evenly divide the FFT size
> <https://github.com/EttusResearch/uhd/blob/c354764c93b49c90be08958f942b9bcb7704cbd5/host/examples/python/fft_loopback.py#L577>
> .
>
>
> So depending on your FFT size, this would probably be my guess to why you
> are seeing issues when not setting `spp` according to this scheme.
>
> Regards,
>
> Niels
> ------------------------------
>
> Nikos Balkanas wrote:
>
> Hi Zhou,
>
> Glad you were able to resolve your issue. Interesting...spp = 1024, has
> nothing to do with fosphor, but instead adjusts all I/O to the streamer. It
> is used to set maxsps (maximun samples per second) for your streamer.
> Errors to that generate a crash in your convert functions. What is your
> connection MTU? With 9000 MTU you should get 1991 maxsps... Is your
> hardware, cable, card OK? Check uhd_rx_streamer_max_num_samps for more
> details.
>
> HTH Nikios
>
> On Tue, Jun 24, 2025 at 11:03 AM zhiwen_zhou@seu.edu.cn wrote:
>
> I’ve resolved this issue. As it turns out, 'spp=1024' is necessary for the
> ‘RFNoC RX Radio’ block. The correct yml and grc file are attached for
> reference.
> ------------------------------
>
> USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send
> an email to usrp-users-leave@lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-leave@lists.ettus.com
>
ZZ
zhiwen_zhou@seu.edu.cn
Wed, Jun 25, 2025 1:46 AM
My MTU is 9000 and uhd_rx_streamer_max_num_samps returns 1996.
My MTU is 9000 and uhd_rx_streamer_max_num_samps returns 1996.