Timeweb.Cloud

Приветствую всех!

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

И вот наконец в мои руки попал не просто какой-то контроллер, а очень примечательный экземпляр — от «концептуальной» электрички ЭМ2И, коих в наши дни уже не осталось.

Итак, в сегодняшней статье поговорим о том, как устроен такой контроллер и как его подключить. Традиционно будет много интересного.

❯ Суть такова

Так получилось, что ко мне в руки попал контроллер от старого электропоезда ЭМ2И. И, само собой, напрашивалось единственное верное решение — подключить его к Trainz или «Метрострою».

Удивительно, что при наличии огромного количества железнодорожных симуляторов нет практически никакой периферии для них. Если вспомнить, сколько всякой амуниции выпускается для фанатов авиации, то окажется, что для желающих покататься на поезде у себя дома по сути нет ничего.

Безусловно, кое-что всё же существует. Есть такая штука как Raildriver, которая даже нативно поддерживается в Trainz, однако в России оказалось реальнее достать настоящий контроллер, нежели её.

Немного про электропоезда ЭМ2И

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

ЭМ2И являются детищем более старых проектов — ЭМ1 и ЭМ2. Все эти поезда — глубокие модернизации куда более старых ЭР2. Серия была предназначена для эксплуатации на линии в Домодедово в качестве экспрессов.

Электропоезд обладал целым рядом нововведений — новые сцепные устройства, полупантографы, электронная система управления. Выпускались они на Московском локомотиворемонтном заводе, а запчасти для них поставляло некое ЗАО «Спецремонт».

Модель была многообещающей — тут вам и скорость аж в сто шестьдесят километров в час, и мягкие сиденья, и салон повышенной комфортности, всё как в дорогих иномарках японских поездах.

Увы, с самого начала история этих электричек пошла не в их пользу — уже на испытаниях выяснилось, что многие характеристики не соответствовали заявленным, а в конструкции имелось немало фатальных недостатков. Эксплуатировались необычные поезда совсем недолго, в первой половине нулевых, а большую часть своего существования они стояли в депо или на базах запаса и тихонечко гнили. Проект вышел крайне неоднозначным: стоили машины очень дорого (практически как новые ЭД4М), имели небольшой срок службы (ведь ходовая часть осталась от старых ЭРок), а также были крайне ненадёжными и неудобными в ремонте. В итоге от их использования довольно быстро отказались, а в 2019-2020 годах все машины (точнее, то, что от них осталось за долгие годы стояния на открытом воздухе и постепенного разграбления вандалами) были порезаны на металлолом.

Впрочем, многие (как и я) до сих пор жалеют, что не успели прокатиться на этом неудачном, но всё же весьма интересном МВПС.

Обзор оборудования

Ну что же, переходим к нашей железке. Ко мне в руки попал контроллер машиниста КМ-4А, снятый с одного из списанных таких поездов. Скручен он был ещё много лет назад, отчего он не успел сгнить, пострадать от рук вандалов или стать собственностью охотников за драгметаллами.

А вот и подопытный экземпляр. На нём две ручки — реверс и непосредственно управление. Также имеется тумблер.

Позиции.

Вид снизу. Видно сердце контроллера — кулачки. В нынешних электронных вагонах применяются бесконтактные контроллеры машиниста (БКМы), где вместо кулачков и контактных групп используются датчики (оптические или магнитные). Чуть позже я расскажу и про этот тип контроллеров, ну а пока что будем разбираться с нашим.

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

Разъём для связи девайса с внешним миром — DB37F. Закреплён он на обычном куске фанерки.

Наклейка того самого «Спецремонта».

А вот механизм. Дискретное перемещение ручки обеспечивается за счёт детали сложной формы, в которую упирается подпружиненный ролик. Шестерни обмазаны густой липкой смазкой.

Вдалеке видно тот самый прижимной механизм.

Нужное усилие обеспечивается двумя мощными пружинами.

По бокам находятся толстые стальные пластины, в которые вкручиваются стойки и вставляются валы. Из-за их толщины (десять миллиметров) скромный по размерам контроллер имеет весьма внушительную массу — чуть больше семи килограммов.

Кулачки

Контроллер внутри очень похож на командоаппарат.

В самом деле, в нём имеются всё те же самые контактные элементы, которые переключаются расположенными на вращающемся валу кулачками. Разница лишь в том, что в командоаппарате вал вращается электромотором, а тут он связан с ручкой контроллера машиниста.

Вот для примера положение кулачков в разных позициях ручки.

Реверс

Начнём, наверное, с самого простого — с ручки реверса.

Для неё выделено сразу три кулачка, один из которых не используется. От оставшихся контактных групп идут четыре провода — по одной на каждое из двух «рабочих» положений.
Помимо этого ручка реверса блокирует перемещение основного вала. Когда она стоит на нуле, ручка контроллера заблокирована. В то же время нельзя переключить реверс на ходу. Достигается это за счёт использования диска с прорезью на основном валу и ролика на реверсоре. Когда вал находится в положении, отличном от нуля, ролик не может встать в прорезь, отчего реверс не переключается. При этом, когда ролик находится на своём месте, диск не может повернуться, что обеспечивает блокировку ручки контроллера.

Вот положение этих двух деталей при нулевой позиции реверса.

А вот — когда включён реверс, а ручка повёрнута на ход или тормоз.

Распиновка

Чтобы разобраться с работой самого контроллера, пришлось выяснить распиновку, благо проблем с её определением не возникло. Она здесь оказалась вот такая:

1. Пятый кулачок (нормально разомкнутый контакт)

2. Четвёртый кулачок (нормально разомкнутый контакт)

3. Третий кулачок (нормально разомкнутый контакт)

4. Второй кулачок (нормально разомкнутый контакт)

5. Первый кулачок (нормально разомкнутый контакт)

6. Третий кулачок (нормально замкнутый контакт)

7. Второй кулачок (нормально замкнутый контакт)

8. Назад

9. Вперёд

10. Ничего

11. Вперёд

12. Назад

13. Второй кулачок (нормально замкнутый контакт)

14. Третий кулачок (нормально замкнутый контакт)

15. Первый кулачок (нормально разомкнутый контакт)

16. Второй кулачок (нормально разомкнутый контакт)

17. Третий кулачок (нормально разомкнутый контакт)

18. Четвёртый кулачок (нормально разомкнутый контакт)

19. Пятый кулачок (нормально разомкнутый контакт)

20. Ничего

21. Ничего

22. Ничего

23. Ничего

24. Ничего

25. Ничего

26. Ничего

27. Ничего

28. ЗАП/ОТП

29. ЗАП/ОТП

30. Ничего

31. Ничего

32. Ничего

33. Ничего

34. Ничего

35. Ничего

36. Ничего

37. Ничего

Далее берём мультиметр и выясняем, какие контакты в какой позиции замкнуты.

Далее объединяем всё в одну таблицу:

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

Подключение к ПК

Для того, чтобы связать контроллер с компьютером, понадобится всего-ничего — плата на самом дешёвом МК с поддержкой USB HID в лице Raspberry Pico, вилка DB37 и немного проводков...

> Продолжение в источнике материала на Хабре. Увы, все фото не влезли (их действительно много), а именно в них вся суть и самое вкусное. Так же там элементы кода и прошивка :)

• Написано специально для Timeweb Cloud и читателей Пикабу. Подписывайтесь на наш блог, чтобы не пропустить новые интересные материалы.

• Также подписывайтесь на наш телеграмм-канал — только здесь, технично, информативно и с юмором об IT, технике и электронике. Будет интересно.

• Облачные сервисы Timeweb Cloud — это реферальная ссылка, которая может помочь поддержать наши проекты.

Многие помнят линейку телефонов Siemens 65-75 серии, которые были в ходу около 20 лет назад. Мы попробуем провести необычный эксперимент на их основе, для чего напишем небольшую управляющую библиотеку на C, а также изменим код одной из встроенных в ОС Linux утилит. Подробнее в статье.

