Oszillator? Resonator? Quarz?

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.
Anhang 21102Anhang 21103
Hat jemand eine Idee, wo ich so einen Taktgeber in der gewünschten Frequenz ordern könnte?

Hallo!

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

Zitat:

---

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.

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. ;)

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

Zitat:

---

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?

Zitat:

---

Laut DB kann man den M328P nur bis 16MHz takten

---

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

Zitat:

---

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)...

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.

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

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.

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

Hallo,
das sieht auf der Platine nach einem Resonator aus, vgl. reichelt Best-Nr. CSTCE 16,0 http://www.reichelt.de/Filter/CSTCE-...1407b48d92187c .
Scheint eine relativ hohe Temperaturdrift zu haben, angegeben sind 0,15% = 1500ppm (ein Quarz hat z.B. 30-50 ppm)
Grüße,
Bernhard

Zitat:

---

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.

---

Wenn mein Experiment mit dem 18.324 MHz Baudratenquarz (großes bedrahtetes Gehäuse) jetzt klappt, muss ich wohl einfach so einen Klopper auf die Platine kleben...

Zitat:

---

ob's mit einer krummen selbst ausgerechneten Baudrate besser geht ( Formel im ATMEL Datasheet )

---

danke, habe mir das mal angeguckt, werde aber nicht richtig schlau daraus. In den Tabellen im Datasheet stehen register, die ich in der BASCOM Hilfe so nicht wiederfinde. Ich befürchte, BASCOM lässt da kaum experimente zu. Und wie ich eine sinnvolle baudrate ausrechnen kann ist mir durch den Atmel Datasheet auch nicht wirklich klar geworden.

Zitat:

---

- 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.

---

Das war nur ein Beispielbild aus dem Internet. Bei mir ist ein 328p drauf.

Zitat:

---

- 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).

---

das war eine gute idee... Habe ich grad gemacht, und die LED fängt sofort an zu flackern wenn ich den RC-Empfänger mit einer Prise Eisspray behandle. Gleichzeitig ist auch keine Auswertung der seriellen Daten mehr möglich.

Code:

---

'Abfrage Framing Error:
  K = Usr And &B00010000
  If K = &B00010000 Then
  Toggle Portc.0
  End If

---

Zitat:

---

das sieht auf der Platine nach einem Resonator aus, vgl. reichelt Best-Nr. CSTCE 16,0

---

Oh ja, das sieht genau so aus wie das was ich brauche. Den Resonator gibt es sogar als 18.432 MHz, leider habe ich noch keinen Lieferanten gefunden.

Grad getestet:
Der Baudratenquarz behebt das Problem. Der Empfang funktioniert damit auch unter 0°C. Trotzdem wäre eine Lösung ohne Löterei schöner... Ich teste jetzt mal wahllos ein paar Baudraten.

Hallo!

Zitat:

---

Zitat von Willa

Trotzdem wäre eine Lösung ohne Löterei schöner...

---

... wenn es früher, so wie erst jetzt, getestet würde ... ;)

Ich bin fleissig weiter am testen... Einfach mal so verschiedene Baudraten in Bascom einzustellen hat nichts gebracht. Es gab Baudraten, bei denen der Empfang noch empfindlicher auf niedrige Temperaturen reagierte, und Baudraten bei denen die auswertung bei allen Temperaturen "halbwegs gut" lief. D.h. ich hatte viel Jitter in der Auswertung, wahrscheinlich weil oftmals Bytes verwechselt werden.
Jetzt habe ich etwas weiter gegoogelt und die Register Ubrr und u2x gefunden. Ubrr ist das das Baudraten register, es ist in Bascom bei 16MHz und 115200 baud standardmässig auf 8 eingestellt. U2x ist ein register für den "double speed mode", bei Bascom normalerweise ausgeschaltet. Im Datenblatt des m328p habe ich eine tabelle mit den typischen baudratenfehlern gefunden. Bei u2x = 0 und ubrr = 8 (bascom standard) ist der baudratenfehler bei -3.5% (warum zeigt bascom hier 7.84% an?).
Wenn man den doublespeed mode einschaltet (u2x=1) und ubrr auf 16 setzt, ist der fehler laut tabelle im Datenblatt angeblich nur noch +2.1%
Da ich mich scheinbar genau auf einer Toleranzgrenze befinde, könnte diese kleine Verbesserung ja bereits helfen.
Also habe ich das mal ausprobiert. Und siehe da, auf einmal funktioniert es auch mit dem 16MHz quarz und Eisspray. Es tritt kein Framingerror mehr auf, und mein Code scheint den RC-Empfänger sauber auszuwerten. Auch die Hitzesimulation per Glühlampe verursacht keinen Fehler. Also habe ich mich jetzt scheinbar ein Stück von der Toleranzgrenze wegbewegt.

Was mich nur noch wundert: Wenn ich mir die m32def.dat anschaue (im Moment teste ich alles auf einem Mega32), dann steht dort in einer Zeile
U2X = 1
Ich würde daraus schliessen, dass der double speed mode in Bascom standarmässig eingeschaltet ist. Lese ich aber in Bascom das Register aus (print Ucsra.u2x), dann wird mir eine 0 ausgegeben.

Das mit dem Datarate Register UBRR hatte ich gemeint.

Ich denk mal das U2X=1 bezieht sich auf den Platz des Bit's U2X im Register UCSRA, da es dort auf Bitplatz 1 ist.

Zitat:

---

Ich denk mal das U2X=1 bezieht sich auf den Platz des Bit's U2X im Register UCSRA, da es dort auf Bitplatz 1 ist.

---

Da hast du wohl recht, danke. Wenn man sich den Rest anguckt, erscheint das doch sehr naheliegend,

Zitat:

---

;UCSRA
RXC =7
TXC =6
UDRE =5
FE =4
;OR =3 ; old name kept for compatibilty
DOR =3
PE =2
U2X =1
MPCM =0

---