[Ioann_II 0]

Здравствуйте, Коллеги.

Пришлось перейти от модуля SIM968 к модулю SIM868. И вылезли некоторые отличия. Среди них формат передаваемых координат.

Если модуль SIM968 передаёт координаты в формате XXXX.XXXX и YYYYY.YYYY для широты и долготы, соответственно, как и прописано в документации, то вот модуль

SIM868 передаёт в формате XXXX.XXXXXX и YYYYY.YYYYYY. Хотя в спецификации написано только 4 цифры посте точки.

В связи с этим вопрос: У кого как? Что следует ожидать от других экземпляров? (у меня только один сейчас).

И ещё: дополнительные 2 цифры реально значащие? Такая точность?

Спасибо.

[jcxz 182]

6 часов назад, Ioann_II сказал:

Если модуль SIM968 передаёт координаты в формате XXXX.XXXX и YYYYY.YYYY для широты и долготы, соответственно, как и прописано в документации, то вот модуль

SIM868 передаёт в формате XXXX.XXXXXX и YYYYY.YYYYYY. Хотя в спецификации написано только 4 цифры посте точки.

В связи с этим вопрос: У кого как? Что следует ожидать от других экземпляров? (у меня только один сейчас).

И ещё: дополнительные 2 цифры реально значащие? Такая точность?

А какая разница? И почему у Вас ПО зависит от количества знаков после точки? Вы же, когда на экране нового калькулятора видите больше знаков после запятой, чем было раньше, не впадаете в ступор. Почему тогда это делает Ваше ПО? Такое ПО - неправильное.

Вот у меня в одном проекте есть SIM868 и используется GPS, но я даже не обращал внимания сколько там знаков. Какая разница? И мне кажется очевидным, что при развитии firmware SIM868 и выпуском новых версий, SIMCOM вполне вправе изменять количество этих знаков, лишь бы оно было >= чем указано в доке. И я думаю, что в доке указали минимальное разрешение, которое может обеспечить модуль, а при захвате бОльшего числа спутников, точность определения положения увеличивается и количество знаков, естественно, должно увеличиваться (производитель может или передавать там мусор (пока спутников маловато) или не передавать эти знаки (что он и делает получается)).

[Ioann_II 0]

А разница такова - в спецификации стоит один формат, а на деле - другой! И чего ждать от других (третьих, четвёртых, пятых экземпляров)? Хочется понимать, что за "зверинец" эта SIM868.

Я - то  в "ступор" не впадаю - моё ПО парсит строку верно, но вот на вопрос про 2 цифры Вы не ответили - они реально что-то значат?

Точность возросла по сравнению с SIM968?

Соответственно: есть ли смысл выделять память под большую строку или строку просто резать?

 

[jcxz 182]

17 минут назад, Ioann_II сказал:

А разница такова - в спецификации стоит один формат, а на деле - другой! И чего ждать от других (третьих, четвёртых, пятых экземпляров)? Хочется понимать, что за "зверинец" эта SIM868.

Я - то  в "ступор" не впадаю - моё ПО парсит строку верно, но вот на вопрос про 2 цифры Вы не ответили - они реально что-то значат?

А почему Вы решили что формат "другой"? Это цифры - незначащие. Так что - формат тот же самый.

Ожидать надо любого положения точки. И по-моему Вы не полностью прочитали мой пост. Я думаю, что количество знаков может зависеть от получаемой сейчас точности определения положения. И меняться в реальном времени. А значат эти цифры - что в данный момент SIM868 определяет положение с бОльшей точностью.

Цитата

Соответственно: есть ли смысл выделять память под большую строку или строку просто резать?

А зачем вообще выделять что-то там под строку? Не знаю как Вы там парсите ответы SIM868, но у меня ничего "под строку" не выделяется. Ответы SIM868 парсятся прямо в приёмном FIFO-буфере драйвера SIM868. А он, естественно, много больше, чем место под одну строку, потому что кроме строки GPS, могут приходить и другие URC или ответы на команды. В произвольное время.

[Ioann_II 0]

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

Формат никак не тот же самый - в спецификации он чётко прописан. 4 знака после запятой а есть 6 знаков! Как я понимаю, если в спецификации написано 4 - должно быть 4. А если может быть разное количество - то тогда так и пишут... Но этот вопрос не к вам.

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