❯ 1. Аппаратная часть

В серии телефонов «Siemens 75» существовали такие модели, как C75, ME75, CX75 и прочие. Они различались между собой дизайном корпуса и некоторым другим функционалом. Но их основные элементы были, во многом, схожи. Например, дисплей разрешением 132x176. Для работы с данным проектом в коробке с различным электронным мусором были обнаружены останки подобного телефона. Состояние изделия за 20 с лишним лет очень плохое, надписи стёрлись, но я предполагаю, что это был экземпляр телефона C75 – BenQ, позднего выпуска. Родной процессор телефона давно уже умер — какое-то время назад удавалось оживить его, прогрев плату паяльным феном, но теперь осталась лишь безжизненная плата и оболочка. Поэтому я решил перехватить информацию на уровне дисплея.

Нас интересует, в первую очередь, этот самый дисплей. Поэтому, для начала, разберём устройство:

Поскольку любая наука стоит «на плечах гигантов», я не буду повторять материал о видах дисплеев в данном телефоне. Ознакомиться с ним вы можете самостоятельно, это описал ещё в 2013 году Кизим Игорь, в своей статье.

У меня уже был некоторый опыт работы с данным дисплеем. Используя библиотеку, взятую из статьи Игоря, я подключал данный дисплей к микроконтроллеру ATmega8. Однако, это было более 5 лет назад, поэтому, для начала, я решил проверить, а работает ли вообще данный дисплей. Для чего собрал схему Игоря. Её ключевые особенности: установлен стабилитрон по питанию дисплея (5V -> 2.9V), установлены резисторы для понижения уровней логики (5V -> 3.3V). Однако, нам необходимо ещё одно напряжение – 12V, для питания диодной ленты подсветки. Поскольку я не хотел городить дополнительный инвертор, я расковырял подсветку и заменил диоды на те, которые могут работать напрямую от 5V, подсоединив их не последовательно, а параллельно. Таким образом я избавился от лишнего провода питания, хотя и качество подсветки несколько пострадало.

Теперь я имел 2 провода питания (+5V, GND), и 5 сигнальных проводов с уровнем логики 3.3V.

Однако, контроллера ATmega8 под рукой не оказалось, но был китайский клон Arduino Uno на ATmega328. Я попытался поискать библиотеку Arduino под этот дисплей, и нашёл такую. Но она была заточена под ESP8266. Хотя идею замены SPI в функции Send_to_lcd с программного на аппаратный я намотал на ус:

В итоге я взял оригинальную библиотеку Игоря (Igoryosha), и портировал её под Uno, просто заменив в текстовом редакторе функции присваивания (напр. LCD_CLK=0) на ардуиновские digitalWrite(LCD_CLK, LOW). Библиотека запустилась без особых проблем.

Так как в ней используется программная имитация SPI, выводы GPIO можно назначить произвольно (кроме тех, что заняты RX TX). Библиотеку под Arduino Uno для данного дисплея в итоге я оставил у себя на github, в ветке main.

Результат запуска программы и скорость работы такого SPI можно увидеть наглядно на видео:

Теперь можно подсобрать телефон для удобства работы. Я вытащил динамик, чтобы вывести провода через отверстие.

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

❯ 2. Подключаем Orange Pi GPIO

Как можно было увидеть в предыдущем фрагменте, скорость отрисовки картинки просто черепашья. Оно и неудивительно: контроллер работает всего лишь на 16 МГц, ещё и использует программный SPI для вывода картинки. Ситуацию нужно исправлять, взяв более мощный и производительный контроллер. Тут я натыкаюсь на статью хабровчанина Hoshi.

В ней он данный дисплей подключает к Raspberry Pi, и использует его как «монитор». Поскольку мы стоим на плечах гигантов, было решено проследовать его примеру, и не изобретать ещё какие-либо методики. Но Raspberry Pi у меня не оказалось, нашёлся только Orange Pi PC.

Поэтому запустить код Hoshi без переделки у меня бы не вышло: в своей статье он оперирует GPIO через библиотеки чипсета bcm2835. Так как данного чипсета на моей плате нет, и библиотеку подключить не выйдет. Я начал поиски способа, как подключить GPIO на моём чипсете h3. Выяснилось, что для этого нужна библиотека wiringPi (на текущий момент уже не поддерживается официальными авторами). Однако, просто установить её через apt-get оказалось мало: устанавливался оригинал под Raspberry. Спустя некоторое время была найдена модификация этой библиотеки от zhaolei. Я собрал её через build (ветка h3), и именно она оказалась рабочей для моей платы. После выполнения build библиотека установилась в систему, и стало возможным вызвать её из требуемого места (например, проверить пины с помощью sudo gpio readall).

Назначение выводов GPIO для «апельсина» назначается через define по аналогии с Arduino:

Также следует отметить следующий момент: в схеме Igoryosha для AVR использовался логический уровень +5В, а на Orange Pi разъем GPIO сразу оперирует уровнями +3.3В. Поэтому резисторные делители я убрал. В итоге получилась следующая конструкция:

Однако, у меня сходу не получалось завести аппаратный SPI. Поэтому для повторной проверки работоспособности дисплея я взял, опять же, библиотеку Игоря из-под AVR, портировав её теперь и под wiringPi. К счастью, особых замен не понадобилось, только поменять в коде LOW и HIGH на 0 и 1 соответственно. Даже функции delay в wiringPi аналогичны ардуиновским. Также на данном этапе библиотека лишилась практически всех графических функций отрисовки примитивов, кроме отрисовки, непосредственно, одного кадра из буфера.
После чего я собрал программу через gcc (gcc –o example example.c –lwiringPi), и запустил из терминала.

Результат можно увидеть на видео:

Однако разницы, по сравнению с Arduino, практически нет. Отрисовка стала шустрее, но лишь немножко. Оно и неудивительно: чаще всего вызывается метод передачи по SPI (Send_to_lcd), а так как он у нас всё ещё программный, прироста в скорости мы не видим, сам GPIO работает достаточно медленно, по скорости сопоставим с обычным Arduino. Поэтому нам нужно исправлять ситуацию, задействовав аппаратный SPI.

❯ 3. Подключаем аппаратный SPI

Для замены программного SPI на апаратный можно, также, задействовать библиотеку wiringPi, а именно, из wiringPiSPI.h использовать функции wiringPiSPISetup и wiringPiSPIDataRW. Функции эти несколько хитрые. Но перед тем, как их использовать, нужно включить этот самый SPI. Информации о том, как это сделать конкретно на Orange Pi PC также в интернете нет, но удалось найти направление, в котором нужно искать. Немного погуглив, я выяснил, что spi включается правкой файла /boot/armbianEnv.txt (актуально для моей версии системы Armbian_23.11.1_Orangepipc_jammy_current_6.1.63_xfce_desktop.img).

В него нужно добавить следующие строки:

После чего сделать sudo reboot, и у нас в /dev/ появляется spidev0.0. Проверить это можно, выполнив команду ls /dev | grep spi. Если spidev0.0 появился, дальше библиотека wiringPiSPI подхватит его. Теперь контакты дисплея CS, CLK, DATA нужно подключить к пинам SPI0, как это сделано у Hoshi. Распиновка (40-pin) полностью соответствует Raspberry Pi. Пины RS и RESET оставляем на попечении обычного GPIO.

Однако, просто заменив SPI на аппаратный, я заметил, что FPS отрисовки практически не поменялся. Проблема заключалась в том, что если отправлять по одному байту, то с каждой посылкой SPI будет заново открываться и закрываться, а эта процедура отнимает очень много времени. Поэтому было решено отправлять данные пачками максимально возможной длины.

Возникла следующая проблема: буферизация пакетов SPI. На данном устройстве мы можем отправить только 4 килобайта данных за одну посылку. Наша страница же занимает порядка 44 Кб: 132*176*2, так как используется 16-битная цветность. В качестве решения можно было либо увеличить буфер SPI, что возможно, однако, мне не хотелось прибегать к данной методике. Поэтому я просто в своём коде раздробил страницу на 11 пачек:

