Pull to refresh
296
-10.7

Программист микроконтроллеров

Send message

Да, выглядит верно.

Данные идут непрерывно.
Первый байт после декодирования - 0x9E = 0b10011110.

Соответственно, семплы, которые приходили c АЦП в хронологическом порядке - 0,1,1,1,1,0,0,1.

В целом - нелинейно, также как и доплеровское смещение. Но на небольших интервалах времени нелинейность незаметна.

Я уже говорил вам на такой же вопрос, что нет у меня такого желания.
https://habr.com/ru/articles/789382/comments/#comment_26671589

И я не понимаю, в чем сложность в вашем софте сделать и одного байта восемь int8_t .

Похоже, вы что-то делаете не так.
Вот такой тестовый код (точнее, его часть):

void test(void) 
{
    char data_path[300] = "D:\\PATH\\source2.bin";
    gps_fill_summ_table();

    gps_ch_t gps_channel1;
    memset(&gps_channel1, 0, sizeof(gps_channel1));
    gps_channel1.prn = 5;
    gps_channel1.acq_data.given_freq_offset_hz = 1000;
    gps_channell_prepare(&gps_channel1);

    uint8_t read_buffer[BITS_IN_PRN / 8];

    uint8_t res = data_reader_open_file(data_path);
    if (res == 0)
    {
        printf("Open file fail\n");
        return;
    }

    for (int i = 0; i < 2000; i++)
    {
        //Читаем 1мс данных
        res = data_reader_read_unpack(read_buffer, BITS_IN_PRN);
        if (res == 0)
        {
            printf("Can't read file\n");
            return;
        }
        acquisition_freq_test(&gps_channel1, read_buffer);
    }

    data_reader_close_file();
    printf("Execution end\n");
}

#define GPS_DATA_WORDS_CNT      (PRN_SPI_WORDS_CNT + 1)
uint16_t tmp_prn_data[GPS_DATA_WORDS_CNT];
uint16_t tmp_data_i[GPS_DATA_WORDS_CNT];
uint16_t tmp_data_q[GPS_DATA_WORDS_CNT];

//Генерирует локальный PRN код
//Переносит принятые данные на частоту, близкую к 0
//Перебирает все фазы кода, и выводит фазу максимальной
void acquisition_freq_test(gps_ch_t* channel, uint8_t* data)
{
	gps_generate_prn_data2(channel, tmp_prn_data, 0);
	int16_t freq_offset_hz = channel->acq_data.given_freq_offset_hz;

	gps_shift_to_zero_freq(data, (uint8_t*)tmp_data_i, (uint8_t*)tmp_data_q, IF_FREQ_HZ + freq_offset_hz);
	uint16_t avr_val;
	uint16_t best_phase1 = 0;
	correlation_search(tmp_prn_data, tmp_data_i, tmp_data_q, 0, (PRN_LENGTH * 2), &avr_val, &best_phase1);
	printf("%d\n", best_phase1);
}

Здесь использованы те же функции, что и репозитории:
https://github.com/iliasam/STM32F4_SDR_GPS/blob/develop/Firmware/project_main/GPS/gps_misc.c

Код выдает такие значения (первые 20 штук):

Hidden text

1360
137
504
2043
2043
1670
1112
2043
2043
450
1153
2043
2043
1775
1266
2043
2043
1840
485
2043

Моно видеть, что значение 2043 часто встречается. Это и есть фаза кода.

При увеличении видно, что фаза меняется:

" это была-бы хорошая игрушка для тех молодых ребят"
А вот и плата для них - https://habr.com/ru/articles/214355/

Я имел в виду фазу кода.
Если перебирать все фазы кода в диапазоне 0-2045 и все частоты в зоне -7000..+7000 Гц с шагом 1 Гц, то нужно 28 миллионов корреляций посчитать. Это очень много. А гарантий, что уровень сигнала в выбранном участке данных высокий - нет.

Я по положительной искал. И не по одному из каналов i/q, а по двум.
Использовал классический корень из суммы квадратов.
Посмотрите gps_correlation8() и correlation_search() здесь.

