Sinnvolle Daten seriell übertragen?

Hallo,

wir haben hier eine kleine Aufgabe bekommen deren Lösung nahezu fertig ist. Zehn PTC-Widerstände werden nach einander, via Multiplexer auf einer gemeinsamen Trägerplaine, auf den einen A/D-Wandler-Kanal unseres PIC-Prozessors geschaltet. Die PTCs werden dann nacheinander durchgemessen. Diejenigen die die Toleranz nicht einhalten kommen in Charge B, die anderen in Charge A. Nun werden wir die gemessenen Spannungen zum PC übertragen via RS232. Das geht auch soweit. Meine Frage ist, ob das auch weniger bescheuert geht als

als Startsequenz für den PC Angabe in Volt das Komma zwischen Volt und Millivolt Angabe der beiden Nachkommastellen in Volt als Endesequenz für den PC

Die Angabe von 11,75 Volt wird also tatsächlich mit allen Zeichen übertragen.

Was passiert wenn z.B. das Komma bei der Übertragung verloren geht bzw. als anderes Zeichen interpretiert wird? Das ist uns (noch)nicht passiert. Gibt es irgendwelche Kniffe, Tips oder brauchbare Algorithmen die eine solche sehr einfache Datenübertragung sicherer machen?

Sven

Das kommt drauf an, was du auf der PC-Seite machen kannst/willst.

Ich würde auf der PIC-Seite gar nicht erst in Volt umrechnen, sondern einfach den ADU-Wert nehmen und mit der gewünschten Auflösung an den PC senden, und dort die Umrechnung in die Dezimalschreibweise machen.

Die Datenmenge dürfte kein Problem darstellt, also braucht man sich keine Gedanken über Komprimierung etc. machen. Wenn du bereits in Dezimal umgerechnet hast, kannst du das natürlich so lassen. Statt zwei Bytes, sendest du dann einfach 5 Character.

Das Komma muss dann an der richtigen Stelle sein und kann als zusätzliches Kriterium für ein fehlerfreies Telegramm verwendet werden. Ebenso die Ziffern. An der entsprechenden Stelle dürfen nur Ziffern zwischen 0..9 stehen. Dazu dann noch eine Checksumme, und das wars.

Beispiel für 16 Bit Binärdaten:

1. Zeichen: FF, die Synchronisation auf den Telegrammanfang wird dann etwas sicherer
2. Zeichen: 02, oder was anderes, Startzeichen
3. Zeichen: nn, Kanalnummer
4. Zeichen: xx, 1. Byte des ADU-Wertes
5. Zeichen: yy, 2. Byte des ADU-Wertes
6. Zeichen: cc, Checksumme

mit : 02 + nn + xx + yy + cc = 0

Das ganze kann man natürlich beliebig aufblähen. Für eine Dezimaldarstelleung z.B.

1. Zeichen: FF, die Synchronisation auf den Telegrammanfang wird dann etwas sicherer
2. Zeichen: 02, oder was anderes, Startzeichen
3. Zeichen: nn, Kanalnummer
4. Zeichen: aa, 1. Character '0'..'9'
5. Zeichen: bb, 2. Character '0'..'9'
6. Zeichen: kk, 3. Character ',' oder '.'
7. Zeichen: ee, 4. Character '0'..'9'
8. Zeichen: ff, 4. Character '0'..'9'
9. Zeichen: cc, Checksumme

mit:

02+nn+aa+bb+kk+ee+ff+cc = 0

und: 30H

Hallo Sven,

Ja, z.B. das ganze fuenfmal hintereinander uebertragen und Mehrheitsentscheidung treffen. Kein Scherz, so wird das in der Luftfahrt schon mal gemacht.

--
Gruesse, Joerg

http://www.analogconsultants.com

Wenn auf dem PC ein selbstgestricktes Programm auf die Daten wartet könnte man das Komma und die Endesequenz wegrationalisieren.

Der PC kann dann erkennen ob die empfangenen Daten konsistent sind und Maßnahmen ergreifen.

timo.

Sven Schulz schrieb:

Hallo,

das geht natürlich schon effizienter, nehmen wir mal an die 11,75 Volt stammen aus einem 12 Bit AD Wandler, dann reichen zwei Zeichen statt fünf für die Daten. Auch bei einem 16 Bit Wandler reichen noch zwei 8 Bit Zeichen. Wenn man Fehlererkennung will ist das einfachste Verfahren die Verdoppelung, zweimal hintereinander senden, für eine einfache Fehlererkennung mit Korrektur eine Verdreifachung. Wenn man es eleganter machen will kann man auch CRC benutzen oder einen Code zur Erkennung und Korrektur.

