Передача данных через электросеть!

[plc-cat]

[uquote="linuxdude",url="/forum/viewtopic.php?p=3367190#p3367190"]В тему - набрел на https://github.com/leocat3/PLC-Modem - просто довольно забавный PLC модем. Со схемой и исходниками прошивки. Ну и просто любопытный пример того как данные через сеть 220 вольт можно качать. Runglish автора конечно довольно забавный, зато штука использует ряд любопытных схемных трюков и неплохо иллюстрирует один из вариантов как это можно делать. Относительно низкоскоростная штука (до 19200 bps) но этого хватит для управления и телеметрии и даже вроде быстрее и менее дурацки чем X10 и тому подобные странные вещи.[/uquote]
Это удивительно, но вы едиственный, кто увидел схемотехнические трюки
На великом и могучем описание реализации я как-то размещал на хабре (в то время гиктаймс), но кроме реки говна в комментариях ничего не было. Статьи на эту тему поудалял, публику послал нахер, за что был пожизненно переведен в режим только чтения ( о чём нисколько не сожалею )

Цели создания данного модема:
- минимальное количество деталей
- предельно низкая цена
- при этом максимальные возможности

Реализация есть. Описание: https://hackaday.io/project/156686-powe ... -blue-pill
По профилю там еще есть разработки.
За рунглиш - звиняйте. Как умею (основная практика - чтение)
Сайт еще только в начале реализации. Но планирую все открытые разработки там выложить. ( open-plc.com )

[SIM31]

[uquote="СКАЗОЧНИК",url="/forum/viewtopic.php?p=3371203#p3371203"]я в этом не соображаю. [/uquote]

На картинке же всё нарисовано. Передаем 2 частоты почередно, одна частота логическая 1, другая частота логический 0. Чем медленней, тем проще выделить сигнал из шума.

[Wladimir_TS]

[uquote="plc-cat",url="/forum/viewtopic.php?p=3418798#p3418798"]Реализация есть. Описание: https://hackaday.io/project/156686-powe ... -blue-pill[/uquote]

Не исходников, не прошивок найти не удалось, а тема интересна очень. На Али есть китайские модемы, но довольно недешево.

У меня задача - передача данных по сити 220 в условиях наличия помех от энергосперегаек и прочих китайских ИБП без входного фильтра на 10-15 метров со скоростями 50-75 бод.

Ковырялся с Х-10 оборудованием - как-то там все печально. И клонировать сложно - система содержит фильтры на LC элементах и хитрые системы АРУ в приемниках с использованием управления от МК.

Еще момент - работа открытым UART на РЧ частотах очень легко детектиться теми, кому о том знать не нужно. Нужно как-то привязывать каждую посылку к полупериоду - тогда это похоже на помеху от ИБП. Либо использовать какую-то модуляцию похитрее - например фазовую с опорой на "0" сети.

[linuxdude]

[uquote="plc-cat",url="/forum/viewtopic.php?p=3418798#p3418798"]Это удивительно, но вы едиственный, кто увидел схемотехнические трюки [/uquote]Ух ты, здесь кажется зарегался автор этой штуки .Из того что показалось необычным или новым для меня:
1) Использование свойств феррита трансформатора в роли ВЧ фильтра. Красиво расписано.
2) Пример как STM32'ом модулировать что-нибудь шустрое (1.8МГц, по сути RF) аппаратно.
3) Идея подать выход DAC на компаратор для подстройки порога софтом - не встречал такого раньше.

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

На хабре специфичная публика, вебразработчики в основном. И система кармы специфичная. Не любят разборки и сольют за сам факт. Меня на хабре нет, а если захочется что-то такое, есть easyelectronics с более тематичной публикой. Впрочем, hackday мне больше нравится. Неординарными проектами, смелыми идеями и настроем публики.

Цели создания данного модема:
- минимальное количество деталей
- предельно низкая цена
- при этом максимальные возможности

По крайней мере, это был самый простой, понятный и логичный вариант который навскидку попался. Кстати, примером простоты выглядят простые RF модули: минимально приемник 1 транзистор + 2904 (358, ...). Но там "жульничество": сверхрегенерация. Есть варианты схем, где сдвоенный операционник делает нечто типа АРУ аппаратно, усиливая отличия сигнала сейчас от усредненного (RC цепочкой, так что деталей мало). Как я понимаю это дает восстановление битов независимо от абсолютного уровня сигнала, без участия МК. А тут что-то такое - плохая идея? Из плюсов - МК ничего не знает про это (прошивка проще, что хорошо для датчиков и проч). Из минусов - RC не переконфигурируется программно. Могу показать пример куска схемы в таком духе.

И еще: размер проводки может быть сравним с четвертью волны. Не будет оно любителям в эфир пакостить? Понятно что телеметрия и управление вещает мало и редко, 160 метров ценным не считается, но формально все же не ISM

Реализация есть. Описание: https://hackaday.io/project/156686-powe ... -blue-pill
По профилю там еще есть разработки.
За рунглиш - звиняйте. Как умею (основная практика - чтение)
Сайт еще только в начале реализации. Но планирую все открытые разработки там выложить. ( open-plc.com )

Для лично меня штука любопытна тем что дает понимание как это можно делать. Я то понял что и как, а вот насколько англоговорящие поняли что задумано - не знаю. Некоторые из оборотов они не используют, перевод русского в английский 1 в 1 все же не всегда срабатывает. А так ... я могу представить себе коммуникационную среду, с датчиками, охраной, управлением и всем таким, на базе чего можно делать нечто типа "умного дома" (и не только). Я вижу себе это как "1.5-уровневую" систему: глупые/дешевые "датчики" (МК, не сложнее F103) и более умные штуки типа контроллеров локаций, равноправных/дублирующих друг друга (насколько физически возможно, хотя-бы в пределах локации), некоторые из - гейты в другие протоколы/интернет/etc. Чтобы все это было всегде мне доступно. Из любой точки планеты. Мне кажется что многие мечтают о чем-то таком. Упомянутая штука выглядит неплохим вариантом для случая когда датчик питается от сети. Мне хочется нечто типа синхронного битового протокола, так к FEC дружественнее: всегда ожидаемое количество битов. В uart может из-за единичного сбоя выпасть пару байтов в середине пакета - дальше пакет в мусор: точно неизвестно сколько и чего выпало. При синхронном протоколе битов нужное количество, а то что несколько перевернуто - FEC исправит. Можно перепослать сбойный пакет, но если в канале рушится каждый 20-й бит, UART-у будет напряжно. А с FEC + синхронным протоколом - исправить 1/20 сбойных битов и дело в шляпе. Но как синхронку поаппаратнее слать/принимать - вопрос (SPI? USART в синхронном режиме?). И требования к разбегу тактовых частот... (лично меня требование кварца у всех кто вхож в протокол - не напрягает).

[Wladimir_TS]

Ну идея регулировки чуться сигналом с ЦАПа - не нова.

Насчет свойств феррита - не уловил - 50 Гц отсекать...достаточно конденсатора емкостью в десятки пикофарад и для 50 Гц он непроницаем. Транс скорее гальваническая развязка.

А насчет примеров с модуляцией - ГДЕ он пример - я вот не нашел...может плохо искал (с) не моё.

[Maykill]

кстати-
https://habr.com/post/198874/
любопытное решение с полной развязкой от электросети

[Wladimir_TS]

Непонятное решение если честно. И вообще интересный решения с более детальным описанием, схемотехникой, исходниками ПО.

[SIM31]

[uquote="linuxdude",url="/forum/viewtopic.php?p=3440193#p3440193"]...При синхронном протоколе битов нужное количество, а то что несколько перевернуто - FEC исправит. Можно перепослать сбойный пакет, но если в канале рушится каждый 20-й бит, UART-у будет напряжно. А с FEC + синхронным протоколом - исправить 1/20 сбойных битов и дело в шляпе. Но как синхронку поаппаратнее слать/принимать - вопрос (SPI? USART в синхронном режиме?). И требования к разбегу тактовых частот... (лично меня требование кварца у всех кто вхож в протокол - не напрягает).[/uquote]

Тут похоже UART вообще ни как не подходит, нужно программно ловить биты, это не сложно. UART может принять середину байта за начало данных и всё такое, в шумном канале работает плохо. Хотя можно в начале отправлять данные типа 0xFF несколько раз, тогда должен подстроится, там из всех данных одинокий старт бит, неправильно понять невозможно.

Если каждый 20й бит приходит с ошибкой, это отличный канал связи. Очень просто восстановить данные передавая их с небольшой избыточностью. В радиоканале то же самое всё.

[roman.com]

[uquote="SIM31",url="/forum/viewtopic.php?p=3441986#p3441986"]Если каждый 20й бит приходит с ошибкой, это отличный канал связи. Очень просто восстановить данные передавая их с небольшой избыточностью. В радиоканале то же самое всё.[/uquote]
Это ужасный канал связи! )) Это в каких это радиоканалах то же самое?)) Разве что только в специальных... типа Радиомодули на основе технологии LoRa... с исправлением ошибок.
В простых каналах (в подавляющем большенстве) при потери одного бита весь пакет пересылается повторно. Никто не будет заморачиваться из-за одного бита))
Используйте проверенные протоколы. Они все стандартные... Хоть по радио, хоть по проводам...
А вообще... идея связи по электросети - это мягко говоря извращение))

[Wladimir_TS]

Ну на самом деле сеть весьма зашумлена - любой коллекторный электродвигатель без сетьевого фильтра (старые советские дрели) глушит его на ура.

[SIM31]

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

[Wladimir_TS]

Если медленная телеметрия - тогда да.

[linuxdude]

[uquote="Wladimir_TS",url="/forum/viewtopic.php?p=3441251#p3441251"]Ну идея регулировки чуться сигналом с ЦАПа - не нова.[/uquote] Возможно, но мне не попадалась. Зато в радио попадались варианты когда операционник сам порог подстраивает, что не требует внимания МК. Но и не настраивается из прошивки.

Что до феррита, автор расписал в PDFе почему лишние сигналы срежутся. Низкую частоту не пустит конденсатор. Высокую - феррит, через него ВЧ не пролезет (на частоты выше нескольких МГц используют ВЧ ферриты, обычные поглощают энергию RF на перемагничивание, так что вместо работы core оно работает фильтром). Детальки многофункциональные, красиво.

Что до модуляции - UART МК заведен коммутировать 1.8МГц формируемые МК (PWM). Насколько я понимаю идею, отправка данных в UART вызывает довольно лобовую коммутацию этих 1.8МГц. Обычный OOK, типа того что в дешевых китайских радиомодулях на 315/433 получится, только почти все сделано железками МК.

[uquote="SIM31",url="/forum/viewtopic.php?p=3441986#p3441986"]Тут похоже UART вообще ни как не подходит, нужно программно ловить биты, это не сложно.[/uquote] Ну да, мне что-то такое пришло в голову. Для оптимизации нагрузки на МК можно попробовать обнаруживать preamble/magic, а основную часть пакета можно попробовать словить SPI или USART (в Sинхронном режиме). Клок конечно же локально синтезировать (требует кварцы с обоих сторон, иначе можно не те биты поймать, но кварц у мк есть). И тогда неизбежно примется нужное количество битов, если их отправили. То что часть будет битой - ну и ладно. С uart проблема в том что если его фрейминг собьется в середине пакета, выпадет сколько-то байтов в неизвестной позиции. Это делает проблематичным FEC, пакет идет в мусор, если канал шумный - не пролезет ни 1 пакет. Перепосылки пакета при сбое в каждом 20 бите не помогут, каждый пакет будет битым. FF починит сбой фрейминга, но кто сказал что он не произойдет снова? UART хорош лишь простотой и лобовой реализацией, но такая недружественность uart к FEC мне не нравится.

Возникает картинка в голове: таймер тикает килогерц на допустим 10 (10 kbps), в нем можно битики сэмплить. Если кварц принципиально хочется сэкономить, можно как в радиооткрывашках - кодирование 1 к 3, но скорость грохнется в 3 раза, и clock recovery сложнее с точки зрения софта. Актуально при тираже в миллион, когда экономия 1 кварца приносит сумку долларов.

В радиоканале то же самое всё.

Ну так я и посмотрел как делают протоколы для этого самого. С достаточной избыточностью можно вытянуть даже очень плохие условия. И все же для радио 5% BER считается "запредельным" в массе своей. Хотя возможно вы сигналы от космических аппаратов принимаете? У них то конечно свои понятия о качестве сигнала, когда передатчик в паре миллионов километров. Но в сети условия тепличные - 1.8МГц неплохо разлетится по проводам.

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

[SIM31]

Ну да, мне что-то такое пришло в голову. Для оптимизации нагрузки на МК можно попробовать обнаруживать preamble/magic, а основную часть пакета можно попробовать словить SPI или USART (в Sинхронном режиме). Клок конечно же локально синтезировать (требует кварцы с обоих сторон, иначе можно не те биты поймать, но кварц у мк есть). И тогда неизбежно примется нужное количество битов, если их отправили. То что часть будет битой - ну и ладно. С uart проблема в том что если его фрейминг собьется в середине пакета, выпадет сколько-то байтов в неизвестной позиции. Это делает проблематичным FEC, пакет идет в мусор, если канал шумный - не пролезет ни 1 пакет. Перепосылки пакета при сбое в каждом 20 бите не помогут, каждый пакет будет битым. FF починит сбой фрейминга, но кто сказал что он не произойдет снова? UART хорош лишь простотой и лобовой реализацией, но такая недружественность uart к FEC мне не нравится.

UART прекрасно сам синхронизируется, приходит старт бит и приемник "понимает" что именно с этого интервала времени начинается отсчет интервалов по битам. Там несколько процентов разницы в скорости вообще ни как не влияют.
Пакет не надо в мусор отправлять. Даже в древнем UART есть режим с битом четности, когда можно выделить сбойные байты в кадре и при следующей передаче из двух сбойных кадров собрать один корректный. Или из трех кадров, телеметрию можно сразу хоть сотней кадров отправить одинаковых, приемник разберется. Никакой сложной математики, старинный UART, бит четности в каждом байте и нормальная контрольная сумма. CRC32 например или аналогичное что-то. Рано или поздно дойдут данные даже если каждый второй байт с ошибкой.

Если есть желание заняться математикой, можно передавать данные в матрице, например 16*16 бит, и по столбикам и строкам считать бит четности для каждого столюца и строки. Если в пакете один сбойный бит, мы его находим по "горизонтали" и "вертикали" и корректируем. Так можно исправить и 16 сбойных бит за раз, только они должны быть все в разных столбцах и столбиках. Передали 256 бит, избыточной информации 32 бита плюс контрольная сумма.

Или еще проще, передать пакет 3 раза, и смотреть чтобы биты были одинаковые тоже 2 или 3 раза. Шумы повреждают отдельные биты и полезный сигнал рано или поздно пройдет, даже если повреждает каждый второй бит, тут можно работать когда энергия шума выше энергии полезного сигнала. Но избыточность многократная тут.

Тут проще несколько строк кода написать, чем на словах ))

[Wladimir_TS]

[uquote="linuxdude",url="/forum/viewtopic.php?p=3446025#p3446025"]Возможно, но мне не попадалась. Зато в радио попадались варианты когда операционник сам порог подстраивает, что не требует внимания МК. Но и не настраивается из прошивки.[/uquote]

В промышленных Х-10 устройствах так встречал. Только там в качестве ЦАП фаза сигнала прихдящего на интегратор относительно "0" сети. А с выхода интегратора - собственно на регулируемый усилитель.

[uquote="linuxdude",url="/forum/viewtopic.php?p=3446025#p3446025"]Что до феррита, автор расписал в PDFе почему лишние сигналы срежутся. Низкую частоту не пустит конденсатор. Высокую - феррит, через него ВЧ не пролезет (на частоты выше нескольких МГц используют ВЧ ферриты, обычные поглощают энергию RF на перемагничивание, так что вместо работы core оно работает фильтром). Детальки многофункциональные, красиво.[/uquote]

Пара мегагерц через ширпотребовский феррит проходит. А выше давить если только наводки от близкорасположенных РЛС

[uquote="linuxdude",url="/forum/viewtopic.php?p=3446025#p3446025"]Что до модуляции - UART МК заведен коммутировать 1.8МГц формируемые МК (PWM). Насколько я понимаю идею, отправка данных в UART вызывает довольно лобовую коммутацию этих 1.8МГц. Обычный OOK, типа того что в дешевых китайских радиомодулях на 315/433 получится, только почти все сделано железками МК.[/uquote]

Мдаааа - побился старт или стоп - прощай пакет - печально.

[uquote="SIM31",url="/forum/viewtopic.php?p=3441986#p3441986"]Тут похоже UART вообще ни как не подходит, нужно программно ловить биты, это не сложно. Ну да, мне что-то такое пришло в голову. Для оптимизации нагрузки на МК можно попробовать обнаруживать preamble/magic, а основную часть пакета можно попробовать словить SPI или USART (в Sинхронном режиме). Клок конечно же локально синтезировать (требует кварцы с обоих сторон, иначе можно не те биты поймать, но кварц у мк есть).[/uquote]

В SPI у AVR по крайней мере плавно подстраивать частоту приема не выйдет. А крутить через варикап собственную тактовую - оригинально - но как-то через не тот проход.

Может взглянуть в сторону протоколов ИК ПДУ - там во первых в начале пакета часто идет пачка импульсов для подстройки АРУ и синхронизации приемника. А вообще загрузка МК невелика - можно и программно ловить. Чай не на 8035 делается.

[uquote="SIM31",url="/forum/viewtopic.php?p=3441986#p3441986"]И тогда неизбежно примется нужное количество битов, если их отправили. То что часть будет битой - ну и ладно. С uart проблема в том что если его фрейминг собьется в середине пакета, выпадет сколько-то байтов в неизвестной позиции. Это делает проблематичным FEC, пакет идет в мусор, если канал шумный - не пролезет ни 1 пакет. Перепосылки пакета при сбое в каждом 20 бите не помогут, каждый пакет будет битым. FF починит сбой фрейминга, но кто сказал что он не произойдет снова? UART хорош лишь простотой и лобовой реализацией, но такая недружественность uart к FEC мне не нравится.[/uquote]

Не особ надежен UART - кстати сбой возможен при импульсной помехе в середине информационного (битового) импульса. Тут по службе мучаюсь с RS422. На столе работает, на объекте - шищЪ - каждая 3 посылка битая (хорошо что протокол с перезапросами). Скорость правда 256 кБит.

[uquote="SIM31",url="/forum/viewtopic.php?p=3441986#p3441986"]Возникает картинка в голове: таймер тикает килогерц на допустим 10 (10 kbps), в нем можно битики сэмплить. Если кварц принципиально хочется сэкономить, можно как в радиооткрывашках - кодирование 1 к 3, но скорость грохнется в 3 раза, и clock recovery сложнее с точки зрения софта. Актуально при тираже в миллион, когда экономия 1 кварца приносит сумку долларов.[/uquote]

В некоторых применениях, которыми я имею дело идет 16 опросов на 1 период битовой посылки. Позволяет вытягивать инфу из каналов, которые дают паразитную фазовую модуляцию.
Но там суровые ПЛИС.Да и сам метод кодирования ДСПшный увы.

[uquote="linuxdude",url="/forum/viewtopic.php?p=3446025#p3446025"]Ну так я и посмотрел как делают протоколы для этого самого. С достаточной избыточностью можно вытянуть даже очень плохие условия. И все же для радио 5% BER считается "запредельным" в массе своей. Хотя возможно вы сигналы от космических аппаратов принимаете? У них то конечно свои понятия о качестве сигнала, когда передатчик в паре миллионов километров. Но в сети условия тепличные - 1.8МГц неплохо разлетится по проводам.[/uquote]

Для КВ канала избыточность более чем вдвое. И то - все оооочень сложно и неоднозначно на скоростях в 1200 бод всего. Но на тут сторону шарика.


[uquote="linuxdude",url="/forum/viewtopic.php?p=3446025#p3446025"]А что до коллекторного двигателя - так он и в эфир гадит хорошо. В широком спектре. А провода еще и антенной работают. Но какая мощность излучения попадет в порог чувствительности схемы и как это соотнесется с мощностью сигнала - да на самом деле вопрос. Большая часть излучения коллекторника не попядет в полосу схемы. И как то что пролезло соотнесется с сигналом передатчика - вопрос любопытный.[/uquote]

