Univelis / Foxspeed

Пост от @swiftfoxx! Недавно была новость, что похакали ESP32 в плане доступа к радиочасти. Немного в этом решил разобраться. Итак, есть 2 основных проекта. 1. https://espargos.net/espsdr Просто гениальная штука, превращающая ESPшку в два клика в SDR приемник. Причем в 2 клика — это не особо преувеличение, прошивает прямо из браузера, там же SDR. Возможности — прием до 80 Ms/s в полосе примерно с 1,7 до 2,8 ГГц. Причем реально, характерные сигналы GSM1800 наблюдал лично. Минусы — минимальная полоса 16 МГц, а наружу отдает через юарт, с помощью этого проекта можно получить полосу 250кГц и виде IQ после децимации или же реализовывать обработку сигнала внутри самому. Причем обработка не совсем тривиальная, переварить 16 Ms/s надо постараться. Из плюсов - настраиваемый аналоговый фильтр, минимальная полоса 13 МГц. 2. https://github.com/whstudio123/esp32-iq-tx Некоторые эксперименты по скармливанию сырого IQ потока в трансивер. Ограничения тут значительно серьезнее. 40 или 80 MHz, данные идут из SRAM буфера размером до 16128 отсчетов. Причем во время работы передатчика доступа к буферу нет. Воспроизводиться буфер может или циклически или один раз. Потом остановка, подготовка нового буфера, повторная передача. На частоте 40 MHz максимальный размер буфера по времени чуть больше 400мкс. Для генерации всяких сигналов в циклическом режиме подходит, для передачи данных с трудом. Суть натурного эксперимента. Передатчик Модуляция QPSK, 150 ксимв/с, 8 символов преамбула, 4 символа пилот, потом 32 бита константа, 32 бита счетчик пакетов, контрольная сумма CRC16, длительность IQ буфера 16000 отсчетов, 400 мкс весь пакет. Полоса около 200 кГц, как раз чтобы уложиться в оба проекта. Частота — 14 канал WiFi + сдвиг в пару мегагерц. Подготовка пакета занимала около 4мс, отправка каждые 10мс. Прошито на плату с ESP32 c PCB антенной. Приёмник. Прошивка espsdr, отдает поток в 250ks/s питон скрипту. Плата Xiao-esp32-s3 с FPC антенной. На си реализован простой QPSK декодер, поверх питон, настройки (усиление, CFO, RRC декодера) вынесены в веб-интерфейс, туда же статистика приема. Ход эксперимента. Приёмник на окне на возвышенности, передатчик в кармане, прием контролируется через веб-интерфейс. Антенн нет, но только прямая видимость. Результаты Максимальная проверенная дальность — 1 км, прием стабильный, целыми пришло около 70% пакетов, еще 20-25% с ошибками CRC, если использовать FEC, то можно думаю получить около 90% пакетов. Любое препятствие, нарушающее прямую видимость практически полностью убивает прием. Внутри здания пробивает не более 4 этажей, одна лишняя стена и прием падает с 50% до 0% Наиболее устойчивый прием наблюдался при ручной настройке усиления на максимум. Это значит, что есть шансы подключив антенну с большим коэффициентом усиления добиться увеличения дальности, помехи (а они дичайшие, центр города с кучей вайфай сетей), не являются ограничивающим фактором. Аналоговый фильтр тут зарешал, стоило только чуть-чуть отстроиться от самого загруженного участка, при этом даже формально не уходя за пределы WiFi ISM диапазона. Приёмник показал достаточно сильный температурный дрейф, при изменении температуры на 20 градусов сдвиг CFO изменился с 25 до 50 кГц. Это пришлось учесть в декодере QPSK. Насчёт долгой подготовки (4 мс ради передачи 400 мкс): там суровый матан формирования QPSK с RRC фильтром плюс потом переквантование в формат, который жрёт передатчик. Обошлось без тригонометрии, заранее подготовленные таблицы именно для этого частотного сдвига, но все равно вычислений много. Полностью табличный синтез затруднен, так как из-за RRC фильтра нужно учитывать несколько соседних символов, таблица получается слишком большая для всех комбинаций. В теории можно ускорить, оптимизировать, может выкинуть RRC фильтр, ограничивающий полосу на момент переключения символа, но будет срань. ===== Это опыты @swiftfoxx! Также, другие исследователи подняли OFDM с 16QAM, аппаратное расписание TX-бёрстов без CPU, и непрерывный IQ-поток через внешнюю ПЛИС. Идёт активное развитие, следим :3

Любой современный радиочип — это странный, ограниченный и неудобный приёмопередатчик с кучей HW блоков обработки потока и интерфейсом наружу. К счастью, инженеры добавляют захват и выдачу сырых данных оцифровки эфира для отладки. И ведь это всё, что нам нужно, чтобы сделать железку для SDR! Лимиты радиотрактов, отладки и наружных интерфейсов не исчезли, но инженерные режимы найдены уже в многих чипах. RTL-SDR в своё время появился так же: оказалось, что дешёвый ТВ-тюнер умеет отдавать IQ-поток вместо декодинга DVB-T ТВ. • Команда ESPARGOS нашла отладочный путь к входным АЦП в большинстве ESP32 с Wi-Fi: до 80 Msps, 8/10-битные IQ, диапазон от 1.85 до 2.8 ГГц, + 5 ГГц у C5. Скорости USB/UART хватало лишь на короткие записи, но уже умеют считать FFT прямо на чипе, S3 отдаёт 250 ksps, а новый S31 добрался до невероятных 40 Msps через 1GbE. И что забавно, уровень шума НИЖЕ, чем у HackRF! • LoRa-трансивер LR2021 превратили в приёмник 100..2740 МГц, хотя даташит обещал лишь 150..960 + 1500..2500 МГц. Доступны 16-битные семплы, к нему приклеивают ESP32-P4 и передают инфу на 500 kSPS или 800 kSPS при 8 битах. SoapySDR работает. • Дешёвый USB3.0-Wi-Fi адаптер на MT7921AU настраивается в 2160..2610 МГц, и выдаёт 40 Msps на 14 бит. • Wi-Fi 7 роутер Gemtek W1700K на чипе MediaTek MT7996 отдаёт умопомрачительные 320 Msps на 14 битах IQ, т.е. почти полный диапазон Wi-Fi одним махом. Поток выходит через 10GbE. Для сравнения: HackRF даёт 20 Msps @ 8 бит, XTRX — 120 Msps @ 12b. А передача? В чипах обычно есть тестовые генераторы сигналов с быстрым управлением; на ESP32-S3 и LR2021 это уже работает. А что раньше? Всё выше — довольно свежие проекты, конечно рутину они тащили через LLM (ESPARGOS так и говорит). Но и раньше были подобные проекты. • Broadcom BCM4339 / BCM43455: SEEMOO Lab ещё в 2018 нашли в чипах память Template RAM, из которой можно воспроизводить IQ-записи. И самый прикол, что это Wi-Fi-чипы Nexus 5 и Raspberry Pi 3 B+. • Qualcomm Atheros AR92xx / AR93xx / ath10k — инфа найдена давно, но только после FFT. Так что это хороший быстрый спектроанализатор, а не SDR, фаза уже потеряна. Сколько ещё чипов скрывают IQ-capture, особенно с быстрым цифровым PHY и RAM внутри для семплов... The next big thing?

На пути МКС внезапно построили дом, так что пока 0 резалтов: четыре пролёта, в т.ч. 32° и 41°, ни одной картинки, и даже глубокое вкапывание в IQ семплы не помогло. Причина пока не ясна окончательно, но буду исследовать, есть зацепки, как минимум то, что у меня всего 10 разных значений во всех IQ семплах — видимо, улисение было недостаточным. Но был смешной момент: @Ir_192 скинул свежий видос с ютуба, как человек в поле принимает. Я глянул и закрыл, ибо спойлер. Пошёл настраивать цепочку приёма дальше, А НА СТРАНИЦЕ ПРИËМНИКА ИДЕАЛЬНАЯ КАРТИНКА (у меня веб-приёмник SSTV)! Думаю, что за магия: я же при приёме слышал только шум, а картинка вот. Ага, тулза услышала звук видоса и распознала :D причём даже лучше, чем прога в видосе, меньше шума цвета. Два часа гнул Франклина, согласовывал Super J-Pole по LibreVNA, поднимал GNU Radio, боролся с маршрутизацией звука в macOS через BlackHole, не спал всю ночь… чтобы первую картинку с МКС получить от YouTube, случайно декодировав чужой видос. Ваще ожидаемо, что у меня с первого раза не получилось. @Ir_192 занимается этим дольше, и вот какую картинку он принял. Буду пробовать дальше, чтобы тоже получилось :) Теперь мне нужна домашняя спутниковая станция: к 70-летию Спутника-1 в 2027 надо подготовиться основательно.

