Send a free sequence of pulses with custom timings

[Martin-Laclaustra]

This is an extension that does not break current API. The change increases the footprint of the program just a little with minimal impact on memory use on runtime.

It allows to send a free sequence of pulses with custom timings.
It also allows to generate such sequences from command functions.

This is the functionality that this API extension adds:

• Use send(unsigned int *) to send a starting-low zero-terminated array of timings.
• Create an array of timings: If pointer transmittimings is not null any send command saves the timings to the pointed array instead of sending the code (the main program is responsible from memory management and coherent function calling that will not cause a buffer overflow).

These modification tries to be as small as possible. Error checking has been left out.

A full explanation is in: #146

An example and small tutorial on how to use the custom timings send function: #163 (comment)

There are several issues asking for this functionality. Also issue #163 proves that there is demand and possible uses for this modification.

NOTE: This is an API compatible modification. I believe that the next major version advance of the library (new API) could implement a layered architecture ranging from functions to deal with brand/command to those managing low level control of the transmitter. I will open an issue with these ideas at some point or we could discuss them through email.

[Martin-Laclaustra]

Please @sui77 , @fingolfin , @rotv ,
could you consider merging this pull request? I proposed it more than half a year ago.
At least I would like to discuss the possibility.
The new code is fully backwards compatible and in addition it has the advantage of adding very useful functionality.
I was waiting to this being part of the official library to publish some implementations that are based on these changes.

[Martin-Laclaustra]

@1technophile
I see you are taking care of this repository. Could you consider merging this pull request?
The new code is small footprint, fully backwards compatible, and, in addition, it has the advantage of adding very useful functionality, that has been requested several times.
Thank you for looking after this project.

[1technophile]

Hello Martin,

That's interesting!

I don't understand how transmittimings is set, as there is no methods for that, maybe I'm missing something?

[Martin-Laclaustra]

Thank you for looking into this. I assume that you had a look at the links in the OP.
Here I add more concrete examples.

In the case of sending custom timings, you have an example of usage here: #163 (comment)
In short, you create a pointer to an array (zero-terminated) of timings, and pass it to the send function. The function is overloaded to process the array correctly.

In the case of getting an array of synthetic timings (i.e. you pass a code to the library and get an array of timings - no RF transmitting or receiving involved in this process), the only thing to do is to set a pointer in transmittimings. It is a public member variable (pointer) of the class that can be modified directly. It may be advisable to move it to protected and write setter and getter functions (as I specify in the source code) but just now it does the job with minimal footprint.
https://github.com/Martin-Laclaustra/rc-switch/blob/3a536a172ab752f3c7a58d831c5075ca24fd920b/RCSwitch.h#L83
So, if mySwitch.transmittimings is Null (default after the constructor) the library behaves as usual.
But when we add unsigned int data[66]; before the functions and mySwitch.transmittimings = &data; in setup() after the constructor, any call to a send function (i.e. mySwitch.send(5393, 24);) does not use RF hardware to transmit, but instead it records the timings in the array, which can then be retrieved in the main program and transmitted to another device via IP or printed. Those timings can be used, for example, in "ultra small footprint" programs designed to transmit only one code, without library.
Of course, you can copy the pointer, clear the member variable mySwitch.transmittimings = Null; and feed that array to the send(*int) function and it will transmit it.
Also the timings can be used to compare to those captured with SimpleRcScanner, when fine tuning a new protocol.
If this is accepted I have in mind to use those timings in generating signals through methods different than a 433MHz transmitter connected to a pin.

[1technophile]

In the case of sending custom timings, you have an example of usage here: #163 (comment)
In short, you create a pointer to an array (zero-terminated) of timings, and pass it to the send function. The function is overloaded to process the array correctly.

That's perfect, do you think you could add it as an example into the examples folder?

So, if mySwitch.transmittimings is Null (default after the constructor) the library behaves as usual.
But when we add unsigned int data[66]; before the functions and mySwitch.transmittimings = &data; in setup() after the constructor, any call to a send function (i.e. mySwitch.send(5393, 24);) does not use RF hardware to transmit, but instead it records the timings in the array, which can then be retrieved in the main program and transmitted to another device via IP or printed. Those timings can be used, for example, in "ultra small footprint" programs designed to transmit only one code, without library.

Ok I get it, if I understand well it could also be used to do some unit testing of the library; checking that the protocols, bits, translation generate the appropriate timings.
For example by generating:
(i.e. mySwitch.send(5393, 24);)
and checking that transmittimings have the expected array?

[Martin-Laclaustra]

That's perfect, do you think you could add it as an example into the examples folder?

Sure! I understand that you mean in my branch. I probably will need to find time in the weekend to do this.

Ok I get it, if I understand well it could also be used to do some unit testing of the library; checking that the protocols, bits, translation generate the appropriate timings.
For example by generating:
(i.e. mySwitch.send(5393, 24);)
and checking that transmittimings have the expected array?

You are right. But there are also the other possible applications: "ultra small just-one-code" sketches and using the timings with "different" RF systems (this may sound obscure, but I will release sketches and programs for different platforms after the merge).
I could also create a basic example sketch for this function.

[1technophile]

I understand that you mean in my branch. I probably will need to find time in the weekend to do this.

Exactly, the goal is to include them into this PR if possible.

I could also create a basic example sketch for this function

It would be great !

[ivnvsd]

This is very nice extension, I just used it for sending code to Nedis 433 outlet. But I had one problem which is not related to this change directly but I'd like to share it - it may help to someone. I'm not familiar with RcSwitch.h file. Problem was that sending array of timigs to that outlet wasn't received. It was because in RcSwitch.h is constant #define RCSWITCH_MAX_CHANGES 67 but my array if timings had 120 integers. Once I changed RCSWITCH_MAX_CHANGES to 167 it was received with no problems. I'm wondering if it would be helpful to change RCSWITCH_MAX_CHANGES to bigger vaule. Or do some check in send method that array of timings exceed RCSWITCH_MAX_CHANGES. (I'm using Arduino Mega 2560). From the comment of RCSWITCH_MAX_CHANGES I wasn;t able to understand what vaue I can set there. 500? 1000?

[cgmckeever]

@Martin-Laclaustra did this merge never happen?

[Martin-Laclaustra]

@cgmckeever Sorry, in this strange year I still did not produce the promised example. May be during the holiday season I can prepare it.
However, in the meantime, if you need to use it, you can checkout my branch. It is functional.

[cgmckeever]

This is a F'd up year, let alone strange -- thanks for the feedback ... Was just combing through the issues, and noticed so much referencing your branches ... and was thinking, hope all this goodness makes it in! .. Have a great new year --