- gps.conf для всех, или как ускорить работу GPS на Android
- Телефон как GPS-приемник для другого телефона или планшета на Android (Wi-Fi)
- Настройка Wi-Fi между телефонами
- Настройка телефона-передатчика
- Настройка телефона-приемника
- Устранение обрывов связи
- Передача GPS данных(NMEA) с Android на Windows
- Введение
- Что же надо было сделать?
- TCP/IP соединение
- NMEA данные с Android, получение и отправка
- NMEA данные на ПК
- Заключение
- GPS-монитор под андроид «KidsTrack»
- Сюрпризы управления питанием
- Сюрпризы GPS
- Прочие сюрпризы
gps.conf для всех, или как ускорить работу GPS на Android
«Фантастика!» подумал я и без промедления перешел по ссылке. По сравнению с первым постом в этот раз предлагались еще более конкретные действия, а именно заменить содержимое файла gps.conf (его можно найти по пути /etc/gps.conf, должны быть root-права) на следующие настройки:
NTP_SERVER=ua.pool.ntp.org
NTP_SERVER=0.ua.pool.ntp.org
NTP_SERVER=1.ua.pool.ntp.org
NTP_SERVER=2.ua.pool.ntp.org
NTP_SERVER=3.ua.pool.ntp.org
NTP_SERVER=europe.pool.ntp.org
NTP_SERVER=0.europe.pool.ntp.org
NTP_SERVER=1.europe.pool.ntp.org
NTP_SERVER=2.europe.pool.ntp.org
NTP_SERVER=3.europe.pool.ntp.org
XTRA_SERVER_1=/data/xtra.bin
AGPS=/data/xtra.bin
AGPS=http://xtra1.gpsonextra.net/xtra.bin
XTRA_SERVER_1=http://xtra1.gpsonextra.net/xtra.bin
XTRA_SERVER_2=http://xtra2.gpsonextra.net/xtra.bin
XTRA_SERVER_3=http://xtra3.gpsonextra.net/xtra.bin
DEFAULT_AGPS_ENABLE=TRUE
DEFAULT_USER_PLANE=TRUE
REPORT_POSITION_USE_SUPL_REFLOC=1
QOS_ACCURACY=50
QOS_TIME_OUT_STANDALONE=60
QOS_TIME_OUT_agps=89
QosHorizontalThreshold=1000
QosVerticalThreshold=500
AssistMethodType=1
AgpsUse=1
AgpsMtConf=0
AgpsMtResponseType=1
AgpsServerType=1
AgpsServerIp=3232235555
INTERMEDIATE_POS=1
C2K_HOST=c2k.pde.com
C2K_PORT=1234
SUPL_HOST=FQDN
SUPL_HOST=lbs.geo.t-mobile.com
SUPL_HOST=supl.google.com
SUPL_PORT=7276
SUPL_SECURE_PORT=7275
SUPL_NO_SECURE_PORT=3425
SUPL_TLS_HOST=FQDN
SUPL_TLS_CERT=/etc/SuplRootCert
ACCURACY_THRES=5000
CURRENT_CARRIER=common
Эти настройки рассчитаны на жителей Украины, но для жителей России их очень легко адаптировать заменив ua.pool на ru.pool.
Далее нужно перезагрузить Android, а затем запустить программу для работы с GPS и наслаждаться стабильным сигналом.
От себя могу добавить, что я пользуюсь приложением GPS Status и после перезагрузки при первом запуске приложения я сделал сброс данных кэша: в программе вызываем меню, далее выбираем Tools, там Manage A-GPS state и жмем Reset, а затем Download.
Снимаю шляпу перед автором оригинального поста, уважаемым mechanicuss. Его совет помог не только мне, и может помочь еще многим страдающим.
На этом все. Всем чистого неба и стабильного сигнала из космоса.
Источник
Телефон как GPS-приемник для другого телефона или планшета на Android (Wi-Fi)
Раньше на сайте уже публиковались статьи, как настроить соединение по Bluetooth между двумя Android-устройствами или между Android-устройством и компьютером с Windows для передачи данных GPS. Для связи использовалось приложение GPS over BT. В настоящей статье показано, как можно настроить подобную передачу GPS-данных по Wi-Fi с помощью приложения GPS Tether от разработчиков Lucky Always.
Оно полезно для тех, у кого нет или не получается настроить связь по Bluetooth (GPS Tether наряду с Wi-Fi поддерживает Bluetooth-соединение). К тому же хочется отметить, что передача данных по Wi-Fi происходит быстрее и, благодаря этому, данные о местоположении обновляются чаще.
Существует несколько приложений для передачи данных GPS по Wi-Fi, как платных, так и бесплатных. На наш взгляд, наиболее простым в настройке и использовании показалось именно приложение GPS Tether. К тому же оно бесплатное, единственное, разработчики заявляют, что оно не работает на планшетах Amazon Fire с заводской прошивкой. В описании также упоминается, что приложение должно работать на Android 4.2 (Jelly Bean) и выше.
Настройка Wi-Fi между телефонами
Перед использованием приложения GPS Tether необходимо настроить Wi-Fi сеть между устройствами. Зайдите в настройки сетей Wi-Fi телефона-передатчика, сконфигурируйте и запустите беспроводную точку доступа. Данная функция присутствует во всех современных Android-телефонах. Укажите имя и пароль точки доступа, сохраните и активируйте ее.
Подключитесь на телефоне-приемнике к созданной Wi-Fi сети, используя установленный ранее пароль.
Настройка телефона-передатчика
Включите функцию GPS на телефоне-передатчике, откройте приложение GPS Tether и на вкладке Sharing (Раздача) нажмите на иконку WiFi Hotspot Sharing (Раздача через точку доступа Wi-Fi).
Настройка телефона-приемника
Откройте GPS Tether на телефоне-приемнике, переключитесь на вкладку Receiving (Получение) и нажмите на иконку «WiFi Hotspot Receiver» (Приемник точки доступа Wi-Fi). Приложение выдаст предупреждение, что нужно включить функцию фиктивных местоположений (Mock Locations) в настройках Android. Нажмите на кнопку «DEVELOPER SETTINGS», чтобы сразу попасть в нужный раздел настроек из приложения.
Найдите в списке пункт «Выбрать приложение для фиктивных местоположений», откройте его и в списке доступных приложений выберите GPS Tether.
Нажмите на кнопку назад на телефоне для возврата в приложение и снова нажмите на иконку «Wi-Fi Hotspot Receiver», чтобы она стала цветной.
Запустите любое удобное для Вас приложение навигации и используйте его как обычно. Настроенная таким образом навигация тестировалась в некоторых популярных приложениях для Android:
- Google Maps – работает;
- Яндекс.Карты – работает;
- Waze – не работает.
Устранение обрывов связи
Если связь между телефонами периодически теряется, проверьте настройки беспроводной сети на предмет опции автоматического отключения Wi-Fi в спящем режиме устройства.
Также запретите системе Android закрывать на обоих телефонах приложение GPS Tether, работающее в фоновом режиме. На телефонах Xiaomi это можно сделать через просмотр последних открытых приложений (короткое нажатие аппаратной кнопки меню).
Нажатие на замок рядом с приложением предотвращает его закрытие системой Android в спящем режиме телефона.
Источник
Передача GPS данных(NMEA) с Android на Windows
Введение
Под windows имеются приложения, которые нуждаются в NMEA сообщениях от GPS устройства, передаваемых по COM порту. Под Android’ом же есть возможность с помощью API генерировать подобные сообщения. В целом была идея доставить данные на виртуальный COM порт с Android’a. Если вам интересно как это удалось реализовать, прошу под кат.
Что же надо было сделать?
Реализовать требовалось следующее:
- Настроить TCP/IP соединение между устройством и ПК
- Получить NMEA данные на Android’e
- Передать их по UDP протоколу на компьютер
- Принять на компьютере UDP пакет и отправить его на COM порт
TCP/IP соединение
Соединение было организовано с помощью Revers wired tether, для этого на телефоне были, получены права root и с помощью программки android-wired-tether было создано TCP/IP подключение к ПК. Почему же не по WiFi? Да, такая возможность есть, можно на windows 7 создать виртуальный WiFi адаптер и к нему уже подключится с Android’a. Но мой адаптер Atheros AR5B95 через 5 минут подключения уводил систему в синий экран, поэтому и было решено создать подключение все же по проводу + по нему еще и зарядка устройства происходит, что не мало важно при работе GPS(оно прожорливо в плане питания).
NMEA данные с Android, получение и отправка
Данные на Android получались следующим кодом:
//NMEA listener
LocationManager LM = (LocationManager) getSystemService(Context.LOCATION_SERVICE); ((LocationManager)getSystemService(Context.LOCATION_SERVICE)).requestLocationUpdates(LocationManager.GPS_PROVIDER,0,0,new LocationListener() <
@Override
public void onLocationChanged(Location loc) <>
@Override
public void onProviderDisabled(String provider) <>
@Override
public void onProviderEnabled(String provider) <>
@Override
public void onStatusChanged(String provider, int status,Bundle extras) <> >);
LM.addNmeaListener(new GpsStatus.NmeaListener() <
public void onNmeaReceived(long timestamp, String nmea) <
SendNmea2UDP(nmea);
>>);
И передавались в метод SendNmea2UDP который отправлял их на UDP порт ПК:
public void SendNmea2UDP(String nmeastring)
<
message = nmeastring;
msg_length=message.length();
messageB = message.getBytes();
nmeapacket = new DatagramPacket(messageB, msg_length,local,server_port);
try
<
socket.send(nmeapacket);
>
catch(Exception e) <>
>
NMEA данные на ПК
Для получения данных и отправку их на COM порт со стороны компьютеры, было на C# написано простенькое приложение.
С помощью программки Virtual Serial Ports Emulator, было создано два связанных виртуальных COM порта, на один из которых приходили данные от программы на ПК, а на втором виртуальном COM порту их уже можно принимать любым положением, которое в них нуждается.
Заключение
Если кому интересен исходный код программ, то он тут на Android и Windows
В итоге можно запустить программу, которая понимает NMEA данные с COM порта:
В низу справа программка, которая принимает UDP с Android’a и передает NMEA далее на виртуальный COM порт. Программка upd2com отправляет на 3 порт, а к примеру в данном случае SASПланета принимает с 4 порта (организовано это с помощью VSPE). Красненькая точка это где я сейчас тестирую все это.
Спасибо за внимание, надеюсь, статья была вам интересна.
Источник
GPS-монитор под андроид «KidsTrack»
Задача: наступает лето, дети все больше времени проводят где-то на улице, и я бы хотел знать, где они находятся. Идеальный вариант — я просто даю им с собой старый андроидный телефон, и затем наблюдаю за ними по карте на большом домашнем мониторе.
В этой статье я расскажу, почему и как я написал свое первое приложение для Андроид с функциями GPS «KidsTrack», и какие открытия при этом сделал. Статья будет полезна тем, кто недавно начал программировать под Android.
Поиски на Google Play выдали мне сотни различных приложений с функциями GPS-мониторов. Я уж начал их было перебирать, но примерно на 2-м десятке я осознал, что затраты времени на выбор могут оказаться вполне сравнимыми с затратами времени на разработку. Ведь мои функциональные требования очень просты:
- приложение должно периодически отправлять анонимные координаты на сервер,
- сервер должен показывать карту с маркером в соответствующем месте.
Это все!
Есть еще требования, которые не связаны с функциональностью, но которые не менее важны:
- отсутствие необходимости регистрации, и привязки аккаунтов
- бесплатность
- отсутствие рекламы
- отсутствие ненужных функций, которые уже есть или в телефоне, или в других приложениях, типа обмена сообщениями, тревожных кнопок, уведомлений, стираний данных, блокировок телефона, чата, и т.п.
И да, координаты будут хранится на сервере, который не бесплатен. Но хостинг сейчас стоит такие копейки, что я считаю неправильным брать с людей деньги за хранение пары чисел (или даже нескольких килобайт).
Одним словом, попробовав несколько приложений из Google Play, я решил написать трекер сам.
Далее, все тривиально: установил Android Studio, нарисовал единственный экран с 3-мя кнопками, написал, как мне казалось, сервис, отладил все в эмуляторе, затем в USB-дебаггере, вроде все заработало.
Но как только попробовал запустить на физическом устройстве — начались сюрпризы. О некоторых из них я хотел бы рассказать.
Сюрпризы управления питанием
Реальные андроид-устройства стремятся отключить себе питание при любой возможности. Постоянно получают питание лишь весьма примитивные системные часы (модуль мобильной связи здесь он не рассматривается). В часах есть регистр(ы), куда посредством AlarmManager можно записать время следующей пробудки процессора телефона. Если процессор не разбудят часы, то он так и будет продолжать спать ничего не делая. Сделано это по простой причине: включенный процессор разрядит батарею за час. Поэтому если надо, чтобы сервис что-то делал раз в минуту, то приемы десктопного программирования вроде Thread.sleep(60000) не подойдут, а вместо этого надо пользоваться AlarmManager, примерно вот так:
В этом примере мы программируем AlarmManager разбудить телефон через 1 минуту, и отправить интент START_ALARM всем приложениям, кто на него подписан.
Прием интентов во всех учебниках осуществляется объектом BroadcastReceiver, однако если нам нужно, чтобы:
- телефон пробуждался из глубокого сна
- запускал наш сервис,
- не засыпал до завершения работы
то BroadcastReceiver не подойдет, и вместо него надо использовать WakefulBroadcastReceiver — этот объект гарантировано не допустит впадения телефона в сон до тех пор, пока не будет вызван метод completeWakefulIntent. Во всяком случае у меня так и не получилось заставить BroadcastReceiver работать надежно на физическом устройстве.
Если ваш сервис теоретически может выходить в интернет через WiFi, то вам необходимо позаботится, чтобы у WiFi-модуля во время соединения тоже было включено питание, так как оно у него отдельное. Если этого не сделать, то бывает трудно понять почему приложение не работает на физическом устройстве: ведь при отладке на эмуляторе или устройстве, подключенном к дебаггеру через USB, питание модуля WiFi не выключается, и все отлично работает. Запретить отключать питание WiFi можно так:
Сюрпризы GPS
В первой версии приложения я сделал определение координат устройства только с использованием провайдера «GPS». И очень было мне удивительно наблюдать на сервере, как более 90% устройств не смогли определить координаты и присылали нули.
Как оказалось, GPS – довольно капризная технология с множеством ограничений, низкой скоростью и непредсказуемой точностью. При использовании традиционной GPS сенсор приемника должен получить данные обо всех GPS-спутниках (а их более 2х десятков), среди всех них выбрать наиболее подходящие, и уже по ним вычислять координаты. Получение данных и перебор могут занимать 5 минут и более, поэтому первый «холодный» старт GPS всегда самый медленный.
Если GPS-приемник имеет часы и помнит прошлые координаты и положения спутников, то он может использовать эти данные для определения тех спутников, к которым можно привязаться в данный момент. Поэтому повторный запуск GPS обычно происходит намного быстрее.
В современных смартфонах первоначальное грубое определение координат может осуществляться по близлежащим передающим сотовым вышкам, что так же позволяет ускорить «холодный старт» GPS. Для использования этого способа требуется разрешение на использование провайдера «network» в Manifest-е, так для определения я координат вышек может использоваться интернет.
Еще одна функция провайдера «network» — определять координаты по видимым WiFi — сетям. Определение осуществляется путем поиска координат видимых в данный момент сетей по их именам и MAC-адресам на серверах Google через интернет. Разумеется, в фоновом режиме и без лишних уведомлений идет и обратный трафик: телефон, когда определил свои координаты по GPS, может по-тихому послать данные об окружающих его WiFi-сетях на серверы Google, чтобы таким образом поддерживать актуальное состояние базы WiFi-сетей. Грустные размышления о потенциальной власти Google над владельцами Андроидов и WiFi-сетей оставим за рамками этой статьи…
Прояснив все эти нюансы я в авральном порядке подправил приложение, чтобы оно использовало не только провайдера «GPS» но и «network». После этого типичная последовательность вызовов метода onLocationChanged стала выглядеть так:
Я все-таки очень хотел задействовать GPS, так как обычно это самый точный способ, поэтому я установил время ожидания сигнала от GPS-сенсора 30 секундам, а если это первый пуск — 2-м минутам. И если GPS-сенсор так и не сработал, то используются координаты от провайдера «network». После этого изменения устройства стали присылать на сервер нормальные, ненулевые координаты.
Точность GPS также оказалась весьма условной. Например нередко точность координат, получаемых с сенсора неподвижного лежащего устройства может выглядеть так:
Из этих данных ясно, что GPS хорош для нахождения зданий или других больших объектов, но найти человека в толпе, или телефон в сугробе будет непросто.
Отдельно стоит упомянуть питание GPS. Модуль GPS весьма прожорлив, поэтому в учебниках рекомендуют при вызове requestLocationUpdates не устанавливать слишком короткие параметры минимального интервала по времени и по расстоянию. Но в моих опытах с 3-мя различными физическими устройствами оказалось, что постоянно включенный модуль GPS садит батарею одинаково при различных параметрах. Потом уже я нашел где-то упоминание, что эти параметры влияют только на частоту вызова метода onLocationChanged, но не обязательно на энергопотребление самого сенсора.
Прочие сюрпризы
Google Play: Первая версия пролежала на Google Play два дня, после чего была заменена новой, с исправленным алгоритмом определения координат. Несмотря на то, что это произошло уже две недели назад, я на сервере продолжаю видеть, что очень часто продолжают происходить активации старой версии. Я уже и добавил сообщение о необходимости обновления на веб-странице мониторинга, но это не всегда помогает. Непонятно откуда вообще люди берут старую версию. Я не знаю чем это объяснить.
Пользователи: Почти треть пользователей, установивших приложение, никогда не открывала страницу, на которой устройство можно мониторить. Без страницы мониторинга приложение бесполезно, поэтому объяснить это феномен я тоже не могу.
Яндекс.Карты: Страница мониторинга изначально была реализована с использованием API Яндекс.Карт, так как там не требуется ID, и нет ограничений на количество загрузок карты в день. Но оказалось, что на слабых устройствах Яндекс.Карты или тормозят, или вообще не открываются. Пришлось эту страничку делать в 2-х вариантах: Яндекс.Карты для настольных компьютеров, и Google Maps для слабых мобильных устройств. Google Maps оказались существенно быстрее.
Источник