Forum: Mikrocontroller und Digitale Elektronik oszi gemessen -> 31428 baud?


von Das R. (Firma: Verliererland) (verlierer)


Angehängte Dateien:

Lesenswert?

Hab heute mal versucht die seriellen Daten eines Drehmomentsensors eines 
Sunstar S03 Mittelmotor (pedelec) auszulesen.
Kann aber keine baudrate identifizieren.
Scheinen 3 byte im 100 Hz Takt zu sein (nicht 200 Hz wie im Foto)
Vielleicht kann hier jemand mehr aus dem Foto rauslesen :-)

: Bearbeitet durch User
von Forist (Gast)


Lesenswert?

Das R. schrieb:
> baudrate_pas.png
> 2,93 MB
Den Sonderpreis für Bildformate hast du schon mal abgestaubt.

von Martin (Gast)


Lesenswert?

Forist schrieb:
> abgestaubt.

Was übrigens auch ein gutes Stichwort ist, über das Du mal nachdenken 
solltest ;)

von MIDI (Gast)


Lesenswert?

Das R. schrieb:

Sind es vielleicht 31250 bps?

von Das R. (Firma: Verliererland) (verlierer)


Lesenswert?

> Sind es vielleicht 31250 bps?

Wäre das ein Standart ? Mir ist bei solchen Umgebungen eigentlich nur 
9600 oder 1200 über den Weg gelaufen.

Bei 28800 baud hakt der byte stream öfters, obwohl ja kontinuierlich 100 
mal pro Sekunde rund 3 byte gesendet werden:
Terminal log file
Date: 12.05.2020 - 14:51:53
-----------------------------------------------
EF FF FF FF EF FF FF FF 7F FF DF FF 7F FF FF
EF EF D7 FF FF FF DF FF EF EF EF FF 7F BF EF EF
EF FF FF FF FF FF FF FF DF FF FF FF FF FF EF FF
DF EF FF FF FF FF 7F EF EF EF FF DF EF FF FF FF
7F 7F ED EF EF EF FF FF FF FF FF FF EF FF FF BF
FF FF DF FF FF DF FF FF EF FF FF FF FF FF EF FF
FF EF ED FF FF DF EF EF FF FF FF EF FF DD EF DF
EF EF FF FF EF FF DF 7F FF FF FF EF FF BF EF FF
FF FF FF EF EF FF FF FF FF FF FF 7F EF EF EF 7F
FF EF EF EF EF FF EF DF FF FF FF 7F FF EF FF 7F
FF EF FF FF DF FF DF 7F FF EF FF EF FF FF FF EF
FF DF FF FF FF FF FF FF FF FF FF FF FF FF 7F EF
EF FF EF FF EF FF EF 7F FF FF EF 7F EF FF FF EF
BF FF FF FF EF CF FF EF FF FF EF FF FF EF FF FF
FF EF EF FF FF EF DF FF EF FF 7F 7F 7F EF EF BF
DF FF FF FF EF EF FF 7F FF EF FF FF FF FF FF EF
FF EF FF DF FF FF FF FF FF FF EF FF EF FF EF EF
EF FF 7F FF DF EF 7F EF FF FF FF FF FF FF FF EF
EF EF FF DF EF FF FF FF DF FF FF EF FF 7F FF EF
FF EF FF EF EF FF EF FF FF FF 7F FF EF FF 7F FF
EF BF FF FF DF DF EF EF EF FF DF FF FF FF DF EF
7F FF FF FF FF EF
-----------------------------------------------
Date: 12.05.2020 - 14:52:04
End log file


Hier die am oszi gemessenen 31428 baud:
Terminal log file
Date: 12.05.2020 - 14:55:24
-----------------------------------------------
FF FF BF FF FF FF DF 7F BF FF FF BF BF BF FF
FF FF FF FF DF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF DF FF FF FF FF FF FF FF FF FF BF
BF BF FF FF FF FD BF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF BF FF FF FF FF FF FF FF FF
BF FF FF FF BF FF FF FF FF FF FF FF FF FF BF FF
FF FF FF FF FD FF FD FD FF BF FF BD FF FF FF FF
FD FD FF FF FF FF FF BF FF FF FF FF FF FF FF FF
FF FF FF FF BF FF DF FF BD BF BF FF DF FF FF FD
FF BF BF FF BF FD FF FF FF FD FF FF FF FF FF BF
FF FF FD FF FF FF FF FF FF FF FF FF FF FD FF FF
FF FF FF FF BF FF FF FF BF FF FF BF FF FD FF FF
FF BF BD FF BF BF FF BF FF FF FF DF DF F7 FF FF
FF FD FF FD FF BF FF FF BF FF FF FF BF BF FF FF
FF FF FF FF EF FF FF FF DF FD FF FF FD FF DF FD
DF BF BF FF FF BF FF BF BF FF FF BF FF FF FF BF
FF FD FF BF FE FF FF FF FF FD FF FD FF FF FF FF
FF FF FF FF FF FF FF BF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FD FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FD FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF BF FF FF FF
FF FF DF FF BF FF FF DF FF FF BF BF BF FF DF FF
FF FD DF FF FF BF BF FF BF FF FF FF FF BF FF BF
FF FF FF BF BF DF DF FF FF FF FF FD DF BD FF BF
BF BF FF BF FF BF FF FF FF BF FF FF FF EF 7F FF
FF FF FF FF FF FF DF FF FF FF FF BF FF BF FF DF
FF FD BF FF FF FF FF FF BF FF FF BF FF FF FF FF
EF FF FF EF FF FF FF FF FF FF EF FF FF FF FF FF
FF FF FD FF FF BF FF FF FF FF FF FD BF FF FF FF
FF FF FF FF FF FF FF BF FF FF FF FF FF FF FF FF
FF BF FF FF BF FF FF FF FF FF FF FF FF FF FF
-----------------------------------------------
Date: 12.05.2020 - 14:55:31
End log file

Da in der Nähe die ungewöhnlichen 32768 baud:
Terminal log file
Date: 12.05.2020 - 14:54:28
-----------------------------------------------
FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF BF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF BF FF FF FF FF FF
FF BF BF BF FF BD FF FF FF FF FF FF FF FF BD BF
BF FF FF BF FF FF FF FF BF FF FF FF FF FF FF EF
FF FF FF DF FF BF BF B7 FF FF DF FF BF FF FF BF
BF BF FF BF FF FF FF FF FF EF FF FF FF FF FF FF
FF FF FF BF FF FF FF FF FF FF FF FD FF FF FF FF
FF FF FF FF FF FF FF FF FF FF BF FF BF FF FF FF
FF FF FF FF FF FF BF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF BF BF FF FF EF BF FF BF BF
BF 3F BF BF FF FF FF FF FF FF FF BF FF FF FF FF
FF BF DF BD BF FF EF FD AF FF DF BF FF FF BF FF
BF FF BF BF FF BF FF FF FF BF BF FF FF FF FF FF
FF FD FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF BF BF FF BF FF FF FF FF FD FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FD FF FF FF
FF FF FF FF FF FF FF BF FF BF FF FF FF FF FF FF
FF FF FF BF FF FF FF FF FF FF FF FF FF FF FF FF
BF FF FF FF FF FF FF FF FF FF FF BF BF FF FF BF
FF FF FF FF FF FF BF BF BF BF BF BD BF BF FF FF
FF FD FF FF FF DF FF FF FF BF BF FF FF FF FF BD
FF FF BF BF FF FF FF FF FF BF BF FF DF FF FF FF
FF FF FF FF FF BF FF BF FF FF BF FF BD FF FF BF
FF FF BF FF BF BF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF BF FF FF FF FF FF FF FF FF FF
FF FF FF FF FD FF FF FD FF FF FF FF FF FF FF FF
FF FF FF FD FF BF FF FF FF FF FF FF FF BF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF BF FF BF FF FF FF FF FF
BF FF FF BF BF BD FF DF FD FF DF FF FF FF BF FF
BF BF FF FF BF FF FF BF FF FF FF FF FF FF FF FF
FF FF FF FF FF DF FD FF BD FF BF FF FF FF BF FF
BF FF FF FF BF FF FF AF FD FF FD FD BF FF FF FF
FF FF FF FF FF FF FF FF FF FD FF FF FF FF FF FF
BF FF FF FF FF FF BF FF BF FF FF FF FF FF FF FD
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FD
FD FF FF FF FF FF FF FF FF FF FF BF BF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF BF FF FF FF FF FF FF EF
FF BF FF BF FF BF FF FF FF FF FF FF FF FF FF BF
FF BF BF BD FF FF BF FF FF FF BF FF FF FF FF BF
FF FF BF FF BF BD FF FF BD FF BF FF FF FF FD AF
FF FF FF FF DF FF FF FF FF FF BF BF FF FF FF DF
FF FF BF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF BF BF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF BF
FF
-----------------------------------------------
Date: 12.05.2020 - 14:54:35
End log file


