IO module ticks support

[louisvangeldrop]

RF433 devices are used a lot in the Home Automation environment. There is a broad supply of all kind of devices - thermohygrometes, all kind of sensors, alarms, switches etc. Heterodyne transmitters and receivers are abundantly available for a very affordable price.
Transmitting the pulses with RMT- or IO write works with the current available functionality.
However receiving the pulses in the range of 100 microseconds until over 10000 microseconds requires the number ticks in the onreadable event.

Suggestions:
Allow the use of a filter in microseconds when specifying the Digital Pin.
Add the tick-duration in microseconds in the triggers event object.

[andycarle]

Hi @louisvangeldrop,

Just to clarify, are you suggesting these changes be made to the RMT module? Or are you proposing added functionality for the Digital IO class?

I can speak to the implementation of the RMT module.

The duration of an RMT tick is a function of the divider property of the dictionary provided to the RMT constructor. The underlying clock source for the RMT hardware is the 80 MHz APB clock (i.e. 0.0125 microsecond period). The divider property applies a clock divider to that signal. So, for example, the default divider of 255 means that each RMT tick is (0.0125 microsecond * 255 =) 3.1875 microseconds.

The filter property in the dictionary specifies a minimum tick length for "accepted" RMT pulses. The maximum value there (because it is the maximum supported by the hardware) is 255. So, the longest filter supported by the hardware is 3.1875 microseconds * 255 = 812.8125 microseconds.

The hardware does not support arbitrary combinations of tick lengths and filters in microseconds: the filter duration has to be a multiple of the tick length. We could support a property on the RMT instance to get the tick length from the current settings, if that would be helpful.

I'm not entirely sure I follow what you're describing for "the number ticks in the onreadable event". If you're talking about the RMT module here, what exact functionality would be helpful for your intended use of the module? I'd be happy to sort out improvements to the module to support what you need.

 - Andy

[louisvangeldrop]

Hi @andy. Maybe I was a litlle bit unclear in my previous request. Probably it has to do my writing in English. Dutch is my native language, hence I am not so fluently in English.

My suggestion was to include the feature into Digitial IO class as an extension to the triggers object that is passed in the onReadable-event. Adding a tick property to the triggers object would be helpful.

The filter -specified in microseconds is a kind of Glitch or Debounce, that reduces the amount of event-calls in the onReadable event. I have used piGpiod Client Notify with a glitchfilter and Espruino's setWatch with a debounce ( the Espruino interpreter is too slow to cover all the interrupts). Just like there is a baud-option in the serial-class, maybe a filter property is an option.

[andycarle]

Ah, I understand now.

For debouncing digital inputs, I would recommend implementing that as a module on top of Digital IO, rather than modifying the IO class itself. We have something similar implemented in m5button.js, which debounces digital buttons on the M5Stack Fire device. That uses a different digital input module, but the principle should be the same when building on top of Digital IO.

For monitoring precise times of GPIO level changes, you are right that the Digital IO class is not currently an appropriate solution. My inclination there would be to use the RMT module in receive mode for this purpose, with the logic for processing the level durations managed in script. If you find that the current RMT implementation does not work well for this purpose, I would be happy to investigate updates to the module to fit your needs.

[louisvangeldrop]

For the RF433 receiver I am using RMT with the divider set to 80 and the filter to 100. Meaning all pulses below 100 usec's are skipped and all pulses are in usec's. The problem is that I have to poll the buffer in order to get data.
Reading the values of a DHT11/22 is also implemented with RMT.
I just wonder how the ECMA TC53 standards committee will include support for these type of receivers, that will return their data based upon a combination of pulsewidths and rise/fall.

[phoddie]

This doesn't seem to be an issue but a design discussion of how to implement a particular capability. I'm going to move it over to Discussions.