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

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

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

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

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

Удачи! Rob.

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

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

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

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

Как Вам такой вариант? (работает для гладких сигналов)
Исходные данные - 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 бит.

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

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

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

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

Успехов.

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

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

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

Удачи! Rob.

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

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

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

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

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

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

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

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

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

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