Быстрое сжатие без потерь, реализация в FPGA Опции

[RobFPGA]

Приветствую!

Озадачили меня вот такой задачкой

Требуется в реалтайме, без потерь, ужать поток данных с двухканального АЦП с 250 Mb/sec
хотя бы до 200 Mb/sec. Так как на плате узкое место - PCI контроллер имеет максимум 240 Mb/sec.
Проблема усугубляется тем что сами данные - "музыка звездного неба" даные радиотелескопа с полосой 8-30 MHz (частота оцифровки 62 МНz).

Из доступных ресурсов - часть Virtex4, DSP 6416 плюс RAM на 2 секунды полета.

Беглый обзор вариантов компресии определенности не принес.
Подскажите - в какую сторону копать. Есть ли где примеры (реализации) подобного.

Удачи! Rob.

[eugen_pcad_ru]

Рекомендую:
Попробуйте сжать такой объем данных в постреальном режиме времени любым архиватором.
Если сжатие получится приличное, то имеет смысл рассматривать вопрос дальше.
Если нет (скажем, ужмет на 10-20%), то ничего без потери качества у Вас не выйдет.

[slog]

А не проще PCI заменить на PCI-E?

[DmitryR]

Что-то у меня арифметика не сходится: частота оцифровки 62МГц, а с двух каналов получается 250 мегабод? Двухразрядный АЦП, что ли?

[litv]

Сжатие же нужно ГАРАнтированное. Вдруг данные примут другой вид, плохосжимаемый(чисто обнаружен НЛО), и данные опять не вошли в полосу ?
Может такую идею - сделайте БПФ в ПЛИС. На время расчета БПФ пишите из буфера. Раза в два можно гарантированно снизить поток выходных данных. Кстати если вычислить БПФ до значения с логарифмом - вообще 8 бит хватит на выходе(типа 256 дБ).

[EvgenyNik]

Как Вам такой вариант? (работает для гладких сигналов)
Исходные данные - 16 бит/отсчёт АЦП
Измеренные значения (для 1 канала): N0, N1, N2, N3, N4, N5, N6, N7
Вычисляем dN1 = N1 - N0 смотрим - помещается ли результат в 7 бит (с учетом знака).
Если dN1 не помещается, то округляем N1 до старших 7 бит N1 = r[N1; 15..9], приравниваем dN1 округлённому значению N1 и взводим для dN1 флаговый 8-ой бит абсолютного значения в единичку aN1 = 1.
Вычисляем dN2 = N2 - N1 и так далее, причём здесь используем уже округлённое значение N1, если оно является таковым.
Получаем последовательность:
N0[15..0], aN1[15]..dN1[14..8]..aN2[7]..dN2[6..0], aN3[15]... и т.д.
Вычисляем CRC8 для всего этого, если нужно, и помещаем его в слово: aN7[15]..dN7[14..8]..CRC8[7..0]
Передаём эту последовательность.
Приёмник получает данные:
N0 - запомнил,
aN1 - по нему смотрит что передано - приращение от N0 до N1 или старшая часть N1.
Если aN1 == 0, то N1 = N0 + dN1
Иначе N1 = dN1 * 256
aN2... N2 = N1 + dN2 или N2 = dN2 * 256 и т.д.
---
Если сигнал гладкий и приращения укладываются в 7 бит, то потерь не будет вообще. Если же на каком-то интервале есть резкий перепад сигнала, то будут потери только на округление этого отсчёта. Последующие данные будут переданы без потерь.
Таким образом:
исходные данные 128 бит.
переданные (с учетом CRC8) 80 бит.
Сжатие в 1,6 раза для 8 отсчетов по 16 бит.

[eugen_pcad_ru]

Степень сжатия в существенной степени зависит от структуры сигнала.
Если архиватором не удастся ничего сделать (а это скорее всего), то без потери ничего не получится.
Все остальные методы приводят либо к потере качества (типа АДИКМ и т.п.) либо к расширению аппаратных средств (переход на PCI-E, распараллеливание на несколько устройств и т.п.).
Необходим предварительный анализ сигнала.

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

[Fat Robot]

Ответ рабоче-крестьянский (отталкиваясь от аппаратуры):
Попробуйте на ПЛИС реализовать ITU-T v42bis. (Можно украсть у Mentor: есть на ftp) Только сначала в оффлайне протестируйте на модели, но с большим объемом реальных данных и с фиксацией макс. выходного потока.

Ответ более научный (отталкиваясь от задачи):
Видимо тот, кто Вас это попросил, человек не слишком большого ума.

Успехов.

[RobFPGA]

Приветствую!

Спасибо всем!

Немного уточню - 62.5 Mhz 16 bit sample 2 chanel = 250 Mbyte/sec.
Нереальное сжатие архиваторами дает в среднем ~25 % сжатия.
Из этого и возникла эта задача. Переползти на PCIe проще но дороже,
а у радиоастрономов (умище у них будь здоров, но уж больно специфичный ) уже слюнки текут от превкушения лишних 500 гиг данных в час. И надо вроде чуть-чуть ужат, вот и просят слезно.
Тем более из всего спектра 0-31 МНz рабочими есть 8-30. Была мысль сдвинуть чуток по частоте вниз и сделать ресемплинг - так нет, просять данные не "портить".
Анализ показывает что данные представляют собой слабые шумоподобные сигналы на фоне
сильных узкополосных помех.
Полазив в инете нашел несколько названий упаковщиков wav формата без потерь - FLAC, WavePac, ...
хочу попробовать на реальных данных, но разбиратся с эффективностью реализации всего долго. Поэтому и рад любой информации.

Удачи! Rob.

[DmitryR]

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

А нельзя вырезать куски, где помеха, раз она полностью глушит сигнал? Это раз. После этого окажется, что слабый сигнал занимает не весь динамический диапазон, и его (динамического диапазона) сжатие даст дополнительный выигрыш.
Думая так, конечно сразу появляется желание усилить сигнал до АЦП, чтобы полезный сигнал занял весь динамический диапазон, а помеха ушла в насыщение. Сделав так, можно поставить АЦП уже на 10-12 бит, и все будет хорошо.

[EvgenyNik]

Если шумы узкополосные, то имеет смысл заложить 3-4 режекторных фильтра в ПЛИС со сменными коэффициентами. Коэффициенты для каждой частоты рассчитываются в МатЛабе. Загружаются в ПЛИСку программно по PCI. Сигнал фильтруется, помехи вырезаются, а всё, что осталось - ужимается и на выход.
Привожу пример результата работы подобного фильтра. Кстати, фазовые задержки нетронутых фильтром компонент остались взаимно неизменными. Умными словами если, то время групповой задержки близко к нулю.

Эскизы прикрепленных изображений

 

[AsJohnAs]

Ну я присоеденюсь ко всему выше сказанному. Если сигнал имеет равномерную плотность вероятности то его сжатие без потерь не возможно.
Вы можете произвести такой эксперимент: Возьмите ПСП ну не очень большой длинны. И запишите его в файл N раз. Потом этот файл сожмите ну например RAR то он сожметься ровно в N раз.

Так что выкусывайте помеху, уменьшайте битность, логарифмируйте, беритие FFT все что угодно что является с потерями. Другого теория не дает.

[fontp]

Приветствую!

Спасибо всем!

