New interpreter error: FIFO_FULL on the Pixl.js while running the Remote Control Sockets sniffer example

I've tried to do a forum search but it seems that they're quite older.

I'm trying to find out the codes my remote uses for my rf socket, but when the remote is in range and I press a button, I get this error in the console.

|  __|___ ___ ___ _ _|_|___ ___
|  __|_ -| . |  _| | | |   | . |
|____|___|  _|_| |___|_|_|_|___|
         |_| espruino.com
 2v18 (c) 2021 G.Williams
>
New interpreter error: FIFO_FULL
> 

I'm not really sure how to debug this. Is there a way to recompile the firmware to increase the FIFO buffer?

I'm connected via the realtek bt adapter (so i don't need to throttle send) just in case the mtu made a difference, but it's still the same.

Would moving serial from bluetooth to a serial adapter help at all?

I also just tried to send to flash, disconnect from the ide, rebooted the pixl.js and then tried the remote. I still get the FIFO_FULL message but this time on the pixl lcd so I'm guessing the serial or bt connection doesn't make a difference?

I managed to get the remote's binary code using an arduino lying around and the rcswitch library.

Using the same codes, I used the rcswitch module in Espruino to switch on and off the relay.

Here's what I'm using, if anyone's interested:

let _on  = 0bxxxx;
let _off = 0byyyy;

var sw = require("RcSwitch").connect(1, D10, 10);
var on = false;
function toggle() {
  on = !on;
  if (on) {
      sw.send(_on, 24);
      console.log("switchOn");
      }
  else{
      sw.send(_off, 24);
      console.log("switchOff");
  }
}
setInterval(toggle, 5000);

I'm still confused with the FIFO_FULL message but now that things are working (and that I know of a workaround if ever I need to do it again) it's not as big of an issue for me anymore.

I would still prefer to use Espruino for sniffing the codes though :)

Would save a bit of time if you would link the sniffing code directly but I guess it is about this https://www.espruino.com/Remote+Control+­Sockets and the sig(e) function there.

Maybe it is good candidate to use the new JIT feature. Try to mark it with "jit" for it to execute faster. I think the FIFO_FULL in this case means the setWatch(sig, pin, {repeat:true, edge:"both"}); fires the sig method faster than it can execute. Or maybe the console.log there writes to output too much too quickly, then the "jit" would probably not help.

The explanation of FIFO_FULL is here https://github.com/espruino/Espruino/blo­b/master/src/jswrap_espruino.c#L702 "could be state transitions for setWatch"

I think the FIFO_FULL in this case means the setWatch(sig, pin, {repeat:true, edge:"both"}); fires the sig method faster than it can execute

Yes, this is likely it.

The FIFO_FULL message comes up when the queue of input events for Espruino fills up and isn't emptied fast enough. That's either text sent over BLE/USB/etc or input events from setWatch.

Some RF receivers have 'squelch' (I think it's called?) and when there isn't a signal strong enough they don't output anything, but others just output whatever they see - so if there is no strong signal they're just outputting random noise.

In that case you may get so many events so quickly that Espruino can't handle it. Actually adding a debounce:0.1 parameter to setWatch might help.

... but it may be that FIFO_FULL doesn't matter. It'll end up dropping some events, but when it gets the correct signal the event rate will go right down and it'll be able to process it - if not the first one then the second

Ah thanks, sorry about that. I didn't realize I forgot to link the actual page :(

I'll see if I can jit this function and if that helps.

I'm using the same receivers as in here https://www.espruino.com/433Mhz (well they look the same at least) so I'm not sure if they have squelch.

I used the same receivers in the Arduino in order to sniff the code. I'm using this Maker Uno from Cytron that has LEDs on each of the pins, and I can see the LED glowing and changing in brightness a lot which probably means there's a lot of noise being picked up.

Then again the FIFO_FULL message only shows up when I actually push the button on the remote near the receiver.

Of course it's all academic at this point since I got what I needed but I'm still curious about what can be done to get it working :P Just for future reference :)

So you were using the 433 module from that page? Maybe I should add "jit" to that event handler in https://www.espruino.com/modules/433.js.

When you got FIFO_FULL did it print anything to the console beforehand at all?

I'll see if I can try again later in a few hours, I should have time for it again.

It didn't print anything to the console, it shows up as soon as I press the remote.

Just in case anyone is curious, I'm trying to make one of the projects suggested there which is the fancy "sous vide" machine :p I got a janky version working with WiFi and the RPI Pico w but it wasn't really user friendly (boot up time was atrocious for some reason) so I'm porting it over to espruino and using a 433mhz socket instead.

I'll post a project writeup once I'm fully done :)

1 Attachment

Here's a quick screencast of the error. I get the FIFO_FULL as soon as I press the remote button.

1 Attachment

Sorry, I just realized you were talking about the module as in js module, not the hardware module.

I wasn't using the 433.js module because I got it to work with the rcswitch module. I don't think I had any issue with sending signals.

The FIFO_FULL message comes when using the receiver hardware module.

So can you just in case put "jit" into the function definition of sig? And if you used parts of https://www.espruino.com/modules/433.js then also in the decode function that is called from sig there.

you can also try to increment some global variable inside sig to know how often it is called

I did that too, but it still resulted in the same error message. Here's what I used, in case I made a mistake somewhere.

var n="";
function sig(e) {
  "jit";

  // The data we have received so far
  // The handler that gets called when the signal changes state
  // start listening for a change
  var d = 10000*(e.time-e.lastTime);
  if (d<2 || d>10) {
    if (n.length>20) console.log(n);
    n="";
  } else if (!e.state) n+=0|d>5;
}

