JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

Arduino sketch to generate raw code for use with IR Scope
Goto page Previous  1, 2, 3, 4, 5  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
MikeT



Joined: 28 Oct 2010
Posts: 115

                    
PostPosted: Wed Jan 29, 2014 4:38 pm    Post subject: Reply with quote

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:
Code:
non-inverting sensor detected
bufferSize=1042
press 'a' for aggregating capture
press 'r' for raw capture (rising edges)
press 'b' for raw capture (both edges)
--- aggregating capture ------ f=40816 d=100 n=77
 +2365 -623 +573 -623 +1170 -623 +572 -623 +573 -623 +1170 -623 +573 -623 +573 -623 +1170 -622 +573 -623 +573 -623 +573 -623 +573 -25856 +2365 -623 +573 -623 +1170 -623 +573 -623 +573 -623 +1170 -623 +573 -623 +573 -623 +1170 -623 +573 -623 +572 -623 +573 -623 +573 -25856 +2365 -624 +573 -623 +1170 -623 +573 -623 +573 -623 +1170 -623 +573 -623 +573 -623 +1170 -623 +573 -623 +573 -623 +573 -623 +573
--- raw capture (rising edge) ------ f=40816 d=100 n=1041
 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 623 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 623 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 623 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 623 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 623 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 623 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 623 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 623 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 623 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 623 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 623 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 623 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 9472 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 623 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 623 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 623 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 622 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 623 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 623 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 623 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 623 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 622 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 623 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 623 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 623 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 9472 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 624 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 623 25 25 25 25 25 25 25 25 25
--- raw capture (both edges) ------ f=40816 d=28 n=1041
 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -616 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -615 +7 -18 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -615 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -615 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -615 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -615 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -615 +7 -18 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -615 +7 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -615 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -615 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -615 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -615 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +7 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -9456 +7 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -17 +8 -17 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8 -18 +8 -18 +8 -17 +8 -18 +8 -18 +8


Michael
Back to top
View user's profile Send private message
MikeT



Joined: 28 Oct 2010
Posts: 115

                    
PostPosted: Sat Feb 01, 2014 9:09 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
MikeT



Joined: 28 Oct 2010
Posts: 115

                    
PostPosted: Sun Feb 02, 2014 9:36 am    Post subject: Reply with quote

3FG wrote:
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?

I have added such modes ('n' and 'm') but it is very experimental. Actually I never looked at the data I got, but only for the time it takes to send the serial data.

The format must be binary (16 bit values, big-endian) and in MCU clocks (not in mikroseconds) because there is no time left for conversion of the values (costs at least 3µs extra for the formatting and even more for clk=>time conversion).

To get the time in mikroseconds, the following code can be used:
Code:

const uint8_t CAPTURE_PRESCALER_BITS = 3;
const uint8_t RANGE_EXTENSION_BITS = 4; // factor for upper measurement range = 2^(RANGE_EXTENSION_BITS+1)
const uint8_t F_CPU = 16000000; // the clock of the Arduino
uint32_t index; // current index to buf
uint32_t clocks = unpackTimeValSwapped((buf[index] << 8) | (buf[index + 1]));
uint32_t timeInMikroSecs = ClocksToMikroSeconds(clocks);

uint32_t ClocksToMikroSeconds(uint32_t x)
{
  return ((x * (125UL << CAPTURE_PRESCALER_BITS)) / (F_CPU/8000000UL)); // will only work for F_CPU which are a multiple of 8MHz
}

inline uint32_t unpackTimeValSwapped(uint32_t val)
{
  if(val & 0x8000)
  {
    val = val & 0x7fff;
    uint32_t valOvl =  (val & (_BV(RANGE_EXTENSION_BITS) - 1)) << 16;
    uint32_t valTim =  (val << 1) & (0x7fff & ~(_BV(RANGE_EXTENSION_BITS) - 1));
    val = valOvl | valTim;
  }

  return val;
}


/edit: The minimum time needed for a single edge is 5.6µs, so the highest possible frequency is below 89 kHz when capturing both edges.
/edit2: The code was using the wrong variant of unpackTime

The new source can be found here.

Michael
Back to top
View user's profile Send private message
MikeT



