Я имел в виду фазу кода. Если перебирать все фазы кода в диапазоне 0-2045 и все частоты в зоне -7000..+7000 Гц с шагом 1 Гц, то нужно 28 миллионов корреляций посчитать. Это очень много. А гарантий, что уровень сигнала в выбранном участке данных высокий - нет.
Я по положительной искал. И не по одному из каналов i/q, а по двум. Использовал классический корень из суммы квадратов. Посмотрите gps_correlation8() и correlation_search() здесь.
Я не понимаю, как вы устанавливаете частоты с такой точностью, не зная фазы сигнала.
Я бы рекомендовал, для тестирования кода, анализировать данные одного спутника, к примеру, с PRN=5, задать постоянным смещение частоты - 1000 Гц. Далее для каждого блока по 1мс перебирать все варианты фазы кода и выводить в консоль или сразу на график фазы кода, где был максимум корреляции. Если по этим данным построить график (именно точками, не линиями), то должна получится картина, аналогичная тому, что была в статье в пункте "Поиск фазы кода". Если на графике есть наклонная линия - значит алгоритм нормально работает и "видит" сигнал спутника.
То тогда придется использовать оба канала I/Q, что выходят из микросхемы. Соответственно, при переносе частот в софте придется формировать не просто "синус", а пару cos/sin (хотя так и сейчас делается). Смена знака частоты, в таком случае, так понимаю, делается через смену знака одной из составляющих.
Черным показан сектор, принимаемый антенной, но в нем некоторые спутники все равно могли быть закрыты домами или иметь слишком низкий уровень сигнала. Координаты и время указаны, можете попробовать использовать этот сервис: https://www.gnssplanning.com/#/settings
Точное значение частоты я сказать не могу, значения, приведённые в файле, округлены примерно до 500 Гц. Для спутника 5 смещение частоты - около 1200 Гц. Я не могу дать никаких гарантий, что в первых 2мс данных сигнал от спутников был качественный и стабильный.
Я специально приложил к данным файл, который считывает данные из source2.bin и декодирует их. У меня нет желания писать конвертер.
По логике действительно так, вот только даже в относительно бытовых модулях часто оказывается более высокая точность. Как этого добиваются - не знаю. Возможные варианты - просто усреднение (аналогично тому как в АЦП используют оверсемплинг) или какая-то интерполяция данных. Возможно, @GreatGehar что-то подскажет?
"У меня нет статистики, как в среднем распределяются смещения частот в реальной жизни." У меня есть ощущение, что отклонения частоты разных спутников равномерно распределены по диапазону сканирования, а не сосредоточены ближе к нулю.
И чем оно лучше обычного сканирования? У меня нет статистики, как в среднем распределяются смещения частот в реальной жизни. Могу только сказать, что из-за того, что TCXO может иметь свою ошибку, то частоты всех принимаемых сигналов будут сдвинуты на единицы кГц относительно нуля. Интересно, что кроме обычных спутников GPS, есть еще геостационарные WAAS. Они передают свой сигнал на L1, так что их сигнал не должен иметь допплеровского смещения.
Данные source2.bin собраны с использованием MAX2769, которая тоже упоминается в этой статье. Так что частоты там 16.368 и 4.092 МГц. Я же говорил - данные были собраны для тестирования приёмника на STM32, который работает с MAX2769.
Вы точно к той статье задаете вопрос? В этой статье для Acquisition сгенерированный PRN код сразу пропускается через FFT. В какой форме там перемножение происходит - точно не помню, это же не мой код.
Верно, у GPS разброс около +-5кГц, зона поиска может быть расширена для компенсации ошибки TCXO и учета скорости движения приёмника. А на картинке выше - LEO, т.е. низкая орбита. Вопрос ведь был про форму кривой.
Да, выглядит верно.
Данные идут непрерывно.
Первый байт после декодирования - 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 (хотя так и сейчас делается). Смена знака частоты, в таком случае, так понимаю, делается через смену знака одной из составляющих.
Распределение было такое:
Черным показан сектор, принимаемый антенной, но в нем некоторые спутники все равно могли быть закрыты домами или иметь слишком низкий уровень сигнала.
Координаты и время указаны, можете попробовать использовать этот сервис: https://www.gnssplanning.com/#/settings
Точное значение частоты я сказать не могу, значения, приведённые в файле, округлены примерно до 500 Гц.
Для спутника 5 смещение частоты - около 1200 Гц.
Я не могу дать никаких гарантий, что в первых 2мс данных сигнал от спутников был качественный и стабильный.
Я специально приложил к данным файл, который считывает данные из source2.bin и декодирует их.
У меня нет желания писать конвертер.
Вот здесь попробуйте посмотреть - https://github.com/taroz/GNSS-SDRLIB/blob/master/test/testdata_download_link.txt
В случае SiGe GN3S V3 вроде бы как раз данные частот такие же - 16.368/4.092 МГц и данные - только I в формате int8_t.
По логике действительно так, вот только даже в относительно бытовых модулях часто оказывается более высокая точность. Как этого добиваются - не знаю.
Возможные варианты - просто усреднение (аналогично тому как в АЦП используют оверсемплинг) или какая-то интерполяция данных.
Возможно, @GreatGehar что-то подскажет?
"У меня нет статистики, как в среднем распределяются смещения частот в реальной жизни."
У меня есть ощущение, что отклонения частоты разных спутников равномерно распределены по диапазону сканирования, а не сосредоточены ближе к нулю.
По-моему - нет. Без корреляции обнаружить сигнал спутника нельзя.
И чем оно лучше обычного сканирования?
У меня нет статистики, как в среднем распределяются смещения частот в реальной жизни.
Могу только сказать, что из-за того, что TCXO может иметь свою ошибку, то частоты всех принимаемых сигналов будут сдвинуты на единицы кГц относительно нуля.
Интересно, что кроме обычных спутников GPS, есть еще геостационарные WAAS. Они передают свой сигнал на L1, так что их сигнал не должен иметь допплеровского смещения.
Данные source2.bin собраны с использованием MAX2769, которая тоже упоминается в этой статье. Так что частоты там 16.368 и 4.092 МГц. Я же говорил - данные были собраны для тестирования приёмника на STM32, который работает с MAX2769.
Вы точно к той статье задаете вопрос? В этой статье для Acquisition сгенерированный PRN код сразу пропускается через FFT. В какой форме там перемножение происходит - точно не помню, это же не мой код.
Верно, у GPS разброс около +-5кГц, зона поиска может быть расширена для компенсации ошибки TCXO и учета скорости движения приёмника.
А на картинке выше - LEO, т.е. низкая орбита. Вопрос ведь был про форму кривой.
Да, там нелинейная зависимость:
https://www.mdpi.com/1424-8220/20/20/5866
Я видел варианты шага 100-500 Гц. В статье про приемник на MCU я использовал шаг 500 Гц, в той статье это число упомянуто.
Выложенный у меня вариант GNSS-SDRLIB собран с шагом 100 Гц.