Оригинальная документация включает спецификацию протокола, описание функций firmware и конфигурирование высокоточных приемников сигналов позиционирования серии u-blox 7. Спецификация протокола описывает версию 14 протоколов NMEA и UBX (перевод документа [1] GPS.G7-SW-12001-B1, 15 июня 2018 г. Все непонятные термины и сокращения см. в разделе "Словарик", в конце статьи).

Описание приемника и его протокола - важный информационный ресурс для применения и конфигурирования чипов и приемников позиционирования u-blox. Описание модульное, поэтому его необязательно читать от начала до конца. В нем 2 основных раздела: описание приемника и описание его протокола. В этой части перевода документации [1] приведено описание приемника. Вторая и третья части перевода [6, 7] содержат описание протоколов NMEA и UBX.

Описание приемника содержит программные аспекты системных функций и конфигурацию технологии позиционирования u-blox. Описание приемника структурирована по областям функциональности, с предоставленными ссылками на соответствующие сообщения NMEA и UBX, информация по которым содержится в спецификации протокола.

Спецификация протокола это справочник, описывающий программные сообщения, используемые в приемнике u-blox GNSS (Global Navigation Satellite System, глобальная спутниковая система определения позиции, к каким относятся системы GPS, GLONASS, QZSS). Этот справочник организован по специфике сообщений NMEA и UBX.

 Этот документ дает общую информацию по приемникам u-blox GNSS. Некоторая информация может быть не применима к определенным моделям чипов и приемников. Обращайтесь к документам product Data Sheet и Hardware Integration Manual для получения информации по возможным ограничениям.

[2. Описание настроек конфигурации навигации]

Эта секция относится к конфигурационному сообщению UBX-CFG-NAV5.

2.1. Настройка платформы (Platform settings)

Технология позиционирования u-blox поддерживает различные модели динамических платформ (см. таблицу ниже) для подстройки системы навигации к ожидаемому рабочему окружению приложения. Эти настройки платформы можно поменять без выключения и включения питания или сброса. Эти настройки улучшают интерпретацию измерений приемником, в результате получается более точное определение позиции. Настройка приемника на не подходящую модель платформы для имеющегося рабочего окружения может повлечь потерю производительности приемника и ухудшение точности позиционирования.

Динамические модели платформ:

Параметры динамических моделей платформ:

 Динамические платформы, разработанные для систем с высокими ускорениями (например бортовая авионика с ускорениями более 2g) могут показывать повышенную стандартную девиацию в определении положения.

2.2. Входные навигационные фильтры

Входные фильтры навигации (Navigation Input Filter) в CFG-NAV5 маскируют входные данные системы навигации.

 Эти настройки уже оптимизированы. Не меняйте никакие параметры, если только изменения не посоветовали сделать инженеры техподдержки u-blox.

Параметры входных фильтров навигации:

См. также комментарии в секции "Degraded Navigation".

2.3. Выходные навигационные фильтры

Результат решения по навигации изначально классифицируется по типу фиксации позиции (как описано полем fixType сообщения UBX-NAV-PVT). Это позволяет отличать отказы навигации ("No Fix", позиция не определена) и случаи, когда фиксация была достигнута, что имеет дальнейшее уточнение на определенные типы фиксации (например 2D, 3D, dead reckoning).

Когда фиксация была достигнута, делается проверка с целью определения, должна ли эта фиксация считаться правильной, или нет. Фиксация правильная только тогда, когда она подходит под выходные навигационные фильтры (Navigation Output Filters), как это определено в UBX-CFG-NAV5. В частности, оба параметра PDOP и точность должны быть меньше соответствующих пределов.

Правильные фиксации помечаются флагом valid в определенных сообщениях NMEA (см. "21. Флаги фиксации позиции в NMEA" [6]) и флагом gnssFixOK в сообщении UBX-NAV-PVT.

 Важное замечание: пользователям рекомендуется проверять флаг gnssFixOK в UBX-NAV-PVT, или флаг valid NMEA. Фиксации, не помеченные как valid, обычно не должны использоваться.

 Сообщения UBX-NAV-SOL и UBX-NAV-STATUS дают также информацию о правильности фиксации своими флагами gpsFixOK и GPSfixOk. Эти сообщения оставлены только для обратной совместимости, и рекомендуется предпочтительно использовать сообщение UBX-NAV-PVT.

Сообщение UBX-CFG-NAV5 также определяет значения TDOP и точности времени, которые используются, чтобы определить, относится ли фиксация к захваченной GNSS или нет, и вследствие этого узнать, может ли использоваться настройка импульса времени (time pulse). Фиксации, которые не удовлетворяют обоим критериям, считается не захваченной GNSS, и соответствующие настройки времени UBX-CFG-TP5 будут использоваться для генерации импульса времени.

2.4. Static Hold

Режим статического удержания (Static Hold Mode) позволяет алгоритмам навигации уменьшить шум в выводе позиции, когда скорость ниже предварительно определенного порога (Static Hold Threshold). Это уменьшает блуждание позиции, вызванное такими внешними факторами, как множественное распространение радиосигнала, в результате повышается точность для приложений, рассчитанных на статическое окружение (когда положение приемника в пространстве не меняется, или меняется медленно). По умолчанию режим статического удержания запрещен.

Если скорость падает ниже определенного Static Hold Threshold, то активируется Static Hold Mode. Как только был осуществлен вход в Static Hold Mode, вывод позиции удерживается статическим, и скорость устанавливается в 0, пока не появится доказательство нового движения. Таким доказательством может быть скорость, ускорение, изменение флага valid (например неточность позиции превысила Position Accuracy Mask, см. также секцию "Выходные навигационные фильтры"), смещение позиции и т. п.

2.5. Фиксация курса по земле

Приемник вычисляет курс по земле из информации о скорости (GNSS velocity). Если velocity не может быть вычислена с достаточной точностью (например из-за плохих сигналов от спутников) или если абсолютная скорость очень мала (в пределах 0.1 м/сек), то также становится неточным курс по земле. В этом случае курс по земле замораживается, т. е. сохраняется предыдущее значение, и на некоторое время его точность снижается. Эти замороженные значения не выводятся в NMEA-сообщениях NMEA-RMC и NMEA-VTG за исключением случаев, когда протокол NMEA специально сконфигурирован для подобного вывода (см. "NMEA Protocol Configuration").

2.6. Degraded Navigation

Degraded Navigation (ухудшенная навигация) описывает все режимы навигации, которые используют менее 4 спутников (Satellite Vehicle, SV).

2.6.1. 2D-навигация.

Если приемник для определения своей позиции имеет данные только от 3 спутников, то алгоритмы навигации используют постоянную высоту для компенсации отсутствующего четвертого спутника. Когда спутник потерян после успешной 3D fix (когда было доступно как минимум 4 спутника), вычисленная высота сохраняется постоянной, равной предыдущей высоте. Этот режим фиксации позиции называется 2D fix.

 Технология позиционирования u-blox не дает вычисления позиции, когда доступно меньше 3 спутников. Только timing-приемники u-blox, когда находятся в стационаре, вычисляют интервалы времени, даже когда доступен только 1 спутник.

[3. Конфигурация GNSS]

Последние изделия компании u-blox это поддерживающие множество стандартов (multi-GNSS) приемники, поддерживающие прием и обработки сигналов от спутниковых систем различных стандартов.

Приемники u-blox multi-GNSS могут захватывать и отслеживать спутники от нескольких систем GNSS, и применять их данные для вычисления позиции. Приемники u-blox multi-GNSS также могут быть сконфигурированы для обработки:

• Сигналов GPS, SBAS (например WAAS, EGNOS, MSAS) и QZSS L1, центрированных на частоте 1575.42 МГц L1.
• Сигналов GLONASS L1, центрированных на частоте 1602.00 МГц L1.

Используйте сообщение UBX-CFG-GNSS, чтобы сконфигурировать приемник u-blox в требуемый режим работы. Это сообщение дает возможность пользователю указать, какие сигналы GNSS должны быть обработаны вместе с ограничениями, сколько каналов трекинга должно быть выделено для каждой GNSS. Приемник будет отвечать на такие запросы сообщением UBX-ACK-ACK, если он может поддержать запрошенную конфигурацию, или будет отвечать сообщением UBX-ACK-NAK, если не поддерживает.

 Для максимальной чувствительности GPS при холодном старте убедитесь, что разрешена подсистема SBAS.

3.1. GLONASS

GLONASS это система GNSS, которая работает в России. У неё есть несколько значительных отличий от GPS. В большинстве случаев приемники u-blox работают очень похоже, когда они сконфигурированы для использования GLONASS вместо GPS. Однако вероятно будут затронуты некоторые аспекты вывода приемника:

• Сообщения NMEA поменяют идентификатор на GL (см. "NMEA Protocol Configuration").
• Сообщения UBX будут давать информацию с другими идентификационными номерами спутников (см. секцию "Нумерация спутников").
• Точность позиционирования, когда используются только спутники GLONASS, может быть хуже, чем когда используются только спутники GPS. Причина в сниженной доступности спутников; у системы GLONASS меньше спутников (на момент написания номинально 24 спутника GLONASS вместо 32 спутника GPS). Дополнительно сигналы GLONASS передаются реже, что снижает точность.
• Спутники GLONASS идентифицируются по декодированию определенной части их передаваемых данных. Таким образом, о только что полученных сигналах GLONASS может сообщаться, что они от неизвестного ("unknown") спутника, пока тип спутника не будет идентифицирован. С момента идентификации о спутниках GLONASS сообщают их корректными идентификационными данными.
• Поскольку пользователи GLONASS используют временную базу, выровненную непосредственно по UTC, на приемники GLONASS влияют скачки секунд, когда иногда база времени UTC перекалибровывается. Как следствие пользователи должны быть готовы к перезапуску приемника, если в момент отслеживания сигналов GLONASS произошел скачок секунд.

 На приемники GPS не влияют изменения скачков секунд, поскольку их временная база (время GPS) не зависит от скачков секунд. Спутники GPS периодически передают информацию, которая позволяет приемнику вычислить UTC.

3.2. QZSS

QZSS это система GNSS, работающая под управлением Japan Aerospace Exploration Agency (JAXA). Она была разработана как улучшение GPS, с повышенной доступностью спутников и повышенной точностью позиционирования. Это может быть достигнуто путем передачи системой QZSS сигналов, совместимых с GPS и в диапазонах GPS.

Сообщения NMEA покажут спутники QZSS только если они это сконфигурировано соответствующим образом (см. секцию "Нумерация спутников").

[4. Нумерация спутников]

4.1. NMEA

Протокол NMEA (V2.3) идентифицирует спутники с помощью числа из 2 цифр, резервируя числа 1 .. 32 для GPS, 33 .. 64 для SBAS и 65 .. 96 для GLONASS. Так например, GLONASS SV4 будет сообщаться с помощью числа 68. Приемники u-blox поддерживают этот метод в своем выводе NMEA, когда выбрана жесткая нумерация спутников ("strict" SV numbering). В большинстве случаев это установка по умолчанию, однако это можно установить или проверить с помощью UBX-CFG-NMEA.

К сожалению, с помощью протокола NMEA в настоящий момент нет способа идентифицировать спутники других систем GNSS. Чтобы поддерживать QZSS текущими приемниками и подготовиться к поддержке других систем (например Galileo) в будущих приемниках, с помощью UBX-CFG-NMEA может быть разрешена расширенная схема нумерации спутников ("extended" SV numbering). Она использует по возможности номера NMEA, но добавляет другие диапазоны номеров, чтобы поддерживать другие системы GNSS. Однако имейте в виду, что это нестандартное расширение требует чисел из 3 цифр, что может не поддерживаться некоторым программным обеспечением, предназначенным для обработки сообщений NMEA. Например, расширенная схема сообщает о спутниках QZSS с помощью чисел в диапазоне 193 .. 197.

 Спутники GLONASS могут использоваться до того, как они были идентифицированы. В выводе NMEA о таких "unknown"-спутниках сообщается с помощью null-поля (т. е. пустой строки).

4.2. UBX

Сообщения протокола UBX используют две разные схемы нумерации. Многие сообщения UBX (например UBX-NAV-SVINFO) используют 1 байт для идентификатора спутника (обычно именуемый "svId"). Эта система нумерации подобна "extended"-схеме NMEA, и это просто расширение схемы, использующейся предыдущим поколением приемников u-blox.

С постепенным увеличением количества спутников GNSS эта схема будет выходить из употребления в будущих приемниках u-blox (так как понадобятся числа больше 255). Следовательно более новые сообщения используют улучшенный и гибкий способ нумерации, подходящий для будущего развития. Для этого применяется отдельный идентификатор gnssId для указания типа спутника GNSS и простого svId, который показывает номер спутника в этой системе. Почти во всех случаях это означает, что "svId" это натуральное число, связанное со спутником. Например, спутник GLONASS SV4 идентифицируется как gnssId 6, svId 4, в то время как GPS SV4 идентифицируется gnssId 0, svId 4.

Идентификаторы GNSS:

В эту таблицу будут добавлены значения для поддержки других типов GNSS приемниками u-blox.

 Спутники GLONASS могут использоваться до того, как они были идентифицированы. В сообщениях UBX такие "unknown"-спутники всегда сообщаются номерами svId 255.

Следующей таблицей суммарно представлена нумерация спутников.

[5. Описание настроек конфигурации SBAS]

5.1. SBAS

SBAS (Satellite Based Augmentation System) это вспомогательная (улучшающая) технология для GPS, которая вычисляет целостность и корректность данных GPS с помощью наземных станций RIMS (Ranging and Integrity Monitoring Stations), и использует геостационарные спутники для широковещания GPS и коррекции данных для пользователей GPS. Корректирующие данные передаются на частоте GPS L1 (1575.42 МГц), поэтому требуется дополнительный приемник, чтобы использовались коррекция и проверка целостности данных.

 В настоящее время SBAS доступна только для GPS, следовательно информация в этой секции относится только к GPS.

Всего в мире имеется или разрабатывается несколько SBAS-совместимых систем:

• WAAS (Wide Area Augmentation System) для Северной Америки, которая в находится в работе с 2003 года.
• MSAS (Multi-Functional Satellite Augmentation System) для Азии, запущенная с 2007 года.
• EGNOS (European Geostationary Navigation Overlay Service), европейская система, работающая с 2009 года.
• GAGAN (GPS Aided Geo Augmented Navigation), разработанная правительством Индии, и на момент написания этого текста работающая в тестовом режиме.

Поддержка SBAS позволяет приемникам u-blox использовать все достоинства доступных вспомогательных систем (WAAS, EGNOS, MSAS), а также систем, которые тестируются и планируются к вводу в действие (такие как GAGAN).

Использование SBAS предоставляет информацию от дополнительных спутников, что используется для улучшения производительности определения позиции (навигации). Технология u-blox GPS использует все доступные спутники SBAS для навигации так же, как спутники GPS, если спутники SBAS предоставляют службу GPS.

Для улучшения точности позиционирования SBAS использует разные типы коррекции данных:

• Fast Corrections (быстрые коррекции) для коротких нарушений в сигналах GPS (из-за проблем с часами и т. п.).
• Long-term corrections (длинные коррекции) для коррекции часов GPS, ошибок орбиты широковещания и т. п.
• Ionosphere corrections для учета активности ионосферы.

Другое достоинство SBAS - использование информации целостности GPS. Станции управления SBAS (SBAS Control stations) могут запретить использование спутников GPS на 6 секунд (alarm time) в случае серьезных проблем со спутниками GPS. Если разрешен мониторинг целостности, технология u-blox GPS использует только те спутники, для которых есть информация о целостности.

Для дополнительной информации о SBAS и связанных с этим службах см. следующие источники:

• RTCA/DO-229D (MOPS) на сайте www.rtca.org.
• gps.faa.gov, информация для WAAS.
• www.esa.int, информация для EGNOS.
• www.essp-sas.eu, информация для European Satellite Services Provider (ESSP), менеджера EGNOS.
• www.isro.org, информация для GAGAN.

Спутники SBAS, отслеживаемые в марте 2012 года:

5.2. Функции SBAS

 Эта реализация u-blox SBAS разработана в соответствии со стандартом RTCA/DO-229D, оборудование класса Beta-1. Все таймауты и т. п. параметры выбраны для En Route Case. Не используйте это оборудование ни при каких обстоятельствах, когда приложения касаются безопасности жизни!

Приемники u-blox могут принимать несколько сигналов SBAS параллельно, даже от разных систем SBAS (WAAS, EGNOS, MSAS и т. п.). Они могут одновременно отслеживаться и использоваться для навигации. Каждый отслеживаемый спутник SBAS использует свободный канал трекинга приемника. Общее количество используемых спутников ограничивается только количеством каналов приемника. Каждый спутник SBAS, широковещательно передающий информацию эфемериды и альманаха, может использоваться для навигации так же, как обычный спутник GPS.

Для приема данных коррекции приемник u-blox GPS автоматически выбирает самый лучший спутник SBAS как источник первичной информации. Выбирается информация только от одного спутника SBAS, потому что информация от других спутников SBAS была бы избыточной и/или противоречивой. Стратегия выбора определяется близостью спутников, службами, которые предоставляет спутник, конфигурацией приемника (Testmode allowed/disallowed, Integrity enabled/disabled) и качеством канала связи со спутником.

В случае доступности коррекций от выбранного спутника SBAS и использовании их при вычислении навигационной информации, установится флаг DGPS в сообщениях выходного протокола (см. описание флагов фиксации позиции NMEA: NAV-PVT, NAV-SOL, NAV-STATUS, NAV-SVINFO). Сообщение NAV-SBAS предоставляет подробную информацию о том, какие коррекции доступны и были применены.

Наиболее важная функция SBAS для улучшения точности - Ionosphere correction. Измеренные станциями RIMS данные региона комбинируются с картой TEC (Total Electron Content). Эта карта передается в приемник через спутники, чтобы позволить применить коррекцию ионосферной ошибки на каждом принимаемом спутнике.

Поддерживаемые сообщения SBAS

Каждый спутник обслуживает определенный регион и его корректирующий сигнал полезен только в пределах этого региона. Крайне важно планирование выбора наилучшей возможной конфигурации, особенно в местах, где есть возможность приема сигналов от разных систем SBAS:

Пример 1, приемник SBAS в Северной Америке. В восточных частях Северной Америки следует быть осторожным, чтобы спутники EGNOS не получали преимущество перед спутниками WAAS. Спутники системы EGNOS должны быть запрещены с помощью PRN Mask.

Пример 2, приемник SBAS в Европе. Некоторые спутники WAAS могут приниматься в восточных частях Европы, поэтому рекомендуется запретить все спутники, кроме EGNOS, с помощью той же PRN Mask.

 Хотя приемники u-blox пытаются выбрать самые лучшие доступные данные коррекции SBAS, рекомендуется конфигурировать приемник для запрета использования нежелательных спутников SBAS. SBAS-система EGNOS не предоставляет функцию ранжирования спутников.

5.3. Конфигурация SBAS

Для конфигурирования функционала SBAS используйте проприетарное UBX-сообщение UBX-CFG-SBAS (SBAS Configuration).

Параметры конфигурации SBAS

По умолчанию SBAS разрешена с тремя приоритетными каналами SBAS, и будут использоваться любые принятые спутники SBAS (кроме тех, которые находятся в режиме тестирования) для коррекции навигации, получения параметров ионосферы.

[6. Тактирование и время]

6.1. Локальное время приемника

Приемник зависит от локального генератора (обычно это TCXO или кварцевый генератор), который используется как для работы радиотракта, так и генерации интервалов при обработке сигнала. Независимо от номинальной частоты локального генератора (например 26 МГц) приемники u-blox делят эту частоту генератора для предоставления опорной частоты 1 кГц, используемой для управления многими процессами приемника. В частности измерение сигналов спутников синхронизируется по "тикам" этого тактового сигнала 1 кГц.

Когда приемник запускается первый раз, у него пока нет информации о том, как эти такты тиков соотносятся с другими системами времени; он может только лишь отсчитывать время шагами в 1 миллисекунду. Однако поскольку приемник получает информацию от спутников, он корректирует время по их сообщениям, ориентируя свои тики 1 кГц по базе времени соответствующей системы GNSS. В предыдущих версиях firmware приемников u-blox это всегда была база времени GPS, но в последних версиях firmware это также могут быть базы GPS или GLONASS, и в будущем могут быть также базы времени и других систем GNSS (таких как Galileo, Compass, и т. д.). Это предварительное время на основе локального генератора 1 кГц называется локальным временем приемника.

Поскольку локальное время приемника отображает опорную локальную частоту 1 кГц на базу времени GNSS, могут быть случайные перерывы этого процесса, особенно когда приемник запускается первый раз, и когда меняется информация о базе времени. В действительности после холодного старта локальное время приемника показывает время, которое приемник работает. Однако когда приемник получит некую доверенную информацию о времени от спутника или из уточняющего сообщения, он перейдет к оценке времени GNSS.

6.2. Navigation Epoch

Каждое решение навигации срабатывает по тикам 1 кГц, самых близких к желаемому времени навигации. Этот тик называется навигационной эпохой (navigation epoch). Для успешной работы навигации требуется точное измерение времени по временной базе выбранной системы GNSS, что называется временем системы GNSS. Разница между вычисленным временем системы GNSS и локальным временем приемника называется смещением часов - clock bias (и clock drift, если скорость этого смещения меняется).

На практике локальный генератор приемника не настолько стабилен, как атомные часы систем GNSS, и следовательно clock bias имеет тенденцию накапливаться со временем. Однако когда выбирается следующая navigation epoch, приемник будет всегда пытаться использовать такой тик 1 кГц, который максимально близко соответствует желаемому фиксированному периоду, измеренному по времени системы GNSS. Соответственно количество тиков часов 1 кГц между фиксациями времени будет случайно меняться Так, если делается одна фиксация в секунду, то в нормальной ситуации должно быть 1000 тиков между фиксациями, но иногда из-за дрейфа относительно времени системы GNSS это количество тиков будет 999 или 1001.

Время системы GNSS, вычисленное в навигационном решении, всегда преобразуется во время GPS и для вывода во время UTC.

Очевидно, что когда приемник выбрал использовать базу времени GPS для своего времени системы GNSS, преобразование во время GPS не требует никаких действий, однако преобразование в UTC требует знания количества секунд с момента старта времени GPS (и других менее важных факторов коррекции). Соответствующие параметры конверсии GPS в UTC передаются периодически (каждые 12.5 минуты) спутниками GPS, но также эти параметры могут быть предоставлены приемнику через уточняющее сообщение UBX-AID-HUI. Если сравнить с ситуацией, когда приемник выбрал базу времени GLONASS в качестве своего времени системы GNSS, то преобразование ко времени GPS более сложное, так как требует знаний о разнице между этими двумя базами времени, но преобразование к UTC осуществляется проще (так как время GLONASS очень близко связано с UTC).

Когда для приемника недостаточно информации, чтобы точно выполнить преобразования базы времени, используются заранее определенные смещения по умолчанию. Следовательно вероятные близкие времена почти всегда генерируются, однако они могут быть ошибочными на несколько секунд (особенно близко к моменту старта приемника). В зависимости от конфигурации приемника такие "неправильные" времена могут выводиться, но вместе с флагом, показывающим их состояние (например флаги "valid" в UBX-NAV-PVT).

 Будущие приемники u-blox вероятно будут использовать несколько времен систем GNSS и/или локальное время приемника (чтобы параллельно поддерживать несколько систем GNSS), так что пользователи не должны полагаться на сообщения UBX, которые сообщают системное время GNSS или локальное время приемника, как это будет поддерживаться в будущем. Поэтому рекомендуется предпочтительно использовать сообщения, которые будут сообщать о времени UTC.

6.3. Метки времени iTOW

Все основные сообщения UBX-NAV (и некоторые другие сообщения) содержат поле iTOW, показывающее время GPS, на котором произошла navigation epoch. Сообщения с одинаковым значением iTOW могут считаться пришедшими от того же самого решения навигации.

Обратите внимание, что значения iTOW могут быть неправильными (т. е. они могут быть сгенерированы с недостаточными данными преобразования), поэтому не рекомендуется использовать поле iTOW для любых других целей. Если требуется надежная информация абсолютного времени, рекомендуется использовать сообщения UBX-NAV-TIMEUTC, UBX-NAV-TIMEGPS, UBX-NAV-PVT или UBX-NAV-SOL, которые содержат дополнительные поля, показывающие достоверность и точность вычисленных времен.

 Изначально разработчики GPS приняли решение выразить время/дату как целое число недель (начиная от первой полной недели января 1980 года) и время недели (time of week, сокращенно TOW) в секундах. Манипулирование временем/датой в такой форме намного проще для цифровых систем, чем более "удобное" выражение времени год/месяц/день, час/минута/секунда. Следовательно большинство приемников GPS/GNSS используют такое представление времени внутренне, преобразуя его в более "удобные формы" только на внешних интерфейсах. Поле iTOW самое очевидное видимое следствие такого представления времени.

6.4. Представление времени UTC

Время UTC используется во многих сообщениях NMEA и UBX. В сообщениях NMEA время всегда округляется до ближайших сотых долей секунды. Следовательно оно обычно сообщается двумя десятичными позициями после запятой (например 124923.52). Кроме того, хотя режим совместимости (выбранный с помощью UBX-CFG-NMEA) требует три десятичные позиции, округление к ближайшим сотым частям секунды остается, просто дополнительная цифра всегда равна 0.

Также время UTC сообщается в некоторых сообщениях UBX, таких как UBX-NAV-TIMEUTC и UBX-NAV-PVT. В этих сообщениях дата и время разделены на семь отдельных целочисленных полей. Шесть из них (год, месяц, день, час, минуты и секунды) имеют очевидный смысл. Гарантируется, что это значение времени соответствуют значениям в сообщениях NMEA генерируемым в той же navigation epoch. Это упрощает синхронизацию между связанными сообщениями UBX и NMEA.

Седьмое поле называется nano, и оно содержит количество наносекунд, на которое должна быть исправлена остальная часть времени и даты, чтобы получить точное время. Так, например, время UTC 12:49:23.521 будет сообщено так: hour: 12, min: 49, sec: 23, nano: 521000000.

Однако важно заметить, что первые шесть полей являются результатом округления до ближайших сотых частей секунды. Соответственно значение nano может меняться в диапазоне от -5000000 (т. е. -5 мс) до +994999999 (т. е. примерно 995 мс).

Когда поле nano отрицательное, количество секунд (и может быть минут, часов, дней, месяцев и даже лет) было округлено вверх. Таким образом, некоторые из этих полей и иногда все будут нуждаться в подстройке, чтобы получить корректное значение даты и времени. Как экстремальный пример, UTC-время 23:59:59.9993 на 31 декабря 2011 могло быть сообщено так: year: 2012, month: 1, day: 1, hour: 0, min: 0, sec: 0, nano: -700000.

Конечно, если точность одна сотая секунды достаточно, можно просто округлить значения nano до нуля (игнорировать).

6.5. Скачок секунд

Принято решение (одним из международных органов по хранению времени), что из-за немного неравномерной частоты вращения Земли, время UTC смещается достаточно значительно по сравнению с солнечным временем (т. е. Солнце не кажется непосредственно наверху на 0 долготе в полдень). Таким образом введен "скачок секунд" (leap second), чтобы привести время UTC обратно, близко к такому выравниванию. Это обычно приводит к добавлению дополнительной секунде к последней минуте года, но это может также произойти 30 июня. Когда это происходит, то ожидается переход часов UTC от 23:59:59 к 23:59:60, и только тогда к 00:00:00.

Теоретически есть возможность отрицательного скачка секунды, в этом случае получится в минуте только 59 секунд, и за временем 23:59:58 будет идти 00:00:00.

Приемники u-blox спроектированы так, что они обрабатывают скачки секунд в своем выводе UTC, и соответственно пользователи, обрабатывающие времена UTC, получаемые из сообщений NMEA и UBX, должны быть готовы обработать минуты так, что они могут быть длиной 59 или 61 секунд.

 Имейте в виду, что поведение сигналов GLONASS во время скачка секунд не определено достаточно хорошо. Как следствие пользователи должны быть готовы к тому, что приемник перезапустит сам себя, если отслеживаются сигналы GLONASS, когда произошел скачек секунды.

6.6. Real Time Clock

Приемники u-blox содержат схему для поддержки часов реального времени (real time clock, RTC, если аппаратура правильно адаптирована и запитана), сохраняя отсчет времени, когда приемник выключен. Когда приемник включается, то он пытается использовать RTC для инициализации локального времени приемника, и в большинстве случаев это дает возможность заметно быстрее получить первые фиксации позиции.

[7. Последовательные коммуникационные порты]

Технология позиционирования u-blox поставляется с очень гибким коммуникационным интерфейсом. Поддерживаются протокол NMEA и проприетарный протокол UBX, и есть реальная возможность работать через несколько портов и по нескольким протоколам. Каждый протокол (UBX, NMEA) может быть назначен на несколько портов одновременно (функция multi-port) с индивидуальными настройками (т. е. baud rate, частота появления сообщений и т. д.) для каждого порта. Есть даже возможность назначить больше одного протокола (т. е. протоколы UBX и NMEA одновременно) на один порт (функция multi-protocol), что в частности полезно для отладки.

Чтобы разрешить сообщение на порте, протокол UBX и/или NMEA должен быть разрешен на этом порте, что делается с помощью проприетарного UBX-сообщения CFG-PRT. Это сообщение также позволяет менять настройки, специфические для порта (baud rate, адрес и т. д.). См. CFG-MSG для описания механизма разрешения и запрета сообщений.

Следующая таблица показывает используемые номера для портов. Обратите внимание, что любые не перечисленные здесь номера зарезервированы для использования в будущем.

Назначение номеров коммуникационным портам

7.1. Индикация готовности к передаче (TX-ready)

Эта функция позволяет каждому порту определить соответствующую ножку чипа, которая будет показывать готовность байт к передаче. По умолчанию эта функция запрещена. Для USB эта функция конфигурируется, но может работать не так, как описано ниже, потому что используется другой внутренний механизм передачи. Если количество ожидающих передачи байт достигло порога, сконфигурированного для этого порта, то соответствующая ножка типа станет активной (конфигурируется лог. 0 или лог. 1 для уровня активности), и остается активной, пока последний байт не будет передан из программы в аппаратуру (обратите внимание, что это не всегда равно количество переданных байт, например после того как ножка стала не активной, до 16 байт все еще могут нуждаться в передаче хосту).

Ножка TX-ready может быть выбрана из всех выводов PIO, которые не используются (см. MON-HW для получения списка PIO и их привязки). Каждая ножка TX-ready используется исключительно для одного порта, и не может использоваться совместно с другими портами. Если выбранный вывод PIO недопустим или уже используется, игнорируется конфигурация только для ножки TX-ready, применяется остальная действующая конфигурация портов, если она правильная. Сообщение подтверждения не показывает, что конфигурация TX-ready успешно установлена, оно только показывает успешную конфигурацию порта. Чтобы определить успешность конфигурации ножки TX-ready, конфигурация порта должна быть опрошена, и проверена установка функции TX-ready (она будет запрещена/обнулена, если установка неправильная).

Порог по размеру данных не должен превышать 2 килобайта, поскольку внутренний буфер сообщений может в противном случае переполниться, в результате ножка TX-ready никогда не будет активирована, так как сообщения будут отбрасываться до достижения порога передачи.

7.2. Расширенный таймаут передачи (Extended TX timeout)

Если хост не обменивается с приемником через SPI или DDC дольше, чем примерно 2 секунды, то приемник предполагает, что хост больше не использует этот интерфейс, и на этот порт больше не планируется передача пакетов. Этот механизм можно поменять, разрешив "extended TX timeouts", в этом случае задержка ожидания приемника увеличивается для этого бездействующего порта, пока количество не доставленных байт для этого порта не достигнет 4 килобайт. Эта функция особенно полезна, когда используется TX-ready со скоростью выдачи сообщений меньше одного раза в секунду, и данные опрашиваются только когда они доступны, что определяется по активности ножки TX-ready.

7.3. Порты UART

Имеются один или два универсальных асинхронных последовательных порта UART (Universal Asynchronous Receiver/Transmitter), что можно использовать для передачи измерений GNSS, мониторинга информации о состоянии и конфигурирования приемника.

Последовательные порты используют сигналы RX и TX (сигналы приема и передачи данных). Нет никакой информации квитирования, ни через сигналы данных (handshaking), ни через дополнительные аппаратные сигналы управления потоком (hardware flow control). Эти последовательные порты работают в асинхронном режиме. Скорость (baud rate) может быть сконфигурирована индивидуально для каждого последовательного порта. Однако на одном порте нет поддержки для установки разных скоростей приема и передачи, или разных скоростей для разных протоколов.

Возможные конфигурации UART

Обратите внимание, что для таких протоколов, как NMEA или UBX, не имеет смысла менять длину слова по умолчанию (количество бит данных), поскольку их свойства определены в протоколе и не относятся к электрическому интерфейсу.

Если количество сконфигурированных данных слишком большое для определенной полосы пропускания порта (например все сообщения UBX выводятся через UART на скорости 9600), то буфер переполнится. Как только пространство буфера исчерпается, новые сообщения для отправки будут отбрасываться. Чтобы предотвратить потерю сообщений, скорость и частота обмена, или количество разрешенных сообщений должно быть выбрано так, чтобы ожидаемое количество байт передавалось меньше чем за секунду.

См. CFG-PRT для UART, чтобы получить описание конфигурационного сообщения порта UART.

7.4. Порт USB

Имеется порт Universal Serial Bus (USB). Его доступность см. в даташите на соответствующий продукт. Этот порт может использоваться для целей коммуникации и для питания чипа позиционирования или модуля приемника.

Интерфейс USB поддерживает 2 разных режима питания (power modes):

• Self Powered Mode, когда приемник питается от своего собственного источника питания. Ножка VDDUSB используется для определения доступности порта USB, например когда приемник подключен к хосту USB.
• Bus Powered Mode, устройство получает питание от шины USB, дополнительный источник питания не нужен. Устройства поколения u-blox 7 потребляют ток не более 50 мА. См. CFG-USB для получения описания, как может поменяться этот максимум. Конфигурирование Bus Powered Mode показывает, что устройство войдет в состояние низкого энергопотребления с запретом функциональности GNSS, когда хост приостановит (suspend) устройство USB, например когда хост переведен в состояние приостановки (stand-by mode).

Максимальный ток в Bus Powered Mode

 Диапазон напряжений для VDDUSB указан от 3.0V до 3.6V, что незначительно отличается от спецификации для VCC.

7.5. Порт DDC

Реализована шина Display Data Channel (DDC), у которой 2-проводный коммуникационный интерфейс, совместимый со стандартом I2C.

В отличие от всех других интерфейсов, DDC не может работать в режиме полного дуплекса (full-duplex; на самом деле USB физически тоже не полнодуплексный, однако на высоком уровне обмена он работает как full-duplex), т. е. передача и прием I2C исключают друг друга (не могут происходить одновременно). Приемники u-blox в режиме настройки соединения работают по шине I2C как подчиненное устройство (slave), поэтому они не могут сами инициировать передачи данных. Хост, который всегда является мастером, предоставляет сигнал тактов данных (SCL), и частота тактов на подчиненном устройстве не конфигурируется.

 Частота тактов SCL, генерируемая мастером, не должна превышать 400 кГц (fast-mode I2C).

DDC-адрес приемника по умолчанию установлен 0x42. Этот адрес может быть изменен установкой поля mode в CFG-PRT.

Поскольку приемник будет работать в режиме подчиненного устройства, и физический слой интерфейса испытывает недостаток в handshake-механизме для оповещения хоста о доступности данных, между физическим слоем и слоем UBX и NMEA. DDC реализует простой потоковый интерфейс, который позволяет постоянно опрашивать данные, отбрасывая все, что не может быть обработано. Это означает, что приемник вернет 0xFF, если данные недоступны. Может использоваться функция TX-ready, чтобы оповещать мастер о наличии данных, и по этому сигналу можно запускать передачу данных.

7.5.1. Доступ на чтение

Чтобы позволить осуществить как доступ для опроса, так и передачу полного потока сообщения и быстрый доступ к ключевым данным, на рисунке ниже показано расположение регистров DDC.

Регистры данных 0 .. 252 с адресами 0x00 .. 0xFC, каждый размером в 1 байт, содержат информацию, которая будет определена позже. По адресам 0xFD и 0xFE находится текущее количество байт, которые можно прочитать в виде потока сообщений. По адресу 0xFF находится поток сообщений. Последовательные чтения из регистра 0xFF вернет байт за байтом сообщения в буфере передачи. Если количество прочитанных байт превышает показанное количество, то полезная нагрузка будет дополнена значением 0xFF.

 Регистры 0x00 .. 0xFC будут определены в будущих релизах firmware. Не используйте их, так как они не предоставляют каких-либо полезных данных!

7.5.1.1. Доступ на чтение по произвольному адресу

Операции произвольного чтения позволяют мастеру получить доступ к любому регистру в произвольном порядке. Чтобы выполнить этот тип операции чтения, в приемник сначала должен быть записан адрес регистра для чтения (см. рисунок ниже).

За сигналом START (START condition, на рисунке показан буквой S), выданным мастером, идет 7-битный адрес устройства (который по умолчанию 0x42) и бит RW (где лог. 0 показывает доступ на запись, что на рисунке показано буквой W), все эти биты передаются мастером через сигнал SDA с каждым тактом SCL. Приемник подтверждает это сигналом ACK (лог. 0), чтобы показать, что он может ответить по указанному адресу (0x42). Далее на шину выдается 8-битный адрес регистра, который должен быть прочитан. За подтверждением ACK приемником этого адреса мастер снова выдает сигнал START, и записывает адрес устройства, но в этот раз бит RW в лог. 1 (на рисунке показано буквой r), что показывает доступ на чтение. Теперь мастер может прочитать от 1 до N байт из приемника, генерируя not-acknowledge (отсутствие подтверждения, NAK) и сигнал STOP (STOP condition, на рисунке показано буквой P) после последнего прочитанного байта. После каждого прочитанного байта внутренний счетчик адреса инкрементируется на 1, с переполнением на значении адреса 0xFF. Это переполнение означает, что после прочтения всех регистров после изначальной установки адреса регистра, может быть прочитан поток сообщения (который, как известно, находится по адресу 0xFF).

7.5.1.2. Чтение по текущему адресу

Приемник содержит счетчик адреса, который хранит адрес последнего регистра, к которому осуществлялся доступ, внутренне увеличенный на 1. Таким образом, если предыдущий доступ на запись был по адресу n (где n любой допустимый адрес), то следующая операция чтения будет осуществлять доступ по адресу n+1 (см. рисунок ниже).

При получении адреса устройства, где бит RW установлен в лог. 1 (на рисунке показано буквой r), приемник ответит подтверждением (ACK) и мастер может прочитать от 1 до N байт из приемника, генерируя not-acknowledge (отсутствие подтверждения, NAK) и сигнал STOP (P) после последнего прочитанного байта.

Чтобы получить прямой доступ к потоковым данным, внутренний счетчик адреса инициализируется в значение 0xFF, что означает, что чтения текущего адреса без предварительного доступа на чтение по произвольному адресу будет возвращать поток сообщения. Счетчик адреса может быть установлен на другой адрес в любой момент, с помощью доступа на чтение по произвольному адресу.

7.5.2. Доступ на запись

Приемник не предоставляет любой доступ на запись, кроме записи сообщений UBX и NMEA, таких как конфигурация или уточняющие данные. Таким образом набор регистров, упомянутый в предыдущих секциях с описанием операций чтения, недоступен на запись. За сигналом START от мастер идет 7-битный адрес устройства и бит RW (равный лог. 0 для операции записи, на рисунке ниже это показано буквой W).

Приемник отвечает подтверждением (ACK, лог. 0), чтобы показать, что он ответит на указанный адрес. Теперь мастер может записать от 2 до N байт в приемник, генерируя сигнал STOP после завершающего байта. Количество записанных байт должно быть как минимум 2, чтобы правильно выделить доступ на запись в целью установки адреса, применяемый для доступа на чтение по произвольному адресу.

7.6. Порт SPI

Имеется шина Serial Peripheral Interface (SPI) для выбранных приемников (см. доступность интерфейса в даташите).

SPI это 4-проводный синхронный коммуникационный интерфейс [3]. В отличие от UART, здесь мастер предоставляет сигнал тактов, поэтому параметры соединения для починенного устройства (скорость) не требуется определять заранее (установка скорости не предусмотрена в принципе). Реализованы режимы 0-3 интерфейса SPI, что можно конфигурировать для SPI с помощью поля mode.spiMode в CFG-PRT (по умолчанию для SPI установлен режим 0).

 Скорость SPI ограничена в зависимости от версий hardware и firmware!

7.6.1. Максимальная скорость тактов SPI

u-blox 7

7.6.2. Доступ на чтение

Так как режим регистров не реализован для порта SPI, имеется только поток сообщений UBX/NMEA. К этому потоку доступ осуществляется путем двунаправленного (Back-To-Back) доступа на чтение и запись (см. секцию "Чтение Back-To-Back и доступ на запись"). Когда нет данных для записи в приемник, сигнал MOSI должен удерживаться в лог. 1, т. е. все записываемые байты в приемник устанавливаются в 0xFF.

Чтобы не допустить, чтобы приемник был занят парсингом приходящих данных, процесс парсинга останавливается после 50 следующих друг за другом байт, содержащих 0xFF. Процесс парсинга в приемнике возобновляется с первым пришедшим байтом, который не равен 0xFF. Количество байт для ожидания деактивации (50 по умолчанию) может быть настроено для SPI с помощью поля mode.ffCnt в CFG-PRT, что необходимо только тогда, когда должны быть отправлены сообщения с большим количеством байт 0xFF.

Если у приемника больше нет данных для отправки, то он удерживает сигнал MISO в лог. 1, т. е. все передаваемые байты декодируются как 0xFF. Эффективный парсер хоста будет игнорировать все байты, которые не являются частью сообщения, и возобновит обработку данных, как только будет принят первый байт, который не равен 0xFF.

7.6.3. Чтение Back-To-Back и доступ на запись

Приемник не предоставляет никакой доступ на запись, кроме как запись в приемник сообщений UBX и NMEA, таких как данные конфигурации или уточняющие данные. Для каждого байта, записанного в приемник, этот байт будет немедленно прочитан приемником. Во время, когда мастер пишет данные в сигнал MOSI, одновременно он должен читать данные из MISO, поскольку во время этого доступа будут выведены любые оставшиеся в приемнике данные. Данные на MISO представляют результаты чтения текущего адреса, возвращая 0xFF, когда нет больше доступных данных. На рисунке ниже показан этот двунаправленный доступ по обмену данными (SPI Back-To-Back Read/Write Access).

7.7. Как переключаться между протоколами

Переконфигурирование порта с одного протокола на другой выполняется за 2 шага:

• Шаг 1: выбранный протокол (протоколы) должны быть разрешены для порта с помощью CFG-PRT. Как уже упоминалось, один порт может обслуживать несколько протоколов одновременно (т. е. протоколы NMEA и UBX). По умолчанию все порты сконфигурированы для протоколов UBX и NMEA, так что для большинства случаев не требуется менять никакие настройки порта. Настройки порта можно посмотреть с помощью сообщений CFG-PRT.

• Шаг 2: активация определенных сообщений на каждом порту с помощью CFG-MSG.

[8. Конфигурация приемника]

8.1. Концепция конфигурации

Концепция позиционирования u-blox полностью конфигурируется с помощью конфигурационных сообщений протокола UBX (класс сообщений UBX-CFG). Та конфигурация, которая используется приемником GNSS при нормальном функционировании, называется текущей (Current Configuration). Текущая конфигурация может быть изменена во время нормального функционирования путем отправки в приемник любого сообщения UBX-CFG-XXX через любой порт ввода/вывода. Приемник поменяет свою Current Configuration немедленно после приема конфигурационного сообщения. Приемник GNSS всегда использует только текущую конфигурацию.

Кроме случаев, когда Current Configuration сделана постоянной (с помощью сообщения UBX-CFG-CFG, как описано ниже), Current Configuration будет потеряна:

• При выключении и включении (пропадании) питания (power cycle).
• При аппаратном сбросе (hardware reset).
• При (полном) управляемом программном сбросе (software reset).

См. секцию "9. Принудительный сброс приемника" для получения подробностей.

Current Configuration может быть сделана постоянной (хранимой в энергонезависимой памяти) путем сохранения её в постоянную конфигурацию (Permanent Configuration). Это делается отправкой сообщения UBX-CFG-CFG с соответствующей saveMask (UBX-CFG-CFG/save).

Permanent Configuration копируется в Current Configuration после запуска (включение питания, сброс), или когда в приемник отправлено сообщение UBX-CFG-CFG с соответствующей loadMask (UBX-CFG-CFG/load).

Примечание: u-blox концепция конфигураций Permanent Configuration и Current Configuration подобна концепции startup-config и running-config на активном сетевом оборудовании Cisco.

Permanent Configuration может быть восстановлена значениями конфигурации по умолчанию (Default Configuration) путем отправки в приемник сообщения UBX-CFG-CFG с соответствующей clearMask (UBX-CFG-CFG/clear). Это только заменит Permanent Configuration, но не Current Configuration. Чтобы приемник заработал с параметрами Default Configuration, когда она была восстановлена (скопирована) в Permanent Configuration, приемнику должна быть отправлена команда UBX-CFG-CFG/load, или должен быть выполнен сброс приемника.

Эти вышеупомянутые маски (saveMask, loadMask, clearMask) представляют собой 4-байтные битовые поля. Каждый бит здесь представляет одну из подсекций конфигурации. Эти подсекции определены в разделе "8.2. Организация секций конфигурации". Все три маски являются частью каждого сообщения UBX-CFG-CFG. Команды сохранения (save), загрузки (load) и очистки (clear) могут комбинироваться в одном сообщении. Порядок выполнения следующий: clear, save, load. Этот процесс иллюстрируется диаграммой:

8.2. Организация секций конфигурации

Конфигурация делится на несколько подсекций. Каждая подсекция соответствует одному или нескольким сообщениям UBX-CFG-XXX. Номера подсекций в следующих таблицах соответствуют позиции бита в масках, упомянутых выше. Все значения, которые не перечислены этих таблицах, являются зарезервированными.

Подсекции конфигурации:

8.3. Носитель данных для Permanent Configuration

Current Configuration сохраняется в обычном ОЗУ приемника (volatile RAM), значения которого теряются при выключении питания). Таким образом, любые изменения в Current Configuration без их сохранения будут потеряны, если произойдет любое из событий сброса, перечисленных в предыдущей секции "8.1. Концепция конфигурации". С помощью UBX-CFG-CFG/save, выбранные подсекции конфигурации сохраняются во все доступные энергонезависимые (non-volatile) области памяти:

• On-chip BBR (battery backed RAM), встроенная в чип память RAM, данные которой поддерживаются напряжением дополнительной батарейки. Чтобы технология BBR работала, в приемнике должна быть правильно подключенная батарейка резервного питания памяти.
• External flash memory (внешняя память FLASH), где она имеется.

8.4. Default Configuration приемника

Permanent Configuration может быть сброшена в параметры Default Configuration с помощью сообщения UBX-CFG-CFG/clear. Default Configuration приемника обычно определяется в момент производства приемника. Для подробностей обратитесь к соответствующей документации на изделие (product data sheet).

[9. Принудительный сброс приемника]

Обычно в приемниках GNSS разделяют события холодного, теплого и горячего старта (Cold, Warm и Hot start), в зависимости от допустимости информации, которую приемник имеет в момент своего рестарта.

• Cold start (холодный старт). В этом режиме в момент запуска у приемника нет никакой информации о последней позиции (т. е. времени, скорости, частоте). Таким образом, приемник должен найти полное время и опросить область частот и все возможные номера спутников. Если найдены сигналы спутников, то они отслеживаются и декодируется их информация эфемерид (на что уходит 18..36 секунд в условиях хорошего приема сигнала), в то же самое время каналы продолжают искать спутники. Как только принято достаточное количество спутников с достоверными эфемеридами, приемник может вычислить данные своего положения и скорости (position, velocity). Пожалуйста имейте в виду, что некоторые конкуренты называют этот режим запуска Factory Startup.

• Warm start (теплый старт). В этом режиме приемник может аппроксимировать информацию о времени, позиции и курсе на основе данных позиций спутников (Almanac, альманах). В этом режиме после включения питания приемник обычно нуждается в загрузке эфемерид перед тем, как сможет вычислить данные позиции и скорости. Поскольку данные эфемерид обычно устаревают после 4 часов, приемник будет скорее всего запускаться в режиме теплого старта, если он был выключен на время больше 4 часов. В этом сценарии существует несколько уточнений, см. раздел "15. Aiding, Acquisition".

• Hot start (горячий старт). В этом режиме запуска приемник был выключен только на короткое время (меньше 4 часов), поэтому эфемериды все еще достоверны. Поскольку приемнику не нужно снова загружать эфемериды, то это самый быстрый метод запуска.

В сообщении UBX-CFG-RST можно принудить приемник сбросить и очистить данные, чтобы немедленно увидеть эффекты от сохранения / потери таких данных между перезагрузками. Для этого сообщение CFG-RST предоставляет поле navBbrMask, где могут быть инициированы запуски Hot, Warm и Cold, и также другие их комбинации.

 Данные, сохраненные в памяти flash, не очищаются ни одной из опций, предоставленных UBX-CFG-RST. Так, например, если допустимые данные AlmanacPlus сохранены в flash, то это вероятно окажет влияние на Cold start.

Может быть также задан тип сброса (Reset Type). Это не связано с GNSS, но задает способ, каким программное обеспечение перезапускает систему.

• Hardware Reset (аппаратный сброс). Этот сброс использует встроенный сторожевой таймер (on-chip Watchdog), чтобы электрически сбросить чип приемника. Это немедленный, асинхронный сброс. Не генерируются события остановки (Stop events). Это эквивалент подачи аппаратного сигнала Reset приемнику.

• Controlled Software Reset (управляемый программный сброс) организованным способом завершает все работающие процессы и, как только система перейдет в состояние ожидания (idle), перезапускает функционирование, перезагружает свою конфигурацию и запускает захват и отслеживание информации со спутников GNSS.

• Controlled Software Reset (GNSS only) перезагружает только задачи GNSS, без повторной инициализации всей системы или повторной загрузки любой сохраненной конфигурации.

• Controlled GNSS Stop останавливает все задачи GNSS. Приемник не перезапускается, но останавливает все процессы, связанные с любой обработкой GNSS.

• Controlled GNSS Start запускает все задачи GNSS.

[10. Remote Inventory]

10.1. Описание термина

Remote Inventory позволяет сохранять определяемые пользователем данные в энергонезависимой памяти приемника (довольно странное название для термина). Эти данные могут быть либо двоичные, либо это может быть строка символов ASCII. Во втором случае можно при старте вывести эти данные.

10.2. Использование

• Содержимое Remote Inventory может быть установлено и опрошено сообщением UBX-CFG-RINV (подробную информацию см. в описании этого сообщения).
• Если содержимое Remote Inventory было опрошено перед тем, как что-либо было там установлено, то будет выведена конфигурация по умолчанию (см. таблицу ниже).

Конфигурация по умолчанию Remote Inventory

 Когда поменялась конфигурация, она должна быть сохранена, чтобы стать постоянной (permanent). Убедитесь, что сохраняете секцию RINV перед сбросом или выключением приемника. Больше информации по сохранению секции конфигурации можно найти в главе "8.1. Концепция конфигурации".

[11. Управление питанием (Power Management)]

Приемники u-blox поддерживают разные режимы питания. Эти режимы представляют стратегии, как управлять системами захвата и трекинга (спутников), чтобы достичь либо самой лучшей производительности, либо хорошей производительности со сниженным потреблением энергии.

Режимы питания (power modes) выбираются с помощью сообщения CFG-RXM и конфигурируются сообщением UBX-CFG-PM2.

11.1. Continuous Mode

Во время холодного старта (Cold start), приемник постоянно находится в Continuous Mode, задействуя систему захвата (acquisition engine) для поиска всех доступных спутников. Как только может быть вычислена позиция, и достаточное количество спутников отслеживается, acquisition engine выключается, чем достигается значительное снижение потребляемой мощности. Система отслеживания (tracking engine) постоянно отслеживает захваченные спутники и захватывает другие доступные или появляющиеся спутники. Всякий раз, когда приемник не может больше вычислить свою позицию, или количество отслеживаемых спутников становится недостаточным, acquisition engine снова включается, чтобы гарантировать быстрое восстановление обнаружения спутников.

Обратите внимание, что даже если acquisition engine выключена, спутники продолжают обнаруживаться.

11.2. Power Save Mode

Power Save Mode (PSM, режим пониженного энергопотребления) позволяет снизить потребление мощности за счет выборочного включения и выключения частей приемника.

 Замечание: Power Save Mode не может быть выбрано, когда приемник сконфигурирован для обработки сигналов GLONASS.

11.2.1. Работа PSM

Power Save Mode имеет 2 режима работы: циклический трекинг (cyclic tracking operation) и включение/выключение (ON/OFF operation). Циклический трекинг используется, когда позиция зафиксирована, и требуется в коротких периодах 1 .. 10 сек. С другой стороны, ON/OFF operation используется для периодов, которые дольше 10 сек. Периоды в ON/OFF operation могут задаваться в минутах, часах или днях. Режим работы можно конфигурировать, и в зависимости от установки приемник демонстрирует разное поведение: при ON/OFF operation приемник переключается между фазами старта/навигации (startup/navigation) и фазами с низкой системной активностью или почти никакой системной активностью. При циклическом трекинге приемник не выключается полностью между фиксациями, но использует вместо этого трекинг с низким энергопотреблением.

PSM основывается на машине состояний с пятью разными состояниями: Inactive for update и Inactive for search, Acquisition, Tracking и Power Optimized Tracking (POT).

• Inactive-состояния: большинство узлов приемника выключено.
• Acquisition: приемник активно ищет и захватывает сигналы спутников. Это состояние максимального потребления энергии.
• Tracking: приемник непрерывно отслеживает спутники и загружает данные. В этом состоянии потребление меньше, чем в состоянии Acquisition.
• POT: приемник с повторами проходит через последовательность состояния трекинга (TRK), вычисления позиции фиксации (Calc) и входа в период ожидания (Idle). Новые сигналы не захватываются, и данные не загружаются. Потребление намного меньше, чем в состоянии Tracking.

На следующем рисунке показаны переходы машины состояний:

11.2.1.1. ON/OFF operation - период долгого обновления

Когда приемник включается, он сначала входит в состояние Acquisition. Если приемник в состоянии получить достоверную позицию фиксации за время, отведенное таймаутом acquisition, то он переключится в состояние Tracking. Иначе он войдет в состояние Inactive for search и перезапустится после сконфигурированного периода поиска (минус поле запуска). Как только приемник получит достоверную позицию фиксации (такую, которая прошла через выходные фильтры навигации), он войдет в состояние Tracking. После входа в состояние Tracking запускается время включения (on time). Как только время включения закончится, приемник переходит в состояние Inactive for update, и приемник перезапускается в соответствии со сконфигурированной сеткой обновления update grid (см. "11.2.2.8. Grid offset"). Если в состоянии Tracking сигнал был потерян, то происходит переход в состояние Acquisition. Если сигнал не найден в течение таймаута acquisition, то приемник входит в состояние Inactive for search. Иначе приемник снова входит в состояние Tracking и остается в нем, пока опять не истечет время on time.

Диаграмма ниже показывает, как функционирует режим ON/OFF:

11.2.1.2. Циклический трекинг - короткий период обновления

Когда приемник включается, он сначала входит в состояние Acquisition. Если он может получить фиксацию позиции в течение таймаута acquisition, то переключается в состояние Tracking. Иначе приемник переходит в состояние Inactive for search и перезапускается в соответствии сконфигурированной сеткой поиска (search grid). После получения достоверной позиции фиксации происходит вход в состояние Tracking, и запускается отсчет времени on time. Другими словами on time отсчитывается от первой достоверной фиксации позиции. Как только on time истекло, происходит вход в состояние POT. В состоянии POT приемник продолжает выводит фиксацию позиции в соответствии с периодом обновления. Чтобы получить максимальную экономию энергии, установите on time в 0. Это заставит приемник войти в состояние POT при первой возможности. Если в состоянии POT сигнал становится слабым или потерян, происходит вход в состояние Tracking. Как только сигнал снова становится сильным, и истечет заново запущенное время on time, приемник снова войдет в состояние POT. Если приемник не может получить фиксацию позиции в состоянии Tracking, то он переходит в состояние Acquisition. Если захват также потерпит неудачу, то произойдет переход в состояние Inactive for search.

 На диаграмме ниже показано, как работает циклический трекинг:

11.2.1.3. Функционирование под управлением пользователя - нулевой период обновления и поиска

Установка периода обновления в 0 заставит приемник ждать в состоянии Inactive for update, пока не будет разбужен пользователем. Установка периода поиска в 0 заставит приемник бесконечно ждать в состоянии Inactive for search при неудачном запуске. Любое событие пробуждения (wake-up event) перезапустит приемник. См. "11.2.3.2. Wake-up" для дополнительной информации по событиям пробуждения.

 Требуются внешние wake-up события, когда установлены в 0 периоды обновления или поиска!

11.2.1.4. Загрузка данных спутника

Приемник не может загрузить данные спутника (т. е. эфемериды) когда он работает в режиме ON/OFF или в режиме циклического трекинга. Поэтому приемник должен временно переключиться в Continuous operation на время передачи необходимых данных со спутника. Чтобы сохранить энергию, приемник планирует загрузки в соответствии с внутренней таблицей времени, и переключается в Continuous operation только когда интересующие данные передаются спутниками.

Каждый спутник (SV) передает свои данные эфемерид. Эфемеридная загрузка данных выполнима, когда соответствующий SV был прослежен с минимальным C/No за определенный период времени. Загрузка планируется в сетке 30 минут или немедленно, когда меньше чем определенное количество видимых имеют достоверные данные эфемерид. Данные альманаха, ионосферы, коррекции UTC и работоспособности спутника (SV health) передаются всеми SV одновременно. Таким образом, эти параметры могут быть загружены, когда один SV отслеживается с достаточно высоким коэффициентом C/No.

11.2.2. Конфигурация

Power Save Mode (PSM) разрешается и запрещается сообщением UBX-CFG-RXM, и конфигурируется сообщением UBX-CFG-PM2.

 Когда разрешается Power Save Mode, поддержка SBAS может быть запрещена (UBX-CFG-SBAS) поскольку приемник в этом режиме не может загружать любые данные SBAS.

При настройке PSM, чтобы удовлетворить Вашим специфическим требованиям, может использоваться некоторое количество параметров. Эти параметры перечислены в следующей таблице:

Опции конфигурации Power Save Mode

11.2.2.1. Режим работы

Режим работы для использования зависит главным образом от периода обновления: для коротких периодов обновления (в диапазоне нескольких секунд) должен быть сконфигурирован циклический трекинг. С другой стороны, для длинных периодов обновления (в диапазоне от минуты или дольше) работает только режим ON/OFF.

См. "11.2.1.1. ON/OFF operation - период долгого обновления" и "11.2.1.2. Циклический трекинг - короткий период обновления" для дополнительной информации о том, как работают эти два режима.

11.2.2.2. Период обновления и поиска

Период обновления (update period) задает время между успешными фиксациями позиции. Если за таймаут acquisition не была получена фиксация позиции, приемник попробует возобновить попытку после времени, которое задано периодом поиска (search period). Периоды обновления и поиска фиксированы по отношению к абсолютной сетке времени, основанной на времени GPS. Они не относятся ко времени последней достоверной фиксации позиции или последней попытки фиксации позиции.

 Новые настройки игнорируются, если период обновления или период поиска превышают максимальное количество миллисекунд в неделе. В этом случае останутся в действии последние, сохраненные ранее значения.

11.2.2.3. Acquisition timeout

Приемник пытается получить фиксацию позиции в течение таймаута acquisition. Эта настройка обрабатывается как минимальное значение. Если приемник определяет, что нужно больше времени в текущих начальных условиях, то он автоматически продлит это время. Если это время установлено в 0, то таймаут acquisition определяется исключительно самим приемником. В случае очень слабого приема сигнала GPS или при его отсутствии таймаут, определяемый приемником, может быть сокращен, чтобы снизить потребление энергии. Однако таймаут acquisition не будет короче, чем сконфигурированное значение.

11.2.2.4. On time и wait for timefix

Параметр on time задает, как долго приемник остается в состоянии Tracking перед переключением в состояние POT и Inactive for update соответственно. Качество фиксации позиции может быть сконфигурировано установкой масок в сообщении UBX-CFG-NAV5. Если разрешена опция wait for timefix, то переход от состояния Acquisition к состоянию Tracking происходит только если известно время GPS и в сконфигурированных пределах, и приемник постоянно выдает фиксации позиции в течение больше 2 секунд. Таким образом, разрешение опции timefix обычно задерживает переход из Acquisition в Tracking на несколько секунд. Имейте в виду, что установка более жестких пределов в UBX-CFG-NAVX5 увеличит время запуска, так что Вы можете захотеть увеличить таймаут acquisition.

11.2.2.5. Не входить в состояние 'inactive for search' при отсутствии фиксации

Если эта опция разрешена, то приемник действует по-другому в случае, когда не может получить фиксацию: вместо входа в состояние Inactive for search, сохраняются попытки получения фиксации позиции (acquire fix). Другими словами, приемник никогда не войдет в состояние Inactive for search state, так что период поиска (search period) и таймаут acquisition становятся не актуальными.

11.2.2.6. Обновление RTC и эфемерид

Чтобы поддерживать возможность быстрого запуска, приемнику нужно регулярно калибровать свои часы RTC и обновлять данные эфемерид. Это можно гарантировать активацией опции update RTC и update Ephemeris. RTC калибруются каждые 5 минут, и данные эфемерид загружаются каждые 30 минут. Для дополнительной информации см. "11.2.1.4. Загрузка данных спутника".

11.2.2.7. Управление сигналом EXTINT

Функция управления ножкой позволяет отменить автоматический цикл активно/не активно Power Save Mode. Состоянием приемника можно управлять через ножку EXTINT0 или EXTINT1.

Если разрешена функция Force-ON (принудительное включение), то приемник не войдет в состояния Inactive, пока сконфигурированная ножка EXTINT (либо EXTINT0, либо EXTINT1) находится в состоянии лог. 1. Приемник будет всегда в состояниях Acquisition/Tracking (ON/OFF operation) и Acquisition/Tracking/POT (циклический трекинг) соответственно. Когда эта ножка поменяет свой уровень на лог. 0, приемник продолжит свое сконфигурированое поведение. UBX-CFG-PM2 используется для выбора и конфигурирования ножки, которая управляет описанным выше поведением.

Если разрешена функция Force-OFF (принудительное выключение), то приемник войдет в состояние Inactive и останется в нем до следующего события пробуждения (wake-up event). Любое событие пробуждения может разбудить приемник, даже если ножка EXTINT установлена на Force-OFF. Однако приемник проснется только на период времени, необходимый для чтения настроек конфигурации ножки, т. е. Force-OFF, и затем снова войдет в состояние Inactive.

11.2.2.8. Смещение (временной) сетки

Как только у приемника есть достоверное время, обновляемая решетка времени (update grid) выровнена на начало недели GPS (воскресенье, 00:00). До получения достоверного времени update grid не выровнена. Тогда смещение решетки сдвигает update grid по отношению к началу недели GPS. Пример использования можно найти в главе "11.2.4.1. Использование смещения сетки времени".

 Смещение сетки не используется в функционировании циклического трекинга.

11.2.3. Функции PSM

11.2.3.1. Коммуникация

Когда PSM разрешено, обмен данными с приемником (например отправка сообщения UBX для запрета PSM) требует особого внимания. Причина в том, что приемник может находиться в состояние неактивности (Inactive state), и поэтому не сможет принять какое-либо сообщение через свои интерфейсы. Чтобы гарантировать обработку конфигурационного сообщения приемником даже в состоянии неактивности, следует предпринять следующие шаги:

• Отправить пустую последовательность 0xFF (достаточно отправить 1 байт) через UART приемника. Это разбудит приемник, если он находится в состоянии Inactive. Если приемник не находится в состоянии Inactive, то эта последовательность будет игнорироваться.
• Отправить конфигурационное сообщение через примерно 0.5 секунды после отправки пустой последовательности. Если интервал между пустой последовательностью и конфигурационным сообщением слишком короткий, то приемник может быть не готов к приему сообщения. С другой стороны, если этот интервал будет слишком длинный, то приемник может вернуться в состояние Inactive перед тем получением конфигурационного сообщения. Поэтому важно проверить ответ UBX-ACK-ACK от приемника, чтобы убедиться в том, что конфигурационное сообщение было принято.
• Сразу после сообщения конфигурации отправить сообщение о сохранении конфигурации.

11.2.3.2. Wake-up (пробуждение, вывод приемника из состояния Inactive)

Приемник может быть "разбужен" генерацией перепада на следующих ножках:

• Нарастание или спад уровня на одной из ножек EXTINT.
• Нарастание или спад уровня на ножке RXD1 (прием UART).
• Нарастание уровня на ножке NRESET.

Все сигналы пробуждения интерпретируются как запрос позиции, когда приемник пробуждается и пытается получить фиксацию своего положения. Сигналы пробуждения не дают эффекта, если приемник уже находится в состоянии Acquisition, Tracking или POT.

11.2.3.3. Поведение при подключении к хосту USB

Пока приемник подключен к хосту USB, он не входит в состояние с самым малым потреблением энергии. Причина в том, что он должен оставить некоторый небольшой уровень активности CPU, чтобы не нарушить требования спецификации USB. Недостаток, однако, заключается в том, что потребление энергии оказывается выше.

 Пробуждение от одной из ножек EXTINT и от UART также возможно, даже если приемник подключен к хосту USB. Состояние этих ножек должно поменяться как минимум на 1 миллисекунду.

11.2.3.4. Взаимодействие с функцией AssistNow Autonomous

Если обе функции, PSM и AssistNow Autonomous, разрешены, то приемник не войдет в состояние Inactive for update, пока AssistNow Autonomous не выполнит вычисления. Это предотвратит потерю данных из-за не оконченных вычислений, и в результате снизит общий необходимый объем энергии, который нужен для AssistNow Autonomous. Задержка перед входом в состояние Inactive for update, если она есть, будет в диапазоне нескольких секунд, очень редко больше 20 секунд.

AssistNow Autonomous затрагивает только вход в состояние Inactive for update. Другими словами, при работе циклического трекинга AssistNow Autonomous не пересекается с PSM (кроме увеличенной потребляемой мощности).

 Разрешение функции AssistNow Autonomous приведет к повышению потребляемой мощности при вычислении прогноза. Главная цель PSM состоит в снижении общего потребления энергии. Таким образом для каждого приложения следует уделять особое внимание принятию решения, что что важнее - выгоды AssistNow Autonomous или повышенное энергопотребление, связанное с его использованием.

11.2.4. Примеры

11.2.4.1. Использование смещения сетки времени

Сценарий: получение фиксации позиции один раз в день, в указанное фиксированное время. Если фиксация позиции не получена, то попытаться это сделать снова через каждые 2 часа.

Решение: сначала установить период обновления (update period) 24*3600 секунд, и период поиска (search period) 2*3600 секунд. Теперь фиксация позиции будет получена каждые 24 часа, и если при этом произошла ошибка, то повторные попытки будут осуществляться интервалами в 2 часа. Поскольку update grid выровнена на полночь суббота/воскресенье, то фиксация позиции будет происходить в полночь. Путем установки grid offset на 12*3600 секунд, фиксация позиции будет сдвинута на время полдня. Если фиксация в полдень потерпела неудачу, то повторные попытки будут осуществляться каждые 2 часа, первая в 14:00. После успешного получения фиксации позиции следующая фиксация будет осуществляться в полдень следующего дня.

11.2.4.2. Использование нулевого периода обновления

Сценарий: получать фиксацию позиции по запросу.

Решение: установить в 0 период обновления (update period) и период поиска (search period). Тогда приемник будет оставаться в неактивном состоянии до своего пробуждения.

11.3. Настройка пикового тока

Пиковый ток (peak current) во время захвата спутников и получения фиксации может быть снижен путем активации соответствующей опции в CFG-PM2. Снижение peak current приведет к увеличению времени запуска приемника.

 Эта настройка не зависит от активированного режима (Continuous или Power Save Mode).

11.4. Команда включения/выключения (Power On/Off)

С помощью сообщения RXM-PMREQ приемник принудительно может быть введен в состояние Inactive (в Continuous и Power Save Mode). Он будет оставаться в состоянии Inactive на время, указанное в сообщении, или пока не будет разбужен активностью ножек EXTINT или RXD1.

 Отправка сообщения RXM-PMREQ, когда приемник находится в Power Save Mode перезадаст PSM и принудительно переведет приемник в состояние Inactive. Он будет оставаться в состоянии Inactive, пока не будет разбужен. После пробуждения приемника он продолжить работать в Power Save Mode так, как был сконфигурирован.

11.5. Управление EXTINT, когда Power Save Mode не активен

Приемник может быть принудительно выключен (OFF) также когда не активен Power Save Mode. Это работает так же, как управление EXTINT в Power Save Mode. Только в Power Save Mode эта функция разрешается и конфигурируется с помощью CFG-PM2.

11.6. Частота измерений и навигации с Power Save Mode

В Continuous Mode частота измерения и навигации конфигурируется с помощью UBX-CFG-RATE. Однако в Power Save Mode частота измерения и навигации может отличаться от сконфигурированных скоростей следующим образом:

• Cyclic Operation: когда приемник в состоянии Power Optimized Tracking (трекинг, оптимизированный по потреблению тока), частота измерений и навигации определяется периодом обновления updatePeriod, сконфигурированным в CFG-PM2. Однако приемник может переключиться в состояние Tracking (например для загрузки данных). Когда приемник в состоянии Tracking, частота измерения и навигации конфигурируется через UBX-CFG-RATE. Замечание: когда приемник не может больше выдавать фиксации позиции, он может переключиться из Cyclic Operation в ON/OFF Operation (если это не запрещено ключом doNotEnterOff в CFG-PM2). В этом важны замечания ниже.
• ON/OFF Operation: когда приемник в состоянии Acquisition, частота измерения и навигации фиксирована на 2 Гц. Все сообщения NMEA (и возможно UBX), которые выводятся при фиксациях навигации также появляются с частотой 2 Гц.

Это должно быть рассмотрено при выборе baud rate приемника, который использует Power Save Mode! Имейте в виду, что приемник может оставаться в состоянии Acquisition в течение довольно длительного времени (могут быть десятки секунд при условиях приема слабого сигнала). Когда приемник иногда переключается в состояние Tracking, частота измерения и навигации будет такой, как сконфигурировано UBX-CFG-RATE.

 Когда используется Power Save Mode, скорость передачи (baud rate) приемника должна быть выбрана такой, чтобы он мог обработать вывод объема данных, когда частота измерения и навигации равна 2 Гц.

[12. Time pulse]

 Эта функция имеет ограниченную поддержку, когда приемник работает в режиме GLONASS mode. В частности, точность импульса времени (time pulse) в режиме GLONASS не была калибрована.

У приемников u-blox GNSS есть функция генерации временного импульса, у которых можно конфигурировать длительность и частоту. Функция time pulse может конфигурироваться с помощью сообщения CFG-TP5. Сообщение TIM-TP предоставляет информацию для следующего импульса, источника времени и ошибки квантования (quantization error) выходной ножки сигнала импульса.

12.2. Рекомендации

• Для самого лучшего качества импульсов времени (time pulse) рекомендуется запретить подсистему SBAS.
• Когда time pulse используется для точных приложений отсчета времени, рекомендуется калибровать задержку сигнала RF по опорному источнику времени.
• Следует позаботиться о настройках задержки кабеля в конфигурации приемника.
• Чтобы получить самую лучшую точность времени с помощью антенны, для неё нужно выбрать фиксированное и точное положение.
• Если требуется относительная точность времени между несколькими приемниками, не смешивайте приемники разных семейств. Если это все-таки требуются, то приемники должны быть калиброваны соответствующим образом по задержке кабеля и пользовательской задержке.
• При использовании сообщения TIM-TP рекомендуется конфигурация с установкой обоих параметров, скорости измерения (measurement rate, CFG-RATE) и частоты импульса (time pulse frequency, CFG-TP5) на частоту 1 Гц.

 Поскольку выдача TIM-TP связана со скоростью измерений (measurement rate), может появляться больше одного сообщения TIM-TP между двумя импульсами, если скорость измерения установлена больше, чем частота импульсов времени. В этом случае все сообщения TIM-TP между импульсами T1 и T2 относятся к T2, и последнее TIM-TP перед T2 сообщает самые точные данные, с меньшей ошибкой квантования (quantization error). В общем, если частота решения получения навигации и частота импульса времени сконфигурированы на разные значения, то не будет соответствия одного сообщения TIM-TP для каждого импульса времени.

Последовательный порядок присутствия сигнала на ножке TIMEPULSE и соответствующее выходное сообщение для простого случая 1 импульса в секунду (1PPS) и скорости обновления навигации раз в секунду показан на следующем рисунке.

Пример практического использования импульса времени TIMEPULSE на выводе PPS модулей, которые можно купить на AliExpress и Ebay, см. по ссылке [4].

12.3. Конфигурация time pulse

Приемники u-blox GNSS предоставляют одну или две ножки TIMEPULSE (в зависимости от модели), на который поступает сигнал импульса времени (time pulse, TP) с конфигуриуемым периодом импульсов, длиной импульса и полярностью (с нарастанием или спадом). См. документацию на изделие (product data sheet) для получения подробной информации для конфигурируемых величин.

Есть возможность определит разное поведение сигнала (например выходную частоту или длину импульса) в зависимости от того, засинхронизирован ли приемник по времени GPS. Сигналы импульсов времени могут быть сконфигурированы с помощью проприетарного UBX-сообщения CFG-TP5.

12.4. Конфигурация time pulse с помощью UBX-CFG-TP5

UBX-сообщение CFG-TP5 может использоваться для изменения настроек импульса времени. Следующие параметры определяют этот импульс:

• time pulse index - индекс импульса времени.
• antenna cable delay - задержка сигнала из-за его распространения по кабелю между антенной и приемником.
• RF group delay - групповая задержка радиотракта, задержка сигнала в модуле RF приемника (параметр только для чтения).
• pulse frequency/period - частота или время периода импульса.
• pulse frequency/period lock - частота или время периода импульса, как только приемник вычислил достоверное время из принятого сигнала. Используется только если установлен соответствующий флаг для использования другой настройки в режиме захвата (locked mode).
• pulse length/ratio - длина или скважность генерируемого импульса, когда либо задается время импульса, либо коэффициент соотношения времени между длительностями его состояний on/off.
• pulse length/ratio lock - длина или скважность генерируемого импульса, как только приемник вычислил достоверное время из принятого сигнала. Используется только если установлен соответствующий флаг для использования другой настройки в режиме захвата (locked mode).
• user delay - пользовательская задержка, задержка кабеля от приемника до устройства пользователя плюс задержка сигнала в любом приложении пользователя.
• active - выдача time pulse, если этот бит установлен.
• lock to gps freq - если этот флаг установлен, то для формирования сигнала будет использоваться информация GPS вместо частоты локального генератора.
• locked other setting - если этот бит установлен, то как только приемник вычислил достоверное время из принятого сигнала, используется альтернативная настройка. Этот режим может использоваться, к примеру, для запрета time pulse, если время не синхронизировано, или чтобы показать отсутствие синхронизации другими импульсами.
• is frequency - если этот флаг установлен, то интерпретировать поле 'Frequency/Period' как частота, а не период.
• is length - если этот флаг установлен, то интерпретировать поле 'Length/Ratio' как длина, а не соотношение интервалов.
• align to TOW - если этот бит установлен, то импульсы выравниваются по границе секунды.
• polarity - если установлено, первый перепад импульса будет фронтом нарастания уровня (Pulse Mode: Rising).
• grid UTC/GPS - выбор между сеткой времени UTC (0) или GPS (1). Также влияет на вывод информации времени сообщением TIM-TP.

 Максимальная длина импульса не может превысить его период. Настройки time pulse должны быть выбраны так, чтобы ни лог. 1, ни лог. 0 импульса не были меньше 50 нс (кроме случая, когда импульсы полностью запрещены), иначе импульсы могут теряться. Таким образом, максимальная частота на выходе TIMEPULSE приемника u-blox 7 не может быть больше 1000000000/(50+50) = 10000000 Гц, т. е. не больше 10 МГц.

12.4.1. Пример 1

Пример ниже показывает генерацию сигнала 1PPS TP в соответствии с определенными параметрами, переданными в сообщении CFG-TP5. Вывод 1 Гц сохраняется не зависимо от того, засинхронизирован или нет приемник по времени GPS. Выравнивание на TOW возможно только когда осуществлена синхронизация по времени GPS.

12.4.2. Пример 2

Следующий пример показывает генерацию сигнала 10 МГц TP на ножке выхода TIMEPULSE2, когда приемник засинхронизирован по времени GPS. Без синхронизации времени GPS частота 10 МГц не выводится.

[13. Receiver Status Monitoring]

UBX-сообщения класса MON используются для выдачи информации о состоянии частей встроенной вычислительной системы приемника, которые не относятся к специфике GNSS. Эти сообщения применяются главным образом для:

• Определения версий аппаратуры и ПО (Hardware and Software Versions) с помощью MON-VER.
• Получения статуса коммуникационной системы ввода/вывода.
• Получения статуса различных аппаратных секций с помощью MON-HW.

13.1. Система ввода/вывода

Система ввода/вывода (Input/Output, I/O) это внутренний слой GNSS в приемнике, где сосредоточены все возможности по обмену информацией с внешним хостом (такие как обмен через UART, DDC, SPI, USB). Каждой задаче коммуникации назначаются буферы, где ставятся в очередь данные сообщений. Для данных, источником которых служит приемник, и которые должны быть переданы через несколько коммуникационных очередей, может использоваться сообщение MON-TXBUF. Это сообщение показывает текущее и максимальное использование буфера, а также случаи ошибки (error conditions).

 Если сконфигурированное для выдачи количество данных слишком велико для определенной полосы пропускания используемого интерфейса (например, все UBX-сообщения порта UART передаются на скорости 9600), то буфер переполнится. Когда место в буфере истощится, новые сообщения, которые должны быть отправлены, отбрасываются. Подробности см. в секции "7. Последовательные коммуникационные порты".

Входные данные для приемника помещаются в буфер. Использование этих буферов показывается сообщением MON-RXBUF. Далее, поскольку данные затем декодируются приемником (например, чтобы разделить данные протоколов UBX и NMEA), может использоваться MON-MSGPP. Это сообщение показывает (для каждого порта и протокола), сколько сообщений было успешно принято. Оно также показывает (для каждого порта), сколько байт было отброшено из-за того, что они не были ни в одном из поддерживаемых структур протокола.

Следующая таблица показывает используемые номера портов. Обратите внимание, что не перечисленные здесь номера зарезервированы для будущего использования.

Назначение номеров коммуникационных портов

Протоколам назначены номера 0-7. Все не перечисленные в таблице ниже номера зарезервированы.

Назначение номеров коммуникационных протоколов

13.2. Индикатор Jamming/Interference

Поле jamInd сообщения UBX-MON-HW может использоваться как индикатор качества распространения (jammers/interference) непрерывной несущей (узкополосный радиосигнал). Интерпретация jamInd зависит от приложения. Необходимо запустить приемник в приложении и калибровать случай 'not jammed'. Если значение значительно вырастет сверх этого порога, то присутствует continuous wave jammer. Этот индикатор всегда разрешен.

13.3. Jamming/Interference Monitor (ITFM)

Поле jammingState сообщения MON-HW может использоваться как индикатор помех (jammers/interference) как для широкополосного, так и узкополосного (CW) радиосигнала (CW). Ото независимый от CW-only индикатора помех Jamming/Interference, описанного выше.

Этот монитор сообщает, был ли определен jamming, или есть ли подозрение на него со стороны приемника. Приемник следит за фоновым шумом, и смотрит на его значительные изменения. Обычно, если помехи не обнаружены, то он сообщает 'OK'. Если приемник определяет, что шум вырос выше предустановленного порога, то он сообщит 'Warning'. Если также шум вырос настолько, что не дает получить достоверную фиксацию, то приемник сообщит 'Critical'.

У монитора есть 4 состояния, показанные в следующей таблице:

По умолчанию монитор запрещен. Монитор разрешается отправкой соответствующего сообщения UBX-CFG-ITFM с установленным битом enable. В этом сообщении также можно указать пороги, на которых будет сообщаться широкополосный и CW jamming. Эти пороги должны интерпретироваться как уровень в децибелах (dB) выше нормального уровня (normal). Также можно указать, какую антенну приемник подразумевает, активную или пассивную (они отличаются усилением и уровнем шума).

 Алгоритм мониторинга шума/помех полагается на сравнение текущего измеренного спектра с опорным, когда была получена хорошая фиксация. Таким образом, этот монитор будет функционировать только когда приемник имеет хотя бы одну (хорошую) первую фиксацию, и до этого времени будет сообщать 'Unknown'. Jamming/Interference не поддерживается в режимах Power Save Mode (PSM) и ON/OFF.

[14. Timemark]

Приемник может использоваться для точного измерения времени, на котором был детектирован импульс на внешней ножке прерывания (EXTINTx). Опорное время может быть выбрано GPS, UTC или локальное с помощью конфигурационного сообщения UBX-CFG-TP5 (используя флаги LockGpsFreq и gridUtcGps). Числа задержек, определенные с помощью UBX-CFG-TP5, также применяются для результатов вывода сообщения UBX-TIM-TM2.

Вывод сообщения UBX-TIM-TM2 осуществляется на следующей эпохе, если:

• Разрешено сообщение UBX-TIM-TM2.
• На одном из каналов EXTINT произошло нарастание уровня или его спад с момента последней эпохи.

Сообщения UBX-TIM-TM2 включают время последней метки времени (timemark), индикатор нарастания/спада уровня, источник времени, достоверность, количество меток и ошибка квантования (quantization error). Метка времени инициируется постоянно.

 Сообщается только о детектировании последнего нарастания или спада уровня между двумя эпохами, поскольку частота вывода (output rate) сообщения UBX-TIM-TM2 соответствует частоте измерений (measurement rate), сконфигурованной с помощью UBX-CFG-RATE (см. рисунок ниже).

[15. Aiding, Acquisition]

Класс сообщений UBX-AID предназначены для предоставления уточняющих/вспомогательных данных (assistance data) для приемников u-blox GNSS, включая AssistNow Online и AssistNow Offline.

 В настоящий момент эти функции ограниченно поддерживаются во всех системах, кроме GPS. Соответственно все перечисленное в этой секции относится только к функционированию GPS.

15.2. Стратегии запуска

• Cold start (холодный старт): в этом режиме запуска у приемника нет информации о последней позиции, времени, скорости, частоте и т. д. Таким образом, он должен осуществить поиск по всей области времени, частот и возможным номерам спутников. Если найден сигнал спутника, то он отслеживается для декодирования эфемерид (18-36 секунд в условиях хорошего сигнала), в то время как другие каналы продолжают искать спутники. Как только определено достаточное количество спутников с достоверными эфемеридами, приемник может вычислить данные позиции и скорости. Обратите внимание, что некоторые конкуренты называют этот режим запуска как Factory Startup.
• Warm start (теплый старт): в режиме теплого старта приемник аппроксимирует информацию времени, позиции, данных курса по позициям спутников (альманаху). В этом режиме после включения питания приемник в основном должен загрузить эфемериды, пока он не может вычислить данные позиции и скорости. Поскольку данные эфемерид обычно устаревают после 4 часов, то приемник обычно начинает работу с режиме теплого старта, если время выключенного состояния, начиная от момента последней загрузки эфемерид, находится в этом интервале. Для такого сценария есть несколько уточнений, см. ниже описание AssistNOW online и AssistNOW offline.
• Hot start (горячий старт): при горячем старте приемник был выключен на не долгий интервал времени (меньше 4 часов), так что эфемериды все еще актуальны. Поскольку приемнику не нужно заново загружать эфемериды, это самый быстрый метод запуска. В сообщении UBX-CFG-RST можно принудить приемник сбросить и очистить данные, чтобы увидеть эффект от хранения / потери таких данных между перезапусками. Для этого сообщение UBX-CFG-RST предоставляет поле navBbrMaskfield, где инициируются запуски Hot, Warm и Cold, а также их другие комбинации.

15.3. Aiding / Assisted GPS (A-GPS)

Проблема автономных GPS. Пользователи ожидают немедленно получить информацию о своей позиции. С помощью стандартной GPS это не всегда возможно, потому что приемнику GPS должны передать свои данные как минимум 4 спутника, где содержатся точные орбитальные данные (эфемериды). При неблагоприятных условиях распространения сигнала загрузки данных спутников могут занять по времени минуты, часы, или даже вовсе закончиться неудачей.

Система Assisted GPS (A-GPS) ускоряет производительность получения информации путем предоставления через мобильные сети или Интернет приемнику GPS таких данных, как эфемериды, альманах, точное время и статус спутника. Эти уточняющие данные позволяют приемнику вычислить позицию в за секунды, даже в условиях плохого приема сигнала.

15.4. Aiding Data

Следующие уточняющие данные (aiding data) могут быть представлены приемнику:

• Position: информация о позиции с помощью сообщения UBX-AID-INI. Поддерживаются оба формата, ECEF X/Y/Z и latitude/longitude/height.
• Time: время может быть предоставлено либо неточным значением, поскольку будет страдать от задержки в зависимости от скорости в бодах интерфейса, или с помощью аппаратной синхронизации времени, когда точный импульс времени приходит на вход внешнего прерывания. Сообщение UBX-AID-INI поддерживает оба метода.
• Frequency: можно аппаратно подать частоту периодического прямоугольного сигнала с частотой 500 кГц и произвольной скважностью (однако минимальная длительность фаз лог. 0/лог. 1 не должна быть короче 50 нс) на вход внешнего прерывания, и предоставить значение частоты с помощью сообщения UBX-AID-INI.
• Orbit data: данные орбиты представляются с помощью сообщений UBX-AID-ALM и UBX-AID-EPH.
• Additional information (дополнительная информация): UBX-AID-HUI может использоваться для предоставления приемнику данных о работоспособности (спутников), параметрах UTC и ионосферных данных.

15.5. Aiding Sequence

Типовая последовательность передачи уточняющей информации (aiding sequence) состоит из следующих шагов:

• Включение приемника GNSS.
• Отправка сообщения UBX-AID-INI (время, такты и позиция).
• Отправка сообщения UBX-AID-EPH (эфемериды).
• Подача аппаратного импульса синхронизации времени в пределах 0.5 с после (или перед, в зависимости от конфигурации в UBX-AID-INI) отправки сообщения UBX-AID-INI, если требуется аппаратная синхронизация. когда это сообщение отправляется перед подачей импульса, убедитесь, что приемник GNSS смог прочесть и обработать уточняющее сообщение. Время чтения зависит от baud rate. Максимум для времени обработки 100 мс.
• Опциональная отправка сообщения UBX-AID-HUI (параметры health, UTC и ionosphere).
• Опциональная отправка сообщения UBX-AID-ALM (альманах).

15.6. AssistNow Online

AssistNow Online это целостное Assisted GPS (A-GPS) решение компании u-blox, ускоряющее производительность получения данных GPS, в результате время первой фиксации (Time To First Fix, TTFF) снижается до секунд. Эта система работает путем предоставления доступа к таким данным, как эфемериды, альманах и точное время от сети Global Reference Network приемников GNSS, сервера которой размещены по всему земному шару. С помощью A-GPS приемник может захватывать спутники и предоставлять точные данные позиции немедленно в ответ на запрос, даже в условиях плохого приема сигнала.

AssistNow Online использует коммуникации пользовательского уровня (User Plane) и открытые стандарты, такие как TCP/IP. Таким образом, эта служба работает на всех стандартных мобильных сетях коммуникаций, поддерживающих доступ к Интернет, включая GPRS, UMTS и беспроводные сети (Wireless LAN). Не требуется предпринимать дополнительные шаги, чтобы мобильные операторы разрешили работу сервиса AssistNow Online.

В контексте сообщений AssistNow Online состоит из уточняющих данных (Aiding data), которые доставляют позицию и время (Position, Time) через сообщение UBX-AID-INI, эфемериды (Ephemerides) через UBX-AID-EPH, альманах (Almanac) через UBX-AID-ALM и работоспособность/UTC/ионосфера (Health/UTC/Iono) через UBX-AID-HUI.

 AssistNow Online единственная форма уточняющей информации, которую поддерживает в работе GLONASS. Несмотря на это, данные орбиты GLONASS (эфемериды или альманах) в настоящий момент не поддерживаются.

15.7. AssistNow Offline

AssistNow Offline это служба A-GPS, которая также улучшает производительность GPS, снижая TTFF до нескольких секунд. В отличие от AssistNow Online, это решение позволяет осуществить немедленное позиционирование без необходимости подключения к сети в момент запуска. Система работает с помощью AlmanacPlus (ALP), данных дифференциальной коррекции альманаха для ускорения получения данных, в результате разрешается фиксация позиции за несколько секунд. Пользователи обращаются к данным путем случайных загрузок из Internet, когда это удобно.

Компания u-blox предоставляет файлы данных AlmanacPlus (ALP) разного размера, содержащие дифференциальные коррекции альманаха на периоды времени между 1 и 14 дней. Пользователи могут загрузить данные коррекции в любой момент, когда у них есть доступное соединение с Интернет. Приемник GNSS сохраняет загруженные данные в своей энергонезависимой памяти (non-volatile memory). Как альтернатива CPU хоста может хранить файл у себя, но передавать его данные частями, когда приходит запрос.

AssistNow Offline работает в местах без какого-либо беспроводного соединения, пока файлы с данными коррекции находятся в приемнике или на хосте, с которым приемник общается. Это делает данные коррекции немедленно доступными при запуске, устраняя задержки установки соединения, время ожидания завершения загрузки и затраты на звонки.

Самый простой способ настройки приемников GNSS состоит в использовании внутренней энергонезависимой памяти ли внешней flash-памяти, где могут быть сохранены данные ALP. В этом случае используется сообщение UBX-AID-ALP.

Когда у приемника нет ни одной подходящей собственной памяти, файл ALP должен храниться на хосте. Тогда приемник может запросить данные у хоста при необходимости. Это реализуется с помощью сообщения UBX-AID-ALPSRV.

В обоих случаях информация о состоянии доступности данных ALP для приемника может быть получена с помощью сообщения UBX-AID-ALP (STAT).

Файлы данных AssistNow Offline опубликованы по адресу [2].

15.7.1. Обзор AlmanacPlus на основе flash

Функциональность Flash-based AlmanacPlus означает, что данные AlmanacPlus сохранены в программируемой памяти flash, подключенной к чипу приемника.

Задача сервера - просто загрузить данные с сервера Интернет [2] или других источников, и затем передать их по кусочкам приемнику GNSS. Это отличается от метода, описанного в UBX-AID-ALPSRV, где файл должен оставаться на хосте, и приемник GNSS должен был бы брать оттуда данные частями по мере необходимости.