Dann 38400 baud:
Terminal log file
Date: 12.05.2020 - 14:52:17
-----------------------------------------------
FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF BF BF BF FF FF FF FF FF BF FF BF
FF FF FF BF FF FF FF FF DF DF FF BF FF FF FF DF
FD BF FF BF FF FF EF FF DF FF BD 9F BF FF FF BF
FF FF BF FF FF BF FF BF FF FF FF FF FD FF FF FF
FF FF FF FF EF BF BF FF BF FF FF BF BF FF FF FF
FF FF FF FF FF FF BF BF FF FF FF FF FF FF FF FF
FF FF BF BF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF DF FF FD FF BF BF BF BF
FF FF FF FF DF FF BF BF DF BF BF BF FF BF FF FF
FF FF FF EF FF FF FF DF FF FF FF FF FF BF FF FF
F7 BF FF 3F FF FF FF FF FF FF FF FF FF FF FF BF
FF BF FF BF BF FF BF FF FF FF FF FD FF FF FF FF
FF FF FD FF FF FF FF FF BF FF BF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FD FF FF BF FF
FF BF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF BF FF FF FF FF FF FF
FF BF BF BF FF FF FF FF FF FF FF FF FF BF BF FF
BF FF FF FF BF BF BD BF BF BF BD FF FF FF FF FF
FF FF FF FF FF BF FF FF BF FF BF FF DF BF FF FF
FF FF FF EF FF FF FF FF FF FF FF FF FF FF BF FF
FF FF FF BF EF FF FF BF FF FF FF FF FD FF FF FF
FF BF F7 FE FF FF FF FF FF FF FF FF FF 7F FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF BF FF
FF FF FF FF FF BF FF FF FF FF FF BF FF FF FF FF
BF FF BF BF FF BF 3F FF FF AF FF FF BF FF BF BF
FF FF FF FF DF
-----------------------------------------------
Date: 12.05.2020 - 14:52:22
End log file


und 56000 baud:
Terminal log file
Date: 12.05.2020 - 14:52:33
-----------------------------------------------
BF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF BF EF FF FF FF FF
FF FF FF FF FF EF FF FF FF FF FF EF FF FF BF FF
FF FF FF FF FF FF FF EF F7 BF FF FF FF EF FF FF
EF FF FF FF FF FF FF FF FF EF FF EF FF BF FF FF
FF FF FF FF FF FF FF FF FF FF EF FF FF FF FF EF
FF FF F7 FF FF FF FF EF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FE FF FF BF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF BF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF EF
FF FF FF FF FF FF FF FF BF FF FF FF FF FF FF FF
FF FF FF FF DF FF BF FF EF FF FF FF FF FF FF FF
FF FF FF FF EF FF FF FF FF FF FF FF FF EF FF FF
FF EF FF FF FF FF FF FF FF FD FF FF FF FF FF FF
FF EF FF FF FF FF EF FF EF FF FF FF FF FF FF FF
FF FF EF BF FF FF FF FF FF FF FB FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF EF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF BF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FE FF FF FF FF FF
FF FF FF FF FF FF FF FF FF EF FF FF FF EF FF FF
FF FF EF FF EF FF FF FF EF EF FF FF EF FF EF FF
FF FF FF FF FF FF FF FF FF FF FF FF EF FF FF FF
FF EF FF FF FF FF EF FF EF FF FF EF EF FF FF EF
FF FF BF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF BF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF EF FF FF FF FF EF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF BF FF
EF EF FF FF FF FF BF FF BF FF BF FF FF BF FF FF
FF BF FF FF FF FF FF BF FF FF FF FF FF FF FF EF
FF FF FF FF FF FF FF FF FF FF EF FF FF FF FF FF
FF BF FF FF FF FF FF FF FF BF FF FF FF FF FF FF
EF FF FE FF FF FF FF FF FF FF FF FF FF FF FF EF
FF EF FF FF FF FF FF FF FF FF FF FF FF FF EF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF EF FF EF FF FF FF FF BF FF FF FF BF
FF BF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF BF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF BF FF FF FF
FF FF FF FF FF FF FF FE FF FF FF EF FF FF FF FF
FF FF FF BF FF FF FF FF FF FF FF FF FF FF FF EF
FF FF FF FF FF EF FF FF EF FF FF FF FF FF EF EF
FF FF FF FF F7 FF FF FF FF FE FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
EF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF EF FF FF FF FF FF EF FF EF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF BF FF FF
-----------------------------------------------
Date: 12.05.2020 - 14:52:40
End log file

Nichts ergibt für mich Sinn.
Müsste jetzt mal den softwareserial von einem Arduino Mini 
programmieren, der kommt vielleicht besser mit ungewohnten baudraten 
zurecht.


das Roland
Ideen immer zu mir :-)

"Versager lachen wenn ihnen nichts einfällt. Da Versagern nie etwas 
einfällt, lachen sie immer."

von Yalu X. (yalu) (Moderator)


Lesenswert?

Das R. schrieb:
>> Sind es vielleicht 31250 bps?
>
> Wäre das ein Standart ?

Schau dir den Namen des Users "MIDI" an. Ja, genau dort sind die 31250
Standard. 31250 = 1e6 / 2⁵. Man kann diese Baudrate damit aus "glatten"
Taktfrequenzen wie 1MHz, 2MHz, 4MHz oder 8Mhz einfach durch fortgesetzte
Halbierung mittels Flipflops ableiten.

Für die interne Kommunikation wie in deinem Pedelec gibt es keinen
Grund, sich an Baudratenstandards aus dem Analaogmodembereich zu
orientieren.

Das R. schrieb:
> Nichts ergibt für mich Sinn.

Ich würde mal 31250 baud, 8 Datenbits, ungerade Parität und 1 Stoppbit
probieren.

: Bearbeitet durch Moderator
von Das R. (Firma: Verliererland) (verlierer)


Angehängte Dateien:

Lesenswert?

Yalu X. schrieb:
> Ich würde mal 31250 baud, 8 Datenbits, ungerade Parität und 1 Stoppbit 
probieren.

Ja prima und Danke Euch Zwei. Das sieht schon mal besser aus:
1
F7 01 07 01 28 00 00 18 39 06 F7 01 07 01 28 00 
2
01 00 00 E8 CF 06 F7 00 F9 01 28 00 01 09 CF 00 
3
37 00 39 01 28 00 00 3E 86 18 80 00 07 
4
01 28 00 01 19 CF 06 F7 01 07 
5
01 28 00 00 18 39 06 F7 01 07 
6
01 28 00 
7
01 28 00 01 19 CF 06 F7 01 07 
8
01 28 00 00 E8 CF 06 F7 00 F9 
9
01 28 00 01 09 CF 00 37 00 39 
10
01 28 00 00 3E 86 18 80 00 07 
11
01 28 00 01 19 CF 06 F7 01 07 
12
01 28 00 00 18 39 06 F7 01 07 
13
01 28 00 01 E8 00 00 18 39 06 F7 01 07 
14
01 28 00 01 19 CF 06 F7 01 07 
15
01 28 00 00 E8 CF 06 F7 00 F9 
16
01 28 00 01 09 CF 00 37 00 39 
17
01 28 00 00 3E 86 18 80 00 07 
18
01 28 00 01 06 F7 01 07 01 E8 00 00 18 39 06 F7 01 07 
19
01 28 00 01 19 CF 06 F7 01 07 
20
01 28 00 00 E8 CF 06 F7 00 F9 
21
01 28 00 01 09 CF 00 37 00 39 
22
01 28 00 00 3E 86 18 80 00 07 
23
01 28 00 01 19 CF 06 F7 01 07 
24
01 28 00 00 18 39 06 F7 01 07 
25
01 28 00 01 F7 01 07 
26
01 28 00 00 E8 CF 06 F7 00 F9 
27
01 28 00 01 09 CF 00 37 00 39 
28
01 28 00 00 3E 86 18 80 00 07 
29
01 28 00 01 19 CF 06 F7 01 07 
30
01 28 00 00 18 39 06 F7 01 07 01 28 00 01 
31
F7 00 F9 01 28 00 01 09 CF 00 37 00 39 01 28 00 
32
00 3E 86 18 80 00 07 01 28 00 01 19 CF 06 F7 01
Parity odd oder even scheint mir keinen Unterschied zu machen.
Wichtig ?