Антенна на 437.5 готова, ждём МКС 🎹 Легко сделать такую же: • Раздень 140 см провода ВВГ (моножильный), у меня 2.5 мм². • Гни 332 мм — 90° R3 — 166 мм — 180° R6 — 166 мм назад — 90° R3 — 498 мм — 180° R15 — 166 мм. т.е. два луча 332 и 498 мм коллинеарно, между ними петля 166 мм и обратно для сдвига фазы, и внизу J-согласующий шлейф. С другой т.з. это два луча по 332 мм с поворотом фазы, а к нижнему приделан U-образный шлейф длиной 166. • Петлю можно загнуть вокруг оси. • Продень метр коаксиала через ферритовый бочонок от любого компьютерного кабеля. • От нижней точки U-шлейфа отступи 24 мм, паяй землю коакса на этот короткий конец, а центр на антенну. • Бочонок крепи вплотную к точке пайки, но не касаясь антенны. • Клей на окно. Медь плотнее касается стекла = ниже резонанс. Работа займёт час. Вот эта штука будет резонировать на 437-440, и позволит всё принять. А дальше в SDR и в комп.

КОСМОС НА СВЯЗИ! 🛰 Доставайте свои yagis и decoders, сегодня последняя ночь приёма! Я чуть не пропустил: МКС прямо сейчас передаёт фоточки, и принять их может каждый с SDR и куском кабеля. 437.550 МГц ± допплер 10 кГц, протокол SSTV Robot 36, на МКС передатчик до 10 Вт. Лучше всего писать в GNU Radio raw сигнал, потом обработаете (я так и сделаю). Из провода ВВГ гнём антенну, гнём радио, и принимаем. Передачу продлили до 26 октября 20:45 МСК, так что для Москвы осталось 4 окна: 02:05, 03:39, 05:15 и 06:52, все этой ночью. Как участвовать: • Берём RTL-SDR, HackRF или радиостанцию с FM на 437 МГц • Делаем антенну — полуволновой диполь / петлевой вибратор / штырь с противовесами, или даже штатная антенна на 433 • Находим ближайший пролёт по heavens-above.com • Принимаем FM, декодируем звук через Robot36 или QSSTV • Отправляем картинку в галерею ARISS, получаем сертификат Я уже достал свой HackRF и медную проволоку, если получится, обязательно выложу. https://www.ariss.org/upcoming-sstv-events.html

Новости #радиотелескоп — лютый прогресс по каждой части! Приём настроек: я говорил, что приём невозможен, мне нечем принимать на скорости 100 Мбит/с; а нифига: из PHY торчит линия RX_DV, при приёме пакета она поднята. Догадались? Сервер посылает мусорные пакеты, стмка меряет их длину. Короткий/длинный, точка/тире :D Или 2, 4 или 8 разных длин для кодирования битов. Или формировать пакеты так, чтобы в payload один бит медленно менялся, за 1500 байт можно успеть. Тюнинг тюнера: мой жукостенд всё же развалился, и я стал тратить больше времени на его починку, чем на опыты; проще уже заказать плату, тем и занимаюсь сейчас. Тайных режимов найти у чипа не удалось, наоборот, нашёлся только баг (палка 10 МГц внутри), который помешает 12+ Msps режимам. Это плохо для отдельного продукта #SDR20, но радиотелескопу не мешает. Антенна: Алюминиевая композитная панель (Al-LDPE-Al) это не только прекрасный конструкционный лист для корпусов девайсов (изи обрабатывается и красиво гнётся), но и отличный материал для антенн: алюминий там довольно толстый (толще скин-слоя), а полиэтилен это нулевые диэлектрические потери. А ещё он дешёвый и множество контор его фрезеруют. Но как снять сигнал, оксид же мешает, и даже если его пробьём, он нарастёт снова, и контакт пропадёт? Ëмкостная связь: к точке фида патч-антенны площадка через тефлоновую плёнку. Она же заменит DC-blocking кондёр на входе МШУ и не внесёт потери; да и согласовать импеданс можно этой ёмкостью и L её ножки. Входной тракт: усилители с шумом меньше 0.5 дБ уже массовы и недороги. Мой сигнал очень слабый и помех рядом нет (патч-антенна частично отстроится от LTE), поэтому подключаю МШУ прямо на выход антенны. Одного улисителя мало, нужно два; второй уже можно перегрузить помехами, и между ними нужен фильтр. Я думал об объёмных резонаторах и микрополосковых СВЧ-фильтрах, всё это было несобираемо; а оказалось, что у меня под домом делают фильтры на поверхностных акустических волнах на 1420 МГц (и на многое другое) задёшево. Суммарный шум: в итоге кажется, что реально вытянуть шум входного тракта ниже 0.5 дБ, т.е. температура 35К, ниже чем 50К характерного шума водорода H I, а значит, SNR системы станет выше 0 дБ! Это ли не магия :) За кадром ещё много деталей — выбор LDO, фильтр на IF, моделирование антенны, передача и сбор инфы, корреляции на видеокарте — но про это потом.

Спустя некоторое время я получил чипы тюнеров RDA5815M, и практически без документации, по сорцам драйвера из линукса запустил их. Первый экземпляр это нейрохирургия уровня "подковать блоху" QFN20 с шагом 0.4 мм. Такой эксперимент: - HackRF отправляет несущую RF=1090.350 МГц без модуляции - RDA5815M настроен на LO=1090.000 МГц от 25 МГц генератора - Он выделяет IF=0.350 МГц. На осциллограмме IP, IN, QP, QN. Зачем из 1 антенны получать 4 сигнала? Чтобы сохранить фазу. Перенос частоты — разрушающее преобразование, теряет фазу. Формула умножения синусов: sin(a)*sin(b) = (cos(a–b)–cos(a+b))/2. a и b — аргументы RF и LO, содержащие частоту и фазу. После умножения появляются две компоненты: сумма частот RF+LO и разность RF−LO. Сумму мы в радиоприёме отфильтруем, поскольку хотим понизить частоту. Фаза не теряется, но становится суммой фазы RF и LO. Большая проблема: такой вещественный смеситель не отличит "сигнал на 1 ГГц ниже LO" от "сигнала на 1 ГГц выше LO". И 60° от 120° отличить нельзя: их синусы, как проекции на Y, равны. Что делать? Элементарно: проецировать ещё и на ось X. Сделаем два LO, под 0° и под 90°, и будем умножать RF на них по отдельности. Из таких сигналов, I (in-phase) + Q (quadrature), легко восстановить фазу, работая не с одним синусом, а с комплексным I+jQ. Сигнала уже два, но откуда тогда четыре? I и Q тюнер выдаёт не просто так, а в дифференциальном виде, чтобы подавить синфазные помехи и увеличить размах: IP–IN=I, QP–QN=Q. На осциллограмме видно: каналы 1–2 противофазны, 3–4 тоже, а между I и Q — сдвиг на 90°. Всё как хотели! Теперь вычесть P–N, добавить антиалиасинговый ФНЧ, принять I/Q в STM32 и отправить по Ethernet, что мы уже умеем. Ещё один кусочек будущего радиотелескопа сделан и работает. Без ChatGPT и Codex я бы, наверное, вообще за это не взялся. А теперь оно живое. :)

- DualSPI (2-битный режим QuadSPI) готов - оцифровка 3 из 4 АЦП готова (в 4 проблема с Nucleo) - 27% idle, которое можно тратить на другие дела Принимаю аналоговые сигналы на компе по Ethernet. Это и есть мой SDR20 для радиотелескопа :)

Все сотни функций микроконтроллеров — порты, таймеры, интерфейсы, аналоговые штуки для сигналов реального мира — реализуются IP-ядрами, и в мире есть компании, занятые только разработкой (не производством!) этих ядер: Synopsys и Cadence. Arm занимается процессорными ядрами, памятью и DMA (и лицензирование, ммм). Но это того стоит; разработка и отладка такого ядра вручную будет дольше и дороже. Простые штуки типа SPI же пишут сами. Каждая новая модель МК это в основном новый набор модулей и путь для вендор-лока: модули от одного поставщика IP это знакомый интерфейс и набор багов, а если МК-мейкер написал хорошие драйвера, то к ним привыкаешь мгновенно. Но это же и путь для манипуляций: поставим вам классные модули, но забудем один. ST чётко разделяет семейства для коммуникаций и для смешанных сигналов. В 2026 уже очевидно, что самое интересное всегда возникает на стыке областей; думаю, ограничение искусственное. Причём есть серия STM32H, где разделение сглажено, и собрано почти всё; но там и много лишнего, и огромные корпуса, и цена... Для моих микродевайсов не катит. Ещё и АЦП всего 3 штуки. Ощущается несправедливость! Попробуем решить её сами :D Хейтеры скажут: есть USB, юзай его, на то он и universal. Но USB это широкий спектр помех, архитектура "мастер-слейв" и большой тяжёлый стек протокола. Для задачи "слать данные на максимуме скорости и не шуметь на АЦП" не подходит совсем; и кстати, у 12 мбит/с USB FS не хватит скорости.

Классическая история, как мы в селфдрайвинге яндекса поймали дикие помехи на GNSS-антенну от камерного USB3.0, а камер много и кабели длинные, в итоге позиционирование деградировало почти в ноль. Переход на GMSL и 10G оптику решил всё.

Но есть модуль QUADSPI: взяли обычный SPI (3 провода, клок CLK, данные туда Out, данные оттуда In, и выбор чипа CS), сделали 4 линии данных двунаправленными: CLK, [IO0, IO1, IO2, IO3], nCS; разогнали до 110 МГц и добавили DDR режим. Используется для памяти, и добавлены фичи контроля и отображения на память (это не просто труба данных, как SPI). С другой стороны, стандартный интерфейс MII для Ethernet микросхем это rx/tx клок + 4 бита данных RX + 4 RX, сигналы валидности инфы и медленный канал настройки SMI (похож к I2C или SWD). RMII это вообще 1 общий клок + 2 TX + 2 RX. Похоже же? Берём O0+O1 как TXD0+TXD1, и CLK как NET_CLK. К сожалению, QUADSPI нельзя завести в две стороны как [O0, O1, I2, I3], поэтому напрямую это даёт только приём или передачу; мне нужна передача, поэтому мне хватит :) Важный момент: NET_CLK задаёт не только тактирование данных MII, но и работу всего чипа ETH PHY, поэтому CLK должен работать постоянно. QUADSPI обычно выключает CLK, если буфер на передачу пуст, и между кадрами мы потеряем линк; обязательно нужно перевести его в режим постоянной передачи: бесконечная транзакция и кольцевой DMA. На время IPG (пауза между пакетами, 96 бит = 0.96 мкс) продолжаем слать нули, только снимаем TX_EN. Сложность только с линией валидности данных TX_EN: она должна меняться в точные моменты времени; слать данные на большой скорости нужно через DMA, а дёргать отдельную линию синхронно с DMA в общем случае сложно. Поэтому лучше интегрировать этот сигнал прямо в данные. У нас есть 4 линии передачи: 2 пойдут под данные, а третья станет TX_EN. Тогда придётся немного поработать над подготовкой данных, и это потратит время, но упростит ситуацию. Альтернатива: модуль умеет управлять пином CS, хоть и негибко, ещё и инверсия; лучше таймером, хотя и неудобно, как я упоминал. Зато модуль сам разложит данные по парам битов, мы сэкономим время на подготовке нибблов и сэкономим пины: переведём модуль в режим dualSPI на 2 пина IO, остальные 2 пина пойдут на АЦП, ОУ или куда-то ещё. Ещё одна проблема это контрольная сумма. Мы привыкли, что в UDP пакетах чек-сумма необязательна, всё и так примется; но это только потому, что в конце пакета Ethernet есть своя контрольная сумма FCS (Frame Check Sequence), и её всегда достаточно. Но тут мы сидим на самом низу стека протоколов, и вынуждены реализовывать всё. Благо, модуль CRC возьмёт это на себя и вычислит сумму почти без нагрузки на ядро, нам остаётся положить её в конец пакета. lwIP стек здесь не нужен, раз мы склеиваем пакеты вручную; можем слать хоть сырые пакеты (AF_PACKET в линуксе), но ничего не мешает обернуть это в UDP пакет, это не добавляет нагрузки. Очевидная проблема в том, что все эти преобразования, особенно разрезание байтов занимают время; и да, даже при работе на 150 МГц остаётся всего 33% свободного времени. Хотя отправка данных АЦП не требует больших вычислений. Насчёт приёма: думаю, что можно завести обычный SPI на приём с RXD0, потерять половину инфы, но специальная подготовка пакетов на стороне компа это до известной степени нивелирует; можно и два SPI завести на приём, но потом склеивать эти потоки будет не очень удобно. В любом случае, это выглядит реальным; думаю, так и lwIP заведётся. Крайне важно: PHY микросхема в общем случае не выдержит отсутствие RX пары в Ethernet кабеле; хоть мы и только передаём, нам скорее всего придётся иметь полный кабель с двумя парами. Некоторые PHY (например, DP83825I от TI) умеют работать без RX пары установкой специального бита, но это не общее место. В любом случае, ETH PHY остаётся полнофункциональным, мы лишь реализуем часть функций MAC. Ну и основная (ранее) функция MAC (контроль среды, сосуществование) тут естественно не заложена, раз у нас только передача на максимальной скорости. Но в 2026 Ethernet это только точка-точка, CSMA/CD уже не нужен. Никакого ARP и DHCP нет, MAC/IP заданы жёстко, но вот unicast/broadcast доступны. Так реализован 100MbE, который работает на 99.5 Мбит/с пропускной способности, возможно и больше (не тестил, но это же уже 99.5%!) и 95.2 Мбит/с данных UDP, проходит через свитчи и принимается USB-Eth адаптерами и нативными Ethernet-портами, а значит, полностью корректен. Ещё не проверены DualSPI, RX через два SPI и сосуществование с 4 АЦП — но приём мне некритичен, DualSPI проверяю прямо сейчас, а АЦП запущу на днях, когда подкую блоху тюнера.

Все сотни функций микроконтроллеров — порты, таймеры, интерфейсы, аналоговые штуки для сигналов реального мира — реализуются IP-ядрами, и в мире есть компании, занятые только разработкой (не производством!) этих ядер: Synopsys и Cadence. Arm занимается процессорными ядрами, памятью и DMA (и лицензирование, ммм). Но это того стоит; разработка и отладка такого ядра вручную будет дольше и дороже. Простые штуки типа SPI же пишут сами. Каждая новая модель МК это в основном новый набор модулей и путь для вендор-лока: модули от одного поставщика IP это знакомый интерфейс и набор багов, а если МК-мейкер написал хорошие драйвера, то к ним привыкаешь мгновенно. Но это же и путь для манипуляций: поставим вам классные модули, но забудем один. ST чётко разделяет семейства для коммуникаций и для смешанных сигналов. В 2026 уже очевидно, что самое интересное всегда возникает на стыке областей; думаю, ограничение искусственное. Причём есть серия STM32H, где разделение сглажено, и собрано почти всё; но там и много лишнего, и огромные корпуса, и цена... Для моих микродевайсов не катит. Ещё и АЦП всего 3 штуки. Ощущается несправедливость! Попробуем решить её сами :D Хейтеры скажут: есть USB, юзай его, на то он и universal. Но USB это широкий спектр помех, архитектура "мастер-слейв" и большой тяжёлый стек протокола. Для задачи "слать данные на максимуме скорости и не шуметь на АЦП" не подходит совсем; и кстати, у 12 мбит/с USB FS не хватит скорости.

Классическая история, как мы в селфдрайвинге яндекса поймали дикие помехи на GNSS-антенну от камерного USB3.0, а камер много и кабели длинные, в итоге позиционирование деградировало почти в ноль. Переход на GMSL и 10G оптику решил всё.

Но есть модуль QUADSPI: взяли обычный SPI (3 провода, клок CLK, данные туда Out, данные оттуда In, и выбор чипа CS), сделали 4 линии данных двунаправленными: CLK, [IO0, IO1, IO2, IO3], nCS; разогнали до 110 МГц и добавили DDR режим. Используется для памяти, и добавлены фичи контроля и отображения на память (это не просто труба данных, как SPI). С другой стороны, стандартный интерфейс MII для Ethernet микросхем это rx/tx клок + 4 бита данных RX + 4 RX, сигналы валидности инфы и медленный канал настройки SMI (похож к I2C или SWD). RMII это вообще 1 общий клок + 2 TX + 2 RX. Похоже же? Берём O0+O1 как TXD0+TXD1, и CLK как NET_CLK. К сожалению, QUADSPI нельзя завести в две стороны как [O0, O1, I2, I3], поэтому напрямую это даёт только приём или передачу; мне нужна передача, поэтому мне хватит :) Важный момент: NET_CLK задаёт не только тактирование данных MII, но и работу всего чипа ETH PHY, поэтому CLK должен работать постоянно. QUADSPI обычно выключает CLK, если буфер на передачу пуст, и между кадрами мы потеряем линк; обязательно нужно перевести его в режим постоянной передачи: бесконечная транзакция и кольцевой DMA. На время IPG (пауза между пакетами, 96 бит = 0.96 мкс) продолжаем слать нули, только снимаем TX_EN. Сложность только с линией валидности данных TX_EN: она должна меняться в точные моменты времени; слать данные на большой скорости нужно через DMA, а дёргать отдельную линию синхронно с DMA в общем случае сложно. Поэтому лучше интегрировать этот сигнал прямо в данные. У нас есть 4 линии передачи: 2 пойдут под данные, а третья станет TX_EN. Тогда придётся немного поработать над подготовкой данных, и это потратит время, но упростит ситуацию. Альтернатива: модуль умеет управлять пином CS, хоть и негибко, ещё и инверсия; лучше таймером, хотя и неудобно, как я упоминал. Зато модуль сам разложит данные по парам битов, мы сэкономим время на подготовке нибблов и сэкономим пины: переведём модуль в режим dualSPI на 2 пина IO, остальные 2 пина пойдут на АЦП, ОУ или куда-то ещё. Ещё одна проблема это контрольная сумма. Мы привыкли, что в UDP пакетах чек-сумма необязательна, всё и так примется; но это только потому, что в конце пакета Ethernet есть своя контрольная сумма FCS (Frame Check Sequence), и её всегда достаточно. Но тут мы сидим на самом низу стека протоколов, и вынуждены реализовывать всё. Благо, модуль CRC возьмёт это на себя и вычислит сумму почти без нагрузки на ядро, нам остаётся положить её в конец пакета. lwIP стек здесь не нужен, раз мы склеиваем пакеты вручную; можем слать хоть сырые пакеты (AF_PACKET в линуксе), но ничего не мешает обернуть это в UDP пакет, это не добавляет нагрузки. Очевидная проблема в том, что все эти преобразования, особенно разрезание байтов занимают время; и да, даже при работе на 150 МГц остаётся всего 33% свободного времени. Хотя отправка данных АЦП не требует больших вычислений. Насчёт приёма: думаю, что можно завести обычный SPI на приём с RXD0, потерять половину инфы, но специальная подготовка пакетов на стороне компа это до известной степени нивелирует; можно и два SPI завести на приём, но потом склеивать эти потоки будет не очень удобно. В любом случае, это выглядит реальным; думаю, так и lwIP заведётся. Крайне важно: PHY микросхема в общем случае не выдержит отсутствие RX пары в Ethernet кабеле; хоть мы и только передаём, нам скорее всего придётся иметь полный кабель с двумя парами. Некоторые PHY (например, DP83825I от TI) умеют работать без RX пары установкой специального бита, но это не общее место. В любом случае, ETH PHY остаётся полнофункциональным, мы лишь реализуем часть функций MAC. Ну и основная (ранее) функция MAC (контроль среды, сосуществование) тут естественно не заложена, раз у нас только передача на максимальной скорости. Но в 2026 Ethernet это только точка-точка, CSMA/CD уже не нужен. Никакого ARP и DHCP нет, MAC/IP заданы жёстко, но вот unicast/broadcast доступны. Так реализован 100MbE, который работает на 99.5 Мбит/с пропускной способности, возможно и больше (не тестил, но это же уже 99.5%!) и 95.2 Мбит/с данных UDP, проходит через свитчи и принимается USB-Eth адаптерами и нативными Ethernet-портами, а значит, полностью корректен. Ещё не проверены DualSPI, RX через два SPI и сосуществование с 4 АЦП — но приём мне некритичен, DualSPI проверяю прямо сейчас, а АЦП запущу на днях, когда подкую блоху тюнера.

