Если не ошибаюсь, GPT может довольно убедительно рассказать, что 2+2=5, стоит только попросить. Это может быть проблемой - человек должен выискивать, нет ли в рассуждениях GPT ошибок.
Поэтому еще есть такое в официальной документации: 20.3.3.5.2.4 Coordinated Universal Time (UTC). " Page 18 of subframe 4 includes: (1) the parameters needed to relate GPS time to UTC" Дальше идут параметры и формулы. Эти параметры я не использовал.
Навигационные данные идут с низкой скоростью - 50bit/s, дальномерный код - 1.023 Mbit/s. Но дальномерный код просто повторяется, и, упрощенно говоря, является синхроимпульсами сложной формы.
В данном случае даже int8_t избыточен - из 8 бит используются только два. Другие типы приемников могут давать более приличную упаковку данных, помещая по 4 семпла в 1 байт. С wav так в принципе не сделать.
"Как в декодированном BPSK потоке семплов найти начало бита, если уже долгое время передаются только нули (или только единицы)?" Никак. Нет смены значения битов -> нет смены фазы -> нечего искать.
Про софт. Похоже, древняя программа SkyGlobe прошла мимо вас. Тут эмулятор есть: https://archive.org/details/SkyGlobe_1020 Можно сказать, предок Stellarium из начала 90х.
Насколько я понял, автор все-таки не дальномер сделал, а просто наблюдает, как меняется фаза сигнала при перемещении микрофона. Говоря по другому, к качестве опорного сигнала для измерения разности фаз, используются сколько-то первых семплов записи. Можно сравнить такую конструкцию с линейным инкрементальным энкодером, который тоже не дает информации об абсолютном положении.
Интересно, что если проводить аналогии с энкодерами, можно вспомнить, что не зря они делаются квадратурными - это нужно, чтобы можно было измерять направление сдвига. Подозреваю, что и со звуком выходит тоже самое - только с одной частотой нельзя точно определить направление сдвига микрофона. Отсюда и неопределенности, которые упоминаются в статье. Вот тут и может пригодится передача сигнала на нескольких частотах. Но абсолютное расстояние таким образом не получить.
Приемник может подстроить фазу своего гетеродина и под принятую синусоиду. Для того, чтобы измерить абсолютное расстояние, нужно, чтобы синхронизация фаз передатчика и приемника не зависела от расстояния, а этого нельзя добиться, используя передачу данных только в одну сторону. При этом не важно, какая там используется модуляция, не важно, импульсный принцип, или фазовый.
"синхронизовать гетеродин" Только на приемнике? Фазовыми методами расстояние измерить можно, если приемник связан с передатчиком линией связи известной длинны. В лазерных рулетках (использующих фазовый метод измерения расстояния) приемник и передатчик находятся в одном корпусе, расстояние между ними фиксированное, и они, конечно, электрически связаны. А если нет способа синхронизировать приемник и передатчик между собой, то и абсолютное расстояние не измерить. Никак.
Меня полностью устраивает отладка через IDE. Отладка позволяет использовать breakpoint, удобным образом смотреть содержимое памяти и модифицировать ее, выполнять программу пошагово. Не нужно встраивать в софт лишний код, боятся, что он часть ресурсов MCU заберет, не нужно лишний UART в MCU занимать, и лишний USB в ноутбуке (там и так портов мало).
Предлагаю вам на Хабре написать статью с опросами - знают ли люди про CLI и есть ли у них желание его использовать. Я вот знаю, что CLI можно организовать, но у меня совершенно нет такого желания.
Если не ошибаюсь, GPT может довольно убедительно рассказать, что 2+2=5, стоит только попросить. Это может быть проблемой - человек должен выискивать, нет ли в рассуждениях GPT ошибок.
В Subframe1 есть Hand Over Word (HOW), в нем есть TOW (time-of-week).
Также в Subframe1 10-битный Week Number.
Объединяя их, можно получить время.
https://github.com/iliasam/STM32F4_SDR_GPS/blob/develop/Firmware/project_single_sat/GPS/nav_data_decode.c
Только там нужно знать год примерно, чтобы знать, от какой даты будет отсчитываться Week Number. Плюс, вроде там есть какие-то тонкости с leap second.
Поэтому еще есть такое в официальной документации:
20.3.3.5.2.4 Coordinated Universal Time (UTC).
" Page 18 of subframe 4 includes: (1) the parameters needed to relate GPS time to UTC"
Дальше идут параметры и формулы.
Эти параметры я не использовал.
Да, примерно такая погрешность будет.
Я специально не приводил формулы в статье.
"Любая формула, включенная в книгу, уменьшает число ее покупателей вдвое".
В статье дана ссылка на книгу, в которой есть нужные формулы: https://www.ocf.berkeley.edu/~marsy/resources/gnss/A Software-Defined GPS and Galileo Receiver.pdf
И да, теории там много.
В GPS используется кодовое разделение данных, все спутники предают сигнал на одной частоте.
Про то, как устроена передача данных в GPS, я писал здесь: https://habr.com/ru/articles/765402/
Навигационные данные идут с низкой скоростью - 50bit/s, дальномерный код - 1.023 Mbit/s. Но дальномерный код просто повторяется, и, упрощенно говоря, является синхроимпульсами сложной формы.
В GPS BPSK точно используется без OFDM.
В данном случае даже int8_t избыточен - из 8 бит используются только два. Другие типы приемников могут давать более приличную упаковку данных, помещая по 4 семпла в 1 байт. С wav так в принципе не сделать.
"Как в декодированном BPSK потоке семплов найти начало бита, если уже долгое время передаются только нули (или только единицы)?"
Никак. Нет смены значения битов -> нет смены фазы -> нечего искать.
"-Как бороться с тем, что в BPSK модуляции данные можно интерпретировать и принять как инвертированные биты?"
Вы сами ответили на этот вопрос в тексте: "Видимо это задача протокола канального уровня."
Используются уникальная комбинация битов/проверка CRC/особые виды кодирования: https://wirelesspi.com/resolving-phase-ambiguity-through-unique-word-and-differential-encoding-and-decoding/
https://en.wikipedia.org/wiki/Differential_coding
Про софт. Похоже, древняя программа SkyGlobe прошла мимо вас.
Тут эмулятор есть: https://archive.org/details/SkyGlobe_1020
Можно сказать, предок Stellarium из начала 90х.
Нужно ждать момент смены знака, другого способа я не знаю.
Это сработает, но это совершенно сторонние методы синхронизации, требующие дополнительного железа и каналов связи.
Каким образом?
Может, в таком случае дать пользователю возможность самому выбирать регион?
Насколько я понял, автор все-таки не дальномер сделал, а просто наблюдает, как меняется фаза сигнала при перемещении микрофона.
Говоря по другому, к качестве опорного сигнала для измерения разности фаз, используются сколько-то первых семплов записи.
Можно сравнить такую конструкцию с линейным инкрементальным энкодером, который тоже не дает информации об абсолютном положении.
Интересно, что если проводить аналогии с энкодерами, можно вспомнить, что не зря они делаются квадратурными - это нужно, чтобы можно было измерять направление сдвига. Подозреваю, что и со звуком выходит тоже самое - только с одной частотой нельзя точно определить направление сдвига микрофона. Отсюда и неопределенности, которые упоминаются в статье.
Вот тут и может пригодится передача сигнала на нескольких частотах. Но абсолютное расстояние таким образом не получить.
Приемник может подстроить фазу своего гетеродина и под принятую синусоиду.
Для того, чтобы измерить абсолютное расстояние, нужно, чтобы синхронизация фаз передатчика и приемника не зависела от расстояния, а этого нельзя добиться, используя передачу данных только в одну сторону. При этом не важно, какая там используется модуляция, не важно, импульсный принцип, или фазовый.
"синхронизовать гетеродин"
Только на приемнике?
Фазовыми методами расстояние измерить можно, если приемник связан с передатчиком линией связи известной длинны. В лазерных рулетках (использующих фазовый метод измерения расстояния) приемник и передатчик находятся в одном корпусе, расстояние между ними фиксированное, и они, конечно, электрически связаны.
А если нет способа синхронизировать приемник и передатчик между собой, то и абсолютное расстояние не измерить. Никак.
Я так понял, что пока передатчик и приемник не имеют другой связи, кроме как через звук, абсолютное расстояние не измерить.
Меня полностью устраивает отладка через IDE.
Отладка позволяет использовать breakpoint, удобным образом смотреть содержимое памяти и модифицировать ее, выполнять программу пошагово.
Не нужно встраивать в софт лишний код, боятся, что он часть ресурсов MCU заберет, не нужно лишний UART в MCU занимать, и лишний USB в ноутбуке (там и так портов мало).
Предлагаю вам на Хабре написать статью с опросами - знают ли люди про CLI и есть ли у них желание его использовать.
Я вот знаю, что CLI можно организовать, но у меня совершенно нет такого желания.
Судя по тексту, циферблат он действительно сам сгенерировал, о чем дальше идет речь.