RC5 Modulation

[Jan H. (janiiix3)]

Hallo,

ich bin gerade dabei eine RC5 Modulation auf die Beine zu stellen.
Leider haut es noch nicht mit der Modulation hin. Das "HALF_BIT" Timing
haut soweit hin. Komme dort auf ca. 880µs.

Leider mache ich irgendwas gravierends falsch was die 36kHz Modulation 
angeht.
Bei der Modulation bin ich mir sicher, dass ich dort "alles" falsch 
gemacht habe.

Würde mich über hilfe freuen.

[Jan H. (janiiix3)]

Hallo Profis,

ich bekomme es leider nicht hin auf meinem RC5 - Decoder anständige 
Signal zu senden.

Fernbedienung vom TV klappt wunderbar.
Mein eigener "Kram" hingegen nicht.

Könnte es an meinem Quellcode liegen? Würde mich freuen, wenn mal jemand 
drüber schauen könnte, der mehr Ahnung von C hat als ich laie...

/*
 * Send_RC5.c
 *
 * Created: 24.06.2015 16:58:52
 *  Author: Jan
 */ 


#define F_CPU 16000000

#define RC5_HALF_BIT_TIME 8 // 8 * 110µs = 880µs

#define RC5_SEND_ON    PORTD |=  (1<<PD1)  
#define RC5_SEND_OFF  PORTD &= ~(1<<PD1)
#define RC5_SEND_TOGGLE  PORTD ^=  (1<<PD1)

#define RC5_SHOOT 890

#include <avr/io.h>
#include <avr/interrupt.h>
#include <util/delay.h>
#include <stdbool.h>


void rc5_send_command(uint16_t command);
void rc5_send_one(void);
void rc5_send_zero(void);
void delay_880(void);
void rc5_modulation(void);

volatile static uint8_t  rc5_half_bit_cnt, rc5_state;
uint16_t rc5_byte = 0x00;

int main(void)
{
  DDRB |= (1<<PB7);
  DDRD |= (1<<PD1);
  
//  TCCR0A   = (1<<WGM01);  // CTC TIMER0
  TCCR1B  |= (1<<WGM12);  // CTC TIMER1  
  
//  TCCR0B   = (1<<CS01);   // 8 ( ca. 110µs @ 16 MHz )
  TCCR1B  |= (1<<CS10);   // 1 ( ca. 72 kHz @ 16 MHz )

//  TIMSK0   = (1<<OCIE0A); // OutputCompare0A
  TIMSK1   = (1<<OCIE1A); // OutputCompare1A

//  OCR0A  = 0xE8;
  OCR1A  = 221; // habe ein wenig mit den Werten gespielt

  sei();
  
      
    while(1)
    {
    rc5_send_command(0b11000000001100); // switch tv on  
    }
}

/* send a 14 bit command to the IR - Receiver */
void rc5_send_command(uint16_t command)
{
  uint16_t send_byte = command;
  
  for (uint16_t x = 0 ; x < 14 ; x++)
  {
    if (send_byte & 0x2000)
    {
      rc5_send_one();
    }
    else
    {
      rc5_send_zero();
    }

    send_byte <<= 0x0001;
  }
    rc5_state &= ~(0x80);
}

/* send a logical one to the Receiver ( 1 --> 0 ) */
void rc5_send_one(void)
{  
  rc5_state |= 0x80;
  RC5_SEND_ON;
  _delay_us(RC5_SHOOT);
  rc5_state &= ~0x80;  
  RC5_SEND_OFF;
  _delay_us(RC5_SHOOT);
}

/* send a logical zero to the  Receiver ( 0 --> 1 ) */
void rc5_send_zero(void)
{
  rc5_state &= ~0x80;  
  RC5_SEND_OFF;  
  _delay_us(RC5_SHOOT);
  rc5_state |= 0x80;
  RC5_SEND_ON;
  _delay_us(RC5_SHOOT);
}

void delay_880(void)
{
  while(1)
  {
    if ((rc5_state & 0x01) == 0x01)
    {
      rc5_half_bit_cnt = 0x00;
      rc5_state &= ~(0x01);
      break;
    }
  }
}

