logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

[AtMega644][C] - SIM900 - moduł GPRS w dziwny sposób zrywa połączenie

mateo767 26 Lut 2016 09:11 1578 8
  • #1 15472206
    mateo767
    Poziom 9  
    Witam,
    piszę ostatnio oprogramowanie do obsługi SIM900 na AtMega644 w C. Potrzebne mi jest tylko połączenie TCP z serwerem. Nie interesują mnie połączenia ani SMS'y (na razie). Generalnie wszystko idzie dobrze, połączenie się zestawia, transmisja idzie w obydwu kierunkach, ale:
    Kiedy zostawiam urządzenie do testów na noc (cały czas aktywne połączenie TCP i co minuta zapytanie od serwera do kontrolera) to zauważam dziwny objaw.
    Serwer traci połączenie z urządzeniem po kilku godzinach (widzę to w logach aplikacji serwerowej i w wyniku polecenia netstat), jednak moduł SIM900 na komendę CIPSTATUS odpowiada "CONNECT OK". Procesor był zaprogramowany na pytanie SIM900 co pewien czas o status połączenia.
    Pomyślałem, że może to przez te zbyt częste pytania o status, SIM900 zgłupiał, więc zmieniłem program tak, aby procesor reagował tylko na komunikaty od SIM900.
    I znów coś poszło nie tak. Około godziny 23 serwer przestał "widzieć" urządzenie, a dopiero 3 godziny później SIM900 wysłał do procesora komunikat "+PDP: DEACT".

    Moduł SIM900 jest na starcie ustawiany komendami:
    ATr
    AT
    AT+IPR=9600
    ATE=0
    AT+CREG=0
    AT+CMGF=1
    AT+CMGDA="DEL ALL"
    AT+CNMI=1,1,0,0,0
    AT+GSMBUSY=1
    AT+CLIP=1
    AT+CIPSHUT
    AT+CIPMUX=0

    Potem następuje sekwencja połączenia:
    AT+CSTT="APN","APN_USER","APN_PASS"
    AT+CIICR
    AT+CIFSR
    AT+CIPSTART="server",port

    Możliwe że gdzieś pomyliłem się w spisywaniu komend do tego postu, ale zapewniam, że wszystkie działają, po każdej oczekiwana i sprawdzana jest odpowiedź.
    Czyli podsumowując: procesor działa, ale moduł SIM900 podłączony do niego fałszywie twierdzi, że jest połączony do serwera.
    Czy ktoś może miał taką sytuację? Jak sobie z nią poradzić? Potrzebuję połączenia stałego i niezawodnego.
  • #2 15473153
    don diego
    Poziom 32  
    Z ciekawości zapytam jakiego operatora karty SIM używasz? Próbowałeś z kartami innych operatorów?
  • #3 15479727
    Marico
    Poziom 20  
    Tak bywa, nie tylko z sim900. Nikt nigdy nie gwarantuje, że połączenie TCP będzie stabilne tak długo jak sobie zażyczysz. W warstwie aplikacyjnej musisz zaimplementować zabezpieczenie periodycznie weryfikujace stan połączenia z serwerem a nie opierać się tylko na zdarzeniach raportowanych przez api tcpip modułu sim900.
  • #4 15480414
    michalko12
    Specjalista - Mikrokontrolery
    mateo767 napisał:
    Czyli podsumowując: procesor działa, ale moduł SIM900 podłączony do niego fałszywie twierdzi, że jest połączony do serwera.
    Czy ktoś może miał taką sytuację? Jak sobie z nią poradzić? Potrzebuję połączenia stałego i niezawodnego.

    Mnie coś takiego się zdarzało i to niezależnie od operatora i sprzętu. Wygląda to tak jakby modem otwierał połączenie nie z serwerem docelowym tylko z jakimś pośrednikiem w sieci GSM, a ten pośrednik otwierał inne połączenie z serwerem docelowym. Te dwa wewnętrzne sockety są jakoś synchronizowane wewnętrznymi mechanizmami GSM i prawdopodobnie zdarza się, że ta synchronizacja zawodzi. Teraz przypuść, że coś takiego istnieje i załóż jakie z tego mogą wynikać problemy.
  • #5 15480549
    don diego
    Poziom 32  
    Pytałem o operatora, bo mi właśnie się podobny problem zdarza dość często z kartami Orange. Testuję też Play i T-Mobile i się to nie zdarzało. U mnie wygląda to tak, że po stronie modułu wszystko wygląda jakby połączenie TCP było poprawnie otwarte, a po stronie serwera nie ma ani jednego pakietu od modułu. Problem występuje na dwóch modelach modułów Sierra Wireless, z którymi aktualnie pracuję.
  • #6 15481147
    mateo767
    Poziom 9  
    don diego napisał:
    Z ciekawości zapytam jakiego operatora karty SIM używasz? Próbowałeś z kartami innych operatorów?

    Ja pracuję na T-Mobile. Karta ze stałym IP.
    don diego napisał:
    Pytałem o operatora, bo mi właśnie się podobny problem zdarza dość często z kartami Orange. Testuję też Play i T-Mobile i się to nie zdarzało.

    Czyli wygląda na to że to nie problem operatora, skoro mi się to zdarza na T-Mobile.
    Marico napisał:
    Nikt nigdy nie gwarantuje, że połączenie TCP będzie stabilne tak długo jak sobie zażyczysz. W warstwie aplikacyjnej musisz zaimplementować zabezpieczenie periodycznie weryfikujace stan połączenia z serwerem a nie opierać się tylko na zdarzeniach raportowanych przez api tcpip modułu sim900.

    Tego się obawiałem.
    Jednak ostatnio usterka zdarzyła się "na moich oczach" i również miałem podłączony podsłuch na UART. Tak jak wcześniej SIM900 nic nie zgłosił.
    ALE: zauważyłem że zmieniło się zachowanie diody SIM900 (NETLIGHT). Z dokumentacji wynikało, że wskazywała ona na szukanie zasięgu sieci, więc SIM900 "zauważa" problem.
    Wprowadziłem jedną modyfikację:
    komendę AT+CREG=0, która blokowała powiadomienia o zmianie stanu rejestracji w sieci, zmieniłem na AT+CREG=1. Okazało się że SIM900 po takim wydarzeniu wysyła komunikat, że status rejestracji sieci jest nieznany. Dodatkowo wprowadziłem mechanizm, który po utracie zasięgu próbuje go odzyskać przez pewien czas a jeśli się to nie uda - resetuje modem. Zrobiłem to w piątek i przez cały weekend urządzenie utrzymało połączenie. Właśnie sprawdziłem kompletność danych na serwerze i jest 100% :-D
    Więc wygląda na to, że SIM900 nie powiadamia o utracie połączenia z serwerem TCP jeżeli straci zasięg sieci GSM. Powiadamia tylko o utracie zasięgu, a nie o tym co się z tym wiąże. Trochę dziwne według mnie.
    Co do samej utraty zasięgu to zastanawiam się czy jest sens się przejmować? Takie utraty chyba się zdarzają nawet telefonom i po prostu trzeba je obsłużyć. Tak myślę...

    Edit:
    W odniesieniu do postu kolegi michalko12:
    michalko12 napisał:
    Mnie coś takiego się zdarzało i to niezależnie od operatora i sprzętu. Wygląda to tak jakby modem otwierał połączenie nie z serwerem docelowym tylko z jakimś pośrednikiem w sieci GSM, a ten pośrednik otwierał inne połączenie z serwerem docelowym. Te dwa wewnętrzne sockety są jakoś synchronizowane wewnętrznymi mechanizmami GSM i prawdopodobnie zdarza się, że ta synchronizacja zawodzi. Teraz przypuść, że coś takiego istnieje i załóż jakie z tego mogą wynikać problemy.

    Z teorii TCP chyba nie może występować takie pośrednictwo. Sieć GPRS jest tylko medium. Protokół TCP nie powinien pozwolić na połączenie z socketem o innych danych niż docelowy. Za to z programowania w JAVA wiem, że istnienie socketu nie musi oznaczać istnienia połączenia. Kiedy nawiązujemy połączenie TCP, tworzymy obiekt socketa, który łączy się z socketem na drugim końcu połączenia i socket ten istnieje niezależnie od stanu połączenia. Ciekawostka jest taka, że metoda Socket.isConnected() zawsze da wartość true jeżeli ten socket był kiedykolwiek podłączony niezależnie czy od tamtego czasu coś nieprzewidzianego nie przerwało połączenia. Myślę że tu jest podobnie. SIM900 nadal widzi połączenie na poziomie socketu, pomimo tego, że zawiodło medium (połączenie GPRS).
  • #7 15481317
    michalko12
    Specjalista - Mikrokontrolery
    mateo767 napisał:
    Z teorii TCP chyba nie może występować takie pośrednictwo. Sieć GPRS jest tylko medium.

    No właśnie to jest tylko teoria.
    mateo767 napisał:
    Protokół TCP nie powinien pozwolić na połączenie z socketem o innych danych niż docelowy.

    Nikt nie wspominał, że dane będą inne.
    mateo767 napisał:
    Za to z programowania w JAVA wiem, że istnienie socketu nie musi oznaczać istnienia połączenia.
    Socket to tylko struktura danych, a połączenie TCP to jest abstrakcja, coś umownego. To nie są endpointy fizycznie połączone kabelkami. Siedzę w modemach już kilka ładnych lat i wiele różnych cudów widziałem. Przykład : jeśli MMS w TCP był ustawiony na 1460 to ostatnie 60 bajtów było wycinane, ale wszystko działało prawidłowo. Jakim cudem skoro według Ciebie GPRS to tylko medium? Ten problem pojawił się z dnia na dzień i występował w PLUSie i jeszcze wtedy w Erze. Na Idei wszystko ładnie działało. Okazało się, że W BTSach zostało wgrane nowe oprogramowanie i wyjściem było na stałe ustawienie MMS na 1400 lub interwencja producenta modemu. I teraz wyobraź sobie zmianę firmware w modemach poinstalowanych na obiektach. Takie problemy są nie tylko od strony modemu. Ten sam problem jest od strony serwera, gdzie jest połączenie z siecią operatora prze internet. Na modemie wszystko ładnie pozamykane a serwer widzi istniejące połączenie i śle dane do socketa. Nie ma żadnej informacji ze strony operatora że jest coś nie tak, pakiety ACK przychodzą i jakim cudem? Potrafisz to wytłumaczyć?
  • #8 15481428
    don diego
    Poziom 32  
    michalko12 napisał:
    ...pakiety ACK przychodzą i jakim cudem?

    A właśnie, nie napisałem, że wysyłam dane po tym niby otwartym socketcie i dostaję ACK. A serwer nic o tym nie wie:) Parafrazując pewną reklamę operatora komórkowego: Takie rzeczy tylko po GSMie :)
  • #9 15481460
    mateo767
    Poziom 9  
    @michalko12, @don diego fakt, jest masa rzeczy, o których nie mam pojęcia. To co nam na studiach mówili (a zdarzyło mi się studiować telekomunikację) to teoria nie zawsze w 100% zaimplementowana choćby w urządzeniach budujących sieć. Faktycznie dostarczanie ACK pomimo zamkniętego jednostronnie połączenia sugeruje jakiegoś pośrednika. Nie podejmę się wytłumaczenia tego. Może za kilka lat ;-)
    W każdym razie ten mój problem rozwiązałem tak jak napisałem:
    uaktywniając i parsując wiadomość o zmianie stanu rejestracji w sieci komórkowej. Więcej problemów w tej chwili nie zauważam więc temat oznaczam jako rozwiązany.
REKLAMA