SDR изнутри: почему прошивка имеет значение
Развенчиваем мифы о «глупой коробке» в мире OpenHPSDR
Автор: Юрий, EU2AV
Введение: споры, которые переодически возникают
На радиолюбительских форумах периодически вспыхивают дискуссии: «Влияет ли прошивка FPGA на качество приёма и передачи?» Недавнее обсуждение на одном из форумов показало, что многие операторы считают SDR-трансивер (Orion, Hermes и другие платформы OpenHPSDR) всего лишь «RF-устройством», которое просто оцифровывает сигнал, а вся «магия» происходит в программе на ПК — Thetis, PowerSDR или другой.
Цитата из обсуждения: (можно часто услышать)
«Вся обработка сигналов такого рода происходит в Thetis….»
Звучит убедительно? На первый взгляд — да. Но давайте разберёмся, что на самом деле происходит внутри вашей «коробки», и почему прошивка Protocol 2 (P2) для платформ OpenHPSDR (Orion, Anvelina PRO3, и др.) — это не просто «драйвер», а сердце всей системы.
Архитектура SDR: три уровня обработки
Современный SDR-трансивер на базе OpenHPSDR — это трёхуровневая система, где каждый уровень выполняет свою незаменимую работу.
Уровень 1: Аналоговый тракт (RF)
1. Антенна → Аттенюатор → УВЧ → Фильтры → АЦП
Здесь сигнал из эфира проходит предварительную подготовку:
- Аттенюатор защищает от перегрузки в случиях с сильными сигналами
- УВЧ усиливает слабый сигнал
- Фильтры отсекают внеполосные помехи
- АЦП (LTC2208) — критический элемент: здесь аналоговый сигнал становится цифровым потоком с частотой дискретизации 122.88 MSPS (миллионов выборок в секунду)
Важно: После АЦП сигнал уже цифровой и больше никогда не вернётся в аналоговую форму (до момента передачи).
Уровень 2: Цифровая обработка в FPGA (REAL-TIME)
Вот здесь находится «мозг» системы. ПЛИС (FPGA) Cyclone IV/V выполняет задачи, которые физически невозможно перенести на ПК:
Почему FPGA, а не ПК?
| Параметр | FPGA | ПК (даже мощный) |
|---|---|---|
| Частота обработки | 122.88 MHz (параллельно) | Ограничена USB/Ethernet и ОС |
| Детерминизм | Жёсткие тайминги, наносекунды | ОС Windows/Linux — недетерминирована |
| Параллелизм | Десятки блоков работают одновременно | Последовательная обработка |
Что делает FPGA в реальном времени:
| Блок | Функция | Почему нельзя на ПК |
|---|---|---|
| DDC (Digital Down Converter) | Перенос сигнала с 122.88 MHz на базу (0 Hz) | Требует обработки каждого из 122.88 миллионов отсчётов в секунду |
| CIC-фильтры | Децимация (понижение частоты) в 640 раз | Должны работать на входной частоте, иначе данные потеряются |
| FIR-фильтры | Формирование полосы, подавление алиасинга | Критичны к задержкам, требуют детерминированной работы |
| CORDIC | Выделение I/Q-компонент, поворот фазы | Математика в реальном времени, параллельная обработка 8+ каналов |
| Тактирование (PLL) | Распределение клоков, синхронизация | Физический уровень, невозможно эмулировать в ПО |
| Сетевой стек | Формирование UDP-пакетов, DHCP, ARP | Должен работать на скорости линии (Gigabit Ethernet) |
| CW-ключ | Формирование точек/тире с точностью до мкс | Требует жёстких таймингов, недостижимых через USB/сеть |
| PureSignal | Предыскажение для линейности PA | Требует синхронизации основного и feedback-каналов |
Ключевая цифра:
FPGA обрабатывает 122.88 миллиона выборок в секунду. После децимации (CIC ×640) на ПК уходит к примеру поток 192 kSPS — это в 640 раз меньше данных!
Без FPGA ПК должен был бы принимать поток 122.88 MSPS × 16 бит × 2 канала = 3.9 Гбит/с — это предел возможностей USB 3.0, и никакой процессор не смог бы обрабатывать это в реальном времени для 8+ приёмников одновременно.
Уровень 3: Обработка на ПК (не real-time, high-level)
Что делает Thetis/PowerSDR:
| Задача | Описание |
|---|---|
| Приём UDP-пакетов | Получение уже обработанных I/Q-данных (после децимации!) |
| Аудио-DSP | Noise reduction (NR2/NR4), AGC, эквалайзеры, дополнительные фильтры |
| Визуализация | Панорама, водопад, S-метр |
| UI/UX | Ручки, кнопки, настройки, профили, макросы |
| Управление | Отправка команд в FPGA (частота, режим, gain, аттенюатор) |
| Модуляция (TX) | Формирование I/Q-потока для передачи (SSB, CW, digital modes) |
Важно понимать: ПК получает уже подготовленный, очищенный и децимированный поток. Вся тяжёлая работа по первичной обработке уже сделана в FPGA.
Полный путь сигнала: пошаговый разбор
📡 Режим приёма (RX)
1. Антенна
↓ (сигнал из эфира, мкВ-мВ)
2. RF-тракт
├─ Аттенюатор (0-31 dB)
├─ УВЧ (усиление)
├─ Фильтры (LPF/BPF)
↓ (подготовленный аналоговый сигнал)
3. АЦП (ADC)
├─ 122.88 MSPS
├─ 16 бит
└─ LVDS-интерфейс
↓ (цифровой поток: 122.88 миллионов 16-битных выборок/сек)
4. FPGA (Cyclone IV/V)
├─ DDC (перенос на базу, умножение на sin/cos)
├─ CIC-фильтры (децимация ×640, 5 стадий)
├─ FIR-фильтры (формирование полосы, подавление алиасинга)
├─ CORDIC (извлечение I/Q, 24-битная точность)
├─ Масштабирование (gain, balance)
├─ Формирование UDP-пакетов (8 приёмников × 2 канала × 16 бит)
└─ Gigabit Ethernet MAC/PHY
↓ (UDP-поток: 192 kSPS, упакованные I/Q)
5. Ethernet (Cat5e/Cat6)
↓ (пакеты 1000BASE-T)
6. ПК (Thetis/PowerSDR)
├─ Сетевой драйвер, приём UDP
├─ Буферизация (jitter buffer)
├─ Дополнительная фильтрация (NR2/NR4, DSP)
├─ AGC (автоматическая регулировка усиления)
├─ Аудио-ЦАП (через звуковую карту или USB-кодек)
└─ Динамики/наушки
↓ (звуковой сигнал, 48 kSPS)
🎙️ Режим передачи (TX)
- Микрофон / CW-ключ / Digital mode
↓ (аудио или управляющий сигнал) - ПК (Thetis/PowerSDR)
├─ Аудио-АЦП (микрофон)
├─ Модуляция (SSB: Hilbert transform, CW: keying envelope)
├─ Формирование I/Q-потока (192 kSPS)
├─ Упаковка в UDP-пакеты
└─ Отправка через Ethernet
↓ (UDP-поток) - Ethernet
↓ - FPGA
├─ Приём UDP-пакетов
├─ Буферизация (FIFO)
├─ CORDIC (перенос на частоту передачи)
├─ CIC-интерполяция (повышение частоты ×640 до 122.88 MSPS)
├─ FIR-фильтры (подавление гармоник интерполяции)
├─ PureSignal (предыскажение для компенсации нелинейности PA)
├─ Формирование огибающей (CW: raised cosine, SSB: envelope)
└─ ЦАП (DAC, 16-бит, 122.88 MSPS)
↓ (цифровой поток) - RF-тракт (TX)
├─ Фильтры (LPF)
├─ Усилители (Driver, PA)
├─ ATU (согласование)
└─ Антенна
↓ (RF-сигнал в эфир)
Развенчиваем мифы: конкретные примеры
❌ Миф 1: «NR/NR4 работают в Thetis, прошивка не влияет»
Реальность:
NR (Noise Reduction 2) и NR4 — это действительно алгоритмы на ПК. НО:
- Качество входных данных зависит от FPGA:
- CIC/FIR-фильтры в FPGA определяют, есть ли алиасинг (наложение спектров)
- Чистота I/Q зависит от точности CORDIC и качества тактирования
- Джиттер АЦП напрямую влияет на динамический диапазон и фазовый шум
- Переполнение FIFO в FPGA приводит к пропуску выборок → артефакты
Аналогия:
NR/NR4 — это как шумоподавление в фоторедакторе. Если исходное фото снято с шумом (плохой АЦП, джиттер), никакой софт не сделает из него шедевр. Если же фото чистое (качественная FPGA-обработка), то NR/NR4 лишь слегка улучшат его.
Вывод:
Плохая прошивка = шумные входные данные = NR/NR4 не помогут.
❌ Миф 2: «Панорама рисуется в ПК, прошивка не при чём»
Реальность:
Панорама (waterfall) действительно строится в Thetis. НО:
- Джиттер тактов в FPGA → фазовый шум → «дрожание» панорамы, размытые сигналы
- Неправильная маршрутизация клоков (не через Global Clock) → наводки от соседней логики → артефакты на панораме
- Переполнение FIFO в FPGA → пропуски данных → разрывы водопада, «пропадающие» сигналы
- Неточная децимация → алиасинг → ложные сигналы на панораме
Пример из практики:
В проекте Anvelina PRO3 после оптимизации тактовых сетей (принудительное использование Global Clock для CMCLK, CBCLK, PHY_TX_CLOCK) шумовая полка на панораме стала еще луччше, отрисовка Panadaptera стала еще приятнее . Это не магия — это снижение джиттера на физическом уровне.
Вывод:
Панорама — это зеркало качества FPGA-обработки.
❌ Миф 3: «CW формируется в ПК, прошивка не важна»
Реальность:
CW-модуляция действительно инициируется в ПК (нажатие ключа → команда в FPGA). НО:
- Тайминги точек/тире должны быть точные до микросекунды (стандарт ITU)
- FPGA отвечает за:
- Формирование огибающей (raised cosine для отсутствия щелчков)
- Точные задержки (RF delay, hang time, sidetone timing)
- Синхронизацию с тактами ЦАП (122.88 MHz)
- Iambic keying (режимы A/B, weight, spacing)
- CWX (CW с клавиатуры)
Пример:
В модуле iambic.v для Anvelina PRO3 мы исправили неявное усечение битов в таймерах (10230 warning). До исправления длительности точек могли «плавать» на 1-2 такта (8-16 нс), что незаметно на слух, но при высоких скоростях (40+ WPM) приводило к накоплению ошибки и «размазыванию» знаков.
Вывод:
Плохая прошивка = «рваный» CW, искажения, QRM другим станциям.
❌ Миф 4: «PureSignal — это просто обратная связь, любая прошивка подойдёт»
Реальность:
PureSignal (PS) — это система предыскажения для компенсации нелинейности PA. Она критически зависит от FPGA:
- Синхронизация основного и feedback-каналов (задержка должна быть компенсирована с точностью до такта)
- Адаптивное масштабирование feedback (в Anvelina PRO3 мы добавили динамическое смещение битового окна для точности при малых уровонях TX
- Вычитание сигналов (основной − feedback) требует идентичных путей обработки
- CORDIC в обоих каналах должен работать с одинаковой фазой
Пример:
Если feedback-канал имеет другую задержку или джиттер, чем основной, PS не сойдётся и начнёт генерировать артефакты вместо компенсации.
Вывод:
Без точной FPGA-обработки PureSignal не работает или работает плохо со сбоями.
Аналогия для понимания: ресторан
Чтобы проще было понять разделение труда между FPGA и ПК, представьте ресторан:
| Компонент SDR | Аналогия | Роль |
|---|---|---|
| Антенна/RF | Ферма/поставщики | Доставляет сырьё (сигнал из эфира) |
| FPGA (прошивка) | Кухня | Готовит блюдо (обрабатывает сигнал). От качества продуктов и мастерства повара зависит вкус. |
| ПК (Thetis) | Зал обслуживания | Подаёт блюдо клиенту (выводит аудио/панораму). Официант может красиво подать, но не исправит пересоленный суп. |
Можно ли сказать, что «ресторан — это просто зал, а всё делает кухня»?
Нет, оба важны. НО: если кухня (FPGA) работает плохо, никакой зал (ПК) не спасёт.
Почему обновления прошивки P2 имеют значение
Проект OpenHPSDR Protocol 2 (P2) — это живая экосистема. Обновления прошивок для Orion, Anan, Hermes и других платформ включают:
🔧 Что исправляют разработчики:
| Тип изменений | Пример | Влияние |
|---|---|---|
| Оптимизация тактирования | Принудительное использование Global Clock | Снижение фазового шума, стабильная панорама |
| Исправление таймингов | Явное приведение разрядности в CW-ключе | Точные точки/тире, отсутствие QRM |
| Улучшение фильтров | Корректировка коэффициентов FIR | Лучшее подавление алиасинга, чистый приём |
| Оптимизация сети | Исправление DHCP, ARP, UDP-буферов | Стабильное соединение, отсутствие разрывов |
| PureSignal | Адаптивное масштабирование feedback | Работа на малых мощностях |
| DSP-ядро | TPDF dither, phase dither | Улучшение динамического диапазона (+6-9 dB) |
📊 Реальный пример: Anvelina PRO3
В недавней работе над прошивкой Anvelina PRO3 (Cyclone IV EP4CE115F29I7N) мы:
- Устранили все warning синтеза (
10230,10161,10733) — код стал чище и предсказуемее - Настроили глобальные тактовые сети для критических сигналов (
CMCLK,CBCLK,PHY_TX_CLOCK) — снизили джиттер - Исправили CW-модуль (
iambic.v) — точные тайминги, стабильный ключ - Оптимизировали DSP-ядро — TPDF dither, phase dither, round-to-nearest
Результат:
- ✅ Панорама стала ещё стабильнее
- ✅ CW формируется с эталонной точностью
- ✅ Динамический диапазон улучшился на 6-9 dB
- ✅ Сеть работает ещё стабильнее
Это не теория — это практика, основанная на реальных измерениях и отзывах операторов.
Таблица: разделение ответственности
| Задача | FPGA | ПК | Почему так? |
|---|---|---|---|
| АЦП/ЦАП | ✅ Управление, тактирование | ❌ | Физический уровень, наносекундные тайминги |
| DDC/DUC | ✅ Перенос частоты | ❌ | 122.88 MSPS — слишком быстро для USB/Ethernet |
| CIC-фильтры | ✅ Децимация/интерполяция ×640 | ❌ | Должны работать на входной частоте |
| FIR-фильтры | ✅ Первичная фильтрация | ✅ Дополнительная фильтрация | FPGA: алиасинг, ПК: NR2/NR4 |
| CORDIC | ✅ I/Q extraction, phase rotation | ❌ | Параллельная обработка 8+ каналов |
| CW-ключ | ✅ Формирование огибающей, тайминги | ✅ Интерфейс (ключ/клавиатура) | FPGA: точность до мкс, ПК: UI |
| PureSignal | ✅ Previous distortion, sync | ✅ Calibration UI | FPGA: real-time processing |
| Сеть (UDP) | ✅ Формирование пакетов, DHCP | ✅ Приём/отправка, буферизация | FPGA: line speed, ПК: socket API |
| Панорама | ✅ Подготовка I/Q данных | ✅ FFT, визуализация | FPGA: данные, ПК: графика |
| Аудио | ✅ I/Q → audio (через ЦАП) | ✅ DSP (AGC, NR, EQ) | FPGA: базовая обработка, ПК: финальная |
Заключение: прошивка ИМЕЕТ значение
Стоит еще сказать о сложности подобных проектах, то есть что бы все версии ревизий плат (PCB) хорошо работали, то есть одинаково стабильно, порой отладка публичной прошивки может легко занять неделю и более.. Например при работе с микроконтроллерами и близко не возникает подобных сложностей в отладки и тд..
Подведём итоги:
- FPGA — это не «глупая коробка», а мощный процессор реального времени, который выполняет 90% тяжёлой работы.
- ПК получает уже подготовленные данные (после децимации ×640) и занимается финальной обработкой и UI.
- Качество прошивки напрямую влияет на:
- ✅ Динамический диапазон (phase noise, jitter)
- ✅ Стабильность панорамы (waterfall)
- ✅ Точность CW (timing, envelope)
- ✅ Работу PureSignal (convergence, linearity)
- ✅ Надёжность сети (packet loss, latency)
- ✅ Качество фильтров (aliasing, image rejection)
- Обновления прошивок P2 — это не маркетинг, а реальные улучшения:
- Исправление багов
- Оптимизация таймингов
- Улучшение DSP-алгоритмов
- Поддержка новых функций
- Игнорировать роль прошивки — ошибка.
Можно иметь топовый ПК и последнюю версию Thetis, но со старой, неоптимизированной прошивкой вы не получите от трансивера и 50% его возможностей.
Призыв к действию
- Следите за обновлениями прошивок для вашей платформы (Orion, Hermes, Anvelina).
- Читайте changelog — там часто описаны важные улучшения.
- Не бойтесь обновляться (но всегда делайте backup старой прошивки!).
- Задавайте вопросы разработчикам на форумах OpenHPSDR.
- Участвуйте в тестировании бета-версий — ваш фидбек важен.
- Делитесь опытом — если после обновления что-то улучшилось (или ухудшилось), расскажите сообществу.
Post Scriptum
Эта статья написана на основе реального опыта разработки и оптимизации прошивок для платформ OpenHPSDR Protocol 2, включая Anvelina PRO3.
Мы не призываем слепо верить обновлениям. Мы призываем понимать, что происходит внутри вашего трансивера, и осознавать, что FPGA и прошивка — это не «драйвер», а сердце SDR.
Чистого вам эфира, стабильных связей и качественных прошивок!
73!
Юрий, EU2AV
Разработчик, радиолюбитель
🇧 Беларусь
eu2av.com