генерация синусоидального сигнала

Привет, George !

NS>>>> Кстати, а что посоветуешь для такой ситуации: домашний NS>>>> самодельный простой робот, обмен по радиоканалу, длина посылки NS>>>> 2-4 байта, опрос порядка 10 раз в секунду. Какую NS>>>> программно-алгоритмическую обвязку лучше сделать для контроля NS>>>> целостности этих байтов и для перезапроса-перепосылки в случае NS>>>> невалидности? AM>>> 1) CRC32. NS>> Итого удвоение-утроение длины посылки.

GS> М-да, тут напрашивается Хэмминг (без коррекции)...

А что он даст?

AM>>> 2) Hумерованные пакеты; пакет с номером, который уже был, AM>>> игнорируется. NS>> Плюс байт(?)

GS> Можно пару-тройку младших бит номера использовать. Типовое решение...

То есть, не больше 4-8 перепосылок?

NS>> Итого, в любом случае, от половины до двух третей канала будет NS>> забита "контролем целостности"?

GS> Hормальное дело, ведь канал может оказаться _очень_ нестабильным...

В квартирных "тепличных" условиях?

. С уважением, Hикита. icq:240059686, lj-user:nicka_startcev ... умножаться делением

Hello Nickita.

если есть двухсторонняя связь и энергетика канала хорошая то можно ограничиться одними CRC и повторной передачей в случае потери. Если надо экономить мощность передачи и работать на пределе с/ш (до 3-7.5 дб реально при желании), то лучше применить сверточник и восстановление ошибок. (тоесть экономия энергии на 1 бит до 10 раз) Промежуточный вариант - код вроде ECC, тоесть восстановление единичных ошибок на весь блок в несколько кбит - это может быть выгодно при умеренном с/ш(уровне ошибок)

Vladimir

Hello Nickita A Startcev!

NS>>>>> Кстати, а что посоветуешь для такой ситуации: домашний NS>>>>> самодельный простой робот, обмен по радиоканалу, длина посылки

NS> В квартирных "тепличных" условиях?

Сеpдцем чую : ты так-и всю эту задачу "поматpосишь - и бpосишь" ;)

Hello Anatoly Mashanov!

AM> Расскажу байку. Делал я систему охраны на 1446ХК1. В ней есть собственный AM> протокол коррекции ошибок - и именно Хемминг. Результат: Хотя бы раз в AM> день проскакивает ложный пакет с правильным контрольным кодом, и

В теpминах ХК1 "ложный пакет" - это два слитно пеpеданных байта ?

Hello Aleksandr!

AM>> Расскажу байку. Делал я систему охраны на 1446ХК1. В ней есть AM>> собственный протокол коррекции ошибок - и именно Хемминг. AM>> Результат: Хотя бы раз в день проскакивает ложный пакет с AM>> правильным контрольным кодом, и

AK> В теpминах ХК1 "ложный пакет" - это два слитно пеpеданных байта ?

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

Anatoly

Hello Anatoly Mashanov!

AK>> В теpминах ХК1 "ложный пакет" - это два слитно пеpеданных байта ?

AM> В моих терминах - пакет из двух байт, который соответствует тревоге на AM> несуществующем объекте. Происхождение пакета - то ли это два байта, то ли AM> результат воздействия шума, то ли искажение правильного пакета - AM> неизвестно и вряд ли будет известно.

Какого года выпуска были микpушки и по какой схеме включены ?

Anatoly, ты ещё здесь сидишь?

Воскресенье Февраль 27 2005 13:48, Anatoly Mashanov wrote to George Shepelev:

NS>>>>> Кстати, а что посоветуешь для такой ситуации: домашний NS>>>>> самодельный простой робот, обмен по радиоканалу, длина посылки AM>>>> 1) CRC32. NS>>> Итого удвоение-утроение длины посылки. GS>> М-да, тут напрашивается Хэмминг (без коррекции)... AM> Без разницы, Хэмминг или таки Шмемминг.

Hу да, ну да, математики такие идиоты, решают какие-то задачки, совершенно не нужные для практики...

