Czujnik poziomu szamba

[_LM_]

tam nie trzeba czegoś na płycie zmienić? https://tutorials.probots.co.in/communicating-with-a-waterproof-ultrasonic-sensor-aj-sr04m-jsn-sr04t/ 

[jand]

1 godzinę temu, Krisk napisał:

musi być 0&1.

Absolutnie nie musi.

Natomiast nie może być 11, gdyż w ESP32 jest to GPIO wykorzystywane przez moduł pamięci flash.

[ethanak]

Do ESP32 proponuję 13/14 - taka najbardziej neutralna para pinów.

[Krisk]

26 minut temu, jand napisał:

Absolutnie nie musi.

Natomiast nie może być 11, gdyż w ESP32 jest to GPIO wykorzystywane przez moduł pamięci flash.

Niestety na UNO inne niż 0/1 nie działały poprawnie, choć pewnie nie próbowałem wszystkich kombinacji.
Na ESP8266 mam 12/13 i jest ok.

ESP12- niestety nie działa poprawnie, być może przez to, że są 3,3V- choć dokumentacja mówi, że powinno działać też, to nie do końca tak jest.

[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

[ethanak]

Ale ESP12 to przecież 8266. A pisałem i 13/14 a nie 12/13 (dwunastka to jednak strapping pin i jak nie musisz to go unikaj).

 

[Krisk]

2 godziny temu, ethanak napisał:

Ale ESP12 to przecież 8266. A pisałem i 13/14 a nie 12/13 (dwunastka to jednak strapping pin i jak nie musisz to go unikaj).

 

Mam 2 płytki:

8266- D1R1 tutaj działa na 12/13 i 13/14

I 8266/ 12E - tu nie mogłem odpalić.

Kombinowałem 13/14, 1/3 a finalnie poszło na 4/5.

 

[Krisk]

Próbuję teraz wkomponować ten pomiar w kod wykorzystujący powiadomienia na Telegram, mam problem z pokazaniem distance w wiadomości.

Wpisałem taki kawałek i chciałem przywołać parametr distance, który jest wyświetlany na serial print, jednak podczas kompilacji otrzymuję błąd:

Compilation error: conversion from 'int' to 'const String' is ambiguous

Jak to uzyskać?

Pomiar odbywa się w pętli, a wiadomości są przed loop...

if (text == "/poziom")

{
   bot.sendMessage(chat_id, (distance), "");
      }

 

[farmaceuta]

2 godziny temu, Krisk napisał:

Compilation error: conversion from 'int' to 'const String' is ambiguous

 

A nie jest tak że sendmessage() jako parametr do wysłania przyjmuje String lub tablice znaków?? A Ty tam upychasz int'a...spróbuj wysłać jakiś tekst, jak pójdzie to distance sobie przekonwertuje na String (zgaduje 🤭)

[Krisk]

38 minut temu, farmaceuta napisał:

A nie jest tak że sendmessage() jako parametr do wysłania przyjmuje String lub tablice znaków?? A Ty tam upychasz int'a...spróbuj wysłać jakiś tekst, jak pójdzie to distance sobie przekonwertuje na String (zgaduje 🤭)

Masz rację, zrobiłem tak i jest ok.

        String message = "Poziom szamba: " + String(distance) + " cm";
        bot.sendMessage(CHAT_ID, message, "");

Dzięki!

[Talinowski]

Zgadzam się z przedmówcami, że najprostszym sposobem na konwersję int na String jest użycie funkcji String().

[Krisk]

Dziś uruchomiłem prototyp, zamocowałem czujnik stabilnie pod pokrywą szamba, kontroler był na zewnątrz w pudełku, zasilanie z powerbanka. Pierwsze 45min było w miarę ok, potem co kilka, kilkanaście minut otrzymywałem komunikaty. Stan minimum mam określony na 70cm, poziom był na ok 175cm. Komunikaty tak wyglądały:

Nie wiem z czego wynikają te zakłócenia, czujnik jest stabilnie zamocowany.

Chyba powinienem ograniczyć częstotliwość pomiarów, tak na prawdę to wystarczą 2-3 pomiary na dobę, ale wyniki powinny być wiarygodne.

Czy można stosować pętle w takim długim okresie? Ewentualnie zastosować zegar czasu rzeczywistego i ustalić w jakich godzinach powinien być pomiar- ale z wykluczeniem zakłóceń. Podpowiecie coś?

 

[farmaceuta]

Myślę że na millis() by wystarczyło...przecież nie potrzebujesz tutaj otrzymywać komunikaty dokładnie co do sekundy... może przed wysłaniem pomiarów spróbuj zrobić np. 20 pomiarów i je uśrednić..błąd na pewno będzie mniejszy, no i zainteresuj się trybami uśpienia ESP, bo jak to ciągle będzie połączone z wifi to baterii nie nadazysz wymieniać 😉

[jand]

Uśrednianie pomiarów ma sens, jeśli są one w miarę zbliżone - a tutaj jest raz 175, a raz 27 cm. Średnia z tych pomiarów będzie bez sensu.

Jeśli czujnik działa prawidłowo poza szambem, a błędy zaczynają się dopiero po instalacji w komorze, to ich przyczyną mogą być odbicia fali dźwiękowej od ścian "kominka", czy od jakiejś rury osłonowej. Czujniki te mają szeroki kąt działania i łatwo łapią zakłócenia. Obniż czujnik maksymalnie jak się da.

[jand]

Jeśliby tych odbić nie udało by się okiełznać, to można zrobić tak:

Wygląda na to, że wartości fałszywych pomiarów są zawsze mniejsze, niż wartość rzeczywista. Robimy więc serię pomiarów (np. 20 pomiarów co parę sekund) i wyszukujemy wśród nich `wynik o największej wartości, który traktujemy jako końcowy. Albo ewentualnie wyliczamy średnią z kilku najwyższych wartości.

[ethanak]

A cos jak w czujnikach ToF? Mniej więcej coś takiego: czasy spoza pewnego zakresu nie są brane pod uwagę, z pozostałych szukamy okna o największym zagęszczeniu i tu liczymy średnią...