/* called every 110 µs */
ISR(TIMER0_COMPA_vect)
{
  rc5_half_bit_cnt++;
  
  if (rc5_half_bit_cnt >= RC5_HALF_BIT_TIME)
  {
    rc5_half_bit_cnt = 0x00;
    rc5_state |= 0x01;      
  }
}

/* 72kHz */
ISR(TIMER1_COMPA_vect)
{
  if ((rc5_state & 0x80) == 0x80)
  {
    RC5_SEND_TOGGLE;      
  }
  else
  {
    RC5_SEND_OFF;      
  }
  
  
}

[Karl H. (kbuchegg)]

erste Frage: die 16Mhz sind gesichert?

zweite Frage: mit einer Handy Kamera kannst du die LED flackern sehen?
Der Vergleich mit deiner Fernbedienung zeigt, dass das Flackern beim 
Drücken einer Taste ungefähr gleich lang ist? (Ein Kommando dauert ca. 
25ms, also grob 2 Zehntel Sekunden. Das kann man auch optisch durch 
hinsehen noch ganz gut abschätzen, ob das hinkommt)

[Jan H. (janiiix3)]

Ja  meine 16MHz stehen, aber nur der Interne RC Oszillator!

Benutzen tue ich folgendes :

Diode : TSAL6100
Empfänger : TSOP34538

Ich habe das Datenpaket mit dem Oszi nachgemessen, dass kommt soweit 
hin.
Was mir aufgefallen ist, dass meine Schaltung (Sender) nicht wirklich 
eine große Weitreiche erreicht, hingegen meiner Fernbedienung.

Als Vorwiderstand habe ich ~30Ohm gewählt bei 5VDC.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Jan H. schrieb:
> Ja  meine 16MHz stehen, aber nur der Interne RC Oszillator!

Was benutzt du denn für einen MC? Der interne RC Oszillator liefert nur 
8 MHz und müsste mittels PLL, die es aber nur in wenigen Tinys gibt, 
multipliziert werden. Ein Ansprechen der PLL sehe ich aber bei dir 
nicht.
Interne 16MHz ohne solche Klimmzüge gibt es nicht.

> Als Vorwiderstand habe ich ~30Ohm gewählt bei 5VDC.

Das ist auch sehr wenig LED Strom. Fernbedienungen peitschen da bis zu 
100mA im Pulsbetrieb in die IR LED.

> eine große Weitreiche

Das finde ich super - erinnert mich an die Nabelschweden - äh, 
Nebelschwaden.

[Jan H. (janiiix3)]

Matthias S. schrieb:
> Jan H. schrieb:
>> Ja  meine 16MHz stehen, aber nur der Interne RC Oszillator!
>
> Was benutzt du denn für einen MC? Der interne RC Oszillator liefert nur
> 8 MHz und müsste mittels PLL, die es aber nur in wenigen Tinys gibt,
> multipliziert werden. Ein Ansprechen der PLL sehe ich aber bei dir
> nicht.
> Interne 16MHz ohne solche Klimmzüge gibt es nicht.
>
>> Als Vorwiderstand habe ich ~30Ohm gewählt bei 5VDC.
>
> Das ist auch sehr wenig LED Strom. Fernbedienungen peitschen da bis zu
> 100mA im Pulsbetrieb in die IR LED.
>
>> eine große Weitreiche
>
> Das finde ich super - erinnert mich an die Nabelschweden - äh,
> Nebelschwaden.

Benutze einen MEGA2560. Meine UART habe ich auch auf 16000000MHz 
ausgelegt, klappt auch damit.

Der Puls liegt bei ca. 100mA

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Jan H. schrieb:
> Benutze einen MEGA2560.

Nö, damit hast du die internen 8MHz des RC Oszillators. Lies mal bitte 
10.7 im Datenblatt.
Es gibt 2 interne Oszillatoren, den 8MHz RC Oszillator und den 128kHz 
Watchdog.

Das dein UART mit '16Mhz' Einstellung funktioniert, wundert mich nicht, 
denn wenn du ihn z.B. auf 19200 Baud konfigurierst und dann mit 9600 
Baud benutzt, klappt das natürlich.

[Jan H. (janiiix3)]

