Files

2025-09-18 17:11:38 +03:00

14 KiB

Raw Permalink Blame History

1

NaN: Всё взаимодействие через UART вопрос в следующем после получения пакета с заданием 0х7777 он начинает работу по перестройке тока, параметры заданы в пакете. каждую секунду приходит еще пакет
Sent: Request last data (TRANS_ENABLE). Received 30 bytes

формируется ответ и отправляются значения температур диодов

вопрос где тут в коде формируется ответный пакет с параметрами температур

Вы посмотрите, а потом решим когда)

!0x1111_descrtxt.txt У меня возникает недопонимание тут, !0x7777_task_command.txt

вместе с начальным током перестроения лазера 1, устанавливается ток лазера 1 и я не могу понять в каком месте он ставит этот ток при сообщении 0х7777 -- DONE 0х7777 передается один раз при установке настроек Непонятно как измеренные значения назад отправляются по команде 4444

!device_commands.py

!1_1_Report_generator_heterodyne_20240124.pdf

Контроль температуры во время TASK.

Проблема

Во время варьирования тока лазера никакая температура не измеряется и не поддерживается.

Анализ

Быстрый фикс:

Поставить старую поддержку температуры на варьирование тока второго лазера. На task варьирования тока первого -- оставить как было.

Нормальное решение

1 цикл измерения температуры 35 us. Это больше, чем минимальный временной шаг изменения тока. Следовательно, есть 2 подхода:

написать асинхронные MPhD_T() и Set_LTEC().
сделать варьирование тока через DMA, а температуры контролировать обычным способом. Это более перспективно, т.к.разгрузит вычислительные ресурсы во время варьирования.
сделать варьирование тока в обработке прерывания, а температуру контролировать в блокирующем цикле.

Варьирование тока в прерывании

Добавил глобальную переменную task_state task_state = 0 -- task не выполняется -- устанавливается в конце работы в прерывании. task_state = 1 -- task в процессе выполнения. Устанавливается после подготовок в main.c

Что такое Temp_ext_1/2?

Парсинг ответа на команду 0x4444: data = {} data['datetime'] = datetime.now() data['Header'] = get_word(dh, 0) data['I1'] = cnv.conv_I_N_to_mA(get_int_word(dh, 1)) data['I2'] = cnv.conv_I_N_to_mA(get_int_word(dh, 2)) data['TO_LSB'] = get_int_word(dh, 3) data['TO_MSB'] = get_int_word(dh, 4) data['Temp_1'] = cnv.conv_T_N_to_C(get_int_word(dh, 5)) data['Temp_2'] = cnv.conv_T_N_to_C(get_int_word(dh, 6)) data['Temp_Ext_1'] = cnv.conv_TExt_N_to_C(get_int_word(dh, 7)) data['Temp_Ext_2'] = cnv.conv_TExt_N_to_C(get_int_word(dh, 8)) data['MON_3V3'] = cnv.conv_U3V3_N_to_V(get_int_word(dh, 9)) data['MON_5V1'] = cnv.conv_U5V_N_to_V(get_int_word(dh, 10)) data['MON_5V2'] = cnv.conv_U5V_N_to_V(get_int_word(dh, 11)) data['MON_7V0'] = cnv.conv_U7V_N_to_V(get_int_word(dh, 12)) data['Message_ID'] = get_word(dh, 13) # Last received command data['CRC'] = get_word(dh, 14) dh -- принятый ответ, формируемый в MCU в виде массива LongData. Формирование LongData:

	Long_Data[1] = LD1_param.POWER;//Translate Data from monitor photodiode of LD1 to Long_Data
	Long_Data[2] = LD2_param.POWER;//Translate Data from monitor photodiode of LD2 to Long_Data
	Set_LTEC(1,LD1_curr_setup.CURRENT);//Drive Laser diode 1
	Set_LTEC(2,LD2_curr_setup.CURRENT);//Drive Laser diode 2
		//Prepare DATA of internals ADCs
		//Put the temperature of LD2 to Long_Data:
	temp16 = Get_ADC(0);
	temp16 = Get_ADC(1); // measure ADC1 IN2 -- PA2 -- 3V_monitor
	Long_Data[7] = temp16; // 3V_monitor -- Temp_Ext_1
	//Put the temperature of LD2 to Long_Data:
	temp16 = Get_ADC(1); // measure ADC1 IN8 -- PB0 -- U_Rt2_ext_Gain
	Long_Data[8] = temp16; // U_Rt2_ext_Gain -- Temp_Ext_2
	//Put the temperature of LD2 to Long_Data:
	temp16 = Get_ADC(1); // measure ADC1 IN9 -- PB1 -- U_Rt1_ext_Gain
	Long_Data[9] = temp16; // U_Rt1_ext_Gain -- MON_3V3
	//Put the temperature of LD2 to Long_Data:
	temp16 = Get_ADC(1); // measure ADC1 IN10 -- PC0 -- 5V1_monitor
	Long_Data[10] = temp16; // 5V1_monitor -- MON_5V1
	//Put the temperature of LD2 to Long_Data:
	temp16 = Get_ADC(1); // measure ADC1 IN11 -- PC1 -- 5V2_monitor
	Long_Data[11] = temp16; // 5V2_monitor -- MON_5V2
	temp16 = Get_ADC(2); // turn ADC1 OFF
	//Put the temperature of LD2 to Long_Data:
	temp16 = Get_ADC(3);
	temp16 = Get_ADC(4); // measure ADC3 IN 15 -- PF5 -- 7V_monitor
	Long_Data[12] = temp16; // 7V_monitor -- MON_7V0
	temp16 = Get_ADC(5); // turn ADC3 OFF
	//Put the timer tick to Long_Data:
	TO6_stop = TO6;
	Long_Data[3] = (TO6_stop)&0xffff;
	Long_Data[4] = (TO6_stop>>16)&0xffff;
	//Put the average temperature of LD1 to Long_Data:
	Long_Data[5] = LD1_param.LD_CURR_TEMP;
	//Put the average temperature of LD2 to Long_Data:
	Long_Data[6] = LD2_param.LD_CURR_TEMP;

