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