Forum: Projekte & Code IRMP - Infrared Multi Protocol Decoder


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Torsten K. (nobby)


Bewertung
0 lesenswert
nicht lesenswert
Um das ganze zu vervollständigen möchte ich das RCCar jetzt auch noch in 
den IRSND einfügen.

Das habe ich schon gemacht:

in der irsndconfig.h habe ich eingefügt:
#define IRMP_SUPPORT_RCCAR_PROTOCOL             1       // flag: support RC car   

in der irsnd.h habe ich eingefügt:

#define RCCAR_START_BIT_PULSE_LEN               (uint8_t)(F_INTERRUPTS * RCCAR_START_BIT_PULSE_TIME + 0.5)
#define RCCAR_START_BIT_PAUSE_LEN               (uint8_t)(F_INTERRUPTS * RCCAR_START_BIT_PAUSE_TIME + 0.5)
#define RCCAR_PULSE_LEN                         (uint8_t)(F_INTERRUPTS * RCCAR_PULSE_TIME + 0.5)       
#define RCCAR_1_PAUSE_LEN                       (uint8_t)(F_INTERRUPTS * RCCAR_1_PAUSE_TIME + 0.5)   
#define RCCAR_0_PAUSE_LEN                       (uint8_t)(F_INTERRUPTS * RCCAR_0_PAUSE_TIME + 0.5) 
#define RCCAR_FRAME_REPEAT_PAUSE_LEN            (uint8_t)(F_INTERRUPTS * RCCAR_FRAME_REPEAT_PAUSE_TIME + 0.5)

in der irsnd.c habe ich eingefügt:
#if IRMP_SUPPORT_RCCAR_PROTOCOL == 1
          case IRMP_RCCAR_PROTOCOL:
                    {
                        startbit_pulse_len          = RCCAR_START_BIT_PULSE_LEN;
                        startbit_pause_len          = RCCAR_START_BIT_PAUSE_LEN;
                        complete_data_len           = RCCAR_COMPLETE_DATA_LEN;
                        pulse_1_len                 = RCCAR_PULSE_LEN;
                        pause_1_len                 = RCCAR_1_PAUSE_LEN;
                        pulse_0_len                 = RCCAR_PULSE_LEN;
                        pause_0_len                 = RCCAR_0_PAUSE_LEN;
                        // has_stop_bit                = FDC1_STOP_BIT;
                        n_auto_repetitions          = 1;                                            // 1 frame
                        auto_repetition_pause_len   = 0;
                        repeat_frame_pause_len      = RCCAR_FRAME_REPEAT_PAUSE_LEN;
                        irsnd_set_freq (IRSND_FREQ_38_KHZ);
                        break;
                    }
#endif

Was muß mit dem has_stop_bit gemacht werden und wie ist es mit den 
repetitions, sowas gibt es da alles nicht.

Was wohl noch fehlt sind die eigentlichen Daten, da blicke ich aber noch 
nicht ganz durch was da gemacht werden muß ?
Auf jeden Fall müßte da ja auch wieder "zurückgeschoben" werden, aber 
ich weis nicht genau wo das dann hin muß

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hi eku,

eku schrieb:
> Die versprochenen Scans bei 20kHz, Reihe für Reihe von oben nach unten
> (vgl. Beitrag "Re: IRMP - Infrared Multi Protocol Decoder").

Danke, habe sie nun mal durch den IRMP geschickt, Deine Tastatur hat 
dasselbe Timing wie Torsten, die Tasten werden alle als FDC2-Protokoll 
erkannt.

Das heisst, dass Dein damaliger Scan key15.txt aus

  Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"

tatsächlich nur mit 10kHz erzeugt wurde - und nicht mit 15kHz, wie Du 
angegeben hast.

Was auffällig ist: die Timings Deiner Tastatur sind wesentlich exakter, 
sie würde auch bei 10kHz von IRMP einwandfrei erkannt werden. Die 
Streuungen der Puls-/Pausenlängen sind bei Torstens Tastatur wesentlich 
breiter, gerade die Pausen werden zwischendurch arg kurz, so dass hier 
20kHz als Scan-Rate benutzt werden muss.

Woran liegt das? Vielleicht doch am benutzten IR-Empfänger?

Daher Frage an Euch beide (eku und Torsten): welche IR-Empfänger nutzt 
Ihr?

Ich werde das FDC2-Protokoll in FDC umbenennen und das FDC1-Protokoll 
aus dem IRMP wieder rausnehmen. Es gibt keine zwei verschiedenen 
Timings, es gibt nur eins.

Ich melde mich dann später wegen der Tastatur-Matrix nochmal.

Gruß,

Frank

von Torsten K. (nobby)


Bewertung
0 lesenswert
nicht lesenswert
Hy,

ich benutze diesen hier von Reichelt, ich ein 36kHz Typ.

SFH 5110-36
http://www.reichelt.de/?ACTION=3;GROUP=A54;GROUPID=3045;ARTICLE=37920;SID=26P0XrvqwQARoAAALlQXEa9209424a0712a39830a3d1b2f204a48

Ich würde das streuende Timing von mir aber nicht überbewerten, das 
liegt vielleicht auch irgendwo an meiner Platine/Prozessor, oder aber am 
RS232/USB Adapter ?

Ich hatte mir das Signal ja auch auf dem Oszilloskop angeschaut, und da 
konnte ich solche Ausreisser ja garnicht sehen.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hi Torsten,

Torsten Kalbe schrieb:

> ich benutze diesen hier von Reichelt, ich ein 36kHz Typ.
>
> SFH 5110-36

Danke für die Info. Bin gespannt, ob eku einen mit höherer Frequenz 
benutzt und deshalb sein Timing besser ist.

> Ich hatte mir das Signal ja auch auf dem Oszilloskop angeschaut, und da
> konnte ich solche Ausreisser ja garnicht sehen.

Ich habe die Analyze-Funktion von IRMP mal ein wenig ausgebaut, hier die 
Timings von ekus Tastatur:
PULSES:
  6 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 4169
  7 oo 156
avg: 6.0 = 301.8 usec, min: 6 = 300.0, max: 7 = 350.0  tol: 16.0%
PAUSES:
  4 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 1575
  5 oooooooooooooooooooooooooooooooooooooooo 1072
avg: 4.4 = 220.2 usec, min: 4 = 200.0, max: 5 = 250.0  tol: 13.5%

Die (liegenden Glockenkurven) sind praktisch ein Strich, die 
Abweichungen liegen bei 13 - 16%.

Und jetzt das Timing Deiner Tastatur:
PULSES:
  6 oooooooooooooo 43
  7 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 184
  8 oooooooooooooooooooooooooooo 88
  9 ooo 10
 10  3
avg: 7.2 = 361.3 usec, min: 6 = 300.0, max: 10 = 500.0  tol: 38.4%
PAUSES:
  1  1
  2 oooooooooooooooooooo 28
  3 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 83
  4 oooooooooooooooooooooooooooooooooooooooooooooooooooooooo 78
  5 o 2
avg: 3.3 = 163.5 usec, min: 1 = 50.0, max: 5 = 250.0  tol: 69.4%

Hier sind die Kurven breiter und die Abweichhungen liegen bei 38 - 70%. 
Das ist schon happig.

Gruß,

Frank

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

ich benutze das Pollin ATMEL Addon-Board V1.0 (810 053) mit TSOPxx36, 
der breitbandiger als der SFH 5110-36 ist.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> ich benutze das Pollin ATMEL Addon-Board V1.0 (810 053) mit TSOPxx36,
> der breitbandiger als der SFH 5110-36 ist.

Das könnte der Unterschied sein:

Wenn das FDC-Keyboard mit 40kHz oder höher sendet, könnte der 
SFH-Empfänger seine Probleme damit haben. Beim TSOP1736 gibt es keine 
Probleme mit einer 40kHz-Modulation, da wird "nur" die Reichweite ein 
wenig geringer.

Ich habe zu Hause sowohl TSOP1736 als auch TSOP1738 zum Testen.... aber 
leider ist immer noch keine FDC-Tastatur angekommen. Pollin lässt sich 
mal wieder ein wenig Zeit...

Gruß,

Frank

von Torsten K. (nobby)


Bewertung
0 lesenswert
nicht lesenswert
Ich schraube die nächsten Tagen nochmal meine Tastatur auseinander und 
hänge das Scope an die IR-LED, dann sehen wir was da für eine Frequenz 
drauf liegt.

Pollin hat bei meiner letzten Lieferung auch über eine Woche gebraucht, 
die haben wohl momentan gut zu tun....

von Max M. (max_m)


Bewertung
0 lesenswert
nicht lesenswert
hallo,

sorry schon mal für die dumme frage aber:

was läuft hier beim Kompilieren falsch?

meine makefile (arbeite unter linux und will es für einen atmega168 
erstellen)
# controller
MCU = atmega168

# frequency
F_CPU = 20000000UL

# main application name (without .hex)
# eg 'test' when the main function is defined in 'test.c'
TARGET = main

# c sourcecode files
# eg. 'test.c foo.c foobar/baz.c'
SRC = $(TARGET).c irmp.c

# asm sourcecode files
# eg. 'interrupts.S foobar/another.S'
ASRC =

# headers which should be considered when recompiling
# eg. 'global.h foobar/important.h'
HEADERS =

# include directories (used for both, c and asm)
# eg '. usbdrv/'
INCLUDES =


# use more debug-flags when compiling
DEBUG = 1


# avrdude programmer protocol
PROG = usbasp
# avrdude programmer device
DEV = usb
# further flags for avrdude
AVRDUDE_FLAGS =

####################################################
# 'make' configuration
####################################################
CC = avr-gcc
OBJCOPY = avr-objcopy
OBJDUMP = avr-objdump
AS = avr-as
SIZE = avr-size
CP = cp
RM = rm -f
RMDIR = rm -rf
MKDIR = mkdir
AVRDUDE = avrdude

# flags for automatic dependency handling
DEPFLAGS = -MD -MP -MF .dep/$(@F).d

# flags for the compiler (for .c files)
CFLAGS += -g -Os -mmcu=$(MCU) -DF_CPU=$(F_CPU) -std=gnu99 -fshort-enums $(DEPFLAGS)
CFLAGS += $(addprefix -I,$(INCLUDES))
# flags for the compiler (for .S files)
ASFLAGS += -g -mmcu=$(MCU) -DF_CPU=$(F_CPU) -x assembler-with-cpp $(DEPFLAGS)
ASFLAGS += $(addprefix -I,$(INCLUDES))
# flags for the linker
LDFLAGS += -mmcu=$(MCU)

# fill in object files
OBJECTS += $(SRC:.c=.o)
OBJECTS += $(ASRC:.S=.o)

# include config file
-include $(CURDIR)/config.mk

# include more debug flags, if $(DEBUG) is 1
ifeq ($(DEBUG),1)
  CFLAGS += -Wall -W -Wchar-subscripts -Wmissing-prototypes
  CFLAGS += -Wmissing-declarations -Wredundant-decls
  CFLAGS += -Wstrict-prototypes -Wshadow -Wbad-function-cast
  CFLAGS += -Winline -Wpointer-arith -Wsign-compare
  CFLAGS += -Wunreachable-code -Wdisabled-optimization
  CFLAGS += -Wcast-align -Wwrite-strings -Wnested-externs -Wundef
  CFLAGS += -Wa,-adhlns=$(basename $@).lst
  CFLAGS += -DDEBUG
endif

####################################################
# avrdude configuration
####################################################
ifeq ($(MCU),atmega8)
  AVRDUDE_MCU=m8
endif
ifeq ($(MCU),atmega48)
  AVRDUDE_MCU=m48
endif
ifeq ($(MCU),atmega88)
  AVRDUDE_MCU=m88
endif
ifeq ($(MCU),atmega168)
  AVRDUDE_MCU=m168
endif

AVRDUDE_FLAGS += -p $(AVRDUDE_MCU)

####################################################
# make targets
####################################################

.PHONY: all clean distclean avrdude-terminal

# main rule
all: $(TARGET).hex

$(TARGET).elf: $(OBJECTS)
  $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^

# all objects (.o files)
$(OBJECTS): $(HEADERS)

# remove all compiled files
clean:
  $(RM) $(foreach ext,elf hex eep.hex map,$(TARGET).$(ext)) \
    $(foreach file,$(patsubst %.o,%,$(OBJECTS)),$(foreach ext,o lst lss,$(file).$(ext)))

# additionally remove the dependency makefile
distclean: clean
  $(RMDIR) .dep

# avrdude-related targets
install program: program-$(TARGET)

avrdude-terminal:
  $(AVRDUDE) $(AVRDUDE_FLAGS) -c $(PROG) -P $(DEV) -t

program-%: %.hex
  $(AVRDUDE) $(AVRDUDE_FLAGS) -c $(PROG) -P $(DEV) -U flash:w:$<

program-eeprom-%: %.eep.hex
  $(AVRDUDE) $(AVRDUDE_FLAGS) -c $(PROG) -P $(DEV) -U eeprom:w:$<

# special programming targets
%.hex: %.elf
  $(OBJCOPY) -O ihex -R .eeprom $< $@
  @echo "========================================"
  @echo "$@ compiled for: $(MCU)"
  @echo -n "size for $< is "
  @$(SIZE) -A $@ | grep '\.sec1' | tr -s ' ' | cut -d" " -f2
  @echo "========================================"

%.eep.hex: %.elf
  $(OBJCOPY) --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 -O ihex -j .eeprom $< $@

%.lss: %.elf
  $(OBJDUMP) -h -S $< > $@

-include $(shell $(MKDIR) .dep 2>/dev/null) $(wildcard .dep/*)

und das ergibt ein make
avr-gcc -g -Os -mmcu=atmega168 -DF_CPU=20000000UL -std=gnu99 -fshort-enums -MD -MP -MF .dep/main.o.d  -Wall -W -Wchar-subscripts -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wstrict-prototypes -Wshadow -Wbad-function-cast -Winline -Wpointer-arith -Wsign-compare -Wunreachable-code -Wdisabled-optimization -Wcast-align -Wwrite-strings -Wnested-externs -Wundef -Wa,-adhlns=main.lst -DDEBUG   -c -o main.o main.c
main.c:61: Warnung: kein vorheriger Prototyp für »timer_init«
avr-gcc -g -Os -mmcu=atmega168 -DF_CPU=20000000UL -std=gnu99 -fshort-enums -MD -MP -MF .dep/irmp.o.d  -Wall -W -Wchar-subscripts -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wstrict-prototypes -Wshadow -Wbad-function-cast -Winline -Wpointer-arith -Wsign-compare -Wunreachable-code -Wdisabled-optimization -Wcast-align -Wwrite-strings -Wnested-externs -Wundef -Wa,-adhlns=irmp.lst -DDEBUG   -c -o irmp.o irmp.c
irmp.c:1204: Fehler: expected identifier or »(« before »volatile«
irmp.c:1204: Fehler: expected »)« before »(« token
irmp.c:1296: Warnung: Redundante Redeklaration von »irmp_bit«
irmp.c:1193: Warnung: Vorherige Deklaration von »irmp_bit« war hier
irmp.c:2326: Warnung: kein vorheriger Prototyp für »print_spectrum«
irmp.c: In Funktion »print_spectrum«:
irmp.c:2368: Warnung: format »%0.2f« erwartet Typ »double«, aber Argument 3 hat Typ »float«
irmp.c: In Funktion »main«:
irmp.c:2565: Warnung: Übergabe des Arguments 1 von »print_spectrum« entfernt Kennzeichner von Zeiger-Ziel-Typ
irmp.c:2566: Warnung: Übergabe des Arguments 1 von »print_spectrum« entfernt Kennzeichner von Zeiger-Ziel-Typ
irmp.c:2567: Warnung: Übergabe des Arguments 1 von »print_spectrum« entfernt Kennzeichner von Zeiger-Ziel-Typ
irmp.c:2568: Warnung: Übergabe des Arguments 1 von »print_spectrum« entfernt Kennzeichner von Zeiger-Ziel-Typ
make: *** [irmp.o] Fehler 1

wo liegt da das problem?

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Max M. schrieb:
> wo liegt da das problem?

Welche Version? Release oder SVN Top?

von Michael M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
scheint, als würde die irmp.c nicht mitkompiliert werden.
header-datei eingebunden?

von Max M. (max_m)


Bewertung
0 lesenswert
nicht lesenswert
version 1.6
ich glaub versucht sie mit kompilieren sonst würde er doch in der irmp.c 
keine fehler finden oder?



header-dateien werden eingebunden

von Torsten K. (nobby)


Bewertung
0 lesenswert
nicht lesenswert
Tastatur läuft auf 38kHz, hab ich grad nachgemessen.

Gruß
Torsten

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Max M. schrieb:

> was läuft hier beim Kompilieren falsch?
> # use more debug-flags when compiling
> DEBUG = 1

Das muss weg oder auf 0. Debuggen kann man unter Linux nur, wenn man 
IRMP nativ für Linux übersetzt.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hi Torsten,

Torsten Kalbe schrieb:
> Tastatur läuft auf 38kHz, hab ich grad nachgemessen.

Danke für die Info. Das sollte Dein IR-Empfänger aber noch packen. Oder 
hast Du alternativ einen 38kHz-Empfänger zur Hand?

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo Torsten,

Torsten Kalbe schrieb:
> Um das ganze zu vervollständigen möchte ich das RCCar jetzt auch noch in
> den IRSND einfügen.

Du hast das schon ganz gut hinbekommen, aber ein paar wichtige Sachen 
fehlen noch. Solange es dafür keine Doku gibt, wie man einen Encoder in 
IRSND einbaut, wirds auch schwierig.

Ich schaue, dass ich RCCAR diese Woche in den IRSND einbaue. Vielleicht 
kannst Du das dann "abgucken" und im IRMP-Artikel dokumentieren ;-)

Gruß,

Frank

von Torsten K. (nobby)


Bewertung
0 lesenswert
nicht lesenswert
Hy,

also ich habe einen TSOP1738 Empfänger hier, mit dem könnte ich ein paar 
Scans machen. Ich bin mir aber garnicht sicher, welchen ich ursprünglich 
mal verwendet hatte....

Zum RCCar und der Doku, das kann ich dann sicherlich mal versuchen.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hi eku,

eku schrieb:
> Könntest Du bitte die Variable irmp_pause_time auf uint16_t setzen um
> den Überlauf bei höheren Sampleraten zu verhindern.

Wird jetzt abhängig von F_INTERRUPTS gemacht, sobald IRMP_TIMEOUT_LEN 
(das ist die Konstante mit dem höchsten Zeitwert) droht überzulaufen, 
werden irmp_pause_time und last_pause als uint16_t definiert.

So kommt der erhöhte Codebedarf nur bei höheren Frequenzen zum Tragen - 
aktuell ab 15875Hz und mehr. Ist eingecheckt im SVN als Version 1.6.5.

Gruß,

Frank

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank!

Schade das sich RC5 und FDC ausschließen. Im

Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"

beschreibst Du ja, woran es liegt. Fällt Dir vielleicht noch ein Kniff 
ein, wie es doch gehen könnte?

Zum FDC-Protokoll noch ein paar Punkte: Jede Taste wird als zwei Frames 
erkannt, egal wie kurz ich sie betätige. Alle Maustasten werden immer 
als 0000 dekodiert. Ich vermute, dass beides an den nicht dekodierten 
Bits begründet sind.

In Beitrag "Re: IRMP - Infrared Multi Protocol Decoder" schreibst Du noch 
was von anderen Bits,

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ich schaue, dass ich RCCAR diese Woche in den IRSND einbaue. Vielleicht
> kannst Du das dann "abgucken" und im IRMP-Artikel dokumentieren ;-)

FDC- und RCCAR-Protokoll sind nun auch im IRSND drin - eingecheckt im 
SVN.

Demnächst gibt es dann ein neues Release.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:

> Schade das sich RC5 und FDC ausschließen.

Ja, sehr schade.

> Fällt Dir vielleicht noch ein Kniff ein, wie es doch gehen könnte?

Im Moment "verrennt" sich der IRMP im RC5, weil er das Start-Bit früher 
gegen RC5 checkt als gegen FDC. Vielleicht drehe ich die Reihenfolge 
rum, denn ein FDC-Frame ist länger als ein RC5-Frame. Ich könnte ihn 
also zunächst in den FDC-Decoder reinlaufen lassen und wenn plötzlich 
völlige Dunkelheit herrscht, aber noch nicht alle vermeintlichen 
FDC-Bits empfangen wurden, die bisherigen Bits in RC5-Manchester-Code 
"umrechnen". Das könnte vielleicht gehen, ich werde mal drüber 
nachdenken.

> Zum FDC-Protokoll noch ein paar Punkte: Jede Taste wird als zwei Frames
> erkannt, egal wie kurz ich sie betätige.

Im Deinen Scans sehe ich die Wiederholung nur ab und zu, nicht 
ausnahmslos. Ich könnte die Regel einbauen, dass ein Frame mindestens 2x 
reinkommen muss (einmal mit vier 0-en im REPEAT-Block des Frames, einmal 
mit vier 1-en). Erst alle weiteren Repeat-Frames werden dann als 
tatsächlicher langer Tastendruck erkannt werden. Meinst Du das so?

Wenn Du meinst, dass das so besser wäre, mache ich das. Allerding 
wundere ich mich, dass ich diesen 2. Frame nur bei manchen Tastendrücken 
gesehen habe....

> Alle Maustasten werden immer
> als 0000 dekodiert. Ich vermute, dass beides an den nicht dekodierten
> Bits begründet sind.

Ja, die Maustasten werden noch nicht ausgewertet. Dafür werden die 
bisher nicht dekodierten Bits genutzt. Diese werden noch ignoriert.

Mich hätte aber schon mal interessiert, wie z.B. eine Tastenkombination 
STRG-C gesandt wird. Es kann nicht sein, dass zunächst der Keycode für 
STRG, dann der für C gesandt wird. Was ist bei der nächsten Taste? Da 
muss der Empfänger doch wissen, ob die STRG-Taste überhaupt noch 
gedrückt ist. Kannst Du das mal testen, evtl. mit Kombinationen von 
STRG, ALT, SHIFT?

Gruß,

Frank

von Max M. (max_m)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Max M. schrieb:
>
>> was läuft hier beim Kompilieren falsch?
>> # use more debug-flags when compiling
>> DEBUG = 1
>
> Das muss weg oder auf 0. Debuggen kann man unter Linux nur, wenn man
> IRMP nativ für Linux übersetzt.
>
> Gruß,
>
> Frank

Danke für den Hinweis hab es gerade abgeändert.

nun bekomm ich aber immer noch fehler... woran liegt jetzt bitte das?
avr-gcc -g -Os -mmcu=atmega168 -DF_CPU=20000000UL -std=gnu99 -fshort-enums -MD -MP -MF .dep/main.elf.d  -mmcu=atmega168 -o main.elf main.o irmp.o irmp.h
irmp.h:342: Fehler: expected specifier-qualifier-list before »uint8_t«
irmp.h:361: Fehler: expected »=«, »,«, »;«, »asm« or »__attribute__« before »irmp_get_data«
irmp.h:367: Fehler: expected »=«, »,«, »;«, »asm« or »__attribute__« before »irmp_ISR«
make: *** [main.elf] Fehler 1

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
>> Zum FDC-Protokoll noch ein paar Punkte: Jede Taste wird als zwei Frames
>> erkannt, egal wie kurz ich sie betätige.
>
> Im Deinen Scans sehe ich die Wiederholung nur ab und zu, nicht
> ausnahmslos.

Könnte das an IRMP_LOGGION=1 liegen? Die Uart-Ausgabe bremst die 
Interruptroutine aus und es werden weniger Sequenzen 
erkannt/protkolliert?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> Könnte das an IRMP_LOGGION=1 liegen? Die Uart-Ausgabe bremst die
> Interruptroutine aus und es werden weniger Sequenzen
> erkannt/protkolliert?

Die Uart-Ausgabe wird erst gestartet, wenn über eine längere Zeit kein 
Signal mehr am IR-Eingang anliegt. Bis dahin wird gepuffert. In Deinem 
allerersten Scan sandte fast jede Taste 2 Frames. Der lief mit 10kHz. In 
Deinem Scan mit 20kHz kam es nur vereinzelt zu Frame-Wiederholungen. Das 
kann daran liegen, dass bei 20kHz der Logging-Buffer schneller voll ist, 
denn hier wird das Doppelte an Speicher für einen Frame benötigt.

Okay, Du hast zwar meine Frage nicht beantwortet, aber ich nehme mal an, 
dass Du es auch für besser hältst, den ersten und zweiten Frame zusammen 
zu betrachten und erst weitere Frames (ab dem 3.) als Wiederholungen - 
analog zum SIRCS-Protokoll.

Gruß,

Frank

P.S.
Meine Pollin-Tastaturen sind gestern eingetroffen. Leider bin ich in den 
nächsten Tagen viel unterwegs und werde es wohl auch nicht am Wochenende 
schaffen, die Dinger mal selbst zu testen.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Max M. schrieb:
> nun bekomm ich aber immer noch fehler... woran liegt jetzt bitte das?
> avr-gcc -g -Os -mmcu=atmega168 -DF_CPU=20000000UL -std=gnu99
> -fshort-enums -MD -MP -MF .dep/main.elf.d  -mmcu=atmega168 -o
> main.elf main.o irmp.o irmp.h

Die Zeile ist irgendwie Unsinn.

Hier soll ein main.elf gelinkt werden, welches sich aus main.o, irmp.o 
und irmp.h zusammensetzt. So versucht nun der avr-gcc, das irmp.h für 
sich allein zu übersetzen. Das ist aber Quatsch, denn irmp.h ist kein 
eigenständiger Source, sondern nur eine Include-Datei. Das ist in der 
Zeile definitiv zu viel.

Da der make ja schon beim Linken angekommen ist, müsste die Compilierung 
von irmp.c und main.c bereits geschehen sein und Du müsstest dort 
bereits ein main.o und irmp.o vorliegen haben. Ist dem so?

Gruß,

Frank

von Max M. (max_m)


Bewertung
0 lesenswert
nicht lesenswert
ja das ist so aber warum will er die header datei linken?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Max M. schrieb:
> ja das ist so aber warum will er die header datei linken?

Keine Ahnung, ich habe mal eben Dein Makefile unter Linux abgespeichert, 
die führenden Blanks in den Kommando-Zeilen durch TABs ersetzt und 
anschließend eingegeben:
make -n -f Makefile.Max

Der Output dazu:
$ make -n -f Makefile.Max
avr-gcc -g -Os -mmcu=atmega168 -DF_CPU=20000000UL -std=gnu99 -fshort-enums -MD -MP -MF .dep/main.o.d  -Wall -W -Wchar-subscripts -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wstrict-prototypes -Wshadow -Wbad-function-cast -Winline -Wpointer-arith -Wsign-compare -Wunreachable-code -Wdisabled-optimization -Wcast-align -Wwrite-strings -Wnested-externs -Wundef -Wa,-adhlns=main.lst -DDEBUG   -c -o main.o main.c
avr-gcc -g -Os -mmcu=atmega168 -DF_CPU=20000000UL -std=gnu99 -fshort-enums -MD -MP -MF .dep/irmp.o.d  -Wall -W -Wchar-subscripts -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wstrict-prototypes -Wshadow -Wbad-function-cast -Winline -Wpointer-arith -Wsign-compare -Wunreachable-code -Wdisabled-optimization -Wcast-align -Wwrite-strings -Wnested-externs -Wundef -Wa,-adhlns=irmp.lst -DDEBUG   -c -o irmp.o irmp.c
avr-gcc -g -Os -mmcu=atmega168 -DF_CPU=20000000UL -std=gnu99 -fshort-enums -MD -MP -MF .dep/main.elf.d  -Wall -W -Wchar-subscripts -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wstrict-prototypes -Wshadow -Wbad-function-cast -Winline -Wpointer-arith -Wsign-compare -Wunreachable-code -Wdisabled-optimization -Wcast-align -Wwrite-strings -Wnested-externs -Wundef -Wa,-adhlns=main.lst -DDEBUG -mmcu=atmega168 -o main.elf main.o irmp.o
...

Wie man hier in der letzten Zeile sieht, werden nur main.o und irmp.o 
zusammen gelinkt - kein irmp.h. Das ist so vollkommen korrekt. Hast Du 
vielleicht Dein Makefile, was Du hier gepostet hattest, nochmal nachher 
geändert? Für mich sieht es so aus, als ob Du entweder die SRC-Variable 
im Makefile um irmp.h erweitert hast oder gar OBJECTS. Überprüfe das 
bitte nochmal oder nimm das Makefile, was Du hier gepostet hattest und 
setze lediglich DEBUG auf 0.

Gruß,

Frank

P.S.
Wenn Du das hiesige Makefile nimmst, musst Du wohl die führenden TABs 
reparieren. Ich musste das jedenfalls, bevor ich Dein Makefile testen 
konnte. Du kannst natürlich die letzte angezeigte Zeile auch einfach per 
Copy&Paste in der Shell ausführen ;-)

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank!

Mit der SVN-Version von IRMP werden nicht mehr alle Codes des 
Siemens-Protokolls erkannt. Samplerate ist 15kHz, kein anderes Protkoll 
aktiv.


DOS-Zeileenden in test-suite.sh sind Mist

./test-suite.sh
-bash: ./test-suite.sh: /bin/sh^M: bad interpreter: Datei oder 
Verzeichnis nicht gefunden
$ ../irmp-15kHz -v < Siemens-Gigaset-M740AV-15kHz.txt|grep error
error 1: pause after start bit pulse 3 too long: 249
error 1: pause after start bit pulse 3 too long: 249
error 2: pause 249 after data bit 24 too long
error 1: pause after start bit pulse 3 too long: 249
error 2: pause 249 after data bit 24 too long
error 1: pause after start bit pulse 4 too long: 249
error 2: pause 249 after data bit 24 too long
error 1: pause after start bit pulse 4 too long: 249
error 2: pause 249 after data bit 24 too long
error 1: pause after start bit pulse 4 too long: 249
error 2: pause 249 after data bit 24 too long
error 1: pause after start bit pulse 4 too long: 249
error 2: pause 249 after data bit 24 too long
error 2: pause 249 after data bit 24 too long
error 2: pause 249 after data bit 24 too long
error 1: pause after start bit pulse 3 too long: 249
error 2: pause 249 after data bit 24 too long
error 1: pause after start bit pulse 3 too long: 249
error 1: pause after start bit pulse 3 too long: 249
error 1: pause after start bit pulse 3 too long: 249
error 1: pause after start bit pulse 4 too long: 249
error 2: pause 249 after data bit 24 too long
error 1: pause after start bit pulse 4 too long: 249
error 2: pause 249 after data bit 24 too long
error 1: pause after start bit pulse 3 too long: 249
error 2: pause 249 after data bit 24 too long
error 1: pause after start bit pulse 3 too long: 249
error 2: pause 249 after data bit 24 too long
error 1: pause after start bit pulse 3 too long: 249
error 2: pause 249 after data bit 24 too long

Das ging schon mal besser ;-(

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hi eku,

eku schrieb:

> DOS-Zeileenden in test-suite.sh sind Mist

Weiß ich schon seit 25 Jahren ;-)

Nee, im Ernst, ich nutze unter Linux noch meinen eigenen CVS-Server. 
Wenn ich dann unter Windows das Script wieder auschecke, geraten die 
DOS-Zeilenenden da rein. Wenn ich dann anschließend über SVN (unter 
Windows) das Script wieder einchecke, isses dann kaputt. Ich werde das 
Script im CVS explizit auf binary setzen, dann passiert das nicht mehr.

> [code]
> $ ../irmp-15kHz -v < Siemens-Gigaset-M740AV-15kHz.txt|grep error

Kann ich nicht nachvollziehen. Ich habe mir dazu extra nochmal die 
SVN-Version geholt, aus test-suite.sh die DOS-Zeilenenden entfernt und 
dann laufen lassen. Geht ganz normal durch.

Auch Deine obitge Zeile mit Siemens-Gigaset-M740AV-15kHz.txt läuft 
anstandslos durch. Wie hast Du denn irmp-15kHz erzeuhgt? Wenn, dann 
solltest Du die Linux-Binaries mit

  make -f makefile.lnx

erstellen.

> Das ging schon mal besser ;-(

Das geht immer noch so gut ;-)

Gruß,

Frank

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
>> [code]
>> $ ../irmp-15kHz -v < Siemens-Gigaset-M740AV-15kHz.txt|grep error
>
>
> Kann ich nicht nachvollziehen. Ich habe mir dazu extra nochmal die
> SVN-Version geholt, aus test-suite.sh die DOS-Zeilenenden entfernt und
> dann laufen lassen. Geht ganz normal durch.

Bitte setze in irmpconfg.h alle Protokolle außer Siemens auf 0 und
teste noch einmal!

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> Bitte setze in irmpconfg.h alle Protokolle außer Siemens auf 0 und
> teste noch einmal!

Sag mal, kannst Du mit solchen Infos nicht sofort rauskommen, damit ich 
mir nicht einen Wolf suchen muss?

Sobald DENON eingeschaltet ist, funktioniert die SIEMENS-Erkennung.

Bin dran,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> Bitte setze in irmpconfg.h alle Protokolle außer Siemens auf 0 und
> teste noch einmal!

Ist korrigiert und eingecheckt. Es fehlte ein else im Code. Der Fehler 
trat nur auf bei deaktiviertem DENON-Protokoll.

Gruß,

Frank

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Der Fehler trat nur auf bei deaktiviertem DENON-Protokoll.

Danke. Die Testsuite sollte zusätzlich jedes Protokoll für sich testen, 
damit solche Fehler früher auffallen. Dazu braucht es aber Binaries für 
jedes Protokoll. Sollte per Makefile nichht zu kompliziert sein.

Fehlt noch ein Lösung für den Ausschluss von RC5 und FDC/RCCAR wie in
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder" geschrieben.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Im SVN ist eine neue Testversion, welche den Konflikt zwischen RC5 und 
FDC bzw. RCCAR aufhebt.

Kurze Schilderung der Lösung:

Wird RC5 erkannt und passt das Start-Bit zeitlich auch als 
FDC-Protokoll, dann laufen 2 Decoder los. Sobald einer von beiden einen 
Timing-Fehler erkennt, beendet er sich und der andere gewinnt. Dasselbe 
gilt für das RCCAR-Protokoll. Funktioniert mit meinen vorliegenden 
Scan-Daten tadellos.

Man sollte sich aber wirklich überlegen, ob man RC5 und FDC bzw. RC5 und 
RCCAR in Kombination einschalten sollte. Der Decoder für FDC kostet nur 
50 Bytes im Binary, wenn RC5 deaktiviert ist. Ist sowohl RC5 als auch 
FDC eingeschaltet, dann erhöht sich der Platzbedarf des "dualen 
Decoders" auf 500 Bytes. Dasselbe gilt für das RCCAR-Protokoll.

Naja, wer RC5 unbedingt braucht... ich brauchs nicht ;-)

Viel Spaß,

Frank

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Naja, wer RC5 unbedingt braucht...

Das hängt doch in erster Linie von den rumliegenden Fernbedienungen ab. 
Und so alt ist mein DVD-Spieler nun auch nicht. Problematisch ist in 
meinen Augen, dass es so viele unterschiedliche Protokolle existieren.

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank!

Wenn man die "static PROGMEM IRMP_PARAMETER" Blöcke in ein Array 
ir_protos legt und darüber das Protkoll detektiert, spart das noch 
einmal Flash für die vielen Vergleiche:
          uint8_t i;
          for (i = 0; i < NELEMS (ir_protos); i++)
            {
              if (pulse_time >= ir_protos[i].start_len_min &&
                  pulse_time <= ir_protos[i].start_len_max &&
                  pause_time >= ir_protos[i].pause_len_min &&
                  pause_time <= ir_protos[i].pause_len_max)
                {
                  DPRINTF ("protocol %d\n", i);
                  ir_data.protocol = i;
                  ir_protop = &ir_protos[i];
                  break;
                }
            }
          if (i == NELEMS (ir_protos))
            {
              DPRINTF ("protocol UNKNOWN\n");
              /* wait for another start bit */
              start_bit_detected = 0;
            }

Bitte Variablennamen **kreativ** an irmp anpassen.

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe gestern abend mal meine FDC-Pollin-Tastatur mit IRMP getestet. 
Dabei konnte ich noch ein paar Geheimnisse lüften. Die vermeintlichen 
REPEAT-Bits im Frame kennzeichnen keine Wiederholung, sondern das 
Drücken bzw. Loslassen einer Taste. Damit können dann auch 
Tasten-Kombinationen wie

  SHIFT + A
  ALT + M
  STRG + C
  usw.

erkannt werden.

Ich habe IRMP dahingehend angepasst, dass in den untersten 7 Bit der 
Keycode der Taste gespeichert ist und im oberen 8. Bit vermerkt wird, ob 
die Taste gedrückt oder losgelassen wird. Die entsprechende Änderungen 
im IRMP habe ich als Version 1.6.9 ins SVN eingecheckt.

Ebenso habe ich prototypisch eine kleine C-Funktion geschrieben, welche 
aus einem Keycode oder einer Keycode-Folge (bei obigen 
Tastenkombinationen) den zugehörigen ASCII-Code ermittelt, siehe Anhang.

Diese kann entweder direkt auf dem µC zur Ermittlung der Taste oder auf 
dem Host, wo die irmp-Datenstruktur hin übertragen wird, eingesetzt 
werden.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hi eku,

eku schrieb:
> Wenn man die "static PROGMEM IRMP_PARAMETER" Blöcke in ein Array
> ir_protos legt und darüber das Protkoll detektiert, spart das noch
> einmal Flash für die vielen Vergleiche:

Gute Idee, geht zwar nicht ganz so glatt, wie Du es darstellst, aber das 
kann durchaus was bringen. Werde ich testen.

Gruß,

Frank

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Noch ein Vorschlag:
#if F_INTERRUPTS >= 14500
#define IRMP_SUPPORT_SIEMENS_PROTOCOL           0       // flag: support Siemens Gigaset       uses ~150 bytes
#else
#define IRMP_SUPPORT_SIEMENS_PROTOCOL           0       // DO NOT CHANGE! F_INTERRUPTS too low!
#endif

ändern in
#if F_INTERRUPTS < 14500
#undef IRMP_SUPPORT_SIEMENS_PROTOCOL
#define IRMP_SUPPORT_SIEMENS_PROTOCOL 0
#pragma warning: F_INTERRUPTS too low, disapling SIEMENS protocol
#endif

und den eigentlichen
#define IRMP_SUPPORT_SIEMENS_PROTOCOL           0       // flag: support Siemens Gigaset       uses ~150 bytes

hoch zu den anderen Protokollen. Analog die anderen Problemprotokolle.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Neue Version 1.7.0 von IRMP verfügbar, Download unter

  http://www.mikrocontroller.net/articles/IRMP#Download

Änderungen gegenüber 1.6.0:

  - Neues Protokoll: RCCAR
  - Tastenerkennung für FDC-Protokoll (IR-keyboard) erweitert
  - Konflikte FDC <--> RC5 beseitigt
  - Interrupt-Frequenz nun bis zu 20kHz (und mehr) möglich

Ebenso ist nun die Version 1.7.0 von IRSND verfügbar, Download unter

  http://www.mikrocontroller.net/articles/IRMP#Download_IRSND

Änderungen gegenüber 1.6.0:

  - Neues Protokoll: RCCAR


Die Dokumentation im IRMP-Artikel habe ich auch angepasst bzw. 
erweitert, siehe:

  http://www.mikrocontroller.net/articles/IRMP

Für die Pollin-FDC-Tastatur habe ich im Artikel ein eigenes Kapitel 
vorgesehen, wo sämtliche Tasten/Keycodes und die Anwendung mit IRMP 
dokumentiert sind:

  http://www.mikrocontroller.net/articles/IRMP#IR-Tastaturen

@Hugo Portisch:

Kannst loslegen mit der USB-Portierung ;-)

@eku & @ Torsten Kalbe:

Ich habe bei der FDC-Tastatur und einem TSOP1736 als Empfänger nur eine 
Reichweite von max. 15cm, das ist viel zu wenig. Klar, die 
Modulationsfrequenz der FDC-Tastatur ist 38kHz, daher sollte die 
Reichweite bei meinem Aufbau schon eingeschränkt sein. Aber ich dachte 
schon, dass ein paar Meter drin sein müssten. Naja, ich werden den 
TSOP1736 mal durch einen TSOP1738 ersetzen und dann nochmal testen. 
Welche Reichweite schafft Ihr mit der Tastatur?

Viel Spaß,

Frank

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank!

Frank M. schrieb:
> Tastenerkennung für FDC-Protokoll (IR-keyboard) erweitert

Was liefert eigentlich das Steuerkreuz rechts der Tastatur? Soweit ich 
mich erinnere sind da mehr als nur 4 Richtungen möglich.
#if IRMP_SUPPORT_SIEMENS_PROTOCOL == 1 && F_INTERRUPTS < 15000
#warning F_INTERRUPTS too low, SIEMENS protocol disabled (should be at least 15000)
#endif

#if IRMP_SUPPORT_RECS80_PROTOCOL == 1 && F_INTERRUPTS < 20000
#warning F_INTERRUPTS too low, RECS80 protocol disabled (should be at least 20000)
#endif

#if IRMP_SUPPORT_RECS80EXT_PROTOCOL == 1 && F_INTERRUPTS < 20000
#warning F_INTERRUPTS too low, RECS80EXT protocol disabled (should be at least 20000)
#endif

Wo sind denn die undefs für das 'disabled' geblieben?

Prinzipiell sollte F_INTERRUPTS auf den höchsten benötigten Wert anhand 
der aktivierten Protokolle automatisch gesetzt werden. Warum den 
Benutzer damit belasten. Dann entfallen auch die Warnungen und 
Automatismen zur Deaktivierung von Protkollen. Gegenteilige Meinungen?

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> eku schrieb:
>> Wenn man die "static PROGMEM IRMP_PARAMETER" Blöcke in ein Array
>> ir_protos legt und darüber das Protkoll detektiert, spart das noch
>> einmal Flash für die vielen Vergleiche:
> Gute Idee, geht zwar nicht ganz so glatt, wie Du es darstellst, aber das
> kann durchaus was bringen. Werde ich testen.

Gibt es schon Erkenntnisse bezüglich Speicherverbrauch?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hi eku,

eku schrieb:
> Was liefert eigentlich das Steuerkreuz rechts der Tastatur? Soweit ich
> mich erinnere sind da mehr als nur 4 Richtungen möglich.

Das Ding ist nach meinen Versuchen her ziemlich unbrauchbar, da kommen 
relativ wirkürlich 4 verschiedene Bits für oben, unten, rechts, oben und 
bei Zwischenstellungen dann die Summen davon. Leider ist das aber so 
ungenau, dass da beim Drücken des Steuerkreuzes nach rechts so ziemlich 
alles kommt zwischen unten, unten-rechts, rechts, oben-rechts und oben.
Daher habe ich aufgegeben, das Steuerkreuz zu decodieren. Es wird 
schlichtweg ignoriert.

> Wo sind denn die undefs für das 'disabled' geblieben?

Vergessen ;-)

Werde ich dieses Wochenende korrigieren.

> Prinzipiell sollte F_INTERRUPTS auf den höchsten benötigten Wert anhand
> der aktivierten Protokolle automatisch gesetzt werden. Warum den
> Benutzer damit belasten. Dann entfallen auch die Warnungen und
> Automatismen zur Deaktivierung von Protkollen. Gegenteilige Meinungen?

Du kommst jedesmal, wenn ich was umbaue nach Deinen Wünschen, mit einer 
neuen Idee. ;-)

Ob eine 20kHz-Interrupt-Rate bei einer CPU-Frequenz von 8MHz noch 
sinnvoll ist, kann ich nicht beurteilen. Wenn man alle Protokolle 
einschaltet, könnte es dabei eng werden. Um das herauszubekommen, müsste 
man mal die Belastung der CPU in der ISR messen.

Ich halte wenig von Deiner Idee, die Interrupt-Frequenz selbst zu 
bestimmen, denn ich möchte den Anwender von IRMP nicht übermäßig 
bevormunden. Vielleicht hat er durchaus Gründe, die ISR mit 15kHz 
anzusprechen statt mit 10kHz, auch wenn 10kHz reichen würde. Auch kommt 
es darauf an, welchen Timer er nimmt. Die Wahl des Timers und die Wahl 
der Vorteiler/Timing-Register bestimmt die Frequenz und nicht umgekehrt.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> Frank M. schrieb:
>> eku schrieb:
>>> Wenn man die "static PROGMEM IRMP_PARAMETER" Blöcke in ein Array
>>> ir_protos legt und darüber das Protkoll detektiert, spart das noch
>>> einmal Flash für die vielen Vergleiche:
>> Gute Idee, geht zwar nicht ganz so glatt, wie Du es darstellst, aber das
>> kann durchaus was bringen. Werde ich testen.
>
> Gibt es schon Erkenntnisse bezüglich Speicherverbrauch?

Nein, da habe ich mich noch nicht durchringen können, das umzusetzen. 
Ich schwanke nämlich mittlerweile, ob ich diese "Optimierung" überhaupt 
machen soll, nämlich aus folgenden Gründen:

1. Jetzt werden die Startbit-Timings gegen Konstanten geprüft. Das ist
   mit nur wenigen CPU-Takten möglich. Beim Testen der Timings gegen
   Variablen in einer for-Schleife dauert der Check eines Protokolls
   gegen die Startbit-Timings wesentlich länger, weil dann erstmal
   die Variablen in Register geladen werden müssen, um sie gegen die
   ermittelten Timing-Werte zu testen. Bei knapp 20 Protokollen kommt
   da einiges an Laufzeit zusammen, was da zusätzlich verbraten wird.
   Da dies alles innerhalb eines einzigen ISR-Laufes passieren muss,
   kann das arg knapp werden. Man spart zwar Speicherplatz, aber auf
   Kosten von Laufzeit.

2. Wenn Du Dir die Startbit-Timing-Checks anschaust, wirst Du sehen,
   dass nur die wenigsten aller Tests identisch sind. Bei den
   Manchester-Protokollen (RC5, RC6, Grundig, usw.) sind 4 Tests
   notwendig, bei den anderen nur 2 Tests - aber nur, wenn sie
   ausgezeichnete Startbits haben. Beim Denon-Protokoll, welches
   keine Startbits aufweist, muss ich hingegen wieder 4 Tests machen,
   weil das erste Bit schon eine 0 oder eine 1 sein kann. Ausserdem
   kommen dann evtl. weitere Tests hinzu, beim RC5-Protokoll können
   (wegen des erweiterten RC5-X-Protokolls) auch die ersten beiden
   Puls-Pausen-Werte schon verschieden sein. Desweiteren kommt dann
   noch das "Starten" eines zweiten Parallel-Decoders hinzu, um
   den Konflikt zwischen RC5<->FDC und RC5<->RCCAR zu lösen.
   Wenn man diese ganzen Sonderbedingungen in die for-Schleife
   zusätzlich einbaut, wird das ähnlich viel Code verschlingen
   wie jetzt auch.

Man könnte einen Kompromiss eingehen:

Diejenigen Pulse-Distance-Protokolle, für die keine Sonderbedingungen 
anfallen, kann man in einer for-Schleife zusammenfassen - also SIRCs,
NEC, SAMSUNG, MatSUSHITA, KASEIKYO und noch ein paar andere. Aber ob 
sich das dann noch lohnt? Weiß ich nicht.

Mir schwebt eine andere Optimierung vor: Im Moment ist die Ermittlung 
des Protokolls aus den Startbit-Timings eine lineare Suche. Ab einer 
bestimmten Anzahl wird dies ineffektiv, weil dann N Tests gemacht werden 
müssen. Wenn man die lineare Suche gegen eine baumartige Suche ersetzen 
würde, geht das effektiver und spart Zeit. Die ISR kommt nämlich 
irgendwann ab einem bestimmten N (Anzahl der Protokolle) an seine 
Grenzen, und zwar genau nach dem Empfang des Startbits: hier geht die 
Sucherei los... und das kann lang dauern. Wenn man das durch eine 
Intervallschachtelung ersetzt, braucht man nur noch log2(N) viele Tests.

Ungefährer Algorithmus:

Man teilt die Protokolle in 2 Gruppen: Diejenigen mit kurzen und 
diejenigen mit langen Startbits. Dann kann man schon mal 50% der 
Protokolle auf einen Schlag ausschließen. Dann werden die diese 2 
Gruppen wieder in Untergruppen zerschlagen, so dass man mit einem 
weiteren Test von den 50% wieder 50% ausschließen kann. Dann bleiben nur 
noch 25% übrig usw.

Die Kunst besteht nun darin, diesen Abfragebaum zur Compilezeit 
zusammenzustellen - oder zumindest in der init-Funktion. Da denke ich 
noch drüber nach, wie ich das bewerkstellige.

Gruß,

Frank

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi Frank!

Frank M. schrieb:
> Du kommst jedesmal, wenn ich was umbaue nach Deinen Wünschen, mit einer
> neuen Idee. ;-)

In den 25 Jahren Deiner Softwareentwicklung hast Du bestimmt 
mitbekommen:
  * Softwareentwicklung ist ein iterativer Prozess
  * der Kunde hat immer neue Wünsche an die Software
  * ein Programm, das fertig ist, ist veraltet

Lass Dich von mir nicht entmutigen!

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:

> Lass Dich von mir nicht entmutigen!

Nönö, alles noch im grünen Bereich ;-)

Ich hatte Dich noch gefragt, welche Reichweite Deine FDC-Tastatur hat, 
wahrscheinlich hast Du es überlesen... mit meinem TSOP1736 und einer 
Reichweite von nur 15cm bin ich nicht zufrieden. Ich weiß, dass ein 
TSOP1738 bei der Tastatur besser geeignet wäre, jedoch kann ich mir 
diese geringe Reichweite damit nicht allein erklären.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> Gibt es schon Erkenntnisse bezüglich Speicherverbrauch?

Ich habe das gerade mal getestet:

Alle Startbit-Timings in eine struct gepackt und dann zwei for-Schleifen 
(eine mit ausgezeichneten Startbits: 2 Tests, eine für diejenigen 
Protokolle, die direkt mit den Daten beginnen: 4 Tests) gebaut.

Ergebnis: Wenn alle Protokolle aktiviert sind, liegt die Ersparnis bei 
150 Bytes. Leider steigt die Größe des Datensegments dabei um 140 Byte. 
Wenn weniger Protokolle aktiviert sind, dann ist der Gewinn noch 
geringer.

Das kann man also vergessen: es bringt nichts. Im Gegenteil: die 
Laufzeit vergrößert sich drastisch wegen des Ladens aller Startbit-Werte 
aus der struct in die Register, um den Vergleich durchführen zu können. 
Das Einzige, was mir an der Änderung gefällt, ist, dass der Source 
"schöner" aussieht ;-)

Ich werde daher diese Änderung erstmal auf Eis legen und später 
vielleicht wieder aufgreifen, nämlich dann, wenn ich die lineare Suche 
durch eine Intervallschachtelung ersetzen werde.

Gruß,

Frank

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ich hatte Dich noch gefragt, welche Reichweite Deine FDC-Tastatur hat,
> wahrscheinlich hast Du es überlesen... mit meinem TSOP1736 und einer
> Reichweite von nur 15cm bin ich nicht zufrieden.

Nicht überlesen, nur gerade den AVR nicht dabei :-)
Also mein TSOP1736 auf dem Pollin AVR Add-On reagiert noch am anderen 
Ende des Zimmers, d.h. mehr als drei Meter sind kein Problem.

von Torsten K. (nobby)


Bewertung
0 lesenswert
nicht lesenswert
Hy,

ich kann die Reichweite auch nicht so einfach testen, was größer als ein 
paar Meter sein sollte. Dann müßte ich meinen Testempfänger mal mit 
einem 9Volt Block betreiben und die Straße unsicher machen.

Gruß
Torsten

von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gehört zwar vielleicht nicht direkt hierher, hat aber mit IRMP zu tun:
wie lässt sich effektiv (speicher- und laufzeittechnisch) eine Art 
Lookup-Tabelle erstellen, die anhängig von empfangenen IR-Daten ein 
Zeichen über die UART sendet?

Ich will nicht den kompletten IR-Frame senden, sondern wirklich nur ein 
einzelnes 8-bit-Zeichen. Nach Möglichkeit sollte das Ganze lernbar sein, 
d.h. nicht festgelegt auf bestimmte IR-Protokolle/-Kommandos. Auch 
verschiedene Protokolle sollten möglich sein.

BTW: IRMP ist ein richtig feines Stück Software... Vielen Dank dafür!

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> Also mein TSOP1736 auf dem Pollin AVR Add-On reagiert noch am anderen
> Ende des Zimmers, d.h. mehr als drei Meter sind kein Problem.

Torsten Kalbe schrieb:

> ich kann die Reichweite auch nicht so einfach testen, was größer als ein
> paar Meter sein sollte. Dann müßte ich meinen Testempfänger mal mit
> einem 9Volt Block betreiben und die Straße unsicher machen.

Danke fürs Feedback, da muss meine Tastatur (eine von 5, die ich 
bestellt hatte) nicht in Ordnung sein, normale Fernbedienungen werden 
nämlich auch bei mir auf 3-5 Meter erkannt. Muss ich heute abend mal die 
zweite Tastatur auspacken....

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Micha schrieb:
> wie lässt sich effektiv (speicher- und laufzeittechnisch) eine Art
> Lookup-Tabelle erstellen, die anhängig von empfangenen IR-Daten ein
> Zeichen über die UART sendet?

Das ginge mit einer Hash-Funktion. Da hatte mal jemand so etwas im 
Februar diesen Jahres hier in der Codesammlung vorgestellt:

   Beitrag "Universeller IR-Receiver für viele Protokolle"

Hier wird aus dem IR-Frame ein 32-Bit-Hash-Wert berechnet - ohne 
Kenntnis des Protokolls. Hat aber ein paar Stolpersteine... z.B. die 
Behandlung von Repetition-Frames, Eindeutigkeit usw.

Da Du sogar alles in ein einziges Byte packen möchtest, sind doppelte 
Rückgabewerte vorprogrammiert. Auch bei einem 32-Bit-Hash-Wert kann man 
nicht ausschließen, dass zwei verschiedene Fernbedienungen auf 
irgendwelchen Tasten denselben Hash-Wert ergeben. Aber es ist halt 
relativ unwahrscheinlich - jedenfalls dann, wenn die Hash-Funktion "gut" 
ist. Aber eine Hash-Funktion, die nur einen eindeutigen 8-Bit-Wert 
zurückgeben soll - und das ohne Kenntnisse irgendwelcher Protokolle - 
kannste vergessen.

Gruß,

Frank

von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Aber eine Hash-Funktion, die nur einen eindeutigen 8-Bit-Wert
> zurückgeben soll - und das ohne Kenntnisse irgendwelcher Protokolle -
> kannste vergessen.
Und wenn ich nur ein Protokoll "gleichzeitig" zulassen würde? Wie 
schätzt du die Chancen dann ein?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Micha schrieb:
> Frank M. schrieb:
> Und wenn ich nur ein Protokoll "gleichzeitig" zulassen würde? Wie
> schätzt du die Chancen dann ein?

Das kommt darauf an, wieviele Tasten Du unterscheiden möchtest. Sind es 
lediglich die Tasten 0-9, kommst Du mit 4 Bit aus. Wenn wir uns noch das 
NEC-Protokoll anschauen, dann ist die Chance, dass Du in Deinem Haushalt 
2 NEC-kompatible Fernbedienungen hast, schon relativ groß. Dass es 
Überschneidungen bei den Tasten '0' bis '9' gibt, ist auch relativ 
wahrscheinlich.

Du müsstest Dich also nicht nur auf ein Protokoll einschränken, sondern 
auch noch auf eine Adresse konzentrieren, um ein Kommando einer FB 
eindeutig zu erkennen. Wenn Du bis zu 32 Tasten unterscheiden möchtest, 
sind 5 Bit weg und Du hast noch 3 Bit, um verschiedene FBs anhand ihrer 
Adresse zu unterscheiden. Das wird arg knapp.

IRMP nutzt nicht umsonst 16 Bit für die Adresse und 16 Bit für das 
Kommando. Meist kommt man mit 8 Bit für die Adresse und 8 Bit für das 
Kommando aus - aber nicht immer.

Warum willst Du Dich unbedingt auf 8 Bit beschränken? Hugo Portisch, der 
den IRMP im USB-IR-Receiver nutzt, überträgt einfach 6 Bytes, nämlich:

1. Byte: irmp_data.protocol
2. und 3. Byte: irmp_data.address
4. und 5. Byte: irmp_data.command
6. Byte: irmp_data.flags

Du könntest natürlich auch mittels IRMP alles in ein Byte packen:

a) Nur ein Protokoll aktivieren, alle anderen deaktivieren

b) irmp_data.address auf einen festen Wert prüfen, also nur
   eine Adresse zulassen

c) Für die Tasten, die Du übertragen willst, einen case-switch
   bauen, der bestimmte Werte von irmp_data.command in die Werte
   1, 2, 3, 4, usw. übersetzt.

Man könnte noch einen Schritt weiter gehen: Bei 32 verschiedenen Tasten 
hast Du dann noch 3 Bits übrig. Damit könntest Du in den 8 Bits 
folgendes codieren:

   RAACCCCC

wobei:

   R    =  Repetition Flag
   AA   =  00 Adresse FB Nr. 1
           01 Adresse FB Nr. 2
           10 Adresse FB Nr. 3
           11 Adresse FB Nr. 4
   CCCCC = 32 verschiedene Tasten

Somit könntest Du dann zumindest für 4 verschiedene FBs 32 verschiedene 
Tasten-Codes übertragen.

Das obige gilt aber nur für IRMP - unter der Voraussetzung, dass man 
nicht nur das Protokoll, sondern auch schon die Tastencodes kennt. Eine 
Hash-Funktion zu finden, die ohne Kenntnis des Protokolls alles in 8 Bit 
ohne Dubletten stopft, halte ich für illusorisch. Und dann auch noch 
"anlernbar"? Da müsste sich die Hash-Funktion selbst modifizieren, 
sobald ein neuer Code angelernt werden soll, um Dubletten zu vermeiden.

Okay, letzter Versuch:

Du nimmst die 32-Bit-Hashfunktion aus

     Beitrag "Universeller IR-Receiver für viele Protokolle"

und trägst den ermittelten 32-Bit-Hash-Wert in eine 256 x 4 Byte große 
Tabelle ein. Dann kannst Du den 8-Bit-breiten Index auf diese Tabelle 
nutzen, um eine Taste zu identifizieren. Kostet Dich leider 1KB RAM ;-)

Gruß,

Frank

von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Warum willst Du Dich unbedingt auf 8 Bit beschränken? Hugo Portisch, der
> den IRMP im USB-IR-Receiver nutzt, überträgt einfach 6 Bytes, nämlich:
Ich habe ähnliches vor wie Hugo, allerdings wollte ich den AVR (einen 
ATtiny84) "direkt als Tastatur" nutzen, also ohne dlls und dergleichen.

Anlernbar sollte heißen, dass man die IR-Kommandos beliebig einer Taste 
zuweisen kann, à la "Drücken Sie jetzt die Taste für 'a' auf Ihrer 
FB"...

von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Im Prinzip wollte ich das hier 
http://www.obdev.at/products/vusb/hidkeys.html ohne Tasten und 
stattdessen mit IR-Empfänger bauen.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Micha schrieb:
> Anlernbar sollte heißen, dass man die IR-Kommandos beliebig einer Taste
> zuweisen kann, à la "Drücken Sie jetzt die Taste für 'a' auf Ihrer
> FB"...

Wo ist das Problem? Du nimmst IRMP und eine NEC-kompatible 
Fernbedienung. Da sind die Codes zwischen 0x00 und 0xFF.

Zu jeder Taste (z.B. 'a') merkst Du Dir imrp_data.command.

Gruß,

Frank

von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Du nimmst IRMP und eine NEC-kompatible Fernbedienung. Da sind die Codes
> zwischen 0x00 und 0xFF.
Das wäre natürlich eine Möglichkeit. Nachdem ich eine 
Universal-Fernbedienung habe ist das Protokoll eh relative egal - ich 
muss mir halt ein entsprechendes Gerät aus der Datenbank suchen.

Wenn ich so darüber nachdenke müsste es sogar möglich sein mir was 
eigenes zu basteln.

Ich werd mal verschiedenes testen. Vielen Dank für die Tipps!

von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Du nimmst IRMP und eine NEC-kompatible Fernbedienung. Da sind die Codes
> zwischen 0x00 und 0xFF.
Das wäre natürlich eine Möglichkeit. Nachdem ich eine 
Universal-Fernbedienung habe ist das Protokoll eh relative egal - ich 
muss mir halt ein entsprechendes Gerät aus der Datenbank suchen.

Wenn ich so darüber nachdenke müsste es sogar möglich sein mir was 
eigenes zu basteln.

Ich werd mal Verschiedenes testen. Vielen Dank für die Tipps!

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

es gibt einen Bugfix für IRMP - Version 1.7.2, Download unter

  http://www.mikrocontroller.net/articles/IRMP#Download

Änderungen gegenüber 1.7.1:

 - Bugfix: Einführen eines Timeouts für NEC-Repetition-Frames, um
   "Geisterkommandos" zu verhindern.

Was ist ein "Geisterkommando"?

Folgende Situation:

1. IRMP empfängt NEC-Kommonda A und weitere Repetition-Frames

2. Danach wird die Taste B lange gedrückt und IRMP empfängt das
   Kommando nicht vollständig - z.B. wegen zu geringer Reichweite oder
   weil die Katze durch den Strahl läuft.

3. Die FB sendet nun Repetition-Frames für Kommando B und IRMP
   interpretiert diese Wiederholungen als Wiederholungen für Kommando A!

Frank Lorenzen hat mich auf den Fehler aufmerksam gemacht, denn er 
konnte dieses Phänomen tatsächlich im "real life" erleben... naja... 
nicht die Katze war schuld ;-) Vielen Dank dafür!

Viel Spaß,

Frank

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Version 1.7.2

In irsndconfig.h ist noch die alte Behandlung für 
IRSND_SUPPORT_SIEMENS_PROTOCOL. Würdest Du das bitte an irmpconfig.h 
anpassen, d.h. Ausgabe einer Warnung mit Deaktivierung des Protokolls.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> In irsndconfig.h ist noch die alte Behandlung für
> IRSND_SUPPORT_SIEMENS_PROTOCOL. Würdest Du das bitte an irmpconfig.h
> anpassen, d.h. Ausgabe einer Warnung mit Deaktivierung des Protokolls.

Ich hatte nur IRMP angepasst. IRSND hat noch die alte Version ;-)
Aber klar, ich korrigiere das.

Gruß,

Frank

von Frank L. (florenzen)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:

[...]
> Änderungen gegenüber 1.7.1:
>
>  - Bugfix: Einführen eines Timeouts für NEC-Repetition-Frames, um
>    "Geisterkommandos" zu verhindern.
[...]

Funktioniert einwandfrei :-)

> Viel Spaß,
>
> Frank

Vielen Dank für den schnellen Bugfix.

Viele Grüße,
Frank

von jar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
puh alles durchgelesen,

nur habe ich das mit dem Widerholungsflag noch nicht gesehen

kein loslassen, Lautstärke Helligkeit geht ja mit repeat, aber bei 
Programmwahl wäre das ja unglücklich, ergo muss das Bit loslasen 
interpretieren

ist da schon was eingebaut ?

IRMP ist erstmal geil, bin schon am nachbauen,

Probleme bereitet mit bis jetzt nur der heftige Aufwand (für mich)

entweder, Neubau, + Codeumschreibung, denn im Prinzip liegen hier 2(3) 
Geräte mit mega644(32), TSOP1736, LCD, LED, Triber für LCD HG-LED und 
Taster

alle Codes zeigen auf einen mega 88 der einzige Plan (den ich bis jetzt 
gefunden hatte) aber auf einen mega 168

klar könnte ich aus dem Code für mega 88 die Ports ohne Plan extrahieren

da meine HW quasi schon fast steht mal eben die beiden Codes und Quellen 
verheiratet, was aber logisch schief ging, ich nutze halt timer1 für die 
LCD HG LED per pwm OCRA und OCRB für den Kontrast

Ziel ist es aber nach Dekodierung meiner pansonic FB einen FB Sender zu 
generieren der per PC aktiviert wird, über VNC meinen HD Recorder 
fernzuprogramieren, aber da ich nicht noch mehr IR Sendedioden frei 
plazieren möchte, was ist mit IR zu RF 433 MHz Umsetzung, 433 Empfänger 
und IR Sender sind vorhanden, da die ja auf alle FB reagiren vermute ich 
die Trägerfrequenz 30 - 40 kHz ist denen egal, morsen die in 433 Mhz nur 
das an und aus der IR LED ?, wie könnte man ein RF(m?) 12 Modul den 
Transmitter dafür nutzen ?

hier gibt es ja Beispiele für Atmel atmel mit Sender und Empfänger, also 
per seriell Umsetzung, aber ich weiss nicht ob es digital oder analog 
ist was da gesendet wird, habe so eine Funk FB mal belaucht mit dem Oszi 
und Empfängermodul, aber nur Grundrauschen bekommen oder Störsignale, 
weiss aber nicht ob die 433 Module dafür gehen.


wenn sich dazu jemand äussern kann würde mich freuen,

den PC als fernbedienten IR/433 MHz Sender zu nutzen aus dem ganzen 
I-Net muss doch mehr interessieren ?

