Oszillator? Resonator? Quarz?

[Willa]

Hallo!
Ich habe Probleme bei der Übertragung von Daten mit 115200 baud, und ich vermute, dass ein 16MHz Quarz einfach einen zu großen Fehler verursacht. Lustigerweise tritt dieser Fehler nur bei Temperaturen unter ca. 18°C auf.
Deswegen würde ich den gerne durch einen 18,432000MHz oder 20,275200MHz Taktgeber ersetzen.
Es handelt sich um ein Arduino Pro Mini Controllerboard, und ich habe grad Probleme zu verstehen was für ein Bauteil das ist... Bisher kenne ich Quarze, die werden mit 2 externen Kondensatoren betrieben und an XTAL1 und XTAL2 angeschlossen. Und dann kenne ich Oszillatoren, die müssen mit einer Spannung versorgt werden, und haben nur eine Verbindung zum XTAL1.
Aber was ist das hier für ein Taktgeber (siehe Bilder)? Der hat nur drei Pins (XTAL1, XTAL2 und GND), und er wird ohne externe Kondensatoren betrieben. In der Bauteilzeichnung sieht es so aus, als wären die Kondensatoren integriert. Nur habe ich so einen Quarz bisher noch nirgends gesehen.

Hat jemand eine Idee, wo ich so einen Taktgeber in der gewünschten Frequenz ordern könnte?

[PICture]

Hallo!

Deine Problembeschreibung ist für mich leider nicht vollständig. Willst du sehr stabile und temperaturunabhängige Frequenz oder fehlerfreie Datenübertragung haben ?

[Willa]

Deine Problembeschreibung ist für mich leider nicht vollständig. Willst du sehr stabile und temperaturunabhängige Frequenz oder fehlerfreie Datenübertragung haben ?

Ich möchte so einen Taktgeber haben ;-D

Nein, ehrlich gesagt weiß ich nicht genau was ich will, deswegen würde ich als erstes mal einen anderen Quarz probieren. Das Problem ist folgendes: Mein atmega328p (16MHz, 5V) auf dem Arduino Pro Mini muss einen RC-Empfänger auswerten. Dieser sendet mit 115200 baud. Das lässt sich nicht ändern. Mit 16 MHz und 115200 baud ergibt sich im atmega328p ein ziemlich großer baudratenfehler. Bei Zimmertemperatur macht das überhaupt nichts aus. Aber wenn der RC-Empfänger unter ca. 18 °C abkühlt, treten Fehler in der Übertragung auf. Im Moment habe ich einfach eine kleine Heizung an den Empfänger gebaut, aber das kanns ja nicht sein...

Ich glaube also, dass bei Zimmertemperatur der baudratenfehler gerade noch so an der Toleranzgrenze liegt. Wenn dann der RC-Empfänger abkühlt, ändert sich vielleicht die Frequenz des Oszillators im RC-Empfänger, und daddurch wird die Toleranzgrenze überschritten. Klingt alles ein wenig nach Hokuspokus, aber anders kann ich es mir nicht erklären... Und daher wäre ein baudratenquarz am mega328p erstmal die einfachste Lösung nach dem Problem zu suchen.

[PICture]

Angeblich handelt es sich um serielle Datenübertragung. Dabei helfen entsprehende Pausen zwischen gesendeten Bytes, da der Empfänger sich immer beim Startbit (negetive Flanke) neu synchronisiert und die Frequenz muss nur für die Dauer von einem Byte in Toleranz bleiben. Das ist die einfachste Lösung zum ausprobieren.

[Che Guevara]

Hi,

