Pull to refresh

Comments 36

То есть, надо понимать, что современные цифровые коммуникации имеют неустранимые изъяны. 9 секунд запоздания – это вообще за пределами добра и зла... До Луны и обратно пинг равен 3 секунды.

9 секунд запоздания

Мне кажется, что чтобы сделать любые мыслимые преобразования и колдунство над аудиопотоком, и отправить его куда надо через цифровые каналы, 9 секунд, это все равно слишком много, и проблема там в чём-то другом.

UFO just landed and posted this here

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

Если прямой эфир, то как его отправить раньше реального времени? А если передача в записи - то какая разница на сколько она запаздывает?

Комментатор выше отвечает только за стратегию.

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

  1. Станция вещает технический сигнал, судя по приложенному видео. Содержание этого сигнала известно не то, что за 30 секунд, а возможно и за 10 лет. Нет никакой проблемы сгенерировать сигнал не для времени T, а для времени T+30

  2. Если там есть прямые эфиры или еще какой-то живой контент - он идет с задержкой, да. Он и сейчас это делает. Если 30 секунд неприемлемо - выбирается компромисс между отзычивостью и устойчивостью к нестабильности канала.

  3. Станция получает точное время по какому-нибудь NTP, PTP, через GPS или еще как-нибудь.

  4. Станция принимает входящий поток и передает его в радиоэфир по временным меткам этого потока.

Буферизация есть и на оконечном устройстве, то есть, оно тоже вносит задержку, а значит, синхронизация потока с реальным временем должна выполняться на нем.

Из этого следует, что на оконечном устройстве должны быть точные часы.

А если они есть, то зачем ему сигналы точного времени? :)

В целом, можно предположить сценарии, когда такую схему можно использовать для каких-то более сложных технических трансляций, привязанных ко времени — например, расписаний и т.п. Но не для бытовых сетей ТВ/радио.

Тут есть три возможных сценария:

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

  2. Вещание на обычные компьютеры через обычные протоколы. Тут, конечно, всё плохо, особенно если речь идет о классическом аудио-стриминге. Можно попытаться через WebRTC передать сигнал, и в целом развлекаться с RTP - тогда задержка будет сильно меньше секунды (если только речь не идет о какой-то совсем уж плохой связи).

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

  3. Вещание в цифровом формате путем классических радиоволн (DAB, DMR, ...). Я не смотрел конкретно радио-протоколы, но в DVB точное время передается в сигнале отдельно. Приставка его знает без всякой внешней синхронизации. Остается вопрос длины буфера.

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

Остается только вопрос экономической целесообразности этого всего вот.

Так жалуются на то, что метки точного времени запаздывают. Полагаю, что их контент известен куда заранее, чем за 30 секунд.

Да, пускай вообще пользователь сам запускает записанную трансляцию сигналов точного времени, ориентируясь по своим часам.

UFO just landed and posted this here

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

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

Нет, с цифровыми коммуникациям всё в порядке. Тот же GPS позволяет определить не только координаты, но и время притом с погрешность на много порядков меньше этих теплых и ламповых секунд. Может в этом дело? ;)

9 секунд это всякие буферы и кеши, чтобы при передаче сигнала по пакетным сетям не было разрывов звука.
Ну и сигнал через спутник, зачастую ходит

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

Так выходит и новый год отмечаем с запозданием!

При чем давно. Даже эфирное телевидение было не моментальным. Сигнал до местного ретранслятора доставлялся самыми разными путями - от релейных линий до спутника. Каждая давала запоздание. Потом НТВ+/Триколор - цифра + спутник, теперь DVB T2 - тот же спутник + цифровой эфир с буферизацией.

Так что если хотите точно, то Linux + GPS в качестве сигнала точного времени. На крайний случай NTP от нескольких серверов.

А по теме статьи - жаль. Станция обеспечивала точность при прямом приеме. Знаменитый DCF-77, который можно принимать в Питере и почти по всей Европейской части России используется многими радио-контролируемыми часами и принимается довольно хорошо на простые любительские приемники. Часы с коррекцией по этой радиостанции часто являются частью метеостанции (а, как известно что из процессорной платы не делай - всегда выходит или сигнализация, или метеостанция). Так что помимо утилитарного - помимо точного времени, эти станции несут огромную образовательную составлющую. И жалко именно ее, а не точное время. Последнее нынче можно получить другими путями с большей точностью. А вот простой путь в радио...

Да DCF77 очень полезная штука. Даже в быту. У меня все настенные часы синхронизируются по ее сигналам. Всеж таки радиофизик.

Нет, я конечно допускаю, что у радиофизика дома только специально обученные часы, но все же, "как это, Холмс?"

"часы с синхронизацией купить".

Можно и самостоятельно сделать на детальках с али.

Именно так. Но можно и самому намотать катушку на сердечник, собрать приемник и обработать его выход контроллером.

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

которая начала транслировать сигналы точного времени 9 октября 2023 года.

Не долго же она отработала.

Не ужели так трудно прочитать разок перед публикацией?

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

А зачем нам знать про чужое, давайте историю о нашей службе на 66,6. Почему вот тут пишут про немецкую на 77кГц, а не про российскую на 66,6 kГц?

А нет пророков на родине. Разве не знали?

Пишите, разрешаю

Почему?

На это, как водится, есть несколько причин. Но самая главная проста как мычание. Отечественная электроника озадачена выпуском чипов для банковских карт (ибо там деньги), но категорически не заинтересована в выпуске модулей синхронизации для бытовых часов, типа тех что в комментарии выше. В итоге сервис доступен только тем, кто сам в состоянии собрать приемник и запрограммировать контроллер. А в стране дикий дефицит специалистов не только в области больших данных, искусственного интеллекта и блокчейна, но и радиолюбителей - embedder'ов. При чем дефицит последних сильно больше.

Мои, персональный опыт говорит - что даже если собрать систему синхронизации по RBU, то... Результат будет хуже, чем с DCF-77, хотя, казалось бы, должно быть наоборот. Особенно если на табло рядом выводить часы с приемника GPS и обработкой секундной метки. Не знаю. То ли приемник должен быть строго ГЛОНАСС, то ли мне не очень повезло. То ли сам где-то в проекте наврал...

Тут есть радисты. Я бы их статью почитал. А то про жужжалку, она же buzzer, она же УВБ-76 пишут, а про станции точного времени как-то не очень.

В 200х искал приемник для scada-системы, dcf-77 стоил 50 баксов, отечественный для RBU раз в 15 дороже...

Жалко, что технологии уходят в прошлое. Уникальность канадского сигнала точного времени CHU среди остальных сигналов точного времени в том, что он совместим с модемным Bell 103. Только действительно ли радиостанция точного времени прекращает свое существование, как написано в заголовке статье? Как я понял из содержания статьи, сигнал точного времени прекращают транслировать на одной из радиостанций Канады, транслирующей новости, из-за перехода в цифровой формат.

из-за перехода в цифровой формат.

Фактически, это означает конец радиостанции. Устройства, которые могли синхронизировать часы по ее РАДИОсигналу, больше не смогут это делать.

А в цифровом формате есть много каких сервисов, которые обеспечат нормированную ошибку (а не 3-20 секунд)

UFO just landed and posted this here

Я тоже так понял. Поэтому и спросил.

Sign up to leave a comment.