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 ?
:
Bearbeitet durch User
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.
Wer auch immer sich das ausgedacht hat, hat nicht lange genug gedacht.
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.
:
Bearbeitet durch User
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?)
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.