Hallo zusammen, ich habe eine AndroidApp die kommuniziert über Google Protokollbuffer codiert über flußgesteuertes (RTS/CTS) UART mit 921600 Baud mit einer Meßeinheit einer Reifengleichförmigkeitsmaschine(Unwuchtmessung). Baudrate ist nicht verstellbar. Die App ist eine Blackbox und die Messeinheit auch. Ich habe keine weiteren Informationen. Ich konnte die Befehle die über die Schnittstelle gehen dekodieren. Dazu schrieb ich ein Programm das die Leitung abhört. Das erreichte ich indem ich zwei FTDI/USB-UART)-Adapter mit Rx an TX (Adapter1)und RX an RX(Adapter2) verband. Das ist zwar nicht richtig, aber so habe ich es herausgekriegt. 1. Problem Merkwürdigerweise kann ich keinen (hochwertigen) Logic-Analyzer, noch ein modernes Oszi anschließen ohne dass die Kommunikation zwischen App und Messeinheit mit Fehler abbricht. Ich gehe mal davon aus dass die hohe Geschwindigkeit des UART schuld daran ist. 2. Problem (Hauptproblem) Ich habe keine Erfahrung mit Flußkontrolle. Ich soll die Messeinheit für Testzwecke simulieren. Dazu warte ich auf die Anfrage der App und sende die Antwort zurück. Die App reagiert aber nicht. Sie ignoriert meine Antworten. Ich gehe mal davon aus dass das mit einer falschen Konfiguration zusammenhängt. Ich habe die Flusskontrolle auf Hardware gestellt, die Baudrate auf 921600 und die Paritätsbits auf keine (wie beim Abhören). Was habe ich vergessen?
Bevor die Antwort gesendet werden darf muß mit RTS die Bereitschaft signalisiert werden. Damit erkennt die App an ihrem CTS das Daten bereitstehen und fordert sie mit ihrem RTC an. Da die am CTS des Senders hängen weiß er das er loslegen kann. Die Handshakes sind überkreuz verbunden? Je CTS an RTS? evt mit dem Scope die Pegel prüfen.
Angeschlossen ist es wie folgt: App TestMessmodul(FTDI-Adapter) ========================================= RX TX TX RX RTS CTS CTS RTS Auf RTS und CTS habe ich doch keinen Einfluss. Macht das nicht der Treiber? Sobald ich mit dem 70 MHz Rigol drangehe bricht jede Kommunikation zusammen. Ich kann es höchsten noch mal mit dem alten 35 MHz Hameg versuchen... Ich habe Schrödingers Katze getötet!
Gast
#6125255
Andreas V. schrieb: > Sobald ich mit dem 70 MHz Rigol drangehe bricht jede Kommunikation > zusammen. Bild posten, mit Skalierung. Meist reicht ein Widerstand, um die Signale ein bisschen besser zu machen. Wie groß ist die Chance, dass die baudrate leicht unterschiedlich ist?
Gast
#6125259
Andreas V. schrieb: > Sobald ich mit dem 70 MHz Rigol drangehe bricht jede Kommunikation > zusammen. Mit was für einem Tastkopf und wie sieht die Signalform dabei aus?
Andreas V. schrieb: > Macht das nicht der Treiber? Theoretisch. Ich hab hier einen Ch340 der ignoriert das völlig. Auch wenn die Datenleitungen mit dem Scope nicht klarkommen die Handhakes sollte es nicht stören. Alternativ sie trennen an der App verbinden. Evt etwas verzögert antworten.
Ich habe mit meinem alten Hameg und einem 200MHz Billig-Tastkopf einen
Single-Shot gemacht. Da lief die Kommunukation durch.
Die Signale die ich sehe sind Rechtecke wie sie sein sollen.
Ich habe mit dem 400MHz DSView Logicanalyzer mit (Shunt)-Widerständen
noch mal nachgemessen. Da kommen die Antworten falsch.
Statt 08-0D-84-B7-84-CA-08-01 kommt dann
07-0D-84-B7-84-CA-08-01 Ack.
Das zweite Ack Paket kommt mit
08-0D-0D-42-ED-C8-08-02
dann richtig. Allerdings bricht die Kommunikation dann ab.
Hier scheinen einzelne Pakete verfälsch zu werden.
Einmal konnte ich mit dem Logic Analyzer sogar eine Anfangssequenz
aufzeichnen. Dummerweise habe ich es nicht gleich abgespeichert.
Das sah so aus als ob der Adapter Daten geschickt bekommt obwohl er noch
sendet und umgekehrt. In den Error ging er dann trotzdem.
Andreas V. schrieb: > Das sah so aus als ob der Adapter Daten geschickt bekommt obwohl er noch > sendet und umgekehrt. Nachtrag: Kann es sein dass der Sendebeginn und der Empfangsbeginn falsch getriggert werden? (Positive Flanke / negative Flanke)... Kann man das beeinflussen?
Gast
#6126305
Hast Du die GND verbunden. Wie lange ist das Schnittstellenkabel? Viel mehr wie ein Meter wird nicht funktionieren. Eine KO Sonde sollte RS232 eigentlich ohne Probleme vertragen...
Das ist ein standard FTDI Kabel mit 60cm Länge. GND ist verbunden! Habe schon daran gedacht das FTDI Kabel oder einen anderen Adapter direkt an die Schnittstelle zu löten.
Gast
#6126541
Andreas V. schrieb: > Statt 08-0D-84-B7-84-CA-08-01 kommt dann > 07-0D-84-B7-84-CA-08-01 Ack. also (nach Startbit) nur die ersten 4 Bit falsch herum? Mit oder ohne Parity? 0111000001 statt 0000100001 und der Rest perfekt? Da stimmt irgendwas anderes nicht, vermute ich...
Solange ich mit den beiden FTDI-Adapern nur lausche ist alles perfekt. Sobald ich den zweiten FTDI-Adapter abklemme, die Brücken zwischen Messeinheit und Android entferne: => dann kommt bricht die Kommunikation ab und der genannte Fehler mit den vier Bit tritt schon beim Empfangen auf. Ich kann mir das nur mit falschem Timing erklären. Flusskontrolle oder irgendeine Konfigration stimmt auch nicht. Wahrscheinlich kommen noch Bitfehler hinzu. Irgendetwas interpretiert Android anders als das was ich über die Leitung sende.
Ich glaube ich weiß was das Problem ist. Das Problem ist der Unterschied zwischen DTR und RTS. CTS ist gleich CTS. Kann es sein dass ein neues 1 MBaud Gerät mit Halbduplex läuft? Das habe ich übersehen. Korrekt wäre dann: App TestMessmodul(FTDI-Adapter) ========================================= RX TX TX RX RTS CTS CTS DTR GND GND Da habe ich was gleichgestzt was nicht gleich ist! Schade um die verschwendete Zeit. Es kann doch nicht sein... Den FTDI Adapter kann ich dann wohl erst nicht mehr gebrauchen... Der kann ja wohl nur Vollduplex! Das kriege ich so glaube ich nicht gelöst....
Mit einem Chinakracher FTDI-Adapter ohne Kabel habe ich es jetzt zuverlässig zum Laufen gebracht. Ich habe dann noch Breadboardkabel verwendet. Die Kabellänge ist jetzt ca. 8cm! Jetzt gehts auch mit dem Logic Analyzer messen. Ich sende eine Anfrage(Notification) ohne Sendeerlaubnis, bekomme eine korrekte Antwort(Ack) und dann geht die Android App in den Error Mode. Da muß ich noch nacharbeiten!
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.