Posts by FrankJepsen

    Hallo Martin,


    Das Script programmiert nur das, was vom VDR im ersten Parameter ($1) übergeben wird. Ich glaube der VDR setzt Timer die verpasst werden automatisch in die Zukunft. Ein Timer vom 15.05.2003 wird dann auf den 15.05.2004 gesetzt.


    Tschüß Frank

    Hallo,


    wie wärs mit sowas:

    Etwas entsprechendes werde ich auch mal in das shutdownscript für die c't Distribution einbauen.


    Tschüß Frank

    Hallo,


    bei mir läuft es jetzt eigentlich ohne Probleme. Theoretisch kann es natürlich vorkommen das ein Zeichen auf der Seriellen Schnittstelle verschluckt wird. Das bringt aber die Schaltung nicht zum Absturz, sondern dann wird nur eine Zeit nicht gesetzt.


    Quote

    Nach einer Weile kriege ich die Meldung "interrupt_service_dma2:".

    Das sieht nach einer Meldung des Skystar2 DVB drivers aus. ???


    Tschüß Frank

    Hallo,


    Quote

    Eine erweiterung wird auch sein, daß der Rechner über die Serielle Schnittstelle den Befehl zu runterfahren bekommt. Also ein und ausschalten über den PCWakeup.

    Wofür soll das gut sein? Der PC kann per Fernbedienung oder oder vom PC zeitgesteuert runtergefahren werden.


    Anbei die aktualisierte Version meiner Scripts. Jetzt mit der Möglichkeit einen Daily Timer zu setzen. Folgende Dateien sind enthalten:
    vdr-addon-hw-wakeup.conf -> nach /etc/vdr kopieren
    shutdown90.wakeup-module.sh -> nach /usr/share/shutdown-hooks kopieren
    testwakeup.sh -> nur zum Testen


    starter :
    Die alten Versionen kannst dann ja mal löschen.


    Tschüß Frank

    Files

    • ctvdr.zip

      (2.28 kB, downloaded 135 times, last: )

    Hallo,


    Quote

    Ich würde die Schaltung gern so erweitern, daß sich den Rechner Jeden Tag um die eingestellte Zeit einschaltet.

    Das läßt sich nun wirklich leicht mit einer Anpassung im Shutdown Script erreichen. Schon jetzt ist eine ganz ähnliche Sache in meinem Script enthalten. MAX_POWEROFF_TIME sorgt dafür, dass der PC, egal wie die VDR Timer programmiert sind, nach spätestens dieser Zeit wieder einschaltet. Vielleicht baue ich bei Gelegenheit mal etwas wie DAILY_TIMER der den PC immer um eine bestimmte Uhrzeit einschaltet mit ein.


    Quote

    Leider kann ich mit dem Script nur was bei meinem Linux Recher erreichen, möchte die Schaltung aber auch unter Windows verwenden.

    Die Schaltung läßt sich von Windows ganz genauso ansprechen. Ich habe die Serielle Empfangsroutine mit einem Terminalprogramm unter Windows getestet.


    Quote

    wenn möglich sollte es ein comando zum löschen der angelernten fb-codes geben. z.B. CLR0000000x, wobei x 1 oder 2 sein könnte. Oder generell ein reset-comando das alles löscht (uhrzeit, timer, fb-codes)

    Ist das wirklich nötig? Die Fernbedienungscodes sind im EEPROM gespeichert. Mit PonyProg kann man das Auslesen. Sie stehen dann bei Adresse 0x2000 (PowerOn) und 0x200A (RelaisToggle). Ebenso kann man Sie mit PonyProg löschen.


    Quote

    Leider nur, wenn man die Source hat.

    Ich habe zwar eine Source. Die ist allerdings mit dem IDA-Disassembler aus dem Rasputin Hex-File entstanden, welches wohl mit Basic entwickelt wurde. Inzwischen ist Sie recht ordentlich kommentiert, aber enthält durch den Werdegang recht merkwürdige Konstrukte und wird von mir in Assembler weitergepflegt. Aus gutem Grund habe ich deshalb bisher nur Bugfixes gemacht. Ich hoffe eigentlich auf die Source von Carlo, die wir dann hoffentlich gemeinsam unter seiner Oberhand weiterentwickeln können. Bis dahin werde ich vielleicht noch das eine oder andere in die OriginalSource einpflegen.


    Hier ein bischen was zur Abschreckung:

    Tschüß Frank

    Hallo grobi71,


    ich hatte am Anfang auch mal so ähnliche Probleme. Ich habe noch mal alle Lötstellen nachgeschaut und saubergemacht und die Unterseite isoliert. Jetzt läuft es.
    Die Uhr wird in der Hauptschleife ständig abgefragt. Ich schätzte mal im Abstand von etwas mehr als 100 ms.


    Anbei jetzt ein kleines Testscript. Es stellt die Uhrzeit und einen Timer in zwei Minuten.


    Tschüß Frank

    Und hier noch eine neuer Shutdown Hook mit Testmodus. Einfach ohne Parameter aufrufen. Dann wird die Uhrzeit und ein Timer in 2 Minuten gesetz. Dann VDR mit init 0 runterfahren und abwarten was passiert.


    Linvdr User können das Script mit leichten Anpassungen auch zum Testen verwenden.


    Tschüß Frank

    Donnerstag habe endlich mein neues Grafikdisplay (128x64) zum laufen gebracht. Nein, nicht an der Wakeup-Platine. Da sieht es mangels freier Ports erstmal schlecht aus. Dafür müssten wir warscheinlich auf einen ATMega16 mit mehr Ports umsteigen.


    Nun habe ich mich mal wieder an die Software gemacht. Und hier sind die ersten Früchte der Arbeit:


    Tschüß Frank

    Hallo,


    Quote

    Die Beschaltung der DSUB-F 9polig in der Steckerbelegung.pdf ist falsch.

    Es wurden Platinen mit beiden unterschiedlichen Steckerbelegungen gefertigt. Also einfach aufpassen beim Löten des seriellen Kabels.


    Quote

    eine Frage zu dem shutdown90.wakeup-modul.sh script aus "c’t Shutdown-Hook". Bei timern unter der MIN_PRE_TIMER (hier 5 Minuten) schreibt er ATS01000101 in den chip. So wacht der vdr aber nicht auf wenn noch andere timer gesetzt sind. Gehört das so?

    Wie kann der Timer kleiner 5 Minuten (300) sein? Ein Timer der jetzt startet hat den Wert 1083952223! Vielleicht hilft ein Auszug aus Deiner /var/log/messages weiter.


    Quote

    Ich habe leider noch ein power Problem. Wenn ich die Schaltung mit 5V standby von meinem PC-Netzteil (ATX Pin9) versorge funktioniert weder lirc noch wake_on_ir. Auch ist keine Komunikation mit dem chip möglich. Sobald die 5V (ca 40mA) vom Labornetzteil kommen geht alles. Woher kriege ich genug power? Liefern der PS/2- und WOL-Anschluss genug Strom oder kommt das auch vom 5V standby?

    Die 5V Standby Leitung sollte mehr als genug Strom liefern. Mit Ihr werden ja der WOL, PS/2 usw. versorgt. Ich nutze den WOL Stecker. Habe dazu ein altes CDROM-Audiokabel mit dem Messer ein bischen zurechtgeschnitzt damit es in die Buchse passt. Hast Du denn auch mal nachgemessen?


    Quote

    Jetzt meine Frage: braucht der Atmega noch zusätzlich Spannung oder wird er durch den Com-Port versorgt ?

    Klar braucht der Atmel Power. Lass Ihn doch einfach in der Schaltung. Hat bei mir prima geklappt.


    Tschüß Frank

    Hallo abvdr,


    ich habe zwar eine URC-7562 aber auch mit der URC-7030 sollte es keine Probleme geben. Leider kann ich Dir den Code den ich verwende gerade nicht sagen, aber probier einfach mal einen Philips-Code aus.


    Die URC-7562 kann ich übrigens nur empfehlen, denn man sie ist lernfähig und man kann sie sogar mit einem einfachen Kabel am Parallelport vom PC aus programmieren.


    Tschüß Frank

    Hallo,


    schön, das Nils sich bereitgefunden hat eine Seite für dieses Projekt zu pflegen.:applaus


    Quote

    - wozu wird der Pull-Up Widerstand benötigt, den starter unter die Platine gelötet hat????

    Der interne Pullup wird von der Version 1.3 nicht aktiviert.


    Übrigens in der poweroff.pl für die LinVDR-Nutzer wird noch nicht echo -n verwendet. Das sollte geändert werden.


    Tschüß Frank

    Hallo,


    ich bin auch für einen neuen Thread.
    Man sollte aber dort die wichtigsten Links, Bilder und Infos erst einmal zusammentragen. Oder hat schon jemand Seiten erstellt die aktueller als Rasputins Seiten sind? Dann könnte allgemeine Infos dort zusammengetragen werden und dem Forum bliebe die Diskussion vorbehalten.


    Freiwillige vor! :versteck



    Tournevis :
    Die Lösung mit dem Powerschalter finde ich auch universeller zumindestens, wenn man die Platine sowieso in das Gehäuse baut. Kannst Du Deine Beschaltung damit es ganz eindeutig wird auch mal als Schaltbild kundtun?


    Tschüß Frank

    Quote

    1.Es war nie vorgesehen etwas anderes als definierte Kommandos in einer definierten Zeit an das Modul zu senden.

    Ist vorerst auch nichts gegen zu sagen. Leider haben viele (auch ich) übersehen, das echo ein \n hinten dran hängt. Es ist also wichtig echo -n zu verwenden. Zur definierten Zeit läßt nur sagen, dass Interupts nun mal die unangenehme Eigenschaft haben zu jeder Zeit auftreten zu können. Also vor, während und nach der Verarbeitung.


    Quote

    2. Es findet nie ein Pufferüberlauf statt, egal was an das Modul gesendet wird.

    Ohne diesen Pufferüberlauf würde die Software, so wie sie ist, garnicht funktionieren. Denn dann würde ein zuviel gesendetes \n am Anfang des Puffers landen und alle nachfolgenden Befehle würden nicht mehr erkannt.
    Das Ganze läßt sich mit einem Terminalprogramm leicht reproduzieren. Wenn man die Befehle hier langsam tippt startet die Verarbeitung des Befehls nach dem 11. Zeichen und das Return(\n) landet am Anfang des Puffers. Dann geht erstmal nichts mehr.
    Da die Überprüfung des Pufferinhalts nur höchstens alle 100ms statt findet, kann man theoretisch 100 Bytes in den Puffer schreiben bevor das Programm was mitbekommt. Da mit echo alle Bytes hintereinanderweg in ca 10ms geschickt ist nur die Warscheinlichkeit relativ hoch das alle 12 Bytes komplett im Puffer landen bevor die Verarbeitung stattfindet. Trotzdem werden Fälle auftreten, wo das \n nach dem Verarbeiten der ersten 11 Bytes eintrifft, an den Anfang des Puffers geschrieben wird und den nachfolgenden Befehl verstümmelt. Oder das \n trifft während der Verarbeitung ein und stört sie, weil eine hinter dem Puffer liegende Variable überschrieben wird.


    Deshalb für Alle ganz wichtig immer genau als 11 Byte pro Befehl senden und zwischen den Befehlen mehr als 100ms warten. Dann gibt es nur noch bei echten Übertragungsstörungen (nicht übertragene Bytes) Probleme.


    Tschüß Frank

    steini  
    Es ist genauso wie beschrieben. Nach dem 11.Zeichen wird der Befehl ausgeführt und keine Überlaufprüfung.


    starter
    Für das Anlernen brauchst Du nur die Spannung anzulegen. Ich denke Du hast nur immer noch keinen RC5 Code gefunden. Ich habe einen Philips TV Code genommen.
    Man kann auch von Windows aus testen. Habe gerade mal Hyperterminal gestartet und ATS01020304 eingetippt. Sobald ich die vier getippt hatte sprang das Display um.


    Hier noch die geänderten Scripte für die c't Distribution:

    Tschüß Frank

    Files

    • ctvdr.zip

      (1.46 kB, downloaded 67 times, last: )

    Hallo,


    ich habe mir die Source noch mal angeschaut und hier C-ähnlich dargestellt, um die problematischen Stellen deutlich zu machen:

    Code
    1. void RXCompleteIntFunc()
    2. {
    3. int c=RXin;
    4. int pos=strlen(ReceiveBuf);
    5. ReceiveBuf[pos++]=c; // Keine Überlaufprüfung!!
    6. ReceiveBuf[pos]=0;
    7. }

    Wie gesagt, es findet leider keine Überlaufprüfung statt. Man kann sich also leicht andere Variablen, die hinter dem Puffer liegen überschreiben, während sie in der Hauptschleife verwendet werden, wenn man zu schnell oder zu viele Daten über den Comport schickt. Für die Verarbeitung wird weder ein Start- noch ein Stoppzeichen verwendet. Erst wenn mehr als 10 Zeichen empfangen wurden fängt sich das ganze wieder, weil dann der Puffer verarbeitet oder gelöscht wird. Im Augenblick ist die Software so geschrieben, dass jeder Befehl genau 11 Bytes umfassen muss. Deshalb sollte man echo -n beim Senden verwenden. Weil der Puffer nur 12 Zeichen groß ist kann es sonst entweder durch den Pufferüberlauf oder weil das überflüssige \n dem nächsten Befehl vorangestellt wird (die Verarbeitung kann ja schon nach dem 11. Byte starten) zu Problemen kommen. Auch wenn sich diese Überläufe nur selten auswirken, wäre es doch ärgerlich dadurch eine Aufnahme zu verpassen.


    rasputin Lösungsvorschlag:
    In der Interruptroutine bei Pufferüberlauf den Puffer löschen und bei Empfang von \n ein zusätzlich einzurichtendes Flag zu setzen. In der Hauptschleife dann nicht auf die Länge sondern diese Flag testen.


    Tschüß Frank

    Hallo,


    rasputin
    Schön, dass Du weiter mitmachst. Ich habe auch nichts dagegen, dass Du bei Deiner Software die Oberhand behälst und der Herausgeber der aktuellen Version bleibst. Ich werde mich bei Dir wegen meiner Änderungsvorschläge melden.


    Hier mal eine kleine Dokumentation der LEDs:
    [IMG:http://www.jepsennet.de/wakeup_board.jpg]


    LED1: (bei mir grün)

    • blinkt beim Start zweimal
    • ist im Betrieb aus, wenn kein Timer gesetzt ist
    • leuchtet im Betrieb, wenn Timer gesetzt ist
    • blinkt als Bestätigung nach dem Programmieren der RC5-Codes
    • beim Einschalten mit der Fernbedienung blinkt Sie zusammen mit dem RING-Signal.


    LED2:

    • leuchtet nur während Jumper auf Programmierung des RC5-Codes zum Einschalten gesetzt ist.


    LED3:

    • leuchtet nur während Jumper auf Programmierung des RC5-Codes zum Schalten des Relais gesetzt ist.


    LED4:

    • leuchtet nur während das Relais eingeschaltet ist.


    Mit dieser Info sollte es eigentlich möglich sein einen groben Funktionstest der Schaltung nur mit Hilfe der LEDs durchzuführen.
    Einschalten -> LED1 blinkt
    /etc/init.d/lirc stop
    setserial $WAKEUP_PORT uart 16550A
    echo ATS00000000 > /dev/ttyS0 -> Init
    echo ATS01020304 > /dev/ttyS0 -> LED1 geht an
    echo ATS00000000 > /dev/ttyS0 -> LED1 geht aus
    usw.
    Ich bin übrigens ganz systematisch vorgegangen und habe erst mal den Comport mit einem gekreuzten Kabel an einem anderen PC und Terminalprogramm getestet.


    Tschüß Frank

    Wenn ich die Source nicht ganz nicht ganz falsch interpretiere, wird bei jedem empfangenen Zeichen ein Interrupt ausgelöst. In der Interruptroutine wird das empfangene Zeichen ohne Rücksicht auf Verluste hinten an Empfangspuffer drangehängt. Erst in der Hauptschleife des Programms wird dann irgendwann geschaut, ob mehr als 10 Zeichen im Puffer stehen und ein eventuell drinstehendes Kommando ausgewertet. In der Hauptschleife war außerdem glaube ich eine Verzögerung von 100ms. Deshalb muß nach jedem Kommando immer erst gewartet werden, um Pufferüberläufe zu vermeiden. Leider habe ich die Source jetzt nicht hier. Aber gestern hatte ich auf die schnelle nichts gesehen was den Empfangspuffer wieder synchronisiert. Das würde ja bedeuten, dass die Schaltung bei jedem falsch übertragenen Zeichen resettet werden müsste. Wenn ich wieder zu Hause bin schaue ich noch mal rein, denn das wäre ja denn doch zu übel.


    rasputin :
    Ich möchte Dir auch nochmal meinen Dank aussprechen. Ohne Dein Bemühen und Deine Arbeit müsste ich meinen VDR-Rechner heute wohl immer noch von Hand einschalten. Schade, dass bei Dir der Eindruck entstanden ist, alle würden nur an Dir herum meckern.
    Der Sinn von Open Source ist ja nicht an der Arbeit anderer rumzumäkeln sondern gemeinsam daran zu arbeiten Software und Hardware zu verbessern, Fehler auszumerzen und neue Features hinzuzufügen.


    Tschüß Frank