ADC1 -- scan conversion mode.

синхронное детектирование

Кривые тайминги варьирования тока

Проблема:

Камиль: 1 шаг перестроения тока -- не 50 мкс (как надо), а 70 мкс.
после удаления поддержания температуры -- 1 шаг перестройки -- на 10 мкс меньше установленного. Если установлен шаг менее 30 мкс -- GUI вылетает.

анализ

В коде GUI:

Установка шага времени.

GUI -> params['Delta_Time']
в create_TaskEnableCommand(): запись в посылаемые данные: sending_param['Dt']*100 //(Word 6)
в main(): sending_param['Dt'] = float(params['Delta_Time']) Тоесть "передаваемое значение" = "значение из GUI" * 100.

В коде MCU:

TIM10 тактируется от APB2 (184 MHz), prescaler=183, ARR = 9. => TIM10 update -- каждые 10 мкс. (проверено на железе -- верно ) Обработка значения:

task.dt = "принятое значение"/100 (main.c:2070)
TO10_counter = task.dt / 10 - 1 (main.c:2080, 625) => из GUI и кода MCU: период события TIM10_coflag = ('Delta_Time'/10 - 1) * 10 мкс

решение

т.к. период события TIM10_coflag = ('Delta_Time'/10 - 1) * 10 мкс Получаемый период варьирования тока -- на 10 мкс меньше, чем в GUI. main.c:2080,625: "TO10_counter = task.dt / 10 - 1;" -> "TO10_counter = task.dt / 10;" в итоге период события TIM10_coflag = ('Delta_Time'/10) * 10 мкс. Сделать период обновления TIM10 менее 10 мкс -- сложно, т.к. увеличится частота прерываний. => шаг времени -- 10 мкс. добавим в описание поля в GUIte

Клоки для модулятора и АЦП недетерменированно выключаются в конце ЛЧМ.

Проблема

Наблюденные варианты выключения клоков в конце ЛЧМ. Желтый -- клок АЦП (семплирование по спадающему фронту) Синий -- сигнал на модулятор Маха-Цандера. Розовый -- триггер (рассматривается конец процедуры ЛЧМ, триггер произошел 176 мс назад) !

