Jak ustabilizować pomiar prądu na ATmega8 przy zasilaniu silnikiem mikrowiertarki?

Teoretycznie możanby zwiększyc ilość pomiarów do np 100. W tym przypadku
lepiej by było jeszcze porównywac je i odrzucać szczególnie za duże/za małe
wartości. dopiero wtedy miałoby chyba to sens.

Ale tego chyba właśnie nie zajarzyłeś.

Mierz prąd co kilkanaście (czy ile tam trzeba) ms, każdy pomiar zapisuj w
pamięci.
Niech pamięć ma rozmiar 256 pomiarów. Po zapisaniu 255 komórki, zacznij
nadpisywać dane w komórce nr 0.
Średnią zaś licz co pomiar z zakresu od 1 do 256 komórek. Tu możesz
sterować sobie.

Dzięki temu średnią masz co kilkanaście ms liczoną z okresu od 1 do
256xkilkanaście ms (to może być nawet i 1 s).
Oczywiście pomiar pierwszych 256 próbek jest zafałszowany (bo były same
zera w pamięci).
Nie przesadzaj z długością, bo się bedzie muliło. Tak jak z za duzym C w
filtrze RC.

Mógłby przydać się filtr medianowy. Zasada jest trywialna: dla każdej
nowej próbki sortujesz bufor i wybierasz środkowy element = wynik
filtrowania.

Załóżmy że mamy 250 pomiarów co 10ms. Czyli zapis do komórki 1 bedzie co
2,5 sekundy Jeżeli będziemy mieli skok prądu z 2 na 4 A to efekt przejścia
z 2 na pełne 4 bedzie trwał 2,5 sekundy w skrajnym przypadku. To bardzo
duże C

ale kto Tobie każe robić tak duży filtr. Tu właśnie jest pole do popisu i
optymalizacji okresu próbkowania i ilości próbek.
Zresztą masz do wyboru, albo duży kondensator albo trochę pamięci do
wykorzystania.

A może też taki drobny uśredniający filterek programowy.
Nie zaszkodzi przecież.
Dla przykładu, zajmujesz kawałek pamięci, zapisujesz ją w kółeczko, a
pomiar polega na policzeniu średniej z tegoż obszaru.
Jak ilość próbek będzie wielokrotnością 2ki to i średnią łatwo się liczy.




No to zrobiłem też. Robie 10 pomiarów, dodaje do siebie i dziele przez 10.
Ale jeżeli każdy wynik jest inny ze zwględu na zakłucenia to niewiele to
daje.

Mógłby przydać się filtr medianowy. Zasada jest trywialna: dla każdej
nowej próbki sortujesz bufor i wybierasz środkowy element = wynik
filtrowania.

Czyli po 10 pomiarach wyrzucam pierwszy, dodaje kolejny i znowu licze
średnią? Czy to bedzie lepsze niz srednia z kolejnych 10?

Dzięki temu średnią masz co kilkanaście ms liczoną z okresu od 1 do
256xkilkanaście ms (to może być nawet i 1 s).

To już lepiej brać 8 lub 16 próbek a dzielenie zastąpić przesunięciem
wyniku
w prawo o 3 lub 4 bity.
K.

To już lepiej brać 8 lub 16 próbek a dzielenie zastąpić przesunięciem
wyniku
w prawo o 3 lub 4 bity.
K.


A jaka to różnica w działaniu filtra?
Filtra - niewielka. Programu - ogromna. Przesunięcie w prawo to jedna

Filtra - niewielka. Programu - ogromna. Przesunięcie w prawo to jedna
bitowa operacja asemblera, jeden cykl procesora. A dzielenie przez 10 jest
operacją matematyczną wykonywaną programowo, zwłaszcza na avr który nie ma
sprzętowego dzielenia

Filtra - niewielka. Programu - ogromna. Przesunięcie w prawo to jedna
bitowa operacja asemblera, jeden cykl procesora. A dzielenie przez 10 jest
operacją matematyczną wykonywaną programowo, zwłaszcza na avr który nie ma
sprzętowego dzielenia


No fajnie tylko trzeba jeszcze pisać w asemblerze, czego nie robie, a avr z
dzieleniem programowym radzi sobie dość dobrze. Program gotowy na pomiar
napiecia i pradu z filtrem programowym(niewielkim) zajął mi 3k kodu. Zatem
miejsca mam jeszcze oporowo
Jest coś takiego jak kultura programowania, nawet jeśli ty nie widzisz

No fajnie tylko trzeba jeszcze pisać w asemblerze, czego nie robie, a avr z

Uwierz w kompilator.

No fajnie tylko trzeba jeszcze pisać w asemblerze, czego nie robie, a avr
z dzieleniem programowym radzi sobie dość dobrze. Program gotowy na
pomiar napiecia i pradu z filtrem programowym(niewielkim) zajął mi 3k
kodu. Zatem miejsca mam jeszcze oporowo
Jest coś takiego jak kultura programowania, nawet jeśli ty nie widzisz
różnicy, to nie znaczy że w kodzie (po skompilowaniu) nie ma. Skoro
dzielenie przez potęgę dwójki kompilator może zamienić na jeden rozkaz
asemblera (kodu maszynowego) a do twojego dzielenia musi wrzucać
skomplikowaną procedurę, to różnica musi być. Choćby w prędkości działania
programu - nawet jak ci nie zależy na niej zbytnio, ani nie wyciskasz
ostatnich us z czasu procesora, to lepiej program pisać tak by był
maksymalnie wydajny i "płynny" (a nie stawał w bliżej nieokreślonych
miejscach na jakimś dzikim obliczeniu programowym na zmiennej
wielobajtowej na kilkanaście/dziesiąt ms), a potrzebne opóźnienia "waity"
były robione programowo w tych miejscach i w takiej wielkości jaką
zaprojektujesz, a nie "jak wyjdzie"