• Neuer Gutscheincode unseres Partners Schutzfolien24:
    DSLR-Forum2025
    Dauerhaft 10% Rabatt auf alle Displayschutzfolien und Schutzgläser der Eigenmarken
    "Upscreen", "Screenleaf", BROTECT" und "Savvies".
    Der Code ist für alle Geräteklassen gültig.
  • Mitmachen beim DSLR-Forum Fotowettbewerb September 2025.
    Thema: "Straßenfotografie s/w"

    Jeden Monat attraktive Gewinnprämien, gesponsert von unserem Partner PixelfotoExpress.
    Alle Infos zum September-Wettbewerb hier!
  • In eigener Sache!

    Liebe Mitglieder, liebe Besucher und Gäste
    ich weiß, es ist ein leidiges Thema, aber ich muss es ansprechen: Werbung, Werbeblocker und Finanzierung des Forums.
    Bitte hier weiterlesen ...

  • Nicht erreichbare Adressen im Benutzerkonto
    Wir bekommen zurzeit eine große Anzahl an E-Mails, die das System zum Beispiel als Benachrichtigungen an Nutzer verschickt,
    als unzustellbar zurück, weil z.B. die Adressen nicht erreichbar sind oder das Postfach gar nicht existiert.
    Stellt doch bitte sicher, dass die Benachrichtigungen, die ihr vom System erwartet, auch zugestellt werden können.
    Nicht erreichbare E-Mail-Adressen sind dazu wenig hilfreich.
    Danke!
WERBUNG

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

Kann mir jemand sagen ob die Pentax Kameras auch mit 40KHz-Modulation zurecht kommen? Bei Nikon ist das ja machbar.

könnte ich evt. testen, meinen auf 40kHz umstell und auf Stammtisch am Freitag auf Pentaxuser mit IR in Cam hoffen

was macht der Code, mal geschaut ? oder zu komplex ?
 
könnte ich evt. testen, meinen auf 40kHz umstell und auf Stammtisch am Freitag auf Pentaxuser mit IR in Cam hoffen

was macht der Code, mal geschaut ? oder zu komplex ?
Wenn du die 40KHz testen kannst wäre das toll.
Dein Code ist noch gezipt. Bin gestern um 22 Uhr nicht mehr dazu gekommen, und heute abend wird es auch nicht viel früher bis ich zuhause bin. Aber alleine vom Lesen der Beschreibung kann ich schonmal sagen, das es nicht ganz so einfach wird. Mit Multitasking habe ich bisher noch nicht viel gemacht bzw. das dauert dann etwas länger bis ich mich eingearbeitet habe. Vorallem die Deadlock Suche wird spannend.
 
Vorallem die Deadlock Suche wird spannend.

keine Ahnung was das ist,
aber User haben beim Testen immer die Tasten und Bedienkombi gefunden die das Teil abstürzen liessen, es gibt also illegal state, wenn ich nur wüsste wo ?

zur Not aktiviere ich den watchdog :rolleyes:

so dann hau ich in meinen mal 40 kHz exakt rein, Oszi abgeglichen und teste mit Pentax
 
keine Ahnung was das ist,
aber User haben beim Testen immer die Tasten und Bedienkombi gefunden die das Teil abstürzen liessen, es gibt also illegal state, wenn ich nur wüsste wo ?
Stell dir vor, du hast einen Task der die Variablen x und y inkrementiert und einen Task der x und y in einem Koordinatensystem zeichnet. Bei Multitasking kann es passieren das zwischen dem Inkrementieren von x und dem von y der Task wechselt (x ist dann schon x+1, y aber noch y). Jetzt passen die zwei Koordinaten für die Ausgabe nicht und der geziegt Punkt wäre falsch. Hier muss man jetzt einen Schutz bauen der den Zugriff auf die Variablen unterbindet.
Bei großen Programmen sind viele dieser Schutzmechanismen drin und greifen teils auch in ein ander. Ein Deadlock entsteht wenn ich falscher Reinfolge solche Schutzmechanismen betreten, aber nicht verlassen werden. Dann warten Tasks gegenseitig auf einander und keiner kommt weiter.
Wenn bei bestimmten "Tastenkombinationen" dein Programm abstürzt, hat das Bestimmt was damit zu tun, das an Stellen ein Task wechselt und ein anderer auf die gleichen Variablen/... zugreift.
so dann hau ich in meinen mal 40 kHz exakt rein, Oszi abgeglichen und teste mit Pentax.
Thx.
 
