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

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

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

  • что они знать/делать то, о чем я не знаю, и поэтому мой код не учитывает?
12
gps nmea parsing

3 ответов

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

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

Адам

9

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

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

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

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

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

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

3

с таким количеством хороших альтернатив, вы, возможно, не захотите так много беспокоиться.

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

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

0