Problem mit LIRC oder MotherBoard

Ähnliches Board (nur mit HDMI) - geht bei mir auch noch nicht.
Ist bei Dir der serielle Anschluss direkt herausgeführt oder über den internen Pfostenfeldstecker mit Kabel? Hast Du dann ein Originalkabel oder Eigenbau?

Garry

Im Moment weiss ich noch nicht ob die Belegung stimm oder lirc noch nicht richtig eingerichtet ist - es kommt noch kein Signal an.

Garry

@All

Zitat

geht über den internen Pfostenstecker, keine Eigenbau-Kabel, alles original.

Nur mal so als Zwischenfrage: Habt ihr auch im BIOS den COM-Port aktiviert?
Das ist mir schonmal bei einem anderen Board passiert und ich habe zwei Tage lang gesucht und gesucht!

An der Stelle noch eine Frage an die Besitzer einer Original-COM-Port-Blende:
Seit dem Wochenende habe ich ein neues Mainboard ASUS M3N78-Pro für den zukünftigen HDTV-VDR!
Da ich später auch LIRC nutzen möchte interessiert mich die Belegung des Pfostensteckers vom COM-Port.

Wer könnte mal seine Original-COM-Port-Blende durchmessen und die Belegung des Pfostensteckers ermitteln?

Danke Paulaner

Moin,

vielleicht das gleiche Problem?

Wer hat MINI ITX + IR am laufen?

Lars

Hab die gleichen Probleme mit einem ASUS-M3N78 Board.
Die Fernbedienung funktioniert nur sporadisch und es tauchen in den Logs die gleichen Meldungen wie oben beschrieben auf:
lirc_serial: ignoring spike: 1 1 4991c8c7 4991c847 30ac5 d7c9c
...

Ich hab mal mit dem Multimeter nachgemessen:
es sind 7.8 Volt am seriellen Ausgang, 5V nach dem Spannungsregler.
vom TSOP kommen 4V zurück -> soweit scheint da alles in Ordnung zu sein

Ich vermute mal, dass dort irgendwelche übersprechenden Signale diese spikes auslösen.
ansonsten bin ich auch ziemlich ratlos

Grüße, Max

Welches originale Kabel hast Du denn eingesetzt? Es gibt ja mindestens 2 verschiedene Belegungen des internen COM-Ports und entsprechend passende Kabel:
http://www.atric.de/IR-Einschalter/com.html

Da steht ja auch: "ASUS veröffentlicht in seinen Handbüchern keine Pin-Belegung.
ASUS verwendet für den internen Sockel - soweit vorhanden - immer die Typ-5 Belegung."
Und wie man die Belegung herausbekommt, steht da auch

Falls die andere Belegnung auch nicht funktioniert, würde mich folgendes Zitat beunruhigen: "Der falsche Anschluß des IR-Einschalters kann diesen unter Umständen zerstören!!" - ich hoffe, das ist nicht der Fall.

Na dann ist es ja ok, hatte mich selbst mal beim Anschluss eines Extensionboards damit vertan, ist auch nichts passiert, aber ich hatte erst die Belegung ändern müssen. War auch so ein undokumentiertes Teil von Board.

Zitat

Original von mdre
Hab die gleichen Probleme mit einem ASUS-M3N78 Board.
Die Fernbedienung funktioniert nur sporadisch und es tauchen in den Logs die gleichen Meldungen wie oben beschrieben auf:
lirc_serial: ignoring spike: 1 1 4991c8c7 4991c847 30ac5 d7c9c
...

Bei Spikes solltest Du in die Signalleitung so dicht wie möglich am Board einen Tiefpaß mit 470Ohm/470pF einfügen.

Lirc_serial hat auch noch einen kleinen Bug: In einer bestimmten Spike-Konstellation wird die Polarität vom Empfänger gedreht. Danach geht nichts mehr. Ein kleiner Patch und die Vorgabe der Polarität per Parameter hilft dagegen:

linux-qgjx:/usr/src/lirc-work # cvs diff -u drivers/lirc_serial/lirc_serial.c
Index: drivers/lirc_serial/lirc_serial.c
===================================================================
RCS file: /cvsroot/lirc/lirc/drivers/lirc_serial/lirc_serial.c,v
retrieving revision 5.99
diff -u -r5.99 lirc_serial.c
--- drivers/lirc_serial/lirc_serial.c   1 Feb 2009 18:47:20 -0000       5.99
+++ drivers/lirc_serial/lirc_serial.c   10 Feb 2009 20:48:10 -0000
@@ -336,6 +336,7 @@
 #define WBUF_LEN 256


 static int sense = -1; /* -1 = auto, 0 = active high, 1 = active low */
