Hallo zusammen ! Ich habe seit kurzem ein PicoScope 2206A. Zum Austesten des Gerätes habe ich die serielle Dekodierung am TX-Pin eines Arduino UNO ausprobiert. Kein Problem mit dem 9 € China Logik Analyzer auch bei 115200 baud. Das PicoScope 2206A funktioniert auch bis 38400 baud, steigt dann aber bei 57600 baud aus. Er zeigt nicht mehr "hello world!" - wie gesendet - sondern unsinnige Zeichen. Hat jemand eine Ahnung, woran das liegen könnte? Danke für alle Tipps! Jürgen
Jürgen S. schrieb: > Hat jemand eine Ahnung, woran das liegen könnte? Vielleicht an den Geräteeinstellungen.
Jürgen S. schrieb: > Das PicoScope 2206A funktioniert auch bis 38400 baud, steigt > dann aber bei 57600 baud aus. Er zeigt nicht mehr "hello world!" > - wie gesendet - sondern unsinnige Zeichen. Das könnte an der UART implementierung im Arduino liegen. Bei 16Mhz und 57600 Baud und U2X auf 0 hast du einen Baudratenfehler von 2.1%. Normal sagt man, dass bis ca 3% akzeptabel sind, aber je nachdem wie die Abtastung im PicoScope implementiert ist, könnte das auch schon in die Hose gehen. Bei einem U2X von 1 ist der Fehler wesentlich geringer. Allerdings erhebt sich die Frage, ob die Arduino Entwickler dahingehend eine Analyse machen, welche U2X Stellung bei einer konkreten Baudrate die bessere wäre.
Karl H. schrieb: > Bei einem U2X von 1 ist der Fehler wesentlich geringer. Allerdings > erhebt sich die Frage, ob die Arduino Entwickler dahingehend eine > Analyse machen, welche U2X Stellung bei einer konkreten Baudrate die > bessere wäre. Bei 76800 hast du übrigens bei einem U2X von 0 wieder einen kleinen Fehler von 0.2%. Schafft das PicoScope das wieder? Wenn ja, würde ich das als starken Hinweis werten, dass das "Problem" zweigeteilt in einer ungeschickten Abtastung im PicoScope und einem Baudratenfehler im Arduino zu suchen ist.
Karl H. schrieb: > Normal sagt man, dass bis ca 3% akzeptabel sind Das sagt man natürlich nicht nur so, sondern das liegt daran, dass sich bei 8 Bit die Zeitfehler im letzten übertragenen Bit auf 9*3% = 27% der Bitdauer aufsummiert haben, so dass man bei halbwegs sauberen Signalen noch auf dem richtigen Bit abtastet. Ob es nun wirklich 3% sind, hängt davon ab, wie der Empfänger die Abtastung des Bits macht und auswertet. Und darüber schweigt sich das PicoScope Manual aus. Versuchweise könnte man im ATmega mal den Wert im Baudratenregister etwas ändern und gucken, was PicoScope und Sigrok (oder welche SW auch immer) dazu sagen.
Ich dachte auch zunächst, dass es an ungenauen Baudraten liegen könnte, aber der Fehler liegt bei ca. 1%. Anbei zwei Screenshots bei 38400 und 57600 Baud. Inzwischen bin ich mir ziemlich sicher, dass es ein Programmierfehler in der Beta-Version von PicoScope ist, denn die Signale stimmen, aber der Decoder macht zwischen zwei Zeichen eine "Pause" von 2-Bit und verschiebt dadurch alles.
Kann es sein, dass du im Decoder 2 Stoppbits eingestellt hast und am Arduino nur eines rauskommt? Das sieht so aus, als ob der auf Biegen und Brechen die Stoppbits abwartet.
Karl H. schrieb: > Kann es sein, dass du im Decoder 2 Stoppbits eingestellt hast und am > Arduino nur eines rauskommt? vergiss es. Ich seh schon am Bild: 1 Stoppbit
Karl H. schrieb: > Das sieht so aus, als ob der auf Biegen und Brechen die Stoppbits > abwartet. Ja, so ähnlich glaube ich ist es. Die Ursache ist aber keine falsche Einstellung, sondern, dass er das Stoppbit oder das Startbit ignoriert, vielleicht weil es ihm einen Hauch zu spät kommt. Zuerst dachte ich, es ist ein Performance Problem des Oszis (38400 geht, 57600 nicht) und war ziemlich enttäuscht, aber es ist wohl ein Softwareproblem.
:
Bearbeitet durch User
Jürgen S. schrieb: > aber der Decoder macht zwischen zwei Zeichen eine "Pause" von 2-Bit Stell doch versuchsweise den Decoder mal auf 7 Bit bzw. den Arduino auf 2 Stopbits. Vielleicht packt er das dann. Ändert sich was, wenn du die Abtastrate mal auf 1MS/s runter nimmst?
Jürgen S. schrieb: > Karl H. schrieb: >> Das sieht so aus, als ob der auf Biegen und Brechen die Stoppbits >> abwartet. > > Ja, so ähnlich glaube ich ist es. Die Ursache ist aber > keine falsche Einstellung, sondern, dass er das Stoppbit > oder das Startbit ignoriert, vielleicht weil es ihm einen > Hauch zu spät kommt. Du kannst ja mal probieren, zwischen den Buchstaben eine kleine Pause künstlich einzulegen.
Karl H. schrieb: > Das könnte an der UART implementierung im Arduino liegen. > Bei 16Mhz und 57600 Baud und U2X auf 0 hast du einen Baudratenfehler von > 2.1%. Du hattest Recht, genau daran liegt es. Es sind +2,1 %, wenn man das Signal vermisst. Das ergibt eine Baud-Rate von 58.825 und wenn man die einstellt, funktioniert der Decoder. Fazit: PicoScope ist nicht sonderlich fehlertolerant.
Warte mal. VIelleicht doch ein Bedienerfehler. In deinem Screenshot sehe ich in der Toolbar eine Einstellung von 32.irgendwas kS. Offenbar die Abtastrate. Das man damit ein 57k Bitsignal nicht ordentlich abtasten kann, ist klar. Oder wird dann die Einstellung ignoriert?
Das ist nur die Anzahl der Samples insgesamt beim "Single-Shot". Die Abtastrate steht rechts oben und ist 6,25 MS/s.
:
Bearbeitet durch User
Karl H. schrieb: > In deinem Screenshot sehe ich in der Toolbar eine Einstellung von > 32.irgendwas kS. Offenbar die Abtastrate. Bei einer Abtastrate würde man irgenwas mit "kSa/s" o.ä erwarten Oben rechts steht was von "Abtastrate 6.25MS/s" Jürgen S. schrieb: > SerialDecoding57600.png Da ist wohl RTFM angesagt
Jürgen S. schrieb: > Das ist nur die Anzahl der Samples insgesamt beim "Single-Shot". > Die Abtastrate steht rechts oben und ist 6,25 MS/s. Ah, ok. Um was im Screenshot lesen zu können, muss ich vergrössern und dann sehe ich nicht mehr das komplette Bild. Nö. Dann passt das schon. Die scheinen wirklich einen zeitlich sehr strengen Abtaster zu haben.
Wolfgang A. schrieb: > > Bei einer Abtastrate würde man irgenwas mit "kSa/s" o.ä erwarten Warum? MS/s sind doch auch nicht schlecht. "S" steht für "Samples". > > Oben rechts steht was von "Abtastrate 6.25MS/s"
Jürgen S. schrieb: > Wolfgang A. schrieb: >> >> Bei einer Abtastrate würde man irgenwas mit "kSa/s" o.ä erwarten > > Warum? MS/s sind doch auch nicht schlecht. "S" steht für "Samples". > >> >> Oben rechts steht was von "Abtastrate 6.25MS/s" nicht streiten. Ihm gings um die prinzipielle Einheit, die natürlich pro Zeiteinheit angegeben werden muss.
Aber MS/s ist doch pro Zeiteinheit, nämlich Megasamples pro Sekunde. Ich dachte es ging ihm um die Abkürzung "Sa" für Samples, da finde ich "S" auch ok, "s" kleingeschrieben dagegen bezeichnet Sekunden. Vielen Dank auch an alle für die Hilfe! P.S.: Ich denke, Wolfgang und ich haben aneinander vorbeigeredet.
:
Bearbeitet durch User
Teile deine Feststellung dann auch Picoscope mit, damit die das dann entschärfen können.
Jürgen S. schrieb: > Wolfgang A. schrieb: >> >> Bei einer Abtastrate würde man irgenwas mit "kSa/s" o.ä erwarten > > Warum? MS/s sind doch auch nicht schlecht. "S" steht für "Samples". Auf die Info "pro Sekunde", "pro Division" oder "pro ..." legt man aber schon Wert, wenn es um Abtastraten geht ;-)
Thomas O. schrieb: > Teile deine Feststellung dann auch Picoscope mit, damit die das dann > entschärfen können. Das habe ich schon gemacht (im Support-Forum), aber ich glaube, die sehen das nicht als Problem an. Die Software PicoSope ist zwar brauchbar, aber leider auch nicht mehr. Vielleicht mache ich einen PicoSope - Bug - Thread auf.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.