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

do góry

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.

do góry

Użytkownik "Atlantis" <m...@w...pl> napisał w wiadomości
news:kbudjh$sjc$1@portraits.wsisiz.edu.pl...
> Jest jakieś inne rozwiązanie? W tej chwili mój jedyny pomysł opiera się na
> wykorzystaniu linii RI w roli sygnalizatora połączenia

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.

do góry

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

> Po chłopsku - skojarzenie wywołania z wciśnięciem czerwonej słuchawki.
> Może to mało eleganckie, ale chyba zadziała?

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.

do góry

On Tue, 01 Jan 2013 10:13:24 +0100, Atlantis <m...@w...pl>
wrote:
> 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?

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

do góry

Użytkownik "Atlantis" <m...@w...pl> napisał w wiadomości
news:kbufo4$t98$1@portraits.wsisiz.edu.pl...
>W dniu 2013-01-01 11:47, Anerys pisze:
>
>> Po chłopsku - skojarzenie wywołania z wciśnięciem czerwonej słuchawki.
>> Może to mało eleganckie, ale chyba zadziała?
>
> 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".

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

> Żeby skojarzyć z nim wywołanie trzeba najpierw stwierdzić jego obecność,

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

> a to wymaga dwóch kroków:
> 1) Sprawdzenia, czy w buforze odbiorczym są jakieś nieodczytane znaki.

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

> 2) Jeśli tak, sprawdzenia czy znaki te składają się na ciąg "RING\r\n".

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

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

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

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

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.

do góry

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

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

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


> 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

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 buforować impulsy z tarczy (choćby nawet układem autonomicznym, nie
> angażującym procesora), a cyfrówce podawać już gotową informację.

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

do góry

Użytkownik "Atlantis" <m...@w...pl> napisał w wiadomości
news:kbuk07$ul1$1@portraits.wsisiz.edu.pl...
>W dniu 2013-01-01 12:52, Anerys pisze:
>
>> A to nie pojawia się natychmiast? Nie znam komórkowego, bawiłem się
>> tylko POTS-owymi.
>
> 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

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.

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

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.

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

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

>> 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
>
> Tak, wiem - linia RI. To jest następny pomysł, jeśli nic innego nie

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

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

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

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.

do góry

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

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

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

do góry

Dnia Tue, 01 Jan 2013 10:13:24 +0100, Atlantis napisał(a):
> 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.

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 ?

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

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.

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

do góry