Forum: Projekte & Code IRMP - Infrared Multi Protocol Decoder

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:

1

#define IRMP_SUPPORT_RCCAR_PROTOCOL             1       // flag: support RC car

in der irsnd.h habe ich eingefügt:

1

#define RCCAR_START_BIT_PULSE_LEN               (uint8_t)(F_INTERRUPTS * RCCAR_START_BIT_PULSE_TIME + 0.5)

2

#define RCCAR_START_BIT_PAUSE_LEN               (uint8_t)(F_INTERRUPTS * RCCAR_START_BIT_PAUSE_TIME + 0.5)

3

#define RCCAR_PULSE_LEN                         (uint8_t)(F_INTERRUPTS * RCCAR_PULSE_TIME + 0.5)       

4

#define RCCAR_1_PAUSE_LEN                       (uint8_t)(F_INTERRUPTS * RCCAR_1_PAUSE_TIME + 0.5)   

5

#define RCCAR_0_PAUSE_LEN                       (uint8_t)(F_INTERRUPTS * RCCAR_0_PAUSE_TIME + 0.5) 

6

#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:

1

#if IRMP_SUPPORT_RCCAR_PROTOCOL == 1

2

          case IRMP_RCCAR_PROTOCOL:

3

                    {

4

                        startbit_pulse_len          = RCCAR_START_BIT_PULSE_LEN;

5

                        startbit_pause_len          = RCCAR_START_BIT_PAUSE_LEN;

6

                        complete_data_len           = RCCAR_COMPLETE_DATA_LEN;

7

                        pulse_1_len                 = RCCAR_PULSE_LEN;

8

                        pause_1_len                 = RCCAR_1_PAUSE_LEN;

9

                        pulse_0_len                 = RCCAR_PULSE_LEN;

10

                        pause_0_len                 = RCCAR_0_PAUSE_LEN;

11

                        // has_stop_bit                = FDC1_STOP_BIT;

12

                        n_auto_repetitions          = 1;                                            // 1 frame

13

                        auto_repetition_pause_len   = 0;

14

                        repeat_frame_pause_len      = RCCAR_FRAME_REPEAT_PAUSE_LEN;

15

                        irsnd_set_freq (IRSND_FREQ_38_KHZ);

16

                        break;

17

                    }

18

#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ß

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

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.

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:

1

PULSES:

2

  6 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 4169

3

  7 oo 156

4

avg: 6.0 = 301.8 usec, min: 6 = 300.0, max: 7 = 350.0  tol: 16.0%

5

PAUSES:

6

  4 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 1575

7

  5 oooooooooooooooooooooooooooooooooooooooo 1072

8

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:

1

PULSES:

2

  6 oooooooooooooo 43

3

  7 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 184

4

  8 oooooooooooooooooooooooooooo 88

5

  9 ooo 10

6

 10  3

7

avg: 7.2 = 361.3 usec, min: 6 = 300.0, max: 10 = 500.0  tol: 38.4%

8

PAUSES:

9

  1  1

10

  2 oooooooooooooooooooo 28

11

  3 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 83

12

  4 oooooooooooooooooooooooooooooooooooooooooooooooooooooooo 78

13

  5 o 2

14

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

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

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....

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)

1

# controller

2

MCU = atmega168

3

4

# frequency

5

F_CPU = 20000000UL

6

7

# main application name (without .hex)

8

# eg 'test' when the main function is defined in 'test.c'

9

TARGET = main

10

11

# c sourcecode files

12

# eg. 'test.c foo.c foobar/baz.c'

13

SRC = $(TARGET).c irmp.c

14

15

# asm sourcecode files

16

# eg. 'interrupts.S foobar/another.S'

17

ASRC =

18

19

# headers which should be considered when recompiling

20

# eg. 'global.h foobar/important.h'

21

HEADERS =

22

23

# include directories (used for both, c and asm)

24

# eg '. usbdrv/'

25

INCLUDES =

26

27

28

# use more debug-flags when compiling

29

DEBUG = 1

30

31

32

# avrdude programmer protocol

33

PROG = usbasp

34

# avrdude programmer device

35

DEV = usb

36

# further flags for avrdude

37

AVRDUDE_FLAGS =

38

39

####################################################

40

# 'make' configuration

41

####################################################

42

CC = avr-gcc

43

OBJCOPY = avr-objcopy

44

OBJDUMP = avr-objdump

45

AS = avr-as

46

SIZE = avr-size

47

CP = cp

48

RM = rm -f

49

RMDIR = rm -rf

50

MKDIR = mkdir

51

AVRDUDE = avrdude

52

53

# flags for automatic dependency handling

54

DEPFLAGS = -MD -MP -MF .dep/$(@F).d

55

56

# flags for the compiler (for .c files)

57

CFLAGS += -g -Os -mmcu=$(MCU) -DF_CPU=$(F_CPU) -std=gnu99 -fshort-enums $(DEPFLAGS)

58

CFLAGS += $(addprefix -I,$(INCLUDES))

59

# flags for the compiler (for .S files)

60

ASFLAGS += -g -mmcu=$(MCU) -DF_CPU=$(F_CPU) -x assembler-with-cpp $(DEPFLAGS)

61

ASFLAGS += $(addprefix -I,$(INCLUDES))

62

# flags for the linker

63

LDFLAGS += -mmcu=$(MCU)

64

65

# fill in object files

66

OBJECTS += $(SRC:.c=.o)

67

OBJECTS += $(ASRC:.S=.o)

68

69

# include config file

70

-include $(CURDIR)/config.mk

71

72

# include more debug flags, if $(DEBUG) is 1

73

ifeq ($(DEBUG),1)

74

  CFLAGS += -Wall -W -Wchar-subscripts -Wmissing-prototypes

75

  CFLAGS += -Wmissing-declarations -Wredundant-decls

76

  CFLAGS += -Wstrict-prototypes -Wshadow -Wbad-function-cast

77

  CFLAGS += -Winline -Wpointer-arith -Wsign-compare

78

  CFLAGS += -Wunreachable-code -Wdisabled-optimization

79

  CFLAGS += -Wcast-align -Wwrite-strings -Wnested-externs -Wundef

80

  CFLAGS += -Wa,-adhlns=$(basename $@).lst

81

  CFLAGS += -DDEBUG

82

endif

83

84

####################################################

85

# avrdude configuration

86

####################################################

87

ifeq ($(MCU),atmega8)

88

  AVRDUDE_MCU=m8

89

endif

90

ifeq ($(MCU),atmega48)

91

  AVRDUDE_MCU=m48

92

endif

93

ifeq ($(MCU),atmega88)

94

  AVRDUDE_MCU=m88

95

endif

96

ifeq ($(MCU),atmega168)

97

  AVRDUDE_MCU=m168

98

endif

99

100

AVRDUDE_FLAGS += -p $(AVRDUDE_MCU)

101

102

####################################################

103

# make targets

104

####################################################

105

106

.PHONY: all clean distclean avrdude-terminal

107

108

# main rule

109

all: $(TARGET).hex

110

111

$(TARGET).elf: $(OBJECTS)

112

  $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^

113

114

# all objects (.o files)

115

$(OBJECTS): $(HEADERS)

116

117

# remove all compiled files

118

clean:

119

  $(RM) $(foreach ext,elf hex eep.hex map,$(TARGET).$(ext)) \

120

    $(foreach file,$(patsubst %.o,%,$(OBJECTS)),$(foreach ext,o lst lss,$(file).$(ext)))

121

122

# additionally remove the dependency makefile

123

distclean: clean

124

  $(RMDIR) .dep

125

126

# avrdude-related targets

127

install program: program-$(TARGET)

128

129

avrdude-terminal:

130

  $(AVRDUDE) $(AVRDUDE_FLAGS) -c $(PROG) -P $(DEV) -t

131

132

program-%: %.hex

133

  $(AVRDUDE) $(AVRDUDE_FLAGS) -c $(PROG) -P $(DEV) -U flash:w:$<

134

135

program-eeprom-%: %.eep.hex

136

  $(AVRDUDE) $(AVRDUDE_FLAGS) -c $(PROG) -P $(DEV) -U eeprom:w:$<

137

138

# special programming targets

139

%.hex: %.elf

140

  $(OBJCOPY) -O ihex -R .eeprom $< $@

141

  @echo "========================================"

142

  @echo "$@ compiled for: $(MCU)"

143

  @echo -n "size for $< is "

144

  @$(SIZE) -A $@ | grep '\.sec1' | tr -s ' ' | cut -d" " -f2

145

  @echo "========================================"

146

147

%.eep.hex: %.elf

148

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

149

150

%.lss: %.elf

151

  $(OBJDUMP) -h -S $< > $@

152

153

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

und das ergibt ein make

1

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

2

main.c:61: Warnung: kein vorheriger Prototyp für »timer_init«

3

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

4

