Ostatnio zbudowałem ma własne potrzeby bezprzewodową sensorykę
(zdalna kontrola temp + elementy wykonawcze on/off) w oparciu i
klasyczne moduły bezprzewodowe (nie wifi). Teraz się zastanawiam czy
dalej to rozwijać w oparciu o te klasyczne moduły czy dać sobie
spokój i przejść na wifi. Oba "systemy" mają podobny zasięg ale wifi
zdaje się być wygodniejszy ze względu na standard (nie mam problemu z
przejsciem na transoprt tcp/udp).
Jak taka sieć sensorów wifi będzie współegzystować z domową siecią
wifi do celów "internetowych"? Czy nadmiar obcych sieci w zasięgu nie
będzie miał negatywnego wpływu ma stabilność komunikacji w sieci
sensorów?
Bezprzewodowe moduły z jakich korzystam pracują na 868Mhz, czest.
która wydaje się w miarę czysta w porównaniu z wifi, ale z drugiej
strony wifi zostało zostało zaprojektowane do "gęstego użycia" i daje
radę w takich warunkach.

zalety wifi:
- powszechny standard jeśli chodzi o rf
- powszechny standard jeśli chodzi o transport (tcp/udp)

wady wifi:
- brak (lub utrudnione) rozwiązywanie we własnym zakresie problemów z
komunikacją lub stabilności w warstwie rf wifi (jeśli wystąpią)
- większe zużycie prądu

zalety "nie wifi":
- inne "czyste" czestot.
- prostszy choć niestandardowy transport ale wymagający własnej
implementacji
- prostota konstrukcji
- małe zużycie prądu

wady "nie wifi":
- u niektórych wymagany doktorat z rf aby prawidłowo skonfigurować
cześć nadawczą modułu np. pll band, lna gain, rx bandwith itp.


Co wybrać??

--
Marek

do góry

W dniu 2014-11-25 11:32, Marek pisze:

> - prostszy choć niestandardowy transport ale wymagający własnej
> implementacji

Hmm... Czy naprawdę trzeba pisać własną warstwę transportową? Przecież
takie moduły jak RFM69 umożliwiają wysyłanie pakietów o długości
kilkuset bajtów (lub bodajże 64 bajtów w przypadku korzystania z AES).
To w zupełności wystarczy do przesyłania komend w styl "załącz/wyłącz"
albo "podeślij wartość odczytywaną przez czujnik", nawet jeśli będziemy
posługiwać się czytelnymi dla człowieka poleceniami w ASCII.

Wyższa warstwa przydałaby się, gdybyśmy chcieli przesyłać jakiś większy
strumień danych. Tutaj jednak nie dostrzegam takiej potrzeby.

Niemniej pytanie wymienione w temacie tej dyskusji także mnie
interesuje. Bardziej ciekawi mnie inna kwestia: ile takich modułów jak
ESP8266 może jednocześnie pracować bez zapychania nam sieci. Oczywiście
nie chodzi o zapychanie jej transmisją dużej ilości danych, ale przecież
zwykłe, domowe routery także mają ograniczone możliwości w zakresie
maksymalnej ilości obsługiwanych urządzeń. Pasmo też nie jest z gumy i
nie zawsze da się zmienić maskę podsieci, aby pozwalała na
zagospodarowanie większej puli adresów IP...

A taka sieć RF pracuje sobie całkowicie niezależnie od naszej sieci
komputerowej, na zupełnie innym pasmie. Wystarczy tylko zbudować jedną
bramkę Ethernet <--> RF, tudzież wyposażyć jakieś Raspberry Pi w
odpowiedni moduł i napisać do niego sterownik.

do góry

On Tue, 25 Nov 2014 13:23:04 +0100, Atlantis <m...@w...pl>
wrote:
> Hmm... Czy naprawdę trzeba pisać własną warstwę transportową?
Przecież
> takie moduły jak RFM69 umożliwiają wysyłanie pakietów o długości
> kilkuset bajtów (lub bodajże 64 bajtów w przypadku korzystania z
AES).

A one nie są przypadkiem 2.4GHz? Bo wtedy już są czymś bliższym wifi.
Ja miałem na myśli prostrze, np rfm12b. Nie jestem pewien czy jest
sens zamieniać proste (rfm12) , na troche lepsze ale podobne (rfm69)
zamiast przeskoczyc od razu o klasę wyżej, na wifi. Innymi słowy
nawet użycie rf69 nie odpowie nam na pytanie jakby się sprawdziło
wifi.

--
Marek

do góry

On Tue, 25 Nov 2014 13:23:04 +0100, Atlantis <m...@w...pl>
wrote:
> Wyższa warstwa przydałaby się, gdybyśmy chcieli przesyłać jakiś
większy
> strumień danych. Tutaj jednak nie dostrzegam takiej potrzeby.

A ja dostrzegam inną. Mogę diagnozować pojedynczy czujnik w prosty
sposób łącząc się z nim bezpośrednio przez tcp/udp np. komórką, bez
pośrodnika.

--
Marek

do góry

W dniu 2014-11-25 13:47, Marek pisze:

> A one nie są przypadkiem 2.4GHz? Bo wtedy już są czymś bliższym wifi. Ja
> miałem na myśli prostrze, np rfm12b. Nie jestem pewien czy jest sens
> zamieniać proste (rfm12) , na troche lepsze ale podobne (rfm69) zamiast
> przeskoczyc od razu o klasę wyżej, na wifi. Innymi słowy nawet użycie
> rf69 nie odpowie nam na pytanie jakby się sprawdziło wifi.

Na 2,4 GHz pracują RFM70/73.
RFM69 to udoskonalona wersja RFM12. Pracują na tych samych
częstotliwościach (m.in. 434 MHz i 868 MHz) i nawet chyba można je
odpalić w trybie wstecznej kompatybilności, w którym są w stanie
rozmawiać z "dwunastką". Ich główną zaletą jest jednak sprzętowa obsługa
adresowania i transportu, wraz z obsługą błędów i szyfrowaniem.

Zastanawiam się jeszcze jak taki RFM69 wypada w porównaniu z WiFi pod
względem zasięgu i niezawodności transmisji. Na YouTube widziałem
relację z testów ESP8266 z wykorzystaniem zewnętrznych anten. Faktycznie
robiło to wrażenie. Z drugiej test polegający na pingowaniu oddalającego
się modułu to jedno, praktyka użytkowania to drugie. RFM69 mają
teoretyczną przewagę, wynikającą z warunków propagacyjnych na niższych
pasmach - tutaj fale "chętniej" pokonują przeszkody terenowe.

do góry

On Tue, 25 Nov 2014 14:00:37 +0100, Atlantis <m...@w...pl>
wrote:
> Zastanawiam się jeszcze jak taki RFM69 wypada w porównaniu z WiFi
pod
> względem zasięgu i niezawodności transmisji. Na YouTube widziałem
> relację z testów ESP8266 z wykorzystaniem zewnętrznych anten.
Faktycznie
> robiło to wrażenie. Z drugiej test polegający na pingowaniu
oddalającego
> się modułu to jedno, praktyka użytkowania to drugie.

Są też wersje rfm12bp 500 mW, tylko cena 40pln (tme). Ale 0.5W to
już konkret, przy ant kierunkowych zasięg kilometra spokojnie, jak
nie więcej.

--
Marek

do góry

W dniu 2014-11-25 13:51, Marek pisze:

> A ja dostrzegam inną. Mogę diagnozować pojedynczy czujnik w prosty
> sposób łącząc się z nim bezpośrednio przez tcp/udp np. komórką, bez
> pośrodnika.

To fakt. Jest jeszcze kilka innych, niezaprzeczalnych zalet. Na przykład
czujnik/moduł wykonawczy może sobie pobierać czas bezpośrednio z serwera
NTP, nie trzeba mu go wystawiać na żadnej bramce albo innym "zegarze"
pracującym na tej samej magistrali.
Jeśli chcemy gdzieś zrzucać wyniki pomiarów, można dodać funkcję
uploadującą dane do Graphite'a (albo innej bazy danych), potem tylko
wywołujemy ją regularnie i nie ma potrzeby pisania pośredniczącego daemona.

do góry

W dniu 2014-11-25 14:42, Marek pisze:

> Są też wersje rfm12bp 500 mW, tylko cena 40pln (tme). Ale 0.5W to już
> konkret, przy ant kierunkowych zasięg kilometra spokojnie, jak nie więcej.

Tak, wiem. Zaopatrzyłem się kiedyś w jedną czy dwie sztuki na 868 MHz.
Niedługo potem dowiedziałem się o RMF69 i zdecydowałem, że lepiej nie
zaczynać żadnego projektu na starszej wersji, bo to będzie się wiązało z
rezygnacją z największych zalet nowego modelu. Niestety nic nie wiadomo
o RFM69BP.
A teraz zresztą sam się zastanawiam, czy WiFi nie będzie fajniejszym
rozwiązaniem. Bo do tej pory powstrzymywała mnie głównie cena, ale od
czasu pojawienia się ESP8266... Jest jeszcze kilka kwestii, które budzą
moje wątpliwości, ale zobaczymy. :)

do góry

? 2014?11?27????UTC+8??3?21?30?,Atlantis??:
> W dniu 2014-11-25 14:42, Marek pisze:
>
> > Są też wersje rfm12bp 500 mW, tylko cena 40pln (tme). Ale 0.5W to już
> > konkret, przy ant kierunkowych zasięg kilometra spokojnie, jak nie więcej.
>
> Tak, wiem. Zaopatrzyłem się kiedyś w jedną czy dwie sztuki na 868 MHz.
> Niedługo potem dowiedziałem się o RMF69 i zdecydowałem, że lepiej nie
> zaczynać żadnego projektu na starszej wersji, bo to będzie się wiązało z
> rezygnacją z największych zalet nowego modelu. Niestety nic nie wiadomo
> o RFM69BP.
> A teraz zresztą sam się zastanawiam, czy WiFi nie będzie fajniejszym
> rozwiązaniem. Bo do tej pory powstrzymywała mnie głównie cena, ale od
> czasu pojawienia się ESP8266... Jest jeszcze kilka kwestii, które budzą
> moje wątpliwości, ale zobaczymy. :)
sprawdzić to rozwiązanie pod klucz RF4432 dla 868 rozwiązania zespołu. W porównaniu
RFM69, ma USART port i dopasowane portu RF i łatwe do zintegrowania z czujnikami.
http://www.appconwireless.com/PRODUCTS/showproduct.p
hp?lang=en&id=7

do góry