Seite 1 von 4 123 ... LetzteLetzte
Ergebnis 1 bis 10 von 39

Thema: DCF77 mit Pollin DCF1 Modul

  1. #1
    Kabelträger
    Registriert seit
    08.12.2016
    Beiträge
    26

    DCF77 mit Pollin DCF1 Modul

    Hallo!

    Vor vielen Jahren waren einige DCF77-Projekte mit der originalen dcf77.lib bei mir erfolgreich.
    Dummer weise weis ich aber nicht mehr genau unter welchen Basteleien ich das hinbekommen habe.

    Tatsache ist das mir das Testprogramm aus dem Bascom Handbuch folgende Ausgaben rauswirft:

    Code:
    00:21:32 00.00.00 45:85:00 45.25.@5 01000001 11000000 11010010 Timezone : 3 13 111
    00:21:33 00.00.00 45:85:01 45.25.@5 01000001 11000001 11101001 Timezone : 3 13 48
    00:21:34 00.00.00 45:85:02 45.25.@5 01000001 11000000 11110100 Timezone : 3 21 42
    00:21:35 00.00.00 45:85:03 45.25.@5 01000001 11000001 11111010 Timezone : 3 13 49
    00:21:36 00.00.00 45:85:04 45.25.@5 01000001 11000000 11111101 Timezone : 3 19 43
    00:21:37 00.00.00 45:85:05 45.25.@5 01000001 11000001 11111110 Timezone : 3 13 49
    00:21:38 00.00.00 45:85:06 45.25.@5 01000001 11000000 11111111 Timezone : 3 13 49
    00:21:39 00.00.00 45:85:07 45.25.@5 01000001 11000001 11111111 Timezone : 3 13 49
    00:21:40 00.00.00 45:85:08 45.25.@5 01000001 11000000 11111111 Timezone : 3 20 42
    00:21:41 00.00.00 45:85:09 45.25.@5 01000001 11000001 11111111 Timezone : 3 13 49
    00:21:42 00.00.00 45:85:10 45.25.@5 01000001 11000000 11111111 Timezone : 3 19 43
    00:21:43 00.00.00 45:85:11 45.25.@5 01000001 11000001 11111111 Timezone : 3 20 42
    00:21:44 00.00.00 45:85:12 45.25.@5 01000001 11000000 11111111 Timezone : 3 19 43
    00:21:45 00.00.00 45:85:13 45.25.@5 01000001 11000001 11111111 Timezone : 3 13 49
    00:21:46 00.00.00 45:85:14 45.25.@5 01000001 11000000 11111111 Timezone : 3 13 49
    00:21:47 00.00.00 45:85:15 45.25.@5 01000001 11000001 11111111 Timezone : 3 13 49
    00:21:48 00.00.00 45:85:16 45.25.@5 01000001 11000000 11111111 Timezone : 3 13 49
    00:21:49 00.00.00 45:85:17 45.25.@5 01000001 11000001 11111111 Timezone : 3 13 49
    00:21:50 00.00.00 45:85:18 45.25.@5 01000001 11000000 11111111 Timezone : 3 13 49
    00:21:51 00.00.00 45:85:19 45.25.@5 01000001 11000001 11111111 Timezone : 3 20 42
    00:21:52 00.00.00 45:85:20 45.25.@5 01000001 11000000 11111111 Timezone : 3 13 49
    00:21:53 00.00.00 45:85:21 45.25.@5 01000001 00000000 11111111 Timezone : 3 19 43
    00:21:54 00.00.00 45:85:22 45.25.@5 01000001 00000001 11111111 Timezone : 3 19 43
    00:21:55 00.00.00 45:85:23 45.25.@5 01000001 00000000 11111111 Timezone : 3 13 49
    00:21:56 00.00.00 45:85:24 45.25.@5 01000001 00000001 11111111 Timezone : 3 20 42
    00:21:57 00.00.00 45:85:25 45.25.@5 01000001 00000000 11111111 Timezone : 3 13 49
    00:21:58 00.00.00 45:85:26 45.25.@5 01000001 00000001 11111111 Timezone : 3 20 42
    00:21:59 00.00.00 45:85:27 45.25.@5 01000001 00000000 11111111 Timezone : 3 13 49
    00:22:00 00.00.00 45:85:28 45.25.@5 01000001 00000001 11111111 Timezone : 3 13 49
    00:22:01 00.00.00 45:85:29 45.25.@5 01000001 00000000 01010101 Timezone : 3 19 43
    00:22:02 00.00.00 45:85:30 45.25.@5 01000001 00000001 10101010 Timezone : 3 20 42
    00:22:03 00.00.00 45:85:31 45.25.@5 01000001 00000000 11010101 Timezone : 3 13 49
    00:22:04 00.00.00 45:85:32 45.25.@5 01000001 00000001 11101010 Timezone : 3 13 49
    00:22:05 00.00.00 45:85:33 45.25.@5 01000001 00000000 11110101 Timezone : 3 19 43
    00:22:06 00.00.00 45:85:34 45.25.@5 01000001 00000001 11111010 Timezone : 3 19 43
    00:22:07 00.00.00 45:85:35 45.25.@5 01000001 00000000 11111101 Timezone : 3 13 49
    00:22:08 00.00.00 45:85:36 45.25.@5 01000001 10000000 00101101 Timezone : 3 20 42
    00:22:09 00.00.00 45:85:37 45.25.@5 01000001 10000001 10010110 Timezone : 3 20 42
    00:22:10 00.00.00 45:85:38 45.25.@5 01000001 10000000 11001011 Timezone : 3 13 49
    00:22:11 00.00.00 45:85:39 45.25.@5 01000001 10000001 11100101 Timezone : 3 20 42
    00:22:12 00.00.00 45:85:40 45.25.@5 01000001 10000000 11110010 Timezone : 3 13 49
    00:22:13 00.00.00 45:85:41 45.25.@5 01000001 10000001 11111001 Timezone : 3 13 49
    00:22:14 00.00.00 45:85:42 45.25.@5 01000001 10000000 00101101 Timezone : 3 13 49
    00:22:15 00.00.00 45:85:43 45.25.@5 01000001 10000001 10010110 Timezone : 3 13 49
    00:22:16 00.00.00 45:85:44 45.25.@5 01000001 10000000 11001011 Timezone : 3 13 49
    00:22:17 00.00.00 45:85:45 45.25.@5 01000001 10000001 00000111 Timezone : 3 19 43
    00:22:18 00.00.00 45:85:46 45.25.@5 01000001 10000000 10000011 Timezone : 3 19 43
    00:22:19 00.00.00 45:85:47 45.25.@5 01000001 10000001 11000001 Timezone : 3 13 49
    00:22:20 00.00.00 45:85:48 45.25.@5 01000001 10000000 11100000 Timezone : 3 13 49
    00:22:21 00.00.00 45:85:49 45.25.@5 01000001 10000001 11110000 Timezone : 3 13 49
    00:22:22 00.00.00 45:85:50 45.25.@5 01000001 10000000 00011001 Timezone : 3 13 49
    00:22:23 00.00.00 45:85:51 45.25.@5 01000001 10000001 10001100 Timezone : 3 20 42
    00:22:24 00.00.00 45:85:52 45.25.@5 01000001 10000000 11000110 Timezone : 3 20 42
    00:22:25 00.00.00 45:85:53 45.25.@5 01000001 10000001 11100011 Timezone : 3 20 42
    00:22:26 00.00.00 45:85:54 45.25.@5 01000001 10000000 11110001 Timezone : 3 13 49
    00:22:27 00.00.00 45:85:55 45.25.@5 01000001 10000001 11111000 Timezone : 3 20 42
    00:22:28 00.00.00 45:85:56 45.25.@5 01000001 10000000 11111100 Timezone : 3 13 49
    00:22:29 00.00.00 45:85:57 45.25.@5 01000001 10000001 11111110 Timezone : 3 13 49
    00:22:30 00.00.00 45:85:58 45.25.@5 01000001 10000000 10100101 Timezone : 3 13 49
    00:22:31 00.00.00 45:85:58 45.25.@5 01000000 11000000 11010010 Timezone : 3 13 49
    00:22:32 00.00.00 45:85:00 45.25.@5 01000001 11000000 11010010 Timezone : 3 13 111
    Wie man sieht rödelt das Programm schon seit 22Minuten.
    Bereits nach der ersten Minute erkennt er mit dem Pausen-Wert "111" den Minutenanfang und synchronisiert die Sekunden in der DCF-Zeit (3. Spalte) korrekt.
    Danach rödelt er sich tot...auch nach Stunden geschieht nicht mehr.

    Interessant finde ich das die 100ms Impulse mit Impulswert 13 und die 200ms Impulse mit Werten zwischen 19 und 21 gemessen werden.
    OK, das ist "Pi mal Daumen" schon die richtige Dimension, aber eben nicht exakt.
    Wenn 100ms Impulse mit Zählerstand 13 gemessen werden, müssten 200ms Impulse streng genommen auf Zählerwert 26 kommen.

    Den selben Versatz sieht man auch bei den Pausen:
    Standardpause 42 (nach 200ms-Impuls) bis 49 (nach 100ms-Impuls).
    Die zwei sekunden lange Pause von Sekunde 58-00 wird allerdings mit Zählerstand 111 gemessen.

    Ich habe also irgendwo eine Taktabweichung drin die mir die Zählerwerte verfälscht.
    Daher frage ich mich ob die dcf77.lib da eine bestimmte Quarzfrequenz verlangt, oder ob diese die Variable "$crystal" anständig verrechnet.
    In der Lib selber habe ich so nix gefunden über eine Berücksichtigung der realen Taktfrequenz.

    Was aber auch sein könnte:
    Die paar DCF-Projekte von mir waren irgendwann 2008~2009 rum.
    Nun ist aber das DCF-Protokoll abgeändert da seit einigen Jahren diese codierten Wetterdaten mitgesendet werden.
    Die originale dcf77.lib von Bascom ist datiert auf den 27 April 2007.

    Kann es sein das die durch die Wetterdaten irritiert wird?
    Gibt es eine aktuellere dcf77.lib?
    Trotz einiger Updates von Bascom, das letzte erst von einigen Tagen, scheint diese dcf77.lib noch von der Erstinstallation zu meinem Bascom-Einstieg zu stammen.

  2. #2
    Spaghetti-Coder Avatar von Basti
    Registriert seit
    10.11.2016
    Beiträge
    106
    Hallo dg7gj,
    in Bascom gibt es schon seit längerer Zeit eine eingebaute Routine.
    Schau mal unter Config Dcf77 in der Hilfe.

  3. #3
    Neuer Benutzer
    Registriert seit
    02.11.2016
    Beiträge
    54
    Hallo,

    dieser Code funktioniert schon seit Jahren (Bascom- Demo bis Bascom 2.0.7.9. Auch mit m8 und 1MHz Takt.
    Code:
    ' **** Initialisierung
       $baud = 19200
       $regfile = "m1284pdef.dat"
       $crystal = 16000000
       $swstack = 512
       $hwstack = 512
       $framesize = 512
    
    ' DCF77 auf PinB.0 einstellen
    
    Config Dcf77 = Pinb.0 , Timer = 1 , Debug = 1 , Check = 1 , Inverted = 1 ,       'Gosub = Sectic
    
    ' Interrupts müssen aktiviert werden
    Enable Interrupts
    
    ' Datumsformat festlegen
    Config Date = Dmy , Separator = .
    
    Print "Synchronisiere die Uhrzeit mit dem DCF77 Zeitsignal..."
    
    ' Auf die Synchronisierung der Uhrzeit mit dem DCF77 Zeitsignal warten
    While Dcf_status.7 = 0
       ' Dcf_status.7 wird auf 1 gesetzt sobald die Zeit erfolgreich synchronisiert wurde
       ' aktuelle Zeiten (intern und DCF) sowie den Status zum Terminal ausgeben
       Print "Uhr: " ; Time$ ; "    " ; Date$ ; "       " ; "DCF: " ; Time(dcf_sec) ; "    " ; Date(dcf_day) ; "     " ; Dcf_status.7
       Wait 1
    Wend
    
    Print "Uhrzeit erfolgreich synchronisiert! " ; Time$ ; " " ; Date$
    
    ' Hauptschleife des Programms
    ' (kann weitere Anweisungen enthalten)
    Do
      Print Time$ ; "    " ; Date$
    Loop
    
    ' Programmende
    End
    Verwende aber Industrie DCF77- Aktivantennen auch für Außenbereich gut geeignet(IP54 Gehäuse)
    Habe noch ein paar übrig. Wer Interesse bitte melden.

    Gruß

  4. #4
    Spaghetti-Coder Avatar von Basti
    Registriert seit
    10.11.2016
    Beiträge
    106
    Hallo Fredred,
    ist dir Check=1 (nur Parity und die Minute wird gecheckt) nicht zu wenig Überprüfung der eingehenden Werte oder hast du so einen sauberen Empfang?
    Nachdem ich ihm das eingebaute DCF empfohlen hatte, habe ich gestern Abend dann mal einige Tests gemacht, weil ich DCF auch in meinem Heizungs-Projekt verwenden will.
    Dabei ist mir aufgefallen, dass die Parity über die Tage, Wochentage, Monate und Jahre (insgesamt 22 Bits) doch recht wenig Sicherheit ist.
    Denn ich hatte ein paar Fälle, wo Parity stimmte, aber eine gerade Anzahl an Bits gekippt war. Dabei kommt dann ein recht seltsames Datum heraus.
    Zugegebenermaßen war die Umgebung mit PWMs, Schaltnetzteilen und Funk recht verseucht.
    Daher will ich mindestens Check=2 nehmen, evtl. sogar eine eigene Routine schreiben.
    Anspruch ist schon, dass nie ein falscher Wert durchkommt.

  5. #5
    Neuer Benutzer
    Registriert seit
    02.11.2016
    Beiträge
    54
    Zitat Zitat von Basti Beitrag anzeigen
    Anspruch ist schon, dass nie ein falscher Wert durchkommt.
    Hallo Basti,

    kann nur bestätigen das dies Zeitbasis mit DCF77 (wenn Empfangs LED stabil blinkt) Langzeit störungsfrei sein Ding tut.
    Muss aber sagen lag vielleicht ans Händeln in der Testphase. Die DCF- Zeit synchronisiert nur die Interne- Zeit bei Abweichung, so fragte ich diese nicht ständig ab, warum auch wenn die Interne sehr stabil ist.


    Ist zwar schon lange her und habe die Testprotokolle nicht mehr. Also Dcf_status.7 auf 1 gesetzt nun beide Zeiten auf SD-Karte gespeichert
    und nur vor Zeitumstellung die Synchronisierung aktiviert.
    Ergebnis war. Die 2 mal Syn. reichten pro Jahr aus war nicht immer auf 1 Sekunde genau aber eine Abweichung > 4 Sekunden/a kam nicht vor.
    Aktuell lass ich die Synchronisierung immer aktiv, da die erwähnten Antennen auch unter übelsten Bedingungen saubere Zeitflanken liefern.
    Schlusswort:

    Die Empfangsqualität ist das A&O. Jeder nicht erkannter „Flicker“ im Protokoll kann alles aus dem Tritt bringen.
    Ja wenn dieser mal da oder dort und dann auch nur Übermorgen in drei Tagen auftritt „ist guter Rat teuer“

    Gruß
    Geändert von fredred (06.01.2017 um 13:48 Uhr)

  6. #6
    Kabelträger
    Registriert seit
    08.12.2016
    Beiträge
    26
    Hallo!

    Hmm, für mich ist es eigentlich normal das ich erst in einem Fachforum um Tips bitte, wenn ich zuvor schon alle selbstverständlichen und möglichen Versuche unternommen habe um meine Probleme erstmal selbstständig zu klären.
    Ein Hinweis auf die Erklärungen zu Config Dcf77 im Manual ist an meiner Adresse daher eher falsch.
    Zumal das Log welches ich ausschnitsweise postete exakt das Log ist, welches mir das Beispielprogramm zu Config Dcf77 in allen Bascom-Manuals enthalten, ausspuckte.

    Daher hielt ich es für überflüssig dazu den Quelltext nochmal zu posten.

    Vielmehr ist es so das nach gefühlten 40 mal durchlesen verschiedener PDF's und der mcshelp-Seite zum Thema Config Dcf77 empfindliche Umklarheiten bestehen bleiben. So wird über etliche Absätze erkläert was DCF77 ist, wozu auch ein simpler Querverweis nach Wikipedia oder zur Seite des PTB gereicht hätte.
    Dafür kommen viel wichtigere Punkte zur dcf77.lib schlichtweg zu kurz:

    Erster Punkt die Frage "invertiert oder nicht invertiertes Signal":
    DCF77 sendet einen Dauerträger mit voller Amplitude.
    Moduliert wird dieser Träger durch Absenkung der Amplitude in 58 Sekunden für wahlweise 100ms oder 200ms.

    Aus dem Betrachtungswinkel der Modulation wäre also "nicht invertiert" gleichbeteutend mit "High" für die Pausen (Volle Amplitude) und Low-Impuse für wahlweise 100 oder 200ms. Invertiert wäre es dann anders herrum: In den Pausen "Low" und jede Sekunde ein "High" für entweder 100 oder 200ms.

    Aus welcher Sicht Bascom das sieht, wird in keinem Manual von MSC exakt definiert, so das ein User bei jedem Modul erst mal experimentieren muss.

    Dann wäre die optionale Variable "PULSE"

    "This is an optional parameter that sets the pulse time in mS. The
    default is 150. When you have hardware that requires a shorter or
    longer pulse you can try a slightly higher or lower value. At all
    times you should use a value between 100 and 200 where 150
    would be the optimum value."

    Tja...einen Impuls mit 150ms gibt es bei DCF77 nicht, daher wäre eine genauere Umschreibung was dieser Wert darstellen soll wichtig.

    Achtung...mutmaßung...was anderes bleibt einem ja nicht übrig:
    Es könnte einen Schwellwert darstellen der bestimmt: Timer < Pulse = 100ms Puls, und wenn Timer > Pulse = 200ms Puls.
    Aber wenn dem so wäre, müsste es erklärt werden, damit der User was damit an zu fangen weis.
    Der Inhalt der dcf77.lib selber hilft mir auch nicht wirklich zu durchschauen.
    Timer 1 (16Bit) wird wohl einen Vorteiler haben. Denn er kann nur bis 65.535 zählen.
    Bei 8MHz würde das knapp werden, bei 16MHz erst recht. In der Lib kann ich aber nicht mal erkennen das überhaupt ein Teiler für den Timer gesetzt wird.
    *Grübel*...

    Da mir die 100ms Impulse sehr stabil als Timerwert 13 angezeigt werden, müsste der Timer rechnerisch mit 7,69ms laufen (verwendetes Quarz: 16MHz).
    Warum mir aber 200ms Impulse dann den Timerwert 19~21 entsprechend dann 146,11-161,49ms liefert ist mir schleierhaft.
    Auf dem Oszilloskop sehe ich deutlich das dass DCF77-Modul die 100ms und 200ms ziemlich exakt einhält.

    Gut, ein Problem habe ich mittels oszilloskop erkannt:
    Das Datensignal ist nicht wirklich sauber. Wenn man die Zeitachse aufzieht sieht man deutlich das die Impulse aus einem Paket von einzelnen Nadeln besteht.
    Man könnte fast meinen das wäre ein Rauschen dessen Signalspitzen von Low bis High reichen.
    Mag sein das es da noch eine Tiefpassfilterung braucht.
    Aber prizipiell sehen die Impulslängen und Pausenlängen schon relativ richtig aus - zumindest so weit ich es interpretiere:
    Timerwert 13 zeigt mir sehr zuverlässig die 100ms-Impulse an, die 200ms Impulse sind da schon etwas ungenauer, aber die Pausenzeiten sind auch weitestgehend in der richtigen Dimension.
    Und eine LED nie mit dran hängt zeigt ebenso ein sauberes Signal ohne Flackern.

    Jürgen Hüser

  7. #7
    Spaghetti-Coder Avatar von Basti
    Registriert seit
    10.11.2016
    Beiträge
    106
    Hallo Jürgen,
    Zitat Zitat von DG7GJ Beitrag anzeigen
    Hmm, für mich ist es eigentlich normal das ich erst in einem Fachforum um Tips bitte, wenn ich zuvor schon alle selbstverständlichen und möglichen Versuche unternommen habe um meine Probleme erstmal selbstständig zu klären.
    Ein Hinweis auf die Erklärungen zu Config Dcf77 im Manual ist an meiner Adresse daher eher falsch.
    Zumal das Log welches ich ausschnitsweise postete exakt das Log ist, welches mir das Beispielprogramm zu Config Dcf77 in allen Bascom-Manuals enthalten, ausspuckte.
    Daher hielt ich es für überflüssig dazu den Quelltext nochmal zu posten.
    Tut mir leid, wenn ich dir hier zu nahe getreten bin.
    Du sprichst von der DCF77.lib, die es früher einmal gegeben hat und da nahm ich an, dass es sich um ein nicht-MCS Produkt handelt.
    Die sind früher gerne verwendet worden, aber seit es die MCS Funktion gibt, eigentlich eher weniger.
    Daher habe ich gar nicht erst versucht, zu verstehen, was die Ausgabe eigentlich darstellt, da ich dachte, sie wäre von dir zur Fehleranalyse generiert.
    Also bitte nicht gleich böse werden.

    Zitat Zitat von DG7GJ Beitrag anzeigen
    Vielmehr ist es so das nach gefühlten 40 mal durchlesen verschiedener PDF's und der mcshelp-Seite zum Thema Config Dcf77 empfindliche Umklarheiten bestehen bleiben. So wird über etliche Absätze erkläert was DCF77 ist, wozu auch ein simpler Querverweis nach Wikipedia oder zur Seite des PTB gereicht hätte.
    Habe ich auch nicht verstanden, dass dies in der Hilfe so breitgetreten wird.

    Zitat Zitat von DG7GJ Beitrag anzeigen
    Dafür kommen viel wichtigere Punkte zur dcf77.lib schlichtweg zu kurz:

    Erster Punkt die Frage "invertiert oder nicht invertiertes Signal": ...
    Dann wäre die optionale Variable "PULSE" ...
    Timer 1 (16Bit) wird wohl einen Vorteiler haben. ...
    Kann ich dir nur recht geben.
    Der Vorteiler ist wahrscheinlich nicht explizit angegeben, weil er je nach $crystal geändert wird.

    Ich bin halt gerne in der Lage, bestimmte Dinge auf meine Verhältnisse anzupassen.
    Daher habe ich geschrieben, dass ich mir evtl selber eine reine Bascom Routine mache, weil das bei mir eh nicht zeitkritisch ist.
    Und ich nutze besonders den 16-bit Timer1 lieber für andere Dinge als so ein ewig langsames Signal abzutasten.
    Und eine erweiterte Überprüfung des Telegramms nachträglich zu machen, ist mir dann doch zu kompliziert.

    Allerdings hilft dir all dies nicht bei deinem Problem. Offensichtlich werden keine Zeiten richtig erkannt und übernommen.
    Daher bleibt die Date$ Ausgabe immer auf 0 und die Time$ zählt einfach seit Programmstart.
    Kannst du mal den Print Befehl für die Ausgabe zeigen. Mir ist nicht klar, was die binären Ausgaben bedeuten.
    In der Hilfe sind es nur 2 Byte (dcf_status und dcf_bits), bei dir 3.

    Viele Grüße Basti

  8. #8
    Kabelträger
    Registriert seit
    02.11.2016
    Beiträge
    21
    Hallo Jürgen

    Mit dem Pollin Modul gibt es wohl öfter Schwierigkeiten Beschaltung ok
    http://www.dl3ukh.de/18.htm

    Fredfred wie kann man dich erreichen ?

    Gruß Bernd

  9. #9
    Kabelträger
    Registriert seit
    03.11.2016
    Beiträge
    7
    Hallo Zusammen,
    erstmal wünsche ich Euch ein gutes Jahr 2017 !

    Mich interessiert dieses Thema DCF 77 auch.
    Frage: bekommt man heute noch irgendwo her die dcf77.lib ? Wenn ja wo ? + Doku wenn möglich
    Ich war auf der Seite von MCselec.com, da hab ich nichts gefunden. Kann mir da mal jemand bitte einen Tipp geben, bitte.
    Die normale Config Dcf77 kenn ich auch, und funktioniert hier auch problemlos, wobei ich sagen muss, der Empf. (Conrad) hängt an ca 12m Telefonkabel abgesetzt am Fenster, da innerhalb des Raumes nichts mehr zu empfangen ist. Ich wollte auch mal die Bits untersuchen, und feststellen wie die Qualität des Signales denn insgesamt ist.
    Vielen Dank für Die Mühe vorab !
    Gruss
    Theo

  10. #10
    Spaghetti-Coder Avatar von Basti
    Registriert seit
    10.11.2016
    Beiträge
    106
    Hallo Theo,
    die DCF77.lib die ich meine ist vom roboternetz.de.
    Suche dort mal nach ihr, dann findest du jede Menge Links.
    Da ist natürlich auch vieles in C.

Lesezeichen

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •