Wie stĂśrempfindlich ist I2C?

[Thomas 'Tom' Malkus]

Marc Santhoff (m.santhoff@t-online.de):

Vielleicht vom Skript selbst. Schonmal gemessen, wie sich dessen
Ausfßhrungszeit verhält?

Standard-Linux weiß nix von "real time", wenn also die Last wechselt,
wird das Skript womĂśglich mit unterschiedlicher Reaktionszeit bedient..

Wäre auch mein Verdacht. Wobei ich aber beim Reichelt-Modul auch fest-
gestellt habe, dass man die Impulsdauer schon etwas großzügiger fassen
muss. Eine Abfrage genau auf 100 oder 200ms geht nicht. Aktuell habe
ich in der Software 80-120ms und 180-220ms, wenn ich das knapper mache,
habe ich fast nur defekte Daten. Die Flankensteilheit des Signals und der
breitbandige Empfänger in diesen einfachen Modulen sorgen wohl fßr
diese Schwankungen.

73, Tom
--
DARC OV I18|DL-QRP-AG #1186|G-QRP #14624|FISTS #15933|ARRL
http://dl7bj.org https://twitter.com/dl7bj

 

[Gernot Zander]

Hi,

in de.sci.electronics Marc Santhoff <m.santhoff@t-online.de> wrote:

hifi@gmx.de (Gernot Zander) schrieb:

Aaaber: Werfe ich das dem ntpd vor, zeigt der wahlweise ein Jitter von
Ăźber 10 ms oder wirft (beim Pi) die Quelle nach ein paar Minuten wegen
des Jitters als unzuverlässig weg.
Ich frage mich, wo das Jitter herkommt.

Vielleicht vom Skript selbst. Schonmal gemessen, wie sich dessen
Ausfßhrungszeit verhält?

Standard-Linux weiß nix von "real time", wenn also die Last wechselt,
wird das Skript womĂśglich mit unterschiedlicher Reaktionszeit bedient..

Nix script, kernel direkt pps vorgeworfen.

mfg.
Gernot

--
<hifi@gmx.de> (Gernot Zander) *Keine Mailkopien bitte!*
Die Signatur ist der schwerste Teil dieser Nachricht und befindet sich daher
unten. (Nico Hoffmann)

 

[Gernot Zander]

Hi,

in de.sci.electronics Gerhard Hoffmann <ghf@hoffmann-hochfrequenz.de> wrote:

Am 24.12.2014 um 14:00 schrieb Gernot Zander:
Hi,

in de.sci.electronics Marc Santhoff <m.santhoff@t-online.de> wrote:
hifi@gmx.de (Gernot Zander) schrieb:

Aaaber: Werfe ich das dem ntpd vor, zeigt der wahlweise ein Jitter von
Ăźber 10 ms oder wirft (beim Pi) die Quelle nach ein paar Minuten wegen
des Jitters als unzuverlässig weg.
Ich frage mich, wo das Jitter herkommt.

Vielleicht vom Skript selbst. Schonmal gemessen, wie sich dessen
Ausfßhrungszeit verhält?

Standard-Linux weiß nix von "real time", wenn also die Last wechselt,
wird das Skript womĂśglich mit unterschiedlicher Reaktionszeit bedient..

Nix script, kernel direkt pps vorgeworfen.

Auf der timenuts-liste bei febo.com lief gerade eine Diskussion zu
dem Thema. Da hat wohl jemand recht beeindruckende Zahlen auf dem
BeagleBoneBlack hinbekommen, und zwar im Userland.

Ausserdem kam zum Thema ntp letzte Woche ein wesentliches
Sicherheitsupdate fĂźr Linux.

Letzteres hat keinen Einfluss auf die Genauigkeit...

Es gibt unter Linux prinzipiell zwei MĂśglichkeiten: pps oder direkter
ntp-Treiber.
Bei pps sagt der ntp nur dem Kernel, wo er den Sekundenimpuls
herbekommt (beim Pi also, an welchem GPIO-Pin). Es findet keine
Decodierung statt (die initiale Zeit muss also woanders her kommen),
und Erfahrungen berichten, dass der eine fehlende Impuls bei 59 nicht
stĂśrt. Leider meint der Kernel aber im Log, dass die Abweichungen der
einzelnen Impulse so oft außerhalb der erwarteten Toleranz sind,
dass er die Quelle verwirft. (Den fehlenden 59er meldet er, aber
rausfliegen tut er deswegen nicht.)

