zajętości linii GSM

Mam kolejne pytanie związane z moim projektem wykorzystującym moduł GSM. Mianowicie czy istnieje jakaś komenda AT, która uniemożliwiłaby nawiązanie połączenia przychodzącego z modułem (dzwoniący usłyszałby sygnał zajętości) bez wylogowywania go z sieci, tal aby samemu ciągle można było nawiązywać połączenia? Krótko mówiąc chodzi mi o odpowiednik słuchawki zdjętej z widełek w standardowym, analogowym telefonie. Co więcej - chodzi dokładnie o taką sytuację. Jak już kiedyś mówiłem w ramach nauki programowania AVR próbuję zamontować moduł GSM w obudowie starego telefonu, sterując nim za pomocą tarczy numerowej, widełek itp.

Pierwszym pomysłem jaki przyszedł mi do głowy było "ręczne" odrzucanie połączenia, gdy przy podniesionej słuchawce nadszedł komunikat "RING". Niestety, rozwiązanie się nie sprawdza. Zbadanie zawartości bufora zajmuje na tyle dużo czasu, że jeśli taka konieczność zajdzie w momencie kręcenia tarczą, program może przeoczyć część impulsów, co z kolei prowadzi do przekłamania numeru. Poza tym od strony dzwoniącego także nie wygląda to tak, jak powinno - najpierw przez moment słychać sygnał wybierania, a dopiero w chwilę potem pojawia się sygnał zajętości.

W dokumentacji modemu znalazłem coś takiego jak "AT+CHLD". Użycie "AT+CHLD=0" ma oznaczać "Ignore the incoming call". Jednak z tego co widzę to połączenie odnosi się do obsługi kilku połączeń przychodzących jednocześnie. Czy jego użycie w sytuacji, gdy żadnego połączenia nie ma, da właśnie taki efekt, jakiego oczekuję? A może jest do tego inne polecenie, które umknęło mojej uwadze?

Niestety chwilowo nie mam pod ręką modemu, więc sprawdzić nie mogę...

Reply to
Atlantis
Loading thread data ...

Mały update:

Jednak przeprowadziłem próbę. Użycie "AT+CHLD=x" (gdzie x to liczna z przedziału 0-2) w sytuacji, gdy nie ma aktywnej rozmowy powoduje zwrócenie komunikatu "ERROR" i niczego nie zmienia - połączenie przychodzące w żadnym z tych przypadków nie są odrzucane z automatu.

Jest jakieś inne rozwiązanie? W tej chwili mój jedyny pomysł opiera się na wykorzystaniu linii RI w roli sygnalizatora połączenia przychodzącego. Sprawdzenie stanu linii potrwa krócej niż odczytywanie bufora. Niemniej ciągle mam nadzieję, że może dałoby się to załatwić w samym modemie, bez ręcznego odrzucania połączenia.

Reply to
Atlantis

Użytkownik "Atlantis" snipped-for-privacy@wp.pl napisał w wiadomości news:kbudjh$sjc$ snipped-for-privacy@portraits.wsisiz.edu.pl...

Po chłopsku - skojarzenie wywołania z wciśnięciem czerwonej słuchawki. Może to mało eleganckie, ale chyba zadziała? Dodatkowo - jeśli jakiś numer jednak miałby się połączyć (różnie to w życiu bywa), można przeanalizować numer, który pojawi się z wywołaniem - i zamiast odrzucić, to przekierować to wywołanie do aparatu, aby zadzwonił. Tyle ode mnie, taki się wyczerpany czuję, rąbnąłem kawę, ale wiele nie dała. Piłem tylko trochę szampana... Tak jakby ktoś telepatycznie chciał zagrać na moich uczuciach... ale zostawmy ten temat p.s.medycyna, czy parapsychologia :) Pozdro noworocznie!

Reply to
Anerys

W dniu 2013-01-01 11:47, Anerys pisze:

Nie wiem czy dobrze zrozumiałem, ale chyba właśnie na tym opiera się (faktycznie mało eleganckie) rozwiązanie, które chciałem zastosować. Wciśnięcie czerwonej słuchawki = wysłanie komendy "ATH". Żeby skojarzyć z nim wywołanie trzeba najpierw stwierdzić jego obecność, a to wymaga dwóch kroków:

1) Sprawdzenia, czy w buforze odbiorczym są jakieś nieodczytane znaki. 2) Jeśli tak, sprawdzenia czy znaki te składają się na ciąg "RING\r\n".

Ponieważ kolejnych znaków trzeba oczekiwać przez określony z góry czas, całość zajmuje pewną chwilę (kilkaset ms) i jeśli w tym czasie tarcza się kręci, istnieje poważne niebezpieczeństwo (graniczące z dużą dozą pewności), że jakieś impulsy zostaną pominięte i numer ulegnie przekłamaniu... Praktyczna próba potwierdziła te obawy - połączenia wychodzące wykonywane wtedy, gdy ktoś akurat dzwoni do nas, nie dochodzą do skutku.

Reply to
Atlantis

Ja używam AT+CLCC, które daje listę połączeń wraz z numeramu i odpowiednimi flagami (przychodzące, wychodzące, odebrane, oczekujące itp.) Jeśli przy połączeniu jest flaga oczekujace (w sensie jeszcze nieodebrane), to wysylam at+chup. Połączenie jest odrzucone, ale wiem jaki nr dzwonił, więc mogę powiązać zdarzenie z okreslonym numerem (np. tak sobie bramę otwieram).

Reply to
Marek

Użytkownik "Atlantis" snipped-for-privacy@wp.pl napisał w wiadomości news:kbufo4$t98$ snipped-for-privacy@portraits.wsisiz.edu.pl...

Może i tak... jak pisałem, z niewiadomego mi powodu czuję się kompletnie wyczerpany (choć kawa już trochę zadziałała) i nie przyuważyłem niuansu, pardon :)

A to nie pojawia się natychmiast? Nie znam komórkowego, bawiłem się tylko POTS-owymi.

A nie lepiej sprawdzać stan linii... Oj... zaciemnienie, muszę odkimać... Ale zajrzałem tu i mam wrażenie, że tu się da coś znaleźć...

formatting link

Jak się nie da sprawdzić linii, to tak...

To buforować impulsy z tarczy (choćby nawet układem autonomicznym, nie angażującym procesora), a cyfrówce podawać już gotową informację.

To rozdzielić sterowanie impulsami, od ich aktywnej, że tak powiem, rejestracji. Buforem właśnie... Dodatkowo, jak zadzwoni, opróżnić bufor (dla uniknięcia błędnego wywołania), zasymulować sygnał zajętości/nieosiągalności, aby trzeba było całość powtórzyć. Może na dzieńdobry tak będzie łatwiej, a jak zadziała, dopieszczać w kierunku ostatecznego rozwiązania? Łatwiej było by mi to rozrysować przy osobistej rozmowie (w końcu trochę w Tepsie przepracowałem przy tych sprawach), ale pardon, nie dziś... :) Jak odsapnę, to może mnie tzw. wena trafi i podpowiem coś sensowniejszego? :) (przypomniało mi się, jak pisałem kiedyś program do odzyskiwania danych z dyskietki Commodore) :))

Reply to
Anerys

W dniu 2013-01-01 12:52, Anerys pisze:

Pojawia się. Modem wysyła przy każdym sygnale dzwonka ciąg znaków "RING\r\n\" które są zapisywane w kolejnych slotach bufora (circular buffer). Program musi odczytać odczytać kolejne nieodczytane znaki i porównać je z oczekiwanym ciągiem. Funkcja porównująca zwraca wartość "fałsz", jeśli w ustalonym czasie w buforze nie pojawią się znaki składające się na oczekiwany komunikat. Jeśli pojawią się wcześniej - zwraca wartość "prawda". Problem w tym, że operacja chwilę zajmuje. Jeśli właśnie wtedy kręci się tarcza, program może nie zauważyć jakiegoś impulsu...

Tak, wiem - linia RI. To jest następny pomysł, jeśli nic innego nie wypali. Po prostu chciałem uniknąć korzystania z kolejnej linii, gdyby dało się to zrobić inaczej - w końcu linia RX i tak odbiera redundantną informację o połączeniu przychodzącym.

To jest kolejny pomysł. Można by wykorzystać jedno z przerwań, generowanych w przypadku zmiany stanu jednej linii (tarcza zwiera jedną parę styków na czas zliczania impulsów składających się na jedną cyfrę numeru).

Reply to
Atlantis

Użytkownik "Atlantis" snipped-for-privacy@wp.pl napisał w wiadomości news:kbuk07$ul1$ snipped-for-privacy@portraits.wsisiz.edu.pl...

Nasunął mi się taki pomysł - nie porównywać całości, ale po pojedynczym znaku. Dopiero, jeśli się zgodzi, porównać następny i tak da capo al fine, aż do końca.

Już tu mam wrażenie (nie znam środowiska w którym programujesz), że za bardzo się koncentrujesz wokół odbioru informacji z bufora, zaniedbując odbiór impulsowania... Ale to tylko takie bardzo luźne wrażenie.

To może skoncentruj program wokół odbioru impulsowania, a jak znak z bufora przyjdzie te kilka ms pźniej, to czyżby miał się przekłamać?

Może to podpiąć pod obsługę przerwania i wtedy odebrać szybciutko bufor, może się wyrobi w 33 ms (czas zwarcia - nominał w .pl to 33/67 ms zwarcie/przerwa)?

Trudno mi podać ci przepis, ale tak sobie pomyślałem, że zamiast np. oczekiwać zboczy impulsów, to badać stan 0/1, co nawet przy przegapieniu zbocza, jeśli dało by się np. oszacować, ile czasu straciliśmy na odbiorze znaków, przypasować do jakiegoś wirtualnego szablonu, odtworzyć szybciutko przebieg - i od tego uzależnić dalsze działania...

Ja myślę, żeby nawet to bardziej dla procka uprościć - śjakiś licznik dziesiętny (na pierwszy ogień idzie 7490, ale on w BCD podaje, chyba da się oprogamować?), który po zakończeniu cyfry da prockowi znak (nie sam licznik, ale jego prosta oprawa) "odebrałem coś", procek piorunem zrobi przerwanie, może nie straci się znaku z bufora? Znów kojarzę to z komputerem Commodore i jego stacją dysków... Zasadniczo, podczas transmisji stacja dysków - komputer, przerwania i reszta programu schodza na daleki plan - jeśli gra muzyka, na czas transmisji jest wstrzymywana. Ale jakaś grupa popełniła demko, które działa tak: Turbo ok.

10 razy, sample doczytywane on-line (jest ich więcej, niż mieści się w pamięci), ale nie cały czas, proces przypomina nieco tzw. swapowanie pamięci (stosowane w GEOSie), bez przerywania grania muzyki, nawet, gdy nastąpi błąd odczytu, muzyka nie jest przerywana, a jedynie niemożliwy do wczytania fragment jest pomijany, co czasem daje dość niecodzienny efekt, jak muzyka nagle przeskoczy, czy się zapętli. Podrzucam Ci to jako inspirację :)
Reply to
Anerys

W dniu 2013-01-01 13:59, Anerys pisze:

Chyba faktycznie to będzie najlepsze rozwiązanie (nie licząc użycia linii RI). Dziwne, że nie przyszło mi to do głowy... Porównywanie po jednym znaku w każdej iteracji głównej pętli nie powinno w żaden sposób przeszkadzać pozostałym instrukcjom (to zaledwie kilka wykonań if), a sama operacja także powinna w miarę sprawnie przebiegać.

Reply to
Atlantis

Dnia Tue, 01 Jan 2013 10:13:24 +0100, Atlantis napisał(a):

A moze sie nie przejmowac ? Sytuacja na tyle rzadka, ze mozna odebrac.

Do sprawdzenia - a co bedzie jesli w takim stanie wyslesz normalna komende ATDnnn; ? Nie uda sie zadzwonic bo "linia zajeta" czy wlasnie polaczy, a nie odbierze ?

No nie przesadzajmy - sprawdzenie bufora to pare, moze parenascie rozkazow.

I wcale nie wiadomo czy chcesz sprawdzac w czasie krecenia - rozsadne byloby wlaczyc dzwonek, i niech uzytkownik decyduje - naciska widelki, podnosi i odbiera, czy kreci dalej - a pod koniec sprawdzasz czy nic nie czeka.

A w ogole jest jakies polecenie do odrzucenia ? ATH nie wiem czy zadziala. W zaleznosci od telefonu/modulu, moze jest jakies polecenie wciskania klawiszy (AT+CKPD) i "czerwona sluchawke" da sie nacisnac.

Czy moze raczej - do polaczenia przychodzacego w czasie rozmowy. Mozesz pierwsza dac na "hold", pogadac z druga, wrocic do pierwszej.

Nie uzywalem, ale jest taka obiecujaca:

formatting link
Facility lock

+CLCK= fac ,mode [,passwd [,class]] "AI": barr all incoming calls J.
Reply to
J.F.

W dniu 2013-01-01 13:59, Anerys pisze:

Przyszło mi do głowy jeszcze jedno rozwiązanie. Poszczególne przychodzące znaki można by analizować bezpośrednio po odebraniu, w przerwaniu RX USART-a. Każdy zgodny znak przesuwa wskaźnik do przodu, mylny zeruje go. Po dotarciu do końca badanego ciągu ostatnia instrukcja warunkowa, która sprawdza czy słuchawka jest podniesiona. Jeśli tak - wysyła "ATH\r", jeśli nie - uruchamia dzwonek. Oczywiście każdy znak przeanalizowany w przerwaniu byłby nadal dostępny dla procedury odczytującej bufor (nie przesuwałbym wskaźnika odczytu).

Jedną z największych zalet byłaby możliwość uśpienia uC, ponieważ ten nie musiałby ciągle sprawdzać w głównej pętli programu, czy ktoś nie dzwoni. Widełki również można by spiąć z linią obsługującą przerwanie sprzętowe. Mam jednak kilka wątpliwości...

1) Czy dopuszczalne jest wysyłanie jakichkolwiek znaków przez USART w przerwaniu obsługującym obiór znaków? Szczególnie jestem ciekaw jaki byłby efekt, gdyby było włączone echo... 2) Chyba musiałbym zastosować linię DTR, aby powstrzymać modem od wysyłania kolejnych znaków np. podczas tej całej operacji?

To dobry kierunek, czy raczej gra niewarta świeczki?

Reply to
Atlantis

W dniu 2013-01-01 16:44, J.F. pisze:

Zależy mi jednak na stabilnym i przewidywalnym działaniu programu...

Nie uda się zadzwonić, zwraca "NO CARRIER".

Problem polegał na tym, że nieopatrznie skorzystałem z gotowej, standardowej procedury oczekiwania na pojawienie się danego komunikatu w buforze. Działa ona w ten sposób, że przez zadany okres czasu czeka na pojawienie się oczekiwanego ciągu. Jeśli ciąg się pojawi - zwraca wartość prawdziwą. Jeśli czas upłynie - zwraca fałsz. Niestety przez ten czas procek jest zajęty.

Teraz wypróbuję inne podejście. W każdej iteracji głównej pętli procedury wybierania numeru będę sprawdzał jeden znak. Jeśli będzie się zgadzał - wskaźnik++. Jeśli nie - wskażnik = 0 (sprawdzanie od nowa). Gdy dojdzie do końca badanego ciągu (wykrycie komunikatu "RING"), wyślę "ATH".

Odpada. Program ma dokładnie naśladować zachowanie starego telefonu, bo (że tak powiem) będzie działał w starym telefonie. ;) Chodzi o zabudowanie urządzenia GSM w obudowie starego, bakelitowego telefonu RWT, z mikrosterownikiem pośredniczącym w komunikacji z widełkami, tarczą numerową i elektromechanicznym dzwonkiem. ;)

"ATH" działa. Tak BTW jaka jest różnica między "ATH" a "AT+CHUP"? Dokumentacja modułu podaje lakoniczne wyjaśnienie jego działania jako "hangs up call". Jak dla mnie dokładnie to samo robi "ATH"... Dwa redundantne polecenia?

Reply to
Atlantis

Ath nie rozlaczysz połączenia przychodzącego, jeszcze nie odebranego. Tym drugim - owszem.

Reply to
Marek

W dniu 2013-01-01 20:37, Marek pisze:

A to dziwne, bo obecnie w programie używam właśnie "ATH" we wszystkich sytuacjach, kiedy trzeba zakończyć połączenie. Działa równie dobrze w przypadku połączeń odebranych, jak i tych, które trzeba odrzucić...

Reply to
Atlantis

Użytkownik "Atlantis" snipped-for-privacy@wp.pl napisał w wiadomości news:kbv5l4$4tj$ snipped-for-privacy@portraits.wsisiz.edu.pl...

Coś mi mówi, że powinieneś dociągnąć do znaków CR-LF, jakoś nie bardzo mogę sobie wyobrazić znaków dawanych pod wlos... Ale zastanawiam się, czy nie przeszło by - po stwierdzeniu, że "RING", zakombinowaniem ze stanem linii kontrolnych... Ale jak pisałem, nie znam modemów GSMowych, jednak jeśli szybciej było by zrzucić połaczenie zamiast ATH, to ustawieniem/skasowaniem którejś z linii kontrolnych, to nie lepiej?

Reply to
Anerys

A to widać moduł modułowi nie równy :-), ja musiałem at+chup bo ath nie działało dla nieodebranych.

Reply to
Marek

W dniu 2013-01-01 20:46, Anerys pisze:

Oczywiście znaki kontrolne też uwzględniam, tutaj pominąłem dla uproszczenia. Zresztą problem z pominięciem tych znaków miałem tylko wtedy, gdy zaraz po odczytaniu komunikatu trzeba było wysłać jakieś polecenie - wówczas moduł otrzymywał nowe znaki, gdy poprzedni komunikat jeszcze był wysyłany. Prowadziło to do powstania błędu (przychodził "krzaczek").

Gdy jedynie trzeba sprawdzić, czy dany ciąg wystąpił (i nic nie jest zaraz potem wysyłane) ten problem nie występuje. Funkcja zwróci wartość prawdziwą, gdy wystąpi ostatni znak poszukiwanego ciągu. Znaki kontrolne zostaną po prostu zapisane do bufora. Przy następnym wywołaniu funkcji sprawdzającej zostaną pominięte (a właściwie będą resetowały sprawdzanie, dopóki nie pojawi się pasujący znak, albo nie upłynie zadany czas).

Aż takie niuanse nie są wyprowadzone na osobne linie niestety. Jest komplet linii rs232, do karty SIM, włączenia zasilania itp.

Reply to
Atlantis

W jaki sposób rozpoznajesz impuls z tarczy?

Reply to
Adam Wysocki

W dniu 2013-01-02 08:40, Adam Wysocki pisze:

Chyba w najprostszy z możliwych sposobów. Starszą wersję kodu znajdziesz tutaj:

formatting link
Od tamtego czasu nauczyłem się paru rzeczy, rozwiązałem kilka problemów i poprawiłem parę błędów. Sama procedura wybierania numeru (make_call) nie zmieniła się jednak prawie wcale, a część odpowiedzialna za odczytywanie tarczy jest praktycznie taka sama.

Reply to
Atlantis

Chodzi mi o to, w którym miejscu. Mam wrażenie, że nie robisz tego w przerwaniu, tylko w głównej pętli, między innymi funkcjami, które mogą być blokujące...

Reply to
Adam Wysocki

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.