Можно и с нулем, но это не сократит число необходимых спутников.
Собственно, если при старте приемника недоступна сотовая сеть, а его RTC по какой-то причине на работают (батарейка села), то он и стартует с нуля. В нашем приемнике таким нулем выступает 1 января 1970 года.
Ноль - это частный случай плохих часов. Часы, которые встали. В этом случае поправка, которая будет получена в результате решения навигационной задачи, составит 52 года.
Конечно. И в виде части сотового телефона, и в виде отдельных модулей. Изделия разработки моей команды так вообще закрывают все диапазоны и все системы, отсюда и вся боль этой статьи
В этой задержке, собственно, и находится полезная информация. Для каждой точки пространства характерно своё сочетание задержек сигналов разных спутников.
Уход собственных часов дает одинаковый вклад во все наблюдаемые задержки, как подставка. Эта подставка оценивается наравне с координатами приемника. Она выступает четвертой неизвестной в системе уравнений. По этой причине для первого определения нужны наблюдения хотя бы от четырех спутников.
Ключи индивидуальные для каждого приемника, они хранятся в аппаратном SAASM блоке. Даже если его расковырять, ключ скоро сменится и старый станет бесполезным.
Ключи распространяются только среди специальных потребителей, да и спецификация открыта лишь частично.
Есть приемы, позволяющие принимать эти сигналы без ключа, но с существенной потерей в отношении сигнал/шум. Несколько десятелетий назад сигналов и спутников было мало, это было актуально. Реализация встречается в старых геодезических приемниках
Тут два варианта: 1. Обеспечить формирование одних и тех же последовательностей как на борту спутника, так и в приемнике. Для этого ключ передавать по отдельным каналам (сигналы санкционированного доступа). 2. Накладывать случайные последовательности так, чтобы они не исключали прием сигнала отдельными кусочками (codeless режим для сигналов санкционированного доступа, цифровая подпись для сигналов гражданских).
Тема широкая, но я подумаю. Как мининимум, потребуется разбить на статьи о разных системах, а может и отдально писать про спутники, отдельно про наземный сегмент, отдельно про приемники.
"Военные" сигналы GPS - это сигналы с P(Y) (L1P, L2P в таблице) и M (L1M, L2M в таблице) кодом. У них в 10-20 раз шире полоса, чем у соседних гражданских сигналов. Это позволяет существенно снизить ошибку многолучевости и шумовую ошибку, но все остальные источники ошибок никуда не уходят. Поэтому при прочих равных можно говорить об увеличении точности позиционирования раза в два.
Прелесть M и P сигналов в другом: 1. Их дальномерный код является, по-сути, хэшем от текущего времени. Ключики периодически меняют, сломать их тяжело. Это защитает от спуфинга и ретрансляционных помех. 2. Широкая полоса увеличивает на порядок помехоустойчивость, что в разы сокращает радиус действия помехопостановщика 3. У M сигнала есть режим spot beam, когда его мощность поднимается на два порядка на ограниченной территории
На живом приемнике тестов пока не так много: выдача наблюдений по заданному типу сигналов, выдача навигационных данных по заданному типу сигналов, наличие решения по заданному типу сигналов. Это высокоуровневые требования, уровня ТЗ.
Технически все есть, чтобы опускаться глубже. Пропускной способности интерфейса хватает, чтобы забирать данные с систем слежения с темпом 1 мс. Но число проверок начнет расти как снежный ком, да и руки пока не дошли.
Думаю, правильным было бы ввести статистические метрики и для начала построить дашборд с ними. То есть не просто проверять, что TTFF решения укладывается в 60 секунд, а смотреть его динамику от коммита к коммиту. Или скорость разрешения неоднозначности на нульбазе. Или среднее время обработки прерываний. Или число каналов, что вмещаются в ПЛИС. Если в софте действительно появляется какая-то проблема, то она проявится на таких характеристиках. А если она не наблюдаема, то она второстепенна. Мысли у меня об этом крутятся, но построение дашбордов в нашей системе пока не реализовано.
Конкретно эта плата у нас с 17 года, себя уже точно отбила. Да и главная её роль - отработка технических решений, софта и т.д., а далее эти же модули переносятся в СБИС, если проект того стоит.
А теперь главный вопрос: как собрать 30-60 выпускников MIT с опытом 10-15 лет, способных работать самостоятельно, в одну компанию на линейные должности? Почему они при таком бэкграунде всё ещё не лиды, CTO, consulting engineer'ы? Не могут же таких людей мотивировать только деньги, должно быть что-то ещё.
Они выращиваются в компаниях второго эшелона и рассматривают возможность поработать в таком коллективе как промежуточный шаг? Или это MIT и привлекательность США так фильтрует кандидатов? Может это нежелание заниматься менеджерской рутиной и любовь к своему делу? Или возможность прикоснуться к большому проекту и увидеть результат своего труда во всех магазинах?
Если проецировать на мою индустрию, спутниковую навигацию, то на всю Россию людей подобных качеств примерно столько, сколько у вас в одной описываемой команде. Обычно это лиды отдельных коллективов, на которых держатся целые компании или отделы. В коллективы очень редко кто-то приходит с улицы на полноценные рабочие позиции, чаще это выращивание людей со студенчества с постепенным расширением зоны ответственности.
Там в статье есть кат с описанием первых трех вариантов. И даже ностальгические скриншоты. Желание автоматизировать проверки было всегда, т.к. железо/софт сложные и все время стремятся разложиться. Стоит что-то оставить без присмотра - оно обязательно протухнет.
Первые попытки не достигли устойчивого использования, но создали нужные наработки: - покрытие юнит-тестами - библиотеки для настройки приборов и получения с них данных - симуляционное окружение для прошивки - понимаю узких мест, того, что чаще ломается и что не дает системе прижиться
Пандемия резко обострила потребность в системе автотестирования. Мы стали часто работать удаленно, а надо как-то проверять Merge Request'ы перед вливанием в основную ветку.
Зимний сноубордический сезон 2020/2021 свел меня с синьор-помидор-qa-автоматизатором из Яндекса. Так новогодними вечерами под глинтвейн я подтянул знания о Jenkins, worker'ах и современных системах для решения подобных проблем.
В феврале 2021 мы взяли под разработку автотестов бойкую девушку, мою бывшую студентку. Я включал воображение и проектировал в голове будущую систему, она пыталась это натянуть на Gitlab CI/CD. Судя по git blame, 30 марта 2021 года у нас в основном репозитории программного комплекса появился первый gitlab-ci.yaml. Через некоторое время ей в подаваны взяли ещё 2 человек (ребята ещё студенты-третьекурсники, но толковые).
Новая система прижилась, без неё уже не представляю разработку. В новых проектах, даже если там нет задач по написанию прошивок, первым делом заводим CI.
Дивный новый мир. В российских реалиях для встраиваемого ПО наша команда средняя или даже выше среднего по численности. При этом почти всегда идут несколько проектов параллельно, поэтому эффективная численность снижается. И я говорю не только про госкорпорации, но и про местные r&d центры иностранных компаний. Описываемая вами картина с трудом натягивается у нас даже на Яндекс или Сбер в части веба и корпоративных сервисов, не то что эмбэд. Могу предположить, что ваш опыт касается больших корпораций вроде Broadcom, Qualcomm, Intel, Infineon, Apple и т.д. Там мне пока не приходилось работать.
А вот эти senior/principal, составляющие основную массу разработчиков встаиваемого ПО, какой у них бэкграунд? Это MSc/PhD из EE или MSc CS? Они в курсе предметной области или их дело перевести спецификацию в код? Как именно работает система знает только consulting engineer? Насколько глубоко тогда consulting engineer и лиды расписывают спецификации? В духе "нам нужно дополнить систему таким-то режимом, вон описание от IEEE, действуй" или "нужно разработать функцию с именем x, входные и выходные интерфейсы y, тестовые сценарии такие-то, ограничения на память такие-то и т.д."?
В описываемую группу входят разработчики логических модулей (кремния или плис)? Или вы готовите ПО уже под готовый кристалл?
А как PM успевает расписать задачи на 30-60 человек? Или они, разработчики, настолько универсальные бойцы, что могут брать любую задачу из бэклога и начинать работать? Мне последнее тяжело представить в радиотехнике. Когда я пишу issue, я представляю 1-3 человек, кто за неё может взяться. Исходя из прошлого опыта, уровня навыков и текущей загруженности.
Почему бы их не разбить на группы человек по 8-12 и развести по разным подпроектам?
Можно и с нулем, но это не сократит число необходимых спутников.
Собственно, если при старте приемника недоступна сотовая сеть, а его RTC по какой-то причине на работают (батарейка села), то он и стартует с нуля. В нашем приемнике таким нулем выступает 1 января 1970 года.
Ноль - это частный случай плохих часов. Часы, которые встали. В этом случае поправка, которая будет получена в результате решения навигационной задачи, составит 52 года.
Сейчас одновременно работают спутники и второй фазы, и третьей. Со временем отключат аппараты второй фазы и переведут в резерв.
Конечно. И в виде части сотового телефона, и в виде отдельных модулей. Изделия разработки моей команды так вообще закрывают все диапазоны и все системы, отсюда и вся боль этой статьи
В этой задержке, собственно, и находится полезная информация. Для каждой точки пространства характерно своё сочетание задержек сигналов разных спутников.
Уход собственных часов дает одинаковый вклад во все наблюдаемые задержки, как подставка. Эта подставка оценивается наравне с координатами приемника. Она выступает четвертой неизвестной в системе уравнений. По этой причине для первого определения нужны наблюдения хотя бы от четырех спутников.
Ключи индивидуальные для каждого приемника, они хранятся в аппаратном SAASM блоке. Даже если его расковырять, ключ скоро сменится и старый станет бесполезным.
И таймлайн развития приемников неплохо, я надеюсь, отражают две вот эти статьи:
https://habr.com/en/post/664110/
https://habr.com/en/post/664132/
Ключи распространяются только среди специальных потребителей, да и спецификация открыта лишь частично.
Есть приемы, позволяющие принимать эти сигналы без ключа, но с существенной потерей в отношении сигнал/шум. Несколько десятелетий назад сигналов и спутников было мало, это было актуально. Реализация встречается в старых геодезических приемниках
Тут два варианта:
1. Обеспечить формирование одних и тех же последовательностей как на борту спутника, так и в приемнике. Для этого ключ передавать по отдельным каналам (сигналы санкционированного доступа).
2. Накладывать случайные последовательности так, чтобы они не исключали прием сигнала отдельными кусочками (codeless режим для сигналов санкционированного доступа, цифровая подпись для сигналов гражданских).
Тема широкая, но я подумаю. Как мининимум, потребуется разбить на статьи о разных системах, а может и отдально писать про спутники, отдельно про наземный сегмент, отдельно про приемники.
"Военные" сигналы GPS - это сигналы с P(Y) (L1P, L2P в таблице) и M (L1M, L2M в таблице) кодом. У них в 10-20 раз шире полоса, чем у соседних гражданских сигналов. Это позволяет существенно снизить ошибку многолучевости и шумовую ошибку, но все остальные источники ошибок никуда не уходят. Поэтому при прочих равных можно говорить об увеличении точности позиционирования раза в два.
Прелесть M и P сигналов в другом:
1. Их дальномерный код является, по-сути, хэшем от текущего времени. Ключики периодически меняют, сломать их тяжело. Это защитает от спуфинга и ретрансляционных помех.
2. Широкая полоса увеличивает на порядок помехоустойчивость, что в разы сокращает радиус действия помехопостановщика
3. У M сигнала есть режим spot beam, когда его мощность поднимается на два порядка на ограниченной территории
На живом приемнике тестов пока не так много: выдача наблюдений по заданному типу сигналов, выдача навигационных данных по заданному типу сигналов, наличие решения по заданному типу сигналов. Это высокоуровневые требования, уровня ТЗ.
Технически все есть, чтобы опускаться глубже. Пропускной способности интерфейса хватает, чтобы забирать данные с систем слежения с темпом 1 мс. Но число проверок начнет расти как снежный ком, да и руки пока не дошли.
Думаю, правильным было бы ввести статистические метрики и для начала построить дашборд с ними. То есть не просто проверять, что TTFF решения укладывается в 60 секунд, а смотреть его динамику от коммита к коммиту. Или скорость разрешения неоднозначности на нульбазе. Или среднее время обработки прерываний. Или число каналов, что вмещаются в ПЛИС. Если в софте действительно появляется какая-то проблема, то она проявится на таких характеристиках. А если она не наблюдаема, то она второстепенна. Мысли у меня об этом крутятся, но построение дашбордов в нашей системе пока не реализовано.
Конкретно эта плата у нас с 17 года, себя уже точно отбила. Да и главная её роль - отработка технических решений, софта и т.д., а далее эти же модули переносятся в СБИС, если проект того стоит.
Почему же не стали, варится, компилируется и шьется. Но при текущем подходе тяжело окирпичить устройство прошивкой
Если честно, чаще проблемы с сетью, чем запоротая прошивка. Но совсем на крайний случай, в лабе каждый день кто-нибудь есть, восстановит
А теперь главный вопрос: как собрать 30-60 выпускников MIT с опытом 10-15 лет, способных работать самостоятельно, в одну компанию на линейные должности? Почему они при таком бэкграунде всё ещё не лиды, CTO, consulting engineer'ы? Не могут же таких людей мотивировать только деньги, должно быть что-то ещё.
Они выращиваются в компаниях второго эшелона и рассматривают возможность поработать в таком коллективе как промежуточный шаг? Или это MIT и привлекательность США так фильтрует кандидатов? Может это нежелание заниматься менеджерской рутиной и любовь к своему делу? Или возможность прикоснуться к большому проекту и увидеть результат своего труда во всех магазинах?
Если проецировать на мою индустрию, спутниковую навигацию, то на всю Россию людей подобных качеств примерно столько, сколько у вас в одной описываемой команде. Обычно это лиды отдельных коллективов, на которых держатся целые компании или отделы. В коллективы очень редко кто-то приходит с улицы на полноценные рабочие позиции, чаще это выращивание людей со студенчества с постепенным расширением зоны ответственности.
Там в статье есть кат с описанием первых трех вариантов. И даже ностальгические скриншоты. Желание автоматизировать проверки было всегда, т.к. железо/софт сложные и все время стремятся разложиться. Стоит что-то оставить без присмотра - оно обязательно протухнет.
Первые попытки не достигли устойчивого использования, но создали нужные наработки:
- покрытие юнит-тестами
- библиотеки для настройки приборов и получения с них данных
- симуляционное окружение для прошивки
- понимаю узких мест, того, что чаще ломается и что не дает системе прижиться
Пандемия резко обострила потребность в системе автотестирования. Мы стали часто работать удаленно, а надо как-то проверять Merge Request'ы перед вливанием в основную ветку.
Зимний сноубордический сезон 2020/2021 свел меня с синьор-помидор-qa-автоматизатором из Яндекса. Так новогодними вечерами под глинтвейн я подтянул знания о Jenkins, worker'ах и современных системах для решения подобных проблем.
В феврале 2021 мы взяли под разработку автотестов бойкую девушку, мою бывшую студентку. Я включал воображение и проектировал в голове будущую систему, она пыталась это натянуть на Gitlab CI/CD. Судя по git blame, 30 марта 2021 года у нас в основном репозитории программного комплекса появился первый gitlab-ci.yaml. Через некоторое время ей в подаваны взяли ещё 2 человек (ребята ещё студенты-третьекурсники, но толковые).
Новая система прижилась, без неё уже не представляю разработку. В новых проектах, даже если там нет задач по написанию прошивок, первым делом заводим CI.
Дивный новый мир. В российских реалиях для встраиваемого ПО наша команда средняя или даже выше среднего по численности. При этом почти всегда идут несколько проектов параллельно, поэтому эффективная численность снижается. И я говорю не только про госкорпорации, но и про местные r&d центры иностранных компаний. Описываемая вами картина с трудом натягивается у нас даже на Яндекс или Сбер в части веба и корпоративных сервисов, не то что эмбэд. Могу предположить, что ваш опыт касается больших корпораций вроде Broadcom, Qualcomm, Intel, Infineon, Apple и т.д. Там мне пока не приходилось работать.
А вот эти senior/principal, составляющие основную массу разработчиков встаиваемого ПО, какой у них бэкграунд? Это MSc/PhD из EE или MSc CS? Они в курсе предметной области или их дело перевести спецификацию в код? Как именно работает система знает только consulting engineer? Насколько глубоко тогда consulting engineer и лиды расписывают спецификации? В духе "нам нужно дополнить систему таким-то режимом, вон описание от IEEE, действуй" или "нужно разработать функцию с именем x, входные и выходные интерфейсы y, тестовые сценарии такие-то, ограничения на память такие-то и т.д."?
В описываемую группу входят разработчики логических модулей (кремния или плис)? Или вы готовите ПО уже под готовый кристалл?
Спасибо! Изучал вашу статью, когда переносили проект на КПДА
Удалено
А как PM успевает расписать задачи на 30-60 человек? Или они, разработчики, настолько универсальные бойцы, что могут брать любую задачу из бэклога и начинать работать? Мне последнее тяжело представить в радиотехнике. Когда я пишу issue, я представляю 1-3 человек, кто за неё может взяться. Исходя из прошлого опыта, уровня навыков и текущей загруженности.
Почему бы их не разбить на группы человек по 8-12 и развести по разным подпроектам?