И используя memcpy, копировал перед отправкой каждую пачку в буфер. К слову, это необходимо ещё и потому, что буфер побайтово очищается в процессе передачи, заменяя выходные данные на входные с буфера RX (MOSI pin).

Также библиотека позволяет регулировать скорость: от 500 КГц до предела в 32 МГц. Делается это в момент инициализации: int fd = wiringPiSPISetup(0, 32000000); мы выставляем канал 0, и скорость в 32 МГц.

После вышеописанных процедур мне удалось получить скорость кадров в 60 FPS. Я не уверен, способен ли дисплей отрисовать данные с такой скоростью, но таймер рапортовал именно так. Можно увидеть это на видеозаписи:

На первой половинке видео можно увидеть кусочек области дисплея, который передаётся за одну отправку (4096 байт), это примерно одна десятая всей экранной области. Скорость шины выставлена в 500 КГц. На второй половинке отправка всех 11 областей, и скорость шины в 32 МГц. То есть, скорость передачи примерно порядка 20 Мбит/сек. В данном случае, я считаю, достигнут потолок пропускной способности всей нашей сборки.

❯ 4. Выводим статичный bmp кадр

Следующее, что сделал Hoshi в своей статье – вывел статичную картинку, получив проблемы с цветностью. Поскольку я иду по его стопам, я попробовал вывести картинку из буфера, используя частично его код, поменяв только сдвиг (offset, так как мой заголовок занял другое количество байт). Однако, сначала я получил такую картинку, как показана на левой части изображения, и, лишь потом, такую, как на правой:

Я взял такую же картинку, как у Hoshi, и получил примерно такой же результат. Подводный камень заключался в следующем:

1. Два байта нужно поменять местами, этот момент был в коде Hoshi. Либо же добавить/убрать один лишний байт в начале пакета, чтобы вызвать сдвиг всего массива.

2. Я сохранил исходную картинку через Adobe Photoshop в формат BMP 16-bit. Однако, как выяснилось после просмотра в HEX-редакторе, белый цвет у меня получился не FF FF, а FF 7F, вследствие чего он отображался, как бирюзовый, и остальные цвета также имели искажения:

Произошло это из-за того, что редактор сохранил BMP файл в режиме X1R5G5B5 (с альфа-каналом), а у нас в дисплее используется R5G6B5, то есть, зелёный цвет занимает на один бит больше. Поэтому, при скармливании картинки дисплею, мало того, что один из старших битов пропадает, так ещё и происходит бинарный сдвиг одного цветового канала на единицу, из-за чего вся палитра оказывается искажена. После сохранения картинки в нужном режиме значения белого заменились на FF FF, потери одного бита данных больше не было, и она отрисовалась с нормальной цветностью.

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

❯ 5. Пишем ПО для захвата экрана

Далее вышеупомянутый автор для рендеринга использует интерполяцию из фрейм-буфера ОС Linux /dev/fb0. Попытка запустить его код не привела ни к чему хорошему: в моём случае фреймбуфер отображается как чёрная сетка из-за несоответствия данных, да и мне не нужно было проводить интерполяцию картинки всего рабочего стола, а нужна была конкретная область экрана.

Слева: отрисовка из /dev/fb0. Справа: отрисовка из скриншота.

Так как моя GUI в Armbian работает на графической оболочке XFCE, у меня возникла идея выдрать требуемые пиксели непосредственно через неё. Для этого используются средства gdk и x11. Добавление всех необходимых библиотек сильно усложнило бы программу, поэтому мне пришлось прийти к костыльному решению проблемы.

Я решил копнуть в сторону встроенной в ОС утилиты xfce4-screenshooter. Данная утилита позволяет снять скриншот, в том числе, через командную строку. Однако, функции сохранения заданной области в ней нет, либо требуется задавать каждый раз область мышкой, что было мне неудобно. Поэтому я сделал форк кода данной утилиты. И добавил в опции командной строки, помимо FULLSCREEN, WINDOW и REGION ещё и аргумент FIXED, который сохранял в файл конкретно прописанную в коде область экрана.

Для удобства разработки пришлось поставить xubuntu на виртуальную машину с x86, после чего изменить исходный код, а затем собрать его же, но под armbian непосредственно на своём Orange Pi. Сборка утилиты осуществляется помощью xdt-autogen: сначала ./autogen.sh, далее установить библиотеки по требованию (через apt-install) затем с помощью make, и make install для замены установленного в систему скриншоттера на изменённый вариант. После этого готовый скриншот нужного размера стало можно выводить в файл с помощью одной лишь команды терминала – для определения файлового пути, формата и прочего используется оригинальный код скриншоттера.

Однако, данное решение имеет и недостаток: программа-скриншоттер работает, вероятно, таким образом, что сначала делает скриншот всего root-окна (рабочего стола), затем обрезает его до требуемого размера. При этом, на какой-то момент, отрисовка даже приостанавливается. Вся процедура съемки занимает порядочное количество времени: на десктопе xubuntu она осуществлялась примерно за 50-100 миллисекунд. На Orange Pi она же стала занимать порядка 100-400 миллисекунд. Видеозахват – в целом тяжелая процедура для ЦПУ. Поэтому уменьшение разрешения рабочего стола помогло, но незначительно. В идеале нужно выдирать изображение через низкоуровневый код непосредственно из экранной памяти, а не из пользовательской среды через функции gdk. Более того, в самом коде скриншоттера написано, что рекомендуемая задержка между скриншотами должна быть не менее 200 мс, то есть, это уже ограничивает нас до 5 FPS. В случае, если нужно просто проверить консольный вывод, этого достаточно, а вот для видеопотока оказалось маловато.

Прим. авт.: через некоторое время после написания статьи, мне удалось решить данную проблему, используя вместо скриншоттера ПО jsmpeg-vnc. С ним я получил 50 FPS и выше, плюс имеются встроенные функции обрезки кадра до нужного размера.

Данное ПО передаёт MPEG-поток через WebSocket протокол (выполняя трансляцию видеосигнала), позволяет закодировать только нужную область, чтобы не передавать весь рабочий стол. Далее кадр можно расшифровать и передать непосредственно в контроллер, минуя костыль в виде отображения его на экране и снятия скриншота. Если это будет интересно, можно показать подробнее в следующей статье.

Также, поскольку сохранение в bmp происходит через встроенные средства gdk, мне не удалось заставить программу сохранять в 16-битный формат. Она сохраняла в 24-битный формат, поэтому для преобразования цветовой палитры мне пришлось написать фрагмент кода на бинарных сдвигах:

Изначально содержимое нашего скриншота копируется в массив байтов (uint8_t) в порядке очередности. Для конвертации цвета 24bit -> 16 bit (ещё и с перевёрнутым порядком байтов) использованы сдвиги: мы сравниваем первый байт красного с пятью единицами, далее сравниваем второй байт зелёного с тремя единицами и сдвигаем результат в самое начало, далее сравниваем следующие разряды байта зелёного и сдвигаем в самый конец, далее сравниваем синий и сдвигаем его в середину. Таким образом, из цветности КККККККК ЗЗЗЗЗЗЗЗ ССССССС мы привели палитру к цветности ЗЗЗССССС КККККЗЗЗЗ, которую и принимает наш дисплей. Для отладки я использовал цветные картинки, после чего смотрел, корректно ли отображается цвет согласно своему описанию, или же цветовой канал требуется сдвинуть ещё на какое-то количество ячеек.

После чего я в цикле запустил скриншоттер через вызов терминала, а далее отрендерил картинку на экран. Это можно увидеть на видео:

Конечно, данный пункт программы нуждается в доработке – ссылки на заголовочные файлы библиотек gdk и x11 следует внести в общий файл программы, в котором происходит работа с дисплеем чтобы избежать костыля в виде сохранения картинки в кэш на жестком диске. Возможно, это несколько улучшит производительность. А для идеальной работы требуется переписать это всё на уровне ядра ос, чтобы превратить самодельную библиотеку в драйвер для устройства. Но на текущий момент ход программы получился такой:

