Forum: Digitale Signalverarbeitung / DSP / Machine Learning Flowcontrol und UART


von Andreas V. (Firma: IGL) (andreas_va)


Lesenswert?

‭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?

von Achim H. (pluto25)


Lesenswert?

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.

von Andreas V. (Firma: IGL) (andreas_va)


Lesenswert?

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!

: Bearbeitet durch User
von A. S. (Gast)


Lesenswert?

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?

von Wolfgang (Gast)


Lesenswert?

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?

von Achim H. (pluto25)


Lesenswert?

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.

von Andreas V. (Firma: IGL) (andreas_va)


Lesenswert?

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.

von Andreas V. (Firma: IGL) (andreas_va)


Lesenswert?

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?

: Bearbeitet durch User
von zm (Gast)


Lesenswert?

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...

von Andreas V. (Firma: IGL) (andreas_va)


Lesenswert?

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.

von A. S. (Gast)


Lesenswert?

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...

von Andreas V. (Firma: IGL) (andreas_va)


Lesenswert?

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.

von Andreas V. (Firma: IGL) (andreas_va)


Lesenswert?

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....

von Andreas V. (Firma: IGL) (andreas_va)


Lesenswert?

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!

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
Noch kein Account? Hier anmelden.