JP1 Remotes

So, I would like to build something from an Arduino that will work with the sketch that you have provided. I have Arduino Nanos. I understand that I should use capture pin 8. Should I use an OPL-551 for this or something else. If not an OPL-551, what part do you suggest to work with your sketch? Thanks.

[quote="Barf
Having said that, I consider MikeT's solution for the Arduino (which is contained in IrScrutinizer 1.1.0, danke Dir Michael!!) as vastly superior to the IrWidget idea, much more accurate and reproducible captures.[/quote]

Does the "MikeT" Arduino solution actually count the raw pulses? Or is it yet another demod pulse width solution? I don't consider anything that is extracting timing from a demod, particularly accurate.

There are IR protocols, that are carrier-less, that cannot be captured at all using demod timing. On the other hand, the Widget, even though it counts pulses, can't handle carrier-less IR protocols, since it makes some implicit assumptions that are only true if there's a carrier.

Demod schemes also fail with 455 KHz IR carriers unless the demod is specifically designed for that frequency. I believe the Widget pulse counting scheme barely works with 455 KHz carriers.

Perhaps this MikeT Arduino solution is the cat's meow, even if a bit of overkill?

I had no problem purchasing an IR Toy, but maybe I was lucky?

MikeT reported his approach(es) here.

Hi Barf, I tried the receiver and sender sketches yesterday and it worked. I could receive, decode and correctly send codes. No hangs whatsoever. The other sketches I didn't try as they do not seem relevant at the moment: the girs is not yet documened and there seems not even to exist a possibility to select the girs in the GUI; the IrWidget is receiver only.

However, one problem exists: I noticed that it takes very long (1 min) to open the port on configure hardware tabs of the GUI. Apparently the IrScrutinizer waits for a certain string to be returned and which is not sent by the sketches. I could not identify this string by a quick look into the sources of the IrScrutinizer. Would you please clarify on this point? Thanks a lot!

StephenR0 wrote:So, I would like to build something from an Arduino that will work with the sketch that you have provided. I have Arduino Nanos. I understand that I should use capture pin 8. Should I use an OPL-551 for this or something else. If not an OPL-551, what part do you suggest to work with your sketch? Thanks.

Kewl. Yes it is pit 8 in Nano/Uno (pin 4 on Leonardo/Micro, pin 49 on Mega2560). For sending, uses pin 3 on Nano/Uno, pin 9 on Leonardo/Micro/Mega2560.

For sensors, it is not really critical. You can use any non-demodulating sensor, inverting or not, open collecor or not: The software finds out if the sensor is inverting, and there is an internal pull-up resistor enabled in the software (open-collector friendly). Some possible alternatives are: OPL-551 (official replacement of the discontinued QSE-159), OP-550, QSE-157, TSMP4138, TSMP1138, TSMP58000, SDP8600,... You can even use a photo diode/transistor or even a normal sending IR-LED. Here is a photo of a creation of mine, soldering a TSMP4138 directly to a Nano:

cauer29 wrote:Does the "MikeT" Arduino solution actually count the raw pulses? Or is it yet another demod pulse width solution?

See his own words in the thread 3FG linked. Basically, a timer is configured so the all the edges are registered, with high precision. MikeT's software has three modes: In raw mode, it sends all this data to the host. This requires too much space on e.g. an Uno to capure e.g. a NEC1. (Fine on a Mega though.) So there is also an "aggregating mode" which lumps them together into busts, while collecting pertinent parameters. This is what is used in the IrScrutinizer.

I had no problem purchasing an IR Toy, but maybe I was lucky?

I also got mine (two actually) within a day or two from the German firm i linked to. Do not get me wrong: I would love if the 'toy was to be had easily. Nice price, the right sensors and LED, open source and open hardware, possibility to write your own firmware. That is great! Just too bad if it has to be ordered from Asia, and is out of stock "often".

hanryz wrote:Hi Barf, I tried the receiver and sender sketches yesterday and it worked. I could receive, decode and correctly send codes. No hangs whatsoever. The other sketches I didn't try as they do not seem relevant at the momen

Nice. But what "other sketches"? There should be only GirsLite, Did some unintended junk slip through my packaging?

However, one problem exists: I noticed that it takes very long (1 min) to open the port on configure hardware tabs of the GUI. Apparently the IrScrutinizer waits for a certain string to be returned and which is not sent by the sketches. I could not identify this string by a quick look into the sources of the IrScrutinizer.

Try this: In the device mangager, check if there are "junk" entries under serial connections (COM) etc. Often, Bluetooth, ISDN, cell phone stuff, etc creates their own virtual serial ports there, since they believe that the user needs it. Try to delete all junk virtual ports there. I believe that RXTX (the java communication library) needs a lot of time listing the available serial devices in the presence of more-or-less functional pseudo-devices. (I did this on my windows 7 laptop, and the startup time went down from some 20 seconds just to a few seconds, just like on Linux).

You can also turn on the opion "verbose" in the options menu, that will give you some hint on what is going on, and may help debugging weird delays.

BTW, I should say that I have made quite some changes to MikeT's firmware, in particular refacturing the class structure. These changes have not been blessed (nor criticized) by him. Bugs etc are thus possibly introduced by me.

hanryz wrote:Hi Barf, I tried the receiver and sender sketches yesterday and it worked. I could receive, decode and correctly send codes. No hangs whatsoever. The other sketches I didn't try as they do not seem relevant at the momen

Barf wrote: Nice. But what "other sketches"? There should be only GirsLite, Did some unintended junk slip through my packaging?

I could identify the GirsLite and the IrWidget_Atmega328 sketches in the Arduino folder:). For the GirsLite I don´t even know how to set it to use in the IrScrutinizer. But don't worry about it. It's not a problem.

hanryz wrote:However, one problem exists: I noticed that it takes very long (1 min) to open the port on configure hardware tabs of the GUI. Apparently the IrScrutinizer waits for a certain string to be returned and which is not sent by the sketches. I could not identify this string by a quick look into the sources of the IrScrutinizer.

Barf wrote: Try this: In the device mangager, check if there are "junk" entries under serial connections (COM) etc. Often, Bluetooth, ISDN, cell phone stuff, etc creates their own virtual serial ports there, since they believe that the user needs it. Try to delete all junk virtual ports there. I believe that RXTX (the java communication library) needs a lot of time listing the available serial devices in the presence of more-or-less functional pseudo-devices. (I did this on my windows 7 laptop, and the startup time went down from some 20 seconds just to a few seconds, just like on Linux).

You can also turn on the option "verbose" in the options menu, that will give you some hint on what is going on, and may help debugging weird delays.

BTW, I should say that I have made quite some changes to MikeT's firmware, in particular refacturing the class structure. These changes have not been blessed (nor criticized) by him. Bugs etc are thus possibly introduced by me.

Nope, the ports real or virtual are not the problem. It is really the IrScrutinizer software which thinks that something needs to be received. I get "zero bytes returned" error after the 1min timeout (probably an exception thrown in your java code). Moreover, I see that the IrScrutinizer sends "\r" and waits for something when I use a Serial Monitor soft. Note that I see "\r" in both receiver and send modes. Could you please have a closer look on the things here?

Many thanks in advance!

hanryz wrote: I could identify the GirsLite and the IrWidget_Atmega328 sketches in the Arduino folder:). For the GirsLite I don't even know how to set it to use in the IrScrutinizer. But don't worry about it. It's not a problem.

It is a problem. I just checked the setup-distribution, the binary dirstribution, and the source distributions (for 1.1.0). There is simply not an IrWidget_* there.

At least presenlty, an IrScrutinizer version supports only the sketch that comes with it; for 1.1.0 it is called GirsLite, version ArduinoGirsLite 2014-06-07.

Nope, the ports real or virtual are not the problem. It is really the IrScrutinizer software which thinks that something needs to be received. I get "zero bytes returned" error after the 1min timeout (probably an exception thrown in your java code). ...

You appear to be using a firmware that I do not even know exactly what it contains. Please flash the supported firmware, as per above, first.

Barf wrote:

hanryz wrote: I could identify the GirsLite and the IrWidget_Atmega328 sketches in the Arduino folder:). For the GirsLite I don't even know how to set it to use in the IrScrutinizer. But don't worry about it. It's not a problem.

It is a problem. I just checked the setup-distribution, the binary dirstribution, and the source distributions (for 1.1.0). There is simply not an IrWidget_* there.

At least presenlty, an IrScrutinizer version supports only the sketch that comes with it; for 1.1.0 it is called GirsLite, version ArduinoGirsLite 2014-06-07.

Nope, the ports real or virtual are not the problem. It is really the IrScrutinizer software which thinks that something needs to be received. I get "zero bytes returned" error after the 1min timeout (probably an exception thrown in your java code). ...

You appear to be using a firmware that I do not even know exactly what it contains. Please flash the supported firmware, as per above, first.

You are right. The other sketches must be from a previous version. I reinstalled the software from the scratch and I don't see the other sketches anymore. However, you can believe me, your 1.1.0 version worked just fine with the send and receive sketches from the previous version. I will try to flash the girslite sketch onto arduino and report then. I assume that I will still have to select arduino in the GUI in order to communicate with the hardware? Thank you!

Barf wrote:Kewl. Yes it is pit 8 in Nano/Uno (pin 4 on Leonardo/Micro, pin 49 on Mega2560). For sending, uses pin 3 on Nano/Uno, pin 9 on Leonardo/Micro/Mega2560.

For sensors, it is not really critical. You can use any non-demodulating sensor, inverting or not, open collecor or not: The software finds out if the sensor is inverting, and there is an internal pull-up resistor enabled in the software (open-collector friendly). Some possible alternatives are: OPL-551 (official replacement of the discontinued QSE-159), OP-550, QSE-157, TSMP4138, TSMP1138, TSMP58000, SDP8600,... You can even use a photo diode/transistor or even a normal sending IR-LED. Here is a photo of a creation of mine, soldering a TSMP4138 directly to a Nano:

