Feature Request - Support pronto codes

[robste11159]

Please add the ability to support pronto codes.
These are readily available for older devices and handy when you want to use a discrete code (ie go directly to HDMI_2).

Possibility as an argument to an existing method or as a utility function to convert to a known or raw format.

Existing project that may be used as a reference:
https://github.com/probonopd/ProntoHex/blob/master/ProntoHex.cpp

Thanks!

[robste11159]

Thanks for adding this. I'll test it tonight. I did manage to code up something yesterday in perl (my c is a little rusty) and to figure out the timings and convert that into the 48bit message

I have some feedback on some of the code, I'm still learning how this IR stuff operates, so I could be completely wrong :), but in regards to the constants defined in ir_Panasonic.cpp:

#define PANASONIC_HDR_MARK 3456U
#define PANASONIC_HDR_SPACE 1728U
#define PANASONIC_BIT_MARK 432U
#define PANASONIC_ONE_SPACE 1296U
#define PANASONIC_ZERO_SPACE 432U

Would it be better to have a const that represents the base time:
PANASONIC_BASE_TIME 432U

Then represent those values as simply how many "ticks" of the base time, for example

Rename
PANASONIC_HDR_MARK to PANASONIC_HDR_ON_TICKS = 8
PANASONIC_HDR_SPACE to PANASONIC_HDR_OFF_TICKS = 4.

I think that way makes more sense when you read the code as to what is going on behind the scenes

[crankyoldgit]

Yeah. I've often thought about making that sort of change, and did think that when I took over most of the maintenance for this library. While it is totally correct, that they are often built up of multiple of periods/cycles (i.e. the 432 is itself a multiple of the basic underlying PWM signal), having them as independent constants allows people to tweak them as they see fit, and potentially not screw up the rest of the constants. So ... I'm vexed on if I should go more structured, or not. There are pluses and minuses to both arguments etc.

[crankyoldgit]

Additionally, you may be able to use the unit test code, examples. and cases to convert the Pronto codes into the condensed single integer versions for the sendManufacture() routines to use. i.e. take a look at ir_Pronto_test.cpp file in the PR. I do exactly that. Converting in the other direction (e.g. sendNEC() -> Pronto format, is fairly simple, but fairly redundant IMHO. That said, there are some sites out there that will do it in a piece of javascript on a web page. So don't hack in perl (or C for that matter) when a Google search will get you what you want.

For the record, I'm no great C/C++ programmer. Python is my most comfortable language. :-) I used to like Perl, but then I better. :-P

[robste11159]

The whole perl thing was just to get a better understanding, there's no better way to understand something than to write the code yourself. After using perl almost every day for 5 years, I can knock out test code pretty quickly with it :P

I'm using your library with this project: https://github.com/mdhiggins/ESP8266-HTTP-IR-Blaster

So essentially I'm putting in the perl decoded pronto timings into that project like this:

http://192.168.2.197:8080/json?pass=pass&plain=[{"type":"raw","data":[3550,1750, 500,450, 500,1300, 500,450, 500,450, 500,400, 500,450, 500,450, 500,450, 500,450, 500,450, 500,450, 500,450, 500,450, 500,1300, 500,450, 500,450, 500,450, 500,450, 500,450, 500,450, 500,450, 500,450, 500,450, 500,1300, 500,450, 500,1300, 500,450, 500,450, 500,450, 500,450, 500,450, 500,450, 500,450, 500,450, 500,450, 500,450, 500,1300, 500,1300, 500,450, 500,450, 500,450, 500,1300, 500,450, 500,450, 500,1300, 500,1300, 500,450, 500,1300, 500],"khz":"38","repeat":1,"rdelay":80}]

Which works.

So the issue I'm having at the moment is that if I change the URL to include the pronto codes instead, like this:

http://192.168.2.197:8080/json?pass=pass&plain=[{"type":"pronto","data":[0000,006C,0000,0032,0084,0043,0011,0011,0011,0033,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0033,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0033,0011,0011,0011,0011,0011,0033,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0011,0033,0011,0033,0011,0011,0011,0033,0011,0011,0011,0011,0011,0033,0011,0011,0011,0033,0011,0033,0011,0011,0011,0011,0011,0B1E],"khz":"38","repeat":1,"rdelay":80}]

Is that the pronto codes are received in the other code as a String type:

void irblast(String type, String dataStr, int len, int rdelay, int pulse, int pdelay, int repeat, long address, IRsend irsend) {

"dataStr", I need to convert that into uint16_t data[] for use by the IRsend::sendPronto method... yeah embarrassing, but like I said, my c is rusty :p

Also what do you use for development? I regularly just use vim, but I don't have a good undestanding on how to write code for arduino and test it without all the write/upload/test. Is there a way to test locally without writing it to the board?

Thanks.
Rob

[crankyoldgit]

Parsing strings is always a pain, in C/C++. Python & Perl are much better.

For one way to do it, have a look at: https://github.com/markszabo/IRremoteESP8266/blob/master/examples/IRGCTCPServer/IRGCTCPServer.ino#L54
You'd have to modify that of course to deal with hexidecimal, rather than base-10 strings. That shouldn't be hard.

As how I do development ...
During the rewrite of this library, I made everything as standard and machine independant as possible. Such as using c98-style types. e.g. uint16_t rather than unsigned int so they were the same size on all platforms. Then I used/created unit tests (see under the test/ directory) to test/debug everything I could on a local workstation, rather than doing the constant write/compile/upload/run/stare at serial logs cycle.
In short, break up your code, use decent software engineering practices, and learn to love unit testing, and do test-driven development.

As for editors, I've been a VI & Unix user for decades, but I've been using Atom/PlatformIO for doing a lot of these IoT-class devices lately. It certainly helps.

I do most of my testing/debugging in Unit Tests which run locally on my Linux box. That's probably 95% of my testing/development. The rest is uploading to the device and testing on the real hardware etc. which you still have to do. Local unit tests etc mean I cut down the upload/flashing a lot.

There are a few arduino emulator projects out there. I hear they are 'okay', not good. I haven't used them so I can't directly comment.

[crankyoldgit]

Friendly ping. Have you tested out the Pronto code support yet?

I'll be including it in the next release (v2.1.0) as soon as we have merged the Fujitsu A/C code in.

ETA a day or so.

[crankyoldgit]

v2.1.0 has been released. It has support for sending Pronto codes.

Marking this issue/request closed.