Hallo zusammen, bin gerad dabei einen präzisen 1,2 kHz Generator zu bauen. Dabei rechnet mir ein Atmega eine Sinustabelle aus, speichert sie in den eigenen SRAM und ruft sie dann zur Laufzeit draus ab. Über einen 8-Bit DA-Wandler wird anschließend der Sinus geformt. Wenn man nun zwei dieser Schaltungen aufbaut und mit dem selben externen Takt beispielsweise aus einem Sinusgenerator speist, sollte davon auszugehen sein, dass beide von den Atmegas generierten Signal zeitgleich einheitlich ausgegeben werden. Vielleicht Phasenverschoben da der Einschaltmoment nicht 100% der Selbe sein wird. Leider muss ich aber feststellen das die Signale zueinander driften. Nun meine Frage wie kann das sein. - Beide At-Megas arbeiten mit dem selben Takt ( aus einer Quelle ) - Beide At-Megas führen identischen Quellcode aus - Beschaltung beider At-Megas ist komplett identisch Gemessen wird mit einem Oszi auf zwei Kanälen. Zu Beginn werden die Nulldruchgänge der Signale mit Markern versehen. Nach einer Stunde liegt das nicht getriggerte Signal 20 µs neben den zuvor bestimmten Marker. Ein Messfehler ist somit eigentlich ausgeschlossen. Nachdem der Takt der At-Megas identisch ist, kann es nur an den Megas selbst liegen. Meine Vermutung sind die Diskriminatoren die den Takt auswerten. Allerdings findet man in keinen Datenblatt Angaben zu solchen Merkmalen. Deswegen wollte ich mal Nachfragen was ihr davon haltet. Verwendet wird ein AT-Mega 128 mit Taktfreq. 8 MHz Mfg CS
Präzession ist etwas komplett anderes als Präzision, und ob man Präzession mit einem Generator herstellen kann, wage ich zu bezweifeln.
Ich bitte um Verzeihung für den Ausrutscher in der Semantik. Ich denke aber die Beschreibung zeigt gut das Ziel gut auf. Interessant wäre warum du der Meinung bist das ein Generator sich für solche Zwecke nicht eignet?
CS schrieb: > Ein Messfehler ist somit eigentlich ausgeschlossen. Das glaube ich nicht! Man müßte Deine Schaltung kennen und Dein Programm. Dann müßte man wissen, ob irgendwo ein DC-Offset den Triggerpegel verschiebt. Vielleicht sogar im Oszi.
CS schrieb: > Wenn man nun zwei dieser Schaltungen aufbaut und mit dem selben externen > Takt beispielsweise aus einem Sinusgenerator speist In diesem Falle könnte man auch feuchten Torf nehmen.
Das Programm ist wenig spektakulär. Zu meiner Schande ist es in Bascom
geschrieben.
In der Hauptschleife, welche den Sinus erzeugt wird lediglich der Port
neue zugewiesen. 630 Punkte ergeben einen Sinus. Die berechneten
Sinuswerte stehen in Buffer(j). Ein Bytearray welches eben 630 Bytes
tief ist. Das funktioniert an sich recht gut.
Code:
Do
For J = 1 To 630 Step 1
Porta = Buffer(j)
Next
Loop
Zum Thema DC-Offset. Das Oszi misst AC und nach dem DA-Wandler sitzt
eine OP-Stufe zur Pegelanpassung. Ausgekoppelt wird diese über 1µF. Ein
DC-Offset kann ich mir damit schwer vorstellen. Ist aber ein
interessanter Ansatz. Ich muss ehrlich zugeben ein Messfehler in der
Form kam mir noch nicht in den Sinn.
Pfffährt schrieb: > In diesem Falle könnte man auch feuchten Torf nehmen. Man könnte auch einfach nur posten wenn man was zum Thema zu sagen hat. Ich denke jedem ist klar, dass das nicht der Endzustand ist. Geplant ist den Takt über Ofenoszillatoren zu erzeugen, welche nur 1-2 ppm Schwankungen unterliegen. Solang der gleiche Takt aber nicht das Ziel erfüllt, bringt es wenig darauf einzugehen.
Pfffährt schrieb: > CS schrieb: >> Wenn man nun zwei dieser Schaltungen aufbaut und mit dem selben externen >> Takt beispielsweise aus einem Sinusgenerator speist > > In diesem Falle könnte man auch feuchten Torf nehmen. Ich denke es spielt auf den "SINUS" aus dem Generator an. Besser wird wohl ein Rechteck sein. k.
Damit wäre die Synchronität geklärt. Leider nicht der Drift der Signale zueinander über die Zeit.
Hallo CS, wie sieht denn die Schaltung zur Pegelanpassung aus. Ob man einen Sinus oder Rechteck als Takt nimmt, ist völlig banane, da der Takt um Größenordnungen von Deinem Ausgangssignal weg ist. Es kann nur an einem Aufwärmeffekt von OPs oder so liegen. Wie sieht denn die Verschiebung nach einer weiteren Stunde aus ?
Das einer der beiden µC Takte verliert erscheint mir auch sehr ungewöhnlich. Ich würde auch eher auf ein Problem im der Auswertung tippen. Lässt sich aber verifizieren. Vertausch mal die Messkanäle und miss noch mal 1 Stunde. Wenn der 'Fehler' dann auf den anderen Kanal mitgegangen ist, steigen die Chance, dass es was mit den µC zu tun hat.
Ist da sichergestellt,dass nicht irgendwelche Interrupts am Programm beteiligt sind? Nur wenn das oben aufgeführte Programm alleine abläuft, entsteht die exakte Frequenz, sonst mischen irgendwelche Interrupts mit, die den Sinusverlauf in fast zufälliger Weise unterbrechen. Eine andere Möglichkeit wäre, dass durch verschiedene Empfindlichkeit der beiden Aufbauten gegen Störimpulse der Programmablauf ins "Stottern" kommt. Die nächste Version ist, dass der Takt keine genauen Flanken hat, sodass beide oder einer der Kontroller einzelne Flanken verpasst.
Möglich wäre auch ein Hardwareproblem, das zu gelegentlichen Resets führt. Als allererstes würde ich aber mal überprüfen, ob auch wirklich mit 100%iger Sicherheit beide Controller auf externen Takt laufen.
CS schrieb: > Zum Thema DC-Offset. Das Oszi misst AC und nach dem DA-Wandler sitzt > eine OP-Stufe zur Pegelanpassung. Ausgekoppelt wird diese über 1µF. Ein > DC-Offset kann ich mir damit schwer vorstellen. Dann lass dir doch einfach einen Sägezahn ausgeben und zähle die Bitwechsel des MSB mit jeweils einem Ereigniszähler. Wenn die Zahlen dann auseinander laufen, würde ich wirklich mißtrauisch werden. Was sind das denn für DA-Wandler? mit R2R aufgebaut? Dann weichen die Wandler schonmal voneinander ab. Analoge Signalverarbeitung ist beteiligt(der OP und 1µF), Leckströme und leichtes (thermisches) Weglaufen der OPV tut auch das seine. Wie sieht die Stromversorgung aus? Netzgekoppelt? Dann kommen von da auch Störungen rein. Kann man das nicht auch mit einem einzigen Controller lösen? Wie Präzise muss es denn sein? Wenn du zwei 8bit D-Latches nimmst, und denen einen synchronen Latchpuls gibst, werden die Ausgangszustände beider nahezu gleichzeitig aktualisiert. Wenn die Pins des µC nicht reichen, vielleicht einen Port nehmen und pro Kanal zwei Latches "hintereinander" schalten.
1 | ___ _____ _____ |
2 | | 8 8 |Latch| 8 |Latch| 8 |
3 | PA|===/===##===/===| 1A |===/===| 1B |===/===DA1 |
4 | | || 1A--|>____| B--|>____| |
5 | PB1|--1A || _____ _____ |
6 | PB2|--2A || 8 |Latch| 8 |Latch| 8 |
7 | PB3|--B ##===/===| 2A |===/===| 2B |===/===DA2 |
8 | | 2A--|>____| B--|>____| |
9 | ___| |
Programmcode als Pseudocode: -Programmcode Beginn- Do Analogwert 1 berechnen/aus Tabelle lesen Analogwert 1 auf PA ausgeben Latchpuls 1A setzen Latchpuls 1A löschen Analogwert 2 berechnen/aus Tabelle lesen Analogwert 2 auf PA ausgeben Latchpuls 2A setzen Latchpuls 2A löschen Latchpuls B setzen Latchpuls B löschen Loop -Programmcode Ende- mfg mf
Wo gerade von den Latches gesprochen wird: Ich habe auch so eine Schaltung mit 2 mal DAC08. Da habe ich 3 stck LS373 (oder 374) drinne. Da wird das eine 8 bit Latck vorgeladen und wenn ich den 2ten Kanal schreibe wird der vorgeladene wert zeitsynchron auf das 2te Latch durchgereicht. Wenn man die Ausgabeschleife dann in Inlineassembler mit Indexregister x und Y macht wird es sogar recht schnell. Klaus
Rufus Τ. Firefly schrieb: > Präzession ist etwas komplett anderes als Präzision, korrekt. > und ob man > Präzession mit einem Generator herstellen kann, wage ich zu bezweifeln. [Loriot modus] Ach. [/Loriot modus] Es ist sogar trivial dies herzustellen. Denn: Die Präzession ist allgemein die Richtungsänderung der Achse eines rotierenden Körpers. D.h. z.B. ein Handstreich genügt am Kresiel. Ob man denjenigen der diesen Handstreich auf Anforderung ausführt als Generator bezeichnen will. Oder als Experimentator. Nun denn. Ach.
Wow danke für die vielen Antworten. Ich weis gar nicht wo ich anfangen soll ;) Das Signal läuft kontinuierlich über die Zeit. In 10 Stunden ist es um knapp 90° "gewandert". Bei runden 1,2 kHz ca. 200 µs. Messkanäle wurden auch schon vertauscht. Sachverhalt hat sich mit gedreht ;) Hinsichtlich der Tatsache, dass immer auf Kanal 1 getriggert wird auch irgendwie sinnig. Interrupts sind alle Disabled. Es werden wirklich lediglich die Zeilen, wie zuvor beschrieben, ausgeführt. Ein Reset kann auch nicht sein, da zu Beginn des Programms auf den zweiten Controller gewartet wird. Ein Taster lässt beide in die Schleife rennen und den Sinus generieren. Der Takt ist ein sauberer Sinus. Keine Glitches, Störimpulse oder sonstiges überlagert. Wird an einen zweiten Oszilloskop mit geschnitten. Mini Float schrieb: > Was sind das denn für DA-Wandler? mit R2R aufgebaut? Dann weichen die > Wandler schonmal voneinander ab. > Analoge Signalverarbeitung ist beteiligt(der OP und 1µF), Leckströme und > leichtes (thermisches) Weglaufen der OPV tut auch das seine. > Wie sieht die Stromversorgung aus? Netzgekoppelt? Dann kommen von da > auch Störungen rein. Die DA-Wandler sind mit R2R aufgebaut. Sicherlich ein gewisses Problem. Einen systematischen Drift würde ich dem R2R Netzwerk dennoch nicht zuschreiben. Auch thermisches einwirken usw. spielt sicher eine Rolle. Aber im µS Bereich? Der systematische Drift macht sorgen. Würde der Sinus um +-1 µs schwanken ok. Aber er entfernt sich kontinuierlich ca. 20 µs die Stunde. Irgendwie muss das doch bedeuten das entweder falsch gemessen wird und der Messfehler sich aufsummiert, oder der Takt von einem Controller schneller interpretiert wird als vom anderen. Deswegen auch mein anfänglicher Tipp auf die Diskriminatoren welche den Takt auswerten. Zwei µC sind notwendig da die Referenzen räumlich von einander getrennt werden müssen. Dabei sollten die generierten Signal auf +-1µS genau laufen.
Ergänzung ...an Autor: CS (Gast) Wenn du Interesse hast das ganze auf einem Prozessor mit den 3 Latches laufen zu lassen kann ich dir gern die Software heraussuchen und eine grobe Schaltskizze machen. Ich müsste dann allerdings auch noch ein wenig in der Software kommentieren, da es bei mir an sowas immer mangelt. Software ist in Bascom mit Assembler für die Ausgabe. Aus Gründen der Geschwindigkeit ist die Tabelle für jeden Kanal aber nur $FF lang. Er kann Sinus , Dreieck und Rechteck mit einstellbarem Duty. Zudem kann die Phase der beiden Kanäle in 1/255zigtel Schritten eingestellt werden. Bedienung läuft über terminalprogramm. Klaus
CS schrieb: > Der Takt ist ein sauberer Sinus. Keine Glitches, Störimpulse oder > sonstiges überlagert. Wird an einen zweiten Oszilloskop mit geschnitten. Das ist doch unschön. Wenn du einen Fehler suchst würde ich diese Fehlerquelle mal zunächst ausschliessen und einen integrierten Quarzoscillator einsetzen. der Schmitttrigger im Atmel hat auch eine Drift. Klaus
Hi >- Beide At-Megas arbeiten mit dem selben Takt ( aus einer Quelle ) >- Beide At-Megas führen identischen Quellcode aus >- Beschaltung beider At-Megas ist komplett identisch Da fehlen noch die Fuses. MfG Spess
Kommt mir auch ein wenig komisch vor. Kannst du den Datenstrom zu den DAC`s messen? Kannst du den Punkt wann die Spannung wieder Steigt messen? Ich vermute mal auf einen unterschiedlichen Temperaturdrift der DAC`s wodurch die Zeiten gleich sind aber die Spannungen sich verschieben Hab ein wenig mit dem Abschicken gebraucht .. hat sich ja schon erledigt
Klaus De lisson schrieb: > der Schmitttrigger im Atmel hat auch eine > Drift. Das würde aber nur Schwankungen ergeben, keine kontinuierliche Verschiebung. Denn Takte dazuerfinden oder weglassen kann der Schmitttrigger wohl kaum. Fuses auf internen Taktgeber überprüfen. Wobei dann eigentlich die Verschiebung stärker sein müsste. Ansonsten mal mit Kältespray die AVRs, die DACs und die OPVs testen, ob sich da eine Änderung ergibt.
Es ist bisher völlig offen, wie du die Mikrocontroller synchronisiert hast. CKOUT? Mein Tipp liegt irgendwo in die Richtung.
Simon K. schrieb: > Es ist bisher völlig offen, wie du die Mikrocontroller synchronisiert > hast. Er schrieb doch: Ein Sinus für beide.
Laufen denn die µC überhaupt mit dem externen Takt ? Ohne umstellen der Fuses wird nur der interne Takt genutzt, auch wenn ein externer Takt anliegt. Bei einem externen 8 MHz Takt könnte es eventuell passieren das man eine nicht vorgesehene, und nicht perfekte Synchronisation des internen Taktes auf den externe bekommt - das könnte die so geringe Drift erklären. Wie schon geschrieben, sollte die Aufgabe auch 1 µC erledigen können, auch schon ein etwas kleinerer.
Eine Veröffentlichung des Maschinencodes, der auf den AVRs läuft (BASCOM-Compilat?) bspw. zur Kontrolle auf tatsächliche "Interrupt-Freiheit" (oder doch ein "versteckter" Timer/IOHandler/Scheduler?) sowie eine schematische Darstellung des Versuchsaufbaus, die "im Bild" anstelle von aneinandergereihten "Lesungen zum Verdrahtungsplan" u.a zweifelsfrei erkennen läßt, welches Taktsignal (z.B. Frequenz, Pegel, Wellenform) auf welchem Weg (z.B. Leitungswege, galvanisch oder kapazitiv) die AVRs erreicht, wäre gewiß sinnvoller, als hier weiter mit "Bleiguß in Glaskugeln" herumzuphantasieren. ;-)
Timm Thaler schrieb: > Klaus De lisson schrieb: >> der Schmitttrigger im Atmel hat auch eine >> Drift. > > Das würde aber nur Schwankungen ergeben, keine kontinuierliche > Verschiebung. Denn Takte dazuerfinden oder weglassen kann der > Schmitttrigger wohl kaum. Doch, da hat Klaus schon recht.... aber die beschriebene Drfit von "knapp 90°" halte ich dafuer doch zu gross. CS sollte wirklich mal das tun, was ihm hier schon mehrfach empfohlen wurde: 1. Kein Sinus sondern Rechteck als Takt 2. Selektiv Temperatureinfluesse pruefen 3. Schaltung posten 4. Assemblerlisting posten 5. Fuses posten gruss Michael
Danke Mexman, Ich finde auch, dass man bei merkwürdigen Fehlern zunächst alles optimieren sollte was man mit einfachen Mitteln kann. Zudem kann TO ja auch einfach seinen Lookuptable mal abweckselnd mit 00 unf ff füllen. Dann wäre ein oscillografieren am MSB auch simple. Klaus de Lisson
Axel Gartner schrieb: > Simon K. schrieb: >> Es ist bisher völlig offen, wie du die Mikrocontroller synchronisiert >> hast. > Er schrieb doch: Ein Sinus für beide. Ulrich schrieb: > Laufen denn die µC überhaupt mit dem externen Takt ? Ohne umstellen der > Fuses wird nur der interne Takt genutzt, auch wenn ein externer Takt > anliegt. Das meinte ich.
Klaus de Lisson p.s. Zudem könnte ja auch sein Sinusgenerator thermische Offsetdrift haben, die dann von dem einzelnen CPU verschieden beantwortet würde.
CS schrieb: > Das Signal läuft kontinuierlich über die Zeit. In 10 Stunden ist es um > knapp 90° "gewandert". Bei runden 1,2 kHz ca. 200 µs. > Das sind also in 10 Stunden 1/4 Schwingung bei 1200 Hz. also eine relative Abweichung von 1 zu (4 x 1200 x 10 x3600) = (127,8 EXP 6) Es kann sich also wirklich nur um ein gelegentliches "Stolpern" im Programmablauf handeln, z.B. dass sich einer der beiden Kontroller wegen geringerer Störsicherheit einen peak einfängt. Ohne Bild vom Aufbau, Schaltbild , Code usw. wird das nichts. Wenn Du weiter herum-geheim-nistest, mach den Dreck alleene. So ist jeder getippte Buchstabe umsonst.
Es ist meiner Meinung nach höchst unwahrscheinlich, dass der Prozessor "stolpert". Das Problem werden wohl einfach die falsch gesetzten Fusebits sein.
Simon K. schrieb: > Es ist meiner Meinung nach höchst unwahrscheinlich, dass der Prozessor > "stolpert". Das Problem werden wohl einfach die falsch gesetzten > Fusebits sein. Hallo Simon, Du meinst also, beide uC laufen auf internem Oszillator und nicht-synchron? Dann waere das aber ungefaehr wie 6 Rchtige im Lotto: Die internen Oszillatoren sind dermassen daneben, da sind <0.03ppm m.E. nicht drin! Oder hast Du da bessere Erfahrungen gemacht? Ich habe bisher mit dem internen Oszillator nicht mal eine RTC basteln koennen, die bei Austausch des uC nicht mindestens 10 Minuten in der Woche falsch ging! Gruss Michael
Michael Roek schrieb: > Du meinst also, beide uC laufen auf internem Oszillator und > nicht-synchron? Könnt ihr nicht lesen? im ersten beitrag schreibt der TO: CS schrieb: > Wenn man nun zwei dieser Schaltungen aufbaut und mit dem selben externen > Takt beispielsweise aus einem Sinusgenerator speist,
Was ich zum Thema Präzision noch anmerken wollte: CS schrieb: > Code: > > Do > > For J = 1 To 630 Step 1 > > Porta = Buffer(j) > > Next > > Loop Ich weiß nicht was Bascom für einen Code ausspuckt, aber vermutlich werden für die äußere Schleife ein paar Extra-Takte anfallen. Der erzeugte Sinus hat also kleine Plateaus, die Samples werden dort nicht gleichmäßig erzeut. Ergibt einen gewissen Klirrfaktor. Keine Ahnung ob das für die Anwendung relevant ist, aber ich hebe mal vorsichtshalber den Finger. Jörg
Solange man bei AVR die Fuses nicht verstellt, läuft der mit dem internen Takt, unabhängig davon ob man zusätzlich einen externen Takt anlegt. Wenn alles so wäre wie anfangs beschrieben sollten die beiden µC synchron laufen und es gäbe keine Problem. Um den weiter aktiven internen Takt auszuschließen sollte der TO endlich mal verraten was in den Fusebits der beiden µC steht.
Hallo zusammen, Jörg H. schrieb: > Ich weiß nicht was Bascom für einen Code ausspuckt, aber vermutlich > werden für die äußere Schleife ein paar Extra-Takte anfallen. Der > erzeugte Sinus hat also kleine Plateaus, die Samples werden dort nicht > gleichmäßig erzeut. Ergibt einen gewissen Klirrfaktor. Keine Ahnung ob > das für die Anwendung relevant ist, aber ich hebe mal vorsichtshalber > den Finger. Sehr richtig! Direkt nach dem R2R Netzwerk ist dies, wenn auch minimal, noch zu sehen. Die Op-Stufe sowie ein nachgelagert Tiefpass filtern das Signal dann aber soweit, dass dieses Plateaus nicht mehr merklich zu registrieren sind. Dennoch danke für den Hinweis. Die Fuses stehen selbstverständlich auf externen Takt. Benutzt man das interne RC-Glied ist an Synchronität nicht zu denken. Den Takt auf ein Rechteck umzuschalten ist zwar im Testaufbau möglich, im späteren Einsatz jedoch nicht da hier ein stabiler Oszillator mit 0.003 ppm/Tag den Takt erzeugt. Nachdem die Stellen Takt, LSB des µC, Ausgang R2R Netzwerk gemessen hatte, konnte ich den Fehler eingrenzen. Eindeutig erzeugte der µC den Drift. Da ich mir nicht vorstellen konnte, wie die Hardware des µC dies bewerkstelligen soll und wie die Diskussion gezeigt hat, hier auch keiner :D, ist der Code in Assembler implementiert worden. Sie da, der Drift ist nicht mehr vorhanden. Mein Tipp ist nun der Compiler, bzw. irgendwelchen ungewollten Sprünge die sich bei µC A von B unterscheiden. Leider sitze ich gerad vor einem anderen PC auf welchen die Software des µC nicht gespeichert ist. Ich werde die Tage den Basic Code posten. Vielleicht fällt euch etwas auf was ich übersehen hab. Das Statement "Disable Interrupts" findet sich aber definitiv im Code :D Ich möchte mich an der Stelle bei allen hier für die Anregungen und Hinweise bedanken. MFG CS
CS schrieb: > ist der Code in Assembler implementiert worden. Sie da, der > Drift ist nicht mehr vorhanden. Mein Tipp ist nun der Compiler, bzw. > irgendwelchen ungewollten Sprünge die sich bei µC A von B unterscheiden. Wenn man Baskom einmal in HEX wandelt und auf beide µC spielt? Wer glaubt daran?
Wenn du einen definiert laufenden Sinus produzieren möchtest, schmeiß den ganzen Basic-Kram weg und nimm eine Assemblerschleife. Such mal nach "miniDDS" von Jesper Hansen.
cS, evtl sottest mal erklären, wozu das ganze sein soll.... evtl gibt zb mit DDS , einfachere und bessere möglichkeiten...
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.