Comments 51
Что-то странно, что он так долго ловит. Современные GPS чипы даже без AGPS довольно быстры, полчаса на фикс это что-то из начала 2000ых. С высотой ничего сделать нельзя, GPS плохо расчитан на высоту. Хотя с новыми чипами судя по телефонам ситуация некоторым образом лучше.
Все никак не выберусь на открытую местность.
Хотя вот теплее станет — буду окно открывать
Естественно заявленные производителем характеристики не имеют ни чего общего с окном. Ublox отличный чип за свои деньги. На улице получает координаты за положенное время.
Столько времени прошло, может не актуально давно.
Делал себе подобный девайс для замены одометра/спидометра/тахометра мотоцикла. Предусмотрел питание GPS модуля от батарейки на 3 Вольта. Причём на платке уже стоит ионистор (вроде бы), подключил батарейку прямо к нему.
Убрал с приборки тахометр, а вместо него поставил OLED экран 0,96" (вроде). Использовал чисто ардуиновский индусский код (плата Arduino Pro Mini). Устройство показывает время, скорость, несколько одометров, тахометр, некое подобие диностенда. Спутники ловит секунд за 20. Потребление на GPS модуль указано в даташите — какие то микроамперы, это дежурка, чтоб каждый раз спутники с нуля не искать.
Кстати, памяти ещё полно осталось свободной, а оптимизировать мой говнокод можно очень сильно.
Ну там как с нуля… после 6 часов простоя ему нужно обновление данных, считай почти с нуля. А если начальное положение в котором включается приемник сместить на целую «эпоху» в терминах GPS это соответствует сетке координат в 300км то быстрее будет сделать «холодный сброс» и высчитывать координаты заново. Батарейка помогает между поездками в паузах на 2-3 часа, а дальше уже под сомнением. В смартфонах, в которых есть доступ к интернету работает A-GPS которая выкачивает необходимые данные по координатам и параметрам орбит спутников через интернет(около 35кБ) без него модуль вынужден делать это через сами спутники со скоростью около 300Бод/спутник. А это где-то в худшем случае при хорошей связи минут 10… Учитывая что для начала навигации нужны данные только по актуальным спутникам начало навигации происходит гораздо раньше — это где-то минута-две.
Попробую, может быть, завтра завести мот, засеку сколько времени будет ловить первый спутник (по нему сразу синхронизируется время) и ещё три (минимум для начала работы спидометра). Последний раз мот заводился 9 марта. Я бы сбросил его до холодного старта для чистого эксперимента, но уж очень тяжко разбирать приборку…
Кстати, каюсь, что эту статью и связанные с ней ещё не прочитал, но в закладках.
Да, когда покупал GPS модуль, то пожадничал и купил отбраковку без ГЛОНАССа, хотя мне и так хватает точности, плюс/минус лапоть по карте.
Вчера проверил. Чуть меньше чем через минуту (55 секунд или около) поймал 4 спутника. При этом параметр hdop (горизонтальная точность, вроде) был 25 метров. Через ещё 20 секунд поймал 6 спутников, hdop стал 1,5.
В принципе довольно ожидаемо. Где-то читал что у GPS матожидание времени начала навигации составляет 60 секунд с холодного старта. В худших условиях может и пол часа…
А вот немного не по теме — внешний GPS для смартфона. Что-то встроенная антеннка не радует на многих моделях, то в лесу глохнет, то от положения телефона зависит просто радикально, то еще чего… Хочется отдельный девайс, который умеет передавать координаты по синезубу для софта на телефоне. При этом имеет правильную антенну, габариты до пачки сигарет или даже двух — не критичны. Питание встроенное и, крайне желательно, влагозащита до кратковременного буль-буль.
Раньше выпускались приемники GPS во внешнем исполнении с Bluetooth. Но сомневаюсь, что сейчас их можно будет найти, т.к. телефоны вытеснили все.

