RC5 and BASCOM

Go To Last Post
15 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am playing around with the RC5 feature in bascom, and it picks up my TV remote just fine. the commands, and the 0 address.

BUT it wont pick up any of my VCR remotes, DVD remotes, and my old jerrold and hamlin cable box remotes.

whats up with that?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Maybe they don't use the RC5 protocol?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

how can you tell if they do or not.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the only remote it picks up is my dish remote which is programmed to my magnovox TV. the rest it wont pick up. dont know why.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Perhaps the other remotes in your house use a different protocol, as Cliff says. There's the Sony protocol, which is pretty common, and a few others.

I was writing a RC5 decoding library a week ago, and while it works fine it took a long time to twig on the fact that my TV remote was not RC5!

AFAIK there's really no way of knowing if a given remote is RC5, other than to test it on a known-good RC5 reciever. Perhaps make it into a project, a RC5 remote tester?

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:

AFAIK there's really no way of knowing if a given remote is RC5, other than to test it on a known-good RC5 reciever. Perhaps make it into a project, a RC5 remote tester?

How about just measuring the light pulse train lengths and spaces between them to get protocol independence?

A RC5 etc testers plus info about different protocols:

http://www.sbprojects.com/knowledge/ir/ir.htm

- Jani

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I guess this is yet another reason why oscilloscopes were invented!

BTW, maybe everyone already knows this but for testing remote designs at work we look at them with a webcam. This will show the infra-red that the human eye otherwise cannot see and is a useful check that you have got the basic circuit working! (it works because the CMOS/CCD sensor has a wider operating range than the mark 1 eyeball)

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It actually works with other devices too like black-and-white TV cameras, maybe even colour TV cameras, digital cameras, etc.

Some B&W camera modules have IR leds for night time illumination, so at least these will work.

- Jani

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i know the remotes are working, why? becuase i modified the original BASCOM code to output address and command to a VFD. everytime it loops you can see the VFD flicker.

well when i press a button on the non-detected remotes, it flickers alot faster, so i know its recieving commands from the remotes, but i wonder if it filters out all other addresses than 0, and 5, and stuff like that.

like if i made my address say 30 or something like that, would it reject? i dotn know.

but i know the remotes work. hehe. the IRassistent program for the PC picks up all my remotes. and i believe its RC5. it wont pick up my sony remote though.

i noticed in the application note from atmel about RC5 that its hardcoded to respond to certain addresses, not all of them.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the remote i was wanting to use for a project went to an old cable box.

it has a toshiba TC9132P controller chip.

i found a datasheet, but it doesnt quite say what coding scheme it is, but it shows a timing diagram. i just dont know how to take that diagram and make my own interpreter.

datasheet:
http://www.datasheetarchive.com/...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not all remotes are RC-5 as you see.

Sony uses its own SIRCS protocol, way different from RC-5, therefore it does not work.

That Toshiba protocol looks so ancient that I've never heard of anything that looks like that.

But looks very easy to receive. Wait for a rising edge, wait for a half bit time to get into center of a bit, and read the bit if it is 1 or 0. Wait full bit time to get the next bit, until all 16 bits are received. Basically what usart does, but the remote format cannot be fed to usart.

- Jani

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

unless its a 16bit USART.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jepael wrote:
Not all remotes are RC-5 as you see.

Sony uses its own SIRCS protocol, way different from RC-5, therefore it does not work.

That Toshiba protocol looks so ancient that I've never heard of anything that looks like that.

But looks very easy to receive. Wait for a rising edge, wait for a half bit time to get into center of a bit, and read the bit if it is 1 or 0. Wait full bit time to get the next bit, until all 16 bits are received. Basically what usart does, but the remote format cannot be fed to usart.

- Jani

i know how to wait for a rising edge. the rest im not sure on.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mbates14 wrote:
unless its a 16bit USART.

How many 16-bit USARTs have you seen? And how many AVRs have them?

- Jani

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mbates14 wrote:

i know how to wait for a rising edge. the rest im not sure on.

Let's pretend every bit is 1ms long. So 16 bits equals 16 milliseconds.

When you see the first edge, wait 0.5 milliseconds to get to the center of the bit time, and read the first bit. Then wait one full millisecond to get the center of the next bit time. Repeat until all 16 bites are read.

Use timer or something for waiting, or poll in a main loop, but never use delays in an interrupt, if you detect edges in an interrupt.

- Jani