Комментарии 84
Здорово! Многие ждали что-то подобное. Вопрос такой - не пришлось ли бороться с разной длиной проводников от ADC к Zynq?
Круто. А у Вас такт на АЦП прямо с SoC подаётся? Если это цифровой вывод общего назначения, то там джиттер может быть большой, а это приводит к снижению с/ш приёмника за счёт размазывания спектров внеполосовых сигналов и наложения. Кроме того, хорошо бы смоделировать тракт и померять ачх приёмника, потому что комбинация сик фильтров с децимацией может давать наложения.
Да, тактирование прямо с PLL PS идет. Я тоже думал про джиттер, поэтому на плате АЦП сделал посадочное место под TCXO генератор, также имеются перемычки и отдельная линия, позволяющая завести тактовый сигнал в ПЛИС.
Однако сейчас у меня эфир довольно шумный, так что у меня просто не было стимула добиваться более низкого уровня самого приемника.
Понял, всё правильно тогда. Но джиттер как раз и существенен при шумном эфире - из за него хвосты от внеполосных спектров лезут в полосу приёмника. То есть динам диапазон вроде и высокий, а внеполосные шумы и сигналы сразу гробят эф. динам диапазон
И ещё - может я неправильно понял схему буферизации и обмена с cpu/user space, но я в своё время использовал dma для заполнения страниц кольцевого буфера в kernel space, а блокирующий read device для его чтения и освобождения, ioctl только для настройки и управления приёмником. Правда приёмник работал в стробах по несколько мс
Спасибо, интересно почитать как кто-то еще решает задачи через которые прошел. Я когда задумывал собственный трансивер с Zynq думал про AD9866. Даже плату развел и распаял. Но в итоге нашелся в компанию электронщик и мы сделали на LTC2208 + DAC904E. Кстати FFT я делал прямо на PL части, правда потом отказался потому что влазило только в 7020, а хотелось иметь возможность и на 7010 собирать. Теперь у меня FFT считается на сопроцессоре в виде MicroBlaze (; Кстати наш проект открытый, если интересно - буду рад видеть в команде разработчиков.
Кстати STTV днем довольно активно идет на 14.230, а RTTY на 10.100 передают погоду на Балтийский регион. Еще интересно послушать Olivia на 14.106 - правда не помню умеет ли KiwiSDR ее декодировать.
Конечно, 12 бит хуже, чем 14 или 16, но я посчитал, что в сильно зашумленном эфире города нет великого смысла гнаться за разрядностью АЦП.
Все ровно наоборот. Чем ниже соотношение сигнал\шум, тем выше должна быть разрядность, точность установки частоты, синхронизация по частоте, фазе и времени. Самая главная задача при приеме - как можно точнее вычислить параметры передатчика - частоту, фазу, частоту дискретизации и фазу её. Проверить довольно просто на стенде - соединить передатчик и приемник с добавлением шума и помехи. Определить минимальное отношение сигнал\шум. Затем использовать один задающий генератор для передатчика и приемника(абсолютная синхронизация). Обнаружиться, что очень есть ешё куда ползти. Объясняется все просто принципом суперпозиции. Какой бы ни был шум - сигнал в нем есть.
Не много не так. Разрядность ADC повышают только ради динамического диапазона (на приемниках прямогй оцифровки). Чтобы приемник не "запирался" от мощных станций. Есть есть диапазонные фильтры (на КВ почти всегда стоят) то разрядность не так важна.
Забыл сразу добавить. Работа замечательная.
А теперь к спору: именно так. Первое с чем Вы столкнетесь, пытаясь повысить точность синхронизации - разрядность АЦП. От точности синхронизации зависит чувствительность(сейчас говорят производительность канала) при выделении известного сигнала. От разрядности АЦП - чувствительность(изменения, а не только диапазон) вообще. Если изначально изменения вызванные полезным сигналом будут незначительные из-за шага квантования АЦП, то принять такой сигнал будет невозможно. Из тех расчетов которые я видел - 14 бит это минимум при современной возможности обработки сигнала. Тем более SDR.
SDR тем и отличается, что в нем можно применять программные(последние изученные и лучшие) методы синхронизации. А здесь все "обрезается" на входе. Наша задача - "вытащить сигнал из под шумов".
Ну не знаю насчет "14 бит это минимум". Я успешно принимаю через 8 битный HackRF довольно слабый Lora сигнал. Конечно сильно хуже чем родным SX127x, но вполе уверенно. А если взять во внимание направленность статьи (радиолюбительский прием) то там 99% всех сигналов это различные "аналоги" типа AM/FM/USB/LSB и основная проблема "пробиться" сквозь мощные радиовещательные станции (которые запирают приемник). Опять же как сказано в статье - дециматор позволяет "увеличить разрядность".
GPS вообще традиционно на 1 или 2-битный АЦП принимают. Правда, там передаваемый сигнал специально под такое спроектирован.
Не туда
И все же, если уровень шума выше уровня сигнала, поможет ли более высокоразрядный АЦП?
"Шум считается случайным"
А если он не совсем случайный? Индустриальные помехи (ну и помехи от бытовой электроники в доме), по-моему, сложно назвать полностью случайными.
"Что касается мощных вещательных станций - резать(ослаблять) фильтром."
У KiwiSDR концепция - это всеволновый многоканальный приемник. Думаю, фильтры с такой концепцией применять невозможно.
И все же, если уровень шума выше уровня сигнала, поможет ли более высокоразрядный АЦП?
Поможет. Давно уже передают "под шумами".
А если он не совсем случайный?
Тогда применяют избыточность - кодирование с восстановлением. При этом аналоговый сигнал самый избыточный и точность здесь играет решающую роль.
У KiwiSDR концепция
Концепция не нарушается. Здесь же не предлагается вырезать, только ослабить, как раз для соблюдения "концепции" - принимать все волны , а не только сильные.
При сверхдискретизации после ddc полоса снижается, давая полбита разрешения на сужение полосы в 2 раза. Снизили полосу в 16 раз - получили 14 бит разрешения на 12 р ацп
Понятие "любительская связь" не оправдывает термины "довольно слабый", "сильно хуже". Лучше этого избегать, но я Вас понимаю. Что касается разрядности попробую объяснить проще:
АЦП измеряет сигнал вместе с шумом. Шум считается случайным, он может как увеличить сигнал, так и уменьшить. При интерполяции (сверхдискретизации) сигнал восстанавливается и при этом шум вычитает сам себя. Например два соседних отсчета шум "поднял" - средний(восстановленный) также поднят и ошибочен. Но если добавить отсчет по середине(по амплитуде) он должен быть меньше в силу природы шума и сигнал будет восстановлен точнее. При аналоговом сигнале это позволит точнее настроится на несущую (поднесущую) и получить например стерео или вообще факт наличия сигнала. При цифровом правильно принять бит и т.д.
Что касается мощных вещательных станций - резать(ослаблять) фильтром. Это достойный компромисc даже для чистого SDR. Вещание явление не случайное и очень продолжительное и снижать чувствительность из-за него неразумно.
(радиолюбительский прием) то там 99% всех сигналов это различные "аналоги" типа AM/FM/USB/LSB
Там мечтают о 24 битах.
Мы о разном, мне кажется. Сверхдискретизация это когда темп ацп многократно выше, чем полоса сигнала. Потом этот оцифрованный сигнал фильтруется в полосе сигнала, подавляя внеполосовые шумы пролазов и шума квантования. За счёт этого мощность шумов квантования кратно снижается, что эквивалентно увеличению разрядности ацп. Ну и поток выборок можно прорядить, поскольку спектр стал уже после фильтрации. Ваши же рассуждения касаются точности представления сигнала - ну как для цапа при воспроизведении музыки, или ацп при оцифровке. Повышение разрядности выше динам диапазона исходного сигнала ничего не даёт. Если на входе ацп сигнал шум 40 дБ, то он таким и останется, как его не оцифровывай и не фильтруй, 2 разряда на шум и 7 разрядов на сигнал, ну или просто 12 р чтобы ару попроще
Чем точнее будет измерен сигнал, тем точнее он будет восстановлен. Такова природа шума - сколько раз он увеличит амплитуду на разных отсчетах столько и уменьшит на других, но для точного вычитания нужны точные отсчеты. Например при когерентном накоплении сигнал с каждым отсчетом увеличивает амплитуду пока не сработает детектор, шум при этом то увеличивает, то уменьшает сигнал. Но за достаточное время сигнал "вылезает из-под шума". Если только АЦП чувствителен к очень малой амплитуде сигнала, а это разрядность(при малой разрядности тоже сработает, но ждать надо дольше).
В остальных системах принцип тот-же. Это основа - не измеришь, не получишь. Если частота дискретизации важна для приема широкополосных сигналов(и разрядность тоже), то для узкополосных остается разрядность.
Точность измерения параметров определяется свойствами измеряемого сигнала и отношением сигнал шум. Чтобы шум мог считаться для формул гауссовым, его достаточно представлять 2-3 разрядами ацп в полосе сигнала. Мы это многократно моделировали и проверяли, в своё время, для лчм, псп, оценки допплеровских сдвигов частоты и, соответственно, когерентного накопления. Если с/ш высокий, то точность измерения будет высокой, если на пороге обнаружения, то и точность будет около разрешающей способности. Но увеличение разрядности ацп её никак не повысит
Но увеличение разрядности ацп её никак не повысит
Это проверенно? У меня был случай когда не повышало. Перешел с типа float на double в программе на C++, а там еще повышать и повышать. Шум складывается с сигналом, а не стирает сигнал. За достаточное время "сумма" шума равна нолю, сигнала нет. Но вот квантование - не шум. Это помеха. Понимаю еще спор о 24битах и 32битах, но 12 (при современных технологиях) явно мало.
Там мечтают о 24 битах.
Если брать радиолюбителей то о "битах" мечтают только те кто не понимает для чего нужно повышать разрядность. Т.е. фетишизм чистой воды. Теперь к практике. В моем устройстве частота АЦП 122.88Мгц при 16 битах. Децимирую я ее до 12КГц. Что я выиграю при переходе на 24 битный АЦП и где взять такой на эти частоты? (;
Давайте отдельно - Мгц и биты. Это немного разные сущности. Первое время, второе амплитуда и они ортогональны. 24 бита берут в звуковой карте, но это уже ZeroIF архитектура.
Приемник может принимать сигналы в диапазоне 10 кГц - 30 МГц и использует принцип DDC
Ещё можно декодировать радиокоманды для радиоуправляемых игрушек.
Там как раз 27MHz.
10 кГц - 30 МГц - это про KiwiSDR.
Мой приемник только д 20 МГц.
На таких низких частотах антенны должны быть огромные.
В идеале должны быть, но приходится использовать то, что есть.
Как я писал в статье, у меня приемник на магнитную рамку принимает сигналы станции RBU, которая работает на 66,(6) кГц. Длина волны - 4.5 км)
На таких частотах большие антенны нужны только на передачу, на прием работают и маленькие (относительно нормально)
Вопрос по софту.
В OpenWebRX нужно заранее прописывать диапазоны bands, в конфиге. А хочется как в десктопных приложениях, тот же sdrpp, иметь возможность пролистать все частоты, например, от 20 мгц до 1ггц. Сам вопрос, есть ли версии/форки с такой возможностью?
Приделать бы ещё аналоговый управляемый смеситель и тогда будет красота.
А то даже FM радио не послушать.
Чтобы как у Малахит SDR.
FM радио тут не послушать - у KiwiSDR полоса звука всего 12 кГц (хотя вроде есть варианты на 24 кГц). Слишком мало для FM.
Тем более, что у KiwiSDR концепция - много пользователей могут подключаться к приемнику. С одиночным смесителем такое не провернуть.
Проще уж MSI SDR взять.
Есть готовые платы с Zynq + AD9361/AD9363 с диапазоном от 70МГц до 3ГГц и сейчас они довольно бюджетные. Бонусом получаем два RX и два TX.
неистово плюсую, хотя плюс подкинуть и не могу. тоже взял эту плату с расчетом повозиться с чем ни будь когда ни будь.
Когда не знаеш как работать с fpga результат похож на магию.
Появилось желание повторить.
rootfs от убунты, и уж точно NetworkManager слишком жирны и избыточны для такой задачи. (оно хорошо чтобы мышкой настраивать 10500 вариантов подключения)
по старинке это выглядит так https://wiki.debian.org/ru/NetworkConfiguration
А какой rootfs вы вы предложили использовать?
Хотелось бы иметь возможность скачивать библиотеки из репозиториев.
Для такой задачи самое оптимальное это собрать свою систему с помощью buildroot. Я писал статью для журнала FPGA-Systems Magazine :: FSM :: № BETA (state_1) "Buildroot это просто" как раз применительно к TRX-Duo (что близко к вашей работе)
И как в buildroot устанавливать пакеты? =)
Лучше Yocto но там все пакеты надо где то хранить на сервере/диске
Или Alpine какой нибудь, он минималистичен
Вот WEB-888 на Alpine и сделан, но я с ним никогда не сталкивался.
Зачем пакеты? Собирается все что надо и заливается или в образ или по SSH на работающую машину. Yocto сильно избыточен. У меня весь образ для моего проекта с Zynq на buildroot собирается с нуля за 35-40 мин.
Когда известно что и как собирать, пакеты действительно не нужны.
Но у меня весть процесс был сильно экспериментальный, даже сборка приложения тоже на ARM производится.
я правильно помнимаю что пример с TRX-Duo дает только linux без всякого софта касательно sdr? на основе довольно готового xlnx_rebase
кстати вот еще материал конкретно про antminer https://habr.com/ru/articles/842958/ до кучи https://habr.com/ru/articles/567408/
к сожалению @Astranome не совсем все обещанное запостил
но тут же еще надо засунуть вот это все https://github.com/iliasam/OpenZynqSDRApp которое тянет за собой горы либ которые надо где то взять
"к сожалению @Astranome не совсем все обещанное запостил" - все наработки постить - нет столько времени и сил, а что будет востребовано, угадать не могу. Например, я думал, что тема оснащения ZYNQ-ка (VGA/HDMI) дисплеем и "звуковой системой" - будет интересна большинству, оказалось - нет. Так что, как говорится, оставляйте заявки.
я думал, что тема оснащения ZYNQ-ка (VGA/HDMI) дисплеем и "звуковой системой" - будет интересна большинству
Я как-то экспериментировал с DeltaSigma на FPGA и сделал чисто "програмный" композитный видео выход. Получилось NTSC с 256 градаций серого, без всяких внешних компонент (;
ема оснащения ZYNQ-ка (VGA/HDMI) дисплеем
да казалось БЫ ДА. Но почему то до сих пор применяют даже аналоговый cvbs да VGA. А HDMI прослеживается тенденция любить в виде некоторого костыля на платах с rp2040
я правильно помнимаю что пример с TRX-Duo дает только linux без всякого софта касательно sdr? на основе довольно готового xlnx_rebase
Да, планировалось еще несколько статей. Но не сложилось. Возможно это повод написать для Хабра (;
Софта для SDR много всякого. И для каждого случая нужно выбирать, что больше подходит под задачу. В плане TRX-Duo была идея написать IIO драйвер для подключения к GNU Radio. Но пока н аэто времени нет.
да дело скорее в составе пакетов, можно и вручную почистить, вопрос скорее нужно ли делать систему как сервер (легче сломать) или все таки ближе к встроенной
посмотреть можно скажем debian но там уже типа такого можно сделать https://akhileshmoghe.github.io/_post/linux/debian_minimal_rootfs вроде есть и готовые архивы
c openwrt будет примерно такая же история по сути, но уже для web интерфейса с настройками там много сделано, даже слишком много, однако и ее используют не только в роутерах, пакаджи есть при этом
ну а buildroot будет больше к монолиту, там нужные пакаджи можно добавлять при сборке
надо еще мне petalinux глянуть там по сути должно быть тоже самое что и buildroot
Petalinux создает свой вариант rootfs, причем по умолчанию в INTRD.
Но там очень мало что есть (хотя и можно часть пакетов включить при сборке).
Но, насколько я понял, настроить загрузку пакетов из репозиториев там проблематично.
Замечу, что опыта работы с Linux у меня совсем мало.
у меня не вот великий опыт но чем дальше тем дальше кажется что везде одно и то же. да и практический интерес тут скорее если устройство будет в более менее массовом виде и шаловливые ручки будут кирпичить его.
вот такой костыль в голову пришел: собирать то лучше на плате - отлаживать удобнее, убунта там или что - дело второе. а вот релиз собирать виде жирного бинарника максимально статично с минимумом зависимостей. и засовывать его в "чистый" pentalinux сразу в INTRD - оно так и грузиться быстрее будет.
я бы пожалуй покопался в готовом образе pentalinux посмотреть что и как там, и наверное там какой-нить лоадер битрстрима в fpga есть
" вот релиз собирать виде жирного бинарника максимально статично с минимумом зависимостей"
Проблема в том, что там не так уж и мало зависимостей в проекте.
Вот у web-888:
https://github.com/RaspSDR/serveropenssh-server wpa_supplicant git dhcpcd dnsmasq u-boot-tools hostapd iptables avahi dbus chrony gpsd curl-dev htop frp jq libunwind zlib noip2 noip2-openrc netpbm musl-dev linux-headers g++ gcc cmake make minify fftw-dev fdk-aac-dev pkgconf perl gpsd-dev libunwind-dev zlib-dev sqlite-dev sqlite-static libconfig-static libconfig-dev patch automake autoconfМожет, еще какие-то нужны.
тут большая часть пакаджей нужна для функционирования самого linux и сборки бинарника. в сам бинарник включены вероятно libunwind fftw zlib fdk-aac, sql нужна для одного расширения dumphfdl
команда ldd <имя бинарника> детально покажет все .so нужные для этого бинарника даже вместе с путями
забавно, но вот в этих замечательных видеоуроках https://github.com/mkravch/fpga_lessons загрузчик и ядро собирают вообще вручную без всяких petalinux, здесь - в vivaldo https://github.com/astranome/Astra_S9_FPGA - но потом прикручивают тот же самый rootfs ubuntu (там рядом лежит свежаший rootfs debian)
однако openwrt и brainos похоже по другому собирают. в общем я может поторопился с выводами, но поиграться вариантов много
Я считаю, вопрос (RootFS) не стоит выеденного яйца.
Ядро надо собирать отдельно от всяких билдрутов, петалинуксов с ёктами. Тогда это станет осознанным процессом. Опыт сборки ядер пригодится не раз. И ещё придёт понимание, что не существует ядра под Дебиан 11 или Убунту 24.
Лучше всего брать готовые RootFS и не морочиться со сборкой. Берёте минимал/сервер версию Убунту-Дебиан и что нужно добавляете через apt-get. Есть версии как бы "специально для Xilinx-ZYNQ" - PYNQ и Xillinux :-). Лично мне более удобен Армбиан (версия для OrangePiOne) - всегда ей пользуюсь.
Если критичен малый объём , например, чтобы система уместилась на NAND 256 Mb, то OpenWRT-BrainOS-LeDe - отличный выбор. Есть удобный пакетный менеджер. Свежеустановленная LEDE занимает 11 Мб. (Разумеется, Ядро подойдет любое, 3,4,5,6 поколения - без проблем)
Ну уж если уж прямо горит собрать "свою" RootFS, то DebootStrap - то что надо. За полчаса можно собрать пару "Убунт-Дебианов".
Всё вышенаписанное - это не теоретические выкладки. Проверено. Опробовано. Скачать (u-boot, uImage, RootFS и др.) можно в группе https://t.me/+R_oA68EGEtM4NmM6
Не согласен. Пользуюсь buildroot уже больше 10 лет и очень сильно помогает. Под что только им не собирал. Недавно перетащил мой проект который был на AllWinner под Zynq за пару часов. Пакетов каких угодно. Свой пакет добавить - 5 мин. Собирает готовый образ одним make (легко интегрировать в CI/CD). Можно использовать toolchain который собирается внутри, или подсунуть свой (ускоряет сборку)
Не согласен :-) RootFS, который был на AllWinner, под Zynq запускается сразу, а не за пару часов.
А кроме rootfs? Загрузчик пересобери, ядро персобери, dts пересобери, boot.bin сделай. В buidroot оно "все само". Конечно если знаешь как (;
Я вот как то сразу даже не осознал сразу, но rootfs нужен автору данной истории в общем то чтобы удобно пакаджи качать, в первую очередь для сборки. dev пакаджи с исходниками можно заменить скачав нужные библиотеки с git. Ну и собирать на рабочей системе в принципе есть плюсы. А вот что оно то может повызывать командной строкой надо глядеть исходники (там всякие noip netpbm perl зачем то ставятся)
Если есть уже настроенная среда для Zynq то можно "просто" добавить исходники автора туда и посмотреть как он собирается , и сделать выводы.
"Загрузчик пересобери, ядро персобери, dts пересобери, boot.bin сделай" -- это делается один раз , без всякого "пересобери". "Загрузчик" встроен в BOOT.bin , также, как и u-boot и Bitstream. Ядро "пересобирать " не надо, один раз собрал и пользуйся. Или взять готовое для ZYNQ, есть 3,4,5, 6 поколения, скачивайте на здоровье. Повторюсь , ядро НЕ нужно адаптировать, обновлять, он будет работать на всех ОС, Angstrom, OpenWRT, ARCH, Debian - подобных. Devicetree.dtb делается один раз, под своё железо. Как и Boot.bin
Короче , "перетягивание" с Алвиннера выглядит так :
Создаётся раздел FAT (fat32) и туда копируются BOOT.bin uImage devicetree.dtb из вашего "загашника". Этот раздел должен быть Первым в таблице разделов. Размера 30Мб. достаточно. DevTree и zImage от алвиннера - в мусорку.
Второй раздел должен быть ext2- ext4, в нём и располагается RootFS . Если вы взяли РутФС от алвиннера, то содержимое /boot лучше сразу удалить, чтобы не запутаться.
можно создать ещё несколько разделов ЕХТ4 и разместить там другие ОС. Например у меня из первого раздела SD загружается Jammy, со второго PYNQ, с третьего Ubuntu 18.04, с четвертого Xillinux, а с NAND - OpenWRT
Не буду вас ни в чем переубеждать. Все надо пересобирать если у вас рабочий проект и развивается. Внутри PL появляются новые IP - для них нужны новые драйвера. Иногда даже uboot приходится пересобирать если изменился PL. Не получится "один раз собрал и пользуйся". Я уже год работаю над своим TRX "Brass" и все это из конкретного опыта. И мне лично buildroot очень облегчает развитие проекта. Если кому то проще с готовыми бинарниками - почему нет.
Я не тот, кто просит совета. Не буду вас ни в чем переубеждать. Не надо пересобирать всё - только то, что необходимо. Внутри PL не появляются новые IP сами по себе, их туда внедряю лично я и никто другой, поэтому с задачей "какие нужны драйверы (и нужны ли они вообще) и как их компилировать и "прописывать" в девайстри " предпочитаю справляться сам, а не надеяться на "смышлёных помощников". И конечно, после трёхлетнего опыта работы с ZYNQ 7000 волей-неволей начинаешь пользоваться готовыми бинарниками наработками - собственного приготовления разумеется. Со временем таких "готовых" становится всё больше. Я просто хотел поделиться своими наработками. Если кому то buildroot очень облегчает развитие проекта - почему нет.
я бы пожалуй покопался в готовом образе pentalinux посмотреть что и как там, и наверное там какой-нить лоадер битрстрима в fpga есть
Это вообще не проблема. Не нужно для этого лезть в PetaLinux. Штатно решения два: 1) загрузка через uboot (я так делаю) 2) загрузка через штатный драйвер fpga-region (позволяет частичную реконфигурацию)
PetaLinux это Yocto от Xilinx. Дико неповоротливая и капризная система!
Вся разработка конфигурации ПЛИС велась в среде Vivado 2022.2
Какой путь проходит verilog файл с момента написания до попадания в битстрим? Подобно классическому программированию на си. С, obj, elf ,bin
У меня вопрос немного не по теме. А можно ли вот так из какого ни будь хлама, типа платы от чего-то, сделать уловитель электромагнитных волн?
Я знаю что есть всякие электрослухи и простые в сборке проекты электромагнитных микрофонов, но мне интересно, можно ли превратить вещи которые не были для этого предназначены в такую штуку. Может кто знает.
Да, можно даже на обычный гвоздь ловить
Есть такое: https://www.qrz.ru/schemes/contribute/constr/sdr/
Очень важно хорошую антенну иметь.
Проблема в том, что сейчас в России наиболее мощные станции - FM, они на высоких частотах, просто так их не принять (хотя, используя специализированные копеечные микросхемы - легко).
На ДВ/СВ, которые раньше на детекторные приемники, или приемники прямого усиления принимали - море шумов и отсутствие российских станций, а иностранные - сильно далеко.
В этот раз самодельная зеленая защитная маска легла как-то неудачно, и плохо держалась, из-за чего плата выглядит некрасиво.
Прикольно выглядит, как олдскул :)
Вот бы ещё сделать sdr радар. Чтобы потом ещё синтезировать апертуру и зондировать окружающее пространство.
Существуют ли SDR RF учебно-тренировочные отладочные платы для экспериментов по радиолокации?
Чтобы можно было испускать разный ЛЧМ (ФЧМ) сигналы и записывать на SD карту ответы для анализа в виде потока ADC семплов.
Похоже что нужен fullduplex SDR. Гуглим :)
самый дешевый - HackRF не подойдет т.к. halfduplex
PlutoSDR суть есть учебный и где то дешевый https://pnsaeta.github.io/Learning_SDR/lesson08b.html
Pluto+ вроде как суть есть тот же pluto только купить можно на ali
lime (разные модели есть) наверное выйдет дороже но вот что уже есть https://luigi.ltd/2018-11-23/software-defined-radar-cw-doppler-radar-with-limesdr/
Первая мысль была: "Кто-то опять, спустя десятилетие, пишет про DDC приемник на хабре". А оказалось это вы же :)
Тоже делал трансивер на базе этой платы (даже выложил пару видео на ютюбе), только ещё более экспериментальный - на готовых модулях и соотвественно на плохих линиях данных. Посчитал что трудозатраты на изготовление своей платы превышают разумные пределы для использования платы от антмайнера (да и цель была получить не хорошие характеристики приема, а поэксперементировать с ПЛИС) и в итоге, дополнительно, решил делать плату на LTC2208 для девборды от QMTech на 7z020.
Пока с переменным успехом, опыта в разводке мало, уже 4я ревизия по борьбе с кростолками и прочей кашей :)
P.S. Спасибо за ту старую статью с DE0-nano - смотивировали, в то время, на некоторые эксперименты :)
Самодельный SDR приемник на Zynq