Похоже, я первым в мире заявляю о реализации 100M Ethernet TX через QUADSPI в STM32. По крайней мере, других я не нашёл. Вот возьмём STM32G473/474: 5 АЦП по 12 бит и 4 млн выборок в секунду. Это же идеальный DAQ: можно хорошо оцифровывать 5 аналоговых сигналов на высокой скорости, даже синхронно ADC1/2 и ADC3/4, но данные некуда деть: из быстрых линков только QUADSPI для памяти, SPI на 75 Мбит/с и SAI, и ноль интерфейсов в комп (а USB неудобен по многим причинам). И тем не менее всё удалось. LAN8720 RMII подключен к QUADSPI: QUADSPI.CLK→LAN8720.CLKIN, D0→TXD0, D1→TXD1, D2→TX_EN. Ну и MDIO/MDC на GPIO, а D3 и nRST не используются. Стек типа lwIP не нужен: RX нет, а у TX пакета жёсткая структура. Пакету с Ethernet и UDP заголовками считаем CRC; каждый байт кадра режем на 4 пары битов и добавляем биты TX_EN и ∅. Этот поток 4-битных слов по DMA выходит через QUADSPI на 50 МГц с непрерывным клоком, и является RMII TX, родным для LAN8720! Да, там и преамбула, и SFD, и FCS/CRC, и межкадровая пауза IPG. Передаётся 99.5 Мбит/с, это 94 Мбит/с полезной нагрузки UDP. Пока что передаю тестовые данные, АЦП ещё нет; и конечно, всё это работает только на передачу, приём пока не реализован. На протяжении получаса на полной скорости ноль ошибок! Самое интересное, ресурсы: на 150 МГц SYSCLK весь механизм занимает 67% времени, 33% Idle остаётся на подготовку данных. FCS пакета считает CRC модуль, данные летят по DMA, код лежит в CCM: выжато уже многое, но запас оптимизаций ещё есть. Уже были проекты типа pico-10base, Pico-100BASE-TX и pico-rmii-ethernet_nce, но всё это на RP2040, а тут любимая STM32G474. Я не знаю, почему ST не поставили туда Ethernet модуль: говорят про помехи, но в LM3S ETH MAC и даже встроенный PHY отлично сосуществовал с ADC — а теперь потеря восстановлена :D

Карпаты рассказал, как завести мотоцикл

