Timing issues with pigpio-client

[echo-bravo-yahoo]

I've written a timing sensitive application (infrared remote emitter); it sends data on a 37KHz (~37 microsecond) carrier wave. My first go at it, I used https://github.com/fivdi/pigpio (hereafter pigpio.js), which wraps the C bindings to pigpio (hereafter pigpio.c). It works very reliably, but has lots of other unpleasant properties (can only be run as root, and doesn't support concurrent runs).

I moved the application over to pigpio-client, and it initially worked. And then stopped working. And then I'd revert back to pigpio.js, and it would work. And, interestingly enough, if I ran the pigpio.js version, then rolled the application forward to the pigpio-client version, it would work until I restarted pigpiod.c or the pi.

This makes me suspect that there's some setting / configuration pigpio.js does that I'm not doing when I start pigpiod.c without any flags.

As for the application code, the strategy is to build an array of waves, and then send them with: await gpio.waveChainTx([{ loop: false }, { waves }, { delay: 0 }, { repeat: 1 }]). My hope here is to offload all the timing sensitive parts to pigpio.c's internal wave management.

Do you have any advice on how I'd go about debugging this?

[guymcswain]

This makes me suspect that there's some setting / configuration pigpio.js does that I'm not doing when I start pigpiod.c without any flags.

I think you are on the right track. Can you show the initialization prior to calling gpioInitialise?

And then stopped working

Can you provide any other information such as error codes returned by API calls, anything?

Since you mentioned 'concurrent runs': I have a remote ir emitter application currently 'in production'. Concurrency is not practical unless you devise a service through which you funnel all external requests. Essentially you want to protect the internal memory containing the wave ids and not allow a client to clear or clobber them.