Wie stĂśrempfindlich ist I2C?

[Manuel Reimer]

Hallo,

ich mĂźsste eine I2C-Verbindung Ăźber knapp 20 Zentimeter fĂźhren. Parallel
läuft eine weitere Signalleitung, auf der aber nur mit 1Hz gesprochen
wird (da liegt ein DCF77-Signal drauf). Problematisch oder kein Thema?

Danke im Voraus

Gruß

Manuel

 

[Rafael Deliano]

> I2C-Verbindung Ăźber knapp 20 Zentimeter

* Pegel 5V oder kleiner ?
* Steuerung per Software über Controller sodaß
man das Timing langsam machen kann ?
* pullup kein Widerstand sondern Stromquelle ?

I2C wurde in den 80ern bei C-Netz Funktelefonen
als Verbindung Handset neben Fahrer zum Funkteil
im Kofferraum verwendet. Wenn das in einem Bus
verbaut wurde war das Kabel entsprechend lang.
D.h. man kann auch I2C leidlich sicher Ăźber Kabel
fĂźhren.

MfG JRD

 

[MaWin]

"Manuel Reimer" <Manuel.Nulldevice@nurfuerspam.de> schrieb im Newsbeitrag
news:m70rb3$583$3@news.albasani.net...

ich mĂźsste eine I2C-Verbindung Ăźber knapp 20 Zentimeter fĂźhren. Parallel
läuft eine weitere Signalleitung, auf der aber nur mit 1Hz gesprochen wird
(da liegt ein DCF77-Signal drauf). Problematisch oder kein Thema?

20cm sind fĂźr I2C kein Thema, das DCF77 Signal wird sogar eine eher geringe
besondere Flankensteilheit haben. NatĂźrlich sollte es nicht zu hochohmig
angeschlossen sein.
--
MaWin, Manfred Winterhoff, mawin at gmx dot net
Homepage http://www.oocities.org/mwinterhoff/
dse-FAQ: http://dse-faq.elektronik-kompendium.de/

 

[Manuel Reimer]

On 12/19/2014 10:51 AM, MaWin wrote:

20cm sind fĂźr I2C kein Thema, das DCF77 Signal wird sogar eine eher geringe
besondere Flankensteilheit haben. NatĂźrlich sollte es nicht zu hochohmig
angeschlossen sein.

Das DCF? Ist hochohmig angeschlossen. Mit 10k. Warum sollte das ein
Problem sein?

Gruß

Manuel

 

[Rafael Deliano]

Das DCF? Ist hochohmig angeschlossen. Mit 10k. Warum sollte das ein
Problem sein?

Die parallel gefßhrten Adern haben Koppelkapazität.
Am schmlimmsten Flachbandkabel.
Steile Schaltflanken kĂśnnen jeweils Ăźbersprechen.
D.h. I2C kĂśnnte auch das digitale DCF77 Signal stĂśren.

Andere Frage wäre: ist der DCF77 Empfänger so ein Modul
a la Pollin ? Die sind Ăźber ihre Antenne relativ leicht
stĂśrbar. WĂźrde man ungern mehr digitale Elektronik in
der Nähe haben als nÜtig.

MfG JRD

 

[Stefan]

Am 19.12.2014 11:46, schrieb Rafael Deliano:

Das DCF? Ist hochohmig angeschlossen. Mit 10k. Warum sollte das ein
Problem sein?

Die parallel gefßhrten Adern haben Koppelkapazität.
Am schmlimmsten Flachbandkabel.
Steile Schaltflanken kĂśnnen jeweils Ăźbersprechen.
D.h. I2C kĂśnnte auch das digitale DCF77 Signal stĂśren.

Da kommt es dann drauf an, wie oft bzw. wann man I2C und/oder DCF77
wirklich benĂśtigt. Man kĂśnnte z.B. den Zugriff auf das I2C-Device
jeweils während einer Signalpause des DCF-Signals erledigen.

Gruß

