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

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


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


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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Успехов! Rob.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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