Уважаемые форумчане, насколько интересен сабж?
Есть неплохое видео, иллюстрирующее различные варианты реализации GNSS DR.

не совсем понятно, что имеется в виду


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

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



В $GPGSA будут пустые поля, как минимум.

это предположение или уже есть документация?

Интересно было бы посмотреть исходные коды.

сама технология не новая. в интернетиках есть открытые проекты. можно в них посмотреть исходники.

Из открытой документации есть Telit_Jupiter_SL869-DR_EVK_User_Guide. Полный перечень команд - секрет Полишинеля ST

Не смог найти ответа на вопрос - можно использовать другие акселерометр/гиро (не AIS328 и L3G4200) - например MPU-6050 ?
(хотя догадываюсь об ответе )

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

Полностью согласен.

Обращайтесь к дистрибьютору. Если есть хороший проект и нужно привязать другие модели гироскопа/акселерометра - думаю Telit пойдет навстречу. Другие варианты (унификация входных данных) - тоже рассмотрим, но опять таки если будут коммерческие перспективы.

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

Был вопрос: надо?
Ответили: универсальное надо, подвязанное не надо.

А теперь поставьте себя на место производителя. Предположим, он внемлет вашим словам и выпустит прошивку, позволяющую работать с любыми типами инерционных датчиков. Для этого потребуется затратить определенные усилия разработчиков, возможно даже дело одной прошивкой не обойдется и придется модифицировать железо модуля. На это уйдет приличная сумма денег. Естественно, производитель будет рассчитывать, что подобные модули будут раскупаться как горячие пирожки. Ан нет!!! Найдется несколько любителей-энтузиастов, которые сделают штук 10-20 изделий с DR. И все! По собственному опыту - почти никто широко DR не использует: это дорого, энергоемко и нетехнологично. Соответственно, производитель получит на этой разработке одни убытки. Именно поэтому, прежде чем делать какую-либо доработку, выясняется ее потенциал. Бумажки и поклоны совсем не нужны - покажите лишь, что разработка будет пользоваться устойчивым спросом, как с технической, так и с маркетинговой точки зрения. Подозреваю, что и существующие гироскоп/акселерометр выбраны не по прихоти разработчиков, а по заказу конкретных клиентов, поэтому SL869-DR и увидел свет.

>>>По собственному опыту - почти никто широко DR не использует: это дорого, энергоемко и нетехнологично.

Согласен. У Симкома были модули умеющие DR - SIM18
Никому этот функционал так и не понадобился.
Гораздо удобнее датчики повесить отдельно на I2C или SPI.
И к модели не привязываешься и в потоке данных не путаешься.

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


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


ага, привет от распи. хавали уже такое кхм-кхм. ото и закапывайте этот модуль назад.


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


конечно. ведь всем известно, что если из модуля выкинуть SPI/I2C и программный код их поддержки, то модуль подорожает. так-то оно теперь понятно почему модули дорогие.


ну да, ну да. и это так хорошо описано в документации. что удалось узнать за пару минут поиска так это то, что для DR используется I2C. Даже без списка поддерживаемых датчиков можно смело закапывать.
Проблема та же, что и выше.

Так удобно сделать ...но, а потом ругать покупателей: вот негодяи, не покупают наше ...но, а мы так долго тужились.
А устроить опрос? Неее, это менеджерам надо ж закрыть контру/квейк опрашивать крупных покупателей, поспрашивать на форумах, поинтересоваться текущим состоянием рынка технологий. К чёрту это всё, так только
дураки делают. "Я вот слышал дядя Петя, что-то пилит. Раз пилит, значит нужно. Давайте купим/перепишем".

SIM18 не покупали... А с SIM08, что за фигню устроили? Сколько знакомых плевались в сторону симкома за чудачества такие. Год наверное прошёл пока они вместо телита решили опять попробовать симком.



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

Раз уже сделали - взяли бы да опубликовали на github.
Все бы сказали спасибо.
Вариант с загрузкой данных в модуль GPS наиболее удобный для использования.

Отправлять на модуль - это дифпоправки так можно.
А поток данных с акселерометра/гироскопа? Настраивать UART на мегабит?

1. А это проблема?
2. грубенькую теорию возьмём. современные модули обычно чаще 10 Гц не выдают посылки. Следовательно у нас есть 100 мс, чтобы получить всю необходимую информацию от модулю и плюс подтверждение приёма данных от датчиков. На скорости 115200 бод в промежуток 100 мс помещается 1152 байта. Вот некуда там всунуть 6 байт от гироскопа и 6 от акселерометра. Вот всё, ну никак, надо на мегабит переходить.

Теоретически, конечно, 115200 хватит, если 15 раз в сек посылать модулю <$PSTM3DGYRO> (порядка 700 байт в сек)

Вопрос, хватит ли точности. Сколько навигация по DR будет длится? 1 сек? 10сек?

Если кидать данные даже 15 раз в сек, сомневаюсь, что более 2 сек будет приемлимая точность без предварительной фильтрации показаний.
А фильтры в таких случаях ставятся адаптивные, и настраиваются, когда есть сигнал со спутников.....
Приходим к тому, что если не хотим цеплять к модулю датчики, придется самим заниматься DR.

Из приведенного документа непоятно, как долго модуль может поддерживать DR.
Лефортовский тоннель точно никто не выдержит.

Предполагаю что 10Гц будет маловато для последующего интегрирования

вот как раз частотой посылок и можно будет добиваться нужного уровня апроксимации.
Пусть будет пять килопосылок/с
$PSTMSETDRAD,Gx,Gy,Gz,Ax,Ay,Az*CS ,
где Gx,Gy,Gz,Ax,Ay,Az - uint32 в хексе.
такая посылка будет размером - 69 байт. Получаем поток данных со скоростью 345 кбит/с. Делаем без подтверждения от модуля, но включаем два стоп-бита и бит чётности. Всё это даст на интерфейсе поток 474375 бод.
Выбираем либо нестандартную скорость(что тоже удобненько)) ) либо стандартную 921600.
Данные датчиков отправляем по сигналу от выхода TIMEMARK ГНСС-приёмника. Т.е. раз в секунду держим его "в струе". Сигнал пропал, нет TIMEMARK через секунду: PSTMSETblabla,921600 и врубаем на всю катушку поток данных от датчиков.

Спрашивается - зачем это все пропускать через модуль когда есть независимые интерфейсы со скоростями подходящими для решения задачи инерциальной составляющей навигации ???
Магнитометр и акселерометр-гироскоп - одна железка висит на SPI, другая на I2C контроллера - далее математика.
Весной тестировали одну летающую железяку - при отключении GPS возврат по инерциалке с точностью до 2 метров при дальности полета 15 км.
На сегодня наверное уже математику улучшили, так как делалось изначально "на коленке" и проверялось далеко не в спокойных условиях.

можно использовать другой интерфейс, не тот где NMEA - не проблема.