Thank you very much. That was very helpful. Now to build it!

Hi Barf, I tried the girslite sketch and it works insofar that i get the version when connected. However, when trying to capture something I fail to do so. I changed the capture pin to port D and input 2 and recompiled the sketch (D2 is my previous hw config which worked with IrRemote routines). Could it be IR sensor type issue with the Lib you now use or rather the A0 capture pin is hardcoded elsewhere? Thx alot

Barf wrote:

cauer29 wrote:Does the "MikeT" Arduino solution actually count the raw pulses? Or is it yet another demod pulse width solution?

See his own words in the thread 3FG linked. Basically, a timer is configured so the all the edges are registered, with high precision. MikeT's software has three modes: In raw mode, it sends all this data to the host. This requires too much space on e.g. an Uno to capure e.g. a NEC1. (Fine on a Mega though.) So there is also an "aggregating mode" which lumps them together into busts, while collecting pertinent parameters. This is what is used in the IrScrutinizer.

I had no problem purchasing an IR Toy, but maybe I was lucky?

I also got mine (two actually) within a day or two from the German firm i linked to. Do not get me wrong: I would love if the 'toy was to be had easily. Nice price, the right sensors and LED, open source and open hardware, possibility to write your own firmware. That is great! Just too bad if it has to be ordered from Asia, and is out of stock "often".

While I see the basic utility of MikeT's Arduino scheme, I think it has some decided disadvantages. It would seem to be time limited when compared to the Widget, which can capture IR macro sequences of essentially unlimited length. I personally have need to be able to capture very long macro sequences (~20 sec). Additionally, there are air conditioning units that send very long IR sequences that I suspect would not be capturable with MikeT's Arduino scheme.

Given the 3 options, Widget, IR Toy, Arduino, I see pluses and minuses for each. The Widget's overwhelming plus, is that it is a finished product that is ready to use right out of the box. There is no exposed circuit board to scare the crap out of hardware phobes. IR Toy and Arduino both suffer in comparison, as neither one is even slightly friendly to those not comfortable with using unfinished hardware products.

I should point out that the bulk of the people on this forum, would be entirely incapable of dealing with the IR Toy, much less MikeT's Arduino scheme, which is in a whole 'nother galaxy.

The main thing that MikeT's Arduino has going for it, is that given a user that is not afraid of unfinished hardware, it offers many opportunities for modifications. Especially given the widespread availability of Arduinos. I don't see that it is overwhelmingly superior to the Widget in technical capabilities. Neither can deal with carrier-less protocols. The Widget can (barely) work with 455 KHz IR protocols, where the Arduino cannot.

IR Toy on the other hand, isn't quite as readily available. I had difficulty ordering mine from SeedStudio (in China) because my credit card was consistently being refused authorization. Something to do with it being an out of country purchase, but I was eventually able to purchase the IR Toy using PayPal.

hanryz wrote: I assume that I will still have to select arduino in the GUI in order to communicate with the hardware? Thank you!

IrScrutinizer saves the last selected capturing (and sending) hardware to the preferences. However, it does not try to open it when it starts again, because I think that would have more potential problems than benefits, for example if the hardware is no longer present.

StephenR0 wrote:Thank you very much. That was very helpful. Now to build it! Smile

Good luck. Would be nice if you report your progress.

hanryz wrote:when trying to capture something I fail to do so. I changed the capture pin to port D and input 2 and recompiled the sketch (D2 is my previous hw config which worked with IrRemote routines).

No, you cannot change things like that. MikeT explans in the other thread that there is only one of his timers usable om Atmega328 (uno/Nano), two in Leonardo , two in Mega2560. They are connected to certain pins, non-configurable. (The Due is possibly different.) To use the alternative pin in Leonardo or Mega2560 (13 in Leonardo, 48 in Mega2560), use

#define ALTERNATE_PIN

in IrWidget.h. (My stuff, do not blame MikeT.) That are all the things configurable. BTW, I would never hard code anything like that without any good technological reason.

BTW, what hardware are you using?

I will certainly report my progress, maybe with pictures.

One thing I thought of, is both transmit and receive hardware required to work with your sketch? I noticed that you have both and I'm only interested in the receive part of it. Thanks.

The said sketch supports sending and capturing (I prefer to say "capturing" instead of "receiving" to distinguish from demodulating receive). If sending (capturing) hardware fails, only sending (capturing) will be non-functional.

But if your are getting the parts and getting the soldering iron hot, why not get the "whole shebang", including sending. You only need two more componets, a (e.g.) 100 ohm resistor and an IR LED. Cost, something like the fries at McDonalds...

Next time I order parts, I might get the sending parts. But I already have the capturing parts, so I thought I'd try with that. I just wanted to make sure that the lack of sending parts wouldn't cause it to fail. But you're right, I might as well put in the sending parts.