irmp.c:1204: Fehler: expected identifier or »(« before »volatile«

5

irmp.c:1204: Fehler: expected »)« before »(« token

6

irmp.c:1296: Warnung: Redundante Redeklaration von »irmp_bit«

7

irmp.c:1193: Warnung: Vorherige Deklaration von »irmp_bit« war hier

8

irmp.c:2326: Warnung: kein vorheriger Prototyp für »print_spectrum«

9

irmp.c: In Funktion »print_spectrum«:

10

irmp.c:2368: Warnung: format »%0.2f« erwartet Typ »double«, aber Argument 3 hat Typ »float«

11

irmp.c: In Funktion »main«:

12

irmp.c:2565: Warnung: Übergabe des Arguments 1 von »print_spectrum« entfernt Kennzeichner von Zeiger-Ziel-Typ

13

irmp.c:2566: Warnung: Übergabe des Arguments 1 von »print_spectrum« entfernt Kennzeichner von Zeiger-Ziel-Typ

14

irmp.c:2567: Warnung: Übergabe des Arguments 1 von »print_spectrum« entfernt Kennzeichner von Zeiger-Ziel-Typ

15

irmp.c:2568: Warnung: Übergabe des Arguments 1 von »print_spectrum« entfernt Kennzeichner von Zeiger-Ziel-Typ

16

make: *** [irmp.o] Fehler 1

wo liegt da das problem?

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

Tastatur läuft auf 38kHz, hab ich grad nachgemessen.

Gruß
Torsten

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

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

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

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.

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

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

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

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?

1

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

2

irmp.h:342: Fehler: expected specifier-qualifier-list before »uint8_t«

3

irmp.h:361: Fehler: expected »=«, »,«, »;«, »asm« or »__attribute__« before »irmp_get_data«

4

irmp.h:367: Fehler: expected »=«, »,«, »;«, »asm« or »__attribute__« before »irmp_ISR«

5

make: *** [main.elf] Fehler 1

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.

Max M. schrieb:
> nun bekomm ich aber immer noch fehler... woran liegt jetzt bitte das?

1

> avr-gcc -g -Os -mmcu=atmega168 -DF_CPU=20000000UL -std=gnu99

2

> -fshort-enums -MD -MP -MF .dep/main.elf.d  -mmcu=atmega168 -o

3

> 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

ja das ist so aber warum will er die header datei linken?

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:

1

make -n -f Makefile.Max

Der Output dazu:

1

$ make -n -f Makefile.Max

2

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

3

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

4

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

5

...

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 ;-)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

so, mal wieder angemeldet das ich Antworten per mail bekomme

danke

gruss
jar

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

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

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

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

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

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

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 ;-)

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....

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 :|

Joachim B. schrieb:

> zu umwandeln, low aktiv oder high aktiv ?

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

Gruß,

Frank

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

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

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

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

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

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

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

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

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

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

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

Joachim B. schrieb:
> habe mal jvc dazugelinkt

hat nicht geklappt, neuer versuch

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

         1         2         3         4

2

123456789012345678901234567890123456789012345678

3

010000000000010000001101000000001011110010110001 p =  5, a = 0x2002, c = 0x03d0, f = 0x00

4

010000000000010000000001000000001011110010111101 p =  5, a = 0x2002, c = 0x03d0, f = 0x00

5

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

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

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 ?

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

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

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

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 ?

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

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

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 :-)

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

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

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

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

http://de.wikipedia.org/wiki/Jitter

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

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

1. Messung: 000000000000000111111111000000000011111111110000000

2

2. Messung: 000000000000000011111111100000000111111111100000000

3

3. Messung: 000000000000001111111110000000000011111111110000000

Trotzdem danke für den interessanten Link.

Gruß,

Frank

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

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

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

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.

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

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

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

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

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

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

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

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

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

Frank M. schrieb:
> 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


http://www.sbprojects.com/knowledge/ir/ir.htm
http://www.hifi-remote.com/forums/viewtopic.php?t=6401
http://www.hifi-remote.com/forums/viewtopic.php?t=12233&sid=cdf5a421a7ecc165af055f6555019261
http://www.google.de/url?sa=t&source=web&cd=6&ved=0CEMQFjAF&url=http%3A%2F%2Fwww.denon.fr%2Fscripts%2Fbo%2Fadmin%2Fdocuments%2Fanti_leech.asp%3Fdownload_file%3DCode_IR_S_5BD.pdf%26disk_file%3D18865.byupload&ei=Y0ZlTJ7dIeeTOJeerZoN&usg=AFQjCNEiW7SvxrKKOnKIdVpByZ3ISaLfXA
http://usa.denon.com/AVR-4308CI_IRCodes.pdf


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

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

aber es gibt:
TCE RCA Code (56.7 kHz)

Vishay sagt auch nur:
Kaseikyo Matsushita Code (36.7kHz)

gruss
jar

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