+static int rxsense = -1;
 static int txsense;     /* 0 = active high, 1 = active low */


 #ifndef LIRC_IRQ
@@ -488,11 +489,14 @@
                unsigned int new_freq)
 {
        unsigned long long loops_per_sec, work;
+       unsigned long flags;


        duty_cycle = new_duty_cycle;
        freq = new_freq;


+       local_irq_save(flags);
        loops_per_sec = current_cpu_data.loops_per_jiffy;
+       local_irq_restore(flags);
        loops_per_sec *= HZ;


        /* How many clocks in a microsecond?, avoiding long long divide */
@@ -778,7 +782,7 @@
                        break;
                }
                if ((status & hardware[type].signal_pin_change)
-                   && sense != -1) {
+                   && rxsense != -1) {
                        /* get current time */
                        do_gettimeofday(&tv);


@@ -811,7 +815,7 @@
                        if (dcd == last_dcd) {
                                printk(KERN_WARNING LIRC_DRIVER_NAME
                                ": ignoring spike: %d %d %lx %lx %lx %lx\n",
-                               dcd, sense,
+                               dcd, rxsense,
                                tv.tv_sec, lasttv.tv_sec,
                                tv.tv_usec, lasttv.tv_usec);
                                continue;
@@ -826,31 +830,32 @@
                                       "backwards\n");
                                printk(KERN_WARNING LIRC_DRIVER_NAME
                                       ": %d %d %lx %lx %lx %lx\n",
-                                      dcd, sense,
+                                      dcd, rxsense,
                                       tv.tv_sec, lasttv.tv_sec,
                                       tv.tv_usec, lasttv.tv_usec);
                                data = PULSE_MASK;
                        } else if (deltv > 15) {
                                data = PULSE_MASK; /* really long time */
-                               if (!(dcd^sense)) {
+                               if (!(dcd^rxsense)) {
                                        /* sanity check */
                                        printk(KERN_WARNING LIRC_DRIVER_NAME
                                               ": AIEEEE: "
                                               "%d %d %lx %lx %lx %lx\n",
-                                              dcd, sense,
+                                              dcd, rxsense,
                                               tv.tv_sec, lasttv.tv_sec,
                                               tv.tv_usec, lasttv.tv_usec);
                                        /*
                                         * detecting pulse while this
                                         * MUST be a space!
                                         */
-                                       sense = sense ? 0 : 1;
+                                       if (sense == -1)
+                                               rxsense = rxsense ? 0 : 1;
                                }
                        } else
                                data = (lirc_t) (deltv*1000000 +
                                               tv.tv_usec -
                                               lasttv.tv_usec);
-                       frbwrite(dcd^sense ? data : (data|PULSE_BIT));
+                       frbwrite(dcd^rxsense ? data : (data|PULSE_BIT));
                        lasttv = tv;
                        last_dcd = dcd;
                        wake_up_interruptible(&rbuf.wait_poll);
@@ -977,12 +982,14 @@
                                nhigh++;
                        schedule_timeout(HZ/25);
                }
-               sense = (nlow >= nhigh ? 1 : 0);
+               rxsense = (nlow >= nhigh ? 1 : 0);
                printk(KERN_INFO  LIRC_DRIVER_NAME  ": auto-detected active "
-                      "%s receiver\n", sense ? "low" : "high");
-       } else
+                      "%s receiver\n", rxsense ? "low" : "high");
+       } else {
+               rxsense = sense;
                printk(KERN_INFO  LIRC_DRIVER_NAME  ": Manually using active "
-                      "%s receiver\n", sense ? "low" : "high");
+                      "%s receiver\n", rxsense ? "low" : "high");
+       }


        return 0;
 }

Gruß
e9hack

Vielen Dank erstmal für die Hinweise und den Patch, beides hat leider nicht funktioniert.
Ich hab dennoch eine sehr einfache Lösung des Problems gefunden. In der lircd.conf gibt es eine Einstellung für die Toleranzen zur Erkennung eines Tastencodes. Dies sind die Werte eps und aeps.
eps gibt die maximale relative Abweichung in Prozent an, und aeps die maximale absolute Abweichung.
Nach der Erhöhung des Wertes eps von 30 auf 60, funktionierte die Fernbedienung wieder ordnungsgemäß - die spikes bleiben jedoch.
Anscheinend dauert es zu lang oder unterschiedlich lang, bis die Interrupt Service Routine aufgerufen wird.

