Digispark mini (attiny85) ohne Quarz mit softclock, RTC und DCF

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.

    Hinweis kann nach Kenntnisnahme deaktiviert werden!

    • six1 schrieb:

      generiere einen Timer Overflow und messe eine längere Periode Mike...
      Meinst du meinen Programmschnipsel, wo ich 1 Sekunde messe? Da dann zB. 5 Sekunden messen und das Ergebnis durch 5 teilen? Das bringt doch auch keine Verbesserung der Genauigkeit, weil ich ja wieder ganzalige werte für den timerload bekomme.
      Ich hatte meinen Versuchsaufbau über die Nacht laufen, offensichtlich länger keinen DCF-Empfang. Die Abweichung zur Funkzeit betrug an die 10 Sekunden (nach ein paar Stunden softclock-Betrieb).
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • six1 schrieb:

      mag sein, dass die Teilung nicht aufgeht. Es ist aber ein Unterschied, ob du 1/256 oder 1/65535 hast
      kapier nix mehr X/
      soll ich den 1 msec interrupt mit kleinerem prescale laufen lassen?
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • six1 schrieb:

      du vergleichst doch Zeiteinheiten der DCF mit Zeiteinheiten deiner Softclock, um die Ganggenauigkeit zu ermitteln.
      Je länger der Messintervall für die Zeiteinheiten, je genauer die mögliche Abweichung.
      Ich ermittle die Taktzahl zwischen einem Sekundenwechsel der RTC um daraus eine Zeitbasis (1 msec, bzw 25 msec) für die softclock und Decodierung des DCF zu generieren.
      Das mit den Sekundentakt aus dem DCF-Empfänger hab' ich verworfen, da es ja eine Zeit braucht, bis sich der Empfänger eingestellt hat und spikes im Signal müsste ich auch ausfiltern.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Kann es sein hier geht es hauptsächlich darum Softclock Time$ und Date$ von extern zu synchronisieren. Dann reicht doch DCF77(genauer geht es wohl nicht).
      Was mich immer wieder ins Grübeln bring, ist wie hier auch, die Aussage “Der Dcf- Decoder braucht aber eine hinreichend genaue Zeitbasis“. Ja der Decoder schon, soll ja das Signal mit Folgeauswertungen synchronisieren. ABER. Der DCF77-Sender sendet sogenannte Sekundenmarken"(diese sind Sau genau).
      Die Sekundenmarken werden von 0 bis 58 durchnummeriert. Die unterschiedliche Länge der Sekundenmarken werden in BCD dargestellt. Das machen aber die mir bekannten DCF- Module von sich aus.
      Ein vollständiges Telegramm(DCF77-Information) das in einer Minute gesendet wird, kann mit zählen dieser Marken und den zuordnen in ein Speicherbereich gesichert werden.
      Nun sollten die Information in dieser Zeit ausgewertet werden. Beispiel: Bit 20 = Startbit für Zeit.
      Hinweis: Mein alter Funkwecker hat nur ein DCF- Modul und ein BCD- Decoder für Anzeige. Hatte auch verstanden wie es funktioniert(tickt ja heute noch genau) nun kommen meine Zweifel. Kann doch nicht sein ohne ein oder mehrere Controller zu nutzen, damit die Uhrzeit stimmt. Na klar kann die alte „Möhre“ nicht das Rufbit auswerten oder die Wetterdaten für die nächsten Tage anzeigen. Habe ich bei meinen Wecker noch nie vermist.
      Meine Meinung:
      Uhr mit RTC- Modul, wie vorgesehen ist okay.(Triftkorrektur, Zeitumstellung und sogar mit Feiertagskalender) hatte ich schon mal hier im Forum beschriebe.
      RTC hat ja eine Batterie um Daten für ca. 25 Jahre zu halten. Vergleichbar mit einer guten Quarzuhr. Sollte dein Controller mal kein „Saft“ bekommen, muss nur nach „besaften“, gleich RTC gelesen werden. Frage wozu Taster für Korrektur?
      Für eine Uhr mit DCF, muss doch kein zusätzlicher RTC eingebaut werden um nach Spannungsausfall unverzüglich alle DCF- Informationen zu bekommen. Meist reicht die Uhrzeit und diese wird ja vorrangig übermittelt. Den Rest kann man ja noch später nachladen, wenn nicht, wie so oft heute behauptet wird, ohne geht nichts mehr.
      Als Uropa, habe ich nie gesagt „der alte Kram war besser“, nein „nicht besser aber für die meisten nachvollziehbar“. Heute braucht man schon Experten um ein Wecker zu stellen.
      Mit freundlichen Grüßen
    • fredred schrieb:

      Für eine Uhr mit DCF, muss doch kein zusätzlicher RTC eingebaut werden um nach Spannungsausfall unverzüglich alle DCF- Informationen zu bekommen.
      Das Problem hier ist der ungenaue Oszillator des Attiny, der bei Wegfall der DCF Zeit die Softclock nicht korrekt bedienen kann und andererseits die 8Bit Lib für DCF77, die ebenfalls eine gewisse Grundgenauigkeit braucht.


      six1 schrieb:

      das OSCAL nicht genauer beschreiben?
      das ist in der Tat ein Problem.
      Das Register hat nur 8 Bit und nur ein Inkrement macht bei 8MHz locker mal 300Hz Änderung (habs gemessen)
    • fredred schrieb:


      Der DCF77-Sender sendet sogenannte Sekundenmarken"(diese sind Sau genau).
      Hallo fredred,
      in der Theorie mag das ja so sein, in der Praxis kommen aber die Störungen dazu.
      Dann ist es schwierig, Peaks von Sekundenimpulsen zu unterscheiden.
      Um den genauen Start des Impulses zu sehen, müsstest du die Flanke erkennen. Dies würde aber auch auf die Peaks gehen.
      Wenn es keine Störungen geben würde, dann wäre die Genauigkeit des internen RC überhaupt kein Problem, man könnte ja immer auf das Signal synchronisieren.
    • ftelektro schrieb:

      INT/SQW am RTC -DS3231 Pin3 bringt einen ziemlich genauen Sekundentakt zur Auswertung.
      Softwareaktivierung habe ich in Codeschnippsel beschrieben.
      Braucht halt leider einen pin am Kontroller, die sind rar :S
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • hero schrieb:

      in der Theorie mag das ja so sein, in der Praxis kommen aber die Störungen dazu.
      Dann ist es schwierig, Peaks von Sekundenimpulsen zu unterscheiden.
      Um den genauen Start des Impulses zu sehen, müsstest du die Flanke erkennen. Dies würde aber auch auf die Peaks gehen.
      Wenn es keine Störungen geben würde, dann wäre die Genauigkeit des internen RC überhaupt kein Problem, man könnte ja immer auf das Signal synchronisieren.
      Ja sicher ist sicher, deshalb gibt es ja auch die Paritätsbits und außerhalb von Privat sind min zwei Zyklen Standart.
      Ein halbwegs gutes DCF- Modul sollt keine „Peaks“ als gültig durchlassen. Wirst doch auch kein Radio nutzen wollen, was nur piept und pfeift. Sehr oft ist es nur der eigene Aufbau der störanfällig ist.
      Wieder mal meine Bedenken. Wird DCF- Signal einmal vor Ort, sauber Empfangen, ist eine Störung sehr unwahrscheinlich. Die Energieversorgung des DCF- Senders ist so Sicher wie die des Bundeskanzleramts.
      Habe schon sehr viele Anwendungen gesehen, die soviel Sicherheit hatten, das nichts mehr funktioniert hat. Na das kann man doch viel einfacher haben, oder?

      Mit freundlichen Grüßen
    • ftelektro schrieb:

      RST-pin ist nach deinen Worten noch frei.
      Benötigst halt zur Reprogrammierung einen HV-Programmer.
      Ich weiß nicht warum und ob du das willst?
      nee, erst mal möchte ich den reset behalten. Ich möchte mal sehen, wie 'stabil' der bootloader ist. :D
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Heute sind meine Digisparks gekommen.
      Driver setup nach @Galahats Lexikoneintrag gemacht, Programmer auch nach dessen Anweisung eingerichtet.
      Digispark angestöpselt 'didadadim' Gerät erkannt, nach 2 Sekunden 'didadadum', Gerät abgemeldet. Das geht so dahin... Hm? Was soll's, Beispiel der blinkenden Led geladen und compiliert, Programmierer aufgerufen, Fenster vom micronucleus geht auf und wartet auf den spark. Prima! Spark eingestöpselt, nach kurzer Zeit werden paar Zeilen gezeigt, plop, Fenster zu, nix blinkt X/ Ein erneuter Aufruf des Programmers klappt nicht, man sieht, dass wohl ein Fensterchen aufgeht, aber sofort wieder verschwindet :cursing:
      Eine Stunde lang (oder sogar länger) Treiber installiert, destalliert, im i-net gesucht, nix gefunden. Neustart des Rechners..
      Neuer Versuch, bascom mit Programm und Programmierer gestartet, auf Aufforderung spark eingesteckt, paar Zeilen werden nur kurz gezeigt, Fenster zu fertig, nix blinkt :cursing: :cursing:
      Jetzt filme ich das micronucleus-Fenster bei dem Brennvorgang und was kann ich jetzt im meinem Filmchen lesen 'no data in input file, exiting' a_45_132ca9f5
      Nachdem in den Einstellungen vom Programmierer ja das 'use hex-file' angehakelt ist, mal den 'compiler-output' angeschaut und was seh' ich-?-genau, kein Haken bei hex.
      Häkelchen da gemacht, compiliert, geflasht, blinkt! a_64_3a718cae
      Puh, das war ein hartes Stück Arbeit! Jetzt kann ich mal meine Projekte ausprobieren...
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • So kleine Überraschungen würzen das Basteln: Der attiny85 hat ja 2 timer, timer0 und timer1. Es sind aber beides 8-bit-timer. Die Überraschung ist, dass 'load timer1, timer1load' sich an der timerbezeichnung klammert und bei timer1 einen 16 bitigen voraussetzt. Das ergibt dann sowas
      attiny85-load-timer1.PNG
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • aber nur so stößt man auf solche Sachen ^^

      Es gibt hier auch nur 'compare0A' und 'compare0B', für timer1 gibt's in der Richtung nix.

      Aber @hero, wenn ich dich grad' dran hab', wie müsste ich es mit ctc machen, wenn ich:
      mit derselben isr zunächst den timer überlaufen lassen will und die Überläufe zählen, um eine fixe Zeitspanne in Anzahl Takte umzurechnen. Wähle ich dann für compare den Wert 0 oder 255? Oder kann ich für verschiedene Modi dieselbe isr verwenden und halt den entsprechenden Modus enablen?
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von tschoeatsch ()

    • @tschoeatsch
      In der Hilfe steht
      TIMER1 is a 16 bit counter so it will be loaded with the value of 65536-value.
      Sieht so aus , als Timer1 bei Bascom generell als 16er durchgeht.
      Musst vielleicht nur Timer1=xxx eingeben und den Load-Befehl meiden.
      Versuch macht kluch.
      Weiss nicht, in wieweit der Befehl Load den Zählumfang des Timers nachfragt (regfile).

      Detlef
      Leichtsinn ist kein Mut, Vorsicht keine Feigheit.