Show Posts
Pages: [1]
1  Products / Arduino Due / Re: DUE IRremote proof of concept on: April 16, 2013, 12:18:08 am
I'm satisfied with it's status now. I believe I corrected any conflicts that might arise from using analogWrite() and I added examples on how to use the new SAMSUNG(2) send and receive functions. As you can clearly tell I'm new to the forums as a poster, but I've been playing with the Arduino platform for about a year and a half now. I went ahead and posted my port to the library thread.
2  Products / Arduino Due / Re: Arduino Due libraries (official and 3rd party) on: April 15, 2013, 11:58:23 pm
I ported Ken Shirriff's IRremote library to work with the Due with a few improvements:

Note: Don't forget to use a transistor to drive the IR LED. It might work powered directly, but probably not for long. smiley
3  Products / Arduino Due / Re: DUE IRremote proof of concept on: April 15, 2013, 04:20:52 pm
My awesome wife just bought me a Due for an anniversary present and I promptly spent the weekend getting this to work among more boring projects.

I started working on integrating this into the already established library so I wouldn't need to update two different libraries as I find other IR to decode. I Googled "Arduino Due IRremote" and this is the thread I found. Since mantoui apparently was posting a challenge, I decided to take it up and provide a solution. I should probably note that though I'm sure no one will believe that I wrote much of this but, mantoui and I came up with very similar code.

I added clock timers and PWM channels to the timer selections so you can choose what's most appropriate. I purposely only provided clock timers that don't correspond to any pins on the Due. Also while I know there are more PWM channels that I could have made available, I wanted to stay away from pins that have other defined uses within the Arduino environment. It's also worth noting that using analogWrite() will be broken for PWM pins (it switches between PWM, TC and DAC as appropriate) if you send any IR since it only configures itself once. This might be an easy fix, but I haven't got around to it yet.

I added support for the ATtiny85 which I'm sure a lot of people figured out how to do. You just need to be mindful everything compiled is more than 8k, so you have to pick and choose and might even need to comment out entire decode sections to get it all to fit along with your actual code. If all you need is to just receive and maybe only send one or two protocols; it will fit. I was using it with I2C to perform parallel IR blasting and receiving.

I added two protocols: SAMSUNG and SAMSUNG2. SAMSUNG was given in a comment on the page, but I was surprised to never see it committed. SAMSUNG2 was discovered when I was working with one of my remotes. This protocol returns an address as well as a code. I still need to update the examples to include them.

As an added bonus I found this works surprisingly well with the a cheap 310MHz RF receiver when receiving X10 signals, but only on the Due for some reason. While the Uno would work mostly, it would pick up a lot more of the noise giving you lots of false marks and spaces. The Due in general seems much more crisp in the RF applications I tried out, but I'm getting a little off topic now.

Anyhow, here's the link:

Pages: [1]