! Дополнительная проблема: процедура ЛЧМ не всегда содержит одинаковое число шагов.

анализ

Проблема в выключении таймеров. Так как выключение (HAL_TIM_PWM_Stop(&htim11, TIM_CHANNEL_1)) происходит в коде по завершению ЛЧМ -- точный момент выключения зависит от выполнения остального кода, не детерменирован. Надо как-то

решение

Вариант 0

Выключать таймеры атомарной записью в регистр, а не через HAL. Реализация:

Вариант 1.

Зафиксировать число шагов ЛЧМ. Выключать клоки в обработчике прерывания TIM10.

Вариант 2. Реализован

Когда приходит пора выключить таймеры, включаем прерывание TIM11. В прерывании переводим оба таймера в one-pulse mode. Они сами выключаются. Затем перед следующим запуском ЛЧМ -- выключаем one-pulse, прервывание, обнуляем счетчики и запускаем. !

TODO: сделать атомарный запуск обоих таймеров. TODO: настроить сдвиг фазы АЦП относительно модуляции.

настройка таймингов модулятора и АПЦ

Проблема

Клок АЦП плохо соотносится с принятым модулированным сигналом.

!
Синий -- на модулятор Маха-Цандера
Желтый -- клок АЦП (запуск по спаду)
Голубой -- принятый модулированный сигнал
Сигнал с АЦП
!

Анализ

Проблема возникала из-за плохой настройки фаз клоков АЦП и модулятора Маха-Цандера. Большая малопредсказуемая задержка привносилась функцией запуска таймеров HAL_TIM_PWM_Start(&htim11, TIM_CHANNEL_1) (main.c 437,438).

Решение

После запуска таймеров повторно атомарно обнуляем счетчики (TIM -> CNT = 0).

!
Синий -- на модулятор Маха-Цандера
Желтый -- клок АЦП (запуск по спаду)
Голубой -- принятый модулированный сигнал
Сигнал с АЦП:
!

развитие

Установлена небольшая задержка при запуске клока АЦП, чтобы семплирование происходило в конце периода модуляции. Таким образом, при увеличении задержек в радиочастотном тракте семплирование не будет происходить в момент изменения уровня сигнала. Запас по времени ~400 нс (120 м). ! Код: TIM4 -> CNT = TIM4 -> ARR - 20 (main.c:441) #git commit f20ad2301b91b86eddc709a79106fe1518cce531 (HEAD -> master)

оцифровка сигнала радара

АЦП E-502

Нагрузка детекторной головки

Проблема

Детекторная головка требует шунтирования резистором на землю. Если роль резистора играет аттенюатор на выходе головки -- появляются непонятные колебания сигнала частотой ~ 100кГц.! Без непонятных помех: !

Анализ

Колебания появляются также при подключении терминатора 50 Ом посередине кабеля от головки к осциллографу, в т.ч. при парралельном соединении АЦП и осциллографа. Однако, пропадают при подключении терминатора через тройник непосредственно на входе осциллографа или переключении входа осциллографа на 50 Ом. При подключении осциллографа щупом к аттенюатору -- проблема не решается.

Решение

Поставить аттенюатор непосредственно на вход осла и АЦП?

Сделать обработка данных на blackfin в АЦП подготовка

14 KiB Raw Permalink Blame History Unescape Escape

1

Контроль температуры во время TASK.

Проблема

Анализ

Быстрый фикс:

Нормальное решение

Варьирование тока в прерывании

Что такое Temp_ext_1/2?

синхронное детектирование

Кривые тайминги варьирования тока

Проблема:

анализ

В коде GUI:

В коде MCU:

решение

Клоки для модулятора и АЦП недетерменированно выключаются в конце ЛЧМ.

Проблема

анализ

решение

Вариант 0

Вариант 1.

Вариант 2. Реализован

настройка таймингов модулятора и АПЦ

Проблема

Анализ

Решение

развитие

оцифровка сигнала радара

Нагрузка детекторной головки

Проблема

Анализ

Решение

Сделать обработка данных на blackfin в АЦП подготовка

Проблема

Анализ

Решение

Проблема

Анализ

Решение

Проблема

Анализ

Решение

14 KiB

Raw Permalink Blame History