Rückmeldung der Programmierung geht natürlich toll per winTV und den HD 
Rec am AV Modulator ins Subkabelnetz gespeist, muss also auf dem PC nur 
winTV starten, den HDrec Kanal einstellen und schon kann ich alles 
programmieren, mit 433 MHz brauch ich nicht mal ne Sichtverbindung PC 
HDrec (das macht die IR Pyramide)

von jar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
so
1 Nachbau läuft mit 644 intern 8MHz

meine panasonic DVD wird als KASEIKYO erkannt

nur warum die Tasten OFF (2002/3d0) und TV OFF (2002/3d0) denselben Code 
bringen obwohl 2 getrennte Tasten ist mir noch unklar

loggen kann ich (noch) nicht, kein Maxim spendiert und keine Ahnung wie 
ich das dem PC erkläre

erst mal das Prototypeboard auf Akku umstellen und heim alle FB testen

von jar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
alle in Urlaub ? oder sind meine Fragen zu doof ?

egal, noch ein Versuch

so nun verschiedenste FB durchprobiert

Samsung wird als solche erkannt
drei Panasonic als Kaseikyo

nur alle OFF Knöpfe bringen den selben Code (2002/3d0)

aber natürlich reagieren die Geräte nicht so

VHS off Kaseikyo 2002/3d0 nur der VHS geht aus
HDrec off Kaseikyo 2002/3d0 nur der HDrec geht aus
TV off Kaseikyo 2002/3d0 weder der HDrec noch der VHS geht aus

alle RC5 FB zeigen im IRMP nix an (interner 8MHz), dabei geht "meine" 
andere Schaltung mit 8 MHz Quarz und Fleury RC5 Lib wohl

wo soll ich nun suchen ?

Jitter ? auf 8 MHz Quarz umstricken ?
internen auf 8 MHz kalibrieren (keine Ahnung wie das geht) meine andere 
Idee, einfach an den Teilern drehen bis 1s Blink LED 1s auf dem Oszi 
wird ?

1s soll ja nach 10000 ISR aufrufen vergangen sein

ergo lasse ich eine uint16 VAR immer wieder von 0-10000 laufen

in ISR wird uint16 VAR++
in main auf uint16 VAR >= 10000 abgefragt und 0 gesetzt und LED Bit xor 
gesetzt

muss ja 1s Puls / Pause rauskommen

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
so, mal wieder angemeldet das ich Antworten per mail bekomme

danke

gruss
jar

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
jar schrieb:
>
> 1s soll ja nach 10000 ISR aufrufen vergangen sein
>
> ergo lasse ich eine uint16 VAR immer wieder von 0-10000 laufen
>
> muss ja 1s Puls / Pause rauskommen

Kommando zurück, man sollte RC5 auch enabeln

hatte ich schon mal dann aber neu angefangen und vergessen

wer also noch Codes braucht kann sich ja melden, ich versuche dann den 
Max nachzurüsten und aufzuzeichnen

und suche immer noch ne Lösung für 433 MHz send statt IR (das IR 
überlasse ich den IR Pyramiden)

hat schon jemand IRSND am PC zu USB mit Atmel ?

wenn hier keiner ne bessere Idee hat nehme ich einen Atmal als USB zu 
rs232 Umsetzer und frickel da IRSND ein, ggffs mit 433 MHz Modul

von Joachim B. (jar)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
puh, schwerer als gedacht

also die JVC RM C085 wird nicht erkannt, obwohl JVC unter Nec als RC5 
geführt wird, aus dem TSOP1736 kommt schönes Signal raus so das ich die 
Frequenz erst mal nicht vermessen hab,

Interrupt auf 15k hochgesetzt hat nix gebracht, den Rest nicht 
verschlechtert aber der JVC nicht geholfen.

Der Oszi liefert schönen Stream sieht aber dem RC5 der erkannt wird 
nicht ähnlich

Anlage in der Zip:
ein PIC vom Oszi
hardcopy -> Ref1 ist unbekannte JVC und Ref2 ist bekannte Pinnacle RC5

und die Daten als 2x CSV (JVC-FB und Pinnacle FB RC5) und einmal zu XLS 
umgesetzt

ich hoffe das Projekt lebt noch und sind alle nur in Urlaub

ich mache mich nun an die 433 MHz Umsetzung und hoffe weiter auf 
Antworten auf meine Fragen

liebe gruesse
jar

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
jar schrieb:

> meine panasonic DVD wird als KASEIKYO erkannt

Prima.

> nur warum die Tasten OFF (2002/3d0) und TV OFF (2002/3d0) denselben Code
> bringen obwohl 2 getrennte Tasten ist mir noch unklar

Beim Kaseikyo-Protokoll (48 Bit!) werfe ich sämtliche CRCs raus. 
Vielleicht etwas zuviel...

Aktiviere bitte IRMP_LOGGING und schicke mir die Scan-Dateien. Dann 
werde ich den Unterschied schon finden.

> loggen kann ich (noch) nicht, kein Maxim spendiert und keine Ahnung wie
> ich das dem PC erkläre

Du startest einfach ein Terminal-Emulationsprogramm (z.B. HyperTerm) und 
speicherst die Ausgabe.

jar schrieb:

> alle in Urlaub ? oder sind meine Fragen zu doof ?

Ja, bis gestern :-)

> Samsung wird als solche erkannt

Gut.

> drei Panasonic als Kaseikyo

Auch gut.

> nur alle OFF Knöpfe bringen den selben Code (2002/3d0)

Wie gesagt: ich brauche die Scans dazu.

> alle RC5 FB zeigen im IRMP nix an (interner 8MHz), dabei geht "meine"
> andere Schaltung mit 8 MHz Quarz und Fleury RC5 Lib wohl

Scan schicken. Vielleicht haben wir hier nur eine zu starke Abweichung 
vom RC5-Timing.

> Jitter ? auf 8 MHz Quarz umstricken ?

Quarz ist auf jeden Fall gut. Bitte auch hier die Scan-Datei schicken, 
dann kann ich Dir mehr sagen.

> internen auf 8 MHz kalibrieren (keine Ahnung wie das geht) meine andere
> Idee, einfach an den Teilern drehen bis 1s Blink LED 1s auf dem Oszi
> wird ?

IRMP ist vom Timing her ziemlich tolerant. Bist Du sicher, dass Dein 
Timer mit der richtigen Frequenz läuft? Zeigst Du bitte mal die Passagen 
Deiner Timer-Initialisierung?

Joachim B. schrieb:

> Kommando zurück, man sollte RC5 auch enabeln

RC5 geht also jetzt?

> wer also noch Codes braucht kann sich ja melden, ich versuche dann den
> Max nachzurüsten und aufzuzeichnen

Ja, wäre nicht schlecht.

> und suche immer noch ne Lösung für 433 MHz send statt IR (das IR
> überlasse ich den IR Pyramiden)

Du meinst die 433 MHz-Sender/Empfänger von Pollin, die RFM12?
Sag mal genau, was Du willst. Sowas vielleicht:

         IR               Funk
IR-FB ---------> RFM12 ---------> RFM12 ------> Und was dann????


> hat schon jemand IRSND am PC zu USB mit Atmel ?

Meines Wissens nicht. Nur IRMP zu USB, siehe

Beitrag "USB IR Remote Receiver (V-USB + IRMP)"

> wenn hier keiner ne bessere Idee hat nehme ich einen Atmal als USB zu
> rs232 Umsetzer und frickel da IRSND ein, ggffs mit 433 MHz Modul

Male bitte mal ein Schaubild, ich verstehe nicht ganz, was Du vorhast.

Joachim B. schrieb:

> also die JVC RM C085 wird nicht erkannt, obwohl JVC unter Nec als RC5
> geführt wird, aus dem TSOP1736 kommt schönes Signal raus so das ich die
> Frequenz erst mal nicht vermessen hab,

Bitte Scan schicken.

> Anlage in der Zip:
> ein PIC vom Oszi

Nützt mir nichts.

> hardcopy -> Ref1 ist unbekannte JVC und Ref2 ist bekannte Pinnacle RC5

Nützt mir nichts.

> und die Daten als 2x CSV (JVC-FB und Pinnacle FB RC5) und einmal zu XLS
> umgesetzt

Nützt mir nichts.

> ich hoffe das Projekt lebt noch und sind alle nur in Urlaub

Jau :-)

> ich mache mich nun an die 433 MHz Umsetzung und hoffe weiter auf
> Antworten auf meine Fragen

Siehe oben.

Gruß,

Frank

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
hmmm, schade das die die CSV Dateien nix nutzen
jede Zeile ist 10µs also ist bei Zeile 70 der Wechsel bei 700 µs und so 
weiter, ist das für dich nicht lesbar ?

ist Exelformat und die XLS ist schon zu µs umgesetzt

oszi zu CSV oder XLS ist halt schneller als HW bauen

ich verstehe auch nicht manche Kommentare im Quellcode

mal wird JVC als RC5 bezeichnet mal als NEC aber hier steht was anderes
http://www.sbprojects.com/knowledge/ir/jvc.htm

JVC unterscheidet in 1 und Null bits zu 1 ms und 2 ms und das sehe ich 
auf dem Oszi, aber im Quellcode nicht ???

ich dachte auch mein JVC hat zu große Abweichung im Timing, aber ! 1ms 
und 2ms sind nahezu exakt nur warum werden die nicht erkannt ?

also wenn es nicht anders geht muss ich den MAX wohl noch nachrüsten

433 MHz

Ziel ist es später im PC den Code nicht auf eine IR Diode auszugeben 
sondern statt IR Diode auf einen 433 MHz Sender ähnlich den 
Funkfernedienungen oder der FB Transmitter (IR Empfänger - Funkstrecke 
433 MHz - IR Sender)

da zwei 433 MHz Empfänger mit IR Sendedioden schon im Zimmer stehen wäre 
es doch schön wenn der PC den IR Code statt in IR zu senden 433 MHz 
senden würde, dann spart man sich die PC IR Sendediode Ausrichtung zu 
den Geräten. ausgerichtet sind die Pyramiden ja schon

Ziel des ganzen, per PC den HD Recorder zu programmieren, auch übers 
I-Net (VNC)

war der Urlaub schön ?

liebe gruesse
achim

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> hmmm, schade das die die CSV Dateien nix nutzen
> jede Zeile ist 10µs also ist bei Zeile 70 der Wechsel bei 700 µs und so
> weiter, ist das für dich nicht lesbar ?

Es muss nicht für mich, sondern für IRMP lesbar sein, ich analysiere die 
Scans mit IRMP unter Linux, siehe auch Artikel:

  http://www.mikrocontroller.net/articles/IRMP#IRMP_unter_Linux_und_Windows

Du kannst natürlich Deine XLS-Dateien wieder ins IRMP-Format umwandeln, 
das geht so: für jede zehntausendstel Sekunde schreibst Du eine 1, wenn 
der Empfänger aus war, für jede zehntausendstel Sekunde schreibst Du 
eine 0, wenn der Empfänger aktiv war. Das gibt dann eine Folge von 0en 
und 1en in einer langen Zeile z.B. so:

000000011111111111111000111000111.....

Davor schreibst Du noch einen Kommentar:

# OFF-Taste TV
000000011111111111111000111000111.....
# OFF-Taste VCR
000000011111111111111000111000111.....

> ist Exelformat und die XLS ist schon zu µs umgesetzt

Nützt mir nichts. IRMP "versteht" halt nur das IRMP-Format selbst.

> oszi zu CSV oder XLS ist halt schneller als HW bauen

Naja, einen MAX232 dranbauen ist auch nicht soooo schwierig.

> ich verstehe auch nicht manche Kommentare im Quellcode

Welche?

> mal wird JVC als RC5 bezeichnet mal als NEC aber hier steht was anderes
> http://www.sbprojects.com/knowledge/ir/jvc.htm

JVC ist nicht notwendigerweise RC5 oder NEC. JVC ist einfach ein 
Hersteller, der verschiedene IR-Protokolle verwendet. Meist jedoch NEC.

> JVC unterscheidet in 1 und Null bits zu 1 ms und 2 ms und das sehe ich
> auf dem Oszi, aber im Quellcode nicht ???

Schau Dir im IRMP-Artikel folgende Tabelle an:

  http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail_2

Da sind alle Timings der von IRMP unterstützten Protokolle aufgeführt.

Im Quellcode findest Du diese Timings wieder in irmp.h. Sie sind in der 
Header-Datei, da sie auch von IRSND verwendet werden.

> ich dachte auch mein JVC hat zu große Abweichung im Timing, aber ! 1ms
> und 2ms sind nahezu exakt nur warum werden die nicht erkannt ?

Wie gesagt: Scan-Datei hilft weiter.

> also wenn es nicht anders geht muss ich den MAX wohl noch nachrüsten

Jepp :-)

> Ziel ist es später im PC den Code nicht auf eine IR Diode auszugeben
> sondern statt IR Diode auf einen 433 MHz Sender ähnlich den
> Funkfernedienungen oder der FB Transmitter (IR Empfänger - Funkstrecke
> 433 MHz - IR Sender)

Also:

        IR                        Funk                        IR
IR-FB -----> RFM-Sender mit IRMP -----> RFM-Empf. mit IRSND ------> 
fernzubedienendes Gerät

Geht mit IRSND, siehe IRMP-Artikel.

Das einzige, was fehlt, ist der Code für die RFM-Module. Aber da gibt es 
ja hier im Forum genügend Quellcode, wo man sich bedienen kann.

Gruß,

Frank

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Sag mal genau, was Du willst. Sowas vielleicht:

         IR               Funk
IR-FB ---------> RFM12 ---------> RFM12 ------> Und was dann????


so ähnlich,

wenn der Atmel oder PC erst mal alle KASEIKYO Codes kennt soll der PC 
diese senden (notfalls über den Umweg eines Atmels)

aber es soll KASEIKYO nicht in IR gesendet werden, sondern in 433 MHz 
und ja ich denke an die RM12 Module, diese senden dann ungerichtet vom 
PC auf die Empfängerpyramiden die das dann zu IR Strahlung gerichtet 
umsetzen bis zum HD Recorder

Kaseikyo Code von PC (ggffs mit Hilfe eines ATMEGA) als 433 MHz an 
Funkempfängerpyramide - in IR an HDrec
PC kaseikyo Code ---------> RFM12 ---------> Funkempfängerpyramide 
------> IR ------> HD Rec

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> Ziel des ganzen, per PC den HD Recorder zu programmieren, auch übers
> I-Net (VNC)

Dann würde doch folgendes reichen:

USB-to-RS232 -> MAX232 -> AVR

Den USB-to-RS232-Wandler bekommst Du überall für ein paar Euros 
nachgeworfen. Dann kannst Du über die COM-Schnittstelle Befehle an den 
AVR senden. Dort läuft IRSND, welcher die Befehle per IR-LED wieder 
aussendet.

Anregungen findest Du vielleicht hier:

  http://www.klaus-leidinger.de/mp/Mikrocontroller/IR-LCD/IR-LCD.html

> war der Urlaub schön ?

Danke, oft über 40°C und viel Sonne :-)

Gruß,

Frank


P.S.
Ausgerechnet Kaseikyo unterstützt IRSND (das Gegenstück zu IRMP) noch 
nicht. Könnte sich aber ändern, wenn ich genügend "Futter" in Form von 
Scans bekomme ;-)

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Joachim B. schrieb:
>> Ziel des ganzen, per PC den HD Recorder zu programmieren, auch übers
>> I-Net (VNC)
>
> Dann würde doch folgendes reichen:
>
> USB-to-RS232 -> MAX232 -> AVR

>> war der Urlaub schön ?
> Danke, oft über 40°C und viel Sonne :-)
> Gruß,
> Frank
>
> P.S.
> Ausgerechnet Kaseikyo unterstützt IRSND (das Gegenstück zu IRMP) noch
> nicht. Könnte sich aber ändern, wenn ich genügend "Futter" in Form von
> Scans bekomme ;-)

also da denke ich eher an:
http://www.embedded-projects.net/index.php?page_id=135

mit
http://www.embedded-projects.net/index.php?page_id=160

da habe ich etwas mitgewirkt (Platinengröße für USB Stickgehäuse), der 
kann auch als USB zu RS232 Umsetzer arbeiten (über virtcom Treiber) und 
statt den Code als RS232 auzugeben wird das Kommando direkt als KASEIKYO 
ausgegeben (mittels IRSND an 433 MHz)

Ich muss dann eben die RS232 Schnitte nachrüsten in meinem IRMP (seufs 
geht nicht wirklich leicht auf dem Steckbrett, muss wohl erst ne Platine 
schnitzen) damit ich dich mit KASEIKYO Codes füttern kann

dann ist da noch das 433 MHz Problem, senden empfangen mag ja in den 
RS232 Atmel Funkstrecken gehen, ist aber digital, meine Versuche eine 
China Funk FB (Cam RF Remote Auslöser , Canon Pentax, alle nach dem 
selben Prinzip, 4 DIP für Sende/Empfang an Cam mit kleinen Handsender 
mit Stabantenne) zu belauchen mit den Modulen war erfolglos, scheint mir 
analog zu sein....

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Du kannst natürlich Deine XLS-Dateien wieder ins IRMP-Format umwandeln,
>
> das geht so: für jede zehntausendstel Sekunde schreibst Du eine 1, wenn
>
> der Empfänger aus war, für jede zehntausendstel Sekunde schreibst Du
>
> eine 0, wenn der Empfänger aktiv war. Das gibt dann eine Folge von 0en
>
> und 1en in einer langen Zeile z.B. so:
>
>
>
> 000000011111111111111000111000111.....
>
>
>
> Davor schreibst Du noch einen Kommentar:
>
>
>
> # OFF-Taste TV
>
> 000000011111111111111000111000111.....
>
> # OFF-Taste VCR
>
> 000000011111111111111000111000111.....
>
>
>
>> ist Exelformat und die XLS ist schon zu µs umgesetzt
>
>
>
> Nützt mir nichts. IRMP "versteht" halt nur das IRMP-Format selbst.
>
>
>
>> oszi zu CSV oder XLS ist halt schneller als HW bauen
>
>
>
> Naja, einen MAX232 dranbauen ist auch nicht soooo schwierig.


zu umwandeln, low aktiv oder high aktiv ?

in Ruhe kommen 5V aus dem TSOP 1736 wenn IR Signale erkannt werden 
wechselt es zu low


also 1 = 0 ? und 0 = 1 ?

dem MAX anbauen ist schwierig, weil 1. kein max232 in der Kiste, aber in 
der Datenbank, aber max233 in der Kiste aber nur SMD und da muss ich 
löten, dito macht sub-d in dem steckbrett keinen sinn und in smd hab ich 
den nicht, also muss ich max233 auf SMD und dann auf Lochraster mit 
SUB-D verheiraten bevor es ans Steckbrett geht, ist schon nicht trivial 
für mich mit meene ollen ogen :|

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> zu umwandeln, low aktiv oder high aktiv ?

low aktiv, also genau so, wie sie aus dem TSOP rauskommen.

Gruß,

Frank

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
so, ich baue grad mit dem max233 auf (murphy, natürlich habe ich den nur 
als SO und in der LBR gibt es den nur in DIL und die SO Variante hat 
andere Pinbelegung, deswegen erst mal Symbol und Dev in Eagle bauen, 
mann mann mann, das Leben könnte doch einfacher sein)

kann jemand kurz sagen wozu der Taster ist vergessen ? :o (Plan von Hr. 
Leidinger ?)

und warum muss Vcc an Ri ?

mit den Datenrichtungen DTE / DCE komme ich regelmäßig durcheinander

wer ist hier eigendlich was ? ich denke mal Atmel spielt Modem und 
betrachte ihn als DCE und nicht als DTE

glücklicherweise scheint bis jetzt im Plan alles zu stimmen

liebe gruesse
jar

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> kann jemand kurz sagen wozu der Taster ist vergessen ? :o (Plan von Hr.
> Leidinger ?)

gefunden bootloader, SW nachladen, kann also raus,
bleibt also die Frage:

> und warum muss Vcc an Ri ?


liebe gruesse
jar

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> bleibt also die Frage:
>> und warum muss Vcc an Ri ?

Wovon redest Du? Vom Pullup am Reset-Pin in der Schaltung von Klaus 
Leidinger?

Gruß,

Frank

von Joachim B. (jar)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Joachim B. schrieb:
>
>> bleibt also die Frage:
>>> und warum muss Vcc an Ri ?
>
> Wovon redest Du? Schaltung von Klaus Leidinger?
>
> Gruß,
>
> Frank

ja schrieb ich das nicht ?

bald kann ich scans von den FB loggen, dann schick ich alles was ich an 
FB finde

liebe gruesse
jar

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
und nun ? ich wusste ich hasse logging

#ifndef IRMP_LOGGING
#define IRMP_LOGGING                            1       // 1: log IR 
signal (scan), 0: do not (default)
#endif


ich verstehe logging auf 1 ?

steht ja auch da, 1 log IR


aber dann :

  #if IRMP_LOGGING == 0
  // USART initialization has to be done here if Logging is off
  // Communication Parameters: 8 Data, 1 Stop, No Parity
  // USART Receiver: Off
  // USART Transmitter: On
  // USART0 Mode: Asynchronous
  // USART Baud Rate: 9600
  #define BAUDRATE 9600L
  UCSR0A=0x00;
  UCSR0B=0x08;
  UCSR0C=0x06;
  UBRR0H = ((F_CPU+BAUDRATE*8)/(BAUDRATE*16)-1) >> 8;            // 
store baudrate (upper byte)
  UBRR0L = ((F_CPU+BAUDRATE*8)/(BAUDRATE*16)-1) & 0xFF;
  #endif


also wird das UART init wenn logging off ?

nix verstehen.....


bei build gibt:

../irmp.c:645: error: 'U2X' undeclared (first use in this function)

    UART0_UCSRA &= ~(1<<U2X);

ich finde die DEF von U2X nirgends ,

wo gehört sie wie hin ?

danke (sorry das ich blöd bin, ist immer schwer sich in fremden code 
zurechtzufinden und mit dem uart hab ich noch nie im atmel gearbeitet, 
tippe da muss irgendwo ein init vergessen sein)

liebe grüße jar

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
so uart ausgabe läuft,

irgendwie uart.c und .h vergessen

