Problems with DigisparkIRLib

[dougal]

I'm trying to use DigisparkIRLib, but I can't get any of the 'send' demos to compile. If I try to compile IRsendDemo, I get this error:

Code: [Select]

Build options changed, rebuilding all
IRsendDemo.ino:11:1: error: 'IRsend' does not name a type
IRsendDemo.ino: In function 'void loop()':
IRsendDemo.ino:22:5: error: 'My_Sender' was not declared in this scope
Error compiling.

So, I looked through the IRLib source and figured out that I need to define USE_IR_SEND. Adding that before the library include, I now get:

Code: [Select]

IRsendDemo.cpp.o: In function `IRsend':
/Applications/Arduino IDE - Digistump Release 1.5.8C.app/Contents/Resources/Java/hardware/digistump/avr/libraries/DigisparkIRLib/IRLib.h:286: undefined reference to `IRsendBase::IRsendBase()'
collect2: error: ld returned 1 exit status
Error compiling.

And there, I'm stumped. Somebody hit me with a clue-by-four.

[RC Navy]

Hi dougal,

where did you declare USE_IR_SEND symbol, in IRLib.cpp?
The good way is just to uncomment #define USE_IR_SEND in IRLib.h: this will activate the send code in the .h AND the .cpp files.

Please, have a try: I can't remember if I had fully tested the send part of this library.
When I ported this library two years ago, my need was only to receive...
The aim of these directives of compilation was to generate a smaller code as possible for the Digispark.

[dougal]

I put the #define just before the IRLib.h #include.

Any idea why it thinks IRsendBase::IRsendBase() is an undefined reference?

[RC Navy]

You have to put the #define USE_IR_SEND inside the IRLib.h file otherwise it won't be taken into account into the IRLib.cpp and IRsendBase::IRsendBase() won't be referenced.

[dougal]

Ah, yes, that works (along with changing the MY_IR_PROTOCOL define in IRLib.h to match the sketch or defining ALL_IR_PROTOCOL).

It isn't very convenient to have to modify the library files for each project, but I guess that's the trade-off for being able to only link in the parts that you need.

Next question: Are there any conflicts between IRLib and TinyPinChange? I'm trying to use them together, with TinyPinChange monitoring a button, then sending an IR code on button press (with some software debounce based on a millis() counter). But what's happening is that my test LED is coming on and never turning back off again.

But when I remove IRLib and replace it with simple digitalWrite calls to set my output pin high or low, it functions correctly.

[dougal]

Hmmm. I pulled out TinyPinChange and used simpler button state tracking, but I'm still getting the same problem. Once I call My_Sender.send(), my LED turns on, and never turns back off again.

[RC Navy]

I fixed the compilation issue for IRsend::send() when defining a single protocol with "#define MY_IR_PROTOCOL   PROTO_xxx" in IRLib.h.

The changes are:

Code: [Select]

void IRsend::send(IRTYPES Type, unsigned long data, int nbits)
{
switch(Type) {
#if defined(ALL_IR_PROTOCOL) || (MY_IR_PROTOCOL == PROTO_NEC)
case NEC: IRsendNEC::send(data); break;
#endif
#if defined(ALL_IR_PROTOCOL) || (MY_IR_PROTOCOL == PROTO_SONY)
case SONY: IRsendSony::send(data,nbits); break;
#endif
#if defined(ALL_IR_PROTOCOL) || (MY_IR_PROTOCOL == PROTO_RC5)
case RC5: IRsendRC5::send(data); break;
#endif
#if defined(ALL_IR_PROTOCOL) || (MY_IR_PROTOCOL == PROTO_RC6)
case RC6: IRsendRC6::send(data,nbits); break;
#endif
#if defined(ALL_IR_PROTOCOL) || (MY_IR_PROTOCOL == PROTO_PANASONIC_OLD)
case PANASONIC_OLD: IRsendPanasonic_Old::send(data); break;
#endif
#if defined(ALL_IR_PROTOCOL) || (MY_IR_PROTOCOL == PROTO_NECX)
case NECX: IRsendNECx::send(data); break;
#endif
#if defined(ALL_IR_PROTOCOL) || (MY_IR_PROTOCOL == PROTO_JVC)
case JVC: IRsendJVC::send(data,(bool)nbits); break;
#endif
}
}

Now, it compiles by defining for example "#define MY_IR_PROTOCOL   PROTO_JVC" rather than "#define ALL_IR_PROTOCOL" in IRLib.h.

The following (fake) sketch produces 38KHz bursts on Digispark pin#1 that I can see on my oscilloscope: it seems to work fine.

Code: [Select]

#include <IRLib.h>

IRsend My_Sender;

void setup()
{
}

//send a code every time a character is received from the serial port
void loop() {
    My_Sender.send(JVC,0xc2d0,1);//   delayMicroseconds (50);
    My_Sender.send(JVC,0xc2d0,0);   delayMicroseconds (50);
}

You can find the updated librarie on my Github repository:
https://github.com/RC-Navy/DigisparkArduinoIntegration/tree/master/libraries/DigisparkIRLib

Don't forget to declare the rigth protocol you use in IRLib.h and the IR output is Digispark pin#1 for the IR led.

[dougal]

For the record, I still never got this working right. When I remove the IRLib bits and replace them with a simple digitalWrite to turn my LED on and off, it works as expected: I press my button, and the LED lights for half a second.

But when I change it to use MySender.send(), the LED turns on and never goes off again.

