Ich hatte den TSOP4838 verwendet. Der ist gut und günstig und hat sich bei mir bewährt.
Wenn man möglichst viele Protokolle empfangen können will, sollte man z.B. den TSOP34338 nehmen.
Die VS1838B gehen sicher auch, aber das Datenblatt lässt vieles offen.
Siehe auch hier.
Keine Ahnung, ob das was zur Sache bringt, aber es gibt neue Treiber bei nvidia.
Kann ich den STM32F10x über einen USB-TTL Adapter verwenden anstatt direkt über USB
Nein.
über TTL sind größere Leitungslängen möglich
Wie lang brauchst du denn?
Ich selbst habe 11m erfolgreich getestet, es gibt aber auch einen Bericht über 40m.
Hintergrund: Verwenden meiner historischen LIRC Konfig
Das macht keinen Sinn.
Und mit stm32IRconfig_gui ist eine neue map in ein paar Minuten erstellt.
Ich könnte jederzeit diesem neuen Scancode einen KEY zuordnen
Ich habe mich da jetzt nicht tiefer reingedacht, aber ich vermute, das geht nur, wenn du den Code anfasst, jedoch nicht nur durch editieren einer Konfiguration.
Man könnte einen Filter schreiben wie z.B. stm32kbd2uinput oder eventlircd aufbohren oder direkt einen Kernel Treiber schreiben wie z.B. hier.
Ich messe die Spannung am Pin 6 (SWCLK) nach dem Widerstand gegen GND.
Das ist am RedLinkCrap aber EXTLED.
Wenn es mit dem STM32 geht, spricht das erst recht dagegen die RedLinkCrap mit
CKS32 zu verwenden.
An welcher Stelle misst du die 0,5V bzw. 1,2 bis 1,5V? Was misst du dort ohne Tastendruck?
Welche Firmware hast du in #158 benutzt? Ist der andere Stick auch ein CKS32?
Was ist zwischen dem Stick und dem Pi?
Falls es beides CKS32 sind, passiert das auch auf einem STM32?
Ich versuche durch Tests dabei zu helfen, IRMP besser zu machen.
Ich habe da noch
-g
-a alsa
Die "robuste" Lösung für GetChanneslWrite() die Klaus hier eingebaut hat, hat es bis VDR-2.4.2 immer schon gegeben. Sie ist aber mit meinem Patch für die "shared PMTPds" leider rausgefallen.
Das würde meine Beobachtung hier erklären.
buffer usage: 100%
Offenbar kann dein VDR die Daten nicht loswerden.
Ich habe das Problem auch, VDR startet auf dem verschlüsseltem Sender, das Bild bleibt meist schwarz, die Aufnahme startet und VDSB.
Workaround der bei mir funktioniert: Ich lasse VDR auf einem anderen verschlüsseltem Sender auf demselben Transponder starten, wenn die Aufnahme beginnt schaltet er um und die Aufnahme ist OK. Starten auf FTA hatte übrigens auch nicht geholfen (mit älterer VDR Version).
Dieses Problem gibt es erst seit ein paar Wochen/Monaten, vermutlich nachdem VDR upgedatet wurde.
Ich benutze dabei KEINE CAM-Tweaks.
Ich weiss nicht, wie clausmuus das letzten Endes umgesetzt hat.
Aber er hat ja geschrieben:
Ich hab das init jetzt auf die udev Variante umgestellt, und hab die udev Regel hinzugefügt.
Die Regel brauchst du (und das irmplircd Start-Skript und die Map).
Wird der Empfänger denn von stm32IRconfig_gui erkannt und werden Tastendrücke empfangen?
Nov 18 05:36:11 vdr kernel: NVRM: Xid (PCI:0000:01:00): 68, pid=1166, CCMDs 00000016 0000c2b0
Vielleicht wäre es einen Versuch wert, einen anderen nvidia Treiber zu probieren, und zu sehen was dann passiert?
Keymap für den STM32
Hast du die README berücksichtigt?
Nach dem Flashen sind alle Einträge weg.
der Speicher ist leer.
Nur zu schauen, ob das Eeprom leer ist, genügt nicht.
Ein gründlicher Test geht so:
reset eeprom
open file (eine map Datei ohne Kommentare mit 61 Zeilen nehmen, wie z.B die angehängte)
flash eeprom
get eeprom
save file
save (debug messages)
prüfen, ob reingeflashte und ausgelesene Datei identisch, z.B. mit diff -s file1 file2
prüfen, ob irgendwelche Fehler im debug: gibt es Zeilen mit ERROR? (Die neue Firmware macht bei jeglichem eeprom Schreibvorgang ein verify.) Z.B. mit grep -e ERROR x.log
Mach bitte nochmal den gründlichen Test mit der Firmware aus #148, und falls der OK ist, auch mit der Firmware aus #152.
