Наш спутник ударился о небесную твердь ровно в день открытия публичного доступа к нему. Вы, возможно, уже в курсе. Конкретно атмосфера оказалась куда шершавее, чем в прошлый раз, и он спустился пониже и перестал выходить на связь.
К счастью, у нас есть резервный спутник! Из материнского контейнера он вышел чуть позже и выше. Думаю, у него ещё неделя. Так-то мы рассчитывали на несколько месяцев.
И это далеко не всё, что случилось в этой истории.
Вообще, тут две истории, которые сплелись в небольшой ад. Первая — это ожидание и реальность от софта и связи с наземным гридом. Нам пришлось переписывать стек протоколов, потому что в сыром SSH могла дойти половина команды. Например, мы отправляем rm -rf /home/pi/tmp/cache, а приходит rm -rf /home/pi. Это было бы очень забавно.
Очень много приколов с оптимизацией: например, чтобы сделать фотографию не чёрного экрана, надо как-то попасть в Землю. Спутник неуправляемо вращается, двигателя у него нет — поэтому надо дождаться, пока в кадр попадёт планета, и снимать. Так вот, код там прямо из 90-х — камера делает серию из 5 снимков с паузами, а затем основным считается тот JPG, который больше весит. Это значит, что в нём больше значимых пикселей, и это, вероятно, планета.
А, да, и потом американский NORAD перестал давать нам данные о положении спутника, и пришлось стучать в МГУ за матмоделью орбитальных расчётов, которые корректировались по тому, где мы последний раз видели спутник и куда он ушёл.
Итак, наш первый спутник год назад вышел на орбиту и вещал оттуда веб-страницу по радиоканалу. Этот новый спутник, уже с мини-сервером на борту и с доступом по SSH, должен был стать первым полноценным VDS в космосе.
Естественно, всё, что могло пойти не так, пошло не так!
Что мы вообще затеяли (и с кем)
В 2023-м мы запустили TinySat — размером в полтора спичечных коробка — задача была попробовать хостить с орбиты. При выходе из контейнера у него отвалилась память, из резервной удалось развернуть только маленькую HTML-страничку, которую спутник транслировал по радиосигналу. От VPS на орбите это было далеко, поэтому к теме захотелось вернуться.
Тот аппарат отлетал два года.
К нам пришли из ОКБ «Пятое поколение». У них был другой форм-фактор, TriSat, с энергетикой заметно круче (сравнение платформ есть в прошлом посте). У них была своя сеть наземных станций. И у них был протокол Console Gate: общаешься со спутником по SSH, оно оборачивается в Telnet и уходит на борт. Звучало очень круто, простое приключение на 20 минут, просто повторить то, что мы уже делали, раз все протоколы готовы. Мы посмотрели и такие: давайте делать, супер!
На тот момент нам казалось, что достаточно собрать железяку, залить туда правильно подготовленный дистрибутив с архивом статей Хабра, и всё будет хорошо.
Это некоммерческий эксперимент, мы это делаем за маркетинговый бюджет, и, как и многие другие странные эксперименты вроде стратосферного десанта сисадмина на Северный полюс, — потому что можем и потому что это интересно. Партнёры в проекте тоже некоммерческие.
Цель одна: посмотреть, можно ли работать с настоящим спутником как с сервером и давать к нему доступ. Звучит просто. На деле это довольно сложная штука, поэтому так до нас никто и не делал.
Как устроено
Чтобы разговаривать с гридом, нужно было построить три разных модуля: сессии, которые ходят к гриду по HTTPS, канал MQTT, по которому идут сами данные, и авторизацию. Плюс Console Gate, через который всё это доезжает до человека, открывшего страничку. Свой шлюз мы, чтобы уж точно никого не запутать, тоже назвали ConsoleGate. Он живёт в отдельном контейнере рядом с шедулером слотов и базой.
Сама сборка Linux под Raspberry, если что, относительно стандартная, там не то чтобы сильно что-то изменено. Перед сборкой ОС из исходников поменяли энергорежим, добавили библиотеки под специфичный софт, который должен жить на борту, и всё. Вот схема, и на каждой стрелочке этой схемы свои сложности и свои танцы с интеграцией, потому что системы разнородные, писались разными людьми в разное время.
Что пошло не так
Задолго до запуска мы начали тестировать:
— У нас есть своя железка без корпуса, похожая на оборудование спутника. К ней написан симулятор грида, чтобы было как с наземной связью. Можно тестировать её напрямую, можно через SSH через эмулятор связи.
— В ОКБ стоит полная копия спутника — это нужно, чтобы можно было сначала накатить что-то с Земли на него, посмотреть, что с ним станет, и потом уже стабильную ветку катить на орбиту. Потому что до земного ещё можно дойти и перезагрузить, а вот с орбитальным будут небольшие сложности.
— И, наконец, есть три спутника — основной (который уже сгорел) с полным дистрибутивом и 2 резервных, сконфигурированных более просто (они работают бэкапом для всей группировки N+2, поэтому дальше дифференцируется в то, что ему надо заменить). Собственно, от лица всей группировки нам понадобился один из резервных спутников, второй используется для другого и тоже не сильно долго пробудет на орбите.
Сначала протокол Console Gate. ОКБ позиционировали его как API: подключитесь и работайте. Мы так и планировали. Оказалось, что нормального внятного API как продукта нет, есть низкоуровневый стек протоколов. Наша задача внезапно превратилась в «дописать своё и помочь ОКБ дописать их часть». Практически с нуля, начиная с реакций на недошедший пакет (а пакет до спутника не доходит часто) и заканчивая тем, как дробить и отправлять с борта фотографии. Наш разработчик Александр просидел с этим, по моим прикидкам, месяцев семь, до прототипа, который хоть как-то работал.
У Александра был период, который он сам описывает словами «сколько уж можно!!1». Отладил дома. Отладил на стенде. Через два дня прилетает: слушай, что-то не работает. Как, почему? Заходишь в дебаг: вместо привычных строк прилетают другие. Ладно, переписываешь, отлаживаешь, пошло. Проходят сутки: не, опять отвалилось. Опять заходишь — опять поменялся. Параллельная разработка двумя командами — вещь такая.
Работа превращалась в написание стека протоколов и достаточно кропотливую отладку. Причём несколько раз, когда мы уже тестировали что-то верхнеуровневое, у нас отваливались слои ниже в стеке протоколов — потому что ОКБ тоже вносили изменения, и, пока шла разработка, любой из протоколов мог поменяться. И несколько раз менялся достаточно, чтобы мы сходили с ума во время отладки. Около месяца ушло просто на поиск корневых причин, что же не работает.
Внезапный дедлайн
В целом нас ориентировали на запуск в 2026 году. Там живая очередь, и если кто-то слетает, то освобождает место. Вероятно, многие иностранные заказчики очередь освободили. Собственно, в ноябре 2025-го нам сказали, что запуск в декабре 2025-го. И, по факту, осталось быстро-быстро написать софт и всё остальное за неделю-две. Потому что, когда аппарат на орбите, залить туда что-то ещё можно, но чувствительность к объёму апдейтов там такая, что каждый лишний килобайт — отдельная боль.
Дальше мы две недели не спали и красноглазили. Потому что реалистичный срок был 1 месяц разработки, если опять не сменятся протоколы.
Естественно, мы не успели.
Версия, накатанная в ноябре в спешке, конечно, не была финализирована: протестировать успели не всё. Но основную часть мы на боевой аппарат загрузили. Небольшие скрипты, которые можно докинуть уже в полёте, оставили на потом. Тогда это казалось разумным. На борт уехало: дистрибутивы и компиляторы, каталог лучших статей Хабра (золотой фонд плюс работы победителей нашего с Хабром конкурса «Космотекст»), Doom, ну и всякая веселуха. Плюс продукт «Лаборатории Касперского»: они адаптировали под скромную бортовую Raspberry свой Kaspersky Endpoint Security for Linux в редакции Space Edition. То же самое накатали и на два аппарата-дублёра, про них дальше.
Запуск
Стартовали 28 декабря 2025-го, под самый Новый год: «Союз-2.1б» с Восточного, около пятидесяти попутчиков. Наши аппараты были внутри носителя «Мул-4Т». Это тоже разработка ОКБ «Пятое поколение», между собой его зовут фермой — материнский контейнер, который выпускает рой спутников. Точнее, это прошлый раз был рой, а сейчас спутники выстреливали по одному, с интервалом примерно в неделю: выпустили, посмотрели, всё ли нормально, через неделю следующий.
Отделение нашего аппарата было в начале февраля.
При этом все аппараты оказались ниже, чем планировалось. Точнее, прошли по нижней границе допусков — мы рассчитывали на полгода, год или, если очень повезёт, два, а получили практически пессимистичный прогноз по нахождению на орбите.
У спутника-дублёра возникла проблема с энергетикой (они устроены чуть по-разному для тестов), и он иногда отключает сам сервер, потому что не успевает зарядиться на полный цикл.
Теперь про реализацию SSH
Спутник надо ловить наземной станцией грида. Он там проходит, условно говоря, окнами по 10 минут — навелись, он вошёл в узкий луч, сначала много помех, потом нормально, потом снова много помех, потом он выходит из луча. Чтобы поймать ещё раз, нужно наводиться заново, и, возможно, уже через часы или дни в зависимости от ситуации. Возможно, с другой станции грида.
В комментариях к прошлому посту кто-то прикинул, что при 1 кб/с спутник уплывёт за горизонт раньше, чем SSH обменяется ключами. Всё так, поэтому по радио всё не так: SSH заканчивается на Земле, на стороне грида, дальше команда оборачивается в Telnet и уходит на борт. Большими ключами над горизонтом никто не обменивается. Консоль борта существует, это правда. Но связь с ней поочерёдная: мы либо говорим, либо слушаем. Гарантированной доставки нет ни в одну сторону. Ни мы не можем быть уверены, что команда дошла до спутника, ни спутник — что его ответ дошёл до нас. При этом команды идут пакетами, маленькими порциями, друг за другом, а скорость такая, что каждую порцию хочется беречь.
И килобит в секунду — это про радио. То, что видит наш софт, совсем другое: поверх радио сидит MQTT грида со своими контрольными суммами, поверх него наша обвязка, и всё это по очереди, туда-сюда. Очень много уходит на повторы и контроль ошибок при помехах. В итоге лучшее, что мы получали в космосе, — около 45 байт протокола верхнего уровня (то есть значимых) в секунду. Сорок пять байт! В секунду!
Первое, что мы попробовали, — не изобретать велосипед: скомпилировали и отправили на борт ZMODEM и XMODEM. Это протоколы времён COM-портов, восьмидесятых-девяностых, там уже всё было придумано: разбивка на пакеты, контрольная сумма на каждый пакет, даже сжатие. Какой-то выигрыш это дало.
Но ZMODEM рассчитан на то, что линия есть. По умолчанию он делает пять попыток и сдаётся, а при любом рассинхроне начинает перезапрашивать пакеты. А спутник в этот момент не факт, что отвечает, и не факт, что перезапрос до него вообще долетел. В итоге борт отвечает на предыдущие пакеты, а Земля думает, что ждёт уже два следующих.
Ад в канале выглядел так: набираете стандартную команду ls -la. Отобразить каталог. До спутника могло долететь ls. Могло долететь только -la. Могло не долететь ничего. Назад мог пойти список каталога и зависнуть на середине. Мог прилететь кусок: только концовка, потому что пакет с началом куда-то делся. Или начало и конец без середины.
Интересно, что некоторые команды при такой обрезке могут быть с интересными эффектами. Мы это скорректировали чуть позже, но вначале прикинули, что там может быть.
Ну, для начала rm -rf /home/pi/tmp/cache может стать rm -rf /home/pi. Привет. Какой-нибудь chmod -R 755 /var/www/site может стать chmod -R 755. Ладно, это не так страшно. А shutdown -c, ставший shutdown, — уже не так весело. kill 12345 может приехать как kill 123. При потере головы приколы вроде man reboot становятся просто reboot. Конечно, чаще просто нам приезжала ошибка, и команды не исполнялись, но несколько волнительных моментов мы пережили.
Конечно, у нас есть система, которая возвращает спутник в исходное состояние (в частности, между сеансами использования разными пользователями), но всё равно так жить нельзя. В первую очередь из-за несоблюдения очерёдности пакетов.
Протокол из контроллеров 90-х
Александр вспомнил про контроллеры начала девяностых, которые работали по последовательной линии — той, из которой потом выросли RS-485 и Modbus. У них в составе был протокол, который назывался STP, Serial Transfer Protocol, в доску простенький: нумерация пакетов, контрольная сумма содержимого, небольшой заголовок.
Главное, что он занимал мало байт: на 100 байт полезной информации уходило около 8 байт обвязки, а то и меньше. Его взяли за основу и допилили под наши реалии. Номера функций и прочие части, которые нам были не нужны, откинули, сильно упростили, подстроили под связь, какая есть.
Резонный вопрос: если на 100 байт данных уходит 108 байт передачи, откуда такая низкая скорость? Ответ, если что, простой: оверхед не наш. Наш протокол сидит слишком высоко. Под ним грид гоняет данные по MQTT и считает свои контрольки, под MQTT — радио. Где именно по дороге что-то теряется, мы так до конца и не поняли, но эффект вы уже видели выше.
Полудуплекс диктует всё остальное. Мы либо говорим, либо слушаем. То, что услышали, не факт, что пришло целым, надо перезапрашивать. То, что сказали, не факт, что было услышано. А серверная часть при этом стоит на маленькой холодной железяке где-то в космосе.
Собственно, поэтому надо делать как абсолютный конечный автомат, который из любого состояния возвращается в любое другое по команде с Земли и сам никаких решений не принимает. Пассивный отвечальщик: чего запросили, то и выплюнул. Весь контроль на Земле, и Земле нужно уверенно отвечать на четыре вопроса: что мы передали, было ли это передано, что мы получили и то ли это, что должно было прийти.
Если пакет не долетел или вышел тайм-аут ожидания, протокол его перезапрашивает. На Земле параллельно отсчитывается давность: ответа нет, значит, борт уже перешёл в следующий режим, значит, текущее можно игнорировать и снова запускать ретрансмит. Попутно считается скорость передачи и количество потерь.
Те самые 45 байт в секунду — это лучшее, что мы видели в космосе. На стенде на Земле бывало 50–55, абсолютный рекорд — 57.
Когда протокол начал более-менее гарантировать, что команда дошла до спутника, выполнилась и вывод снят обратно, только тогда стало возможно строить процесс. Завести пользователей, настроить тот самый вход, который снаружи выглядит как SSH, запустить скрипты инициализации, гонять пачки передачи. Всё это должно было работать как библиотечные функции для веб-клиента, того, что дальше собирал Кирилл. Загрузка файлов тоже пакетирована, файл разбивается на чанки.
Login incorrect
А вот эта часть доставила нам невероятный геморрой. Кирилл делал мост между пользователем и бэкендом через сокеты. Задача звучит скромно: принять с фронта строчку текста, отдать назад ответ спутника, а перед этим автоматически пройти авторизацию на борту.
Проблема в том, что после перезагрузки Linux запрашивает логин. Перезагрузка случается часто, потому что между сеансами связи железка выключается контроллером. Пока спутник летит без нас, он заряжает аккумулятор. А протокол стабильной связи — внутри сервера, то есть он ещё не работает, надо всё повторять по 10 раз и надеяться, что дошло правильно.
Дальше скрипт ждёт, когда загрузится Linux и появится приглашение логина. Приглашения нет — отправляем Enter. Ждём. Опять нет — ещё Enter, примерно раз в три-пять секунд, по совету коллег. В хорошем случае приходит login:, мы пишем имя пользователя, борт в лучшем случае спрашивает пароль, мы вводим пароль и ждём входа.
Плохой случай выглядит так: мы ждём запрос пароля. Запрос не приходит. Мы отправляем Enter и получаем «Login incorrect». Оказывается, запрос пароля до нас просто не долетел, борт уже ждал пароль, а мы вместо пароля отправили ему пустую строку. Состояние сбрасывается, мы заново ждём логин. Так могло повторяться до трёх раз, после чего связь обрывалась, и подключение приходилось поднимать заново, а это тоже время.
Времени же на всё про всё — 10 минут. Бывало, что связь просто терялась. Из этих десяти логин занимает по-разному. Бывает три-четыре минуты. Бывает, что сессия заканчивается, а мы так и не залогинились. Начало сеанса — это когда спутник ещё на краю диаграммы направленности антенны, там шумно, и до запуска нашего протокола всё это чисто шансовая вещь. Эфир хороший — залогинились с первой попытки.
Если залогинились, первым делом запускаем на борту наш STP-скрипт (он на Python), протокол для обмена пакетами. В подтверждение того, что скрипт поднялся, отправляем строчку, условно «hello», и ждём «hello» в ответ. Бывает, что за сессию уходит тридцать-пятьдесят «hello», а ответа нет ни одного.
Зато, если всё поднялось, дальше красота. Отправляем строчку, получаем ответ. Если ответ большой, борт складывает его во временный файл, мы скачиваем файл частями, потом он удаляется. Никаких дублирований и потерь, ответ приходит целиком и по порядку. Ради этого всё и затевалось.
И да, длинные частые команды мы заменили на алиасы (они раскрываются обратно на стороне сервера), чтобы отправлять меньше данных.
Фото
Одно из самых очевидных использований спутника — фотосъёмка и потом спуск фотографий вниз.
Сначала нужно было отрегулировать размер, чтобы борт не пытался отправить нам 50 мегабайт. Полный файл при нашем канале качался бы неделю-две. С другой стороны, конечно, хотелось, чтобы на картинке хоть что-то было видно.
Картинка жмётся до 7-10 килобайт. То есть можно забрать за 3-5-7 минут, как раз в рамках сессии.
Вторая проблема — сам аппарат. Он крутится не вокруг своей оси, а вообще в какую угодно сторону. Камера болтается. Поэтому мы делаем не один снимок, а серию кадров с интервалом пять секунд. Как вы уже знаете, в работу берём только тот файл, в котором больше байт. Если чёрный космос, он хорошо сжимается и весит мало. Если в нём много байт, значит, там что-то есть, скорее всего, Земля. Правда, иногда все кадры всё равно сняты, когда камера смотрит от планеты. Тогда возвращается самый большой чёрный квадрат.
Скачивает всё это File Downloader, скрипт со стороны грида, который тянет файл по байтам в хранилище. Борт перед файлом шлёт специальную магическую строку-заголовок, по ней шлюз переключается в режим приёма и блокирует ввод команд, потому что параллельно в этот канал лучше ничего не совать.
Прикол с NORAD
Это ещё одна звёздочка к этой задаче. Мы про это на старте не думали вообще. Спутник маленький и летит быстро, поэтому антенну наземной станции нужно точно наводить. А для этого нужно знать, где он конкретно. Эти данные даёт NORAD, американо-канадское командование воздушно-космической обороны (американская ПВО), которое присваивает каждому объекту на орбите номер, отслеживает его траекторию и, по сути, делает всё за вас. Берёте TLE, набор орбитальных элементов, вбиваете в грид-станцию и наводитесь.
Данные общедоступные и бесплатные, с ограничениями, наверное, для тех, кому нужна особая точность, но нам хватало. Так было всё время. А примерно в июле оказалось, что американцы стали обновлять данные по нашим аппаратам гораздо реже. Раз в пять дней. В первый день после обновления связь хорошая. К четвёртому-пятому спутник улетает совсем в другое место, отклонения накапливаются, и антенна ищет его там, где написано, а там его чаще всего нет.
Ну и пришлось искать, как рассчитывать TLE самим: экстраполировать, подбирать баллистические модели, с полным геморроем. Видимо, военное время, американцы решили не делиться. Почему именно так и почему сейчас — непонятно. ОКБ написали американским военным. Те вежливо ответили: «Спасибо за ваш запрос, мы займёмся вашей проблемой». И, естественно, ничем не занялись. Тогда ОКБ срочно подключили МГУ, где есть подразделение, которое занимается космическими исследованиями и у которого своя методика движения небесных тел. Привет мехмату, кстати! По их модели стали вручную пересчитывать и корректировать те данные, что есть в TLE. Сделали несколько пробных замеров, вроде получается.
Считать орбиту самим — вообще нормальная практика у кубсатчиков. AMSAT прямо пишет: после групповых запусков первые пять-десять дней уходят на то, чтобы понять, какой объект чей. SatNOGS и вовсе восстанавливает элементы по доплеровскому сдвигу.
На середину августа возраст последнего TLE у того аппарата, с которым мы работаем сейчас, — трое суток, у соседа по запуску — пять. Для объекта на 300 километрах норма — несколько обновлений в сутки, потому что атмосфера меняет орбиту каждый день.
Объявлений о том, что данные по российским объектам ограничили, мы не нашли нигде. Единственный похожий прецедент — 2022–2023 годы, когда Space-Track почти год отдавал всем «ограниченные обновления TLE» и не объяснял, почему.
Что со спутником сейчас
Когда с NORAD более-менее разобрались и начали тестироваться, оказалось, что спутники уже стремительно сходят с орбиты и жить им осталось недели две.
Мы сидим и такие: зашибись. Начали тестировать в темпе, в ходе тестирования — ещё какие-то мелкие ошибки. И вот день запуска, всё готово, а спутник не отвечает. Собственно, ровно в день, когда мы хотели давать публичный доступ, он и ударился о небесную твердь.
Последнее, что мы знаем про основной аппарат, — орбита 270 километров несколько дней назад, а потом ушёл со связи. За неделю назад на связь не вышел, что неудивительно. Вообще, ниже 300 — уже очень рискованная зона. Формально спутники сгорают на 150 километрах, но это про большие аппараты, а у нас пикоспутник без дополнительных слоёв защиты: как только атмосфера становится плотнее, он, скорее всего, просто ломается. На тех высотах, где он сейчас, никакая радиосвязь невозможна.
Дублёров у нас было два, с той же прошивкой. За счёт этого появился второй шанс: мы накатили на дублёр всё необходимое (прошивка одинаковая, но обновление всё равно потребовалось) и переключились. Дублёр сейчас на 330 километрах, выше, чем был наш, и выстрелен он был на неделю позже, так что у него, по идее, есть еще неделька в запасе. По пессимистичному сценарию — до конца этой недели полетает и будет принимать наш сигнал, на следующей, скорее всего, повторит судьбу первого. Может, полетает до конца августа. А может, завтра выключится.
Дублёру не хватает заряда на полноценный цикл, поэтому не всегда окно нормально открывается: может так быть, что сеанс связи есть, а заряд ещё не накопился, тогда оборудование не включается.
На момент написания доступ открыт, и люди подключаются. С горем пополам, но подключаются. Хотели мы, конечно, совсем не так, но каким-то образом работает. Вход через аккаунт RUVDS, дальше слоты бронируются через Telegram-бота, который ходит в API грида за свободными окнами и бронирует их. Сеансов несколько в день, за полчаса до сеанса нужно подтвердиться; если не подтвердил, сеанс отменяется. Многие на этом теряют свои сеансы.
Воспользоваться этим успеют, думаю, несколько десятков человек. Пара десятков уже поработала, за неделю, может, наберётся ещё пара десятков. Денег мы за это не берём, это не услуга: как получилось, так получилось.
После каждого пользователя всё удаляется, файлы не накапливаются: это максимально близко к использованию виртуалки, насколько вообще возможно при таком канале. От модели «спутник что-то постоянно вещает, а радиолюбители слушают» мы отказались сознательно. Интерес был именно в том, чтобы работать с аппаратом как с сервером.
Когда аппарат замолчит, скажите, надо ли открыть на пару недель по той же схеме доступ к наземному образцу, тому самому, что стоит на вибростенде в лаборатории. Поиграться можно будет, но фотографировать он будет стену.
Раз десять-пятнадцать за этот год мы были близки к тому, чтобы просто плюнуть
Не плюнули благодаря людям, которые собрались и каждый дотащил свою часть. Каждый сделал огромную работу, всем спасибо. Ценность второго эксперимента, на мой взгляд, гораздо выше.
Вторая боль всех участников — гонка со временем. Запуск на полгода раньше, год жизни аппарата стал 8 месяцами. ОКБ уже собирает заявки на следующий TriSat, на 2027 год. Не знаю, будет ли следующий спутник, это всё было очень тяжело. Но пока есть нынешний — можете его затестить. Инструкция выше.
Если мы решим запускать ещё что-то (а я в этом очень сильно сомневаюсь), на той же платформе будет гораздо проще: что-то уже есть, протокол написан, грабли пересчитаны. Но прямо сейчас — не хочу.
Комментарии (41)
VasVovec
20.08.2026 08:36Спасибо что поделились опытом и идеями, очень интересно. Пока прочитал только начало :) Никогда не задумывался о таких возможных трудностях в обмене данными с кубсатом. Стало интересно, как другие разработчики решают эти проблемы.
ntsaplin Автор
20.08.2026 08:36Спасибо!
Мы тоже до начала проекта сильно недооценивали именно эту часть. Думали, ну там же уже есть протокол, SSH завернём и вперёд. В итоге большая часть разработки ушла на то, чтобы превратить не слишком надёжный радиоканал в что-то, что хотя бы отдалённо напоминает нормальное соединение. Плюс, мы специально полезли в более сложный сценарий — сделать из спутника условный сервер, к которому человек может подключиться и что-то выполнить в реальном времен. Отсюда весь этот прекрасный зоопарк с потерями пакетов и 45 байтами в секунду.
Но это всё спойлеры!
Astroscope
20.08.2026 08:36Стало интересно, как другие разработчики решают эти проблемы.
Другие разработчики ставят другие задачи, в смысле не запускают условный сервер. Совсем необязательно, но довольно часто кубсат имеет два или более даунлинка - payload (например картинки с бортовой камеры) отдельно с достаточной шириной полосы - вопрос лицензирования оставлю открытым, я не знаю процедуру, telemetry отдельно. То есть картинки передаются достаточно быстро, чтобы спустить дамп из кучи отснятых картинок за короткое окно радиовидимости, а телеметрия достаточно надежно, чтобы ее можно было принять на кусок провода (это немного утрировано, но иногда даже и буквально). Иногда бывает еще и просто beacon, на который удобно настраиваться и по доплеру которого можно делать выводы об орбитальных параметрах, но помним про ограниченное питание, в которое можно и не поместиться, а значит downlink можно переключать (вместо нескольким работать одновременно) по таймеру, по команде с земли или по другим событиям, например по признаку попадания в зону радиовидимости наземной станции, которая может принять дамп. Control uplink во первых часто не анонсируется (security though obscurity), это крайне примитивный, но все равно вполне себе способ осложнить несанкционированный доступ к управлению, тем более что поцслушать uplink крайне затруднительно просто потому, что наземная станция излучает на спутник, а не в горизонт, а за горизонтом в любом случае ничего уже не принять. Во вторых, опять же, вопрос ширины канала и получения соответствующей лицензии. Многие хотят пойти по пути радиолюбительских частот, а там сильно ограничена полоса - и поделом, потому что любительская связь это другое™. То есть нужно идти на обычный для спутников S band что для uplink, что для downlink (вряд ли что-то возможно согласовать в L-диапазоне, а X band технически сильно сложнее и не стóит того, если вам не нужна полоса в десятки мегагерц). Ну а дальше все просто в теории и несколько заморочливо в реализации, но ничего неподъемно сложного, тем более сегодня с распространением SDR - автоматическое поворотное устройство промышленного производства (ну или самодельное, почему нет), само следящее за спутником на основе TLE, и автоматическая коррекция доплера что по приему, что по передаче, чтобы ничего не трогать на спутнике и чтобы со спутником могла работать любая наземная станция из любого места. Но в принципе нет непреодолимой проблемы компенсировать доплер на спутнике, просто это менее целесообразно. И антенны, нужны длинные антенны, потому что у спутника очень слабое питание и очень ограниченные габариты, значит на спутнике невозможно разместить эффективные, тем более управляемо направленные антенны, и невозможно развить большую мощность на передачу - нужно с земли развивать приличную EIRP в направлении спутника, он же слышит все помехи с земли и нужно их задавать полезным сигналом, и нужно иметь большое "усиление" (антенны не усиливают, это только термин такой) по приему на земле, чтобы выделить крайне слабый сигнал спутника из шумов, тем более что полоса широкая из-за потребности в скорости.
Резюме: полоса, нужна полоса, чтобы за четверть часа в лучшем случае можно было успеть обменяться значимым количеством данных, а не сотнями, максимум тысячами байт.
VasVovec
20.08.2026 08:36Спасибо за ликбез. Звучит здраво. Очень интересно. В закладки, однозначно. Где бы на изучение и главное практическое освоение всей этой космической радиоалхимии найти достаточное количество свободного времени. Желательно, не дожидаясь выхода на пенсию. Как вариант - сменить сферу деятельности на что-то с этими самыми кубсатами связанное.
Astroscope
20.08.2026 08:36Только хотел спросить, с какой целью вы интересуетесь, как прочитал, что вы не против пойти в разработчики. Тут мои компетенции очевидно заканчиваются, потому что мой интерес чисто радиолюбительский и наибольший интерес лично у меня вызывают радиолюбительские спутники связи, хотя я не против и погодные спутники послушать. То есть про обустройство любительской наземной станции я что-то смогу рассказать, а про устройство спутника - немногое. Ну, кроме того, что детали для их сборки продаются готовые (раз, два, три и так далее), и если вы частное лицо или небольшая организация, то вы все равно можете построить и с попуткой запустить свой спутник, собрав его из
говна и палокстандартных промышленных компонентов, хотя для частного лица запуск - удовольствие дороговатое, поэтому типичный workaround это грант под студенческий проект или какой-то иной способ найти спонсоров. Например, радиолюбительские организации собирают пожертвования на строительство и запуск радиолюбительских спутников связи - иногда это донаты от частных лиц, на которые строятся всякие кубсаты, а иногда крупный бизнес позволяет радиолюбителям использовать маленький кусочек большого коммерческого спутника связи. Раньшебыло лучшекаждый спутник был индивидуальной, разработанной по сути с нуля конструкцией, а сегодня можно схитрить и сделатьна Ардуиноиз готовых фабричных модулей - смотря какие ваши цели и каков ваш уровень подготовки, а также смотря каков у вас доступ к материалам и станкам.VasVovec
20.08.2026 08:36Я думаю, что начинать все это изучать надо как раз с радиолюбительства, потом осваивать прием данных с радиолюбительских спутников (сейчас это где-то даже в школьных кружках дети изучают), а уж только потом замахиваться на создание кубсатов. Т.е. сначала научиться пользоваться готовым, а уж только потом с учетом пользовательского опыта можно думать о разработке чего-то своего.
Astroscope
20.08.2026 08:36Если у вас есть радиолюбительская лицензия, то попробуйте сработать через, например, SO-50. Минимально вам понадобится фуфлофенг с удлиненной антенной, но это ненадежно - сигнал слабоват, более мощные станции будут накрывать и, если вы недостаточно настойчивы, то серия нескольких неудач может всерьез отбить интерес. Лучше взять и радио получше, и антенну типа двухдиапазонной Яги на два-три элемента на 145 и на четыре-пять элементов на 437 - такие антенны настолько короткие и легкие, что легко направляются вручную без необходимости в поворотном устройстве, но они все же заметно повышают EIRP на передачу и еще более заметно улучшают прием (у вышеупомянутого SO-50 мощность примерно 0.25W, против примерно 4W~5W у фуфлофенга), а значит вероятность сработать увеличивается. Мощные станции с длинными антеннами все равно будут накрывать, но бороться с ними нерационально - проще переждать и сработать позже, когда почти или совсем не мешают.
Если вам интереснее данные, то на борту ISS имеется digipeater - полудуплексный пакетный ретранслятор. Он включен не всегда (нужно следить за расписанием или просто слушать), но если включен, то можно подключиться к бортовой BBS (я ни разу не пробовал), можно передать пакет в сеть APRS, а самое, на мой взгляд, интересное - обменяться текстовыми сообщениями с другими станциями. В принципе, опять же, достаточно фуфлофенга с удлиненной антенной, но практически лучше что-то вроде двух-трех элементов Яги или, например, Моксона, и станция получше. А вот TNC (радиомодем) на отлично эмулируется софтом для основных десктопных ОС и для телефонов, поэтому по-минимуму достаточно пассивного аудиокабеля от компьютера или телефона к вашему радио.
Либо вас это затянет и вы захотите углубить и расширить, либо быстро наскучит - не попробуешь не узнаешь.
Strijar
20.08.2026 08:36Сколько же прокладок в радиообмене. Была бы прямая Lora например - сильно все проще бы стало!
zapparello2
20.08.2026 08:36лора это просто микросхема, данные можно передавать в любом формате. Размер пакетов от единиц до 255 байт. И ни в чём себе не отказывай!
Strijar
20.08.2026 08:36Lora это не микросхема, это модуляция с коррекцией ошибок. Этот протокол давно используют для любительских спутников, сюрприз! И да доступ к пакетной передаче решает описаную тут проблему когда команда не долетает до конца. Я вот сильно удивлен что команда не отправлялась одним пакетом.
Astroscope
20.08.2026 08:36LoRa это уникальный, не имеющий аналогов в мире™ вариант CSS, доступный для интеграции в виде проприетарного аппаратного обеспечения. То есть LoRa это и микросхема, и вид модуляции одновременно. Отреверсировать и создать стороннюю реализацию LoRa, разумеется, возможно, но могут возникнуть вопросы из области патентного права, не технические - технически это просто CSS, тысячи их, то есть ничего нового или необычного, просто отдельное семейство со своими параметрами. Так что оба правы, спор бессмысленен.
Этот протокол давно используют для любительских спутников, сюрприз!
Сюрприз в том, что в большинстве случаев любительским радиослужбам запрещено использовать виды модуляции с шириной полосы более 2.7kHz. Исключения существуют, куда уж без них, но проприетарный вид модуляции LoRa в эти исключения не входит. В исключения входит, причем в зависимости от конкретной страны, а не глобально в мире, аматорское телевидение на SHF диапазонах, в котором используются открытые и хорошо задокументированные виды модуляции и кодирования (не шифрования!) сигнала. То, на что вы даете ссылку - это попытка вовлечь энтузиастов во в общем-то коммерческий проект. Примерно как сеть энтузиастов, принимающих ADS-B транспондеры по всему миру, и отдающих принятые данные организациям с конкретными бенефициарами.
Я вот сильно удивлен что команда не отправлялась одним пакетом.
А как вы это себе представляете? Я серьезно. Вы отправляете один пакет - что дальше? Вам нужен ACK? Если не нужен, то дальше говорить не о чем - просто шлем что угодно и молимся Летающему Макаронному Монстру, чтобы наши пакеты:
в принципе дошли
были декодированы правильно со всеми FEC и CRC, если они вообще были предусмотрены (а это overhead)
команда в переданном пакете была принята и выполнена
результат выполнения команды был идентичен предполагаемому/прогнозируемому
А в это время
Мчится по орбите спутник,
С апогея в перигей...
у вас окно радиовидимости, если прямо вот так вот практически идеальный транзит через зенит - это минут пятнадцать. На самом деле заметно меньше, но пусть. Не сказать, что мало, нет. Но во первых, если речь о примерно полярной орбите - а большинство кубастов мечтает о ней, то у вас таких транзитов будет... э... ну, там, раз, два, три... Немного, в общем. Удачных - от нуля до одного-двух в сутки, приемлемых для радиосвязи и полдесятка не наберется. Нужно поторапливаться. Или строить наземные станции на достаточно большом расстоянии друг ото друга, чтобы иметь несколько надежных сеансов связи в сутки. Ну, там, за деньги строить самому или пробовать привлекать энтузиастов с других континентов, хотя зачем им это?
А тут еще доплер путается под ногами. Вы как в LoRa собираетесь компенсировать доплер, можете хотя бы в общих чертах рассказать? Я не говорю, что это невозможно - мне на самом деле интересно ваше предложение, каким бы оно, в разумных пределах, ни было. Я даже могу дать поцсказку: не компенсировать вообще, а выбирать более широкие варианты модуляции. Но правда вместе с этим падает минимально приемлемый SNR, а значит нужно наращивать EIRP. И снова не невозможно, но вытягивая одно, топим другое, и так по кругу.
Вот что на самом деле невозможно, так это запилить свой первый спутник с нуля, и не наступить на стопицот граблей, по которым уже топтались сначала трех-четырехбуквенные конторы, потом очень крупный бизнес, и еще позже бизнес помельче вперемешку с хорошо подготовленными энтузиастами, получившими необходимое финансирование. Второй тоже необязательно получится беспроблемным, потому что ошибки первого учли, зато сделали кучу новых - не от глупости, а от недостатка образования, которое невозможно получить иначе чем через чужой или свой опыт. Чужой опыт тут малодоступен, ни госконторы, ни крупный бизнес, секретами делиться не спешат. Что-то можно узнать у строителей помельче, но и они не всезнайки. Вот и получается, что когда идет разбор полетов, ошибки кажутся глупыми и очевидными. Но на этапе проектирования они таковыми казались не только лишь всем - наоборот, опыт проектирования наземного оборудования мог сыграть злую шутку, ведь наземное оборудование либо можно починить, либо заменить новым. Спутник - только заменить новым, но это несколько затратно и почти всегда очень долго.
3263927
20.08.2026 08:36очень круто! а напишите пожалуйста про наземные антенны и как это всё работает
teecat
20.08.2026 08:36Поддерживаю. Это какие-то частные антенны? Используется одна антенна или там последовательно антенны с возможностью передачи объекта от одной к другой?
На МКС же куда бОльшие объемы заливают
3263927
20.08.2026 08:36да, и интересно можно ли сделать следилку которая будет сама вести спутник, может такие кагбэ отражатели и они все будут ловить немножко этого сигнала и по разнице будут понимать куда движется спутник и куда нужно наклониться чтобы смотреть прямо на него, если это такие антенны типа параболические...
можно даже немного предсказывать его траекторию, он же ровно в целом летит... хотя вроде в статье было что когда за облака задевает то тормозит...
Astroscope
20.08.2026 08:36хотя вроде в статье было что когда за облака задевает то тормозит
Да, это проблема, причем не просто тормозит, а может вильнуть в сторону.
ntsaplin Автор
20.08.2026 08:36На стороне grid используется 3 наземные станции для связи с аппаратом: одинаковые антенны только на двух, на третьей другие. Функции «роуминга» между двух станций пока нет, но появится. Подробнее про работу грид станций рассказывал в предыдущем посте.
eg321
20.08.2026 08:36Для связи используется сеть наземных станций GRID - gridgs.com
В составе GRID несколько станций связи и есть возможность "склеивать" сеансы между станциями и тем самым продлять сеанс связи (например, хорошо дополняют друг друга станции на близкой долготе - в Новосибирске и в Дудинке). У нас бывали сеансы и 20 минут и более (зависит от высоты КА).
Javian
20.08.2026 08:36Крутое событие, я думал что он быстро сгорел, а оказалось еще нет. Как-то не запомнилось в статье, что миссия будет длительная.
Dorbah
20.08.2026 08:36А можно сразу дать доступ к наземному, чтобы все сначала потренировались на нём, а уж потом, когда всё понятно станет - можно и космосу подключаться ?
eg321
20.08.2026 08:36Мы приносим извинения перед теми, кому не удалось получить доступ к спутнику в этот раз.
Вне зависимости от решения RuVDS повторить эксперимент, мы хотим это сделать, и постараемся учесть весь полученный опыт.
Чтобы не было недопонимания, изначально спутник для экспериментов предоставлялся As Is (мы даём аппарат на орбите с RPi и канал связи до него, всё взаимодействие и разработка остального ПО - на стороне заказчика) и ровно в таких же условиях было запущено 3 из 4 спутников для остальных заказчиков. Один аппарат мы оставили для собственных экспериментов. И в рамках этого эксперимента мы разработали “Console Gate” как более простую обёртку над всеми протоколами взаимодействия с космическим аппаратом. И, чтобы устранить несколько фактологических ошибок и непонимания как это работает, дам немного комментариев.
общаешься со спутником по SSH, оно оборачивается в Telnet и уходит на борт
На спутнике ни SSH, ни Telnet нет. Там нет сетевой подсистемы в ядре. И в радиоканале оно тоже не ходит. Об этом подробнее чуть ниже…
Сначала протокол Console Gate. ОКБ планировали реализовать его как API: подключитесь и работайте. Мы тоже так планировали. Из-за того, что запуск оказался раньше запланированного срока, оказалось, что рабочего API как готового продукта ещё нет, а есть только низкоуровневый стек протоколов. Наша задача внезапно превратилась в «дописать своё и совместно с ОКБ доработать Console Gate».
GRID даёт API и MQTT для связи с космосом. Всё очень просто и тривиально - MQTT для реалтайм соединения, API для работы с сессиями, кадрами, спутниками и проч. Console Gate - это та самая прослойка, которая оборачивает MQTT-пакеты в TCP/IP поток на земле. И на земле это всё ещё не Telnet и не SSH. Это Raw TCP/IP сокет. Эта прослойка писалась по собственной инициативе для ребят, чтобы упростить им жизнь и как раз не погружать в протоколы, пакетирование, команды управления и проч. Благодаря этой прослойке для пользователя RPi всё сводится к “подключаешься к сокету и всё что ты отправляешь - улетает в космос, а всё что прилетает оттуда - ты принимаешь байтами обратно”. Просто до безумия, только учитывай, что радиоканал не гарантирует доставку, и у тебя по сути UDP связь. Выстраивай внутри такой протокол, который будет убеждаться в доставке, и получать подтверждения. Будь готов к тому, что ты повторишь пакет, а аппарат услышит его второй раз. В общем так, будто бы работаешь по UDP. И не забываем про идемпотентность.
Он там проходит, условно говоря, окнами по 10 минут — навелись, он вошёл в узкий луч, сначала много помех, потом нормально, потом снова много помех, потом он выходит из луча. Чтобы поймать ещё раз, нужно наводиться заново, и, возможно, уже через часы или дни в зависимости от ситуации.
Связь со спутником изнутри выглядит совсем не так. Для каждого аппарата GRID рассчитывает баллистику и вектора наведения антенны. Антенна постоянно “следит” за аппаратом и направляется на него. Как только аппарат вылетает из-за горизонта и появляется в зоне прямой видимости - GRID уже начинает “вести” аппарат. При низком возвышении имеем самую большую дальность до аппарата (тысячи километров) и, соответственно, максимальные потери радиосигнала. Чем ближе аппарат - тем лучше сигнал/шум и качество связи. “Узкий луч” антенны постоянно трэкает аппарат, пока он пролетает над станцией.
SSH заканчивается на Земле, на стороне грида, дальше команда оборачивается в Telnet и уходит на борт. Большими ключами над горизонтом никто не обменивается.
Идеология GRID - не вмешиваться в данные. GRID - это мост из одной среды данных (радиоэфир) в другую среду (MQTT).
Console Gate в свою очередь прослойка между протоколами (MQTT в TCP-сокет). И даже он не оперирует протоколом Telnet и тем более SSH. Оно и не нужно - на аппарате ведь данные мы берём из последовательного порта RPi, и TCP-сокет хорошо подходит для работы на земле.
И килобит в секунду — это про радио. То, что видит наш софт, совсем другое: поверх радио сидит MQTT грида со своими контрольными суммами, поверх него наша обвязка, и всё это по очереди, туда-сюда. Очень много уходит на повторы и контроль ошибок при помехах.
Нет, в радио MQTT и не пахнет. В радио есть своя обвязка, но очень экономичная - уже затрагивал в другой статье, Cubsat Space Protocol. Небольшой оверхед при инкапсуляции в радиоканал есть, но он очень небольшой (6 байт заголовок, 4 байта контроль целостности пакета и т.д.). Разработчики понимают возможности радиолинии (командная линия около 1 кбита/с), и стараются использовать её максимально эффективно - ценят каждый переданный байт.
Ну, для начала rm -rf /home/pi/tmp/cache может стать rm -rf /home/pi. Привет. Какой-нибудь chmod -R 755 /var/www/site может стать chmod -R 755. Ладно, это не так страшно. А shutdown -c, ставший shutdown, — уже не так весело. kill 12345 может приехать как kill 123.
Выше я уже писал про идемпотентность. Когда не понимаешь особенности линии связи и не учитываешь, что ты работаешь в UDP канале, то такое, конечно, может удивлять. А наши разработчики когда работали с Трисатами придерживались простых правил:
Генерировать исходящие данные так, чтобы они входили по длине в один пакет (255 байт). Ибо пакет - это простая неделимая сущность в радиосвязи. Он либо принят, либо нет.
Убеждаться в том, что твоя команда в пакете была принята и обработана. То есть повторять команду, пока не получишь ответ.
Реализовывать команды так, чтобы они были идемпотентны - то есть при повторном выполнении команды результат должен быть тот же. Эти 3 правила всё упрощают и делают работу значительно надёжнее, даже в таком непростом канале как радиосвязь. Мы обновили прошивку на аппаратах более 7 раз. Выкачали фотографии в достаточно неплохо качестве (они были в статьях и на превьюшках). Суммарно прогрузили десятки мегабайт данных даже по такой не быстрой линии.
Ад в канале выглядел так: набираете стандартную команду ls -la. Отобразить каталог. До спутника могло долететь ls. Могло долететь только -la. Могло не долететь ничего. Назад мог пойти список каталога и зависнуть на середине. Мог прилететь кусок: только концовка, потому что пакет с началом куда-то делся. Или начало и конец без середины.
3 правила выше. 3 правила и никакого ада не было бы.
В первую очередь из-за несоблюдения очерёдности пакетов.
Пакеты в GRID всегда приходят в том порядке как были получены. Пакеты могут не приниматься, но ни в коем случае не перепутаться. Ядро GRID основано на одном из популярных брокеров сообщений. GRID сам не маршрутизирует данные и не вмешивается в них.
Ответ, если что, простой: оверхед не наш. Наш протокол сидит слишком высоко. Под ним грид гоняет данные по MQTT и считает свои контрольки, под MQTT — радио. Где именно по дороге что-то теряется, мы так до конца и не поняли, но эффект вы уже видели выше.
Если убрать эмоции, то обмен с Трисатами устроен совсем не так. Полное непонимание где какие протоколы. MQTT в радио конечно же нет. При озвученном уровне понимания сложно выстроить надёжную и эффективную связь.
Дальше скрипт ждёт, когда загрузится Linux и появится приглашение логина. Приглашения нет — отправляем Enter. Ждём. Опять нет — ещё Enter, примерно раз в три-пять секунд, по совету коллег. В хорошем случае приходит login:, мы пишем имя пользователя, борт в лучшем случае спрашивает пароль, мы вводим пароль и ждём входа.
Идемпотентность. И 3 простых правила выше. Задача уровня студента, имхо.
Скачивает всё это File Downloader, скрипт со стороны грида, который тянет файл по байтам в хранилище.
GRID ничего никуда сам не тянет. Отправляет пакет с одной стороны, в другую. File downloader - это изобретение не ОКБ.
Ну и пришлось искать, как рассчитывать TLE самим: экстраполировать, подбирать баллистические модели, с полным геморроем.
Команде GRID и моим коллегам из ОКБ5 пришлось освоить много новых навыков и умений: и триангуляцию, и допплерометрию, и различные баллистические модели. Очень круто, когда ты не имея на борту объективных средств геолокации, можешь “вслепую” определить его местоположение и просчитать орбитальные параметры. Ребята из RuVDS хоть за нас и болели, но в этом помочь не смогли. И здорово, что они понимают сложности этого процесса.
Когда с NORAD более-менее разобрались и начали тестироваться, оказалось, что спутники уже стремительно сходят с орбиты и жить им осталось недели две.
К сожалению, технический образец на Земле не был использован в полной мере. Да.
Дублёров у нас было два, с той же прошивкой.
Очень здорово, что мои коллеги из ОКБ5 нашли возможность и согласились отложить все свои эксперименты и выделить другой (свой) аппарат, чтобы RuVDS и пользователи успели хоть как-то воспользоваться этой возможностью и прикоснуться к космосу. Изначально под эксперименты RuVDS предназначался один аппарат.
В любом случае, я считаю это очень классным экспериментом. Без коллег из RuVDS врядли бы мы решили запустить RPi в космос, тем более на таком маленьком аппарате. За время разработки проекта пришлось решить не мало интересных задач. И судя, по комментариям, многим даже в таком виде результат понравился. Уверен, в следующий раз всё выйдет ещё лучше.
RuVDS спасибо Вам за такие смелые начинания.
randomsimplenumber
20.08.2026 08:36Параллельная разработка двумя командами — вещь такая.
У всех так. Коммуникацию между командами не практикуете?
valdemar-const
20.08.2026 08:36Эх, а я когда-то читал в контексте области применения языка common lisp, что на нем реализовывали софт космических аппаратов (несколько разных миссий в разные года) и могли патчить прошивку прямо во время выполнения. А тут даже данными обменятья уже за счастье. А они там прямо REPL использовали.
mshonich
20.08.2026 08:36мне показалось, или общение со спутником очень напоминает общение с ботом из ботнета?)) тоже агрессивная среда, в любой момент можно потерять любой пакет с данными, или всего клиента, жесткие требования к ПО по зависимостям, памяти и процессору ... ) вся разница, что в ботнете их несколько миллионов, а спутник - один)
aabzel
20.08.2026 08:36“Ну и пришлось искать, как рассчитывать TLE самим: экстраполировать, подбирать баллистические модели, с полным геморроем. Видимо, военное время, американцы решили не делиться. Почему именно так и почему сейчас — непонятно. ОКБ написали американским военным. Те вежливо ответили: «Спасибо за ваш запрос, мы займёмся вашей проблемой». И, естественно, ничем не занялись. Тогда ОКБ срочно подключили МГУ, где есть подразделение, которое занимается космическими исследованиями и у которого своя методика движения небесных тел. Привет мехмату, кстати! По их модели стали вручную пересчитывать и корректировать те данные, что есть в TLE. Сделали несколько пробных замеров, вроде получается.”
Если бы Ваш спутник посылал радио-тон, то его можно было бы обнаружить и вычислить орбиту по частоте доплеровского смещения тона.
https://habr.com/ru/articles/813461/
aabzel
20.08.2026 08:36И килобит в секунду — это про радио. То, что видит наш софт, совсем другое: поверх радио сидит MQTT грида со своими контрольными суммами, поверх него наша обвязка, и всё это по очереди, туда-сюда. Очень много уходит на повторы и контроль ошибок при помехах. В итоге лучшее, что мы получали в космосе, — около 45 байт протокола верхнего уровня (то есть значимых) в секунду. Сорок пять байт! В секунду!
Не рассматривали отечественные 200 Mbit/s Downlink трансиверы?
High-speed X-band Downlink Transmitter 200 Msymb/s
https://www.sait-ltd.com/_files/ugd/3473d8_0f49fffb76a84281b98a79d0085088d4.pdf?index=true
vanxant
20.08.2026 08:36Этот трансивер кушоит 70 ватт. У них на борту в среднем два ватта на всё. Они весь виток заряжают аккумы, чтобы малинка отработала 10 минут окна связи...
Tropolinarius
20.08.2026 08:36А почему, всё же, не использовали LoRa? И готовая сеть https://tinygs.com/ уже есть, и отечественые аппараты там мелькают.
eg321
20.08.2026 08:36На Трисатах как раз Лора. И все они есть на tinygs. Мы дружим с этой сетью, и более того - она появилась благодаря одному из наших первых аппаратов с Лорой (Норби).
mazdayka
20.08.2026 08:36не уж то ssh не имеет контрольных сумм и может прилететь обрезанная команда...
U235U235
20.08.2026 08:36Поиграться можно будет, но фотографировать он будет стену.
Можно украсить стену плакатом. Например, плакат с Великим А'Туином из книг Т. Пратчетта, будет хорошо смотреться.
Akon32
20.08.2026 08:36Выглядит как хождение по граблям - какие-то действия, протоколы, без понимания их области применимости... Здесь https://habr.com/ru/companies/ruvds/articles/1072342/#comment_30350326 прямо хорошо написано. Однако "не ошибается тот, кто ничего не делает", все равно это опыт.
chebo
Если бы не 2026 год, когда я это читаю, я бы подумал, что это все происходит в 90-е…
unclejocker
Скорее 60е. Похоже на чтение мемуаров первопроходцев космонавтики. В принципе разработчики кубсатов сейчас повторно решают схожие задачи.
ntsaplin Автор
Посидеть на Хабре в 90-е — звучит как мечта...
kkuznetzov
Газета Хабр.
RezonanS1
Не хочу ничего сказать плохого, статью интересно было почитать, но в целом сложилось такое впечатление: не проф. подход к проектированию, больше похоже на какой-то DIY, радиолюбительство, где проектирование идет левой пяткой в свободное время и на и так сойдет. Многие проблемы описанные автором в принципе очевидны, но по непонятным причинам на них не обращали внимание... а потом оказалось..., что не работает...
Calculater
Утрата компетенций в отрасли и потеря промежуточного поколения, вот и результат. Почти все пенсионеры с опытом уже на том свете, элементарно мало кого можно нанять в консультанты по конкретным вопросам, отсюда приходится изобретать велосипеды.
mshonich
не такие уж и пенсионеры, mqtt всего то лет тридцать
zapparello2
это и есть радиолюбительство. Государство решило дать доступ к запускам всем желающим ну хоть как-то компетеньным организациям. Вот теперь каждый проходит свой путь, кто с нуля, кто пользуется чьими-то наработками, но серьёзные профильные организации наработки не раздают, да и кубсатов раньше не делали. Так что фактически разрабатываются миниатюрные космические платформы с нуля.