Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

convert_i16_f adds a portional of original data to the end #57

Open
radiosd opened this issue Nov 27, 2020 · 1 comment
Open

convert_i16_f adds a portional of original data to the end #57

radiosd opened this issue Nov 27, 2020 · 1 comment

Comments

@radiosd
Copy link

radiosd commented Nov 27, 2020

Thank you for this useful DSP tool which I am hoping to use. But I notice something strange when converting data types.

I recorded a 1 second IQ sine wave at 48kHz, and used csdr convert_i16_f to convert to a float file. The int16 file is 185.k where as the float32 file is 176k, which is 1k bigger than the expected 187.5*2.

Using python to read the int16 data to array yy and the float32 data to zz.
The beginnings are the same
yy[:5] = array([ 0.+250.j, -812.+134.j, -824. +18.j, -818. -98.j, -800.-213.j])
np.round(zz[:5]*(1<<15))
array([ 0.+250.j, -812.+134.j, -824. +18.j, -818. -98.j, -800.-213.j], dtype=complex64)

The end of the int16 data is
yy[-5:] = array([ 298.+834.j, 195.+868.j, 88.+885.j, -19.+889.j, -129.+876.j])

While the float32 data extends 128 samples beyond sample 48,000
np.round(zz[-131:-126]*(1<<15))
array([ 88.+885.j, -19.+889.j, -129.+876.j, -564.-658.j, -478.-730.j], dtype=complex64)

So the last sample in the int16 data, shown in bold, is at sample [-129] which corresponds to the expected 48000 th sample of the float32. But there are 128 more samples after 48000.

Then, by scanning through the int data, I found the start of the 128 sample extension to be sample 512 from the end of the original
yy[-513:-508].
array([-637.-573.j, -564.-658.j, -478.-730.j, -389.-789.j, -290.-837.j])
np.round(zz[-129:-124]*(1<<15))
array([-129.+876.j, -564.-658.j, -478.-730.j, -389.-789.j, -290.-837.j], dtype=complex64)

In summary the converted data is 128 samples longer than the original with the added data being a 128 sample section taken 512 samples from the end of the original data. I suspect some buffer under/over run but cannot see where this might occur.

Help in understanding and fixing this would be appreciated. R

Capture

PS this is running on a raspberry pi using the branch recommended in the QTCSDR installation instructions.

@ha7ilm
Copy link
Owner

ha7ilm commented Nov 27, 2020

This has to do with the handling of the last buffer before terminating the application.
Note that it will not happen during realtime processing (just as a transient in the end).

https://github.com/ha7ilm/csdr/blob/master/csdr.c#L594

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants