Skip to content

Add support for complex int16_t and uint16_t type files - #6

Open
darkstar007 wants to merge 2 commits into
pabr:masterfrom
darkstar007:master
Open

Add support for complex int16_t and uint16_t type files#6
darkstar007 wants to merge 2 commits into
pabr:masterfrom
darkstar007:master

Conversation

@darkstar007

Copy link
Copy Markdown

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

pabr commented May 20, 2017

Copy link
Copy Markdown
Owner

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
Copy Markdown
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

darkstar007 commented May 21, 2017

Copy link
Copy Markdown
Author

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