Matthias S. schrieb:
> Jan H. schrieb:
>> Benutze einen MEGA2560.
>
> Nö, damit hast du die internen 8MHz des RC Oszillators. Lies mal bitte
> 10.7 im Datenblatt.
> Es gibt 2 interne Oszillatoren, den 8MHz RC Oszillator und den 128kHz
> Watchdog.
>
> Das dein UART mit '16Mhz' Einstellung funktioniert, wundert mich nicht,
> denn wenn du ihn z.B. auf 19200 Baud konfigurierst und dann mit 9600
> Baud benutzt, klappt das natürlich.

Wieso komme ich dann mit meinen 16MHz auf meine genau errechnete ISR 
Überläufe?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Immer schwierig, zwei Teller gleichzeitig in der Luft zu halten...
http://www.makerconnect.de/index.php?threads/rc5-sende-routine.3729/

[Jan H. (janiiix3)]

Genau,

ich dachte ich mache einfach noch mal hier einen Theard auf (hätte ich 
drauf hinweisen sollen, sorry!) und jemand sieht vill. Einen Fehler 
direkt auf anhieb als Tagelang rum zu schreiben.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Jan H. schrieb:
> habe das Datenpaket mit dem Oszi nachgemessen, dass kommt soweit hin.
Wie weit ist "so"?
Kannst du einfach mal ein paar Screenshots eines Pakets zeigen?

> Was mir aufgefallen ist, dass meine Schaltung (Sender) nicht wirklich
> eine große Weitreiche erreicht, hingegen meiner Fernbedienung.
Wie ist dir das aufgefallen? Ich denke der tut noch gar nicht?

[Jan H. (janiiix3)]

Die Diode sendet schon was. Ca. 40cm Reichweite danach geht nichts mehr.
Aber es kommt nur Müll an.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Wo hast du denn da gemessen? Eine 36kHz oder 38kHz Modulation sehe ich 
da nicht.

[Frank M. (ukw) (Moderator)]

Jan H. schrieb:
> Die Diode sendet schon was. Ca. 40cm Reichweite danach geht nichts mehr.

Habs nicht nachgerechnet: Du sendest mit 36kHz Modulation? Abweichungen 
nach oben/unten äußern sich in geringerer Reichweite.

> Aber es kommt nur Müll an.

Für mich sieht das Encoding auch ziemlich kompliziert aus. Das geht 
einfacher. Zum Oszi-Bild: Der letzte Puls ist auf jeden Fall zu lang. 
Bei Biphase-Kodierung (Manchester) kann es prinzipbedingt nur Pulslängen 
mit 1- oder 2-facher Länge geben.

Warum ist das Signal auf dem Oszi invertiert (zu dem FB-Signal)?

[Jan H. (janiiix3)]

Frank M. schrieb:
> Für mich sieht das Encoding auch ziemlich kompliziert aus. Das geht
> einfacher. Zum Oszi-Bild: Der letzte Puls ist auf jeden Fall zu lang.
> Bei Biphase-Kodierung (Manchester) kann es prinzipbedingt nur Pulslängen
> mit 1- oder 2-facher Länge geben.
>
> Warum ist das Signal auf dem Oszi invertiert (zu dem FB-Signal)?

Encoding?

Ich Codiere wenn nur was.

[Karl H. (kbuchegg)]

Frank M. schrieb:

> Für mich sieht das Encoding auch ziemlich kompliziert aus.

Im Programm ist noch jede Menge Müll von früheren Versuchen. So wie das 
bei Neulingen eben ist: eine einmal geschriebene Code Zeile wird auf 
keinen Fall gelöscht. Auch wenn sie keiner mehr braucht.
Drum sieht der Code so groß aus.

[Jan H. (janiiix3)]

Karl H. schrieb:
> Frank M. schrieb:
>
>> Für mich sieht das Encoding auch ziemlich kompliziert aus.
>
> Im Programm ist noch jede Menge Müll von früheren Versuchen. So wie das
> bei Neulingen eben ist: eine einmal geschriebene Code Zeile wird auf
> keinen Fall gelöscht. Auch wenn sie keiner mehr braucht.
> Drum sieht der Code so groß aus.

Was genau meinst du ???

[Karl H. (kbuchegg)]

Jan H. schrieb:
> Ja  meine 16MHz stehen, aber nur der Interne RC Oszillator!

Das kann doch der Mega2560 gar nicht.
Mehr als 8Mhz sind mit dem internen Oszillator nicht drinn.


Miss halt mal die Zeiten mit einem _delay_ms nach! Das ist nun wirkich 
nicht schwer.
Häng eine normale LED an einen Pin an und lass sie mittels _delay_ms 
1000 Millisekunden ein und 1000 Millisekunden aus blinken. Bei welchem 
F_CPU ergeben sich die 1 Sekunden korrekt?

#define F_CPU 8000000UL

oder

#define F_CPU 16000000UL

letzteres ist mit dem internen Oszillator nicht möglich.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Matthias S. schrieb:
> Wo hast du denn da gemessen?
Ja, das wäre sehr interessant. Ohne Angabe der Messpunkte sind das nur 
Pixelhaufen.
Das vierte Bit im "Meine_Sendung" sieht zudem schon recht seltsam aus. 
Zudem auch die Ruhepegel.

Ich würde einfach sagen: solange das eine Bild nicht wie das andere 
aussieht, ist die Marschrichtung klar: Angleichen.

Frank M. schrieb:
> Du sendest mit 36kHz Modulation?
Da ist keinerlei Modulation zu erkennen. Das was da zu sehen ist, ist 
ein rein digitales unmoduliertes Signal...

[Frank M. (ukw) (Moderator)]

Jan H. schrieb:
> Encoding?
>
> Ich Codiere wenn nur was.

Wenn Du das Signal einer Fernbedienung aufzeichnest und dann 
entschlüsselst, dann decodierst Du das Signal. Das macht zum Beispiel 
IRMP.

Wenn Du das Signal aufbereitest, um es zu senden, dann encodierst Du 
etwas. Das macht übrigens IRSND - zu finden hier:

     https://www.mikrocontroller.net/articles/IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder

Lothar M. schrieb:
> Da ist keinerlei Modulation zu erkennen. Das was da zu sehen ist, ist
> ein rein digitales unmoduliertes Signal...

Naja, wenn er einen TSOP zur Aufzeichnung verwendet, dann ist die 
Modulation bereits rausgefiltert. Dagegen spricht jedoch das invertierte 
Oszi-Bild. Leider hat er weder zur Modulation noch zur Aufzeichnung per 
Oszi etwas geschrieben, sondern meine Fragen geflissentlich ignoriert. 
Sein Problem, nicht meins.

[Karl H. (kbuchegg)]

Ich hätt halt mal einen Stufenplan gemacht

* abklären der µC Frequenz. Vorher ist alles andere Makulatur. Darüber 
darf es keine Unklarheiten geben

* dann bau ich mir den 38Khz Oszillator auf. Und den teste ich auch!
Der TO hat ein Oszi. Anstatt da rumzuhampeln, mach ich mir ein Programm, 
dass mit der Timer-Einstellung ein Dauersignal auf den Ausgang ausgibt. 
Da häng ich das Oszi an, und da sehe ich nach, ob die gewollten 38kHz 
auch wirklich 38kHz sind.

* und erst dann fange ich an, die Modulation des Trägers im Datentakt 
durchzuführen. WObei ich mir zuerst einfach mal eine Serie von logischen 
1-en auf den Ausgang lege und mit dem Oszi nachmesse, ob die Burstlänge 
stimmt. Danach dasselbe mit lauter 0-en. Aus Spass an der Freude leg ich 
dann vielleicht auch mal abwechselnd eine logische 1 gefolgt von einer 
logischen 0 auf den Ausgang um zu sehen, wie die bei Manchestercoding 
zusammenlaufen. Aber das ist Kür, rein zur Erbauung.

* und erst dann fang ich an mir darüber Gedanken zu machen, wie das 14 
Bit Datenwort aufgebaut sein muss


Klingt nach einem komplizierten Vorgehen?
Mag sein. Ich weiss aber eines: wenn ich so vorgehen würde, dann würde 
das alles schon längst laufen.
IMHO ist der Hauptfehler von Neulingen, dass sie nicht schrittweise 
geplant und gezielt vorgehen, sondern zu viel auf einmal wollen. 
Manchmal geht das gut, aber öfter als einem lieb ist landet man genau in 
der Situation des TO: nichts geht und keiner hat eine Ahnung warum 
nicht.
Bei schrittweisen Vorgehen kann mir das nicht passieren. Jeder SChritt 
wird getestet und solange ich mich nicht davon überzeugt habe, dass 
alles in Ordnung ist, wird der nächste Schritt nicht begonnen. Und ja: 
die SChritte fangen bei den ganz einfachen Dingen an. Wenn mir wer 
erzählt, dass sein µC etwas kann, was laut Datenblatt vollkommen 
unmöglich ist, dann denk ich mir meinen Teil, was er im Vorfeld alles 
geprüft hat.

[#schlau #meier (Gast)]

Habe mich damit auch schon beschäftigt und habe eine Fernbedienung für 
meinen philips-tv gebaut... beim Code habe ich mir [[sprut.de]] zur 
Hilfe genommen. Wenn du möchtest kann ich dir diesen Code gerne zukommen 
lassen, allerdings in Assembler.

Gruß

MC Supergeilermegaherrscher

[Frank M. (ukw) (Moderator)]

Karl H. schrieb:
> Ich hätt halt mal einen Stufenplan gemacht

Ja, auf jeden Fall.

> * dann bau ich mir den 38Khz Oszillator auf.

[Korinthe] RC5 verwendet 36kHz [/Korinthe]

[Karl H. (kbuchegg)]

Frank M. schrieb:
> Karl H. schrieb:
>> Ich hätt halt mal einen Stufenplan gemacht
>
> Ja, auf jeden Fall.
>
>> * dann bau ich mir den 38Khz Oszillator auf.
>
> [Korinthe] RC5 verwendet 36kHz [/Korinthe]

:-)

Mag sein.
Aber der von ihm verwendete TSOP ist ganz wild auf 38

Nicht das es jetzt eine grosse Rolle spielen würde. So eng sind die 
Filter auch wieder nicht.

[Harald W. (wilhelms)]

Karl H. schrieb:

> Bei schrittweisen Vorgehen kann mir das nicht passieren. Jeder SChritt
> wird getestet und solange ich mich nicht davon überzeugt habe, dass
> alles in Ordnung ist, wird der nächste Schritt nicht begonnen.

Ein solches Vorgehen war schon immer das eines guten Entwicklers.
Weit vor der Erfindung des Mikroprozessors

[Jan H. (janiiix3)]

So,

ich habe den PIN mal Togglen lassen.

Wenn ich meinen Timer1 (CTC) laufen habe, komme ich auf ca. 600ms bei 
einem _delay_ms(500);

und ohne Timer auf 504ms...

Ist wohl eine blöde Idee diese Verfahren mit dem externen RC Oszillator 
zu erledigen?

[Frank M. (ukw) (Moderator)]

Jan H. schrieb:
> Ist wohl eine blöde Idee diese Verfahren mit dem internen RC Oszillator
> zu erledigen?

Nein, das geht durchaus. Es gibt zwar manche Geräte der 
Unterhaltungsindustrie, die vom Timing her ziemlich pingelig sind, aber 
meist kommt man mit dem internen RC-Oszillator bei 8MHz aus.

Was brauchst Du:

1. Timer für Modulation, PWM mit 36 bzw. 38 kHz
2. Timer für die Datenbits

Dann ist der verbleibende Code minimal und muss sich nur noch um das 
Herausschieben der Bits zu kümmern. Delays brauchst Du dann auch nicht 
mehr, das erledigen die beiden Hardware-Timer.

Geh einfach so vor, wie Karl Heinz es skizziert hat. Mit der 
Brechstangen-Methode, alles auf einen Schlag zu erledigen, kommst Du 
nicht weiter. Dafür fehlt es Dir einfach an Know How.

[Jan H. (janiiix3)]

Frank M. schrieb:
> 2. Timer für die Datenbits

Du meinst, für die Zeitbasis von 889µs?

[Frank M. (ukw) (Moderator)]

Jan H. schrieb:
> Frank M. schrieb:
>> 2. Timer für die Datenbits
>
> Du meinst, für die Zeitbasis von 889µs?

Ja, genau. Ein Overflow-Interrupt bietet sich dafür an.

[Wolfgang (Gast)]

Karl H. schrieb:
> Aber der von ihm verwendete TSOP ist ganz wild auf 38

Sooh wild nun auch wieder nicht. Die Empfindlichkeit sinkt beim 
0.95-fachen der Nennfrequenz auf 70% und das würde die Reichweite mal 
gerade auf 84% schrumpfen lassen. Das merkt man fast gar nicht.