• Через терминал вызывается скриншоттер, который сохраняет кадр в cache.bmp;

• Файл cache.bmp открывается, после чего отправляется его содержимое на дисплей.

Причём, основная потеря скорости идёт на этапе снятия скриншота, а не записи/чтения его с диска. Для увеличения FPS выше 5 необходимо заменить xfce4 скриншоттер на какое-то другое ПО. Тем не менее, мы движемся дальше.

❯ 6. Эмуляция сотового телефона

Эмулятор телефона CX75 был написан лет 20 назад, и входил в официальный пакет программ для разработки java-приложений через WTK/JDK 2.0. Он пролежал у меня на жестком диске лет 15, после чего я запустил его для данной работы. Если кому-то интересно также запустить его на своём компьютере, делюсь файлами.

Для работы требуется JDK 6u45 и Windows XP. Насколько я помню, даже при запуске на Windows 7 эмулятор вылетал, на Win 10, тем более, работоспособность я не проверял. Поэтому запускать я его буду через виртуальную машину с WinXP.

Эмулятор полностью реализует функционал прошивки телефона 75-й серии, в том числе, можно устанавливать java-игры, подключать веб-камеру для съемки фото, и так далее. Единственное, вряд ли будет работать интернет, по причине того, что WAP технологии уже не получится использовать.

Вот так эмулятор выглядит в системном окне. Управлять можно с клавиатуры (джойстик – стрелки и enter, клавиши – цифры или тачпад), либо нажатием на виртуальные кнопки.

Выдаёт он картинку чётко размера 132x176, поэтому интерполяция не потребуется. Теперь нужно прокинуть картинку из виртуальной машины в Linux машину. Можно было использовать wine, но я не уверен, будет ли эмулятор адекватно работать на нём. Поэтому он запущен в XP. Для передачи картинки, опять же, ничего нового изобретать я не буду, использую TightVNC.

На Windows мы устанавливаем сервер, на armbian’е устанавливаем клиент через apt-get xtightvncviewer.

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

И вот момент, ради которого всё затевалось: помещаем эмулятор телефона в экранную область на самом телефоне

Видео:

Таким образом, наш видеопоток проходит через следующие уровни:

• Эмулятор CX75 (x86 C-программа, но порт ARM-совместимой прошивки);

• Windows XP (виртуальная машина);

• Windows 10 (через виртуализацию, но можно пропустить, выведя в VNC напрямую с XP);

• Armbian xfce4 gui (через VNC);

• Изображение cache.bmp (через xfce4-screenshooter);

• Дисплей C75 (через wiringPi + wiringPiSPI).

Для эмуляции же клавиатуры достаточно просто припаять контактные площадки к контроллеру от USB-клавиатуры в соответствии со схемой их разводки:

Делать этого сейчас я не буду по причине того, что это несколько монотонное занятие, и вся задача заключается лишь в правильном сопоставлении таблиц кнопок и таблиц на контроллере от USB клавиатуры. После чего клавиатура подключается к виртуальной машине, и можно испытать полное погружение в эмулятор.

❯ 7. Заключение

Результат проекта:

В ходе работы были изучены особенности работы с GPIO, SPI, GTK3, VNC, преобразованием цветности и некоторым другим функционалом компьютерных и микроконтроллерных систем.

Готовые файлы проекта под wiringPi.

Спасибо за внимание.

• Написано специально для Timeweb Cloud и читателей Пикабу. Подписывайтесь на наш блог, чтобы не пропустить новые интересные материалы.

• Также подписывайтесь на наш телеграмм-канал — только здесь, технично, информативно и с юмором об IT, технике и электронике. Будет интересно.

• Облачные сервисы Timeweb Cloud — это реферальная ссылка, которая может помочь поддержать наши проекты.

• Автор текста: Cheapskate

• Автор перевода: Albert_Wesker

Некоторое время назад я написал статью, в которой критически высказался о Linux-разработчиках, не желающих поддерживать дистрибутив, если он предназначен для работы на компьютерах, которым более 15 лет. За это я получил немало критики от читателей с Hacker News. Кто-то указывал, что я не понимаю, насколько же это сложно – создать и поддерживать дистрибутив Linux. Были и такие, кто советовали мне просто накатить на старый компьютер старую версию Windows. Я же начал пользоваться Linux в первую очередь для избегания Windows, так как считал её монструозным порождением Билла Гейтса. Фактически, разработчики операционной системы, ранее обещавшие освободить меня от Windows, теперь склоняют меня вернуться к Windows, как только мой компьютер настолько состарится, что им станет неудобно его поддерживать. Ответы, которые я получаю от Linux-разработчиков, явно свидетельствуют, что Linux больше не является операционной системы для технарей-компьютерщиков, желающих сохранить на ходу свои любимые винтажные машины. Напротив, Linux превратился в операционную систему, которую разработчик рассматривает как средство для прокачки карьеры. Те, кому интересно подробнее разобраться в нарастающей дисфункциональности Linux и узнать, почему сложилась такая ситуация, могут посмотреть это видео на YouTube.

Некоторые разработчики советовали мне собрать собственный дистрибутив Linux. Хотел бы я! К сожалению, по паре причин этот вопрос не обсуждается. Во-первых, у меня просто нет на это времени. Слишком много времени у меня уходит на работу по поддержке моих сообществ Cheapskate's Guide и Blue Dwarf. Во-вторых, даже если бы я взялся за создание собственного дистрибутива, то получился бы ISO-образ размером более 1 гигабайта и с репозиторием на десятки гигабайт, а такой крупный софт я просто не мог бы выложить в общее пользование, так как мне было бы слишком дорого передать все эти данные.

Учитывая, что немного найдётся Linux-разработчиков, готовых поддерживать старые версии своих дистрибутивов в рабочем состоянии, единственный разумный с моей точки зрения выход – сохранить мои любимые дистрибутивы на будущее. К счастью, я сохраняю ISO-образы Linux, которым более 15 лет. Сейчас у меня есть резервные жёсткие диски с самыми разнообразными дистрибутивами. Вот неполный список: AntiX 19.4, AntiX 22, AntiX 23, Arch Linux 2020.09.01, Debian 11.3, Debian 11.1.0 Server, DSL 4.4.10, версии 1.2 и 4.4.9 со встроенными DSL, Kali Linux 2022.2, Kodachi Linux 8.15, LibreELEC 8.2, Mint 9, Mint 13, Mint 17, Lubuntu 22.04, MV Linux 21.1, Nano Linux 1.3, OpenElec 8.0.4, OpenWRT 19.07.7 обобщённый, Parrot OS 4.11.3, Parrot OS 5.3, PirateBox, Noobs v2_4_5, OSMC_TGT_rbp2_20190424, Raspberry Pi Buster 2020-05-27, Raspberry Pi Buster Lite 2020-05-27, Raspios Bullseye 2023-5-03, Raspian Buster 2019-07-10, Raspbian Jessie 2017-07-05, Raspbian Stretch 2017-11-29, TAILS 2.2.1, TAILS 4.5, Zenlive Linux 7.0 и Zorin 9 Lite. Большинство из этих версий в Интернете уже не найти. Если бы не моя предусмотрительность, то и у меня не было бы к ним доступа. Для большинства пользователей кроме меня они навсегда утрачены.

Со всеми вышеупомянутыми ISO-образами Linux существует важная проблема: в них содержатся только такие приложения, которые поставляются в виде ISO-файлов. Зачастую в них нет программ для чтения RSS-лент, браузера Lynx, PHP, веб-серверов, nmap, bleachbit, cowsay и fortune, truecrypt или Veracrypt, Unetbootin, macchanger, espeak, hwinfo, cpulimit, thermald, calibre, fbreader, браузера Dillo, браузера Vivaldi, libdvdread4, libdvd-pkg, libdvdnav4, загрузчика yt (теперь yt-dlp), почтового клиента Alpine, pulseaudio и многих других, от которых бы я не отказался. Многие из этих пакетов и сопутствующие им зависимости содержатся в репозиториях вышеупомянутых дистрибутивов. К сожалению, по прошествии многих лет установить их нельзя, поскольку многие репозитории теперь просто не существуют! Также можете не рассчитывать найти многие из библиотек, от которых зависят старые версии этих приложений для Linux.