da der at644 irgendwie nicht drin lief eben ein paar defs geändert

egal läuft

nur com terminal spuckt nix aus

aber hterm aber mit sonderzeichen


nun weiss ich leider immer noch nicht wie ich mitloggen soll

entweder es ist zu dünne erklärt oder ich bin unfähig....


blicke grad nicht durch warum com terminal nix zeigt aber hterm und 
welches pc log prgramm laufen muss und unter xp laufen kann, mal eben 
linus booten ist grad nicht möglich und den rücken verdrehen zum anderen 
rechner auch nicht so lang sind meine kabel nicht

gruss
jar

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> aber hterm aber mit sonderzeichen

Du musst hterm auf 9600 Bd 8 Bit no Parity stellen.

> entweder es ist zu dünne erklärt oder ich bin unfähig....

Da ich von den IRMP-Anwendern bereits Dutzende Scan-Dateien erhalten 
habe, sollten die Erklärungen im IRMP-Artikel eigentlich reichen ;-)

Gruß,

Frank

von Joachim B. (jar)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
so

versuch mal dein Glück bitte

wenn das erfolgreich ist scanne ich alle Tasen und mher FBs

ich glaube meine Schaltung spinnt noch ein bissl,
nicht so leicht scans einzufangen wenn irgendjemand
irgendwo auf die FB drückt,
muss wohl in ein dunkles Zimmer ohne Fenster
und ohne IR Pyramiden,
die fangen sich offensichtlich auch was ein

lg
jar

: Wiederhergestellt durch Moderator
von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb im Beitrag #1813217:
> so ?
> 11111111111111111110000......

Klasse, Du hast es geschafft, dass die Fensterbreite dieses Threads 
enorm gewachsen ist ;-)

Wäre wohl besser, den Beitrag zu löschen, sonst muss man zum Antworten 
erstmal eine halbe Stunde scrollen...

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> versuch mal dein Glück bitte

Habe es mir eben mal kurz angeschaut: Der Scan ist mit 15kHz 
aufgezeichnet worden... hättest Du auch sagen können ;-)

> nicht so leicht scans einzufangen wenn irgendjemand
> irgendwo auf die FB drückt,
> muss wohl in ein dunkles Zimmer ohne Fenster
> und ohne IR Pyramiden,
> die fangen sich offensichtlich auch was ein

Allerdings... die erste Zeile ist nur ein Fragment, die kann man nur in 
die Tonne stopfen. Die anderen 3 Zeilen sind brauchbar, allerdings hat 
sich da in die zweite Zeile neben eines Kaseikyo-Frames auch noch ein 
kompletter SAMSUNG32-Frame mit reingeschmuggelt. Ausserdem ist da auch 
noch ab und an anderer Schrott zwischendurch zu sehen.

Ich muss Deine Scans erstmal ein wenig säubern, bevor ich da näheres 
erkenne. Besser wäre es allerdings, mit 10kHz zu scannen (reicht für 
Kaseikyo vollkommen aus) und wirklich dafür zu sorgen, dass keine 
anderen IR-Sender dazwischenfunken.

Gruß,

Frank

von Joachim B. (jar)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Joachim B. schrieb im Beitrag #1813217:
>> so ?
>> 11111111111111111110000......
>
> Klasse, Du hast es geschafft, dass die Fensterbreite dieses Threads
> enorm gewachsen ist ;-)
>
> Wäre wohl besser, den Beitrag zu löschen, sonst muss man zum Antworten
> erstmal eine halbe Stunde scrollen...
>
> Gruß,
>
> Frank

ich hab versucht zu löschen, geht nicht, ist mir ja auch peinlich, aber 
ich wollte kein Umbrüche drin haben

ich habe den Beitrag gemeldet, wenn ein Mod bitte diesen löscht !

kannst du mit den Scans was anfangen ?

hier noch mal

alle meine FB
die Kaseikyo würde ich scannen wenn du sagst du kannst sie auswerten, 
muss ich dann wirklich alle Tasten scannen ? ist ein Haufen Arbeit

warum wird die JVC immer noch nicht erkannt ? der Code sollte doch drin 
sein ?

habe mal jvc dazugelinkt

von Joachim B. (jar)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> habe mal jvc dazugelinkt

hat nicht geklappt, neuer versuch

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> ich habe den Beitrag gemeldet, wenn ein Mod bitte diesen löscht !

Ich hatte ihn auch schon gemeldet ;-)

> kannst du mit den Scans was anfangen ?

Ja, habe ein Ergebnis. Die beiden verschiedenen OFF-Tasten bringen 
folgende 48 Daten-Bits:
         1         2         3         4
123456789012345678901234567890123456789012345678
010000000000010000001101000000001011110010110001 p =  5, a = 0x2002, c = 0x03d0, f = 0x00
010000000000010000000001000000001011110010111101 p =  5, a = 0x2002, c = 0x03d0, f = 0x00
ccccccccccccccccPPPPssssppppppppffffffffCCCCCCCC

IRMP ermittelt daraus jeweils die Adresse 0x2002 und das Kommando 
0x03d0. Tatsächlich unterscheiden sich aber die 48 Bits genau an 4 
Stellen, nämlich Bit21-22 und Bit45-46.

Dabei haben die 48 Bits folgenden Aufbau:

c = 16 Hersteller (customer) Bits
P = 4 Parity Bits
s = 4 System-Bits
p = 8 Produkt-Bits
f = 8 Funktions-Bits
C = 8 Datenüberprüfungs-Bits

Der signifikante Unterschied der beiden Tasten liegt in den 4 
System-Bits, die von IRMP bisher komplett ignoriert wurden - einfach, 
weil ich dafür keine genauen Infos herausgefunden habe, was diese Bits 
genau bedeuten. Dass IRMP überhaupt Datenbits bei Kaseikyo ignoriert, 
hat einen einfachen Grund: Ich muss die 48 bit irgendwie in 16 Adress- 
und 16 Kommando-Bits pressen. Ich muss mir also überlegen, wie ich die 4 
Systembits da noch unterbringe. Gib mir also bitte etwas Zeit ;-)

> alle meine FB
> die Kaseikyo würde ich scannen wenn du sagst du kannst sie auswerten,
> muss ich dann wirklich alle Tasten scannen ? ist ein Haufen Arbeit

10 Tasten reichen. Bitte aber nicht einfach nur die Zahlen 0-9 ;-)

> warum wird die JVC immer noch nicht erkannt ? der Code sollte doch drin
> sein ?

Ich werde mir den JVC-Scan anschauen. Ist der auch mit 15kHz gescannt?

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:

> Ich werde mir den JVC-Scan anschauen.

Das Ding benutzt zwar die NEC-Timings, das Protokoll ist aber komplett 
anders aufgebaut: Nach jeweils 16 der insgesamt 50 Bits wird eine 
längere Pause von ca. 22msec eingelegt. Ausserdem scheinen die Daten 
(die nur eine Länge von 16 Bit haben) insgesamt 2x wiederholt zu werden.

Also ist der Aufbau:

 1 NEC-Start-Bit
16 Daten-Bits
 1 Stop-Bit + Pause (Synchronisation?)
16 Daten-Bits
 1 Stop-Bit + Pause (Synchronisation?)
16 Daten-Bits

Näheres kann ich Dir erst sagen, wenn Du mich mit mehr JVC-Scans 
versorgst.

Gruß,

Frank

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> 10 Tasten reichen. Bitte aber nicht einfach nur die Zahlen 0-9 ;-)

mach ich nach Wunsch oder Querbeet ?


Frank M. schrieb:
> Frank M. schrieb:
>
>> Ich werde mir den JVC-Scan anschauen.
>
> Das Ding benutzt zwar die NEC-Timings,...
> Gruß,
> Frank


auch das, s.o.
mach ich nach Wunsch oder Querbeet ?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> mach ich nach Wunsch oder Querbeet ?

Querbeet - halt die Tasten, die Du für am wichtigsten erachtestest. Wäre 
nicht schlecht, wenn die Nummerntasten 0, 1, 2 dabeiwären, da kann man 
meist gut eine Systematik ablesen.

Gruß,

Frank

von Joachim B. (jar)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Joachim B. schrieb:
>> mach ich nach Wunsch ?
>
> Querbeet - halt die Tasten, die Du für am wichtigsten erachtestest. Wäre
> nicht schlecht, wenn die Nummerntasten 0, 1, 2 dabeiwären, da kann man
> meist gut eine Systematik ablesen.
> Gruß,
> Frank

so getan, aber nicht alle 10er Tasten 1-5 jeweils doppelt

ich hoffe ich habe mich nicht ver C&P und verguckt

ich sehe Jitter ? oder Frequenzabweichung, da ich ja doppelt gescant 
hatte erwarte ich 1 und 0 immer fast gleich, mal eine mehr oder weniger 
muss dann Jitter sein ? oder Frequenzabweichung ?

so ich werde dann mal das 128 x 64 gLCD anfrickeln mit LED Beleuchtung
jetzt hängt ja nur das 4x20 Z dran unbeleuchtet

wenn dir Scans fehlerhaft scheinen oder fehlen, bitte sofort melden, 
schick ich dann nach

die pana VCR FB fehlt mir noch, muss ich nachreichen, habe nur noch 3 
Tage Zugriff drauf

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> ich sehe Jitter ? oder Frequenzabweichung,

Ich sehe da zwischendurch viel Schrott, auch mal zwischendurch 
Samsung32-Frames. Ausserdem sind da bei den ersten paar Tasten 
unerklärliche Zeilenumbrüche drin. Funkt da was dazwischen?

Hatte ich auch heute vormittag in

Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"

geschrieben.

Bitte ausschließen, dass Deine "Pyramiden" dazwischenfunken und bitte 
auch die Scan-Frequenz auf 10kHz zurückschrauben. 15kHz sind hier nicht 
notwendig und verlängert die Scans unnötig.

Gruß,

Frank

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Bitte ausschließen, dass Deine "Pyramiden" dazwischenfunken und bitte
> auch die Scan-Frequenz auf 10kHz zurückschrauben. 15kHz sind hier nicht
> notwendig und verlängert die Scans unnötig.
> Gruß,
> Frank

die heutigen scans ohne OFF Taste ohne Störungen von den Pyramiden, die 
sind daheim (die zuvor gescanten OFF Tasten hab ich aber reinkopiert um 
Arbeit zu sparen)

auf 10kHz umgestellt, nach Durchsicht der config brauche ich die wohl 
nicht

IRMP_SUPPORT_FDC_PROTOCOL
IRMP_SUPPORT_RCCAR_PROTOCOL
IRMP_SUPPORT_SIEMENS_PROTOCOL
IRMP_SUPPORT_RECS80_PROTOCOL
SUPPORT_RECS80EXT_PROTOCOL

Siemens könnte evt. noch kommen, dann wird man sehen

>15kHz sind hier nicht
> notwendig und verlängert die Scans unnötig.
> Gruß,
> Frank

aber hilft das nicht der Genauigkeit der Auswertung, weniger 
Jitterfehler ?

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Allerdings... die erste Zeile ist nur ein Fragment, die kann man nur in
> die Tonne stopfen. Die anderen 3 Zeilen sind brauchbar, allerdings hat
> sich da in die zweite Zeile neben eines Kaseikyo-Frames auch noch ein
> kompletter SAMSUNG32-Frame mit reingeschmuggelt. Ausserdem ist da auch
> noch ab und an anderer Schrott zwischendurch zu sehen.
> Gruß,
> Frank

das hatte ich wohl überlesen,

ist halt doof wenn Frau beim Scan der Panasonic die Samsung bedient weil 
sie lauter oder leiser haben will (ich hatte vesucht aufzupassen, 
klappte wohl nicht immer) ausserdem sehe ich ab und an unmotiviert die 
IR Pyramiden blinken, war wohl keine gute Idee die alten scans 
dazuzulinken, OK und 15 kHz hatte ich verschwiegen, aber du findest 
offensichtlich alle Gemeinheiten die dir die User wohl unterjubeln (ohne 
Absicht)

also wie gesagt,

auf 10 kHz ist umgestellt (immer noch die Frage, wäre für Scan nicht 15 
kHz genauer?)
IR Pyramiden sind nicht hier und @work kann kein weiteres IR Signal 
stören, ausser Schmutz auf der Versorgungsleitung oder 
Maschineninduktion, hier sind schon irgendwo heftige Stanzen zu hören, 
aber wo die sind habe ich noch nicht rausgefunden, so ein Stahlbetonbau 
lääst die Gräusche zwar weit durch aber schlecht ortbar

ich sanne neu bei Bedarf

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> auf 10 kHz ist umgestellt

Gut.

> (immer noch die Frage, wäre für Scan nicht 15 kHz genauer?)

Nein, 10kHz reicht bei Deinen FBs vollkommen aus.

> ich sanne neu bei Bedarf

Ich baue erstmal die angekündigten Änderungen für Kaseikyo ein 
(Berücksichtigung der 4 System-Bits) und implementiere das 
JVC-Protokoll. Da wäre es aber klasse, wenn Du mir von der JVC ein paar 
10kHz-Scans liefern würdest.

Gruß,

Frank

von Joachim B. (jar)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ich baue erstmal die angekündigten Änderungen für Kaseikyo ein
> (Berücksichtigung der 4 System-Bits)

super DANKE dafür ! und bitte bitte IRSND nicht vergessen darauf kommt 
es ja hauptsächlich an (Ziel nicht aus den Augen verlieren will)

>und implementiere das
> JVC-Protokoll. Da wäre es aber klasse, wenn Du mir von der JVC ein paar
> 10kHz-Scans liefern würdest.

klaro das hat Zeit ist weniger für mich mehr für alle deren FB nicht 
mehr geht

ich hoffe ich habe keine copy paste Fehler drin

(einige scans waren zu lang und dann läuft hterm leicht über, im scroll 
fenster und man erwischt den anfang nicht)

heute frisch gescant 10 kHz ohne IR Pyramiden

#Sondertasten (VCR/DVD play rec usw.) unter Schiebeklappe bitte nicht 
noch auch, nur wenn die Not gross ist :-)

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> heute frisch gescant 10 kHz ohne IR Pyramiden

Die Scans sehen sehr gut aus. Die Abweichungen (Jitter) sind normal, die 
FBs senden nicht soooo genau. Ausserdem kommt schon durch das Pollen in 
der ISR ein Fehler von +/- 1 zustande. IRMP arbeitet aber mit 
Toleranzen, deshalb ist das überhaupt nicht tragisch.

Ich kümmere mich erstmal um Kaseikyo, dann melde ich mich wieder.

Gruß,

Frank

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ich kümmere mich erstmal um Kaseikyo, dann melde ich mich wieder.
> Gruß,
> Frank

fein morgen scanne ich alle meine Panasonic FB Kaseikyo neu
VCR NV FJ630 VHS
TV TX-L32S10ES
DVD/HDrec Panasonic DMR-EX 79

10 kHz ohne IR Pyramidenstörungen

von Joachim B. (jar)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ich baue erstmal die angekündigten Änderungen für Kaseikyo ein
> (Berücksichtigung der 4 System-Bits)
> Gruß,
> Frank

brauchst du noch was ?

hier die KASEIKYO Panasonic VCR FB

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Die Scans sehen sehr gut aus. Die Abweichungen (Jitter) sind normal,
> Gruß,
> Frank

das wundert mich nun etwas,

sagte ich nicht das an dem MAX nur +5 und NULL rauskamen ?

nun nachdem ich den Schluss unter dem SMD PAD (MAX233 9 GND nach 10 
irgendein int. Kondi) gefunden hatte habe ich jetzt endlich +-10V

aber wenn die Scans schon vorher gut waren soll das nicht weiter stören

von Michael H. (michael_h45)


Bewertung
0 lesenswert
nicht lesenswert

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> hier die KASEIKYO Panasonic VCR FB

Danke, habe ich mir angeschaut, leider sind nur 161 von 216 Scans okay. 
55 Scans weisen einen abweichenden Herstellercode auf, welcher für 
Panasonic 0x2002 ist. Ist die Datei auch schon mit dem MAX-Kurzschluss 
erstellt worden?

Macht nix, der Rest ist echt brauchbar.

Achja, noch eine Bitte: Beim Scannen bitte immer die Tasten so kurz wie 
möglich drücken. Beim JVC-Scan hast Du da offenbar des öfteren ziemlich 
lange den Finger auf den Tasten gehabt - jedenfalls zu Anfang bei den 
ersten Tasten ;-)

Dank und Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Michael H. schrieb:
> http://de.wikipedia.org/wiki/Jitter

Ja, und? Ist hier die Bezeichnung "Jitter" falsch, wenn es um
Messabweichungen von Rechtecksignalen wie bei den folgenden geht?
1. Messung: 000000000000000111111111000000000011111111110000000
2. Messung: 000000000000000011111111100000000111111111100000000
3. Messung: 000000000000001111111110000000000011111111110000000

Trotzdem danke für den interessanten Link.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ich baue erstmal die angekündigten Änderungen für Kaseikyo ein
> (Berücksichtigung der 4 System-Bits) und implementiere das
> JVC-Protokoll.

Anbei die geänderten Sources zum Test.

Neu:

 - Kaseikyo: es werden nun die 4 System-Bits (Genre2) im Frame
   ausgewertet

 - Neues Protokoll: JVC

Viel Spaß,

Frank

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Joachim B. schrieb:
>> hier die KASEIKYO Panasonic VCR FB
>
> Danke, habe ich mir angeschaut, leider sind nur 161 von 216 Scans okay.
> 55 Scans weisen einen abweichenden Herstellercode auf, welcher für
> Panasonic 0x2002 ist.

hmm, welche ?, könnte die ja nachliefern, hast ja die #Headerzeile dazu

>Ist die Datei auch schon mit dem MAX-Kurzschluss
> erstellt worden?

ja leider, wollte erst liefern, dann hat mich der Pegel doch nicht ruhen 
lassen und ich ging auf Fehlersuche

> Macht nix, der Rest ist echt brauchbar.
> Achja, noch eine Bitte: Beim Scannen bitte immer die Tasten so kurz wie
> möglich drücken. Beim JVC-Scan hast Du da offenbar des öfteren ziemlich
> lange den Finger auf den Tasten gehabt - jedenfalls zu Anfang bei den
> ersten Tasten ;-)
> Dank und Gruß,
> Frank

na ja man wartet immer auf Bestätigung, ich hab ne LED Quittung 
eingebaut, 1s LED Blink wenn Code erkannt, nur im Logging Mode erkennt 
er ja nix und ich warte vergebens und im HTERM kommen die Daten 
offensichtlich erst verzögert, also bleib ich zu lang drauf und dann 
wollen die Daten nicht enden

einige Tasten sind auch versenkt um Fehlbedienungen zu meiden, deren 
Druckpunkt ist schwer zu fühlen

ich weiss, alles Ausreden, aber wer so lange im Beruf ist der kann wohl 
nicht anders

danke und gruß zurück
jar

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Frank M. schrieb:
> Ich baue erstmal die angekündigten Änderungen für Kaseikyo ein
> (Berücksichtigung der 4 System-Bits)
> Neu:
>  - Kaseikyo: es werden nun die 4 System-Bits (Genre2) im Frame
>    ausgewertet

hmm, aber scheinbar noch etwas wackelig (muss ich mir meine 
Abblockkondis ansehen oder meine 5V Versorgung ?), wenn die FB nicht 
genau ausgerichtet ist und man nicht lange drückt erkennt er viele 
Zufallscodes, ist nicht so stabil wie RC5, da kenne ich nur ja / erkannt 
oder nein / eben nicht, aber Zufallscodes seh ich nie


> und implementiere das
> JVC-Protokoll.
>  - Neues Protokoll: JVC
ah, erst verwundert, wird nicht angezeigt, dann aber

meine JVC wird erkannt , A + C wird angezeigt aber unter Code nicht JVC 
!

> Viel Spaß,
> Frank

danke den hab ich schon

von Michael H. (michael_h45)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ja, und? Ist hier die Bezeichnung "Jitter" falsch, wenn es um
> Messabweichungen von Rechtecksignalen wie bei den folgenden geht?
Nein, nicht bei dir.
Nur bei Joachim klang es danach, dass er damit die 
Spannungs-Sonderheiten wegen seiner MAX-Beschaltung meinte.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> meine JVC wird erkannt ,

Gut.

> A + C wird angezeigt

Auch gut.

> aber unter Code nicht JVC

Den Satz verstehe ich nicht. Hast Du im main() eine Text-Ausgabe über 
ein Text-Array drin und vermisst nun das Wörtchen "JVC"? Das gehört 
nicht wirklich zu den IRMP-Sources dazu, denn:

irmp_get_data liefert lediglich

   uint8_t protocol
   uint16_t address
   uint16_t command

protocol hat den Wert 20 bei JVC, siehe irmp.h, da sind alle Protokolle 
drin.

Du müsstest bei Deiner Textausgabe das Text-Array auf 20 vergrößern und 
dort den String "JVC" eintragen.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> hmm, aber scheinbar noch etwas wackelig (muss ich mir meine
> Abblockkondis ansehen oder meine 5V Versorgung ?), wenn die FB nicht
> genau ausgerichtet ist und man nicht lange drückt erkennt er viele
> Zufallscodes, ist nicht so stabil wie RC5,

Was für einen IR-Empfänger nutzt Du? TSOP1736 oder 1738? Das Problem 
ist, dass Kaseikyo mit 56 kHz moduliert wird und der TSOP mit seinen 
36kHz bzw. 38kHz ziemlich daneben liegt. Die Entfernung sinkt drastisch 
und die Fehlerquote nimmt zu.

Gruß,

Frank

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Den Satz verstehe ich nicht. Hast Du im main() eine Text-Ausgabe über
> ein Text-Array drin und vermisst nun das Wörtchen "JVC"? Das gehört
> nicht wirklich zu den IRMP-Sources dazu, denn:
>
> irmp_get_data liefert lediglich
>
>    uint8_t protocol
>    uint16_t address
>    uint16_t command
> protocol hat den Wert 20 bei JVC, siehe irmp.h, da sind alle Protokolle
> drin.
> Du müsstest bei Deiner Textausgabe das Text-Array auf 20 vergrößern und
> dort den String "JVC" eintragen.
> Gruß,
> Frank

