Как получить координаты из потока данных GNSS?

Нужно написать приложение для Андроид, рисующее на экране одним цветом точки места,
получаемые от внутреннего GPS смартфона, и другим цветом вариации места, получаемые
через интернет от NTRIP станции (GNSS Data stream).

Вопрос: как из потока данных извлечь широту и долготу?

Сейчас посылаю HTTP запрос:

GET /BRUX0 HTTP/1.0\r\n
User-Agent: NTRIP GNSSInternetRadio/1.2.0\r\n
Accept: */*\r\n
Connection: close\r\n
Authorization: Basic " + Base64.encodeToString("MyName:MyPassword".getBytes(), 4) +
"\r\n"
\r\n

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

 

Читайте описание протоколов RTCM 3.x
Вообще там координат быть не должно, кроме фиксированных координат базовой станции. Ваша затея непонятна.

 

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

 

CMR это проприетарный формат Тримбла. Из скриншота в первом сообщени, поиск по идентификатору станции выдал

Код:

STR;BRUX0;Brussels;RTCM 3.1;1004(1),1006(10),1008(10),1012(1),1019(300),1020(300),1033(10);2;GPS+GLO;EUREF;BEL;50.47;04.21;0;0;SEPT POLARX4TR;none;B;N;1300;ROB

Вам нужно читать описание протокола RTCM 3.1, номера сообщений перечислены выше; емнип в скобках указан период передачи сообщений в секундах.

Если лицензия позволяет, можно посмотреть исходники RTKLib там всё это реализовано.
http://gpspp.sakura.ne.jp/rtklib/rtklib.htm исходники в архиве, также у него есть репозиторий на GitHub

 

Да, Вы правы, спасибо! Trimble тут не поможет. По Вашему совету нащёл похоже то что нужно (в приложении). Наконец-то вижу формат заголовка сообщения и идентификатор заголовка (0x66).

 

Что-то у вас совсем "В огороде бузина, а в Киеве дядька!"
Как записав "... что-нибудь из потока в ASCII файл..." перейти к наблюдениям "... за вариациями электронной концентрации в ионосфере ..."?
Как???
Либо ваши "теоретики" совсем не врубаются что есть TEC и мерцание ионосферы и ставят неразумную задачу.

 

Что с этим будут делать теоретики я толком не знаю, слышал только что-то про TEC. Для начала надо разобрать поток, дальше можно что-то рисовать и писать в файл. Пока вижу что в RTCM 2.0 идентификатор заголовка (первый байт) 0x66, а в RTCM 3.1 вроде бы 0xD3. В потоке полно 0x66, а вот 0xD3 что-то не видно. В приложении док с описанием формата RTCM 3.1, возможно кому-то пригодится.

 

По вашим отрывочным данным скорее всего ваши "теоретики" хотят получить от вас конвертер из потока сообщений в формате RTCM v.3xx от неких постоянно действующих станций файлы с сырыми измерениями (и это совсем НЕ координаты) в формате RINEX, которые можно пользовать для оценки TEC и мерцаний.
Но ведь уже есть готовое для этого железо - чего упираться-то!
NovAtel GPStation6
Вы реально хотите велосипед изобретать?

 

Да, Вы чётко сформулировали проблему и наверняка предлагаете лучшее решение, спасибо! Я покажу это начальству и сообщу их ответ, если это интересно. Мне как программисту интересно самому разобрать поток. Приходилось на бинарном уровне делать связь с серийным и параллельным и USB портами, парсить NMEA протокол, а вот разобрать RTCM v.3xx пока не получается.

 

VALV
Посмотрите в аттаче описание формата. Я помню на форуме уже много раз выкладывали в т.ч. на русском языке, но не могу найти. Учтите между RTCM 2 и RTCM 3 практически нет ничего общего. Когда я декодировал RTCM 2 помню приходилось делать конверсию MSB<->LSB. Про новый формат ещё не смотрел.

(added)
Описание "обертки" сообщений и контрольной суммы в главе 4 "Transport Layer"

 

Спасибо большое! Это - именно то что нужно. То что в потоке на вскидку не видно стартового байта заголовка 0xD3, возможно как раз связано с MSB<->LSB. Буду пробовать.

 

Благодаря советам chnav что-то начало прорисовываться (см. приложение).

Для GNSS4geo: показал Ваш комментарий начальству. Прибор NovAtel GPStation6 их очень заинтересовал. Ответ примерно такой:
1. Для нашего отделения академического института это слишком дорогой прибор.
2. В приборе данные получаются так или иначе обработанными, а нужны сырые данные.

Спасибо за помощь!

 

1. Крутая вещь очевидно прилично стоит ( и "слишком" - это неправильно даже для "отделения академического института ")
2. Именно так, данные о TEC и параметрах мерцаний из GPStation6 получать можно напрямую (в чем собственно и его фишка). Именно за это приемник (уже в 4-ом поколении) и ценен вояками и академическими институтами по всему миру (по моим прикидкам их всего то сотен пять по миру (в России полтора десятка всего)).
3. IMHO - сырые ГНСС-данные для TEC вам проще для начала по-анализировать из RINEX-файлов постоянных станций (IGS например), а уж затем переходить в реал-тайм. Ключевой вопрос для вашей темы - высокотермостабилизированный кварц у приемника.

 

Спасибо за профессиональный и ёмкий комментарий! Покажу его начальству.

 

В приложении разбор входного потока данных от станции BRUX0.

Сообщение 1004

Колонки в таблице:

1 GPSEpochTime
2 SynchrGNSSFlag
3 NoOfGPSSatelliteSignalsProcessed
4 GPSSmoothingInterval
5 GPSSatelliteID
6 L1CodeIndicator
7 L1Pseudorange
8 L1PhaseRangeMinusL1Pseudorange
9 GPSL1LockTimeIndicator
10 GPSIntegerL1PseudorangeModulusAmbiguity
11 GPSL1CNR

Дата и время получения данных: 16:19 моск. время 14.04.2016
Не знаю, похожи ли эти данные на жизнь и как из GPSEpochTime получить время, а из L1Pseudorange - дальность?