JP1 Remotes

[3FG]

I think 60KHz is high enough. Bang and Olafsen does of course run at 455KHz, and JP1 remotes can send these signals (PID 00EB, TV 0565, 0620, and Audio 0799). JP1 remotes can learn the signals in a sense, but detect the frequency as 0. It is possible to buy IR detectors which respond to at least a few MHz, but I don't really see much value in designing a circuit to support such detectors. I have seen no other consumer IR that runs above 60KHz.

As I understand it, detecting a single edge precludes capturing non-modulated IR signals, like Revox, Barco, Archer, PID 0000, and 0004. That's one of the deficiencies of the Widget approach. MiikeT's initial posts were interesting to me because it included detecting both edges,

Another issue with Widgets is the inability to accurately determine frequency for signal with short on bursts. As a practical matter, a true 56KHz signal may be decoded as 50KHz. I imagine the approach taken here will provide good frequency accuracy.

On a different tack, what do you guys think about the possibility to use a Leonardo or similar board with full speed USB capability (12Mbits/sec) to implement a Widget approach but using, say, 5uSec counting intervals? For single edges, that would be 1.6Mbits/sec into a computer. That way, the SRAM is only needed for buffering the USB communication.

[MikeT]

[3FG]

The non-modulated IR protocols mostly have such short on durations that modulation is not needed or in some cases not even practical. Probably the most challenging for a Widget is Barco:

[MikeT]

[3FG]

Yes, Barco is PID 002A.

[MikeT]

I've made a new version which supports 3 modes without recompiling. You have to send one of the characters 'a', 'r' or 'b' to activate these modes and they are only active until a signal has been captured:

press 'a' for aggregating capture
press 'r' for raw capture (rising edges)
press 'b' for raw capture (both edges)

The only one which can tell you the duty cycle is type 'b', but it takes twice as much time to process a edge and also the double amount of memory.

Raw capture never does aggregation (can be done in the PC if needed).

'r' mode doesn't print + or - before the numbers because only the time between rising edges is counted.

The polarity is now detected automatically and all #defines which enabled or switched functionality have been removed.

/edit: In the meanwhile I found my logic analyzer. 60kHz should not be a problem for 'a' and 'r'. When both edges are captured using 'b', it depends on the pulse-width if it can be handled.

Here the current output:

[MikeT]

I've improved the usability for switching between the modes. The command is now also accepted when a capture is already listening. After a capture has been finished, a new capture of the same type is started automatically.
The new source can be found here.

Michael

[MikeT]

[MikeT]

[MikeT]

[Barf]

Hallo Michael,

congrats to your progress, looks quite impressive. Sorry for not responding earlier; I was busy with getting IrScrutinizer 1.0.0 out.

IrScrutinizer 1.0.0's "Arduino capture interface" expects the Arduino to spit out strings like

[MikeT]

Hi Barf,

[MikeT]

[Barf]

I did a few minor changes, in particular to the output format, #ifdef-ed out stuff not needed for IrScrutinizer. The final outcome, as a new version of IrScrutinizer, called 1.0.1 was uploaded. I also removed some files not needed (here), and renamed the .cpp file to .ino. (Sorry, I was not motivated to go through the work of getting your makefile to work... ) I have tested with an Uno, a 10€ Chineses Nano-clone, and with the Mega 2560; all worked fine (using 115200 baud). I am using the sensor OPL551 for the first two, and a QSE159 (with hardware pull-up) for the Mega. Without having tested extensively: it appears to capture very reliably and exactly, subjectively better than the IrWidget. I also made some modifications to IrScrutinizer, in particular the baud rate is now user settable, and even saved in the program preferences (.i.e. between sessions).

Some comments:

- I put the hardware pull-up in #ifdef ENABLE_PULL_UP since I think it is better optional and selectable. (I have just bought 10 OPL551...)
- Would it be possible to make the used pin settable?
- I had to add a "dummy" gap at the end of the output, since IrScrutinizer expects Ir sequences to end with a gap. Logically, this should be the ending timeout: "logically", since we just detected a period of silence of exactly that duration, then we did not to wait any longer. Although your selected value now appears reasonable, I could not find it in the code. Ideally, it should be settable. Also, the initial timeout and the maximal signal length (as long as not limited by the allocated memory) should ideally be settable, or at least easy to read out.

Finally, thanx a lot for this cool piece of software!!

Edit (2014-06-28): version 1.0.1 has been deleted, since obsolete. Please use the current version instead.

[MikeT]