DIY IR Remote: Canon RC-1 + Pentax IR F + Nikon ML-L3 + Olympus RM-1

MasterFX · 16 April 2011

jar schrieb:
stimmt sorry, ich vergaß wohl das du die Taster per Interrupt abfragst

Muss ich machen, weil er nur mit dem Pin-Change Interrupt aus dem Power-Down-Mode wieder aufgeweckt wird.

Wie gesagt, ich werde mal gucken wann ich dazu komme. Hatte bisher noch nichts dergleichen bei mir beobachten können.
Vermutlich reicht es auch, wenn ich den letzten Key-State speichere nach dem Senden des Befehls und bei nächsten Wakeup wird geguckt ob der Taster nun losgelassen oder gedrückt wurde...

Ich habe gerade mal gemessen... der Kurzhubtaster prellt beim drücken praktisch gar nicht (wobei das hier auch eh irrelevant ist, da der Auszuführende Code lang genug ist) dafür aber beim Loslassen. Oftmals ein Peak von wenigen µs dann 5-10ms wieder Low und dann wieder High. Ich denke, dass dies genau der Moment ist an der er aufwacht und bei der Tasterabfrage dann "0" liest.

Ich denke, dann sollte das schon reichen:

Code:

#elif defined NIKON
	uint8_t i;
	uint8_t	j;
        
        [b]_delay_ms(10);[/b]
	if((PINB & 1<<PB3) == 0){

loetknecht · 21 April 2011

Guten Morgen!
Danke für eure Vorschläge, MasterFX und jar!
Da der Tiny schon ins Gehäuse eingeklebt ist und ich aus Mangel an übrigen Pins die SCK, MISO, MOSI mit LED-Bestromung belegen mußte und daher nicht herausgeführt habe, wäre jede Umprogrammierung ziemlich aufwendig.
Den herausgelesenen Tip, einfach so kurz zu drücken, daß kein Prellen bis Ablauf der ISR stattfindet, werde ich testen.
Ansonsten, da die Eingangspins laut Datenblatt rein levelgetriggert zu sein scheinen (keine Einschränkung der Anstiegs- oder Abfallzeit gefunden) behelfe ich mir wohl mit einem Kondensator über den (zugänglichen) Taster.
Schöne Grüße!

Edit: das Entprellen mit dem Kondensator funktioniert, ich habe einen 4,7uF verwendet zum internen Pullupwiderstand von 10..30k (laut Atmel Datenblatt).

Dewenne · 27 April 2011

Leider kann ich erst jetzt antworten - ich wollte ganz sicher sein daß der Fehler nicht bei mir liegt...

Also Minolta auslösen klappt inzwischen einwandfrei ! Super!!
Sony auslösen klappt leider immer noch überhaupt nicht bei mir.
Ich habs mal kurz angeschaut aber keine Präzisionsanalyse bis in die letzten Signalecken und Freqenzen.
Es sieht so aus, daß eine Steuersequenz beim Tastendrücken ausgesendet wird und eine weitere beim Loslassen des Knopfes. Die Sequenzen sind unterschiedlich lang und bewirken keine Auslösung der Sony ;-( sie werden also nicht 5 mal wiederholt. Als Stützkondensator verwende ich einen 220µF SMD Tantal - das sollte eigentlich reichen (keinen 100nF Keramisch parallel).
Eigentlich sollte die Spannung nicht kritisch sein da ich die IR Leds (2 Stück) über Widerstände ansteuere.

Als Gehäuse plane ich ein Platinendesign als Layout in die Außenwandleiterplatten integriert - ich denke das wird ganz schnuckelig.
Toll wäre es natürlich wenn man den IR Remote Transmitter wie eine Rudermaschine an einen RC Empfänger ausm Modellbau anschließen könnte und dann die Kamera zusätzlich über Funk auslösen könnte.
Die Pins würden reichen beim Tiny 25.

Servus vom Werner

MasterFX · 27 April 2011

Ich werde mir das bei gelegenheit nochmal ansehen, bin gerade eher mit dem MultiTrigger beschäftigt. Aber das Prellen beim Loslassen müsstest du mit nem _delay_ms(10) vor der Tasterabfrage unterdrücken können (siehe Post #181).
Es ist natürlich so, dass der Kondensator gar nicht für so eine lange Sequenz ausreicht. Da sind höchstens so 150 36khz Pulse drin bei einem 220µF, danach sackt die Spannung schon sichtbar ein, sollte aber dennoch ausreichen zum Auslösen. (zumindest bei einer CR2032, da diese einfach nicht so viel Dauerstrom liefern kann)

Dewenne · 28 April 2011

Vielen Dank schon mal ...
Klar bist Du aktuell voll in das Multitriggerprojekt eingespannt.

Ich glaub nicht daß es ein Spannungseinbruch ist, denn die Signaldächer bleiben schön waagerecht und außerdem ist die verwendete Lithiumbackupzelle aus PC Beständen relativ kräftig und hat viel mehr Power als eine CR2032.
Einen Keramischen 100nF hab ich doch reingebaut also Spikes werden es auch nicht sein.. (Minolta funzt ja)

Reicht der Platz im Programmspeicher des Multitriggers aus alle Kameraprofile reinzuspeichern und dann per Menü auswählen zu können?

Dewenne

MasterFX · 28 April 2011

Dewenne schrieb:
Reicht der Platz im Programmspeicher des Multitriggers aus alle Kameraprofile reinzuspeichern und dann per Menü auswählen zu können?

Beim MultiTrigger?
Vielleicht nicht alle, aber Canon, Nikon und Pentax ist schon drin. Noch wäre Platz.

race13 · 7 Mai 2011

Ich bin gerade dabei einen kleinen universalen Auslöser für die Kameras in meiner Umgebung (Nikon, Canon, Sony) zu schreiben.
Als der Code fertig war habe ich mir die Frage gestellt wie lange die LED blinken würde, wenn ich alle 7 Modelle aus dem Code von MasterFX hintereinander ansprechen möchte. Spielt sich das alles noch unter einer Sekunde ab oder würde es länger dauern?

MasterFX · 8 Mai 2011

Ja sollte innerhalb einer Sekunde sein
-Canon ~9ms
-Sony ~250ms
-Nikon ~110ms
-Pentax ~15ms
-Olympus ~50ms
-Minolta glaub auch so 100ms
-Fuji ~100ms

jar · 8 Mai 2011

unter 1 s hätte ich auch vermutet, aber alle Codes zugleich raushauen, kann man sich damit nicht auch Feinde machen, OK manche Cams müssen erst für IR eingestellt werden, aber in einer Gruppe von Fotografen alle Codes mit einmal raushauen kann doch für einige doof sein

ich würde das schaltbar machen per Menü

race13 · 8 Mai 2011

jar schrieb:
unter 1 s hätte ich auch vermutet, aber alle Codes zugleich raushauen, kann man sich damit nicht auch Feinde machen, OK manche Cams müssen erst für IR eingestellt werden, aber in einer Gruppe von Fotografen alle Codes mit einmal raushauen kann doch für einige doof sein

ich würde das schaltbar machen per Menü

Ein LCD setzt leider zu viel Code für meinen kleinen PIC16F716 voraus. Ich habe aber auch gemerkt das mein Compiler bei allen Codes aussteigt, weil der PIC nicht genug Speicher hat. Meine drei genannten gehen so mit ~60% Speicherbelegung rein, und das sollte erstmal reichen.

Ich hätte noch eine kleine Codeentschlackung vorzuschlagen.
Ich habe gesehen das for-Schleifen schneller beendet werden wenn nicht (i=0,i<xx,i++) sondern (i=xx,i!=0;i--) schreibt. Der Grund liegt an der Prüfung auf 0 bzw. auf der Prüfung des Zero-Bits (wenn der µC eines hat).
Allerdings weiß ich jetzt nicht in wie weit sich das dann auf die Sendezeiten auswirkt.

jar · 8 Mai 2011

race13 schrieb:
Ich hätte noch eine kleine Codeentschlackung vorzuschlagen.
Ich habe gesehen das for-Schleifen schneller beendet werden wenn nicht (i=0,i<xx,i++) sondern (i=xx,i!=0;i--) schreibt.

grundsätzlich ne gute Idee, mache ich auch sehr oft so, z.B.
Wartezeiten (da ist es egal ob hoch oder runtergezählt wird)
und bei Abarbeitung im Interrupt braucht man jede Verkürzung, nicht nur vom code, sondern auch in der Abarbeitung !!!

aber doof ist es für Arrays wenn da aufsteigend was gemacht werden soll, da bleibe ich lieber bei 0 - Ende (z.B. LCD Ausgabe, fängt ja immer bei Char 0 an)
oder ich schreibe neu nur die Änderungen, aber auch da ist es eine Gradwanderung, was spare ich durch einzelne Zeichen schreiben und was verliere ich durch Cursorsetzung, bzw. wäre nicht die vollständige Ausgabe hintereinander nicht doch schneller ?

MasterFX · 8 Mai 2011

race13 schrieb:
Ich hätte noch eine kleine Codeentschlackung vorzuschlagen.
Ich habe gesehen das for-Schleifen schneller beendet werden wenn nicht (i=0,i<xx,i++) sondern (i=xx,i!=0;i--) schreibt. Der Grund liegt an der Prüfung auf 0 bzw. auf der Prüfung des Zero-Bits (wenn der µC eines hat).

Sind in der Tat zwei Befehle weniger. Macht bei 8MHz aber gerade mal 0,2µs Zeitgewinn und 4 Bytes weniger Flash-Nutzung. Dafür wird der Code aber weniger gut lesbar und solange man noch keine Platzprobleme hat sollte dieses kleine Defizit zugunsten der Lesbarkeit belassen.
Komischerweise wird wenn man "(i=xx,!i;i--)" schreibt die schleife komplett wegoptimiert

hatte mich schon gewundert warum der "Code" damit 60 bytes kleiner wird, bis ich dann gemerkt habe, dass die Schleife dann komplett weg ist. Hängt wohl irgendwie mit den Kompileroptimierungen zusammen.

Dewenne · 9 Mai 2011

Hat sich jetzt eigentlich an der Codierung für Sony nochmal was geändert - oder ist da noch alles beim alten (also nicht funktionierend) ?

Dewenne

MasterFX · 9 Mai 2011

Dewenne schrieb:
Hat sich jetzt eigentlich an der Codierung für Sony nochmal was geändert - oder ist da noch alles beim alten (also nicht funktionierend) ?

Dewenne

Ich habe jetzt scheinbar eine funktionierende Sony-Version in meinen MultiTrigger, ich baue das nachher mal in den IR Remote ein...

race13 · 9 Mai 2011

Ohh, da hätte ich den Thread besser lesen sollen, dachte Sony würde schon gehen. Dann muss ich meinen Schiegervater wohl noch etwas vertrösten.

MasterFX · 9 Mai 2011

race13 schrieb:
Ohh, da hätte ich den Thread besser lesen sollen, dachte Sony würde schon gehen.

Bisher scheinbar nicht ganz zuverlässig.

race13 schrieb:
Dann muss ich meinen Schiegervater wohl noch etwas vertrösten.

Zumindest bis heute ~17 Uhr...

MasterFX · 9 Mai 2011

So, sogar noch 35 Minuten eher mit dem Sony-Protokoll (welches jetzt klappen sollte)

race13 · 9 Mai 2011

Wenn Quellcode weiblicher wäre, dann hätten wir hier wohl ein 85-62-91.

Edit:
Kleine Frage:
Können folgende Verinfachungen für Canon und Sony funktionieren?

Code:

// Canon
for(j=2;j!=0;j--){
	for(i = 16; i !=0; i--){
		PULSE_32k();
	}
	if(j-1){
		if(pincount < 200) 	// Key pressed for undelayed Shot ? 
			DelayBigUs(7330);
		else if (pincount >= 200) // Key pressed for delayed Shot ?
			DelayBigUs(5360);
	}
}

Code:

//Sony gekürzt
for(k=0;k<5;k++){
	// Send Start-Burst
	for(i=96; i!=0; i--)
		PULSE_40k();
	DelayBigUs(640);
	// Send Command
	while(j++<7){
		i=24;
		if(cmd & mask)
			i=48;	
		while(i--)
			PULSE_40k();
		DelayBigUs(640);
		mask <<= 1;
	}
	// Send Address
	mask = 1;
	j = 0;
	while(j++<13){
		i=24;
		if(address & mask)
			i=48;
		while(i--)
			PULSE_40k();
		DelayBigUs(640);
		mask <<= 1;
	}
	DelayMs(11);
}

Ich frage da mein Controller so bei nur 80% Speicherbelung ist. Mit dem "original"-Code von MasterFX bin ich bei 99,6%.

Dewenne · 10 Mai 2011

Also die Sony alpha 550 löst jetzt problemlos bis etwa 4m Abstand aus.
Ich verwende im Testaufbau 2 IR Dioden SFH409 mit je einem Vorwiderstand von 68 Ohm an je einem Prozessorausgang.
Das werde ich noch etwas optimieren.
Das Layout wird kommen.

Schon jetzt sage ich herzlichen Dank an MasterFX !!!

Dewenne

jar · 11 Mai 2011

Dewenne schrieb:
Ich verwende im Testaufbau 2 IR Dioden SFH409 mit je einem Vorwiderstand von 68 Ohm an je einem Prozessorausgang.
Dewenne

hast du mal gemessen ? I und U ?

68 Ohm kommt mir etwas hoch vor, allerdings meine IR vertragen 100mA Dauer und über 1 A Peak und der Rv ist spannungsabhängig, ich war erstaunt das IR LEDs nur 1,2V haben bei 100mA, alle anderen die ich vermessen hatte, von low current bis high power lagen zwischen 2 und 3,3 V im Bereich von 2-3mA bis 350mA

ich hatte schon mit Master gesprochen das an den Transistoren ja auch was Spannung abfällt und er Port kann schon keine 100mA liefern, die älteren Atmel 10mA die neueren bis 40 mA, aber mit nur IR könnte man mehr Ports zusammenlegen um den Trasi zu sparen (wer es muss)

aber zu Reichweiten Tests bin ich noch nicht gekommen, bin froh nach den Zeiten anzupassen (für meinen Atmel) immerhin schon Canon und Pentax auslöst, muss noch Nikon testen und Sony einbauen.

Genial ist das IRMP (universal IR Empfänger) läuft und so ein IR Umsetzer gemacht werden kann, mangels Tasten am Atmel hab ich IR in (RC5) eine pinnacle FB auf Taste 1 gelegt für Canon Code out, 2 für Nikon, 3 für Pentax, kann ich dann mit jeder FB machen