Why SIRC decoding will not work?

[jayanth.devarayanadurga]

I am attaching my SIRC decoding project files. The Tx send IR data without carrier. The code which sends data with carrier is commented in Tx.c. IR data is sent continuously every 45 ms. The receiver has to receive ircode and take action based upon code.

https://www.sbprojects.com/knowledge/ir/sirc.php

button 1 sends the ir data shown in image. IR data = Start bit (2400 us high + 600 us low) + 7 command bits (LSB first) + 5 address bits (LSB first)

command and address bits - 1 = (1200 us high + 600 us low), 0 = (600 us high + 600 us low)

S 0 1 0 0 1 1 0 0 0 1 0 1 (irCode = (ADDR MSB)10100(ADDR LSB) (CMD MSB)0110010(CMD LSB) 1(S))

 

[hexreader]

Re: Why this SIRC decoding not working?

First problem is in TX.c

You are using PORTB for input, but have set TRISB for all outputs.

I will look for more errors....

 

[jayanth.devarayanadurga]

Re: Why this SIRC decoding not working?

Thank you hexreader. I fixed the TRIS but still Rx is receiving only bit 0.

What are the other mistakes?

 

[hexreader]

Re: Why this SIRC decoding not working?

I am still working out how your receive code works, but....

You seem to be looking for a start bit of length 2400 uS. What happens if the start bit is 2399uS or 2401uS?

Shouldn't your code cater for a range of start bit sizes? Or at least, say, anything over 2000uS?

Same looks true for the data bits. You appear to be looking for exact times of high and low, when real data is far from exact.

 

[jayanth.devarayanadurga]

Re: Why this SIRC decoding not working?

How to do that?

I modified a code I got here. I contacted its author and he said his code works. He also has posted a video there. **broken link removed**

 

[hexreader]

Re: Why this SIRC decoding not working?

I will look at the link you gave and see if I can work out what is going on. May take a few days.

In the mean time..... I assume that you have seen the many IR examples that I posted on the LIBSTOCK site?

 

[jayanth.devarayanadurga]

Re: Why this SIRC decoding not working?

Yes. I am checking the IR related files at libstock.com but I need code for SIRC. I found this a few days back but have not tested it.

https://www.vecoven.com/elec/ir/ir/main_c.html
https://www.vecoven.com/elec/ir/ir/ir2_h.html
https://www.vecoven.com/elec/ir/ir/ir2_c.html

https://www.vecoven.com/elec/download/download.html

 

[hexreader]

Re: Why this SIRC decoding not working?

I need code for SIRC.

I have provided many Sony SIRC codes, but none for PIC16F88.

http://www.libstock.com/projects/view/43/infrared-tx-rx-samsung-sharp-nec-sony-rc5-rc6-mce-toshiba-ir-easypic7-pic12-mmb18-mmb33-arm

 

[jayanth.devarayanadurga]

Re: Why this SIRC decoding not working?

Ok. I will modify the code for PIC16F88.

 

[nick703]

Re: Why this SIRC decoding not working?

hey jayanth which tool to use this waveform monitor ?

 

[hexreader]

Re: Why this SIRC decoding not working?

Next problem seems to be with Timer1. As far as I can tell it is interrupting every 100uS instead of every 600uS.

... and shouldn't an initial value be set for timer 1 before enabling the interrupt?

 

[jayanth.devarayanadurga]

Re: Why this SIRC decoding not working?

@nick703

I am using Oscilloscope in Proteus ISIS.

@hexreader

This is the TMR calculation I used.

TMR1 16 bit

Fosc = 4 MHz

TMR Prescalar = 1:4

TMR interrupt period with Fosc/4 and 1:4 PS =

1/((4 MHz/4)/4/65536) = 0.262144 sec = 262144 us

period of the frequency input to Timer 1 =

1/((4 MHz/4)/4) = 0.000004 sec = 40 us

This is the period of time for each count in Timer 1 i.e.

65536 * 40us = 262144 us

Required interrupt period = 600 us

600 us / 40 us = 15

65536 - 15 = 65521 = 0xFFF1

and shouldn't an initial value be set for timer 1 before enabling the interrupt?

You mean initially I have to load the TMRH and TMRL with 0xFF and 0xF1?

 

[hexreader]

Re: Why this SIRC decoding not working?

This is the TMR calculation I used.

I do not have the patience to do all of that maths. I also have a hatred of Proteus. I checked real hardware using an oscilloscope.

You mean initially I have to load the TMRH and TMRL with 0xFF and 0xF1?

This seems sensible to me (except 0xff70 gave me 600uS), but I have no idea what was in the head of the person who wrote this code.

There lies my problem... I don't understand what the original code author intended. My suspicion is that his thinking was flawed, but he got lucky and the code worked for him.

... or maybe the code author knew exactly what he was doing, and it is me that lacks understanding?

I can see the general principle, but debugging code that I do not understand is not easy.

 

[jayanth.devarayanadurga]

Re: Why this SIRC decoding not working?

How you got 0xFF70 value? Explain the calculation. I use both Proteus and hardware to test the working. As I don't have an oscilloscope at home I am testing in simulation. How to debug the interrupt codes using mikroC ICD? I have EasyPICv7.

I don't understand what the original code author intended. My suspicion is that his thinking was flawed, but he got lucky and the code worked for him.

