Univelis / Foxspeed

Любой современный радиочип — это странный, ограниченный и неудобный приёмопередатчик с кучей 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

#иишница

NVIDIA покупает Hugging Face за $12'930'300'000. 129303 в десятичной это 1F917 в шестнадцатиричной. U+1F917 это 🤗 в Юникоде. А #129303🟩 — это css-код зелёного, близкого к цвету NVIDIA :)