Ультразвуковой термометр, Он же анемометр и указатель направления ветра Опции

[Altair]

Увидел на выставке вооружений и военной техники вот такой прибор: http://www.sibai.ru/content/view/151/271/

Ну, понятное дело, "под хвостом" сразу засвербило - тоже такое хочу. Собрал вот такую схемку для измерения времени прохождения звукового импульса через воздух:






Работает так - возбуждаю датчик положительным импульсом длительностью 60 мкс. На приеме усиливаю, детектирую, фильтрую.

На выходе дает вот такое:

Голубой канал - перед детектором, желтый - на входе контроллера.

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

[Altair]

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

[Rst7]

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

Ух как все сложно-то

Как-то состряпал вот такую вещь, правда, до ума не довел - http://community.livejournal.com/ru_radio_electr/575454.html

[Altair]

Ага, видел. Но это не пойдет. Задача стоит так - определить температуру без термометра. Во. Точнее без именно датчика который должен выдавать значение температуры своего корпуса, которая более или менее соответствует окружающей температре.

Доплер - замечательно, и ежели я не смогу победить ту задачу которую я поставил, я применю какой нить DS1820, а собственно флюгер будет на Доплере.

[Rst7]

Но это не пойдет. Задача стоит так - определить температуру без термометра.

А смысл? Вычислять температуру воздуха по скорости звука - это слишком, как мне кажется. Потому как она только в идеальных условиях зависит только от температуры. А давление, а влажность?

а собственно флюгер будет на Доплере.

Это не совсем Доплер в классическом понимании. Тут сдвиг фазы (задержка сигнала) без изменения частоты.

[Евгений Германов...]

Вы бы намекнули,что за датчик используете?Картинка очень странная.Её бы соотнести с вашим возбуждающим импульсом.Rst7 вообщето прав.И кроме давления и влажности есть ещё и ветер,а он ,совместно с давлением и влажностью,меняет плотность воздуха и,как следствие,скорость распространения ультразвука.Или звука Картинка появиласть только после отсылки текста.Схемка очень плоха.У вас вход опера по постоянке висит в воздухе.

[Altair]

2 Rst7

А как определялся сдвиг фаз в вашей конструкции?

2 Евгений Германович

Датчик - пьезоизлучатель, на фотке его видно. Мембрана пластиковая. Но он типа ультразвуковой.
Какая картинка странная?

Возбуждающий импульс - подаю 5В с контроллера. Импульс один, длительность 60 мкс. Такая длительность была выбрана по максимально "отдаче" излучателя. Видимо это частота собственного резонанса излучателя. Кстати на приемной стороне как раз и видно что заполнение "дыньки" как раз около 6 кГц.

Чем плохо висение в воздухе входа? Это может гадить на фронты? Как поправить схему? Подать пол питания с делителя через RCR-фильтр?
Кстати, может и выход надо нагрузить? Что то мне кажется что голый вход компаратора это плохая нагрузка.

Сильнее всего на скорость распространения влияет температура. Влажность и давление - очень незначительно. Формулы описывающие зависимости в литературе есть.

Сообщение отредактировал Altair - Aug 7 2009, 15:37

[Rst7]

А как определялся сдвиг фаз в вашей конструкции?

Напишу сразу, как должно быть (сейчас немного через (_*_), но принцип тот же). Да, и имейте в виду, там весьма сильно используются особенности периферии AVR.

0. Все датчики подключены на порт C. Первый на PC0/PC1, второй на PC2/PC3, третий на PC4/PC5.
1. Тактовая частота проца 10.24МГц.
2. Таймер 1 считает от 0 до 255 (используется режим CTC), итого частота переполнений 40кГц, равная резонансной частоте датчиков.
3. Программно синхронно с таймером дрыгаем ножками текущего передающего датчика, например, PC0/PC1. Т.е. делаем PC0=0,PC1=1 и через 128 тактов PC0=1,PC1=0 и через 128 тактов повторяем (опять же точно 40кГц, причем, синхронно с насчетом таймера).
4. Мультиплексор АЦП подключен к аналоговому компаратору, вторая ножка компаратора на земле.
5. Соответственно, одна из ножек текущего приемного датчика включена на ввод и через мультиплексор АЦП попадает на компаратор, вторая - включена на вывод и на земле.
6. Выход компаратора включен на Input Capture таймера (установкой бита ACSR_ACIC)
7. В коде, который дергает ножками, проверяется флаг наличия ICP, и если он установлен, то значение регистра ICR прибавляется к интегратору (с учетом возможной смены знака).
8. Все это дело крутится в цикле измерения для накопления. Я делал 1024 раза. При этом, предварительно выполняется 4000 холостых циклов (для того, чтобы полностью закончился переходный процесс в приемном и передающем датчике).

Тонкости заключаются в работе со знаком при накоплении. Т.к. изменение значения ICR из 0 в 255 - это на самом деле вычитание 1, а не прибавление 255. Именно для удобства выбрана тактовая 10.24 (но начиналось все с тактовой 10МГц и досчетом таймера до 250, вот там бубен некислый).

[Altair]

А ведь можно немного немного сдвигать фазу исходного сигнала и смотреть через какое время прошло изменение фазы на приемной стороне. И таким образом определять время прохождения сигнала от передатчика до приемника.
А гененрировать передаваемый сигнал таймером 0.

[Rst7]

А ведь можно немного немного сдвигать фазу исходного сигнала и смотреть через какое время прошло изменение фазы на приемной стороне.

Сомнительно. Время будет сильно зависеть от добротности датчиков и изменения резонансных частот, намного сильнее, чем от скорости звука.

Ну и вообще, это не мой метод - много лишней электроники появляется

Вообще в потоке воздуха температура самого DS'а уравнивается за пять-десять минут. Неужели не устраивает?

[Altair]

Вообще в потоке воздуха температура самого DS'а уравнивается за пять-десять минут. Неужели не устраивает?

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

[Tanya]

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

Тогда сделайте термоанемометр...
Две проволочки. Одна на ветру. Два полумоста. Один 2-канальный внешний АЦП.
Или двойной мост, 2 ОУ + АЦП контроллера.
Но, в любом случае, некоторая механическая работа для защиты от птичек потребуется.

[Altair]

А термоанемометром направление ветра измерить? :-))

Прелесть исследуемого метода в том что получаем все и сразу. Правда для этого придется придется попотеть мозгом. ;-)

[Tanya]

А термоанемометром направление ветра измерить? :-))

Прелесть исследуемого метода в том что получаем все и сразу. Правда для этого придется придется попотеть мозгом. ;-)

Чтобы правильно измерять направление, надобно жить в деревне и иметь мачту.... или мечту. Если имеется только последняя, то только мечтать.

[Евгений Германов...]

Оба каскада сделаны не хорошо.1Уберите конденсатоы.2Эта схема вам не подойдет совсем.Опера вкл по схеме инвертирующего усилителя.Номиналы не рассмотрел,однако подобное вкл не блещет высоким входным сопротивлением.Сигнал очень странный.Желательно посмотреть его вместе со входным.Но есть вероятность того,что лучше не будет.У излучателей дальномеров,глубиномеров иная конструкция.В радио она была описана.

[Altair]

Чтобы правильно измерять направление, надобно жить в деревне и иметь мачту.... или мечту. Если имеется только последняя, то только мечтать.

Имею хоть и в городе, но десятиэтажный дом. Преобладающей ближайшей округе высоты. Ну мачту еще метра 3 можно сгородить. Думаю вполне нормально будет.


2 Rst7

А вот еще несколько вопросов. Вот включил ты устройство. Сдвиг фазы всегда постоянный?
Т.е. каждое включение в неподвижном воздухе одной и той же температуры всегда дает один и тот же сдвиг фазы?
Один раз записали для этой температуры где "ноль" и все? Дальше считаем что если от этого нуля сдвинулось, есть ветер?

