Измерение Кш у В102 прямыми методами (с шумовой головкой) дали цифру 2,2 дБ для GPS и 2 дБ для ГЛОНАСС.
Есть мнение, что формулы неверные, а измерения не точные. Например, не учтен Кш самого анализатора, который равен 24 дБ (!!!)
Считать, конечно можно. Только проще отключить 2D-решение и не считать его за решение. В СН-4706 это можно, а в u-blox разве нельзя?
Надо бы это 3D/2D обсудить с Короленко.
Оформление в процессе? "Проблемы с Глонассом" пока не полностью, похоже..
Про "карму" сильно, оценил. =)
-Короленко не спрашивали, как с ИНСом, катая в машине приемник и, соответственно, работая по реальным сигналам, измерять их уровень?
Холодный и горячий старт.. Нам нужно оговорить, что приемник стартует нахолодную, или горячие исследования тоже проводить? Ему надо оно?
Про 3D, отсутствие сбоя - хорошо. 5 повторов - тоже хорошо. По пяти повторам отсеивать выбросы? брать нижний не-выброс? Кусочек метролога, который во мне остался после Скачкова, негодует..
-"За Сбой навигационного решения считать отсутствие 3D-решения в течение 10 секунд (верхний предел горячего старта) и более. " - не понял, можно пояснить? При чем здесь предел старта?
-Поиск пять минут - значит куролесица с TTFF идет лесом? А как же требование универсальности методики?
-Военный приемник нам, я так понимаю, дадут? =)
И последнее, просьбы снять характеристики, это ведь не к Вальсету? Сроки..
1) Глонасс дописал
2) ИНС будет в статике, судя по всему
3) Горячий старт нужен: придется делать методику и ставить эксперименты
4) Про замену усреднения на наихудший вариант в итоге забыли(
5) Пять минут установлены генеральским решением
6) Военный приемник придется искать в закромах Родины
7) Сроки Вальсета остались в прежних пределах, характеристики в рамках работы
ps Надо сделать уведомление по почте о комментировании
Не думаю, что такая проверка на плагиат будет эффективна. Ведь наша задача - не получить от них правильные координаты, а проверить знания каждого. А так все они пропустят замерянные данные через одну и ту же программу, (написанную два года назад на Python) и с точки зрения цифр плагиата ни у кого не будет - измерения-то все сами делают в аудитории и под контролем.
Ответы на вопросы Ильи.
1. Вероятность 0.1 - на весь поиск, а не на одну ячейку.
2. Доплер - +-DopMax.
3. Коэффициент умножается на теоретический порог.
4. Поле поиска разбито на половину символа по задержке и 1/T по частоте.
5. На последнем графике по оси абсцисс двоичный логарифм от количества некогерентных накоплений.
А, он хитрый. Этот график демонстрирует выигрыш от некогерентного накопления для разных длительностей когерентного накопления. При малом отношении сигнал/шум на интервале когерентного накопления график начинает загибаться.
Ну, стадия 0 - это когда совсем ничего нет. Т.е., только идея. Ну, и амбиции, конечно.
Идей у нас, правда, подходящих нет пока, но идею можно придумать.
Я считаю, что если туда лезть не ради просто галочки, то лезть нужно в стадию 1, где выше требования. Иначе это просто бесполезное занятие. А насчёт требований - цель нужно ставить и соответствующие пункты закрывать. Так, по "ИТ" нужнен работающий прототип, это сделать можно.
Проблема, на самом деле, кроется в том, что проект нужен коммерческий, более того, с "существенными конкуретными преимуществами перед мировыми аналогами". Вот тут просто идеей не обойтись, нужна ИДЕЯ. Её у нас нет. Ну, и в коммерческой области никто вертеться не умеет.
PS. Списки требований очень напоминают требования к госконтактам ;) - и это не удивительно, затея примерно такая же, но с другим масштабом. В принципе, я понимаю деятелей от государства, которые это затеяли (я не в плане распила средств) - нужно толкать общество вперёд. Но увы, мне кажется, у них нет для этого методов кроме выделения денег под громкие лозунги. Можно этим, конечно, пользоваться по прямому назначению, т.е. сделать на госденьги что-то коммерчески успешное, но я пока не знаю, как.
Ты поясни, они там что, программно в ARM быстрый поиск устроить хотят?
Сразу предупреждаю, я тут прикинул, текущая реализация блока поиска в Альпаке для обеспечения требуемых характеристик будет искать, видимо, 3 часа. У тебя ресурсы существенно скромнее.
Поиск в микросхеме Шувалова должен быть намного быстрее - 320 с.
Поиск в нынешнем SiRF'е - 2.5 с, но это, скорее всего, не так.
Вот поэтому я не верю в программный поиск.
Кстати, про Альпаку, возможно, написано неверно - я тут недавно подкрутил поиск, и он стал искать в несколько раз быстрее. Надо померять. Но это всё равно будут десятки минут.
Из скидок у меня только простота сигналов - С/А и СТ.
Помнится у Саши был какой-то хитрый алгоритм поиска в программном приемнике, основанный на перемножении спектров.
Эти ограничения - десятки минут, они вызваны возможностями процессора? Или связки какой-то аппаратный поиск в ПЛИС + дополнительная обработка процессором? Как эти цифры привязать к чисто программному поиску?
Это как раз у меня был этот хитрый алгоритм, он сейчас заложен в Альпаку. Оценки выше приведены для сигнала GPS C/A, для ВТ всё будет пропорционально хуже.
Памяти 1 Мб немного, требуемый объём памяти можно разменять на время поиска.
Ограничения вызваны обработкой в процессоре. В ПЛИС можно делать быстрее, но нужна куча ресурсов, это одна из причин, по которой нужно делать новую Альпаку.
"Захват сигнала без поиска по известным эфемеридам (или альманахам), что есть в любом нормальном софте, мы даже никогда не делали, а ведь в случае наличия универсального времени это довольно просто." </br> </br>
Да. Время должно быть непрерывным. Поэтому, в частности, в НАВИСЕ
для всех расчетов берется время GPS.
1. Номер недели всё-таки нужен, чтобы правильно учитывать эфемериды на границе смены недели, и иметь возможность пользоваться старыми альманахами. Вот только ошибок GPS повторять не надо - номер недели должен быть как минимум 16-битным.
2. Представление сигнального времени в канале - это одно, а представление общесистемного времени в приемнике - это всё-таки другое. Для того, чтобы свести все системы нам абсолютно вредно думать об эпохах и чипах ПСП - нам нужны недели, секунды и время внутри секунды.
3. Посему предлагаю общесистемную шкалу времени формировать на основе времени GPS в формате недели-секунды-доли секунды.
Но дальше встает вопрос - мы будем корректировать общесистемное время в приемнике, подстраивая его под время GPS в реальном времени, или же зафиксируем некоторое абстрактное общесистемное время, а в алгоритмах везде будем тащить оценки сдвига шкал? Если грубо, то будем ли мы привязывать метку времени к GPS/UTC или нет?
Моя идея заключалась в едином представлении времени и для системы, и для каналов. Т.е. я ставил задачу как раз объединить сигнальное и системное время в едином формате, чтобы максимально легко их друг с другом сводить.
С точки зрения системы нужны секунды.
С точки зрения канала - там уже есть эпохи (специфичные для сигнала, но в секунде их целое число).
Вот чтобы всё это соединить вместе, я и написал данный материал.
Почему не совсем время GPS? Всё, что выше секунды - полностью совместимо с временем GPS. Так что можно считать, что это время GPS. Всё, что ниже секунды (эпохи и чипы) - специфично для сигнала. Секунда - точка объединения.
Теперь по счётчику недель. Я предполагал, что шкала времени будет аппаратно реализована в каждом из каналов. Интервал времени, на котором желательно однозначно определять время, равен периоду обновления эфемерид, +-2 часа для GPS, как я помню. Поэтому я решил, что времени в пределах недели, как наиболее крупной единицы времени, хватит. Что касается переходов через номер недели - это решается легко. Текущая неделя известна. Если мы находимся на границе недель, то в счётчике секунд будет либо малое число, значит, новая неделя началась, либо большое число, немного менее 604800 с - значит в канале ещё старая неделя. Разрешить это вполне возможно. А тащить номер недели в регистры каждого из каналов мне кажется не нужным. Секуду лучше тащить. Тут всё завязано больше на возможный период пропадания сигнала. Он может быть несколько секунд, несколько минут, но никак не неделю, это бессмысленно.
Общесистемную шкалу я предлагаю привязывать к UTC/GPS (в моментах секунд они совпадают).
Шкалу времени каждого из каналов я предлагаю привязывать к времени канала. Т.е., для сигналов GPS к времени GPS данного канала - чтобы из регистров канала буквально считывалось GPS time.
>> Да. Время должно быть непрерывным. Поэтому, в частности, в НАВИСЕ для всех расчетов берется время GPS.
В очередной раз подтверждается тезис, что время системы должно быть непрерывным. Как разработчики ГЛОНАСС об этом не думают? Я пытался донести эту мысль до Поваляева - но ГЛОНАСС уже не исправить.
И ещё, хочу отметить. Я тут попутно имитатор делаю, там особенно жизнь упрощается от единого формата времени. Единственное - счётчик символов данных добавить надо, но это специфично для имитатора, поэтому я сюда не включил.
Счетчики инициализируются один раз? А потом шкала запускается и начинает щелкать непрерывно и без скачков? Или же подстраивается, если вдруг система символьной синхронизации перестроится на одну позицию и т.п.? Иначе говоря: дергает ли её кто-нибудь, она отражает текущее измерение сигнального времени или синхронизируется только один раз, а дальше щелкает на основе только генератора ПСП?
Предполагается, что шкала будет щёлкать на основе генератора ПСП. Ну, сдёрнуть её программно можно в любой момент. Но если у нас есть устойчивое слежение за фазой дальномерного кода, я предполагаю, что она будет чётко завязана на эпохи кода. По-идее, если сигнальное время вдруг перестанет соответствовать фазе кода, то это должно приводить к срыву слежения.
Конечно, если система символьной синхронизации выяснит, что появилось смещение, то можно шкалу сдёрнуть. Но это будет происходить лишь в случае сбоев в символьной синхронизации - либо в момент начальной инициализации, либо в момент, когда "вдруг" система символьной синхронизации решит перестроиться на позицию. В излучаемом сигнале скачков во взаимосвязи между фазой кода и символами быть не может, в предлагаемой структуре шкалы времени такие скачки тоже не предполагаются - она для этого и нужна.
Статью-то написать можно, только её нигде кроме интернета не опубликуют. Нет научной мысли и технической сути. Для человека непричастного всё будет выглядеть как очередные жалобы на горькую жизнь.
[ Хронологический вид ]Комментарии
Комментарий номер раз
Ответ на коммент
Указан неподдерживаемый язык.
Вы должны указать язык следующим образом: <source lang="html4strict">...</source>
Поддерживаемые языки:
4cs, 6502acme, 6502kickass, 6502tasm, 68000devpac, abap, actionscript, actionscript3, ada, algol68, apache, applescript, apt_sources, asm, asp, autoconf, autohotkey, autoit, avisynth, awk, bascomavr, bash, basic4gl, bf, bibtex, blitzbasic, bnf, boo, c, c_loadrunner, c_mac, caddcl, cadlisp, cfdg, cfm, chaiscript, cil, clojure, cmake, cobol, coffeescript, cpp, cpp-qt, csharp, css, cuesheet, d, dcs, delphi, diff, div, dos, dot, e, ecmascript, eiffel, email, epc, erlang, euphoria, f1, falcon, fo, fortran, freebasic, fsharp, gambas, gdb, genero, genie, gettext, glsl, gml, gnuplot, go, groovy, gwbasic, haskell, hicest, hq9plus, html4strict, html5, icon, idl, ini, inno, intercal, io, j, java, java5, javascript, jquery, kixtart, klonec, klonecpp, latex, lb, lisp, llvm, locobasic, logtalk, lolcode, lotusformulas, lotusscript, lscript, lsl2, lua, m68k, magiksf, make, mapbasic, matlab, mirc, mmix, modula2, modula3, mpasm, mxml, mysql, newlisp, nsis, oberon2, objc, objeck, ocaml, ocaml-brief, oobas, oracle11, oracle8, oxygene, oz, pascal, pcre, per, perl, perl6, pf, php, php-brief, pic16, pike, pixelbender, pli, plsql, postgresql, povray, powerbuilder, powershell, proftpd, progress, prolog, properties, providex, purebasic, pycon, python, q, qbasic, rails, rebol, reg, robots, rpmspec, rsplus, ruby, sas, scala, scheme, scilab, sdlbasic, smalltalk, smarty, sql, systemverilog, tcl, teraterm, text, thinbasic, tsql, typoscript, unicon, uscript, vala, vb, vbnet, verilog, vhdl, vim, visualfoxpro, visualprolog, whitespace, whois, winbatch, xbasic, xml, xorg_conf, xpp, yaml, z80, zxbasic
Подсветка кода Geshi не переваривается
Измерение Кш у В102 прямыми методами (с шумовой головкой) дали цифру 2,2 дБ для GPS и 2 дБ для ГЛОНАСС. Есть мнение, что формулы неверные, а измерения не точные. Например, не учтен Кш самого анализатора, который равен 24 дБ (!!!)
По оси X лучше сделать логарифмический масштаб, так нагляднее.
Подумаю
Считать, конечно можно. Только проще отключить 2D-решение и не считать его за решение. В СН-4706 это можно, а в u-blox разве нельзя? Надо бы это 3D/2D обсудить с Короленко.
3D/2D с Короленко обсудили. Он 2D за полноценное не считает. В u-blox'e не находил команды на отключение 2D решения.
Оформление в процессе? "Проблемы с Глонассом" пока не полностью, похоже..
Про "карму" сильно, оценил. =)
-Короленко не спрашивали, как с ИНСом, катая в машине приемник и, соответственно, работая по реальным сигналам, измерять их уровень?
Холодный и горячий старт.. Нам нужно оговорить, что приемник стартует нахолодную, или горячие исследования тоже проводить? Ему надо оно?
Про 3D, отсутствие сбоя - хорошо. 5 повторов - тоже хорошо. По пяти повторам отсеивать выбросы? брать нижний не-выброс? Кусочек метролога, который во мне остался после Скачкова, негодует..
-"За Сбой навигационного решения считать отсутствие 3D-решения в течение 10 секунд (верхний предел горячего старта) и более. " - не понял, можно пояснить? При чем здесь предел старта?
-Поиск пять минут - значит куролесица с TTFF идет лесом? А как же требование универсальности методики?
-Военный приемник нам, я так понимаю, дадут? =)
И последнее, просьбы снять характеристики, это ведь не к Вальсету? Сроки..
1) Глонасс дописал 2) ИНС будет в статике, судя по всему 3) Горячий старт нужен: придется делать методику и ставить эксперименты 4) Про замену усреднения на наихудший вариант в итоге забыли( 5) Пять минут установлены генеральским решением 6) Военный приемник придется искать в закромах Родины 7) Сроки Вальсета остались в прежних пределах, характеристики в рамках работы
ps Надо сделать уведомление по почте о комментировании
Ну вот, запостить не успел, а уже кто-то правит.. =)
Заглавную страницу перекосило, но дело оказалось не в этой заметке
Ссылка на картинку не работает :(
bug is fixed
Ну вы (Женя с Сашей) на почте флуд развели =)
Есть же комменты - и ящик ничей кондрашка не хватит..
http://www.webupd8.org/2010/12/install-virtualbox-40-stable-in-ubuntu.html
Не думаю, что такая проверка на плагиат будет эффективна. Ведь наша задача - не получить от них правильные координаты, а проверить знания каждого. А так все они пропустят замерянные данные через одну и ту же программу, (написанную два года назад на Python) и с точки зрения цифр плагиата ни у кого не будет - измерения-то все сами делают в аудитории и под контролем.
Ответы на вопросы Ильи. 1. Вероятность 0.1 - на весь поиск, а не на одну ячейку. 2. Доплер - +-DopMax. 3. Коэффициент умножается на теоретический порог. 4. Поле поиска разбито на половину символа по задержке и 1/T по частоте. 5. На последнем графике по оси абсцисс двоичный логарифм от количества некогерентных накоплений.
Спасибо, сейчас подкорректирую. Правда смысловую нагрузку последнего графика так и не осознал.
А, он хитрый. Этот график демонстрирует выигрыш от некогерентного накопления для разных длительностей когерентного накопления. При малом отношении сигнал/шум на интервале когерентного накопления график начинает загибаться.
Ну, стадия 0 - это когда совсем ничего нет. Т.е., только идея. Ну, и амбиции, конечно. Идей у нас, правда, подходящих нет пока, но идею можно придумать.
Я считаю, что если туда лезть не ради просто галочки, то лезть нужно в стадию 1, где выше требования. Иначе это просто бесполезное занятие. А насчёт требований - цель нужно ставить и соответствующие пункты закрывать. Так, по "ИТ" нужнен работающий прототип, это сделать можно.
Проблема, на самом деле, кроется в том, что проект нужен коммерческий, более того, с "существенными конкуретными преимуществами перед мировыми аналогами". Вот тут просто идеей не обойтись, нужна ИДЕЯ. Её у нас нет. Ну, и в коммерческой области никто вертеться не умеет.
PS. Списки требований очень напоминают требования к госконтактам ;) - и это не удивительно, затея примерно такая же, но с другим масштабом. В принципе, я понимаю деятелей от государства, которые это затеяли (я не в плане распила средств) - нужно толкать общество вперёд. Но увы, мне кажется, у них нет для этого методов кроме выделения денег под громкие лозунги. Можно этим, конечно, пользоваться по прямому назначению, т.е. сделать на госденьги что-то коммерчески успешное, но я пока не знаю, как.
Весело отпуск проводишь))
А, да, я никак в отпуск не уйду.
Да, расстояние C-A выбивается среди прочих ... надо перемерять лазерным дальномером ещё раз.
Остальные службы не ответили?
К чему это? В НИИ КП задание дали?
Да, Жень. И так как мне не хочется изобретать велосипед, надеюсь у тебя проконсультироваться на эту тему. Дооформлю тут всё и пришлю тебе письмо.
Ты поясни, они там что, программно в ARM быстрый поиск устроить хотят? Сразу предупреждаю, я тут прикинул, текущая реализация блока поиска в Альпаке для обеспечения требуемых характеристик будет искать, видимо, 3 часа. У тебя ресурсы существенно скромнее. Поиск в микросхеме Шувалова должен быть намного быстрее - 320 с. Поиск в нынешнем SiRF'е - 2.5 с, но это, скорее всего, не так.
Ты абсолютно прав.
Вот поэтому я не верю в программный поиск. Кстати, про Альпаку, возможно, написано неверно - я тут недавно подкрутил поиск, и он стал искать в несколько раз быстрее. Надо померять. Но это всё равно будут десятки минут.
Из скидок у меня только простота сигналов - С/А и СТ.
Помнится у Саши был какой-то хитрый алгоритм поиска в программном приемнике, основанный на перемножении спектров.
Эти ограничения - десятки минут, они вызваны возможностями процессора? Или связки какой-то аппаратный поиск в ПЛИС + дополнительная обработка процессором? Как эти цифры привязать к чисто программному поиску?
Это как раз у меня был этот хитрый алгоритм, он сейчас заложен в Альпаку. Оценки выше приведены для сигнала GPS C/A, для ВТ всё будет пропорционально хуже. Памяти 1 Мб немного, требуемый объём памяти можно разменять на время поиска. Ограничения вызваны обработкой в процессоре. В ПЛИС можно делать быстрее, но нужна куча ресурсов, это одна из причин, по которой нужно делать новую Альпаку.
В поиске всё вообще всегда в ресурсы упирается.
Может быть, перенести сюда наше обсуждение по почте? А то потеряется...
Сделано
"Захват сигнала без поиска по известным эфемеридам (или альманахам), что есть в любом нормальном софте, мы даже никогда не делали, а ведь в случае наличия универсального времени это довольно просто." </br> </br>
Я делал в программном приемнике - даже работало.
Ну, собственно, разговор не об этом.
Да. Время должно быть непрерывным. Поэтому, в частности, в НАВИСЕ для всех расчетов берется время GPS.
1. Номер недели всё-таки нужен, чтобы правильно учитывать эфемериды на границе смены недели, и иметь возможность пользоваться старыми альманахами. Вот только ошибок GPS повторять не надо - номер недели должен быть как минимум 16-битным.
2. Представление сигнального времени в канале - это одно, а представление общесистемного времени в приемнике - это всё-таки другое. Для того, чтобы свести все системы нам абсолютно вредно думать об эпохах и чипах ПСП - нам нужны недели, секунды и время внутри секунды.
3. Посему предлагаю общесистемную шкалу времени формировать на основе времени GPS в формате недели-секунды-доли секунды.
Но дальше встает вопрос - мы будем корректировать общесистемное время в приемнике, подстраивая его под время GPS в реальном времени, или же зафиксируем некоторое абстрактное общесистемное время, а в алгоритмах везде будем тащить оценки сдвига шкал? Если грубо, то будем ли мы привязывать метку времени к GPS/UTC или нет?
Моя идея заключалась в едином представлении времени и для системы, и для каналов. Т.е. я ставил задачу как раз объединить сигнальное и системное время в едином формате, чтобы максимально легко их друг с другом сводить.
С точки зрения системы нужны секунды.
С точки зрения канала - там уже есть эпохи (специфичные для сигнала, но в секунде их целое число).
Вот чтобы всё это соединить вместе, я и написал данный материал. Почему не совсем время GPS? Всё, что выше секунды - полностью совместимо с временем GPS. Так что можно считать, что это время GPS. Всё, что ниже секунды (эпохи и чипы) - специфично для сигнала. Секунда - точка объединения.
Теперь по счётчику недель. Я предполагал, что шкала времени будет аппаратно реализована в каждом из каналов. Интервал времени, на котором желательно однозначно определять время, равен периоду обновления эфемерид, +-2 часа для GPS, как я помню. Поэтому я решил, что времени в пределах недели, как наиболее крупной единицы времени, хватит. Что касается переходов через номер недели - это решается легко. Текущая неделя известна. Если мы находимся на границе недель, то в счётчике секунд будет либо малое число, значит, новая неделя началась, либо большое число, немного менее 604800 с - значит в канале ещё старая неделя. Разрешить это вполне возможно. А тащить номер недели в регистры каждого из каналов мне кажется не нужным. Секуду лучше тащить. Тут всё завязано больше на возможный период пропадания сигнала. Он может быть несколько секунд, несколько минут, но никак не неделю, это бессмысленно.
Общесистемную шкалу я предлагаю привязывать к UTC/GPS (в моментах секунд они совпадают). Шкалу времени каждого из каналов я предлагаю привязывать к времени канала. Т.е., для сигналов GPS к времени GPS данного канала - чтобы из регистров канала буквально считывалось GPS time.
>> Да. Время должно быть непрерывным. Поэтому, в частности, в НАВИСЕ для всех расчетов берется время GPS.
В очередной раз подтверждается тезис, что время системы должно быть непрерывным. Как разработчики ГЛОНАСС об этом не думают? Я пытался донести эту мысль до Поваляева - но ГЛОНАСС уже не исправить.
И ещё, хочу отметить. Я тут попутно имитатор делаю, там особенно жизнь упрощается от единого формата времени. Единственное - счётчик символов данных добавить надо, но это специфично для имитатора, поэтому я сюда не включил.
Счетчики инициализируются один раз? А потом шкала запускается и начинает щелкать непрерывно и без скачков? Или же подстраивается, если вдруг система символьной синхронизации перестроится на одну позицию и т.п.? Иначе говоря: дергает ли её кто-нибудь, она отражает текущее измерение сигнального времени или синхронизируется только один раз, а дальше щелкает на основе только генератора ПСП?
Предполагается, что шкала будет щёлкать на основе генератора ПСП. Ну, сдёрнуть её программно можно в любой момент. Но если у нас есть устойчивое слежение за фазой дальномерного кода, я предполагаю, что она будет чётко завязана на эпохи кода. По-идее, если сигнальное время вдруг перестанет соответствовать фазе кода, то это должно приводить к срыву слежения. Конечно, если система символьной синхронизации выяснит, что появилось смещение, то можно шкалу сдёрнуть. Но это будет происходить лишь в случае сбоев в символьной синхронизации - либо в момент начальной инициализации, либо в момент, когда "вдруг" система символьной синхронизации решит перестроиться на позицию. В излучаемом сигнале скачков во взаимосвязи между фазой кода и символами быть не может, в предлагаемой структуре шкалы времени такие скачки тоже не предполагаются - она для этого и нужна.
При выкидыше ГОСТОв я поскупился на эмоциональные комментарии их содержимого. Исправляюсь.
1. В ГОСТах встречаются просто ВОПИЮЩИЕ ошибки. НАП, сделанная по этим ГОСТам, работать не будет никогда.
2. НИ с кем из моих знакомых разработчиков эти ГОСТы согласованы не были - вопрос: кто и для кого их писал?
Так что джентльмены, если надо заткнуть рот нормативщикам и приверженцам ГОСТов - вот хороший пример.
Может написать статью? Заработаем пафосную репутацию и лишнюю галочку))
Статью-то написать можно, только её нигде кроме интернета не опубликуют. Нет научной мысли и технической сути. Для человека непричастного всё будет выглядеть как очередные жалобы на горькую жизнь.
Войдите, чтобы комментировать.