Vielleicht hat jemand schon eine Idee zum Protokoll
Selten kommen ja 3 Byte. Meist aber wohl 10 :-/
Im Grunde müssten nur ein oder zwei Bytes für den Drehmomentwert 
gesendet werden.

Im Oszi seh ich aber die gleichlangen Pakete alle 10ms, siehe Foto.

das Roland und Dankeschön

von Yalu X. (yalu) (Moderator)


Lesenswert?

Das R. schrieb:
> Das sieht schon mal besser aus:

Da scheinen einige Lücken in den Daten zu sein.

Womit hast du diese Daten aufgezeichnet? Mit dem PC?

Mit welcher Software?

Mit welcher Schnittstelle bzw. mit welchem Schnittstellenadapter?

Wenn mit Schnittstellenadapter: Arbeitet dieser mit TTL-Pegeln oder mit
positiven und negativen Pegeln gemäß RS-232? Wenn du dir nicht sicher
bist: Lade ein Foto von dem Adapter hoch.

Das R. schrieb:
> obwohl ja kontinuierlich 100 mal pro Sekunde rund 3 byte gesendet
> werden

Wie kommst du auf 3 Bytes?

Stell doch dein Oszi mal auf 0,2ms/Div ein. Damit kannst du etwa 70%
eines kompletten Datenpakets sehen. Verschiebe nun das Signal auf dem
Display nacheinander so, dass man einmal die ersten 70% und einmal die
letzten 70% des Datenpakets sehen kann, und mache jeweils ein Foto
davon.

Daraus kann man dann die einzelnen Bytes der Datenpakets manuell
dekodieren und mit den am PC aufgezeichneten Daten vergleichen.

von Das R. (Firma: Verliererland) (verlierer)


Angehängte Dateien:

Lesenswert?

Yalu X. schrieb:
> Womit hast du diese Daten aufgezeichnet? Mit dem PC?

billiges usb uart dongle

> Mit welcher Software?

nettes windows terminal: https://sites.google.com/site/terminalbpp/

> Mit welcher Schnittstelle bzw. mit welchem Schnittstellenadapter?

siehe foto.

> Wenn mit Schnittstellenadapter: Arbeitet dieser mit TTL-Pegeln oder mit
> positiven und negativen Pegeln gemäß RS-232? Wenn du dir nicht sicher
> bist: Lade ein Foto von dem Adapter hoch.

Hab nur Masse und RX verbunden.
Normalerweise zieht der sender das signal auf masse um eine 1 zu senden 
?!


> Wie kommst du auf 3 Bytes?

Oh danke Du hast natürlich recht. Siehe Fotos für komplette Daten.

> Stell doch dein Oszi mal auf 0,2ms/Div ein. Damit kannst du etwa 70%
> eines kompletten Datenpakets sehen. Verschiebe nun das Signal auf dem
> Display nacheinander so, dass man einmal die ersten 70% und einmal die
> letzten 70% des Datenpakets sehen kann, und mache jeweils ein Foto
> davon.

Oh ja hatte schon wieder vergessen, dass ich auf dem Pocket DSO auch 
scrollen kann :-)

> Daraus kann man dann die einzelnen Bytes der Datenpakets manuell
> dekodieren und mit den am PC aufgezeichneten Daten vergleichen.


Puhhhh !!
Hab jetzt schon den ganzen Vormittag damit verbracht und komme nicht 
wirklich weiter.
Die https://de.wikipedia.org/wiki/Paritätsbit  passen nicht.

Wie wird eigentlich der Begin der Daten markiert ?
Hab versucht durch zusätzliche Nullen am Anfang die Stopbits 
hinzubekommen aber klappt nicht.

Wie funktionieren denn 1,5 oder 2 Stopbits ?

Wenn die baudrate von midi kommt, vielleicht werden auch nicht bytes 
sondern nur 7 bit übertragen ?

