Elektroda.pl
Elektroda.pl
X
Elektroda.pl
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.
itemscope itemtype="https://schema.org/QAPage"

Atmega8/SIM300CZ - SIM300CZ wysyła SMS, ale informacja jest nieczytelna

Gienek 22 Sie 2014 23:15 1566 6
  • Atmega8/SIM300CZ - SIM300CZ wysyła SMS, ale informacja jest nieczytelna

    #1
    Poziom 35  

    Walczę z tym problemem i nie mogę znaleźć rozwiązania.
    W czym rzecz? Modem SIM300CZ podłączony jest do ATMEGA8.
    Korzystam z tego schematu:
    Atmega8/SIM300CZ - SIM300CZ wysyła SMS, ale informacja jest nieczytelna
    Kod programu:

    Kod: basic4gl
    Zaloguj się, aby zobaczyć kod


    Modem pracuje w trybie tekstowym. Procesor wysyła komendę:
    Cytat:

    AT+CMGS="+48xxxxxxxxx"
    Temperature High: 126 deg


    Modem odpowiada:
    Cytat:

    >
    +CMGS: 41
    OK


    Faktycznie, SMS został wysłany na wskazany numer telefonu, ale tekst to chińszczyzna (dosłownie - treść SMSa odebrałem w telefonie zapisaną chińskimi znakami).

    Może ktoś miał taki przypadek?
    Dlaczego tak się dzieje?

    Za każdą sugestię będę bardzo wdzięczny.

    0 6
  • #2
    Specjalista - Mikrokontrolery

    Być może chodzi o brak polecenia
    AT+CMGF=1

    0
  • #3
    Poziom 35  

    Ta komenda jest zapisana w programie w części inicjalizacji modemu.

    Dodatkowo sprawdziłem "tą chińszczyznę" na innym (nie na androidzie) telefonie.
    Zamiast znaków chińskich są same kropki.

    Program jest wykonywany przez procesor, zapisywany jest numer telefonu po podaniu hasła, reaguje na zaistniałe zdarzenia (włączenie kontaktronu 1 lub 2, włączenie czujnika ruchu, zmiany temperatury) wysyłką SMS na zapisany numer.
    Jedyny problem, że na telefonie z androidem są chińskie znaczki, a na innym telefonie (8 letnim) wyświetla kropki lub maleńki kwadraciki (prawie kropki).

    Być może, że moduł nie przełącza się w tryb tekstowy (chociaż odpowiada "OK"), ale tego nie mam możliwości sprawdzenia.

    0
  • #4
    Poziom 35  

    Sensownie byloby sprawdzić jakimś analizatorem fizyczny ruch po UARTcie w momencie wysyłki rozkazu. Dawno juz nie dotykalem tego badziewnego modemu, ale coś mi chodzi po glowie (i nie jest to wesz ;) ) ze szopki z SMSami dzieją się wtedy, jak wyślesz treść SMSa zanim przyjdzie prompt. Ty nigdzie nie czekasz na otrzymanie faktycznego prompta...

    EDIT
    Sprawdzilem w jakims swoim bardzo starym kodzie jak ja wysylalem tego SMSa. Nie ma zadnego prompta, tylko:

    AT+CMGS="xxxxxxxxx"[0x0d]trescsmsa[0x1a][0x0d]

    gdzie xxx to nr telefonu. Na ten rozkaz powinien wrocic prosty OK.

    Ale twoj kod to kolejny przyklad jak nie powinno się gadać z modemem. Korzystanie z bascoma nie zwalnia z koniecznosci interpretacji tego, co zwraca modem. To juz bylo...

    0
  • #5
    Poziom 35  

    Dzięki za odzew i podpowiedzi.
    Z analizatorem to u mnie kiepsko, nic nie mam pod ręką.
    Modem, jak modem. Taki "znalazłem" w swoich zasobach i dlatego chciałem go wykorzystać (wydaje się do prostej funkcji), ale okazało się, że to wcale nie takie proste.
    Zrobiłem model urządzenia w PROTEUSIE i uruchomiłem symulację.
    Komendy procesor wszystkie wysyła poprawnie, modem też odpowiada poprawnie na wszystkie komendy, wysyła SMSa, ale też jest nieczytelny.
    Nie mogę "odgadnąć" co się kryje pod tymi znakami przesłanych w SMSach.
    Jak powinien wysłać "Number Stored" to mam 7 znaków, a jak powinien wysłać "Temperature High: 85 deg" to mam 12 znaków. Widać, że coś tam się dzieje, są jakieś zmiany, ale dlaczego "tak szyfruje"?

    Skorzystałem z Twojej podpowiedzi i wysyłałem SMSa według Twojego kodu. Nic to nie zmieniło (za wyjątkiem tego, że procesor wystawił numer telefonu i tekst SMSa w jednej linii), SMSa dalej nie można odczytać.

    Krytykę "przełknąłem", ale to nie do końca tak jest.

    Edit.
    Na dzisiaj jedną "zagadkę" rozwiązałem (że wcześniej na to nie wpadłem).
    Modemowi "nie podoba się" karta PLAY, akceptuje ORANGE.
    Po wymianie kart SMSy przesyłane są poprawnie i są czytelne.

    Pytanie: dlaczego karta PLAY nie jest akceptowana przez modem?

    0
  • #6
    Poziom 35  

    Aaa no tak... a dlaczego play miałby byc akceptowany przez ~15letni grat? ;] A tak na powaznie, modem moze miec problemy z obsluga MVNO.
    Obstawiam jednak, ze w play wersja systemu obslugujacego SMS jest po prostu nowsza - nieobslugiwana - przez stary modem. Hipotezę tą mozna obadac w ciagu kilku godzin zapoznając się głębiej z specyfikacją działania SMS...

    0
  • #7
    Poziom 35  

    Im dalej w las, tym więcej grzybów.
    "Trenuję" nowy problem.
    W kodzie, po ustawieniu Jumper=0 program czeka na SMS z hasłem. Jeżeli otrzyma poprawne, to zapisuje do pamięci numer telefonu, z którego był wysłany SMS i przechodzi do pętli głównej, a zatem alarm jest uzbrojony - reaguje na czujniki zewnętrzne. W programie brak jest możliwości wyłączenia urządzenia bez wywołania alarmu (wysyłane są SMSy na telefon sterujący).
    Dobrym rozwiązaniem by było, aby można było aktywować alarm przez sygnał telefonu: pierwszy telefon - aktywuje alarm, drugi telefon - dezaktywuje.
    Mam taki oddzielny program, który przy pierwszym dzwonieniu identyfikuje numer telefonu i jeżeli zgodny jest ze wzorcem, to np. zapala diodę, a drugi telefon - wyłącza diodę.
    Poprzez adaptację tego programu osiągnąłem to, że wyżej przedstawiony program, po otrzymaniu SMS z hasłem i zapisaniu numeru telefonu czeka na sygnał telefonu.
    Dzwoniąc, aktywuję alarm ( poprzez "Gosub Program1") i na tym koniec, nie mogę dezaktywować alarmu. Nie wiem jak zbudować warunek, aby przy kolejnym telefonie powrócić do drugiego programu.

    Kod drugiego programu:

    Kod: basic4gl
    Zaloguj się, aby zobaczyć kod


    Może ktoś, bardziej doświadczony w Bascomie, naprowadzi na jakieś rozwiązanie?

    0