... or maybe the code author knew exactly what he was doing, and it is me that lacks understanding?

Maybe the author didn't want to share his fully working code.


Edit: The author sent me another code through email. It works. If switch is open all receivers are disconnected. Master sends IR data and slaves display received data. I am attaching the working files.

 

[hexreader]

Re: Why this SIRC decoding not working?

How you got 0xFF70 value? Explain the calculation.

No calculation involved. I did it this way..

1) I set TRISA=0; to set PORTA all output - for diagnostic use
2) I toggled a PORTA bit every time a timer1 interrupt was detected.
3) I looked on an oscilloscope to see the resulting pulse width.
4) I used trial and error with increasing and decreasing timer 1 reload value until the oscilloscope showed 600uS pulse width high, 600uS low.

Not very scientific, but avoids mistakes with calculations.

- - - Updated - - -

If you have easyPIC V7, then my LIBSTOCK examples will give you loads of diagnostic tools for IR, including a timing option, as long as you have a serial connection to your PC and a terminal program running on your PC.

Note that all of the 3-PIN IR receivers that I know of use inverted signals. The receiver output is normally high, and goes low when carrier is detected. All of my examples (except timing printout) rely on this inverted logic. Your code seems to use standard logic.

 

[nick703]

Re: Why this SIRC decoding not working?

for time rollover u should use the FFFF- F = FFF0 instead of 65536-15 = FFF1 .

 

[jayanth.devarayanadurga]

Re: Why this SIRC decoding not working?

@nick703

for time rollover u should use the FFFF- F = FFF0 instead of 65536-15 = FFF1 .

Why? Timer counts from 0 to 65535 = 65536 count in total.

@hexreader

I will try to check for inverted logic. So, Start bit at the TSOP1840 o/p will be 2400 us low and 600 us high, for data bit 0 it will be 600 us low and 600 us high and for data bit 1 it will be 1200 us low and 600 us high, right?

then my LIBSTOCK examples will give you loads of diagnostic tools for IR

Provide the link for IR tools. I could not find it at libstock. I only found some IR projects.


Post #14 updated.



Edit: I think it is better to use inverter at the TSOP18xx o/p.

 

[hexreader]

Re: Why this SIRC decoding not working?

Provide the link for IR tools. I could not find it at libstock. I only found some IR projects.

The most useful tool is attached - fit PIC18F45K22 to your EasyPIC7 board along with a 3-pin IR receiver and 2x16 LCD.

Read the comments at the top of the C file carefully.

Edit: I think it is better to use inverter at the TSOP18xx o/p.

I think you are making a big mistake. TSOP1328 or similar IR receivers are very, very popular. You may find yourself alone if you ignore the inverted logic that these receivers produce.

 

[jayanth.devarayanadurga]

Re: Why this SIRC decoding not working?

You didn't answer my question. I am asking again.

Start bit at the TSOP1840 o/p will be 2400 us low and 600 us high, for data bit 0 it will be 600 us low and 600 us high and for data bit 1 it will be 1200 us low and 600 us high, right?


In your isr code you have used

---

Code C - [expand]
1
2
3
4
5
6
if (INTEDG0_bit){
          INTEDG0_bit = 0;         // interrupt on B0 falling edge
      }
      else{
          INTEDG0_bit = 1;         // interrupt on B0 rising edge
}

---

Does your code execute faster than

---

Code C - [expand]
1
2
3
if (INTEDG0_bit){
          INTEDG0_bit = ~INTEDG0_bit;         // toggle edge detect
}

---

In your code explain this

---

Code C - [expand]
1
2
temp_ir = get_mark();
        if ((temp_ir > 150) && (temp_ir < 250)){

---

temp_ir will contain the TMRx value. How are you calculating the values 150 and 250 for testing 2.4 ms from temp_ir value?

 

[hexreader]

Re: Why this SIRC decoding not working?

Start bit at the TSOP1840 o/p will be 2400 us low and 600 us high, for data bit 0 it will be 600 us low and 600 us high and for data bit 1 it will be 1200 us low and 600 us high, right?

For Sony protocol, yes.

I do not remember writing this interrupt code - I suspect it is redundant and just something I was toying with. As for which code is faster, I have no idea. I am an amateur coder and program for fun, so efficiency is rarely of concern to me.

Values 150 and 250 were not calculated. I would have used option 9 of the utility program to return get_mark() values, seen a value of maybe let's say 192, and decided that 150 to 250 would be enough to tell the wanted time from a spurious signal. No calculation, no science, just measurement of real signals.

- - - Updated - - -

Just tried this old program again - and see that Sony start bit shows as value 157 to 159 when I try option 9 with my Sony remote. I think I may change this to 130 to 200

So 150 to 250 seems like a poor choice - now.

Seems like there are still improvements to be made, but then there is a disclaimer in the header text "// amateur code - use at your own risk - dodgy coding practices" :smile:

- - - Updated - - -

... by the way, if you use option 9 of my IR utility program, notice how mark signals are stretched and spaces are made smaller.

Notice also that timings change a little depending on how close you hold your remote control.

All of this is perfectly normal, and is a feature of how TSOP1840 works. This is why it is so important to allow a range of values for each pulse.

Some remote controls will give different timings with a partly flat battery, compared to a new battery.

To allow for variations, some of my IR receive programs check the length of the leader signal and adjust bit times accordingly. But not this program....