-
31. Data: 2018-12-01 07:39:19
Temat: Re: Arduino, SIM900A, SMS
Od: Marek <f...@f...com>
On Fri, 30 Nov 2018 20:14:17 +0000, "Michal M. Lechanski"
<m...@d...eu> wrote:
> To by było za proste... akurat ten operator nie obsługuje takiej
> formy
Jaki to operator?
> ale to samo zapytanie wysłane za pomocą
> modułu SIM owocuje zwrotką "Przepraszamy nie rozumiemy zapytania,
> proszę
> się skontaktować z BOK".
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ł.
> najpierw AT+CMGF=0 (tryb PDU) zamiast tekstowego AT+CMGF=1
Tryb nie powinien mieć znaczenia (o ile prawidłowo kodowany jest PDU).
--
Marek
-
32. Data: 2018-12-01 15:28:32
Temat: Re: Arduino, SIM900A, SMS
Od: "Michal M. Lechanski" <m...@d...eu>
W dniu 01.12.2018 o 06:39, Marek pisze:
> Jaki to operator?
Asda Mobile, wirtualny operator korzystający z sieci EE
>> ale to samo zapytanie wysłane za pomocą
>> modułu SIM owocuje zwrotką "Przepraszamy nie rozumiemy zapytania,
>> proszę się skontaktować z BOK".
>
> 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ł.
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
> Tryb nie powinien mieć znaczenia (o ile prawidłowo kodowany jest PDU).
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ć.
--
Michał
-
33. Data: 2018-12-01 17:20:27
Temat: Re: Arduino, SIM900A, SMS
Od: Marek <f...@f...com>
On Sat, 1 Dec 2018 14:28:32 +0000, "Michal M. Lechanski"
<m...@d...eu> wrote:
> 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
No bo za bardzo nie ma innego wytłumaczenia dlaczego akurat smsy z
modułu są nierozpoznawalne.
> 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ć.
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.
--
Marek
-
34. Data: 2018-12-01 19:41:34
Temat: Re: Arduino, SIM900A, SMS
Od: "J.F." <j...@p...onet.pl>
Dnia Sat, 1 Dec 2018 14:28:32 +0000, Michal M. Lechanski napisał(a):
> W dniu 01.12.2018 o 06:39, Marek pisze:
>>> ale to samo zapytanie wysłane za pomocą
>>> modułu SIM owocuje zwrotką "Przepraszamy nie rozumiemy zapytania,
>>> proszę się skontaktować z BOK".
>>
>> 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ł.
>
> 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
A modul dobrze ustawiles ? W telefonie sie jakies centrum sms ustawia.
Inne SMS zawieraja rozne znaki ? Moze kwestia parzystosci.
>> Tryb nie powinien mieć znaczenia (o ile prawidłowo kodowany jest PDU).
> Hm... Jeśli dekodowanie odbywa się po stronie odbiorcy, to chyba raczej
> będzie miał - dekoder oczekuje PDU, a dostaje czysty tekst...
Format jest jeden, zmiana na PDU jest w module.
J.
-
35. Data: 2018-12-06 21:37:53
Temat: Re: Arduino, SIM900A, SMS
Od: "Michal M. Lechanski" <m...@d...eu>
W dniu 01.12.2018 o 06:39, Marek pisze:
> A to dziwne. Czy na pewno wysyłany jest tekst jaki oczekujesz, że
> powinien?
> Być może (błędny) kod dokonuje jakiegoš przekłamania.
Miałeś rację - błędny kod.
>> najpierw AT+CMGF=0 (tryb PDU) zamiast tekstowego AT+CMGF=1
>
> Tryb nie powinien mieć znaczenia (o ile prawidłowo kodowany jest PDU).
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.
--
Michał