Немного уточню - 62.5 Mhz 16 bit sample 2 chanel = 250 Mbyte/sec.
Нереальное сжатие архиваторами дает в среднем ~25 % сжатия.
Из этого и возникла эта задача. Переползти на PCIe проще но дороже,
а у радиоастрономов (умище у них будь здоров, но уж больно специфичный ) уже слюнки текут от превкушения лишних 500 гиг данных в час. И надо вроде чуть-чуть ужат, вот и просят слезно.
Тем более из всего спектра 0-31 МНz рабочими есть 8-30. Была мысль сдвинуть чуток по частоте вниз и сделать ресемплинг - так нет, просять данные не "портить".
Анализ показывает что данные представляют собой слабые шумоподобные сигналы на фоне
сильных узкополосных помех.
Полазив в инете нашел несколько названий упаковщиков wav формата без потерь - FLAC, WavePac, ...
хочу попробовать на реальных данных, но разбиратся с эффективностью реализации всего долго. Поэтому и рад любой информации.

Удачи! Rob.

Существует очень хороший компрессор аудио без потерь Monkey's audio в open source
http://www.monkeysaudio.com/

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

Кажется нужно смотреть какие именно потери допустимы

[DmitryR]

Требуется в реалтайме, без потерь, ужать поток данных с двухканального АЦП с 250 Mb/sec
хотя бы до 200 Mb/sec. Так как на плате узкое место - PCI контроллер имеет максимум 240 Mb/sec.

Тут вы перепутали мегабиты с мегабайтами (Mb - мегабит, MB - мегабайт). И в этом свете есть еще вопрос - у 32-х разрадного PCI на 33 МГц полоса примерно гигабод. У вас же заявлено два гигабода (240 мегабайт/с ~ 2 Гбит/с)- это либо 64 разряда, либо 66 МГц. И в этом случае переход на PCIe не кажется таким уж дорогим.

[GetSmart]

ИМХО раз полезный сигнал шумоподобный и малой амплитуды, то есть простые алгоритмы для сужения динамического диапазона передаваемых данных на коротких последовательностях. В зависимости от амплитуды можно легко и в 2 раза его ужимать. Без всяких FFT и прочих сложностей. Даже на вскидку в голове возникают множество разных идей.

ЗЫ. Любопытно ещё бы взглянуть на типичный кусочек данных размером с десяток килобайт.

[RobFPGA]

Тут вы перепутали мегабиты с мегабайтами (Mb - мегабит, MB - мегабайт). И в этом свете есть еще вопрос - у 32-х разрадного PCI на 33 МГц полоса примерно гигабод. У вас же заявлено два гигабода (240 мегабайт/с ~ 2 Гбит/с)- это либо 64 разряда, либо 66 МГц. И в этом случае переход на PCIe не кажется таким уж дорогим.

Интерфейс на плате -PCIX - 64 бит 66 MHz теоретически позволяет ~500 MB/sec.
Но - контроллер PCI PLX9656 - имеет узкое горло - локальную шину данных - 32 бит/66 MHz

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

Вот пример типичного спектра сигнала (правда немного усредненого и то как это выглядит во времени при выравнивании тренда. Тонкая наклонная линия справа - сигнал пульсара гдето с края Млечного пути.


Успехов! Rob.

[blackfin]

ИМХО, сжатие без потерь с использованием вейвлетов: Теория и практика вейвлет-преобразования.

[DmitryR]

Возьмите Virtex-5 LXT или ArriaGX, там есть PCIe недорого. А вам и надо-то всего что захватить сигнал и послать - то есть минимальная микруха. ArriaGX самая дешевая стоит $100 уже в России, XC5VLX20T - долларов 300 наверное.

Интересно еще вот что: допустим, плату вы сделаете. Куда вы денете физически столько необработанных данных? Чтобы записать 250 мегабайт в секунду надо иметь большой дисковый массив (как я знаю, современные жесткие диски дают физически 50 мегабайт в секунду), и то терабайта хватит на час. А если запись идет импульсами - то можно поставить вокруг FPGA несколько гигов памяти, буферировать данные а потом спокойно сливать.

[RobFPGA]

Возьмите Virtex-5 LXT или ArriaGX, там есть PCIe недорого. А вам и надо-то всего что захватить сигнал и послать - то есть минимальная микруха. ArriaGX самая дешевая стоит $100 уже в России, XC5VLX20T - долларов 300 наверное.

Интересно еще вот что: допустим, плату вы сделаете. Куда вы денете физически столько необработанных данных? Чтобы записать 250 мегабайт в секунду надо иметь большой дисковый массив (как я знаю, современные жесткие диски дают физически 50 мегабайт в секунду), и то терабайта хватит на час. А если запись идет импульсами - то можно поставить вокруг FPGA несколько гигов памяти, буферировать данные а потом спокойно сливать.

Плата такая ка есть уже есть - тут уж ничего не поделаеш. Сейчас позволяет вводить непрерывно данные со скоростью до 180 MB/sec (+резерв при модификации). А два канала пишутся импусно пакетами по 5 сек, с паузами в 7 сек для очистки буферов. (Вот в эти то паузы и пролетает нобель )
Записывается все это на raid 0 массив винтов 2-4 винта Seagate 750 Гиг. Максимальное время непрерывной записи raw дата было около 150 мин, так что память на плате только для буферизации коротких тормозов системы. В течении ночи винты забиваются в разных режимах на 3/4, а потом днем народ все это пакует и переписывает кто - куда. Что потом с этой тучей гиг делают радиоастрономы - самая большая тайна Вселенной над разгадкой котороой они же и работают !
Успехов! Rob.

[DmitryR]

Плата такая ка есть уже есть - тут уж ничего не поделаеш.

Можно поделать новую плату. Заодно все-таки реализовать на ней некую, хотя бы предварительную обработку (не визуально же астрономы эти данные отсматривают?). Иначе не получится непрерывного мониторинга: все равно придется делать паузу на очистку дискового массива.

[GetSmart]

Всё-таки, можно взглянуть на чистые данные? Прикрепите файлик небольшой.

Там всего-то надо передавать вместо 16-битных сэмплов 12-битные. Судя по графику 95% времени сигнал имеет как раз неопределённость 12-13 бит.

[Stanislav]

М-да, насоветовали вагон и тележку. Между тем, ни одного сколько-нибудь стоящего предложения, не считая откровенных глупостей.
Единственную разумную вещь предложил GetSmart - выложите реализацию сигнала в какой-нить файлообменник. Думается, не менее 100 кБайт и не более 10 Мбайт, чтобы с ним можно было поработать.
Чтобы "сжать" сигнал, нужно знать его статистику. Ибо сжатие - это ни что иное, как устранение избыточности. Нахождение закономерностей в сигнале и их формализация, соббсно, и означает решение задачи "сжатия".
Универсальные компрессоры данных в решениях таких задач весьма далеки от оптимума, так что на их результаты ориентироваться нельзя.
На первый взгляд, сигнал с приведённым спектром задавить без потерь можно весьма сильно (в разЫ, думается).
Телегу впереди лошади же ставить не нужно. Об FPGA или ещё каком-нить там супер-пупер DSP следует думать в последнюю очередь.

ИМХО, сжатие без потерь с использованием вейвлетов: Теория и практика вейвлет-преобразования.

Очень интересно, как Вы себе это представляете?

Возьмите Virtex-5 LXT или ArriaGX, там есть PCIe недорого. А вам и надо-то всего что захватить сигнал и послать - то есть минимальная микруха. ArriaGX самая дешевая стоит $100 уже в России, XC5VLX20T - долларов 300 наверное.

Да нефиг делать. Дальше что предлагаете?

[Designer56]

Чтобы "сжать" сигнал, нужно знать его статистику. Ибо сжатие - это ни что иное, как устранение избыточности. Нахождение закономерностей в сигнале и их формализация, соббсно, и означает решение задачи "сжатия".
Универсальные компрессоры данных в решениях таких задач весьма далеки от оптимума, так что на их результаты ориентироваться нельзя.
На первый взгляд, сигнал с приведённым спектром задавить без потерь можно весьма сильно (в разЫ, думается).

Совершенно верно, но сначала нужно для себя решить- что есть избыточность для данного сигнала (или классов сигналов). А просто так, сжать что-либо без потерь в абсолютном смысле слова невозможно.

[Stanislav]

Совершенно верно, но сначала нужно для себя решить- что есть избыточность для данного сигнала (или классов сигналов)...

Пытаться априорно решать, что есть избыточность, особенно не нужно. Статистический анализ это покажет, независимо от наших предпочтений.
Сигнал с приведённым спектром, например, даже невооружённым глазом определяется как сильно избыточный - в нём присутствуют мощные (квази)гармонические составляющие. Между тем, представив их параметрически (частота+амплитуда+фаза), удастся "сэкономить" несколько разрядов данных.
Это всё "на пальцах"; если работать с сигналом серьёзно, можно найти и другие закономерности. Будучи представленными в виде набора параметров, они позволят "сжать" сигнал ещё и дополнительно, совершенно без потерь, если уж так задача ставится.

...А просто так, сжать что-либо без потерь в абсолютном смысле слова невозможно.

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

[eugen_pcad_ru]

2RobFPGA: расширяйте горло: Большие умы просто не захотят НИКАКИХ манипуляций с сигналом

[blackfin]

Очень интересно, как Вы себе это представляете?

Да примерно так же, как это представляет себе стандарт JPEG2000, с использованием биортогонального фильтра Добеши с целочисленными коэффициентами (5, 3) для сжатия без потерь и адаптивного арифметического кодера.

[Stanislav]

Да примерно так же, как это представляет себе стандарт JPEG2000, с использованием биортогонального фильтра Добеши с целочисленными коэффициентами (5, 3) для сжатия без потерь и адаптивного арифметического кодера.

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

[blackfin]

Стало быть, Вы утверждаете, что истинно универсальный метод сжатия чего угодно с помощью чудесных свойств вэйвлетов таки найден, и называется он jpeg2000?

Не приписывайте мне то, чего я не говорил..

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

Сами попробуйте.. Мне это не нужно..

[fontp]

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

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

Но скорее всего имидж в канал не передаётся, это результат какой-то обработки сигнала на первой картинке

[blackfin]

Но скорее всего имидж в канал не передаётся, это результат какой-то обработки сигнала на первой картинке

ИМХО, ничто не мешает сжимать "одномерные изображения". Формат файла-контейнера JPEG2000 придется, конечно, "подредактировать".. ;-)

