RTCM MSM поток: проверить совместимость систем и сигналов

Запросить

Радиоканал хозяйства доставляет поток RTCM, но приёмник использует лишь часть доступных данных. Причина может быть в составе сообщений и поддержке конкретных систем или сигналов. Проверяйте фактический поток и возможности получателя. Общее имя формата не гарантирует совместимость каждого сообщения. Приёмка должна показать, что именно распознано и принято, сохраняя различие между сетевой доставкой, декодированием и участием данных в выбранном навигационном решении установленного комплекта.

Сообщения RTCM MSM и возможности приёмника. Фактический поток; Семейства сообщений, системы и сигналы. Приёмник; Поддерживаемые системы, сигналы и применимые сообщения. Сопоставление; Подтверждение использования нужного потока.
Пригодность потока проверяют на согласованных системах и сигналах.

Составить карту поддержки

Обзор форматов BKG описывает MSM семейство для multi-GNSS наблюдений и различных сигналов. (BKG — Real-Time GNSS message formats) Это не означает, что любой приёмник поддерживает весь возможный состав. Сохраните подтверждённые версии и перечень возможностей источника, промежуточного декодера и получателя. Не выводите поддержку по одному успешному сообщению соседнего типа. Если шлюз пересылает данные без разбора, его доступность не доказывает, что конечное оборудование умеет использовать содержимое каждого доставленного пакета.

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

Проверить цепочку получателей

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

Затем на стенде добавьте согласованный неподдерживаемый элемент или измените один разрешённый тип. Программа должна дать предусмотренный исход и сохранить работу понятным образом. Не скрывайте отбрасывание общим статусом «RTCM OK», если потребителю важна полнота. После возврата исходного состава повторите проверку. Выбор минимально необходимого набора и частот передачи определяется проектом и документацией, а не универсальной рекомендацией статьи; экономия радиоканала не должна незаметно менять подтверждённую совместимость или состав данных без отдельной приёмки.

Закрепить фактический охват

В акте сохраните перечень потока, поддерживаемый поднабор и наблюдаемые результаты. Приёмка подтверждает конкретную совместимость, а не обещанную точность или полноту всех GNSS возможностей. Для хозяйства это помогает обоснованно расширять поток и локализовать отказ после обновления базы, шлюза или приёмника. Инженер видит, где закончилась пригодная обработка, и не принимает одно название RTCM MSM за доказательство, что любое устройство автоматически использует каждую переданную систему, частоту и наблюдаемую величину без ограничения.

Все разборы