Die andere Variante ist z.B. ein shm-Treiber fĂźr ntp. Dabei spielt,
weil das ja hier angemerkt wurde, eine Scriptlaufzeit keine Rolle,
weil der shm-Aufruf die decodierte Zeit und die zu diesem Zeitpunkt
(also in C unmittelbar vor- oder nachher) abgefrage Systemzeit in Âľs
zusammen dem ntp Ăźbergibt, so dass der nicht absolut, sondern die
relative Abweichung nimmt. Und ich behaupte mal, dass ein laufendes
C-Programm, welches unmittelbar nach dem Auslesen des 00er Impulses an
einem GPIO-Port einmal gettimeofday() aufruft, da keine nennenswerte
VerzĂśgerung eintritt.

Der ntp ist großzügiger mit Jitter, aber ich bekam bei DCF77 immer
mittlere Jitterwerte von 15-20 ms.
Bei DCF39 (und das dann sogar Ăźber USB!) habe ich meist unter 5 ms.

mfg.
Gernot

--
<hifi@gmx.de> (Gernot Zander) *Keine Mailkopien bitte!*
Ein System-Administrator ist nur so gut wie sein letztes Backup.
(Horst Knobloch)

 

[Gerhard Hoffmann]

Am 24.12.2014 um 14:00 schrieb Gernot Zander:

Hi,

in de.sci.electronics Marc Santhoff <m.santhoff@t-online.de> wrote:
hifi@gmx.de (Gernot Zander) schrieb:

Aaaber: Werfe ich das dem ntpd vor, zeigt der wahlweise ein Jitter von
Ăźber 10 ms oder wirft (beim Pi) die Quelle nach ein paar Minuten wegen
des Jitters als unzuverlässig weg.
Ich frage mich, wo das Jitter herkommt.

Vielleicht vom Skript selbst. Schonmal gemessen, wie sich dessen
Ausfßhrungszeit verhält?

Standard-Linux weiß nix von "real time", wenn also die Last wechselt,
wird das Skript womĂśglich mit unterschiedlicher Reaktionszeit bedient..

Nix script, kernel direkt pps vorgeworfen.

Auf der timenuts-liste bei febo.com lief gerade eine Diskussion zu
dem Thema. Da hat wohl jemand recht beeindruckende Zahlen auf dem
BeagleBoneBlack hinbekommen, und zwar im Userland.

Ausserdem kam zum Thema ntp letzte Woche ein wesentliches
Sicherheitsupdate fĂźr Linux.

Gruß, Gerhard

 

[Ralf Kiefer]

Gernot Zander wrote:

Der ntp ist großzügiger mit Jitter, aber ich bekam bei DCF77 immer
mittlere Jitterwerte von 15-20 ms.

Ist das grundsätzlich so, oder ändert sich der Jitter mit der Tageszeit
oder der Wetterlage?

Bei einem meiner früheren Arbeitgeber vor 15 - 20 Jahren gab's das
Problem mit der Ungenauigkeit vom empfangbaren DCF77-Signal ebenfalls.
Da man für das verkaufte Produkt kontinuierlich eine sehr genaue Zeit
benötigte, wurde ein eigener Controller entwickelt, der zwischen dem
DCF77-Empfänger (damals preisgünstiges Conrad-Teil) und der Software
hing. Der glich Ausfälle und Jitter aus, indem er ein eigenes Zeitsignal
generierte (BTW mit Kenntnis der Ungenauigkeit vom eigenen Quarz in
Abhängigkeit von der Umgebungstemperatur). Der war drauf ausgelegt auch
einen mehrstündigen Ausfall vom DCF77-Signal recht genau zu überbrücken,
damit es bei erneutem Empfang weder einen Sprung noch allzu große sanfte
Korrekturmaßnahmen in der Anlage geben mußte.

Ich erinnere mich an die Bemerkungen der Entwickler dieses Controllers
bzgl. dem reinkommenden Zeitsignal, daß sie Unwetter, Gewitter und
starken Regen zwischen Mainflingen und dem Standort gut erkennen können.
Weiterhin waren damals gerade größere Bildschirme in Mode, deren
Hsync-Frequenz nicht allzu weit von den 77,5kHz weg waren, und die teils
großflächig "streuten". Weitere Störquellen fanden sich natürlich in den
umgebenden Industrieanlagen. Soll heißen: das DCF77-Signal ist nicht
unbedingt robust.

Wenn's gar nicht zuverlässig lief, dann wurde das Empfängermodul oben am
Gebäude außen an die Wand mit ungefährer Blickrichtung Mainflingen
geschraubt, damit wenigstens die Bildschirme und Anlagenstörungen
draußen blieben.