У меня та же проблема, на YouTube нашел несколько видео, где рекомендуется разобрать телефон и подогнуть несколько выводов, якобы проблема из-за плохого контакта GPS-антенны. Разобрал, подогнул, но никакого улучшения не получил. :(

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

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

Кстати говоря, тот самый Holux M241, который я переделываю, как раз и умеет отдавать по синезубу. Только вот если с windows mobile (я им пользовался лет 7 назад) все более менее работало, то в современном андроиде у меня не получилось. По блютусу то я их связал, но так и не понял как системе сказать где брать GPS данные.
По идее вот эта софтина должна помочь. Но только с софтом, который не против mock location
https://play.google.com/store/apps/details?id=googoo.android.btgps
Ухты! Буду знать.

То, что блютус GPS не работает с андроидом из коробки я выяснил во время полета на самолете, возможности гуглить небыло :)
А её особо и не нагуглишь. Я о ней узнал только потому что она в «рекомендуемых» рядом с моей программой, которая делает обратное (вещает NMEA с телефона как holux)

Очень понравилась ваша статья.


Так вот, сцуко, компилер для каждого цппшника дублирует фонты. Я переместил фонты в cpp файл и объем флеша сразу сократился на 9к.

Не в том ли проблема, что ваш хедер со шрифтом (8x12Font.h) не содержит include guards?
Хотя в остальных заголовочных файлах он есть.

good catch! Спасибо!

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

Там у самого A7 чипа довольно богатый набор команд вплоть до HTTP запросов. Так что вещь просто бомбовая!

Последний месяц пытался осилить как раз stm32f103cbt6 в виде китайского клона Maple mini. Arduino подобная IDE от Leaflab совсем не впечатлила. Поэтому решил установить Eclipse. Ставил по инструкции отсюда (там есть на русском языке).
Не все там получилось, но простой Blink завелся. А дальше решил «усложнить» и подключить DS1307 по I2C. На этом все и застопорилось — сплошные ошибки получения данных от часов. После долгих попыток победить проблему и чтений интернетов наткнулся на Errata от STM, в котором много и непонятно описана куча проблем по работе I2C именно на камнях stm32F1xx.
В файле драйвера stm32f1xx_hal_i2c.c, который идет в CubeMX, есть строки:
*** I2C Workarounds linked to Silicon Limitation ***
====================================================
[..]
Below the list of all silicon limitations implemented for HAL on STM32F1xx product.
(@) See ErrataSheet to know full silicon limitation list of your product.

