Hallo, ich möchte gerne das OSCCAL Byte eines ATmega32M1 nutzen um die Störausstahlung zu verwischen. Gibt es Gründe warum die nicht funktionieren wird? Im Datenblatt in "Figure 29-20. Calibrated 8MHz oscillator frequency versus osccal value" lese ich bei 8MHz einen ASCCAL Wert von 96 ist das immer so solange ich den nicht selbst kalibriere? Ich dachte der Takt wird wärend der Fabrikation kalibiriert, wird das anders gemacht? Vielen Dank Simon
Simon schrieb: > Im Datenblatt in "Figure 29-20. Calibrated 8MHz oscillator frequency > versus osccal value" lese ich bei 8MHz einen ASCCAL Wert von 96 ist das > immer so solange ich den nicht selbst kalibriere? Ja Simon schrieb: > Ich dachte der Takt wird wärend der Fabrikation kalibiriert, wird das > anders gemacht? Hier wurde er auf 96 kalibriert Simon schrieb: > ich möchte gerne das OSCCAL Byte eines ATmega32M1 nutzen um die > Störausstahlung zu verwischen. Häää?
Ingo schrieb: > Simon schrieb: >> ich möchte gerne das OSCCAL Byte eines ATmega32M1 nutzen um die >> Störausstahlung zu verwischen. > Häää? Bei der EMV Messung haben wir bei der Störaustrahlung ein Maximum bei 32MHz (gemessen wird ab 30Mhz). Die Vermutung liegt nahe, dass dies eine Harmonische des CPU-Takts ist. Die Hoffnung ist, dass durch Änderung des Taktes diese Störaustrahlung verteilt und damit unter den zulässigen Bereich sinkt.
@Simon (Gast) >Bei der EMV Messung haben wir bei der Störaustrahlung ein Maximum bei >32MHz (gemessen wird ab 30Mhz). Die Vermutung liegt nahe, dass dies eine >Harmonische des CPU-Takts ist. Könnte sein. >Die Hoffnung ist, dass durch Änderung des Taktes diese Störaustrahlung >verteilt und damit unter den zulässigen Bereich sinkt. Spread Spektrum arbeitet aber mit deutlich höheren Modulationsferquenzen als man sie mittels softwaremässiger Umschaltung des Kalibrierbytes hinbekommt. Aber einen Versuch ist es wert.
Simon schrieb: > Die Hoffnung ist, dass durch Änderung des Taktes diese Störaustrahlung > verteilt und damit unter den zulässigen Bereich sinkt. ... was zwar nichts an der abgestrahlten Störleistung verbessert, aber auf dem Papier sieht es halt besser aus. :/
Simon schrieb: > ich möchte gerne das OSCCAL Byte eines ATmega32M1 nutzen um die > Störausstahlung zu verwischen. Ich würde mir da nicht zuviel Hoffnung machen. Wie sollen denn die internen RC-Takte den MC verlassen?
Man kann den RC-Oszilator nicht über OSCCAL modulieren, da der Wert nur bei einem Reset vom Oszilator übernommen wird.
Detlef Kunz schrieb: > Man kann den RC-Oszilator nicht über OSCCAL modulieren, da der Wert nur > bei einem Reset vom Oszilator übernommen wird. Doch, das geht schon. Auszug aus dem Datenblatt, Abschnitt 8.5 "Calibrated internal RC oscillator": "By changing the OSCCAL register from SW, see "OSCCAL Oscillator Calibration Register" on page 33, it is possible to get a higher calibration accuracy than by using the factory calibration." Du meinst das "Calibration byte", von dem mit Abschnitt 27.5 gesagt wird: "The ATmega16M1/32M1/64M1 has a byte calibration value for the internal RC Oscillator. This byte resides in the high byte of address 0x000 in the signature address space. During reset, this byte is automatically written into the OSCCAL Register to ensure correct frequency of the calibrated RC Oscillator."
Simon schrieb: > Die Hoffnung ist, dass durch Änderung des Taktes diese Störaustrahlung > verteilt und damit unter den zulässigen Bereich sinkt. Bei jeder Änderung des Wertes im OSCCAL Register hüpft dann dein Oszillator auf eine andere Frequenz. Je nach Scangeschwindigkeit und Mittelung des Speki wird einem dann ein Mischspektrum vorgegaukelt, das nur vom Messgerät abhängt - was wird bei den einzuhaltenden Grenzwerten über das Zeitverhalten gesagt? Wenn du deinen µC nicht Vollzeit, d.h. im 1/10-µs-Takt mit OSCCAL-Schreiberei beschäftigen willst, ist die Umschalterei nur Augenwischerei, weil du - wenn auch nur jeweils kurz - einen umherhüpfenden Peak erzeugst, der den Grenzwert überschreitet.
Der TO möge bitte posten, wenn er damit Erfolg hatte und seine EMV dann besser ist. Nehme mal an, dass es sich bei der Messung um das fertige Gerät handelt. Ist ja ein bisschen 'von hinten rum'.
:
Bearbeitet durch User
Wolfgang schrieb: > über das Zeitverhalten gesagt? Wenn du deinen µC nicht Vollzeit, d.h. im > 1/10-µs-Takt mit OSCCAL-Schreiberei beschäftigen willst, ist die > Umschalterei nur Augenwischerei, weil du - wenn auch nur jeweils kurz - > einen umherhüpfenden Peak erzeugst, der den Grenzwert überschreitet. Das ist aber ein gängiges Verfahren, welches auch in dem PC eingesetzt wird, an dem Du gerade sitzt. Google mal nach "Spread Spectrum Clocking".
Tim schrieb: > Das ist aber ein gängiges Verfahren, welches auch in dem PC eingesetzt > wird, an dem Du gerade sitzt. Klar, und je nach dem, in welchem Verhältnis die Bandbreite eines Empfänger zur Spreizbreite steht, wird das (Stör-)Signal abgeschwächt. Ein Speki, der meint, besonders gut zu sein, weil er schmalbandig arbeitet, kriegt dann davon entsprechend weniger mit.
Wolfgang schrieb: > Tim schrieb: >> Das ist aber ein gängiges Verfahren, welches auch in dem PC eingesetzt >> wird, an dem Du gerade sitzt. > > Klar, und je nach dem, in welchem Verhältnis die Bandbreite eines > Empfänger zur Spreizbreite steht, wird das (Stör-)Signal abgeschwächt. > Ein Speki, der meint, besonders gut zu sein, weil er schmalbandig > arbeitet, kriegt dann davon entsprechend weniger mit. Ja, genau das ist die Idee. Und es wird sogar behördlich anerkannt.
Tim schrieb: > Und es wird sogar behördlich anerkannt. ... und gipfelt dann in so Dingen wie PLC, wo das ganze Kurzwellenspektrum bis auf kleine Bereiche versaut wird, weil die Grenzwerte "eingehalten" werden.
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.