Все комментарии викилогов

Поправил в тексте.

Вот она национальная идея - в Америке бардак ещё больше, чем у нас)

"... на несущей частоте 1575,42 МГц, в то время, как верняя частота 
диапазона LightSquared равна 1559 МГц, т.е. на 26 МГц ниже."

Я долго тупил, а потом посчитал на калькуляторе: 1575,42-1559=16,42

Да, и зазор между ближайшим нулём М-кода ВОС(10,5) и частотой 1559 МГц у меня получился всего 1,075 МГц. Скаты ПАВ-фильров обычно шире, а ничего более избирательного пока не придумали. В общем, М-сигнал должен пострадать. Однако есть смутные сомнения, что всё-таки не пострадает. Будем с интересом следить за ходом событий!

Подпись шефа устроим.

Я собирался так сделать. Единственное, шефа в четверг не будет, поэтому такой вариант всё равно сдать не получится. Хотелось бы протолкнуть всё-таки с буквой . А там видно будет.

Напечатал бы ты сразу резервный комплект для BOC(pi, e). Вероятность того, что он пригодится - 90%

Идея понятна, нужно пробовать и разбираться.

Приемник любой можно. Основная головная боль - как сообщить соответствующему демону метку времени с минимальной задержкой. Хотя и тут уже есть стандартные решения - она висит на одной из ног RS232, которая по прерываниям (таймеру) обрабатывается.

Это два колеса с 650 кубиками ;)

Да, у меня была такая идея. У меня время в компьютере настраивалось по NTP, приходилось использовать сервер из какого-то американского университета. Как фишку, это можно. Только непонятно, на каком оборудовании. Тут приёмник соответствующий нужен, наверное.

154 км/ч - забавно...

А вот это не подойдёт? http://stackoverflow.com/questions/939119/how-do-i-restrict-repository-access-via-websvn Там ведь указыватся путь к хранилищу SVN и файл с паролями. Может быть, сделать такие конфиги отдельные для каждого проекта?

Примерно так:

<Location /svn1>

...

AuthUserFile "/svn1/secret"

</Location>

<Location /svn2>

...

AuthUserFile "/svn2/secret"

</Location>

А можно ли, допустим, запустить два WebSVN с разными паролями? Или при таком подходе вообще два Апача понадобиться?

На WebSVN пароль реализован средствами Апача. Он просто не дает запустить сам WebSVN. Пока не вижу пути, как запаролить в WebSVN отдельные проекты.

Надо им раздать пароли - только индивидуальные! И не на все проекты.

Так для снарядов навигаторы тоже не очень нужны.

Да, по всем признакам проверять методику надо. Как раз потому, что они получили величину больше скорости света. Как признак того, что они ошиблись. Т.е. правильнее говорить не о проверке скорости нейтрино с помощью ГНСС, а о проверке приёмника ГНСС на основе известной скорости ;)

У меня друг как раз неделю назад купил себе маршрутку (Ford Transit). Сегодня я его сильно обрадовал)

Эта мера в народе популярности не найдет. Остается только надеяться, что от неё будет толк в гипотетическое военное время - снаряды на фронт привозить.

Тут небольшая проблема - у студентов нет доступа к WebSVN

Нет дыма без огня... Я хотел донести причастность ГНСС к этому эксперименту.

Уверен на 99%, что так и будет)

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

Только, как я понимаю, в постановлении не сказано, зачем это нужно. Нет, сказано, что для повышения безопасности и т.п., но не сказано, как это связано с безопасностью. А так и получается, что просто все маршрутки "разуют" на покупку навигатора, который при движении по постоянному маршруту им решительно не нужен. Вот в результате все и будут ставить "скотчевые" ГЛОНАСС-навигаторы.

Для чего на самом деле может быть нужно? Только если будет вводится система отслеживания положения из диспетчерского центра. Но к маршруткам это отношения не имеет. И в постановлении об этом ничего не сказано.

Короче говоря, "получилось, как всегда"...

Что до нас (как разработчиков НАПов), не уверен, что на этом можно обогатиться. Боюсь другого - добьются они того, что нам будет людям стыдно говорить, что мы занимаемся разработкой устройств ГЛОНАСС.

Жаль только, журналисты всё перепутали и в тексте статьи смысловые ошибки.

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

Женя с шефом участвовали в совещании, теперь должны знать ответ на этот вопрос.

Зачем нужен переходник с волновода на N? Разве в приемнике вход не волноводный?

Да нет, Андрей недавно подходил.

Чудеса))) В понедельник привезли? Или ты вчера в центре был?

С L3 - запамятовал. Остается L1CR)

1) Илья, в L3 BPSK(10)

2) Да! Spirent уже у нас в комнате, у него даже инвентарный номер есть.

