Сверните свой собственный парсер NMEA или используйте парсер с открытым исходным кодом GPS?

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

Однако в проектах, таких как GPSD и Gypsy, активно проводится активная разработка. Если бы GPS был простым делом, проекты давно бы закончились и просто перешли в режим обслуживания.

  • Что они знают/делают, о которых я не знаю, поэтому мой код не учитывает?

Ответы

Ответ 1

От отличная статья от руководства GPSD:

  • Стандарт NMEA не обеспечивает полный набор TPV (время, положение, скорость) с ошибкой, геоида и магнитной вариацией и т.д.
  • Так как разные значения находятся в разных предложениях, и нет определенного порядка, вы не можете легко узнать, какая скорость идет, какой отчет о местоположении
  • Некоторые значения не указаны полностью (т.е. год составляет две цифры в более распространенных и avilable предложениях)
  • Нет стандартизованного способа определения поставщика, модели, прошивки
  • Нет стандартизованного способа изменения настроек (скорость связи, сообщенные сообщения, выборки в секунду и т.д.).
  • Несовместимые двоичные протоколы для расширенного использования и более быстрой отчетности
  • Из-за интересных условий гонки для USB для последовательных мостов и bluetooth для последовательных мостов, изменение скорости - очень сложная проблема.

-Adam

Ответ 2

Я работал с NMEA, мой опыт:

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

В дополнение к темам, упомянутым Адамом Дэвисом выше:

  •  
  • Не определено, как обращаться с недействительными атрибутами: например. Если автомобиль стоит на месте, особенно если он не двигался с момента запуска GPS-приемника, атрибут курса/заголовка недействителен; Большинство получателей выдаст пустой атрибут ",". Но это undefined.  
  • Поле времени: некоторые поставщики используют дробную часть после второй. Его точно не указано (?), Если это разрешено, или нет; некоторые устройства делают это, другие нет. (Далее: предложение GGA определяет две цифры после второго, предложение RMC использует целые секунды)
  • Порядок предложений RMC, GSV и т.д. отличается от одного приемника другим. Это приводит к тому, что проблема заключается в том, чтобы узнать, когда исправление позиции завершено. Либо вы проверяете, что прибыла новая метка времени, то вы знаете, что позиция завершена, но затем вы потеряете одну секунду с точки зрения поведения в реальном времени. Или вы знаете своего получателя и знаете, какое последнее предложение исправить. Или вы делаете "искусственный интеллект" для анализа порядка в первые десять секунд, а затем знаете, что является последним.

Вы можете посмотреть в спецификации SIRF и протокол UBLOX и посмотреть, какие огромные главы у них есть, чтобы описать, как они интерпретируют протокол NMEA.

Если кто-то знает действительно хороший парсер/писатель NMEA, написанный в java или Objective-C, который является открытым исходным кодом, а не под лицензией GPL, сообщите мне.

Ответ 3

С таким количеством хороших альтернатив вам может не нравиться так много.

Вот быстрая, оптимизированная по микроконтроллеру (AVR) библиотека анализатора NMEA: https://code.google.com/p/avr-nmea-gps-library/

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