- Cleaned up layout of output, removed trailing commas
- buffer sizes are now correct
- no need to add 0 for space at end, as sendRAW takes care of this
Fixed presentation & 2 bugs.
Presentation: No longer display leading space in timings, as is confusing to users & essentially irrelevant.
Bug Fix 1: rawData was starting with a space & would not work with sendRaw
Bug Fix 2: chaned x from unsigned int to nsigend long to avoid potential overflow on integer multiplication.
very similar to recent changes to IRrecDump #167#207
Have updated IRrecvDdump to fix bugs described in Issue: #167
In summary, removed bug where large space values were displayed incorrectly & confusing users. The output now always starts with a mark, instead of a space, which makes it easier to interpret and less confusing for users.
refer to #167 for more detials.
The update has been tested with several protocols (but not all) and verified as working.
As sendRaw is a very popular methos of sending unknown or AC signals, I though it would be very useful to include and example of same with the library.
The code in this new example is tested and verified as working with the latest Master.
As written this example will cause issues with some IR receivers. On the face of it it sends teh sony signal burst 3 times with a 40ms gap. However, it really continues to send the sony signal forever with a 40ms gap.
There needs to be a reasonable gap between signals sent & I have added in a 5 sec gap as a reasonable figure.
Without a gap, many IR receivers will treat this signal as noise as it send continuous sony bursts with a 40 ms gap.
looks like this multiplier was omitted and needs to be include to make the output meaningful/useful???
Would also explain some weird output I have seen posted.
Improve output for recvDumpV2
Added my name to the contributors list (not 'cos I really care for the credit <whatever> but so people know who to "blame" [non-pejorative])
Moved the decode() function to the top of the source as it is likely to be edited the most
Most work already done by zenwheel, but the sendPanasonic command
didn't work. Sending and decoding is confirmed to work with using both
the JVC and Panasonic protocol.
The library has also been updated to work with Arduino IDE 1.0.
Many problems happen with git due to some machines liking CRLF at the
end of lines, and others linking CR. To try to straighten this out,
I'm using Unix-style LF (\n) as the line endings. To make sure your
repository remains consistent, try:
$ git config --global core.autocrlf input
For details, see:
http://help.github.com/dealing-with-lineendings/
