Arduino, SIM900A, SMS

Nov 25, 2018 34 Replies

Dzień dobry,



Może ktoś z Was podpowie mi co robię źle.



Hardware: Arduino Uno, moduł GSM SIM900A, zasilacz 5V 3.6A Software jak poniżej. W plikach Arduino SoftwareSerial.h i HardwareSerial.h zmieniona wielkość bufora RX do 256.



Objawy - wysyłanie smsów działa (choć przyznam, że nie sprawdzałem ile maksymalnie znaków mogę wysłać), odbieranie działa ale odebrana wiadomość jest ucinana do kilkunastu znaków (poniżej przykład). Wysyłam dla przykładu 1234567890 powtórzone pięć razy i w msgBuffer otrzymuję:


+CMT: "+XXXXXXXXXXXX","","18/11/25,15:36:19+00"
12345678901237

czasem ostatnia cyferka jest inna, czasem jej w ogóle nie ma, czasem jest jedna więcej - żadnej prawidłowości.



Kod (właściwie to copy&paste z internetowych poradników):



#include <SoftwareSerial.h>



SoftwareSerial mySerial(5, 6);



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



void setup() { Serial.begin(115200); delay(2000); mySerial.begin(57600); delay(30000); mySerial.println("AT+CMGF=1"); mySerial.println("AT+CNMI=2,2,0,0,0"); delay(1000); Serial.print("End of setup"); SendMessage("+XXXXXXXXXXXX", "End of setup"); }



void loop() { msgDetails(); }



void msgDetails() { String msgBuffer = readSIM900A(); if (msgBuffer.startsWith("\r\n+CMT: ")) { Serial.println(msgBuffer); } }



String readSIM900A() { String msgBuffer; while (mySerial.available() > 0) { char c = mySerial.read(); msgBuffer.concat(c); delay(10); } return msgBuffer; }



Pomożecie? Z góry bardzo dziękuję.


Michal M. Lechanski wrote on 25.11.2018 16:59:

Po pierwsze podłącz oscyloskop albo lepiej analizator stanów logicznych na linie RxD/TxD i zweryfikuj co faktycznie leci po drutach, łącznie z czasami trwania bitów. Może masz odrobinę skopaną prędkość transmisji i po kilku bajtach ci się rozjeżdża synchronizacja? Zwłaszcza jeśli używasz software'owego UARTa. Jeśli masz też włączone inne przerwania (timery?, inne uarty?), to na bank nie będzie to działało dobrze. AVR nie ma priorytetów przerwań i jedyne co możesz w tej sytuacji zrobić to zmiana procka na model z 2 UARTami.

PS. Pamiętam też że ktoś już kiedyś skarżył się na grupie na modem SIMxxx, że cześć radiowa zakłócała mu komunikację po RSie, ale to sprawdził po upewnieniu się, że z programem jest wszystko w porządku.

W dniu 25.11.2018 o 18:21, Zbych pisze:

Pięknie dziękuję, ale przeceniasz mnie :-)

Zapomniałem napisać - sprawdzałem dla różnych kombinacji prędkości i albo nie dostawałem nic, albo jakieś krzaczki. Ustawienia Serial i prędkość w okienku terminala na 115200 wydają się działać dla różnych prędkości SoftwareSerial. Nie wpływa to jednak na to co dostaję w msgBuffer

Jak pisałem poprzednio - mój "program" to w zasadzie copy&paste z (wielu różnych) internetowych poradników. Trudno mi uwierzyć, żeby wszyscy autorzy publikowali to bez sprawdzenia.

Jeszcze raz bardzo dziękuję za zainteresowanie.

Michal M. Lechanski wrote on 25.11.2018 19:33:

Tzn. nie masz 20...40zł na narzędzie, które pozwoli ci zweryfikować co się dzieje na drutach?

formatting link
?spm=2114.search0104.0.0.8205740boSXdhk&initiative_id=SB_20181125104744&site=glo&groupsort=1&SortType=price_asc&SearchText=logic+analyzer

Jeśli problemem jest programowy Uart, to tylko maksymalne obniżenie prędkości transmisji może cię ratować. Ale i tak najpierw musisz z prędkością 115200 wysłać do SIM900 komendę zmieniającą prędkość na np. 9600.

W dniu 25.11.2018 o 18:50, Zbych pisze:

Nie w narzędziu problem ale w umiejętności skorzystania z takiego urządzenia lub interpretacji uzyskanych pomiarów.

To wydaje mi się ważne - nie pomyślałem że zadeklarowanie prędkości w kodzie może nie być wystarczające i że trzeba jeszcze zmienić ustawienia modemu... Poczytam, spróbuję. Dzięki za dodatkowy trop, bez względu na to dokąd mnie doprowadzi :-)

