Diagnosing interference between pulseIn and (interrupt-based) HL1606PWM library?

I have a sketch at... https://github.com/cefn/ReadingLights/blob/d6486f0508f7d6267057b8ee86f44750152859a5/lightUpLancaster/rainbowOnMovementHL1606/rainbowOnMovementHL1606.ino ...which successfully detects nearby objects and reports distances from the sensor over serial, so long as strip.begin() is commented out (as per the github version).

However, the moment strip.begin() is uncommented, and the interrupt- and SPI- logic of the Adafruit library is allowed to run, then the sensor always reports 0 distance and pulseIn never detects the sensor pulse, even when objects are placed directly in front of the distance sensor.

I'm using Adafruit's HL1606PWM library for full color control of a strip of 32 LEDs, which works well. I'm also using a HC-SR04 ultrasonic sensor to detect movement using pulseIn, and this works well. However, combining them in a sketch seems to be very bad news, even if the LEDs are off, and therefore drawing minimal power, so I'm assuming it's a software issue and really need to work out how to get them to play nicely. I gave up using NewPing because it depended on interrupts and could conflict through shared use of the same Timer but using pulseIn to detect the ultrasonic sensor shouldn't have this dependency I think, so it's really blind-sided me with very little time left to go before an installation.

Because of the nature of the project, it's not needed to run both the ultrasonic and the LEDs at the same time, so if I need to deactivate one in order to run the other, that's fine, but currently if the LED strip is ever activated, the pulseIn invocation then always returns 0 from the echo pin of the ultrasonic sensor for the lifetime of the sketch.

The sensor fails to detect even if I bracket the pulsein(...) invocation with noInterrupts() then interrupts(), which I think should prevent the strip library from taking over the processor in the middle of a pulseIn. The sensor fails to detect even if I remove the maxDuration value which determines the maximum wait time from pulseIn.

Can anyone suggest a software issue which would mean that pulsein stops working correctly when using the (Timer2 interrupt-based) HL1606 library (which you can see at https://github.com/adafruit/HL1606-LED-Strip-PWM ). Are there sensible workarounds in rewiring or reprogramming to be able to have them both attached and functioning (even at different times)?

If you disconnect the led strip but keep the code intact does pulseIn() still fail?

can you post a schema and a minimal version of the code that shows the issue?

Yes, I can recreate the problem with and without the LED strip entirely detached using the minimal code below.

This code is functional (reports varying distances as you put your hand in front of the sensor) unless the strip.begin() line is uncommented to enable the SPI and Interrupt code of the LED strip with the Adafruit library, and then it fails (always reporting 0 as a result from pulseIn, and hence always reporting 0 distance).

#include "HL1606stripPWM.h"

int triggerPin = 12;
int echoPin = 9;
long maxDuration = 16000; //longest time a pulse might take in microseconds

int latchPin = 10;
HL1606stripPWM strip = HL1606stripPWM(2, latchPin); 

void setup(){
  //configure pins for Ultrasonic sensor
  //configure strip

void loop(){
  //wait on response
  long duration, distance;
  duration = pulseIn(echoPin, HIGH, maxDuration);
  distance = (duration/2) / 29.1;

Ah I think I understand schema, now - a wiring diagram, sorry.

The circuit currently has only those pins indicated in the sketch. VCC and GND is provided to power the HC-SR04 and Trigger and Echo pins on the HC-SR04 are attached to digital pins 12 and 9 respectively. That's the entire circuit.

I haven't detailed the wiring as it seems so innocuous and unlikely to be this, given the difference in behaviour between commenting and uncommenting the strip.begin() behaviour.

I'm imagining it's something to do with HL1606 use of timers, interrupts, and the use of delayMicroseconds and pulseIn (which may implicitly depend on some timer configuration). However, I can't see anything online which indicates an issue of this kind, hence wondering if an expert eye could help.

As a workaround, I'm trying to reimplement pulseIn and delayMicroseconds from scratch, as these are the only invocations which are needed to use the HC-SR04 although it's weird that I can't figure out how it's not working, these functions use some fairly fancy shortcuts and difficult for me to know if there's a negative interaction between these and the Interrupt logic of the HL1606 PWM library.

In the end, a resolution became possible using Hugokernel’s latest commit to PaintYourDragon’s HL1606 (PWM) library.

This was combined with some hit-and-hope testing around the maximum LED update rate which the ATMEGA could handle at the same time as the slowest available Serial connection and alongside the Ultrasonic Ping logic. Finally I had some stable code I could deploy, although using the HC-SR04 at the same time as the HL1606 strip seemed impossible, using Hugokernel’s end() method it was at least possible to turn off the strip and suspend interrupts (using noInterrupts wasn’t equivalent) when I wanted to use the Ultrasonic, then toggle back to using the LED strip when I needed.

However, even with this intervention, I had to carefully select LED library parameters to avoid HC-SR04 non-responsiveness and other hangs.