Мы пришли в интересное состояние, когда LLM топовых тиров почти перестали галлюцинировать, и ответственность целиком на операторе: галлюцинации уже не универсальное объяснение плохого ответа — лишь диагноз процесса вокруг неё :) По своим темам я видел галлюцинации только на самом старте. Теперь я почти уверен, что Гелл-Манн не про это. Если вы часто видите галлюцинации в ответах LLM, проверьте два варианта: 1. вы адово шарите в теме и работаете за пределами модели; 2. вы не шарите в общении с LLM. И скорее всего вы не 1. Если вы систематически получаете от frontier-моделей бред — скорее всего, проблема именно в вас. Люди почему-то общаются с LLM как с телепатом. "реши задачу <задача>", "а как будет <>", "как мне сделать <>". Пять слов, ноль контекста; ок, можно что-то достать из памяти о человеке, но у него же все запросы такие, там ничего не достанешь. Поэтому нейтронка выбирает простейшую интерпретацию, получает "нет", перестраивает рассуждения, отравляя контекст; опять "нет" с самым минимумом объяснений, и после пяти итераций у нас археологический слой говна. Чисто принцип GIGO: Garbage In → Garbage Out. Порой кажется, что люди намеренно пытаются дать минимум инфы и заставить её дать неподходящий ответ, только чтобы очередной раз "убедиться", что оно тупое и оскорбиться. Дай релевантную инфу, контекст, что ты сам пробовал и что нашёл. Граничные условия, исходники, что блин происходит вокруг твоего вопроса — и очень важно, что считать хорошим ответом. Поискать и проверить факты предложи, может целое исследование провести. Особенно забавно заставлять её писать код в чате, где ни среды, ни проекта, ни компилера, ни возможности прогнать тесты. На уроке информатики пишем алгоритмы в тетради, ага. Зато потом можно рассказывать, какая она тупая. Побольше инфы, побольше отвёрток (про инструментацию тут ещё будет, я всё готовлю эту тему), сомнений, перепроверок, харнесса, попытки опровергнуть свой же ответ, консилиума разных моделей, да в конце концов агенты сделают половину этой работы, хоть и дорого. Не раздувайте запрос человечьими интерфейсами (мой косяк), давайте супер-релевантную инфу сверхплотно. Используйте фреймворки — нет, не дебильное "ты CTO с 50-летним опытом, реши это", это никогда и не работало; вот атомы типа "найди тонкие места", "попробуй опровергнуть", "а что здесь может быть неверно" работают. И естественно не one-shot. А уточнения по пять слов это серия micro-one-shot, латание отравленного контекста и увод мыслей в сторону. Если уже совсем не туда ушло — соберите в контекст всё полезное найденное и начните новый чат. Да, сложно. Да, много работы. Это же вообще не вайб-кодинг! LLM — не оракул, а вычислительная система, крайне зависящая от harness. Вы обязаны сделать половину работы сами, или построить процесс проверки и подтверждения результата. Кстати, сюда же отлично ложатся крики про ИИ-обезьянок, которые лучше всего выучили кнопки Ctrl-C/Ctrl-V: для них ИИ это протез мозга, без него они уже никто, и за результат они не отвечают; они массово снимают с себя эпистемическую ответственность: не знают, почему результат правильный, и как его проверить, но всё равно считают работу выполненной. ИИ должен быть не протезом, а соавтором.

В Японии изобрели то, что очевидно любому человеку, видевшему вакууматор для одежды? Я довольно часто летаю, и вакууматор с пакетами у меня всегда с собой, не раз выручал (мама любит подарить пару новых полотенец :)

Рад показать проект, который делал всё лето: edige.xyz. Я меняю формат новостей электроники. Простых агрегаторов, дёргающих инфоповоды отовсюду, много. А моя система помнит, что происходило раньше, и связывает инженерные идеи между собой: в связях вся суть. EdigE читает инженерный инет — десятки источников, и их число растёт, — сохраняет исходники и строит свой коннектом. Сейчас на сайте уже 440 статей, 4000+ найденных материалов, а внутри базы полторы тысячи найденных связей. И нет, связи не просто по совпадению тегов :) Система читает посты и ищет, что поможет раскрыть тему, показать историю штуки или внезапное применение того же инженерного приёма. Например, начинаем с CIC-фильтра → проваливаемся в четыре SDR-приёмника на Cyclone IV → а оттуда в HackRF Pro и вопрос о том, как разменивать полосу на USB-трафик. Темы типичные для меня, а значит и для читателей канала: вокруг цифровой и СВЧ электроники, высоких напряжений, оптики и фотоники, радиотелескопов, иногда новых чипов (но оч редко, только если рил надо). Без слабого DIY и арадруин. И очень много чего о по типу "чо за нахер и почему это не я придумал?!" Каждый день движемся вперёд на сегодня и назад на неделю: достойные свежие новости сразу на сайт, а историю в архив. Старые статьи всплывут, когда это потребуется для раскрытия темы. История уже уходит до 01.01.2026, и продолжаем копать назад. Engineering Digest или Engineer Digs Electronics? :) https://edige.xyz

#иишница