Przyciski 1 z 10 sterowane radiowo - kolizja błędów

Witam,
chciałbym zbudować urządzenie podobne do 1 z 10 sterowane radiowo. Chodzi o pozbycie się przewodów od stanowisk do sterownika.


Chodzi o to, aby poszczególne stanowiska z przyciskiem chwilowym, radiowo do centralki wysyłały informację o tym który z graczy jako pierwszy nacisnął przycisk. Sterownik po decyzji załączał by podświetlanie stanowiska najszybszego gracza.

Problemem jest sytuacja, w której 2 lub więcej graczy, w podobnym czasie lub jednocześnie nacisną przyciski w swoim stanowisku. Wtedy jednoczesne wysłanie informacji drogą radiową spowoduje kolizję w transmisji i może się zdarzyć, że odbiornik nie odbierze informacji od żadnego stanowiska. Różnice w naciśnięciu między graczami będą zapewne rzędu milisekund.

Jakie moduły i sterowanie można tu wykorzystać, aby uniknąć kolizji?

Zastanawiam się nad takim rozwiązaniem:
- sterownik wysyła do stanowisk informację o gotowości (np zapala zieloną lampkę na stanowiskach)
- od tego momentu liczony jest czas w każdym z stanowisk.
- gdy każdy gracz naciśnie swój przycisk, zapala się czerwona lampka (jak jakiś gracz nie naciśnie po jakimś czasie zwłoki to nie jest brany pod uwagę)
- teraz gdy minęły np 3 sekundy od włączenia zielonej kontrolki gotowości, to sterownik odpytuje stanowiska i sprawdza czas reakcji każdego z graczy
- na końcu podświetla stanowisko gracza najszybszego
- w sterowniku będzie też przycisk Reset wyłączający podświetlania stanowiska lub inne przyciski (np do nastawy szans)

Co o tym myślicie, można to zrobić lepiej? Najchętniej za pomocą łatwo dostępnych modułów transciverów RF 433MHZ, 868Mhz itp.

Z góry dziękuję za pomoc i wskazówki.
Pozdrawiam Darek.

Temat dość szeroki do dyskusji.
Ja bym zrobił jeden master a na stanowiskach slavy. Tylko master inicjuje połączenie i odpytuje. Odpowiada tylko pytany slave.
I teraz...
Master wysyła sygnał, że zaczynamy grę.
Slavy zerują liczniki i zaczynają odliczanie na przykład mili sekund.
Master odpytuje kolejno czy przycisk został wciśnięty, a jeśli tak to po jakim czasie od startu liczników.
Komplikuje program, ale eliminuje kolizję.

Cytat:

jeden master

Pomyślałem to samo zanim przeczytałem twój wpis.
To jest jedyne sensowne rozwiązanie załatwiające w 100% problem wyścigu.
Problemem teoretycznie mogłaby być dokładność zegarów, ale przy okresie synchronizacji zegarów rzędu sekundy czy nawet kilku sekund to pewnie większy wpływ na wynik będą czasy zadziałania poszczególnych przycisków mechanicznych.

Witam.

@Press A nie lepiej jako start dać nośną która jak się pokaże to da sygnał do startu.
Radio może popełnić błąd przy dekodowaniu ramki co sprawić może opóźnienie lub brak zainicjowania sygnału do startu.

Obieranie danych w slave też może mieć inne czasy zależne od miejsca w którym będzie program.
Zdekodowaną nośną wprowadzany na procesor np. przerwaniem INT0.

Teoretycznie masz rację, ale z odbiorem danych jest różne. Tyle jest różnych transmisji w powietrzu że
czasami dostajemy śmieci które źle wpływają na dekodowanie takich ramek.

Pytanie do autora postu, na ile ma być to wiarygodne?

Cytat:

Radio może popełnić błąd przy dekodowaniu

Wystarczy dodać możliwość sprawdzenia przez mastera, czy zegary ruszyły prawidłowo albo po prostu odczytać po uruchomieniu stan każdego z nich i liczyć czas z uwzględnieniem tego "offsetu" potem ( oczywiście odpowiednio uwzględniając też czas pomiędzy odczytami każdego z 10 punktów ).
Przypuszczam, że opóźnienia które tu w praktyce mogą wystąpić czy to z tego powodu czy z powodu jakichś przerwań itp. nie mają w praktyce znaczenia, bo będą o rzędy mniejsze niż realne opóźnienia wprowadzane przez mechanikę przycisków.

W takim zastosowaniu dokładność rzędu 0.01 sek. to będzie świat i ludzie jak sądzę.

Dzięki za dyskusję. Także myślałem o tylko jednym masterze, odpytującym i zerującym liczniki.

Pomysł dasej wydaje mi się ok, ale może ciut inaczej bo są przecież moduły które dają przerwanie gdy na wejściu odbiornika pojawi się nośna z ramką synchronizacyjną i można (np w modułach HOPRF) ustawić przerwanie sygnalizujące nadejście bajtu synchronizacji. Z drugiej strony od bajtu synchronizacji do końca całej ramki i jej rozpoznania minie kilka ms więc czy będziemy rozpoznawać sam bajt synchronizacji czy całą ramkę nie ma znaczenia bo np mechanizm przycisku będzie miał większą i różną reakcję jak te kilka ms.

Jedyne co mnie zastanawia to stan kiedy slave'y dostają sygnał resetu i startu liczników czasu. Dobrze by było aby potwierdziły masterowi, że otrzymały taki sygnał. Tutaj jednak poza liczeniem czasu reakcji trzeba by było uwzględnić czas między kolejnymi odpytaniami slave'ów i korygować wynik w zależności od szybkości transmisji (ogólna wartość offsetu o której wspomniał sundayman ).

Na pewno reakcja człowiek będzie raczej w dziesiątkach ms . Nie moze być jednak sytuacji, że któryś z slave'ów nie otrzyma sygnału startu, muszą być potwierdzenia.

FastProject napisał:

Jedyne co mnie zastanawia to stan kiedy slave'y dostają sygnał resetu i startu liczników czasu.

Oddzielna nośna z mastera ma to wyzwalać.

Cytat:

Oddzielna nośna z mastera ma to wyzwalać.

Się uczepiłeś. Nie ma potrzeby żadnej "nośnej" dodawać.
Wystarczy wysyłana komenda w stylu "startuj zegar".
To, czy jeden czy drugi slave będzie miał opóźnienie rzędu jakiejś "ramki" nie ma żadnego praktycznego znaczenia. Ile twoim zdaniem może to opóźnienie wynieść, żeby się nim zajmować ? Pamiętaj, że tutaj dokładność rzędu kilkudziesięciu mS spokojnie wystarczy.

Dalej to już można zrealizować różnie.
Wystarczy nadać numery każdemu slave'owi i kazać po czas x+n*50mS ( gdzie n to numer slave ) wysłać "zgłoszenie" do mastera z aktualnym czasem.

Po poprawnej synchronizacji powinno przyjść do mastera 10 informacji w odstępie 50ms zawierającej odpowiednie wartości zegarów dla każdego z nich. Jeśli każdy slave wyśle stan zegara PRZED odmierzeniem tego czasu oczekiwania na swoją kolejkę", to nawet nie będzie potrzebny żaden offset, bo każdy powinien mieć ten sam stan zegara.

Oczywiście, te czasy będą się różnić o ileśtam wynikające z nierównomierności pracy zegarów, odległości od mastera itp. ale w praktyce to wszystko jest bez znaczenia.

Jeśli przyjdą wszystkie i z tą samą (w ramach określonej dokładności ) zawartością zegara - to jest OK. Jeśli nie, to ponawiamy synchronizację i po zabawie.
Oczywiście master musi mieć możliwość sygnalizacji, że np. coś jest "nie halo" i że układ nie gotowy.

Moim zdaniem żadna synchronizacja zegarów nie jest potrzebna Jeśli pominąć konieczność zdalnego zapalania lampek wystarczy aby master jedynie odbierał dane.
Załóżmy, że każdy salve ma licznik taktowany zegarem o znanej częstotliwości. Aktualna wartość tego licznika jest okresowo wysyłana przez radio. Naciśniecie przycisku zeruje licznik. Master na podstawie odbieranych informacji jednoznacznie będzie mógł określić kiedy zostały naciśnięte poszczególne przyciski.

TvWidget napisał:

Aktualna wartość tego licznika jest okresowo wysyłana przez radio.

No i wracamy do punktu wyjścia bo przyjdzie w końcu taki czas że slavy będą musiały się rozstrzelić czasowo i nastąpi kolizja.
Poza tym nie wiadomo kiedy przycisk slave zostanie zwarty więc to wysyłanie do mastera musiało by być wykonywane dość często więc kolizja tym szybciej nastąpi.

W paśmie 2.4GHz nadanie ramki trwa zapewne około 1mS. Przy okresie rozgłaszania 100mS kolizje będą się zdarzały stosunkowo rzadko. Spowodują one jedynie, że master będzie potrzebował trochę więcej czasu na określenie wyniku.
W przypadku Bluetooth Low Energy urządzenia się okresowo rozgłaszają na trzech różnych kanałach. Nawet jeśli urządzeń jest dużo to trudno zaobserwować aby się zagłuszały.

1 master wysyła Broadcast że start (pojedyncza ramka)
2 master odpytuje czy są wystartowane jeśli któryś nie, to 1
3 master stale odpytuje aż znajdzie zatrzymanego slave z najkrótszym czasem.
4 master wyświetla i zatrzymuje slave.

Cytat:

3 master stale odpytuje aż znajdzie zatrzymanego slave z najkrótszym czasem.

Bez okresowej synchronizacji będzie narastać "rozjazd" zegarów w przypadku dłuższego oczekiwania na naciśnięcie przycisku. Ale być może ta synchronizacja nie musi być często - trzeba by ustalić eksperymentalnie po jakim czasie różnica robi się znacząca.

Albo porównywać ( w masterze ) stopień "rozsynchronizowania" poszczególnych stanowisk i po przekroczeniu określonego limitu synchronizować.

Metod szczegółowej realizacji na pewno jest sporo.
Komunikacja dwukierunkowa ma także tą zaletę, że zostaną wykryte ewentualne nieprawidłowości w działaniu. W przypadku takich "turniejowych" zastosowań nie byłoby dobrze, gdyby system nie zadziałał i trzeba by powtarzać

sundayman napisał:

Cytat:

3 master stale odpytuje aż znajdzie zatrzymanego slave z najkrótszym czasem.

Bez okresowej synchronizacji będzie narastać "rozjazd" zegarów w przypadku dłuższego oczekiwania na naciśnięcie przycisku. Ale być może ta synchronizacja nie musi być często - trzeba by ustalić eksperymentalnie po jakim czasie różnica robi się znacząca.

sundayman napisał:

Cytat:

Oddzielna nośna z mastera ma to wyzwalać.

Się uczepiłeś. Nie ma potrzeby żadnej "nośnej" dodawać.

Zamień słowo nośna na sygnał wyzwalający start i kończy się problem z rozjazdem zegarów.

Dla kwarcu np 16MHz 30 ppm to rozjazd wyniesie 0,00000000375 / sekundę
a tyle na dobę 0,000324 sekund.

sundayman napisał:

3 master stale odpytuje aż znajdzie zatrzymanego slave z najkrótszym czasem.


Bez okresowej synchronizacji będzie narastać "rozjazd" zegarów w przypadku dłuższego oczekiwania na naciśnięcie przycisku. Ale być może ta synchronizacja nie musi być często - trzeba by ustalić eksperymentalnie po jakim czasie różnica robi się znacząca.

Właśnie po to jest Broadcast w postaci pojedynczej ramki

Panowie temat powraca, w ciut bardziej skomplikowanej postaci. Czy któryś z kolegów jest zainteresowany opracowaniem i wykonaniem takiego urządzenia, w którym jest master, oraz 3 graczy, i każdy z graczy ma po 10 do 16 przycisków. Z braku czasu nie jestem w stanie zacząć projektu. Termin początek 2023, budżet 7000+ netto. Utworzę ogłoszenie w dziale Projektowanie Bazar Link. Pozdrawiam.