[fontp]

ИМХО, ничто не мешает сжимать "одномерные изображения". Формат файла-контейнера JPEG2000 придется, конечно, "подредактировать".. ;-)

A в одномерном сигнале отсутствуют те корреляции или они становятся очень "дальними"
Сжатие без потерь основывается только на статистических неоднородностях.

[DmitryR]

Да нефиг делать. Дальше что предлагаете?

Дальше в полосу PCIe 4x (а дешевые микросхемы содержат именно 4 трансивера) необходимый траффик в 250 мегабайт/с укладывается с четверным запасом, а что с ним делать на той стороне проблемой автора топика по его словам не является.

[blackfin]

A в одномерном сигнале отсутствуют те корреляции или они становятся очень "дальними"
Сжатие без потерь основывается только на статистических неоднородностях.

Как бы то ни было, в JPEG2000 сжатие по строкам и по столбцам выполняется независимо друг от друга. Ессно, при двумерном сжатии общий коэффициент сжатия будет выше: Kобщ=Kx*Ky.

[rv3dll(lex)]

судя по картинке в 2 раза можно сжать используя дельто сжатие с переходом в полноразмерное

16 бит сжать до байта используя числа от -127 до 127

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

[Stanislav]

Не приписывайте мне то, чего я не говорил..

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

Сами попробуйте.. Мне это не нужно..

Даже пытаться не буду.
Лучше поведайте, кто Вам сказал, что это вообще возможно?

ЗЫ. Ах, да. В википедию-то я и забыл заглянуть...

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

А зачем нужны вэйвлеты, может, Вы поясните тёмному? ;)

судя по картинке в 2 раза можно сжать используя дельто сжатие с переходом в полноразмерное...

Ой, мамО... А может, не надо так-то, сплеча? Иначе объём данных увеличить рискуете.

[fontp]

А зачем нужны вэйвлеты, может, Вы поясните тёмному?

Неплохая картинка должна сжиматься методами, предназначеными для изображений.
В частности JPEG2000, вообще любыми двумерными, которые сжимают линии любой ориентации.
В JPEG2000 есть сжатие без потерь, почему не попробовать?

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

[Stanislav]

Неплохая картинка должна сжиматься методами, предназначеными для изображений.

Скажите, а почему вэйвлеты используются для сжатия именно изображений?

...В частности JPEG2000, вообще любыми двумерными, которые сжимают линии любой ориентации.
В JPEG2000 есть сжатие без потерь, почему не попробовать?

Иными словами, соответствие входной и выходной информации после кодека обеспечивается с точностью до бита, я правильно понял?

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

Что значит "не проявляются"?

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

[fontp]

Скажите, а почему вэйвлеты используются для сжатия именно изображений?

Иными словами, соответствие входной и выходной информации после кодека обеспечивается с точностью до бита, я правильно понял?

Что значит "не проявляются"?

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

1) Так оказалось. Кодирование сигналов разной природы всегда строилось на том, что сделать некое преобразование обнаруживающее некоторые статистические аномалии присущие сигналам данной природы + провести энтропийное кодирование. Перепробовали много всяких преобразований, все известные перепробовали (учёные как шакалы!), вейвлеты дали лучший результат для изображений. Для звука не дали :-)

2) Ну да. Без потерь - без маскирующей или психофизической ерунды
3) Не проявляются значит в исходном представлении вероятности равномерно распределены и энтропийное кодирование не заработает

ЗЫ. Ещё раз - картинка достаточно хорошая, чтобы её кодировать методами характерными для картинок. Не морочьте мне голову. Я в прошлой жизни сам был доктор наук по обработке изображений типа Ярославского :-)

[Stanislav]

1) Так оказалось...

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

...Кодирование сигналов разной природы всегда строилось на том, что сделать некое преобразование обнаруживающее некоторые статистические аномалии присущие сигналам данной природы + провести энтропийное кодирование.

Чешуя какая-то, ещё раз простите. Может, просто не понял правильно...
Вэйвлет-разложение видеокартинки, с последующим "сжатием", в смысле информационных потерь, ничуть не лучше любого другого способа кодирования, включая косинусное, уолшево, фурье, и т.д.
ФишкА в том, что вэйвлеты некоторых видов, при использовании их в видеокодеке, порождают меньшее количество перцептуально-значимых артефактов, поскольку способны с меньшими погрешностями передавать субъективно существенные для человеческого восприятия детали.
В остальном, вэйвлет-кодирование, по сравнению с другими известными способами, имеет принципиально бОльшую величину разностной ошибки (в частности, яркостного шума по всей площади картинки). Просто дело в том, что эта ошибка человеческим мозгом "фильтруется", и не является раздражающим фактором.
Соббсно, вот и вся теория.

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

Дык, вопрос-то мой и был: почему?
Ответ также прост: ухо - не глаз; его не обманешь. Любые искажения им фиксируются весьма чётко.
А вэйвлеты, даже сконструированные самым хитрым образом, не соответствуют ни структуре аудио сигнала, ни механизму восприятия звука человеком (будете удивляться, но вполне адекватная модель восприятия изображения человеком уже давно существует, а звука - нет).
Поэтому, для компрессии звука используется технологии, в корне отличающиеся от таковых для изображения. Причём, поскольку механизм восприятия звука не ясен, для кодирования разных сигналов (речи, музыки) используются также совершенно разные подходы.

