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

Add support for complex int16_t and uint16_t type files #6

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

darkstar007
Copy link

Simple patch to support int16_t and uint16_t files.

Tested with LimeSDR with a complex int16_t file from broadcast DVB-S signal from Astra satellite.

There is an issue I'm not sure the best way to solve. Due to 16bit nature of the data, the graphs now don't show too much as they are scaled for a byte. There is the option of applying a scale in the cconverter class, but that will cause a truncation of the data (due to int operations) before stuffing it into a float32 - would be better to preserve all the bits, not just the MSB.

Thanks,

Matt

@pabr
Copy link
Owner

pabr commented May 20, 2017

Thank you for testing; I will implement something along these lines and address the scaling issue.

I would rather set the origin for uint16_t at 32768 than 2048, though. Can limesdr output signed 16-bit instead of unsigned without overhead ? Alternatively, can it shift the uint16_t format so that the four LSB bits are zero ?

@darkstar007
Copy link
Author

The limesdr does signed int16_t by default, so that's not an issue (its a 12bit ADC, left shifted by 4). I have access to another system which uses a 12bit ADC and outputs between 0 and 4095, which is why I set the level to 2048. I also have access to a 14bit ADC (0 to 16383) - so thinking about it, it might be necessary to make it a user chosen value? (Or look at small block of data and estimate a mean).

Thanks,

Matt

@darkstar007
Copy link
Author

darkstar007 commented May 21, 2017

One thing I have noticed is that it doesn't appear to read all of the file - in fact its reading only a small fraction of it - its not giving any indication as to why it stops. I'll investigate further......

Edit: I've done some more looking around. If I change in framework.h to following function in schedular to be:

    unsigned long long hash() {
      unsigned long long h = 0;
      for ( int i=0; i<npipes; ++i ) {h += (1+i)*pipes[i]->hash(); fprintf(stderr, "%s %lld ", pipes[i]->name, (1+i)*pipes[i]->hash()); }
fprintf(stderr, "      %lld\n", h);
      return h;
    }

I get the attached output.
leandvb_hash_vals.txt

From which it appears the packet counter gets stuck first. I'm not really sure where to go from here....

For info, this is the command line I'm running:

./leandvb --i16 -f 36000000 --drift --cr 5/6   --sr 22000000 -v  --gui <~/devel/mygnuradio/sky_lime_20170521_082216_36000_982_ch0.ci16 >sky2.ts 2>hash.txt

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

Successfully merging this pull request may close these issues.

2 participants