Gruß, Max

grias eich!

Also ich hab auch seit 48 Stunden ein M3N78 PRO laufen und ebenfalls den Effekt, dass LIRC nicht mehr sauber arbeitet (VDR auf intel board eingerichtet - lirc ok - dann HDD an M3N78 PRO angeschlossen. da mag lirc nicht mehr).

Symptome: MG-Fehler (manchmal gehts)

mode2 -d /dev/lirc0 (bei gestopptem lirc) meldet brav tastenbetätigungen
irrecord geht nicht,

irw zeigt bei weitem nicht jeden tastendruck, aber immerhin

dmesg meldet
[11880.383216] lirc_serial: ignoring spike: 0 1 499fac32 499fac32 55243 54f6b
[11880.411769] lirc_serial: ignoring spike: 1 1 499fac32 499fac32 5ee66 5e9ca
[11880.825514] lirc_serial: ignoring spike: 0 1 499fac33 499fac33 6f5e7 6f345
[11880.833465] lirc_serial: ignoring spike: 0 1 499fac33 499fac33 743ad 7407f
[11881.198607] lirc_serial: ignoring spike: 0 1 499fac34 499fac34 5f4b2 5f180

Hat schon jemande auf einem M3N78 den lirc sauber laufen?

danke
lg
csp

Servus,

das ist vermutlich nicht die Antwort die du erwartet hast. Ich habe mit meinem Board (m3n78-em) das gleiche Problem. Ich habe den Easyvdr darauf laufen . Installiert hatte ich das Ganze mit einem Asus m2n-vm dvi. Damit lief die Fernbedienung fehlerfrei. Der IR-Empfänger ist der Einschalter von Atric (www.atric.de) und er Fernbedienung der TechnoTrend S2-3200. Ich habe dann letzte Woche das Board gegen das m3n78-em getauscht.
Dann funktionierte die Fernbedienung erst mal gar nicht mehr. Ich habe dann in der /etc/lircd.conf den Parameter eps von 30 auf 60 geändert. Seither ist die Fernbedienung einigermasen zu gebrauchen hat aber immer wieder Aussetzer und reagiert oft erst nach mehrmaligen Tastendruck. Im Syslog tauchen dann eben die Meldungen "lirc_serial: ignoring spike: 1 1 49a5a103 49a5a0ff 954e4 7288" auf. Ich werde mal ein Update von lirc auf die Version 0.8.4 versuchen. Danach mal eine andere Fernbedienung.

Gruß
goesi

Servus

ich habe eine Lösung gefunden!

Es liegt an eine Einstellung im BIOS.
Mit BIOS Version 0418 wurde der C1E Support hinzugefügt.
verwendet man ein BIOS < 0418 funktioniert meine Fernbedienung und lirc ohne Fehler.

Dadurch bin ich auf die Einstellung im BIOS gestossen "C1E Configuration"
Dies ist standardmässig auf auto gestellt.
C1E Configuration auf disabled stellen behebt das Problem !!
Es tauchen keine Fehlermeldungen
"lirc_serial: ignoring spike: 0 1 499fac32 499fac32 55243 54f6b'
in der Syslog mehr auf und die die Fernbedienung funktioniert ohne Probleme !
Zumindest ist es bei meiner Konstellation so.
Board: M3N78-EM Aktuelles BIOS 0511
ARTIC IR-Einschalter Rev.4
Fernbedienung der TerraTerm S2-3200

Also: BIOS Setup -> Advanced -> CPU Configuration -> C1E Configuration disabled

Den Menuepunkt sieht man aber erst wenn mann ganz nach unten scrollt !!
Daher findet man diese Einstellung auch nicht sofort.

Wäre Interessant ob es bei Anderen auch funktioniert.

Die Fernbedienung ist natürlich eine TechnoTrend S2-3200 keine TerraTerm !!

ich vermute ehr es liegt an den nicht normgerechten Signalpegeln und zu schwachen Treibern des UART-Ports. Ein Problem das schon oft bei Notebooks zu beobachten war wenn man damit kleine Treiberschaltungen über die RS232-Pegel versorgen wollte.
Bei mir liegt der default Signalpegel bei um die 3V - muss mal mit de, Oszi messen wie der Signalverlauf tatsächlich aussieht. Eventuell hilft ja ein Max232 der über die 5V vom USB-Port versorgt wird.

Garry