> Podsumowując: zmierzyć k..wa długość bitu. Jak nie ma czym zmierzyć,
> załatwić sprzęt pomiarowy. Nie zgadywać.

No, k..wa racja :)
Dobra , na razie zapodałem sygnał zegarowy (czyli 16Mhz) podzielone przez
CD4040 :)
I mamy co następuje
http://picasaweb.google.pl/lh/photo/EG1i87i3j8N2Db1A
m2DaNA?feat=directlink

Poszczególne kanały :

1. sygnał RXD
2. sygał TXD (czyli jak się moduł odszczekuje :) - tu akurat nic nie widać
na tym rysunku, ale generalnie są odpowiedzi
3. sygnał Fosc / 64 = 250kHz (czyli okres 4 uS)
4. sygnał Fosc / 128 = 125 Khz (okres 8 uS)
5. sygnał Fosc / 256 = 62500 kHz (okres 16 uS)

Czyli zaznaczony markerem odcinek ma w rzeczywistośco 8 uS a nie - jak
twierdzi program =9.06 uS

Ponadto widać, jak nierówno program próbkuje - zwłaszcza na 3 kanale się
rzuca w oczy. Ale - wychodzi definitywnie, że bity startu są oddalone od
siebie o 64 uS.
No a jeden bit na RXD ma 4 uS - znaczy takie są najkrótsze "bity" na RXD.

Z tego jednak by wynikało, że transmisja chodzi na 250kb czyli maksymalnej
dla tego procesora, dobrze rozumiem ?
Znaczy tak (start + 8 bitów + stop) = 40us + 24 us pauza = 64 us ? To by się
jakby zgadzało, bo z tego wynika że w ciągu przynajmniej 24uS przed bitem
startu nie mają prawa się zadne dane pojawić - i faktycznie tak zasadniczo
jest - chociaż trafiłem na jeden wyjątek, ale może to jakiś błąd w
transmisji.
Myślę, że 8 bitów a nie 9 bo parzystość by musiała byc liczona prgoramowo w
tym PICu (ale nawet jakby to było 9 bitów to w sumie niewielka różnica).

Czy dobrze kombinuję ? No, teraz podstawowa sprawa, to jutro poprawię ten
konwerter tak, żeby miał szansę te 250kbit przejąć i się zobaczy...