function startListening(pin) {
  "jit";
  setWatch(sig, pin, {repeat:true, edge:"both"});
}

startListening(A0);

I'll try to see if I can do the count in a bit.

Here's another screencast with the count. I clicked the remote button twice: first one was before the first time I inspected c then the second time was after I inspected c then I inspected it again.

Also, it looks like even when I'm not doing anything, c gets incremented (so I'm guessing random rf noise is triggering the setWatch). But when I do press the remote, it looks like the signals then get to the point that it causes the FIFO_FULL message?

1 Attachment

Ok, then it didn't help and is still slow. You can verify the JIT is enabled by typing just the name of function sig and see the output.
See the difference here.

>function f(x){ return 0 ;}
=function (x) { ... }
>f
=function (x) { ... }
>function f(x){ "jit";return 0 ;}
=function (x) { [JIT] }
>f
=function (x) { [JIT] }
> 

From c change it can be seen it is >thousand calls per second so the JIT is probably working and the debounce as Gordon suggested might further help.

BTW if you would remove "jit" then maybe the c would be much smaller as with "jit" it runs in about 1 milisecond (if it handles about 4000 calls in 3 seconds) which is not that bad.

EDIT: and BTW no need to put "jit" in startListening, that one is not called in tight loop and JIT eats extra RAM for generated native code. Doesn't hurt in this case, just mentioning it because overall marking everything with "jit" is not a good idea.

I tried both "jit" and "compiled" but they both still had the FIFO_FULL message.

>
 ____                 _
|  __|___ ___ ___ _ _|_|___ ___
|  __|_ -| . |  _| | | |   | . |
|____|___|  _|_| |___|_|_|_|___|
         |_| espruino.com
 2v18 (c) 2021 G.Williams
>
New interpreter error: FIFO_FULL
>sig
=function () { [native code] }
>
 ____                 _
|  __|___ ___ ___ _ _|_|___ ___
|  __|_ -| . |  _| | | |   | . |
|____|___|  _|_| |___|_|_|_|___|
         |_| espruino.com
 2v18 (c) 2021 G.Williams
>
>
New interpreter error: FIFO_FULL
>sig
=function (e) { [JIT] }

and you're right, the count is smaller (according to my unscientific estimate) when removing "jit"

Thanks for trying all that! That is a bit of a shame. It looks like the data is just coming in too fast.

I just tried it here with your code and a Pixl running 2.18 with one of the receivers shown in http://www.espruino.com/433Mhz and I can get it to work...

It does show FIFO_FULL, and it doesn't always pick up the button presses - but if I press the button on the transmitter a few times it does tend to pick it up eventually.

What I did was used your code, but removed jit from the second function which only gets called once (it probably doesn't matter):

var n="";
function sig(e) {
  "jit"
  // The data we have received so far
  // The handler that gets called when the signal changes state
  // start listening for a change
  var d = 10000*(e.time-e.lastTime);
  if (d<2 || d>10) {
    if (n.length>20) console.log(n);
    n="";
  } else if (!e.state) n+=0|d>5;
}
function startListening(pin) {
  setWatch(sig, pin, {repeat:true, edge:"both"});
}
startListening(A0);

You can also try NRF.setConnectionInterval(100) which will slow down Bluetooth which gives the CPU more of a chance to handle the inputs coming in.

Not having jit at all it still works occasionally, but is even less reliable. Interestingly some buttons seem to be more reliable than others in the remote too - I'm not sure why that happens!

It's also interesting to see that the console gets pretty slow/unreliable - the data coming in is just too fast for it.

Checking on a scope I see pulses coming it at around 1kHz - so it'll be calling sig at 2kHz. It's a shame we can't get it handling signals just a bit faster.

... and interestingly using the 433 module doesn't work at all for me :( I'll see if I can add 'jit' in it

However the idea with debouncing is good? If you are sending 0/1 bits with some known minimal pulse length then debouncing to something less could save the CPU quite a lot by not firing the setWatch callback for shorter pulses? And maybe even filter out some noise so even some bits could be received despite the noise?

However the idea with debouncing is good?

I did try this, but it didn't seem to help noticeably - I think because the signal from the receiver already maxed out at 1kHz or so, and you couldn't debounce for more than that because that's about the rate that data comes in.

Interestingly some buttons seem to be more reliable than others in the remote too

Oh, I haven't actually tried all of the buttons :D (all I'm interested in were the first two since those were bound to the socket's on and off switch).

I'll try and see later if at least some of the buttons do work.

I'll also try the connection interval setting. Maybe even fanoush's suggestion of moving serial to a usb adapter might help.

Maybe even fanoush's suggestion of moving serial to a usb adapter might help.

Yes, if you can avoid having a BLE connection that would help.

As it's a Pixl you could not connect anything and just take a photo of what it prints on the screen, since it'll write to that if you're not connected to anything

Unfortunately I still get the FIFO full message even when disconnected from ble and having the output on the pixl's LCD :(

1 Attachment

I still get the FIFO full message even when disconnected from ble

Yes, you would do - but that doesn't mean it's stopped working - it just means that at some point it got a bit too much data for it to handle and dropped some, but it still stays working.

Do you not manage to get any output at all when using your transmitter?

Do you not manage to get any output at all when using your transmitter?

No, none at all unfortunately :( With all the buttons and trying to press it over and over.
I only ever get one message though, and I'm not able to get another response from the remote. Yeah it's still running; If I'm connected via ble terminal I can still inspect some variables (like the count example above)