Zwei weitere Punkte sind mir noch vage in Erinnerung: die Ausrichtung
der Antenne war auf dem Gehäuse markiert. Der andere Hinweis zu
möglichen Ungenauigkeiten ist vermutlich mit dem Hinweis im Wiki-Eintrag
angedeutet: "Haushaltsübliche Funkuhren setzen schmalbandige Empfänger
ein (mit 10Hz Bandbreite) und können daher den Sekundenbeginn nur auf
0,1s genau feststellen."

Gruß, Ralf

 

[Gernot Zander]

Hi,

in de.sci.electronics Ralf Kiefer <R.Kiefer.SPAEM@gmx.de> wrote:

Gernot Zander wrote:

Der ntp ist großzügiger mit Jitter, aber ich bekam bei DCF77 immer
mittlere Jitterwerte von 15-20 ms.

Ist das grundsätzlich so, oder ändert sich der Jitter mit der Tageszeit
oder der Wetterlage?

Mit einem ntp-Log-Graf-Tool ausgewertet sieht das den ganzen Tag/Nacht
gleich aus.

Zwei weitere Punkte sind mir noch vage in Erinnerung: die Ausrichtung
der Antenne war auf dem Gehäuse markiert. Der andere Hinweis zu

Da ich das selbst gebaut habe, kenne ich die Lage des Ferrits...

mĂśglichen Ungenauigkeiten ist vermutlich mit dem Hinweis im Wiki-Eintrag
angedeutet: "Haushaltsßbliche Funkuhren setzen schmalbandige Empfänger
ein (mit 10Hz Bandbreite) und kĂśnnen daher den Sekundenbeginn nur auf
0,1s genau feststellen."

Das ist, was ich vermute. Um das Signal trotz umgebender StĂśrungen zu
empfangen, muss der Empfänger schmalbandig sein, und ist er das,
passiert genau das, was du schreibst. Naja, auf 0,02 s, aber eben...
Nu sind 20 ms oder 5 ms ja nicht schlecht, aber halt auch nicht
atomar-gut

mfg.
Gernot

--
<hifi@gmx.de> (Gernot Zander) *Keine Mailkopien bitte!*
Ach, die Welt ist so geräumig, und der Kopf ist so beschränkt.
W. Busch

 

[Ralf Kiefer]

Gernot Zander wrote:

Mit einem ntp-Log-Graf-Tool ausgewertet sieht das den ganzen Tag/Nacht
gleich aus.

Dann deutet das durchaus auf die Art des Signalauswertung auf unterster
Ebene:

Das ist, was ich vermute. Um das Signal trotz umgebender Störungen zu
empfangen, muss der Empfänger schmalbandig sein, und ist er das,
passiert genau das, was du schreibst. Naja, auf 0,02 s, aber eben...
Nu sind 20 ms oder 5 ms ja nicht schlecht, aber halt auch nicht
atomar-gut

.... womit der eine Teil der Begründung für eine zwischengeschaltete
Instanz gegeben wäre, denn gemittelt wird es atomar-gut [1].

Ich müßte mal schauen, ob ich noch ein paar dieser Module im Keller
habe. Bei Interesse -> PM (Adresse ist genau so korrekt).

Gruß, Ralf

[1] Wenn man vom Versatz durch die Signallaufzeit zwischen Mainflingen
und dem Empfänger absieht

 

[Sieghard Schicktanz]

Hallo Ralf,

Du schriebst am Sat, 27 Dec 2014 10:20:09 +0100:

Mit einem ntp-Log-Graf-Tool ausgewertet sieht das den ganzen Tag/Nacht
gleich aus.

Dann deutet das durchaus auf die Art des Signalauswertung auf unterster
Ebene:

Muß ja wohl, das analoge DCF-77-Signal muß ja erstmal gleichgerichtet,
gesiebt und von einem Schmitt-Trigger digitalisiert werden, bevor das ein
ÂľC verdauen kann.
D.h. jede Signalschwankung, in Amplitude oder Phase, Ăźbersetzt sich in
Schwankungen der Umschaltflanken des Digitalsignals, vulgo "Jitter".

... womit der eine Teil der BegrĂźndung fĂźr eine zwischengeschaltete
Instanz gegeben wäre, denn gemittelt wird es atomar-gut [1].

DafĂźr wird dann jaauch gerne ein "VCXO" genommen, ein elektrisch
"gezogener" Quarzoszillator.

Wenn man vom Versatz durch die Signallaufzeit zwischen Mainflingen
und dem Empfänger absieht

Naja, Laufzeit hat man immer, aber die sollte nur sehr wenig schwanken,
auch wenn sogar der Luftdruck einen Einfluß hat. Nebel, Regen oder sowas
wirken da aber wesentlich stärker.

--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------