Stefan

 

[MaWin]

"Manuel Reimer" <Manuel.Nulldevice@nurfuerspam.de> schrieb im Newsbeitrag
news:m70ts5$a8c$1@news.albasani.net...

On 12/19/2014 10:51 AM, MaWin wrote:
20cm sind fĂźr I2C kein Thema, das DCF77 Signal wird sogar eine eher
geringe
besondere Flankensteilheit haben. NatĂźrlich sollte es nicht zu hochohmig
angeschlossen sein.

Das DCF? Ist hochohmig angeschlossen. Mit 10k. Warum sollte das ein
Problem sein?

10k ist nicht so besonders hochohmig, 1M wäre es, mache DCF77 Module sind
kaum
belastbar.

--
MaWin, Manfred Winterhoff, mawin at gmx dot net
Homepage http://www.oocities.org/mwinterhoff/
dse-FAQ: http://dse-faq.elektronik-kompendium.de/

 

[Bernd Laengerich]

Am 19.12.2014 um 12:24 schrieb MaWin:

10k ist nicht so besonders hochohmig, 1M wäre es, mache DCF77 Module sind kaum
belastbar.

Ich habe meinem Modul gleich einen BS170 spendiert (open drain), damit es
niederohmiger treiben kann.

Bernd
--
Meine Glaskugel ist mir leider unvorhersehbarerweise vom Balkon gefallen.
P.Liedermann in defa

 

[Manuel Reimer]

On 12/19/2014 11:46 AM, Rafael Deliano wrote:

Die parallel gefßhrten Adern haben Koppelkapazität.
Am schmlimmsten Flachbandkabel.

Ist ein kurzes StĂźck Flachbandkabel.

Andere Frage wäre: ist der DCF77 Empfänger so ein Modul
a la Pollin ?

Ist ein fertiges Modul von Conrad. Wird aber etwas abgesetzt im eigenen
Gehäuse montiert werden.

Wenn hin und wieder ein Datenpaket Schrott ist, dann ist das auch nicht
besonders kritisch. Der Empfänger läuft permanent und jedes valide Paket
wird genutzt um die Systemuhr nachzustellen.

Gruß

Manuel

 

[Manuel Reimer]

On 12/19/2014 11:53 AM, Stefan wrote:

Da kommt es dann drauf an, wie oft bzw. wann man I2C und/oder DCF77
wirklich benĂśtigt. Man kĂśnnte z.B. den Zugriff auf das I2C-Device
jeweils während einer Signalpause des DCF-Signals erledigen.

DCF läuft ständig. Ich lasse den Empfänger durchlaufen und ziehe die
Systemuhr mit jedem validen Paket nach. Um Schrottpakete auszufiltern
darf dabei nur ein gewisses Maximum an Differenz zwischen "DCF" und
"Systemuhr" sein.

Falls das relevant ist: Das ganze hängt an einem Raspberry Pi B+.

Das I2C brauche ich fĂźr eine RTC. Die wird dann sagen wir alle 10
Minuten mit der Systemzeit nachgestellt. Bei Stromausfall habe ich so
direkt eine Referenzzeit.

Traffic auf DCF ist also "permanent" während das I2C nur alle paar
Minuten mal angesteurt wird. Wenn es dann mal ein DCF-Paket verbiegt
wäre das eigentlich weniger tragisch.

Prinzipiell kĂśnnte ich aber eine Massebahn zwischen I2C und DCF legen.
DafĂźr mĂźsste ich das Flachband an einer Seite einmal "verdrehen". Das
dürfte das Übersprechen dann doch reduzieren, oder?

Gruß

Manuel

 

[Rafael Deliano]

Andere Frage wäre: ist der DCF77 Empfänger so ein Modul
a la Pollin ?

http://www.pollin.de/shop/dt/NTQ5OTgxOTk-/Bausaetze_Module/Module/DCF_Empfangsmodul_DCF1.html