Ведь можно туды-сюды померить фазовый сдвиг, сложить, поделить пополам и получим скорость звука. А значит и температуру.
А скорость звука определим как расстояние между излучателями поделить на время, которое равно n*(2п+f) (или все же n*2п + f??). n-это сколько полных периодов укладывается в расстояние между датчиками. Очень грубо количество 2п можно померить изменяя резко фазу излучаемого сигнгала и смотреть когда измениться на приеме. А значение фазы в последнем периоде как раз и даст ту маленькую точную прибавочку.

Если возбуждать излучатель от Таймера 0, то фазу очень легко менять. OCR0A=phase, OCR0B=phase+0x80. Ну в прерывании понятно дергаем излучатель.

[Rst7]

Т.е. каждое включение в неподвижном воздухе одной и той же температуры всегда дает один и тот же сдвиг фазы?

Это состояние называется "сферический конь в вакууме" В таком состоянии сдвиг фазы один и тот же.

Ведь можно туды-сюды померить фазовый сдвиг, сложить, поделить пополам и получим скорость звука. А значит и температуру.

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

Если возбуждать излучатель от Таймера 0, то фазу очень легко менять. OCR0A=phase, OCR0B=phase+0x80. Ну в прерывании понятно дергаем излучатель.

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

[Altair]

Это состояние называется "сферический конь в вакууме"

Ааааа!!! Старые знакомые!!! :-)

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

Отнюдь. Используя прерывания я как раз точно все и сформирую. Если в системе будет использоваться только два прерывания по OCR0A и OCR0B. Вход в прерывание вполне по тактам нормирован, а мне нужно только проследить что бы в самих обработчиках прерывания код был одинаковый. Так что думаю тут проблем с джиттером не будет, бо прерыванию может помешать только другое прерывание, а их нет. Зато! Я легко могу вертеть фазой исходногот сигнала. Ну и еще момент есть. "Прямокод" это для АСМа. А я от него уже отвык. :-)

А вот на приеме можно прерывание и не делать. Даже нужно не делать. В ICR1 информация сама запишется по событию, без моего участия. Мне остается только флаг контролировать. Так что пока не вижу причин для возникновения джиттера.

[CDT]

Отнюдь. Используя прерывания я как раз точно все и сформирую. Если в системе будет использоваться только два прерывания по OCR0A и OCR0B. Вход в прерывание вполне по тактам нормирован, ........................

Да-да. Именно отнюдь.

Имеются команды одно, двух и трех тактные.
Переход на вектор прерывания происходит по окончании выполнения текущей команды. Отсюда разбег (в зависимости от используемых команд) будет составлять 1-2 такта, что видно даже в эмуляторе.
Но это не безнадежно, если принять специальные меры.

[MaslovVG]

[Сильнее всего на скорость распространения влияет температура. Влажность и давление - очень незначительно. Формулы описывающие зависимости в литературе есть.

Сюда нужно добавить еще скорость и направление ветра итго 4 (если учитывать направление 5) переменных. Для того чтобы решить уравнение 4 переменных нужно иметь минимум 4 уравнения точнее 4 (идеинтичных) датчика на каждом из которых известно значение одного из определяемых параметров.
Померять с помощью одного датчика два или больше параметра среды невозможно. Кстати сдвиг по фазе и задержка по времени это всего одна сущность.

[Altair]

Переход на вектор прерывания происходит по окончании выполнения текущей команды. Отсюда разбег (в зависимости от используемых команд) будет составлять 1-2 такта, что видно даже в эмуляторе.
Но это не безнадежно, если принять специальные меры.

Например?

Сюда нужно добавить еще скорость и направление ветра итго 4 (если учитывать направление 5) переменных. Для того чтобы решить уравнение 4 переменных нужно иметь минимум 4 уравнения точнее 4 (идеинтичных) датчика на каждом из которых известно значение одного из определяемых параметров.
Померять с помощью одного датчика два или больше параметра среды невозможно. Кстати сдвиг по фазе и задержка по времени это всего одна сущность.

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

[MaslovVG]

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

В таком случае вам нужно расширит полосу пропускания детектора. Это повысит крутизну фронтов. Если Дрожание фронтов превышает период несущей то остается толко цифровая фильтрация результата (например скользящее среднее десятков измерений). Иначе можно добавить в систему фазовый детектор и повысит разрешение до точности измерения сдвига фаз.

[Altair]

Иначе можно добавить в систему фазовый детектор и повысит разрешение до точности измерения сдвига фаз.

Этот метод сейчас и обдумываю. Потому и терроризирую уважаемого Rst7 и всех присутствующих всякими вопросами. :-)

