Форум: Техническая поддержка

1. Корректирующий КИХ-фильтр, применённый в LTR35, теоретически описан в этой статье. В FPGA LTR35 этот корректирующий КИХ-фильтр реализован в целочисленной арифметике. Я полагаю, что "особенность после окончания переходных процессов "залипать" в непредсказуемом положении" теоретически невозможна в КИХ-фильтрах, поскольку эти фильтры не имеют обратной связи, в рамках которой мог бы происходить подобный арифметический эффект "залипания".
2. По поводу реализации цифровых фильтров высокого порядка в ЦАП LTR35: других данных, кроме общеизвестной документации на PCM4104, у нас нет. Но я сомневаюсь, что такой эффект "залипания" есть в PCM4104, поскольку это - топовый измерительный звуковой ЦАП по мировым меркам. Хотя насчёт тех или иных тонких эффектов в микросхеме PCM4104 Вы можете сами спросить на форуме техподдержки Texas Instruments, поскольку Вы наверняка точнее сформулируете (и сможете, при необходимости, переспросить специалиста TI) по интересующему Вас эффекту. С другой стороны, на форум техподдержки обычно выкладывают описание обнаруженной проблемы, а вопрос по необнаруженной проблеме там могут не понять
3. По поводу наличия тонких статистических эффектов в LTR35 - на этот счёт Вам явно требуется проводить дополнительные исследования - далеко за рамками штатной метрологии LTR35 (за рамками нормированных технических и метрологических зарактеристик LTR35).

Отредактировано Инженер (13.12.2020 11:42:23)

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

Зависание наблюдалось как минимум 6 раз в течение 40-60 минут после первого запуска. Все случаи - именно после первого запуска генерации после включения питания. Если после зависания генерацию перезапустить с теми же параметрами - она уже работает без проблем сутки и более.

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

Добавили использование циклического буфера. В буфер записывали информацию для получения прямоугольных импульсов частотой 1 Гц на выходе OUT8. К этому выходу подключили светодиод для контроля.

Было выполнено несколько десятков запусков. Зависание наблюдалось только 1 раз. То есть или эффект проявляется существенно реже, или не проявляется вообще (а это единственное зависание произошло по какой-то другой случайной причине).

Здравствуйте!

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

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

Здравствуйте, Алексей.
На выходе LTR35 в полосе частот примерно от 100 до 200 кГц имеется некоторое возрастания спектральной плотносити шума. Это связано с остатком внеполосного шума сигма-дельта ЦАП, который не до конца дофильтровался активными ФНЧ на выходах LTR35. Об этом сказано в руководстве пользователя https://www.lcard.ru/download/ltr.pdf п.17.4.3.2. Во многих задачах из области применения LTR35 эта особенность не оказывает влияния. Но по характеру Вашего вопроса я понимаю, что это может оказать влияние на статистически очень тонкий эксперимент, если в Вашем внешнем тракте нет линейного фильтра, у которого область частот 100 до 200 кГц входит в зону подавления (20 дБ подавления в полосе 100-200 кГц уже было бы достаточно).
Этот лепесток на спектре выглядит размазанным (как шумовой процесс), но его статистику никто не исследовал. Влияние этого процесса на Ваш эксперимент, скорее всего, зависит от электрофизических свойств внешнего тракта измерения, от полосы частото пропускания, наличия нелинейностей в тракте. Сама микросхема сигма-дельта ЦАП внутри LTR35 работает под управлением периодических внешних сигналов, но внеполосный шум от сигма-дельта преобразователя носит наверняка квазислучайный характер (истинная случайность там вряд ли достигается). Но, поскольку микросхема ЦАП в LTR35 управляется строго периодическими сигналами, то есть надежда на то, что краткосрочный и долгосрочный статистические эксперименты не будут различаться.

Здравствуйте!

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

(При этом такой режим не вносит физических ограничений для применений в задачах, где резкое изменение напряжения не нужно и/или физически невозможно, и для кодирования изменений достаточно 1 или 2 байтов.)

Здравстивуйте, Алексей. Технически возможно применить тот или иной метод сжатия при передаче данных из ПК на потоковый вывод в LTR35. Для этого нам потребуется разработать соответствующие прошивки FPGA и функции API. Но планов на такие работы пока у нас нет.

Алексей, для частного случая, когда в каналы ЦАП передаются неизменные значения отсчётов, сжатие потока данных было реализовано в модуле LTR35 изначально. Объясню это на примере 4-канального режима, когда поток данных, относительно номеров каналов, можно описать последовательностью:
1,2,3,4,1,2,3,4,1,2,3,4...
Если на 4-ый канал настроено обновление выхода ЦАП (граница кадра), а по 2-му каналу идёт константа, то её можно передать только один раз:
1,2,3,4,1,3,4,1,3,4...
При этом, синхронность потока не нарушится, если каждый отсчёт в 4-ом канале всегда безусловно передаётся. В предельном случае, если по каналам 1,2,3 сразу после первого отсчёта идут константы, то сжатый синхронный поток без потери информации будет таким:
1,2,3,4,4,4,4...
Другими словами, выходы каналов ЦАП всегда размножают предыдущее выведенное значение при отсутствии в текущем кадре отсчёта данного канала. Но в канале, по которому происходит обновление ЦАП, поток должен быть без пропусков для сохранения общей синхронности работы, в т.ч., и по остальным каналам.

Спасибо! Такой режим работы решает часть наших проблем, обусловленных техническими ограничениями LTR35.

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

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

Алексей, как указано в руководстве пользователя,

эти ограничения связаны с указанными ограничением пропускной способности интефейса модуля LTR. И максимальное количество каналов в данной таблице рассчитаны из предположения, что для каждого кадра в буфер LTR35 (размером 8 Mотсч.) через интерфейс были переданы новые отсчёты данных. Но эти ограничения в синхронном режиме могут быть ослаблены или даже полностью сняны (!) в ситуации, когда незменные значения отсчётов передаются только один раз, при следующем условии:  необходимо обеспечить условие неопустошения буфера 8 Mотсч. даже  в ситуации, когда на локальном промежутке времени указанный трафик на передачу будет превышен (и отчёты встанут в очередь на передачу), но в среднем (за время, сравнимое с временем наполнения буфера 8 Mотсч.) необходимый трафик на передачу не будет превышать указанные значения. В LTR35 нет других аппаратных ограничений на максимальное количество каналов в синхронном потоковом режиме.

С другой стороны, здесь следует сказать, что специально именно такой синхронный режим с сжатием данных у нас не моделировался и специально на этот случай LTR35 не проверялся  - мои рассуждения исходили только из понимания принципа действия LTR35.  И здесь могут быть следующие проблемы:
1. При отсутствии отсчётов в текущем кадре у корректирующего КИХ-фильтра соответствующего канала в LTR35 включается режим размножения последнего принятого отсчёта, а при возобновлении отсчётов этот режим выключается. Это заложено и было проверено, что в асинхронном режиме это работает, но явно в синхронном режиме (с непередачей константных значений отсчётов) это не проверялось.
2. Если включен режим эха данных от того канала, по которому происходит сжатие, то, эхо-поток будет соответствовать уже декомпрессированным данным (это может нарушить логику ПО, использующего данный режим). Нарушит ли такой режим работу LTR-сервера? - это ещё нужно понять.
3. Вообще, нужно понять, не нарушит ли этот "режим с сжатием" логику LTR-сервера подкачки данных в LTR35, поскольку входной трафик в LTR35 будет иногда меньше, чем данные от LTR35 серверу о трафике выходных декомпресстрованных данных LTR35.
По п.2, 3 необходима консультация нашего программиста Алексея.
Если корректную работу LTR-сервера в таком режиме обеспечить, то по п.1 мне проверить корректость синхронной работы (путём моделирования логики FPGA) будет относительно несложно.

Отредактировано Инженер (07.03.2021 16:18:00)

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

С точки зрения штатной библиотеки, обновление выхода настраивается по последнему разрешенному каналу ЦАП (или по DOUT, если все каналы ЦАП запрещены). При этом LTR35_PrepareData() также ожидает, что на входе данные на каждый отсчет представлены на все разрешенные каналы в порядке увеличения их номеров и в таком же порядке формирует выходной массив. Таким образом, для этого режима нужно либо вручную прореживать данные после PrepareData перед Send, либо вручную формировать поток на вывод для Send. При этом последний разрешенный канал должен быть без сжатия.

Здравствуйте! Eщё вопрос - возможно ли с помощью двух каналов LTR35, рассматривая их как координаты X и Y, "нарисовать" Архимедову спираль, используя арифметические генераторы (т. е. не загружая в LTR35 весь массив значений координат, а используя собственные вычислительные возможности LTR35). Требуется постоянные (или близкие к постоянным) шаг спирали и линейная скорость "рисования". Возможна ли необходимая доработка, если имеющегося в настоящий момент функционала для этого недостаточно?

В FPGA LTR35 в арифметическом режиме нет возможности изменять синхронно, с постоянным приращением, амплитуду квадратурного сигнала, чтобы получить Архимедову спираль. Этот функционал нужно дописывать.