Fehlerhafte Übertragung mit PySerial

  • Hallo,

    ich habe bereits einige serielle Verbindungen über den GPIO-UART und PySerial erfolgreich realisiert.
    Jetzt muss ich allerdings ein Gerät via RS232 mit dem Raspi verbinden, weswegen ich mich entschieden habe,
    einen USB-Serial Converter zu verwenden.

    Für Testzwecke nutze ich zwei USB-RS232 Adapter, welche über einen Nullmodem-Adapter verbunden sind.
    Einer der Adapter steckt dabei am Raspi der andere an meinem PC.
    Leider bekomme ich bisher keine brauchbare Übertragung zustande, es kommen beim Raspi nicht die Zeichen an,
    die ich vom Windows Rechner absende.

    Zuerst ging ich von einem Hardwareproblem (fehlendes GND o.ä.) aus, weswegen ich mit den Adaptern mal eine
    Verbindung zwischen zwei Windows-PCs hergestellt habe und über EasyTerm Tests gemacht habe. Dabei gelang
    mir eine fehlerfreie Kommunikation problemlos. Somit ist das mögliche Hardware-Problem mMn vom Tisch.

    Deswegen gehe ich nun von einem Softwarefehler aus, welchen ich allerdings nicht finde. :helpnew:
    Noch ein Hinweis: Die Verbindung muss nur unidrektional vom Sender (derzeit PC mit Win10) zum Raspi möglich sein.

    Python-Code auf dem Empfänger (Raspi)

    Python-Code auf dem Sender (Windows-PC)

    Und das kommt alle 5s auf dem Raspi an:

    Code
    b'\x08\x01\x0c\x0c\x0f\r\n'
    ASCII:

    Meiner Meinung nach wird immer die zweite Stelle des Hex-Werts korrekt übertragen und die erste Stelle kommt warum auch immer abhanden.
    Hat jemand eine Idee woran das liegen kann?
    Die Parameter der seriellen Schnittstelle entsprechen denen des späteren Senders und können somit nicht geändert werden.

    Danke für Eure Hilfe.

    technikasg

  • Hast du mal anstelle von

    Code
    bytestring = bytes(ser.readline())
    Code
    bytestring = bytes(ser.read())

    versucht? Oder auch

    Code
    bytestring = bytes(ser.readline(size=8))

    Kanns grade leider nicht testen, aber laut pySerial API könnte das besser klappen

    P.S.: https://pythonhosted.org/pyserial/shortintro.html#readline

  • Da ist viel unnötiger Kram dabei - readline liefert einen bytestring, den muss man nicht noch mal konvertieren. Und "vorbelegen" mit einem Wert ändert nichts an dem Typ wenn man den Namen später an etwas anderes bindet. Und zu guter letzt - decode liefert eine String, da noch mal str() drum zu wickeln ist unnötig.

    Zu deinem Problem - das sieht eigentlich alles gut aus & vor allem die Übertragung der newline Zeichen macht mich stutzig.

    Ich weiß, dass du die Parameter später so brauchst, aber zu Testzwecken solltest du damit mal spielen. Vor allem mal 8 statt sieben bits. Und natürlich passend auf Sender wie Empfänger Seite.

    Das Problem kann auf beiden Seiten liegen. Statt Windows - PI könntest du auch mal PI -PI und Windows - Windows probieren.

    Und falls das Problem irgendwo in der Treiberschicht von Linux liegt, könnte auch ein pegelwandler ala max232 helfen, um mit dem eingebauten UART zu arbeiten.


    Gesendet von iPhone mit Tapatalk


  • Hast du mal anstelle von

    Code
    bytestring = bytes(ser.readline())
    Code
    bytestring = bytes(ser.read())

    versucht? Oder auch

    Code
    bytestring = bytes(ser.readline(size=8))

    Danke für die Hinweise. ser.read() hatte ich schon versucht, leider ohne Erfolg.
    Auch die zweite von Dir beschriebene Methode mit ser.readline(size=8) brachte keinen Erfolg.
    Automatisch zusammengefügt:


    Da ist viel unnötiger Kram dabei - readline liefert einen bytestring, den muss man nicht noch mal konvertieren. Und "vorbelegen" mit einem Wert ändert nichts an dem Typ wenn man den Namen später an etwas anderes bindet. Und zu guter letzt - decode liefert eine String, da noch mal str() drum zu wickeln ist unnötig.

    Zu deinem Problem - das sieht eigentlich alles gut aus & vor allem die Übertragung der newline Zeichen macht mich stutzig.

    Ich weiß, dass du die Parameter später so brauchst, aber zu Testzwecken solltest du damit mal spielen. Vor allem mal 8 statt sieben bits. Und natürlich passend auf Sender wie Empfänger Seite.

    Das Problem kann auf beiden Seiten liegen. Statt Windows - PI könntest du auch mal PI -PI und Windows - Windows probieren.

    Und falls das Problem irgendwo in der Treiberschicht von Linux liegt, könnte auch ein pegelwandler ala max232 helfen, um mit dem eingebauten UART zu arbeiten.

    Danke für den Hinweis zum unnötigen Quellcode, den habe ich gleich mal entfernt. Das hat allerdings keine Abhilfe gebracht.

    Windows-Windows hatte ich bisher nur mit Easyterm getestet (erfolgreich). Jetzt habe ich den Test nochmal mit meinen Python Skripten gemacht, ebenfalls erfolgreich.
    Pi-Pi habe ich nach deinem Hinweis auch mal probiert, allerdings mit dem gleichen Problem wie im Eingangsthread beschrieben.

    Ich glaube, dass dein Hinweis mit dem Linux-Treiber eine sehr brauchbare Spur ist... Oder anders gesagt, ist das ja das Einzige was im Moment noch als Fehlerquelle
    übrig bleibt, wenn ich das richtig sehe.

    Ich werde am Wochenende den Versuch nochmal mit einem anderen USB-RS232 Adapter starten - in der Hoffnung, dass der dann die Abhilfe bringt.

    Ich melde mich auf jeden Fall wieder, wenn ich eine Lösung gefunden habe.

    Einmal editiert, zuletzt von technikasg (25. August 2016 um 19:49)

  • Die Hinweise auf unnötige Code haben tatsächlich nichts mit dem Problem zu tun, machen den Code aber komplizierter als notwendig und dadurch ist es schwieriger daran zu arbeiten bzw Hinweise zu geben.

    Bei PI - PI - hast du da auch mit den Parametern gespielt? Denn theoretisch sollte das ja schon klappen, USB 2 serial ist ja oft benutzt.

    Recht hast du mit der Beobachtung das es nicht an Python sondern an System liegen dürfte. Denn pyserial ist eine sehr dünne Schicht um die OS APIs, die nicht das Potential hat solche Probleme zu verursachen.


    Gesendet von iPhone mit Tapatalk

  • Hallo,

    jetzt hatte ich die Zeit, die Verbindung mit einem anderen USB-RS232 Adapter am Raspi zu testen.
    Diese Änderung brachte dann tatsächlich die Lösung des Problems.

    Vorher hatte ich folgenden Adapter verwendet (NICHT kompatibel mit dem Raspi)

    Code
    USB 2.0 Auf RS232 Seriell DB9 9 Pin Adapter Kabel GPS PDA 1M 9587
    Chip: HL-340
    Kompatibilität: USB 1.1 und 2.0
    Unterstützt serielle RS232-Schnittstelle (DB25 oder DB9)
    Unterstützungen über 1Mbps Transfergeschwindigkeit
    Länge: 0,8 m

    Mit folgenden USB-RS232 Convertern am Raspi konnte ich erfolgreich eine Kommunikation herstellen:
    - Hama 00053325v2 (Prolific Chip)
    - USB-RS232 Converter von CSL-Computer

    Was mich allerdings sehr verwundert, ist die Tatsache, dass sowohl der nicht funktionierende Adapter als
    auch der Adapter von CSL Computer unter Windows als COM-Port mit 'CH340' Chip erkannt werden.
    Warum nun der eine mit dem Raspi kompatibel ist und der andere nicht kann mMn nur auf unterschiedliche
    Hardwareversionen der Chips im jeweiligen Adapter zurückzuführen sein.

    Abschließend nochmal zusammengefasst:
    - kein Problem mit dem Pythonskript (wie anfangs ja von mir vermutet)
    - kein Hardwareproblem (alle Schnittstellenconverter funktionieren unter Windows tadellos)
    - offensichtlich ein Treiberproblem unter Linux welches dazu noch abhängig von der Hardwareversion des Schittstellenadapters ist

    Vielen Dank für Eure Hilfe, welche mich bei der Problemfindung sehr gut unterstützt hat.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!