Hallo, ich habe ein Problem. Ich logge mit dem RASPI und einem FTDI-USB-RS485-Adapter mit. Das Problem sind dabei relativ viele Bitfehler/Prüfsummenfehler. So wie es aussieht ist das Stopbit wohl das Problem. Die Daten werden mit 19.2 kBit übertragen. Das Stopbit sollte demnach also 52µs lang sein. Alle Geräte auf diesem Bus scheinen aber nur ein Startbit zu haben das 20µs lang ist. Hat jemand eine Idee wie ich das zum laufen bekomme? Wie wird denn das Startbiut abgetastet? Kann man das an der Seriellen Schnittstelle ändern? Wenn auf die letze Flanke vom Startbit gewartet wird dürfte es ja kein Problem sein. Wenn aber die erste Flanke vom Startbit für das Timing genommen wirde kann das nur schiefgehen. Hat jemand eine Idee wie man den FDTI am Rapberry, Linux oder Windowspc "umprokonfigurieren" kann? Gruß Ingo
Ingo F. schrieb: > Das Stopbit sollte demnach also 52µs lang > sein. Das Stopbit darf auch länger, sogar beliebig lang sein. Ingo F. schrieb: > Wie wird denn das > Startbiut abgetastet? Unterschiedlich. Ein Verfahren entdeckt die Vorderflanke des Startbits, wartet dann eine halbe Bitzeit und schaut nochmal nach, ob das Startbit andauert. Falls nicht, handelt es sich um eine Störung und wird ignoriert. Falls ok, werden nun mit einer Verzögerung von 1 Bitzeit alle Datenbits, evtl. Parity, und das Stopbit abgetastet. Wenn das Timing präzise ist, liegen die Abtastzeitpunkte damit genau in der Mitte der Bits, aber das ist nicht Voraussetzung. Das Stopbit sollte zum Abtastzeitpunkt mit der richtigen Polarität vorhanden sein, sonst wird ein "Framing Error" signalisiert. Im Normalfall wartet der Empfänger nicht auf das Ende des Stopbits, sondern er ist sofort, nachdem er dieses abgetastet hat, wieder für ein neues Startbit bereit. Ein häufiger Fehler bei den seriellen Übertragungen hängt mit dem Parity-Bit zusammen. Wenn der Sender eines erzeugt, der Empfänger aber keins erwartet, wird das mit 50% Wahrscheinlichkeit einen Framing Error hervorrufen. Wenn der Sender keins erzeugt, der Empfänger aber Parity erwartet, wird der Empfänger zu 50% einen "Parity Error" signalisieren. Dann gibt es noch die Fehlerfälle, bei denen Sender und Empfänger mit unterschiedlichen Parity-Einstelllungen Odd (PO) bzw. Even (PE) initialisiert wurden. In vielen Fällen ist das Wort im Datenregister beim Auftreten der oben genannten Fehler trotzdem richtig. Falls nicht, kann man aber oft aus der Art der Verfälschung auf ihre Ursache schliessen. P.S.: Zu allem Überfluss kann man auch noch die Länge des Datenwortes mit 7 oder 8 Bits initialisieren. Das sollte natürlich auf beiden Seiten übereinstimmen. Die Länge des Stopbits kann man meist auf 1 1,5 oder 2 Bitzeiten einstellen, aber das hat nur Wirkung beim Sender. Den Empfänger interessiert es nicht, er ist immer mit einem Stopbit zufrieden.
:
Bearbeitet durch User
Hp M. schrieb: > Ein Verfahren entdeckt die Vorderflanke des Startbits, wartet dann eine > halbe Bitzeit Das wäre bei dem Startbit mit 20µs eine Katastrophe. Allerdings ist das Startbit nicht wirklich mein Problem. Das was ich als Startbit angesehen habe ist wohl nur das Einschalten des Senders: http://www.amescon.com/phpbb/viewtopic.php?t=540 Allerdings wird das Startbit ja auch vor jedem Byte gesendet und dürfte daher nicht mein Fehler sein. Bei meinem Besipiel kommt das letzte NachrichtenByte nicht an und die CRC wird falsch empfangen. Beispiel: 0F 25 88 81 <Taste> <CRC-High> <CRC-Low> Als Taste werden 05, 04, 03, 02 oder 00 gesendet. Bei allen Sendern wird nur das Telegramm mit der Taste "03" falsch empfangen. Die Bits am Oszilloskop sind genau 52µs lang. Also könnte es kein Fehlerhafter Takt sein. Muss wohl mal versuchen jedes Bit in einem Telegramm nachzumessen und die Bits zu dem Telegramm zusammensetzen.
Moinsen! Wenn der Fehler immer bei einer bestimmten Datenkombination (Taste "03") auftritt, würde ich mal die CRC-Generierung/Prüfung ganz genau unter die Lupe nehmen. meint Baku
Baku M. schrieb: > würde ich mal die CRC-Generierung/Prüfung ganz genau unter die > Lupe nehmen Mal überhaupt ansehen, wie der ganze Record jeweils aussieht, z.B. ob bei Taste 03 die CRC-Bytes ein besonderes Muster haben. Prinzipiell würde ich darauf tippen, dass die Enable-Schaltung für den Sendebetrieb nicht korrekt funktioniert. Schaltet der Sender zu früh ab, werden die letzten Bits nicht richtig übertragen, ist es zu spät, kommt das in Konflikt mit der Antwort. Korrekt müsste der Sender gerade nach dem Stoppbit des letzten CRC-Bytes abschalten. Georg
Ingo F. schrieb: > Hat jemand eine Idee wie man den FDTI am Rapberry, Linux oder Windowspc > "umprokonfigurieren" kann? Bevor du ziellos ans "umprokonfigurieren" gehst, solltest du erstmal klären, was die echte Ursache für die Empfangsstörungen ist (falsche Hardwaresteuerung, falsche Aussendung, falsche Erwartungshaltung des Empfängers, ...).
Baku M. schrieb: > Wenn der Fehler immer bei einer bestimmten Datenkombination (Taste "03") > auftritt, würde ich mal die CRC-Generierung/Prüfung ganz genau unter die > Lupe nehmen. Also das Problem ist nicht die CRC. Die CRC-Berechnung funktiorniert bei 95 % der Telegramme. Die ist also OK. Nur 5% der Telegramme haben eine falsche CRC. Alle Telegramme mit falscher CRC sind zufällig auch ein Byte kürzer. Es wird wohl so sein dass er beim 03-Byte das Startbit nicht erkennt und das nächste 0-Bit als STartbit erkennt. Ein einziges Telegramm wird richitg erkannt und dort ist das zweite Byte genau um 1 Bit verschoben. Vermutlich habe ich jetzt den richtigen Fehler gefunden. Alle Impulse sind ein vielfaches von 40µs. Der Bus läuft also mit 25000 Bit/s Das Problem wird wohl der FTDI-USB-Adapter sein. Wie bekomme ich den auf 25kBit/s umgestellt??? Jemand eine Idee?
Häh? Dann läuft der doch mit 25kBit/s?!? Oder fehlt eine Null?
Felix A. schrieb: > Häh? Dann läuft der doch mit 25kBit/s?!? Oder fehlt eine Null? So wie es aussieht läuft der Bus auf 25kbit/s. Das heisst fast alle Telegramme laufen problemlos mit 19,2kBit nur eins macht Probleme. Was mich nur wundert ist dass es bei fast allen Telegrammen mit etwa 20% Taktabweichungen immer noch so gut funktioniert. Also nach dem 8 Bit sollte die Abweichung dann schon bei 1,8 Bit liegen. Habe gerade ein AN von FTDI gefunden. Demnach könnte ich einfach die INF-Datei anpassen und könnte mir meine 25kBit zusammenbasteln. Dumm ist nur dass es unter Linux laufen soll. Muss mal sehen ob und wo man die Divisoren sehen oder ändern kann....
IngoF schrieb: > Habe gerade ein AN von FTDI gefunden. http://www.ftdichip.com/Documents/AppNotes/AN232B-05_BaudRates.pdf
IngoF schrieb: >> Ein Verfahren entdeckt die Vorderflanke des Startbits, wartet dann eine >> halbe Bitzeit > > Das wäre bei dem Startbit mit 20µs eine Katastrophe. Deswegen gibts sowas auch nicht. Das Startbit ist bei 19200Baud immer genau 52.08µs lang. Die Dauer des Startbits ist immer exakt genau eine Bitzeit weil die Vorderflanke des Startbits als initiale Zeitreferenz genommen wird (evtl wird bei manchen Luxus-UARTS bei den folgenden Flanken noch leicht nachkorrigiert, aber der erste und wichtigste Zeitpunkt ist stets die Vorderflanke des Startbits, ohne die ginge gar nichts).
Habe gerade den Link gefunden um die Schnittstelle in c umzuprogrammieren auf beliebige Baudraten: http://www.mrunix.de/forums/archive/index.php/t-49885.html Bei den 40µs Bitzeit bin ich mir nicht mehr ganz sicher. Kann seinn dass ich ausversehen an den Feineinstellungen der X-Achse gekommen sein könnte. Habe gerade noch mal nachgemessen scheinen doch 19200 zu sein. Habe mal ein bisschen verschiedene Bitraten ausprobiert. Zumindest habe ich jetzt einmal das Telegramm das immer fehlerhaft war auch schon zweimal korrekt empfangen Auch das fehlende Byte 03 wird jetzt auch immer empfangen. Nur noch die CRC sind noch fehlerhaft. Wenn ich die Bittrate etwas höher drehe werden die CRC von anderen telegrammen übertragen. Wenn ich sie tiefer drehe sind es andere Telegramme die keine richtige CRC haben. Auf jedenfall ist die Übertagung sehr instabil....
Protokoll-Fehler? Ich habe ein Projekt bei dem ich über einen Original FTDI RS485/USB Adapter von einem AVR aus mit 2 MBit/s Daten zum PC übertrage. Da schicke ich alle 500µs einen Datenrahmen mit durch die Kodierung variabler Länge raus (mindestens 46 Byte) in dem eine CRC32 enthalten ist. Dabei habe ich noch keinen CRC-Fehler beoabachtet, obwohl das ganze schon recht grenzwertig für den AVR ist. 19200 ist dagegen echt stumpf.
Einige Geräte verwenden eine Stoppbit-Länge von 1.5, warum auch immer. Vielleicht kommt Dein Wandler damit nicht klar, und wenn direkt nach dem 1.5er Stoppbit ein neues Byte gesendet wird, erkennt der Wandler nur ein halbes Startbit. Wie sieht es denn auf dem Oszi aus?
Rudolph R. schrieb: > Protokoll-Fehler? > > Ich habe ein Projekt bei dem ich über einen Original FTDI RS485/USB > Adapter von einem AVR aus mit 2 MBit/s Daten zum PC übertrage. > Da schicke ich alle 500µs einen Datenrahmen mit durch die Kodierung > variabler Länge raus (mindestens 46 Byte) in dem eine CRC32 enthalten > ist. > Dabei habe ich noch keinen CRC-Fehler beoabachtet, obwohl das ganze > schon recht grenzwertig für den AVR ist. > > 19200 ist dagegen echt stumpf. Habe keine Ahnung. Vermute schon fast dass es am Bus selber liegt und der FTDI-USB-Adapter nur etwas empfindlicher ist.. Werde mir noch mal eine Platine ausbauen müssen und die direkt am RS485-Adapter zu testen.
Timm T. schrieb: > Wie sieht es denn auf dem Oszi aus? Sieht eigentlich ganu gut aus. Habe gerade mal den Logoganalyzer (Salea Logic) direkt am Bus angeklemmt. Der kann die Telegramme von den Schaltern nicht richtig empfangen, die von der Zentrale aber schon. Werde den Logictester vielleicht noch mal am USB-Adapter anklemmen wenn ich an die TTL-Signale komme.
IngoF schrieb: > Der kann die Telegramme von den Schaltern nicht richtig empfangen, die > von der Zentrale aber schon. Dann zeig doch mal Capture Files von beiden Seiten.
Angehängte Dateien:
-
Schalter.bmp
150 KB -
Steuerung.bmp
150 KB -
Log.PNG
12 KB
> Dann zeig doch mal Capture Files von beiden Seiten.
Einmal ein Screenshot vom Schalter-Telegramm.
Dann ein Telegramm von der Zentrale.
Das Saleae-Logfile lässt sich wohl nur mit "Logic 1.2.5" öffnen.
Den Framingerror am Ende liegt wohl daran dass er den RS485-Ruhepegel
nicht "erkennt"
Und dann noch ein Auschnitt von meinem Monitorprogramm
Es sieht wohl so aus dass es 19200 8N2 sind.
Habe jetzt natürlich alle Mitschnitte einzeln voneinader machen müssen.
DSO und Saleae haben sich nicht miteinder vertragen...
Im Capture-File sind alle Daten vorhanden in meinem Programm aber nicht.
Hatte mich auch vertan. Es wurde immer das 0x13 unterschlagen, und nicht
die 0x3.
Muss mir das noch mal ansehen...
Angehängte Dateien:
-
Image3.png
5,4 KB
Hallo Bei RS485 Datenübertragung gibt es oft bei den Treibern das Problem, dass der Ruhepegel (Datenübertragung inaktiv) auf den Datenleitungen "nicht stimmt" und deshalb der Datenausgang nicht auf High liegt. Liegt der Datenausgang des Treibers in der inaktiven Zeit nicht auf High dann führt das dazu dass das Startbit des ersten Bytes einer Blockübertragung nicht erkannt wird. Es gibt mittlerweile Bausteine (z.B. LT1785A) die dieses Problem der inaktiven Leitungen berücksichtigen und in diesen Fällen immer ein High am Datenausgang ausgeben. http://cds.linear.com/docs/en/datasheet/178591fd.pdf Man kann aber auch einen definierten Zustand auf inaktiven Datenleitungen mit 3 Widerständen erzwingen! (siehe Bild) Gruss Stefan
Hallo, noch ein Nachtrag: Die Schaltung mit den 3 Widerständen sollte natürlich nur einmal im Bussystem vorkommen. Die Widerstandswerte müssen der Versorgungsspannung angepasst werden falls nicht 5V. Es gibt auch eine einfache Softwarelösung: Immer nach dem Einschalten des Transmitters im RS485-Treiber eine ganze Bytelänge warten und dann erst lossenden. (Minimum 1 Stopbit lang) Der FTDI-Chip berücksichtigt das bei RS485 Beschaltung schon! Gruss
Angehängte Dateien:
-
13EE9D-BE9D.PNG
3,5 KB -
Log2.PNG
8,7 KB
stefan schrieb: > Die Schaltung mit den 3 Widerständen sollte natürlich nur einmal im > Bussystem vorkommen. Habe mir diesen Adapter zugelegt: http://shop.in-circuit.de/product_info.php?cPath=38&products_id=81 der hat 390Ohm gegen GND oder VCC und 220 Ohm A gegen B. Die Widerstände lassen sich einzeln über DIP-Schalter aktivieren. sobald ich einen der 390Ohm widerstände einschalte wird das Signal an der Ader in die Knie gezogen und es kommen nur noch Nadeln an. Wenn ich beide aktiviere ist keine Kommunikation mehr möglich. Wird also schon in der Steuerung eingebaut sein... Müsste das mal testen wenn ich mein Testprogramm angeschlossen habe. Eventuell kann ich sie dann einschalten. Habe es jetzt gerade mal nur mit meinem Testprogramm ohne steuerung getestet. Meine Bestätigung kommt jetzt auch wohl an den Schaltern an. die vermisste 0x13 wird auch auf dem Bus gesendet. Mein Testprogramm kann es einfach nicht über den RS485-Adapter empfangen. Keine Ahnung warum das nur bei diesem einen Byte so ist. statt der 13 EE 9D kommt nur ein BE 9D an kann das nicht wirklich verstehen. Habe nochmal alles mögliche angehangen. Oder ich muss mir noch mal einen anderen RS485-Adpater zulegen. Oder es ist der Raspberry PI oder meine Software. Aber irgendwie klingt alles nicht logisch. selbst wenn jetzt irgend ein 0-Bit von der 0x13 als Startbit erkannt werden würde komme ich auch nicht auf 0xBE sondern andere Werte.
IngoF schrieb: > sobald ich einen der 390Ohm widerstände einschalte wird das Signal an > der Ader in die Knie gezogen und es kommen nur noch Nadeln an. Wenn ich > beide aktiviere ist keine Kommunikation mehr möglich. Eventuell ist der RS485 Treiber Baustein kaputt oder überlastet. Wenn man den Widerstand A-=-B weglässt, können die Vorspannwiderstände auch größer (1k) ausfallen. Dann darf der Bus allerdings nicht sehr lang sein.
IngoF schrieb: > Das was ich als > Startbit angesehen habe ist wohl nur das Einschalten des Senders: Ds macht man ja auch nicht, dass man nach dem Einschalten sofort lossendet. Schliesslich muss der Empfänger evtl. erst initialisiert werden, nachdem dort das Zustandekommen der Verbindung erkannt wurde, oder -falls er schon läuft-, muss man ihm Zeit geben aus dem bei offener Leitung herrschenden Dauer-Start Zustand herauszukommen. Das kann ein ganzes Zeichen dauern. IngoF schrieb: > statt der 13 EE 9D kommt nur ein BE 9D an kann das nicht wirklich > verstehen. Asynchrone Verbindungen haben die Angewohnheit, von allein nach einigen Zeichen wieder fehlerfrei zu funktionieren, wenn sie durch eine Störung wie etwa eine Leitungsunterbrechung, völlig aus dem Tritt gekommen sind. Natürlich mag es binäre Datenfolgen geben, die das zuverlässig verhindern, aber eine gestörte Übertragung von Text, erzeugt vielleicht eine halbe Zeile nach Verschwinden der Störung wieder lesbaren Text. Hier scheint es so zu sein, dass 13 wegen Framing Error gar nicht abgeholt wird, EE ist schon fast richtig, und ab 9D läuft die Übertragung wieder fehlerfrei. Timm T. schrieb: > Einige Geräte verwenden eine Stoppbit-Länge von 1.5, warum auch immer. > Vielleicht kommt Dein Wandler damit nicht klar "Warum auch immer": Das war die Norm für die mechanischen Fernschreibmaschinen. 50 Baud, 5-Bit Baudot Code, 1,5 Stop-Bits. Wie ich oben bereits erwähnte, ist es dem Empfänger aber völlig egal, wie lang das Stop-Bit ist, wenn es nur mindestens erkannt wird.
:
Bearbeitet durch User
Hp M. schrieb: > Wie ich oben bereits erwähnte, ist es dem Empfänger aber völlig egal, > wie lang das Stop-Bit ist, wenn es nur mindestens erkannt wird. Nach Standard sind auch 5, 6 oder 7 Datenbits statt der üblichen 8 erlaubt. Trotzdem würde ich nicht darauf wetten, daß damit jeder Wandler klarkommt. Wenn der Empfänger auf 1 Stopbit eingestellt ist, versucht er vielleicht gerade bei 1.5 neu zu samplen und bekommt mal ein Startbit und mal nicht. Das macht man zwar nicht so, aber weißt Du, ob der Entwickler das sauber implementiert hat? Ich hab das schon die komischsten Sachen gesehen.
Auf dem Rpi könnte die 13 als "Kommando" erkannt werden. Mit C# hatte ich ein ähnliches Problem. Gefunden habe ich es durch einen uC, der stumpf alle Bytes von 0 bis 255 an den PC gesendet hat. Vielleicht solltest du sowas mal ausprobieren und dann schauen, ab wo der Fehler auftritt (Adapter, Pi,...)
> Ich logge mit dem RASPI und einem FTDI-USB-RS485-Adapter mit.
Mit anderen Worten du liesst erstmal nur. Es sollte dir mit deinem Oszi
also leicht fallen zu sehen ob das Startbit bereits auf dem RS485 Bus zu
kurz ist, oder ob es das erst nach dem Pegelwandler ist. Wobei ich
denken wuerde das es das schon auf dem Bus ist.
Wenn das der Fall ist dann ist das sendende Device defekt oder hat einen
Programmierfehler. Das markante an RS485 ist ja das man die
Treiberbausteine regelmaessig zwischen Lese und Schreibrichtung
umschalten muss und dabei kommt es gerne mal zu Problemen.
So muss der Sender sicherstellen das halt der Treiberbaustein wirklich
im Sendemodus ist bevor er etwas ausgibt. Man sollte eigentlich meinen
das man da nicht viel falsch machen kann. Andererseits sind moderne
Controller sehr schnell und haben die Portleitungen vom Prozessorbus
abgekoppelt. Vielleicht reicht das fuer eine kleine Verzoegerung.
Haeufiger sind aber Fehler am Ende der Uebertragung. Im Extremfalle wird
da das falsche Bit abgefragt. (Sendebuffer anstatt Senderegister) Ich
hab aber auch schon mal einen Controller gehabt der hat manchmal (nicht
immer!) bereits Senderegister leer gemeldet wenn das Stopbit erst halb
raus war.
Olaf
IngoF schrieb: > die vermisste 0x13 wird auch auf dem Bus gesendet. Ist es Zufall, daß ausgerechnet 0x13 = XOFF (CTRL-S) verloren geht?
Ich benutze so einen hier: http://www.ftdichip.com/Products/Cables/USBRS485.htm Auf der anderen Seite habe ich einen MAX485 mit 120R zur Terminierung. Plus einen ADuM1201BR für die galvanische Trennung. Gesendet wird mit 8N1, nur in eine Richtung und ohne Unterbrechung innerhalb eines Datenrahmens. Kein Problem, am PC kommt alles so an wie es soll.
Timm T. schrieb: > Wenn der Empfänger auf 1 Stopbit eingestellt ist, versucht er vielleicht > gerade bei 1.5 neu zu samplen Also bei mir war es hier wohl andersherum. Ich hatte erst mit 1 Stoppit gesendet. Der Gegenseite benötigt wohl zwei Stoppits. Also Kamm von mir schon das nächste Startbit als die Gegenseite noch das zweite Stopbit abgewartet hat. Felix Adam schrieb: > Auf dem Rpi könnte die 13 als "Kommando" erkannt werden. Mein erster Gedanke war das Linefeed aber das ist ja 13(Dez) und nicht 13(Hex). Aber ich glaub ich habe den Fehler: 0x13 ist das Zeichen für XOff. Ich denke das erklärt alles. EIgentlich müsste ich das aber deaktiviert haben. Olaf schrieb: > Es sollte dir mit deinem Oszi > also leicht fallen zu sehen ob das Startbit bereits auf dem RS485 Bus zu > kurz ist Das war mein erster Eindruck. Aber das ist wohl das aufwachen aus dem Idle beim RS485 und nicht das Startbit. Markus F. schrieb: > Ist es Zufall, daß ausgerechnet 0x13 = XOFF (CTRL-S) verloren geht? Vermutlich nicht.. bin vor 15 Sekunden durch den anderen Beitrag auch auf diese Idee gekommen.. Rudolph R. schrieb: > Ich benutze so einen hier: > http://www.ftdichip.com/Products/Cables/USBRS485.htm Habe auch mehrere RS232-Kabel und Platinen direkt von FTDI. Bin garnicht auf die Idee gekommen dass es das dort auch direkt als RS485-Kabel und Platine gibt. :-) SO dann hoffe ich mal dass das Problem gefunden ist. Das erklärt vermutlich warum ein bestimmtes 0x0D als 0x0A ankommt. Vielleicht wird das "CR" und "LF" ausgetauscht... Muss mir noch mal die Konfiguration genauer ansehen.
stefan schrieb: > mit 3 Widerständen erzwingen! (siehe Bild) Die sind mit 1.5k viel zu groß. Du mußt außerdem beachten daß es sich was den resultierenden Abschlusswiderstand angeht dann von der Leitung aus gesehen um eine Parallelschaltung dreier Widerstände handelt, also wenn Du 120 Ohm Wellenwiderstand auf der Leitung hast bemisst Du zum Beispiel den mittleren mit 240 Ohm und die beiden Pullup und Pulldown (die heißen übrigens Failsafe) mit je 480 Ohm, das wären dann halbwegs gesunde Werte.
:
Bearbeitet durch User
IngoF schrieb: > Der Gegenseite benötigt wohl zwei Stoppits. Bestimmt nicht, es sei denn die Gegenseite besteht aus einem alten Lorenz-Fernschreiber im Holzgehäuse. Bei heutigen UARTs wirkt die Stoppbit-Einstellung nur beim Senden, beim Empfang sind alle mit 1 Stoppbit zufrieden, genau genommen sogar mit etwas mehr als einem halben. Mit der Abtastung in der Mitte des Stoppbits ist der Empfang abgeschlossen. Das alles gilt natürlich nicht für selbstprogrammierte Software-UARTs, aber da kann sowieso alles falsch sein. Georg
IngoF schrieb: > sobald ich einen der 390Ohm widerstände einschalte wird das Signal an > der Ader in die Knie gezogen und es kommen nur noch Nadeln an. Na dann hast Du den Fehler ja gefunden: Beim sendenden Gerät (das welches das kaputte Signal erzeugt und dann nicht mehr gegen die Widerstände ankommt) ist etwas kaputt. Hier mußt Du den Fehler suchen. Überprüf mal die Versorgungsspannung, ebenso die Masseverbindungen. (Schlechte Lötstellen? Geh mit dem Tastkopf mal direkt auf die Beinchen am Transceiver-IC und schau mal ob der seine 5V bekommt und ob die stabil bleiben beim Senden, ebenso ob die Masse gut ist und was direkt an den A und B Anschlüssen anliegt und dann verfolge das weiter bis zum Fehler). Eventuell stellst Du dabei auch fest daß es nicht am Transceiver liegt sondern an der Verkabelung, an einem Stecker, etc. Aber ich tippe eher auf die Spannungsversorgung des Transceivers. Ist das ein galvanisch isolierter Transceiver mit seiner eigenen 5V-Versorgung? Halbtote Schottky-Diode in dessen Gleichrichter evtl?
:
Bearbeitet durch User
stefan schrieb: > Immer nach dem Einschalten des Transmitters im RS485-Treiber eine ganze > Bytelänge warten und dann erst lossenden. (Minimum 1 Stopbit lang) Olaf schrieb: > Haeufiger sind aber Fehler am Ende der Uebertragung. Im Extremfalle wird > da das falsche Bit abgefragt. (Sendebuffer anstatt Senderegister) Ich > hab aber auch schon mal einen Controller gehabt der hat manchmal (nicht > immer!) bereits Senderegister leer gemeldet wenn das Stopbit erst halb > raus war. In beiden Fällen könnte es eine gute Idee sein, als erstes nach dem Einschalten bzw. als letztes ein (Dummy-)Byte mit dem Wert 0xFF zu senden. Grüße Stefan
Olaf schrieb: > Ich > hab aber auch schon mal einen Controller gehabt der hat manchmal (nicht > immer!) bereits Senderegister leer gemeldet wenn das Stopbit erst halb > raus war. Dann hast Du das falsche Bit abgefragt. Du sollst nicht "Senderegister-Leer" abfragen sondern "Transmission-Complete"
Bernd K. schrieb: >> sobald ich einen der 390Ohm widerstände einschalte wird das Signal an >> der Ader in die Knie gezogen und es kommen nur noch Nadeln an. > > Na dann hast Du den Fehler ja gefunden: Das werde ich mir mal bei Zeiten genauer ansehen. Ob nicht sogar schon diese Widerstände woanders schon eingebaut sind oder ob es da Probleme gibt. So, Alle meine Empfangsprobleme sind gelöst:
1 | options.c_iflag &= ~IXON; /* deactivate XON */ |
2 | options.c_iflag &= ~IXOFF; /* deactivate XOFF */ |
3 | options.c_iflag &= ~IGNCR; /* do NOT ignore CR */ |
4 | options.c_iflag &= ~ICRNL; /* do NOT replace CR with NL */ |
5 | options.c_iflag &= ~INLCR; /* do NOT replace NL with CL */ |
6 | // options.c_iflag &= ~IGNBRK; /* Do NOT ignore break condition (SMI) */ |
7 | options.c_iflag |= IGNBRK; /* ignore break condition (SWB) */ |
Ich hatte noch ein paar andere Probleme die ich auf dem RS485-Bus vermutet hatte.
IngoF schrieb: > So, Alle meine Empfangsprobleme sind gelöst: Naja, wenn das Oszillogramm immer noch so aussieht wie oben gepostet dann würde ich das nicht unbedingt als gelöst betrachten, das ist eindeutig ein Hardwaredefekt. Mir an Deiner Stelle würde das keine Ruhe lassen.
Bernd K. schrieb: > Naja, wenn das Oszillogramm immer noch so aussieht Na zumindest alle meine Übertragungsfehler sind gelöst... Was meinst Du denn? Dass diese Spikes an den vorderen Flanken vom linken Oszillogramm? Das "20µs-Start-Bit-Problem" war ja nur das "aufwachen" aus dem Ruhezustand. Ich glaube das Signal am DSO ist auch invertiert. Habe nicht darauf geachtet ob GND vom DSO auf A oder B war.
IngoF schrieb: > Dass diese Spikes an den vorderen Flanken vom linken > Oszillogramm? Ich glaub ich bin noch nicht ganz wach. Sollte in etwa heissen: Die Spikes an den vorderen Flanken vom linken Oszillogramm?
IngoF schrieb: > IngoF schrieb: >> Dass diese Spikes an den vorderen Flanken vom linken >> Oszillogramm? > > Ich glaub ich bin noch nicht ganz wach. > > Sollte in etwa heissen: > Die Spikes an den vorderen Flanken vom linken Oszillogramm? Ja. Das ist ein Hardwaredefekt. Der bewirkt auch dass es ganz zusammenbricht wenn du Failsafe und Abschlusswiderstände zuschaltest (die ja im normalen Betrieb normalerweise vorhanden sein müssen). Dieser Defekt bewirkte auch Dein ursprüngliches Symptom welches jetzt nach ziellosem Rumdoktorn an anderer Stelle rein zufällig um Haaresbreite mal nicht auftritt. Diesen elektrischen Defekt würde ich suchen und beheben.
:
Bearbeitet durch User
> Bei heutigen UARTs wirkt die > Stoppbit-Einstellung nur beim Senden, beim Empfang sind alle mit 1 > Stoppbit zufrieden, genau genommen sogar mit etwas mehr als einem > halben. Das stimmt nicht ganz. Du hast natuerlich Recht was die UART Hardware angeht, aber ein weiteres Stopbit gibt dem Controller mehr Zeit in den Interrupt zu kommen und das Byte abzuholen. Je nach Controller und wie schlecht das programmiert ist kann das durchaus notwendig sein. Olaf
Olaf schrieb: > Du hast natuerlich Recht was die UART Hardware > angeht, aber ein weiteres Stopbit gibt dem Controller mehr Zeit in den > Interrupt zu kommen und das Byte abzuholen. Naja, ich weiß ja nicht wie andere Controller das machen, aber beim AVR sind die Bytes gepuffert, Du hast da ein ganzes Byte lang Zeit, das vorherige Byte abzuholen. Interessant ist das eher für Software-Uart, aber für einen ordentlich gebauten Uart ist das bei 19200 Baud auch noch kein Problem. Letztlich muß er das empfangene Byte nur in einen Ringpuffer klatschen, den Pufferzähler hochzählen und kann auf das nächste Startbit samplen. Das sind nur ein paar Takte.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.