sowas dachte ich schon, nur hab ich die Zuweisung nicht gefunden

aber nun

static char 
*Proto[]={"SIRCS","NEC","SAMSUNG","MATSUSH","KASEIKYO","RECS80","RC5(x)" 
,"DENON","RC6","SAMSG32","APPLE","RECS80x","NUBERT","JVC"};

> Du müsstest bei Deiner Textausgabe das Text-Array auf 20 vergrößern

wie das ich finde nirgends eine Zuweisung von Array auf 20

soweit wie ich C gelernt habe ist durch anhängen von ,"JVC" das Array 
schon ab compile vergrößert, da es ja statisch initialisiert wird, eine 
seperate Zuweisung dürfte nicht (nötig) sein und finde ich auch nicht

hmm es funzt jedenfalls noch nicht

ich tippe auf NEC erkannt und JVC eben nicht

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Was für einen IR-Empfänger nutzt Du? TSOP1736 oder 1738? Das Problem
> ist, dass Kaseikyo mit 56 kHz moduliert wird und der TSOP mit seinen
> 36kHz bzw. 38kHz ziemlich daneben liegt. Die Entfernung sinkt drastisch
> und die Fehlerquote nimmt zu.
> Gruß,
> Frank


TSOP 1736 , aber mein Scan an einer BPW21 lieferte 36 kHz Schwingungen

ich könnte ja noch mal einen OP vorschalten und eine FFT machen

gruss
jar

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
peinlich peinlich

sind ja nur 14 Text STR definiert, hab nicht nachgezählt

musste also 6x "", einfügen das 20 auf "JVC" zeigt ......

ja ich bin aus der Übung und sehe nicht immer alles (sofort)

gruss
jar

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> aber nun
>
> static char
> *Proto[]={"SIRCS","NEC","SAMSUNG","MATSUSH","KASEIKYO","RECS80","RC5(x)" 
,"DENON","RC6","SAMSG32","APPLE","RECS80x","NUBERT","JVC"};

Du hast "JVC" an 14. Stelle statt an 20. Stelle eingetragen, damit das 
Array auch nur auf 14 Elemente vergrößert.

>
>> Du müsstest bei Deiner Textausgabe das Text-Array auf 20 vergrößern
>
> wie das ich finde nirgends eine Zuweisung von Array auf 20

Eben, die Dimension von Proto[] ist nicht angegeben.

> hmm es funzt jedenfalls noch nicht

Trage alle fehlenden Namen ein (die einzelnen nicht zu lang machen!) und 
sorge dafür, dass "JVC" an 20. Stelle steht, siehe Nummern der 
Protokolle 1-20 in irmp.h.

Gruß,

Frank

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Eben, die Dimension von Proto[] ist nicht angegeben.
> Trage alle fehlenden Namen ein (die einzelnen nicht zu lang machen!) und
> sorge dafür, dass "JVC" an 20. Stelle steht, siehe Nummern der
> Protokolle 1-20 in irmp.h.
> Gruß,
> Frank


hatte ich doch schon,

Joachim B. schrieb:
> peinlich peinlich
> sind ja nur 14 Text STR definiert, hab nicht nachgezählt
> musste also 6x "", einfügen das 20 auf "JVC" zeigt ......
> ja ich bin aus der Übung und sehe nicht immer alles (sofort)
> gruss
> jar



ich denke ich werde trotzdem noch mal einen Frequenz Scan aller FB 
machen

wie geschrieben mit BPW21 OP und FFT
und mal alle meine FB scannen

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Das Problem ist, dass Kaseikyo mit
>> 56 kHz
> moduliert wird und der TSOP mit seinen 36kHz bzw. 38kHz
> ziemlich daneben liegt.
> und die Fehlerquote nimmt zu.
> Gruß,
> Frank

wo hast du die Daten her ?

ich kann hier machen was ich will

ich messe burst von 26-28 µs was 35,9 - 38,5 kHz gibt

übrigens alle
>> meine Kaseikyo liegen eher bei 36 kHz ,
nur die JVC scheint um 38 kHz zu liegen

bin verwirrt von deinen 56 kHz

gruss
jar

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> bin verwirrt von deinen 56 kHz

Laut
http://www.mikrocontroller.net/attachment/4246/IR-Protokolle_Diplomarbeit.pdf

auf Seite 26 (hier "Japan-Code" genannt) sind es 56 kHz. Da habe ich das 
her.

Aber es gibt noch eine zweite Quelle, nach welcher ich das 
Kaseikyo-Protokoll implementiert habe, nämlich:

http://www.roboternetz.de/phpBB2/files/entwicklung_und_realisierung_einer_universalinfrarotfernbedienung_mit_timerfunktionen.pdf

Und tatsächlich wird hier von 38kHz (auf Seite 8) geredet. Entweder 
werden verschiedene Modulationsfrequenzen bei Kaseikyo eingesetzt oder 
meine erste Quelle hat schlichtweg einen Fehler. Leider habe ich 
persönlich keine Kaseikyo-kompatible FB, kann daher nix dazu sagen.

Leider habe ich auch nicht mehr Doku als diese beiden Quellen. Wenn Du 
da noch irgendeine Doku ausgraben könntest, würde ich mich freuen.

Gruß,

Frank

von Wolfgang Dunczewski (midi-rakete) (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich lese oben, dass es Probleme gibt/gab mit dem Code einer Kathrein 
UFS-922 Fernbedienung. Wurde das Problem gelöst? Ich habe beim Bau einer 
FB diesen Code enträtselt.....

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
ach ja , vergessen

irgendwer schrieb mal was von 450 kHz IR Modulation, aber ich bin nicht 
sicher ob das so stimmt, weil :

einige modilieren auch mit x-facher Frequenz wegen oversampling

da können die paar 100 kHz auch vielfache von 36 oder 38 - 40 oder 56 
kHz sein

ggffs kann man später mal in IRSND oversampling einstellen und schauen 
was aus den TSOP rauskommt, ich vermute mit exakt doppelter oder gerade 
Vielfache werden die auch output liefern.......

gruss
jar

von Samuel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> peinlich peinlich
Spiegelt deinen Auftritt hier gut wieder.
Du hast mal von jar nüscht Ahnung.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Samuel schrieb:
> Joachim B. schrieb:
>> peinlich peinlich
> Spiegelt deinen Auftritt hier gut wieder.
> Du hast mal von jar nüscht Ahnung.

danke danke, von nüscht würde ich nüscht sagen.....

OK ich bin nicht so der Softi und aus der Übung

aber war der Kommentar nötig ?

na egal wer anonym so was schreibt braucht das wohl

ich komm schon klar, hab halt nicht die Arrays ausgezählt

wer so perfekt ist wie du kann sich anmelden und auch besser Fragen 
beantworten und zum Rest höflich schweigen....

freundlichen gruss
jar

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Wolfgang Dunczewski (midi-rakete) schrieb:
> Ich lese oben, dass es Probleme gibt/gab mit dem Code einer Kathrein
> UFS-922 Fernbedienung. Wurde das Problem gelöst?

Nein, die Kathrein benutzt einen RC6-Mode, der nicht oder nur spärlich 
dokumentiert ist. IRMP unterstützt nur den sog. Mode 0 von RC6, siehe 
auch:

http://www.sbprojects.com/knowledge/ir/rc6.htm

> Ich habe beim Bau einer FB diesen Code enträtselt.....

Dann schieß mal los.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> http://www.sbprojects.com/knowledge/ir/ir.htm

Keine Infos zum Kaseikyo-Protokoll.

> http://www.hifi-remote.com/forums/viewtopic.php?t=6401

Keine Infos zum Kaseikyo-Protokoll.

> 
http://www.hifi-remote.com/forums/viewtopic.php?t=12233&sid=cdf5a421a7ecc165af055f6555019261

Keine Infos zum Kaseikyo-Protokoll.

> http://www.google.de/url?sa=t&source=web&cd=6&ved=0CEMQFjAF&url=http%3A%2F......

Nette Tabelle, aber keine Infos zum Kaseikyo-Protokoll selbst.

> http://usa.denon.com/AVR-4308CI_IRCodes.pdf

Dito.

> sehr interessant:
> http://ecee.colorado.edu/~mcclurel/vishay_ir_data_formats.pdf

Danke, immerhin steht da drin, dass Kaseikyo mit 36.7kHz moduliert wird. 
Werde ich im IRMP-Artikel anpassen.

> Kaseikyo 56 kHz muss ein Fehler sein, finde nix, ausser beim Klaus

Der hat es wahrscheinlich von mir....

Insgesamt ist Deine Liste nicht so der Renner, trotzdem danke dafür.

Vielleicht hättest Du Dir vorher mal die Literatur-Hinweise aus dem 
IRMP-Artikel angucken sollen, um entsprechend auszufiltern und nicht 
jeden Google-Treffer einfach hier reinzukopieren ;-)

http://www.mikrocontroller.net/articles/IRMP#Literatur


Gruß,

Frank

von Wolfgang Dunczewski (midi-rakete) (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Nein, die Kathrein benutzt einen RC6-Mode, der nicht oder nur spärlich..
>
> http://www.sbprojects.com/knowledge/ir/rc6.htm
>
>> Ich habe beim Bau einer FB diesen Code enträtselt.....
>

Ich fand im Web Infos über den RC-6 Mode 6A 20:

[[http://www.guiott.com/wrc/RC6-6.html]]

mit 20 Bit Nutzrate

Die Kathrein nutzt "in etwa" diesen als 32 Bit Version (RC-6 mode 6a 
32), aber nicht nach Norm:

Die FB vom UFS-922 macht folgendes:

Leader Pulse (ok)
Start Bit (ok)
Mode Bits 2,1,0 (H,H,L = Mode 6)
Trailer Bit: Flanke immer L>H (nicht offiziell, soll normal toggeln)

Dann folgen 4 Bytes:

Das erste Byte ist immer 10000000 (von links nach rechts wird gesendet)
Das zweite Byte ist immer 01000110

Das dritte Byte enthält das Toggle-Bit TB und
die Ebene/Adresse falls man mehrere FBs hat

TB AD2 AD1 AD0 0000

also normal bei Adresse 0:

10000000
und abwechselnd
00000000

Eigenlich gehört das Togglebit an eine andere Stelle. Das Trailer Bit 
soll eigentlich toggeln. Aber Kathrein lässt ein Bit togglen. Deshalb 
funtioniert fast keine programmierbare FB mit dem Kathrein.

Und im 4. Byte kommen die Befehe 00-FF

nnnnnnnn

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Wolfgang Dunczewski (midi-rakete) schrieb:

> Die Kathrein nutzt "in etwa" diesen als 32 Bit Version (RC-6 mode 6a
> 32), aber nicht nach Norm:
> [...]

Vielen Dank für die Infos, werde ich mir mal zu Gemüte führen.

Gruß,

Frank

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
>> Joachim B. schrieb:
>> sehr interessant:
>> http://ecee.colorado.edu/~mcclurel/vishay_ir_data_formats.pdf
>
> Danke, immerhin steht da drin, dass Kaseikyo mit 36.7kHz moduliert wird.
> Werde ich im IRMP-Artikel anpassen.

> Insgesamt ist Deine Liste nicht so der Renner, trotzdem danke dafür.
> Vielleicht hättest Du Dir vorher mal die Literatur-Hinweise aus dem
> IRMP-Artikel angucken sollen, um entsprechend auszufiltern und nicht
> jeden Google-Treffer einfach hier reinzukopieren ;-)
> Gruß,
> Frank

immerhin hab trotzdem noch was gefunden, sorry das es mir nicht möglich 
war alle Infos mit den vorhandenen abzugleichen, ich hab hier grad Land 
unter und bin deswegen nur sehr begrenzt konzentriert dabei, ich hoffe 
das geht trotzdem i.O.

gruss
jar

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Vielen Dank für die Infos, werde ich mir mal zu Gemüte führen.
> Gruß,
> Frank

hallo,

wie siehts aus mit KASEIKYO im IRSND ?

würde dann bald ein IRSND Modul aufbauen für

PC -> RS232 -> Atmel IRSND -> IS Sendediode

ich grübel gerade ob der Umweg über Atmel sein muss weil,

kennst du den CT Artikel IRDEO ?
http://www.heise.de/ct/projekte/Fernregie-IRdeo-284185.html
http://irdeo.de/

dort wurde IR Empfang und Senden mit der seriellen Schnitte gemacht, 
funzte so leidlich (sogut win das eben zulässt) mit W2k und XP musste 
der IO (giveio o.ä.) Treiber installiert werden
http://irdeo.de/ntdriver.zip
GIVEIO.SYS (Dale Roberts), LOADDRV (Paula Tomlinson)


senden war übrigens tricky, die IR Modulation 36  38  40 kHz wurde per 
Baudrate / respektive geschickte 1/0 Wahl eingestellt, je nach 1/0 Folge 
und Baudrate ist ja quasi jede IR Modulation machbar, die Start oder 
Stoppbits, wenn sie einzeln erfolgen, scheinen nicht zu stören

leider war es nur eine lernbare FB welche die Codes nur gelernt wieder 
abspielen konnte und mit der Erkennung haperte es leider auch, da ist 
dein Projekt viel weiter und besser, aber ggffs kann man die beiden 
Konzepte zusammenbringen

für mich wäre ja nur IR Sender nötig wenn ich das ohne Atmel am RS232 
Port erreiche spart das Arbeit und Geld (nix gegen die Atnelbastelleien)

freundliche Grüße
jar

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> wie siehts aus mit KASEIKYO im IRSND ?

Wie ich schon schrieb: dafür brauche ich Futter, damit ich sämtliche 
Paritätsbits aus den Daten wieder erzeugen kann. Nur so kann ich die 32 
Bit IRMP-Datenstruktur auf die vollen 48bit-Kaseikyo-Frames aufblasen.

Ich warte daher immer noch auf die Scan-Dateien Deiner 3 
Kaseikyo-Fernbedienungen, die Du mir schon vor ein paar Tagen 
angekündigt hattest.

Ich brauche von jeder dieser 3 FB ca. 10 Tasten, wie ich schon mal 
schrieb.

Du hattest hier mal für die Panasonic VCR FB Scans reingestellt, wo aber 
noch erhebliche Störungen drin waren. Du hattest den Grund wohl gefunden 
und wolltest den Scan wiederholen. Bisher hab ich da aber nix neues von 
Dir gesehen.

> kennst du den CT Artikel IRDEO ?

Ja, habe ich mal vor Jahren überflogen.

> für mich wäre ja nur IR Sender nötig wenn ich das ohne Atmel am RS232
> Port erreiche spart das Arbeit und Geld (nix gegen die Atnelbastelleien)

Sorry, wüsste ich jetzt nicht, wie. Du kannst natürlich den IRSND-Code 
auf eine andere Plattform portieren.

Gruß,

Frank

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Joachim B. schrieb:
>> wie siehts aus mit KASEIKYO im IRSND ?

> Wie ich schon schrieb: dafür brauche ich Futter, damit ich sämtliche
> Paritätsbits aus den Daten wieder erzeugen kann. Nur so kann ich die 32
> Bit IRMP-Datenstruktur auf die vollen 48bit-Kaseikyo-Frames aufblasen.
>
> Ich warte daher immer noch auf die Scan-Dateien Deiner 3
> Kaseikyo-Fernbedienungen, die Du mir schon vor ein paar Tagen
> angekündigt hattest.
>
> Ich brauche von jeder dieser 3 FB ca. 10 Tasten, wie ich schon mal
> schrieb.
>
> Du hattest hier mal für die Panasonic VCR FB Scans reingestellt, wo aber
> noch erhebliche Störungen drin waren. Du hattest den Grund wohl gefunden
> und wolltest den Scan wiederholen. Bisher hab ich da aber nix neues von
> Dir gesehen.
> Gruß,
> Frank


war wohl ein Missverständniss

auf die VCR FB hab ich nun kein Zugriff mehr, ich hab noch im Ohr, sind 
zwar Störungen drin aber brauchbar

Frank M. schrieb:
> Joachim B. schrieb:
>> hier die KASEIKYO Panasonic VCR FB
>
> Danke, habe ich mir angeschaut, leider sind nur 161 von 216 Scans okay.
> 55 Scans weisen einen abweichenden Herstellercode auf, welcher für
> Panasonic 0x2002 ist. Ist die Datei auch schon mit dem MAX-Kurzschluss
> erstellt worden?
>
> Macht nix, der Rest ist echt brauchbar.
> Dank und Gruß,
> Frank

die 161 scans reichen nicht von der VCR ?

Ich kann also nur noch
Panasonic TV liefern und Panasonic HDrec/DVD

muss mal sehen ob ich den VCR noch mal bekomme

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> die 161 scans reichen nicht von der VCR ?

Wenn es diese FB ist, welche Du über IRSND auch emulieren willst - ja, 
dann reicht es.

> Ich kann also nur noch
> Panasonic TV liefern und Panasonic HDrec/DVD

Wenn Du die für IRSND nicht brauchst, dann nicht. Wäre aber trotzdem 
nett, wenn Du davon jedoch auch noch je 10 Scans machen könntest, dann 
kann ich das allgemeiner in IRSND machen.

Sag mir bitte auch, welche FB Du mit IRSND emulieren möchtest.

Gruß,

Frank

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Sag mir bitte auch, welche FB Du mit IRSND emulieren möchtest.
> Gruß,
> Frank

eigendlich genau diese

Panasonic HDrec/DVD

und die sollst du noch mal bekommen

zur Fernprogrammierung über PC


TV hat ja aus der Ferne irgendie keinen Sinn, da könnte ich gleich winTV 
im Rechner starten

ich hab den IRMP so schön auf 4x MiMh Akku laufen, damit wäre mobiles 
logging auch für den VCR möglich, aber seit der MAX dranhängt läuft der 
TSOP nicht mehr, der MAX braucht 1W sind 200mA und zieht offensichtlich 
den Pegel runter, ohne externe Versorgung geht da leider nix

ich grübel gerade ob ich den MAX rausschmeisse und einfach mit 2 Trasis, 
simple RS232 Konverter baue
http://picprojects.org.uk/projects/simpleSIO/ssio.htm

1W ist schon heftig
alternativ ginge ja die RS232 anzuzapfen, einige Dioden nach P5 sollte 
wieder mehr Strom liefern, DTR und RTS kann man ja setzen, nur auf + 
setzen , sollten ja ungefähr je 20mA liefern können

so ähnlich hatte ich auch meine PONY Elektronik aus der parallelen 
gespeist, einfach 15 BAT42 an jede signalführende Leitung auf einen 
Pufferkondi, reicht für CMOS Logik und Signal LED 3mA

von Joachim B. (jar)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Halbzeit

versucht alle Tasten je 2x zu scannen, Tastendruck so kurz wie möglich

musste leider im logging CR LF einfügen, ich hoffe das stört nicht

morgen verm. den Rest

freundliche Grüße
jar

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> versucht alle Tasten je 2x zu scannen, Tastendruck so kurz wie möglich

Sehr sauberer Scan: keine Störungen, keine Erkennungsfehler. Bei der 
Gelegenheit habe ich erkannt, dass bei Kaseikyo auch bei kurzen 
Tastendrücken immer mindestens zwei Frames verschickt werden. Bei 
längeren Tastendrücken werden drei Frames und mehr gesandt. Ich hatte 
das bisher zwar schon immer vermutet, hatte aber da noch nie geeignete 
Kaseikyo-Scans.

Ich muss da im IRMP bzgl. Kaseikyo noch nacharbeiten: die erste 
Wiederholung des Frames muss unterdrückt werden. Erst alle weiteren 
Wiederholungsframes sind als langer Tastendruck auszuwerten. Sonst 
bekommt man immer einen langen Tastendruck zurück - auch wenn man die 
Taste nur kurz gedrückt hat.

> musste leider im logging CR LF einfügen, ich hoffe das stört nicht

Passt perfekt.

Wann ich das Enkodieren in den IRSND einbaue, kann ich Dir noch nicht 
genau sagen. Habe im Moment viel um die Ohren.

Gruß,

Frank

von Joachim B. (jar)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
so der 2te Teil

viel Erfolg mit den CRC

gruss
jar

von Joachim B. (jar)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ich muss da im IRMP bzgl. Kaseikyo noch nacharbeiten: die erste
> Wiederholung des Frames muss unterdrückt werden. Erst alle weiteren
> Wiederholungsframes sind als langer Tastendruck auszuwerten. Sonst
> bekommt man immer einen langen Tastendruck zurück - auch wenn man die
> Taste nur kurz gedrückt hat.

gibt es da keine Toggel Bits wie in RC5 ? dort klappt das hervorragend 
mit der Toggelbitauswertung, habe meinen Timer ja mit

Peters RC5 gebaut
Beitrag "Fernbedien RC5 Empfänger"

da klappt das einfach mit toogle Bit auswerten, muss ja nicht erkennen 
ob lang oder kurz

> Wann ich das Enkodieren in den IRSND einbaue, kann ich Dir noch nicht
> genau sagen. Habe im Moment viel um die Ohren.
> Gruß,
> Frank

OK danke erst Mal, ich bekomm ja Bescheid wenn du hier weiterbist und 
postest

viel um die Ohren, wer nicht ;-) (wenn du wüsstest)

gruss
jar

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> gibt es da keine Toggel Bits wie in RC5 ?

Nein, gibt es nur in RC5, RC6 und RECS80. In den anderen 17 Protokollen, 
die IRMP "versteht", gibt es kein Toggle-Bit. Dort gibt es u.a. 
alternative Mechanismen wie zum Beispiel Repetition-Frames (NEC). 
Kaseikyo hat hier nichts, hier arbeite ich mit Timeouts, um längere 
Tastendrücke von X-maligen Tastendrücken zu unterscheiden.

>> Wann ich das Enkodieren in den IRSND einbaue, kann ich Dir noch nicht
>> genau sagen. Habe im Moment viel um die Ohren.
> OK danke erst Mal, ich bekomm ja Bescheid wenn du hier weiterbist und
> postest

Bin doch schon fertig damit. Ich lade hier gleich den Test-Source hoch.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Anbei die geänderten Sources (gegenüber der Download-Version) mit 
verbesserter Unterstützung des Kaseikyo-Protokolls als Test-Version.

Änderungen IRMP
---------------

- Kaseikyo-Protokoll:
  Unterschiedliche Behandlung des 1. Wiederholungsframes (kein langer
  Tastendruck) von nachfolgenden Wiederholungsframes (langer
  Tastendruck).

- Kaseikyo-Protokoll:
  Auswertung der 4 + 8 = 12 "Parity-Bits", um Empfangsfehler zu
  erkennen.

Änderungen IRSND
----------------

- Unterstütrung des Kaseikyo-Protokolls inkl. Parity- und Genre1-Bits.
- Keine Unterstützung der Genre2-Bits beim Kaseikyo-Protokoll

Schwächen
---------

Das Kaseikyo-Protokoll enthält von den 48 Bit insgesamt 36 
Nutzdatenbits. Da die IRMP-Datenstruktur nur 32 Bits (16 Adresse, 16 
Kommando) davon speichern kann, gehen leider 4 Bits verloren. Dabei 
handelt es sich um die sog. Genre2-Bits, die aber meist 0000 sind.

Relevant kann diese Schwäche beim Senden per IRSND werden, da dann die 
Codes einiger bestimmter Tasten (wie MENÜ und OK bei Panasonic) nicht 
gesandt werden können.

Abhilfe könnte hier die Erweiterung der IRMP-Datenstruktur um ein neues 
Byte namens "product" bringen. Muss ich nochmal nachdenken, ob ich das 
einbaue. Wahrscheinlich wird es im nächsten Release enthalten sein.

Gruß,

Frank

von Dirk W. (dirkw)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ist IRMP eigentlich mit der neuen Apple Remote (Unibody) kompatibel?

Hab mir gestern eine gekauft und wollte sie in meinem aktuellen Projekt 
verwenden; funktionierte aber leider nicht. Keinerlei Reaktion von IRMP.

Einen Debug Trace der Apple Remote habe ich mal angehängt (Trace enthält 
noch eine Taste einer anderen FB zum Vergleich), sowie einen 
aufbereiteten Oszilloskop-Mitschnitt.

CU Dirk

von Klaus L. (kllei)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Dirk,

diese Seite: http://en.wikipedia.org/wiki/Apple_remote
lässt darauf schliessen das beide gleich sind.
Laut Apple Seite ist die Unibody Remote mit allen Produkten nach 2005 
eingeführt wurden kompatibel, was nicht das gleiche ist...

Ich hatte die alte (Plastik) FB mit dem iPod 5 Generation getestet, der 
im Oktober 2005 vorgestellt wurde, hatte funktioniert. Diese scans waren 
auch die "Referenz" für Frank. (falls nicht jemand neue scans geliefet 
hat).

Ich glaube dem Wiki Artikel und bin sicher das beide Remote das gleiche 
Protokoll haben.

HTH,
Klaus

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Dirk W. schrieb:

> Hab mir gestern eine gekauft und wollte sie in meinem aktuellen Projekt
> verwenden; funktionierte aber leider nicht. Keinerlei Reaktion von IRMP.

Ich habe mir gerade den Scan angeschaut. Das Timing ist NEC- und 
APPLE-kompatibel, allerdings verwendet Deine APPLE-FB eine andere ID als 
die APPLE-FB von Klaus - nämlich genau da, wo NEC eigentlich die Bits 
nochmal invertiert ausgibt.

Das ist ein Klacks, die neue ID in den IRMP einzubauen. Mache ich am 
Wochenende.

Gruß,

Frank

von Dirk W. (dirkw)


Bewertung
0 lesenswert
nicht lesenswert
Hi,

Danke Frank :-).