Сообщение AID-ALP существует в нескольких вариантах, комбинируя в себе весь функционал, необходимый для загрузки данных и сообщения о состоянии с одним Class/Message ID.

 Любой тип сброса приемника не затрагивает данные AlmanacPlus, сохраненные в памяти flash. Есть только один простой способ очистить их - стереть полностью всю память flash, или перезаписать её новым набором данных AlmanacPlus.

15.7.1.1. Процедура загрузки

Типовая последовательность шагов для загрузки файла ALP в приемник:

• Хост (компьютер PC) загружает из Интернет [2] копию текущего файла  ALP, и сохраняет её на своем локальном диске.
• Хост отправляет первые N байт из этого файла, используя сообщение AID-ALP (TX).
• Хост ждет от приемника сообщения AID-ALP (ACK) или AID-ALP (NAK).
• Если можно продолжить, хост отправляет следующие N байт, если сообщение было подтверждено положительно (ACK).
• Как только все данные были переданы, или когда было принято отрицательное подтверждение (NAK), хост передает сообщение AID-ALP (STOP).

Имейте в виду:

• N не должно быть больше ~700 байт (из-за входных буферов RS232/USB). Чем меньше N, тем может быть лучше надежность передачи пакета данных.
• N должно нацело делиться на 2.
• Здесь нет механизма повторной отправки (например, в случае ошибки или других проблем); если от приемника поступило сообщение NAK, то весь процесс загрузки должен быть перезапущен заново.
• Нет никакой явной контрольной суммы для проверки отдельных пакетов, однако есть неявная, поскольку сам файл ALP уже содержит контрольную сумму для проверки целостности данных файла.

Обзор разных версий сообщений AID-ALP

15.7.2. Обзор AlmanacPlus на основе хоста

Все три версии сообщения AID-ALPSRV используются для случая, когда файл ALP хранится не flash-памяти приемника, и когда хосту нужно периодически доставлять данные файла GNSS-приемнику. Это позволяет поддерживать функциональность AlmanacPlus для приемников GNSS, у которых нет на борту памяти flash. Для получения подробностей по реализации, где данные находятся во flash-памяти приемника, см. "15.7.1. Обзор AlmanacPlus на основе flash".

В сценарии, когда файл ALP находится на хосте, приемник GNSS называется клиентом, так как он главным образом запрашивает данные у хоста, а хост CPU, где находится ALP-файл, называется сервером.

Такой способ взаимодействия подразумевает, что клиент периодически посылает запросы данных хосту (клиент ALP выдает запросы ALPSRV-REQ), и хост должен ответить ему соответствующим образом, как показано ниже в описании ALPSRV-SRV.

 Чтобы этот механизм работал, сообщение AID-ALPSRV нужно активировать с помощью обычных команд  CFG-MSG. Если это не было активировано, то запросы отправляться не будут.

Клиент может попытаться модифицировать данные, сохраненные на сервере, с помощью сообщения ALPSRV-CLI. Сервер может безопасно игнорировать такой запрос, в таком случае файл ALP не может быть модифицирован. Однако для улучшения производительности при последующих перезапусках приемника рекомендуется модифицировать эти данные.

Обзор трех версий сообщений AID-ALPSRV

15.7.3. Особенности сообщений

Три варианта этого сообщения всегда несут заголовок и данные переменной длины, присоединенные к тому же сообщению. Первое поле idSize дает количество байт, на которых заканчивается заголовок полезной нагрузки UBX, и начинаются данные.

В случае ALP-запроса клиента сервер должен собрать новое сообщение в соответствии с вариантом сообщения AID-ALPSRV-SRV. Заголовок должен быть задублирован на idSize байт. Дополнительно серверу надо заполнить поля fileId и dataSize. Присоединенные к заголовку с размером idSize, данные должны быть добавлены в соответствии с запросом клиента (начиная от смещения ofs с количеством size значений).

15.7.3.1. Проверки диапазона

Сервер должен выполнять проверку полей ofs (смещений) и size, так как клиент мог бы запросить данные, которые на самом деле не существуют. Если клиент запросил данные в пределах, где данные еще есть, то поле dataSize должно быть заполнено удвоенным значением поля size (поле size показывает количество 16-битных значений, в то время как поле dataSize ожидает количество в байтах). Если клиент запрашивает данные вне пределов буфера, то действительное количество отправляемых байт должно быть соответственно уменьшено, и это реальное количество байт должно показываться полем dataSize.

15.7.3.2. Изменение файлов ALP

Функция сервера периодически пытается получить новые данные ALP из внешнего источника (конечный источник находится по ссылке [2]). Передача нового файла выполняется в результате выполнения запроса HTTP.

Когда становится доступным новый файл, сервер должен это показать клиенту. Эту функцию выполняет поле fileId.

Сервер должен произвольным образом нумеровать файлы ALP, которые он обслуживает. Для этого существует только одно требование - чтобы поле fileId реально менялось, когда имеется новый файл, и fileId не должен меняться, пока этот файл изменяется.

Если клиент в результате своего запроса получает другой fileId, отличающийся от ответов других предыдущих запросов, то он заново инициализирует свою подсистему обработки ALP, и запросит новые данные.

Кроме того, если клиент пытается отправить данные серверу с помощью метода ALPSRV-CLI, он показывает значением fileId, какой файл должен быть записан. Сервер должен игнорировать запрос, если fileId не подходит к файлу.

15.7.3.3. Код примера

Компания u-blox предоставила код примера на языке C, показывающий реализацию сервера, обслуживающего данные ALP на своей файловой системе с предоставлением их клиенту. Для получения копии этого примера обратитесь к ближайшему специалисту по внедрению решений u-blox (u-blox Field Application Engineer).

15.8. AssistNow Autonomous

15.8.1. Введение

Сценарии помощи, обслуживаемые AssistNow Online и AssistNow Offline, требуют онлайн-соединения, и хост может использовать это соединение для загрузки уточняющих данных (aiding data) и предоставления их приемнику, когда это необходимо. AssistNow Autonomous предоставляет функционал, подобный AssistNow Offline, без необходимости наличия хоста и соединения. На основе широковещательных эфемерид, загруженных со спутника (или полученных с помощью AssistNow Online) приемник может автономно (т. е. без какого-либо взаимодействия с хостом или онлайн-соединения) генерировать представление орбиты спутника ("AssistNow Autonomous data"), которые можно использовать для навигации намного дольше, чем для этого была предназначена загруженная через широковещание эфемерида. Это делает ненужными загрузки новых эфемерид для получения первой фиксации при последующих перезапусках приемника.

 По умолчанию функция AssistNow Autonomous запрещена. Её можно разрешить сообщением UBX-CFG-NAVX5.

15.8.2. Концепция

Ниже на рисунке показан принцип работы AssistNow Autonomous.

• Широковещательная эфемерида, загруженная со спутника, дает точное, номинально в пределах 4 часов, представление части орбиты спутника (траектории). Нельзя использовать эти данные вне 4 часов, так как они будут существенно отличаться от реальной орбиты.
• Орбита AssistNow Autonomous является расширением широковещательной эфемериды. Это предоставляет долгосрочную орбиту спутника для нескольких оборотов. Хотя эта орбита не совершенно точна, её точность достаточна для представления истинной орбиты, используемой для навигации.
• Данные AssistNow Autonomous автоматически и автономно генерируются из загруженных (или предоставленных вспомогательными службами) эфемерид. Эти данные автоматически сохраняются в память, защищенные питанием от резервной батареи (on-chip battery-backed memory). Опционально эти данные могут быть сохранены во внешнюю flash-память или на хост. Количество спутников, для которых можно сохранить данные, зависит от конфигурации приемника, и это можно поменять во время работы.
• Если в настоящий момент нет доступного широковещания эфемериды для навигации, то AssistNow Autonomous автоматически генерирует требуемые части орбиты из сохраненных данных. Данные также автоматически удерживаются текущими, чтобы уменьшить время расчета, когда подсистема навигации нуждается в данных орбиты.
• Работа функции AssistNow Autonomous прозрачна для пользователя и для работы приемника. Все вычисления осуществляются в фоновом режиме, и не влияют на нормальную работу приемника.
• Подсистема AssistNow Autonomous автоматически выводит из действия данные, которые стали слишком старыми, и которые больше нельзя использовать, чтобы не вводить ошибки позиционирования. Порог устаревания данных конфигурируется (см. ниже).
• AssistNow Autonomous может автоматически улучшить качество предсказания, если приемник может через 24 часа загрузить широковещательные эфемериды раннее доступного спутника.

15.8.3. Интерфейс

Для функции AssistNow Autonomous предоставляют интерфейс несколько сообщений протокола UBX:

• Сообщение UBX-CFG-NAVX5 используется для разрешения или запрета функции AssistNow Autonomous. По умолчанию эта функция запрещена. Когда AssistNow Autonomous разрешена, приемник будет автоматически генерировать данные AssistNow Autonomous для новых приятных широковещательных эфемерид и, если эти данные орбиты доступны и адекватны, автоматически предоставлять их подсистеме навигации при необходимости. Это сообщение также позволяет конфигурировать максимально допустимую ошибку орбиты. См. следующую секцию для объяснения этой возможности. Рекомендуется использовать firmware-значения по умолчанию, которые обеспечивают допустимость данных орбиты примерно до 3 дней.
• Сообщение UBX-NAV-AOPSTATUS предоставляет информацию о текущем состоянии подсистемы, а также о доступности данных AssistNow Autonomous для отдельных спутников GPS. Это состояние показывает, находится ли подсистема AssistNow Autonomous в ожидании (idle, или не разрешена), или она занята генерацией данных или орбит. Хосты должны мониторить эту информацию и выключать приемник только когда подсистема AssistNow Autonomous в состоянии idle (т. е. когда поле status показывает постоянный нуль).
• Сообщение UBX-NAV-SVINFO показывает использование орбит AssistNow Autonomous для отдельных спутников.

Есть 2 способа сохранить данные AssistNow Autonomous при выключении приемника, когда нет никакой батареи резервного питания (нет battery backup):

• Сохранение всех данных, включая конфигурацию, орбиты, и т. д.) во flash, когда такая память доступна.
• Опрос из приемника всех требуемых данных и конфигурации с сохранением их на сервер и возвращением обратно в приемник после запуска приемника. Это может быть реализовано с помощью сообщений UBX-AID-AOP (требуемые данные AssistNow Autonomous), UBX-AID-ALM (альманах, рекомендуется для улучшения производительности) и UBX-AID-HUI (требуемая информация времени UTC). Обратите внимание, что сообщение UBX-AID-AOP может содержать дополнительные (опциональные) данные, которые не сохраняются в battery backup RAM из-за ограничений по размеру доступного места. Эти дополнительные данные помогают приемнику произвести некоторые расчеты быстрее, чем если бы их не было. Однако это не влияет на качество орбиты. Таким образом, не обязательные данные могут быть вырезаны из полезной нагрузки, наgример, когда ограничен размер хранилища хоста. Отправка достоверного сообщения UBX-AID-AOP (или сообщений), в приемник автоматически разрешит функцию AssistNow Autonomous. Кроме того, рекомендуется использовать высокие скорости на последовательных интерфейсах, когда опрашиваетcя и отправляется это сообщение, поскольку у него довольно большой размер.

Имейте в виду, что приемнику требуется абсолютное время (т. е. полные дата и время, Date и Time) для вычисления орбит AssistNow Autonomous. Таким образом, для лучшей производительности рекомендуется предоставлять эту информацию приемнику с помощью сообщения UBX-AID-INI в сценарии, когда у приемника нет работающих часов RTC (например, когда у него нет backup battery).

15.8.4. Достоинства и недостатки

AssistNow Autonomous может предоставить ускоренный запуск (уменьшение TTFF), когда в наличии имеется недостаточное количество видимых спутников. Это в частности верно для ситуации, когда из-за слабого сигнала приема нельзя через широковещание загрузить эфемериды, и поэтому без AssistNow Autonomous (или A-GPS) нельзя получить фиксацию позиции. Однако требуется, чтобы приемник грубо знал абсолютное время, либо от RTC, либо с помощью уточняющего время сообщения UBX-AID-INI, и чтобы он знал, какие спутники сейчас видимы, либо из альманаха, или по отслеживаемым соответствующим сигналам.

Точность орбиты AssistNow Autonomous (позиции спутника) зависит от разных факторов, таких как определенный тип спутника, точности нижележащих широковещательных эфемерид, или орбитальной фазы спутника и Земли, и от того, насколько стары данные (со временем ошибка добавляется).

AssistNow Autonomous обычно расширяет широковещательные эфемериды на срок до 3 дней. Сообщение UBX-CFG-NAVX5 (см. выше) позволяет поменять этот порог установкой параметра максимальной допустимости неточности орбиты "maximum acceptable modelled orbit error" (в метрах). Имейте в виду, что это число не отражает реальную ошибку орбиты, вводимую расширением эфемериды. Это статистическое значение, которое представляет определенный ожидаемый верхний предел на основе некоторого количества параметров. Грубое приближение, которое связывает максимальное время расширения с этой установкой: maxError [m] = maxAge [d] * f, где множитель f равен 30 для данных, полученных из спутников, замеченных 1 раз, и 17 для данных, полученных из спутников, которые были видны больше одного раза.

Нет прямой зависимости (реальной и статистической) точности орбиты и точности позиционирования. Точность позиционирования зависит от разных факторов, таких как точность положения спутника, количество видимых спутников и геометрия (DOP) видимых спутников. Фиксации позиции, которые включают информацию орбиты AssistNow Autonomous, могут быть хуже, чем позиции, полученные только с использованием широковещательных эфемерид. Может быть необходимо подстроить пределы фильтров вывода навигации (Navigation Output Filters).

Фундаментальный недостаток любой системы для предсказания орбиты спутника, состоит в неизвестных будущих событиях. Следовательно, приемник не может знать о спутниках, которые станут неработоспособными, подверглись переустановке часов, или получили маневр на орбите. Это означает, что система навигации может перепутать неправильную позицию спутника с реально существующей. Однако при наличии достаточного количества других "хороших" спутников навигационные алгоритмы в конечном счете устранят дефектную орбиту из навигационного решения.

Воспроизводимость совокупности спутников GPS - потенциальная ловушка для использования функции AssistNow Autonomous. Для имеющегося положения Земли совокупность спутников (геометрия видимых спутников) повторяется каждые 24 часа. Следовательно, когда приемник "обучился" количеством спутников в некоторый момент времени, те же спутники в большинстве мест не будут видимы через 12 часов, и доступные данные AssistNow Autonomous ничем не могут помочь. Еще через 12 часов применимые данные были бы доступны, потому что сгенерированы 24 часа назад.

Чем дольше приемник смотрит в небо, тем больше спутников он увидит. На экваторе при полном виде на небо в течение часа обнаружатся приблизительно 10 спутников. После 4 часов трекинга неба обнаружатся примерно 16 спутников (т. е. половина всей совокупности), после 10 часов около 24 спутников (2/3 от общей совокупности), и примерно через 16 часов будет отслежена вся совокупность спутников (и сгенерированы данные AssistNow Autonomous). Меньшая видимость неба снизит эти значения. С определенным удалением от экватора ситуация может улучшится, потому что спутники могут быть видимы дважды в день. Например, на 47 градусов к северу полная совокупность спутников может наблюдаться примерно через 12 часов просмотра неба приемником.

