Ich soll mit einem Microcontroller eine nicht spezifizierte Datenrate
einer UART ermitteln und dann Daten empfangen. Bekannt ist, dass das
anzuschließende Gerät mit 9600 ... 115k senden wird, Parity und
Stoppbits sind offen.
Problem1: Gerät wird angeschlossen und pulst die Daten raus. Alles muss
empfangen werden ohne einen Vorlauf auf den man sich einpendeln könnte.
Problem2: Die Geräte werden in der Hitze und vor allem der Kälte
betrieben. Im Namib-Modus / Alaska-Modus haben die Taktraten die
ausserhalb der 2% Abweichung liegen, welche unsere UART-Chips
verkraften.
Ich brauche also eine Format-Rate-Schaltung mit angeschlossener
Dekodierung.
Wie macht man das am Klügsten?
Herbert schrieb:> Wie macht man das am Klügsten?
Dem sender VOR dem sender zusagen es soll eine info senden was der
emfänger zu erwarten hat dann erst auswerten muss und sich drauf
einstellen Kann ?
serielle Verbindung öffnen mit 9600 und sagen du ich sende jetzt mit xyz
Verbindung schlissen und ein paar ms warten und los senden?
Oder dem Empfänger RATEN/testen lassen und dabei Daten verliehen ?
Gibt es schon infos welche Geräte da senden sollen ?
Also wenn die Gegenseite ohne Pause zwischen Bytes Daten rausbläst gibt
es keine garantierte Methode um die datenrate zu ermitteln.
Ein 0101 Datenstrom kann je nach datenrate entweder 0f(hex) bei
datenrate x oder 0f0f(hex) bei datenrate 2x sein.
Man kann zwar datenraten ausschließen indem man minimale/maximale Zeiten
misst, aber ohne Wissen über den Inhalt der Daten ist das stochern im
Nebel (quasi datenRATEN).
Das einfachste wäre, es gäbe eine feste Präambel, idealerweise mit
Flankenwechsel nach dem start-bit, dann kannst du die baudrate messen
(autobaud)
Wenn du das alles nicht hast, bleibt vermutlich nur den bitstrom sampeln
und im nachgang irgendwas überlegen...
zu den beiden Rückfragen:
Die Daten kommen gepulst, also mit Pausen. Ich kann natürlich ein
Startbit erkennen. Es ist nur nicht klar, ob es ein Stoppbit gibt. Die
Daten sind aber ausreichend lang, um zu erkennen, ob es z.B. 4x8, 4x9
oder 4x10 Bits sind. Zwischen Stopp und Start gibt es auch eine minimale
Pause.
Dem Sender kann ich nichts mitteilen.
Die Geräte, die senden sind bekannt. Es sind Geräte zum Programmieren
einer Forschungsstation. Diese haben ein mit einem Microcontroller
erstelltes Protokoll. Es gibt glaube ich 4 unterschiedliche Geräte
unterschiedlicher Forschungsgruppen.
Die Anchaltung der Geräte erfolgt induktiv durch den Boden / die Luft
Äh falsch, ich wollte sagen, "ob es Parity gibt".
Präambel gibt es in der Weise zwar, aber ich kann sie nicht nutzen, da
der Inhalt nicht 100% klar ist.
Und ich muss es erkennen.
Herbert schrieb:> Die Daten kommen gepulst, also mit Pausen. Ich kann natürlich ein> Startbit erkennen. Es ist nur nicht klar, ob es ein Stoppbit gibt.
Wenn es kein Stoppbit gibt, ist es keine normale UART-Kommunikation. Die
hat immer mindestens ein Stoppbit.
Warum senden die denn auf verschiedenen baudraten?
Lösung 1: brutal force... Alle möglichen baudraten parallel mit n SIOs.
Auf der Logikebene kannst Du so viele haben, wie Du möchtest.
Dann ggf nach Präambel alle parallel mit der ermittelten baudraten,
jedoch in 1% Schritten.
Die praktische Lösung ist aber eine andere, ... Wenn es wirklich
Forscher waren und nicht alle
gestorben/teleportiert/eingefroren/wahnsinnig sind, dann fragen, wer da
was warum tut. Niemand baut sowas damit es nicht funktioniert.
seltsame Angaben.
Wie soll das z.B. eindeutig ohne Stopbit funktionieren, wenn die Daten 0
sind? Insbesondere wenn man nicht weiß ob diesmal ein Stopbit dabei ist
oder nicht.
Irgendwelche Infos wird es zu diesem Protokoll sicher noch geben.
Ansonsten kannst du nur alle Flanken auswerten und die Zeit zwischen den
Flanken messen und dies alles in ein Protokoll schreiben.
Die Auswertung dieser einzelnen Zeitstempel kann man dann in aller Ruhe
danach machen und nach Plausibilität prüfen.
Also um das erste Problem anzugehen musst du mittels Abtasttheorem
(Abtastrate = 2x Senderate(Maximale mögliche Senderate)) alle Daten
erfassen können, dann verpasst du auch nichts. Diese Daten sollten dann
gebuffert werden und im Anschluss verarbeitet werden.
Herbert schrieb:> Die Daten kommen gepulst, also mit Pausen.
Dann ist die Sache doch ganz einfach. Die Bitfolge mit 460,8 kHz
abtasten, zwischenspeichern und anschließend auswerten ;-)
Kennt man die Bitanzahl kann man den Bitstrom im Nachhinein auswerten.
Jeder LA hat das Feature "Auto Baudrate" und kann das auch selbst
erkennen.
Nur "on the fly" wirds etwas knifflig. Was dann auch den Einsatz einer
dezidierten UART Komponente ausschließt.
Herbert schrieb:> Ich soll mit einem Microcontroller eine nicht spezifizierte Datenrate> einer UART ermitteln und dann Daten empfangen. Bekannt ist, dass das> anzuschließende Gerät mit 9600 ... 115k senden wird, Parity und> Stoppbits sind offen.>> Problem1: Gerät wird angeschlossen und pulst die Daten raus. Alles muss> empfangen werden ohne einen Vorlauf auf den man sich einpendeln könnte.Herbert schrieb:> Die Daten kommen gepulst, also mit Pausen. Ich kann natürlich ein> Startbit erkennen. Es ist nur nicht klar, ob es ein Stoppbit gibt. Die> Daten sind aber ausreichend lang, um zu erkennen, ob es z.B. 4x8, 4x9> oder 4x10 Bits sind. Zwischen Stopp und Start gibt es auch eine minimale> Pause.
Wenn du wirklich nichts weiter weißt und auch nichts verpassen darfst,
dann bleibt dir nichts übrig als das Telegramm mit hinreichend hoher
Zeitauflösung über einen hinreichend langen Zeitraum zu samplen. Und
dann die Daten aus dem Empfangsbuffer intelligent auszuwerten.
Hinreichend schnell: so daß du bei maximaler Baudrate wenigstens zwei
Samples pro Bitzelle hast, mehr wären besser.
Hinreichend lange: so daß auch das längste denkbare Telegramm bei der
niedrigsten Baudrate noch komplett aufgezeichnet wird.
Intelligent: die Längen von L- und H-Phasen klassifizieren. Das sollten
vielfache (1 .. maximal 11) einer kürzesten Zeitdauer sein. Diese
kürzeste Dauer ist dann die Bitzeit (Kehrwert der Baudrate). Allerdings
kann man sich problemlos Telegrame ausdenken, die auch bei dieser
Auswertung in die Irre führen. Störungen kommen noch oben drauf.
Rufus Τ. F. schrieb:> Wer auch immer sich das ausgedacht hat ....
Worauf beziehst du dich? Auf die unbekannte, variable Datenrate oder den
Abtastvorschlag?
Falls letzteres: ich würde es ähnlich versuchen, aber mit höherer Rate
als TI (Gast) vorschlug.
Es sollte aber wenigstens bekannt sein, ob mit oder ohne Parity und wie
lange das Stopbit ist.
Herbert schrieb:> Ich soll mit einem Microcontroller eine nicht spezifizierte Datenrate> einer UART ermitteln und dann Daten empfangen.
Ist doch eigentlich ganz einfach. Jeder serielle Bootlader in den
heutigen µC - die sowas haben - kann das.
Zuerst wird ohne UART der Zustand des Portpins beobachtet und ab einem
Flankenwechsel h->l die Länge der low- und high-Zeiten bestimmt. Die
kürzeste davon ist (mit Ausnahme von eventuellen ganz kurzen
Störimpulsen) die Zeit für 1 Bit und die anderen Zeiten sind dann so
etwa ganzzahlige Vielfache davon. Dann hat man die Bitzeit, gemessen in
Perioden des eigenen Taktes und kann daraus den Baudratenteiler
bestimmen.
W.S.
Herbert schrieb:> Dem Sender kann ich nichts mitteilen.>....> Die Anchaltung der Geräte erfolgt induktiv durch den Boden / die Luft
Irgendwie ist die ganze story nicht schlüssig - dem Sender bleibt also
eh nichts anderes übrig, als andauernd zu senden. Ob nun jemand zuhört
oder nicht weiss er ja nicht.
Genausogut könntest du die "Anschaltung" ein Paket später machen und
hättest damit auch dieses eine verloren. Also kannst du auch ein erstes
Paket zur Ermittlung der Baudrate nehmen und ab dann korrekt mithören.
Cyblord -. schrieb:> Nur "on the fly" wirds etwas knifflig. Was dann auch den Einsatz einer> dezidierten UART Komponente ausschließt.
Man könnte mit Input-Capture die Timestamps aller Flanken aufzeichnen
und dann nachträglich auswerten. Ein ATmega328 sollte dafür reichen.
W.S. schrieb:> Ist doch eigentlich ganz einfach.
Jetzt mußt Du nur noch mitteilen, wie man die Anzahl der Bits, Parität
und die Länge des Stoppbits erkennt,
Kann das die Betty? ;-)
Axel S. schrieb:> Hinreichend schnell: so daß du bei maximaler Baudrate wenigstens zwei> Samples pro Bitzelle hast, mehr wären besser.
Ist eine Möglichkeit...
... die andere ist, auf die Flanken zu gehen und die Zeit messen.
Bei einem Signal aus einem UART hat man den Vorteil, dass jedes Bit
immer gleich lange dauert.
Man kann das noch weiter verbessern, wenn man eine schräge Stopbit
Einstellung vorschreibt.
Zb. Stoppbit Länge 1,5
Dann kann man in der Regel bereits nach dem ersten Byte nach einer Pause
die Baudrate bestimmen.
====
Der Empfänger hat also zwei Zustände:
- Baudrate erkennen
- Daten lesen
Baudrate erkennen:
UART ausschalten und den IO Pin als normalen Input betreiben.
Oder, wenn möglich, die Flanken auswerten per Interrupt.
Dann die Samples auswerten und die UART Parameter durch Analyse
erkennen.
Daten lesen:
UART einschalten mit den analysierten Parameter.
Daten lesen ...
Im wiederholten Fehlerfall ggf. auf Baudrate erkennen wechseln.
Hallo,
für jede mögliche Baudrate einen UART mit den Eingängen parallel und
schauen, wo gültige Daten rauskommen. ;)
ich hae hier eine alte Handycam die sendet ihr Bild mit 921kBaud raus.
Ohne Punkt und Komma, will sagen: Startbit-8
Datenbits-Stopbit-Startbit-8 Datenbist usw. Da hat man keine Chance
mittendrin einzusteigen...
Gruß aus Berlin
Michael
HildeK schrieb:> Worauf beziehst du dich? Auf die unbekannte, variable Datenrate oder den> Abtastvorschlag?
Auf ersteres.
Unbekannte, variable Datenrate, unbekanntes Framing und unbekannter
Inhalt ohne Präambeln zur Synchronisation oder Erkennung o.ä.
Das ist ein brutalstmöglicher Designfehler.
Kannst Du Dich überhaupt darauf verlassen, dass es immer Pakete von
genau vier Bytes (mit welchem Aufbau auch immer) sind?
Anders herum: Wie stellst Du sicher, dass 4*10 nicht eigentlich 5*8
bedeuten soll?
Wenn möglich würde ich einen Laptop mitnehmen da einen 5€ saleae-Klon
dran und einfach den ganzen Datenstrom in den RAM saugen. Danach hat die
CPU eine Ewigkeit Zeit jede erdenkliche baud Rate zu testen.
Falls ein Laptop zu sperrig geht vlt auch ein SBC (da ist man halt etwas
beschränkter im RAM).
Edit: sigrok ist ein guter anfangspunkt für logic-analyzer Nutzung und
ist per python-skript erweiterbar.
Herbert schrieb:> Die Daten kommen gepulst, also mit Pausen. Ich kann natürlich ein> Startbit erkennen.
Man kann ein Startbit nicht erkennen, wenn das erste Bit eine 0 ist.
Zumindest nicht die Länge um daraus eine Baudrate abzuleiten.
> Es ist nur nicht klar, ob es ein Stoppbit gibt. Die> Daten sind aber ausreichend lang, um zu erkennen, ob es z.B. 4x8, 4x9> oder 4x10 Bits sind. Zwischen Stopp und Start gibt es auch eine minimale> Pause.
Die Pause ist auch als Stoppbit bekannt. UART ohne Stoppbit geht nicht.
Die Sender müssen sich schon an eine vorgegebene Spezifikation halten,
sonst wird das nix.
Man muss mindestens die drei Parameter wissen:
- Baudrate
- Wortlänge
- Parity Ja/Nein
Die Länge des Stoppbits ist für den Empfang nicht wichtig. Muss aber
selbstverständlich vorhanden sein.
Wenn alle Geräte mit den gleichen Parametern senden aber unbekannt ist,
kann man das Format meist analysieren und dann im Empfänger einstellen.
Eine automatische Erkennung aller Parameterkombinationen ohne
Datenverlust ist sicher möglich, aber extrem aufwendig, unzuverlässig
und teuer.
Es ist wesentlich besser, die Sender in einen genormten Zustand zu
bringen.
Uwe K. schrieb:> Es ist wesentlich besser, die Sender in einen genormten Zustand zu> bringen.
Und sei es pro Gerät nur ein kleiner µC, der das vorhandene Format
empfängt und die Daten dann in einem bekannten, festen Format ausgibt.
Das dürfte eine zuverlässige und kostengünstige Lösung sein.
Herbert schrieb:> Ich brauche also eine Format-Rate-Schaltung mit angeschlossener> Dekodierung.>> Wie macht man das am Klügsten?
Viele NXP LPCxxx µCs (z.B. LPC1768) haben Autobauding fürs Hayes
Protokoll, wie bei alten seriellen Modems.
Das basiert auf dem Timing des "A" oder "a", denn die Kommandos fangen
alle mit "AT" an.
Allerdings braucht man auch zwingend eine ausreichend lange Pause
zwischen den Daten, damit der Anfang korrekt erkannt wird.
In meinen Augen gehört der Hardware Designer erschossen der den Quarz
eingepart hat. Damit wäre die Abweichung deutlich unterhalb von 1%, auch
über einen weiten Temperarturbereich.
Jim M. schrieb:> Viele NXP LPCxxx µCs (z.B. LPC1768) haben Autobauding fürs Hayes> Protokoll, wie bei alten seriellen Modems.>> Das basiert auf dem Timing des "A" oder "a", denn die Kommandos fangen> alle mit "AT" an.
Damit ist es für den TO ungeeignet, da das erste Zeichen wahrscheinlich
nicht "A" ist.
Max D. schrieb:> Wenn möglich würde ich einen Laptop mitnehmen da einen 5€ saleae-Klon> dran und einfach den ganzen Datenstrom in den RAM saugen.
Abhängig vom Umfang der Daten würde ich über einen Logik-Analyzer mal
nachdenken. Ein Oversampling von 4 würde ich mindestens machen, 1 MSPS
und mehr über längere Zeit ist mit den Saleae möglich. Allerdings ist
das vorher trocken zu üben. Sonst gibts auf dem Feld böse
Überraschungen!
Eine Dekodierung des UART lässt sich anschließend in der zugehörigen
Software relativ bequem machen.
Eine Frage: Wie wurden denn die Geräte bisher ausgelesen, wenn es nicht
gerade du machen musst? Zum Beispiel zum Test bei der Entwicklung, oder
auch von anderen Operatoren im Feld?
Zweite Frage: Zu welchem Zeitpunkt beginnt das DUT Daten zu senden?
Sobald es Energie über das induktive Feld bekommt? Werden die Daten
zurückgesetzt, wenn ich den Vorgang erneut initiiere? (Oder direkt
gefragt: Musst du zwingend das erste Telegram richtig empfangen, oder
reicht es irgendein Telegram vollständig zu empfangen?)