Stell dir vor, du hast einen Task der die Variablen x und y inkrementiert und einen Task der x und y in einem Koordinatensystem zeichnet. Bei Multitasking kann es passieren das zwischen dem Inkrementieren von x und dem von y der Task wechselt (x ist dann schon x+1, y aber noch y). Jetzt passen die zwei Koordinaten für die Ausgabe nicht und der geziegt Punkt wäre falsch. Hier muss man jetzt einen Schutz bauen der den Zugriff auf die Variablen unterbindet.
Bei großen Programmen sind viele dieser Schutzmechanismen drin und greifen teils auch in ein ander. Ein Deadlock entsteht wenn ich falscher Reinfolge solche Schutzmechanismen betreten, aber nicht verlassen werden. Dann warten Tasks gegenseitig auf einander und keiner kommt weiter.
Wenn bei bestimmten "Tastenkombinationen" dein Programm abstürzt, hat das Bestimmt was damit zu tun, das an Stellen ein Task wechselt und ein anderer auf die gleichen Variablen/... zugreift.
Thx.

ja sowas wirds sein, nur ist es nahezu unmöglich alles gegen alles zu testen, auch da bleibt der Controller dann stecken wegen zuviel Prüfung, evt. findest du ja die gröbsten Fehler ?
 
So. Meine Fernbedienung ist nun komplett fertig.

Falls es jemanden interessiert, hier der Code für Bascom - und zwar so, das auch die Modulationsfrequenz mit einem Atmel Mega 88 (@8MHz) stimmt (denn mit den 13µS geht es sich nicht aus und die Kamera reagiert eher sporadisch):

$regfile = "M88def.dat"
$crystal = 8000000
$hwstack = 48

Dim A As Integer
Dim I As Integer
Dim J As Integer

Config Pinb.1 = Output
Config Pinc.0 = Input
Config Pinc.1 = Input

Fokus Alias Pinc.0
Ausloes Alias Pinc.1

Portc.0 = 1
Portc.1 = 1


Do

If Ausloes = 0 Then
For A = 1 To 494
Portb.1 = 1
Waitus 11
Portb.1 = 0
Waitus 11
Next A

Waitus 3000

For I = 1 To 7
For J = 1 To 38
Portb.1 = 1
Waitus 11
Portb.1 = 0
Waitus 11
Next J
Waitus 1000
Next I
Waitms 120
Else
Portb.1 = 0
End If

If Fokus = 0 Then
For A = 1 To 494
Portb.1 = 1
Waitus 11
Portb.1 = 0
Waitus 11
Next A

Waitus 3000

For I = 1 To 6
For J = 1 To 38
Portb.1 = 1
Waitus 11
Portb.1 = 0
Waitus 11
Next J
Waitus 1000
Next I
Waitus 2000
For J = 1 To 38
Portb.1 = 1
Waitus 11
Portb.1 = 0
Waitus 11
Next J
Waitms 120
Else
Portb.1 = 0
End If

Loop

End

Der zweite Teil ist zum fokussieren, falls das jemand braucht.
 
Ups, das hätte ich dazu schreiben sollen, sorry.
Also ungutknut sagte das es zwar geht aber nicht so gut wie 38kHz.
Da ich dummerweise meine Controller schon gebrannt und verlötet habe kann ich das jetzt nicht mehr ändern, aber immerhin sollte es gehen.

Es wäre jetzt richtig genial wenn jemand Zugriff auf alle Modelle mit 38-40kHz hätte und testen könnte ob nicht vielleicht 38,9kHz oder 39,3kHz für alle Modelle zuverlässig funktioniert. Somit könnte man eine ganze Menge an Code sparen.


Um keinen Doppelpost zu machen, kommt nun mein Fernauslöser mit Microchip-Controller.
Nach langem hin und her, Teils richtig funken aber Teils auch nicht richtig, habe ich endlich einen Code der für Nikon und Canon getestet ist und für Pentax und Sony mit dem Oszi überprüft ist.
- Der Quellcode ist weites gehend von MasterFX übernommen, allerdings musste ich die Wartezeiten für die Hi-TechC-Delay Funktion anpassen.
- Eine weitere Änderung liegt bei mir auch bei der Funk-Funktion vor. In dieser wird bei mir für alle vier genannten Modelle der Code abgeschickt und die Funktion findet nicht im Interrupt statt.
- Des weiteren habe ich auch nur einen Taster im Layout. Um mit diesem aber auch mit 2s Verzögerung auszulösen, habe ich eine Schleife erstellt, die die Zeit des Tastendrückens "misst" und anhand der Länge des Drückens die Verzögerung einstellt. Oder für nicht Technik begeisterte: "Drück 2 Sekunden drauf und es wird verzögert, ausgelöst."
- Da ich 4 Modelle mit einem Tastendruck auslöse habe ich die "Modulations-Makros" von MasterFX in Funktionen umgeschrieben. So konnte ich ~200byte Code sparen, was bei einem PIC12F615 20% ausmacht.

Im Anhang sind der Stromlaufplan, das "Compiler-Projekt" für MPLab 8.6x und Bilder meiner fertigen Auslöser.

Edit 19.05.2011:
Die Gehäuse, die LED's und die Batteriefassungen habe ich bei Reichelt bestellt. Alles andere (Widerstände, Taster, Platinen, Kupferfolie als Minus-Pol) lag bei mir auf der Arbeit rum.

Edit 20.05.2011:
Nach den interessanten Diskusionen auf Seite 24, habe ich Timings überarbeitet und verbessert. Der neue Code ist im Zip-File hinterlegt. Pentax läuft nun richtigerweiße mit ~38kHz und nicht mit ~40kHz.

Edit 20.05.2011_2:
Mir ist eben aufgefallen das man beim compilieren mit dem Hi-Tech Compiler auf den Modus achten muss. Stellt man ihn von Lite auf Pro um stimmen die Timings nichtmehr.

Bei Sony gab es noch kleinere Macken die jetzt behoben sind.
 
Zuletzt bearbeitet:
Es wäre jetzt richtig genial wenn jemand Zugriff auf alle Modelle mit 38-40kHz hätte und testen könnte ob nicht vielleicht 38,9kHz oder 39,3kHz für alle
Das sollte bei allen (außer Canon) ohne weiteres Möglich sein.
Die meisten IR-Receiver haben eine 3dB Bandbreite von ±5%.
Die Reichweite geht dann eben auf 25% zurück wenn die Modulationsfrequenz um ±5% abweicht.
Da alle, bis auf Canon, mit 38-40kHz arbeiten hast du bei 39kHz im schlimmsten Fall so 60% der Reichweite

Gratulation zu deiner FB, sieht ja ganz nett aus...
 
Es wäre jetzt richtig genial wenn jemand Zugriff auf alle Modelle mit 38-40kHz hätte und testen könnte ob nicht vielleicht 38,9kHz oder 39,3kHz für alle Modelle zuverlässig funktioniert. Somit könnte man eine ganze Menge an Code sparen.

kannst das mal erklären ? viel. stell ich mich ja grad doof an, aber was meinst du

alle FB Codes C N P mit 38-39 kHz wohin ? oder mit 38,9-39,3 auf alle Cams ?

wie stellst du dir das vor ? morgen ist Stammtisch, C und P ist vertreten, N mögl. auch, mein "Sender" ist noch Steckbrett, kann alle Frequenzen einproggen, nur seh ich kaum Sinn drin, die Empfänger sind eh so breitbandig das +-10-20% an der Sendefrequenz "nur" :rolleyes: die Reichweite beeinflußt, das restliche Timing/Pulsfolge macht die Funktion

glaubst du bei diesen 50 Ct Artikel IR an promille genaues Timing ?
das würde ein Geschrei geben wenn kein IR FB Auslöser mehr sicher funzt

Oder für nicht Technik begeisterte: "Drück 2 Sekunden drauf und es wird verzögert, ausgelöst."

heisst aber auch du hast immer ne Verzögerung drin, wie soll der Controller wissen das du 2s drückst ? wenn er nicht wartet, es kann nur so sein das er auslöst wenn man loslässt :D somit umgeht man die Verzögerung das der Controller wartet bis 2s gedrückt sind

also einfacher ausgedrückt, er reagiert nicht auf die Drückzeit sondern auf die Loslasszeit ?
 
kannst das mal erklären ? viel. stell ich mich ja grad doof an, aber was meinst du

alle FB Codes C N P mit 38-39 kHz wohin ? oder mit 38,9-39,3 auf alle Cams ?
Er würde am liebsten nur eine Modulations-Frequenz nehmen, mit der alle Cams klarkommen.
Ausschlaggebend für das Erkennen des "HIGH" oder "LOW" ist aber die Zeit die nach der Demodulation erkannt wird. Die Empfindlichkeit der Modulationsfrequenz ist ja von mir bereits genannt worden und vom IR-Empfänger abhängig. Dahinter ist aber noch die Logik die das demodulierte Signal erkennen muss, und die misst die Länge des High oder Lows vom demodulierten Signal.
Wenn ich also ein "PULSE_39k" mache (anstatt z.b. Pulse_36k), sollte man lieber die Toggle-Zeiten anpassen, so dass die High-Zeit des Signals wieder passt.
Also anstatt
Code:
for(i=0;i<494; i++)
   PULSE_38k();
sollte man nicht einfach
Code:
for(i=0;i<494; i++)
   PULSE_36k();
machen sondern
Code:
for(i=0;i<468; i++)
   PULSE_38k();

dann Funktioniert das Ausslösen weiterhin zuverlässig, jedoch mit verringerter Reichweite.

Wenn man das jedoch so löst wie ich - über Makros - dann spart man selbst mit einem identischen "PULSE_XXk" praktisch kein Speicher ein, da es eine einfache Textersetzung ist, welche jedoch durch die kompileroptimierung ggf. auf die gleiche "vom Compiler erstellte" "delay-funktion" zugreift.
 
