logo elektroda
logo elektroda
X
logo elektroda
REKLAMA
REKLAMA
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Jak minimalizować błędy w transmisji danych RS232?

marciano8 09 Sie 2017 21:33 2013 20
REKLAMA
  • #1 16633848
    marciano8
    Poziom 8  
    Posty: 52
    Dzień dobry.

    Zwracam się do Was bo zapewne cześć osób zna i stosuje rozwiązanie problemu z którym walczę.
    Jak radzicie sobie z błędami w transmisji danych w komunikacji szeregowej RS232?

    Szukając informacji o błędach występujących w komunikacji szeregowej znalazłem informację, że uzyskanie błędu na poziomie 0 % jest sprawą złożoną i że gdy procent błędów wynosi 1-2 % to poziom ten uznaje się za zadowalający.
    A teraz przykładowo: mam mikrokontroler który steruje procesem i przez RS232 przesyłam z PC wartości zadane do tego mikrokonteolera jako strumień ASCII a mikrokontroler to odczytuje i zapisuje sobie jako kolejne wartości zadane w czasie (nie chodzi mi tu o sterowanie w czasie rzeczywistym za pośrednictwem RS232 bo mikrokontroler robi to tak, że zapisuje sobie cały zadany przebieg z PC a sterować zaczyna dopiero po zapisaniu go).
    Jak teraz rozumieć, że 2 % błędu jest poziomem akceptowalnym? Jeżeli wysyłam strumień danych, np. 1000 próbek zadanego przebiegu i teraz 2 % z nich jest błędne a gdzieś zostanie odczytany krzaczek zamiast poprawnej wartości liczbowej to taki sterownik a wraz z nim cały proces utyka. Dla mnie (i na pewno dla was też) jest to nie do zaakceptowania.

    I tu rodzi się moje pytanie bo może o czymś nie wiem:
    W jaki sposób rozwiązujecie problem polegający na tym, że do 2 % przesłanych danych może być błędnych gdy chcecie przesyłać dane bezbłędne? Przesyłacie je dwa razy i porównujecie? Sprawdzacie czy przesłane wartości są liczbami i w przypadku krzaczków wznawiacie transmisję? Jak sobie z tym radzicie? Czy jest jakieś rozwiązanie sprzętowe które samo sprawdza poprawność transmisji i ponawia wysyłanie gdy wystąpi błąd? Czy jest to jakoś związane z kontrolą parzystości (u mnie włączanie i wyłączanie kontroli parzystości nie miało wpływu na błędy w komunikacji)?

    Proszę o Waszą pomoc i pozdrawiam,
    M.
  • REKLAMA
  • #2 16633871
    electronics_design

    Poziom 14  
    Posty: 64
    Pomógł: 13
    Ocena: 7
    Kontrola parzystości i retransmisja? Jeżeli wystąpi max 2 razy na 100 próbek to nie zwolni to znacznie transmisji. Gotowe elementy w środowiskach (SerialPort itd) mają możliwość kontroli parzystości, tak samo peryferia w mikrokontrolerach.
    Konto firmowe:
    RED Electronics
    Świętojańska 39/9, Gliwice, 44-100 | Strona WWW: http://red-electronics.pl/
  • #3 16633881
    dondu
    VIP Zasłużony dla elektroda
    Posty: 13906
    Pomógł: 1292
    Ocena: 809
    Skąd te informacje?
    Jak wygląda tor transmisyjny?
    Jak wygląda ramka danych?
    ...

    Innymi słowy piszesz o teoretycznych problemach, a nie o konkretnym przypadku.
    Jeśli wszystko rozwiążesz prawidłowo, to błędy może będą liczone w promilach lub jeszcze mniejszych jednostkach.
  • #4 16633939
    marciano8
    Poziom 8  
    Posty: 52
    dondu napisał:
    Skąd te informacje?
    Jak wygląda tor transmisyjny?
    Jak wygląda ramka danych?
    ...

    Innymi słowy piszesz o teoretycznych problemach, a nie o konkretnym przypadku.
    Jeśli wszystko rozwiążesz prawidłowo, to błędy może będą liczone w promilach lub jeszcze mniejszych jednostkach.


    Promilach? Myślałem, że te 1-2 % to coś z czym należy się pogodzić.

    Konkretny przypadek jest taki:
    Mam STM32F4 DISC1 (z programem napisanym w C#.NETMF), który odbiera dane z aplikacji Windowsa (napisanej w C#.NET). Aplikacja wysyła zadany przebieg czasowy a STM32 go odczytuje i zapisuje w tablicy. Następnie zgodnie z zadanym przebiegiem czasowym ma sterować procesem. STM32 jest widziany jako wirtualny port COM. Prędkość transmisji - próbowałem 9600 oraz 19200 i w obu przypadkach zdarzały się błędy. Objawiało się to tym że w wysłanym ciągu danych pojawiła się np. kropka zamiast zera i cały przebieg był niepoprawny a proces utykał bo nie potrafił dokonać działania arytmetycznego na "1.0.123". Włączałem kontrolę parzystości (Even) ale działało to tak samo jak przy wyłączonej tj. zdarzały się "wartości" typu "1.0.123", które sprawiały że proces utykał.

    Piszę to w C# i korzystam tam z gotowych poleceń typu "serialPort2.Write()", "serialPort2.Read()". Przesyłam to portem który jest skonfigurowany następująco: Liczba bitów na sekundę: 9600, Bity danych: 8, Parzystość: Brak, Sterowanie przepływem: Brak.
    Próbowałem też z 19200 bps i ustawiałem Parzystość: Parzyste ale bez poprawy. Zdarza się, że jak wysyłam taki przebieg do co jakiś czas wkrada się coś typu "1.0.123".

    Czy znacie koledzy jakieś mądre rozwiązania o których nie wiem? Kontrola poprawności transmisji realizowana procesowo przez sam protokół? Albo jakieś metody mniej prostackie od napisania programu na uC, który po zakończeniu odbierania będzie sprawdzał wszystkie liczby po kolei i wymuszał retransmisję jeżeli stwierdzi, że jakiś element nie jest poprawną liczbą?

    Dodano po 12 [minuty]:

    electronics_design napisał:
    Kontrola parzystości i retransmisja? Jeżeli wystąpi max 2 razy na 100 próbek to nie zwolni to znacznie transmisji. Gotowe elementy w środowiskach (SerialPort itd) mają możliwość kontroli parzystości, tak samo peryferia w mikrokontrolerach.


    Gdy ustawiałem kontrolę parzystości (Even) w konfiguracji portu w aplikacji, mikrokontrolerze i w windowsie to problem i tak występował. Czasami wkradały sie wartości takie jak "1.0.456".
  • Pomocny post
    #5 16634072
    jnk0le
    Poziom 18  
    Posty: 172
    Pomógł: 33
    Ocena: 32
    Te "2 % błędu" oznacza raczej niedopasowanie rzeczywistego baudrate dwóch urządzeń.
  • REKLAMA
  • Pomocny post
    #6 16634077
    JacekCz
    Poziom 42  
    Posty: 8670
    Pomógł: 760
    Ocena: 1464
    jnk0le napisał:
    Te "2 % błędu" oznacza raczej niedopasowanie rzeczywistego baudrate dwóch urządzeń.


    Tez mam wrażenie, że zasłyszane w literaturze procenty, do pozwolenie na niezgodność zegarów (clocków),, mogą się różnić, byle w ciągu bajtu i bitów kontrolnych nie urosło więcej niz kawałek bita. Jeśli bajt danych z bitami to 11-13 elementów, łączny błąd clockowania (błąd baud rate) powinien być znacznie niższy niż pól bitu.
    Mówimy o transmisji asynchronicznej, gdzie nie ma odtwarzania z sygnału jego podstawowego zegara

    Użytkowa stopa błędów 2% (w sensie błędów parzystości) de facto by uniemożliwiła transmisję żadnej dłuższej ramki, taka stopa zabija tranmisję tego typu
  • Pomocny post
    #7 16634153
    Konto nie istnieje
    Konto nie istnieje  
  • #8 16634667
    marciano8
    Poziom 8  
    Posty: 52
    Piotrus_999 napisał:

    Jezeli używałeś V-COM-a z STLINK-a to problem jest w nim bo jest delikatnie mówiąc schrzaniony i nadaje się tylko do wysyłania komunikatów przy debugowaniu.


    Dokładnie. Używam V-COM-a z STLINK-a. Bardzo Ci dziękuję za tę informację. A dlaczego jest delikatnie mówiąc schrzaniony i nie nadaje się do wysyłania danych? Jaki jest w nim problem i co z nim nie tak?
  • REKLAMA
  • Pomocny post
    #9 16634753
    arturt134
    Poziom 27  
    Posty: 792
    Pomógł: 76
    Ocena: 24
    Tak jak pisali Koledzy wcześniej, te 2% błędu oznacza niedopasowanie częstotliwości zegarów i jako takie może być pominięte. Niemniej jednak przy transmisji danych może dojść do chwilowych zakłóceń sygnału, co spowoduje powstanie "krzaków".
    Aby temu zaradzić można zastosować kontrolę CRC dla ramki danych, transmisję z potwierdzeniem i retransmisją w razie braku potwierdzenia.

    Dużo zależy też od medium. Na przykład przy transmisji danych przez modem GPRS dodatkowo należy się liczyć z "rwaniem" ramki danych, tzn. odstępy między fragmentami ramki danych mogą wynosić nawet kilka sekund. W takim przypadku, oprogramowanie musi być przygotowane na "składanie" takich porwanych ramek.
  • Pomocny post
    #10 16634767
    Konto nie istnieje
    Konto nie istnieje  
  • Pomocny post
    #11 16634823
    JacekCz
    Poziom 42  
    Posty: 8670
    Pomógł: 760
    Ocena: 1464
    arturt134 napisał:
    Tak jak pisali Koledzy wcześniej, te 2% błędu oznacza niedopasowanie częstotliwości zegarów i jako takie może być pominięte. Niemniej jednak przy transmisji danych może dojść do chwilowych zakłóceń sygnału, co spowoduje powstanie "krzaków".
    Aby temu zaradzić można zastosować kontrolę CRC dla ramki danych, transmisję z potwierdzeniem i retransmisją w razie braku potwierdzenia.

    Dużo zależy też od medium. Na przykład przy transmisji danych przez modem GPRS dodatkowo należy się liczyć z "rwaniem" ramki danych, tzn. odstępy między fragmentami ramki danych mogą wynosić nawet kilka sekund. W takim przypadku, oprogramowanie musi być przygotowane na "składanie" takich porwanych ramek.


    żeby dopełnić od strony teoretycznej, jeśli stopa błedów jest większa, a po drugie w zalezności od ich charakteru (np pochodzące od zakłóceń elektrycznych są grupami, rysa na CDROM niszczy bezpowrotnie część 'bliskich' bajtów i znowu w dość dalekim bloku itd, tu słusznie wspominasz o czasie, o innym rodowodzie inaczej) ... są całkiem ambitne sposoby radzenia sobie.

    Ale trzeba mieć zrozumienie przyczyny błędów (tu mówię o reakcji 'softwarowca' czy 'telekomunisty', bo 'elektronik' też zareaguje po swojemu).

    EDIT na błędy 'logiczne', czyli jak tu się sugeruje coś w chipie spieprzone, albo źle użyte oprogramowanie, NIE JEST lekarstwem redundancja danych. Zwykle jak mamy kłopoty z niedopracowaniem+złożoność, to zwiększenie złożoności nie jest lekarstwem

    marciano8 napisał:
    ... sterowanie w czasie rzeczywistym za pośrednictwem RS232 bo mikrokontroler robi to tak, że zapisuje sobie cały zadany przebieg z PC a sterować zaczyna dopiero po zapisaniu go).


    Nie wyobrażam sobie inaczej, tylko tak jest profesjonalnie. Bo co, jak drugi bajt w ramce już był uszkodzony, a my wytworzyliśmy jakis skutek.

    To rodzi problemy (o czym pośrednio pisał @arturt134) gdy ostattnie bajty ramki się dużo spózniają
  • Pomocny post
    #12 16634837
    arturt134
    Poziom 27  
    Posty: 792
    Pomógł: 76
    Ocena: 24
    Jeżeli przyczyną błędów jet spieprzony chip, to na to była już podana rada wcześniej - kup przejściówkę za kilka złotych. Niemniej jednak wymiana przejściówki nie zabezpieczy przed innymi źródłami błędów - o tym właśnie piszę.....
  • #13 16634904
    marciano8
    Poziom 8  
    Posty: 52
    Bardzo Wam wszystkim dziękuję za pomoc.
  • #14 16887666
    marciano8
    Poziom 8  
    Posty: 52
    Piotrus_999 napisał:
    Jezeli używałeś V-COM-a z STLINK-a to problem jest w nim bo jest delikatnie mówiąc schrzaniony i nadaje się tylko do wysyłania komunikatów przy debugowaniu.


    Już byłem pewny, że Twoja rzeczowa porada rozwiąże mój problem. Użyłem przejściówki - gotowy układ oparty na scalaku FTDI 1407-C. Jest tak samo jak przy użyciu V-COM-a z STLINK-a - kiedy chcę przesyłać ciąg znaków odpowiadających przebiegowi wartości zadanych to raz na jakiś czas (niekiedy w sposób uporczywy) przesyła dane z błędami. Podpinałem się do dwóch różnych portów STM32F4 żeby mieć pewność - do COM1 (Rx - PA10, Tx - PA9) i COM5 (Rx - PD2, Tx - PC12). Oznacza to, że nie V-COM z STLINKa jest przyczyną (przynajmniej nie jest jedyną przyczyną). Nadmieniam że korzystam z gotowej biblioteki w C#.NETMF: STM32F429I_Discovery.Netmf.Hardware.cs do obsługi tych portów.

    Czy jesteście w stanie koledzy podrzucić jakąś inną wskazówkę lub rozwiązanie tego problemu? Spotkaliście się z czymś takim, że zamiast ciągu ze znakami typu "0.12345" przesyła Wam błędnie "0.1.345"?
  • REKLAMA
  • #15 16887787
    sawitar
    Poziom 18  
    Posty: 228
    Pomógł: 20
    Ocena: 19
    Wypadało by rozwiązać problem HW w pierwszej kolejności bo 2% BER przy RS232 to rzeczywiście sporo.

    Z rozwiązań softwarowych wspomnieć należy:
    - kontrola parzystości (wspomniana wcześniej ale podaje dla porządku) pozwala na weryfikacje poprawności transmitowanego słowa
    - sumy kontrolne (proste sumowanie binarne lub CRC) pozwalają na weryfikację poprawności bloku danych
    - kodowanie nadmiarowe (w tym korekcyjne) pozwala na detekcję (i/lub korekcję) danych przesłanych przez zaszumiony kanał transmisyjny. Takie kody można zaprojektować do pracy w prawie dowolnych warunkach (także przy BER na poziomie 2%)

    Na wspomnianych płytach CD-ROM zastosowano kilka wspomnianych wyżej rozwiązań. Nadmiarowość danych na płycie CD-ROM sięga zdaje się 15% (ale nie pamiętam dokładnie). i znacznie więcej jeśli uwzględnić CIRC i EFM).
    W systemach satelitarnych gdzie ilość błędów transmisji jest duża stosuje się kodowanie od 2/3 (2/3 na każde 2 bity danych transmitujemy 3 bity w kanale transmisyjnych czyli 50% nadmiarowych danych) do 5/6 (20% nadmiarowości).
  • #16 16887951
    Konto nie istnieje
    Konto nie istnieje  
  • #17 16888070
    marciano8
    Poziom 8  
    Posty: 52
    Piotrus_999 napisał:
    Powyżej 500k ST-Link nie działa poprawnie. Ja do dużych prędkosci uzywam przejściówek i nie mam problemu.


    Czy programujesz wtedy mikrokontroler w C# czy w C?
  • #18 16888089
    Konto nie istnieje
    Konto nie istnieje  
  • #19 16891372
    marciano8
    Poziom 8  
    Posty: 52
    Piotrus_999 napisał:
    Ja do dużych prędkosci uzywam przejściówek i nie mam problemu.
    Piotrus_999 napisał:
    Jezeli używałeś V-COM-a z STLINK-a to problem jest w nim bo jest delikatnie mówiąc schrzaniony i nadaje się tylko do wysyłania komunikatów przy debugowaniu.
    Piotrus_999 napisał:
    uC programuję w C. Program na PC-cie zależy od potrzeb. C++, C# z reguły. .NET na uC nie znam i nie mam potrzeby poznawać.


    Rozumiem zatem, że programowałeś STM32F4-DISC1 w C i przy użyciu przejściówki nie miałeś takiego problemu co ja. Dobrze zrozumiałem?
  • #20 16891588
    Konto nie istnieje
    Konto nie istnieje  
  • #21 16929888
    marciano8
    Poziom 8  
    Posty: 52
    Piotrus_999 napisał:
    UC tylko w C


    Ja używam C# .NETMF i bibliotek od STM32. W takim razie przyjrzę się dokładnie wykorzystywanym przeze mnie bibliotekom dla płytki STM42F4-DISCO. Dziękuję Ci za trop.

Podsumowanie tematu

LABEL_AI_GENERATED
W dyskusji poruszono problem błędów w transmisji danych RS232, szczególnie w kontekście mikrokontrolera STM32F4 DISC1, który odbiera dane z aplikacji Windows. Użytkownicy wskazali, że akceptowalny poziom błędów na poziomie 1-2% może być mylący, zwłaszcza przy przesyłaniu dużych strumieni danych, gdzie nawet niewielkie błędy mogą prowadzić do poważnych problemów. Zasugerowano różne metody minimalizacji błędów, takie jak kontrola parzystości, sumy kontrolne (CRC), retransmisja oraz użycie odpowiednich przejściówek, takich jak FTDI. Wskazano również na problemy z synchronizacją zegarów oraz zakłóceniami sygnału, które mogą wpływać na jakość transmisji. Użytkownicy podkreślili znaczenie odpowiedniego doboru sprzętu oraz oprogramowania, aby zredukować błędy do minimum.
Podsumowanie AI na podstawie dyskusji. Może zawierać błędy.
REKLAMA