По прошедшему: Счетчик времени может представлять некоторую величину в прошлом, которая имеет достаточно измеренной информации до и после счета времени (), чтобы сделать очень точную оценку PRC и RRC в момент счета времени (). Передаваемые поправки, полученные на основе такой техники, подразумевают пост-обработку определенного типа со стороны пользователя. Пользователь может выполнять обработку близко к реальному времени, выполняя свое решение в интервале . Измерения псевдодальности сохраняются пока не получена поправка для этого момента. После этого пользователь будет применять поправки без какой-либо задержки корректирующих данных. Чтобы получить навигационную информацию в реальном времени, приемник пользователя должен прогнозировать данные местоположения на текущее время , используя данные о скорости, или инерциальные, или другие датчики. Эта техника также хорошо применима к методу “Текущий”.

Текущий: Счет времени () для PRC и RRC должен быть в пределах 0.6 секунды от последней последовательности измерений, используемых в формировании данной поправки. В этом случае время ожидания в поправках может быть вызвано только задержками в передаче сообщений от опорной станции через некоторый промежуточный передатчик и приемник пользователя. Этот метод будет выдавать точные результаты в реальном времени. Пользователь может компенсировать задержку в линии передачи данных также, как вслучае техники “По прошедшему”, представленной выше.

Будущий: Счет времени () может быть сдвинут в будущее, чтобы компенсировать задержку в линии передачи данных. Этот метод требует точного знания ускорения псевдодальности. Этот метод будет вносить ошибку в поправки, если ускорение псевдодальности значительно изменяется в интервале между временем измерения и прогнозируемым временем. В этом случае пользователь не способен “убрать” эту ошибку, используя поправки в момент счета времени (). В сценарии, где ускорения являются значительными и хорошо известными, данная техника может повысить точность пользователя в реальном времени.

Метод, выбранный производителем обслуживания, должен удовлетворять требованиям специального обслуживания. Многие приложения, требующие высокой точности, не требуют реального фактического времени для обновления дифференциальных данных GNSS. Способность, близкая к реальному времени (< 30 секунд), может быть удовлетворительной. Метод “Текущий” обеспечивает наилучшие характеристики реального времени без искажения поправок ошибками прогнозирования. Для пользователей реального времени поправки легко пролонгируются вперед на текущее время (t) и пользователи могут получать наилучшую точность в момент счета времени (), близкого к реальному времени.

3.3 Формат сообщений дифференциальных поправок

Чтобы обеспечить общность программного обеспечения пользователя, обеспечить строгую способность выявления ошибки и минимизировать изменения по отношению к версии 2.1 Стандарта, которая относилась только к дифференциальной GPS, формат данных для дифференциальной GNSS был скопирован с формата данных GPS, хотя он и расходится с ним в чем-то, когда возникают другие требования. Однако, размер слова GPS, формат слова, алгоритм четности и другие характеристики сохранены. Наибольшее различие заключается в том, что дифференциальный стандарт использует формат сообщения переменной длины, тогда как формат GPS имеет фиксированную длину подкадров. Сохранение характеристик объясняется следующими причинами [7]:

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

2) Алгоритм четности GPS является общеизвестным и отработанным алгоритмом, с которым пользователи знакомы и который уже закодирован в приемнике пользователя.

3) Алгоритм четности перекрывает границы слова и разрешает знаковую неоднозначность, вносимую двухфазной модуляцией передачи данных.

4) 30-ти битовые слова (когда они сопоставляются с 32-х битовыми словами) в сочетании со скоростью передачи в 50 Гц обеспечивают удобную способность синхронизации, где моменты времени границ слова представляют собой величины, кратные 0.6 секунды. Граница каждого пятого слова совпадает при умножении с 3-мя секундами. Если бы использовались 32-х битовые слова, граница слова попадала бы на целочисленное значение только один раз в 16 секунд.

3.3.1 Общий формат сообщения

Общий формат сообщения показан на рисунке 2.2 с деталями для первых двух тридцатибитовых слов каждой посылки или каждого сообщения. Длина каждой посылки N + 2 слова, где N слова, содержащие данные сообщения. N изменяется в зависимости от типа сообщения, а также от содержания типа сообщения. Размер слова и алгоритм четности идентичны тому, что используется в навигационном сообщении GPS и описано в опубликованном издании Спецификации Сигналов GPS/SPS, документе, который можно приобрести в Информационном Центре GPS Береговой Охраны США.

Первое и второе слова

Первые два слова каждой посылки содержат данные, которые имеют отношение к любому типу сообщения, Данные об опорной станции, опорное время и информация, необходимая для синхронизации посылки пользователем. Их содержание обобщено в Таблице 3.1. Необходимо отметить, что индекс станции относится к идентификации дифференциальных опорных станций. Он не предназначен для идентификации станций линий передачи данных, которые различны для каждого из радиомаяков.

Таблица 3.1 - Состав первого и второго слов

* - 64 обозначается нулями во всех разрядах.

** - Спецификация сигнала стандартного позиционного обслуживания “Глобальной Системы определения местоположения”, которую можно получить из Центра Навигации Береговой Охраны, Александрия VA, 22315 [7].

Синхронизация кадра может быть получена пользователем способом, который подобен применяемому для данных GPS, с отличиями, которые связаны с переменной длиной кадров. Начало первого кадра представляет собой 8-битовую преамбулу, которая отыскивается пользователем. Номера типов сообщений являются теми, которые представлены ниже данной пояснительной записки. Индекс опорной станции является произвольным и устанавливается владельцем опорной станции.

Для передач псевдолитов, модифицированный Z-счет представляет собой время начала следующего кадра (начало преамбулы), а также опорное время для параметров сообщения. Модифицированный Z-счет отличается от Z-счета GPS тем, что LSB (младший значащий бит) имеет коэффициент масштабирования 0.6 сек, вместо 6 сек, для отсчета кадров переменной длины. Это требуется только для сообщений псевдолитов. Кроме того, диапазон Z-счета составляет только один час с целью экономии битов. Причина, лежащая в основе этого, заключается в том, что все пользователи дифференциальной GNSS всегда будут инициализироваться через систему GNSS и им будет известно время. Необходимо отметить, что Z-счет дифференциальной GNSS опирается на время GPS или GLONASS, соответственно для сообщений GPS и GLONASS, а не UTC.

Номер последовательности в кадре синхронизации является вспомогательным средством, заменяя последовательный Z-счет, когда имеется приращение параметра. Он будет увеличиваться в каждом кадре. Длина кадра на два слова больше, чем число слов с данными (N), следующих за заголовком. Т. е. если N равно нулю, то это означает, что нет ни одного слова после заголовка и длина кадра будет равна 2.

Версия 2.2 стандарта заново определяет значение трех битов Технического Состояния Станции таким образом, чтобы это не вызывало проблем у большинства существующих пользователей. Состояние “111” должно по-прежнему показывать, что опорная станция работает неудовлетворительно, “110” должно означать, что передача не контролируется, как показано в таблице 3.2. Другие шесть состояний в таблице 3.2 представляют собой те состояния, которые применяются Береговой Охраной США для обозначения коэффициента масштабирования для поля UDRE в сообщениях с дифференциальными поправками.

Таблица 3.2. Показатель технического состояния* опорной станции

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20