On 12.11.2013 12:09, Piotr Gałka wrote:

> Kolejne bity są próbkowane w coraz błędniej dobranym środku bitu.

Ale w którym miejscu jest synchronizacja*? Przy każdym bicie startu, czy
przy pierwszym w "paczce" ?
Bo jeżeli na początku paczki to moje błędy też podpadają: kilka
początkowych bajtów jest zawsze w porządku, później bywają zjedzone, ale
najczęściej już ich po prostu nie ma do końca transmisji. Następna
przychodzi przeważnie poprawna. Nie dostałem też ani jednego błędnego
bajtu - kontrola parzystości działa.

* no dobra z tym każdym zboczem to chyba moje pobożne życzenia.

--
Mirek.

do góry

Użytkownik "Mirek" <i...@z...adres> napisał w wiadomości
news:l5tdk9$ju0$1@node1.news.atman.pl...
> On 12.11.2013 12:09, Piotr Gałka wrote:
>
>> Kolejne bity są próbkowane w coraz błędniej dobranym środku bitu.
>
> Ale w którym miejscu jest synchronizacja*? Przy każdym bicie startu, czy
> przy pierwszym w "paczce" ?

Standardem jest synchronizacja na pierwszym zboczu każdego bitu startu.
Nadajnik może nadawać z dwoma bitami stopu, a odbiornik może być ustawiony
na jeden bit stopu i też zadziała.
Gdyby synchronizacja była na paczkę to:
- tak by nie działało,
- tolerancja na odchyłki częstotliwości byłaby jeszcze mniejsza niż jest.
Czy są rozwiązania niestandardowe - nie mam pojęcia.

> Bo jeżeli na początku paczki to moje błędy też podpadają: kilka
> początkowych bajtów jest zawsze w porządku, później bywają zjedzone, ale
> najczęściej już ich po prostu nie ma do końca transmisji. Następna
> przychodzi przeważnie poprawna. Nie dostałem też ani jednego błędnego
> bajtu - kontrola parzystości działa.

A może nadajnik urywa transmisję.
P.G.

do góry

W dniu 2013-11-12 12:09, Piotr Gałka pisze:
>
> Użytkownik "Dariusz Dorochowicz" <_...@w...com> napisał w wiadomości
> news:l5lt1n$sl8$1@node2.news.atman.pl...
>>>
>>> Uzyc cztery czy dwa bity w bajcie i tez bedzie lepiej :-)
>>
>> Kwestia bitów startu, stopu... Tu chyba byłby problem tak czy siak.
>
> Nie widzę powodów do problemu.
> Kolejne bity są próbkowane w coraz błędniej dobranym środku bitu.
> Jeśli tylko 4 byłyby ważne to dopuszczalne rozsynchronizowanie będzie 2
> razy większe niż przy wykorzystaniu 8 bitów.
> Pozostałe 4 na jedynkę i między nadawaniem kolejnych bajtów można
> jeszcze odczekać chwilę na wypadek, gdy to my nadajemy za szybko.

No tak, tak jest OK. Myślałem o podwójnych bitach: aabbccdd, a nie o
abcd1111. Podoba mi się, tylko trzeba dać dłuższy bit stopu niż jest
faktycznie (chyba właśnie jedynki na końcu) - będzie dobrze.

Pozdrawiam

DD

do góry

Piotr Gałka <p...@c...pl> wrote:
>
> Użytkownik "Mirek" <i...@z...adres> napisał w wiadomości
> news:l5tdk9$ju0$1@node1.news.atman.pl...
>> On 12.11.2013 12:09, Piotr Gałka wrote:
>>
>>> Kolejne bity są próbkowane w coraz błędniej dobranym środku bitu.
>>
>> Ale w którym miejscu jest synchronizacja*? Przy każdym bicie startu, czy
>> przy pierwszym w "paczce" ?
>
> Standardem jest synchronizacja na pierwszym zboczu każdego bitu startu.

Chyba ubogim standardem. Sam miałem problem kiedyś z taką dziwną parą:
- odbiorca synchronizował na zboczu
- nadawca przed zboczem bitu startu czasami wysyłał szpilkę
i było wesoło :(

Prawidłowe implementacje nadpróbkowują np 16x i decyzja op poziomie sygnału
zapada na podstawie wartości większości z tych 16-tu próbek.

do góry

Użytkownik "Mirosław Kwaśniak" <m...@u...ikem.pwr.wroc.pl> napisał w
wiadomości news:l5tnoe$4fl$1@dont-email.me...
>>
>> Standardem jest synchronizacja na pierwszym zboczu każdego bitu startu.
>
> Chyba ubogim standardem. Sam miałem problem kiedyś z taką dziwną parą:
> - odbiorca synchronizował na zboczu
> - nadawca przed zboczem bitu startu czasami wysyłał szpilkę
> i było wesoło :(
>
To nie wina standardu tylko nadajnika niezgodnego ze standardem.

> Prawidłowe implementacje nadpróbkowują np 16x i decyzja op poziomie
> sygnału
> zapada na podstawie wartości większości z tych 16-tu próbek.

Gdy standard powstawał, takie rozwiązanie było chyba ekonomicznie
nieuzasadnione.
P.G.

do góry

Hello Mirosław,

Tuesday, November 12, 2013, 6:15:58 PM, you wrote:

>>>> Kolejne bity są próbkowane w coraz błędniej dobranym środku bitu.
>>> Ale w którym miejscu jest synchronizacja*? Przy każdym bicie startu, czy
>>> przy pierwszym w "paczce" ?
>> Standardem jest synchronizacja na pierwszym zboczu każdego bitu startu.
> Chyba ubogim standardem. Sam miałem problem kiedyś z taką dziwną parą:
> - odbiorca synchronizował na zboczu
> - nadawca przed zboczem bitu startu czasami wysyłał szpilkę
> i było wesoło :(
> Prawidłowe implementacje nadpróbkowują np 16x i decyzja op poziomie sygnału
> zapada na podstawie wartości większości z tych 16-tu próbek.

Prawidłowe implementacje próbkują raz po czasie połowy bitu, czy to
faktycznie był bit startu.

--
Best regards,
RoMan
Nowa strona: http://www.elektronika.squadack.com (w budowie!)

do góry

> Dyskusja zmierza w kierunku rozwiązywania problemów nieistniejących w
> innych systemach :-) - pytanie do autora czemu konieczne użył
> uart"a zamiast np. spi?

SPI używam do czego innego, poza tym ten UART poza komunikacją
Atmeg8<>Atmega128 spełnia też rolę połączenia z PC (ten sam port).

do góry

On 12.11.2013 17:16, Piotr Gałka wrote:

> A może nadajnik urywa transmisję.

Nie urywa. Podłączyłem równolegle pod komputer i testowało się dobę - na
komputerze wszystkie transmisje są prawidłowe. Po stronie linuksa mam
kilka pozjadanych bajtów - jak zwykle. Teraz pytanie jak wygląda tam
uart - jeśli ma "bufor" jednobajtowy, a reszta odbywa się po stronie
sterownika linuksowego to może on gdzieś gubi.
Przez przypadek zrobił się też inny test - miałem kiepski zasilacz i
dawał na avr 5,6V i zaczęły się pojawiać błędy w transmisji: "A"
zamieniało się na "@" , "=" na "<" itp. czyli tutaj pewnie kwarc by
pomógł, ale napięcie i tak było dla avr za wysokie.

--
Mirek.

do góry