Обновить

Комментарии 31

Хабр - торт. Очень крутая статья

Очень круто! Помню, у меня не раз спрашивали, можно ли запустить сеть с PlutoSDR. И вот оно, наконец-то теперь есть реализация для этого. Спасибо за интересную статью.

Исследование выдаваемых OsmoMSC ошибок ("We only support voice calls") и настроек телефона показало, что телефон поддерживает только Not-transparent режим CSD, а Osmocom поддерживает только Transparent - про это прямо указано здесь: "TODO/limitations - non-transparent calls (V.110 RLP, V.120)".

Оказывается, такие девайсы ещё и довольно редкие.

У меня есть пара-тройка вот таких модемов от старых терминалов оплаты:

Когда-то думал попробовать поднять на них CSD, но сейчас посмотрел PDFку на них, узнал, что с ними тоже дохлый номер. Их собрат MC55i в Transparent mode тоже не умеет. Видимо, нужна какая-то совсем уж древность типа Nokia 2110i.

Я надеюсь, что когда-то у меня дойдут руки доработать Osmocom, и я смогу добавить туда поддержку Non-transparent CSD.

Еще интересно с RRLP попробовать разобраться.

Спасибо за статью! По поводу T/NT CSD, оба варианта поддерживаются и работают (если мы ничего не сломали). Большинство телефонов/модемов как раз поддерживают именно NT. Я так Nokia 3410 в качестве развлечения подключал к интернету. Присылайте PCAP-ы - погляжу.

В случае с NT часто возникает проблема несовместимости RLP: модемы разных производителей не могут договориться друг с другом. В идеале, модемы должны звонить друг другу не напрямую, а через IWF, которая решает проблемы совместимости. Но этот компонент пока еще никто не написал. Поэтому, проще всего на данный момент использовать модемы одного производителя, у которых одинаковая реализация RLP.

Кстати, какие версии Osmocom RAN/CNI у Вас установлены? В репозиториях Debian/Ubuntu чаще всего старье. Лучше всего добавить наш package feed (latest или nightly) и устанавливать пакеты оттуда: https://osmocom.org/projects/cellular-infrastructure/wiki/Binary_Packages.

Osmocom поддерживает только Transparent — про это прямо указано здесь: «TODO/limitations — non‑transparent calls (V.110 RLP, V.120)».

Ссылка ведет на wiki проекта osmocom-bb, который к RAN/CNI не имеет прямого отношения. То есть, это ограничение именно osmocom-bb, а не RAN/CNI.

Со стороны сети оба режима T/NT обрабатываются одинаково. Различия есть только на этапе установления соединения (CC signalling).

Спасибо за ответ.
У меня Ubuntu 24.04, соответственно, все части Osmocom  ставил из ее репозитория.
osmo-bsc --- 1.9.0-3build2
osmo-pcu --- 1.1.0-3build2
osmo-msc --- 1.9.0+dfsg1-2build2
osmo-bts --- 1.5.0+dfsg1-2ubuntu2

У меня, если я все верно понял, ошибки вылезали на этапе установления соединения, до второго телефона процесс вообще не доходил. MSC жаловался "We only support voice calls"
https://github.com/osmocom/osmo-msc/blob/97eeaff2ff42ec47fcd625ee7dbc3fdbc7ebaecb/src/libmsc/mncc_builtin.c#L96

Это очень старые версии. Например, релиз osmo-bsc 1.9.0 датируется 2022 годом. Актуальный релиз 1.14.1 (2026 год). Поддержка CSD была добавлена в 2023-м году.

Еще интересно с RRLP попробовать разобраться.

Давным-давно тоже пытался выудить координаты телефона через RRLP, и тоже не удавалось (даже если в фоне было запущено приложение навигатора и текущее местоположение было известно).

