Мы привыкли видеть 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 заработала, нужно настроить каждый из них:
Gateware
На самом нижнем слое находится двоичный файл конфигурации FPGA (битстрим с расширением .rbf), который должен лежать по адресу /lib/firmware/radioberry.rbf. После подачи питания FPGA «чиста» и ждет этот файл. Только после его загрузки микросхема начинает работать. При потере питания состояние сбрасывается.
Driver
Этот слой состоит из модуля ядра radioberry.ko и соответствующего device-tree оверлея. При загрузке системы модуль создает устройство /dev/radioberry и загружает битстрим в FPGA.
Firmware
Демон-прослойка /usr/local/bin/radioberry, действующий в пользовательском пространстве. Преобразует поток данных с шины SPI в стандартный сетевой протокол приложения HPSDR на интерфейсе lo. Он как переводчик позволяет HAT-плате на гребенке RPI представляться «взрослым» трансивером HPSDR/Hermes. Софт вроде pihpsdr вообще не будет знать, чем по-факту управляет.
Service
Финальный слой — автоматический запуск сервиса, чтобы все вышеперечисленные уровни выполняли свою работу. Если хотя бы один из них не запустится, pihpsdr будет искать устройство, а затем выдаст ошибку, что не нашел. С таким поведением и столкнулся мой знакомый.
Подготовка системы
Для начала залейте свежую Raspberry Pi OS на MicroSD-карту. Проще всего для этого использовать Raspberry Pi Imager или Balena Etcher. После успешной загрузки выполните обновление пакетов:
|
sudo apt update && sudo apt -y upgrade |
Перезагрузитесь:
|
sudo reboot |
Теперь откройте утилиту конфигурации «малинки»:
|
sudo raspi-config |
Включите SPI в разделе Interface Options. Он нужен для управляющего обмена с FPGA, потоковая часть завязана на GPIO/IRQ. Для проверки выполните команду:
|
ls /dev/spidev* |
В выводе команды должны появиться два устройства /dev/spidev0.0 и /dev/spidev0.1. Это будет означать, что вы достучались до девайса.
Установите зависимости для сборки:
|
sudo apt-get install git libpulse-dev libgtk-3-dev libasound2-dev libcurl4-openssl-dev libi2c-dev libgpiod-dev libusb-1.0-0-dev device-tree-compiler libfftw3-dev |
Сборка
Перейдите в домашнюю директорию:
|
cd ~ |
Клонируйте репозиторий проекта:
Зайдите в директорию Radioberry-2.x:
|
cd Radioberry-2.x |
Запустите скачивание и установку всех необходимых подмодулей:
|
git submodule update —init —recursive —depth=1 |
Первая проблема — несовместимая библиотека libwdsp.so
Итак, для сборки вначале надо скопировать библиотеку WDSP в системную директорию. Приложение pihpsdr использует ее для всей цифровой обработки сигнала:
|
sudo cp ~/Radioberry-2.x/wdsp/libwdsp.so /usr/local/lib/ |
Файла там не оказалось. Моим первым (ошибочным) решением было скачать готовую библиотеку из стороннего репозитория:
wget https://github.com/g0orx/pihpsdr/raw/refs/heads/master/release/pihpsdr/libwdsp.so
|
sudo cp libwdsp.so /usr/local/lib/ |
|
sudo ldconfig |
Попытка сборки после этого закончилась типичной ошибкой линковки:
|
/usr/bin/ld: skipping incompatible /usr/local/lib/libwdsp.so when searching for -lwdsp /usr/bin/ld: cannot find -lwdsp: No such file or directory collect2: error: ld returned 1 exit status |
Если внимательно приглядеться к формулировке, то становится ясно, что линковщик видит файл, но пропускает как несовместимый. Причина в том, что библиотека собрана под x86_64, а мы работаем с aarch64. Готовых бинарников из чужих сборок много, и допустить эту ошибку оказалось проще простого.
Правильное решение — самостоятельная сборка библиотеки из исходников под конкретное железо:
|
cd /tmp |
|
git clone —depth=1 https://github.com/g0orx/wdsp |
|
cd wdsp |
|
make -j$(nproc) |
|
sudo make install |
|
sudo ldconfig |
Теперь проверьте, что получилось:
|
file /usr/local/lib/libwdsp.so |
Должно выдать что-то вроде ELF 64-bit LSB shared object, ARM aarch64…
Теперь можно собирать pihpsdr из каталога проекта:
|
cd ~/Radioberry-2.x/pihpsdr |
|
make clean |
|
make CFLAGS=»-g -Wno-deprecated-declarations -I../wdsp» LDFLAGS=»-L../wdsp» -j$(nproc) |
Флаг -Wno-deprecated-declarations обязателен — код писался под старые версии GTK, и без него сборка упадет. Перед финальной установкой уточните, какая FPGA стоит на плате: CL016 или CL025:
|
sudo make install FPGATYPE=CL016 |
После завершения сборки запустим приложение и наткнемся на очередные (не последние) грабли.
Вторая проблема — pihpsdr не видит устройств
Первый запуск выглядел довольно эпично — pihpsdr отрисовал окно, построил планы FFTW, нашел аудиоустройства и запустил Discovery:
|
discover: looking for HPSDR devices on lo |
Плата физически подключена, синий огонек горит, SPI включен, /dev/spidev0.0 на месте, а вот софт ее в упор не видит. Программа ищет HPSDR-трансиверы по сети через UDP-запросы Discovery. Если ответа нет — вероятно, проблема на уровне Firmware. Демон должен был запустить эмуляцию HPSDR на интерфейсе loopback, но этого не произошло.
Проверяем модуль ядра:
lsmod | grep -i radioberry
В ответ тишина — модуля radioberry нет. На всякий случай еще заглядываем в dmesg:
|
dmesg | grep -i -E «radioberry|fpga|spi» |
Пусто. Значит, модуль не загружен. Устанавливаем заголовки ядра:
|
sudo apt install raspberrypi-kernel-headers |
|
ls /lib/modules/$(uname -r)/build && echo «headers OK» |
Далее проверяем слой Driver и собираем недостающее:
|
cd ~/Radioberry-2.x/SBC/rpi-4/device_driver/driver |
|
make |
На выходе должно получиться два файла: radioberry.ko и radioberry.dtbo. Тут стоит оговориться: модуль писали под старые ядра (4.x–5.x). На 6.12 он собрался без доработок, но, подозреваю, это скорее везение. В будущем, возможно, придется доставать напильник.
Скачиваем битстрим под FPGA. Готовые файлы лежат в репозитории, поэтому достаточно просто команды копирования. Тут я и сделал ошибку — не посмотрел маркировку FPGA, а воспользовался копипастой:
|
sudo cp ~/Radioberry-2.x/SBC/rpi-4/releases/stable/CL025/radioberry.rbf /lib/firmware/radioberry.rbf |
Распределяем файлы по директориям. Держим в голове, что config.txt и overlays переехали из /boot/ в /boot/firmware/:
|
sudo mkdir -p /lib/modules/$(uname -r)/kernel/drivers/sdr |
|
sudo cp radioberry.ko /lib/modules/$(uname -r)/kernel/drivers/sdr/ |
|
sudo cp radioberry.dtbo /boot/firmware/overlays/ |
grep -Fxq «dtoverlay=radioberry» /boot/firmware/config.txt \ || echo «dtoverlay=radioberry» | sudo tee -a /boot/firmware/config.txt
|
sudo depmod |
Теперь лечим слой Firmware-демона:
|
sudo apt-get install -y pigpio |
|
cd ~/Radioberry-2.x/SBC/rpi-4/device_driver/firmware |
|
make |
|
sudo cp radioberry /usr/local/bin/ |
|
sudo chmod +x /usr/local/bin/radioberry |
Настраиваем автозапуск:
|
cd ~/Radioberry-2.x/SBC/rpi-4/device_driver/systemd |
|
sudo cp radioberry.service /etc/systemd/system/ |
|
sudo cp radioberryd /etc/init.d/ |
|
sudo chmod +x /etc/init.d/radioberryd |
Да, выглядит как странный гибрид systemd и старого init.d, но именно так устроен текущий сервис в репозитории Radioberry. Перечитываем список демонов и включаем сервис:
|
sudo systemctl daemon-reload |
|
sudo systemctl enable radioberry |
Перезагружаемся:
sudo reboot
Если вдруг после этого systemd выдаст ошибку Configuration file radioberry.service is marked executable , то выполните следующие две команды:
|
sudo chmod 644 /etc/systemd/system/radioberry.service |
|
sudo systemctl daemon-reload |
Проверка всех слоев перед запуском:
|
lsmod | grep radioberry |
Модуль загружен.
|
ls -l /dev/radioberry |
Устройство присутствует в системе.
|
dmesg | grep -i radioberry |
Битстрим загружен в FPGA.
|
systemctl status radioberry |
Демон в статусе 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 идет поток ошибок:
|
old_protocol_init: num_hpsdr_receivers=2 |
Раньше в старом протоколе HPSDR у каждого пакета с данными был порядковый номер. Ошибки вида SEQ ERROR: last 71, recvd 74 означают, что пакеты потеряны: ожидали пакет после 71, а прилетел 74. Библиотека WDSP не может собрать непрерывный буфер и водопад остается пустым. Формально все работает, интерфейс отзывается, но данные — битые.
Признаться, на этом моменте я уже почти был готов сдаться. Причин могло быть несколько: от троттлинга самой RPI и неправильного питания до неверного количества приемников и sample rate. Перебрав все, что можно и нельзя, я пришел к единственной оставшейся версии — битстрим был залит не под ту версию FPGA.
Помните, я говорил, что есть два варианта? На моей плате оба чипа владелец заботливо прикрыл радиаторами, хотя они там вовсе не обязательны. Отклеил радиатор — а там не CL025, а CL016. Коварство в том, что FPGA без единой ошибки сожрал чужой битстрим: плата отвечала на Discovery, подключение устанавливалось, а внутри все шло не так.
Это самый неприятный тип ошибки в отладке — все вроде бы работает, а IQ-поток идет мусором с дырами. В итоге вылечилось тремя командами:
|
sudo systemctl stop radioberry |
|
sudo cp ~/Radioberry-2.x/SBC/rpi-4/releases/stable/CL016/radioberry.rbf /lib/firmware/radioberry.rbf |
|
sudo reboot |
После ребута размер gateware в dmesg поменялся — прошивки CL016 и CL025 весят по-разному. Хороший способ проверить, что нужный файл встал на место и заработал.
|
dmesg | grep -i radioberry |
Ошибки SEQ ERROR исчезли, водопад ожил и эфир пошел. Плата оказалась полностью рабочей — проблема была в программной части.
Выводы
Хотя этот опыт выдался непростым, он позволил сформулировать несколько полезных советов на будущее.
-
Не берите готовые бинарники из чужих сборок. Готовые .so и .ko могут оказаться собранными под другую архитектуру или ядро. Лучше потратить 15 минут на сборку из исходников, чем час на расшифровку ошибок линковщика.
-
Понимание архитектуры — ключ к успеху. Казалось бы, простая HAT-плата тянет за собой четыре программных уровня, и каждый должен работать как часы. Без этого отладка превращается в гадание.
-
Пути в Raspberry Pi OS изменились. В старых инструкциях все еще пишут про /boot, но на актуальной системе config.txt и overlays живут в /boot/firmware/. Не ленитесь проверять.
-
Всегда смотрите на маркировку чипов. Правильно собранный софт с неправильной прошивкой даст подключение, но не даст эфира. Если бы я сразу снял радиатор и проверил маркировку, то сэкономил бы пару часов.
Надеюсь, мой опыт поможет вам обойти все эти грабли и сэкономить время.
73
ссылка на оригинал статьи https://habr.com/ru/articles/1056976/