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

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

Требуется в реалтайме, без потерь, ужать поток данных с двухканального АЦП с 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 и прочих сложностей. Даже на вскидку в голове возникают множество разных идей.

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

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

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

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


Успехов! Rob.
Нажмите для просмотра прикрепленного файла Нажмите для просмотра прикрепленного файла

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

Возьмите 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.

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

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

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

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

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


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

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

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

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

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

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

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

Не приписывайте мне то, чего я не говорил..
Сами попробуйте.. Мне это не нужно..

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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