Gps логгер для автомобиля
Многофункциональный GPSLogger своими руками. Часть 1
Я являюсь обладателем замечательного устройства — GPS логгера Holux M-241. Штука весьма удобная и полезная в путешествиях. С помощью логгера я пишу GPS трек поездки, по которому потом можно посмотреть свой путь в деталях, а также привязать снятые фотографии к GPS координатам. А еще у него есть небольшой экран который показывает дополнительную информацию — часы, текущую скорость, высоту и направление, одометр и многое другое. Вот тут я когда то написал небольшой обзор.
При всех достоинствах железки я стал из нее вырастать. Мне не хватает нескольких небольших, но полезных плюшек: несколько одометров, показ вертикальной скорости, замер параметров участка пути. Вроде мелочи, но фирма Holux посчитала это недостаточно полезным для реализации в прошивке. Так же мне не нравятся кое какие параметры железяки, а некоторые вещи за 10 лет уже морально устарели…
В какой то момент я осознал, что могу сам сделать логгер с такими фичами как мне нужно. Благо все необходимые компоненты достаточно дешевы и доступны. Свою реализацию я начал делать на основе Arduino. Под катом дневник постройки, где я постарался расписать свои технические решения.
Определяемся с фичами
Многие спросят, зачем мне строить свой логгер, если наверняка есть что нибудь готовое у именитых производителей. Возможно. Если честно, особо не искал. Но наверняка там будет чего нибудь нехватать. В любом случае этот проект — фан для меня. Почему мы и не заняться постройкой устройства своей мечты?
Итак, за что же я ценю свой Holux M-241.
Но для меня работа от батареек это сущий геморрой. Приходится носить горсть батареек и кто его знает насколько они качественные (вдруг они лежали 5 лет на полке и уже саморазрядились). С аккумами гемор еще больше. У меня зарядник умеет только парами заряжать. Приходится разряжать аккумы, чтобы они были одной степени разряжености. В итоге никогда не помнишь где уже разряженные, а где еще нет.
За 6 лет использования логгера я всего пару раз оказывался в глуши без электричества. Как правило у меня хотя бы раз в сутки появляется доступ к розетке. В таком случае встроенный литиевый аккумулятор был бы гораздо удобнее. Ну а на крайний случай у меня павербанк есть.
К тому же не каждая программа умеет слопать формат слитых треков. Родная утилита очень убога. Благо есть BT747, которая может адекватно слить трек и сконвертировать в какой нибудь удобоваримый формат.
Всякое разное. Сам не использую, но вдруг кому полезно:
Выбираем железо
С требованиями более менее определились. Пора понять на чем это все можно реализовать. Главные компоненты у меня будут такие:
Под рукой как раз валялась россыпь разнокалиберных ардуинок, а также парочка stm32f103c8t6. Решил начать с AVR, которые я хорошо знаю на уровне контроллера/регистров/периферии. Если упрусь в ограничения — будет повод пощупать STM32.
Но для начала нужно определится с очень важным вопросом — питание компонентов. Мне показалось разумным запитать все от 3.3В: GPS и экран только на нем и умеют работать. Это так же родное напряжение для USB и SD. К тому же схему можно запитать от одной литиевой банки
Выбор пал на Arduino Pro Mini, которую можно найти в версии 8МГц/3.3В. Вот только USB у нее на борту не оказалось — пришлось использовать USB-UART переходник.
Первые шаги
Вначале проект создал в Arduino IDE. Но если честно, у меня язык не поворачивается называть это IDE — так, текстовый редактор с компилятором. Во всяком случае после Visual Studio, в которой я работаю последние 13 лет делать что либо серьезное в Arduino IDE без слез и матюков не получается.
Благо есть бесплатная Atmel Studio, в которой даже Visual Assist из коробки встроен. Программа умеет все что нужно, все привычно и на своих местах. Ну почти все (не нашел только как скомпилировать только один файл, например, чтобы синтаксис проверить)
Начал с экрана — это нужно чтобы отладить скелет прошивки, а потом наполнять ее функциональностью. Остановился на первой попавшейся библиотеке для SSD1306 от Adafruit. Она умеет все что нужно и предоставляет очень простой интерфейс.
Поиграл шрифтами. Оказалось один шрифт может занимать до 8кб (размер букв 24пт) — особо не разгуляешься в 32кб контроллере. Большие шрифты нужны, например, для вывода времени.
Шрифты в комплекте с библиотекой весьма корявые. Моноширинный шрифт оказался очень широким — строка “12:34:56” не влазит, Serif — все цифры разной жирности. Разве что стандартный шрифт 5×7 в библиотеке выглядит съедобно.
Оказалось, что эти шрифты были сконверчены из каких то опенсорсных ttf шрифтов, которые просто не оптимизированы под мелкие разрешения.
Пришлось рисовать свои шрифты. Точнее сначала выколупывать из готовых отдельные символы. Символ ‘:’ в таблице ASCII очень кстати находится сразу после цифр и можно выколупать одним блоком. Так же удобно, что можно делать шрифт не на все символы, а только на диапазон, например от 0x30 (‘0’) до 0x3a (‘:’). Т.о. из FreeSans18pt7b получилось сделать весьма компактный шрифт только на нужные символы. Пришлось правда чуток подхачить ширину, чтобы текст влезал на ширину экрана.
Оказалось, что шрифт 18пт на самом деле высотой 25 пикселей. Из-за этого он слегка налазит на другую надпись
Инвертированный дисплей, кстати, помогает понять где на самом деле находятся границы области рисования и как относительно этой границы лежит строка — дисплей имеет весьма большие рамки.
Долго гуглил готовые шрифты, но они не подходили или по размеру, или по форме, или по содержанию. К примеру в интернете валом шрифтов 8х12 (дампы знакогенераторов VGA карт). Но по факту эти шрифты являются 6х8, т.е. гуляет куча места — в случае такого маленького разрешения и размера как у меня это критично.
Пришлось таки рисовать свои шрифты, благо формат шрифтов у Adafruit библиотеки очень простой. Картинку готовил в Paint.net — просто рисовал буквы нужным шрифтом, потом чуток корректировал карандашом. Картинку сохранял как png, а затем отправлял в побыстряку написанный на коленке питоновский скрипт. Этот скрипт генерировал полуфабрикат кода, который уже точечно правил в IDE прямо в хекс кодах.
Например так выглядит процесс создания моноширинного шрифта 8х12 с маленькими межбуквенными и межстрочными интервалами. Каждый символ в итоге получился примерно 7х10, и по умолчанию занимал 10 байт. Можно было бы упаковать каждый символ в 8-9 байт (библиотека это позволяет), но я не стал заморачиваться. К тому же в таком виде можно редактировать отдельные пиксели прямо в коде.
Каркас
Оригинальное устройство предоставляет весьма простой и удобный интерфейс. Информация группируется по категориям, которые показываются от отдельных страничках (экранах). С помощью кнопки можно циклически переключаться между страничками, а второй кнопкой выбрать текущий пункт или выполнить действие которое указано в подписи под кнопкой. Такой подход мне кажется весьма удобным и не нужно ничего менять.
Мне нравится красота ООП, потому я сразу слепил небольшой интерфейсик, каждая страничка реализует интерфейс как ей требуется. Страничка знает как себя нарисовать и реализует реакцию на кнопки.
В зависимости от текущего экрана кнопки могут выполнять различные действия. Поэтому верхнюю часть экрана высотой в 8 пикселей я отвел на подписи для кнопок. Текст для подписей зависит от текущего экрана и возвращается виртуальными функциями getSelButtonText() и getOkButtonText(). Также в шапке будут еще отображаться служебные штуки типа уровня сигнала GPS и заряда батареи. Оставшиеся ¾ экрана доступны для полезной информации.
Как я уже сказал экранчики могут перелистываться, а значит где то должен быть список объектов для разных страниц. При чем не один — экраны могут быть вложенными, как подменю. Я даже завел класс ScreenManager, который должен был управлять этими списками, но потом я нашел решение проще.
Так каждый экран просто имеет указатель на следующий. Если скрин позволяет войти в подменю, то у него добавляется еще один указатель на скрин этого подменю
По умолчанию обработчик кнопки просто вызывает функцию смены экрана, передавая ей нужный указатель. Функция получилась тривиальной — она просто переключала указатель на текущий экран. Чтобы обеспечить вложенность экранов я сделал небольшой стек. Так что весь менеджер экранов у меня поместился в 25 строк и 4 маленькие функции.
Правда код наполнения этих структур выглядит не очень красиво, но пока лучше не придумал.
Идем дальше. В своей реализации интерфейса мне захотелось сделать что то наподобие message box’а — короткого сообщения, которое бы показывалось на секунду-другую, а потом исчезало. Например, если на экране с текущими координатами нажать кнопку POI (Point Of Interest), то помимо записи точки в трек было бы неплохо показать пользователю сообщение “Waypoint Saved” (в оригинальном устройстве просто на секунду показывается дополнительная иконка). Или при разряде батареи “взбодрить” пользователя соответствующим сообщением.
Поскольку данные с GPS будут приходить постоянно, то ни о каких блокирующих функциях речи быть не может. Поэтому пришлось изобрести простенькую стейт машину (конечный автомат), которая в функции loop() выбирала бы что делать — показывать текущий экран или мессадж бокс.
Также с помощью машины состояний удобно обрабатывать нажатия кнопок. Возможно, через прерывания было бы правильно, но так тоже неплохо получилось. Работает это так: если в состоянии IDLE была нажата кнопка — запомним время нажатия и переходим в состояние BUTTON_PRESSED. В этом состоянии ждем пока пользователь отпустит кнопку. Тут мы можем подсчитать длительность когда кнопка была нажата. Короткие срабатывания ( 1c) для специальных функций. Например, короткое нажатие запускает/приостанавливает одометр, длинное нажатие сбрасывает значение счетчика в 0.
Возможно и другие состояния добавятся. Так, например, в оригинальном логгере после переключения на очередную страничку значения на экране меняются часто, а через пару секунд реже — раз в секунду. Это можно сделать добавлением еще одного состояния.
Когда каркас был готов, я уже, было, начал подключать GPS. Но тут возникли нюансы, которые заставили меня отложить эту задачу.
Оптимизация прошивки
Прежде чем идти дальше мне нужно отвлечься на кое какие технические детали. Дело в том, что примерно в этом месте я начал бодаться с растущим потреблением памяти. Оказалось, что строка опрометчиво объявленная без модификатора PROGMEM на старте прошивки копируется в ОЗУ и занимает там место в течении всего времени выполнения.
В двух словах. На больших компах используется Фон Неймановская архитектура где код и данные располагаются в одном адресном пространстве. Т.е. данные как из ОЗУ так и из ПЗУ будут читаться одинаковым способом.
В микроконтроллерах, как правило, используется Гарвардская архитектура, где код и данные разделены. Т.о. приходится использовать различные функции для чтения памяти и флеша. С точки зрения языка C/C++ указатели выглядят одинаково, но при написании программы мы должны точно знать куда на какую именно память указывает наш указатель и вызывать соответствующие функции.
Благо разработчики библиотек уже, отчасти, позаботились об этом. Основной класс библиотеки дисплея — Adafruit_SSD1306 наследуется от класса Print из ардуиновской стандартной библиотеки.
Это предоставляет нам целую серию разных модификаций метода print — для печати строк, отдельных символов, чисел и чего то там еще. Так вот в нем есть 2 отдельные функции для печати строк:
Первая знает, что нужно печатать строку из флешки и посимвольно ее загружает. Вторая печатает символы из ОЗУ. По факту обе эти функции принимают указатель на строку, только из разных адресных пространств.
Я долго искал в коде ардуино этот самый __FlashStringHelper чтобы научиться вызывать нужную функцию print(). Оказалось дядьки поступили хитро: они просто объявили такой тип с помощью forward declaration (без объявления самого типа) и написали макрос, который кастил указатели на строки во флеше к типу __FlashStringHelper. Просто чтобы компилятор сам выбирал нужную перегруженную функцию
Это позволяет писать так:
Но не позволяет писать так
И, судя по всему, библиотека не предоставляет ничего, что бы можно было так делать. Я знаю, что нехорошо в своем коде использовать приватные штуки библиотек, но что мне было делать? Я нарисовал свой макрос, который делал то, что мне нужно.
Так функция рисования шапки стала выглядеть так:
Ну а раз я уж влез в низкоуровневые штуки прошивки, то решил глубже изучить как же там оно все внутри устроено.
Вообще, ребятам которые придумали Ардуино нужно поставить памятник. Они сделали простую и удобную платформу для прототипирования и поделок. Огромное количество народу с минимальными знаниями электроники и программирования смогли войти в мир Ардуино. Но все это гладко и красиво пока делаешь фигню типа моргалки светодиодами или считывания показаний термометра. Как только замахиваешься на что нибудь серьезное сразу приходится разбираться глубже чем хотелось с самого начала.
Так, после каждой добавленной библиотеки или даже класса я отмечал как быстро растет потребление памяти. К этому моменту у меня было занято более 14 кб из 32 кб флеша и 1300 байт ОЗУ (из 2к). Каждое неосторожное движение добавляло еще процентов 10 к уже используемому. А ведь я еще толком не подключил GPS и SD/FAT32 библиотеки, а самого функционала пока кот наплакал. Пришлось брать в руки шашку дизассемблер и изучать что же там компилятор такого наколбасил.
Я в тайне надеялся, что линкер выкидывает неиспользуемые функции. Но оказалось, что некоторые из них линковщик вставляет практически целиком. В прошивке я обнаружил функции рисования линий и некоторые другие из библиотеки работы с экраном, хотя в коде я их явно на тот момент не вызывал. Неявно они тоже вызываться не должны — зачем нужна функция рисования линии, если я только буквы из битмапок рисую? Более 5.2кб на ровном месте (и это не считая шрифтов).
Помимо библиотеки управления дисплеем я еще обнаружил:
Так же в коде я обнаружил:
Среди этого нашелся здоровенный массив со “сплешскрином” экрана — начальные значения буфера кадра. Теоретически если сделать экрану display() сразу после старта, то можно увидеть цветок и надпись Adafruit, но в моем случае тратить на это флеш память бессмысленно.
Что с этим делать? Пока не знаю. Будет зависеть от того как будет расти потребление дальше. По хорошему найденные косяки нужно нещадно чинить. По всей видимости мне придется втянуть к себе в проект все библиотеки явно а потом почекрыжишь их хорошенько. А еще возможно придется по другому переписать некоторые куски с целью оптимизировать память. Или перейти на более мощное железо. В любом случае теперь я знаю о проблеме и есть стратегия как его чинить.
UPDATE:
Немного продвинулся в эффективности использования ресурсов. Делаю апдейт к этой части, т.к. в следующей хочу сфокусироваться на совершенно других вещах.
В коментах наблюдается некоторое недоумение по поводу использования С++. В частности что ж это он такой плохой и vtable хранит в драгоценной RAM? И вообще, виртуальные функции, конструкторы и деструкторы — это ж накладные расходы. Зачем? Давайте разбираться!
Вот статистика по памяти на некотором этапе проекта
Program size: 15 458 bytes (used 50% of a 30 720 byte maximum) (2,45 secs)
Minimum Memory Usage: 1258 bytes (61% of a 2048 byte maximum)
Эксперимент №1 — переписываем на С.
Я выкинул классы, переписал все на таблицах с указателями на функции. Поскольку экраны на самом деле имеют всегда одинаковую структуру, то все члены данных стали обычными глобальными переменными.
Статистика после рефакторинга
Program size: 14 568 bytes (used 47% of a 30 720 byte maximum) (2,35 secs)
Minimum Memory Usage: 1176 bytes (57% of a 2048 byte maximum)
Итого. Выиграл 900 байт флеша и 80 байт ОЗУ. Что именно ушло из флеша не копал. 80 байт ОЗУ это как раз размер vtable’ов. Все остальные данные (члены классов) так или иначе остались.
Должен сказать, что спортировал я не все — мне просто хотелось увидеть общую картину, не особо тратя на это время. После рефакторинга я “потерял” вложенные скрины. С ними потребление было бы чуток больше.
Но что самое главное в этом эксперименте, так это то, что качество кода значительно ушудшилось. Код одного функционала стал размазаным по нескольким файлам. Для некоторых кусков данных перестал существовать «один владелец», одни модули стали лазить в память других. Код стал размашистым и некрасивым.
Эксперимет №2 — выжимаем байты из С++
Свои сишные эксперименты я откатил, решил все оставить классами. Только на этот раз экраны делать на статически распределенных объектах. Структура страничек экранов у меня фиксирована. Можно задать ее на этапе компиляции без использования new/delete.
Program size: 15 408 bytes (used 50% of a 30 720 byte maximum) (2,60 secs)
Minimum Memory Usage: 1273 bytes (62% of a 2048 byte maximum)
Потребление ОЗУ немножко выросло. Но это, на самом деле, к лучшему. Увеличение потребление ОЗУ объясняется перемещеним объектов из кучи в статически распределенную область памяти. Т.е. по факту объекты и раньше создавались, только это не шло в статистику. А теперь эти объекты учитываются явно.
Но вот ощутимо уменьшить потребление флеша не получилось. В коде все еще остались сами конструкторы, которые по прежнему вызываются на старте. Т.е. Компилятор не смог их “выполнить” заранее и поместить все значения в заранее распределенные области. А еще в коде по прежнему были деструкторы, хотя и ежу понятно, что объекты никогда удалятся не будут.
В попытке сэкономить хотя бы чутьчуть я удалил все деструкторы в иерархии, и в частности виртуальный деструктор в базовом классе. Идея была в том, что бы освободить пару байт в каждом vtable. И тут меня ждал сюрприз:
Program size: 14 704 bytes (used 48% of a 30 720 byte maximum) (2,94 secs)
Minimum Memory Usage: 1211 bytes (59% of a 2048 byte maximum)
Оказалось из vtable’ов поуходило не по одному указателю, а аж по 2. При чем оба на деструктор. Только один деструктор пустой (видимо для объектов на стеке), а другой с вызовом free, видимо для объектов на куче (-12 байт ОЗУ). Так же ушли переменные связаные с хипом (8 байт) и втейблы объектов, которые никогда и не создаются (Screen, ParentScreen — 40 байт)
Потребление флеша уменьшилось существенно — на 700 байт. Ушли не только сами деструкторы, но и реализации malloc/free/new/delete. 700 байт за пустой виртуальный деструктор! 700 байт, Карл!
Что бы не мотать туда-сюда, вот все цифры в одном месте
Итог: Потребление на С++ получилось почти таким же как и на С. Но при этом инкапсуляция, наследование и полиморфизм это сила. Я готов за это переплачивать некоторым увеличением потребления. Возможно я просто не умею красиво писать на С, но зачем, если я могу красиво писать на С++?
Послесловие
Изначально я хотел написать одну статью в конце работы над проектом. Но поскольку заметки по ходу работы накапливаются с большой скоростью, то статья грозится быть очень большой. Так что я решил разбить ее на несколько частей. В этой части я рассказал о подготовительных этапах: понимание чего же я вообще хочу, выбор платформы, реализация каркаса приложения.
В следующей части я планирую перейти уже к реализации основной функциональности — работу с GPS. Я уже столкнулся с парочкой интересных граблей, про которые хотел бы рассказать.
Я более 10 лет серьезно не программировал под микроконтроллеры. Оказалось, что я несколько избалован обилием ресурсов больших компов и мне тесновато в реалиях ATMega32. Поэтому пришлось продумать разные бекапные варианты, как то урезание функционала библиотек или редизайн приложения во имя эффективного использования памяти. Так же я не исключаю переход на более мощные контроллеры — ATMega64 или что нибудь из линейки STM32.
По стилистике статья получается что-то вроде журнала постройки. И я буду рад конструктивным комментариям — еще не поздно что либо поменять. Желающие могут присоединиться к моему проекту на гитхабе.
GPS возвращатели и GPS логгеры
GPS логгер или GPS компас или GPS возвращатель для грибника – как понять что это и как сделать выбор? Мы подготовили для вас статью, где все подробно изложили. Теперь вам станет гораздо проще сделать выбор.Читать дальше
Новое и интересное устройство G03 mini GPS Логгер, которое поможет вам не потеряться в незнакомом…
Новое и интересное устройство G03 mini GPS Логгер, которое поможет вам не потеряться в незнакомом…
Новое и интересное устройство G03 mini GPS Логгер, которое поможет вам не потеряться в незнакомом…
GPS логгер ManGo.Pro16 – это компактный прибор предназначен для фиксации и записи координат…
Новое и интересное устройство G03 mini GPS Логгер, которое поможет вам не потеряться в незнакомом…
GPS логгер легок в управлении, имеет всего лишь 3 кнопки и может отображать географические…
GPS логгер легок в управлении, имеет всего лишь 3 кнопки и может отображать географические…
Супер мини GPS логгер
Что такое GPS возвращатель и для чего он нужен?
Что такое GPS логгер и для чего он нужен?
Принцип работы устройств.
Любой GPS логгер и GPS возвращатель работает с помощью спутников GPS, так что можете не сомневаться – с таким помощником вы никогда не заблудитесь. Устройства работают по всему миру. В зависимости от модели, устройства питаются или от встроенного аккумулятора, который можно заряжать с помощью USB кабеля или от батареек, которые вы можете заменить в любой момент.
Сегодня мы получаем много положительных отзывов от владельцев этих устройств и можем смело их рекомендовать. Купить от самых дешевых до дорогих возвращателей для грибника можно в нашем интернет магазине, ведь при всей своей практической ценности данное устройство действительно очень доступно.
Сравнение двух GPS Data Logger’ов
Многие из нас любят походы. Мы привозим тонны фотографий, потом долгими вечерами ковыряемся, пытаясь выбрать лучшие, чтобы было что показать друзьям и знакомым. Но некоторым этого мало. Хочется порой, знаете ли, погрузиться в воспоминания ещё немного полнее. Вот бы записать маршрут и потом посмотреть его на карте или в Гуглобусе!
Первое, что приходит на ум — навигатор. Не будем касаться конкретной реализации, это может быть и специализированное устройство, и приложение на смартфоне. Однако каждый походник знает: батарейки садятся в самый неподходящий момент (а более серьёзные, отламывая ручку у зубной щётки, вспомнят ещё и о весе рюкзака). И не всегда есть возможность эти самые батарейки поменять или зарядить. Да и наличие карты не всегда нужно, хочется просто знать пройденный путь.
Впредь решено было «писать» все походы и я приступил к поиску устройства.
Для начала я определил критерии необходимого устройства:
— максимальная компактность;
— только логирование, без навигации;
— максимальное время автономной работы;
— установка точки POI кнопкой (по возможности, но обязательно).
Были обшарены всемирный рынок Ebay и «электронный „Черкизон“ AliExpress. На DealExtreme я даже не полез, потому как хочется утсройства надёжного, желательно от известного производителя. На Ebay’е доминируют устройства слежения за авто/детьми/питомцами с возможностью получения текущего местоположения бъекта по GSM-каналу. AliExpress „продвигает“ видеорегистраторы. Впрочем, устройства из конечного набора, к которому я пришёл, встретить можно и там и там. Но наиболее полные „каталоги“ с более-менее вменяемыми описаниями расположены здесь и здесь.
Как ни странно, но толковой информации по подобного рода устройствам довольно мало, хотя оказалось, что очень многих привлекает идея привязки фотографий к координатам места съёмки. В сети полоно описаний подобных сервисов, даже на Хабре этот вопрос обсуждался. Но вот детального рассмотрения функционала железок я почти не нашёл.
Вобщем, после долгого копания по сайтам производителей, по Youtube в частности и интернету в целом, лично мой выбор пал на следующие устройства:
1. Holux M-241c
2. Holux M-1200E
3. GiSTEQ PhotoTrackr Mini (DPL900)
4. Columbus V-990
Номер 1 „выбыл из борьбы“ по вполне прозаичной причине: негде купить. Есть модель без индекса „c“, с передачей координат по Bluetooth, но мне он не нужен совершенно, только отъедает ресурс батарейки, да и вычитал слухи, что в последнее время качество устройств стало совсем не то и многие жалуются на большие погрешности в определении местоположения. К тому же, сколько я не искал, но так и не понял, можно ли ставить точку POI на этом устройстве. Ну и чип MTK (MediaTek) первого поколения, по отзывам, довольно медлителен и прохорлив в плане электропитания (по крайней мере по сравнению с чипами поколения второго).
Очень жаль! Ведь прекрасная игрушка, посудите сами: работает от AA-батарейки, есть дисплей с указанием времени, полученного со спутника (один снимок и ты точно знаешь смещение времени своей камеры относительно Logger’а).
Номер 2 тоже найти в продаже не удалось (повторю, искал в „приличных“ магазинах с курьерской доставкой).
Номер 3 на официальном сайте больше не продаётся. Удалось найти его модернизированный вариант на более современном чипе SiRF Atlas IV — Canmore GT-730FL-S.
В конечном итоге были приобретены два устройства: Columbus V-990 и Canmore GT-730FL-S, в чём немало помогла эта таблица сравнений GPS-чипов.
Устройство, безусловно, красиво. Задняя полированная металлическая поверхность и бархатный чехольчик делают его похожим на зажигалку. Зарядка происходит с помощью разъёма mini-USB И это, увы, единственное его предназначение, получить данные по нему невозможно (хотя контакты D+ и D- с разъёма куда-то уходят). „Сердцем“ устройства служит микроконтроллер PIC 18-й серии.
К плюсам можно отнести GPS-чип производства MediaTek второго поколения (MTK 3329), способный работать с 66-ю спутниками (?!), датчик движения (который отключает запись трека в состоянии покоя), батарею на 1000 мА/ч, возможность не только ставить метки, но и делать к ним голосовые подсказки, а также возможность установить карту памяти до 2 Гб, что даёт нам просто невероятный объем места для записи треков. Правда, без карты памяти устройство не работает, точнее работает, но трек писать некуда. А разобрав устройство мы увидим, что ужасающее качество записи голосовых меток обусловлено тем, что отверстие в корпусе и микрофон на плате далеки друг от друга, как „А“ от „Я“: 
Кстати, устройство можно перевести в так называемый „Spy mode“, в этом режиме устройство просыпается через определённый промежуток времени (задаётся в настройках), сохраняет свои координаты и опять благополучно „засыпает“ до следующего раза. Правда, сам я этот режим не проверял, так как интереса не возникало.
Из минусов следует отметить следующее:
— индикация „слепнет“ на дневном свету, становясь практически нечитаемой;
— для установки точки POI с голосовой меткой используется отдельная кнопка, она довольно мелкая, расположена сбоку и с маленьким ходом;
— при записи голосовой метки установка точки в логе происходит после отпускания кнопки (то есть по окончании записи), это несущественно при ходьбе, но если двигаешься быстро, то за это время можно оказаться далеко от необходимого для пометки места;
— если передержать кнопку установки POI дольше необходимого, то начнётся запись нового трека.
Внешне этот логер выглядит как толстая флешка. Материал корпуса — пластик. В целом всё довольно прилично, разве что нет такого лоска, как у Columbus’а. Устройство заряжается по USB, подключаясь как обычная флешка. Производитель указывает ёмкость батареи в 450 мА/ч.
Со спутниками работает чип SiRF Atlas IV, заявлена поддержка 48-и спутников (GPS и Galileo).
Для извлечения данных необходимо установить драйвер виртуального COM-порта, который эмулирует мкроконтроллер STM32, тоже „сердце“ этого устройства. Данные (треки) извлекаются либо программой от производителя (CanWay), либо программой от „оригинала“ (GiSTEQ PhotoTrackr Mini (DPL900)) — PhotoTrackr. Впрочем, что-то читает и gpsbabel, но точных параметров запуска я не нашёл (да и не искал особо, если честно).
Приведу несколько фотографий внутренностей.
Как видите, patch-антенна у Columbus’а по площади несколько больше, чем у конкурента. Возможно, это обусловлено тем, что у MediaTek GPS-чип совмещён с антенной, тогда как у SiRF это два отдельных устройства. Впрочем, я могу и ошибаться и если так, то поправьте меня в комментариях.
Пытливый глаз заметит, что контакты D+ и D- разъёма mini-USB куда-то разведены, но практического толку, к сожалению, всё равно нет.
Левый нижний угол фото, квадрат
5 мм — это и есть GPS-чип SiRF Atlas IV.
И ещё пара фотографий для оценки размеров:
Тпеперь поговорим о практической стороне использования и сразу в сравнительном ключе.
Columbus ловит спутники за 40 секунд, Canmore — порядка трёх-пяти минут. Columbus увереннее „держит трек“, но у него иногда возникают проблемы с некорректным определением высоты (пики вверх, в основном в моменты установки соединения со спутником). Оба устройства не лишены проблем с появлением „аномальных“ точек (резкий выброс в сторону), впрочем, нечастые и впечатления в целом не портят. Есть разница с определением высот между этими двумя устройствами:
Синий — Canmore, красный — Columbus. Заметна разница в определении высоты и скачки высоты у чипа MTKII.
К сожалению, сказать большего об устройстве Canmore GT-730FL-S я не могу. Мне устройство попалось с браком (аккумулятор не заряжается), посему использую только те данные, которые успел накопить.
Прочесть данные с карты и преобразовать их не составляет никакого труда практически в любой современной ОС и в этом ещё один огромный плюс Columbus’у.
Поскольку я „виндузятник“, то проблем с установкой драйвера и чтением данных с Canmore у меня не возникло, но как быть приверженцам других ОС я не знаю. Если знаете Вы, то напишите в комментариях. Уверен, что многим решение пригодится.
Вот, кажется и всё. В целом оба устройства мне понравились но, ни одно из них не произвело впечатление идеального.
Для интересующихся выкладываю два демо-трека и пример голосовой метки Columbus’а, по одному с каждого устройства. Треки я немного скорректировал (отрезал лишнее) так, чтобы они начинали и заканчивались в одно и то же время. Я вышел из метро (с работающими логгерами в наплечной сумке), дошёл до остановки, подождал автобуса, доехал до работы, вышел и дошёл пешком до проходной. Думаю, по этим трекам каждый желающий сам сможет оценить для себя работу того или иного GPS-чипа.