Это не официальный сайт wikipedia.org 01.01.2023

Обсуждение:Физическое кодирование — Википедия

Обсуждение:Физическое кодирование

Последний комментарий: 4 года назад от 31.135.45.53 в теме «Не пренебрегайте запятыми»
VRTS Wikimedia Разрешение на использование этого произведения хранится в системе VRTS. Его идентификационный номер 2009041210028488.
Если вам требуется подтверждение, свяжитесь с кем-либо из участников, имеющих доступ к системе.

Про название статьи и вступительную часть Править

Насколько я понимаю, «физическое кодирование» совершенно не обязательно связано с Ethernet. Надо или переименовать статью, добавив в название Ethernet, или дополнить статью информацией о физическом кодировании вообще. И, ИМХО, не стоит начинать статью со слов о том, что не применяется. Кстати, в русской Википедии ещё есть статья про физический уровень модели OSI. А в английской Википедии есть статья именно про физический уровень Ethernet --Nokta strigo 19:20, 5 мая 2010 (UTC)Ответить[ответить]

Проставил интервики на en:Line code, с ожиданием переделки хотя бы в преамбуле о том, что физическое кодирование бывает не только в Ethernet, а понятие и его реализации относятся к одному из сервисов в физического уровня модели OSI. Кстати, в самой статье упоминается и Power line communication, т.е. преумбула у́же содержимого. Хотелось бы, чтобы статью довёл до ума сам автор, тем более, он потрудился получить разрешение. Но если в обозримое время этого не случится — то придётся выпрямлять другим участникам. Andrei Nikolaenko 21:34, 28 декабря 2010 (UTC)Ответить[ответить]

Лучше бы переписали статью, например на "При физическом кодировании цифровых сигналов (например в Эфирнете) используются особые методы, дабы избежать неоднозначности декодирования, например используются особые слова для опознавания начала кодирования и окончания и т.д. Такие методы называются протоколами кодирования"... Я уже писал статью про Манчестер-2. После чего её довели до такого маразма все эти деланные нубы-программисты с высшим образованием, что сейчас её читать невозможно. У меня возникает ощущение, что статьи здесь пишут студеньтики без опыта, тупорылые качки. Потому что очкарику понаписать такого бреда ну никак невозможно. Jem 17:50, 4 марта 2013 (UTC)Ответить[ответить]

Другие способы самосинхронизации. Править

в статье написано:

    • Если одна станция посылает битовую строку 00010000, то другая станция может интерпретировать её либо как 10000, либо как 01000, так как она не может отличить «отсутствие сигнала» от бита 0.

Есть альтернативные способы решить эту неоднозначность без применения манчестерского кода. Например, в RS232 используется NRZ кодирования, а для синхронизации используются специальные синхронизирующие импульсы. Стоповый бит 1 означает простой линии и может тянуться сколь угодно долго, минимум 1 такт. 0-Стартовый бит, тянется 1 такт. После него идут 8 бит данных, после которых обязателен стоповый бит. например чтобы послать 00010000
10000100001
Чтобы послать 01011110 01011111 надо передать по линии
100101111010010111111
Те есть задача синхронизации прекрасно решается без манчестерского кодирования. Одно из преимуществ Манчестера - возможность обеспечить гальваническую развязку с помощью трансформатора. Но приходится использовать в 2 раза большую полосу частот, чем в nrz.

Ты наверное глуповат, да? Повторяешь бред, незная ничего про кодирование, я вон вверху про вас таких написал пооткровенней. Почитай про Манчестер побольше. Манчестер-2 самый плотный и самый устойчивый к рассинхронизации код. И не пиши бреда про "в 2 раза большую полосу частот" - не тупи, студеньтик. Jem 17:55, 4 марта 2013 (UTC)Ответить[ответить]

Не пренебрегайте запятыми Править

Что значит "единичный бит передается в пределах такта уровень не меняется"? Это "единичный бит передается, в пределах такта уровень не меняется", то есть уровень фиксируется на один так, а единичный бит когда-то передаётся? или "единичный бит передается в пределах такта, уровень не меняется", то есть единичный бит передаётся в пределах такта, а уровень вообще не меняется? 31.135.45.53 11:46, 24 сентября 2018 (UTC)Ответить[ответить]