2) Ну да. Без потерь - без маскирующей или психофизической ерунды

До бита - это значит, до бита.
Иными словами, выходной цифровой массив кодека при сравнении с исходным, не должен содержать ни одной несовпадающей единицы информации.
Смысл "сжатия без потерь" я понимаю именно в этом контексте.
Думаю, "товарисчи учёные, доценты с киндидатами" меня в этом вопросе всецело поддержат.

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

3) Не проявляются значит в исходном представлении вероятности равномерно распределены и энтропийное кодирование не заработает

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

ЗЗЫ. Меня когда-то учили: если с наскоку не можешь описать сигнал статистически, считай моменты.

ЗЫ. Ещё раз - картинка достаточно хорошая, чтобы её кодировать методами характерными для картинок. Не морочьте мне голову. Я в прошлой жизни сам был доктор наук по обработке изображений типа Ярославского :-)

Типа Губельмана, что ли?

[DS]

Да нельзя сжимать данные с радиотелескопов, ускорителей и т.п. Поскольку ищутся обычно сигналы и события с неизвестными заранее характеристиками. Поэтому исходно они неотличимы от шума с точки зрения любого алгоритма, а шум, как известно, не жмется.
Вон с БАКа из ЦЕРНа по всей Европе волокна растягивают для передачи СЫРЫХ данных в различные научные центры, а уж казалось бы чего - проще - взял да и пожал, почистил от случайных событий ...
Другое дело, если надо выделить конкретное что-то типа Вашего пульсара - тогда можно и в миллион раз пожать без потери информации - обычно характеристик сигнала весьма немного.

[Stanislav]

Да нельзя сжимать данные с радиотелескопов, ускорителей и т.п.

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

...Поскольку ищутся обычно сигналы и события с неизвестными заранее характеристиками.

Если так, характеристики можно оценить адаптивно; выбирать придётся только метод, исходя из априорных сведений о структуре сигнала.
Если автор темы соизволит выложить файлы данных (лучче несколько реализаций, не менее миллиона отсчётов каждая, чтоб вопросов потом не возникало), смогу продемонстрировать, как примерно это надо делать.

...Поэтому исходно они неотличимы от шума с точки зрения любого алгоритма,

Кто это сказал? Почему данные именно неотличимы от шума? Я на картинках вижу прямо противоположное.

...а шум, как известно, не жмется.

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

...Вон с БАКа из ЦЕРНа по всей Европе волокна растягивают для передачи СЫРЫХ данных в различные научные центры, а уж казалось бы чего - проще - взял да и пожал, почистил от случайных событий ...

И что из того? И почему что-то обязательно нужно "чистить от случайных событий"?
Пусть изгаляются, если хотят. В данной теме речь идёт вовсе не об этом.
Кроме того, при малых отношениях С/Ш сжималки становятся малоэффективными. Здесь опять же не тот случай, а как там в ЦЕРНе - не интересовался.

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

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

[GetSmart]

Сильно сумневаюсь, что на скорости входных данных 250 MB/sec можно будет организовать хоть сколько-нибудь сложный алгоритм сжатия. Это к вопросу об рабочей тактовой FPGA.

судя по картинке в 2 раза можно сжать используя дельто сжатие с переходом в полноразмерное...

Ой, мамО... А может, не надо так-то, сплеча? Иначе объём данных увеличить рискуете.

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

[Stanislav]

Сильно сумневаюсь, что на скорости входных данных 250 MB/sec можно будет организовать хоть сколько-нибудь сложный алгоритм сжатия. Это к вопросу об рабочей тактовой FPGA.

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

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

А где в посте rv3dll(lex) сказано, что он именно должен быть адаптивным?
Кроме того, я могу придумать Вам последовательность, дельта-кодирование которой гарантированно будет приводить к увеличению объёма выходной информации.

[GetSmart]

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

А я две последовательности могу придумать, и что?

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

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

Сообщение отредактировал GetSmart - Feb 16 2008, 01:05

[Stanislav]

А я две последовательности могу придумать, и что?

Отлично.

Вы вообще внимательно читаете?
В потоке используется префикс (одно зарезервированное значение) для указания перехода в режим дельта и обратно.

Не понимаю, как Вы это себе представляете?
Если идёт речь о зажатии спектрограммы, рекомендую Вам прочитать внимательнее Ваш же пост:

Сильно сумневаюсь, что на скорости входных данных 250 MB/sec можно будет организовать хоть сколько-нибудь сложный алгоритм сжатия. Это к вопросу об рабочей тактовой FPGA.

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

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

Идеи, вообще-то, должны соответствовать реальной действительности...

[GetSmart]

Вообще-то если АЦП оцифровывает звёздное небо, как я понимаю - ночью, то там должна быть огромная избыточность, а 16 бит выбрано для большого дин.диапазона. Я говорю о реальном сигнале, а не спектрограммах на картинке. Я вообще избегал высказывания каких-либо алгоритмов до взгляда на реальные данные. Просто указал Вам, что вы со своими мега-идеями можете пропустить чужие стоящие. Именно из-за однобокости хода мысли.

Идеи, вообще-то, должны соответствовать реальной действительности...

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

[Stanislav]

Вообще-то если АЦП оцифровывает звёздное небо, как я понимаю - ночью, то там должна быть огромная избыточность,

Ух ты!
Очень интересно, как это АЦП может "оцифровывать звёздное небо", да ещё содержащее "огромную избыточность".
Вам неплохо бы понять, что в звёздном небе, как и в мире вообще, нет никакой "избыточности". Там всё логично и взаимосвязано. Более того, "мир познаваем", как говорили товарищи большевики.
"Избыточность" Вселенной надёжно присутствует только в умах неких неучей, которые пытаются кому-то что-то объяснять.

...а 16 бит выбрано для большого дин.диапазона.

Америка открыта.
Скажите, а что Вы подразумеваете под "большим динамическим диапазоном"? Я б, например, ежли б предложил нашим учёным 18-битный АЦП, с гораздо бОльшим дин. диапазоном, то мне б, думаю б, за "увеличение динамического диапазона" б, никто памятник б' не поставил.

...Я говорю о реальном сигнале, а не спектрограммах на картинке.

Нихт ферштеен. Вы что, являетесь обладателем реального сигнала?

...Я вообще избегал высказывания каких-либо алгоритмов до взгляда на реальные данные.

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

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

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

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

Молодой человек, Вам бы стоило зажать свои мысли в кулачок, и отвечать на вопросы по существу.

[GetSmart]

Ух ты!
Очень интересно, как это АЦП может "оцифровывать звёздное небо", да ещё содержащее "огромную избыточность".
Вам неплохо бы понять, что в звёздном небе, как и в мире вообще, нет никакой "избыточности". Там всё логично и взаимосвязано. Более того, "мир познаваем", как говорили товарищи большевики.
"Избыточность" Вселенной надёжно присутствует только в умах неких неучей, которые пытаются кому-то что-то объяснять.

Абалдеть
Вы небо видели? 99% чернота. Мне всё-равно насколько оно там пустое или нет в воображении астрономов, но если хотя бы 50% времени сигнал меньше 15 ЗР (бит), то я уже утверждаю что в сигнале уже избыточность.

Скажите, а что Вы подразумеваете под "большим динамическим диапазоном"? Яб, например, ежлиб предложил нашим учёным 18-битный АЦП, с гораздо бОльшим дин. диапазоном, то мнеб, думаю, за "увеличение динамического диапазона" никто памятник бы не поставил.