[jcxz 182]

12 минут назад, Ioann_II сказал:

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

Так запоминайте уже распарсенные значения. У меня так и делается. И их размер никак не зависит от исходной строки, он всегда - Q31. Тем более что строковое представление - совершенно неудобно для последующей обработки (дальнейших целей).

Цитата

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

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

[Ioann_II 0]

Что значит "Q31"?

[jcxz 182]

28 минут назад, Ioann_II сказал:

Что значит "Q31"?

гугл в помощь. Википедия хотя-бы.

 

PS: Для угловых данных Q-форматы наиболее оптимальны для обработки/хранения. имхо.

[Ioann_II 0]

Ну ладно, прочитал, получается что Q31 - это 31 бит для дробной части. И при чем это тут? Это касается двоичных чисел, а тут уже двоично-десятичный формат, да и ещё преобразованный в строку, да и ещё, к тому- же там и размерность по позициям разная.

Сначала градусы, а потом, без разделителя, минуты, дробью.

М.б. там, внутри модуля и Q31, в доке не написано - да хоть в 3-ной системе пусть будет, главное, в каком виде наружу выдаёт.

 

[jcxz 182]

25 минут назад, Ioann_II сказал:

Ну ладно, прочитал, получается что Q31 - это 31 бит для дробной части. И при чем это тут? Это касается двоичных чисел, а тут уже двоично-десятичный формат

Почитали, но не поняли...

Двоичный, двоично-десятичный и пр. - это форматы текстового представления чисел, а не форматы чисел. А формат хранения (и обработки) чисел в МК это - либо обычное целое (частный случай Q-формата), либо Q-формат (общий случай для чисел с фиксированной точкой), либо плавающая точка. Парсер переводит числа из формата текстового представления в один из форматов хранения чисел.

Для представления угловых данных удобно использовать например Q31, получается он из плавающей точки умножением на (1u<<31)/180 с насыщением. Так как диапазон углов -180....+180, то умножаем на (1u<<31)/180, затем выполняем насыщение по диапазону -2^31...+2^31-1 и получаем угол в формате Q31 с полным диапазоном значений: -1.0 соответствует -180, +0.99999999 соответствует +180. Насыщение не обязательно, так как без него +180 автоматом станет -180, а ведь это - одно и то же. Только изредка оно важно.

Как можно заметить - для Q31 легко выполняется суммирование углов - просто сумма без всяких последующих проверок (результат автоматом будет в том же диапазоне -180...+180). Ну и т.д.

Аналогично можно использовать не Q31, а Q15 если хватает его разрядности и если он удобнее. Или другие разрядности Q. При необходимости - легко конвертировать один Q-формат в другой, простым сдвигом.

Точнее сказать: это нормализованное представление угловых значений. Нормализованное по значению 180. И представленное в Q-формате.

 

PS: Вообще советую почитать литературу про цифровую обработку сигналов. В части целочисленной обработки. Там почти вся она на Q-форматах. В систему команд DSP даже команды и регистры входят для аппаратной поддержки Q-формата. В системе команд ARM есть только лёгкие потуги в сторону аппаратной поддержки Q-формата.

[Ioann_II 0]

Да, теперь я Вас понял -Вы при распарсивании gnss строки сразу оцифровываете значения. Тогда все становится на свои места.

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

[jcxz 182]

1 час назад, Ioann_II сказал:

Да, теперь я Вас понял -Вы при распарсивании gnss строки сразу оцифровываете значения. Тогда все становится на свои места.

Да, конечно. Все нужные.

[wwo55 0]

Добрый день!

Есть такая волшебная программа Corebuilder.

В результате ее работы получается прошивка с измененными Вами параметрами.

В закладке NMEA есть возможность установить требуемое количество знаков после децимального разделителя.

Производитель SIM868 применил 6 знаков, памятуя, что для ряда применений стандартных 4 знаков недостаточно по разрешению.

 

[Ioann_II 0]

wwo55, не поделитесь этой программой? Спасибо.

[masterAL 0]

Добрый день. Не подскажете, возникают ли у вас проблемы при чтении данных GPS  и работе GSM канала связи?