Czujka z interfejsem LAN

Zaczęty przez kriu, 12 Luty 2015, 21:59

kriu

Zastanawiam się czy jest możliwość, a raczej jaka trudność (bo możliwość na pewno tak) wykonywać czujki z interfejsem sieciowym LAN i jakimś prostym web-serwerem. Podłączało by się ją bezpośrednio do sieci LAN i poprzez przeglądarkę konfigurowało. Zapewne dałoby się nawet zautomatyzować wszystko i ograniczyć do podania nazwy użytkownika i hasła.
Taką czujkę można by wtedy podłączyć praktycznie wszędzie gdzie jest odstęp do sieci komputerowej i wolne gniazdo LAN.
Opcja rozszerzona to np. trochę pamięci FLASH (a nawet tymczasowa w RAM), buforowanie i zapisywanie danych pomiarowych, wykresy, statystyki, itp.
http://kriu.cba.pl/LT1/pomiary.htm

Troll81

możesz podpiąć pod raspberry PI :D

krzyszp

Cytat: kriu w 12 Luty 2015, 21:59
Zastanawiam się czy jest możliwość, a raczej jaka trudność (bo możliwość na pewno tak) wykonywać czujki z interfejsem sieciowym LAN i jakimś prostym web-serwerem. Podłączało by się ją bezpośrednio do sieci LAN i poprzez przeglądarkę konfigurowało. Zapewne dałoby się nawet zautomatyzować wszystko i ograniczyć do podania nazwy użytkownika i hasła.
Taką czujkę można by wtedy podłączyć praktycznie wszędzie gdzie jest odstęp do sieci komputerowej i wolne gniazdo LAN.
Opcja rozszerzona to np. trochę pamięci FLASH, buforowanie i zapisywanie danych pomiarowych, wykresy, statystyki, itp.

Taka opcja to niestety spory budżet dla konstruktora + czas potrzebny na oprogramowanie firmware... Najlepiej (łatwiej) to chyba faktycznie wykorzystać RaspberryPi i umieścić w jednej obudowie...

Fajne zegarki :)
Należę do drużyny BOINC@Poland
 Moja wizytówka

Szopler

Taka czujka powstała na płytce prototypowej. Problemem głównym było zastosowanie układu ENC28J60 i implementacja całego stosu TCP w procesorze - dużo pamięci programu na to poszło.
Do tego maksymalny rozmiar strony jaki udało mi się zrobić miał rozmiar MTU czyli 1490 bajtów, a to za mało na pełną stronę konfiguracyjno - diagnostyczną.
Gdyby zastosować układ ETH który ma cały stos w sobie i pcha się do niego tylko dane (HTML) to można by to zrobić dużo prościej.

kriu

Według mnie była by to świetna sprawa (podobnie jak w Blitzortung gdy przeszli z GREEN na RED).
Opcja np. z Raspberry PI oczywiście jest do zrobienia ale obawiam się, że mogłyby być większe problemy z niezawodnością całości. Jest wtedy więcej czynników, które mogą zawieść: czujka, transmisja USB, Raspberry PI, system tam zainstalowany. Ja w tej chwili korzystam z małych terminali czyli czegoś podobnego (Windowsy).
No ale tak jak napisał szopler na razie są pewne problemy, ale być może kiedyś doczekamy się takich wersji.
http://kriu.cba.pl/LT1/pomiary.htm

ryszard.korczyk

Jeśli zainteresowanie będzie, to mogę z tematem się zmierzyć, mam trochę doświadczenia z LAN na pic32, ale będę potrzebował pomocy z komunikacją z serwerem np poprzez php, tego nigdy nie robiłem.
BTW: czujka już nie pracowałaby pod projektem boinc? Czy może dać jej dwie opcje, praca samodzielna lub z komputerem z uruchomionym boinc w tej samej sieci?

Grzes978

Zainteresowanie na pewno się znajdzie, bo taki rodzaj urządzenia jest najbardziej optymalny dla kazdego. Podłaczasz pod lan i po problemie. Zawwsze mozesz spojrzec na urzadzenie przez wifi na komorce, etc. Tak jak to jest z systemem red blitzortung.

A co gdyby wykorzystac kit blitzortunga do przerobienia tego na czujnik radioactiva? Podejrzewam że tak mogło by być najszybciej. sparwdzone rozwiazanie, trzebabybyło tylko przerobic plytke o elementy potrzebne do wykrywania radioaktywnosci, i przeprogramowac urzadzenie i zrobic inny webinterfarence?

Mysle ze goscie z blitza by sie nie obrazili.

krzyszp

Taka czujka powinna stać się "komercyjną" częścią naszego projektu, gdyż większość zainteresowanych nigdy by jej pod BOINC nie podczepiła, a z powodu ceny by atakował Ryśka o możliwość zakupu...

Fajne zegarki :)
Należę do drużyny BOINC@Poland
 Moja wizytówka

kriu

A czy nie ma możliwości tak jakby zaimplementowania w interfejs www opcji logowania na stronę projektu podobnie jak robi się to w Linux z wiersza poleceń (proszę mnie poprawić jak się mylę). Ktoś gdzieś napisał (to chyba Ty krzyszp:), że "odpalił" czujkę na tunerze satelitarnym :) Nie byłby to manager Boinc, ale punkty były by chyba naliczane ? Czy mam rację?
http://kriu.cba.pl/LT1/pomiary.htm

krzyszp

Czujkę na tunerze odpalił chyba TJM, ale ten tuner miał Linuksa na pokładzie i tam chyba normalnie apka BOINC'owa chodziła...

Fajne zegarki :)
Należę do drużyny BOINC@Poland
 Moja wizytówka

TJM

Z tymi czujkami na tunerze SAT, to była taka sprawa, że napisał do mnie gość podając konkretną platformę i zrobiłem do tego aplikację + klienta BOINC, potem się właśnie okazało że to tuner był, normalny linuksowy host tylko z słabym hardware i jakimś dziwnym procem.

Co do czujnika pracującego po LANie, to obie opcje są wykonalne i z sensorem w wersji standalone nawet już były przeprowadzane próby. Taki pracujący całkowicie poza BOINCem sensor jest łatwiejszy do ogarnięcia kosztem tego, że już np. na stronach projektu nie wiadomo co się w ogóle z nim dzieje i dochodzą opcje związane z autoryzacją usera i może samego sensora. Po stronie serwera do dorobienia sporo rzeczy do obsługi takiego hardware.

To ja dorzucę też inny pomysł - zintegrowanie z sensorem czegoś w rodzaju ESP8266. Ten akurat przykładowy moduł kosztuje 20zł w detalu a zamiast kabli od razu jest wifi. Zasięg dość kozacki, mimo małych gabarytów i używania zintegrowanej na PCB anteny, w mieszkaniu wifi sięga mniej więcej tak jak przeciętny laptop, a w otwartym terenie (100% widzialność optyczna) udawało mi się przy dobrej pogodzie nawiązać komunikację z odległości ok. 300m (po stronie AP słaba antena kierunkowa).




W razie jakiejś pilniejszej sprawy - jestem często dostępny na kanale IRC B@P, na forum czasami zapominam zajrzeć lub nie mam czasu.

tplewa

#11
W sumie nie jest tak zle z tym ETH ale i nie jest rozowo :) ENC28J60 nie jest tutaj akurat jakims wielkim problemem, problemem jest mikrokontroler za zwyczaj posiadajacy malo RAM-u. Niestety ale przyzwoita obsluga stosu TCP/IP wymaga pamietania ramek do momentu otrzymania ACK... implementacja tego na 8 bitowcach w stylu AVR owszem jakos tam dziala, ale jest obwarowana wieloma wadami. Pakowanie znowu czegos w stylu RB PI to lekki przerost formy nad trescia i kolo sie zamyka ;)

Natomiast spokojnie mozna uzyc jakiegos ARM-a z wiekszym RAM-em i wbudowanym kontrolerem MAC, potrzeba do tego podpiac jeszcze PHY. Od strony stosu to jest calkiem sensowny Cylcone TCP:
http://www.oryx-embedded.com/cyclone_tcp.html

co prawda w wersji darmowej brak dokumentacji, ale kod jest bardzo sensownie napisany. Tutaj jest demko jak to smiga na plytce STM3220G-EVAL (z prockiem  STM32F207IGH6):
http://demo.oryx-embedded.com/#&panel1-3

ESP8266 tez jest tam jakims wyjsciem, on uzywa akurat stosu lwIP i czesciowo uwolnione jest SDK wiec mozna czesc obslugi wpakowac nawet do ukladu...
z drugiej strony patrzac na ceny ARM-ow tez jest to jakies tam wyjscie bo nie sa one straszna, a wrecz konkurencyjne do AVR-ow ktorych (stosunek mozliwosci/cena).

Jedyny problem cos takiego zrobic to niestety czas, ale jak ktos by sie chcial bawic na ARM-e to moge udostepnic caly kod mojego licznika :)
Z drugiej strony nie musi to robic jedna osoba po to sa repozytoria ;) kwestia tylko organizacji calosci :) Bo jak na razie to jest tak ze licznikow buduje sie troche, ale jak to mowia kazdy sobie rzepke skrobie ;) i powiela to co inni juz zrobili...





Gecko

Widzę że wcale nie będę pierwszy z pomysłem aby detektor promieniowania wykonać jako autonomiczne urządzenie w oparciu o ESP8266.
Na razie potestuję ten moduł.
Gdy lepiej go poznam spotkam się z TJM i/lub Szoplerem co by ustalić jak właściwie to rozegrać ze względu na cały projekt.
Ktoś na IRC'u obiecał wygospodarować dla mnie G-M tube.

tplewa

W sumie czy ESP czy inny to najpierw nalezy rozwiazac kilka problemow, a podstawowy to jest kompatybilnosc z protokolem jaki uzywany jest w BOINC. Nie wiem czy jest gdzies opis czy potrzeba posiedziec nad analiza kodu klienta itp.

Mysle ze Tuba na chwile obecna nie jest jakosc bardzo potrzebna, bo te testy mozna wykonac bez niej. Nie wiem jak na chwile obecna wyglada sprawa z ESP, ale jak sie nimi bawilem z powodu ze nie jest uwolniony caly kod (a przynajmniej na tamten czas nie byl). Prowadzi to do sytuacji ze czesc spraw moze byc trudna w realizacji bez ingerencji w lwIP.  Natomiast realizacja tego w oparciu o skrypty LUA itp. moze nie byc realna do wykonania. Pare osob bawilo sie w reverse engineering i zrobilo na tych ukladach troche ciekawych projektow, ale nie udostepnili wiele materialow na ten temat - wiec jak widac realne tylko potrzeba troche samozaparcia :)

Zreszta jak zrobisz jakies testy daj znac najlepiej na forum. Wiem ze jest IRC itd. ale nie kazdy tam zaglada (a raczej ma czas na to). Jak by cos ruszylo ja tam moge w miare wolnych chwil tez cos poklepac. Na chwile obecna nie chcialem glownie kombinowac z symulacja klienta i swoim GM, aby nie narobic syfu w projekcie R@H - w razie jakis bledow w firmware... a nie mialem zbytnio czasu odpalac wlasnej infrastruktury BOINC do testow...

Teraz jeszcze co do koncepcji. Taka czujka z WiFi miala by sens przykladowo w opcji z panelem slonecznym + aku + uklad ladowania itd. W przeciwnym wypadku (jak mamy do niej ciagnac zasilanie) znowu bardziej logiczne uzycie jest eth + poe.




kriu

Cytat: tplewa w 10 Lipiec 2016, 12:13
... Teraz jeszcze co do koncepcji. Taka czujka z WiFi miala by sens przykladowo w opcji z panelem slonecznym + aku + uklad ladowania itd. W przeciwnym wypadku (jak mamy do niej ciagnac zasilanie) znowu bardziej logiczne uzycie jest eth + poe.
Wydaje mi się, ze czujka z Wi-Fi nie będzie dobrym rozwiązaniem. Moduł bezprzewodowy pobiera dość dużo energii i dodatkowo należałoby wyposażać czujkę w panel słoneczny (pewnie co najmniej kilka watów) co będzie dość drogim rozwiązaniem. Całość (także ten dość duży panel słoneczny) trzeba byłoby gdzieś umocować w miejscu nasłonecznionym. No i do tego akumulator wymieniany co kilka lat.
Najsensowniejsze rozwiązanie to czujka z PoE i nawet nie w pełnym standardzie (48V) ale "zwykłe" 12V (pewnie i 5V by obskoczyło). Przy tak małym prądzie pobieranym przez czujkę będzie można zapewne zasilić ją poprzez skrętkę nawet na kilkadziesiąt metrów. Wiem - trzeba będzie ciągnąć "kabel" (skrętkę) ale to jedyny problem bo cena skrętki już nie. Nie wiem jak inni koledzy ale ja taką czujkę "po skrętce" i tak prowadziłbym raptem kilka metrów od komputera a większość miała by ją pewnie w domu połączoną jakimś 2 metrowym Patchcord'em. Tu chodzi o wygodę w obsłudze tego. Czujka z własną stroną, na którą wchodzimy przez przeglądarkę i konfigurujemy. Dołączyć ją można byłoby po prostu do "wolnego" gniazdka w sieci LAN przez jakiś prosty zasilacz PoE lub nawet dodać dodatkowe gniazdko na zasilacz klasyczny - wtedy zasilamy jak kto woli.
http://kriu.cba.pl/LT1/pomiary.htm

tplewa

Pomijajac juz tam pobor pradu itp. to o WiFI wlasnie myslalem jako czujka umieszczona w jakims dalszym miejscu - gdzie istnieje problem dociagnac okablowanie. Tak faktycznie najczesciej jest ona blisko np. za oknem czy nawet w domu.

Jednak wracajac do tematu jak by sie komus chcialo siedziec i zrobil opis protokolu komunikacji tak aby sumulowac klienta boinc (bo nie ma sensu jego funkcjonalnosci przepisywac na male procki) - to mozna by bylo cos w temacie podzialac.

Wiem ze z jednej strony odbiega to troche od zalozen uzycia BOINC, ale osobiscie nie odpalam takiej czujki z prostego powodu - nie mam sprzetu ktory odpalny jest 24h i mozna na nim takiego klienta odpalic, a odpalanie tego na jakims RB PI tylko pod czujke itp. jest dla mnie przerostem formy nad trescia...