Joined: 28 Oct 2010
Posts: 115

                    
PostPosted: Sun Feb 02, 2014 4:28 pm    Post subject: Reply with quote

MikeT wrote:

I have added modes 'n' and 'm' (no buffering, direct USB output).
The minimum time needed for a single edge is 5.6µs, so the highest possible frequency is below 89 kHz when capturing both edges

It's now a bit faster, one edge takes only 3.2µs to process.

To make detecting of the capture data a bit easier, the first value is always 0x0000 and the last value 0xffff.

The new source can be found here.

Michael
Back to top
View user's profile Send private message
MikeT



Joined: 28 Oct 2010
Posts: 115

                    
PostPosted: Sat Feb 08, 2014 2:17 pm    Post subject: Reply with quote

MikeT wrote:
I have added modes 'n' and 'm' (no buffering, direct USB output which means unlimited capture length, requires Arduino Leonardo or other board with ATmega32U4).
It's now a bit faster, one edge takes only 3.2µs to process.

The new version has been further improved, it needs 2.5µs.

MikeT wrote:
To make detecting of the capture data a bit easier, the first value is always 0x0000 and the last value 0xffff.

I've added a second end tag 0xfffe for marking a failed capture when the USB send buffer had an overflow.

A command line tool has been added to the distribution as reference implementation (in C++) . It has exactly one parameter: the device name of the serial port
Here an example how to call it on my Mac with an Arduino Leonardo
Code:
IR_Widget/console_client/ArduinoIRWidget/ArduinoIRWidget\ 08.02.14\ 19.46\ MacOSX/ArduinoIRWidget  /dev/cu.usbmodemfd121
times[2799]=+10 -17 +9 -17 +10 -17 +10 -17 +10 -17 +9 -17 +10 -17 +10 -17 +9 -17 +9 -17 +10 -17 +10 -17 +9 -17 +9 -17 +10 -17 +10 -17 +9 -17 +10 -17 +10 -17 +10 -17 +9 -17 +10 -17 +10 -17 +10 -17 +9
...


The Mac XCode project of the tool can be found in the directory "console_client". It should easily be portable to Linux, but windows might require some more work.
The main purpose of the code was to have a working test and reference implementation as base for the Java implementation in IRScrutinizer.

The new source can be found here.

Michael
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1434
Location: Munich, Germany

                    
PostPosted: Sun Feb 09, 2014 4:06 am    Post subject: Reply with quote

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

Code:
f=38095 +14875 -11562 +14750 -11562 +14750 -11562 +14750 -11562 +14750 -11562 +14750 -11562 +14750 -11562 +14750 -11562 +14750 -11562 +14750 ... -200000


the "f=xxxxx" part being optional, The f argument is the only difference from 0.1.1, btw. This is the "aggregate form". Also note that the number of durations is even, the last one being the final silence, which happens to be identical to the preset ending timeout. So, for the short time solution, if you can have your sketch outputting this format, IrScrutinizer 1.0.0 unmodified will take it directly. (Ohh, 9600 baud hard soldered in... Embarassed )

The interface is done in the class org.harctoolbox.harchardware.ir.Arduino, sources download.

For other forms than the "aggregated", it is definitely interesting to be able to analyze signals in that detail, however, I think it is probably better to us programs like Matlab/Labview/Octave/Gnuplot or a spreadsheet program for doing the analysis. What do you think? Nevertheless, it would be nice to identify e.g. Barco as
Code:
f=0 +10 -250 +10 -50 +10 -50 +10 -150 +10 -150 +10 -50 +10 -50 +10 -150 +10 -50 +10 -50 +10 -50 +10 -150 +10 -250 +10 -120000


For the long time perspective: I wrote down my ideas of a modular, general IR server for sending, receiving, capturing. (The response format is not really defined there, though). What do you say?

Have you had a look at the Intel Galileo?

Finally, would you consider changing your license (GPL2) to e.g. "GPL2 or later"? Since IrScrutinizer is "GPL3 or later", it would make things simpler.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
MikeT



Joined: 28 Oct 2010
Posts: 115

                    
PostPosted: Sun Feb 09, 2014 4:43 am    Post subject: Reply with quote

Hi Barf,