Вычисления, требуемые для AssistNow Autonomous, выполняются приемником. Это требует энергии, и пользователи могут заметить увеличение энергопотребления на короткие периоды времени (несколько секунд, редко больше 60 секунд), когда запускаются такие вычисления. Осуществляющиеся вычисления автоматически не дают активироваться режиму сохранения энергии (power save mode), т. е. приемник не войдет в состояние выключения (power-off). Отключение приемника будет задержано до момента завершения всех вычислений.

 Функции AssistNow Offline и AssistNow Autonomous являются взаимоисключающими, и не могут использоваться одновременно.

[16. Точное позиционирование (Precise Point Positioning, PPP)]

 Эта функция доступна только для PPP-вариантов продукции.

Precise Point Positioning (PPP) это разновидность приемников, предоставляющих улучшенную точность позиционирования путем задействования изменения фазы несущей, чтобы сглаживать ошибки сигналов спутников. Этому алгоритму требуются постоянные измерения несущей, чтобы повысить эффективность коррекции. Требуются дополнительные коррекции ионосферы, наподобие принятых от SBAS или от GPS. Улучшение позиционирования можно ожидать только в случае не нарушенного вида на небо в периоде времени порядка минут.

 PPP-алгоритм работает только для спутников GPS, и для расширения точности позиционирования требуются коррекции SBAS.

16.2. Конфигурация

Чтобы использовать алгоритм точного позиционирования, функция PPP должна быть разрешена установкой соответствующего флага в сообщении UBX-CFG-NAVX5 (этим же сообщением PPP может быть запрещено).

 PPP можно активировать только в вариантах продукции с поддержкой Precise Point Positioning, где эта функция уже активирована по умолчанию.

Когда приемнику предоставлены достоверные коррекции RTCM, алгоритм Precise Point Positioning не будет работать. Алгоритм Precise Point Positioning перезапустится после того, как истекло время действия последней коррекции RTCM.

16.3. Мониторинг

Сообщение UBX-NAV-SVINFO показывает для каждого используемого спутника, сглаживался ли его псевдодиапазон алгоритмом PPP.

[17. Информационный лог]

17.1. Введение

Функция лога позволяет записать текущую приемника информацию в память flash, подключенную к нему. Лог может содержать фиксации позиции и произвольные строки байт. Запись позиций фиксации происходит независимо от системы хоста, и может продолжаться, когда хост выключен.

Следующие таблицы перечисляют все сообщения, связанные с логом:

Сообщения для управления логом и конфигурирования лога

Сообщения для выборки информации из лога

17.2. Настройка системы лога

Пустой лог может быть создан сообщением UBX-LOG-CREATE, и лог может быть удален сообщением UBX-LOG-ERASE. Система лога будет работать только если лог существует, так что большинство сообщения лога будет отбрасываться, если лог не присутствует. Только один лог может быть создан в любой момент времени, так что будет возвращено сообщение UBX-ACK-NAK в ответ на попытку создания лога, если лог уже существует. Сообщение задает максимальный размер лога в байтах (с некоторыми предустановленными значениями). И подсистема лога, и файловое хранилище приемника вносят дополнительную нагрузку в реализации, так что общее пространство, доступное для записей лога, может быть несколько меньше, чем указано.

UBX-LOG-CREATE также позволяет логу быть циклическим. Если лог создан как циклический, то когда он переполнится, старые записи лога будут удалены для того, чтобы можно было записать в него новые записи. Не циклический лог отличается от циклического тем, что при переполнении лога новые сообщения, которые не помещаются в лог, будут отбрасываться. UBX-LOG-CREATE также запускает систему лога, чтобы могли быть обработаны будущие сообщения лога. Система лога запуститься автоматически после старта приемника, если имеется в наличии настроенный лог. Лог будет оставаться в приемнике до тех пор, пока не будет специально уничтожен сообщением UBX-LOG-ERASE.

UBX-CFG-LOGFILTER управляет, разрешен ли в настоящий момент лог, и выбирает сообщения фиксации позиции для записи в лог. Эти конфигурационные настройки будут сохранены, если конфигурация записана во flash. Если это так, то запись в лог будет продолжена при включении питания точно так же, как это было до выключения питания.

На рисунке показаны переходы состояний на высоком уровне для подсистемы лога:

17.3. Информация о логе

Приемник может опрашивать сообщение UBX-LOG-INFO, которое дает информацию о логе. В ней имеется максимальный размер, до которого может дорасти лог (который, из-за дополнительных расходов, будет меньше, чем размер, запрошенный в UBX-LOG-CREATE), и количество уже занятого места в логе. Также это сообщение содержит информацию о количестве записей, находящихся в логе, вместе с временем и датой самого нового и самого старого сообщения лога, имеющих достоверную метку времени.

Записи лога сжаты, и есть информация хранения, связанная с ними, так что реальное пространство, занимаемое логом, может быть трудно предсказуемо. Минимальный размер для записи фиксации позиции 9 байт, и максимум 24 байта, типовой размер 10 или 11 байт.

Каждый лог имеет фиксированную дополнительную нагрузку, которая зависит от типа лога. Приблизительный размер этой дополнительной нагрузки показан в следующей таблице.

Дополнительные накладные расходы на ведение лога

Общее количество записей N, которое может быть записано в виде лога, зависит от размера flash, и может быть приблизительно оценено по формуле:

N = (FSZ - LO)/TSZ

FSZ размер flash, доступный для лога.
LO log overhead, размер дополнительной нагрузки.
TSZ типичный размер одной записи.

Например, если размер flash для лога 1500 kB (доступный размер после других использований flash, таких как образ firmware), не циклический лог мог бы содержать приблизительно 139000 записей:

((1500*1024)-(8*1024))/11 = 138891

17.4. Запись в лог

Сообщение UBX-CFG-LOGFILTER указывает условия, при которых происходит запись в лог. Ничего не будет записываться, если запись запрещена, иначе будут записываться фиксации позиции, и могут быть записи UBX-LOG-STRING. Когда запись разрешена, то элемент лога также будет создан из сообщения UBX-LOG-STRING. В нем будет метка времени, если у приемника будет информация о текущем времени.

В сообщении UBX-CFG-LOGFILTER есть несколько значений, которые можно использовать для выбора записи в лог позиций фиксации. Если все эти значения нулевые, то будут записываться в лог все фиксации позиции (их появление может происходить с максимальной частотой 1 Гц). Позиция записывается в лог, если превышен любой из порогов. Если порог установлен в 0, то он игнорируется. В дополнение к разнице позиции и текущей скорости также есть порог минимального интервала времени.

Фиксации позиции записываются только если была достоверная фиксация - ошибки фиксации и неправильные фиксации не записываются.

Фиксации позиции сжимаются, чтобы экономно использовать пространство flash. Чтобы улучшить сжатие, значения фиксации округляются, что улучшает их сжатие. Это означает, что значения позиций, которые вернула система лога, могут незначительно отличаться от значений, захваченных в реальном времени.

В режимах On/Off и Power Save Mode можно сконфигурировать систему лога так, что только одна фиксация будет записана для каждого периода. Фиксация будет записана немедленно перед выключением приемника, и это будет самая лучшая фиксация за период (в этом случае "лучшая" определяется по минимальной горизонтальной погрешности).

Записанные данные фиксаций состоят из:

• Времени и даты фиксации с точностью 1 секунда.
• Широта и долгота с точностью одна миллионная градуса. В зависимости от положения земли это обеспечивает точность порядка 0.1 метра.
• Высота (над уровнем мирового океана) с точностью 1 метр.
• Скорость по земле с точностью 1 см/сек.
• Тип фиксации (могут быть записаны только типы успешной фиксации).
• Количество спутников, используемых в записанной фиксации, но не более 19; значение 19 означает, что фиксация была осуществлена на основе данных от 19 или большего количества спутников.
• Оценка горизонтальной точности, чтобы показать качество фиксации.
• Заголовок к точности одного градуса.

Состояния активной подсистемы лога:

17.5. Получение данных из лога

UBX-LOG-RETRIEVE запускает процесс, который позволяет приемнику вывести записи из лога. Для этого запись в лог должна быть предварительно остановлена с помощью UBX-CFG-LOGFILTER. UBX-LOG-INFO может быть полезно для системы хоста, чтобы оценить текущее состояние лога перед запуском его вывода.

Как только вывод лога запущен, из приемника выводится одно сообщение в ответ на каждый запрос к логу. Отправка в приемник любого сообщения записи во время выборки лога приедет к остановке вывода лога перед обработкой сообщения.

Чтобы ускорить передачу вывода лога, рекомендуется установить высокую скорость передачи, и остановить обработку GNSS перед запуском передачи лога (см. UBX-CFG-RST).

UBX-LOG-RETRIEVE может указать начальный индекс записей лога и их количество. Максимальное количество записей, которое может быть возвращено в ответ на UBX-LOG-RETRIEVE, равно 256. Если осталось больше записей, то требуется выдать UBX-LOG-RETRIEVE несколько раз с другими значениями индекса startEntry.

Приемник отправит сообщение UBX-LOG-RETRIEVEPOS для каждой записи фиксации позиции и сообщение UBX-LOG-RETRIEVESTRING для каждой строковой записи лога. Сообщения будут отправлены в том же порядке, как они были записаны в лог, так что сообщения UBX-LOG-RETRIEVEPOS и UBX-LOG-RETRIEVESTRING могут чередоваться в потоке сообщений выводимого лога.

UBX-LOG-FINDTIME может использоваться для поиска в логе индекса первой записи с меньшим или равным указанным временем. Затем этот индекс может использоваться в сообщении UBX-LOG-RETRIEVE, чтобы предоставить выборку сообщений из лога на основе метки времени.

17.6. Подтверждение на команду сообщения

Некоторые операции с логом могут занять много времени для своего выполнения, потому что запись в память flash довольно медленная. Время некоторых операций может быть непредсказуемо, поскольку время операций flash может меняться. Чтобы позволить ПО хоста синхронизироваться с этими задержками, сообщения лога генерируют ответ. Это будет UBX-ACK-NAK в случае ошибки, иначе это будет UBX-ACK-ACK, если для ответа не было определено некоторое другое сообщение.

Можно отправить малое количество команд лога без ожидания подтверждения, поскольку существует очередь команд, однако тогда есть риск конфликта между подтверждениями от команд. Также очередь команд может переполниться, в результате команды потеряются.

[Словарик]

AGC Automatic Gain Control, автоматическая регулировка усиления, АРУ.

A-GPS, aGPS Assisted GPS, система предоставления уточняющих (вспомогальных) данных для навигации GPS.

Acquisition сбор данных со спутников с целью фиксации позиции.

Aiding вспомогательная, уточняющая функция.

Almanac альманах. Альманах в контексте GPS содержит шесть параметров орбиты спутника на определенный момент времени. Причем каждый спутник системы имеет данные о других спутниках. Навигатор, установив связь всего с одним спутником, после получения альманаха имеет данные о параметрах орбит и других. Альманах, загруженный в память спутника, действителен 30 дней. Тем не менее уточняются эти данные чаще — раз в несколько суток, во время сеанса связи с одной из наземных станций.

ALP сокращение от AlmanacPlus. Расширение *.alp имеют файлы с данными AlmanacPlus.

AOP Autonomous Orbit Parameters, автономные параметры орбиты.

BBR Battery Backup RAM, оперативная память, энергонезависимое хранение данных в которой осуществляется с помощью дополнительной батарейки резервного питания.

C/No, CNO Carrier-to-noise-density ratio, соотношение уровня несущей к плотности шума, подробнее см. Википедию.

COG course over ground, курс (маршрут) по земле.

CW continuous wave, непрерывная несущая, узкополосный радиосигнал (чистая синусоида).

dBHz логарифмическое выражение полосы пропускания (см. Википедию).

dead reckoning, DR точный расчет.

DGPS Differential Global Positioning Systems, дифференциальная глобальная система позиционирования. Улучшение системы Global Positioning System (GPS) с предоставлением улучшенной локальной точности, в диапазоне работы каждой системы, от номинальной точности 15 метров для GPS до точности около 10 см в случае лучших реализаций (из Википедии).

DOP Dilution of precision, снижение точности - специальный термин, использующийся в области систем глобального позиционирования для параметрического описания геометрического взаимного расположения спутников относительно антенны приёмника. Когда спутники в области видимости находятся слишком близко друг к другу, говорят о «слабой» геометрии расположения (высоком значении DOP), и, наоборот, при достаточной удалённости геометрию считают «сильной» (низкое значение DOP) (из Википедии).

ECEF Earth Centered Earth Fixed, геоцентрическая система координат с привязкой к Земле (подробнее см. Википедию).

GLONASS спутниковая система навигации, принятая Россией.

GNSS global navigation satellite system, общий термин обозначения систем глобальных спутниковых систем навигации.

GPS Global Positioning System, система глобального позиционирования, принятая США.

HDOP Horizontal DOP, горизонтальное DOP (см. DOP).

IGS International GNSS Service, международная служба глобальной навигации.

interference помеха, шум.

jamming помеха, нарушение радиосигнала.

NED Nord East Down, система координат север/восток/вниз. Система координат, также известная как local tangent plane (LTP), это географическая система координат, представляющая состояние направлений и обычно используемая в авиации (подробнее см. Википедию).

NMEA 0183 комбинированная спецификация, описывающая электрические соединения и обмен данными между морской электроникой, такой как эхо-локаторы, сонары, анемометры, гирокомпасы, автопилот, приемники GPS и т. д.

PDOP Position DOP, см. DOP.

POST Power-On Self-Test, самотестирование после включения питания.

POT Power Optimized Tracking, работа трекинга, оптимизированная по минимальному энергопотреблению.

PPS pulse per second, количество импульсов в секунду.

PR PseudoRange, тип коррекции DGPS.

PRN Psuedo Random Noise, насколько я понял, это система назначения номеров спутникам по псевдослучайному закону.

PRR PseudoRange Rate, тип коррекции DGPS.

PSM Power Save Mode, режим экономии энергии.

RAIM Receiver Autonomous Integrity Monitoring, система автономного контроля целостности навигации приемника.

RF radio frequency, радиочастота.

RTCM Radio Technical Commission for Maritime Services, специальный протокол для обслуживания морского оборудования.

RXM RX Manager, т. е. менеджер приемника.

SFDR spurious free dynamic range, динамический диапазон сигнала, свободный от помех.

SV Satellite Vehicle, спутник.

TCT Temperature Compensation Table, температурная таблица компенсации.

TCXO температурно-компенсированный кварцевый генератор.

TDOP Time DOP, см. DOP.

TOW Time Of Week, термин формата времени GPS.

TP TIMEPULSE, обозначение сигнала импульса времени.

TTFF Time to First Fix, время до получения первого достоверного места положения (фиксации).

UBX протокол обмена сообщениями, разработанный компанией u-blox.

URA User Range Accuracy, пользовательский показатель точности.

UTC Всемирное Координированное Время, система представления времени (подробнее см. Википедию).

VDOP Vertical DOP, вертикальное DOP (см. DOP).

эфемериды орбитальные данные спутника.

[Ссылки]

1. u-blox 7 Receiver Description Including Protocol Specification V14 site:u-blox.com.
2. ALP-файлы u-blox.
3. Интерфейс SPI.
4. Простой GPS-стандарт частоты и генератор RF.
5. NEO-7: модули GPS/GNSS.
6. Протокол NMEA в приемниках u-blox 7.
7. Протокол UBX в приемниках u-blox 7.