Da hat mir zumindest der Preis gefallen,
auch bei ebay nichts billigeres gefunden.

> Ist ein fertiges Modul von Conrad.

http://www.conrad.de/ce/de/product/641138/C-Control-DCF-Empfaengerplatine

Das Ding hat wohl zwei Quarze gegenĂźber ein Quarz bei Pollin.
Bei Conrad haben diverse Anwender ihre Erfahrungen
geschildert, oft ist halt die Erwartungshaltung zu hoch.
Unverrauschtes Signal kommt aber wohl eher nicht, selbst
wenn besser als Pollin.

> Wird aber etwas abgesetzt im eigenen Gehäuse montiert werden.

Auf S. 22 wäre ein Auerswald Oldtimer dargestellt ( ganz ohne
Temic Spezial-IC in CD4000-Logik )
http://www.forth-ev.de/filemgmt_data/files/4d2014-01.pdf
D.h. kann man aussen anbringen, endlos langes Kabel, Ăźppiger
Signalpegel. Das Ding ist recht frustrationsfrei, bei
sinnvoller Ausrichtung ungestĂśrtes Signal. Bei ebay sowas
von unterschiedlichen Herstellern ausgemustert erträglich
teuer, meins war ca. 25 EUR.

MfG JRD

 

[Stefan]

Am 19.12.2014 14:00, schrieb Manuel Reimer:

On 12/19/2014 11:53 AM, Stefan wrote:
Da kommt es dann drauf an, wie oft bzw. wann man I2C und/oder DCF77
wirklich benĂśtigt. Man kĂśnnte z.B. den Zugriff auf das I2C-Device
jeweils während einer Signalpause des DCF-Signals erledigen.

DCF läuft ständig. Ich lasse den Empfänger durchlaufen und ziehe die
Systemuhr mit jedem validen Paket nach. Um Schrottpakete auszufiltern
darf dabei nur ein gewisses Maximum an Differenz zwischen "DCF" und
"Systemuhr" sein.

Du hast bei DCF Signale im Sekundenabstand, also einen Träger der einmal
je Sekunde fĂźr 0,1s oder 0,2 s abgesenkt wird. Du hast also jeweils
mindestens 800ms Zeit in der auf dem DCF-Signal nichts relevantes passiert.

> Falls das relevant ist: Das ganze hängt an einem Raspberry Pi B+.

nicht mein Favorit, aber egal...

Das I2C brauche ich fĂźr eine RTC. Die wird dann sagen wir alle 10
Minuten mit der Systemzeit nachgestellt. Bei Stromausfall habe ich so
direkt eine Referenzzeit.

Da sollte auch 1h ausreichen, aber egal.

Traffic auf DCF ist also "permanent" während das I2C nur alle paar
Minuten mal angesteurt wird. Wenn es dann mal ein DCF-Paket verbiegt
wäre das eigentlich weniger tragisch.

Prinzipiell kĂśnnte ich aber eine Massebahn zwischen I2C und DCF legen.
DafĂźr mĂźsste ich das Flachband an einer Seite einmal "verdrehen". Das
dürfte das Übersprechen dann doch reduzieren, oder?

Erstmal probieren, ob es Ăźberhaupt ein Problem ist. Ich denke eher nicht.

Gruß

Stefan

 

[Rafael Deliano]

Wenn es dann mal ein DCF-Paket verbiegt
wäre das eigentlich weniger tragisch.

Pollin sieht ca. so aus:

http://www.embeddedforth.de/temp/dcf.pdf

Wobei der vĂśllig ungestĂśrte Fall fast nicht vorkommt.
Man kann das Signal kaum auf Interrupt legen,
weil man sonst im stark gestĂśrten Fall ein Problem
mit der Auslastung der CPU hat.
Abtastung mit z.B. 15,6msec wäre mÜglich, aber
dann kann man Aussetzer nicht direkt filtern.
Vermutlich werde ich der Gurke noch etwas Hardware
a la Tiefpaß spendieren müssen.