Очевидное решение – скачивать и сохранять не только ISO-образ каждого дистрибутива Linux, но и его репозитории. Да, это осуществимо, и в Интернете можно найти множество статей, в которых объясняется, как скопировать репозиторий. Но сам процесс скачивания и хранения файлов на десятки гигабайт на множестве резервных жёстких дисков для каждого дистрибутива порой утомляет, особенно, если приходится делать это годами и учитывать такие факторы, как гниение бит и плановые обновления винчестеров.

Теперь, когда многие из моих старых ПК слишком устарели для современного Linux, мне приходится серьёзнее относиться к информации и сохранять не только базовые ISO-образы Linux, но и дополнительные файлы. Немного поразмыслив, я решил пойти по компромиссному пути, между двумя крайностями «сохранять только ISO-образ» и «сохранять ISO и все связанные с ним репозитории». Итак, пока такая возможность ещё не утрачена, я решил сохранять хотя бы по одной версии дистрибутива Linux плюс дополнительные пакеты к нему. Очевидный вариант – а в настоящее время, вероятно, и единственный – работать с AntiX Linux. Я не особенно переживаю за AntiX, поскольку багов в нём хватает. Кроме того, он работает несколько иначе, нежели другие Debian-подобные дистрибутивы. Вероятно, дело в том, что он использует легковесные среды для рабочего стола, в частности, IceWm. Они довольно старые и никогда не стандартизировались до такой степени, до какой принято доводить более современные окружения. К сожалению, не знаю ни одного другого до сих пор поддерживаемого дистрибутива, который бы нормально работал на компьютерах от двадцати лет и старше. Я пробовал несколько «легковесных» дистрибутивов и убеждался, что они просто кишат багами, и пользоваться ими на компьютерах старше 15 лет решительно невозможно.

❯ Устанавливаем AntiX

Я скачал ISO-образ AntiX-23_386_full.iso современной версии AntiX со страницы загрузки AntiX. Это самая «полная» версия, в которой содержится больше всего приложений для работы на ПК. Это 32-битная версия. Кстати, немного найдётся таких Linux-разработчиков, которые до сих пор предоставляют 32-битные версии своих дистрибутивов. Пожалуйста, не надо мне доказывать, что 32-битную версию любого дистрибутива Linux вполне можно скомпилировать из исходного кода. Я не раз безуспешно пытался скомпилировать таким образом хотя бы единичное приложение, поэтому на собственном опыте знаю, насколько маловероятно преуспеть с таким подходом.

Попытался установить AntiX из скачанного ISO-файла на мой компьютер fDell Precision M20, 2004 года выпуска. Эта машина может похвастаться ЦП Pentium M (Centrino) с частотой 1,86 ГГц и 2 ГБ ОЗУ (это для неё максимум). Этот компьютер я купил в 2019 году на барахолке за 20 долларов. Даже если вы совсем новичок в Linux, вам не составит труда установить AntiX, так как установщик в нём включён. К сожалению, я неоднократно и безуспешно пытался поставить его на «жёсткий диск» Precision M20 (за громким названием скрывается карта памяти microSD с адаптером IDE-to-microSD). Всякий раз казалось, будто установка прошла успешно. Я даже проверял систему при помощи Gparted, убеждаясь, что раздел диска действительно создан, с него можно загрузиться, и в него записываются данные. Потом перезагружаюсь – и никакого раздела нет! Короче говоря, мне не удавалось установить на этот компьютер ни одну из версий AntiX, ни 19.4, ни 23, ни через установщик с GUI, ни через командную строку. Теряюсь в догадках, но, возможно, что-то не так с самой microSD-картой или адаптером, поэтому установка и не выходит. Ранее я уже поднимал проблему некачественных установщиков Linux, поэтому здесь не стану снова в неё углубляться.

Поскольку мои первые попытки установить AntiX на Precision M20 успехом не увенчались, я решил повторить попытку на ноутбуке с обычным твердотельным жёстким диском SATA. Для начала установил компактный твердотельный диск SATA в мой ноутбук Lenovo Thinkpad T500, модель 2008 года, воспользовался при этом утилитой для установки AntiX через командную строку. AntiX установился! К сожалению, по-видимому, мне не удалось бы таким способом установить сверх одного-двух дополнительных пакетов при помощи команды «apt-get install» (уверен, что сначала я выполнил «sudo apt-get update»). В AntiX на этой машине проявлялись и другие неприятные баги, поэтому я подумал, что лучше воспользуюсь другим дистрибутивом Linux.

Несмотря на все эти неудачи, я не отступал. Попытался установить AntiX 23 на ноутбук Dell Inspiron 5100, модель 2002 года, с жёстким диском IDE на 40 ГБ и с 256 МБ ОЗУ. Это самый старый из имеющихся у меня действующих компьютеров. Установщик потребовал, чтобы я выделил ему весь жёсткий диск, но AntiX всё-таки встал. Затем, чтобы сэкономить место, я ужал сегмент с AntiX до 14 ГБ. Для этого я воспользовался Gparted на загрузочной флешке с AntiX, так как Gparted не может ужать сегмент, используемый в настоящий момент. Держал в уме, что нужно сделать перманентную резервную копию этого сегмента и потом попробовать устанавливать её на другие старые компьютеры. Непосредственно после установки дистрибутив занимал около 5 ГБ дискового пространства. Я обновил получившуюся конфигурацию при помощи «sudo apt-get update», а потом приступил к установке дополнительных пакетов.

❯ Добавляем пакеты Linux в AntiX

Как решить, какие именно пакеты Linux устанавливать? Если у вас есть рассчитанные на работу под Linux копии приложений, не содержащие зависимостей, то, теоретически, их можно установить в любой момент (хотя, чтобы максимально перестраховаться, можете поставить их сразу же). Важно установить именно те пакеты Linux, у которых есть по несколько зависимостей, ведущих в репозитории. В данном случае у вас возникает такая дилемма: требуется установить те приложения, которые могут вам понадобиться не только в ближайшем будущем, но, вероятно, и через 10, и через 20 лет. Конечно, непросто сходу определить, что это за приложения. Но можете попробовать установить по одному-два приложения всех основных типов: браузер, читалка для электронных книг, агрегатор новостных лент, офисный пакет, утилиты, т.д.

В качестве первой попытки я установил при помощи «sudo apt-get install» следующие дополнительные пакеты себе на Inspiron 5100:

• nmap

• ftp

• tcpdump

• iotop

• nethogs

• cowsay

• fortune

• macchanger

• bleachbit

• lynx

• liferea

• gedit

• thermald

• goldendict

• mplayer

• smplayer

• aspell

• fbi

• w3m

• seamonkey

Установив вышеперечисленные пакеты, я убедился, что все они сохранены на жёстком диске в каталоге /var/cache/apt/archives в формате ".deb". Кроме того, посмотрел с DVD кино через Smplayer. Шло медленно, но работало. С огромными проблемами установил библиотеки, необходимые для просмотра DVD-фильма в ОС Parrot 4.11 и выше. Очевидно, разработчик Parrot OS считает, что больше никто уже не смотрит фильмы с DVD.

Всякий раз при установке дополнительных пакетов в любой дистрибутив Linux, вы рискуете его дестабилизировать. Я не обнаружил никакой явной рассогласованности в работе того AntiX, который сам и установил, но, чтобы с уверенностью полагать, что всё прошло нормально, дистрибутив нужно тестировать неделю или более. Чтобы сохранить эту вполне работоспособную конфигурацию AntiX, я сделал резервную копию 14-гигабайтного сегмента и сохранил её на внешнем диске.

