discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Incorrect quantizations when converting from floa


From: CEL
Subject: Re: [Discuss-gnuradio] Incorrect quantizations when converting from float to char
Date: Sat, 9 Jun 2018 16:08:35 +0000

I can reproduce these, but do the errors disappear for you if you
replace "u_sse2 u_sse2" with "generic generic" on that line?


Best regards,
Marcus
On Sat, 2018-06-09 at 18:04 +0200, Paul Boven wrote:
> Hi Marcus,
> 
> This machine did not yet have a volk_config when I ran these tests.
> 
> I have since run volk_profile and rebooted, and the Float->Char 
> quantization bug still occurs.
> 
> $ volk-config-info --machine
> avx2_64_mmx_orc
> 
> $ grep volk_32f_s32f_convert_8i .volk/volk_config
> volk_32f_s32f_convert_8i u_sse2 u_sse2
> 
> Regards, Paul Boven.
> 
> On 06/09/2018 05:30 PM, Müller, Marcus (CEL) wrote:
> > Hi Paul,
> > 
> > hm, OK, considering the actual conversion is done in VOLK, can you
> > tell
> > us
> > 
> > * whether ~/.volk/volk_config exists (and if so, its contents
> > regarding
> > volk_32f_s32f_convert_8i )
> > * what the output of `volk-config-info --machine` is?
> > 
> > Thanks,
> > Marcus
> > 
> > On Sat, 2018-06-09 at 17:13 +0200, Paul Boven wrote:
> > > Hi everyone,
> > > 
> > > I'm trying to perform 2 bit sampling of an RF signal. In one
> > > approach,
> > > I'm using a float->char block, and noticed that around zero, a
> > > number
> > > of
> > > float inputs become quantized in a bin that's one off from the
> > > correct
> > > value. The ones that are wrong are always off by one, with their
> > > quantization error always in the direction of zero.
> > > 
> > > The problem can be demonstrated with a really simple flowchart,
> > > using
> > > the following blocks:
> > > 
> > > * Noise Source (Noise Type: Gaussian, Amplitude: 1, Seed: 0,
> > > Output
> > > type: Float)
> > > * Throttle
> > > The throttle is then connected to two blocks:
> > > * A file-sink (Type Float) and a
> > > * 'Float to Char' block.
> > > * The float to char block is again connected to a File Sink, now
> > > of
> > > type
> > > Char.
> > > 
> > > As an example, I've plotted all the samples that quantized as
> > > zero.
> > > These should fall in the range [-0.5:0.5], but occasionally we
> > > also
> > > get
> > > hits that lie within [-1:1]. These mishaps are rare (about one in
> > > 2000).
> > > It also shows that they only occur at multiples of 8192 samples,
> > > and
> > > zooming in reveals that they always happen shortly before the
> > > next
> > > multiple of 8192, not after.
> > > 
> > > For other values than 0, the same applies, but the
> > > misquantizations
> > > are
> > > only in one direction, ending up in a lower bin if the input is
> > > positive, or in a higher bin if the input is negative. Again, the
> > > misquantizations only occur in half the bin: For a value of 1,
> > > the
> > > float
> > > value should be in [0.5:1.5], but occasionally a value in [1.5:2]
> > > also
> > > ends up being quantized as 1.
> > > 
> > > This seems to me a bug that is somehow related to internal block
> > > boundaries, but I'm not familiar enough with the internals of
> > > GnuRadio
> > > to figure out just what's going wrong.
> > > 
> > > The problem does NOT occur when converting to Short or Int.
> > > 
> > > This is using GnuRadio 3.7.11 (as packaged with Ubuntu 18.04).
> > > 
> > > Regards, Paul Boven.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > Discuss-gnuradio mailing list
> > > address@hidden
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

Attachment: smime.p7s
Description: S/MIME cryptographic signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]