(#) Workarounds Implemented inside I2C HAL Driver
(##) Wrong data read into data register (Polling and Interrupt mode)
(##) Start cannot be generated after a misplaced Stop
(##) Some software events must be managed before the current byte is being transferred:
Workaround: Use DMA in general, except when the Master is receiving a single byte.
For Interupt mode, I2C should have the highest priority in the application.
(##) Mismatch on the «Setup time for a repeated Start condition» timing parameter:
Workaround: Reduce the frequency down to 88 kHz or use the I2C Fast-mode if
supported by the slave.
(##) Data valid time (tVD;DAT) violated without the OVR flag being set:
Workaround: If the slave device allows it, use the clock stretching mechanism
by programming NoStretchMode = I2C_NOSTRETCH_DISABLE in HAL_I2C_Init.

Это я к тому, что если есть планы использовать I2C на этом камне, то стоит внимательно проштудировать errata.
Хм… Спасибо за предупреждение.
Переезд на HAL мне, возможно, предстоит в недалеком будущем.
Впечатляюще! Как же чудесно что есть те, кто любит оптимизировать и разбираться отчего так толсто, а не брать контроллер пожирнее! Если Вам интересно, года два назад оптимизировал библиотеку u8glib и переносил на STM32 добился результата около 7-8 мс на экран ssd1306 128х64. Если Вам это поможет то вот. Так же где-то еще валялась для ST7735 от adafruit… Если надо могу найти.
Интересно. Я поизучаю код.
переливание пикселей с голубого на белый это глюк камеры? или дисплей действительно двухцветный?
я предвзято отношусь к текстовым протоколам — сообщения же еще парсить нужно. Почему бы данные не гонять в бинарном виде? Да еще пакетами? Все равно их человек не читает. А бинарные пакеты могли бы значительно упростить обработку.
Имхо текстовые протоколы значительно облегчают отладку, сопровождение и поиск ошибок. Когда работаешь один — бинарный не такая беда. А когда получил в наследство от другого человека нечто, которое надо внимательно изучить от и до, чтобы понять в чем проблема, хочется выть.
Сейчас час разработчика стоит больше, чем частота процессора и кучка транзисторов в чипе.
разработка парсера может занять достаточное время, тогда как бинарный пакет парсить не нужно — он сразу превращается в структуру.

Я в какой то момент карьеры активно писал парсеры разных текстовых форматов. Написание парсера вручную дело крайне порочное — очень легко сделать оишбку. Если текст, который нужно парсить сложнее чем key=value, то однозначно нужно использовать парсерогенераторы на основе грамматик. Иначе баги ловить задолбешься. И опять приходим в выводу, что это overkill для мира микроконтроллеров.

А дампалку бинарного пакета в текстовый сделать вообще легко. Особенно если используется продвинутый отладчик типа visual studio или gdb где это можно сделать вообще скриптом отладчика

Снижение частоты не поможет экономить энергию. Энергию потребляют такты, а не частота. Когда контроллер не спит а молотит постоянно, то зависимость потребления от частоты есть, но если задействовать режим сна то разницы не будет. Да и особого эффекта на длительность работы это тоже не окажет — сам GPS-модуль в режиме навигации потребляет 35мА, а в режиме поиска спутников — до 70 или даже больше. то что ваш контроллер будет потреблять 20мА или 7мА разницы особой не добавит. Лучше сокращать и оптимизировать действия в самой программе — исключить двойную и/или ненужную работу, ненужное переливание из пустого в порожнее и т.д.
Ну и заранее вставить в девайс батарею порядка 3000-4000мА*ч и ваша оптимизация потребления превратится в экономию на спичках.

Снижение частоты не поможет экономить энергию. Энергию потребляют такты, а не частота

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

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

Вопрос потребления буду детально копать, когда закончу со всей логикой.

Табличка приведена для активного режима, и вполне справедлива. Потребление контроллера в статике — меньше микроампера, а в активной работе потребление идёт только за счет переключений вентилей, и соответственно чем быстрее они переключаются тем больше потребление.
Но фишка в чём… если использовать спящий режим, то количество переключений(== тактов ядра контроллера) необходимых для выполнения некой работы всегда одно и то же, хоть ты её будешь выполнять на скорости в 1кГц хоть на 100кгц — энергии будет потреблено на единицу работы одинаково, но время выполнения полезной работы ЗАВИСИТ. и пока ты укладываешься в выполнении работы за интервал меньше чем интервал пробуждения, среднее потребление контроллером на большом интервале времени будет одинаковым.

Хм, а как же таблички в даташите? там явно прописана зависимость милиампер от мегагерц

Это когда:
Когда контроллер не спит а молотит постоянно


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

Но в случае работы на более высокой частоте есть возможность избежать лагов при бОльших пиковых нагрузках.
Можно питание от GPS отлючать (с сохранением на VRTC) тогда старт будет сильно быстрее.
И добавить акселератор, что бы можно было движение определять в спячке и быстро включать GPS.
Например слегка измененный ODBC можно, я правда на кошках и собаках проверял, но люди ничем не лучше.
Что такое ODBC? Я такой термин только где то из области баз данных слышал…
Модуль BN-800 имеет встроенный трехосевой компас, SCL и SDA там от него, а не от GPS. Для квадрокоптеров сделано.

У самого M8N есть SPI, можно брать оттуда, если он разведен. Ну, и ещё есть проприетарный бинарный протокол UBX, который он тоже может кидать в UART.

Если будет слишком долго ловить спутники — проверь питание, там не должно быть шума и просадок.

А вообще, рекомендую сделать свою плату с модулем Ublox M8N, реализовав нормальную антенну и питание.
SPI не разведен.

Протокол UBX хочу посмотреть, но пока руки не дошли. NeoGPS сам умеет UBX чуток, но там совсем мало заимплеменчено. Но с другой стороны уже сделан задел для дальнейшей реализации.

Питание проверю. До развода платы, к сожалению, пока далековато.
Не знаю как в NMEA, а в UBX на половину полей есть флаг валидности. Поэтому не надо писать костылей вида «время есть, а дата 0» — достаточно проверить флаг. Так же он намного богаче по возможностям нежели текстовый. Рекомендую перейти на него.
Так я по флагам валидности и работаю. Только их для меня готовит NeoGPS. Типа если в последнем пакете были координаты — выставляем флаг, иначе не выставляем.

Но на UBX я обязательно посмотрю
Так в этом и фишка, данные то есть, но им не стоит доверять, о чём и сообщает чип.
Тогда я не понимаю в чем разница между «данных нет» и «данные есть, но вы их, пожалуйста, игнорируйте»
Очень просто, как в статистике: измерения есть, но они за полем допуска, поэтому пропускаем.
Для всяких разных GPS-игрушек есть же замечательный NavSpark.
100MHz 32bit SPARC, 212Kb RAM и программируется через Arduino IDE.
Есть вообще мини-версия полтора на полтора сантиметра.

У меня на нем антирадар собран, например.

Хотел бы призвать автора (если он живет в России, ну и к странам СНГ и Украине это тоже в значительной степени относится) к чрезвычайной осторожности. Вы вступили на скользкую дорожку конструирования устройства, которое при должном желании правоохранительных органов натягивается на статью 138.1 УК РФ и на ряд других неприятностей. Поэтому:


  1. Перед выносом устройства в любой степени готовности на полевые испытания (особенно в городе) придайте ему цивильный вид. Никаких шахид-девайсов с открытыми платами, разноцветными проводками, батарейками, примотанными изолентой и прочими характерными атрибутами. Чем меньше устройство может привлечь внимания, тем лучше. Увы, нарвался на этой неделе на досмотр с пристрастием в метро, лишился готового собранного и отлаженного макета и пакета с деталями, которые вез на работу, еще и помурыжили и думаю, не раз вызовут еще.
  2. Сразу дистанцируйтесь от понятия "GPS-логгер". Говорите, что делаете GPS-навигатор, велокомпьютер с функцией определения GPS координат, скорости и пройденного пути — все, что угодно, но не логгер. Соответствующая информация должна быть нанесена на "выездной" корпус макета, с ее учетом следует строить и вывод на экран.
  3. Обзаведитесь какой-нибудь бумагой с подписями и печатями на официальном бланке.

И еще — проверьте выбранный экран на деградацию. А то я сталкивался с тем, что они иногда за очень короткое время превращаются в тыкву.

Спасибо за предупреждение. Буду осторожен.

С экраном пока все в порядке.
Как-то повезло вам с stm32. Я также думал, что будет мощь, когда эту платку за 100р покупал. Вместо этого получил боль и страданье.( Я прогал из под Keil с CubeMX. В итоге 2 недели правил баги в сгенеренном коде и когда всё наконец заработало, я получил кучу непонятного мусорного кода и производительность в 3 раза меньше, чем давал вылизанный и компактный код для ATmega328.

Сейчас балуюсь с платкой на stm32f4, с ней уже профит есть. А с этой больше заморачиваться смысла не вижу.
Согласен с вами, но лишь отчасти. Камешек то действительно мощнее, и шустрее, и периферии больше, и памяти. Например, у меня сейчас уже 18кб памяти (из 20) распределено — потоков добавилось (а им стек нужен), очереди, семафоры, буффера для USB и MSD. Не знаю как свою поделку я бы в мегу уместил.

А вот HAL (он же STM32Cube) это печаль — такой рогатый и неудобный, и кода много, и потребление памяти большое, и архитектура некрасивая. Но похоже придется смириться ибо мейнстрим, есть поддержка и комьюнити. Ну и вкурить как это все работает времени уходит масса (и еще больше понять почему НЕ работает).

В общем, stay tuned, скоро новая статья будет, как раз на переезд на HAL
Only those users with full accounts are able to leave comments. Log in, please.