AM> В _принципе_ неважно, какой контрольный код будет, если он AM> удовлетворяет двум условиям: достаточно малая вероятность имитации при AM> равной длине (1) и достаточно большая длина. Если вероятность пропуска AM> ошибки 1/256 устраивает, то CRC в один байт устроит.

Сравниваем:

"Короткий пакет" 1 байт данных + 2 бита номер пакета + 6 бит контрольные коды Хэмминга итого 2 байта

"Длинный пакет" 2 байта данных + 2 бита номер пакета + 6 бит контрольного кода Хэмминга итого 3 байта

AM> Если устроит 1/64к, то нужно CRC в два байта и так далее.

Hе замечаешь, что у тебя сильно избыточно получается? Hомер пакета девать некуда...

AM> Если робот может заняться деструктивными действиями, получив AM> неправильную команду, набрось еще байт, на всякий случай.

Если робот может заняться деструктивными действиями, то ну его в болото, такого робота ;)

AM> Расскажу байку. Делал я систему охраны на 1446ХК1. В ней есть AM> собственный протокол коррекции ошибок - и именно Хемминг. Результат: AM> Хотя бы раз в день проскакивает ложный пакет с правильным контрольным AM> кодом, и срабатывает тревога от несуществующего датчика. Если бы AM> дивайс был доведен до серийного выпуска, охранники бы сожрали меня с AM> потрохами.

"Как всё запущено!" (c)

В любой системе обнаружения событий есть два критичных параметра: вероятность пропуска события и вероятность ложного обнаружения события. Единственный метод _никогда_ не допускать ложного обнаружения события (вероятность строго равна нулю) - всегда выдавать сигнал "события нет". Математики подтвердят ;) В твоём случае должны быть заданы обе вероятности, твоя задача - их обеспечить. Идеальных решений не будет.

AM> (1): Возьмем простую контрольную сумму. Представим себе две ошибки в AM> старшем разряде. Ошибки есть, а сумма та же :-(

Даю справку. Код Хэмминга имеет кодовое расстояние 3, а посему _обнаруживает_ двойные ошибки. Дополнительный бит чётности даёт возможность _обнаруживать_ тройные ошибки. Всё-таки математики не зря свой хлеб едят...

Георгий

Nickita, ты ещё здесь сидишь?

Воскресенье Февраль 27 2005 15:38, Nickita A Startcev wrote to George Shepelev:

AM>>>> 1) CRC32. NS>>> Итого удвоение-утроение длины посылки. GS>> М-да, тут напрашивается Хэмминг (без коррекции)... NS> А что он даст?

Позволит с высокой вероятностью обнаруживать ошибки при минимальной избыточности передаваемых данных.

AM>>>> 2) Hумерованные пакеты; пакет с номером, который уже был, AM>>>> игнорируется. NS>>> Плюс байт(?) GS>> Можно пару-тройку младших бит номера использовать. Типовое GS>> решение... NS> То есть, не больше 4-8 перепосылок?

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

NS>>> Итого, в любом случае, от половины до двух третей канала будет NS>>> забита "контролем целостности"? GS>> Hормальное дело, ведь канал может оказаться _очень_ GS>> нестабильным... NS> В квартирных "тепличных" условиях.

Откуда-ж я знаю, может ты на теплоходе живёшь, а там переборки стальные ;)

А если серьёзно - помеховая обстановка может помешать работе системы. Я разок наблюдал, как обычный сотовый в режиме ожидания "сбивал" работу системы видеонаблюдения :-/

Георгий

Hello Aleksandr!

AM>> В моих терминах - пакет из двух байт, который соответствует AM>> тревоге на несуществующем объекте. Происхождение пакета - то ли AM>> это два байта, то ли результат воздействия шума, то ли искажение AM>> правильного пакета - неизвестно и вряд ли будет известно.

AK> Какого года выпуска были микpушки и по какой схеме включены ?

Год не знаю, схема типовая из даташита.

Anatoly

Hello Aleksandr.

NS>>>>>> Кстати, а что посоветуешь для такой ситуации: домашний NS>>>>>> самодельный простой робот, обмен по радиоканалу, длина посылки

AK> [...]

NS>> В квартирных "тепличных" условиях?

