Jak ustawić moduł GSM, aby odrzucał połączenia przychodzące z sygnałem zajętości?

Tue Jan 01, 2013 10:13 am   

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ę...

Tue Jan 01, 2013 11:25 am   

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.

Tue Jan 01, 2013 11:47 am   

Użytkownik "Atlantis" <marekw1986NOSPAM@wp.pl> napisał w wiadomości
news:kbudjh$sjc$1@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!

--
Pod żadnym pozorem nie zezwalam na wysyłanie mi jakichkolwiek reklam,
ogłoszeń, mailingów, itd., ani nawet zapytań o możliwość ich wysyłki.
Nie przyjmuję ŻADNYCH tłumaczeń, że mój adres e-mail jest ogólnodostępny
i nie został ukryty. Wszelkie próby takich wysyłek potraktuję jako stalking.

Tue Jan 01, 2013 12:02 pm   

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.

Tue Jan 01, 2013 12:27 pm   

On Tue, 01 Jan 2013 10:13:24 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:

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).

--
Marek

Tue Jan 01, 2013 12:52 pm   

Użytkownik "Atlantis" <marekw1986NOSPAM@wp.pl> napisał w wiadomości
news:kbufo4$t98$1@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źć...
http://pl.wikipedia.org/wiki/RS-232


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) )

--
Pod żadnym pozorem nie zezwalam na wysyłanie mi jakichkolwiek reklam,
ogłoszeń, mailingów, itd., ani nawet zapytań o możliwość ich wysyłki.
Nie przyjmuję ŻADNYCH tłumaczeń, że mój adres e-mail jest ogólnodostępny
i nie został ukryty. Wszelkie próby takich wysyłek potraktuję jako stalking.

Tue Jan 01, 2013 1:14 pm   

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).

Tue Jan 01, 2013 1:59 pm   

Użytkownik "Atlantis" <marekw1986NOSPAM@wp.pl> napisał w wiadomości
news:kbuk07$ul1$1@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ę :)

--
Pod żadnym pozorem nie zezwalam na wysyłanie mi jakichkolwiek reklam,
ogłoszeń, mailingów, itd., ani nawet zapytań o możliwość ich wysyłki.
Nie przyjmuję ŻADNYCH tłumaczeń, że mój adres e-mail jest ogólnodostępny
i nie został ukryty. Wszelkie próby takich wysyłek potraktuję jako stalking.

Tue Jan 01, 2013 3:59 pm   

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ć.

Tue Jan 01, 2013 4:44 pm   

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:
http://gatling.ikk.sztaki.hu/~kissg/gsm/at+c.html

Facility lock
+CLCK= fac ,mode [,passwd [,class]]
"AI": barr all incoming calls

J.

Tue Jan 01, 2013 5:57 pm   

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?

Tue Jan 01, 2013 6:16 pm   

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?

Tue Jan 01, 2013 8:37 pm   

On Tue, 01 Jan 2013 18:16:16 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:

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

--
Marek

Tue Jan 01, 2013 8:40 pm   

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ć...

Tue Jan 01, 2013 8:46 pm   

Użytkownik "Atlantis" <marekw1986NOSPAM@wp.pl> napisał w wiadomości
news:kbv5l4$4tj$1@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?

--
Pod żadnym pozorem nie zezwalam na wysyłanie mi jakichkolwiek reklam,
ogłoszeń, mailingów, itd., ani nawet zapytań o możliwość ich wysyłki.
Nie przyjmuję ŻADNYCH tłumaczeń, że mój adres e-mail jest ogólnodostępny
i nie został ukryty. Wszelkie próby takich wysyłek potraktuję jako stalking.