Barf wrote:
IrScrutinizer 1.0.0's "Arduino capture interface" expects the Arduino to spit out strings like
f=38095 +14875 -11562 +14750 -11562 +14750 -11562 +14750 -11562 +14750 -11562 +14750 -11562 +14750 -11562 +14750 -11562 +14750 -11562 +14750 ... -200000[/code]


I can adapt to this format for all capture types except for the direct USB output, because the Arduino is not fast enough for doing the formatting in realtime, so the post processing needs to be done on the PC.

Barf wrote:
This is the "aggregate form".

Can IrScrutinizer also handle the non-aggregate form?

Barf wrote:
Also note that the number of durations is even, the last one being the final silence, which happens to be identical to the preset ending timeout.

No problem, I can add this dummy value to the end of the output.

Barf wrote:
So, for the short time solution, if you can have your sketch outputting this format, IrScrutinizer 1.0.0 unmodified will take it directly. (Ohh, 9600 baud hard soldered in... Embarassed )

The native USB interface on the Arduino Leonardo doesn't care about the baudrate setting because there is no UART interface between the PC and the ATmega. Only the FTDI converters use this setting for their UART interface to the ATmega.

Barf wrote:
For other forms than the "aggregated", it is definitely interesting to be able to analyze signals in that detail, however, I think it is probably better to us programs like Matlab/Labview/Octave/Gnuplot or a spreadsheet program for doing the analysis. What do you think?

What's the real world usecase? Who needs to do the capture and who will analyze the waveform?

Barf wrote:
Finally, would you consider changing your license (GPL2) to e.g. "GPL2 or later"? Since IrScrutinizer is "GPL3 or later", it would make things simpler.

No problem for my own code.

I've to leave for today and answer the rest later...

Michael
Back to top
View user's profile Send private message
MikeT



Joined: 28 Oct 2010
Posts: 115

                    
PostPosted: Mon Feb 10, 2014 4:07 pm    Post subject: Reply with quote

Barf wrote:
For the long time perspective: I wrote down my ideas of a modular, general IR server for sending, receiving, capturing. What do you say?

I really like the idea of a general purpose IR box on the network which can be controlled via a mobile phone. There are WiFi and LAN shields for the Arduino but it might be easier to use a real server.

Barf wrote:
Have you had a look at the Intel Galileo?

The only thing I know about it is that it is a 486. GPIO access can only do 230 Hz (not kHz !). For hard real-time requirements you additionally need dedicated hardware like the ATmega32U4.

The Arduino Tre might be a nice board because it has an ARM Cortex-A8 and ATmega32U4 chip, so it can run a network server and do realtime IO.

I would probably prefer a combination of a Raspberry Pi or Beagle Board and a ATmega board. The Pi and the Tre have a HDMI output which is very useful.

Michael
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1434
Location: Munich, Germany

                    
PostPosted: Sun Feb 23, 2014 10:12 am    Post subject: Reply with quote

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!! Very Happy

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
View user's profile Send private message Send e-mail Visit poster's website
MikeT



Joined: 28 Oct 2010
Posts: 115

                    
PostPosted: Tue Feb 25, 2014 4:04 pm    Post subject: Reply with quote

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
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1434
Location: Munich, Germany

                    
PostPosted: Tue Feb 25, 2014 4:42 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
MikeT



Joined: 28 Oct 2010
Posts: 115

                    
PostPosted: Wed Feb 26, 2014 12:29 pm    Post subject: Reply with quote

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
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1434
Location: Munich, Germany

                    
PostPosted: Sun Mar 16, 2014 2:09 pm    Post subject: Reply with quote

Hallo Michael,

do you know if there is a (resource-) conflict between your code and the Arduino Ethernet library?
Back to top
View user's profile Send private message Send e-mail Visit poster's website
MikeT



Joined: 28 Oct 2010
Posts: 115

                    
PostPosted: Sun Mar 16, 2014 3:06 pm    Post subject: Reply with quote

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
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1434
Location: Munich, Germany

                    
PostPosted: Sun Mar 23, 2014 6:10 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Software All times are GMT - 5 Hours
Goto page Previous  1, 2, 3, 4, 5  Next
Page 4 of 5

 
Jump to:  
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
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control