Czujnik prędkości wiatru

[SOYER]

1 godzinę temu, ethanak napisał:

@SOYER żaden sąsiad nie ma trachtora?

Co to za ustrojstwo?

Pierwsze testy za mną, powiem tak, prędkość ze wzoru nie ma nic wspólnego z rzeczywistością. Jeszcze nie analizowałem, to wieczorem, ale korekcja niezbędna, a najlepiej mapowanie jak pisaliśmy.

 

Edytowano 1 listopada przez SOYER

[SOYER]

Pierwsza analiza, tak na szybko.

Faktycznie widać nieliniowość, wraz ze wzrostem prędkości rośnie różnica między wynikiem obliczeń, a wskazaniami prędkościomierza.

Ostatnia kolumna w tej „tabeli” to stosunek prędkości obliczonej do realnej.

Oczywiście wahania dość spore przy jednej prędkości, warunki różne przy takich pomiarach, a i wietrznie dzisiaj było.

[SOYER]

Anemometr i esp8266, testy obliczeń

Było zabawnie:)

[SOYER]

void temporaryRPM(){
    noInterrupts(); 
    if((last_event + 2000) < millis()){    
     rpm=0;
     moment_kmh = 0;
    }
    else{ 
      rpm = (30000 / half_revolutions_time) ;
      moment_kmh = 6.28 * 0.075 * rpm/60.0 * 3.6;
      if(moment_kmh < 8.5){
        correct_moment_kmh = moment_kmh * 1.9;
      }
      else if((moment_kmh >= 8.5) && (moment_kmh < 25)){
        correct_moment_kmh = moment_kmh * 2.4;
      }
      else if((moment_kmh >= 25) && (moment_kmh < 38)){
        correct_moment_kmh = moment_kmh * 2.8;
      }
    } 
    if(sekund6.available()){
      tempKmh = tempKmh + correct_moment_kmh;
      sample++;
      sekund6.restart();
     }
    if(sample==10){
      average_kmh = tempKmh / 10; 
      //wiatr->setValue(kmh);
      tempKmh = 0;
      sample=0;
      sekund6.restart();
    }
   interrupts() ; //Przywróć przerwania
}

Z powodu sporych rozbieżności w pomiarach na razie postanowiłem wprowadzić 3 stopniową korekcję przeliczania prędkości. Jutro będzie spokojniejsza pogoda to sprawdzę to w praktyce, ew. naniosę kolejne korekty. Zmieniłem również sposób obliczania średniej z ostatniej minuty, opierając się na prędkości po korekcie, a nie na RPM.

Edytowano 1 listopada przez SOYER

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[Sylba]

9 godzin temu, _LM_ napisał:

Ale jak? Mocniejszy wiatr, więcej rpm

Tu ponownie w grę wchodzi mechanika, a w zasadzie mechanika płynów lub dokładniej aerodynamika. Generalnie ruch obrotowy, nazwijmy to miseczkowego wirnika, jest spowodowany momentem obrotowym wytworzonym przez przepływające wokół miseczek powietrze. Nie wdając się w szczegóły, miseczki w które wiatr napływa od strony wgłębienia stawiają większy opór niż te, na które powietrze napływa od strony wypukłej. Opór jest proporcjonalny do kwadratu prędkości względnej powietrza opływającego miseczki i współczynnika oporu. Prędkość powietrza wokół miseczek jest zmienna nawet przy stałej prędkości wiatru, gdyż wynika z prędkości wiatru i ruchu obrotowego wirnika.

Prędkość względna powietrza napływającego prostopadle na wypukłą część miseczki jest równa prędkości powietrza Vw plus prędkość liniowa miseczki Vr podczas gdy prędkość względna powietrz napływającego prostopadle na stronę wklęsłą jest równa Vw - Vr. Przy stałej prędkości wiatru wirnik wiruje z taką prędkością przy której momenty napędzający jest równoważony przez moment oporu powietrza oraz moment oporów mechanicznych przetwornika. Dynamikę ruchu wirnika opisano w licznych opracowaniach naukowych i badaniach. Istnieją również ścisłe procedury opisujące sposób kalibracji tych urządzeń. W sumie to dość skomplikowane zagadnienie.

[Sylba]

6 godzin temu, SOYER napisał:

prędkość ze wzoru nie ma nic wspólnego z rzeczywistością

Popatrz na to co napisałem powyżej. Wzór przelicza prędkość obrotową wirnika na km. Wszystko by się zgadzało gdyby prędkość liniowa miseczek była równa prędkości napływającego powietrza, ale tak nie jest.

6 godzin temu, SOYER napisał:

korekcja niezbędna, a najlepiej mapowanie

Tak na chłopski rozum, to masz rację. Można zmierzyć kilka prędkości, a wartości pośrednie interpolować prostą, albo krzywą.

[Sylba]

3 godziny temu, SOYER napisał:

Anemometr i esp8266, testy obliczeń

Aby zmniejszyć wpływ powietrza opływającego samochód możesz umieścić anemometr na kiju by był dalej od nadwozia.

[Sylba]

5 godzin temu, SOYER napisał:

Faktycznie widać nieliniowość, wraz ze wzrostem prędkości rośnie różnica między wynikiem obliczeń, a wskazaniami prędkościomierza.

Pokazuję twoje pomiary na wykresie wraz z linią trendu w postaci liniowej.

 

Drugi wykres pokazuje prędkość zmierzoną w funkcji prędkości obrotowej oraz prędkość obliczoną na podstawie wzoru. Tu też dodałem linie trendów w postaci funkcji liniowej. Dla wartości pomierzonej linię trendu opisuje równanie Vr = 0,0767*n - 2,6786. Równanie linii obliczonej ze wzoru Vw = 0,0282*n - 0,0449.

Na tej podstawie proponuję być przyjąć wzór obliczający prędkość Vk = 2,72*n. Gdy podstawisz do tego wzoru zmierzone prędkości obrotowe otrzymasz takie wyniki. Pomiary trzeba by powtórzyć. Szczególnie te, które znacznie odchylają się od linii prostej.

 

Edytowano 1 listopada przez Sylba

[SOYER]

7 godzin temu, Sylba napisał:

Pokazuję twoje pomiary na wykresie wraz z linią trendu w postaci liniowej.

 

Drugi wykres pokazuje prędkość zmierzoną w funkcji prędkości obrotowej oraz prędkość obliczoną na podstawie wzoru. Tu też dodałem linie trendów w postaci funkcji liniowej. Dla wartości pomierzonej linię trendu opisuje równanie Vr = 0,0767*n - 2,6786. Równanie linii obliczonej ze wzoru Vw = 0,0282*n - 0,0449.

Na tej podstawie proponuję być przyjąć wzór obliczający prędkość Vk = 2,72*n. Gdy podstawisz do tego wzoru zmierzone prędkości obrotowe otrzymasz takie wyniki. Pomiary trzeba by powtórzyć. Szczególnie te, które znacznie odchylają się od linii prostej.

 

Dzięki za bardzo wyczerpującą i pouczającą odpowiedź. Jesteś pewny, że współczynnik korygujący powinien być stały wraz ze wzrostem prędkości?

[SOYER]

Pora na deszczomierz. Tutaj również niespodzianki. Poradniki na internetach podają, że każdy impuls z czujnika to 0.2794mm opadu. W domyśle na m2.

Wziąłem do ręki strzykawkę 10ml, rozebrałem czujnik i zrobiłem kilka prob. Za każdym razem wychodziło mniej więcej 6 przechyleń wahadełka na strzykawkę. To nam daje ok 1.6ml na przechył. Celowo na razie nie piszę na impuls, o tym za chwilę. Te próby też powiedzmy średnio dokładne, bo jak widać na zdjęciach zdarza się, że napięcie powierzchniowe utrzymuje wodę w wahadełku pomimo przechylenia.

Obliczenia.

Pojemnik zbiorczy czujnika ma 110mm x 50mm to nam daje 0.0055m2. Czyli 1/181 część metra kwadratowego.

1.6ml na jeden przelew razy 181 daje nam 289ml/m2, czyli 0.289mm/m2. Czyli jesteśmy dość blisko wyniku podawanego przez producenta(?). Tak jak mówię pomiary są dość średnio precyzyjne ale śmiało możemy zaokrąglić ilość przelewanej wody z jednej części wahadełka na 0.28mm/m2.

 

Edytowano 2 listopada przez SOYER

[SOYER]

Teraz liczba impulsów z deszczomierza. Tu jest pewne zaskoczenie, którego przyznam nie rozumiem. Jeśli czytamy pin przy pomocy digitalRead() to faktycznie mamy stan wysoki po przelaniu na którąś ze stron. Jeden impuls na jedno wylanie. 

Jednak wszyscy piszą szkic na przerwaniach, a tutaj niespodzianka, dla ustawienia RISING lub FALLING mamy po dwa impulsy na każde wylanie. Dlaczego? To mi się nie zgadza ze zdrowym rozsądkiem. Dlaczego digitalRead widzi coś innego niż przerwanie. W funkcji przerwania mam debouncing:

void ICACHE_RAM_ATTR rn(){// wektor przerwania deszczomierza
  unsigned long static last_event1 = 0;
  if (millis() - last_event1 < 50) {   //debouncing
    return;
  }
  rai++;
}

To by znaczyło, że spora liczba tych urządzeń źle przelicza ilość opadów....

Opisywane rzeczy przedstawiam na filmach.

Kto wytłumaczy?

 

 

[SOYER]

Miałem błąd w funkcji przerwania, dotyczący eliminacji drgań, nie aktualizowałem zmiennej last_event1. Jednak poprawa nic nie zmieniła w wynikach szkicu.

Poprawiona funkcja:

void ICACHE_RAM_ATTR rn(){// wektor przerwania deszczomierza
  unsigned long static last_event1 = 0;
  if (millis() - last_event1 < 50) {   //debouncing
    return;
  }
  rai++;
  last_event1 = millis();
}

 

[SOYER]

Bardzo proszę kolegę @Treker, lub innego admina o wydzielenie moich trzech ostatnich postów w tym temacie(o deszczomierzu), do nowego wątku. Może się nazywać "Deszczomierz".

Niepotrzebnie pomieszałem sprawy, a tematu wątku już nie da się zmienić.

Dziękuję i przepraszam za zamieszanie.

[Sylba]

2 godziny temu, SOYER napisał:

Jesteś pewny, że współczynnik korygujący powinien być stały wraz ze wzrostem prędkości?

Jest to przybliżenie liniowe. W tym zakresie prędkości oraz mając na uwadze cel, któremu ma służyć, wydaje się zupełnie wystarczające.

Poprawiłem swoje szacunki przyjmując dodatkowo oczywisty punkt pomiarowy n = 0 [1/min] i odpowiadającą mu prędkość V = 0 [km/h]. Przyjmując zależność liniową V = a * n gdzie na podstawie pomiarów ap = Vmax / nmax = 100 / 1360 = 0,0735 oraz według wzoru aw = 3,6 * pi * R / 30000 = 0,0283 obliczyłem współczynnik do przeliczania prędkości wg wzoru na prędkość rzeczywistą k = ap / aw = 0,0735 / 0,0283 = 2,5972.

Wyniki pokazuję na wykresie. V teoretyczna to V = 2,5972 * Vwzór

Tabela z obliczeniami.

Jeśli starczy ci cierpliwości, to możesz powtórzyć kalibrację zwracając uwagę na pomiary zaznaczone w tabeli na żółto, które znacznie odbiegały od teoretycznej wartości.

 

[jand]

3 godziny temu, SOYER napisał:

każdy impuls z czujnika to 0.2794mm opadu. W domyśle na m2.

Jeśli podajemy wielkość opadu w mm słupa wody, to powierzchnia nie ma znaczenia - dla każdej będzie tyle samo.

Dopiero jeśli chcemy podać opad np. w litrach, to powierzchnia ma znaczenie (litry/m²).