Кто разбирается в NMEA? Вопрос по RMC.

[Dikoy]

В строчке RMC магнитное склонение идёт двузнаковым? То есть может принимать отрицательное значение, или только положительные? В мане как-то невнятно написано...

[Goldfinch]

Не знаю насчет склонения, но можно проверить на гарминовском приемнике. У меня вопрос по букве А перед контрольной суммой в таком сообщении $GPRMC,125123.000,A,5535.7014,N,03806.6422,E,0.00,139.95,040311,,,A*63 Это из чипа MTK, NMEA 0183 v3.01. Что значит вторая буква A в конце? Перед А запятые как раз выделяют пустые поля с магнитным склонением. Может у кого есть описания по NMEA более свежие, в тех что я находил магнитное склонение было последним полем.

[Moskus]

The last version 2 iteration of the NMEA standard was 2.3. It added a mode indicator to several sentences which is used to indicate the kind of fix the receiver currently has. This indication is part of the signal integrity information needed by the FAA. The value can be <b>A=autonomous, D=differential, E=Estimated, N=not valid, S=Simulator</b>. Sometimes there can be a null value as well. <b>Only the A and D values will correspond to an Active and reliable Sentence.</b> This mode character has been added to the RMC, RMB, VTG, and GLL, sentences and optionally some others including the BWC and XTE sentences.

[Goldfinch]

Понято, спасибо! Не первый раз выручаете!

[Kypcop]

<i><b>$GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A</b> где: RMC √ NMEA заголовок 123419 √ UTC время, 12:34:59 А √ статус (А- активный, V- игнорировать) 4807.038,N √ Широта, 48 градусов 07.038 минут северной широты 01131.000,Е √ Долгота, 11 градусов 31.000 минута восточной долготы 022.4 √ Скорость, в узлах 084.4 √ Направление движения, в градусах 230394 √ Дата, 23 марта 1994 года 003.1,W √ Магнитные вариации</i> <A HREF="http://www.alpinemap.su/index.php?to=ar ... Из приведеного видно, что "<i>003.1,W √ Магнитные вариации</i>" имеют трехзначное значение и определитель долготы, значит диапазон значений должен быть в пределах 0╟ - 180╟ без знака.

[Goldfinch]

При разборке NMEA сообщения столкнулся с тем, что блютус-приемник на sirf3 выдает строку переменной длины. Некоторые поля RMC фиксированные (время, координаты), а длина полей скорости и путевого угла плавают из-за отсутствия дополняющего нуля (например 36.00 градусов вместо 036.00). Работал с приемником на mtk - там с длиной все четко, она постоянная. Скажите, пожалуйста, протокол NMEA оговаривает длину полей или она может варьироваться в зависимости от значений величин?

[Adrenalin]

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

опять же, учтите помехи при передаче, и проверку на контрольную сумму.
80 знаков по длине на одно предложение.

[Goldfinch]

Я пишу под конкретный приемник, но хочу сделать универсальную библиотеку с проверками на достоверность помимо контрольной суммы. Попадал в ситуации, когда из сообщения выпадало два одинаковых символа, например две запятые или две цифры, при этом КС остается прежней) Поэтому нужна дополнительная проверка. На ум приходит первая проверка на количество полей сообщения. А с достоверностью данных хотелось бы для начала длину проверить. Или городить проверку на уровне повыше, например на какую величину могла координата или скорость измениться на за 200 мс между опросами.

[skycolonel]

Вариант.

В первую очередь выделить из потока строку, начинающуюся с '$' и заканчивающуюся ВК/ПС и не больше 79 символов. Посчитать контрольную сумму.

Далее выделять поля. Их три типа.
- Начинается с бакса. Всегда первое.
- Начинается с запятой. Не первое. Может быть пустым. Переменной длины!
- Начинается со звездочки. Может отсутствовать. Всегда две 16-ричных цифры. Всегда последнее. Если присутствует, то равно контрольной сумме, посчитанной на первом этапе.

Принцип выделения полей - начинаются со спец. символов '$' ',' '*'. Заканчиваются ПЕРЕД символами ',' '*' ВК/ПС (или концом строки, если могут обрезаться где-то, но это ошибка).

Выделение строки и парсинг первого поля (ID) универсален. Далее по каждому типу отдельно. Незнакомые предложения лучше игнорировать, а не выдавать ошибку. Если хочется строгой проверки, надо смотреть какого типа поле (например: широта, знак широты, время итп) и диапазон значений. Учесть, что поля могут быть пустыми.

[Dikoy]

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