Я не понимаю, как вы устанавливаете частоты с такой точностью, не зная фазы сигнала.

Я бы рекомендовал, для тестирования кода, анализировать данные одного спутника, к примеру, с PRN=5, задать постоянным смещение частоты - 1000 Гц.
Далее для каждого блока по 1мс перебирать все варианты фазы кода и выводить в консоль или сразу на график фазы кода, где был максимум корреляции. Если по этим данным построить график (именно точками, не линиями), то должна получится картина, аналогичная тому, что была в статье в пункте "Поиск фазы кода". Если на графике есть наклонная линия - значит алгоритм нормально работает и "видит" сигнал спутника.

То тогда придется использовать оба канала I/Q, что выходят из микросхемы.
Соответственно, при переносе частот в софте придется формировать не просто "синус", а пару cos/sin (хотя так и сейчас делается). Смена знака частоты, в таком случае, так понимаю, делается через смену знака одной из составляющих.

Распределение было такое:

Черным показан сектор, принимаемый антенной, но в нем некоторые спутники все равно могли быть закрыты домами или иметь слишком низкий уровень сигнала.
Координаты и время указаны, можете попробовать использовать этот сервис: https://www.gnssplanning.com/#/settings

Точное значение частоты я сказать не могу, значения, приведённые в файле, округлены примерно до 500 Гц.
Для спутника 5 смещение частоты - около 1200 Гц.
Я не могу дать никаких гарантий, что в первых 2мс данных сигнал от спутников был качественный и стабильный.

Я специально приложил к данным файл, который считывает данные из source2.bin и декодирует их.
У меня нет желания писать конвертер.


Вот здесь попробуйте посмотреть - https://github.com/taroz/GNSS-SDRLIB/blob/master/test/testdata_download_link.txt
В случае SiGe GN3S V3 вроде бы как раз данные частот такие же - 16.368/4.092 МГц и данные - только I в формате int8_t.

По логике действительно так, вот только даже в относительно бытовых модулях часто оказывается более высокая точность. Как этого добиваются - не знаю.
Возможные варианты - просто усреднение (аналогично тому как в АЦП используют оверсемплинг) или какая-то интерполяция данных.
Возможно, @GreatGehar что-то подскажет?

"У меня нет статистики, как в среднем распределяются смещения частот в реальной жизни."
У меня есть ощущение, что отклонения частоты разных спутников равномерно распределены по диапазону сканирования, а не сосредоточены ближе к нулю.

По-моему - нет. Без корреляции обнаружить сигнал спутника нельзя.

И чем оно лучше обычного сканирования?
У меня нет статистики, как в среднем распределяются смещения частот в реальной жизни.
Могу только сказать, что из-за того, что TCXO может иметь свою ошибку, то частоты всех принимаемых сигналов будут сдвинуты на единицы кГц относительно нуля.
Интересно, что кроме обычных спутников GPS, есть еще геостационарные WAAS. Они передают свой сигнал на L1, так что их сигнал не должен иметь допплеровского смещения.

Данные source2.bin собраны с использованием MAX2769, которая тоже упоминается в этой статье. Так что частоты там 16.368 и 4.092 МГц. Я же говорил - данные были собраны для тестирования приёмника на STM32, который работает с MAX2769.

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

Верно, у GPS разброс около +-5кГц, зона поиска может быть расширена для компенсации ошибки TCXO и учета скорости движения приёмника.
А на картинке выше - LEO, т.е. низкая орбита. Вопрос ведь был про форму кривой.

Да, там нелинейная зависимость:

"Approximation of the Doppler curve for LEO downlink signals in different elevation angles"
"Approximation of the Doppler curve for LEO downlink signals in different elevation angles"

https://www.mdpi.com/1424-8220/20/20/5866

Я видел варианты шага 100-500 Гц. В статье про приемник на MCU я использовал шаг 500 Гц, в той статье это число упомянуто.

Выложенный у меня вариант GNSS-SDRLIB собран с шагом 100 Гц.

Information

Rating
Does not participate
Location
Москва и Московская обл., Россия
Registered
Activity