1) "Да всё из-за этого BOC(1, 1). Пока кроме Galileo никто его не излучает. "
А как же летающий Глонасс-К? Там же вроде как есть L1CR и L3CR?

2) Куда прибыл Spirent? oO

У нас аналогичная ситуация. Есть запись только по первому варианту акта:
Акт передан на подпись госзаказчику 04.08.2011

№ 1 от 01.01.1970

Зато в замечаниях:
Необходимо срочно прислать акты с новым названием и новой печатью вашей организации. По адресу Пролетарский проспект д.8 кор. 2
Необходимо исправить до 15.08.2011
Замечание от 08.09.2011, 15:32
Оператор: Аванесян Мария Ромиковна
Замечание исправлено

Может написать статью? Заработаем пафосную репутацию и лишнюю галочку))

С праздником!!! Давайте всю ночь кодить и дизассемблить!

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

У меня тоже все замечания снялись, но в разделе "Государственный контракт->Этапы НИР" в графе "Акт" по-прежнесу стоит что акта нет :(

При выкидыше ГОСТОв я поскупился на эмоциональные комментарии их содержимого. Исправляюсь.

1. В ГОСТах встречаются просто ВОПИЮЩИЕ ошибки. НАП, сделанная по этим ГОСТам, работать не будет никогда.

2. НИ с кем из моих знакомых разработчиков эти ГОСТы согласованы не были - вопрос: кто и для кого их писал?

Так что джентльмены, если надо заткнуть рот нормативщикам и приверженцам ГОСТов - вот хороший пример.

Отлично, ждём подписанный акт...

Сделано

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

Может быть, перенести сюда наше обсуждение по почте? А то потеряется...

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

>> Да. Время должно быть непрерывным. Поэтому, в частности, в НАВИСЕ для всех расчетов берется время GPS.

В очередной раз подтверждается тезис, что время системы должно быть непрерывным. Как разработчики ГЛОНАСС об этом не думают? Я пытался донести эту мысль до Поваляева - но ГЛОНАСС уже не исправить.

Общесистемную шкалу я предлагаю привязывать к UTC/GPS (в моментах секунд они совпадают). Шкалу времени каждого из каналов я предлагаю привязывать к времени канала. Т.е., для сигналов GPS к времени GPS данного канала - чтобы из регистров канала буквально считывалось GPS time.

Теперь по счётчику недель. Я предполагал, что шкала времени будет аппаратно реализована в каждом из каналов. Интервал времени, на котором желательно однозначно определять время, равен периоду обновления эфемерид, +-2 часа для GPS, как я помню. Поэтому я решил, что времени в пределах недели, как наиболее крупной единицы времени, хватит. Что касается переходов через номер недели - это решается легко. Текущая неделя известна. Если мы находимся на границе недель, то в счётчике секунд будет либо малое число, значит, новая неделя началась, либо большое число, немного менее 604800 с - значит в канале ещё старая неделя. Разрешить это вполне возможно. А тащить номер недели в регистры каждого из каналов мне кажется не нужным. Секуду лучше тащить. Тут всё завязано больше на возможный период пропадания сигнала. Он может быть несколько секунд, несколько минут, но никак не неделю, это бессмысленно.

Моя идея заключалась в едином представлении времени и для системы, и для каналов. Т.е. я ставил задачу как раз объединить сигнальное и системное время в едином формате, чтобы максимально легко их друг с другом сводить.

С точки зрения системы нужны секунды.

С точки зрения канала - там уже есть эпохи (специфичные для сигнала, но в секунде их целое число).

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

Да. Время должно быть непрерывным. Поэтому, в частности, в НАВИСЕ для всех расчетов берется время GPS.

1. Номер недели всё-таки нужен, чтобы правильно учитывать эфемериды на границе смены недели, и иметь возможность пользоваться старыми альманахами. Вот только ошибок GPS повторять не надо - номер недели должен быть как минимум 16-битным.

2. Представление сигнального времени в канале - это одно, а представление общесистемного времени в приемнике - это всё-таки другое. Для того, чтобы свести все системы нам абсолютно вредно думать об эпохах и чипах ПСП - нам нужны недели, секунды и время внутри секунды.

3. Посему предлагаю общесистемную шкалу времени формировать на основе времени GPS в формате недели-секунды-доли секунды.

Но дальше встает вопрос - мы будем корректировать общесистемное время в приемнике, подстраивая его под время GPS в реальном времени, или же зафиксируем некоторое абстрактное общесистемное время, а в алгоритмах везде будем тащить оценки сдвига шкал? Если грубо, то будем ли мы привязывать метку времени к GPS/UTC или нет?

Ну, собственно, разговор не об этом.