Да, это опечатка, постараюсь поправить, как смогу.

Код выложен, можете посмотреть.
https://github.com/iliasam/STM32F4_SDR_GPS/blob/develop/Firmware/project_main/GPS/tracking.c#L333

Записать реально, я же уже давал вам ссылку - https://github.com/taroz/GNSS-SDRLIB/blob/master/test/testdata_download_link.txt
Только RTL-SDR, как и большинство других SDR приемников, выдает результаты в формате I/Q.

Xircom REX 6000 имел толщину 5мм. Если делать девайс тоньше в два разы, выйдет 2.5мм.
В такую толщину сложно EINK засунуть, и обеспечить ему нормальную защиту от механических воздействий.
Есть такой проект - https://paulschow.com/2016/08/epaper-business-card.html

Декодировать реально - https://myriadrf.org/news/lora-modem-limesdr/
Насколько сложно - не знаю.

Что-то механика станка мне непонятна. Станок сам себе винт одной из осей не перепилит (тот, что вертикальный на 1 фотографии)? Или тут стол для крепления заготовки не установлен?

На профильных дисциплинах такое есть - https://srns.ru/wiki/Blog:Korogodin/14.08.2011,_График_занятий_по_АП_СРНС

Да, если считать, что данные записываются так: 0bMSB.....LSB

У меня алгоритм стабильней работал в таком варианте.
Замечу, что этот участок кода работает только в acquisition.

Я специально написал в статье рядом с аналогичной картинкой:
"а вот частота здесь подписана неверно, в действительности значения - не Hz, это просто значение индекса среди N перебираемых частот. "
В этой программе acquisition вообще странновато работает, иногда он может давать немного разные результаты с одним и тем же файлом данных.

Я этой таблицы вообще не понимаю.
Первый бит, который примет SPI, будет помещен в LSB (D0), последующие биты будет помещаться "слева", шестнадцатый бит будет помещён в MSB (D15).
0bMSB.....LSB

Да, выглядит верно.

Данные идут непрерывно.
Первый байт после декодирования - 0x9E = 0b10011110.

Соответственно, семплы, которые приходили c АЦП в хронологическом порядке - 0,1,1,1,1,0,0,1.

В целом - нелинейно, также как и доплеровское смещение. Но на небольших интервалах времени нелинейность незаметна.

Я уже говорил вам на такой же вопрос, что нет у меня такого желания.
https://habr.com/ru/articles/789382/comments/#comment_26671589

И я не понимаю, в чем сложность в вашем софте сделать и одного байта восемь int8_t .

Похоже, вы что-то делаете не так.
Вот такой тестовый код (точнее, его часть):

void test(void) 
{
    char data_path[300] = "D:\\PATH\\source2.bin";
    gps_fill_summ_table();

    gps_ch_t gps_channel1;
    memset(&gps_channel1, 0, sizeof(gps_channel1));
    gps_channel1.prn = 5;
    gps_channel1.acq_data.given_freq_offset_hz = 1000;
    gps_channell_prepare(&gps_channel1);

    uint8_t read_buffer[BITS_IN_PRN / 8];

    uint8_t res = data_reader_open_file(data_path);
    if (res == 0)
    {
        printf("Open file fail\n");
        return;
    }

    for (int i = 0; i < 2000; i++)
    {
        //Читаем 1мс данных
        res = data_reader_read_unpack(read_buffer, BITS_IN_PRN);
        if (res == 0)
        {
            printf("Can't read file\n");
            return;
        }
        acquisition_freq_test(&gps_channel1, read_buffer);
    }

    data_reader_close_file();
    printf("Execution end\n");
}

#define GPS_DATA_WORDS_CNT      (PRN_SPI_WORDS_CNT + 1)
uint16_t tmp_prn_data[GPS_DATA_WORDS_CNT];
uint16_t tmp_data_i[GPS_DATA_WORDS_CNT];
uint16_t tmp_data_q[GPS_DATA_WORDS_CNT];

//Генерирует локальный PRN код
//Переносит принятые данные на частоту, близкую к 0
//Перебирает все фазы кода, и выводит фазу максимальной
void acquisition_freq_test(gps_ch_t* channel, uint8_t* data)
{
	gps_generate_prn_data2(channel, tmp_prn_data, 0);
	int16_t freq_offset_hz = channel->acq_data.given_freq_offset_hz;

	gps_shift_to_zero_freq(data, (uint8_t*)tmp_data_i, (uint8_t*)tmp_data_q, IF_FREQ_HZ + freq_offset_hz);
	uint16_t avr_val;
	uint16_t best_phase1 = 0;
	correlation_search(tmp_prn_data, tmp_data_i, tmp_data_q, 0, (PRN_LENGTH * 2), &avr_val, &best_phase1);
	printf("%d\n", best_phase1);
}

Здесь использованы те же функции, что и репозитории:
https://github.com/iliasam/STM32F4_SDR_GPS/blob/develop/Firmware/project_main/GPS/gps_misc.c

Код выдает такие значения (первые 20 штук):

Моно видеть, что значение 2043 часто встречается. Это и есть фаза кода.

При увеличении видно, что фаза меняется:

" это была-бы хорошая игрушка для тех молодых ребят"
А вот и плата для них - https://habr.com/ru/articles/214355/

Я имел в виду фазу кода.
Если перебирать все фазы кода в диапазоне 0-2045 и все частоты в зоне -7000..+7000 Гц с шагом 1 Гц, то нужно 28 миллионов корреляций посчитать. Это очень много. А гарантий, что уровень сигнала в выбранном участке данных высокий - нет.

Я по положительной искал. И не по одному из каналов i/q, а по двум.
Использовал классический корень из суммы квадратов.
Посмотрите gps_correlation8() и correlation_search() здесь.

Я не понимаю, как вы устанавливаете частоты с такой точностью, не зная фазы сигнала.

Я бы рекомендовал, для тестирования кода, анализировать данные одного спутника, к примеру, с PRN=5, задать постоянным смещение частоты - 1000 Гц.
Далее для каждого блока по 1мс перебирать все варианты фазы кода и выводить в консоль или сразу на график фазы кода, где был максимум корреляции. Если по этим данным построить график (именно точками, не линиями), то должна получится картина, аналогичная тому, что была в статье в пункте "Поиск фазы кода". Если на графике есть наклонная линия - значит алгоритм нормально работает и "видит" сигнал спутника.

То тогда придется использовать оба канала I/Q, что выходят из микросхемы.
Соответственно, при переносе частот в софте придется формировать не просто "синус", а пару cos/sin (хотя так и сейчас делается). Смена знака частоты, в таком случае, так понимаю, делается через смену знака одной из составляющих.