Alternative to digitalPulse for remote control sockets?

I started off using remote control sockets on an Espruino Pico, which worked great. I then switched to a Pixl.js, and suddenly things were not so great. Sometimes it works, and sometimes it doesn't.

I've traced it to this issue, which explains that the NRF52 does not have the same accurate timing as the STM32.

Now I'm wondering if there's another way to send the right pulse stream to the 433.92MHz transmitter, or at least get my new remote control sockets working reliably with the Pixl.js?

Is your Pixl.js firmware up to date? And you're using the code from that remote control sockets example?

Did you actually see the waveforms it sends getting messed up?

It shouldn't be that limited. After all we use exactly that code fine on nRF52 for sending IR control signals from Puck.js and it's fine. Even if it were only accurate to 1/32kHz, that should still be more than enough for the 0.3ms signal pulses that are send out.

I was on 2v06, so just updated to 2v07 to be sure. No difference.

I'm using the code from the example, but found that I had a little bit more success on Pixl.js by changing

digitalPulse(TX,1,0.9);
digitalPulse(TX,0,0.3);

to

digitalPulse(TX, 1, [0.9, 0.3]);

I was also able to increase the chances of success by sending 40 times instead of 10 times, and it works better for some pulse trains than others (in my case, using button 2 's pulses instead of button 1).

All this led me to believe that it may be jitter due to the RTC. I will try to hook up my logic analyser to see if it is indeed the actual waveforms getting messed up.

• Would the digitalPulse(TX,1,0.001) at the end of the pulse train be affected by the RTC?
  
• Also, does it matter whether I use an analog pin vs a digital pin?
  

Using a logic analyser, the Pico pulse trains are 27.4ms long, pretty close to the 25 * 1.1ms = 27.5ms:

The Pixl.js pulse trains are 29.7ms long:

I used the remote control example code for both, just changing from A6 on the Pico to D13 on the Pixl.js, and modifying the pulse train sequences for my sockets.

Please could you try:

function sendCommand(command) {
  var bits = (CODE & ~0b11111) | command;
  var pulses = [];
  for (var i=24;i>=0;i--) {
    if ((bits>>i)&1) {
      pulses.push(0.9,0.3);
    } else {
      pulses.push(0.3,0.9);
    }
  }
  pulses.push(0.001);
  digitalPulse(TX,1,pulses);
}

That might fix it - it's possible that because the Pixl is a bit slower than STM32 boards it's actually struggling to go around the loop and call digitalPulse again before all the pulses have already gone out?

Sending them all in one go might sort it.

Gave it a try, but the Pixl.js pulse train is still 29.7ms.

Ok, thanks - I'll take a look in the next few days. There are other solutions (like using SPI) but obviously fixing this properly would be ideal

Hi @Gordon! Did you manage to look into this issue more at all? I know you were working on https://github.com/espruino/Espruino/issues/1749, but that didn't seem to resolve it.

If this is not fixable in the near future, how would I go about using SPI to do it? Would I just set up hardware SPI and write it out on the MOSI pin?

Not yet - I'll try and have another look soon. I think the changes improved matters slightly but it still wasn't great. To do SPI, I'd do something like:

SPI1.setup({ mosi: output_pin, sck : pin_you_dont_use, bitrate: 125000 });
var data = new Uint8Array(18*24);
var n = 0;
function push(on, cnt) { while (cnt--) data[n++]=on?0xff:0; }
// now fill data with bytes - 0xFF for 1, 0x00 for 0
for (var i=24;i>=0;i--) {
    if ((bits>>i)&1) {
      push(1, 13);
      push(0, 5);
    } else {
      push(1, 5);
      push(0, 13);
    }
  }

SPI1.write(data);

Not tested, but that's the rough idea - create a big array with 0 for off, 0xFF (all 1s) for on - and transmit it. nRF52 should do that via DMA which will be nice and smooth

Thanks so much for the code example! I spent most of Friday evening trying to get this to work, but still no dice. I hooked it up to the logic analyser again, and noticed that the timings on the Pico are not as accurate as what I originally though, but it still works, even though similar timings on the Pixl.js are not working.

Would it at all be possible for you to try and reproduce the issue with Pixl.js and the remote control sockets, just so that we know I didn't make a mistake somewhere else?

Honestly, it seems the best bet for me is to try and get the initial timing reliable. I'll try and look into it this week.