MfG JRD

 

[Thomas 'Tom' Malkus]

Rafael Deliano (rafael_deliano@arcor.de):

http://www.embeddedforth.de/temp/dcf.pdf

Wobei der vĂśllig ungestĂśrte Fall fast nicht vorkommt.
Man kann das Signal kaum auf Interrupt legen,
weil man sonst im stark gestĂśrten Fall ein Problem
mit der Auslastung der CPU hat.
Abtastung mit z.B. 15,6msec wäre mÜglich, aber
dann kann man Aussetzer nicht direkt filtern.
Vermutlich werde ich der Gurke noch etwas Hardware
a la Tiefpaß spendieren müssen.

Ich bastel auch gerade mit DCF rum, fĂźr eine UTC und
Beacon-Clock. Ich habe das Modul von Reichelt und
solange ich nicht gerade die 128kHz RFID Antenne
daneben lege, ziemlich guten Empfang.

Ein solches StĂśrsignal wie bei Deiner Zeichnung habe
ich noch nicht gesehen. Wenn eine StĂśrung vorliegt,
habe ich nur ein High-Signal. In der Software verwende
ich einen flankengesteuerten Interrupt, jeweils auf
fallende oder steigende Flanke umgeschaltet.

Hast Du das StĂśrsignal selbst produziert? Falls ja wie?
WĂźrde ich dann auch gerne mal testen.

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

 

[Rafael Deliano]

> Modul von Reichelt

Anderes Modul kann sich anders verhalten, aber
etwas Spikes werden alle machen.

> Hast Du das StĂśrsignal selbst produziert?

Ich hab im unteren Fall USB/FTDI-V24 in Verdacht
die Verbindung zum GP32 Controller macht und sich
in etwa 10cm Abstand zu DCF77 befand.
Ich hatte das Pollin-Modul auch schon auf
Breadboard im Doppeleuro-Format in Betrieb. Also
wesentlich weiter von V24 weg, da war es zwar
nicht sauber aber nur erträglich verstÜrt.

MfG JRD

 

[Thomas 'Tom' Malkus]

Rafael Deliano (rafael_deliano@arcor.de):

Modul von Reichelt

Anderes Modul kann sich anders verhalten, aber
etwas Spikes werden alle machen.

Ich hab im unteren Fall USB/FTDI-V24 in Verdacht
die Verbindung zum GP32 Controller macht und sich
in etwa 10cm Abstand zu DCF77 befand.

Wenn ich das USB Kabel vom AVRISPMKII direkt auf das
Modul hänge, kann ich ein paar Spikes erzeugen. Meist
ist aber gar kein Signal mehr da.

Man kann natĂźrlich auch in der Interrupt Routine etwas
Sicherheit einbringen, in dem man den Int einfach ab-
schaltet, wenn die Impulse zu schnell kommen. Nach einer
Zeit wieder einschalten und mal schauen. Ne' StĂśrungsled
ist dann auch noch drin ;-)

Wobei ich ein eDIP240-7 Display verwende, alles nur aus der
Restekiste.

https://twitter.com/DL7BJ/status/542461880443207681/photo/1

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

 

[Manuel Reimer]

On 12/19/2014 02:38 PM, Rafael Deliano wrote:

http://www.pollin.de/shop/dt/NTQ5OTgxOTk-/Bausaetze_Module/Module/DCF_Empfangsmodul_DCF1.html

Da hat mir zumindest der Preis gefallen,
auch bei ebay nichts billigeres gefunden.

Ich habe schon ganz bewusst nicht "billig" genommen. Beim Pollin-Modul
wird empfohlen noch einen Transistor als "Buffer" nachzuschalten. Beim
Conrad-Modul sind derer bereits zwei verbaut. Einmal um ein nicht
invertiertes Signal zu bekommen und ein zweiter um das gebufferte
invertierte Signal wieder zu invertieren.

Das Conrad-Modul kann man in Etwa so direkt an den Raspberry hängen:

