między Atmegą a modułem G

W dniu 2012-12-11 23:15, Mirek pisze:

Tak, tylko dlaczego nie robi tego, gdy jest podłączony do komputera przez max3232???

Poza tym z tego co widzę w pewnym momencie wysłał też dwa znaki NULL.

To gadaj z nim przez komputer. Podłącz do jednego com modem a do drugiego atmegę i ... hmm pewnie nie masz linuksa bo cat /dev/ttyUSB0 > /dev/ttyUSB1 i odwrotnie załatwiłby sprawę. I przy okazji podsłuchać można.

5% szans że to jednak załócenia od zasilania i objawiają się właśnie po określonych komendach jak modem "bierze" prąd. FE to długi ciąg jedynek potem 0. Natomiast 00 00 (znak null dwa razy) no to dłuuugi ciąg zer... przy czym mało prawdopodobne żeby został odebrany przypadkowo.

Mirek.

Dnia Wed, 12 Dec 2012 00:05:34 +0100, Mirek napisał(a):

Odwrotnie. Dwa bity zero (start i LSB), a potem jedynki.

Moze byc skutek jakiegos chwilowego zaklocenia ... ale zabraklo koledze 0A po 0D. I tak dziwnie po CPIN ... modemik dostaje pin i probuje sie z siecia skomunikowac ?

J.

Atlantis snipped-for-privacy@wp.pl napisał(a):

Zmierz może w końcu oscyloskopem szerokość bitów, jak Ci już dwie osoby doradziły.

Atlantis snipped-for-privacy@wp.pl napisał(a):

Bo nie mają znaczenia.

A czytasz i ustawiasz bajt kalibracyjny generatora RC dla 8 MHz?

Bez znaczenia. Ja zwykle ustawiam TX na wyjście a RX na wejście, bo jakoś trzeba je ustawić, ale włączony USART ma priorytet nad DDR i sam kontroluje te linie.

Sprawdź jeszcze oscyloskopem zasilanie obu układów (ATmegi i modułu), może okazać się, że masz duże tętnienia (szczególnie na module).

No to tu masz problem. Przerabiałem temat. Użyj zewnętrznego kwarcu i problem (jeżeli to jedyny problem) zniknie.

W dniu 2012-12-12 08:45, Adam Wysocki pisze:

Hmm... Wygląda na to, że masz rację w sposób podwójny:

1) Istotnie po części wina musiała leżeć po stronie wewnętrznego rezonatora RC. Dałem kwarc 8 MHz i sytuacja się nieco poprawiła. To znaczy transmisja zaczęła być trochę stabilniejsza i udało mi się (po raz pierwszy) zainicjować moduł bez pomocy komputera, po wykręcając kod PIN na tarczy numerycznej. Potem też telefon jako tako działał, przy czym nie do końca stabilnie. Udało mi się na niego dodzwonić (pojawiła aktywność linii, które potem będą odpowiadały za sterowanie dzwonkiem). Parę razy też udało mi się wybrać numer. Niestety nie wszystko działa stabilnie np. wybieranie numeru nie zawsze udaje mi się zrealizować (nie wiem jednak, czy to nie jest jakiś bug w kodzie). Nie zawsze też po włączeniu inicjacja przechodzi do końca. Podsłuchałem dane zwracane przez modem i niestety - krzaczki nadal się pojawiają...

2) Sprawdziłem oscyloskopem jak wygląda przebieg na zasilaniu modemu (konkretnie na kondensatorze 1000uF). Na czas próby odpiąłem Atmegę i podłączyłem do stabilizatora jedynie D15. Gdy urządzeni nic nie robi - generalnie jest ładny, płaski przebieg. Problem zaczął się w przypadku wykonywania operacji. Przy wpisywaniu komend linią wyraźnie szarpało. Po wywołaniu numeru innego telefonu kompletnie się rozmyła. Dobierając podstawę czasu "znalazłem" taki oto przebieg, zbliżony do sinusoidy (przepraszam za jakość, zdjęcie zrobione niezbyt nowoczesnym aparatem...)

Tego nie powinno tam być? ;)

W dniu 2012-12-12 00:31, J.F. pisze:

Wtedy to nawet jeszcze do tego nie dochodziło. Modem nie mógł poprosić o PIN, bo nie wiedział co dostaje w odpowiedzi na "AT+CPIN?". Zwracał po prostu "ogólny błąd". Przejście do pobrania PIN-u byłoby możliwe dopiero wtedy, gdyby otrzymał i zrozumiał komunikat "+CPIN: SIM PIN".

Jak już pisałem zastosowanie kwarcu trochę poprawiło sytuację. To znaczy wydaje mi się, że chodzi o kwarc, gdyż jednocześnie dałem też inny egzemplarz Atmegi8. Co parę odpaleń problem jednak powraca...

