Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 4 of 4

Thread: OctoWS2811 pixel corruption with dim brightness values

  1. #1
    Junior Member
    Join Date
    Aug 2013
    Posts
    7

    OctoWS2811 pixel corruption with dim brightness values

    I'm having problems with OctoWS2811 with specific low-intensity bit patterns when we have multiple Teensy3's connected to the same machine. The conditions seem somewhat specific and hard to pinpoint: with only one teensy on my laptop it is ok, but fails when there are multiple teensys, and on the BeagleBone Black it fails with even just one teensy connected. It is repeatable across the four boards that I have here. The Teensy's are running stock VideoDisplay firmware and are being powered by the external 5V@20A regulated supply and are not having any power issues.

    The two attached patterns for our LED strips differ in a single bit, but turning on that bit in pixel 0 on strip #4 causes all of the later pixels on all eight strips to be incorrect. The problem only appears to occur when the intensity on the adjacent strips are less than or equal to 7, which means that only the last three bits in each word are set.

    You should be able to cat good-pattern.bin > /dev/ttyACM1 to see the YGR diagonals and then cat bad-pattern.bin > /dev/ttyACM1 to see the bug. Instead of a uniform dim diagonal, what we get is something like this with intense blues and other colors:


    Bad LED checkerboard test pattern by hudson, on Flickr
    http://www.flickr.com/photos/osr/9484997647/

    I've also observed with this setup that drawing anything on strip #4 causes frequent USB failures on the BBB. Masking all of the sliced pixel data with 0xF7 to exclude seems to prevent this from happening (as well as preventing the color bug). Has anyone seen either of these before?
    Attached Files Attached Files

  2. #2
    Junior Member
    Join Date
    Aug 2013
    Posts
    7
    This is an easy fix and a frustrating bug. The low intensity bit pattern that messes things up included 0xA, also known as a newline character. Disabling OPOST in the termios prevents the tty from adding a carriage return, which adds one extra byte to the output stream, causing the bit stream to the LEDs to be shifted by one and making the LSB of red into the MSB of blue. The one line fix is:

    attr.c_oflag &= ~OPOST;


    I'm so used to Unix not screwing with line endings on file I/O that this is frequently a surprise when dealing with serial devices. Probably hasn't caused as many issues as endianness, but it is still one of those stupid gotchas waiting to trip up developers.

  3. #3
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,309
    Which linux distro did this?

    I saw this with a Beaglebone Black some time ago. It is very frustrating! I also saw one freshly installed Ubuntu (on PC hardware) default to this setting. But my desktop machine has never defaulted to this.

  4. #4
    Junior Member
    Join Date
    Aug 2013
    Posts
    7
    I saw it always with the BeagleBone Black, Xbuntu on my toughbook for /dev/ttyACM1-4 (but not ACM0?), and also Mountain Lion on my Macbook. With the termios fix everything is better now and our giant 7m tall pyramid of LEDs will be 12.5% more blinky with strip #4 re-enabled.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •