Arduino, SIM900A, SMS

U¿ytkownik "Michal M. Lechanski" napisa³ w wiadomo¶ci grup dyskusyjnych:ptpgl2$oi1$1$ snipped-for-privacy@news.chmurka.net...

Ale moment - nie mozesz wyslac z procesora do modulu, czy modul nie potrafi wyslac do sieci ?

skoro piszes, ze mozesz odbierac, to procesor jakies potrzebne komendy wysyla.

A przeloz karte do telefonu.

Albo sprawdz procedure inicjacji ... i dodaj troche opoznien przed wyslaniem komend :-)

J.

Jeśli dostajesz ERROR po AT+CMGS (przy poprawnej składni) oznacza to, że skończyły się środki na koncie prepaid.

W dniu 29.11.2018 o 20:28, Marek pisze:

Po AT+CMGS="+XXXXXXXXXXXX" Dostaję znak zachęty do wpisania tekstu. ERROR dostaję po kilku chwilach od wysłania CTRL+Z ((char)26) Środki na prepaidzie się same uzupełniają więc to nie to raczej, ale na wszelki wypadek sprawdzę po przełożeniu karty do telefonu.

I tu rodzi się kolejne pytanie - czy przełożenie karty do telefonu może jakoś wpłynąć na działanie modułu? Bo przekładałem tę kartę - J>F mi o tym przypomniał...

W dniu 29.11.2018 o 20:26, J.F. pisze:

moduł do sieci. Wysyła ((char)26) chwilę myśli i wywala ERROR.

Procesor z modułem komunikuje się bez problemów, a przynajmniej ja żadnych nie zauważyłem.

Dzięki za przypomnienie, spróbuję.

W dniu 29.11.2018 o 20:50, Michal M. Lechanski pisze:

Bardzo przepraszam - miałeś rację. Okazało się że nie skończył się jeszcze okres potrzebny żeby automatyczne doładowanie zadziałało...

Doładowałem online i już znowu działa. Jeszcze raz dziękuję za pomoc.

Jeśli to nie wina braku środków, to error może być zwrócony również przy braku zalogowania do sieci. Co zwraca "at+creg?"?. Trzeci powód to brak prawidlowego (stabilnego) zasilania (brak kondensatora low esr przy Vdd modułu), podczas próby wysyłania po cmgs kontroler brown out'u wykrywa niedopuszczalny spadek Vdd co przerywa komunikację i zwraca błąd.

Do testów modulu i oprogramowania polecam włączyć sobie usługę typu "smsy bez limitu" (większość operatorów prepaid to ma), bo inaczej znowu Cię zaskoczy brak środków :).

Nie, ale nie musisz przekładać karty. Możesz wysłać krótki kod do sprawdzenia salda orepaid at+cusd=1,"*100#" Zamiast przykładu *100# użyj kod dostarczany przez swojego operatora . W odpowiedzi dostaniesz unsolicited code +cusd , np:

W dniu 29.11.2018 o 21:54, Marek pisze:

To by było za proste... akurat ten operator nie obsługuje takiej formy zapytania o saldo konta. Już to sprawdziłem. Obsługiwane za to są smsy pod określony numer. Niestety to także nie jest rozwiązanie - odpowiedź na taki sms wysłany z telefonu to właśnie stan konta, ale to samo zapytanie wysłane za pomocą modułu SIM owocuje zwrotką "Przepraszamy nie rozumiemy zapytania, proszę się skontaktować z BOK". Mam zamiar sprawdzić czy coś pomoże jeśli zapytanie wyślę ustawiając najpierw AT+CMGF=0 (tryb PDU) zamiast tekstowego AT+CMGF=1 Jeśli to nie pomoże, to będę musiał się skontaktować z operatorem albo zmienić SIM.

Jaki to operator?

A to dziwne. Czy na pewno wysyłany jest tekst jaki oczekujesz, że powinien? Być może (błędny) kod dokonuje jakiegoš przekłamania. Podłącz terminal/monitor szeregowy pod linię RX modułu by podsłuchać co naprawdę dostaje moduł.

Tryb nie powinien mieć znaczenia (o ile prawidłowo kodowany jest PDU).

W dniu 01.12.2018 o 06:39, Marek pisze:

Asda Mobile, wirtualny operator korzystający z sieci EE

Wszystkie inne wysyłane smsy są bez błędów. Dlaczego akurat ten jeden miałby mieć *zawsze* błąd? I to w dodatku w 3 literkach: BAL

Hm... Jeśli dekodowanie odbywa się po stronie odbiorcy, to chyba raczej będzie miał - dekoder oczekuje PDU, a dostaje czysty tekst... Zobaczymy, niech tylko znajdę trochę czasu żeby doczytać i spróbować.

No bo za bardzo nie ma innego wytłumaczenia dlaczego akurat smsy z modułu są nierozpoznawalne.

To tak nie działa, nie wyslesz smsa text (jawnego) w trybie pdu (no upraszczając, no na siłę można ale nie o takim błędzie mówimy) i na odwrót. Miałem na myśli sytuację, w której encoder pdu z jakiego korzystasz może przekłamywać na jednym bicie budując nieprawidłowy octet. Da się to wysłać ale po zdekodowaniu u odbiorcy na jawny text jeden (lub więcej) znaków będzie nieprawidłowych. Kiedyś miałem taki problem z kodem encodera pdu napisanego w asm.

Dnia Sat, 1 Dec 2018 14:28:32 +0000, Michal M. Lechanski napisał(a):

A modul dobrze ustawiles ? W telefonie sie jakies centrum sms ustawia.

Inne SMS zawieraja rozne znaki ? Moze kwestia parzystosci.

Format jest jeden, zmiana na PDU jest w module.

J.

W dniu 01.12.2018 o 06:39, Marek pisze:

Miałeś rację - błędny kod.

Znów miałeś rację. Dzięki za pomoc.

Najbardziej mnie złości, że przedobrzyłem be żadnego sensownego powodu - błąd był w sumie trywialny - funkcja wysyłająca sms wysyłała zbyt dużo znaków końca linii i program odczytujący u operatora traktował to jako błąd:

tak miałem i było źle:

void SendMessage(String rcpNumber, String sendMsgBody) { mySerial.println("AT+CMGF=1"); //Sets the GSM Module in Text Mode delay(1000); // Delay of 1000 milli seconds or 1 second mySerial.print("AT+CMGS=\""); mySerial.print(rcpNumber); mySerial.println("\"\r"); delay(1000); mySerial.println(sendMsgBody);// The SMS text you want to send delay(100); mySerial.println((char)26);// ASCII code of CTRL+Z delay(1000); }

a tak działa bez problemu:

void SendMessage(String rcpNumber, String sendMsgBody) { mySerial.println("AT+CMGF=1"); //Sets the GSM Module in Text Mode delay(500); mySerial.print("AT+CMGS=\""); mySerial.print(rcpNumber); mySerial.print("\"\r"); delay(500); mySerial.print(sendMsgBody);// The SMS text you want to send delay(500); mySerial.print((char)26);// ASCII code of CTRL+Z delay(1000); }

Problemy rozwiązane. Bardzo wszystkim dziękuję za zainteresowanie.