Мы привыкли видеть Raspberry Pi в виде основы для различных SDR-приемников, декодеров и панорамирующих адаптеров. А вот полноценные КВ-трансиверы на базе RPI встретить сложно. Проект Radioberry — одно из редких приятных исключений. Эта маленькая плата превращает «малинку» в настоящую SDR-станцию со своим интерфейсом и возможностью как принимать, так и передавать в КВ-диапазоне.

До недавнего времени настройка была простой, но после обновления Raspberry Pi OS старые инструкции почти утратили актуальность: плата больше не определялась в системе. Один мой знакомый радиолюбитель даже решил, что она вышла из строя, и попросил меня о диагностике.

Radioberry интересна тем, что это не звуковая карта с антенным входом и не надоевший всем SDR-свисток. Это полноценная SDR-плата с двумя ключевыми микросхемами: Analog Devices AD9866 и FPGA Intel Cyclone 10 LP. Первая представляет собой широкополосный модем (MxFE, Mixed Signal Front End), который в одном корпусе объединяет АЦП, ЦАП, микшеры и цифровые преобразователи частоты. На нем построен SDR-трансивер прямого преобразования.

AD9866 — 12-битный, компромиссный, но вполне рабочий вариант для платы такого класса. Разумеется, до современных 14/16-битных чипов ему далеко, однако и цена у него значительно ниже. Так что ждать от Radioberry возможностей профессионального устройства с широким динамическим диапазоном не стоит — плата исключительно любительская. 

Второй чип также довольно интересный. Дело в том, что если попытаться отдать сырые данные на Raspberry, одноплатник не справится с обработкой потока данных из-за его высокой скорости. Именно здесь FPGA становится ключевым элементом — он берет данные от AD9866, формирует IQ-поток, фильтрует, снижает частоту дискретизации — и только после этого передает их на Raspberry Pi.

Перед установкой полезно понять, как все устроено. Большинство проблем с платой возникает как раз из-за того, что архитектура остается за кадром. В сети полно руководств по настройке отдельных частей, но целостной картины они не дают. В итоге настройка выполнена, а система молчит.

В системе выделяются четыре программных уровня, каждый со своей задачей. Чтобы Radioberry заработала, нужно настроить каждый из них:

На самом нижнем слое находится двоичный файл конфигурации FPGA (битстрим с расширением .rbf), который должен лежать по адресу /lib/firmware/radioberry.rbf. После подачи питания FPGA «чиста» и ждет этот файл. Только после его загрузки микросхема начинает работать. При потере питания состояние сбрасывается.

Этот слой состоит из модуля ядра radioberry.ko и соответствующего device-tree оверлея. При загрузке системы модуль создает устройство /dev/radioberry и загружает битстрим в FPGA.

Демон-прослойка /usr/local/bin/radioberry, действующий в пользовательском пространстве. Преобразует поток данных с шины SPI в стандартный сетевой протокол приложения HPSDR на интерфейсе lo. Он как переводчик позволяет HAT-плате на гребенке RPI представляться «взрослым» трансивером HPSDR/Hermes. Софт вроде pihpsdr вообще не будет знать, чем по-факту управляет.

Финальный слой — автоматический запуск сервиса, чтобы все вышеперечисленные уровни выполняли свою работу. Если хотя бы один из них не запустится, pihpsdr будет искать устройство, а затем выдаст ошибку, что не нашел. С таким поведением и столкнулся мой знакомый.

Для начала залейте свежую Raspberry Pi OS на MicroSD-карту. Проще всего для этого использовать Raspberry Pi Imager или Balena Etcher. После успешной загрузки выполните обновление пакетов:

Перезагрузитесь:

Теперь откройте утилиту конфигурации «малинки»:

Включите SPI в разделе Interface Options. Он нужен для управляющего обмена с FPGA, потоковая часть завязана на GPIO/IRQ. Для проверки выполните команду:

В выводе команды должны появиться два устройства /dev/spidev0.0 и /dev/spidev0.1. Это будет означать, что вы достучались до девайса.

Установите зависимости для сборки:

Перейдите в домашнюю директорию:

Клонируйте репозиторий проекта:

Зайдите в директорию Radioberry-2.x:

Запустите скачивание и установку всех необходимых подмодулей:

Итак, для сборки вначале надо скопировать библиотеку WDSP в системную директорию. Приложение pihpsdr использует ее для всей цифровой обработки сигнала:

Файла там не оказалось. Моим первым (ошибочным) решением было скачать готовую библиотеку из стороннего репозитория:

wget https://github.com/g0orx/pihpsdr/raw/refs/heads/master/release/pihpsdr/libwdsp.so

Попытка сборки после этого закончилась типичной ошибкой линковки:

Если внимательно приглядеться к формулировке, то становится ясно, что линковщик видит файл, но пропускает как несовместимый. Причина в том, что библиотека собрана под x86_64, а мы работаем с aarch64. Готовых бинарников из чужих сборок много, и допустить эту ошибку оказалось проще простого.

Правильное решение — самостоятельная сборка библиотеки из исходников под конкретное железо:

Теперь проверьте, что получилось:

Должно выдать что-то вроде ELF 64-bit LSB shared object, ARM aarch64...

Теперь можно собирать pihpsdr из каталога проекта:

Флаг -Wno-deprecated-declarations обязателен — код писался под старые версии GTK, и без него сборка упадет. Перед финальной установкой уточните, какая FPGA стоит на плате: CL016 или CL025:

