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

--
Marek

do góry

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

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

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?

do góry

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ł?

do góry

Dnia Sat, 15 Dec 2012 00:16:00 +0100, Atlantis napisał(a):
> 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...

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

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

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

> 2) Możliwe jest, żeby HyperTerminal "ukrywał" pewne rzeczy przy

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

> normalnej komunikacji z modułem, gdy był z nim połączony obiema liniami,
> ale już pokazywał je przy "podsłuchiwaniu" linią odbiorczą?

To juz moze mniej...

> 3) Możliwe jest, żeby jednego komunikatu nie dało się wysłać z Atmegi do

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

> modułu (chociaż HyperTerminal go odbierał), a co więcej - żeby
> "podsłuchujący" komputer nic nie widział?

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

J.

do góry

W dniu 2012-12-15 00:16, Atlantis pisze:
> 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,

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

do góry

Hyperterminal to chyba najgorszy program jaki mogłeś użyć.
Spróbuj programu Tera Term (działa na XP i 7),
albo też Realterm.

pytający

do góry

On Fri, 14 Dec 2012 23:39:34 +0100, Atlantis <m...@w...pl>
wrote:
> Oczywiście za nim dałem 78T05. Na wejściu kondensator 470uF i
330nF, na

Rozumiem ze to moduł 5V? Możesz mi podać jego model?
W dalszej części przez ze nie ma problemu przy komunikacji z
komputerem a później masz wątpliwisci co do działania hyperterminala.
W jaki sposób atmega (opisz procedurę odbioru znaku) komunikuje sie z
modulem? Czy nie występuje sytuacja w ktorej atmega wysyla do modulu
komendy at, gdy moduł nie jest gotowy na ich otrzymywanie (nie
czekasz na wszystkie znaki z poprzedniego komunikatu z modulu lub
znaku gotowosci). Najczestsza przyczyną problemow to za szybkie
wysyłanie komend nie czekając na poprawne zakończenie poprzednich
(transmisja kolejnego polecenia w trakcie odbierania wyników z
poprzedniego). Np. na sam początek wysylasz at&f i atmega czeka tylko
na OK i wysyła kolejne polecenie, a trzeba czekać na OK\r\n dopiero
po ostatnim \n z odpowiedzi może transmitowac kolejne polecenie.
Kiedyś miałem podobny problem ze moduł dziwnie się zachowywał z mcu a
w terminalu było prawidłowo. Był błąd w kodzie programu, mcu wysyłał
kolejne polecenie w trakcie transmisji ostatniego \n z odpowiedzi
poprzedniego polecenia i moduł albo się "przytykal" albo wysylal
krzaczek.
Na pc w terminalu problemów nie będzie bo wklepujac polecenia
przerwy między poleceniami sa naturalne i wtedy wszystko działa.

--
Marek

do góry

W dniu 2012-12-15 09:12, Marek pisze:

> Rozumiem ze to moduł 5V? Możesz mi podać jego model?

Wydawało mi się, że już wcześniej wspominałem. Moduł to Motorola D15.
Może pracować z napięciem zasilania od 3V do 6V.
Niezależnie od tego stan wysoki na liniach rs232 wynosi 5V. W tej chwili
się tym szczególnie nie martwię, bo Atmega zasilana jest ze
stabilizatora 5V, ale faktycznie ta kwestia chodzi mi po głowie, bo
docelowo układ ma być zasilany z akumulatorka 3,6V.

Będę wtedy chyba potrzebował jakiegoś level shiftera?

Manual podaje następującą informację.

The signal thresholds are:
Vih 2.0V min.
Vil 0.8V max.
Voh 4.4V min. @ 50uA or 3.8V min. @ 8mA.
Vol 0.1 max. @ 50uA or 0.44V @ 8mA.


> W dalszej części przez ze nie ma problemu przy komunikacji z komputerem
> a później masz wątpliwisci co do działania hyperterminala.

Po prostu starałem się doszukiwać przyczyn tam, gdzie tylko się dało.
Program pisałem w oparciu o wskazania HT, więc zacząłem nawet
podejrzewać, że to on coś ukrywał i mogłem tego nie uwzględnić w kodzie.
Wychodzi jednak na to, że przyczyna była zgoła inna...


> odpowiedzi może transmitowac kolejne polecenie. Kiedyś miałem podobny
> problem ze moduł dziwnie się zachowywał z mcu a w terminalu było
> prawidłowo. Był błąd w kodzie programu, mcu wysyłał kolejne polecenie w
> trakcie transmisji ostatniego \n z odpowiedzi poprzedniego polecenia i
> moduł albo się "przytykal" albo wysylal krzaczek.