Советую посмотреть в сторону osmo-smlc (https://osmocom.org/projects/osmo-smlc/wiki/OsmoSMLC). Еще есть вот этот заброшенный репозиторий времен 2012 года: https://gitea.osmocom.org/cellular-infrastructure/osmocom-lcs.

Спасибо, знаю про этот репозиторий. Особенно интересен в нем RRLP Server: https://gitea.osmocom.org/cellular-infrastructure/osmocom-lcs/src/branch/master/rrlpd
Сам бы попробовал, если бы не нужно было части Osmocom патчить - с этим еще разбираться нужно.

OsmoSMLC - судя по описанию, поддерживает только Timing Advance based method, думаю, толку от него мало.

В итоге, я все-таки запустил CSD со своим телефоном в Non-Transparent режиме: https://habr.com/ru/articles/1039636/

Вот дойдут руки, сделаю. Спасибо за ссылки.

4 комментария за 2 суток после публикации. Это худший результат среди всех моих статей за 14 лет.
Возникает вопрос - стоит ли вообще писать такие длинные технические статьи на нынешнем Хабре...

Зато - плюсы и закладки. А чтобы прокомментировать - надо быть погруженным в или интересующимся темой. Желательно, так же иметь оборудование. Пожалуйста, продолжайте.

По сравнению с этой статьей: https://habr.com/ru/companies/timeweb/articles/784300/ тут обсуждения вообще нет, а железо там еще более дорогое.

Ну а всякие переводы или обсуждения ИИ набирают сейчас куда больше плюсов.

Только сейчас обратил внимание на рекомендацию, отображаемую в статистике статьи, по моему, выглядит несколько издевательски:

Да. Согласен. Habr стал не тот. Надо искать альтернативные варианты для поиска мест для размещения текстов. OpenNet, discord, livejurnal.

Стоит, конечно.

Я прочитал с большим удовольствием, понятно, что больше для общего развития - поскольку ни на работе, ни в хобби это использовать не смогу. Но что-то в нейросетке отложилось, так что вы писали точно не зря.

Выехал из Москвы в отпуск. Тут у полстраны интернет на неделю вырубили.

Банковские карты не работают

Плюс перебои с электричеством. Два дня от бензогенератора свет получал

4 комментария за 2 суток после публикации

Якобы это такая защита от ковровых бомбардировок украинскими дронами. Отключить населению интернет и электричество.

Я сам только сегодня в habr зайти смог.

А вы сюда загляните: https://habr.com/ru/articles/top/weekly/ и убедитесь, что люди активно пишут и дискутируют.

Очень даже стоит! За себя скажу: очень интересно было, но не всё понял потому что не настолько в теме :) читаю как триллер!

А статью нашёл у Катехизиса в канале :)

Достаточно известный HackRF One не подойдет — он half‑duplex.

А если подключить сразу два?

Если их синхронизировать (в идеале - тактирование от одного внешнего генератора сделать, хотя, возможно, можно один затактировать от другого) и обеспечить синхронизацию запуска - https://hackrf.readthedocs.io/en/latest/hardware_triggering.html
вероятно, и удаться запустить БС.
Но два hackrf явно дороже, чем один pluto-подобный трансивер.

К слову, у меня сложилось ощущение, что у моего трансивера чувствительность выше, чем у hackrf (у меня он есть). Уж не знаю, это заслуга 12 бит, или еще что-то.

Коэффициент шума HackRF One от 10 дБ (за исключением участка 2.2 - 2.7 ГГц, там 5 дБ). https://greatscottgadgets.com/2025/12-03-hackrf-pro-receive-sensitivity-and-noise-figure/

Коэффициент шума Pluto менее 2.5 - 3.5 дБ https://wiki.analog.com/university/tools/pluto/users/receiver_sensitivity

Итого чувствительность Pluto лучше на 6-7 дБ.

Разрядность АЦП при правильном проектировании тракта это больше про динамический диапазон, чем про сигнал/шум.

Строго говоря, разрядность АЦП в Pluto 4 бита, остальные 8 вытягиваются фильтрацией.

https://ru.wikipedia.org/wiki/Сигма-дельта-модуляция

На этом оборудовании можно декодировать LoRa модуляцию?

Декодировать можно практически на любом современном SDR.
Pluto поддерживается в SDRAngel, а там есть декодер Lora.

Этот декодер в Ангеле мне так и не удалось запустить. Типа "мы тут по приколу запилили Лора-декодер, но это экспериментальная разработка, так что декодирование не гарантируем. Спасибо за потраченное время"

Даже на HackRF хорошо работает. Декодируются сообщения в местной сети Мештастик

MeshStation + HackRF One
MeshStation + HackRF One

Можно ли при помощи Pluto SDR запрограммировать локатор дальномер?

Чтобы экспериментировать с различными зондирующими импульсами, а в перспективе делать зондированный земле обзор через синтез апертуры (SAR).

Поэтому стоит перейти к трансиверам, ведущим свою родословную от PlutoSDR.

Есть ли в открытом доступе схемотехника для изделия Pluto SDR, а в идеале полный комплект КД ?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации