[Unzap] IR-Transistor / Abschaltcodes

[Stefan Uhl]

* Alexander Neumann <fd0 at lochraster.org> [081015 10:59]:
> [Ich antworte mal direkt auf die Mailingliste]
> 
> * Stefan Uhl <s.uhl at gmx.net> wrote:
> > Das 3/4 klingt nach recht empfindlich... fein.
> 
> Ists auch, tut aber nur fuer Traegerfrequenzen zwischen ~15khz und ~80khz,
> alles schnellere bekommt den Fototransistor nicht lange genug auf, um den
> Widerstand runterzuziehen. 

Hmmm. Wie hoch ist das Rauschen? Wenn das klein ist, sollte eine kleine 
Messdifferenz ausreichen... Man kann dann nur kein fixen Schwellwert
verwenden...
Bis wohin kriegt man noch ne Messung mit mehr als 2 Bit Unterschied
zwischen an und aus? 

> Da koennte man in einer erweiterten Version der
> Hardware nochmal drueber nachdenken, dafuer verschiedene Widerstaende zu
> benutzen, die dann zb. durch Portpins vom Controller aus eingeschaltet werden.

Hmmm. Was ist die höchste Frequenz, die man mit dem Atmel so messen
kann? Jede Messung braucht 13 Takte. Setzt man 1Messtakt=2Systemtakte,
so sollte man 200kHz noch auflösen können. Die Messzeiten sind dann aber
kürzer als im Datenblatt angegeben. Das macht die Messungen ungenauer.
Aber welche Genauigkeit braucht man?

> > - Pulsweitencodierung, 
> 
> Hab ich generisch implementiert.

In der Firmware ja. Aber wie schreib ich die als YAML?
Macht es Sinn zwischen Pausencodierten, Pulsweitencodierten und
Mischungen zu unterscheiden? Wie wärs mit

  type: pwm
  pulse_one: 23
  pulse_zero: 46
  pause_one: 42
  pause_zero: 21 # auch nur die halbe Wahrheit...

Evtl. mit 

  pulse: zyxxzy 

als Alias für 

  pulse_one: zyxxzy
  pulse_zero zyxxzy

Für die ganzen Manchestercodierungen genauso. 
> > - ein Haufen Codes die zum Teil wiederholt, zum Teil invertiert wiederholt werden, 
> > - Codes die erst vorwärts und dann rückwärts abgespielt werden (sieht
> >   zumindest so aus...)

Sieht übrigens nur so aus. Das ist irgendein Sony-Code...

> > - seltsame Sendepausen verschiedener Längen, 
> > - komische Dinge am Ende der Codes (Etwa: Lange Pause, Zwei Pulse, längere Pause, 
> >   ein letzter Puls), 

Das ist vielleicht einfach nur Schrott, der am nicht gebraucht wird.
Aber woher wissen?

> Lohnt sich meist nicht, der Code selber (als Ein-Aus-Folge) ist kleiner, als
> eine generische Implementierung.
 
Kann man nicht einfach n Blöcke von abwechselnd pausencodierten Daten 
und Rohdaten nacheinander senden? Damit bekäme man einige Codes
wesentlich kleiner ohne sie zu verändern.

Das yaml wäre dann etwa:

  type: mixed
  blocks: 2
  type: pause
   .
   .
  pattern: [0x23,0x42]
  type: raw
   .
   .
   .


> > - Pausencodes mit zwei verschiedenen Pausenlängen für die 1 (etwa 4190 für die 
> >   erste 1 nach einer 0, 5220 für jede folgende),
> 
> Das sind meist nur der erste Puls und die erste Pause, so eine Art Header,
> damit sich der Empfaenger auf den Sender einstellen kann.
 
Nee. Da sind mindestens zwei Codes, die genau dieses Muster aufweisen.
Aber ich denke dafür lohnt es keine explizite Beschreibung... Außer wir
machen was für trinäre Codes, dann sinds mehr, aber wahrscheinlich
immer noch nicht genug...

> > - trinäre Codes (ich finde zumindest kein binäres Erklärungsmuster (etwa
> >   tvbgone055)
> 
> Stimmt, der ist komisch.

Eine Erklärung wäre, daß das Ding Adresse und Befehl mit verschieden
langen Pausen codiert und dann alles zweimal sendet.

> > - Manchestercode, bei dem ein Bit doppelt so lang ist wie alle anderen
> >   (Zeile 5 in tvbgone100)
> 
> Oder ein zwischen-Header?

Das ist tats"achlich ein doppelt langes Bit (eine 0, zwischen zwei
einsen). Der Code heißt rc6 und ist von Sony.

> > Wie hattest du vor, solche Dinge in YAML aufzuschreiben? Pausencodes
> > ohne Seltsamkeiten hab ich verstanden. Aber schon bei nec steig ich aus.
> 
> Eigentlich die meisten einfach als Puls-Pausenfolge, das ist am einfachsten.

Braucht aber mehr Platz. Die meisten Codes sind einfach
kleinzukriegen...

> Ich kann die Codes vom tvb-gone auch nicht verifizieren zum Teil, manche hab
> ich auf einer Universalfernbedienung wiedergefunden, die veraendern sich
> aber unter Umstaenden beim naechsten Druecken der Taste...

Toggle-Bits... Ich frage mich sowieso, wie exakt die Angaben sind. Bei
den Codes, die ich erkannt hab (<http://www.sbprojects.com/knowledge/ir/ir.htm>)
weichen die Angaben zu Frequenz und Puls/Pausendauer z.T. erheblich ab. 

> > Was ist mit den seltsamen Dingen am Ende? Wieso ist repeat: 2 und data:
> > [ 0x87, 0x22, 0xe0, 0x1f ]? Da ist doch schon das invertierte Bitmuster
> > angehängt. 
> 
> Ich speichere nur die 4 Bytes, den NEC-Code hab ich ja implementiert, und
> diese Funktion generiert mir auch diesen Kram am Schluss, der dem Empfaenger
> nur sagt "Taste immernoch gedrueckt".

Ich hätte gedacht, daß man nur die erste Hälfte der Bits braucht, da die
Zweite ja nur die Erste invertiert ist...

Braucht man den Kram am Schluß eigentlich?
Wenn ja: Viele codes haben sowas am Ende. Gibts da nicht ne generischere
Lösung? 

Grüße,
        Stefan


> _______________________________________________
> unzap mailing list
> unzap at lochraster.org
> http://lists.gnuzifer.de/mailman/listinfo/unzap