-
• #2
I wonder how long the string actually was?
Some kind of timer might be a good idea as you say - but then it screws up the low power sleep states on the proper Espruino boards as it'll be waking up every so often.
I guess the other option is to replace
if (d>0.04) {
withif (d>0.04 || code.length>100) {
Hopefully it won't add too much to the execution speed.
-
• #3
Not sure how to determine the string length. - I could save to
this
in a local version of the module and monitor that.I'll try the 100 length.
The remotes I have seem to send 1's after fixed length (33 bytes in most cases) as repeat code if a button is constantly hit. If the constructor knew the length, a repeated event could be emitted. Not sure how to handle or perhaps retrigger the code sent?
I've bee also thinking about how the codes could be shortened instead of sending a string of 1 and 0's, perhaps a hex code? -
• #4
The remotes I have seem to send 1's after fixed length (33 bytes in most cases) as repeat code if a button is constantly hit
Yes, but they do this after a gap - which
if (d>0.04)
should normally pick up? Perhaps it's one of those ESP8266 gotchas again - after all, this module's been around for years and nobody has reported a problem with it before.Potentially you could have a varying length, but it does complicate usage - and you might want to use the same receiver to detect different types of remote controls which have different signal lengths.
I've bee also thinking about how the codes could be shortened instead of sending a string of 1 and 0's, perhaps a hex code?
It's done this way for speed of processing - single character string appends are nice and fast, so I wouldn't advise changing it.
Realistically bits come in once a millisecond maximum, so to fill up available memory 0 even on an ESP8266 - you've got to have a continuous burst of 10 seconds of IR. I think that's so unlikely that memory efficiency isn't really an issue.
What's the 'fluro lamp' that's triggering the receiver, and are you using a proper receiver?
Maybe you could check
getPinMode
on the receiver pin, to make sure it really is ininput_pullup
mode.Most receivers need a ~40kHz series of IR pulses to trigger, and then to run out of memory there needs to not be a gap of more than 40ms for a whole 10 seconds. It all seems really unlikely unless something is wrong.
-
• #5
if (d>0.04 || code.length>100) {
Seems to have fixed the issue.
Would you like me to do a pull request?
-
• #6
Yes, that'd be great - thanks!
I have discovered at night a fluro lamp triggers the IR reciever. These random pulses after a couple of hours trigger this:
it appears to be in this block:
I believe the cause is here:
So code just keeps getting longer.... I wondering what the best way is to make this robust?
Set a watch dog timer that truncates the
code
string if it gets too long, or simply controls it's length?http://www.espruino.com/modules/IRReceiver.js