Ich habe allerdings mal Treiber für eine Datenübertragung nach dem Modbus Protokoll mit CRC geschrieben, das läuft jetzt auf mehreren Anlagen seit Jahren fehlerfrei. Bei einer Leitungslänge von bis zu 15 m in einer Laborumgebung mit Leistungselektronik für die Öfen gibt es nie Übertragungsfehler. Also wenn ihr keine sehr langen Leitungen oder sehr viel Störungen aus der Umgebung habt werdet ihr Fehlerkorrektur wohl nie brauchen. Fehlererkennung wäre zwar schön aber nicht zwingend notwendig.

Bye

Uwe Hercksen schrieb:

Hammingcode, lässt sich einfachst implementieren.

Gruß Dieter

Wie wärs mit einer Checksumme. Stimmt sie quitiert der PC den Empfang. Wenn nicht fordert er den Wert neu an.

Die Übertragung der Daten in ASCII oder Binär ist "geschmackssache". In Tcl/Tk kann man dazu die serielle Schnittstelle zwischen Ascii und Binär umschalten, unter C++ habe ich binär noch nicht probiert.

MfG Michael

"Sven Schulz" schrieb im Newsbeitrag news:46c2a199$0$16111$ snipped-for-privacy@newsspool1.arcor-online.net...

Der grosse Vorteil einer Uebertragung von ASCII-Ziffern ist, dass man auch mit einem simplen Terminalprogramm pruefen kann, ob der PIC funktioniert. Das habt ihr mit und aber ziemlich sabotiert, CRLF waere besser gewesen. /t=TAB /r=CR /n=LF Wenn man Fehler bei der Uebertragung erkennen will, sollte man Pruefzeichen mitschicken, die CRC der Ziffern oder so, auch den Messkanal. Vielleicht also:

03,25\tA\t0\r\n 11,75\tB\t4\r\n mit der Festkommaposition ist auch das Komma klar. Die Anzahl der uebertragenen Zeichen spielt ja wohl eher keine Rolle, daher hab ich schon mal die Datenfelder miot TAB getrennt, zum direkten Einlesen in Tabellensoftware.

--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

Michael Schlegel schrieb: ...

Was ist der Unterschied? Man wirft ein Bitmuster 'rein und auf der anderen Seite kommt dieses Bitmuster wieder heraus.

ASCII ist ein Zeichensatz, wie UTF-8 auch. Man kann alles seriell übertragen. (slip, ppp...)

Falk

Die Frage ist, was der Empfänger mit z.B. 0x11 oder 0x13 anfangen soll. Binär sind es einfach Zahlen, in ASCII ist es XON, XOFF.

MfG Michael

Kleines Update: habe doch schon unter C++ binär kommuniziert. Die Klasse CSerial von

unterscheidet nicht zwischen binär und ASCII und überläßt es dem Programmierer wie er auf Steuerzeichen reagiert. Andere Programmierumgebungen handhaben das aber z.T. anders.

MfG Michael

Hallo Sven,

Also kann man nicht mehr allzuviel dran ändern ;-)

Wozu auch immer...

Meinetwegen, machen wir aber auch gern so, weil man dann im Terminal einfach mal so ein paar Daten durchschieben kann und im Klartext schon beurteilen kann.

Wers so mag, Ich ziehe die einfache CSV-Formatierung vor. Das lässt sich dann einfach in Labview, Excel oder sonst wohin importieren und bequem auswerten.

Na und?

Egal welches Zeichen, die Nachricht geht dann verloren und dieser Datensatz ist futsch. Ist aus dem FF ein FE geworden wird der Blockanfang überlesen und die darauf folgenden Daten nicht erkannt (sonst bräuchte man das FF gar nicht zu senden ;-) Alle anderen Stellen machen genau so viel Fehler.

1. Handshake, um Datenverlust durch Datenabholfehler zu vermeiden. Der PIC kann das über zusätzliche Portpins realisieren. Softwarehandshake wäre ggfs ohne drahtänderungen machbar. Inwieweit sich das auf dem PIC machen lässt, mögen andere sagen.
2. Antwortprotokolle einführen. Z.B. der PC generiert eine Antwort, indem er die Nachricht einfach wieder an den PIC zurücksendet. Dann weiss man zumindest auf PIC-Seite, dass der PC es verstanden hat. Gabs einen Fehler, dann kann der Wert als Korrektur gekennzeichnet noch einmal übertragen werden. So ist sichergestellt, dass die richtige Zahlen angekommen sind.
3. Checksummen und (zyklisch) redundante Codierungen wurden bereits genannt, machen das Protokoll aber nicht mehr klartextlesbar.