_____
DCF77-Modul o------------o---------|_____|-------o GPIO
| 10k
_____ |
+3.3V o-------|_____|----'
10k

Einmal 10k Pullup und einmal 10k Schutz fĂźr den Fall, dass am Raspberry
der Port versehentlich als Ausgang geschaltet und "high" gezogen wird.

http://www.conrad.de/ce/de/product/641138/C-Control-DCF-Empfaengerplatine

Das Ding hat wohl zwei Quarze gegenĂźber ein Quarz bei Pollin.
Bei Conrad haben diverse Anwender ihre Erfahrungen
geschildert, oft ist halt die Erwartungshaltung zu hoch.
Unverrauschtes Signal kommt aber wohl eher nicht, selbst
wenn besser als Pollin.

Ich bekomme die Interrupts sauber getriggert und mehr brauche ich nicht.
DCF-Decodierung mache ich in einem selbstgebauten Perl-Script. Die Zeit
ziehe ich dann mit einem selbstgebauten Perl-Modul via "adjtimex" nach.

Auf S. 22 wäre ein Auerswald Oldtimer dargestellt ( ganz ohne
Temic Spezial-IC in CD4000-Logik )

Ich habe immer mal wieder bei ebay geschaut und die Fertigmodule, die
brauchbar gewesen wären, waren mir alle zu teuer. Beim von dir erwähnten
Auerswald-Modul bräuchte man außerdem 12V. Mein Netzteil liefert aber
nur 5V.

Gruß

Manuel

 

[Gernot Zander]

Hi,

in de.sci.electronics Manuel Reimer <Manuel.Nulldevice@nurfuerspam.de> wrote:

geschildert, oft ist halt die Erwartungshaltung zu hoch.
Unverrauschtes Signal kommt aber wohl eher nicht, selbst
wenn besser als Pollin.

Ich bekomme die Interrupts sauber getriggert und mehr brauche ich nicht.
DCF-Decodierung mache ich in einem selbstgebauten Perl-Script. Die Zeit
ziehe ich dann mit einem selbstgebauten Perl-Modul via "adjtimex" nach.

Ich habe in den letzten Monaten auch nochmal damit rumgespielt, auch
am Pi, auch an anderen Rechnern mit einem alten Modul von HKW und mit
einem neuen von Reichelt. Das HKW decodiert dabei selbst.
Was da an Impulsen am Pi ankommt, ist sicher zu decodieren, kein
Problem. Dto. liefert das HKW-Modul zuverlässig die Zeit.

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. Geht das ohne die zusätzliche
Korrelations-Modulation nicht besser?
Ich bin auf DCF39 gewechselt, das gibt (am USB-Port) ein Jitter von
um die 5 ms, was mich immer noch nicht begeistert, aber fĂźr meine
Zwecke ausreicht.

mfg.
Gernot

--
<hifi@gmx.de> (Gernot Zander) *Keine Mailkopien bitte!*
Bitte beantworten Sie diese E-Mail nicht, da sie elektronisch erstellt
wurde.
(Aus einer Support-Antwort - kann man Mails auch anders erstellen?)

 

[Manuel Reimer]

On 12/22/2014 08:23 PM, Gernot Zander wrote:

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.

Da kann ich dir leider nicht weiterhelfen.

Das Teil wird Bestandteil eines Photovoltaik-Log-Transmitters. Die Logs
liegen fertig im Wechselrichter vor. Nur das der etwa 10 Kilometer von
meinem Wohnort entfernt ist. Der Raspberry hat die Aufgabe einmal am Tag
das Log des Vortags via UMTS an einen Server im Internet zu senden.

Den eher fummelig zu konfigurierenden ntpd habe ich mir da garnicht erst
angetan. Ich komme mit einen einfachen Perl-Script auf eine Genauigkeit
von unter einer Sekunde. Besser brauche ich nicht.

Gruß

Manuel

 

[Marc Santhoff]

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

Marc