Контроллер (что-то типа младших cortex-m0 или даже AVR может хватить) может пассивно слушать обмен по SPI, просыпаться по активности, определять, на какую частоту настраивается синтезатор в MSi001 и какой вход включается, коммутировать соответствующий фильтр и снова засыпать до следующей транзакции по SPI.
Вот бы кто написал такой скетч для ардуины... чтобы можно было настроить под любой набор фильтров
Зачем все так сложно, все программы вроде поддерживают CAT интерфейс, ардуинка нормально с ним работает, достаточно забирать частоту из рограммы и включать нужный фильтр, либо еще что ни будь, вплоть до внешнего энкодера и выбора частоты кнопками, и внешнего ЖК экрана.

fly2015
все программы вроде поддерживают CAT интерфейс
Какой интерфейс? Какие все? У меня такого интерфейса в ноутбуке нет!

Или вы предлагаете прикостылись ещё один usb провод к ещё одному usb устройству? Спасибо, но не надо. И ладно бы msi2500 работала через хабы... тут можно было бы ещё стерпеть и сделать "комбинированное" устройство.

прикостылись ещё один usb провод к ещё одному usb устройству? Спасибо, но не надо. И ладно бы msi2500 работала через хабы
Если лишний провод проблема, то тогда это решение не пойдет. Про хаб не знал, не было необходимости. Сегодня надо будет попробовать.

fly2015
Если лишний провод проблема, то тогда это решение не пойдет.
Да, в такое я уже играл - наигрался.

надо будет попробовать.
попробуйте... если решите эту проблему (потерю буфферов) - вам цены не будет =) Тут я готов рассмотреть любые варианты, разве что кроме запайки кабеля наглухо в корневой хаб. Да и то, боюсь, не поможет. Там просто явный баг микрокода. С другой стороны я не вижу чтобы особо жаловались на это. Вероятно в проприетарном виндовом драйвере всё закостылено.

если решите эту проблему (потерю буфферов)
Как это проверить? Так просто через хаб работает, проверил в SDRRuno и SDR Consolе. Сейчас поставил на прогон, будет декодировать FT8, посмотрим, что будет дальше.

fly2015
посмотрим, что будет дальше.
Да ничего не будет. Если он запустился стабильно - он будет работать стабильно.

Вот бы кто написал такой скетч для ардуины
Я может попробую, когда (если) руки дойдут развести платку под свой RSP1-подобный девайс с набором фильтров 5..7 порядка. Но никаких ардуин не будет. Только нормальный GCC и make/cmake.

sibrat
У меня же проблема потери (точнее рассинхронизации) буферов вроде решена на 100%. После https://github.com/vladisslav2011/libmirisdr-4/commit/d9d7584d28210e3170a47a0a5ba54dd84684cbd3 ни одного кривого запуска не было. Все стабильно запускается и работает даже в 14-битном формате на 10Msps (правда MSi2500 довольно сильно греется в таком режиме).
С хабами проблем не замечал. В городе только через хабы и работает (FE1.1, VL815, VL817). Если провода не шевелить и не бить по антенне статикой работает стабильно.

Померил вход немодифицированного фиолетового свистка векторником - увидел вполне приличное согласование в районе 1200МГц. Попробовал принять на фиолетовый свисток с невыпаянным MMIC GPS L5/Galileo E5 - все глухо. MMIC перегружается сигналами LTE и DVB. На HackRF с той же антенны все четко принимается. Надо наверное выехать за город подальше от сотовой связи и попробовать там.

vladisslav2011
Если провода не шевелить
во-во... Я бы даже сказал если на них не дышать. Сейчас у меня новый ноутбук, кабель со свежими разъёмами. Я его не трогаю, не отключаю и всё работает стабильно.

После https://github.com/vladisslav2011/libmirisdr-4/commit/d9d7584d28210e3170a47a0a5ba54dd84684cbd3
А ваша версия драйвера тут вообще не причём. С проприетарным драйвером всё точно так же. Проприетарный ресинкал всегда, но проблема то в том что буффер-то потерян, он же не пересылается повторно. Каждая потеря - выпадение выборок. А они могут вылетать до 10 раз в секунду и чаще.

Четыре разных свистка, три разных ноутбука, куча разных кабелей с хабами и без - потеря буфферов присутствует везде. Причём чем "прогретее" свисток - тем меньше интенсивность. Свисток лежащий в ящике пару месяцев гарантированно не запустится.
Единственное чего я не пробовал - менять ОСь. У меня давно и везде arch linux. Но это уже изотерика какая-то...

вот так это звучит http://www.radioscanner.ru/uploader/2022/gqrx_20230112_032557.mp3
Это приём частоты без модуляции. каждый щелчок - потеря буффера. (В случае использования libmirisdr сопровождается сообщением об этом в консоли)

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

Spirex
Это ведь решается переходом с изохронных, на крупноблочные передачи.
Разверните вашу мысль. Кем решается? Не думаю что в моей власти изменить алогритм роботы msi2500, добавить ей кеша... Подозреваю что она транслирует данные с АЦП сразу в выходной буффер USB интерфейса.

P.S.
Потратил полдня, поставил на безголовый debian сервер всё что надо... нет, чуда не произошло. Сначала показалось что произошло, но потом оказалось что нет. Всё так же теряет буффер, пусть и менее интенсивно и даже терпит наличие хаба. (на ноуте мне тоже удавалось "уговорить" его работать пару раз)

Всё так же теряет буфер
Ка я и писал, нужно перевести режим передачи на крупноблочные, (Bulk Transfer). Решается софтом, точнее библиотекой.
Удочку дал, дальше сами)

sibrat
Подозреваю что она транслирует данные с АЦП сразу в выходной буффер USB интерфейса.
Пока нет синхронизации Clock, никакие танцы с буферами и их размерами не помогут.
А Clock есть только на оптических входах / выходах звуковых карт и в домашних кинотеатрах.)

Programmist
Это что за философия ситхов? Разумеется проблема синхронизация принципиально не решаема, но 10 дропов в секунду и один дроп в минуту это не одно и то же.
С другой стороны вы подсказали что именно калибруется при старте msi2500, другое дело что пользы это понимание не несёт :)

Spirex
Удочку дал, дальше сами)
Дальше сами что? Создавать микросхему где такой режим поддерживается? Какой ценный совет, как же мы без вас раньше жили?!

sibrat
10 дропов в секунду и один дроп в минуту это не одно и то же.
Разумеется не одно и то же. В таком случае, Вы должны знать, что в компьютере нет интерфейсов для передачи данных в реальном времени, а микрочипы имеют свой собственный дроп и джиттер, как это не печально.
А проблема решаема, но изготовлением собственного специализированного ЦАП.
И если это не удалённый приёмник, ничто не мешает разместить его на одной плате с АЦП.

sibrat
потеря буфферов присутствует везде
Это очень странно. У меня ни на одной машине буферы не теряются (после начальной синхронизации при запуске).

Spirex
нужно перевести режим передачи на крупноблочные, (Bulk Transfer)
Так вроде как уже все сделано: https://github.com/vladisslav2011/libmirisdr-4/blob/bandwidth_and_stability/src/libmirisdr.c#L154
У меня на 2-х машинах, одна из которых laptop на 10MHz/14bit потерь не наблюдается.

Programmist
Пока нет синхронизации Clock, никакие танцы с буферами
Переход между тактовыми доменами делается добавлением защелки или FIFO. Но это как бы немного другое программирование...
в компьютере нет интерфейсов для передачи данных в реальном времени
В смысле с нулевым latency?
Тогда и специализированные ЦАП/АЦП не помогут. Это в принципе невозможно. Даже в аналоговых схемах будут задержки.
Проблема с потерями решается буферизацией: или низкие задержки или высокая скорость без потеррь буферов. В MSi2500 буферизация достаточная.

vladisslav2011
специализированные ЦАП/АЦП не помогут. Это в принципе невозможно. Даже в аналоговых схемах будут задержки.
В принципе – возможно. Возможно получить приемлемую задержку в 50 – 100 мсек.
При передаче данных по UDP, что само по себе не гарантирует доставку.
Работа с TCP на практике вызывает дополнительные сложности.
О нулевой latency, конечно, речи не идёт.

Но это как бы немного другое программирование...
Наверно другое. И далеко не всё можно безболезненно перенести на микроконтроллер.

//
Понятно, что мои рассуждения здесь не имеют особого практического смысла, но потери сигнала при передаче были, есть и будут.
Слишком много факторов влияющих на эту напасть.
А игры с размером буфера говорят только о том, что проект находится в стадии создания.
Ещё хороший вопрос - какого буфера?
Когда их там десятки, и все должны быть оптимизированы по размеру, как шестерёнки в часовом механизме.

vladisslav2011
Это очень странно.
Остаётся считать что это моя карма :) Других вариантов не остаётся. Единственное что однозначно понятно - это связано с качеством USB интерфейса. Реже всего глючит именно фиолетовый включаемый непосредственно в порт.

vladisslav2011, Так вроде как уже все сделано знаю, благодарю!
применяю давно режим bulk, а sibrat сидит на изохронных передачах (проходили), я уже не знаю как прямее написать)
sibrat, Создавать микросхему где такой режим поддерживается?
Да не надо ничего создавать, у Вас софтовая проблема, перейдите на Bulk и всё.

sibrat
это связано с качеством USB интерфейса
Это связано с качеством всех интерфейсов. Дело в том, что помимо скорости передачи данных есть ещё такой параметр, как возможность интерфейса обеспечить стабильность этой скорости.
И если при приёме записи он не важен, то при приёме в реальном времени имеет первостепенное значение.
У меня нет MSi2500, для передачи данных используются совершенно другие чипы и другие устройства, но проблема у всех одна.

Spirex
применяю давно режим bulk, а sibrat сидит на изохронных передачах (проходили), я уже не знаю как прямее написать)
а вы завязывайте умничать и говорите как его включать :) В доках мирикса упомянуто что такой режим предусмотрен в API их драйвера... где-то.

P.S.
Всё понятно. В исходниках драйвера вижу опции bulk/isoc в исходниках soapymiri не вижу...

P.P.S.
В исходниках драйвера bulk, вроде, по-умолчанию, а значит именно он и включен и используется раз soapymiri переключать его не умеет.

P.P.P.S
"The benefit of the isochronous mode driver is that it reserves the necessary USB bandwidth, something that does not happen with a bulk mode driver. As a consequence, depending what else the PC is actually doing, there is a greater risk of buffer overflows and packet losses with a bulk mode driver than with an isochronous mode driver. We do occasionally get complaints from developers that we chose not to use a WinUSB (bulk mode) driver, but the reason for doing this was to open up the range of platforms capable of using the device’s full capability."©SDRplay team

the truth is out there

P.P.P.P.S
vladisslav2011
подскажи как правильно пропатчить чтобы собрать с изохронным режимом по-умолчанию.

sibrat
В SDRuno это включается в меню.

подскажи как правильно пропатчить чтобы собрать с изохронным режимом
Поменять в строчке https://github.com/vladisslav2011/libmirisdr-4/blob/bandwidth_and_stability/src/libmirisdr.c#L154 MIRISDR_TRANSFER_BULK на MIRISDR_TRANSFER_ISOC
Но зачем?
В изохронном режиме практически невозможно получить стабильную работу и максимальный sample rate ограничен ~6Msps (192mbps) в идеальных условиях.
У меня потери прекратились только после перехода с изохронного на bulk. В bulk можно выжать около 440mbps или теоретически около 14 Msps в идеальных условиях. Практически получается 10..11 Msps в реальных условиях через хабы. Вполне достаточно при полосе тюнера в 8MHz.

Потестировал свисток с MMIC с антенной на 1200MHz на предмет приема GNSS за городом. Результат отрицательный. Еле-еле захватился 1 спутник Galileo на L5 через 10 минут поиска. При этом на L1 свисток с mmic без внешнего LNA вполне принял достаточно бортов для получения решения.
Протестировал также запись в 10-битном упакованном формате IQ на КВ и результаты мне понравились. Заметного подъема шумовой полки в полосе пропускания входного фильтра MSi2500 не наблюдается и сохраняется возможность приема на краях полосы пропускания ценой увеличения занимаемого файлами объема на 25% по сравнению с 8-битном форматом.

vladisslav2011
Поменять в строчке
Вот и разобрались =) Я собирал master а не bandwidth_and_stability а там собирается изохронный режим. :)
Теперь работает даже с пятиметровым кабелем и хабом :)
merci beaucoup

P.S.
у драйвера обнаружилась серьёзная проблема - при попытке открыть два разных свистка драйвер этого, кажется, не вдупляет, удивляется и вешает подсистему конкретный порт usb аж до такого состояния:
[ 1557.991510] usb 1-6: device descriptor read/64, error -110
[ 1573.571429] usb 1-6: device descriptor read/64, error -110

спасает только ребут системы

[ 1557.991510] usb 1-6: device descriptor read/64, error -110
Таких ошибок у меня не было. Обычно такая ошибка намекает на плохой кабель.
Прямо сейчас 2 свистка работают на 10Msps без потерь буферов через 2 разных USB хаба в 2-х экземплярах Gqrx...
Ошибка была только когда 1 хаб из-за помех по питанию глюканул и стал упорно определяться как Full-speed. Но эта ошибка была такая:
failed to use alternate setting for Bulk mode on miri usb device 1 with code -5

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

vladisslav2011
Обычно такая ошибка намекает на плохой кабель.
обычно да, но это не обычная ситуация. Воспроизводится 100%.

Я разобрался подробнее в чём дело - драйвер вешается и блокирует порт если в gqrx напутать с serial и index.

P.S.
unbind / bind порта через /sys/bus/pci/drivers приводит порт в чувство :)

Изучая вопрос влияния шумов LDO на уровень шума приёмника я, внезапно, осознал, что разные клоны имеют разное напряжение питания чипсета: от 2.85 до 3.3 вольта. При этом спеки msi001 приведены для питания аналоговой части 2.85. Возникает резонный вопрос:
А в чём сакральный смысл? Есть ли смысл пытаться менять схемы питания для обеспечения этими самыми 2.85 вольтами?

Суть в том, наверное, что лдо на 3-3.3в более массовые и дешевые.

А проверять разницу надо не по собственному, а подавать с кварц-генератора максимально мощный (до тех пор, пока приемник дает прирост линейно, от повышения этого сигнала ступенчатым аттенюатором) и смотреть шумовую юбку несущей по сторонам.
Какой-то цифровой китай-ГСС для этого не годится, они будут иметь больше собственного шума.

Zmej
смотреть шумовую юбку несущей по сторонам.
Это будет оценка фазового шума тактового генератора. Шумы по питанию и свисты самовозбуда LDO это другая проблема - их видно возле нулевой частоты.

О поисках возбудов стабилизатора вроде вопрос не стоял.
О каких по серьезному преобладающих еще шумах тогда вести речь, это же не dc/dc-преобразователь.
Любой остаточный шум возле нуля в такой архитектуре с преобразованием в ноль-пч не минуем и в общем-то должен накрываться шумом эфира, если правильно согласована система по чувствительности с антенны.

Короче говоря, овчинка выделки не стоит. Возбуды разве что убрать подбором другого лдо, если они есть и реально чем-то не дают жить. В своих старых клонах ничего проблемного не видел, при работе с эфиром, не без антенн.

Zmej
овчинка выделки не стоит.
да я вроде никого и не заставлял ничего выделывать :) Мне перебросить микросхемку ldo - пять минут, включая время достать из шкафа фен. Я спросил есть ли смысл перевода с 3.3 вольт на 2.85. Хотя бы теоретический.