Zuletzt bearbeitet:
kannst das mal erklären ? viel. stell ich mich ja grad doof an, aber was meinst du

alle FB Codes C N P mit 38-39 kHz wohin ? oder mit 38,9-39,3 auf alle Cams ?
Es geht um die Cameratypen die mir 38 bis 40 kHz Moduliert sind. Da fällt Canon ja bei raus.

heisst aber auch du hast immer ne Verzögerung drin, wie soll der Controller wissen das du 2s drückst ? wenn er nicht wartet, es kann nur so sein das er auslöst wenn man loslässt :D somit umgeht man die Verzögerung das der Controller wartet bis 2s gedrückt sind

also einfacher ausgedrückt, er reagiert nicht auf die Drückzeit sondern auf die Loslasszeit ?
Ja, eine "Verzögerung" habe ich drin wenn C und S verzögert ausgelöst werden sollen. Sollen sie direkt ausgelöst werden, reicht das kurze Betätigen des Tasters. Betätigen heißt das C und S erst mit dem loslassen auslösen. Wie der Controller merkt das ich ~2s drücke erreiche ich hiermit:
Code:
	while(GP2 && (pincount<=250))	// Tastentruck für verzögertes Auslösen messen
	{				// Automatischer Abbruch bei langem drücken
		pincount++;
		DelayBigUs(9600);
	}
//---------------------------- direktes Auslösen
		cmd = 0x2D;					// Sony
		k = 7;						// Canon

	if(pincount>=200){				// verzögertes Auslösen
		cmd = 0x37;					// Sony
		k = 5;						// Canon
	}
Mit GP2 wird der Pin des Controllers abgefragt an dem der Taster ist.
 
Wenn ich also ein "PULSE_39k" mache (anstatt z.b. Pulse_36k), sollte man lieber die Toggle-Zeiten anpassen, so dass die High-Zeit des Signals wieder passt.
Also anstatt
Code:
for(i=0;i<494; i++)
   PULSE_38k();
sollte man nicht einfach
Code:
for(i=0;i<494; i++)
   PULSE_36k();
machen sondern
Code:
for(i=0;i<468; i++)
   PULSE_38k();

genauso hab ich das verstanden, nur die Frequenz austauschen geht nicht !

es würde zwar wie gesagt den Code verschlanken, aber ich sehe da keinen Sinn drin, warum künstlich die Reichweite beschränken, was die Cams wollen sollen sie bekommen
 
...
Wenn man das jedoch so löst wie ich - über Makros - dann spart man selbst mit einem identischen "PULSE_XXk" praktisch kein Speicher ein, da es eine einfache Textersetzung ist, welche jedoch durch die kompileroptimierung ggf. auf die gleiche "vom Compiler erstellte" "delay-funktion" zugreift.
Ja das habe ich gemerkt, deshalb habe ich bei mir Funktionen geschrieben was sich in der Speicherbelegung stark bemerkbar machte. ~200Byte sind es weniger geworden.

Edit:
Ich glaube das ich für Pentax doch den Code umschreiben sollte.
Edit2:
Da Glauben nicht Wissen ist, habe ich den Code jetzt geändert und in meinem Post aktualisiert. Neben 38kHz habe ich die 40kHz nochmals verbessert. Da kam bei genauerem hinschauen nur 39,6kHz raus. Desweiteren habe ich aber auch die Schleifen für die Bursts angepasst. Ich komme zwar nicht überall auf die glatte Zeit, aber 5% Schwund hat man ja immer irgendwo. :D
 
Zuletzt bearbeitet:
Kleine Frage:
Was macht eigentlich der Canon RC-6 Code?

hab es nicht geschafft die Codes alle mit 39 kHz an C N P zu testen, auch wegen der notwendigen Anpassung der Pulslängen

aber alle C N P sind nun bei mir gelaufen (nach Anpassung der Timings für meinen internen RC, der lief etwas schneller, da mussten die waitµs verlängert werden)

hast du meinen Code schon beguckt ? die deadlocks ?
 
hab es nicht geschafft die Codes alle mit 39 kHz an C N P zu testen, auch wegen der notwendigen Anpassung der Pulslängen

aber alle C N P sind nun bei mir gelaufen (nach Anpassung der Timings für meinen internen RC, der lief etwas schneller, da mussten die waitµs verlängert werden)

hast du meinen Code schon beguckt ? die deadlocks ?
Von Canon habe ich auch nicht gesprochen. Zu deinem Code bin ich leider noch nicht gekommen. Steht aber auf meiner Todo-Liste für den Monat.

Bin ich Blind oder sehe ich gerade die Antwort auf die RC-6 Frage nicht? Oder war dein Zitat nur ein versehen? :confused:
 
WERBUNG
Zurück
Oben Unten