Затем я попытался установить следующие приложения, входящие в оборудованный графическим интерфейсом установщик пакетов для AntiX:

• pulseaudio

• Audacious

• GIMP Basic

• ImageMagick

• Handbrake

• Adobe Reader

• xfce4-screenshot

• VLC

Adobe Reader не установился, предположительно, потому, что для него не выполнялись две зависимости, которые мне не удалось подтянуть. Audacious не заработал. Когда я попытался проиграть в Smplayer и VLC фильм с DVD и MP4-файл, ни в одном из четырёх вариантов не было звука, в обеих программах ролики шли очень медленно, а в конце концов зависали. Позже мне удалось заставить VLC зазвучать, но всё равно ни одно из двух этих приложений не стало работать хотя бы так же гладко, как работал Smplayer до установки последнего набора программ. Я даже пытался нарастить ОЗУ на 750 МБ, но это проблем не решило. Я решил перенести резервную 14-гигабайтную копию AntiX на Inspiron 5100, вернувшись таким образом на более работоспособную машину. Пока мне кажется, что чем меньше приложений установлено, тем стабильнее работает вся система, а мне было бы предпочтительнее рассчитывать на уверенное воспроизведение видео, пусть и ценой отказа от некоторых приложений.

Есть два способа перенести файлы ".deb" в каталог /var/cache/apt/archives на другой компьютер, где установлен новый экземпляр AntiX. Первым делом нужно сделать резервные копии всех файлов ".deb", дополнительно к ISO-образу системы AntiX. Затем можно попытаться установить ISO на новый компьютер, скопировав файлы ".deb" в каталог /var/cache/apt/archives на новом компьютере, а затем установив их при помощи «apt-get install». Второй вариант – просто создать файл ".img" и записать в него весь сегмент с AntiX плюс дополнительные пакеты, а затем всё это скопировать на новый компьютер.

Как только я пошёл по первому пути, нарисовалась очевидная проблема. По какой-то причине «apt-get install» не понимала, какие ".deb"-файлы из каталога /var/cache/apt/archives от каких зависят. Не знала, в каком порядке их нужно устанавливать, если только они не лежат в репозитории. Подозреваю, что команда «gdebi -i» может устанавливать отдельно взятые пакеты с зависимостями, а команда «dpkg --unpack» – устанавливать пакеты безотносительно их зависимостей. Но у меня ни с одной ничего не получилось. Путь, на первый взгляд показавшийся простым как с точки зрения установки, так и относительно хранения дополнительных пакетов, не входящих в ISO-образ AntiX, на практике вышел более тернистым.

Таким образом, немного потрепав себе нервы за исследованием первого подхода, я осознал, что не представляю, как методично устанавливать файлы ".deb" в каталог /var/cache/apt/archives. Поэтому решил попробовать второй подход.

Второй подход выглядел так:

1. Установить AntiX в небольшой сегмент на жёстком диске компьютера (напомню, после установки этот сегмент можно ужать при помощи Gparted);

2. При помощи «sudo apt-get install» установить любые дополнительные пакеты на мой вкус;

3. Сделать файл-образ небольшого сегмента (допустим, 14 ГБ) и вынести его на флешку командой «sudo dd if=/dev/sda of=/media/user/usb/AntiX_installed_with_extra_packages.img bs=1M count=14812 conv=notrunc, noerror» (обратите внимание: здесь используется /dev/sda, а не /dev/sda1);

4. Запустить другой компьютер с загрузочной флешки с Linux, а уже в него вставить флешку, на которой содержится копия только что изготовленного мною образа AntiX;

5. Скопировать образ AntiX на жёсткий диск нового компьютера при помощи «sudo dd if=/media/user/usb/AntiX_installed_with_extra_packages.img of=/dev/sda bs=1M conv=notrunc,noerror», и, наконец;

6. Молиться, чтобы конфигурационный файл grub заработал на новом компьютере.

На этапе 3 я воспользовался «count=14812», чтобы скопировать первые 14,5 ГБ с жёсткого диска. Это я сделал лишь чтобы удостовериться, что у меня будет скопирована и главная загрузочная запись, на случай, если её не окажется в сегменте sda1. Если конфигурационный файл grub не заработает на новом компьютере, то придётся поразмыслить, как изменить его, чтобы загрузка прошла. Обратите внимание: я скопировал на новый компьютер лишь 14-гигабайтный сегмент sda1, но в какой-то момент его загрузочная последовательность оборвалась, поэтому и потребовалось указать «count=14812».

Именно вторым способом мне удалось перенести установленный AntiX с компьютера Dell Inspiron 5100 на модели Emachines KAV60 и Compaq Presario V5000. Оба раза всё получилось, даже не пришлось вносить изменений в файл grub.cfg. После того, какую огромную фрустрацию доставил мне первый способ, успех в данном случае практически сподобил меня простить разработчиков Linux и AntiX в частности, хотя, согласитесь, они сделали очень хрупкую операционную систему. Как говорится, осадочек остался.

Если кому-то из вас придётся работать со старым дистрибутивом, обязательно учитывайте эти риски. Конечно же, может быть опасно бороздить Интернет на таком старом софте. Может быть, воспользуйтесь Gemini или другой оверлейной сетью, которая пока не кишит подозрительными личностями (интересно, а существуют ли ещё такие сети?). Может быть, отключите JavaScript в браузере, и такой защиты будет достаточно? Ещё лучше было бы выделить старый компьютер строго для путешествий по Интернету, а на другом компьютере хранить исключительно личные данные. Также работает подход с использованием нескольких загрузочных USB-флешек на одном старом компьютере. Любая старая версия любого дистрибутива Linux отлично подойдёт для оффлайновой работы. В самом деле, а есть ли более удобные варианты для старого компьютера, на котором современный дистрибутив Linux? Может быть, Windows? Нет, я не враг моим старым компьютерам!

❯ Заключение

Ни в коем случае не утверждаю, что вышеописанный метод спасения старых версий любимых дистрибутивов Linux идеален (то же касается любых других операционных систем, которые вы хотели бы запустить на старом компьютере). Может быть, читатели предложат способ получше. Но я думаю, так лучше, чем довольствоваться лишь теми приложениями, которые оказались в конкретном образе, либо пробовать копировать целые репозитории (и эти резервные копии тоже копировать), а затем пытаться хранить их десятилетиями. Если бы мы только могли рассчитывать, что разработчики Linux сделают это за нас. Но они не сделают.

• Облачные сервисы Timeweb Cloud — это реферальная ссылка, которая может помочь поддержать наши проекты.

• Подпишись на наш блог на Пикабу и Хабре, чтобы не пропустить новые интересные статьи.

• Автор текста: MaFrance351

Приветствую всех!

Давным-давно я уже рассказывал про то, как в домашних условиях поднять GSM-сеть при помощи комплектующих, доступных любому школьнику. И в той статье я мельком упомянул, что идеальным в плане производительности вариантом будет запускать сети при помощи SDR, а не телефонов.

Итак, в сегодняшней статье поговорим о том, как быть владельцам SDR, желающим запустить свою GSM-сеть. Узнаем, какой софт нужен, чтобы заставить её работать в прямом смысле слова за пять минут. Попутно запустим GPRS и ненадолго побываем в 2007 году. Традиционно будет много интересного.

❯ Суть такова

Многие помнят тот поистине легендарный пост про то, как из двух телефонов и обычного компьютера собрать базовую станцию. Но всё же у той конфигурации был целый ряд недостатков, которых лишена БС на базе SDR. В свою очередь, единственным минусом того, что будет рассмотрено в данной статье, является высокая стоимость оборудования.

Также на просторах Хабра был найден пост про Osmocom в Docker-контейнере, однако за десять лет софт порядком устарел, теперь есть куда более новые версии с большими возможностями и более стабильной работой.
И вот в мои руки попал полнодуплексный SDR, а это значит, что самое время попробовать запустить сеть при помощи него и узнать, что же из этого выйдет.

