You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The library could provide the raw timings that any send function produces. These could be used to create compact code when an embedded application does not need to link the full library but only send a fixed code. Also, when creating new protocols or testing platforms, receivers, and transmitters, they could be used to compare the intended send timings with the received timings or the actually emitted ones, and calibrate corrections. In addition the timings could be used to broadcast through other means different from the output pin.
On the other hand, it would be convenient to be able to send a free sequence of pulses with custom timing (i.e. replay the above codes, or any set of timings recorded by any other mean). Combining this with a restriction-free scanner like SimpleRcScanner may provide the often requested record and play function for the library.
This can be achieved with very few lines of code. I implemented these functions on the transmittimingsarray branch.
The implementation includes an array pointer as member of the class. When null, everything works as usual. When points to an array, any send function saves the timings to that array instead of sending the values to the output pin. The array is zero-terminated. The calling program is responsible for memory allocation. The first timing is always for a low signal.
I tested it with Raspberry pi, with the code I wrote in accesstotransmittimings branch of 433Utils. In short, generatetimings works as codesend but prints the timings instead of sending them. They can be easily visualized, for example in Suat's online visualizer. And sendtimings transmits a quoted string of space-separated timings, considering the first timing always as low signal.
I will be testing this with Arduino next, and prepare equivalent sketches.
Let me know if you see possible to merge this code and I will issue a pull request.
The text was updated successfully, but these errors were encountered:
The library could provide the raw timings that any send function produces. These could be used to create compact code when an embedded application does not need to link the full library but only send a fixed code. Also, when creating new protocols or testing platforms, receivers, and transmitters, they could be used to compare the intended send timings with the received timings or the actually emitted ones, and calibrate corrections. In addition the timings could be used to broadcast through other means different from the output pin.
On the other hand, it would be convenient to be able to send a free sequence of pulses with custom timing (i.e. replay the above codes, or any set of timings recorded by any other mean). Combining this with a restriction-free scanner like SimpleRcScanner may provide the often requested record and play function for the library.
This can be achieved with very few lines of code. I implemented these functions on the transmittimingsarray branch.
The implementation includes an array pointer as member of the class. When null, everything works as usual. When points to an array, any send function saves the timings to that array instead of sending the values to the output pin. The array is zero-terminated. The calling program is responsible for memory allocation. The first timing is always for a low signal.
I tested it with Raspberry pi, with the code I wrote in accesstotransmittimings branch of 433Utils. In short, generatetimings works as codesend but prints the timings instead of sending them. They can be easily visualized, for example in Suat's online visualizer. And sendtimings transmits a quoted string of space-separated timings, considering the first timing always as low signal.
I will be testing this with Arduino next, and prepare equivalent sketches.
Let me know if you see possible to merge this code and I will issue a pull request.
The text was updated successfully, but these errors were encountered: