Comments 106
Здорово, что статья опубликована в международный день ГНСС:)
Работа проделана грандиозная, но результат оказался хуже, чем просто брать готовые данные с выхода самого GPS. Для повышения опыта - полезно. А практической пользы - не увидел.... GPS приемники сейчас пучок за пятачок.....
Верно, никакой практической пользы и не предполагалось, вся статья - про эксперимент, который планировался коротким, но затянулся)
В теории, приемник, способный выдавать данные о фазе, может быть полезен для RTK (дешевые приемники сырые данные не выдают).
Но в данном случае по каким-то причинам сырые данные от GNSS-SDRLIB (RTCM) получились шумные.
который планировался коротким
Но получился очень основательным. Да и на написание статьи наверно много времени ушло?
Спасибо за отличный пост!
Статья безусловно познавательная. И наглядный пример, как заметил сам автор:
"Ровно было ( в смысле "быстро" ) на бумаге, но забыли про овраги"
Но замечу, замечание о том, что "дешевые приемники сырые данные не выдают" ошибочно.
В статье указан приемник u-blox M8T, который выдает эти данные и стоит 2600 руб.
-----------------------
Если делать как описано в статье то получится и дольше и дороже и хуже,в статье это доказано.
Так стоимость только микросхем для эксперимента составляет
CY7C68013A - 700 руб.
MAX964EEE -500 руб.
GlobalSat BT-318 -4000 руб. предположим, что старый можно найти рублей за 1500.
если берем RTL SDR приемник уже от 2500 руб.
Плюс печатные платы +ПО + творческая инициатива.
Что-то дешевые приемники m8t, у производителя на сайте они от 90$ стоят.
за 90$ можно взять такой:
Продукт G-Mouse GN-02B с улучшенной навигацией и позиционированием, разработанный и произведенный TOPGNSS, представляет собой одночастотный RTK-усовершенствованный чип и интегрированную плату с антенной
Модель:： GN-02B
Режим ГНСС：
Рабочее напряжение (В): Напряжение постоянного тока 3,7 В, типичное: 3,7 В
Рабочий ток: Захват 55 мА / 3,7 В
размер (мм):： 35*35*8.6 мм
Вес (г): 10 г
Бренд：： TOPGNSS
Сообщение NMEA:： RTCM3.2, NMEA0183 RMC, GGA, GSA, GSV, GLL, VTG
Так приемники умеют выдавать готовые сообщение RTK...
Все зависит от области применения. Высокоточные, да еще и с PVT, очень даже недешевые. А двухантенные так и подавно.
Все верно. Но высокоточными являются только приемники для военного применения. Гражданские могут быть только просто точные для геодезистов например. Все остальное - в навигаторах и телефонах - "обычные" с точностью хорошо если метров 20....
Сильно ошибаетесь. В сехозке применяются приемники которые дают сантиметровую и миллиметровую точность при наличии RTK поправок. Военные отличаются не точностью, а помехозащищенностью в основном. Вот характеристики одного из таких модулей от SinoGNSS:
Ну и Ublox:
ну это hi-end приемник 65000 на алишке.... у здешних барыг цена ваще будет космос
Ну так он же все равно не военный, а просто точный =)
Используя RTKLIB и два приемника, способные выдавать сырые данные (упоминались выше) тоже можно получить высокую точность: https://habr.com/ru/articles/244475/
Ublox ZED-F9P умеет GNSS-RTK.
Вот обзор.
https://habr.com/ru/articles/648247/
Интересная статья!
Я вот только не понял, каким образом получается разделить сигналы разных спутников почти на одной несущей частоте, оцифровывая всего двумя битами. Тем более одним битом, как здесь. Вообще ведь полная каша после такой оцифровки получится, особенно если мощность сигналов разных спутников сильно отличается.
Все работает за счет большой избыточности данных. Даже в случае RTL-SDR, один чип - это 2048*2 выборок АЦП. Но из этих всех выборок приемник выделяет только фазу PRN-кода и "полярность" - один бит данных.
Получается что в GNSS навигации происходит кодовое разделение канала CDMA. Так?
Да, в книге "A Software-Defined GPS and Galileo Receiver: A Single-Frequency Approach" [1] прямо написано - "GPS is a CDMA system".
Википедия тоже об этом говорит - https://en.wikipedia.org/wiki/Code-division_multiple_access
>> оцифровывая всего двумя битами
Два бита это ещё нормально...В статье упомянут 1-bit ADC (по ссылке реальный работающий проект Homemade GPS Receiver (Andrew Holme, 2011) в статье тоже есть ссылка на него.
Монументальная работа. Я очень давний поклонник SiRF Star (штук 20 устройств точно есть), но так глубоко не влезал )))
>>> В презентации выше упомянуты частоты: ACQCLK=38.192 MHz и IF=9.548 MHz (1/4 ACQCLK). Такие же частоты упоминаются в книге [1].
>>> А вот в Application Note APNT0012 упомянуты другие частоты: ACQCLK=38.194 и IF=9.45MHz.
Правда, если проанализировать структурную схему, можно определить коэффициенты деления и формулы, связывающие все частоты в микросхеме RF frontend. По ним первые частоты подходят, вторые - нет. Но есть явное ощущение, что тут что-то не так.
Ошибки нет. В приёмниках SiRF Star II. III, IV промежуточная частота смещена на номинальные 96.25 kHz by design, т.е. при нулевом доплере приёмник измерит 96.25 kHz. Это их фишка. В своё время (2006) на форуме GPS-Passion отвечал один из разработчиков с ником Carl@SiRF, он не вдавался глубоко в детали, но писал что это улучшило цифровую обработку, в их системе не бывает отрицательного доплера. Тут я не краевед. Но то что частота смещена - факт. В бинарных данных также доплер смещён на эти номинальные 96.25 kHz, а псевдодальности растут такими темпами, что в момент сброса достигают значений по 50,000,000 м и более )) По этой причине эти приёмники не поддерживаются в RTKLib, а большинство энтузиастов спотыкалось и просто забрасывало идеи RTK и постобработки. Но если уметь "готовить" то ничем не хуже uBlox.
Что касается сырых данных по бинарному протоколу, то все указанные приёмники отдают псевдодальности, а также
SiRF Star II (ваш приёмник) - отдаёт дальности, фазу, но измерения не синхронизированы с целыми GPS-секудами, в сырых данных дробные плывущие секунды от измерения к измерению.
SiRF Star III - отдаёт дальности, измерения синхронизированы с целыми секундами, но фаза обнулена по коммерческим соображениям, видимо предполагалось продавать как отдельный продукт. Чип получился супер-удачным. К слову пользователь Alexey Illarionov пропатчил прошивку, фазу она тоже умеет отдавать. В постобработке я вытягивал сантиметры.
SiRF Star IV - отдаёт дальности, фазу, измерения синхронизированы с целыми секундами. Пока ещё можно купить на Ali, но выбор уже минимальный. Недостаток - нельзя прошивать.
Не подскажете где можно почитать про это вот все?
У меня китайский навигатор на Sirf III, вроде бы, хотелось бы как минимум модулю GPS прошивку обновить что бы дату правильнотпонимал. Как максимум - давно хотел посмотреть поближе, сервисную программу для Sirf скачал и запускал,, но мало что понял а наугад тыкать не стал.
https://gps.0xdc.ru/docs/sirfstar.html
Но боюсь вам это не подойдёт - китайские навигаторы делались на микросхеме Atlas III (CPU + GPS), их перекупил Sirf и начал называть SiRF Atlas III. Он не имеет ничего общего с дискретным GPS-чипом SiRF Star III, его нельзя прошить, протокол Sitf Binary отсутствует.
С SiRF Star III делались только брендовые и топовые навигаторы - TomTom (Linux), Mitac Mio (Windows CE), HP iPaq Travel Companion (Windows Mobile), наладонники ASUS (Windows Mobile) и др.
Не лазил за характеристиками DE0, но - не чужой ли 68013 на этом празднике любознательности? ЕМНИП, DE0 мог-бы и LVPECL напрямую принять?
В любом случае - круто! И "тёплый, ламповый" ПМ-70.
"не чужой ли 68013 на этом празднике любознательности?"
На DE0-nano нет никаких интерфейсов для этого.
Там есть FT245, но она только для JTAG. Какой-нибудь SignalTap может из ПЛИС данные вычитывать через JTAG, но приличную скорость так не получить.
"DE0 мог-бы и LVPECL"
Возможно да, но тащить 3 дифпары из приемника к ПЛИС мне не хотелось - так в любом случае нужны будут длинные провода, а не короткие проволочки, как сейчас.
PECL (Pseudo Emitter Coupled Logic)
Всегда думал, что P от слова Positive
Из Википедии: https://en.wikipedia.org/wiki/Emitter-coupled_logic#PECL
"Positive emitter-coupled logic, also called pseudo-ECL, (PECL)
В APNT0012 использовано определение именно - "Pseudo Emitter Coupled Logic"
Как из 50 бит/с создать поток 304 мегабит/с и затем самоотаерженно с этим бороться? Ну,, за дело берётся опытный программист ,)))
Ширина полосы С/A-кода - 2 МГц, с приемника из статьи поток данных - 76Mbit.
Считайте это ΣΔ-АЦП. Там тоже идет размен одного бита со скоростью 100500 на 24 бита со скоростью 10. За счёт передискретизации и корреляций - сигнал GPS с мощностью ниже мощности эфирных шумов - вытаскивается на свет.
"компаратор" на биполярном транзисторе просится :)
Я светодиод на 68013 ставлю чтобы показать что он не сконфигурирован и сидит в буте.
C/A - это сигнал гражданского назначения
Хорошо, с физическим уровнем примерно ясно.
Однако что из себя, собственно, представляет бинарный протокол, который приходит из космоса с навигационных спутников?
Какая там, хотя бы, структура пакета?
Какой канальный протокол?
Какой протокол на прикладном уровне?
Протокол имеют только навигационные данные (те, что 50 бит/с). Там чистая проприетарщина.
Здесь неплохо формат данных описан: https://www.e-education.psu.edu/geog862/book/export/html/1407
Ну вот, хоть чтото полезное в статье есть. ;) "Проприетарщина" ???? А что же тогда стандарт навигации? То, что написал ты? ;)
Все "стандарты навигации" есть в официальных документах: https://www.gps.gov/technical/icwg/IS-GPS-200M.pdf
Замечу, что фазы всех вышеупомянутых сигналов синхронизированы друг с другом, к примеру, смена битов навигационных данных четко привязана к периодам C/A-кода.
Это значит, что битовая скорость на выходе сложения по модулю два не увеличивается, а остается 1.023 Mbit/s.
Получается, что фаза сигнала со спутника постоянна c периодом минимум 970ns.
Так?
Номер спутника. Он нужен для генерирования PRN кода.
--Сколько бит в номере спутника?
--Сколько бит в PRN коде?
"Этот поток данных представляет собой псевдослучайный шумоподобный код (PRN), который формируется по специальной формуле, уникальной для каждого спутника.
Поток данных состоит из 1023 бит (называемых chips/чипами), то есть через каждые 1023 чипа (1 мс) данные повторяются."
Для PRN не всякая последовательность из 1023 нулей и единиц подойдет.
Надо же чтобы PRN(ы) были попарно ортогональны для всех остальных 30+ спутников. Так?
Есть ли возможность представить все известные PRN коды в hex/base64 виде?
Да, верно.
"Есть ли возможность представить все известные PRN коды в hex виде?"
Без проблем, возможно, где-то в интернете они выложены, можно попробовать поискать.
Я их генерирую при включении: https://github.com/iliasam/STM32F4_SDR_GPS/blob/develop/Firmware/project_main/GPS/gps_misc.c#L317
Я так понял что эти PRN коды, каждый из них в отдельности зеркально не симметричный.
Если последовательность бит в них инвертировать, то получится не то же самое.
Так?
Что-то я не понял вопроса.
Могу только это порекомендовать - https://en.wikipedia.org/wiki/Gold_code
Опять же, в статье есть ссылка - https://www.wasyresearch.com/generating-gps-l1-c-a-pseudo-random-noise-prn-code-with-matlab-and-c-c/
Если я не ошибаюсь, спутник нигде свой номер не передает.
Здесь написано, что есть 45 комбинаций, из них используют 32:
https://lea.hamradio.si/~s53mv/navsats/theory.html
Очень рекомендую прочитать эту статью.
PRN-код и С/A-код это одно и то же?
Выглядит так, что GNSS приемник сложнее GNSS cпутника.
Не забывайте, что каждый спутник содержит 4 штуки атомных часов (подозреваю, их параметры можно подстраивать с земли), более сложную электронику для передачи P(Y)-кода, целую гору оборудования для загрузки данных на борт. И все это, скорее всего, дублировано.
Плюс, современные спутники данные еще и на разных частотах передают, и протоколы там разные.
На какой мощности в ватах изучают спутники GNSS ?
Пишут, 25.6 Вт - http://gpsinformation.net/main/gpspower.htm
Откуда вообще взялись GPS частоты 10.23 MHz и 1.023 MHz?
Что-то не получаются целочисленных делителей, которыми получится 1.023 MHz из атомных часов.
# https://youtu.be/3lNtav3CjM8?si=GnWTsXfnhxfEzaYF
cesium133_freq_hz = 9192631770.0
rubidium_freq_hz =6834682610.904
l1_freq_hz=1575.42*(10**(6))
l1_period_s = 1.0/l1_freq_hz
cesium133_period_s = 1.0/cesium133_freq_hz
rubidium_period_s = 1.0/rubidium_freq_hz
f_0_freq_hz = 10.23 * (10**(6))
f_0_period_s = 1.0/f_0_freq_hz
cesium133_div = f_0_period_s/cesium133_period_s
rubidium_div = f_0_period_s/rubidium_period_s
l1_cesium133_div = l1_period_s/cesium133_period_s
l1_rubidium_div = l1_period_s/rubidium_period_s
print ('cesium133 Freq:{} Hz Period:{} s '.format(cesium133_freq_hz,cesium133_period_s))
print ('rubidium Freq:{} Hz Period:{} s'.format(rubidium_freq_hz,rubidium_period_s))
print ('L1 Freq:{} Hz Period:{} s'.format(l1_freq_hz,l1_period_s))
print ('F0 Freq:{} Hz Period:{} s'.format(f_0_freq_hz,f_0_period_s))
print ('F0_div cesium133 {} '.format(cesium133_div))
print ('F0_div rubidium {} '.format(rubidium_div))
print ('L1_div cesium133 {} '.format(l1_cesium133_div))
print ('L1_div rubidium {} '.format(l1_rubidium_div))
в этом приемнике тоже использован 2-битный АЦП, так что допустимые значения данных тут - [-3,-1, 1, 3].
А какие 2bit коды соответствуют -1; -3; 1; 3?
Какой частотой кварца REF XTAL тактируется GNSS RF front-end ASIC GRF2i/LP?
Простите, рекомендую внимательней читать статью:
"Чтобы вычислить истинные значения частот, нужно знать только частоту TCXO кварцевого генератора, использованного в моем приемнике. И с этим есть проблема - маркировка R2141 Y439 не находится в интернете, точного частотомера у меня нет (уже позже я выяснил, что это может быть Rakon Part 2141-24.5535MHZ). Покопавшись в интернете, я смог найди одну схему GPS приемника на таком же чипсете, и выяснил, что другие производители использовали с этим чипсетом TCXO на частоту 24.5535MHz. "
GNSS RF front-end ASIC GRF2i/LP выдает на улицу I или Q?
У меня была дешевя отладочная плата для микросхемы CY7C68013a, которую я и собирался использовать для захвата данных от ПЛИС:
Теоретически записать поток данных в параллельной 8 bit поток данных на частоте 9.5238 MHz из FPGA можно было бы и при помощи логического анализатора Saleae и утилиты Logic 2.
Вот так она например записывает I2S https://habr.com/ru/articles/758188/
но я пошел более простым путем, и использовал отладочную плату ПЛИС DE0-Nano. Так так задача довольно простая, то и код на Verilog получается простейший. В результате на 4 такта ACQCLK ПЛИС выдает один байт данных (8 выходов). В них четыре старших бита - SIGN, четыре младших - MAG. Также имеется выход синхронизации. Таким образом мы получаем поток данных 9.5 Мбайт/с.
Что-то много нулей в захваченном логе.
Неужели MAG всегда "бинарный 0" то есть "1"? Там случайно контакт не отвалился при записи?
Честно, не помню уже, действительно ли source2.bin - данные именно связки ПЛИС+CY7, вроде да, точно лишь могу сказать, что приложенный код адекватно извлекает из них данные SIGN, и помещает их в массив так, как будто они приняты по SPI контроллером.
После ПЛИС+CY7 данные были упакованы так - в одиночном байте биты [3..0] - MAG, [7..4] - SIGN, 3/7- самые старые выборки, 0/4 - самые новые. Один байт - 4 двухбитных семпла.
Я не могу гарантировать, что в случае именно файла source2.bin данные MAG верные - при записи я мог эту линию не подключать, так как данные MAG контроллер не обрабатывает. Судя по количеству нулей, так и есть.
Получается вот такое битовое поле.
typedef union {
uint8_t byte;
struct {
uint8_t mag3 : 1;/*bit 0: sample0 MAG new*/
uint8_t mag2 : 1;/*bit 1: sample1 MAG*/
uint8_t mag1 : 1;/*bit 2: sample2 MAG*/
uint8_t mag0 : 1;/*bit 3: sample3 MAG old*/
uint8_t sig3 : 1;/*bit 4: sample0 SIGN new*/
uint8_t sig2 : 1;/*bit 5: sample1 SIGN*/
uint8_t sig1 : 1;/*bit 6: sample2 SIGN*/
uint8_t sig0 : 1;/*bit 7: sample3 SIGN old*/
};
} GnssFpgaPackByte_t;
Правильно ли я декодировал первые сорок восемь 38.192 MHz(цовых) семплов?
1,-1,-1,-1,-1,1,1,-1,1,-1,-1,1,-1,-1,1,1,-1,-1,1,1,-1,-1,-1,-1,1,1,-1,-1,1,1,1,-1,-1,1,1,-1,-1,-1,1,1,1,-1,-1,-1,-1,1,1,1,
из файла [source2.bin],Size:268435456 bytes,Samples:1073741824,Duration:28.114313 s
Вроде бы да, только у меня данные инверсные. Знак в данном случае неважен.
Напоминаю, что SPI настроен на режим - LSB first.
Я так понял, что это непрерывный битовый поток.
Порядок самих битов(ADC семплов) вот такой:
1,0,0,1, 1,1,1,0, 0,0,1,1, 0,1,1,0, 1,1,1,1, 0,0,1,1, 1,0,0,0, 1,1,0,0, 0,0,1,1, 1,0,0,1, 0,0,0,1, 1,1,1,0 0,1,1,1 0,0,1,1 1,0,0,1, 0,0,1,0
Так?
Напоминаю, что SPI настроен на режим - LSB(least significant bit ) first.
Это что значит, что в каждом слове(2байт) сперва надо биты инвертировать, а только потом семплы через запятую записывать?
Данные идут непрерывно.
Первый байт после декодирования - 0x9E = 0b10011110.
Соответственно, семплы, которые приходили c АЦП в хронологическом порядке - 0,1,1,1,1,0,0,1.
Вот это правильное начало gn3sv3_l1 файла для source2.bin?
Да, выглядит верно.
Это очень странно, Так как для этого файла byte_stream_i8.bin и спутника 5 утилита GNSS-SDRLIB-GUI находит другую фазу и доплер.
Должно же быть смещение по частоте 1000 Hz. byte_stream_i8.bin - Это же производный файл от source2.bin
Я специально написал в статье рядом с аналогичной картинкой:
"а вот частота здесь подписана неверно, в действительности значения - не Hz, это просто значение индекса среди N перебираемых частот. "
В этой программе acquisition вообще странновато работает, иногда он может давать немного разные результаты с одним и тем же файлом данных.
Я воспользовался сорцами из архива REC_GPS.zip и получился вот такой битовый поток
9e 36 f3 8c 39 1e 73 92
-------------------------------------------------------------------
9 e | 3 6 | f 3 | 8 c | 3 9 | 1 e | 7 3 | 9 2
-----------------------------------------------------------------------------------------------
1001 1110 0011 0110 1111 0011 1000 1100 0011 1001 0001 1110 0777 0011 1001 0010
-------------------------------------------------------------------------------
1,0,0,1, 1,1,1,0, 0,0,1,1, 0,1,1,0, 1,1,1,1, 0,0,1,1, 1,0,0,0, 1,1,0,0, 0,0,1,1, 1,0,0,1, 0,0,0,1, 1,1,1,0 0,1,1,1 0,0,1,1 1,0,0,1, 0,0,1,0
-------------------------------------
-1,1,1,-1 -1,-1,-1,1 ....
Первоначальный вариант явно не корректный.
Реально ли записать непрерывный 60 сек гигабайтный dump GPS семплов (int8_t) при помощи RTL-SDR приемника на R820T2+ RTL2832U с GNSS антенной?
https://microsin.net/adminstuff/others/rtl-sdr-quick-start-guide.html
Записать реально, я же уже давал вам ссылку - https://github.com/taroz/GNSS-SDRLIB/blob/master/test/testdata_download_link.txt
Только RTL-SDR, как и большинство других SDR приемников, выдает результаты в формате I/Q.
Частота сигнала, на которой нужно искать поток данных. Спутники постоянно движутся по небу, в результате чего принимаемый на Земле сигнал имеет доплеровское смещение частоты. При "холодном старте" приемник опять же ничего не знает про спутник, так что ему приходится определять истинную частоту перебором. Очевидно, что у каждого спутника, от которого мы принимаем сигнал, частота будет своя. Обычно зона поиска находится в диапазоне ±10 кГц.
C учетом эффекта Доплера частоту гетеродина надо варьировать в диапазоне от
F_LO_Start до F_LO_End
F_L1=1575420000
F_LO_End =F_L1+10000=1575410000
F_LO_Start=F_L1-10000=1575430000
1575410000 ..........1575430000
Но ведь тут 20000 вариантов только целых частот. С каким шагом перебирать частоты на практике?
Я видел варианты шага 100-500 Гц. В статье про приемник на MCU я использовал шаг 500 Гц, в той статье это число упомянуто.
Выложенный у меня вариант GNSS-SDRLIB собран с шагом 100 Гц.
По какому графику меняется частота принятой несущей L1 от времени F_L1(t)=? из-за доплеровского эффекта и вращения Земли?
Там наверное нелинейная зависимость?
Да, там нелинейная зависимость:
По моим вычислениям разброс частоты принятой несущей должен составлять всего 10kHz
import matplotlib.pyplot as plt
import math
import numpy as np
#SV space vehicle
F_L1_Hz=1575420000.0 #L1 carrier
C_m_s = 299792458.0 # speed of lignt
R_m=6371000;#radius of Erth
Ro_m = (R_m+20180000.0) #radius of orbit
Mass_of_earth_kg= (5.9722 ) * (10**24)
G = 6.6743015*np.power(10.0, -11.0)
Orbit_speed_mps = np.sqrt(G*Mass_of_earth_kg/Ro_m);
print("SV Orbit_speed {} m/s".format(Orbit_speed_mps))
Orbit_path_m = 2*math.pi*Ro_m
SV_OrbitPeriod_s = Orbit_path_m/ Orbit_speed_mps
print("SV Orbit_period {} h".format(SV_OrbitPeriod_s/3600.0))
#SV_OrbitPeriod_s = (11.0+(58.0/60.0))*3600.0
#Coordinates of receiver
Rx_x = 0
Rx_y = R_m
t_s = np.arange(0, SV_OrbitPeriod_s, 1.0)
phi_rad = 2*math.pi*t_s/SV_OrbitPeriod_s
SV_x=Ro_m*np.cos(phi_rad)
SV_y=Ro_m*np.sin(phi_rad)
Dist_vector = (SV_x-Rx_x)+ 1j*(SV_y-Rx_y)
Dist_m = np.abs(Dist_vector)
h_deg=np.rad2deg(np.angle(Dist_vector))
# Numerical derivative
Speed_ms = np.gradient(Dist_m)
#Doppler effect
Frx_hz = F_L1_Hz/(1.0-(Speed_ms/C_m_s))
Frx_diff_hz=np.max(Frx_hz)-np.min(Frx_hz)
fig, axes = plt.subplots(4)
axes[0].plot(t_s, Dist_m, label="dist[m]")
axes[0].grid()
axes[1].plot(t_s, h_deg, label="h[deg]")
axes[1].grid()
axes[2].plot(t_s, Speed_ms, label="SV-to-Recever Speed [m/s]")
axes[2].grid()
axes[3].plot(t_s, Frx_hz, label="F_carrier_rx,[Hz] Diff:{} Hz".format(Frx_diff_hz))
axes[3].grid()
axes[0].legend(loc='best')
axes[1].legend(loc='best')
axes[2].legend(loc='best')
axes[3].legend(loc='best')
plt.xlabel('Time,[s]')
plt.xticks(rotation=-90)
plt.show()
вот нижний график
SV Orbit_speed 3874.6246836846635 m/s
SV Orbit_period 11.959929219682028 h
С GNSS FrontEnd GRF2i/LP получается 37.33(3) ADC Samples на chip. Так?
А спутник GPS посылает какой-нибудь рadding между PRN кодами?
Выдерживает ли спутник какую паузу между отправкой следующего PRN кода?
Или спутник непрерывно шарашит свои PRNы один за другим без зазоров .
При этом придется имеются следующие неизвестные:
A фазу сигнала гетеродина разве не надо тоже подстравивть?
Где цифровой фильтр нижних частот, который уберёт синус удвоенной частоты (2*9.5238 =19.0476 MHz ) после программного смесителя, аналогично тому как это происходит в GNSS Front-End?
При захвате сигнала со спутника (поиск несущей и фазы PRN) по какому сигналу Вы делали свертку синтезированного PRN кода с принятым сигналом с антенны?
a--с I каналом,
b--с Q каналом
c--abs(I+jQ)
d--arg(I+jQ)
e--другое
Вы точно к той статье задаете вопрос? В этой статье для Acquisition сгенерированный PRN код сразу пропускается через FFT. В какой форме там перемножение происходит - точно не помню, это же не мой код.
Я пробую обработать данные из файла source2.bin алгоритмами из текста SDR приемник GPS на микроконтроллере, однако в первых 2ms не находится PRN 5
на частотах -+10kHz от несущей.
Захват не происходит. Максимум корреляции достигает значения 15-18, а судя по скриншотам должно быть 2000-6000.
В source2.bin точно семплы следуют на частоте 38192000 Hz?
Какого порядка у вас получались максимальные значения корреляции prn кода с данными с антенны?
Как по мне, декодирование GPS сигнала была бы отличной лабораторной работой для Политехнических ВУЗов по курсу DSP/ЦОС ( Цифровая Обработка Сигналов)
Тут вам и корреляция, и свёртка, и кодовое разделение каналов (CDMA), и преобразование Фурье, и полосовые фильтры и Доплер и ещё что-н .
Даешь ВУЗ(овцу) гигабайтный файл с логами отсчетов в int8_t и говоришь:
—найти сигнал PRN20 (захватить)
-- построить график смещения фазы от времени для PRN5
—определить расстояние до спутника
—декодировать NAV data.
--выделить время
и т п
На профильных дисциплинах такое есть - https://srns.ru/wiki/Blog:Korogodin/14.08.2011,_График_занятий_по_АП_СРНС
Именно по разнице фаз между сигналами разных спутников и происходит вычисление расстояния до них
С какой погрешностью и какой точностью вычисляется расстояние до спутников?
Новая жизнь старого GPS-приёмника