❯ В чём преимущества сети на базе SDR?

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

• Диапазон частот. В телефонах используются фильтры, не позволяющие прослушивать входящий трафик. Моя БС работала исключительно из-за их неидеальности, лучшим же решением было бы заменить их, что доступно не каждому ввиду необходимости наличия оборудования и хороших навыков пайки, дабы не запороть плату телефона. SDR лишён этой особенности.

• Генератор. Точности внутреннего генератора SDR с лихвой хватит, чтобы обеспечить корректную работу сети. В телефонах такого устройства нет, поэтому нам приходилось ловить тактовый сигнал от других коммерческих вышек.

• Подключение к компьютеру. В случае с SDR не придётся заниматься ерундой типа пайки проводов, проверки заряда аккумулятора и тому подобными вещами, достаточно просто подключить его к ПК и больше не думать о том, что причины неработоспособности сети кроются где-то здесь.

• Производительность. В отличие от телефонов, можно создать конфигурацию, где будут доступны сразу и звонки, и SMS, и интернет.

• Стабильность. Сеть на базе SDR при правильной настройке не падает.

• Поддерживаемые устройства. При запуске сети на базе телефонов я смог подключить к ней далеко не все устройства, какие у меня были. В частности, телефон от Nokia смог поймать её только один раз. В случае же с SDR все имевшиеся у меня телефоны, которые участвовали в испытаниях, подключались без проблем. Товарищ axilirator подсказал, что связано это с частотной характеристикой сигнала, так как телефон после попытки подключения к операторской сети ориентируется на неё, а лабораторную не видит. В моём случае эта проблема если и возникала, то устранялась банальной перезагрузкой трубки.

Таким образом, если у вас есть желание серьёзно заниматься исследованием устройства и работы сотовых сетей, приобретение полнодуплексного SDR должно стать вашим первым шагом.

❯ Обзор оборудования

А вот и SDR. Это USRP B200mini-i, которого для данных опытов хватает с избытком. Само собой, к нему понадобится и компьютер, который будет им управлять. Виртуалка или Raspberry не подойдёт.

Далее понадобятся телефоны, которые будут ловить сеть. В них должны быть симки, какие именно — неважно, лишь бы были. Вот, например, Samsung Galaxy M12, уже фигурировавший в опытах с LTE.

Три легенды кнопочных телефонов — Nokia 3310, Siemens CX75, Sony Ericsson K750i.

Nokia E90, крутейший девайс, совмещающий в себе кнопочный телефон, коммуникатор на Symbian и клавиатурный КПК.

❯ Софт

Как и в прошлых опытах с SDR, использовать будем дистрибутив DragonOS. Там уже есть все необходимые компоненты для запуска сети, достаточно лишь слегка поменять настройки. Уже не придётся ни собирать софт из исходников, ни искать примеры файлов конфигурации.
Как и в прошлых статьях, ссылки на всё необходимое я оставлю в конце.

❯ Конфигурация

Теперь, когда ОС загружена, можно приступать к настройке.
Открываем папку osmo-nitb-scripts (ярлык на неё есть в меню «Пуск» в разделе «Other»), а в ней — папку configs. Нас интересует файл openbsc.cfg.

Вообще, сеть будет работать и с тем файлом, что есть по умолчанию, однако SMS не будут ходить из-за неправильной настройки таймслотов и протокола SMPP. Так что приводим файл к следующему виду:

!
! OpenBSC configuration saved from vty gprs mode none | phys_chan_config SDCCH8
! !
password foo
!
line vty
no login
!
e1_input
e1_line 0 driver ipa
network
network country code 250
mobile network code 10
short name MaFrance
long name MaFrance
auth policy accept-all
location updating reject cause 13
encryption a5 0
neci 1
rrlp mode none
mm info 1
handover 0
handover window rxlev averaging 10
handover window rxqual averaging 1
handover window rxlev neighbor averaging 10
handover power budget interval 6
handover power budget hysteresis 3
handover maximum distance 9999
subscriber-keep-in-ram 0
bts 0
type sysmobts
band GSM900
cell_identity 1087
location_area_code 13415
training_sequence_code 7
base_station_id_code 56
ms max power 30
rxlev access min 0
periodic location update 1000
cell reselection hysteresis 14
cell reselection offset 120
temporary offset 0
penalty time 20
channel allocator ascending
rach tx integer 9
rach max transmission 7
ip.access unit_id 1801 0
oml ip.access stream_id 255 line 0
gprs mode none
trx 0
rf_locked 0
arfcn 25
nominal power 34
max_power_red 20
rsl e1 tei 0
timeslot 0
phys_chan_config CCCH+SDCCH4
hopping enabled 0
timeslot 1
phys_chan_config TCH/H
hopping enabled 0
timeslot 2
phys_chan_config TCH/H
hopping enabled 0
timeslot 3
phys_chan_config TCH/H
hopping enabled 0
timeslot 4
phys_chan_config TCH/H
hopping enabled 0
timeslot 5
phys_chan_config TCH/H
hopping enabled 0
timeslot 6
phys_chan_config TCH/H
hopping enabled 0
timeslot 7
phys_chan_config TCH/H
hopping enabled 0
nitb
assign-tmsi
subscriber-create-on-demand random 100 199
smpp
local-tcp-port 2775
system-id OSMO-SMPP
policy accept-all
esme OSMPP
password 1234
osmocom-extensions

Коротко пройдёмся по параметрам.

• ARFCN — самый важный. Это номер канала, на котором будет работать наша вышка. Необходимо воспользоваться приложением по типу Net Monitor, чтобы узнать, на каких каналах работают вышки в округе и выбрать незанятый.

• LAC. Код зоны, использующийся для определения местоположения. Вообще, он не влияет на работу, но некоторые телефоны могут не подключаться, если он равен 0 или 1.

• CID. Код соты. Выбирается аналогично LAC.

• MCC — код страны. Для России это 250. Можно выбрать другой, но стоит учитывать, что не все телефоны смогут подключиться к такой сети.

• MNC — код сети. Нужно открыть список сотовых операторов (он есть, например, тут или тут)

• Long name и Short name. Это, как нетрудно догадаться, имя сети, отображаемое в строке состояния на телефоне. Устанавливается любое желаемое.

  
  Теперь разберёмся с таймслотами. Каждый из них конфигурируется на определённый тип канала. Подробнее о них можно почитать тут.
  
  Теперь, когда параметры изменены, запускаем нашу сеть:

sudo ./main.py

Если у вас не LimeSDR, а USRP, то запускать надо следующим образом:

sudo ./main.py -d uhd

Если всё было сделано правильно, то на экране должно будет появиться примерно следующее:

А через несколько секунд — вот это:

Всё, сеть работает. На всё ушло меньше пяти минут не считая времени загрузки ОС. Можно пробовать подключаться.
В этом окне отображаются IMSI абонентов, подключившихся к сети, а также их номера.

Как показали опыты, все имевшиеся у меня телефоны без проблем подключались к созданной сети.

Запустились и две более новые легенды. Всё, можно звонить и отправлять SMS. Точно так же, как мы делали это при помощи телефонов.

❯ А что насчёт интернета?

Но, конечно, при помощи Osmocom можно поднять и GPRS. Причём в случае использования SDR можно получить полноценную сеть, где будут работать все составляющие: звонки, SMS, USSD и пакетные данные. В случае использования телефонов нам пришлось бы либо подключать дополнительные моторолы, либо потерять возможность звонить.
Ну что же, самое время попробовать запустить GPRS.

❯ GPRS и как он работает

И перед началом экспериментов традиционно разберёмся с тем, как пакетный трафик в 2G-сети перенаправляется во внешний мир.

GPRS имеет свою опорную сеть. Она представляет собой расширение для сети GSM, добавляющее в неё возможность обмена пакетными данными.

