U_K

Пробовал светить под углом, затем ставил оптический изолятор (Thorlabs IO-2D-633-VLP) между коллиматором и внешним ФД - колебания сохраняются, вот можно по ссылке график оценить при оптическом изоляторе: https://drive.google.com/file/d/1Zb4Q5rS3KO9VIputYsUbLzV7yNK_TrKg/view?usp=drive_link Так еще аккуратно грел феном ФД (~100*C), сигнал просто "уползает вверх" по амплитуде.

Т.е. эффект самонагрева/остывания сопротивления базы ФД вызывает автоколебания сигнала на нагрузке? Так температура окружающей среды дрейфует медленнее, чем период колебаний в сигнале. Если посмотреть на график "Laser_APC_mode" в описании исходной темы, то размах колебаний переменной составляющей ~0.001В при постоянном уровне ~0.14В, т.е. стабильность получается ~0.7%. В принципе если перевести +/-0,1 дБ в %, получаем диапазон 97.7...102.3%, т.е. разница около ~4.6%. В целом экспериментальная стабильность "умещается" в паспортную.

Есть, но измерения с другого дня, когда это делалось. В сигнале с внутреннего ФД в APC-режиме отсутствуют данные колебания, возможно из-за того, что контур "пытается" удержать этот сигнал на заданном уровне. Сам сигнал с внутреннего ФД снимался через трансимпедансный усилитель, расположенный в драйвере. Внутри S1FC635 стоит ЛД HL6320G, скорее не DFB, а FP(Фабри-Перо). Интерференция вследствие переотражения от резонатора, излучения с внешнего/внутреннего ФД?

Имеется лазер с оптоволоконным выходом - Thorlabs S1FC635, внутри одномодовый ЛД и драйвер с БП. Измеряется дневная стабильность мощности излучения, установка простая - излучение с волоконного разъема лазера попадает в коллиматор, далее на внешний ФД(S12915-1010R). Сигнал снимается с нагрузки ФД через 24-битную DAQ-систему. Вся установка на оптическом столе, мощность лазера установлена ~1мВт. Получено некоторое количество измерений, главный вопрос - причина(ы) колебаний мощности лазера в APC-режиме в низкочастотном диапазоне около 0,277...0,555 мГц?(см.графики) Что было проверено: 1)В ACC-режиме сигналы от внешнего ФД и внутреннего ФД (который внутри ЛД) практически одинаковы, думаю, что параметры внутреннего ФД не должны изменяться под воздействием самонагрева ЛД (1 мВт на выходе...) 2)Уставка драйвера лазера "плавает" от внешней температуры, но "медленнее", чем 0,277...0,555 мГц, и не повторяет динамику вышеуказанных колебаний. Предположения: 1)Изменяется количество лазерной мощности, поступающей в волокно, из-за позиционного дрейфа луча. 2)Чувствительность волокна к возможной низкочастотной механической деформации 3)Количество лазерной мощности, поступающей на внутренний ФД, меняется - но почему APC-контур не исправляет это? Ограничение коррекции на низких частотах? Или из-за отсутствия активной термостабилизации, температурная нестабильность ЛД вносит низкочастотное запаздывание в APC-контур? Прикрепил графики стабильности мощности в ACC-режиме, в APC-режиме и график измерения темп-ы окруж.среды, когда лазер был включен в APC-режиме. На всех графиках время указано в формате часов.

На фрагменте схемы можно посмотреть как соединен MII_INT с PWR/DN INT. В GPIO подтянул MII_INT к питанию - HAL_GPIO_WritePin(MII_INT_GPIO_Port, MII_INT_Pin, GPIO_PIN_SET);

Понадобилось выяснить внутреннюю стабильность тока драйвера

Лазер Thorlabs S1FC635, работает около 1.5 года (бывает даже круглосуточно), пока вроде в норме) Внутри лазерный диод HL6320G

По невнимательности написал, надо было R19 и C1, исправил... В простейшем интеграторе "+" обычно просто заземлен, а тут к нему прицеплены напряжения с 2-х точек Скажем так, Uset - напряжение с потенциометра ограниченное двумя повторителями на U1.1 и U2.2 (итого диапазон от 0В до 2В) + напряжение с "входа модуляции", уменьшенное в 0,4 раза (т.к. на этот вход может подаваться 0..5В, которые преобразуются в 0...2В) вот U1_3OUT - сигнал с трансимпедансного усилителя (усиленный сигнал фотодиода)

Производная или интеграл? Там же вроде интегратор находится А тогда получается, что -2.5В - "искусственная земля"? Тогда R34 - это нагрузка на землю, а R20 - это, как в инвертирующем усилителе, резистор на землю с "+"-ого входа?

Здравствуйте. Имеется схема драйвера для лазерного диода, восстановленная по плате (через Diptrace). Есть в схеме один фрагмент - см.картинку. Хотелось бы понять, какую роль выполняет ОУ U1.4. На его инвертирующий вход подается напряжение с фотодиода(встроен внутрь лазерного диода, предназначен для стабилизации мощности излучения). На неинвертирующий вход подается Uset - это напряжение с потенциометра, который регулирует мощность(находится на передней панели лазера) + к входу прицеплено через R20 отрицательное опорное напряжение. Так вот вопрос - U1.4 является дифференциальным усилителем, который вычисляет разницу между входами, причем один из входов интегрируется(R19 и C1 на схеме) или U1.4 выполняет роль интегратора с каким-то смещением? И какой примерно формулой будет определяться напряжение на выходе U1.4 в этом случае?

Наконец-то выяснил источник проблемы. При чтении регистра PHY_BMCR выдавалось 0x3900, так из этого значения получается, что PHY находится в POWER-DOWN режиме. Еще раз посмотрел на схему - пин PB14(MII_INT) у STM соединен с пином PWR_DN/INT у DP83848. Так вот, нужно было подтянуть в этом случае MII_INT к питанию. Cделал это в инициализации GPIO. Инициализация в HAL_ETH_Init теперь выдает HAL_OK (и бит SR в DMAMBR сбрасывается когда нужно, и бит link status в регистре BMSR у DP83848 устанавливается). И соотвественно ping есть. Вот так, очередной раз у меня из-за такой мелочи, не работало. Кто помогал - большое спасибо!

Из регистра PHY_BMCR (39 00) - Autonegation Enable, PHY-BMSR (78 49). На ПК, в Wireshark все то же самое, как и раньше(ПК спрашивает "Who has 192.168.1.1? Tell 192.168.1.192", но никто не отвечает). Светодиоды на разъеме Ethernet на плате - один горит постоянно, другой мигает периодически(когда ПК шлет данные). Локальная петля кабелем - в смысле закоротить TX и RX на кабеле, из МК что-то отправить через PHY и обратно через PHY принять?

В while (((heth->Instance)->DMABMR & ETH_DMABMR_SR) != (uint32_t)RESET) заккомментировал "return HAL_TIMEOUT" и добавил break. Бит SR в DMABMR стал сбрасываться - источник https://www.programmersought.com/article/52516336171/ Добрался до чтения регистра PHY_BSR (HAL_ETH_ReadPHYRegister(heth, PHY_BSR, &phyreg)) - теперь зависает в цикле while (((phyreg & PHY_LINKED_STATUS) != PHY_LINKED_STATUS)) Регистры у PHY читаются, все нормально. Проблема теперь в том, что бит LINK STATUS в PHY BSR не устанавливается.

Проверил перед циклом, все нормально, AHB Prescaler=1, после него 168МГц. Перед ним 168 МГц идет на Ethernet PTP clock, но однако из регистра RCC->AHB1ENR, Ethernet PTP clock disabled. Если что вот регистры: RCC->CR 03 03 87 83 HSEON=1(HSE clock enable) HSERDY=1(HSE clock ready flag) HSION=1(Internal high-speed clock enable) - если у нас внешнее тактирование, HSI вроде должен быть выключен? HSIRDY=1 PLLRDY=1(Main PLL (PLL) clock ready flag) PLLON=1( Main PLL (PLL) enable) RCC->PLLCFGR 04 40 54 19 PLLQ=4 PLLP=2 PLLN=336 PLLM=25 f(VCO)=25*336/25=336МГц f(PLL general clock output)=336/2=168МГц RCC->CFGR 00 00 94 0A RTCPRE 00000(no clock) PPRE2(APB2)=100(divided by 2) PPRE1(APB1)=101(divided by 4) HPRE(AHB)=0000(system clock not divided) SWS=10(PLL used as the system clock) SW=10(PLL selected as system clock)

Тактирование настроено на внешний кварц 25МГц, отдельный кварц, второй на плате(после кварца для PHY). В коде установлено HSE value = 25000000, регистры с тактированием STM уже проверял. У TX_CLK и RX_CLK амплитуда до 2.6В, может нужно хотя бы 3В?(Хотя возможно, амплитуда уменьшается из-за щупов для такой частоты)

как раз перед этим циклом проверяю

Проверил тактирование в регистрах, сверился с reference документом на STM, все установлено как нужно(включен альтернативный режим, выбраны альтернативные функции ETH для PA1(RX_CLK) и PC3(TX_CLK)). Если, что вот значения из регистров: RCC->AHB1ENR 0E 10 00 8F RCC->AHB1RSTR 00 00 00 00 GPIOA->MODER A8 00 80 AA GPIOC->MODER 00 05 AA A8 GPIOA->AFRL B0 00 BB BB GPIOC->AFRL 88 BB BB B0 На входах MII_RX_CLK и MII_TX_CLK, а также 25MHz_OUT у DP83848 генерация есть (по форме между синусом и квадратом), единственно тактовый сигнал в границах от 840мВ до 2.6В. По длительности импульсы 40нс, соответствует 25МГЦ. На линиях RX_CLK и TX_CLK стоят резисторы по 51 Ом, может тока маловато? Хоть и звучит как бред, но было у меня дело один раз с цифровым потенциометром - на SPI пришлось убрать резисторы, иначе команды потенциометр не воспринимал. P.S. попробовал без резисторов, не повлияло

