Pull to refresh
61
0.7
Александр Козлов @alcotel

Инженер-электронщик

Send message

Боюсь, что вы бы имели в 30 раз меньше, чем 100 кбит/c )))

Другие коды с этим не справляются

Даже без введения избыточности - NRZI с этим прекрасно справляется.

Это максимальная скорость базовой станции по стандарту. То, что она делится между пользователями одной станции - это просто приходится принимать.

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

А раз существует метод тестирования, который даёт 300 Мбит/c, то никакого обмана тут нет, просто бизнес)

Смотря с чьей колокольни смотреть)

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

У произвольного информационного цифрового слова и у закодированного слова вид и спектр один и тот же

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

У произвольного информационного цифрового слова и у закодированного слова вид и спектр один и тот же

Тогда они идентичны. Это клонирование, а не кодирование)

Просто когда дело касается физической реализации, понятия "кодирование" и "модуляция" иногда смешиваются. Тот же манчестер можно считать и избыточным вдвое кодированием (добавили инверсный бит), и вариантом фазовой модуляции (BPSK). А полезный результат тот же - манипуляции со спектром.

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

Так это просто один из методов расширения спектра. Которые уже давно позволяют, например, GPSу работать при соотношении сигнал/шум хуже, чем минус 20 дБ.

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

Информация передаётся, и вполне можно посчитать, сколько.

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

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

Учтено в конструкции передатчика и приёмника. Также, как и способ кодирования, сжатия, вид модуляции, среда передачи. Да, это тоже информация, но передаётся она вам один раз, когда вы это железо покупаете)

При миллисекундной точности возможных вариантов 86400000. По формуле Хартли это 26,3 бита.

Тут я, похоже, перестал понимать, о чём речь. Поясните, что конкретно вы понимаете под "голографическим кодом". Приведите пример такого кода.

Этот пик приносит вам информацию, на сколько миллисекунд из диапазона +-43200 секунд (сутки) ваши часы отличаются от часов ВНИИФТРИ. Чем лучше вы примете сигнал (с лучшим соотношением сигнал/шум), тем точнее определите начало шестого пика, и получите больше знаков после запятой.

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

Это проверенный факт

Давайте же проверим этот факт. Ну во ты получили, например, сообщение
0000001000010000
Даже имея информацию, что тут искажён всего один бит, а не 13, вы восстановите исходные данные?

Теорема Шеннона говорит про передачу полезной информации. Какое вы при этом используете кодирование или избыточность - без разницы. Поэтому теорема и считается одной из фундаментальных.

А если передавать голограмму одной светящейся точки, когда информация заложена в координаты точки, а не яркость – качество не имеет значения

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

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

А какой раздел математики запрещает сжатие без потерь?

Теория множеств скорее всего, и базовые аксиомы. Я при доказательстве не привлекал понятие "информация". Прочитайте внимательнее.

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

А уже соответствие соответствие аналоговых сигналов и количество информации в них задаётся теоремами Котельникова, Шеннона и Найквиста.

Я примерно о том же

В начале 00х пин-коды подтверждения чистили от повторяющихся цифр и арифметических прогрессий. Но из-за парадокса Дней рождения 4-значных таких примерно половина, и криптостойкость фактически снижалась в 2 раза. Сейчас фильтруют от дурака только горячую десятку "часто используемых", типа 1111 и 1234.

Качество картинки падает.

Грубо говоря, у вас было 8 бит на пиксель и разрешение 1000х1000. А когда вы отломали кусок, стало 7 бит и 500х500. Картинка-то в целом осталась, но получилась более грязная и размытая, как при большом сжатии в JPEG.

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

Ну а про помехоустойчивость есть таки теорема Шеннона.

То есть, вы по факту пытаетесь оптимизировать мощность передатчика, а не сжать данные.

Только в оптике и скоростных интерфейсах как раз наоборот стараются использовать кодирование с примерно одинаковым количеством нулей и единиц (DC-баланс). И избегают длинных монотонных последовательностей (8b10b, битстаффинг). Иначе порог срабатывания тяжело подстраивать, и разваливается синхронизация.

Да, это я ошибся по невнимательности, там сдвиг на любое значение, даже в Cortex-M0. Но и умножение в Cortex-M0 тоже есть, пускай и за 2 такта делается.

В качестве "слобого железа" лучше, наверное, посмотреть в сторону 8-битной классики:

8051 - умножение есть, за 2 такта. Сдвиги только на +-1
STM8 - не классика, но то же самое
AVR - умножение не везде есть. Сдвиги только на +-1
Z80 - полный олдскул, умножения нет, сдвиги на +-1
Полноценный сдвиг появляется только в 16-битных 8086, но тут уже и умножение, и деление присутствует.

Ну я тут, конечно, немного "пофантазировал". Раз есть умножение, то и сдвиг на фиксированную константу через него же и делается. Но ведь не наоборот! Нет умножения - нет и "бочки".

И классический LFSR всё равно побитный, или табличный. Тут ускорение есть, вариант неплохой, но за всё приходится платить ценой более прозрачной предсказуемости.

Information

Rating
1,946-th
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Date of birth
Registered
Activity

Specialization

Embedded Software Engineer, Разработчик электроники
Lead
From 280,000 ₽
Electronics Development
Development of printed circuit board
FPGA
Programming microcontrollers
Sound processing