Итак, сеть с поддержкой GPRS дополнительно включает в себя следующие компоненты:

• PCU (Packet Control Unit). Это устройство управления пакетами, позволяющее в паре с контроллером БС отправлять и принимать те самые данные.

• SGSN (Serving GPRS Support Node). Этот узел отвечает за обслуживание абонентов — обмен пакетами, тарификацию, проверку APN (Access Point Name) точки доступа, распределение ресурсов.

• GGSN (Gateway GPRS Support Node). Шлюз, соединяющий сотовую сеть с другими сетями передачи данных.

Для работы GPRS на телефоне должна быть создана точка доступа, включающая в себя APN, логи и пароль. Обычно она создаётся сразу при регистрации в сети оператора и участие пользователя в этом не требуется.

❯ Конфигурация

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

Необходимо узнать имя подключения, через которое компьютер получает доступ в интернет. Сделать это можно, открыв ifconfig или iwconfig.

Теперь открываем opengts_egprs.cfg из папки configs. И приводим его к следующему виду:

!
! OpenBSC configuration saved from vty
! !
password foo
!
line vty
no login
!
e1_input
e1_line 0 driver ipa
e1_line 0 port 0
no e1_line 0 keepalive
network
network country code 250
mobile network code 10
short name MaFrance
long name MaFrance
auth policy accept-all
authorized-regexp .*
location updating reject cause 13
encryption a5 0
neci 1
rrlp mode none
mm info 1
handover 0
handover window rxlev averaging 10
handover window rxqual averaging 1
handover window rxlev neighbor averaging 10
handover power budget interval 6
handover power budget hysteresis 3
handover maximum distance 9999
subscriber-keep-in-ram 0
bts 0
type sysmobts
band GSM900
cell_identity 7229
location_area_code 7619
training_sequence_code 7
base_station_id_code 63
codec-support fr efr amr
ms max power 15
rxlev access min 0
periodic location update 1000
cell reselection hysteresis 14
cell reselection offset 120
temporary offset 0
penalty time 20
radio-link-timeout 32
channel allocator ascending
rach tx integer 9
rach max transmission 7
channel-descrption attach 1
channel-descrption bs-pa-mfrms 5
channel-descrption bs-ag-blks-res 1
ip.access unit_id 1801 0
oml ip.access stream_id 255 line 0
gprs mode egprs
gprs routing area 1
gprs cell bvci 1234
gprs nsei 1234
gprs nsvc 0 nsvci 1234
gprs nsvc 0 local udp port 23001
gprs nsvc 0 remote udp port 23000
gprs nsvc 0 remote ip 127.0.0.1
no force-combined-si
trx 0
rf_locked 0
arfcn 100
nominal power 34
max_power_red 20
rsl e1 tei 0
timeslot 0
phys_chan_config CCCH+SDCCH4
hopping enabled 0
timeslot 1
phys_chan_config SDCCH8
hopping enabled 0
timeslot 2
phys_chan_config TCH/H
hopping enabled 0
timeslot 3
phys_chan_config TCH/H
hopping enabled 0
timeslot 4
phys_chan_config TCH/H
hopping enabled 0
timeslot 5
phys_chan_config TCH/H
hopping enabled 0
timeslot 6
phys_chan_config PDCH
hopping enabled 0
timeslot 7
phys_chan_config PDCH
hopping enabled 0
nitb
assign-tmsi
subscriber-create-on-demand random 100 199
smpp
local-tcp-port 2775
system-id OSMO-SMPP
policy accept-all
esme OSMPP
password 1234
osmocom-extensions

Здесь активирован GPRS, а также изменены два таймслота — теперь им выделены пакетные данные. Настройки, касающиеся сети (имя, канал, код...) остались те же самые, их также нужно изменить, как в прошлый раз.

На телефоне необходимо создать точку доступа. APN её может быть любым, как и в случае с srsRAN он не проверяется, нужна она лишь для того, чтобы телефон сам начал подключение.
Итак, время запускать сеть. На этот раз делается это так:

sudo ./main.py -d uhd --gprs -i (тут ваше имя подключения)

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

Для проверки был взят всё тот же смартфон от Samsung. Подключаемся к сети, включаем сотовые данные, и в строке состояние появляется «EDGE». Отлично, работает.

У меня было много опасений, что интернет работать не будет. Во-первых, куча приложений, стремящихся дорваться до сети во что бы то ни стало, во-вторых, сам размер сайтов, не позволяющий пропихнуть их через канал, по скорости недалеко ушедший от модемного. Но легковесные сайты по типу old-dos.ru вполне открылись.

Далее я подключил и свой основной телефон. Он тоже отлично заработал и подхватил созданную сеть.

❯ Возвращаем свой две тысячи седьмой

Пожалуй, одна из немногих составляющих старого железа и «тех» времён в принципе, к которой я не испытываю ностальгии, — мобильный интернет.

По поистине конским тарифам (единицы рублей за мегабайт) предоставлялось весьма слабенькое соединение. Мобильные версии сайтов тогда тоже сильно отличались от привычных нам. Существовало два протокола — WAP (созданный специально для GSM-сетей, работающий через шлюз поверх GPRS или SMS), в котором передавалиись страницы в формате WML, и обычный HTTP. Позднее префикс «wap.» получили вообще почти все сайты, адаптированные под сотовые телефоны.

Сайты эти тоже были весьма своеобразными — на типичной страничке было в наличии практически всё, от новостей и мобильного софта (с непременными разделами для J2ME, WM и Symbian) до знакомств и дешёвой эротики. Многие телефоны из использовавшихся в те времена до сих пор хранят на своих картах памяти картинки с котиками, скачанные по пять рублей за мегабайт.

Также существовал такой бич для баланса как «premium-rate сайты». Суть их заключалась в том, что при заходе на с виду обычный сайт абонент мог не только просадить весь свой баланс, но и уйти в глубокий минус — тарификация по ним была повышенной (вплоть до сотен рублей за мегабайт), отчего заход на такие страницы обходился во всех смыслах дорого (на безлимитных тарифах они всё равно списывали деньги). Не обходилось и без грязного SEO (в духе тех времён) в виде размещения на страницах элементов с вот таких вот сайтов по типу «невидимых» картинок и тому подобного материала.

К слову говоря...

Нечто подобное сейчас тоже существует, правда, в куда меньших масштабах (например, у Tele2 — на страницах ошибок по типу 404).
Случайный жмяк по рекламе (которую ещё иногда делают картинкой в виде видеоплеера, чтобы кто-то намеренно нажал), и пользователь немедленно получает подписку за двадцать-тридцать рублей в сутки, отказаться от которой очень сложно.

Для работы полноценного WAP сейчас понадобится WAP-шлюз, поэтому в данной статье ограничимся только HTTP.

Увы, Siemens так и не смог загрузить ни один сайт. То ли что-то с настройкой точек доступа, то ли его браузер поддерживает только WML, но ничего больше унылой надписи «Соединение...» из него выжать не удалось.

Поэтому на помощь был призван Nokia E90, который смог загрузить вначале old-dos.ru…

… а потом и какой-то древний мобильный сайт.

А вот он же на экране Nokia N95.

Интересно, обновляются ли они? Или эти «обновления дня» остаются такими уже лет десять?

Отправляемся гуглить и находим список из всё ещё живых старых сайтов. А вот и ещё один экземпляр…

Забавно — программы для WM, а значок от Win8/WP…

lankost.net, один из крупнейших ныне живых...

> Продолжение в источнике материала на Хабре. Увы, все фото не влезли (их действительно много), а именно в них вся суть и самое вкусное. :)

• Написано специально для Timeweb Cloud и читателей Пикабу. Подписывайтесь на наш блог, чтобы не пропустить новые интересные материалы.

• Также подписывайтесь на наш телеграмм-канал — только здесь, технично, информативно и с юмором об IT, технике и электронике. Будет интересно.

• Облачные сервисы Timeweb Cloud — это реферальная ссылка, которая может помочь поддержать наши проекты.