ich kann dir zwar nicht sagen, woher du solch ein Bauteil bekommst, aber nimm doch einfach einen normalen Quarz und dazu dann 2 Kondensatoren. Das wird man doch irgendwie unterbringen können?!
Allerdings sehe ich da ein klitzekleines Manko: Laut DB kann man den M328P nur bis 16MHz takten. Wenn du da drüber gehst, KANN es sein, dass alles funktioniert, aber es MUSS nicht. Ich wäre da sehr vorsichtig! Und da es sich hier schätzungsweise um einen Empfänger für deine Kopter handelt: Du benutzt auch das EEPROM, das wird mit ziemlich großer Wahrscheinlichkeit beim Übertakten nicht mehr Funktionieren... Lasse mich aber gerne eines Besseren belehren
Zum eigentlichen Problem:
Ich hatte auch mal eine Kommunikation zwischen zwei µCs (M328P und TINY2313) aufgebaut, lief auch mit bis zu 1.000.000 Baud. 115.200 waren auch dabei, das funktionierte auch draußen, bei kühlen 7°C. Ich denke, es liegt eher an deinem Sender. Du schreibst ja auch, dass du an diesen eine Heizung gebaut hast. Kannst du daran garnichts ändern?

Gruß
Chris

[Willa]

Angeblich handelt es sich um serielle Datenübertragung. Dabei helfen entsprehende Pausen zwischen gesendeten Bytes, da der Empfänger sich immer beim Startbit (negetive Flanke) neu synchronisiert und die Frequenz muss nur für die Dauer von einem Byte in Toleranz bleiben.

Der RC-Empfänger (es ist ein Spektrum Satellitenempfänger) sendet alle 11ms ein Paket aus 16 Bytes. Die Pause zwischen den Paketen nutze ich bereits um meine Auswerteroutine zu synchronisieren. Zwischen den einzelnen Bytes gibt es keine wirklich Pause. Oder meinst du etwas anderes?

Laut DB kann man den M328P nur bis 16MHz takten

Da hast du dich verguckt, der 328p kann schon bis 20 MHz.

Ich denke, es liegt eher an deinem Sender. Du schreibst ja auch, dass du an diesen eine Heizung gebaut hast. Kannst du daran garnichts ändern?

Mit "Sender" meinst du den RC-Empfänger? Ja, es liegt wahrscheinlich daran, dass der scheinbar minimal seine Baudrate ändert. Ich habe zwei verschiedene Empfänger ausprobiert (die sind sogar aus komplett unterschiedlicher Serie), aber bei beiden tritt das indentische Problem auf. Deswegen glaube ich ja, dass die Baudrate an die Toleranzgrenze kommt. Und da könnte eine genauere Baudrate auf dem Controller helfen.

Ich habe grad einen Testaufbau gemacht mit RNControl und dem Spektrum-Satelliten. Jetzt brauche ich nur Kältespray und einen steckbaren 18.432 MHz Quarz um es mal zu probieren (beides kaufe ich mir sehr bald bei Conrad)...

[Besserwessi]

Neben Quarzen gibt es auch noch billigere Keramik-Resonatoren. Da ist die Ausführung mit 3 Anschlüssen gar nicht so selten. Wenn der Platz knapp ist, wäre ein Quarz und die 2 Kondensatoren in einem Gehäuse auch keine so schlechte Idee.

[Che Guevara]

Oh... da hab ich wohl ausversehen das falsche DB erwischt. Sorry!
Evtl. kannst du dir das Signal ja mal mit dem Oszi ansehen und vergleichen, zw. kalt und warm...

Gruß
Chris

[wkrug]

Also bei der seriellen Datenübertragung hatte ich mit Quarz eigentlich noch nie Probleme.
Wenn's wirklich vom RC Empfänger her kommt, kannst Du mal versuchen, ob's mit einer krummen selbst ausgerechneten Baudrate besser geht ( Formel im ATMEL Datasheet ). Eventuell sendet der RC Empfänger genau auf der anderen Toleranzgrenze der Baudrate, als Du eingestellt hast.

[seite5]

hallo,
- auf Deinem Bild (Platine) ist eine V-Version des ATmega168 (low voltage version ab 1.8V) zu erkennen, die läuft lt. Datenblatt nicht mit 20MHz.
- Wenn durch den Baudratenfehler das Problem entsteht, müsste das Frame Error Bit im UART-Statusregister gesetzt werden, einfach mal den Wert
dieses Registers abfragen und ansehen (evtl. über eine LED).
mfg
Achim