To ja pisałem. Faktycznie zakłócenia były tak silne, że musiałem prędkość obniżyć do 9600, natomiast nigdy nie udało mi się tym modulem (w sensie chińskiej płytki z modułem) uzyskać 100% transmisji bez błędów. A tak z ciekawości pytanie do inicjatora wątku, z jakiego zrodla pochodzi ten Twój sim900A? O ile pamiętam sim900a był wyłącznie na rynek azjatycki z simlockiem. Sam go flashowales by chodził u nas?

W dniu 25.11.2018 o 20:12, Marek pisze:

Kupiony na eBay więc pewnie z Chin, choć dostawa była z UK. I tutaj działa, tyle że narowiście... Czy sprzedawca coś z nim robił? Nie mam pojęcia.

Dnia Sun, 25 Nov 2018 15:59:51 +0000, Michal M. Lechanski napisał(a):

^^^^^

wstaw delay(1), albo wywal kompletnie/przerob.

Teraz ci grozi cos takiego, ze znaki stracisz, bo sie bufor przepelni.

J.

W dniu 25.11.2018 o 21:48, J.F. pisze:

Dziękuję bardzo! Znacząca poprawa - po usunięciu delay(10), zamiast kilkunastu znaków z wysłanych 50, dostałem 47...

Możesz pokazać jak wygląda, jakiś link do aukcji?

Niestety to kolejny przykład badziewnego gotowego softu dla Arduino. Często nadużywane delay() blokujące Io a w tym skrajnym przypadku powodujące utratę danych czy wręcz blokadę uarta spowodowaną przepełnienie sprzetowwgo bufora rx . Nie możesz zakładać, że tysiące ludzi używa to musi działać, jak wydzisz działa tak sobie. Odbiór znaku z uart powinien być w przerwaniu, które zapisze je do aplikacyjnego kołowego bufora odbiorczego (ring buffer). Z niego aplikacja pobiera sobie po kolei odebrane znaki.

W dniu 26.11.2018 o 08:30, Marek pisze:

Na ebay już ich nie ma, ale znalazłem niemal identyczny (mój ma czerwoną płytkę) na Aliexpres:

tiny.cc/5lo90y

Albo jak kto woli:

formatting link

W dniu 26.11.2018 o 19:32, Michal M. Lechanski pisze:

Oczywiście mój to SIM900a a nie SIM800C

Tylko na ile dobrze rozumiem:

-to jest akurat uart softwareowy, sprzetowy zajety na wazniejsze rzeczy,

-biblioteka dziala w przerwaniach, i zapisuje do bufora, ale jakos slabo, albo bufor maly,

-to przyklad jest do d*, bo nalezy odbierac dane z uarta az do ... jakiegos znaku konca czy dluzszej przerwy w transmisji,

-zrodel biblioteki znalezc na szybko nie moglem, no to co mozna mowic o jakosci ...

J.

Pięknie , pięknie aż całe 100uF dali.... Ale wiesz ile bierze taki moduł przy transmisji ? Pobór prądu przy nadawaniu/logowaniu do sieci to seria impulsów

2A/~0.6ms. Napięcie na zasilaniu nie może spaść bardziej niż o 0.35V.

No to jeżeli tam nie ma więcej pojemności lub bardzo szybkiego zasilacza/stabilizatora no to jesteś w .... niedomówienie.

To tyle odnośnie problemów ze zbyt szybkim rs-em i zakłócaniem z anteny.

Adam Górski

Tyle, ze to 1200uC ladunku. na 100uF 12V spadku, na 1000 1.2V, musieliby 4700uF wsadzic.

Widac to zadanie konstruktora plytki ... albo po prostu grube sciezki do zasilacza :-)

J.

Ja proponuję w takim przypadku 3300 µF/6.3 V. Przy zasilaniu z zasilacza proponuję 5 V, LDO ustawiony na min. 3.9 V (max 4.2 V) i rezystor szeregowy 1 Ω przed kondensatorem 3300 µF/6.3 V. Działa bez pudła - zamiast szarpać po 2 A z zasilacza ciągnie ok. 300 mA w pikach dla najgorszego warunku.

Ten rezystor nie pogarsza "recovery time" kondensatora w takim przypadku?

W dniu 27.11.2018 o 12:13, Adam Górski pisze:

wiem, przekonałem się że wtyczka Samsunga z USB oznaczona na 2A nie dała rady. Więc teraz zasilacz daje 3.6A (no dobrze tak było na nim napisane) i dodatkowo elektrolit o ile pamiętam 2200uF.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required