Hab gerade mal ein bisschen gesucht und beim LIRC Projekt folgendes
gefunden:

http://lirc.sourceforge.net/remotes/apple/A1294

> pre_data        0x77E1
> UP                       0x50
> DOWN                     0x30
> LEFT                     0x90
> RIGHT                    0x60
> PLAY                     0xFA
> MENU                     0xC0
> OK                       0x3A


Das würde dem von mir ausgelesenen Protokoll entsprechen.
Scheinbar hat Apple wohl verschiedene Codes in seinen Produkten
hinterlegt.

Wünsche ein schönes WE...


CU Dirk

von Klaus L. (kllei)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> APPLE-kompatibel, allerdings verwendet Deine APPLE-FB eine andere ID als
> die APPLE-FB von Klaus - nämlich genau da, wo NEC eigentlich die Bits
> nochmal invertiert ausgibt.

Laut der lirc Seite sind die Adressen von alter und neuer FB gleich, nur 
die Kommandos der Tasten unterscheiden sich:
http://lirc.sourceforge.net/remotes/apple/A1156
http://lirc.sourceforge.net/remotes/apple/A1294

Allerdings stimmen die "Lirc" Werte der alten FB mit der Wiki Seite 
überein, wenn man LSB berücksichtigt.

Ich habe noch mal meine Aufzeichnungen gecheckt, die alte FB wurde von 
IRMP ebenfalls mit Adresse 0x77E1 erkannt,
0x87EE (von der Wiki Seite) in LSB gelesen ergibt 0x77E1

Ach ja, die "alte" FB gibt es wohl auch erst seit Oktober 2005, das 
hatte ich überlesen.
Mal wieder raffiniert gemacht von A**le...

Grüße,
Klaus

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Hat schon jemand IRMP und IRSND in ethersex eingebaut?

von Graf-von-Socke (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo und supper Arbeit.

So weit leuft alles bei mir mit dem einlesen der codes. Aber die 
Ferbedinung von der XBOX 360 macht schwierwigkeiten.Egal welche Taste 
ich drücke kommt immer der Code

irmp_data.protoco =9
irmp_data.address =0
irmp_data.command =31

Vieleicht kann mir von euch Jemand helfen

danke

Graf-von-Socke

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:

> Das ist ein Klacks, die neue ID in den IRMP einzubauen. Mache ich am
> Wochenende.

Habe gerade mal IRMP an den APPLE-Scan angepasst.

@Dirk:

Ersetze bitte die Zeile:
    else if ((irmp_command & 0xFF00) == 0xD100)

durch
    else if ((irmp_command & 0xFF00) == 0xD100 || (irmp_command & 0xFF00) == 0x4600)

in irmp.c. Dann sollte die FB erkannt werden.

Ich werde das aber anders im nächsten IRMP-Release implementieren. Das 
Problem ist nämlich, dass beide FBs dieselbe NEC-Adresse (0x87ee) haben, 
aber eine unterschiedliche ID verwenden. Damit dann später auch IRSND 
APPLE-Frames versenden kann, welche beide (und auch weitere!) APPLE-FBs 
unterstützt, werde ich zukünftig die bisher von IRMP zurückgegebene 
Adresse 0x87ee ersetzen durch die ID. Das wäre dann bei der FB von Klaus 
die 0xD100 und bei Dirk die 0x4600. Nur so kann eine IRMP-Anwendung auch 
beide APPLE-FBs auseinanderhalten. Daher bitte den obigen Patch erstmal 
als Test/Notlösung sehen...

Die korrekte Fassung kommt dann am Sonntag.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Graf-von-Socke schrieb:

> So weit leuft alles bei mir mit dem einlesen der codes. Aber die
> Ferbedinung von der XBOX 360 macht schwierwigkeiten.Egal welche Taste
> ich drücke kommt immer der Code
>
> irmp_data.protoco =9
> irmp_data.address =0
> irmp_data.command =31

IRMP glaubt da anhand des Timings einen RC6-Code zu empfangen. Ich 
glaube aber nicht, dass Microsoft tatsächlich einen von Philips 
entwickelten Code verwendet, sondern (wie so oft) sich etwas eigenes 
ausgedacht hat.

> Vieleicht kann mir von euch Jemand helfen

Da helfen nur Scans. Wie Du diese erstellen kannst, steht im 
IRMP-Artikel:

  http://www.mikrocontroller.net/articles/IRMP

Gruß,

Frank

von Graf-von-Socke (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo hier ist nein Scan ergbis fielicht finden sie etwas


gruß

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Graf-von-Socke schrieb:
> Hallo hier ist nein Scan ergbis fielicht finden sie etwas

Danke, scheint ein simpler 32-Bit-Code zu sein. Zwei Tasten reichen da 
aber nicht, ich bräuchte schon so um die 10 Tasten-Scans, um da auch 
eine Struktur zu erkennen. Dann kann ich das in den IRMP integrieren.

Noch als Tipp:
Bitte vor und hinter jedem Kommentar eine neue Zeile beginnen und den 
Kommentar selbst mit dem #-Zeichen einleiten, also:

# Die X Taste
000000000000000000000000000000000000000000000000001111...
# Die Play Taste
000000000000000000000000000000000000000000000000001111...

Ist der Scan mit 10kHz aufgenommen worden?

Gruß,

Frank

von Graf-von-Socke (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ok werde ich morgen abend nochmal durchführen
habe was nettes im Internet gefunden fielicht hilft das weiter


........................................................................ 
..
lircd.conf für USB-Empfänger (MCEUSB2)

# this config file was automatically generated
# using lirc-0.8.0-CVS(mceusb2) on Tue Jan 17 15:14:11 2006
#
# contributed by Kyle at shadowmage.org
#
# brand: Microsoft
# model no. of remote control: Xbox 360 Universal Media Remote
# devices being controlled by this remote: Xbox 360
#
# This probably works for the normal Xbox 360 remote too.
#
# TV button sends no signal and toggles Xbox 360/TV mode. TV mode can be
# signals for any device the remote supports. Volume Up, Volume Down and
# Mute always use the TV mode while the Xbox live guide button always 
sends
# to the xbox.

begin remote

  name  Microsoft_Xbox360
  bits           16
  flags RC6|CONST_LENGTH
  eps            30
  aeps          100

  header       2676   870
  one           454   429
  zero          454   429
  pre_data_bits   21
  pre_data       0x37FF0
  gap          106291
  min_repeat      1
  toggle_bit      0

  rc6_mask    0x100000000

      begin codes
          OpenClose                0x8BD7
          XboxFancyButton          0x0B9B
          OnOff                    0x8BF3
          Stop                     0x0BE6
          Pause                    0x8BE7
          Rewind                   0x0BEA
          FastForward              0x8BEB
          Prev                     0x0BE4
          Next                     0x8BE5
          Play                     0x0BE9
          Display                  0x8BB0
          Title                    0x0BAE
          DVD_Menu                 0x8BDB
          Back                     0x0BDC
          Info                     0x8BF0
          UpArrow                  0x0BE1
          LeftArrow                0x8BDF
          RightArrow               0x0BDE
          DownArrow                0x8BE0
          OK                       0x0BDD
          Y                        0x8BD9
          X                        0x0B97
          A                        0x8B99
          B                        0x0BDA
          ChUp                     0x8BED
          ChDown                   0x0BEC

          Start                    0x0BF2
          Play                     0x8BE9
          Enter                    0x0BF4
          Record                   0x8BE8
          Clear                    0x0BF5
          1                        0x8BFE
          2                        0x0BFD
          3                        0x8BFC
          4                        0x0BFB
          5                        0x8BFA
          6                        0x0BF9
          7                        0x8BF8
          8                        0x0BF7
          9                        0x8BF6
          100                      0x0BE2
          0                        0x8BFF
          Reload                   0x8BE3
      end codes

end remote
........................................................................ 
..
Quelle

http://www.vdr-wiki.de/wiki/index.php/Fernbedienung_-_Microsoft_XBOX_360_Universal_Media_Remote

von Dirk W. (dirkw)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

@Frank:

Danke dir; die Apple-FB klappt jetzt wunderbar :-)

@Frank, Graf-von-Socke

Weiß nicht ob's euch hilft, aber ich hatte vor meiner Apple FB
mit dem Gedanken gespielt die XBOX360 FB zu nehmen.
Hab meinen Trace mal angehängt. Wurde mit 15000 gemacht
und jede Taste 3x aufgezeichnet.

CU Dirk

Zusatz:
Hatte ich ganz vergessen; Im Trace sind noch an einigen Zeilenenden
</n>'s
Bitte vorher ersetzen, falls es den Parser stören sollte ?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Dirk W. schrieb:

> Danke dir; die Apple-FB klappt jetzt wunderbar :-)

Freut mich. Wie angekündigt, habe ich das mittlerweile allgemeiner 
gelöst: die ID wird nun als Adresse zurückgegeben. So sind Deine 
Fernbedienung und die von Klaus (und auch weitere APPLE-FBs) 
unterscheidbar. Nachteil ist: Die Adresse Deiner FB wird dann eine 
andere sein, nämlich 0x0046. Die von Klaus ist dann 0x00D1.

Update kommt in Kürze als Download im Artikel bzw. über SVN.

> Weiß nicht ob's euch hilft, aber ich hatte vor meiner Apple FB
> mit dem Gedanken gespielt die XBOX360 FB zu nehmen.
> Hab meinen Trace mal angehängt. Wurde mit 15000 gemacht
> und jede Taste 3x aufgezeichnet.

Vielen Dank! Deine Scans sind wunderbar, Graf-von-Socke hat offenbar 
eine ganz andere Scan-Frequenz genutzt, so dass ich mit seinen Scans 
wenig bis gar nichts anfangen konnte, weil IRMP mit 10kHz erst gar nicht 
RC6 erkannt hat.

Die XBOX benutzt tatsächlich RC6-Code, wer hätte das gedacht. Aber ich 
habe hier genau dieselben Probleme wie mit der Kathrein-FB, deren Scans 
hier schon mal gepostet wurden. Das ist leider kein Mode-0-RC6, wie er 
in

  http://www.sbprojects.com/knowledge/ir/rc6.htm

beschrieben ist. Ich werde mich nochmal mit der RC6-Decodierung 
beschäftigen und hoffe damit, die Kathrein-FB und die XBOX erschlagen zu 
können. Im Moment werden nämlich nur Mode-0-FBs mit 7 + 16 Datenbits 
erkannt. Die XBOX und die Kathrein-FB benutzen einen abweichenden Mode 
mit wesentlich mehr Datenbits. Wenn da jemand irgendeine Doku findet, 
wie die Struktur der Datenbits (Länge der Adresse und der Kommandos) 
ist, würde ich mich freuen.

> Hatte ich ganz vergessen; Im Trace sind noch an einigen Zeilenenden
> </n>'s
> Bitte vorher ersetzen, falls es den Parser stören sollte ?

Das war kein Problem :-)

Gruß,

Frank

von Achim (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe eine Dokumentation zum Mode 6A von RC6 gefunden: 
http://slycontrol.ru/scr/kb/rc6.htm. Ich hoffe die hilft dir weiter.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Achim schrieb:
> Ich habe eine Dokumentation zum Mode 6A von RC6 gefunden:
> http://slycontrol.ru/scr/kb/rc6.htm. Ich hoffe die hilft dir weiter.

Vielen Dank, das ist ja schon mal ein wenig mehr. Habe den URL direkt 
mal im IRMP-Artikel verlinkt. Jetzt muss ich nur schauen, ob ich den 
Mode 6A mit den Scans in Einklang bringen kann...

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Es gibt eine neue Version 1.7.3 von IRMP.

Download:

   http://www.mikrocontroller.net/articles/IRMP#Download

Änderungen gegenüber 1.7.2:

 - Neues Protokoll: JVC

 - Kaseikyo-Protokoll: Berücksichtigung der Genre-Bits.
   ACHTUNG: dadurch neue Command-Codes!

 - Kaseikyo-Protokoll: Verbesserte Behandlung von Wiederholungs-Frames

 - Verbesserte Unterstützung des APPLE-Protokolls.
   ACHTUNG: dadurch neue Adress-Codes!

Analog dazu gibt es auch eine neue Version 1.7.3 von IRSND.

Download:

   http://www.mikrocontroller.net/articles/IRMP#Download_IRSND

Änderungen gegenüber 1.7.2:

 - Neues Protokoll: Kaseikyo (Panasonic u.a.)

Viel Spaß,

Frank

von Graf-von-Socke (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo
und danke für den richtigen scan war mein fehler hatte den scan auf 
20000 eingestellt.

Nun wenn es euch intersesiert bastel ich gerade eine schaltung damit ich 
den
mikrocontroller über mein Handy dazu auffoder die geräere (TV usw) zu 
steuern.

bis dann

von Dirk W. (dirkw)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

noch interessant ist eventuell folgende Seite:
http://www.picbasic.nl/info_rc6_uk.htm

und folgendes Dokument (Seite: 28)
http://home.hccnet.nl/m.majoor/files/pronto.pdf

Hatte vor kurzem auch mal probiert RC6a per Hand zu dekodieren ..
Hab wohl allerdings einen Fehler gemacht, denn das Ergebnis
das ich zum Vergleich herangezogen hatte war unterschiedlich.

Hab's trotzdem mal angehängt; vielleicht hilft es ??


CU Dirk

von Graf-von-Sokce (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen

Habe nun ein anders Problem auf meine ATMEGA8 leuft alles supper.
Bin nun wegen platzmagel auf einen ATMGA 168 umgestigen nun leuft nur 
noch ISR aber es werden keine IR-CODES Ausgeben

gruß

Graf-von-Socke

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Dirk W. schrieb:

> noch interessant ist eventuell folgende Seite:
> http://www.picbasic.nl/info_rc6_uk.htm

Super Link! Danke. Damit werde ich RC6/RC6A wohl endlich in den Griff 
bekommen.

> Hatte vor kurzem auch mal probiert RC6a per Hand zu dekodieren ..
> Hab wohl allerdings einen Fehler gemacht, denn das Ergebnis
> das ich zum Vergleich herangezogen hatte war unterschiedlich.
>
> Hab's trotzdem mal angehängt; vielleicht hilft es ??

Danke, werde ich mir anschauen.

Gruß,

Frank

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
hattest du meine Frage per Mail bekommen ?
darf man dich per Mail fragen ?

gruss
jar

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> hattest du meine Frage per Mail bekommen ?
> darf man dich per Mail fragen ?

Habe ich bekommen. Da ich aber erst Freitag aus dem Urlaub gekommen bin 
und eine Antwort auf Deine Mail etwas länger dauert, bin ich noch nicht 
dazu gekommen, Deine Mail zu beantworten.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, ich habe RC6A als extra Protokoll No. 21 eingebaut. Damit sollte 
nicht nur die XBOX-FB funktionieren, sondern endlich auch die 
Kathrein-FB, an der ich schon längere Zeit rumdoktere.

Anbei die gegenüber der Download-Version geänderten Sources als 
Testversion. Sobald mir jemand sagt, dass es läuft, gibt es ein neues 
Release.

Viel Spaß,

Frank

von Graf-von-Socke (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Suppi
werde es mal gleich ausprobieren ob es geht

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Graf-von-Socke schrieb:
> werde es mal gleich ausprobieren ob es geht

Nimm aber 10kHz, das reicht vollkommen. 20kHz braucht man nur für 
Protokolle, die enorm kurze Pulse nutzen. Ds ist bisher bisher lediglich 
bwi RECS80 der Fall.

15kHz sind auch okay, verbät aber schon mehr CPU-Zeit.

Gruß,

Frank

von Graf-von-Socke (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nochnal Hallo

habe es gestest und funktioniert supper gemacht.

Und haben Sie schon mal wegen den ATMGA 168 nachgeschaut warum es mit 
dem nicht leüft !

gruß

Graf-von-Socke

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Graf-von-Socke schrieb:
> habe es gestest und funktioniert supper gemacht.

Freut mich :-)

> Und haben Sie schon mal wegen den ATMGA 168 nachgeschaut warum es mit
> dem nicht leüft !

irmp läuft auch auf einem ATMEGA 162 ohne Codeänderung, z.B. im 
WordClock-Projekt. Hast Du denn auch den Prozessor-Typ im WinAVR-Projekt 
ausgewechselt? Man kann i.a. nicht einfach das HEX-File für einen 
ATMEGA8 auf einen 168er laden.

Und unbedingt die Fuses beachten! Siehe 
http://www.engbedded.com/fusecalc/

Gruß,

Frank

von Graf-von-Socke (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank

Jo habe habe ich gemach siehe an den 2 Bildern. Habe eine jungfreulichen 
ATMEGA 168 genommen den ich noch hatte wie müssen die  Fuses-bits 
aussehn

gruß

Graf-von-Socke

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Graf-von-Socke schrieb:
> Jo habe habe ich gemach siehe an den 2 Bildern. Habe eine jungfreulichen
> ATMEGA 168 genommen den ich noch hatte wie müssen die  Fuses-bits
> aussehn

Ein jungfräulicher 168er läuft mit 1MHz internem Oszillator. Benutzt Du 
tatsächlich einen 3,686400 MHz Quarz, wie Du das im Projekt angegeben 
hast?

Ich kann Dir erst die Fuses-Einstellung nennen, wenn Du obige Frage 
beantwortet hast.

Gruß,

Frank

von Graf-von-Socke (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jo da es auf der Testplatine drauf ist. Hatte damit noch keine Probelem 
da ich schon fiel mt UART gemach habe und die frequenz mit UART sehr gut 
leuft

siehe http://www.wormfood.net/avrbaudcalc.php


gruß

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Graf-von-Socke schrieb:
> Jo da es auf der Testplatine drauf ist.

Vorausgesetzt, der µC läuft mit 5V, würde ich wählen:

Low:      0xc7
High:     0xdc
Extended: 0xf9

Achtung: der µC lässt sich dann auch nur noch flashen, wenn der Quarz 
auch wirklich angeschlossen ist.

Du kannst Dir die Werte aber auch selbst ausrechnen lassen, siehe

  http://www.engbedded.com/fusecalc/

Gruß,

Frank

von Graf-von-Socke (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danke

nun leuft alles Danke

hatte ein nettes erreignis. Mein Quartz wolte nicht  muste erst mit dem 
Frequenz Generator einen Beipass legen. Muss bestimmt nachlöten


Kennst du eigendlich den X-PORT


gruß
Graf-von-Socke

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Graf-von-Socke schrieb:

> nun leuft alles Danke

Prima.

> hatte ein nettes erreignis. Mein Quartz wolte nicht  muste erst mit dem
> Frequenz Generator einen Beipass legen. Muss bestimmt nachlöten

Deshalb meine obige Warnung :-)

> Kennst du eigendlich den X-PORT

Du meinst den "XPORT Ethernet Wandler Ethernet zu seriell" von 
Lantronix?

Gruß,

Frank

von Graf-von-Socke (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jo

Den meine ich finde den ganz nett aber er ist halt bischen teuer. Aber 
was man geschenkt bekommt sagt man nicht nein.

Bin nun dabei eine Schalung zu entwickeln damit jeder PC (auch Handy) 
auf den µC zu greifen kann und die Infrarot Befehle absetzen kann.

Der Grund dafür ist meine Frau die findt das die vielen Gräte aus den 
Blickfang verschwinden und daher fand ich deinen Ansatz hier sehr 
hilfreich.


Gruß

Graf-von-Socke

von Dirk W. (dirkw)


Bewertung
0 lesenswert
nicht lesenswert
Hi Frank,

auch hier Bestätigung. Super gemacht; System und Command Byte 
funktionieren.

Bist du dir allerdings bei der Customer ID sicher ?
Ich bekomme hier als Ausgabe 0xffef bin mir aber
ziemlich sicher daß die MS ID 0x800F ist.


CU Dirk

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Dirk W. schrieb:

> auch hier Bestätigung. Super gemacht; System und Command Byte
> funktionieren.

Sehr schön, danke für die Rückmeldung :-)

Achja, das MSB der 14 Bits (das ist das MSB des System-Bytes) ignoriere 
ich: das scheint nämlich zu togglen - ähnlich dem Toggle-Bit "TR" bei 
Mode 0, was dort ziemlich weit vorne direkt hinter den Mode-Bits liegt. 
Das ist mir beim XBOX-Scan als auch bei der Kathrein-FB aufgefallen: 
Beim Mode 6A wechselt das eigentliche Toggle-Bit nicht, dafür aber das 
oberste Bit vom System-Byte.

> Bist du dir allerdings bei der Customer ID sicher ?

Nein, sonst hätte ich ja keine Testversion gemacht ;-)

> Ich bekomme hier als Ausgabe 0xffef bin mir aber
> ziemlich sicher daß die MS ID 0x800F ist.

Okay, ich überprüfe das nochmal. Ich stehe echt auf Kriegsfuß mit der 
Manchester-Deokodierung. Wenn ein Bit falsch ist, kippen alle Bits 
dahinter mit :-(

Die Hölle ist nämlich das "eigentliche" RC6-Toggle-Bit "TR", welches die 
doppelte Länge der anderen Bits hat. Da ich mir immer nur Längen 
zwischen zwei Flankenwechseln anschaue, macht mir diese wechselnde 
Frequenz das Leben schwer, denn es kann da als Länge nicht nur 1-fache 
und 2-fache Länge, sondern auch die 1,5-fache Länge auftreten. Ich 
vermute mal, dass genau da das Bit kippt - und damit auch die 
Custtomer-ID, die danach folgt.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Dirk W. schrieb:
> Bist du dir allerdings bei der Customer ID sicher ?

Fehler gefunden und behoben.

Ersetze in irmp.c die Zeilen 2078/2079
    irmp_store_bit (0);
    last_value = 0;

durch folgendes:

    if (irmp_param.complete_len == RC6_COMPLETE_DATA_LEN_LONG) // RC6 mode 6A
    {
        irmp_store_bit (1);
        last_value = 1;
    }
    else    // RC6 mode 0
    {
        irmp_store_bit (0);
        last_value = 0;
    }

Nun kommt als Customer-ID auch 0x800F raus - wie gewünscht ;-)

Gruß,

Frank

von Dirk W. (dirkw)


Bewertung
0 lesenswert
nicht lesenswert
Hi,

jetzt funktioniert es ... ^_^

Ich protokollier dann gerade mal die Tasten, damit
ich meine alte PC FB gegen die XBOX FB tauschen kann ^_^


CU Dirk

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Neue Version 1.8.0 von IRMP verfügbar, Download unter

  http://www.mikrocontroller.net/articles/IRMP#Download

Änderungen gegenüber 1.7.3:

  - Neues Protokoll: RC6A

Damit werden nun die XBOX und auch die Kathrein-FBs unterstützt.

Ebenso ist nun die Version 1.8.0 von IRSND verfügbar, Download unter

  http://www.mikrocontroller.net/articles/IRMP#Download_IRSND

Änderungen gegenüber 1.7.3:

  - Neues Protokoll: JVC
  - Anpassung des APPLE-Encoders an IRMP-Version 1.7.3.

Im IRSND fehlt jetzt nur noch die Unterstützung des 
RC6-/RC6A-Protokolls, dann sind beide Software-Module wieder 
"symmetrisch". Bin da nun dran.

Die Dokumentation im IRMP-Artikel habe ich angepasst bzw.
erweitert, siehe:

  http://www.mikrocontroller.net/articles/IRMP

Viel Spaß,

Frank

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
wollte nur noch mal danke sagen,

deine Tipps wo ich meinen source anpassen musste waren erfolgreich, 
brauchte wirklich nur noch die irmp.c/.h einbinden und die irmpconfig.h 
anpassen und es funzt sofort, RC6 hab ich noch nicht testen können, aber 
der Rest läuft wie gehabt was ein gutes Zeichen ist......


gruss
jar

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Neue Version 1.8.0 von IRMP verfügbar,

Ganz toll ,Frank. Nur leider wird irmp_ISR immer länger. Wie steht es 
mit den Optmierungen aus 
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder" ?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> Ganz toll ,Frank. Nur leider wird irmp_ISR immer länger. Wie steht es
> mit den Optmierungen aus
> Beitrag "Re: IRMP - Infrared Multi Protocol Decoder" ?

Schlecht. Ich hatte mal testweise so eine Version gemacht, wo (nach 
Deiner Idee) in einer Schleife über die Protokolle mittels Timingwerten 
das richtige Protokoll ermittelt werden sollte. Dabei mussten noch 
Pulse-Distance-Protokolle mit Start-Bit von denen ohne Start-Bit (z.B. 
Denon) und auch die Manchester-codierten Protokolle extra abgearbeitet 
werden. Also gab es schon einmal 3 Schleifen...

Ergebnis:

1. Keine Flash-Speicher-Ersparnis, da die Konstruktion der 3 Schleifen
   inkl. zusätzlichen Speicherbedarf der Startbit-Werte für die
   einzelnen Protokolle alles wieder auffraß. Am Ende wurde sogar mehr
   Flash-Speicher benötigt als vorher.

2. Viel Größere Laufzeiten, da die Pulse-/Pause-Werte nicht mehr mit
   Konstanten, sondern mit Variableninhalten abgeglichen werden
   mussten. Der Variablenzugriff war wegen Indirektion über

            startbitstructarray[idx]->value

   nicht gerade effizient.

Kampakter bekommt man den Code wohl nicht, da kann man nur an Feinheiten 
tunen. Ab und zu stolpere ich mal über eine Stelle, die optimiere ich 
dann "on-the-fly", wenn es ohne größeren Aufwand geht.

Ich erwähnte damals zwar, dass man die linearen Vergleiche, die 
unmittelbar nach Eintreffen des Startbits auftreteten, noch optimieren 
könnte. Das würde aber auch keine Verkleinerung des Codes verursachen, 
eher eine (leichte) Vergrößerung. Lediglich die "Suche" nach dem 
richtigen Protokoll ginge dann etwas schneller. Die Arbeit habe ich mir 
aber noch nicht gemacht, da hier der Gewinn bei 20 Protokollen eher 
marginal ist. Bei 1000 Protokollen wäre das was anderes ;-)

Mein Fazit:

Wenn Dir der Code zu groß ist, schalte die nicht benötigten Protokolle 
ab. Dann wirst Du sehen, dass IRMP selbst eigentlich nicht größer ist 
als vorher. Ein neues Protokoll im IRMP verursacht im allgemeinen keine 
Vergrößerung des Codes - solange man es ausgeschaltet(!) lässt ;-)

Wenn jemand ein neu implementiertes Protokoll tatsächlich nutzen will, 
kann er schlecht erwarten, dass der Code gleich groß bleibt.


Gruß,

Frank

von Simon B. (nomis)


Bewertung
0 lesenswert
nicht lesenswert
Frank, vielen Dank für IRMP, das leistet bei mir gerade gute Dienste 
:-)

In irmpconfig.h steht als Maximum für F_INTERRUPTS 15000 - das ist aber 
eher ein veralteter Wert, oder? Oder muss man was spezielles tun, wenn 
man darüber hinausgeht (Manche Protokolle verlangen ja 20kHz)?

Ich habe übrigens beobachtet, dass bei F_INTERRUPTS=16000 eine 
Verringerung der Codegröße eintritt (um ca. 130-135 Bytes). Was passiert 
denn da?

Viele Grüße,
        Simon

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Simon Budig schrieb:
> Frank, vielen Dank für IRMP, das leistet bei mir gerade gute Dienste
> :-)

Freut mich :-)

> In irmpconfig.h steht als Maximum für F_INTERRUPTS 15000 - das ist aber
> eher ein veralteter Wert, oder? Oder muss man was spezielles tun, wenn
> man darüber hinausgeht (Manche Protokolle verlangen ja 20kHz)?

Ja, es sind auch 20kHz möglich, habe ich vergessen, das zu 
aktualisieren. Allerdings wird dann etwas mehr Speicherplatz benötigt, 
da dann einige Variablen vom Typ her automatisch über den Preprocessor 
von uint8_t auf uint16_t wechseln. Auch wird mehr CPU-Zeit verbraten. 
RECS80, das einzige Protokoll, welches 20kHz erfordert, ist auch noch 
nicht in der Praxis getestet worden.

> Ich habe übrigens beobachtet, dass bei F_INTERRUPTS=16000 eine
> Verringerung der Codegröße eintritt (um ca. 130-135 Bytes). Was passiert
> denn da?

Du meinst bei Erhöhung auf 16000? Müsste dann eigentlich größer werden, 
siehe oben.

Gruß,

Frank

von Simon B. (nomis)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Simon Budig schrieb:
>> Ich habe übrigens beobachtet, dass bei F_INTERRUPTS=16000 eine
>> Verringerung der Codegröße eintritt (um ca. 130-135 Bytes). Was passiert
>> denn da?
>
> Du meinst bei Erhöhung auf 16000? Müsste dann eigentlich größer werden,
> siehe oben.

Deswegen war ich ja irritiert...

Aber ich beobachte hier das Gegenteil. Ich habe gerade mal eine kleine 
Reihe gemacht:

F_INTERRUPTS  |   text  | data  |  bss  |    dec  |  vgl. zu 16000
--------------+---------+-------+-------+---------+----------------
        6000  |  11108  |  180  |  113  |  11401  |  +118
        7000  |  11124  |  180  |  113  |  11417  |  +134
        8000  |  11112  |  180  |  113  |  11405  |  +122
        9000  |  11126  |  180  |  113  |  11419  |  +136
       10000  |  11126  |  180  |  113  |  11419  |  +136
       11000  |  11130  |  180  |  113  |  11423  |  +140
       12000  |  11130  |  180  |  113  |  11423  |  +140
       13000  |  11130  |  180  |  113  |  11423  |  +140
       14000  |  11126  |  180  |  113  |  11419  |  +136
       15000  |  11130  |  180  |  113  |  11423  |  +140
       16000  |  10990  |  180  |  113  |  11283  |     0
       17000  |  10990  |  180  |  113  |  11283  |     0
       18000  |  10990  |  180  |  113  |  11283  |     0
       19000  |  10988  |  180  |  113  |  11281  |    -2
       20000  |  10988  |  180  |  113  |  11281  |    -2
       21000  |  10982  |  180  |  113  |  11275  |    -8
       22000  |  10982  |  180  |  113  |  11275  |    -8
       23000  |  10982  |  180  |  113  |  11275  |    -8
       24000  |  10982  |  180  |  113  |  11275  |    -8

Mhm. Ich habe mir gerade mal den Assembler angeguckt. Offensichtlich 
verschwindet bei F_INTERRUPTS = 16000 die gesamte if-Abfrage bei Zeile 
2020 (if (irmp_pause_time > IRMP_TIMEOUT_LEN)) in irmp.c, anscheinend 
beschließt der Compiler, dass das nicht eintreffen kann und schmeißt den 
Code weg.

Viele Grüße,
        Simon

PS: Zur Klarstellung: In der Codegröße ist natürlich noch jede Menge 
anderer Kram drin (LUFA, Displayansteuerung). Die Zahlen dürfen nicht 
zur Beurteilung der Größe von IRMP herangezogen werden, interessant sind 
hier nur die relativen Änderungen.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Simon Budig schrieb:
> Mhm. Ich habe mir gerade mal den Assembler angeguckt. Offensichtlich
> verschwindet bei F_INTERRUPTS = 16000 die gesamte if-Abfrage bei Zeile
> 2020 (if (irmp_pause_time > IRMP_TIMEOUT_LEN)) in irmp.c, anscheinend
> beschließt der Compiler, dass das nicht eintreffen kann und schmeißt den
> Code weg.

Das darf nicht sein, eigentlich wird ab ca. 16000 Hz IRMP_TIMEOUT_LEN 
größer als 255 und deshalb auch irmp_pause_time dann vom Typ uint16_t. 
Das scheint aber nicht zu funktionieren. Kein Wunder, dass der Compiler 
dann das if-Statement wegwirft. Ich werde das überprüfen.

Danke für den Tipp und Deine "Messungen" :-)

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Fehler gefunden, es ist eine Änderung in irmp.c notwendig.

Alt:
#include "irmp.h"
#ifndef IRMP_USE_AS_LIB
#include "irmpconfig.h"
#endif

Neu:
#ifndef IRMP_USE_AS_LIB
#include "irmpconfig.h"
#endif
#include "irmp.h"

Werde ich noch am Wochenende im Paket ändern.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Fehler gefunden, es ist eine Änderung in irmp.c notwendig.
> Werde ich noch am Wochenende im Paket ändern.

[x] Done

Download-Version ist nun 1.8.1.

Gruß,

Frank

von Simon B. (nomis)


Bewertung
0 lesenswert
nicht lesenswert
Sieht besser aus:

  F_INTR |   text  | data  |  bss  |    dec  |  vgl. zu 16000
---------+---------+-------+-------+---------+-----------------
   5000  |  11104  |  180  |  113  |  11397  |  -268
   6000  |  11108  |  180  |  113  |  11401  |  -264
   7000  |  11124  |  180  |  113  |  11417  |  -248
   8000  |  11112  |  180  |  113  |  11405  |  -260
   9000  |  11126  |  180  |  113  |  11419  |  -246
  10000  |  11126  |  180  |  113  |  11419  |  -246
  11000  |  11130  |  180  |  113  |  11423  |  -242
  12000  |  11130  |  180  |  113  |  11423  |  -242
  13000  |  11130  |  180  |  113  |  11423  |  -242
  14000  |  11126  |  180  |  113  |  11419  |  -246
  15000  |  11130  |  180  |  113  |  11423  |  -242
  16000  |  11370  |  180  |  115  |  11665  |     0
  17000  |  11370  |  180  |  115  |  11665  |     0
  18000  |  11372  |  180  |  115  |  11667  |    +2
  19000  |  11372  |  180  |  115  |  11667  |    +2
  20000  |  11376  |  180  |  115  |  11671  |    +6
  21000  |  11370  |  180  |  115  |  11665  |     0
  22000  |  11370  |  180  |  115  |  11665  |     0
  23000  |  11372  |  180  |  115  |  11667  |    +2
  24000  |  11372  |  180  |  115  |  11667  |    +2
  25000  |  11372  |  180  |  115  |  11667  |    +2

Vielen Dank und viele Grüße,
        Simon

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
der Bug bei U2X ist leider immer noch da, habe wie gesagt nur irmp.c/h 
eingebunden, meine main und die irmpconfig geändert sowie logging on und 
defines fürs steckbrett, , muss am verwendeten m644 liegen, ich weiss 
nur nicht wann und warum dieser U2X Fehler im irmp-uart kommt, wenn ich 
das einfach auskommentier gehts ja, aber der code sollte ja so laufen

Fehlermeldung:
../irmp.c:593:26: error: util/setbaud.h: No such file or directory

finde ich auch in meinem winAVR nicht
void
irmp_uart_init (void)
{
    UART0_UBRRH = UBRRH_VALUE;                                                                      // set baud rate
    UART0_UBRRL = UBRRL_VALUE;
/*
#if USE_2X
    UART0_UCSRA |= (1<<U2X);
#else
    UART0_UCSRA &= ~(1<<U2X);
#endif
*/
#if USE_2X
    UART0_UCSRA |= (1<<U2X0);
#else
    UART0_UCSRA &= ~(1<<U2X0);
#endif

    UART0_UCSRC = UART0_UCSZ1_BIT_VALUE | UART0_UCSZ0_BIT_VALUE | UART0_URSEL_BIT_VALUE;
    UART0_UCSRB |= UART0_TXEN_BIT_VALUE;                                                            // enable UART TX
}

so gehts, nur warum

lg
jar

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
als helfende krücke noch

#if IRMP_LOGGING != 0       // 1: log IR signal (scan), 0: do not 
(default)
    uart_init(UART_BAUD_SELECT(9600,F_CPU));
#endif


mit uart.c/h eingebunden Peter Fleury
modified by Patrick Kaplan for ATMega644 usage

und uart_init aufruf statt irmp-uart_init

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> Fehlermeldung:
> ../irmp.c:593:26: error: util/setbaud.h: No such file or directory

Meines liegt unter 
C:\Programme\WinAVR-20100110\avr\include\util\setbaud.h

und ist Bestand der avr-libc.

Wo liegt Dein avr\include-Verzeichnis? Überprüfe mal Deine Version - 
damit meine ich jetzt nicht die WinAVR-Version, sondern Deine 
avr-gcc-Version.

> finde ich auch in meinem winAVR nicht

Dann fehlt da was bei Dir. setbaud.h gibt es schon länger.

> so gehts, nur warum

Weil genau die U2X-Geschichte in setbaud.h definiert wird.

Gruß,

Frank

von Joachim B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Meines liegt unter
> C:\Programme\WinAVR-20100110\avr\include\util\setbaud.h
> und ist Bestand der avr-libc.
> Wo liegt Dein avr\include-Verzeichnis? Überprüfe mal Deine Version -
> damit meine ich jetzt nicht die WinAVR-Version, sondern Deine
> avr-gcc-Version.
>> finde ich auch in meinem winAVR nicht
> Dann fehlt da was bei Dir. setbaud.h gibt es schon länger.

setbaud.h fehlt, ergo muss bei meiner letzten Installation was schief 
gelaufen sein
 Verzeichnis von C:\Programme\atmel

10.12.2008  01:11    <DIR>          .
10.12.2008  01:11    <DIR>          ..
07.01.2010  21:50    <DIR>          AVR Tools
17.03.2008  20:32    <DIR>          BASCOM-AVR
02.09.2008  14:23           432.040 CodeCompareSetup.exe
25.11.2008  01:00    <DIR>          Grafikkonverter
07.03.2008  21:01    <DIR>          PonyProg2000
04.03.2008  20:25    <DIR>          WinAVR


komisch nur das alle meine anderen Projekte laufen, also habe ich nie 
was vermisst
was muss ich also noch wie einbinden ?

vielen Dank

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
so, setbaud ist wieder da, neuste winAVR installiert

muss noch testen

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
bin leider noch nicht weiter, so siehts aus:
Build started 9.9.2010 at 15:33:42

avr-gcc -I"C:\Programme\atmel\WinAVR\avr\include\util"  -mmcu=atmega644 -Wall -gdwarf-2 -std=gnu99                                                     -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT main.o
 -MF dep/main.o.d  -c  ../main.c

avr-gcc -I"C:\Programme\atmel\WinAVR\avr\include\util"  -mmcu=atmega644 -Wall -gdwarf-2 -std=gnu99                                                     -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT irmp.o

 -MF dep/irmp.o.d  -c  ../irmp.c

../irmp.c: In function 'irmp_uart_init':
../irmp.c:657: error: 'U2X' undeclared (first use in this function)
../irmp.c:657: error: (Each undeclared identifier is reported only once
../irmp.c:657: error: for each function it appears in.)
make: *** [irmp.o] Error 1
Build failed with 3 errors and 0 warnings...

was muss ich noch machen ?

include file search path, hab ich doch in project options ??? grübel
C:\Programme\atmel\WinAVR\avr\include\util\

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> bin leider noch nicht weiter, so siehts aus:

> ../irmp.c: In function 'irmp_uart_init':
> ../irmp.c:657: error: 'U2X' undeclared (first use in this function)

Du hast offenbar nicht die aktuelle IRMP-Version vom 04.09.2010. Da wird 
für bestimmte µCs U2X als U2X0 definiert.

Gruß,

Frank

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
stimmt da war ich unterwegs, habs also nicht mitbekommen

so geladen, eingespielt, aber immer noch Probleme...

ich glaub ich lasse meine Einbindung von P.Fleury UART.C/H damit klappts 
ja

DAANNKEEE

von Fabi S (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hey,
super geile Sache.
Wollt nur kurz mitteilen das meine LG Fernbedienung vom TV und BluRay 
Player mit dem Samsung(32) Protokoll einwandfrei funktionieren.

von Fabi S (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ahhh noch was vergessen,
meine beiden Fernbedienungen (sind verschiedene) der Marke Smart 
Electronics (Receiver usw.) funktionieren mit dem NEC Protokoll.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Fabi S schrieb:
> Wollt nur kurz mitteilen das meine LG Fernbedienung vom TV und BluRay
> Player mit dem Samsung(32) Protokoll einwandfrei funktionieren.

Freut mich.

> meine beiden Fernbedienungen (sind verschiedene) der Marke Smart
> Electronics (Receiver usw.) funktionieren mit dem NEC Protokoll.

Aber sie werden unterschiedliche Adressen haben, oder?

Gruß,

Frank

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.