Придумайте сначала как это ужать до 200 MB/sec, а потом предлагайте хоть 20 бит. Я констатировал то, что уже есть и работает. И что нужно ужать по ТЗ.

Нихт ферштеен. Вы что, являетесь обладателем реального сигнала?

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

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

Думаю и без Ваших указок. Пока что ничего лишнего себе не позволил.

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

Легко! Вижу, что задел наверно неподецки. Мне даже льстит такое Ваше внимание

Сигнал с приведённым спектром, например, даже невооружённым глазом определяется как сильно избыточный - в нём присутствуют мощные (квази)гармонические составляющие. Между тем, представив их параметрически (частота+амплитуда+фаза), удастся "сэкономить" несколько разрядов данных..

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

Молодой человек, Вам бы стоило зажать свои мысли в кулачок, и отвечать на вопросы по существу.

По-другому не умею. Вы ещё не заметили?

Также прошу пояснить понятие "однобокость хода мысли".

Забыл совсем.
Я имел ввиду акцент на сложных в реализации параметрических методах (методе) в ущерб более быстрым алгоритмам, работающим с битовыми/байтовыми строками. Такое мнение сложилось из-за недостаточного собственного акцента на них и ещё из-за критики чужых идей. ИМХО именно у таких методов здесь больше шансов.

Кстати, судя по репликам, настоящие аргументы у Вас закончились.

[DS]

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

Кто это сказал? Почему данные именно неотличимы от шума? Я на картинках вижу прямо противоположное.

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

Так в представлении статистических закономерностей сигнала и заключается работа тех людей, которые исследуют его. После того, как они найдены, сигнал обычно становится никому не интересен. Приведенный пример неправильный, поскольку там уже известно, что принимается. И его можно сжать, наверное, до нескольких байт в секунду. То, же и с шумом - если известно, что это белый шум и только, его, действительно, парой параметров можно описать, только потом уже сигнал не восстановить обратно.
Zip и подобные алгоритмы зашумленный (а точнее не отличимый от шума) сигнал не сожмут.
Другой вопрос, если переформулировать задачу, и искать сигнал, похожий на представленный автором (или еще на что-то). Только тогда не придется говорить о "сжатии без потерь". Поэтому и пишут сырые данные, ведь один человек в них будет искать пульсар, другой - неравномерность реликтового излучения, третий - еще что-нибудь. Каждый потом "сжимает" эти данные до нескольких цифр, которые характеризуют то, что он искал.
Если сформулировать по другому - сигнал с научного оборудования в рассматриваемых случаях отличается от сигнала, который существует в обычных измерительных системах тем, что априорно не известно, что в нем содержится.

[Stanislav]

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

Совершенно верно!
Поэтому, задача "сжатия" информации - творческая. Более того, по-настоящему хороший компрессор является также хорошим анализатором данных, так, как по параметрическому представлению можно судить об особенностых самогО сигнала. Задача "сжатия", таким образом, очень близка к задаче идентитфикации системы, и методы к ней применимы абсолютно те же. На выходе идеального фильтра-компрессора должен быть нормированный гауссовский белый шум, не несущий в себе никакой информации.
Дело, однако, в том, что для эффективной компрессии не нужно слишком уж сильно углубляться в анализ. "Товарисчи учёные", например, ждут какого-нибудь всплеска, который бывает в галактике раз в миллион лет, весьма слаб, и не описывается априорно никакой статистикой - отсюда требование отсутствия каких-либо потерь. В свете написанного здесь ранее, я их опасения начал чувствовать печёнкой, и поддерживаю требование в полной мере - нашим "умельцам" только дай волю, они враз тут вэйвлеты с дельтами прикрутят, после чего работать с данными станет действительно неинтересно.
Однако, в сигнале присутствуют и другие "мощные закономерности", которые, соббсно, и нужно трамбовать. С возможностью полного восстановления, конечно.
Они не несут в себе большой информации, но, вследствие своей энергетической значимости, "жрут" несколько разрядов данных. АЦП поэтому выбирать приходится с достаточно большим динамическим диапазоном.

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

Как это известно? Мне, например, ничего не известно, кроме того, что он обладает большой степенью избыточности. Однако, думаю, утрамбовать этот неизвестный мне сигнал до требуемой скорости смогу, причём в "реалтайме", т.е, постоянно имея в памяти анализатора только небольшой его участок.

...И его можно сжать, наверное, до нескольких байт в секунду...

В том-то всё и дело, что нельзя...

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

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

...Zip и подобные алгоритмы зашумленный (а точнее не отличимый от шума) сигнал не сожмут.

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

...Другой вопрос, если переформулировать задачу, и искать сигнал, похожий на представленный автором (или еще на что-то)...

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

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

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

[GetSmart]

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

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

Просто скучно вас слушать. Раз уже договорились без потерь, то не надо это во всех красках расписывать.

Априорно известно, что сигнал повторяемый. Априорно известно какой диапазон он занимает. Априорно известно, что во время измерения не произойдёт "Большого взрыва", что прямо или косвенно говорит о том, что сохраняемая информация не изменится кардинально. Могут появляться всплески и прочие уникальные отличия в разные короткие моменты времени, но большую часть времени будет передаваться очень похожий сигнал на тот, который много раз передавался до этого. Именно его и можно ужать.

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

[Stanislav]

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

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

[GetSmart]

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

А где рилтаймовый алгоритм параметрического сжатия?

Да и кому вообще интересно кто в какой весовой категории себя воображает? Если есть реальные аргументы или идеи - выкладывайте, а то я вижу много критики и мало практичных идей. Покажите нам свою весовую категорию в деле. По существу, практически пригодное, Вы сами ещё ничего не высказали.

ЗЫ. Расчитываю на Ваше внимание Обещание нужно держать!

[RobFPGA]

Приветствую!

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

Есть плата PCIX 64/66 (и новую уже никто пока делать не будет так как на Большую науку выделяют маленькие деньги), поэтому вариант с PCIE был бы правильный и для меня самый легкий - но увы .

Данные для сжатия представляют собой необработанный поток с АЦП. Приведенные картинки лиш быстрый способ представить типичный спектр этих данных. Сейчас они формируются паралельно с записью сырых данных расчетом на лету 16k FFT в FPGA. Образец самих данных я смогу представить чуть позже.

Мною был быстро попробован простейший способ кодирования дельты соседних отсчетов - результат - сжатие ~5-8% что дает основание для оптимизма. В данный момент пытаюсь понять реализацию алгоритмов сжатия WavePACK и FLAC благо софтварно можно попробовать на реальных данных.

Успехов! Rob.

[GetSmart]

Мною был быстро попробован простейший способ кодирования дельты соседних отсчетов - результат - сжатие ~5-8% что дает основание для оптимизма.

Ну раз простейший уже рулит, то есть все шансы сжать от полутора раз и выше тем же способом, но более продуманным. Потом ещё и разрядность АЦП можно будет бонусом поднять.

[EvgenyNik]

RobFPGA, скажите - а насколько стабильна "помеха" в плане частоты, амплитуды и периодичности появления?
Если стабильность достаточная, то имея FFT, Вы можете выделять большие по амплитуде компоненты параметрически и, как говорил Stanislav, передавать эту информацию в более общем виде.
Более того, Вы можете держать на борту набор таблиц для генерирования больших компонент. Причём, Вам совершенно не обязательно иметь таблицы для частой сетки частот и не надо мастерить сверхточный генератор. Для регулировки амплитуды подойдёт деление на 2, т.е. откидывание младших бит. При откидывании Вы вносите искажение =< 1 МЗР, но оно восстанавливаемое на верхнем уровне, т.к. Вы передали параметры вычитаемой компоненты и "верхний уровень" знает ваши таблицы.
Определив компоненту(ы), Вы передаёте её(их) параметры, кодируемые просто табличным номером, начальным индексом фазы и коэффициентом деления амплитуды, и начинаете с определённой фазы их "генерировать" и вычитать из реального сигнала до момента, пока по какой-либо причине (уход по фазе из-за неточности определения/генерации частоты, изменение амплитуды или частоты исходной компоненты) разностная составляющая не перестанет помещаться в меньшую разрядность.
Преимущество такого вычитания больших компонент заключается в практически полной восстанавливаемости сигнала, т.к. вычитаемая часть нам известна.
Дальше можно попытаться применить разностный метод (дельту), если в нём ещё будет потребность.

[rv3dll(lex)]

я считаю что упираться в один алгоритм не стоит

по поводу увеличения данных при дельта кодировании - если данные поделить на блоки то можно потом посмотреть что дало кодирование того или иного алгоритма на этом блоке

возможно даже с плавающим окном

всё есттественно параллельно - и потом выбрать лучший на этом блоке данных - но уже под конец

[dinam]

Вот здесь попробуйте спросить. Много чего интересного можно прочитать здесь

[rv3dll(lex)]

подскажу ещё вариантик по дельте
сам всё пробовал в своё время

сначала была мысль с изменяемым остатком а именно выходные данные переменной разрядности
а именно 6 - 16 бит но это не удобно потом разгребать одна ошибка в такой системе и всё нафиг

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

есть некий буфер фифо в котором осуществляется анализ нескольких следующих чисел на возможность ужатия до байта

если есть такая возможность условие перехода ставится метка резервирования 4 байта из которых 3 байта никогда не повторяющаяся последовательность четвёртый длина предшествующей несжатой части

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

переход туда обратно естественно тратит 2 16 ти битных слова и используется только тогда когда выгоден.

[DS]

А не правильнее ли здесь сторговаться с астрономами по снижению частоты дескретизации на 20% ? Особенно, если я правильно понял, что полоса не 0 - 30 Мгц, а 8-30 Мгц. Думаю, что результат такого компромисса куда полезнее сложного сжатия.

[Stanislav]

А не правильнее ли здесь сторговаться с астрономами по снижению частоты дескретизации на 20% ? Особенно, если я правильно понял, что полоса не 0 - 30 Мгц, а 8-30 Мгц. Думаю, что результат такого компромисса куда полезнее сложного сжатия.

Думаю, в этом нет необходимости.
Сдаётся, ужать входной поток с подобным спектром до озвученной величины удастся и несложными способами, которые вполне можно будет реализовать в реалтайме. Например, что-нибудь вроде регрессионных, или других адаптивных методов.
Что-либо определённое можно будет предложить только при наличии конкретных файлов с данными.

[DS]

Думаю, в этом нет необходимости.
Сдаётся, ужать входной поток с подобным спектром до озвученной величины можно и несложными способами, которые вполне можно будет реализовать в реалтайме. Например, что-нибудь вроде регрессионных, или других адаптивных методов.
Что-либо определённое можно будет предложить только при наличии конкретных файлов с данными.

Да если под 8-30 Мгц понимается, что спектр 0 -8 неинтересен, то и без сжатия можно влезть.

[Stanislav]

Да если под 8-30 Мгц понимается, что спектр 0 -8 неинтересен, то и без сжатия можно влезть.

Тогда полосу 0-8МГц придётся отфильтровывать с помощью ФВЧ и делать ресэмплинг. Или фильтровать на входе АЦП, а частоту дискретизации снизить.
Однако, насколько я понял, такой способ автору темы применять запретили...

[RobFPGA]

Приветствую!

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

Успехов! Rob.

[rv3dll(lex)]

Приветствую!

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

Успехов! Rob.

что то я не понимаю каким боком эти сигналы попадают в тракт
если они всёже попадают то сигналы остальной части кв диапазона 8 -30 мегагерц будут мешать ещё больше
что за антенна используется в таком широком диапазоне частот? сколько десятков квадратных километров занимает эта антенна?, какой угол ДН и чем задаётся сканирование и вообще это на земле или на спутнике

на сколько я понимаю нижний порог частоты задаётся границей пропускания ионосферы и на сколько я помню под прямым углом это больше 8 - где то около 14 мегагерц ещё от времени суток зависит, а при наклоне луча на горизонт чтото около 45 мегагерц - могу правда ошибаться вообще наверное про 8 мегагерц похоже на правду - это примерная граница изменения свойств прохождения радиоволн

[DS]

Приветствую!

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

Успехов! Rob.

Так почему бы вам не изменить аналоговую часть, так, чтобы спектр был в диапазоне 0 - 22 Мгц, или не сделать в цифре ресемплинг со сдвигом вниз на 8 Мгц? Это же не сжатие с потерями, полезные данные Вы не потеряете, зато уложитесь в канал.

[rv3dll(lex)]

Так почему бы вам не изменить аналоговую часть, так, чтобы спектр был в диапазоне 0 - 22 Мгц, или не сделать в цифре ресемплинг со сдвигом вниз на 8 Мгц? Это же не сжатие с потерями, полезные данные Вы не потеряете, зато уложитесь в канал.

Для этого понадобится перенести сигнал на высокую промежуточную - 100-200 мегагерц а потом обратно на 0-22

ещё вариант хороший фильтр 8-30 прямое преобразование с гетеродином 8 мгц и фнч 0-22

ещё вариант даже наверное самый приемлемый прямое преобразование с гетеродином 30 мегагерц правда при этом произойдёт инверсия спектра

[Stanislav]

Так почему бы вам не изменить аналоговую часть, так, чтобы спектр был в диапазоне 0 - 22 Мгц, или не сделать в цифре ресемплинг со сдвигом вниз на 8 Мгц? Это же не сжатие с потерями, полезные данные Вы не потеряете, зато уложитесь в канал.

Для этого понадобится перенести сигнал на высокую промежуточную - 100-200 мегагерц а потом обратно на 0-22

ещё вариант хороший фильтр 8-30 прямое преобразование с гетеродином 8 мгц и фнч 0-22

ещё вариант даже наверное самый приемлемый прямое преобразование с гетеродином 30 мегагерц правда при этом произойдёт инверсия спектра

Какие промежуточные и какие ещё гетеродины?
Братцы, может, хватит наконец ерунду писать?
Сигнал в полосе 8-30 МГц теоретически можно оцифровывать с частотой 44 и выше МГц без всяких гетеродинов.

[GetSmart]

А интересно, в данный момент FFT работает в рилтайме непрерывно или с какими-то интервалами?

Сообщение отредактировал GetSmart - Feb 19 2008, 09:36

[rv3dll(lex)]

Какие промежуточные и какие ещё гетеродины?
Братцы, может, хватит наконец ерунду писать?
Сигнал в полосе 8-30 МГц теоретически можно оцифровывать с частотой 44 и выше МГц без всяких гетеродинов.

каким образом предлагается перенос спектра в рамках того, что входной и выходной спектры пересекаются?????

[DS]

Сигнал в полосе 8-30 МГц теоретически можно оцифровывать с частотой 44 и выше МГц без всяких гетеродинов.

А я что, предлагаю что-нибудь другое ?

[GetSmart]

То есть на 44 МГц можно оцифровать 30 МГц без потерь?!? Круто!

ЗЫ. Может кто-то забыл название темы.

[Stanislav]

А я что, предлагаю что-нибудь другое ?

Нет, это не к Вам относится, а к отвечавшему на Ваш пост.

То есть на 44 МГц можно оцифровать 30 МГц без потерь?!? Круто!
ЗЫ. Может кто-то забыл название темы.

Рекомендую некоторым неучам хотя бы раскрыть учебник по основам обработки сигнала.

А интересно, в данный момент FFT работает в рилтайме непрерывно или с какими-то интервалами?

16К?

каким образом предлагается перенос спектра в рамках того, что входной и выходной спектры пересекаются?????

Полоса сигнала - 22 МГц, если отбросить 8, только и всего. Взяв частоту выборки 44 МГц, формально удовлетворим критерию Найквиста.
На практике, конечно, желательно эту частоту брать побольше, т.к. фильтры идеальными сделать нельзя.

[GetSmart]

Рекомендую некоторым неучам хотя бы раскрыть учебник по основам обработки сигнала.

Можно я это процитирую, чтобы ненароком не удалили. Как я понимаю, вы так демонстрируете свою "весовую категорию". Ну что ж, тогда ещё и страничку сообщите, на которой это подробно описано. Причём что б было без потери точности. Мне например почему-то кажется, что если сигнал 1 МГц сдвинуть на 1 МГц назад (пускай чуть меньше), то его огибающая уже не сможет передать точно огибающую исходного сигнала.

16К?

Типа я забыл указать, что имеенно 16К, а не 1К. Вопрос был в другом.

Сообщение отредактировал GetSmart - Feb 19 2008, 12:05

[rv3dll(lex)]

перенос целостного спектра с 8-30 на 0-22 оцифровка и восстановление его назад в 0-22 и перенос обратно на 8-30 вроде не противоречит никаким законам

только чтото я про 44 мгцне понял

если взять в прямую и оцифровать 8-30 44мя

получим 0-22 будет суммирован с 44-22



то есть вообще всё перемешается на фиг 14-22 сложится с 30-22

[GetSmart]

только чтото я про 44 мгцне понял
если взять в прямую и оцифровать 8-30 44мя
получим 0-22 будет суммирован с 44-22

Никто не говорил что на прямую. С предворительным сдвигом ессно (хотя куда уж мне до гуру)

перенос целостного спектра с 8-30 на 0-22 оцифровка и восстановление его назад в 0-22 и перенос обратно на 8-30 вроде не противоречит никаким законам

А по-моему противоречет законам логики. И ещё закону "без потерь". Но тут вряд ли кого это интересует. Ведь если сигнал 1 МГц, то его огибающая может меняться во времени очень сильно. Если же его сдвинуть до 1 Гц, то она уже не сможет так же быстро меняться. Так что потери неизбежны.

Другими словами, если на сигнале 1 МГц модуляцией передавать сигнал 100 кбод, то на сдвинутом сигнале 1 Гц я думаю и под микроскопом будет не найти эти 100 кбод.

Сообщение отредактировал GetSmart - Feb 19 2008, 12:01

[fontp]

перенос целостного спектра с 8-30 на 0-22 оцифровка и восстановление его назад в 0-22 и перенос обратно на 8-30 вроде не противоречит никаким законам

только чтото я про 44 мгцне понял

если взять в прямую и оцифровать 8-30 44мя

получим 0-22 будет суммирован с 44-22
то есть вообще всё перемешается на фиг 14-22 сложится с 30-22

8-22 останется на месте, а 22-30 сползёт биениями в 0-8, где ничего нет
отфильтровать только нужно хорошо
и восстанавливать на приёме

[rv3dll(lex)]

Никто не говорил что на прямую. С предворительным сдвигом ессно (хотя куда уж мне до гуру)
А по-моему противоречет законам логики. И ещё закону "без потерь". Но тут вряд ли кого это интересует. Ведь если сигнал 1 МГц, то его огибающая может меняться во времени очень сильно. Если же его сдвинуть до 1 Гц, то она уже не сможет так же быстро меняться. Так что потери неизбежны.

Другими словами, если на сигнале 1 МГц модуляцией передавать сигнал 100 кбод, то на сдвинутом сигнале 1 Гц я думаю и под микроскопом будет не найти эти 100 кбод.

и да и нет

вы каждый день слушаете приёмник в котором речевой спектр переносится с частоты радиопередачи на низкую 10.7м 6.5м 465к 455к 500к 215к 128к это я для примера написал ряд промежуточных частот
и ничего не происходит.

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

когда перемещаем спектр это соотношение рушится - а перемещаем обратно - восстанавливается - с ошибкой конечно изза фаз гетеродинов и доп шумов

единственное о чём стоит не забывать об отношении модулирующей частоты и несущей - хотябы в 10 раз


про ваши боды всё просто на мегагерце 100 килобод увеличат ширину канала от 900 до 1100 килогерц при индексе модуляции 1

соответственно если передвинете не на 1 мгц а на 900 кгц вниз запишете а потом восстановите и передвинете обратно ничего не изменится

8-22 останется на месте, а 22-30 сползёт биениями в 0-8, где ничего нет
отфильтровать только нужно хорошо
и восстанавливать на приёме

ничего подобного - так как спектр выше получастоты котельникова инвертируется

[GetSmart]

Люди! Я вас уверяю, что точность исказится! Не думайте, что я такой балбес (каким мемя разрисовывает местный гуру), что не знаю про переносы спектра радиочастот. Тут автор недвусмысленно описал что ему надо.

Ещё, могу поспорить, что автору совсем нежелательно переделывать аппаратуру ради чьих-то "умных" идей. И он точно выберет цифровой алгоритм сжатия. Все, кто в это не верит - можете дальше рассказывать друг другу познания в области радиочастот

Сообщение отредактировал GetSmart - Feb 19 2008, 12:40

[fontp]

ничего подобного - так как спектр выше получастоты котельникова инвертируется

ну пусть инвертируется. Восстановить-то всё равно можно

[GetSmart]

ИМХО при сдвиге спектра какого-либо сигнала энергия модуляции распределяется неравномерно между Fс+Fг и Fс-Fг (Fс - сигнал, Fг - частота гетеродина), то есть на получившихся низких частотах будет меньше енергии, а верхние вы тут договорились отфильтровать и выбросить. Поэтому и восстановить точный вы сигнал не сможете.

[rv3dll(lex)]

ну пусть инвертируется. Восстановить-то всё равно можно

нельзя так как старшая от 22 до 30 не попадёт в 0-8
а попадёт в 14-22 просуммируется там с полезным же сигналом и капут))))

ИМХО при сдвиге спектра какого-либо сигнала энергия модуляции распределяется неравномерно между Fс+Fг и Fс-Fг (Fс - сигнал, Fг - частота гетеродина), то есть на получившихся низких частотах будет меньше енергии, а верхние вы тут договорились отфильтровать и выбросить. Поэтому и восстановить точный вы сигнал не сможете.

из чего это следует?

если вы говорите о спектре 8-22 то это значит, что эти границы показывают полезную составляющую сигналов и когда и как вы их обрежете не имеет практического значения

то есть вас абсолютно не интересуют сигналы ниже 8 м

а вы говорите о несущей 8м и какойто несуществующей модуляции.

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

надеюсь объяснил доходчиво

[RobFPGA]

Приветствую!

Любой перенос частот с последующей фильтрацией вносит доп. искажения. Которые потом при постобработке могут непонятно как вылезти. Поэтому и просят сделать как можно проще и именно сырые данные. Например один из вариантов постобработки - взят сырые данные за часик и сделать стомилиооноточечное FFT затем домножить это на зависимость дисперсии сигнала в межзвезном прстранстве и назад IFFT - потом в результате ищут линии от далеких пульсаров.


to GetSmart в реалтайме, потоком, 16384 точечное FFT с перекрытием 50%, для двух каналов (16 бит вход, 20бит коэффициент, 30бит выход), с последующим усреднением от 2- до 1024 спектров.