Here is the code in question:

Code: [Select]

/* Make sure these are defined in IRLib.h */
//#define USE_IR_SEND
//#define MY_IR_PROTOCOL PROTO_SONY

#include <IRLib.h>

// Which pin drives the LED -- IRLib hardcodes to pin 1
#define LEDPIN 1
 
// Which pin has the button connected
#define BUTTONPIN 0

// How many milliseconds do we want to spend sending the signal
#define TIMEOUT 500UL

uint8_t ButtonPressed = 0;
uint8_t ButtonPrev = 0;
uint32_t LedMs = 0;

IRsend My_Sender;

void setup() {
  pinMode(BUTTONPIN, INPUT);
  digitalWrite(BUTTONPIN, LOW); // ensure it's low to start with. probably not needed.
  pinMode(LEDPIN, OUTPUT);
}
 
void loop() {
  // Both low, wait state, read button
  if (! ButtonPressed && ! ButtonPrev) {
    ButtonPressed = digitalRead(BUTTONPIN);
  }
   
  // Perform button actions, and debounce
  if (ButtonPressed && ButtonPressed != ButtonPrev) {
    ButtonPrev = HIGH;
    ButtonPressed = HIGH;
    LedMs = millis();
  }
  if (ButtonPrev) {
    if (millis() - LedMs >= TIMEOUT) {
      // Timed out, turn it off
      digitalWrite(LEDPIN, LOW);
     
      ButtonPressed = 0;
      ButtonPrev = 0;
    } else {
      //My_Sender.send(SONY,0xa8bca, 12);
      digitalWrite(LEDPIN, HIGH);
    }
  }
}
 


[dougal]

I'm still fiddling with this, though I'm currently prototyping with a different MCU (I'll try again with a Digispark when I have more time for experimentation). The background here is that I'm building a TV mute control for my special-needs son, who has trouble with the small buttons on the regular television remote. I was able to make a working prototype with a pushbutton (using software debounce), and it correctly sends the "mute" command to our television.

The problem I have now is that the range is too short -- it only works if the device is within about 1m of the television. I'm going to need it to work at a distance of about 3-5m. After a little Googling, it seems that there are few different things you can change to increase the range:

• Use more power (higher current to drive the LED, and/or use more LEDs)
• Use lenses to focus the signal
• Get a better wavelength match

Since it *does* work, I feel like I can ignore the wavelength issue. I doubt it would affect the range a whole lot, anyways.

I'd rather not mess with lenses if I don't have to. I don't recall really seeing any in most commercial remotes?

So I'm looking at power. Obviously, I can't drive a lot of current from a microcontroller pin, so I figure I need to use a transistor, and let the LED pull current straight from my power source. Also, I might try ganging up three or four LEDs in parallel.

The infrared LED I'm using says that while the typical current draw is 20mA, it has a maximum tolerance of 100mA. Looking at an LED calculator for four LEDs in parallel, it's saying I just need about 6ohms for my current-limiting resistor with a 3V source (I'm hoping to use a couple of AAA batteries, with a boost to power the MCU -- and even with a 5V source, we're still only talking about 15ohms).

Since the IR signal is modulated at 38kHz and is of very short duration, I'm thinking that I could probably just omit the resistor entirely. Should that be safe enough? Alternately, I'm guessing that I can probably power them at even higher currents, but then I probably *would* need a resistor.

Thoughts?

[dougal]

Thanks for the insights, @Ralf. I'll just have to experiment with a few things. The IR LED I'm using is an ancient Radio Shack model that I dug out of my parts bin. Perhaps it was just designed for more short-range applications (like maybe a beam-break system for a doorway). I have some other IR LEDs that I can pull out, and maybe I'll break down and buy some more new ones that might be more suitable.

I was also looking at the design of the Adafruit TV-B-Gone for ideas.

[defragster]

dougal: does this look like it might do what you want SparkFun Max Power IR LED Kit: https://www.sparkfun.com/products/10732

I got one or more I haven't powered up yet - if the wavelength is a match - if nothing else it might show you how to wire a transistor.

[dougal]

@defragster -- Yeah, that's basically what I was planning to do. I know I have some PN2222s at home, so I should be able to experiment more with it. Plus, I have some more IR LEDs to play with.

And now that I have a working prototype using a Pro Trinket, and I have a better idea of how the IRLib code fits together, I'll probably try it with a Digispark again.

Then the next fun thing will be researching how to use low-power sleep mode, and wake up on button press. Any pointers on that?

[defragster]

@dougal Good luck with the remote.  Came here to post on the right thread -

If you get the transistor and blow wimpy IR's - Here are some 75 cent adafruit hi power - you can pulse with 1 Amp!  https://www.adafruit.com/products/387

"continuously (for 'night vision' illumination) with 100mA and for IR remote application they can take up to 1 Amp pulses"

[dougal]

Yeah, I had spotted those. Have some in my shopping cart, though I haven't actually ordered them yet.

I did rework the circuit to incorporate a 2N3904 transistor, which greatly improved the range. Sometime this week, I'm going to try the IRLib on Digispark again, but if I feel like I'm spending too much time fighting that, I can fall back to using a Digispark Pro or the Pro Trinket again. 

After settling on the controller, I'll experiment with multiple IR LEDs to improve the effective angle and range (right now, it seems to have a pretty tight beam angle). Then I need to find something to use for my enclosure. Maybe the ubiquitious Altoids tin, if nothing else.