No i to chyba będzie to... Dopiero wróciłem z pracy i nie miałem czasu
na eksperymenty, ale to najbardziej prawdopodobne wytłumaczenie. Po
prostu nie wiedziałem o tej własności modułu - sądziłem, że komunikaty
się kolejkują i wymiana informacji w obydwie strony odbywa się
niezależenie. Faktycznie dotychczasowy kod ma opisaną przez Ciebie cechę.

Krótko rzecz ujmując używam dwóch tablic: rx_buffer[] i last_line[]. Do
pierwszej napływają wszystkie znaki z modułu GSM, za wyjątkiem \n, które
są pomijane. Wystąpienie \r powoduje przepisanie wszystkich
poprzedzających go znaków z bufora do last_line[]. Pierwszy element
tablicy last_line[] pełni też funkcję flagi informującej o przyjęciu
odpowiedzi (kopiowanie odbywa się w przerwaniu, więc z punktu widzenia
reszty programu całość przybywa za jednym razem).

Jednak zgodnie z tym co piszesz po wystąpieniu \r moduł odbierał jeszcze
\n (tyle tylko, że go nigdzie nie zapisywał). Co więcej - w niektórych
przypadkach potem leciała jeszcze pusta linie (\r\n). A tymczasem flaga
była już postawiona i zaczynało się nadawanie kolejnej komendy...

Teraz zrobię to inaczej. Wystąpienie \n będzie inicjowało kopiowanie
danych z bufora do last_line[], aż do wystąpienia znaku \r. Wyjątkiem
będzie sytuacja, kiedy \r znajdzie się w pierwszym polu bufora - wtedy
zostanie on po prostu wyczyszczony (ignorowanie pustych linii).
Dodatkowo, przed nadaniem każdej komendy zastosuję opóźnienie.

BTW jeszcze pytanie natury formalnej. Jak inteligentny jest kompilator w
zakresie makrodefinicji zastępujących wartości liczbowe? Jeśli np. dam:

#define WARTOSC 31

a potem w programie dam:

if (zmienna < (WARTOSC-1))

To w którym momencie zostanie obliczona wartość? Podczas kompilacji, czy
też za każdym razem uC będzie sobie musiał odejmować jedynkę? ;)

do góry

Atlantis <m...@w...pl> wrote:

>> To może z innej beczki. Spróbuj podciągnąć linie transmisyjne lekko do
>> plusa. Np rezystorami 10k.
>
> A co to może zmienić? To znaczy jakie jest uzasadnienie takiego posunięcia?

Jakie masz wyjście z module? Bo może to jest OC z jakimś słabym pullupem
i pojemności pasożytnicze nie przeładowują się wystarczająco szybko?

Sprawdzałeś kształt obu zboczy na wyjściu z modułu oraz z AVR-a?

Tak mi jeszcze przyszło do głowy - jakie masz opóźnienie między kolejnymi
znakami, wysyłanymi do modułu?

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

Może odsyła coś ze złym baudrate? A może to fałszywa transmisja, wynikająca
z tego, że moduł się włącza, resetuje, inicjalizuje i na chwilę zmienia stan
linii? Oglądałeś ten krzaczek na oscyloskopie?

W takich przypadkach (diagnozowanie problemów komunikacji) oscyloskop jest
podstawowym narzędziem... gdzieś coś jest źle, oscyloskop pomoże Ci zobaczyć,
gdzie.

Kiedy ten krzaczek w ogóle przychodzi? Gdy coś wyślesz? Czy może wcześniej,
przy starcie modułu, ale odczytujesz go dopiero wtedy, gdy coś wyślesz?

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

Generalnie z RS-em jest tak, że warto opróżnić bufor odbiorczy przed pierwszą
komunikacją. Diabli wiedzą, co się tam dzieje przy włączaniu modułu.

--
Gof
http://www.chmurka.net/

do góry

Atlantis <m...@w...pl> wrote:

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

Zasilacz tak (i to o rzędy wielkości - to że moduł pobiera ampery w peakach
nie znaczy, że średni pobór prądu też taki jest) - ale jak widzieliśmy
(oscylacje na zasilaniu) reszta układu zasilania (stabilizator, pojemności,
a nawet przewody) ma kiepską odpowiedź na nagły impuls prądowy. Właśnie po
to są te małe kondensatory. W układach cyfrowych i modułach GSM (i innych
zastosowaniach, gdzie są nagłe zmiany poboru prądu) to ma kluczowe znaczenie.

Ale jeżeli sprawdziłeś zasilanie przy module i te oscylacje zniknęły, masz
pewność, że zasilanie (przy module! to ważne) jest stabilne, gdy moduł
komunikuje się z siecią (wtedy są peaki poboru prądu), to zasilanie mamy
załatwione.

--
Gof
http://www.chmurka.net/

do góry