Proporcja czasu stanów LOW i HIGH na czujniku krańcowym

[Elvis]

Przecież sam zaproponowałeś użycie reszty z dzielenia. Wcześniej nikt o niej nie pisał - albo ja czegoś nie widzę.

[Wrona]

Dobra, chłopaki dziobaki .... kto nie chce nic powiedzieć niech zamilknie a kto chce coś pomóc to serdecznie zapraszam. Programistą nigdy nie zastanę ale na swoje potrzeby chciałbym umieć coś tam naskrobać. Do szkoły elektronicznej też nie pójdą bo to też nie moja bajka co nie zmienia faktu że kwestie te mnie interesują. Mało o tych zagadnieniach wiem dlatego pytania i wątpliwości mam ciągle i gdy ktoś zechce to mi odpowiedzi udzieli.

A wracając do sprawy jestem trochę cyfrowo wykluczony i nawet ruotera nie mam ale planuje zakup właśnie ze względu na bezprzewodową komunikacje z Ardiuno. Chyba nie ma takich prostych modułów WiFi wpinanych do USB w Arduino? W takim wypadku trzeba przemóc lęki i zainteresować się ESP8266 plus konwerter poziomów logicznych. Dobrze kombinuje?

By dokończyć kwestie tego zliczenia otwartych drzwi. Absolutnie nie chce wiedzieć ile razy je otwarto i zamknięte. Do niczego tez nie potrzebuje wiedzieć o której godzinie się otwarły i zamknięte za każdym razem. Konkretnie chce wiedzieć ile czasu w ciągu zadanego okresy były otwarte a ile były zamknięte. Pomoc moich pierwszych korespondentów była trafiona w dziesiątkę. Naprowadzili mnie na właściwą drogę i rozbudowałem troszkę propozycje Trekera i mam dokładnie to czego potrzebowałem. Nie oczekuje niczego więcej bo mam co chciałem, ale jeśli ma ktoś lepszy pomysł to piszmy, dyskutujmy, wymieniajmy albo nawet ścierajmy poglądy. Jedynie się nie obrażajmy! Ty masz doktorat z programowania a ja mam doktorat z biologii kwantowej, każdy od każdego może się czegoś nauczyć.

[Elvis]

Wrona, nie gniewaj się za offtop w Twoim wątku. Po prostu zaciekawiło mnie jak można jednym operatorem w C wykonać dzielenie całkowite z przesunięciem. O takie małe skrzywienie zawodowe.

W każdym razie wracając do meritum - rozwiązanie ze zliczaniem momentów otwarcia/zamknięcia drzwi jest idealna, bo prosta. Dodawanie obsługi przerwań nie ma sensu, szkoda tylko komplikować sobie życie. Możesz dodać RTC - wtedy wystarczy, że w pętli będziesz odczytywał:

1) czas

2) stan drzwiczek

I odpowiednio aktualizował liczniki. Największa zaleta takiego rozwiązania to ucieczka od problemów ze zliczaniem czasu. Jeśli wykorzystasz delay do odmierzania czasu, do każdego cyklu pomiaru/czekania dodasz niewielkie opóźnienie, a wraz z nim błąd. Niestety te błędy będą się sumować, po dłuższym czasie dając (być może) istotną odchyłkę. RTC jest ucieczką od problemu - nawet jeśli delay się rozjedzie, czas będzie pobierany z zewnętrznego źródła.

[Wrona]

Nie gniewam się i oczywiście mnie też interesowała odpowiedz na to pytanie. Ale skoro "nie" to "nie" i sprawa zamknięta.

Co do czujnika w drzwiach to jak już pisałem to nie jest zliczanie momentów otwarcia/zamknięcia bo to mnie nie interesuje tylko jest to zliczanie proporcji okresu kiedy drzwi są otwarte w jednostce czasu. Tzn. nie interesuje mnie ile razu drzwi się otworzyły tylko przez jaki czas były otwarte. Przez raz otwarte drzwi może wejść jedna osoba albo 10 więc zliczenie ilości otwarć nie mówi o ruch jaki panuje w tych drzwiach. Może się tak zdarzyć że w ciągu godziny drzwi zostaną otwarte tylko raz i przez cała godzinę będą otwarte i to nie znaczy że weszła jedna osoba tylko oznacza to 100% ruchu czyli cały czas ktoś przez nie przechodził. Nadal nie wiemy czy było to 1000 czy 1050 osób ale to już mniej ważne. Ważne że ruch "w kiblu" był taki że drzwi się nie zamykały, czyli czas wezwać sanepid do tego lokalu

Możesz dodać RTC - wtedy wystarczy, że w pętli będziesz odczytywał:

1) czas

2) stan drzwiczek

I odpowiednio aktualizował liczniki. [...]

Niestety te błędy będą się sumować, po dłuższym czasie dając (być może) istotną odchyłkę. RTC jest ucieczką od problemu

A to jest jakiś pomysł czy lepszy dla mnie czy nie to się okaże jak już nabędę RTC.

Zbadam wtedy kwestie odchyłek czyli dzięki zegarowi określę jak różnią się interwały czasowe kolejnych pomiarów. Jeśli będą za duże to faktycznie pomiar ten rozbuduje o zegar a jeśli będą zaniedbywalne to zastanę przy obecnym rozwiązaniu. Dzięki wielkie, informacja o odchyłkach "delay" jest dla mnie nowością i takie informacje mnie szczególnie interesują.

[Elvis]

Nie chodziło mi o odchyłkę samego delay-a (chociaż ta też może wystąpić), ale o pozostały kod. Chodzi o to, że wykonanie każdej instrukcji zabiera pewien czas. Więc jeśli masz kod:

delay_ms(100);
delay_ms(100);
delay_ms(100);
delay_ms(100);
delay_ms(100);

To jego wykonanie zajmie dokładnie 500ms - o ile oczywiście delay_ms działa dokładnie.

Ale jeśli zmienisz kod na:

for (i = 0; i < 5; i++)
   delay_ms(100);

taka wersja zajmie już trochę więcej niż 500ms - raptem kilka mikrosekund więcej, ale zawsze.

Więc jeśli chcesz zrobić naprostszą wersję programu:

 while (1) {
  // wykonaj pomiary
  // wyślij wyniki
  delay(1000);
}

To każdy obrót pętli zajmie trochę ponad 1s. To opóźnienie będzie Ci bardzo ciężko zmierzyć, ale jak uruchomisz program na godzinę, będziesz miał już opóźnienie 3600 razy większe. Po całym dniu, będzie jeszcze więcej, a po miesiącu... sam policz.

Oczywiście da się napisać program, który będzie poprawnie zliczał czas bez RTC. Jednak jeśli szukasz prostego rozwiązania, dodanie zegara ma sporo plusów, a jednocześnie pozwala uniknąć problemów. Szczególnie na zwróć uwagę na fragment "wyślij wyniki". Będzesz chyba jakoś odczytywać wyniki pomiarów? A jak pewnie widziałeś na forum, komunikacja wprowadza dość znaczne opóźnienia.

[marek1707]

Wydaje mi się, że ta konkretna aplikacja, zegara RTC jako elementu liczącego czas w sensie sekund, minut godzin zupełnie nie potrzebuje. Przecież procesor może wykonywać wiele drobnych rzeczy właściwie na raz a tutaj mamy do zrobienia tylko dwie:

- próbkowanie i zapamiętywanie stanu drzwi co określony i zawsze taki sam interwał czasu,
- wysyłanie wyników - znowu co pewien określony odstęp czasu.

Każda z nich zasadza się na odmierzaniu odcinków czasu. Najlepiej, gdyby program nie bazował na opóźnieniach liczonych programowo, bo wtedy pojawiają się efekty sumowania błędów o których wspomniał Elvis. Dlatego proponuję moim zdaniem narzucające się rozwiązanie:

1. Wprowadzić "zegar systemowy" czyli zaprząc któryś wolny timer sprzętowy do odliczania pewnych kwantów czasu. To powinno być coś równego, typu 10, 100 czy 250ms. Cokolwiek, co będzie "ładnym" podzielnikiem powiedzmy 1 sekundy. Dzięki temu dostajemy niezależną od czegokolwiek w systemie "podstawę czasu". To może być np. funkcja obsługi przerwania wywoływana właśnie co jakiś stały odcinek czasu.

2. Bazując na znanych już kwantach czasu trzeba zrobić dwa liczniki:

a. Liczący okres próbkowania i zapamiętywania stanu drzwi.

b. Liczący okres wysyłania danych.

Pierwszy może wyznaczać upłynięcie np. 1 sekundy, drugi np. 1, 2 czy 10 minut - jak tam potrzeba.

No i teraz mamy już wszystko czego potrzebujemy: pomiary i transmisję. Ten system nie musi znać konkretnej godziny "zegarkowej" więc nie potrzebuje prawdziwego, podtrzymywanego baterią i pobierającego 1uA prądu modułu RTC, prawda?

To na początku wydaje się może troszkę skomplikowane, ale wcale takie nie jest. Jeśli masz ochotę się w to pobawić, bez problemu sobie z tym poradzisz. Jeden procesor bez żadnych dodatków obsłuży wszystko co (na razie) chcesz zrobić. Możemy zacząć od napisania kodu przygotowującego timer do zgłaszania przerwań okresowych i funkcji, która je "wyłapie".

BTW: Arduino jest wyposażone "firmowo" w licznik czasu o okresie 1ms, ale o ile wiem nie można do tego łatwo podpiąć swojej funkcji. Trzeba za to bazować na odczytach 32-bitowego licznika milisekund upłyniętych od włączenia zasilania procka a to zawsze wydaje mi się jakimś koślawych omijaniem problemu. Zróbmy to porządnie, a przy okazji dotkniesz i wykorzystasz troszkę sprzętu (timer, mechanizm przerwań), który leży odłogiem w procesorze i się marnuje

[Wrona]

Dzięki chłopaki. Dowiedziałem się więcej niż potrzebowałem do tego konkretnego projektu ... i o to chodzi.

Jeśli mógłbym to chciałbym przesunąć ciężar rozmowy na kwestie o których nie wiem kompletnie nic czyli komunikacja WiFi. Chodzi o wysyłanie odczytów do laptopa. Czy najprostsze dla początkującego rozwiązanie to moduł ESP8266? Czy można to zrobić prościej ... a jak Was poznałem to na pewno lepiej

[Elvis]

Skoro planujesz użyć ESP8266, to może pozbądź się Arduino? Na ESP można uruchamiać własne programy, pewnie będzie taniej i łatwiej mieć tylko jeden procesor niż dwa.

[deshipu]

Do tego ESP8266 ma wbudowany RTC -- niezbyt dobry, ale jest.

[buchbuch]

Ok panowie żeby nie było, że jakiś głupek wpadł w poślizg i wypisuje brednie. Jak każdy problem tak i ten da się rozwiązać na kilka sposobów (no chyba, że się nie da ale to wyjątki). Spojrzałem na temat pod kątem stwierdzenia autora, że 9/10 = 0. Reszta z dzielenia się w takich wypadkach czasami przydaje i nie trzeba wtedy stosować skomplikowanych zabiegów. Jak widać ten problem już rozwiązaliście inaczej no i fajnie. Nie wspominałem nic o przesunięciach ale za pomocą kilku warunków można określić działanie programu w każdym możliwym wypadku chcąc wykorzystać modulo do takich prostych rachunków. Być może źle zrozumiałem intencję autora stąd ten pomysł z przerwaniami i dokładnym czasem zdarzeń. Operator dzielenia modulo wygląda tak: % i w tym wypadku 9%10=9 w domyśle 0.9 i ten "domysł" można określić warunkami choćby if. Skoro ma to być taka prosta aplikacja to myślę, że śmiało można skorzystać z typu float i nie bawić się w partyzantkę. Myślę też, że użycie średniej kroczącej mogło by uprościć odczyt danych gdybyś chciał mieć np. pogląd na stosunek czasu otwartych drzwi do zamkniętych w dłuższym okresie niż 5 min. Mam nadzieje, że to co naskrobałem jest w miarę czytelne i zrozumiałe. Dziękuję za uwagę.

Wybaczcie jeśli się znowu wymądrzam ale musiałem sobie ulżyć

[deshipu]

Operator dzielenia modulo wygląda tak: % i w tym wypadku 9%10=9 w domyśle 0.9 i ten "domysł" można określić warunkami choćby if.

Nic nie rozumiem z tego, co piszesz. Możesz trochę podkręcić jasność wypowiedzi? Jaki domysł? Może napiszesz przykładowy kawałek kodu, bo za nic nie potrafię się domyślić o co ci chodzi i jak chciałbyś wyliczyć proporcje za pomocą reszty z dzielenia, a chętnie nauczyłbym się czegoś nowego.

[Wrona]

Tak na marginesie to chyba był jakiś problem z forum z wczoraj na dziś, bo mój post z wczorajszego wieczora gdzieś zniknął a pojawiły się wasze powyższe posty o których nie miałem powiadomienia.

Co do modułu ESP8266 to myślałem na początek o ESP-01 by spróbować ogarnąć kwestie komunikacji. Ma on tylko 2 piny do programowania a ja potrzebuje ponad 20

Dlatego teraz kombinuje już z PCF8574 i o dziwo ogarnąłem temat sprawnie, tak że trzy dodatkowe ekspandery już działają.

Wracając do kwestii WiFi to dla takiego leszcza elektronicznego jak ja idealnym rozwiązaniem byłoby podpiąć coś pod USB i "finito" ale chyba tak dobrze to nie będzie?