 |
JP1 Remotes
|
| View previous topic :: View next topic |
| Author |
Message |
Barf
Expert
Joined: 24 Oct 2008
Posts: 1415
Location: Munich, Germany
|
 Posted: Sun Feb 23, 2014 10:12 am Post subject: |
 |
|
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.
Last edited by Barf on Sat Jun 28, 2014 5:17 am; edited 1 time in total |
|
| Back to top |
|
 |
MikeT
Joined: 28 Oct 2010
Posts: 115
|
| Posted: Tue Feb 25, 2014 4:04 pm Post subject: |
|
|
| Barf wrote: | | I put the hardware pull-up in #ifdef ENABLE_PULL_UP since I think it is better optional and selectable. |
Normally the 20 to 50 kOhm pullup won't hurt even when not using an open collector output.
| Barf wrote: | | Would it be possible to make the used pin settable? |
There is not much choice for the pin. The ATmega328 only has one ICP pin, the ATmega32U4 has two and the ATmega2560 has four (but only two can be used in the Arduino Mega). Each of these ICP<n> pins is directly bound to a specific timer <n> so when changing the pin also the corresponding timer has to be selected. This can be done by setting the #define CAP_TIM to <n> and adapting the CAP_PORT and CAP_PIN accordingly.
[quote="Barf"]I had to add a "dummy" gap at the end of the output. Although your selected value now appears reasonable, I could not find it in the code. Ideally, it should be settable.[quote="Barf"]
It is hidden in the following line:
| Code: |
if(ovlCnt >= (_BV(RANGE_EXTENSION_BITS) - 1))
|
This means "when the number of timer overflows is greater than 2^numberOfBits reserved for the range extension" so the value cannot be stored in a single 16 bit word.
To calculate the timeout value just call clocksToMikroSeconds(unpackTimeValSwapped(0xffff))
Instead of using (_BV(RANGE_EXTENSION_BITS) - 1) you can also use a smaller value to reduce the timeout.
| Barf wrote: | | 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. |
The initial timeout is infinite which means the capture doesn't have to be started explicitly. It just starts with the selected mode and keeps looking for either an IR edge or a command on the serial line.
The maximum length could be easily set using a command and except for the direct USB capture for the Leonard it wouldn't cost extra time. I still don't understand the use case. Why don't you just release the key on the remote control or cut off the non-wanted data instead of limiting the capture?
Michael
PS: At work I'm developing a software which has dozens or even hundreds of settings nobody understands. So I want to avoid any setting that not even I can understand or explain. Most users are happy with reasonable defaults. |
|
| Back to top |
|
|
Barf
Expert
Joined: 24 Oct 2008
Posts: 1415
Location: Munich, Germany
|
| Posted: Tue Feb 25, 2014 4:42 pm Post subject: |
|
|
| MikeT wrote: |
There is not much choice for the pin. The ATmega328 only has one ICP pin, the ATmega32U4 has two and the ATmega2560 has four (but only two can be used in the Arduino Mega). Each of these ICP<n> pins is directly bound to a specific timer <n> so when changing the pin also the corresponding timer has to be selected. This can be done by setting the #define CAP_TIM to <n> and adapting the CAP_PORT and CAP_PIN accordingly.
|
OK. I still have to digest this. There is so much that I still have to learn...
| Quote: | ...
To calculate the timeout value just call clocksToMikroSeconds(unpackTimeValSwapped(0xffff))
Instead of using (_BV(RANGE_EXTENSION_BITS) - 1) you can also use a smaller value to reduce the timeout.
|
Thanx.
| Quote: | | ... The maximum length could be easily set using a command and except for the direct USB capture for the Leonard it wouldn't cost extra time. I still don't understand the use case. Why don't you just release the key on the remote control or cut off the non-wanted data instead of limiting the capture? |
The use case is this: For some reason, IrScrutinizer has been put into capturing mode, and the user decides that (s)he wants to bail out. Should (s)he just wait for a few seconds, or is (s)he required to grab to an arbitrary remote to send a junk signal just to get out of the capture state?
| Quote: | | PS: At work I'm developing a software which has dozens or even hundreds of settings nobody understands. So I want to avoid any setting that not even I can understand or explain. Most users are happy with reasonable defaults. |
Point taken. There are exactly three parameters (not counting pin-#) I care about, not "dozens or even hundreds".
Again, I am really happy how "smooth" capturing with this works, Without making very exhaustive tests, I seem to get reliable captures from 10 cm (4 inches) which Kevin's IrWidget definitely does not do. |
|
| Back to top |
|
|
MikeT
Joined: 28 Oct 2010
Posts: 115
|
| Posted: Wed Feb 26, 2014 12:29 pm Post subject: |
|
|
| Barf wrote: | | The use case is this: For some reason, IrScrutinizer has been put into capturing mode, and the user decides that (s)he wants to bail out. Should (s)he just wait for a few seconds, or is (s)he required to grab to an arbitrary remote to send a junk signal just to get out of the capture state |
Why not press a button in IrScrutinizer to abort capturing? You don't have to tell the Arduino to start or abort capturing, you just have to set the capture mode (or use the default mode) and it is always ready to start the capture when it sees the first edge, even when IrScrutinizer is not listening. Therefore you should clear the serial receive buffer when you start listening at the serial port because there might already be some data in the receive buffer.
In the sketch it works like this (in pseudo code):
| Code: |
Loop()
{
int c = Serial.Read(); // non-blocking
if(c != -1)
{
switch(c)
case ... // switch capture mode
captureMode = ...
}
switch(captureMode)
{
case XXX:
captureXXX(); // this is where all the time is spend
}
}
captureXXX()
{
// wait for either an edge or for a character from the serial port
while(!edgeDetected && !Serial.Available())
{}
}
|
Michael |
|
| Back to top |
|
|
Barf
Expert
Joined: 24 Oct 2008
Posts: 1415
Location: Munich, Germany
|
| Posted: Sun Mar 16, 2014 2:09 pm Post subject: |
|
|
Hallo Michael,
do you know if there is a (resource-) conflict between your code and the Arduino Ethernet library? |
|
| Back to top |
|
|
MikeT
Joined: 28 Oct 2010
Posts: 115
|
| Posted: Sun Mar 16, 2014 3:06 pm Post subject: |
|
|
Hi Barf,
| Barf wrote: | | do you know if there is a (resource-) conflict between your code and the Arduino Ethernet library? |
Which ATmega are you using?
The ATmega328 shares ICP1 with PCINT0 and PB0 ==> Arduino digital pin 8
The ATMega32U4 shares ICP1 with ADC8 and PD4 ==> Arduino digital pin 4
and ICP3 with CLK0, OC4A and PC7 ==> Arduino digital pin 13
Arduino Digital pin 4 is used to control the slave select pin on the SD card of the newer versions of the shield. On the ATmega32U4 this pin is connected to PD4 and therefore collides with ICP1.
You can either change the ICP pin from ICP1 to ICP3 by changing the following constants
from
| Code: | #if defined(_AVR_IOM32U4_H_)
#define CAP_PORT D
#define CAP_PIN 4
#define CAP_TIM 1
#define CAP_TIM_OC A
|
to
| Code: | #if defined(_AVR_IOM32U4_H_)
#define CAP_PORT C
#define CAP_PIN 7
#define CAP_TIM 3
#define CAP_TIM_OC A
|
When you don't need the SDCard you can try to change the initialization order of the ethernet library and the IRWidget: first init ethernet and afterwards the IRWidget which will override the pin function. Depending on the hardware and if an SDCard is inserted, this will not work reliably.
I see the following possibilities for further problems:
* the disabled timer IRQ during capturing (and waiting for the first edge)
* EthernetClient::available() and ::read() are not called and requests from ethernet clients are not answered
Both can easily be changed with little side-effects.
Michael |
|
| Back to top |
|
|
Barf
Expert
Joined: 24 Oct 2008
Posts: 1415
Location: Munich, Germany
|
| Posted: Sun Mar 23, 2014 6:10 am Post subject: |
|
|
Michael,
thanx a lot for your answer. It turned out that the problem was elsewhere. Nevertheless, your post was quite valuable.
It works fine over ethernet (Uno). |
|
| Back to top |
|
|
probono
Joined: 12 Aug 2012
Posts: 48
|
| Posted: Sun Apr 20, 2014 6:03 am Post subject: Re: Arduino sketch to generate raw code for use with IR Scop |
|
|
Exciting development in this thead 
Just found this now. I will try to catch up asap. In the meantime, I found this question:
| NEC1 wrote: | | If you have not done so, are there plans to incorporate the IR sender and receiver program in the same Arduino board (of which the mode can be selected with a serial port command e.g. "RX" for IR receiving mode and "TX" for IR transmitting mode)? |
I am using this sketch and it is working for me (but likely it should be prettified):
https://gist.github.com/probonopd/5793692#file-sendandreceive-ino
Send Pronto Hex via an IR LED connected to Arduino Pin D9. Make sure you do not send a blank (" ") as the last character. For example, to send Sony12, device = 1, obc = 47:
| Code: | | SEND 0000 0067 0000 000d 0060 0018 0030 0018 0030 0018 0030 0018 0030 0018 0018 0018 0030 0018 0018 0018 0030 0018 0018 0018 0018 0018 0018 0018 0018 03de |
|
|
| Back to top |
|
|
Barf
Expert
Joined: 24 Oct 2008
Posts: 1415
Location: Munich, Germany
|
| Posted: Sun Apr 20, 2014 8:39 am Post subject: |
|
|
Hi Probono,
nice to hear from you again.
Next version of IrScrutinizer (1.0.2 or possilbly 1.1.0) will come with one Arduino sketch good for both sending and capturing. Due "real soon now". Basically, I am implementing a simple case of the Girs specification.. |
|
| Back to top |
|
|
Barf
Expert
Joined: 24 Oct 2008
Posts: 1415
Location: Munich, Germany
|
| Posted: Sat Jun 21, 2014 2:28 am Post subject: |
|
|
As described in another thread, IrScrutinizer 1.1.0 has been released. It contains a sketch that, as per above, will both send and capture. The capture is based on MikeT's work, for the sending part, I am now using Chris Young's IrLib, which is based upon Ken Shirriff's library.
It has been tested on Arduino Uno, Nano, Lenoardo, Micro, Mega2560. |
|
| Back to top |
|
|
Barf
Expert
Joined: 24 Oct 2008
Posts: 1415
Location: Munich, Germany
|
| Posted: Fri Jan 08, 2016 3:04 pm Post subject: |
|
|
Hi again,
Here is a fairly detailed DIY guide for an Arduino nano clone based board, for the price of a small pizza. It incorporates most of the stuff mentioned in this thread, including a further developments of MikeT's excellent work.
It uses my own Arduino software AGirs and Infrared4Arduino instead of IRLib.
It is primarily geared to be used with IrScrutinizer and Lirc (driver contained in Lirc 0.9.4), but other usages are also possible. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
File Section
Wiki