Посмотрел инициализацию. В low_level_init(), функция HAL_ETH_Init(&heth) выдает HAL_TIMEOUT - зависает в цикле "while (((heth->Instance)->DMABMR & ETH_DMABMR_SR) != (uint32_t)RESET)" и через некоторое время, вылетает из него. По документации на STM, я так понял, не происходит программный сброс - MAC DMA controller должен сбросить все регистры MAC, после чего бит SR должен установиться в ноль в регистре DMABMR. В файле stm32f4xx_hal_eth.c по этому поводу написано, что сброса не происходит, потому что нет сигналов ETH_RX_CLK или ETH_TX_CLK, и нужно проверить PHY или конфигурацию GPIO. Странно, но сигналы RX_CLK и TX_CLK есть, и GPIO по десятому разу проверил.

MX_LWIP_Init() имеется, она же стандартно генерируется кубом

Посмотрел регистры из ETH_MMC, связанные с приемом (после условия "if (HAL_ETH_GetReceivedFrame(&heth) != HAL_OK"), которое находится в low_level_input): ETH->MMCRIR, ETH->MMCRIMR, ETH->MMCRFCECR, ETH->MMCRFAECR, ETH->MMCRFAECR, ETH->MMCRGUFCR - все по нулям, дефолтные значения. Проверил еще пару MAC-регистров - ETH->MACA0HR, ETH_MACA0LR - там тоже все как в документации на STM(reset value). В регистре ETH->MACCR значение отличается от стандартного - там в 2-м и 3-м битах единицы - Receiver, Transmitter enable. В ETH->MACDBGR(debug register) по нулям -> по документации MAC в idle-режиме(ожидания), буферы FIFO пусты, а на линиях данных нет сигналов. Получается, что периферия Ethernet не инициализировалась?

При включении платы, на линии RX_DV проходят положительные импульсы (длительность ~5мкс, бывает проскакивают 50мкс) синхронно с данными на линиях RXD0...RXD3(когда ПК шлет свое "Who has 192.....?"), т.е. DP83848 воспринимает данные с ПК. На RX_ER - ничего (только при включении появляется длинный положительный импульс и потом в ноль)

На ПК поставил 192.168.1.192, не пингуется.

Здравствуйте! Имеется разработанная плата с STM32F407VET6 и PHY DP83848 для реализации Ethernet-передачи(планируется TCP-клиент или сервер). STM32F407VET6 и DP83848 соединяются по MII-интерфейсу. Используется LWIP-стек. DP83848 тактируется от отдельного кварца на 25 МГц, микроконтроллер - также от отдельного на 25 МГц. Плата и ПК соединены напрямую по Ethernet-кабелю, без роутеров и маршрутизаторов. Проект был сгенерирован из CubeMx в Keil v5.27. Далее в цикл While() добавил MX_LWIP_Process(), скомпилировал, прошил. Основная проблема - МК не принимает данные от DP83848. Что было проверено/сделано: 1. Сверил все адреса регистров/значений из даташита на DP83848 с тем, что выдает CubeMx. Пришлось в некоторых местах исправить. 2. Проверил повторно схему, соответствие подключаемых выводов на обоих сторонах (STM32 и DP83848), еще раз сверился с требованиями по подключению DP83848 из даташита. 3. Проверил осциллографом сигналы на RXD0..RXD3 - имеются (т.е. DP83848 принимает сигналы с ПК, и передает затем STM32, но он их не воспринимает что-ли?), RX_CLK и TX_CLK - имеются, генерация от кварца есть. 4. Назначил IP адрес, маску и узел в настройках адаптера Ethernet на ПК. 5. Попытался понять, где же все-таки происходит "затык", прошелся последовательно по функциям: While() -> MX_LWIP_Process() -> ethernetif_input(&gnetif) -> low_level_input(netif) -> HAL_ETH_GetReceivedFrame(&heth). В функции HAL_ETH_GetReceivedFrame(&heth) есть условие: if(((heth->RxDesc->Status & ETH_DMARXDESC_OWN) == (uint32_t)RESET)), в него программа не заходит. Подумал, что возможно что-то с DMA, но так и не получилось понять. 6. Хотел проверить в RMII-режиме - схема и разводка платы не позволяет (P.S.- Хотя конечно, можно настроить "нестандартно" тактирование STM32, пустить 50 МГц с MCO на RX_CLK и X1 у DP83848 через доп.провода) После вышеописанных действий результата нет. Скриншоты с настройкой из CubeMx прикрепил. Также прикрепил пару скриншотов из WireShark, скриншоты "фейкового" пинга из командной строки и общих настроек LWIP. В WireShark видно, что ПК постоянно спрашивает "Who has 192.168.1.1.?", а плата шлет какие-то запросы (наверно связаны с автосогласованием при включении DP83848), но не слышит ПК. Я понимаю, что применять CubeMX не очень "рационально", но имеется потребность в кратчайшие сроки реализовать связь по Ethernet для передачи данных. Буду рад любым подсказкам.