Fast LED output is slow when using serial ultrasonic sensor


I am using a A02YYUW Waterproof Ultrasonic Sensor with a teensyLC. I would like to run a different pattern when someone is around 90cm away and then again when they are 5cm away. I am using fastLED and the uart serial pins 9 and 10 on a teensy LC (serial2)

I have it working to start with just filling the led strip with one colour. the colour changes when the sensor recognises the different distances. But when I change the strip to get an animation, it is really slow. I have tested the animations without the sensor and it is fine. This is my first time using serial and I am guessing that it is slowing things down but I am at a loss of why that is happening or how to go about fixing it. any help would be greatly appreciated. I feel a bit out of my depth using the serial, I am not very experienced with arduino code.

I am wondering if I should use the altserial library instead of the hardware serial AltSoftSerial Library, for an extra serial port

here is my code

#include <FastLED.h>
#define HWSERIAL Serial2 //setup pins 9 and 10 as hardware serial
//Led strip setup
#define DATA_PIN    2
#define LED_TYPE    WS2813
#define NUM_LEDS    78

#define BRIGHTNESS          125

byte data[4] = {};
float distance;
int distanceNoDec;
uint8_t gHue = 0; // rotating "base color" used by many of the patterns
uint8_t paletteIndex = 0;

    0,   0,   0,   0,   //black
  128, 255,   0,   0,   //red
  200, 255, 255,   0,   //bright yellow
  255, 255, 255, 255    //full white 

CRGBPalette16 myPal = heatmap_gp;
CRGB g_LEDs[NUM_LEDS] = {0};    // Frame buffer for FastLED

void setup() {
  // put your setup code here, to run once:
  delay(3000); // 3 second delay for recovery
  // tell FastLED about the LED strip configuration
  FastLED.addLeds<LED_TYPE,DATA_PIN,COLOR_ORDER>(leds, NUM_LEDS).setCorrection(TypicalLEDStrip);
  //FastLED.addLeds<LED_TYPE,DATA_PIN,CLK_PIN,COLOR_ORDER>(leds, NUM_LEDS).setCorrection(TypicalLEDStrip);

  // set master brightness control

void sinelon()
  // a colored dot sweeping back and forth, with fading trails
  fadeToBlackBy( leds, NUM_LEDS, 20);
  int pos = beatsin16( gHue, 0, NUM_LEDS-1 );
  leds[pos] += CHSV( gHue, 255, 192);

void loop() {
  // put your main code here, to run repeatedly:

  do {
    for (int i = 0; i < 4; i++)
      data[i] =;
  } while ( == 0xff);


  if (data[0] == 0xff)
    int sum;
    sum = (data[0] + data[1] + data[2]) & 0x00FF;
    if(sum == data[3])
      distance = (data[1] << 8) + data[2];
      distanceNoDec = distance;
      ((distanceNoDec < 900) && (distanceNoDec >50))
        Serial.println("person is recognised"); 
        fill_solid(leds,NUM_LEDS, 0);
      else if (distanceNoDec <50)
        Serial.println("person is very close");
         fill_palette(leds, NUM_LEDS, paletteIndex, 255 / NUM_LEDS, myPal, 255, LINEARBLEND);
        Serial.println ("no person");
        fill_solid(leds, NUM_LEDS, 0);;
    }  else Serial.println("ERROR");

Oh and i've just seen that altsoftserial won't work with the teensy LC

I have a teensy 3.2 I can switch to if altsoftserial would be the way to go

#define LED_TYPE    WS2813#define COLOR_ORDER GRBThis looks like a bit of a contradiction, not your issue but still…CRGB leds[NUM_LEDS];also this is set for RGB only.
This is not the way

do {
    for (int i = 0; i < 4; i++)
      data[i] =;
  } while ( == 0xff);

The normal way is to read() while HWSERIAL.available()
now you discard every 5th byte. Not only that, you may be reading bytes that are not actually in the buffer.

I am wondering if I should use the altserial library instead of the hardware serial

No. hwSerial is always the preferred option if you have a UART available.
Anyway the type of Serial is not the issue, it is the way you read data from it.

The message format seems to be:
0xFF, highByte, lowByte, checksum, 0xFF

The checksum is the sum of the first three bytes. The 16-bit distance (highByte, lowByte) is in mm.

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.