треск АЦП LPC1768

[sysel 0]

Это ?

http://mbed.org/forum/mbed/topic/2003/

[porty 0]

нет, я не использую ДМА, я не использую ADGDR, я не использую Burst mode

[ViKo 0]

Предлагаю следующее решение.

Передискретизация (oversampling) -> медианный фильтр -> фильтр НЧ + децимация.

[porty 0]

Предлагаю следующее решение.

Передискретизация (oversampling) -> медианный фильтр -> фильтр НЧ + децимация.

отлично, просто велликолепно удаляются шумы и устраняются проблемы фазового дребезга, для варианта в 32кГц очень даже норм, но не для 100+кГц, там уже некуда оверсемплинг разгонять, а если разгонять АЦП сверх рекомендаций то вылазят такие помехи и шумы что ничем не поможеш

Edited June 2, 2011 by Porty

[ViKo 0]

отлично...

Это вы экспериментально проверили? Раньше делали, или сейчас?

Да, если АЦП на пределе быстродействия, такой метод уже не пройдет.

[porty 0]

в том то и дело что нужно на пределе, или делать для одного-двух голосовых каналов одну архитектуру а для 8 каналов другую что не интересно.

 

Пробовал в делфи, реально треск после медианного и оверсемплинга уменьшается раза в 2-3 на слух по сравнению когда нет оверсемплинга и даунсемплинга , но частотка не портится т.к. оверсемплинг, но появляется мелкий джитинг (на ффт выглядит как амплитудная модуляция - рядом с палкой частоты вылазит ещё две на -40 ... -50дб), и то только на FFT в 128-256тыщь точек виден, но на слух не слышен так что на него пофиг.

Edited June 2, 2011 by Porty

[Petka 0]

... но появляется мелкий джитинг (на ффт выглядит как амплитудная модуляция - рядом с палкой частоты вылазит ещё две на -40 ... -50дб), и то только на FFT в 128-256тыщь точек виден...

Это медианка вылазит так.

[Alecsej 0]

ADC characteristics (full resolution)

fclk(ADC) ADC clock frequency - - 13 MHz(max)

 

ADC characteristics (lower resolution)

fclk(ADC) ADC clock frequency 3.0 V ≤ VDDA ≤ 3.6 V - - 33 MHz(max)

[bug_fixed 0]

а какая версия чипа "-" или "А"?

[stepper88 0]

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

Интересует сегодняшнее положение дел с АЦП. Его исправили? Прошу прощения, если вопрос дурацкий, но собираемся заложить на пробу LPC1768 или что-нибудь из STM32. Устройство - GPS-треккер - будет использован для выносных датчиков, как АЦП, так и I2C (схемотехника частично наследуется от предыдущей модели на LPC2368). Поэтому интересует, стоит ли использовать именно LPC?

[AltemirX 0]

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

Интересует сегодняшнее положение дел с АЦП. Его исправили?

Насчёт исправления - не в курсе. Однако используем в серийных изделиях. О потенциальном баге предупреждены, спасибо коллегам ;) У самих пока не проявлялся (LPC1763). На ответственных измерениях программно добавлен медианный фильтр, так что не страшно. Заложен LPC1766 в другую серию изделий, где требуется большое кол-во аналоговых входов (расширение аналоговым мультиплексором) и относительно шустрая обработка без ЦОС. Скорее всего применю тоже программный фильтр и счётчик-ловушку, чтобы проанализировать наличие бага в проце. У знакомых ребят стоит LPC1768, пока не споткнулись на АЦП, но им в данный момент не до него было, если честно.

 

[AltemirX 0]

Может кому будет полезно, но обновилась еррата на LPC176x и LPC177x/8x. Описан баг по АЦП, в частности - с кривым A/D Global Data Register Цитирую:

ADC.2: A/D Global Data register should not be used with burst mode

or hardware triggering

 

Introduction:

On the LPC176x, the START field and the BURST bit in the A/D control register specify

whether A/D conversions are initiated via software command, in response to some

hardware trigger, or continuously in burst ("hardware-scan") mode. Results of the ADC

conversions can be read in one of two ways. One is to use the A/D Global Data Register

to read all data from the ADC. Another is to use the individual A/D Channel Data

Registers.

 

Problem:

If the burst mode is enabled (BURST bit set to ‘1’) or if hardware triggering is specified,

the A/D conversion results read from the A/D Global Data register could be incorrect. If

conversions are only launched directly by software command (BURST bit = '0' and START

= ‘001’), the results read from the A/D Global Data register will be correct provided the

previous result is read prior to launching a new conversion.

 

Work-around:

When using either burst mode or hardware triggering, the individual A/D Channel Data

registers should be used instead of the A/D Global Data register to read the A/D

conversion results.

[porty 0]

без всяких A/D Global Data Register щёлкали результаты или вообще случайные шли даже читая из регистров конкретных каналов.

 

Да и смысл в burst mode пользоваться глобальным регистром? Всё равно нужны конкретные каналы после окончания выборок пачки и прерывание настраивается на последний канал пачки или общее окончание работы ацп или просто опрос с заведомо большим интервалом чем обработка пачки.

[AltemirX 0]

Да и смысл в burst mode пользоваться глобальным регистром?

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

 

[AltemirX 0]

Ребят, есть ли новости с фронта АЦП в LPC176x? Сейчас поднял проект, где активно работаю с АЦП без фильтрации медианным фильтром. И - о ужас! LPC1763 rev.'A', LPC1768 rev.'-' обе имеют одинаковые проблемы, мусор может быть хаотическим на любом канале. Использую режим burst и канальные регистры результатов. Плохо то, что надо измерять среднеквадратичные значения, а медианный фильтр, если его использовать, повлияет на точность измерений. АЦП настроено на ~8000Sps, частота шины - 100МГц.

 

Удалось ли как-то победить этот капризный АЦП и есть ли инфа от NXP? Неужели за год компания так и не признала проблем с АЦП?