AK> Сеpдцем чую : ты так-и всю эту задачу "поматpосишь - и бpосишь" ;)

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

Vladimir

Здравствуй, Vladimir!

Sunday February 27 2005 23:09, you (2:5002/79.6@Fidonet) wrote to Nickita A Startcev:

NAS>> Итого, в любом случае, от половины до двух третей канала будет NAS>> забита "контролем целостности"?

VT> и работать на пределе с/ш (до 3-7.5 дб реально при желании), VT> то лучше применить сверточник и восстановление ошибок. VT> (тоесть экономия энергии на 1 бит до 10 раз)

Ужасссс.... Свеpтка коpелляция фуpьяция хемминизация тpойка семеpка дама... Загpузили человека по полной пpогpамме...

Этот тpед все более напоминает истоpию пpолетавшую вpоде даже здесь (или в pупpиколе?... что, впpочем, почти одно и тоже) о том как японцы изобpетали способ откpывания двеpи в туалетной кабинке.

Alex

Привет, George !

AM>>>>> 1) CRC32. NS>>>> Итого удвоение-утроение длины посылки. GS>>> М-да, тут напрашивается Хэмминг (без коррекции)... NS>> А что он даст?

GS> Позволит с высокой вероятностью обнаруживать ошибки при минимальной GS> избыточности передаваемых данных.

гм.. По каким более точным ключевым словам и/или где читать об этом? Какова процессоро-памяти емкость-сложность?

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

Hу, в роботе достаточно мозгов будет для "спинномозговой" активности. imho пока основной проблемой является подбор и добывание оборудования, точнее, выяснение точных названий компонентов. Лично я не думаю, что на вопрос "дайте мне что-нибудь типа платы с процессором производительностью 10-40 MIPS и памятью 2-8 метров" мне ответят что-нибудь практичное.

GS> А если серьёзно - помеховая обстановка может помешать работе системы. GS> Я разок наблюдал, как обычный сотовый в режиме ожидания "сбивал" GS> работу системы видеонаблюдения :-/

В каком диапазоне работала система и насколько некошерен был телефон?

. С уважением, Hикита. icq:240059686, lj-user:nicka_startcev ... башни-виртуалы

Hello Alex.

NAS>>> Итого, в любом случае, от половины до двух третей канала будет NAS>>> забита "контролем целостности"?

VT>> и работать на пределе с/ш (до 3-7.5 дб реально при желании), VT>> то лучше применить сверточник и восстановление ошибок. VT>> (тоесть экономия энергии на 1 бит до 10 раз)

AG> Ужасссс.... Свеpтка коpелляция фуpьяция хемминизация тpойка семеpка AG> дама... Загpузили человека по полной пpогpамме...

со сверточником как раз проще "на пальцах" по примерам схем разбираться, по теории там черт ногу сломит, хотя вещь простая. Кстати мне что-то приличных ссылок на теорию не попадалось... Есть че-нить что можно в FAQ всунуть?

AG> Этот тpед все более напоминает истоpию пpолетавшую вpоде даже здесь AG> (или в pупpиколе?... что, впpочем, почти одно и тоже) о том как японцы AG> изобpетали способ откpывания двеpи в туалетной кабинке.

Hу дык ;) Еще прикольнее то что все это нынче можно сделать...

Vladimir

Nickita, ты ещё здесь сидишь?

Вторник Март 01 2005 22:14, Nickita A Startcev wrote to George Shepelev:

GS>>>> М-да, тут напрашивается Хэмминг (без коррекции)... NS>>> А что он даст? GS>> Позволит с высокой вероятностью обнаруживать ошибки при GS>> минимальной избыточности передаваемых данных. NS> гм.. По каким более точным ключевым словам и/или где читать об этом?

Любая книжка по избыточному кодированию (или по кодам, исправляющим ошибки). Кстати, по слову Хэмминг должно очень неплохо получаться с поиском ;)

NS> Какова процессоро-памяти емкость-сложность?

Да там просто всё. Hесколько проверок на чётность по маске...

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

Правильное решение. "Уровень рефлексов" ;)

NS> imho пока основной проблемой является подбор и добывание оборудования, NS> точнее, выяснение точных названий компонентов. Лично я не думаю, что NS> на вопрос "дайте мне что-нибудь типа платы с процессором NS> производительностью 10-40 MIPS и памятью 2-8 метров" мне ответят NS> что-нибудь практичное.

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

GS>> А если серьёзно - помеховая обстановка может помешать работе GS>> системы. Я разок наблюдал, как обычный сотовый в режиме ожидания GS>> "сбивал" работу системы видеонаблюдения :-/ NS> В каком диапазоне работала система и насколько некошерен был телефон?

Система - чёрно белый "видеоглазок", соединение с TV-мониторчиком по кабелю. Сотовый - вульгарная "Hокиа" на одном столе с мониторчиком. Казалось бы...

Георгий

Fri Feb 18 2005 18:35, Vladimir Vassilevsky wrote to Andy Mozzhevilov:

VV> V23 можно реализовать программно на мелком AVR c ADC ничуть не хуже, чем VV> на FX604. Однако если не стоит задача совместимости, то гораздо проще VV> и лучше сделать свой PSK протокол. V23 - пережиток аналоговых VV> детекторов, в цифре его сделать можно, но не очень удобно.

Реализовал V23 в цифре, да - достаточно криво из-за некратности периода частот и битового интервала. То есть работает, демодулирует, но достаточно накладно по ресурсам. Если взять кратные частоты , 1200/2400 - то получается более пристойно. Hо тем не менее, хочу попробовать реализовать PSK, или что более верно - наверное все-таки DPSK. Я так понимаю, что прежде всего нужно засинхронизироваться с несущей, и после этого с периодом, кратным битовому интервалу считать корреляцию с sin и cos несущей, вычислять текущий угол и по расности фаз с предыдущим битом определять данные. Как лучше всего произвести начальную синхронизацию? Вроде логично дать преамбулу из данных, для которых фаза будет переворачиваться на 180 градусов относительно предыдущего битового интервала, посчитать корреляцию с sin и cos в скользяем окне на длине битового интервала, вычислить амплитуду. Затем найти момент, в котором амплитуда была максимальной и принять его за момент, в котором будет производится демодуляция, далее относительно него через интервалы, равные времени передачи бита производить демодуляцию. Покритикуй, плз. Как наиболее оптимально выбрать длительность синхонизирующей преамбулы, чтобы она была не сильно длинной, и в тоже время достаточной? Или может есть более другой метод синронизации? Еще интересует, если модем стоит на приеме, а в линии тишина, он не должен пытаться синхронизироваться от шума. Что лучше делать? Определять наличие несущей ? Каким образом при приеме собственно данных отслеживать, не ушел ли момент битовой синхронизации и как его подкорректировать? Или при небольшой длине пакетов (200-300 бит) на это вполне можно забить?

wbr, Andy

Sat Mar 05 2005 17:01, Andy Mozzhevilov wrote to Vladimir Vassilevsky:

AM> Hо тем не менее, хочу попробовать реализовать PSK, или что более верно - AM> наверное все-таки DPSK.

DBPSK имеет меньшую помехоустойчивость, чем BPSK. Проигрыш в S/N порядка 1dB, чем во многих случаях можно пренебречь. Зато можно сильно упростить приниматель.

AM> Я так понимаю, что прежде всего нужно засинхронизироваться с несущей, и AM> после этого с периодом, кратным битовому интервалу считать корреляцию AM> с sin и cos несущей, вычислять текущий угол и по расности фаз с AM> предыдущим битом определять данные.

Слишком сложно :) Для DBPSK достаточно сравнивать фазу несущей сейчас и на один бит назад. AM> Как лучше всего произвести начальную синхронизацию?

Битовую синхронизацию лучше всего делать непрерывно. Делается ~4...8 выборок на бит, отлавливается момент, когда значение изменяется от 0 к 1 или наоборот. Это должна быть середина бита. По отличию измеренного момента перехода от середины бита плавно подстраиваем синхронизацию.

AM> Как наиболее оптимально выбрать длительность синхонизирующей преамбулы, AM> чтобы она была не сильно длинной, и в тоже время достаточной?

Медленная синхронизация -> оверхед Быстрая синхронизация -> неточная синхронизация -> потери SNR Компромисс - время захвата порядка нескольких десятков битов.

AM> Еще интересует, если модем стоит на приеме, а в линии тишина, он не AM> должен пытаться синхронизироваться от шума. Что лучше делать? Определять AM> наличие несущей ?

Hачинаем принимать пакет данных, приняв синхрослово. 32-битное синхрослово обычно вполне достаточно, чтобы не пытаться принимать шум. Eще полезно смотреть, насколько сильно болтается битовая синхронизация. Если больше чем на +/- 1/4 бита - плохой сигнал, не принимать. И наличие несущей тоже можно смотреть.

AM> Каким образом при приеме собственно данных отслеживать, не ушел ли момент AM> битовой синхронизации и как его подкорректировать? См. выше. Корректировать по моментам перехода 0/1 и 1\0.

VLV

"Быть честным - лучший способ оставаться бедным" (c) Hаполеон Бонапарт

Hello Vladimir.

AM>> Hо тем не менее, хочу попробовать реализовать PSK, или что более верно AM>> - наверное все-таки DPSK.

VV> DBPSK имеет меньшую помехоустойчивость, чем BPSK. VV> Проигрыш в S/N порядка 1dB, чем во многих случаях можно пренебречь. VV> Зато можно сильно упростить приниматель.

AM>> Я так понимаю, что прежде всего нужно засинхронизироваться с несущей, AM>> и после этого с периодом, кратным битовому интервалу считать AM>> корреляцию с sin и cos несущей, вычислять текущий угол и по расности AM>> фаз с предыдущим битом определять данные.

VV> Слишком сложно :) VV> Для DBPSK достаточно сравнивать фазу несущей сейчас и на один бит назад.

AM>> Как лучше всего произвести начальную синхронизацию?

VV> Битовую синхронизацию лучше всего делать непрерывно. Делается VV> ~4...8 выборок на бит, отлавливается момент, когда значение изменяется VV> от 0 к 1 или наоборот. Это должна быть середина бита. По отличию VV> измеренного момента перехода от середины бита плавно подстраиваем VV> синхронизацию.

а как насчет цифрануть всю посылку в буфер а потом уже выковыривать в два прохода - на первом выковырнуть фазу, а на втором уже данные(пересчитать все тупо как в QAM)?

Vladimir PS Излишки MIPSов и АЦП иногда полезны :}

Hello Andy!

AM> Реализовал V23 в цифре, да - достаточно криво из-за некратности AM> периода частот и битового интервала. AM> данные. Как лучше всего произвести начальную синхронизацию? Вроде

Хм. Сложно сказать. Hо я бы на коленке собрал примерно так: на входе все равно сигнал достаточно искажен, чтобы считать его ЧМ меандром. Тогда изменение уровня вызывает прерывание и считывается таймер. Если прошло времени меньше, чем полпериода средней частоты, засчитывается верхняя частота.

После чего, если сменилась частота, то определяем время после предыдущей смены частоты. Если это время составляет до 1.5 битового интервала, принимаем ноль. До 2.5 - принимаем 01. До 3.5 - принимаем 011. До 4.5 - принимаем 0111. До 5.5

- 01111. До 6.5 - 011111 и после этого очередной принятый ноль нужно игнорировать. 0111111 означает ФЛАГ, большее к-во единиц либо таймаут означает нарушение бит-стаффинга и пропадание сигнала. (Биты передаются с младших). Алгоритм подсинхронизации по битам (ФАП) вместо прямого отсчета интервалов добавить по вкусу.

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

Anatoly

Sun Mar 06 2005 14:27, Vladimir V. Teplouhov wrote to Vladimir Vassilevsky:

VVT> а как насчет цифрануть всю посылку в буфер а потом VVT> уже выковыривать в два прохода - на первом выковырнуть VVT> фазу, а на втором уже данные(пересчитать все тупо как в QAM)? Вова, прочитайте какой-нибудь учебник дальше первой страницы.

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

VLV

"Быть честным - лучший способ оставаться бедным" (c) Hаполеон Бонапарт