Jak skutecznie rozwiązać problem komunikacji Atmegi z modułem GSM przez RS232?

Wed Dec 12, 2012 9:02 pm   

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ą...

http://www.sendspace.pl/file/baf48b4c0760fb6b7b8c247

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...)

http://imageshack.us/photo/my-images/534/img89221.jpg/

Tego nie powinno tam być?

Wed Dec 12, 2012 9:23 pm   

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...

Wed Dec 12, 2012 9:34 pm   

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ę.

Thu Dec 13, 2012 8:29 pm   

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.

Thu Dec 13, 2012 9:17 pm   

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.

--
pozdrawiam
MD

Thu Dec 13, 2012 9:34 pm   

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.

Thu Dec 13, 2012 11:53 pm   

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.

--
pozdrawiam
MD

Fri Dec 14, 2012 9:12 pm   

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...

Fri Dec 14, 2012 9:39 pm   

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?

Fri Dec 14, 2012 9:56 pm   

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

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

J.

Fri Dec 14, 2012 11:29 pm   

Nie widziałem wątku od początku i może top pytanie już padło: z czego
zasilasz ten moduł?

--
Marek

Fri Dec 14, 2012 11:39 pm   

W dniu 2012-12-14 23:29, Marek pisze:


Głównym źródłem zasilania jest zasilacz CB, dający na wyjściu 13,8V.
Oczywiście za nim dałem 78T05. Na wejściu kondensator 470uF i 330nF, na
wyjściu 220uF i 100nF. Przy pinach zasilania modułu (zgodnie z manualem)
1000uF i 100nF.

Atmega zasilana jest z tego samego stabilizatora (próbowałem już
rozdzielenia zasilania, ale nic to nie zmieniło). Oczywiście przy
kluczowych pinach ma kondensatorki filtrujące.

Co do samego zasilacza, to może ciągle dawać 3A, w porywach do 5A, tak
więc ma odpowiednią wydajność...

Tak mi jeszcze przyszło do głowy... Może to nie jest wcale błąd
transmisji? Może to coś związanego z konfiguracją modułu? Tylko w takim
razie dlaczego problemy nie występowałyby przy pracy z samym komputerem?

Sat Dec 15, 2012 12:16 am   

Jest jeszcze jedna rzecz o której chyba zapomniałem wspomnieć, a która
może być wartą odnotowania.
Mianowicie mam dwa takie moduły i obydwa zachowuję się identycznie.
Zastanawia mnie niezwykła regularność tej anomalii. Przecież gdyby to
były jakieś zakłócenia od niefiltrowanego zasilania albo jakichś
lokalnych pół EM, oddziałujących na urządzenie, to przychodziłyby różne
krzaczki. A tak nie jest. Problem występuje w dwóch konkretnych miejscach...

Nie znam się aż do tego stopnia na specyfice transmisji rs232, więc
chciałbym zapytać czy:
1) Możliwe jest, żeby moduł zachowywał się inaczej w stosunku do Amtegi
niż do PC z odpalonym HyperTerminalem? Na przykład żeby wysyłał jakieś
dodatkowe dane?
2) Możliwe jest, żeby HyperTerminal "ukrywał" pewne rzeczy przy
normalnej komunikacji z modułem, gdy był z nim połączony obiema liniami,
ale już pokazywał je przy "podsłuchiwaniu" linią odbiorczą?
3) Możliwe jest, żeby jednego komunikatu nie dało się wysłać z Atmegi do
modułu (chociaż HyperTerminal go odbierał), a co więcej - żeby
"podsłuchujący" komputer nic nie widział?

Sat Dec 15, 2012 12:52 am   

Dnia Sat, 15 Dec 2012 00:16:00 +0100, Atlantis napisał(a):

Niestety - ale GSM bierze duzo pradu i generuje mocna fale.
Mozliwe.


Dziesiatki roznic moga byc.
Napieciowe dopasowanie jest ? bity parzystosci ? 2 bity stopu ?
Predkosc ta sama ? linie dodatkowe ? sterowanie przeplywem ?


Norma. Jeb*y MS, jeb* windows, jeb* programisci, jeb* projektanci, jeb*
prezesi i uczciwych programow juz nie ma.
Podstawa to terminal z trybem hex ... tylko ktory to ?
Odkurzyc stary komputer z DOS i xtalk ? Tez nie byl idealny.

Wlacz logowanie do pliku ... a i za to nie recze, poza tym ... czym to
potem obejrzec, zeby bylo uczciwie ..


To juz moze mniej...


A to juz mniej ... ale w czym oprogramowane ?
Tylko assembler prawde ci powie .. o ile go dobrze znasz :-)


Skoro nie wysyla, to logiczne ze nie widac
Chyba o jakas inna kombinacje chodzi..

J.

Sat Dec 15, 2012 3:00 am   

W dniu 2012-12-15 00:16, Atlantis pisze:

Hyperterminala zazwyczaj nie używam właśnie z tego powodu. Bywa że nie
pokaże ci niczego jeśli nie masz dokładnie ustawionych parametrów
transmisji. Czyli jak przyjdzie ramka nie pasująca do ilości bitów czy
parzystości to jej może nie pokazać. Użyj Terminal v1.90b by Bray++.

--
pozdrawiam
MD