Mein Favorit wäre 1. Es ist einfach zu implementieren und das Protokoll bleibt einfach lesbar und muss nicht komplett neu geschrieben werden.

Marte

Stefan Brröring schrieb:

ist sowas bei XON/XOFF nicht bissi heikel?

rw

Robin Wenninger schrieb:

Hallo,

nein, das bereitet keine Probleme, da die Werte als Hex-Zahl übertragen werden und somit nur die Ascii-Zeichen '0'..'9' und 'A'..'F' enthalten.

Viele Grüße, Björn

punkt schrieb:

Das finde ich etwas leichtsinnig. Ein gekipptes Bit kann so leicht mal aus "0xFF" ein "0xEF" machen. Ich würde konsequenterweise Zahlen in ASCII übertragen. Aus "Null X zweihundertfünfundfünfzig" würde ein Bitkipper "Null X zweijundertfünfundfünfzig" machen.

Bei "Lull X zweijundertfünfundfünfzig" wäre der Datentypist, der die Werte von Hyperterm in ein Exzell-Schiet überträgt schon bei Beginn gewarnt, daß wieder einer Licht ausgemacht hat und erhöhte Aufmerksamkeit gefordert ist.

Anders verhält es sich selbstverständlich, wenn nach Bytes im Code bezahlt wird.

SCNR, Falk

Falk Willberg schrieb:

Hallo,

man könnte zumindest noch eine Prüfsumme hinzufügen, wie das in anderen Antworten schon erwähnt wurde. Dann lässt sich zwar in Hyperterm nicht direkt erkennen, ob das Paket in Ordnung war, da man erst noch nachrechnen muss. Werden die Daten elektronisch weiterverarbeitet, so gibt diese einfache Lösung aber bereits ein gutes Stück Sicherheit.

Schöne Grüße, Björn

--
Zur Antwort per Mail bitte "_nospam_" aus der Mailadresse entfernen.

Sven Schulz schrieb:

....

Früher [tm] gab es doch mal als Lotterie-Fehlererkennung das Parity-Bit der RS232-Übertragung...

--
mfg Rolf Bombach

Xon Xoff spielt keine Rolle, wenn ich die Daten z.B. mit Delphi einlese.

Bei einem Terminalprogramm wie Hyperterminal kann man xon, xoff einfach aussschalten. Muss man sogar, weil es sonst im Falle von Übertragungsfehlern die Sache blockieren könnte.

Deshalb ist es auch fast egal, ob ich Ascii-Ziffern, oder Binärdaten übertrage.

Ascii-Ziffern haben tatsächlich den Vorteil, dass man die Telegramme mit Hyperterminal testen kann. Meistens mache ich das auch so. Anstelle von Hyperterminal verwende ich aber ein selbstgeschriebenes einfaches Terminalprogramm.

Wenn man die PC-Seite im Griff hat, ist es aber eher unwichtig, ob Ascii-Ziffern, oder Binärdaten.

Die Frage ist nur, wieviel von der Auswertung will ich dem PIC überlassen, und wieviel dem PC?

Bei meinen Anwendungen, findet die Umrechnung in physikalische Werte und darstellbare Zeichenfolgen üblicherweise im PC statt. Das Delphi-Programm würde dann auch die CSV-Dateien erzeugen (machen wir meistens nicht, weil wir üblicherweise in Datenbanken schreiben).

Da zuvor eine Plausibilitäts- und Fehlerprüfung erfolgen kann, würde diese dann "sauber" sein, was bei einer direkten Erzeugung einer CSV-Datei mit Hyperterminal o.ä. nicht unbedingt der Fall wäre.

Prüfsumme habe ich in meinem Vorschlag vorgesehen.

Es gibt natürlich noch aufwendigere Prüfsummen, z.B. CRC16 o.ä. Das ist aber in der Regel nicht nötig.

Gruß

Stefan

Kann man immer noch verwenden. Aber es bleibt trotzdem immer noch das Problem, dass ein Fehler mit einer gewissen Wahrscheinlichkeit nicht als solcher erkannt wird.

Bei der von mir oben vorgeschlagenen einfachen 0-Prüfsumme könnte man annehmen, dass eines von 256 fehlerhaften Telegrammen nicht als fehlerhaft erkannt wird. Tatsächlich ist die Wahrscheinlickeit aus statistischen Gründen aber noch schlechter. Deshalb gibt es aufwendigere Prüfsummenverfahren, z.B. CRC16.

Aber da kommt man dann mit 16 Bit auf eine Wahrscheinlichkeit von mindestens 1:65536 und das ist in manchen Fällen bereits zu schlecht.

Gruß

Stefan