Elektroda.pl
Elektroda.pl
X
Arrow Multisolution Day
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Modem GSM ZME3006 - milknie/resetuje się

Lukasz.Kaplonski 11 Cze 2011 13:16 1844 15
  • #1 11 Cze 2011 13:16
    Lukasz.Kaplonski
    Poziom 9  

    Witam.
    Mam problem z modem z Maritexu a konkretnie z ZME3006. Podłączyłem go do ATMEGI16L według poniższego schematu.
    Modem GSM ZME3006 - milknie/resetuje się

    Zasilanie jest zrealizowane następująco :
    Modem GSM ZME3006 - milknie/resetuje się

    Generalnie na początku chciałbym żeby po włączeniu modem odpowiedział po UART

    Code:

    <CR><LF>+CFUN: 1<CR><LF>
    <CR><LF>+CPIN: READY<CR><LF>


    Bo z tego co wiem takie jest jego domyślne działanie. Niestety w moim przypadku gdy załączam moduł dostaję tylko 1 komunikat (tj, CFUN: 1..), a właściwie półtora ponieważ dokładnie to otrzymuje

    Code:

    <CR><LF>+   // << Wygląda mi to jakby modem resetował się w trakcie wysyłania wiadomości.
    <CR><LF>+CFUN: 1<CR><LF>


    Po czym modem milknie i nie reaguje na nic. Takie działanie jest podczas normalnego włączania go według sekwencji z dokumentacji tj.
    Modem GSM ZME3006 - milknie/resetuje się

    za pomocą poniższego kodu :

    Kod: c
    Zaloguj się, aby zobaczyć kod


    Jeżeli natomiast zakomentuje załączanie GSM_ON czyli linie zaznaczoną w powyższym listingu to otrzymuje obydwa komunikaty tak jak być powinno ale pojawiają się one cyklicznie non stop. Tj układ wysyła te komunikaty, resetuje się, i ponownie wysyła i tak wkoło.

    Co próbowałem :
    - dodałem na linii zasilania kondensatory jeszcze 2 razy 200uF tantalowe
    - testowałem na 2 kartach sim , jedna PLAY i jedna PLUS
    - zmieniałem czasy odpowiednich delayów

    Przyznam, że nie bardzo mam już pomysł co może być przyczyną takiego zachowania. Wiem, że układy te są bardzo wrażliwe na zasilanie dlatego od stabilizatora idzie do nich bezpośrednio przewód (obecnie zmontowane jest to na płytce stykowej/prototypowej). Ale wątpię, żeby zasilanie było problemem. Tam jest 300uF w elektrolicie i łącznie 700uF w tantalach.

    Byłbym wdzięczny za pomoc w tej kwestii.

    0 15
  • Arrow Multisolution Day
  • #2 11 Cze 2011 19:53
    Jaca
    Poziom 28  

    Zasilasz go z 3.3V ? Wg dokumentacji 3.3V to minimalne napięcie przy jakim moduł działa. Pamiętaj również, że podczas nadawania ten moduł będzie ciągnął do 2.5A w impulsie...

    0
  • #3 11 Cze 2011 20:01
    nsvinc
    Poziom 35  

    Układ ogólnie nie ma prawa - i nie będzie - chodzić z takiego zasilania jak zaprojektowałeś. Modem będzie działał przy 3.3V, tyle, że wydajność tego zasilacza na 3.3v musi być spora.

    Modem resetuje ci się z powodu nieciągłości w dostawach energii elektrycznej. Objawy są wtedy dokładnie takie jak opisujesz. Albo montujesz baterię kondensatorów (w sumie z 10mF by sie przydalo) bezposrednio do pinów zasilania modemu, albo zmieniasz cały obwód zasilania, w tym użyjesz stabilizatora liniowego lub przetwornicy która ma albo nominalnie 3A albo dopuszcza się jej przeciążanie do 3A...

    0
  • Arrow Multisolution Day
  • #4 11 Cze 2011 20:30
    Lukasz.Kaplonski
    Poziom 9  

    Brałem pod uwagę że skoro zakres zasilania podawany w nocie katalogowej jest 3.3V-4.25V to te 3,3V powinno starczyć.

    Hmmm skoro uważacie że to może być zanik zasilania (pomimo kondensatorów które zamontowałem) to w poniedziałek domontuje jakieś spore niskoimpedancyjne elektrolity.

    Zastanawia mnie jeszcze jedna sprawa piszesz :

    Cytat:
    Układ ogólnie nie ma prawa - i nie będzie - chodzić z takiego zasilania jak zaprojektowałeś.


    Co konkretnie w torze zasilania dobrałem niepoprawnie? Przy wyborze stabilizatora starałem się żeby jego wydajność prądowa była wystarczająca. Według dokumentacji dla zastosowanego elementu (Output Current 3A) więc wydaje mi się że powinien wydolić. Hmm czy nie wziąłem czegoś pod uwagę?

    0
  • #5 11 Cze 2011 20:44
    Jaca
    Poziom 28  

    Zauważ, że podczas nadawania, napięcie zasilające może "przyklęknąć" poniżej progu działania modułu. Jeśli teraz masz resety (bez logowania do sieci/nadawania) to co będzie się działo później. Zasil moduł z akumulatora Li-Ion 3.6V + układ ładowania. Nie zapomnij o GRUBYCH ścieżkach zasilających moduł odpowiednio prowadzonych, odpowiedniej impedancji masy, zestawach kondensatorów ceramicznych 33p/100n/tantal na linii zasilającej...

    0
  • #6 11 Cze 2011 21:38
    Lukasz.Kaplonski
    Poziom 9  

    Dziękuje za odpowiedź , a odnośnie tego co napisze teraz chciałbym wyjaśnić z góry że moim celem nie jest kłócenie się lecz poznanie przyczyny zaistniałego zjawiska (żebym nie został źle zrozumiany).

    Otóż piszesz:

    Cytat:
    Zauważ, że podczas nadawania, napięcie zasilające może "przyklęknąć" poniżej progu działania modułu.


    Jak rozumiem , owa odchyłka napięcia zasilania miałaby brać się z wzmożonego poboru prądu podczas nadawania. Tylko jak ta teoria ma się do wykresu przedstawionego w nocie katalogowej stabilizatora (poniżej)

    Modem GSM ZME3006 - milknie/resetuje się

    Jeżeli dobrze go interpretuje to przy piku w poborze prądu do 3A (moduł ma pobierać około 2,5A więc mamy tutaj zapas) na 50us musimy liczyć się ze spadkiem napięcia około 0,1-0,2V. Teraz pytanie brzmi czy 700uF + 300uF nie są naprawdę wstanie utrzymać różnicy 0,2V przez 50us? Jest to możliwe? Jeżeli zaś nie to jest przyczyną to co może być przyczyną owego spadku napięcia zasilania?

    Zaś co się tyczy zasilania modułu z akumulatora to wolałbym uniknąć tego rozwiązania, układ w którym będzie moduł pracował ma mieć zasilanie sieciowe + awaryjne akumulatorowe. Zasilanie modułu z osobnego akumulatora bądź z akumulatora awaryjnego przyznam szczerze wydaje mi się dziwnym rozwiązaniem. Po za tym nasuwa się pytanie jakie korzyści idą z zastosowania zasilania akumulatorowego nad sieciowym? Przecież akumulatory też mają jakąś wydajność prądową maksymalną.

    0
  • #7 11 Cze 2011 21:54
    Jaca
    Poziom 28  

    Zrób test: podnieś napięcie zasilające na 3.6V i wtedy sprawdź transmisję z modułem. Jeśli nie jest zalogowany do sieci (przed wpisaniem PINu) to starczy mu z 15mA. Balansowanie na krawędzi napięcia minimalnego nie jest dobrym rozwiązaniem, uwierz mi. :)

    0
  • #8 12 Cze 2011 11:55
    Tuxlab
    Poziom 12  

    Modem resetuje się dlatego, że dochodzą do niego jakieś głupie rozakazy. Jest to typowe zabezpieczenie softwerowe programu firmowego. Zasilanie jest OK.

    pozdrowienia
    T

    0
  • #9 12 Cze 2011 14:13
    Jaca
    Poziom 28  

    Tuxlab napisał:
    Modem resetuje się dlatego, że dochodzą do niego jakieś głupie rozakazy. Jest to typowe zabezpieczenie softwerowe programu firmowego. Zasilanie jest OK.

    pozdrowienia
    T


    Bardzo ciekawe i wielce pomocne zabezpieczenie. :) Czy nie lepiej byłoby modułowi wysłać zwrotne ERROR ?

    0
  • #10 12 Cze 2011 14:56
    Lukasz.Kaplonski
    Poziom 9  

    Cytat:
    Modem resetuje się dlatego, że dochodzą do niego jakieś głupie rozakazy


    Tylko problem polega na tym że ja do niego nic nie wysyłam, w programie tylko i wyłącznie nasłuchuje.

    Ale żeby zweryfikować twoją hipotezę zwarłem wyprowadzenie RXD modemu poprzez rezystor do V_MSM. Nie przyniosło to jednak żadnej poprawy choć powinno gdyby zachowanie było winą błędnych transmisji.

    0
  • #11 12 Cze 2011 15:17
    Tuxlab
    Poziom 12  

    Pozornie nic do modemu nie idzie, ale wystarczy, że RX przez jakiś czas (zbyt długi) będzie w stanie aktywnym np. niskim co modem odbiera jako przychodzące bity. Modem interpretuje to jako właśnie głupie rozkazy. Proszę sprwdzić przerwania !

    pozdrowienia
    T

    0
  • #12 12 Cze 2011 17:45
    Lukasz.Kaplonski
    Poziom 9  

    Chwileczkę , czegoś tutaj nie rozumiem. Tak jak napisałem podpiąłem wejście odbiorcze UART modemu (RXD) przez rezystor do stanu wysokiego. Z tego co wiem w transmisji UART start rozpoczyna się poprzez podanie stanu niskiego. Czyli , jeżeli przez cały czas jest tam podpięty stan wysoki to modem dosłownie nie ma prawa odbierać żadnych głupich rozkazów ponieważ żadna transmisja nie jest rozpoczynana. Czy może się mylę?

    Dalej. W kwestii objaśnienia to transmisje z UART mam zrobioną nie na przerwaniach a poprostu przez ciągłe sprawdzanie w czasie oczekiwania transmisje odpowiednich bitów w pętli głównej programu.

    Mniej więcej następująco

    Kod: c
    Zaloguj się, aby zobaczyć kod


    W związku z powyższym nie bardzo wiem o których przerwaniach mówisz.

    0
  • #13 12 Cze 2011 20:09
    Tuxlab
    Poziom 12  

    Kompilator języka wysokiego poziomu obsługuje UART po swojemu i nie zawsze wiadomo jak, bo jedno słowo przykładowo w C to kilkadziesiąt rozkazów kodzie i tak naprawdę nie wiadomo jak wykonuje się obsługa UARTa. Należało by napisać ten kawałek procedury w kodzie.
    pozdrowienia

    T

    0
  • Pomocny post
    #14 12 Cze 2011 23:17
    Jaca
    Poziom 28  

    Tuxlab napisał:
    Kompilator języka wysokiego poziomu obsługuje UART po swojemu i nie zawsze wiadomo jak, bo jedno słowo przykładowo w C to kilkadziesiąt rozkazów kodzie i tak naprawdę nie wiadomo jak wykonuje się obsługa UARTa. Należało by napisać ten kawałek procedury w kodzie.
    pozdrowienia

    T


    Proszę, nie szukaj problemów gdzie ich nie ma. Raptem w tym przypadku kompilator uzyskał świadomość i celowo "namieszał" by zrobić na złość autorowi tematu. :) Może jeszcze mgłę wytworzył. Boki zrywać ! :)

    ps. Przepraszam za OT...

    0
  • #15 13 Cze 2011 21:12
    Marek_Gorecki
    Poziom 16  

    A nie winne są czasem te bazgroły układowe?
    Po co dajesz kondensatory na liniach RS232?
    O co chodzi z tymi tranzystarami ? Co poeta ma na myśli?
    Czy to jest klucz? Jeśli tak to wcale się nie dziwię że to zawodzi.

    0
  • #16 03 Lip 2011 09:37
    Lukasz.Kaplonski
    Poziom 9  

    W powyższym schemacie błędów było kilka.

    1. Dodanie 2*1mF w pobliżu modemu znacznie poprawiło jego prace (resetował się tylko sporadycznie).

    2. Konieczne było podniesienie napięcia zasilania, ja podniosłem o 0,6 V (dioda na stabilizatorze) i modem przestał się resetować w ogóle.

    3. Z konwerterami transmisja w ogóle nie działała. Wiem że innym ponoć działa, mi nie działała. Obecnie mam tylko rezystory ograniczające w szereg wpięte pomiędzy MCU a modem.

    4. Konieczne było zastosowanie kwarcu o częstotliwości umożliwiającej obniżenie BER. Czyli wewnętrzny z AVR odpadał.

    5. Kluczowym okazało się dodanie opóźnienia około 10s po załączeniu modemu. Dopiero po tym czasie transmisja działała poprawnie.

    To chyba tyle z zmian które wprowadzałem.

    Pozdrawiam i dziękuje za pomoc.

    0