W dniu 2012-12-12 00:05, Mirek pisze:

Jest jeszcze gorzej... Mój nowoczesny komputer stacjonarny nie ma już ani jednego złącza COM. Netbook rzecz jasna także. Korzystam z poczciwego ThinkPada, z jednym portem. W przejściówki USB dopiero będę musiał się zaopatrzyć. ;)

Tak czy inaczej - usunąć trzeba przyczynę, zamiast leczyć objawowo. Komputera w obudowie telefonu przecież nie zamknę. ;)

Ok, okazało się, że sinusoida była wynikiem nieodpowiedniego filtrowania

- przeoczyłem kondensator 100nF w pobliżu pinów zasilania modułu GSM. Po jego dodaniu całość działa jakby stabilniej, chociaż nie wszystko jest do końca idealnie. Nie każda inicjacja się udaje (nie zawsze pyta o pin) nie zawsze też udaje się zainicjować połączenie - po prostu jakby nie wysyłał AT*Dnumer. nawet na "podsłuchu" w terminalu nie widać, choć inne komunikaty przechodzą. Pomyślałbym, że to błąd w programie, gdyby s samym komputerem nie działało w 100% poprawnie.

W dniu 2012-12-13 20:29, Atlantis pisze:

Może to nie jest kwestia, że komunikacja z komputerem jest poprawna, tylko system pracuje stabilniej gdy masz połączoną masę komputera z masą urządzenia.

W dniu 2012-12-13 21:17, Mario pisze:

Hmm... Kwestia masy też mi przemknęła przez myśl. Tak prawdę mówiąc teraz nie wygląda to zbyt imponująco - ot, płytka uniwersalna i połączenia wykonane kabelkami z goldpinami. Z drugiej strony masę komputera podpinam też do całości, "podsłuchując" komunikację między obiema płytkami. Poprawy wówczas nie dostrzegam. Nie widać jej też wówczas, gdy wtyczka programatora zostanie w gniazdku ISP.

W dniu 2012-12-13 21:34, Atlantis pisze:

To może z innej beczki. Spróbuj podciągnąć linie transmisyjne lekko do plusa. Np rezystorami 10k.

W dniu 2012-12-13 23:53, Mario pisze:

A co to może zmienić? To znaczy jakie jest uzasadnienie takiego posunięcia?

Generalnie kończą mi się pomysły. Dzisiaj poprawiłem jeszcze na wszelki wypadek filtrowanie zasilania przy stabilizatorze. Teraz mam na wejściu kondensatory 470uF+330nF oraz 220uF+100nF. Poprawa niewielka, praktycznie żadna. Dodanie kondensatorka 100nF przy pinach zasilania modułu w jakimś stopniu pomogło - znikła sinusoida widoczna na oscyloskopie, poza tym subiektywnie wydaje mi się, że moduł inicjuje się nieco częściej. Jednak wciąż muszę kilka razy włączać go ponownie, żeby zaskoczył. Zastosowanie kwarcu też nie do końca pomogło.

Problem z "krzaczkiem" generalnie ciągle występuje. Wychodzi na to, że na pierwsze pytanie AT+CPIN? przychodzi najpierw jedna linia z "krzaczkami" (HyperTerminal widzi tam kwadrat i literę K, Programmer's Notepad wyświetla "t" z ogonkiem u dołu, skierowanym w lewo). Dopiero w następnej linii przychodzi właściwa odpowiedź (+CPIN: SIM PIN) ale program zdążył już przeanalizować poprzednią linię.

Niekiedy ten "krzaczek" nie przychodzi - wtedy udaje się bez problemu zainicjować moduł.

Jest też problem z komunikacją w drugą stronę, także w jednym, konkretnym przypadku. Mianowicie często (nawet bardzo często) Atmega nie wysyła modułowi rozkazu wybrania wykręconego numeru. Nie chodzi nawet o to, że występuje jakiś błąd - nawet terminal nie pokazuje niczego (chociaż inne komendy wychodzą). Jest to jakby nie patrzeć dziwne...

Gdyby nie fakt, że osobno działa, pewnie szukałbym źródła problemu w kodzie...

Jeszcze jedna rzecz rzuciła mi się w oczy w dokumentacji modułu, mianowicie:

"For lines with high rate of signals it is recommended to use Transguard with low capacitance. There are Transguard of 3pF or less."

Czy to znaczy, że powinienem dodać między linie RX i TX kondensatorki po kilka pF do masy?

Dnia Fri, 14 Dec 2012 21:39:07 +0100, Atlantis napisał(a):

Nie, transguarda. Czyli ochrone przepieciowa. Ale takiego o malej pojemnosci.

J.