Не хочу лишнее железо, нужно все по максимуму программно реализовывать.


Кстати можно перед прерыванием контроллер загонять в Sleep. Тогда прерывание всегда будет стартовать из одного и того же места.

[CDT]

Например?

- Генерировать непосредственно таймером на ноге
- не использовать в программе многотактные команды
- зайдя в прерывание считать TCNT и компенсировать ошибку
- построить программу так, чтобы прерывание происходило из конкретного куска или места. Но это должна быть тупая и глухая петля типа rjmp pc

[_Pasha]

глухая петля типа rjmp pc

Ага. И будет джиттер в один клок Из этих методов самые прямые - первый и третий.

[Rst7]

Из этих методов самые прямые - первый и третий.

На самом деле метод со sleep тоже имеет право на жизнь

CODE

UREG16 Measure(void)
{
UREG16 frq=/*FREQ>>16*/1000;
SMCR=(1<<SE); //Idle sleep
//Запретили прерывания от USART'а
TIMSK0_TOIE0=0;
UCSR0B_RXCIE0=0;
//Запретили прерывания от измерителя частоты
//TIMSK1_ICIE1=0;
Start_ADC(frq*2,public_data.zero_real);
do
{
__sleep();
UREG rp=rx_pointer;
if (UCSR0A_RXC0)
{
((UINT8*)(&modbus_buf))[rp]=UDR0;
rp++;
TCNT0=256-146;
TCCR0B=4; //1:256, 1 у.е. = 25мкс
rx_pointer=rp;
}
__sleep();
if (TIFR0_TOV0)
{
//Быстрая проверка на пригодность принятого пакета
TCCR0B=0;
if ((rp<8)||(modbus_buf.pdu.addr!=2))
{
rx_pointer=0;
}
else
{
UCSR0B_RXEN0=0; //Наш пакет
}
TIFR0=1<<TOV0;
}
}
while(Test_ADC());
...
}

И вполне без джиттера

[MaslovVG]

Ещё один метод. (из радиолокации) На излучатель подавать линейно частотно модулированный сигнал. И измерять разностную частоту приемника и передатчика.

[livo]

Вопрос к Rst7:
А какие приемо-передатчики использованы (от чего, где достать)?
Датчики как-то должны быть изолированы от крепления, ведь звук по металлу быстее распространяется или это исключено програмно?

[Rst7]

А какие приемо-передатчики использованы (от чего, где достать)?

Мы покупали готовые. Не совсем эти, но эти тоже пойдут - http://cbsie.dyndns.info/passive31-ultrasonic-sensors.pdf

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

Там конструкция самих датчиков такая, что через корпус нифига не идет.

[livo]

Да уж, вменяемых цен на эти датчики в Украине не нашел, наверное дешевле будет сделать чашечный (хотя надежность конструкции пострадает)

[Rst7]

Мы покупали по 7 баксов. Я думаю, датчики от китайского парктроника вполне сойдут.

[Altair]

Сегодня пришел парктроник. На выходных попробую. В мануале написано что у датчиков диаграмма 60 и 60.

2 Rst7

Были ли помехи на приемной стороне от работы передатчика?

Сообщение отредактировал Altair - Aug 19 2009, 14:58

[Rst7]

Были ли помехи на приемной стороне от работы передатчика?

В смысле?

[Altair]

Сразу говорю - конструкция антинаучная. УЗ датчики длинными проводами подключены к STK500 напрямую.

Желтый канал - передатчик, голубой - просто датчик висящий в воздухе подключен к осцилу.


Датчик лежит мордой на столе. Ловим только помехи.


Вот помеха покрупнее:


Это я одел на приемный провод большое ферритовое кольцо и в нем три витка приемного провода.


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

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

Сообщение отредактировал Altair - Aug 20 2009, 03:32

[Rst7]

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

Я делал на макетке. Датчики подключал обрезками витой пары к лапкам проца. Так что игрался "на халяву".

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

Ставил резисторы параллельно датчикам (придавить мусор). Топологически они были между ножками проца. Если мне не изменяет память (сам девайс далеко) - то ли 10к, то ли 2.2к.

[Altair]

А как было организовано питание порта С? На AVDD питание напрямую подавалось или через RC?
Пытался навесить 1 кОм на ножки проца - особого эффекта не заметил. Думаю что наводка все же по длинным проводам. Буду укорачивать.

[Rst7]

А как было организовано питание порта С? На AVDD питание напрямую подавалось или через RC?

Напрямик.

Пытался навесить 1 кОм на ножки проца - особого эффекта не заметил.

Так а Вы тот датчик, к которому осциллограф подключен, нагрузили резистором? Для передачи, понятное дело, эти резисторы побоку.

[Altair]

Так а Вы тот датчик, к которому осциллограф подключен, нагрузили резистором? Для передачи, понятное дело, эти резисторы побоку.

Нет.

Вобще наверное затупил. На большом сопротивлении большие наводки. А нагружен датчик был только входом осцила.

Сообщение отредактировал Altair - Aug 20 2009, 05:51

[Rst7]

Вобще наверное затупил.

Именно

[Altair]

Значица так. Прикрутил к ногам проца резюки по 4,7 кОм. Которые шунтируют датчики.

Конструкция такая: два датчика от парктроника. Подключены к PC0-РС1, РС2-РС3. Датчики зашунтированы резисторами по 4,7 кОм. Контроллер в прерывании генерит 40 кГц. Остальная программа состоит из одной строчки: PORTB.0=ACSR&(1<<ACO);
Т.е. тупо выводит в порт состояние компаратора, которое я и смотрю осцилом.

В результате получилось следующее:

Желтый канал - выход компаратора, голубой - возбуждение датчика.

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





Но вот ежели я начинаю выходить за пределы этого диапазона, то начинается полная фигня. Смотрим первые картинки, представляем расположение и характер помех и понимаем что происходит:






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

Визуально адекватно можно определять фазу принимаемого сигнала на участке ограниченном маркерами:




Причины явления думаю в следующем. Используемые мной датчики - "дубовые". Почему я так решил? Сравнительный анализ датчиков от Murata показывает, что гереметичные датчики имеют заметно меньшую чувствительность, по сравнению с открытыми, какие и использовал уважаемый Rst7 в своей конструкции. У парктроника датчики мало того что герметичные, так еще и китайские. :-) "Дубовость", имеет два конца. С одной стороны слабо излучается, с другой - плохо слышится. Что в данной конструкции требует во первых близко располагать датчики, во вторых более внимательно относиться к диаграмме направленности. В частности при расположении моих датчиков под углом 60* друг к другу они просто перестали взаимодействовать. Таким образом нужно использовать 4 датчика и в Мегу 48 (в "минималистическом" исполнении) я не укладываюсь. Просто по скудости порта С. Из-за дубовости датчиков имеем малое отношение сигнал/помеха. Это приводит к нечеткому срабатыванию компаратора из-за слабого сигнала на его входе и наличия сильных помех.

Думаю что в такой конфигурации устройство не работоспособно.

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

Что думаете?

Сообщение отредактировал Altair - Aug 21 2009, 13:37

[Rst7]

Вы бы поигрались частотой возбуждения. Уверены, что датчики именно на 40кГц?

[Altair]

Поигрался. Несмотря на то что сам парктроник формирует пачки импульсов примерно в 38,5 кГц, датчики резонируют четко на 40 кГц (определил по дальности на которой датчики взаимодействовали при изменении частоты возбуждения)

Выход парктроника без датчика:




Выход парктроника с датчиком:




Сигнал на базе выходного транзистора:




Меж тем на датчике то 200 вольт... Понятно что мне столько не нужно, но все же...


З.Ы. 2 Rst7, а ведь у нас даты регистрации на этом форуме всего на 1 день отличаются :-)

Сообщение отредактировал Altair - Aug 22 2009, 05:08

[Rst7]

Конструкция такая: два датчика от парктроника. Подключены к PC0-РС1, РС2-РС3. Датчики зашунтированы резисторами по 4,7 кОм. Контроллер в прерывании генерит 40 кГц. Остальная программа состоит из одной строчки: PORTB.0=ACSR&(1<<ACO);

Огласите конктретно, в каком состоянии ножки. Должно быть так: например, на PC0/PC1 - противофазный меандр, PC2 - на вывод (уровень лог. 0), PC3 - на ввод, аналоговый мультиплексор подключен к компаратору, выбран канал ADC3, а другой вывод компаратора (AIN0, он же PD6) должен быть на земле. Еще очень желательно при помощи регистра DIDR0 запретить цифровые входы, но это по желанию.

[Altair]

Да да. Все именно так:

Код

// Analog Comparator initialization
ACSR=1<<ACIC;                                            
ADCSRA=0;
ADCSRB=1<<ACME;  
//Положительный вход компаратора на земле.
DDRD.6=0;
PORTD.6=0;  


// Global enable interrupts
#asm("sei")


//Конфигурим выход
DDRC.0=1;
DDRC.1=1;  
OUT0P=1;
OUT0N=0;

//Конфигурим вход - один вход-вход, второй - земля
ADMUX=ADC3;
DDRC.2=1;
PORTC.2=0;  
DDRC.3=0;
PORTC.3=0;

//Индикаторный выход
DDRB.0=1;

while (1)
   {
   PORTB.0=ACSR&(1<<ACO);
   };
}

А в прерываниях так:

Код

// Timer 0 output compare A interrupt service routine
interrupt [TIM0_COMPA] void timer0_compa_isr(void)
{
   PORTC^=0b00000011;
}

// Timer 0 output compare B interrupt service routine
interrupt [TIM0_COMPB] void timer0_compb_isr(void)
{
   PORTC^=0b00000011;  
}

[Rst7]

Да. Вроде все правильно. Видать чувствительность действительно мала

[Guest_orthodox_*]

До сих пор флюгер не сделал потому что в близкой доступности нет мех. обработки. Без нее нормальный флюгер не сделать.

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

[Altair]

... покупные подшипники, фольгированный стеклотекстолит и пайку , легкие листовые пластики и полимерный клей...компьютерный вентилятор...

Это банально. А потому - неинтересно. Для меня это очень важный момент, потому как проект делается для собственного удовольствия. :-)

[Altair]

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

Видео с осциллографа

[Rst7]

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

Вы бы не горячились про "гуанодатчики". Налицо большой оверхед в процедуре обработки прерывания по таймеру. С двух сторон от фронта/спада имеется мертвая зона, в которой значение пина, соответствующего компаратору не обновляется. Думаете, у меня зря там компаратор на ICP заведен? А так - все фурыкает. Хотя, сигнал малость слабоват (видно по тому, что меандр с компаратора не 50 на 50).

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

[Altair]

Мдя... Точняк. Заменил в прерывании возбуждения PORTC^=0b00000011;
на:
#asm("sbi 0x08,0")
#asm("cbi 0x08,1")

Судя по асм листингу прерывание существенно сократилось.

Видео завтра выложу. Дрожание снизилось с 4 мкс до 2 мкс.... Явно это тормозит проц.

Так что надо мудрить все по настоящему - думаю в "тестовом" варианте более не увидеть, т.к. наблюдать сигнал достоверно не смогу из-за программного метода его получения. А вот капчится он должен хардварно, независимо от кода.

З.Ы. Датчики все же гуано. при 60* развороте друг друга чуют только на 2 см, а напрямую начинают примерно на 35 см. Так что, либо 4 датчика, либо усилять.

Сообщение отредактировал Altair - Aug 25 2009, 16:41

[Rst7]

Судя по асм листингу прерывание существенно сократилось.

Вам бы еще компилятор сменить на вменяемый, например, IAR.

Так что, либо 4 датчика, либо усилять.

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

А по чем датчики брали?

[Altair]

Вот так выглядит при оптимизированном обработчике прерывания (масштаб такой же как на предидущем видео):

Видео с осциллографа

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

Думаю что не бывает плохих компиляторов, быват плохие программисты. :-)) В крайнем случае напишу #asm... и, эх раззудись плечо, размахнись рука... :-)) Хотя и отвык от АСМа капитально.

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

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


С датчиками оказалось сложно. Сначала хотел купить в Платане, но дешевых нет в наличии, а те которые есть предложили привезти по 500 р за шт. Я че то пожадничал. Негуманный ценник. И тогда заказал у китаезов вот такой парктроник. За 1000 р. я получил 4 датчика с комплектом электроники "для опытов". Правда пришлось месяц ждать доставки.
Отдельно датчики от парктроников по вменяемой цене тож не нашел.

[Rst7]

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

Неа. Разница есть. Надо драйвить сразу оба пина в противофазе. Значит, оба вывода датчика должны быть подключены к одному порту.

Думаю что не бывает плохих компиляторов

Бывают компиляторы, генерящие плохой код в не зависимости от мастерства программиста. ICC в их числе.

[Altair]

Неа. Разница есть. Надо драйвить сразу оба пина в противофазе. Значит, оба вывода датчика должны быть подключены к одному порту.

Пробовал и одновременно, и по очереди. Разницы не заметил.

Бывают компиляторы, генерящие плохой код в не зависимости от мастерства программиста. ICC в их числе.

У меня CodeVision. Хотя думаю особой разницы нет. Но меня ПОКА устраивает.

Вопрос еще такой. Интегратор это как? Мне представляется - сложить все измерения, например те же 1024 цкла, и по окончании поделить. Арифметическое среднее короче. Или принять первое значение, а потом в зависимости от значений следующих измерений либо прибавлять либо отнимать единичку к первому принятому?

Сообщение отредактировал Altair - Aug 27 2009, 01:29

[Rst7]

Интегратор это как? Мне представляется - сложить все измерения, например те же 1024 цкла, и по окончании поделить. Арифметическое среднее короче.

Да. Но есть тонкость - если значения будут колебаться 0,255,0,255... и т.д., например. Тут надо брать разность по модулю 255 между двумя измерениями и его дважды интегрировать.

[Огурцов]

А не думали умножить сигнал на sin/cos тех же 40кгц, а уже потом проинтегрировать ? Вроде бы должно помочь принципиально подавить помехи ?

[Rst7]

А не думали умножить сигнал на sin/cos тех же 40кгц, а уже потом проинтегрировать ? Вроде бы должно помочь принципиально подавить помехи ?

То не помехи были, уже ж разобрались. А добротность у датчика вполне приличная. Кстати, из-за приличной добротности я перед самим измерением вхолостую дую где-то 1000 периодов.

[Altair]

Можно измерять в диапазоне -128 0 +128. Значение капчи присваивать переменной типа signed char и отнимать 128. А для усреднения использовать модуль. Тогда получиться как в коде Грея - на краях диапазона различие в один младший разряд. Только одновременно нужно считать количество положительных и отрицательных компонент при усреднении, что бы понимать в положительной или отрицательной половине остаемся.

Сообщение отредактировал Altair - Aug 28 2009, 04:07

[Rst7]

Не совсем понятно, что Вы хотите сделать.

[Altair]

Ну например постоянно принимается 0-255-0-255. Мы это число переводим в знаковое и от каждого измерения отнимаем 128. ТОгда получается что на выходе то -1 то 0. Вот их и усредняем. О, даже и отнимать ничего не надо. В знаковом виде будет то -127 то +127. Таймер то считает от 0 до 255, а в знаковом виде - от -127 до +127. Т.е. когда он досчитал до +127, переполнился и начинается - 127. Или я что то неправильно понимаю?

[Rst7]

Или я что то неправильно понимаю?

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

[Altair]

Нет. Я точно напутал. Но идея такая - перевести значение каждого измерения в код Грея, а уже в нем усреднять. Т.е. использовать свойство кода Грея в отличии любого соседнего значения только на один младший разряд.

[Rst7]

Но идея такая - перевести значение каждого измерения в код Грея, а уже в нем усреднять. Т.е. использовать свойство кода Грея в отличии любого соседнего значения только на один младший разряд.

Причем тут код Грея? Достаточно того, что разность между двумя измерениями стремится к 0. Ху из разность? Правильно, производная. Значит, чтобы получить среднее по всем измерениям, надо дважды проинтегрировать разности соседних измерений (сначала получить интеграл производной, т.е. собственно значение измерения, но уже без переполнения, т.к. производная мала (помещатеся в signed char), а интегратор - достаточно широк, например, 16 бит для простоты), а затем - проинтегрировать (усреднить) уже полученные "непереполняющиеся" значения измерения.

[Altair]

2 Rst7

Т.е. так?

Интегратор(16бит) += (Текущее_измерение - Предидущее_значение);

... повторям много раз

Фактическое_значение = Интегратор/количество_отсчетов

[Rst7]

Нет. Не так.

Интегратор1(16бит) += (Текущее_измерение - Предидущее_значение);
Интегратор2(32бита) += Интегратор1;

... повторям много раз

Фактическое_значение = Интегратор2/количество_отсчетов

[Altair]

ЭЭЭэээ...
А разве это не одно и то же?

Разве нельзя сократить

Интегратор1(16бит) += (Текущее_измерение - Предидущее_значение);
Интегратор2(32бита) += Интегратор1;

... повторям много раз

Фактическое_значение = Интегратор2/количество_отсчетов

до

Интегратор2(32бита) += (Текущее_измерение - Предидущее_значение);

... повторям много раз

Фактическое_значение = Интегратор2/количество_отсчетов ??


Или Интегратор1 тоже static?

Сообщение отредактировал Altair - Sep 7 2009, 12:54

[Rst7]

Или Интегратор1 тоже static?

Конечно. Где Вы видели интегратор не static?

[Altair]

Конечно. Где Вы видели интегратор не static?

- Семен Семеныч!!!
- Ах да, да...


:-))

[Rst7]

Только если быть до конца точным, то должно быть

Код

Int1+=(signed char)(cur_val-prev_val);

Обратите внимание на приведение типа именно к 8ми битам со знаком. Если его не написать, то компилятор исполнит integer promotion и все пойдет по женскому половому органу

[techlab]

Уважаемый RST7, а можно взглянуть на ваш вариант программной реализации? Собственно интересует сам механизм измерения сдвига фазы

[Rst7]

Уважаемый RST7, а можно взглянуть на ваш вариант программной реализации? Собственно интересует сам механизм измерения сдвига фазы

Так вроде все описано выше. Конкретно код там довольно специфический и нечитабельный, по большому счету.

[techlab]

Так вроде все описано выше. Конкретно код там довольно специфический и нечитабельный, по большому счету.

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

[Rst7]

не совсем понимаю сам механизм работы ацп в данном решении

В данном решении не используется АЦП, только компаратор.