Ich komme jetzt nicht weiter :-/
1
111001011
2
101000101
3
110011111
4
111100100
5
011110001
6
111111110
7
010011110
8
000111111
9
111001110
10
101110011
11
111111100
12
101111111
13
100000000
14
15
16
12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 
17
111001011101000101110011111111100100011110001111111110010011110000111111111001110101110011111111100101111111100000000
18
        5        3        6        5 :-( eine 1 einfügen
19
20
12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 
21
111001011101000101110011111X111100100011110001111111110010011110000111111111001110101110011111111100101111111100000000
22
        5        3        6        7        4        8 :-(
23
24
drei Nullen am Anfang einfügen:
25
12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 
26
000111001011101000101110011111111100100011110001111111110010011110000111111111001110101110011111111100101111111100000000
27
        3        4        5        7 :-( eine 1 einfügen
28
29
12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 
30
0001110010111010001011100111111111X00100011110001111111110010011110000111111111001110101110011111111100101111111100000000
31
        3        4        5        8        4 :-(               
32
33
sieben Nullen am Anfang einfügen:
34
12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 
35
0000000111001011101000101110011111111100100011110001111111110010011110000111111111001110101110011111111100101111111100000000
36
        1        5        4 :-(

von Das R. (Firma: Verliererland) (verlierer)


Angehängte Dateien:

Lesenswert?

hab die baudrate neu vermessen: 31143 baud :-/
siehe Foto.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Das R. schrieb:
>> Sind es vielleicht 31250 bps?
> Wäre das ein Standart ?
Warum sollte ein Hersteller bei diesem systeminternen Interface eine 
"Standard"-Baudrate verwenden?
Wenn ich eine Schnittstelle machen wollte, die rudimentär geschützt sein 
sollte, dann würde ich explizit keine Standard-Baudrate verwenden. Das 
würde unbedarfte Hacker schon mal vor eine gewisse Hürde stellen.

Und ja: das Oszi sollte eindeutig mal feucht durchgewischt werden. Dann 
werden auch die PNG Screenshotdateien(*) kleiner, weil nicht jeder 
Fussel extra komprimiert werden muss.

Yalu X. schrieb:
> Das R. schrieb:
>> Nichts ergibt für mich Sinn.
> Ich würde mal 31250 baud, 8 Datenbits, ungerade Parität und 1 Stoppbit
> probieren.
Das liegt nahe genug an der berechneten Baudrate (ich komme da mit 31 
Bits sogar auf 31,6kBd). Und vorher sicherstellen, dass das verwendetete 
Abhörinterface diese Baudrate auch tatsächlich kann und nicht einfach 
die "nächstgelegene" Baudrate wie z.B. 28800Bd verwendet.

> Daraus kann man dann die einzelnen Bytes der Datenpakets manuell
> dekodieren und mit den am PC aufgezeichneten Daten vergleichen.
Wenn ich mir diese Daten ansehe, dann passt da rein gar nix zum ersten 
Bild im Thread. Da wird ganz offensichtlich dreimal ein 11 Bit langes 
Protokoll übertragen. Und zwar in TTL-Pegeln, also mit High=Ruhepegel. 
Ich lese dort (mit LSB first) 9D 97 00 ab.


(*) BTW: hat das Oszi keinen USB-Anschluss für richtige Screenshots?

: Bearbeitet durch Moderator
von Das R. (Firma: Verliererland) (verlierer)


Lesenswert?

Ah ich hab das Startbit vergessen. Das hilft mir aber auch nicht weiter:
1
 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345678 
2
1110010111010001011100111111111001000111100011111111100100111100001111111
3
         5        3        6 :-(
4
5
restlichen bits:
6
12345678 12345678 12345678 12345678 12345678
7
11001110101110011111111100101111111100000000

: Bearbeitet durch User
von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Das R. schrieb:
> siehe Foto.
Du verwendest m.E. falsche Pegel.
Auf der Logikseite ist 1 = 5V und 0 = 0V bei einem Ruhepegel von 5V. Und 
so sieht das auf deinen Oszibildern auch aus.

Nur auf der RS232-Seite gilt >+3V = 0 und <-3V = 1 mit einem Ruhepegel 
von <-3V.

Siehe z.B. das da:
https://www.studerundrevox.de/wp-content/uploads/RS-232_timing.png

Yalu X. schrieb:
> Wenn mit Schnittstellenadapter: Arbeitet dieser mit TTL-Pegeln oder mit
> positiven und negativen Pegeln gemäß RS-232? Wenn du dir nicht sicher
> bist: Lade ein Foto von dem Adapter hoch.
Tu das mal...

: Bearbeitet durch Moderator
von Das R. (Firma: Verliererland) (verlierer)


Angehängte Dateien:

Lesenswert?

> Du verwendest m.E. falsche Pegel.
> Auf der Logikseite ist 1 = 5V und 0 = 0V bei einem Ruhepegel von 5V. Und
> so sieht das auf deinen Oszibildern auch aus.

Mein usb-uart dongle interessiert ja jetzt erstmal nicht. Ich soll doch 
einfach nur die oszi-bilder manuell auswerten. Das dongel hängt also gar 
nicht mehr dran.
Da ja 100 mal pro Sekunde rund 97 bits gefunkt werden, ist doch 
offensichtlich 5V = bit 0.
So kenne ich das auch von all meinen arduino projekten. Zum senden einer 
1 wird der Pegel auf Masse gezogen.
Mit rs232 hat das wohl schon seit jahren nichts mehr zu tun.


>> bist: Lade ein Foto von dem Adapter hoch.
> Tu das mal...

hab ich doch schon gemacht.

Anbei ein Foto mit Startbit.
Es ist nicht möglich, ein Stopbit mit doppelter Breite zu verwenden, da 
dann das erste Stopbit sowohl 1 als auch 0 wäre.

Die Stopbits mit 1,5 facher Länge scheint mir auch nicht zu passen.

Zumal das dritte byte der KO Schlag ist.
Dessen Stopbit wird immer 1 sein, das byte aber immer nur genau zwei 
Nullen enthalten :-(

Ich müsste jetzt mit 6bit oder 7bit für die Daten probieren ?

das Roland und :-(

von Yalu X. (yalu) (Moderator)


Lesenswert?

Hier sind die dekodierten Daten:

1
n Start   Data   Parity Stop hex
2
————————————————————————————————
3
0   0   00110100    0     1   2c
4
1   0   11101000    1     1   17
5
2   0   00000000    1     1   00
6
3   0   11100001    1     1   87
7
4   0   00000000    1     1   00
8
5   0   11000011    1     1   c3
9
6   0   00000000    1     1   00
10
7   0   00101000    1     1   14
11
8   0   00000000    1     1   00
12
9   0   10000000    0     1   01
13
————————————————————————————————

Die Start-/Stoppbits und die ungerade Parität passen für alle 10 Bytes,
weswegen das alles schon ziemlich richtig aussieht.

Jetzt wäre es gut, wenn das Aufzeichnen mit dem UART-Adapter zuverlässig
funktionieren würde, so dass man auch längere Datenreihen analysieren
kann. Man kann dann bspw. nachschauen, welche der 10 Bytes jedes
Datenpakets sich wie ändern, wenn man auf den Sensor ein Drehmoment
ausübt.

: Bearbeitet durch Moderator
von Das R. (Firma: Verliererland) (verlierer)


Angehängte Dateien:

Lesenswert?

zurückgezogen.

: Bearbeitet durch User
von Yalu X. (yalu) (Moderator)


Lesenswert?

Der verwendete USB-UART-Konverter sieht für den vorliegenden Zweck
geeignet aus. Normalerweise sind diese Adapter, was die einstellbaren
Baudraten betrifft, sehr flexibel, so dass er auch die 31250 baud können
sollte. Um aber sicherzustellen, dass diese Baudrate auch vom Treiber,
dem Betriebssystem und der Terminalsoftware unterstützt werden, kannst
mit dem Terminalprogramm bspw. das Zeichen 'U' senden und mit dem Oszi
am TXD-Pin des Adapters das Signal messen.

Du solltest folgendes Signal sehen, wobei jeder der kurzen Low- und
High-Impulse 1 Bit entspricht:

1
_____ _ _ _ _ _______
2
     _ _ _ _ _
3
4
111110101010101111111

Daraus kannst du wie gehabt die Baudrate ermitteln und schauen, ob sie
in etwa der des Sensors entspricht.

von Das R. (Firma: Verliererland) (verlierer)


Angehängte Dateien:

Lesenswert?

Oh ja danke, inzwischen hab ich 
https://de.wikipedia.org/wiki/Universal_Asynchronous_Receiver_Transmitter 
so halbwegs durchgelesen.

Es wird also jedes einzelen byte in ein startbit + paritätsbit + endbit 
verpackt. Wobei startbit das inverse des endbit ist.

Und das Startbit hat laut UART den logischen Wert 0 !!!
Die erste Flanke muss das Startbit sein.
Also ist 0V doch 0 und 5V logisch 1.

Damit komme ich mit meinem neusten Bild auch auf Deine Daten :-)

Yalu X. schrieb:
> Hier sind die dekodierten Daten:
>
1
> n Start   Data   Parity Stop hex
2
> ————————————————————————————————
3
> 0   0   00110100    0     1   2c
4
> 1   0   11101000    1     1   17
5
> 2   0   00000000    1     1   00
6
> 3   0   11100001    1     1   87
7
> 4   0   00000000    1     1   00
8
> 5   0   11000011    1     1   c3
9
> 6   0   00000000    1     1   00
10
> 7   0   00101000    1     1   14
11
> 8   0   00000000    1     1   00
12
> 9   0   10000000    0     1   01
13
>

Laut UART sind die erste 4 bit aber low und die folgenden 4 bit high.
Damit komme ich auf
1
n Start low high   Parity Stop hex
2
————————————————————————————————
3
0   0   0011 0100    0     1   47
4
1   0   1110 1000    1     1   8e
5
2   0   0000 0000    1     1   00
6
3   0   1110 0001    1     1   1e
7
4   0   0000 0000    1     1   00
8
5   0   1100 0011    1     1   3c
9
6   0   0000 0000    1     1   00
10
7   0   0010 1000    1     1   82
11
8   0   0000 0000    1     1   00
12
9   0   1000 0000    0     1   08

Keine unserer hex folgen kommt in meinem 31250 baud log vor :-/

Aber jetzt kann ich das dongle wieder dran hänngen und mit den baudraten 
spielen.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Das R. schrieb:
> Und das Startbit hat laut UART den logischen Wert 0 !!!
> Die erste Flanke muss das Startbit sein.
Die Flanke an sich ist gar nichts. Sie trennt nur das Startbit vom 
nullten Datenbit.

> Keine unserer hex folgen kommt in meinem 31250 baud log vor :-/
Mach die Sache mit dem Senden eines 'U' und miss aus, was dein 
USB-Wandler sendet, und prüfe ob er die gewünschte Baudrate überhaupt 
senden kann.

: Bearbeitet durch Moderator
von Yalu X. (yalu) (Moderator)


Lesenswert?

Das R. schrieb:
> Damit komme ich auf
> n Start low high   Parity Stop hex
> ————————————————————————————————
> 0   0   0011 0100    0     1   47

Nein, die 8 Datenbits werden in der Reihenfolge b0, b1, b2, b3, b4, b5,
b6, b7 übertragen, wobe b0 das niederwertigste und b7 das höchstwertige
Bit ist. In der üblichen Schreibweise für Binärzahlen (höchstwertiges
Bit zuerst, also in umgekehrter Reihenfolge) entspricht die obige
Datenbitfolge der Zahl 00101100 (bin) = 2C (hex).

von Das R. (Firma: Verliererland) (verlierer)


Lesenswert?

Yalu X. schrieb:
> Der verwendete USB-UART-Konverter sieht für den vorliegenden Zweck
> geeignet aus. Normalerweise sind diese Adapter, was die einstellbaren
> Baudraten betrifft, sehr flexibel, so dass er auch die 31250 baud können
> sollte. Um aber sicherzustellen, dass diese Baudrate auch vom Treiber,
> dem Betriebssystem und der Terminalsoftware unterstützt werden, kannst
> mit dem Terminalprogramm bspw. das Zeichen 'U' senden und mit dem Oszi
> am TXD-Pin des Adapters das Signal messen.
>
> Du solltest folgendes Signal sehen, wobei jeder der kurzen Low- und
> High-Impulse 1 Bit entspricht:
>
>
>
1
> _____ _ _ _ _ _______
2
>      _ _ _ _ _
3
> 
4
> 111110101010101111111
5
>
>
> Daraus kannst du wie gehabt die Baudrate ermitteln und schauen, ob sie
> in etwa der des Sensors entspricht.

Ja das "U" kommt am Oszi an.
Aber die "custom baud rate" nicht.
Entweder ist das Terminal Programm buggy oder das dongle kann nicht.
Irgendwie ändert sich zwar schon die Frequenz wenn ich bei "custom BR" 
was ändere, aber wenn ich 31250 eintrage kommt am oszi das selbe wie 
wenn ich 38400 baud auswähle.

Das reicht mir für heute. Der ganze Tag ist hierfür drauf gegangen :-(
Morgen programmiere ich mal Softwareserial von Arduino Nano, das würde 
dann eh die Anwendung sein.

SoftwareSerial kann zum Glück 31250 baud: 
https://www.arduino.cc/en/Reference/SoftwareSerialBegin

Dann leite ich die Daten mit 115200 baud an den Arduino Serial Monitor 
weiter.

So kann ich wohl auch die 100 Hz Pakete erkennen und die Daten anordnen.

Wenn das klappt kann ich endlich an der Tretkurbel biegen und sehen 
welche Bytes sich ändern.

das Roland aka Robo Durden und https://youtu.be/60rfgUiHgkE

von Hmmm (Gast)


Lesenswert?

Das R. schrieb:
> Da ja 100 mal pro Sekunde rund 97 bits gefunkt werden, ist doch
> offensichtlich 5V = bit 0.
> So kenne ich das auch von all meinen arduino projekten. Zum senden einer
> 1 wird der Pegel auf Masse gezogen.

Das ist Unsinn.

Die Ruhelage entspricht einer 1, in diesem Fall 5V. Das Startbit ist 
immer 0 (hier 0V), danach folgen die Daten- und Parity-Bits. Das 
Stop-Bit wiederum ist immer 1, entspricht also der Ruhelage.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Das R. schrieb:
> das dongle kann nicht.
Das war zu vermuten angesichts des offensichtlichen Alters des Geräts... 
?

Nochmal einen kleinen Schritt zurück zu dem, was
Das R. schrieb:
> Wobei startbit das inverse des endbit ist.
Das Startbit ist "das Inverse" vom Ruhepegel, damit nach einer 
Übertragungspause der Telegrammanfang erkannt werden kann.
Das Stopbit ist ein Teil der Übertragungspause, oder bei 
kontinuierlicher Übertragung sogar die gesamte Pause.

: Bearbeitet durch Moderator
von Das R. (Firma: Verliererland) (verlierer)


Lesenswert?

Ja, mit dem Arduino Nano scheint es auf anhieb zu funktionieren:
1
#include <SoftwareSerial.h>
2
SoftwareSerial oSerial(2,3); // RX, TX
3
4
#define NUM_READ 256
5
uint8_t aRead[NUM_READ];
6
uint16_t iRead = 0;
7
8
void setup() 
9
{
10
  Serial.begin(115200);
11
  oSerial.begin(31250);
12
  Serial.println("Sunstar 2020 :-)");
13
}
14
15
unsigned long iLast = millis();
16
void loop() {
17
  unsigned long iNow = millis();
18
19
  if (oSerial.available())
20
  {
21
    char c = oSerial.read();
22
    if ((iNow-iLast) > 5)
23
    {
24
      for (int i=0; i<iRead; i++)
25
      {
26
        Serial.print(" "); Serial.print(aRead[i],HEX);
27
      }
28
      Serial.println();
29
      iRead = 0;
30
    }
31
    aRead[iRead++] = c;
32
    if (iRead == NUM_READ)  iRead = 0;
33
    iLast = iNow;
34
  }
35
}

ohne Kurbelbelastung:
1
 6D 97 0 47 0 23 0 E4 0 0
2
 6C 97 0 47 0 23 0 E4 0 1
3
 6D 97 0 47 0 23 0 E4 0 0
4
 6C 97 0 47 0 23 0 E4 0 1

Anfang der Belastung:
1
AD 97 0 47 0 C3 0 E4 0 0
2
 AC 97 0 47 0 C3 0 E4 0 1
3
 AD 17 0 47 0 23 0 E4 0 0
4
 EC 17 0 47 0 63 0 E4 0 1
5
 9D 17 0 7 0 53 0 E4 0 0
6
 A2 37 0 87 0 8B 0 E4 0 1
7
 AB 4F 0 67 0 6B 0 E4 0 0
8
 DA 2F 0 17 0 1B 0 E4 0 1
9
 7B AF 0 97 0 9B 0 E4 0 0
10
 7A AF 0 97 0 9B 0 E4 0 1
11
 7B AF 0 97 0 9B 0 E4 0 0
12
 6 6F 0 97 0 5B 0 E4 0 1
13
 7 6F 0 97 0 5B 0 E4 0 0
14
 6 6F 0 97 0 5B 0 E4 0 1
15
 47 6F 0 57 0 DB 0 E4 0 0
16
 C6 EF 0 57 0 DB 0 E4 0 1
17
 C7 EF 0 57 0 DB 0 E4 0 0
18
 A6 EF 0 D7 0 3B 0 E4 0 1
19
 A7 EF 0 D7 0 3B 0 E4 0 0
20
 66 1F 0 D7 0 3B 0 E4 0 1
21
 E7 1F 0 37 0 3B 0 E4 0 0
22
 96 9F 0 37 0 BB 0 E4 0 1
23
 97 9F 0 37 0 BB 0 E4 0 0
24
 96 9F 0 37 0 BB 0 E4 0 1

mit wohl mehr Belastung des Drehmomentsensors:
1
 7 20 80 8F 3A E7 0 E4 0 1
2
 FA C0 80 8F 3A E7 0 E4 0 0
3
 87 20 80 8F 3A 17 0 E4 0 1
4
 6 20 80 8F 3A E7 0 E4 0 0
5
 7 20 80 8F 3A E7 0 E4 0 1
6
 86 20 80 8F 3A 17 0 E4 0 0
7
 7 20 80 8F 3A E7 0 E4 0 1
8
 6 20 80 8F 3A E7 0 E4 0 0
9
 87 20 80 8F 3A 17 0 E4 0 1
10
 6 20 80 8F 3A E7 0 E4 0 0
11
 7 20 80 8F 3A E7 0 E4 0 1
12
 6 20 80 8F 3A E7 0 E4 0 0
13
 87 20 80 8F 3A 17 0 E4 0 1
14
 86 20 80 8F 3A 17 0 E4 0 0
15
 7 20 80 8F 3A E7 0 E4 0 1
16
 86 20 80 8F 3A 17 0 E4 0 0
17
 87 20 80 8F 3A 17 0 E4 0 1
18
 86 20 80 8F 3A 17 0 E4 0 0

Wieder ohne Belastung:
1
 6D 97 0 47 0 23 0 E4 0 0
2
 AC 17 0 47 0 23 0 E4 0 1
3
 6D 97 0 47 0 23 0 E4 0 0
4
 6C 97 0 47 0 23 0 E4 0 1
5
 AD 97 0 47 0 C3 0 E4 0 0
6
 B4 17 0 FB 0 FD 0 E4 0 1

Jetzt muss ich nur noch die ersten 6 byte entziffern.

das Roland und :-)

von Yalu X. (yalu) (Moderator)


Lesenswert?

Weißt du, was der Sensor alles misst und wie er intern aufgebaut ist?
Von einem einfachen Drehmomentsensor würde ich als Messergebnis einen
einzelnen Zahlenwert erwarten, wofür man aber keine 10 Bytes braucht.
Misst vielleicht noch die Kurbeldrehzahl oder noch irgendwelche anderen
Größen?

Ich habe so eine leise Idee, wie die Zahlenwerte kodiert sein könnten,
aber so richtig schlüssig ist das Ganze noch nicht. Könntest du eine
weitere Messreihe aufnehmen, bei der das Drehmoment und kontinuierlich
von 0 bis zu einem möglichst großen Wert gesteigert wird und danach
wieder kontinuierlich bis auf 0 abfällt? Da die Datei dadurch recht groß
werden wird, kannst du sie hier ja als Anhang posten.

von Das R. (Firma: Verliererland) (verlierer)



Lesenswert?

Yalu X. schrieb:
> Misst vielleicht noch die Kurbeldrehzahl oder noch irgendwelche anderen
> Größen?

Oh gute Idee !
Ja die Werte sprudeln auch wenn man die Kurbel ohne Drehmoment dreht. 
Wenn man dann aufhört, dauert es so eine Sekunde, dann kommen wieder 
statische Werte.
>
> Ich habe so eine leise Idee, wie die Zahlenwerte kodiert sein könnten,
> aber so richtig schlüssig ist das Ganze noch nicht. Könntest du eine
> weitere Messreihe aufnehmen, bei der das Drehmoment und kontinuierlich
> von 0 bis zu einem möglichst großen Wert gesteigert wird und danach
> wieder kontinuierlich bis auf 0 abfällt? Da die Datei dadurch recht groß
> werden wird, kannst du sie hier ja als Anhang posten.

Der Mittelmotor ist nur mit Schraubzwinge an Tisch geklemmt, sowie am 
Kettenblatt und als Kurbelersatz je eine Gripzange.
Um Drehmument zu testen halte ich also die Gripzange-Kettenblatt fest 
und versuche die Gripzange-Tretkurbel im Uhrzeigersinn zu drehen.
Dabei erhöhe ich das Drehmoment der Tretkurbel so lange bis der Motor 
anspringt. Danach sollte das Drehmoment in der Tabelle zusammenbrechen, 
und ich schalte die Elektronik aus.

anbei die zwei Datenreihen.
100 Zeilen sollte eine Sekunde sein.
Auffällig ist, das im Drehmoment Test die dritte Spalte auf 0x80 
springt. Das sieht mir eben doch nach falsche Byte-Reihenfolge. Also der 
Sensor sendet Big-endien aber das software-serial interpretiert als 
Little-Endien. Irgendsowas..

: Bearbeitet durch User
von Das R. (Firma: Verliererland) (verlierer)



Lesenswert?

So ich hab mal die Reihenfolge der Bits vertauscht und nun ist Spalte 2 
klar das Lowbyte und Spalte 3 das Highbyte des Drehmoments, siehe 
txt-datei.
1
char Convert(char c)
2
{
3
  char w = 0;
4
  if (c & 0b10000000) w += 1;
5
  if (c & 0b01000000) w += 2;
6
  if (c & 0b00100000) w += 4;
7
  if (c & 0b00010000) w += 8;
8
  if (c & 0b00001000) w += 16;
9
  if (c & 0b00000100) w += 32;
10
  if (c & 0b00000010) w += 64;
11
  if (c & 0b00000001) w += 128;
12
  return w;
13
}

Da die erste Spalte teils zwischen 1 und 80 springt, handelt es sich 
wohl um einen 32 bit Wert und ich muss die 4 bytes noch richtig ordnen ?

Die anfänglichen
1
 C0 E9  0 E4  0 CB  0 28  0  0
2
 BE E8  0 E3  0 CB  0 28  0  0
3
 BF E9  0 E3  0 CB  0 28  0  0
4
 BF E8  0 E4  0 CB  0 28  0  0
5
 BF E8  0 E4  0 CB  0 28  0  0
6
 BF E8  0 E4  0 CB  0 28  0  0
7
 BF E8  0 E4  0 CB  0 28  0  0
deuten wohl schon auf zwei 32 bit Werte ?

von Das R. (Firma: Verliererland) (verlierer)


Lesenswert?

Im Video kann man besser sehen, wie die Zahlen auf die Kurbel reagieren:

https://youtu.be/f45o7__WmSY

von Oszi50 (Gast)


Lesenswert?

Oh man Roland,

hast du aber einen Saustall bei dir!

von Das R. (Firma: Verliererland) (verlierer)


Lesenswert?

Interessant dass bei Rückwärtsdrehung das Drehmoment im hi-biyte von 0 
auf 0x80 springt.
Das passt zu der üblichen Bedeutung des höchsten Bit als Minuszeichen:
1
 B6 DF  0 E1  0 CE  0 28  0  0
2
 36 DF  0 E1  0 CE  0 28  0 80
3
 B6 DF  0 E1  0 CE  0 28  0  0
4
 36 DF  0 E1  0 CE  0 28  0 80
5
 92 DF 80 E1 5C CE  0 28  0  0
6
 12 DF 80 E1 5C CE  0 28  0 80
7
 93 E0 80 E1 5C CE  0 28  0  0
8
 13 E0 80 E1 5C CE  0 28  0 80
9
 93 E0 80 E1 5C CE  0 28  0  0
10
 13 E0 80 E1 5C CE  0 28  0 80
11
 13 E0  0 E1 5C CE  0 28  0  0
12
 93 E0  0 E1 5C CE  0 28  0 80
13
 13 E0  0 E1 5C CE  0 28  0  0

Allerdings bleibt das (vorläufige) Low-Byte bei DF stehen.
Dafür springt das Hi-Byte des Position+Drehmoment von 0 auf 5C.
Und bleibt auch auf 5C. Durch die Rückwärtsdrehung könnte also die 
Position neu gesetzt worden sein.

Die 80 als Minus-Zeichen könnte auch bei der letzten Spalte, also der 
Drehgeschwindigkeit helfen. Die schwankt dann bei Stillstand vielleicht 
immer zwischen 0 und -1
Wie im Video zu sehen, lässt sich da aber kein low- und hi-byte 
erkennen.

Seltsam seltsam :-/

von Das R. (Firma: Verliererland) (verlierer)


Angehängte Dateien:

Lesenswert?

Mhh, die Adruino SoftwareSerial kann kein parity.
Hab das gemerkt als ich versucht habe, den Sensor durch eigenes Senden 
zu emulieren. Siehe Foto. der orange scan ist vom Arduino, der gelbe vom 
original Sensor.
Ausserdem sieht es so aus, als ob beim vom Arduino bei jedem gesendeten 
Byte ein halbes Bit zu kurz kommt, so dass nach zwei gesendeten Bytes 
ein Versatz von einem Bit zum Sensor entsteht.

So als ob der Arduino ohne partiy aber mit 1,5 Stopbits sendet.
Aber die doofe arduino softwareserial nutzt eigentlich 1,0 stopbits ?
Und dass der Sensor mit 0,5 Stopbits sendet gibts wohl nicht !

Wer sich mit parity und stopbits auskennt, mag vielleicht ein blick auf 
das angehängte foto werfen !

Das hat dann der Motorcontroller nicht akzeptiert und ist auf Störung 
gegengen. Mit der lib https://github.com/ljbeng/SoftwareSerialParity 
akzeptiert der Controller nun meine Daten, so dass ich anfangen, den 
Motor durch simuliertes Drehmoment zu laufen zu bringen.

Hab aber mit dem Testcode schon große Timing-Schwierigkeiten. Ich denke 
ich werde auf den ESP32 wechseln, da hab ich drei hardware seriel die 
ich wohl kompelett konfigurieren kann: 
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/uart.html

Und die pins sollen sich umlegen lassen, so dass ich selbst auf 
https://www.aliexpress.com/item/4000894572043.html die drei hardware 
seriel nutzen können sollte: 
https://hackaday.com/2017/08/17/secret-serial-port-for-arduinoesp32/

von foobar (Gast)


Lesenswert?

1
> B6 DF  0 E1  0 CE  0 28  0  0
2
> 36 DF  0 E1  0 CE  0 28  0 80
3
>...
4
> 93 E0  0 E1 5C CE  0 28  0 80
5
> 13 E0  0 E1 5C CE  0 28  0  0
Das erste Byte ist die Prüfsumme (mod 256) der folgenden Bytes.

von Das R. (Firma: Verliererland) (verlierer)


Lesenswert?

foobar schrieb:
> Das erste Byte ist die Prüfsumme (mod 256) der folgenden Bytes.

Ja wunderbar und dankeschön :-)
Ich war gerade dabei, das 2te und 3te Byte zu variieren um verschiedene 
Drehmomente zu emulieren, aber der Controller ging sofort auf Störung.

Jetzt mit
1
    aRun[0] = 0;
2
    for (int i=1; i<PAS_BUFF; i++)  aRun[0] += aRun[i];
klappt es prima. Wenn auch der Controller trotzdem nur an/aus macht, und 
die Stärke über das Display in drei Stufen gewählt werden kann.
Das Display muss ich also auch noch emulieren. Dann mal sehn ob das auch 
MIDI spricht.

Wir können jetzt also festhalten, dass meine "Invertierung" der Bytes 
korrekt ist, da ich die Prüfsumme berechnen muss, bevor ich die 10 Byte 
invertiere und sende.
1
uint8_t Convert(char c)
2
{
3
  uint8_t w = 0;
4
  if (c & 0b10000000) w += 1;
5
  if (c & 0b01000000) w += 2;
6
  if (c & 0b00100000) w += 4;
7
  if (c & 0b00010000) w += 8;
8
  if (c & 0b00001000) w += 16;
9
  if (c & 0b00000100) w += 32;
10
  if (c & 0b00000010) w += 64;
11
  if (c & 0b00000001) w += 128;
12
  return w;
13
}

Gibts dafür einen Einzeiler ?

das Roland und :-)

update:
1
nsigned char reverse(unsigned char b) {
2
   b = (b & 0xF0) >> 4 | (b & 0x0F) << 4;
3
   b = (b & 0xCC) >> 2 | (b & 0x33) << 2;
4
   b = (b & 0xAA) >> 1 | (b & 0x55) << 1;
5
   return b;
6
}
https://stackoverflow.com/questions/2602823/in-c-c-whats-the-simplest-way-to-reverse-the-order-of-bits-in-a-byte

: Bearbeitet durch User
von foobar (Gast)


Lesenswert?

> Gibts dafür einen Einzeiler?

Gibt es, aber nur auf bestimmten Rechnern wirklich vorteilhaft:
1
uint8_t Convert(uint8_t c)
2
{
3
    return (c * 0x0202020202ULL & 0x010884422010ULL) % 1023;
4
}
Ist von [1], da findest du auch besser geeignete Methoden.

[1] 
https://graphics.stanford.edu/~seander/bithacks.html#ReverseByteWith64BitsDiv

von Joachim B. (jar)


Lesenswert?

Das R. schrieb:
> Wäre das ein Standart ?

heisst das nicht "eine Standart"?

die Art zu stehen und damit female?

Das R. schrieb:
> Ideen immer zu mir :-)

Eine Art zu stehen (Standart) kann für einige durchaus Standard werden.
Die hier oft auf einem Bein:
https://www.tagesspiegel.de/images/flamingos-im-allgaeu/24571260/1-format43.jpg

von Das R. (Firma: Verliererland) (verlierer)


Angehängte Dateien:

Lesenswert?

So das Display scheint mir auch wieder seltsame baudrate zu nutzen.
Leider sendet das Display nur ein einziges Byte, und bekommt dann wohl 
über die selbe Leitung genau ein Byte als Bestätigung zurück.
Siehe angehängtes Bild.

Mit 14400 komme ich aber klar.
Jedoch wird bei manchen bytes der Leerraum als 0xff interpretiert.

Vielleicht ist hier also auch wieder eine baudrate am Werk die mir 
unbekannt ist.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Das R. schrieb:
> So das Display scheint mir auch wieder seltsame baudrate zu nutzen.
Wie schon Lothar M. schrieb:
>>> Wenn ich eine Schnittstelle machen wollte, die rudimentär geschützt sein
>>> sollte, dann würde ich explizit keine Standard-Baudrate verwenden. Das
>>> würde unbedarfte Hacker schon mal vor eine gewisse Hürde stellen.

Das R. schrieb:
> So das Display scheint mir auch wieder seltsame baudrate zu nutzen.
Und nur einen Pullup für den High-Pegel?

Das R. schrieb:
> Das passt zu der üblichen Bedeutung des höchsten Bit als Minuszeichen:
Das höchste Bit ist bei der Zweierkomplementdarstellung nicht "das 
Minuszeichen". Denn wenn dort binär 000000001 = dezimal 1 ist, dann ist 
eben nicht bin 10000001 = dez -1. Man kann am MSB bestenfalls 
erkennen, dass die Zahl negativ ist.

von Menno (Gast)


Lesenswert?

1) Die echte Baudrate ist vollkommen sch..ßegal, wenn Sender und
   Empfänger nur weniger, als 1...2% auseinander liegen.

2) Wenn dem nicht so ist, muss man eben dafür sorgen. So einfach
   ist das. (PUNKT, FERTIG, AUS)

von Hmmm (Gast)


Lesenswert?

Das R. schrieb:
> Vielleicht ist hier also auch wieder eine baudrate am Werk die mir
> unbekannt ist.

Hat Dein Oszi keine Cursor-Messfunktionen, um mal exakt eine Bitlänge zu 
bestimmen?

Da auch diese Baudrate vom gleichen Takt abgeleitet sein dürfte, halte 
ich 15625 Baud für wahrscheinlicher.

von Yalu X. (yalu) (Moderator)


Angehängte Dateien:

Lesenswert?

Ich glaube, ich habe jetzt den prinzipiellen Aufbau der Sensoreinheit
und das Übertragungsprotokoll weitestgehend verstanden. Viele Dinge hast
du ja schon selber herausgefunden, die Idee mit der Prüfsumme kam von
foobar. Hier ist eine Zusammenfassung eurer und meiner Erkenntnisse. Zu
beachten ist, dass mangels geeigneter Datensätze einige Dinge auf bloßen
(aber relativ naheliegenden) Vermutungen beruhen.

Die Einheit enthält drei separate magnetoelastische Drehmomentsensoren,
die mit 120° Abstand zueinander um die Welle angeordnet sind. Durch die
Verwendung von drei Sensoren statt nur einem können Asymmetrien und
Inhomogenitäten der Welle weitgehend ausgeglichen werden. Die
Analogsignale der Sensoren werden jeweils mit einer Auflösung von 10-Bit
digitalisiert.

Der Kurbelwinkel wird mit einer Auflösung von 15° erfasst, d.h. eine
volle Kurbelumdrehung wird in 24 Einzelschritte aufgelöst.

Die Bestimmung der Drehrate erfolgt durch Messung der Dauer Δt für eine
Winkeländerung um 30° (2 Schritte der Kurbelwinkelmessung) mit einer
Auflösung von 100µs. Daraus kann in einer externen Auswerteeinheit die
Drehrate berechnet werden, sie ist 30°/Δt. Die Zeitpunkte der Messung
von Δt werden grob durch die 0/1- und 1/0-Wechsel von Bit 7 in Byte 9
angezeigt (grob deswegen, weil die Daten nur alle 10ms gesendet werden,
die Messauflösung aber 100 µs beträgt).

Bedingt durch dieses Messprinzip ist die Messdauer der Drehrate
variabel. Bei einer Drehzahl von 60/min ≙ 360°/s wird alle 30°/(360°/s)
= 83ms ein neuer Messwert ermittelt. Wird dir Kurbel langsamer gedreht,
dauert die Messung entsprechen länger. Ist die Kurbel gar im Stillstand,
kann die Drehrate mit dieser Methode überhaupt nicht mehr bestimmt
werden, da die Messdauer unendlich wäre. Um die damit verbundenen
Probleme zu umgehen, wird die Messdauer auf 1s begrenzt. Bewegt sich die
Kurbel in dieser Zeit nicht um 30° weiter, wird angenommen, dass sie
stillsteht. Dies wird dadurch angezeigt, dass der Wert für die gemessene
Zeitdauer auf null gesetzt und Bit 7 von Byte 9 in einen "Zappelmodus"
versetzt wird, in dem es alle 10ms seinen Wert ändert.

Die Bedeutung von Byte 7 ist noch unklar. Dessen Wert ist von 0
verschieden (scheint also eine Bedeutung zu haben), ändert sich aber –
wenn überhaupt – nur sehr langsam. Möglicherweise handelt es sich um den
Messwert der Temperatur oder der Versorgungsspannung, aber auch andere
Größen oder eine Zusammenfassung von Statusbits sind vorstellbar.

Ein Datensatz besteht aus 10 Bytes, die jeweils beginnend mit dem
höchstwertigen Bit übertragen werden, also genau andersherum als bei
RS-232 und den gängigen Hardware-UARTs.

Die einzelnen Bytes und Bits tragen folgende Informationen:

1
Byte 0:
2
  Bit 0..7: Prüfsumme, 8-Bit-Summe aus Byte 1..9
3
4
Byte 1:
5
  Bit 0..7: Drehmoment 1, Bit 0..7
6
7
Byte 2:
8
  Bit 0..1: Drehmoment 1, Bit 8..9
9
  Bit 2..7: ???, evtl. ungenutzt und immer 0
10
11
Byte 3:
12
  Bit 0..7: Drehmoment 2, Bit 0..7
13
14
Byte 4:
15
  Bit 0..1: Drehmoment 2, Bit 8..9
16
  Bit 2..6: Kurbelwinkel, Wertebereich 0..23, Einheit 15°
17
  Bit 7   : ???, evtl. ungenutzt und immer 0
18
19
Byte 5:
20
  Bit 0..7: Drehmoment 3, Bit 0..7
21
22
Byte 6:
23
  Bit 0..1: Drehmoment 3, Bit 8..9
24
  Bit 2..7: ???, evtl. ungenutzt und immer 0
25
26
Byte 7:
27
  Bit 0..7: ???, typische Werte sind 0x29 (41) oder 0x2a (42)
28
29
Byte 8:
30
  Bit 0..7: Dauer für 30°-Rotation, Bit 0..7, Einheit 100µs
31
32
Byte 9:
33
  Bit 0..5: Dauer für 30°-Rotation, Bit 8..13, Einheit 100µs
34
  Bit 6   : ???, evtl. ungenutzt und immer 0
35
  Bit 7   : Messpunkte, repräsentiert durch die Flanken des Signals


Basierend auf diesen Annahmen, habe ich zwei Datensätze ausgewertet und
visualisiert (s. Anhang). Datensatz 1 bezieht sich dabei auf die Datei

  "an._eine_kurbeldrehung_ohne_drehmoment__aus.txt"

und Datensatz 2 auf

  "an__drehmoment_bis_Unterstuetzung_einsetzt__aus.txt"

von hier:

Das R. schrieb:
> anbei die zwei Datenreihen.

Dazu ein paar Anmerkungen:

- Die Messwerte für die Drehmomente haben einen mittleren Offset von
  218,5. Diesen habe ich subtrahiert, so dass der Mittelwert der drei
  Sensorwerte in Ruhe bei etwa 0 liegt.

- Die Drehmomente konnte ich wegen des unbekannten Skalierungsfaktors
  nicht in Nm umrechnen. Deswegen habe ich hier die ADC-Auflösung (LSB)
  als Einheit verwendet.

- Im Diagramm links oben (ohne Drehmoment) erkennt man, dass die
  Asymmetrien der Welle auch durch die Mittelung nicht vollständig
  kompensiert werden. Eine perfekte Kompensation wäre nur möglich, wenn
  die Störungen einen über dem Kurbelwinkel exakt sinusförmigen Verlauf
  hätten, was in der Realität aber nicht der Fall ist. Die verbleibenden
  "Dellen" haben aber immerhin wie erwartet einen Abstand von genau 120°
  zueinander.

- Die dargestellten Drehraten habe ich bereits aus den zugehörigen
  Zeitmessungen berechnet. Die jeweils zugrunde liegenden Zeitmesswerte
  können aus der Breite der High- und Low-Abschnitte des roten Signals
  abgelesen werden.

- Auf Grund der niedrigen Drehrate haben die dargestellten Kurven grobe
  Stufen. Bei eine typischen Trittfrequenz von 60/min bis 100/min sähen
  die Kurven viel glatter aus.

- Man kann deutlich erkennen, dass der "Zappelmodus" immer nach genau 1s
  Stillstand einsetzt.

- In den untersten beiden Diagrammen habe ich den diskreten Messwert im
  Bereich von 0..23 in Winkelgrade umgerechnet. Jeweils nach einer
  vollen Kurbelumdrehung springt der Wert wieder auf 0.

Ich habe die Diagramme als SVG hochgeladen, weil man darin durch Zoomen
auch die Details sehen kann. Für den Fall, dass sie bei jemandem nicht
richtig dargestellt werden, gibt es zusätzlich noch ein PNG.

von Das R. (Firma: Verliererland) (verlierer)


Angehängte Dateien:

Lesenswert?

Hmmm schrieb:
> Hat Dein Oszi keine Cursor-Messfunktionen, um mal exakt eine Bitlänge zu
> bestimmen?
>
> Da auch diese Baudrate vom gleichen Takt abgeleitet sein dürfte, halte
> ich 15625 Baud für wahrscheinlicher.

Ich hab hier nur ein Pocket-DSO, siehe Video.
Und meine Fotografiermethode halte ich für genauer.
Hab jetzt mal eine Diode zwichen Display und Motor gehängt. Jetzt bin 
ich der Meinung, dass das erste Byte vom Motor kommt und den Status wie 
AssistMode übermittelt.
Daraufhin sendet das Display ein Byte zurück welche Knöpfe gedrückt 
sind.

Ich hab mal drei dieser Display-Bytes übereinander gelegt:
nichts gedrückt, boost gedrückt, Light gedrückt.
Siehe Anhang.

Das scheinen 9 bit plus parität plus start und stop zu sein :-/
Für diese 12 bit komme ich auf 0,62 ms und damit auf eine baudrate von 
19354

Wenn ich diese Baudrate verwende, kann mein Arduino auch folgende Bytes 
auslesen:
1
19354 baud:
2
00111100 = 3c = no button
3
00111000 = 38 = boost button
4
00011100 = 1c = light button
5
18 = boost + light
6
2c = on button
7
34 = off button
Genau diese drei bytes sind auch in meinem Bild zu sehen.

Für andere Baudraten passt das gar nicht:
1
14400 baud:
2
71 = no button
3
61 = boost button
4
31 = light button
5
21 = boost + light
6
51 = on button
7
61 = off button
8
9
15625 baud:
10
39 = no button
11
30 = boost button
12
38 = light button
13
31 = boost + light
14
18 = on button
15
28 = off button

Jetzt muss ich testen, ob der Motor diese 8 bits akzeptiert.
Dem Bild nach müsste ich ja 9 bits senden ?!


Zum Sinn des Hack: Sunstar ist nicht insolenz gegangen, sondern haben 
die Produktion der S03 Nachrüstsets eingestellt. Es gibt aber noch 
Lagerbestände bei Händlern die so langsam geräumt werden. Aber meist 
bekommt man nur diese nackten Motoren, die ohne das hier praktisch 
Schrott sind.

von Das R. (Firma: Verliererland) (verlierer)


Lesenswert?

Yalu X. schrieb:
> Ich glaube, ich habe jetzt den prinzipiellen Aufbau der Sensoreinheit
> und das Übertragungsprotokoll weitestgehend verstanden.

Woww !
wenn ich geahnt hätte, dass Du so lieb viel Zeit dafür verwenden magst, 
hätte ich Dir längere Messreihen geliefert.
Ich versuche heute mal, Deine umrechnung zu implementieren, dann kann 
ich Video machen bei dem ich live die Kurbel drehe/biege und wir können 
sehen wie Deine Berechnung reagiert :-)

von Das R. (Firma: Verliererland) (verlierer)



Lesenswert?

So bin am verhungern aber möchte noch die Implementierung des Protokols 
melden.
Sieht soweit ganz gut aus. hab noch kleinen bug in meinem zyklischem 
Puffer.
Darum benutzte ich das statische Feld 7 als iError um den Puffer zu 
verwerfen..
1
bool DoPAS()
2
{
3
  uint8_t iError = aRead[(iReadStart+7)%NUM_READ];
4
  if (iError != 0x2c) return false;
5
6
  
7
  int16_t iTorque1 = aRead[(iReadStart+1)%NUM_READ] + (uint16_t)(0b00000011 & aRead[(iReadStart+2)%NUM_READ]) * 256;
8
  bool bBackwards  = 0 != (0b10000000 & aRead[(iReadStart+2)%NUM_READ]);
9
  uint8_t iLost1  = 0b01111100 & aRead[(iReadStart+2)%NUM_READ];
10
11
  int16_t iTorque2 = aRead[(iReadStart+3)%NUM_READ] + (uint16_t)(0b00000011 & aRead[(iReadStart+4)%NUM_READ]) * 256;
12
  uint8_t iPos    = 0b01111100 & aRead[(iReadStart+4)%NUM_READ];
13
  uint8_t iLost2  = 0b10000000 & aRead[(iReadStart+4)%NUM_READ];
14
15
  int16_t iTorque3 = aRead[(iReadStart+5)%NUM_READ] + (uint16_t)(0b00000011 & aRead[(iReadStart+6)%NUM_READ]) * 256;
16
  uint8_t iLost3  = 0b11111100 & aRead[(iReadStart+6)%NUM_READ];
17
18
19
  uint16_t iSpeed = aRead[(iReadStart+8)%NUM_READ] + (uint16_t)(0b00111111 & aRead[(iReadStart+9)%NUM_READ]) * 256;
20
  uint8_t iLost4  = 0b01000000 & aRead[(iReadStart+9)%NUM_READ];
21
  uint8_t iAlive  = 0b10000000 & aRead[(iReadStart+9)%NUM_READ];
22
23
  if (millis() < 1000)
24
  {
25
    if (iTorque1Min > iTorque1) iTorque1Min = iTorque1;
26
    if (iTorque2Min > iTorque2) iTorque2Min = iTorque2;
27
    if (iTorque3Min > iTorque3) iTorque3Min = iTorque3;
28
  }
29
    iTorque1 -= iTorque1Min;   iTorque2 -= iTorque2Min;   iTorque3 -= iTorque3Min;
30
31
  for (int i=0; i<PAS_BUFF; i++)
32
  {
33
    uint8_t c = aRead[(iReadStart+i)%NUM_READ];
34
     //Serial.print(c < 16 ? "  " : " ");
35
     Serial.print(c < 16 ? "0x0" : "0x");
36
    Serial.print(c,HEX);
37
    Serial.print(" , ");
38
  }
39
40
    Serial.print("\ttorque: ");Serial.print(iTorque1);Serial.print("\t");Serial.print(iTorque2);Serial.print("\t");Serial.print(iTorque3);Serial.print("\t");
41
    Serial.print("pos: ");Serial.print(iPos);Serial.print("\tspeed: ");Serial.print(iSpeed);Serial.print("\tbackwards: ");Serial.print(bBackwards);Serial.print("\t");
42
    Serial.print("lost: ");Serial.print(iLost1,HEX);Serial.print("\t\t");Serial.print(iLost2,HEX);Serial.print("\t");Serial.print(iLost3,HEX);Serial.print("\t");Serial.print(iLost4,HEX);
43
    Serial.print("\terror: ");Serial.print(iError,HEX);Serial.print("\talive: ");Serial.print(iAlive,HEX);
44
  
45
  Serial.println();
46
  return true;
47
}

Die ausgabe in den csv log Dateien
Gutenacht :-)

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.