Стенд и оборудование для испытаний и измерений VIII

Serge77> Думаю, надо наконец-то записать данные и попробовать их обработать, тогда сразу всё станет ясно.
Тут у меня конструкция получилась из серии "левой ногой правое ухо почесать". Т.е. не то чтобы невозможно, но неудобно и неприятно после сборки потом что-то менять: угораздило не на той стороне платы входной усилитель смонтировать.

Вот, и в этой связи хотелось бы получить хотя бы минимальное теоретическое обоснование дальнейших действий. Основной вопрос сейчас - какой Ку выбрать: на 8 кгс или на 80? Чтобы сохранить приемлемое для моей задачи разрешение в районе 20 г?

Non-conformist> Правильно ли я понимаю, что если сейчас при Ку = 11000 напряжение шума у меня, например, 40 мВ, то для того, чтобы получить напряжение шума 5 мВ, нужно уменьшить Ку примерно в десять раз? И тогда можно будет пользоваться шумовым усреднением?

Если 5 мВ — это среднеквадратичное значение, то да, примерно так.
Точное значение оптимальной величины шума зависит от числа отсчётов, участвующих в усреднении.
Формулы для расчёта не знаю.
Для прикидок:
величина_шума_усреднённого_значения = величине_шума / корень_из_числа_отсчётов.
То есть, усреднил 100 отсчётов, шум уменьшился в 10 раз.

Non-conformist> А какое разрешение можно получить при диапазоне измеряемых нагрузок 8 х 10 = 80 кгс, пользуясь шумовым усреднением?

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

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

В общем, больше скорость, меньше забот.

Xan>> Чтоб пользоваться шумами, они должны быть амплитудой в несколько тысячных.
Serge77> Несколько тысячных чего?

Разговор, обычно, о МК с 10-битным АЦП — 1/1024 ~ 1/1000 от всей шкалы.

Serge77> По теории, шум прежде всего должен быть белый, это самое главное. Вроде бы здесь так и есть? Так почему не будет работать усреднение?

Не понял вопроса.

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

Сначала попробую записать то, что уже спаяно, т.е. Ку = 11000. Без усреднения. Потом 5000, потом 1000. С усреднением.

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

Non-conformist> Сначала попробую записать то, что уже спаяно, т.е. Ку = 11000. Без усреднения. Потом 5000, потом 1000. С усреднением.

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

Xan>> Чтоб пользоваться шумами, они должны быть амплитудой в несколько тысячных.
Serge77> Несколько тысячных чего?
Serge77> По теории, шум прежде всего должен быть белый, это самое главное.

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

Serge77> Вроде бы здесь так и есть? Так почему не будет работать усреднение?

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

Serge77> Думаю, надо наконец-то записать данные и попробовать их обработать, тогда сразу всё станет ясно.

Если типичная постоянная времени объекта 10 секунд (печка), то и 50 Гц наводка на термопару отлично подходит для точного усреднения.

А.С.> Шум необязательно должен быть белый, как и у тебя в высотомере, он не белый нифига.

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

Non-conformist> Если всё пройдёт нормально, то тогда мяч перейдёт к ГОГИ - пусть напишет небольшую тестовую программку для записи... ???
Подключал сегодня к своему стенду съёмную плату МК. Ток потребления возрастал с 4,5 мА до 9,6 мА - колебался вокруг нового значения три-четыре секунды, и устанавливался. Что это значит? Так происходит штатный запуск нового, незапрограммированного МК?

Изменений шумовой картины в аналоговой части с подключением цифровой замечено не было. Запаял временный разъём программирования. Нужна тестовая программа записи данных. Но прежде, наверное, стОит каким-то образом проверить МК, например помигать лампочкой через ядерный предохранитель по РС4? Или попищать пищалкой? Схему прилагаю.

Потихоньку вспоминаю эпопею с POV-мигалкой, хе-хе...

Установил драйвер USBASP (УСБ-адаптер), воткнул, подключил сабж, прочитал фьюзы. Вроде всё нормально, можно программировать. ГОГИ?

ГОГИ! Нарисуй, пожалуйста, где ставить галочки. Питание 5В, внешний кварц 12,00 МГц. Ну и всё остальное, применительно к схеме выше.

Блин, ты скачай какую-нибудь оболочку к AVR dude, в которой не надо лезть в даташит, чтобы фьюзы выставить.
Например:

По ДШ вроде разобрался, не стал новую оболочку качать. Настроил внешний кварц на 12 МГц, остальное пока не трогал.

***
Модифицировал программу мигания светодиодом для управления ксановым ядерным предохранителем. Т.е. сделал импульсы длительностью 10 мкс. Вывел их на PC4, наблюдаю осциллографом.

Суммарный ток потребления системы (с усилителем) в районе 22 мА. Импульсы красивые, 10 мкс = как заказывал, амплитуда 4,5 В. Единственное замечание - единичный уровень меандра не гладкий, а размазан ВЧ-колебаниями амплитудой до 200 мВ. Это нормально? Может ли такое быть из-за неправильной разводки кварца?

1. #include <ioavr.h>
2. #include <intrinsics.h>
3.  
4.  
5. int main(void)
6. {
7.   DDRC = 16;
8.  
9.   while(1){
10.     PORTC = 0;
11.     __delay_cycles(120);
12.     PORTC = 16;  
13.     __delay_cycles(120);
14.   }
15.   return 0;
16. }

Прогресс идёт семимильными шагами: пищалку на PC5 с полпинка пищать заставил на одном килогерце... Лехко!

Вах, программист, слушай да? Давай набросай тестовую программку для записи, да?

Прошу прощения за красную рамку, случайно.

GOGI> Ну а как ты сделал в любом случае не правильно, вечером из дома напишу, почему.
Вот чёрствый человек да! Спасибо хоть не забанил да!

А вот на пищальном меандре (1 кГц) размах ВЧ-шума (это, видимо, двенадцатимегагерцовые такты и есть) на единичных полках составляет лишь 65 мВ, т.е. амплитуда в районе 30 мВ.

зы: Двести милливольт шума выше - это тоже таки размах.

GOGI> DDRC_DDC4=1;
GOGI> PORTC_PORTC4=1;
Строчку
#include <inavr.h>
вставил. Заменил на процитированное. Компилятор ругается:
Error[Pe020]: identifier "DDRC_DDC4" is undefined

Обнаружил, что общий для МК и усилителя стабилизатор питания есть не совсем гут. При подключении МК-платы, питание на выходе стабилизатора проседает с 5,02 В до 4,99 В. Этого, как оказалось, вполне достаточно, чтобы ноль, сбалансированный делителем на входе ОУ, почти ушёл за пределы линейного диапазона.

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

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

1. #include <ioavr.h>
2. #include <inavr.h>
3. #include <intrinsics.h>
4. #define Out1DDR DDRC_DDC4
5. #define Out1Pin PINC_PINC4
6. #define Out1Port PORTC_PORTC4
7. #define Crystal 12000000
8.     void SetOut1 (unsigned char Duration)
9.     {
10.       unsigned long Duration1=10000*(long)Duration;
11.       Out1DDR=1;
12.       while(Duration1>0){
13.         Out1Pin=1;
14.         __delay_cycles(Crystal/100000);
15.         Duration1-=1;
16.       }
17.     }
18.     void main(void)
19.     {
20.       SetOut1(10);
21.      
22.     }

Тут вместо того, чтобы писать
PORTC=1
пауза
PORTC=0
пишем PINC=1 такая запись в регистр инвертирует текущее значение регистра PORT. Удобно, когда надо включать и выключать порт.
Длительность вывода в порт задается в десятых долях секунды

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

И поставь себе Proteus, наконец уже!

Заменил, поставил галочку - теперь всё компилится. Ни строчки кода не понятно, но всё работает.

По поводу dropbox - тебе надо, наверное, сообщить мне свои реквизиты, например gmail или yahoomail, и тогда я смогу пригласить тебя в мою папку (расшарить её для тебя).

Папку с этим примером расшарил на тебя. С него и начнем.
Какой следующий шаг?

---

Так и не написал, почему ты портом неправильно управляешь
Ты написал PORTC=16; в общем-то понятно, что установил бит 4 порта в единицу. Но если бы ты написал PORTC=136, тут уже без калькулятора сложно понять, что установлены биты 7 и 3. Поэтому надо привыкать к 16-ричной системе, потому как запомнить соответствие 16 цифр четырехбитным последовательностям много проще, чем 256 чисел - восьмибитным. И со временем начнешь сразу видеть, что PORTC=0x88 это седьмой и третий бит.
Кроме этого, написав PORTC=16; ты не только установил бит 4 в единицу, но и сбросил все остальные биты в ноль, хотя тебе этого по смыслу не требовалось. От этого надо отучаться сразу, потому как потом такие баги очень сложно отыскивать.
Поэтому ты должен был сделать так: PORTC|=(1«PORTC4); а сбросить бит вот так PORTC&=~(1«PORTC4); по началу такое непривычно, но потом просто.
Ну и IAR, если в конфигах биты расписаны, позволяет напрямую управлять отдельными битами в порту. И также получать состояние одного бита. Например, сделать что-то если на 4 пине порта C логическая единица
if (PINC_PINC4==1) {do_something()}
или просто
if (PINC_PINC4) {do_something()}