Тут или уходить по частоте вверх за 1 МГц и получим тот-же эзернет по проводам (были такие провайдеры), соответственно на входе фильтр тупо режет все ниже. Или резко увеличивать избыточность информации.. Вообще-то надо сначала определиться с ТЗ - какой поток мы хотим передавать, как далеко, какая организация сети.

[Ivanoff-iv]

[uquote="SIM31",url="/forum/viewtopic.php?p=3446354#p3446354"]Шумы повреждают отдельные биты и полезный сигнал рано или поздно пройдет, даже если повреждает каждый второй бит, тут можно работать когда энергия шума выше энергии полезного сигнала. Но избыточность многократная тут.

Тут проще несколько строк кода написать, чем на словах ))[/uquote]
НАПИШИ! и подавай на нобелевку!!! это ж если каждый 2й бит неправильный... генератор случайных чисел с такой вероятностью работает. прицепил ГСЧ к приемнику (даже антенна не нужна) и передавай сигнал хоть с альфы центавра!

[As]

Нынешние HDD работают при ошибках чтения под 5% - и ничего, наружу ни одна ошибка не просачивается...
Есть же помехоустойчивое кодирование, с перемежением - почему бы не порыться в этом направлении?

[SIM31]

[uquote="Ivanoff-iv",url="/forum/viewtopic.php?p=3446523#p3446523"]НАПИШИ! и подавай на нобелевку!!! это ж если каждый 2й бит неправильный... генератор случайных чисел с такой вероятностью работает. прицепил ГСЧ к приемнику (даже антенна не нужна) и передавай сигнал хоть с альфы центавра! [/uquote]

Ну да, тут надо уточнить что правильных битов должно быть более 50%, хотя бы 51%.
Или неправильные биты должны группироваться во времени в большие мусорные кадры, давая пройти потоку корректных байт и кадров. Но тут математическая абстракция ))

Добавлено after 1 hour 46 minutes 19 seconds:
[uquote="Wladimir_TS",url="/forum/viewtopic.php?p=3446395#p3446395"]В некоторых применениях, которыми я имею дело идет 16 опросов на 1 период битовой посылки. Позволяет вытягивать инфу из каналов, которые дают паразитную фазовую модуляцию.
Но там суровые ПЛИС.Да и сам метод кодирования ДСПшный увы.[/uquote]

Суровые ПЛИС нужны на скоростях работы в 300 МГц. У нас медленный канал связи и программно можно делать всё то же самое. Еще проще даже можно делать, если период бита Т, то отдельно фиксировать изменение сигнала, и через Т/2 предполагаемый истинный сигнал. На микроконтроллере это всё замечательно работает на прерываниях и может скорости до 115 кбит программно обрабатывать, даже с фазовыми искажениями, по любому фронту приемник подстроится. Самый сложный случай когда байт FF, один стартовый бит и более ничего, подстраиваться сложнее.

Это если нужно именно UART программно обрабатывать в ожидании фазовых искажений (а их тут не будет). Я такое сделал программно ради интереса, работает и Proteus вполне себе.

Если UART не нужен, можно манчестерским кодом данные передавать биты 01 и 10, обрабатывать намного проще. И аналоговая часть проще, постоянной составляющей нет, никакие пороги не нужны.

В SPI у AVR по крайней мере плавно подстраивать частоту приема не выйдет. А крутить через варикап собственную тактовую - оригинально - но как-то через не тот проход.

Ну SPI аппаратный там до 400 кбит/с работает, нам опять же такие скорости не нужны. Даже если нужно было бы, крутили бы программно скорость RC генератора встроенного

[roman.com]

Технология прямого расширения спектра нечувствительна к импульсным помехам.

https://strij.tech/publications/tehnolo ... -lora.html

... "позволяет демодулировать сигналы на уровне до -20 дБ относительно уровня шумов"

https://strij.tech/publications/tehnolo ... -lora.html

и т.д. и т.п. ))

[linuxdude]

[uquote="SIM31",url="/forum/viewtopic.php?p=3446354#p3446354"]UART прекрасно сам синхронизируется, приходит старт бит и приемник "понимает" что именно с этого интервала времени начинается отсчет интервалов по битам.[/uquote] Старт и стоп могут быть ложными - помехи же. Будет framing error. Потом в проводе смесь сигнала и помех. Запросто засинхрится на середину байта или помеху. Асинхронное же - дальше что-то примет, хвост пакета будет кривой. Четность - слабая штука. Две ошибки в байте - и все как бы ОК. Не расчитано на помехи.

Пересыл несколько раз - простейший FEC, мажоритарный принцип. Скорость в разы ниже, варианты пакета хранить надо, RAM кушает. Если помех много - с UART может не оказаться ни 1 правильной версии хвоста пакета и фокус не сработает. Для синхронных протоколов так делали, пока лучше не придумали.

С матрицей - тоже какой-то известный простой FEC. В случае UARTесли байтов вдруг не 32 (256 битов) из-за сбоя фрейминга, удачи понять где какие строки и столбцы. И UART размножает ошибки, пара неудачных переворотов битов "апгрейдятся" до framing error с вылетом/врезкой сколько-то байтов в середине пакета и проч. Для синхронного протокола - почему нет? У меня правда RS(223,255) есть, я его как бенч на F103 запустил (в оригинале писючная либа, кто-то обрубил ее под DSPIC, а я на F100/F103 перетащил). Там не обязательно 223 байта слать, декодер умеет "вообразить" ноли если надо меньше, так можно варьировать соотношения FEC и данных не меняя алгоритм. Если сделать пакет 64 байта, слать 32 байта данных + 32 байта RS, переживет 25% сбоев (даже 50%, если точно знать где сбои). При 50% оверхеда, что явно лучше мажора 2 из 3. Но про внешние хидеры придется забыть, всегда 32 байта, всегда принимаем, декодируем и только потом узнаем - а надо ли нам этот пакет. Хидер не защищенный FEC при 25% сбоев умрет, остальное уже не важно. Ну и на атмеле FEC надо попроще. Видел у кого-то хэмминга. Не RS конечно, но по сравнению с битом parity...

[uquote="Wladimir_TS",url="/forum/viewtopic.php?p=3446395#p3446395"]В промышленных Х-10 устройствах так встречал. Только там в качестве ЦАП фаза сигнала прихдящего на интегратор относительно "0" сети. А с выхода интегратора - собственно на регулируемый усилитель.[/uquote] В "простых радио" тупо амплитуда (OOK) - сигнал усредняют RC, операционник усиливает значение относительно этого. Требует пару деталек, просто и логично. В результате можно поймать и слабый сигнал и сильный. Преамбула в радиопротоколах кроме всего прочего позволяет подстроить усиление под сигнал системы с которой намечается обмен. По минимуму это даже RC цепочка сделает. А программно подкручивать может иметь свои плюсы, RC все нюансы не объяснишь, а софту - можно.

Что до пары МГц - у автора того PLC модема задумка работать на 1.8МГц (160 метров) - там в самый раз.

Варикапы и подстройку - нафиг . Уход на 1 бит за допустим 255 байтов пакета (максимум того RS(223,255), etc) требует разбег ~490 PPM (1/2040). Кварцы, даже хреновые и с разбегом в разные стороны на концах линка - точнее. Без подстройки. На отправку как мне кажется прокатит зарядить в SPI (или USART в синхронном режиме) блок из preamble, magic и данные - сделать все кратным байту. С приемом сложнее - надо свой клок завести на вход spi/usart'а и врубать его в момент когда по преамбуле/магику прикинули что пора. Чтобы проще в софте жевать можно сделать их как битрейт/4 или /8. Т.е. преамбула не 10101010 на основном битрейте, а допустим 11111111 00000000 ... и при поиске - отлов в 8 раз реже. Что по идее разгрузит "софтварную" часть. А когда нашли - врубаем свой клок заведенный на клок SPI и на полной скорости загребаем биты. Но да, немного сложнее чем читать из UART-а. По минимуму на небольшой скорости можно и просто прерывание от таймера пустить и слать или получать в нем очередной бит. Если тикание таймера завязано на кварц - в каком месте это может обломаться?