Matlab (unlike octave as of version 3.8.2) is able to read single-bit values, so here are a couple of very simple programs for converting interleaved shorts and interleaved chars to bit-streams ready to be used in Matlab. The awkward conversion from char to bits reading the imaginary part first is due to the layout of my flowchart: I have put the imaginary part on the top position of the interleave block and real part on the bottom, so that the real part is in the even samples and the imaginary part in the odd ones.

One way of reading such values in GNU/Octave might be through the bitget function after reading single bytes, but I have not attempted to do as much

Function File: c = bitget (A, n) Return the status of bit(s) n of the unsigned integers in A. The least significant bit is n = 1. bitget (100, 8:-1:1) ⇒ 0 1 1 0 0 1 0 0 See also: bitand, bitor, bitxor, bitset, bitcmp, bitshift, bitmax.In Matlab, reading N-bit samples is as simple as

data=fread(fid,inf,'bitN') or data=fread(fid,inf,'ubitN')Of course, manipulating data at the bit value means hitting the endianness issue. By generating a subset of the recorded samples

$ head -c 128 150719_gn3s_ishort.bin > test_ishort.bin $ xxd test_ishort.bin 0000000: ffff ffff ffff ffff 0100 ffff 0100 ffff ................ 0000010: 0100 0100 0100 0100 0100 0100 0100 0100 ................ 0000020: 0100 0100 0100 0100 0100 0100 0100 0100 ................ 0000030: 0100 0100 0100 0100 0100 0100 ffff 0100 ................ 0000040: ffff 0100 ffff 0100 ffff 0100 0100 0100 ................ 0000050: 0100 ffff 0100 ffff 0100 ffff 0100 ffff ................ 0000060: 0100 0100 0100 0100 ffff 0100 ffff 0100 ................ 0000070: ffff 0100 ffff ffff ffff ffff ffff ffff ................we see that since the x86 PC I am using is little endian, all +1 values appear as 0100, while -1 is alway 0xFF(FF), whatever the endianness.

Converting such an interleaved short dataset to bits shrinks the size 16-fold as seen below, and the gain is (obviously) 8-fold from interleaved chars to bits:

$ ./short2bit test_ishort.bin total 3354736 -rw-r--r-- 1 jmfriedt jmfriedt 1053532160 Jul 19 10:54 150719_gn3s_ichar.bin -rw------- 1 jmfriedt jmfriedt 131691520 Jul 19 20:51 150719_gn3s_ichar2ibit1.bin -rw-r--r-- 1 jmfriedt jmfriedt 2273165312 Jul 19 10:44 150719_gn3s_ishort.bin -rw------- 1 jmfriedt jmfriedt 142072832 Jul 19 20:22 150719_gn3s_ishort2ibit1.binThe gain in storage space is obvious, and close to optimum. But are the data correctly encoded ? Running the GPS acquisition program on such datasets, the result indeed matches the result from processing ishort or ichar values.

These charts were generated using the this script assuming a copy of cacode.m as found on the Matlab Central repository is located in the Matlab path. The raw binary files needed to reproduce these charts, recorded on July 19th 2015, are 150719_gn3s_ichar2ibit1.bin (132 MB for a 1 minute long record) and 150719_gn3s_ishort2ibit1.bin (142 MB).