Триколор тв не работает телегид. Не работает Триколор, перестал показывать Триколор, пишет кодированный канал DRE или нет доступа

Где Телеканал Звезда, почему его нет на ТВ?

Многие абоненты оператора кол ТВ столкнулись с проблемой — пропал любимый телеканал Звезда. Интересен тот факт, что в списке он есть, но когда заходишь — там нет телеканала, к которому многие привыкли. Все дело в том, что оператор кол ТВ прекратил вещание любимого телеканала Звезда с 18 января 2015 года, но тут дело не просто в технической стороне, а в том, что многие абоненты может не обращали внимание на то, что в сетке вещания оператора было два телеканала Звезда, один вещал в MPEG-2, а второй вещал в MPEG-4 .

Где Телеканал Звезда?

Качество трансляции было чуть ниже среднего уровня. Многие абоненты не обращая внимания! что версий две- жаловались на низкое качества изображения именно у оператора . Для сравнения! У других операторов качество трансляции было на порядок выше. И технической службой оператора 18 января 2015 года были сделаны действия, в результате которых телеканал Звезда в формате MPEG-4 был убран из сетки вещания или попросту сказать — вещание телеканала Звезда прекращено.

Конечно, тут на лицо В том, что они в установленном порядке не предупредили зрителей о данной процедуре. Может они не посчитали это делать нужным! А может решение по отключению было принято в ночь на 18 января 2015 года и они это сделать попросту не успели! Нам это не интересно (пусть сотрудники оператора разбираются в этом внутри компании) .

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

Это сделать очень легко если у вас приемники марки GS , DRE , DRS , вам всего навсего надо найти в меню вашего приемника пункт и нажать кнопку которая подтвердит команду поиска.

После этого в списке запоминаете где на новом месте находится телеканал Звезда и смотрите его.

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

Имеется 2 или более устройств на достаточно большом (1-100 метров) расстоянии, между которыми надо передавать данные. Рассмотрев некоторые интерфейсы (rs232/422/485, I2C, Ethernet) пришел к выводу - что они либо не гарантируют однозначную передачу данных, много проводов тоже мне не понравилось, не дают ответ что информация принята. За основу решил взять интерфейс RS485 - из его плюсов он может «далеко идти», 2 провода, можно одновременно подключить кучу приборов, прост, (UART) есть почти на любом контроллере.

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

Один цикл обмена.

Для удовлетворения моих потребностей по передаче данных требуется решить всего два вопроса. Вопрос первый: проверка передаваемого байта основана на самом интерфейсе RS-485, но она не гарантирует достоверно переданный байт - при обнаружении запорченного байта в самом интерфейсе он выкидывается из принимаемых данных, но при этом все равно остается возможность передать неправильный байт - если поменялось(испортилось) четное количество бит в байте. т.е. требуется проверка на количество передаваемых байт и достоверность байтов в передаваемых данных.

Вопрос второй: получение ответного сообщения, на переданное.

По первому вопросу: предлагается такая схема: начальный байт, байт количества
передаваемых символов во всем сообщении, что-то еще, байт контрольной суммы (БКС), конечный байт.

Примечание: байт контрольной суммы считать по модулю 2

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

Для исправления этого было принято: если ответ не приходит(или приходит но недостоверный), то повторно (кол-во раз без маразма) повторять текущий цикл обмена. Здесь может возникнуть следующая ошибка. Допустим мы направляем команду говорящую устройству, что нужно прибавить громкость на +1 единицу. Когда сообщение доходит до ведомого, он выполняет команду прибавить громкость и отправляет ответ «ок, я сделал как ты хотел», при этом может получится так что ответ портится и ведущий не понимает что команда уже исполнена, и отправляет сообщение повторно. В итоге по приеме команды на стороне ведомого громкость будет уже прибавлена на +2 единицы. Для избегания такого явления, принято ввести идентификатор (НС - номер сообщения) отличия сообщений. Если номер сообщения повторяется, то это повторное сообщение и указанную команду выполнять не надо, а просто отправить предыдущее ответное сообщение.

Так же здесь ввожу еще 2 параметра - это номер (код) устройства которому передаются данные и номер (субкод) обозначающий какую команду надо выполнять(либо какие данные лежат внутри сообщения).

В итоге сложу все вместе и пройду по алгоритму, на примере увеличения значения порога срабатывания реле по температуре на 5 градусов Цельсия и забора текущего показания температуры из ведомого устройства за 1 цикл обмена:

Формирую передаваемые данные от ведущего:

При приеме сообщения ведомым смотрит 2 байт, где лежит кол-во отправленных байт, если кол-во отправленных байт равно кол-ву принятых - значит сообщение не потеряло байтов далее смотрим начальный байт(символ) если он = "$", а также конечный байт(символ) если он = "#" - то это сообщение от ведущего к ведомому.

Тут же рассмотрю возможные варианты сообщения от ведущего к ведомому с ошибками в начальном и конечном байтах, а также вариант с ошибкой кол-ва байт в сообщении. Оговорюсь сразу из 3 значений параметров буду считать правильными 2 и 3, т.е. при совпадении 2-х параметров из 3-х возможных считаю сообщение состоявшимся.

1. начальный байт = "$", кол-во принятых байт = 7(кол-во отправленных байт = 7), конечный байт не равен "#";
2. начальный байт не равен "$", кол-во принятых байт = 7(кол-во отправленных байт = 7), конечный байт = "#";
3. начальный байт = "$", кол-во принятых байт = 7(кол-во отправленных байт = 7, кол-во байт не равно 7), конечный байт = "#".

Применение схемы ["$"][кол-во отправленных/принятых байт][...]["#"] - с большой вероятностью гарантирует что такая комбинация не сможет встретится в передаваемых данных, и спровоцировать лжесообщение.

Формирую передаваемые данные от ведомого на основе принятого сообщения:

Принцип обработки следующий: смотрим 2 байт где лежит кол-во отправленных байт, если кол-во отправленных байт равно количеству принятых байт а также начальный байт = "@" и конечный байт = "&" - то это сообщение от ведомого к ведущему. Если требуется использую механизм 2 из 3-х, аналогично описанному выше только уже для ответного сообщения (для символов "@" и "&"). Ведущий при приеме этого сообщения анализирует контрольную сумму 9 (с 3-го по 11-ый) байт, при совпадении контрольной суммы данные в сообщении считаются достоверными и продолжается дальнейший анализ данных. При совпадении кода, субкода и НС отправленного и принятого сообщения продолжаем анализ ответа на сообщение отправленное ведущим. Далее идет анализ принимаемых данных, в моем случае в 6-ом байте значение 1 - говорит о том что команда по прибавке 5 градусов к порогу срабатывания реле произведена успешно, остальные 5 байт говорят о текущих показаниях температуры 7-ой байт - флаг говорящий о достоверности передаваемой температуры (т.е. рассматриваю вариант ведомое устройство включено и отвечает, а датчик может не работать) и 4 байта типа float значения температуры.

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

Немного о передаче данных ведомый ведомому, и централизованное сообщение всем ведомым от ведущего.

Сначала о последнем - передача от ведущего ведомым осуществляется назначением кода устройства 255, говорящего ведомым что это централизованное сообщение, далее остается только решить вопрос об общих субкодах, также можно группировать по кодам устройств т.е. назначить код устройства 254 и по этому коду 3 или 4 устройства будут принимать сообщение остальные ее игнорируют, естественно здесь не должна срабатывать часть по отправке ответов от ведомых устройств - т.е. не гарантированно что ведомые однозначно приняли эти сообщения!

О передаче данных ведомый ведомому, реализовать методом ведущий отправляет сообщение ведомому (ведомый1) от которого должна поступить информация другому ведомому (ведомый2), ведомый1 отправляет ответ ведущему при этом ведомый2 подслушивает этот ответ забирая данные себе. Опять же гарантии об однозначной доставки сообщения от ведомого1 к ведомому2 нет, этот надо учитывать!

Возможности интерфейса кол-во теоретически подключаемых устройств около 250, команд/типов данных до 248 для каждого устройства, длинна полезной информации в сообщении до 250 байт.

Поговорим о подводных каменьях:

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

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

Отдельно хотелось бы выделить вопрос об синхронизации устройств по времени - следует учитывать что синхронизация по времени ведомого при получении сообщения требует учитывать задержки времени на отправку данных в канал (при скорости 9600 сообщение 10 байт будет передаваться примерно 11 мсек) и важен момент срабатывания прерывания по окончанию приема данных на стороне ведомого, если прерывания нет то стоит учитывать время проверки прихода данных в буфер устройства, и т.п.

Так-же стоит отметить что повторная отправка цикла сообщения также добавляет нюансов, рекомендую на синхронизацию по времени использовать отправку сообщения без повторов, а формировать сообщения с новым НС.

P.S. У меня есть сомнения что я открыл здесь что-то новое, все это в той или иной мере где-то используется в разных интерфейсах! С легкой руки автора этой писанины и применения сего протокола в своих разработках, хочу дать название этому протоколу передачи данных «SRDB2».

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

Сначала нужно разобраться в причинах – почему не работает телегид:

• Неправильно установленное время на самом приёмнике;
• Произошел сбой в работе оборудования;
• Устаревшая прошивка или сломался приемник;

Конечно оставлять оборудование в таком состоянии никак нельзя, поэтому нужно искать решение. Самое простое решение вопроса это обратиться к специалисту, который устанавливал ваше оборудование. Кроме того, можно попытаться обратиться к специалистам Триколор ТВ по телефону горячей линии.

Как починить телегид на Триколор ТВ

• Установить правильное время на приёмнике. Для этого на пульте приёмника нажмите “меню”, затем найдите раздел “дата и время”. Установите точную дату и время;
• Сбросить настройки до заводских. Инструкция: ;
• Попробовать обновить приёмник, возможно было выпущено обновление с новыми настройками;
• Перезагрузите приёмник. Для этого нужно сделать следующее: выключите его. Затем выньте его шнур из розетки на несколько минут. Включите приёмник. Произойдет сброс ошибок.

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