RFM22 - Jeden odbiornik i wiele nadajników radiowych zasilanych bateryjnie

Witam,
zbudowałem pewien system z 3 czujnikami i 1 odbiornikiem pokazującym stan czujników.

System oparty na modułach radiowych RFM22-868MHz.

Czujniki zasilane są bateryjnie i swój stan wysyłają albo co 10s albo po zwarciu wejścia do masy (przerwanie zewnętrzne budzi procesor a ten inicjuje wysyłanie danych). Odbiornik jest ciągle włączony, zasilony 230VAC i czeka na odebranie danych z nadajników. Czujnik-nadajnik po wysłaniu jakiejkolwiek informacji "usypia" się na kolejne 10s i pobiera prąd rzędu kilku mikroamper (µA).

Chodzi o to, że chciałbym zwiększyć ilość nadajników i tu pojawia się problem, gdyż nigdy nie wiadomo kiedy dany czujnik pobudzi się i wyślę dane.
W takiej sytuacji może zaistnieć i istnieją (co prawda rzadko) ale istnieją sytuacje gdy jednocześnie 2 lub więcej nadajników wysyłają dane jednocześnie albo w części pokrywające się. Podczas jednoczesnego nadawania odbiornik nie odbiera poprawnych danych, o czym nadajniki nie wiedzą i bez względu na to czy odbiornik odebrał dane czy nie, usypiają się.
Nadajniki nie mogą ciągle czekać na potwierdzenie i ponawiać transmisje bo grozi to szybkim rozładowaniem baterii (pastylka CR2450).

Podsumowując proszę kolegów o porady jak tu zachować ciągłość transmisji i wyeliminować błędy "nałożenia się" danych z 2 lub więcej nadajników, zachowując niski pobór prądu w nadajnikach i ich usypianie. Sytuacja dla 3 nadajników nie jest tak krytyczna, ale "schody" zaczną się gdy będzie ich więcej (np 9).

Z góry dziękuje za pomoc.

Urządzenie czujnikowe - UCz, wysyłające dane o mierzonych parametrach
Centrala - Cen, do której spływają dane z czujników droga radiową

Każdemu UCz należy nadać identyfikator ID.
Urządzenia czujnikowe wybudzać np Watchdogiem. Przejście w stan uśpienia inicjowane przez Cen.

Arbitraż :
1. Załączenie zasilania przez wszystkie UCz i ustawienie na odbiór. Oczekiwanie na numer identyfikacyjny.
2.Jeżeli numer identyfikacyjny pokrywa się z danym UCz to Ucz odpowiada tym samym numerem + dane + CRC. Cen po odebraniu danych wysyła rozkaz przejścia Ucz w stan uśpienia. UCz jest usypiane na ściśle określony czas który jest brany pod uwagę przez Cen tak by krótko po ponownym wybudzeniu UCz nastąpiło wysyłanie komendy identyfikacyjnej przez Cen.
3. Jeżeli nie zgadza się CRC lub minie czas oczekiwania na odbiór z Cen (np zakłócenia, pogorszenie zasięgu) Cen odstawia obsługę UCz i przechodzi do adresowania następnego UCz.
UCz nie przechodzi w stan czuwania! Będzie oczekiwać na następne próby obsługi przez Cen.
4. Po obsłużeniu wszystkich UCz odbiornik odlicza czas do wybudzenia się pierwszego UCz i cykl się zamyka.
5. W przypadku gdyby któreś UCz nie odpowiedziało za pierwszym razem Cen wraca ponownie do niego po obsłużeniu wszystkich Ucz.

To tak ogólnie szczegóły należy dostosować do swoich potrzeb.

OK, dzięki, ten sposób przez kolegę przedstawiony będzie działał, ale będzie do póki dopóty któryś z UCz podczas uśpenia nie obudzi się przed czasem i będzie chciał wysłać info o zwarciu wejścia.

Idąc dalej może zdarzyć się tak, że dwa lub więcej UCz będzie musiało przerwać uśpienie bo ktoś zewrze wejścia w kilku UCz i "zmusi" UCz do nadawania, a wtedy dane nakłądają się i Cen nie otrzyma info o tym które wejście zostało zwarte.

Oczywiście UCz po zwarciu we może czekać do końca czasu i dopiero po odpytywaniu przez Cen wysłać info o zwarciu wejścia, ale nie jestem pewien czy taka sytuacja będzie mogła zaistnieć w moim systemie gdyż całość jest jeszcze na etapie ustaleń i najlepsza byłą by natychmiastowa reakcja po zwarciu we w UCz.

Może jakieś inne pomysły?

Załóżmy że mamy 5 UCz.
1 : może nadawać tylko w czasie 0,1-0,15s każdej sekundy.
2 : może nadawać tylko w czasie 0,2-0.25s każdej sekundy.
3 : 0,3-0,35s
4 : 0,4-0,45s
5 : 0,5-0,55s

Zalożmy ze zostały zwarte w tym samym czasie wejścia w UCz 2 i 4 w 6 sekundzie od uśpienia UCz nr.1:
urządzenie nr2 wygeneruje dane z opóznieniem 0,2sek a UCz nr 4 z opóznieniem 0,4sek.
Nigdy nie nałozą sie dane z obu nadajnikow bo każde ma inny ofsset. UCz są synchronizowane często więc nie ma obawy zejścia się czasów.
W czasie gdy może być uaktywniony UCz przez zwarcie wejścia oczywiste jest ze Cen cały czas jest przygotowana do odbioru danych.
Zastanawiam się jeszcze nad wykorzystaniem liczb pierwszych ale muszę to dobrze przemyśleć.

nanoTECHNO wrote:

Zalożmy ze zostały zwarte w tym samym czasie wejścia w UCz 2 i 4 w 6 sekundzie od uśpienia UCz nr.1:
urządzenie nr2 wygeneruje dane z opóznieniem 0,2sek a UCz nr 4 z opóznieniem 0,4sek.
Nigdy nie nałozą sie dane z obu nadajnikow bo każde ma inny ofsset. UCz są synchronizowane często więc nie ma obawy zejścia się czasów.
.

No tak, a co jeśli np. urządzenie UCz nr4 wygeneruje dane(bo zwarto wejście) 0,4s przed obudzeniem Ucz nr1? Przecież dane nałożą się na siebie, ale z całkowitym wyeliminowanie takich sytuacji chyba sie nie uniknie, bo jak?

Jeżeli urządzenie UCz nr4 wygeneruje dane(bo zwarto wejście) 0,4s przed obudzeniem Ucz nr1 to Cen odbierze te dane ponieważ może obsługiwać UCz (ID+DANE+STBY+CRC) tylko w wybranym offsecie czasowym:

1 : w czasie 0,6-0,65s
2 : w czasie 0,7-0.75s
3 : 0,8-0,85s
4 : 0,9-0,95s
5 : 0,0-0,05s

Więc nie będzie to kolidować. Czasy są przykładowe. W zależności od długości ramki można je skrócić i więcej UCz upchać ewentualnie czas rozszerzyć do 2 sek.
W czasie kiedy UCz typowo są uśpione dla Cen ważne są czasy 0.1 do 0.55s.

Może niejasno opisałem sytuację...mam na myśli taką sytuację, że:

Jeśli np. urządzenie UCz nr4 i UCz nr np 6 wygeneruje dane w tym samym czasie (bo zwarto wejście w tych czujnikach), a 0,4s przed obudzeniem Ucz nr1, to zakładając że ponawiają one
dane po odpowiednio 0,4s i 0,6s to UCz nr 4 będzie chciało ponowić dane w momencie kiedy przyjdzie czas nadawania UCz nr1, prawda? I o takąkolizję mi chodzi, ale chyba nie da się tego wyeliminować bo to jest losowość zwieranie wejść w UCz której nie przewidzimy.

Załóżmy że są 2 tryby pracy A i B.
W trybie A :
1. Cen wysyła identyfikator
2. Odpowiada odpowiedni UCz przez wysłanie ID+DANE+CRC
3. Cen zapisuje dane i wysyła rozkaz POWERDOWN do UCz. Rozkaz jest jednocześnie sygnałem synchronizujacym. UCz zaczyna odmierzać czas.

W trybie A wszelka obsługa odbywać się może w okienku czasowym X.6 do X+1.05 sek.
Każdy UCz równo odmierza czas.

Tryb B
1. Zwarcie wejścia UCz i transmisja radiowa ale nie od razu tylko po czasie przynależnym danemu UCz.
2. Odebranie przez Cen danych i wysłanie rozkazu POWERDOWN do UCz z uwzględnieniem czasu synchronizacji ew. pozostawienie włączonego aż do obsługi w trybie A .
Wszelka obsługa odbywać się może w okienku czasowym X.1 do X.55 sek.

Jak widać tryby A i B nie nachodzą na siebie.
Skupmy się narazie na 5 UCz bo dla większej liczby trzeba zarezerwować większe ramy czasowe.
UCz4 nie może równo nadać (w przypadku zwarcia wejścia) w momencie kiedy Cen chce obsłużyć UCz1 bo transmisja z UCz4 jest generowana tylko w X.4s
Kiedy UCz4 może nadawać w przypadku zwarcia wejscia?
Transmisje może rozpocząć tylko : 1.4s, 2.4s, 3.4s, 4.4s itd
i nie może trwać dłużej niż przynależny czas dla następnego UCz.
Dla Ucz5 rozpoczęcie transmisji to może być : 1.5s, 2.5s, 3.5 itd

Kiedy Cen może odpytać UCz 4 (Tryb A) ?
Cen może rozpocząc transmisje w 10.9s, 15.9s, 20.9s itd

Jeszcze przykład : jeżeli zwarcie wejscia UCz4 wystąpi w 8.6sek to UCz4 musi doczekać do 9.4 sek i wtedy wygenerować transmisje. Nie kiedy mu się chce.

nanoTECHNO wrote:

Jeszcze przykład : jeżeli zwarcie wejscia UCz4 wystąpi w 8.6sek to UCz4 musi doczekać do 9.4 sek i wtedy wygenerować transmisje. Nie kiedy mu się chce.

Wszystko to jest dla mnie jasne i nawet pobawię się może tą metodą, ale miałem nadzieję, że da się wy myśleć albo zaaplikować taki algorytm aby UCz-ujnikowe nie musiały czekać na swoje "okienko czasowe". Ale po rozpatrzeniu różnych sytuacji i rozwiązań trudno tu o kompromis między kolizyjnością a oszczędnością baterii poprzez usypianie Ucz.

Za dotychczasową pomoc bardzo dziękuje. Pozdrawiam

Jeśli łączność może być dwukierunkowa, to może działać to tak, że Cen wysyła kolejno
identyfikatory wszystkich czujników, po każdym ma być krótka przerwa, podczas której
Cen nasłuchuje, a czujnik, którego identyfikator Cen właśnie wysłał, może odpowiedzieć;
każdy czujnik po obudzeniu się ma czekać na swój identyfikator (jeśli w zadanym czasie
nie "usłyszy" żadnego identyfikatora, to ma się uśpić bez nadawania sygnału) i po nim
wysłać swoje dane; Cen ma potwierdzić poprawny odbiór, i może podać, na jak długo
czujnik ma się uśpić (i w ten sposób doprowadzać do równomiernego rozkładu sygnałów
od czujników w czasie), albo zasygnalizować błąd i np. podać krótszy czas uśpienia.
Jeśli nawet kilka czujników obudzi się jednocześnie, to każdy z nich dostanie swój czas
na nadawanie, nie będzie konfliktu, tylko niektóre zaczekają, kiedy inne będą nadawać.

Zakładam, że czas uśpienia nie jest dokładnie mierzony, może być znacznie skrócony,
jeśli czujnik zostanie "obudzony" nie przez upływ czasu, a przez coś, co ma wykrywać;
oraz że wysyłanie identyfikatorów przez Cen może być szybkie (a czujnik po odbiorze
swojego identyfikatora szybko przełącza się na nadawanie), żeby czujniki nie musiały
długo czekać na swój identyfikator, jeśli żaden inny czujnik akurat nie wysyła; w stanie
uśpienia czujnik ma wyłączony odbiornik (bo on by znaczące zużywał baterię).

Ewentualnie, bardziej złożony system: Cen wysyła na zmianę identyfikator czujnika,
który powinien właśnie się obudzić i nadać swój sygnał, oraz sygnał zezwalający na
zgłaszanie poza kolejnością - jeśli odbierze zgłoszenie (możliwe, że kilku czujników
naraz), to odpytuje wszystkie czujniki; to zapewni krótsze czekanie na nadawanie
przy braku alarmu, ale kosztem większej ilości sygnałów wysyłanych przy alarmie.

A jaka jest tak naprawdę różnica między metoda kolegi nanoTECHNO a Twoim _jta_?

Że nadajnik może być "uśpiony", nie wysłać danych w odpowiedzi na identyfikator,
a odbiornik wtedy szybko wysyła następny, żeby inny nadajnik za długo nie czekał.
Ale jeśli czas przesłania sygnału jest krótki, to ta różnica nie jest istotna.

Witam

Przy założeniu, że czujnik budzi się np co 10s i transmisja z racji oszczędności energii ma być jednokierunkowa można to rozwiązać następująco:
Do tego czasu 10s odmierzanego w mikrokontrolerze należy losowo dodawać lub odejmować inną wartość czasu, ale musi się to odbywać w sposób losowy.Wówczas nawet jeśli na kilkadziesiąt czujników w danej chwili będą transmitowały 2 to już w kolejnej sekwencji ich czasy się rozjadą "losowo" i się nie nałożą.Przy transmisji jednokierunkowej można się wtedy pozbyć RFM22 na rzecz tylko nadajnika,przy większej ilości czujników zaoszczędzi się sporą kwotę.