Что-то механика станка мне непонятна. Станок сам себе винт одной из осей не перепилит (тот, что вертикальный на 1 фотографии)? Или тут стол для крепления заготовки не установлен?
Я специально написал в статье рядом с аналогичной картинкой: "а вот частота здесь подписана неверно, в действительности значения - не Hz, это просто значение индекса среди N перебираемых частот. " В этой программе acquisition вообще странновато работает, иногда он может давать немного разные результаты с одним и тем же файлом данных.
Я этой таблицы вообще не понимаю. Первый бит, который примет SPI, будет помещен в LSB (D0), последующие биты будет помещаться "слева", шестнадцатый бит будет помещён в MSB (D15). 0bMSB.....LSB
Я имел в виду фазу кода. Если перебирать все фазы кода в диапазоне 0-2045 и все частоты в зоне -7000..+7000 Гц с шагом 1 Гц, то нужно 28 миллионов корреляций посчитать. Это очень много. А гарантий, что уровень сигнала в выбранном участке данных высокий - нет.
Я по положительной искал. И не по одному из каналов i/q, а по двум. Использовал классический корень из суммы квадратов. Посмотрите gps_correlation8() и correlation_search() здесь.
Я не понимаю, как вы устанавливаете частоты с такой точностью, не зная фазы сигнала.
Я бы рекомендовал, для тестирования кода, анализировать данные одного спутника, к примеру, с PRN=5, задать постоянным смещение частоты - 1000 Гц. Далее для каждого блока по 1мс перебирать все варианты фазы кода и выводить в консоль или сразу на график фазы кода, где был максимум корреляции. Если по этим данным построить график (именно точками, не линиями), то должна получится картина, аналогичная тому, что была в статье в пункте "Поиск фазы кода". Если на графике есть наклонная линия - значит алгоритм нормально работает и "видит" сигнал спутника.
То тогда придется использовать оба канала I/Q, что выходят из микросхемы. Соответственно, при переносе частот в софте придется формировать не просто "синус", а пару cos/sin (хотя так и сейчас делается). Смена знака частоты, в таком случае, так понимаю, делается через смену знака одной из составляющих.
Да, это опечатка, постараюсь поправить, как смогу.
Код выложен, можете посмотреть.
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 .
Похоже, вы что-то делаете не так.
Вот такой тестовый код (точнее, его часть):
Здесь использованы те же функции, что и репозитории:
https://github.com/iliasam/STM32F4_SDR_GPS/blob/develop/Firmware/project_main/GPS/gps_misc.c
Код выдает такие значения (первые 20 штук):
Hidden text
1360
137
504
2043
2043
1670
1112
2043
2043
450
1153
2043
2043
1775
1266
2043
2043
1840
485
2043
Моно видеть, что значение 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 (хотя так и сейчас делается). Смена знака частоты, в таком случае, так понимаю, делается через смену знака одной из составляющих.