После завершения сборки запустим приложение и наткнемся на очередные (не последние) грабли.

Первый запуск выглядел довольно эпично — pihpsdr отрисовал окно, построил планы FFTW, нашел аудиоустройства и запустил Discovery:

Плата физически подключена, синий огонек горит, SPI включен, /dev/spidev0.0 на месте, а вот софт ее в упор не видит. Программа ищет HPSDR-трансиверы по сети через UDP-запросы Discovery. Если ответа нет — вероятно, проблема на уровне Firmware. Демон должен был запустить эмуляцию HPSDR на интерфейсе loopback, но этого не произошло.

Проверяем модуль ядра:

lsmod | grep -i radioberry

В ответ тишина — модуля radioberry нет. На всякий случай еще заглядываем в dmesg:

Пусто. Значит, модуль не загружен. Устанавливаем заголовки ядра:

Далее проверяем слой Driver и собираем недостающее:

На выходе должно получиться два файла: radioberry.ko и radioberry.dtbo.  Тут стоит оговориться: модуль писали под старые ядра (4.x–5.x). На 6.12 он собрался без доработок, но, подозреваю, это скорее везение. В будущем, возможно, придется доставать напильник.

Скачиваем битстрим под FPGA. Готовые файлы лежат в репозитории, поэтому достаточно просто команды копирования. Тут я и сделал ошибку — не посмотрел маркировку FPGA, а воспользовался копипастой:

Распределяем файлы по директориям. Держим в голове, что config.txt и overlays переехали из /boot/ в /boot/firmware/:

grep -Fxq "dtoverlay=radioberry" /boot/firmware/config.txt \ || echo "dtoverlay=radioberry" | sudo tee -a /boot/firmware/config.txt

Теперь лечим слой Firmware-демона:

Настраиваем автозапуск:

Да, выглядит как странный гибрид systemd и старого init.d, но именно так устроен текущий сервис в репозитории Radioberry. Перечитываем список демонов и включаем сервис:

Перезагружаемся:

sudo reboot

Если вдруг после этого systemd выдаст ошибку Configuration file radioberry.service is marked executable , то выполните следующие две команды:

Проверка всех слоев перед запуском:

Модуль загружен.

Устройство присутствует в системе.

Битстрим загружен в FPGA.

Демон в статусе active.

Правильный вывод dmesg выглядит примерно так:

radioberry_probe ... Device property 'rx-sample-gpio' found!
Radioberry: registered correctly with major number 238
Radioberry gateware file size: 334039
inside radioberry_open function

Вот теперь пробуем запускать pihpsdr и видим: в Discovery появилось устройство. Победа или очередной сюрприз?

Устройство вроде бы подключилось, окно открылось, но водопад отсутствует. Ползунки усиления не работают, в консоли pihpsdr идет поток ошибок:

Раньше в старом протоколе HPSDR у каждого пакета с данными был порядковый номер. Ошибки вида SEQ ERROR: last 71, recvd 74  означают, что пакеты потеряны: ожидали пакет после 71, а прилетел 74. Библиотека WDSP не может собрать непрерывный буфер и водопад остается пустым. Формально все работает, интерфейс отзывается, но данные — битые.

Признаться, на этом моменте я уже почти был готов сдаться. Причин могло быть несколько: от троттлинга самой RPI и неправильного питания до неверного количества приемников и sample rate. Перебрав все, что можно и нельзя, я пришел к единственной оставшейся версии — битстрим был залит не под ту версию FPGA.

Помните, я говорил, что есть два варианта? На моей плате оба чипа владелец заботливо прикрыл радиаторами, хотя они там вовсе не обязательны. Отклеил радиатор — а там не CL025, а CL016. Коварство в том, что FPGA без единой ошибки сожрал чужой битстрим: плата отвечала на Discovery, подключение устанавливалось, а внутри все шло не так.

Это самый неприятный тип ошибки в отладке — все вроде бы работает, а IQ-поток идет мусором с дырами. В итоге вылечилось тремя командами:

После ребута размер gateware в dmesg поменялся — прошивки CL016 и CL025 весят по-разному. Хороший способ проверить, что нужный файл встал на место и заработал.

Ошибки SEQ ERROR исчезли, водопад ожил и эфир пошел. Плата оказалась полностью рабочей — проблема была в программной части.

Хотя этот опыт выдался непростым, он позволил сформулировать несколько полезных советов на будущее.

• Не берите готовые бинарники из чужих сборок. Готовые .so и .ko могут оказаться собранными под другую архитектуру или ядро. Лучше потратить 15 минут на сборку из исходников, чем час на расшифровку ошибок линковщика.

• Понимание архитектуры — ключ к успеху. Казалось бы, простая HAT-плата тянет за собой четыре программных уровня, и каждый должен работать как часы. Без этого отладка превращается в гадание.

• Пути в Raspberry Pi OS изменились. В старых инструкциях все еще пишут про /boot, но на актуальной системе config.txt и overlays живут в /boot/firmware/. Не ленитесь проверять.

• Всегда смотрите на маркировку чипов. Правильно собранный софт с неправильной прошивкой даст подключение, но не даст эфира. Если бы я сразу снял радиатор и проверил маркировку, то сэкономил бы пару часов.

Надеюсь, мой опыт поможет вам обойти все эти грабли и сэкономить время.

73