to rv3dll(lex) антена имеет 150.000 M^2 более подробно - UTR-2

Успехов. Rob.

[Stanislav]

Можно я это процитирую, чтобы ненароком не удалили. Как я понимаю, вы так демонстрируете свою "весовую категорию". Ну что ж, тогда ещё и страничку сообщите, на которой это подробно описано. Причём что б было без потери точности.

Можно; я это ещё неоднократно повторить могу.
Для начала, откройте в самом начале, и выясните, что происходит со спектром сигнала при его дискретизации.
Далее, откройте там, где говорится про теорему Котельникова (Найквиста). Эти сведения будут не менее актуальными/полезными.
Не знающих этого студентов отправляют с экзамена восвояси без дальнейших расспросов.

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

М-да?
А Вы о комплексной огибающей, случайно, ничего не слышали? Даже теорема такая, помнится, была.
И вообще, когда кажется, креститься нужно.

Никто не говорил что на прямую. С предворительным сдвигом ессно (хотя куда уж мне до гуру)

Я говорил именно про прямую.
А кто не умеет работать головой, тому приходится работать руками. Впрочем, некоторым, видимо, и мартышкин труд в радость...

А по-моему противоречет законам логики. И ещё закону "без потерь". Но тут вряд ли кого это интересует. Ведь если сигнал 1 МГц, то его огибающая может меняться во времени очень сильно. Если же его сдвинуть до 1 Гц, то она уже не сможет так же быстро меняться. Так что потери неизбежны.

А Вы в этом уверены?
У сигнала "1 МГц" огибающая не меняется вовсе, поскольку он есть гармонический.

...Другими словами, если на сигнале 1 МГц модуляцией передавать сигнал 100 кбод, то на сдвинутом сигнале 1 Гц я думаю и под микроскопом будет не найти эти 100 кбод.

Даже до 0 можно сдвинуть, и никакого микроскопа не потребуется.
Более того, нормальные люди только так и делают.

перенос целостного спектра с 8-30 на 0-22 оцифровка и восстановление его назад в 0-22 и перенос обратно на 8-30 вроде не противоречит никаким законам

только чтото я про 44 мгцне понял

если взять в прямую и оцифровать 8-30 44мя

получим 0-22 будет суммирован с 44-22
то есть вообще всё перемешается на фиг 14-22 сложится с 30-22

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

Люди! Я вас уверяю, что точность исказится! Не думайте, что я такой балбес (каким мемя разрисовывает местный гуру), что не знаю про переносы спектра радиочастот. Тут автор недвусмысленно описал что ему надо.

Мамой поклянётесь? ;)

ну пусть инвертируется. Восстановить-то всё равно можно

Всего делов-то: циклически сдвинуть выходные термы ДПФ.
Так нет же, гетеродины подавай...

ИМХО при сдвиге спектра какого-либо сигнала энергия модуляции распределяется неравномерно между Fс+Fг и Fс-Fг (Fс - сигнал, Fг - частота гетеродина), то есть на получившихся низких частотах будет меньше енергии, а верхние вы тут договорились отфильтровать и выбросить. Поэтому и восстановить точный вы сигнал не сможете.

[DS]

Приветствую!

Любой перенос частот с последующей фильтрацией вносит доп. искажения. Которые потом при постобработке могут непонятно как вылезти. Поэтому и просят сделать как можно проще и именно сырые данные. Например один из вариантов постобработки - взят сырые данные за часик и сделать стомилиооноточечное FFT затем домножить это на зависимость дисперсии сигнала в межзвезном прстранстве и назад IFFT - потом в результате ищут линии от далеких пульсаров.

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

[Stanislav]

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

Если диапазон 0-8МГц всё-таки нужен, то это верно.
Если не нужен, то неверно. Точнее, искажения можно сделать теоретически сколь угодно малыми.
Перенос частоты не нужен.

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

Э-э, извиняюсь... Стомиллионноточечное за часик измерения?
Вы случайно с частотой дискретизации АЦП не ошиблись? Поскольку такое ДПФ соответствует данным за время менее 2-х секунд при 62 МГц выборки.

ЗЫ. Кстати, а не проще ли в реал-тайме, во временнОй области фильтровать, без ДПФ? Не думаю, что такая зависимость описывается ста миллионами точек.

[RobFPGA]

Приветствую!


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


Успехов. Rob.

[blackfin]

...антенна имеет 150.000 M^2 более подробно - UTR-2

Чуднó.. На антенну площадью в полтора кв. километра денег нашли, а на новую плату $2000-$3000 найти не могут..


Кстати, если не секрет, для чего у Вас на плате DSP 6416?

[Stanislav]

Чуднó.. На антенну площадью в полтора кв. километра денег нашли, а на новую плату $2000-$3000 найти не могут..

Дык, посмотрите, в какие времена эти антенны делались. Тогда, видимо, денег хватало...

[GetSmart]

Э-э, извиняюсь... Стомиллионноточечное за часик измерения?
Вы случайно с частотой дискретизации АЦП не ошиблись? Поскольку такое ДПФ соответствует данным за время менее 2-х секунд при 62 МГц выборки.

Ну щас Stanislav будет учить уму-разуму RobFPGA, а вместе с ним и астрономов, чтобы они молчали и внимательно слушали когда говорит гуру

И не только слушали, но и переделали измерительное радиочастотное устройство, плату PCIX, а так же программное обеспечение прекрасно работающей системы под гениальную идею, созревшую в светлой голове Stanislavа

[RobFPGA]

Приветствую!


В данном случае DSP почти ничего не делает - в основном контрольные функции, установка параметров, EDMA для буферизации.



Успехов! Rob.

[Stanislav]

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

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

[blackfin]

В данном случае DSP почти ничего не делает - в основном контрольные функции, установка параметров, EDMA для буферизации.

А... Place-Holder... Ясно.. Я бы на этом сэкономил..
А PCI-X 64/66 можно было бы в Virtex'е синтезировать

[RobFPGA]

Приветствую!

Я брал готовую плату с PLX контроллером для других целей.
Потом уже возникла идея использовать ее и для этого проэкта.
Тем более первоначальный вариант был еще на Virtex2-3000,
тесно было, еле FFT впихнул, а сейчас в V4sx35 просторно и светло (пока еще).
Еслиб PCI контроллер был на FPGA то и проблем бы небыло.

Успехов. Rob.

[Stanislav]

Ну щас Stanislav будет учить уму-разуму RobFPGA, а вместе с ним и астрономов, чтобы они молчали и внимательно слушали когда говорит гуру

И не только слушали, но и переделали измерительное радиочастотное устройство, плату PCIX, а так же программное обеспечение прекрасно работающей системы под гениальную идею, созревшую в светлой голове Stanislavа

Простите, но я обращал свой пост к RobFPGA, и общался именно с ним.
Вы можете заметить, что здесь есть посты, посвящённые и Вам.
Убедительно прошу Вас прекратить флейм и вникнуть в суть написанного именно для Вас ранее, а также последовать доброму совету воспользоваться учебником по элементарным основам обработки сигнала.

[vetal]

2 Stanislav и GetSmart:
Нарушение правил п.2.1а.

[rv3dll(lex)]

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

так я тоже могу написать )))))

частоту дискретизации в студию?????

[GetSmart]

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

На день.

[rv3dll(lex)]

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

На день.

надеюсь сегодня сдлать выводы из предоставленной за сутки частоты дескритизации
а то как то тоскливо может чего то не понимаю образоване как раз строить сигнальные тракты - аналоговые)))

[rv3dll(lex)]

зато есть возможность подумать и посчитать
ждём от станислава предложений а не пустых слов типа ......