Hardware-Wakeup nachrüsten

Hi,

@ Carlo

Zitat

Die CV350 liefert RC5 Code, wenn auf Taste VCR der Code 235 eingestellt wird,

o.k ich werde das noch mal probieren, ich habe vielleicht doch zu früh aufgegeben

@ all
ich habe ja immer noch das "Nach-5h-kein Aufwachen" - Problem.

Ich habe dazu mal ein paar Spannungen gemessen:
- Versorgungsspannung (5VSB) ist immer zwischen 4,97 und 4,9 V
- Pin9/X1 normal: zwischen -6,78 und -6,94V
- Pin9/X1 aktiv: zwischen +7,09 und +7,25V

ist das o.k. ??

Ich will jetzt mal probieren, dass ich direkt mit den 5VSB an Pin9 (WOR) oder an WOL gehe (über 100 Ohm??). Dann sollte doch der PC auch aufwachen - oder?

Gruß
Cervicor

Hallo steini,

Ich habe zuerst ./runvdr stop
dann killall lircd
dann modprobe 8250
und dann stty < /dev/ttyS1
eingegeben:
speed 9600 baud;
-brkint -imaxbel

Das scheint gut auszusehen. (Finde ich)
Die COMs habe ich im Setup fest auf 0x3f8 und 0x2f8 gelegt.
LIRC lief (wie weiter oben beschrieben) auch fest auf 0x2f8.

Wenn ich jetzt "ATS..." oder "RTS..." abschicke, sollte doch irgendetwas blinken. Tut aber nicht. Oder passiert das, wenn der Timer abgelaufen ist?

Tournevis

Hi Tournevis,
jawoll, jetzt hast du die Com-Schnittstelle "reanimiert". Die Ausgabe ist absolut ok.
Nochmal die Frage: Hat der Hermes eine oder zwei COM-Ports? Sieht ja so aus als ob der zwei hat.
Dann: Hast du das Modul an COM 1 oder COM2 angeschlossen, falls du zwei hast. Normalerweise ist dev/ttyS1 COM2. Also das muß schon stimmen!!
So, wenn du das überprüft hast und alles stimmt (v.a. die "Verdrahtung") müsste mit:

echo "RTSHHMMddmm" > dev/ttyS1

die Uhr einzustellen sein. Sicherheitshalber kannst du aber auch

echo -e "\nRTSHHMMddmm\n" > dev/ttyS1

um ggf. vorhandenen Schrott im Puffer ausschliessen (durch den Schalter -e werden die Backslash-Kommandos interpretiert, hier z.B. "new line").
Danach entsprechend dann mit

echo -e "\nATSHHMMddmm\n" > dev/ttyS1

eine Zeit in der Zukunft eingeben.
Was dann genau passiert muß dir rasputin, vdrtux, starter, Carlo oder halt jemand sagen bei dem die Schaltung läuft. Ich hab die Schaltung ja so nicht. Wenn das dann klappt gehts weiter. Die Konfiguration wäre dann überhaupt kein Problem
Gruß
steini

Hallo Ihr Alle,

ich melde mich auch mal wieder. Meine Schaltung, die ich auf Grundlage der von Carlo geätzten Platine gebaut habe, hat glücklicherweise gleich funktioniert. Sehr hilfreich beim Testen war ebenfalls ein Display was ich aus einem alten Gerät ausgebaut habe. So siehts bei mir inzwischen aus:

[Blockierte Grafik: http://www.jepsennet.de/wakeup_board.jpg]

Netterweise hat mir Carlo nicht nur eine Platine geätzt sondern auch gleich einen programmierten Atmel zur Verfügung gestellt. Heute habe ich auch endlich meinen seriellen Programmieradapter fertiggestellt und mit PonyProg erfolgreich getestet.

[Blockierte Grafik: http://www.jepsennet.de/wakeup_prog.jpg]

Ich habe vorerst nur den Cursor abgeschaltet und die Anzeige für mein 16x2-Zeichen Display angepasst.

[Blockierte Grafik: http://www.jepsennet.de/wakeup_all.jpg]

Am Anfang hatte ich auch das RC5-Problem. Ich habe auch erst meine Fernbedienung OneForAll URC-7562 auch erst auf einen RC5-Code umprogrammieren müssen.

Dann musste ich, da ich LIRC benutze den COM-Port erst freibekommen um die Wakeup-Schaltung zu programmieren. Hier mein ShutdownHook für die c't-Distribution:

#
# VDR shutdown hook for hw-wakeup - Frank Jepsen
# --------------------------------------------------
# inspired by shutdown hook for nvram-wakeup 
# by Tobias Grimm
#
# This shutdown hook sets the wakeup time for the next timer using
# hw-wakeup. 
#




# read arguments for nvram-wakeup from conf-file
. /etc/vdr/vdr-addon-hw-wakeup.conf


# Defaults:
[ -z "$ENABLED" ]           && export ENABLED="no"
[ -z "$WAKEUP_PORT" ]       && export WAKEUP_PORT="/dev/ttyS0"
[ -z "$KILL_LIRC" ]         && export KILL_LIRC="yes"
[ -z "$MIN_PRE_TIMER" ]     && export MIN_PRE_TIMER=5
[ -z "$MAX_POWEROFF_TIME" ] && export MAX_POWEROFF_TIME=0
[ -z "$MAX_TRY_AGAIN" ]     && export MAX_TRY_AGAIN=0


if [ $MAX_TRY_AGAIN -gt 0 ]
then
  # another script wants to retry shutdown later
  logger -t vdr-addon-hw-wakeup "hw-wakeup not called - shutdown suspended by other script"
  EXITCODE=0
else
  if [ $ENABLED = "no" ]
  then
    # vdr-addon-hw-wakeup is disabled, so just exit
    logger -t vdr-addon-hw-wakeup "hw-wakeup functionality is disabled"
    EXITCODE=0
  else


    # calculate, at what time the machine should be powered on


    NOW=$((`date +%s`))
    if [ -z $1 ] || [ $1 -eq 0 ]
    then
      WAKEUPSTR="00000000"
    else
      NEXTTIMER=`expr $1 - $MIN_PRE_TIMER \* 60`
      if [ $NEXTTIMER -gt $NOW ]
      then
        if [ $MAX_POWEROFF_TIME -eq 0 ]
        then
          WAKEUPTIME=$NEXTTIMER
        else
          WAKEUPTIME=`expr $NOW + $MAX_POWEROFF_TIME \* 60`
          if [ $WAKEUPTIME -gt $NEXTTIMER ] && [ $NEXTTIMER -gt 0 ]
          then
            WAKEUPTIME=$NEXTTIMER
          fi
        fi
      fi
      WAKEUPSTR=`date -d "1970-01-01 $WAKEUPTIME seconds UTC" +%H%M%d%m`
    fi


    TIMESTR=`date +%H%M%d%m`


    logger -t vdr-addon-hw-wakeup "echo ATS00000000 > $WAKEUP_PORT"
    logger -t vdr-addon-hw-wakeup "echo ATS$WAKEUPSTR > $WAKEUP_PORT"
    logger -t vdr-addon-hw-wakeup "echo RTS$TIMESTR > $WAKEUP_PORT"


    if [ $KILL_LIRC = "yes" ]
    then
      /etc/init.d/lirc stop
      setserial $WAKEUP_PORT uart 16550A
    fi


    sleep 1
    echo ATS00000000 > $WAKEUP_PORT
    sleep 1
    echo ATS$WAKEUPSTR > $WAKEUP_PORT
    sleep 1
    echo RTS$TIMESTR > $WAKEUP_PORT
    EXITCODE=0
  fi
fi

Die Parameterübergabe über die serielle Schnittstelle ist leider so gut wie garnicht abgesichert. Schickt man mehr als 11 Bytes bevor der Befehl abgearbeitet wurde, kann es sogar zu Überläufen im Datenbereich des Atmel kommen. Deshalb Vorsicht, es ist leider kein Endezeichen vorgesehen. Die Newlines \n dürften das Programm total aus dem Tritt bringen. Ich hoffe das hilft Euch erstmal ein bischen weiter.

So nun muß ich aber langsam ins Bett.

Tschüß Frank

Hi Frank,

Zitat

Die Newlines \n dürften das Programm total aus dem Tritt bringen

das kann ich mir eigentlich nicht vorstellen. Ich kenne jetzt natürlich nicht die UART-Routine von rasputin, aber normalerweise wird jede Übergabe an den Controller außer den definierten Kommandos ignoriert. An meinem COM-Port hängt sogar ein serielles Display, so dass da jede Menge los ist. Bei mir geht's nur mit "new line" zumindest vor dem Kommando.
Gruß
steini

PS: schönes Skript!!

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

Hallo Frank,

Zitat

Das würde ja bedeuten, dass die Schaltung bei jedem falsch übertragenen Zeichen resettet werden müsste

Nee,Nee, keine Sorge.So ist das sicher nicht.
Also ich beschreib mal kurz wie ich das gemacht hab, und wahrscheinlich hat rasputin das ähnlich gemacht.
Man definiert eine Stringvariable mit konstanter Länge (z.B. "8"). Die UART des Controllers "lauert" auf Daten von der COM-Schnittstelle. Der Empfang eines Zeichens wird entweder durch Auslesen eines Registerbits oder aber durch einen Interrupt gemeldet. Kommt jetzt ein Return oder "new line" ("echo" hängt immer wenn es nicht mit dem Schalter -n aufgerufen wird ein "new line" dran) wird die Übertragung als komplett gewertet und dann die Stringvariable ausgewertet. Jetzt vergleicht man die ersten z.B. 3 Zeichen mit der deklarierten Stringkonstanten die dem Kommando entspricht (z.B. "ATS"). Wenn die übereinstimmt, geht's weiter, wenn nicht wird alles in der Variable ignoriert. Is jetzt nur ganz grob beschrieben.
Aber das genaue Vorgehen ist in einem disassemblierten Code schwer zu erkennen.
Du kannst das ja ganz leicht überprüfen indem du mal Unsinn an den Controller schickst (z.B. ATXwas_weiss_ich). Dann wirst du sehen das nix passiert und du den Controller nicht resetten musst.

Viel wichtiger wäre es wenn einer Tournevis mal sagen würde wie er merkt dass der Controller die Daten korrekt empfangen hat, auch ohne Display. Blinkt dann eine LED oder so? Dann käme er weiter.

Gruß
steini

Hallo, da es doch noch einige Fragen gibt will ich gerne noch helfen:

Zitat

Oder dass das Toggle-Bit stört? Wie lange soll ich denn drücken? Einmal lang oder eher oft und kurz? Wird bei jedem Umstecken des Jumpers ein Anlernen gestartet und mögliche Vorwerte überschrieben?

Durch stecken des Programmierjumpers wird noch nichts gelöscht. Erst
ein erkanntes Signal der FB beschreibt den Speicher neu. Wenn ein
Code erkannt wird, blinkt die LED. Ohne blinken also keine Programmierung.
5 Sekunden drücken reichen eigentlich. Wichtig ist es etwas Abstand zum
IR-Empfänger zu halten, sonst kann er übersteuern und das Signal wird
nicht erkannt.

steini

Mit Deiner Interpretation der UART-Routine hast Du fast recht.
Fakt ist das nur ATS und RTS als Startbefehl ausgewertet werden.
Darauf folgen 8 numerische Zeichen. Alles Andere wird ignoriert und
verworfen.
Eigentlich habe ich mir bei der Entwicklung nicht so viel Gedanken über
diese Routine gemacht. Es sollten ja nur diese 2 Befehle durchkommen
was auch tadellos funktioniert.

Rasputin

PS: Ich hätte nicht gedacht, dass meine Schaltung und die Software
solchen Wirbel verursachen. Viele verstehen nicht, dass ich die Software
nicht frei geben will. Dazu Folgendes: Bei einem früheren anderen Projekt
veröffentlichte ich den Sourcecode mit dem Ergebnis, dass auf einmal einige
verschiedene Versionen der Software im Umlauf waren und niemand wußte
wer wann was geändert hatte.
Das wäre natürlich bei einer solchen hardwarenahen Software wie für
das WakeUP-Modul sehr fatal.
Gerne will ich Euch bei Problemen noch helfen. Aber Ihr müßt verstehen
das ich nicht jede Hardwareumgebung nachstellen kann (Display, Version
und Typ der Distribution usw.) Ich kann auch versuchen einige Sonderwünsche
einzupflegen. Aber mangels Testumgebung ohne Gewähr.

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:
[Blockierte Grafik: 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

Hallo Frank, rasputin, steini, ...

das hilft mir schon sehr weiter! Vielen Dank!

rasputin: Wie ist ist das mit 36kHz und 38kHz? Meine lirc.conf besagt:
bits 13
flags RC5|CONST_LENGTH
eps 30
aeps 100

one 955 817
zero 955 817
plead 978
gap 113548
toggle_bit 2

Passt das?

Tournevis

Tournevis

Eigentlich habe ich von lirc nicht viel Ahnung. Ich weiß nur das diese
36kHz oder 38kHz die Trägerfrequenz ist auf dem der Code von der
FB übermittelt wird (wie im Radio die Musik ). Es spielt auch keine so
große Rolle ob Du einen Empänger mit 36kHz oder mit 38kHz benutzt.
Beide sind breitbandig genug um zu funktionieren. Eventuell sind kleine
Einbußen bei der Empfindlichkeit hinzunehmen.
Alles das was lirc über den COM-Port erhält hat nichts mehr mit der
Trägerfrequenz zu tun.

Rasputin

Hallo,

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

void RXCompleteIntFunc()
{
  int c=RXin;
  int pos=strlen(ReceiveBuf);
  ReceiveBuf[pos++]=c;   // Keine Überlaufprüfung!!
  ReceiveBuf[pos]=0;
}

while(1)  // main loop
  {
    .
    .
    .
    if (strlen(ReceiveBuf)>10)
    {
      if (strncmp(ReceiveBuf,"ATS",3)
      {
        // Timer setzen
      }
      else if (strncmp(ReceiveBuf,"RTS",3)
      {
        // Uhrzeit setzen
      }
      else if (strncmp(ReceiveBuf,"STS",3)
      {
        // Ausgang schalten
      }
      ReceiveBuf[0]=0;    // Puffer löschen
    }
    .
    .
    .
    DelayMS(100);
  }

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

Hi,
rasputin
Schön dass du dich wieder meldest

@Frank
wenn das stimmt wäre das aber recht unkonventionell. Üblicherweise wird tatsächlich mit einem CR oder Zeilenvorschub eine Eingabe beendet. Würde bei mir mit dem seriell angesteuerten Display zu nem ziemlichen Chaos führen denn da gehen locker 20-30 Zeichen pro Sek. drüber ;). Kann aber nur rasputin klären. Muß ja auch spätestens dann geändert werden wenn man im laufenden Betrieb noch was anderes darstellen möchte als die Uhrzeit (Programminfo o.ä.) ohne das Diplay "abzukoppeln".

Tournevis,
wat is denn nu? Klappt's mit dem Setzen des Timers?
Falls ja, müssen noch ein paar Änderungen am System gemacht werden.

[edit]
Cervicor
ich weiß nich ob das hilft, aber:
Manche Netzteile haben keine ganz so saubere Spannung am 5VSB. Versuch doch mal ein ELKO (z.B. 47µF) parallel an die Stromversorgung des Moduls zu löten. Ein 100 nF ist ja schon drin. Nur bitte auf die Polung achten
[/edit]

Gruß
steini

Zitat

Original von rasputin

Durch stecken des Programmierjumpers wird noch nichts gelöscht. Erst
ein erkanntes Signal der FB beschreibt den Speicher neu. Wenn ein
Code erkannt wird, blinkt die LED. Ohne blinken also keine Programmierung.
5 Sekunden drücken reichen eigentlich. Wichtig ist es etwas Abstand zum
IR-Empfänger zu halten, sonst kann er übersteuern und das Signal wird
nicht erkannt.

Alles anzeigen

Hallo Rasputin,

schön, dass Du wieder dabei bist. Das hebt meine Chancen, auch meine Wakeup-Schaltung nun endlich zum Rennen zu bringen.

Ich hatte ja, nachdem ich nach dem Aufbau der Schaltung Probleme beim Anlernen der FB (MD4688 ) hatte, erstmal angekündigt, ein zweites Board zu bestücken, um damit ggf. mehr Erfolg zu haben. Das ist jetzt fertig. Der Fehler bleibt.
Vielleicht also doch nur ein Problem bei mir?

So sieht das jetzt aus: 5V aufs Board (es ist kein VDR angeschlossen, nur der TSOP und ein Display), LED 1 blinkt zweimal, "Bootscreen" auf dem Display, dann "No active timer". Ich setze den Jumper auf 1-2, die LED 2 geht an. Dann probiere ich alle möglichen Codes (inkl. der von Carlo hier vorgeschlagenen TV 290 und CD 376), nichts, kein Blinken. Das in zwei (bis auf den ATMEGA8 komplett neu bestückten) Schaltungen. Drücke ich die All OFF-Taste ,gehts. Aber den Code dieser Taste kann ich praktisch nicht gebrauchen, da damit alle anderen Geräte gleichzeitig aus- bzw. eingeschaltet werden.

Benötige ich zum Anlernen vielleicht bereits die serielle Verbindung zum Rechner, liegt hier mein Fehler???

Hat vielleicht jemand anders eine normale MD4688 (nicht auf lernfähig umgebaut) in Nutzung mit wakeup 1.3? Welchen Code?

Noch einen Schritt weiter: Da hier viel über die Einstellung der seriellen Schnittstelle unter Linux diskutiert wird: geht das Übertragen der Befehle nur unter Linux? Kann ich die Schaltung auch unter Windows oder am Mac (mit einem Keyspan USB-COM) benutzen bzw. testen?

starter

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:

#
# VDR shutdown hook for hw-wakeup - Frank Jepsen
# --------------------------------------------------
# inspired by shutdown hook for nvram-wakeup
# by Tobias Grimm
#
# This shutdown hook sets the wakeup time for the next timer using
# hw-wakeup. 
#




# read arguments for hw-wakeup from conf-file
. /etc/vdr/vdr-addon-hw-wakeup.conf


# Defaults:
[ -z "$ENABLED" ]           && export ENABLED="no"
[ -z "$WAKEUP_PORT" ]       && export WAKEUP_PORT="/dev/ttyS0"
[ -z "$KILL_LIRC" ]         && export KILL_LIRC="yes"
[ -z "$MIN_PRE_TIMER" ]     && export MIN_PRE_TIMER=5
[ -z "$MAX_POWEROFF_TIME" ] && export MAX_POWEROFF_TIME=0
[ -z "$MAX_TRY_AGAIN" ]     && export MAX_TRY_AGAIN=0


if [ $MAX_TRY_AGAIN -gt 0 ]
then
  # another script wants to retry shutdown later
  logger -t vdr-addon-hw-wakeup "hw-wakeup not called - shutdown suspended by other script"
  EXITCODE=0
else
  if [ $ENABLED = "no" ]
  then
    # vdr-addon-hw-wakeup is disabled, so just exit
    logger -t vdr-addon-hw-wakeup "hw-wakeup functionality is disabled"
    EXITCODE=0
  else


    # calculate, at what time the machine should be powered on


    NOW=$((`date +%s`))
    if [ -z $1 ] || [ $1 -eq 0 ]
    then
      WAKEUPSTR="00000000"
    else
      NEXTTIMER=`expr $1 - $MIN_PRE_TIMER \* 60`
      if [ $NEXTTIMER -gt $NOW ]
      then
        if [ $MAX_POWEROFF_TIME -eq 0 ]
        then
          WAKEUPTIME=$NEXTTIMER
        else
          WAKEUPTIME=`expr $NOW + $MAX_POWEROFF_TIME \* 60`
          if [ $WAKEUPTIME -gt $NEXTTIMER ] && [ $NEXTTIMER -gt 0 ]
          then
            WAKEUPTIME=$NEXTTIMER
          fi
        fi
      fi
      WAKEUPSTR=`date -d "1970-01-01 $WAKEUPTIME seconds UTC" +%H%M%d%m`
    fi


    TIMESTR=`date +%H%M%d%m`


    logger -t vdr-addon-hw-wakeup "echo -n ATS00000000 > $WAKEUP_PORT"
    logger -t vdr-addon-hw-wakeup "echo -n ATS$WAKEUPSTR > $WAKEUP_PORT"
    logger -t vdr-addon-hw-wakeup "echo -n RTS$TIMESTR > $WAKEUP_PORT"


    if [ $KILL_LIRC = "yes" ]
    then
      logger -t vdr-addon-hw-wakeup "Shutting down LIRC"
      /etc/init.d/lirc stop
      setserial $WAKEUP_PORT uart 16550A
    fi


    sleep 1
    echo -n ATS00000000 > $WAKEUP_PORT
    sleep 1
    echo -n ATS$WAKEUPSTR > $WAKEUP_PORT
    sleep 1
    echo -n RTS$TIMESTR > $WAKEUP_PORT
    EXITCODE=0
  fi
fi

Tschüß Frank

FrankJepsen

Zur UART-Routine:
1.Es war nie vorgesehen etwas anderes als definierte Kommandos
in einer definierten Zeit an das Modul zu senden.
2. Es findet nie ein Pufferüberlauf statt, egal was an das Modul gesendet wird.
3. Es ist richtig das nur die Länge des Kommandos abgeprüft wird was bis
jetzt auch völlig ausreichend war (siehe Punkt 1)
4. Der Atmel ist auf 9600 baud eingestellt, alles andere ergibt Datenmüll.

Sollte bei einigen über den COM-Port jetzt noch andere Kommunikation
laufen, schreibe ich die Routine um.

starter

FrankJepsen hat Deine Frage ja schon beantwortet.
Ich benutze übrigens eine TCM FB von Tchibo.

Rasputin

Zitat

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.

Zitat

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

Zitat

Hat vielleicht jemand anders eine normale MD4688 (nicht auf lernfähig umgebaut) in Nutzung mit wakeup 1.3? Welchen Code?

@ starter

Ich habe eine MD4688 auf "lernfähig" umgebaut,
eine weitere nicht umgebaut,
beide funktionieren mit Code 376 auf die VCR-Taste programmiert und der Software V1.3.

MfG Carlo

Hallo,

nach einigem Probieren musste ich erkennen, dass der 9V-Block, den ich als Spannungsversorgung angeschlossen hatte, mittlerweile ein wenig platt ist. Am Ausgang des Linearreglers waren gerade mal 3,4V...

Auf der Suche nach einer besseren Spannung dachte ich, es müsste doch auch der PS/2 der Maus geeignet sein, der ja auch aufwecken können soll. Aber da liegt nach Poweroff auch nichts mehr an.
Im Setup habe ich alles mögliche durchprobiert und enabled.
Auch Keyboard wecken geht nicht, und WOL (das hatte ich schon mal laufen) rührt sich auch nicht mehr.
Das einzig reproduzierbare ist der Taster am Gehäuse

Oder genügt es, einfach +5V von der Standby-Versorgung auf RING von COM oder DATA von PS/2 zu legen? Das möchte ich ungern 'mal eben so' ausprobieren.

Tournevis

Hallo Tournevis,

Ich habe eben erst von Carlo gelernt, dass zum Aufwecken über den Ring-Kontakt an der Seriellen Schnittstelle 8V bis 9,5 V anliegen sollen. (Bei ihm geht das Wecken auch nicht mit 7,5 V, bei mir geht es mit 7,8 V auch nicht sicher)

Bei der PS/2 - Schnittstelle müssen meines Wissens Tasten- oder Mauscodes ankommen um den PC zu wecken. Das muss aber auch im BIOS eingestellt werden. Beim Wecken über Tastatur werden da meistens auch spezielle Tastenkombinationen eingestellt, die das Wecken auslösen sollen.

Für WOL sollten 5V o.k. sein. Habe ich so mal gelesen aber auch noch nicht probiert.

Auch eine Warnung von Carlo (habe ich auch selbst gemessen): Am PIN 9 der seriellen Schnittstelle (auf der Wakeup-Platine = Ring) können auch negative Spannungen anliegen. Wenn du damit herumprobieren willst (z.B. an WOL), mußt du eine Diode in Reihe schalten.

viele Grüße
Cervicor