search

Yona-Appletree / LEDscape

Beagle Bone Black cape and firmware for driving a large number of WS281x LED strips.
126 stars 58 forks source link

WS2811 not working #38

Open SummerSeaSun opened 8 years ago

SummerSeaSun commented 8 years ago

Hi, I've tried the defaul config "ws281x" with a strip of 5vdc WS2812B and everything was fine. Then I've replaced the strip with a 12Vdc WS2811 with one chip driving 3 led and the strip turns on but doesn't respond correctly to signals.

this is how I've wired the WS2811:

12vdc power supply( + ) ---------------- STRIP (+) 12vdc power supply( - ) -----------------STRIP (-) STRIP( DI ) ---------------- level shifter (H1)

5vdc power supply( + ) ---------------- level shifter (H) 5vdc power supply( - ) ----------------- com (-)

3V3 BEAGLEBONE ---------- level shifter (L) CHANNEL0 PIN ---------------level shifter (L1)

every help is really appreciated, BR

Yona-Appletree commented 8 years ago

I've seen those modules require different voltages for signal. Try a 5v signal. Other than that, it's hard for us to help because it sounds like LEDscape is working correctly for your WS2812Bs, and that the problem with the other modules is specific to them.

SummerSeaSun commented 8 years ago

Thanks for the help, I've already tried the signal at 5v with the level shifter. With raspberry no problem in driving them using rpi_ws281x library.

Could it be an issue on the speed of WS2811, is there a way to set low or high speed mode?

Yona-Appletree commented 8 years ago

LEDscape only supports 800mhz ws2811, unfortunately. I personally have never encountered one of the slower ones, nor have we received any requests for support for them (other than this). It wouldn't be very hard to add support, however. Can you verify that your LEDs are of the slower sort by checking the parameters of rpi_ws281x or by using a logic analyzer? Thanks.

jammerxd commented 3 years ago

I too am having problems with WS2811 strips. I also have a WS2815 strip that I tried and neither of them functioned with LEDscape. Can you make specific timing templates for them instead of ws281x.p make ws2811.p, ws2812B.p, ws2815.p, etc...? I'm not even sure how to adjust the timings based on the data sheets because I don't know enough about your structure to make those changes. Where is the low time defined? Where is the high time defined? Where is the reset time defined? I can't pick out what's going on in the .p file to adjust the ws281x.p to my needs.

bigjosh commented 3 years ago

@jammerxd

I know the PRU code well and can make timing adjustments for you if necessary, but first let's make sure that is the problem.

Are you using a 5 volt level shifter to feed the data in signal of the strips? It is not always necessary, but some strips require it.

Do you have an Arduino handy that you could use to test these strips?

jammerxd commented 3 years ago

Hi @bigjosh,

Thanks for the answer, I've got an arduino and when I use fastLED and set the LED type accordingly, the strip works fine(using WS2811 timing for the WS2815 has been fine - WS2812 and WS2812B timing for the WS2815 strip produces the same result I see on the beaglebone).

I'm not sure if a logic level shifter is required for the WS2811. I've got the WS2815 strip that doesn't require it when hooked up to the arduino. I'm using an arduino UNO for reference.

I've also had the WS2815 strip hooked up directly to a raspberry pi without issues as well.(The pi is just too slow)

I haven't tried the WS2811 on the arduino yet because I can't determine if the WS2811 needs 5v or 3.3v for DI and if the arduino UNO digital out is 3.3V or 5V.

Also to clarify on the strips I have:

1xWS2815 - 300 Pixels 2xWS2811 - 160 Pixels ea.

bigjosh commented 3 years ago

UNO digital out is 5V and WS2811 uses 5V for data lines. Almost all strip types I've seen use 5V for data lines. Some strips will work connect directly to BB's 3.3v data lines, but not all. So things that could be wrong...

  1. Bad strip
  2. Voltage level mismatch
  3. Timing

To rule out case 1, get the strip to work with an Arduino.

To rule out case 2, take any strips that work on Arduino and try them on BB with a level converter.

If then you are left with only case 3 possible then I can make you a version with different timing, but looking at the data sheets for both 2811 and 2815, the timings seem to be within the specs of the standard 2812B timings (assuming the WS2811 is running in high speed mode.

LMK what you find!

jammerxd commented 3 years ago

Hi @bigjosh ,

Is there a link you can give to me of a pre-assembled logic level shifter that requires no soldering?

That's the last part I'm stuck on as the WS2811 strips work fine on an arduino and a raspberry pi 3 model b+ when hooked up to data directly.

Thanks

bigjosh commented 3 years ago

The Pi is also only 3.3V, so if your strips work on it then it is not a voltage issue.

Can you send me a gist with the code (including any settings and #defines) you are using on the Arduino? I can then run it on an Arduino here and capture the exact timings it is generating and make a .p module to reproduce them on the BBB.

jammerxd commented 3 years ago

Hi @bigjosh

Sorry I didn't see this until now,

Here's the arduino code I'm using:

https://gitlab.com/jammerxd/ledspectrumanalyzer/-/blob/master/arduino/music_led_mirror/music_led_mirror.ino

I'm actually using the WS2811 timings. I think it's just because this package requires such an out of date debian package I've had such trouble even getting this to setup correctly.

The debian packages for wheezy don't even exist anymore so I can't get updates and install new packages - including vncserver and htop - the animations even for a single strand at 150 pixels is 5 fps, not the 160 showed in the output.

root@beaglebone:~# apt-get update

Hit http://repos.rcn-ee.com wheezy Release.gpg
Ign http://security.debian.org wheezy/updates Release.gpg
Ign http://security.debian.org wheezy/updates Release
Hit http://repos.rcn-ee.com wheezy Release
Ign http://httpredir.debian.org wheezy Release.gpg
Ign http://httpredir.debian.org wheezy-updates Release.gpg
Get:1 http://repos.rcn-ee.com wheezy/main armhf Packages [124 kB]
Ign http://httpredir.debian.org wheezy Release
Ign http://httpredir.debian.org wheezy-updates Release
Err http://security.debian.org wheezy/updates/main armhf Packages
  404  Not Found [IP: 151.101.66.132 80]
Err http://security.debian.org wheezy/updates/contrib armhf Packages
  404  Not Found [IP: 151.101.66.132 80]
Err http://security.debian.org wheezy/updates/non-free armhf Packages
  404  Not Found [IP: 151.101.66.132 80]
100% [Waiting for headers]
Err http://httpredir.debian.org wheezy/main armhf Packages
  404  Not Found [IP: 199.232.30.132 80]
Err http://httpredir.debian.org wheezy/contrib armhf Packages
  404  Not Found [IP: 199.232.30.132 80]
Err http://httpredir.debian.org wheezy/non-free armhf Packages
  404  Not Found [IP: 199.232.30.132 80]
Err http://httpredir.debian.org wheezy-updates/main armhf Packages
  404  Not Found [IP: 199.232.30.132 80]
Err http://httpredir.debian.org wheezy-updates/contrib armhf Packages
  404  Not Found [IP: 199.232.30.132 80]
Err http://httpredir.debian.org wheezy-updates/non-free armhf Packages
  404  Not Found [IP: 199.232.30.132 80]
Fetched 1 B in 6s (0 B/s)
W: Failed to fetch http://security.debian.org/dists/wheezy/updates/main/binary-armhf/Packages  404  Not Found [IP: 151.101.66.132 80]

W: Failed to fetch http://security.debian.org/dists/wheezy/updates/contrib/binary-armhf/Packages  404  Not Found [IP: 151.101.66.132 80]

W: Failed to fetch http://security.debian.org/dists/wheezy/updates/non-free/binary-armhf/Packages  404  Not Found [IP: 151.101.66.132 80]

W: Failed to fetch http://httpredir.debian.org/debian/dists/wheezy/main/binary-armhf/Packages  404  Not Found [IP: 199.232.30.132 80]

W: Failed to fetch http://httpredir.debian.org/debian/dists/wheezy/contrib/binary-armhf/Packages  404  Not Found [IP: 199.232.30.132 80]

W: Failed to fetch http://httpredir.debian.org/debian/dists/wheezy/non-free/binary-armhf/Packages  404  Not Found [IP: 199.232.30.132 80]

W: Failed to fetch http://httpredir.debian.org/debian/dists/wheezy-updates/main/binary-armhf/Packages  404  Not Found [IP: 199.232.30.132 80]

W: Failed to fetch http://httpredir.debian.org/debian/dists/wheezy-updates/contrib/binary-armhf/Packages  404  Not Found [IP: 199.232.30.132 80]

W: Failed to fetch http://httpredir.debian.org/debian/dists/wheezy-updates/non-free/binary-armhf/Packages  404  Not Found [IP: 199.232.30.132 80]

E: Some index files failed to download. They have been ignored, or old ones used instead.
root@beaglebone:~#
root@beaglebone:~/LEDscape-yona2# ./opc-server --no-lut --no-dithering --no-interpolation --count 150 --strip-count 1
root@beaglebone:~/LEDscape-yona2# ./opc-server --no-lut --no-dithering --no-interpolation --count 150 --strip-count 1
[main] Starting server on ports (tcp=7890, udp=7890) for 150 pixels on 48 strips
[main] Demo Mode Enabled
[udp] Starting UDP server on port 7890
[render] Starting render thread for 7200 total pixels
Starting demo data thread
[main] Initializing / Updating server...[tcp] Starting TCP server on 7890
Allocating buffers for 7200 pixels (172800 bytes)
[e131] Starting UDP server on port 5568
frame_size1=7200
[render] Awaiting server initialization...
[demo] Starting Demo: fade
[main] Starting LEDscape...[e131] Joined multicast group 239.255.0.0 on 10.0.1.25
[e131] Joined multicast group 239.255.0.0 on 192.168.7.2
pru_init: PRU 0: data 0xb454b000 @ 8192 bytes,  DMA 0xb44cb000 / 9f3c0000 @ 262144 bytes
pru_init: PRU 1: data 0xa444d000 @ 8192 bytes,  DMA 0xa43cb000 / 9f3c0000 @ 262144 bytes
String PRU0 with pru/bin/ws281x-original-ledscape-pru0.bin... OK
String PRU1 with pru/bin/ws281x-original-ledscape-pru1.bin... OK
{
        "outputMode": "ws281x",
        "outputMapping": "original-ledscape",
        "demoMode": "fade",
        "ledsPerStrip": 150,
        "usedStripCount": 1,
        "colorChannelOrder": "BRG",
        "opcTcpPort": 7890,
        "opcUdpPort": 7890,
        "enableInterpolation": false,
        "enableDithering": false,
        "enableLookupTable": false,
        "lumCurvePower": 2.0000,
        "whitePoint": {
                "red": 0.9000,
                "green": 1.0000,
                "blue": 1.0000
        }
}
[render] fps_info={frame_avg_usec: 213, possible_fps: 4694.84, actual_fps: 0.10, sample_frames: 1}
[render] fps_info={frame_avg_usec: 6227, possible_fps: 160.59, actual_fps: 155.60, sample_frames: 1556}

I also had to modify the /boot/uEnv.txt file to even get this to work and I'm still not sure that it's working correctly because the cape-universala device tree doesn't exist:

#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

uname_r=3.8.13-bone80
#uuid=
#dtb=
enable_uboot_overlays=1
##BeagleBone Black/Green dtb's for v4.1.x (BeagleBone White just works..)

##BeagleBone Black: HDMI (Audio/Video) disabled:
#dtb=am335x-boneblack-emmc-overlay.dtb

##BeagleBone Black: eMMC disabled:
#dtb=am335x-boneblack-hdmi-overlay.dtb

##BeagleBone Black: HDMI Audio/eMMC disabled:
#dtb=am335x-boneblack-nhdmi-overlay.dtb

##BeagleBone Black: HDMI (Audio/Video)/eMMC disabled:
#dtb=am335x-boneblack-overlay.dtb

##BeagleBone Black: wl1835
#dtb=am335x-boneblack-wl1835mod.dtb

##BeagleBone Green: eMMC disabled
#dtb=am335x-bonegreen-overlay.dtb

cmdline=coherent_pool=1M quiet init=/lib/systemd/systemd

#In the event of edid real failures, uncomment this next line:
#cmdline=coherent_pool=1M quiet init=/lib/systemd/systemd video=HDMI-A-1:1024x768@60e

##Example v3.8.x
#cape_disable=capemgr.disable_partno=
#cape_enable=capemgr.enable_partno=

##Example v4.1.x
#cape_disable=bone_capemgr.disable_partno=
#cape_enable=bone_capemgr.enable_partno=

##Disable HDMI/eMMC (v3.8.x)
#cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G

##Disable HDMI (v3.8.x)
#cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN

##Disable eMMC (v3.8.x)
#cape_disable=capemgr.disable_partno=BB-BONE-EMMC-2G

##Audio Cape (needs HDMI Audio disabled) (v3.8.x)
#cape_disable=capemgr.disable_partno=BB-BONELT-HDMI
#cape_enable=capemgr.enable_partno=BB-BONE-AUDI-02

enable_uboot_cape_universal=1

##enable Generic eMMC Flasher:
##make sure, these tools are installed: dosfstools rsync
#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh

#PRU RPROC
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo
#PRU UIO
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
disable_uboot_overlay_emmc=1
disable_uboot_overlay_video=1
disable_uboot_overlay_audio=1
uboot_overlay_addr4=/lib/firmware/cape-universal-00A0.dtbo

Additionally, the WS2815 strip still isn't functioning quite right, the timing is close, but still not quite right. It looks like only every other pixel is getting updated with the correct color - if I run a test program setting a solid color to all pixels every 5s then everything works fine. I've tried this both with and without the logic level converter. WS2811 strip seems fine without the converter off of the beaglebone.

bigjosh commented 3 years ago

Maybe try this ready-to-run image from my repo...

https://github.com/bigjosh/De-Harak-Clock-Controller/releases/tag/1.0BB

Put it on an SD card, then burn that into a BBB. Connect pixel strings to any or all of these pins....

image

...and see what you see.

Note I can do apt-get update in this image and it seems to work fine. Root user is root, no password.

jammerxd commented 3 years ago

Thanks,

I'll give this a try - just out of curiosity, is there a way to have there be more than 7 channels?

Also - does this have the Open Pixel Control server built into it? That's why I was using this repository. I need the network control capability.

Josh

bigjosh commented 3 years ago

is there a way to have there be more than 7 channels?

Yes, you can edit the ledscape.config after you successfully test with channels 0-7. The purpose of the test is to eliminate possible sources of problems, so initially use those channels and do to make any changes to the image config.

You should expect to see the fade demo on any LEDs connected to those pins after the BBB boots up.

jammerxd commented 3 years ago

Trying this now - I'll let you know! Thank you so much!

jammerxd commented 3 years ago

Channel 0 produced a rapid red fade pattern that lasted only a second or 2, it still looked really rough in terms of FPS - i.e. it wasn't smooth.

jammerxd commented 3 years ago

I ran my own demo c# code and it looks like it can handle the FPS I want now. I don't know why there were so many issues before. Thank you so much! The timings look good for the WS2811 and WS2815 strip.

jammerxd commented 3 years ago

Can you update that image with a full mapping of all the channels and any other steps needed to enable them? I know I can go into the ledscape.config file and adjust the led strip count but I don't know what the other channels are mapped to due to conflicting data.

bigjosh commented 3 years ago

The pin mapping scheme is set with the outputMapping param in the /etc/ledscape-config.json. You can see the scheme mapping files in pru/mappings/*.json. You can also print a channel-to-pin map using the command node pru/pinmap.js --mapping <mapping-id> where <mapping-id> is the mapping ID you want to print.

bigjosh commented 3 years ago

https://github.com/bigjosh/LEDscape#pin-mappings

jammerxd commented 3 years ago

Thanks @bigjosh for helping with this! Looks like everything is all set to be expanded! WS2815 and WS2812 strips work fine, I'm just wondering what I'm supposed to do if I have varying lengths of LED strips per channel and if that's something that's even supported? It also appears that when using OPC, all channels are treated like channel 0. i.e. If I want to control just channel 2 I'd send 2 as the channel in the OPC protocol but it gets ignored and sent to channel 0 as well as channel 2

bigjosh commented 3 years ago

what I'm supposed to do if I have varying lengths of LED strips

Tell ledscape the length of the longest strip. When sending packets, pad the shorter channels so all channels are the same length (the actual length of the longest one).

nargetdev commented 2 years ago

Thank you @bigjosh so much for preparing that flasher image. That is the way to deploy. After much headache between wheezy eMMC/SD card management -or- attempting to compile/run on 4.19 your deployment is the winner by far.. this should be bumped up in the master README.

..anyhow, I'm still struggling to get all 48 channels of output to show up. When I adjust the config to the following:

{
    "outputMode": "ws281x",
    "outputMapping": "original-ledscape",
    "demoMode": "black",
    "ledsPerStrip": 94,
    "usedStripCount": 48,
    "colorChannelOrder": "BRG",
    "opcTcpPort": 7890,
    "opcUdpPort": 7890,
    "enableInterpolation": false,
    "enableDithering": false,
    "enableLookupTable": true,
    "lumCurvePower": 2.0000,
    "whitePoint": {
        "red": 0.9000,
        "green": 1.0000,
        "blue": 1.0000
    }
}

... and send appropriate data, I can see I think 25 channels active total. I can see data for example on P8_35 and P8_33 with your attached image above - so this means that HDMI must be disabled right? But I still have no joy on the other pins in the p8_27 - p8_46 range.

Whenever I copy down the uEnv.txt in the repo to the /boot dir things go pear shaped and I need to reflash the entire image.

For now I've been going with https://github.com/iontank/ThrowingBagels because it works out of the box on modern distros, but their packet format is a bit funny (two datagrams per frame, splitting each strip first half in one, second half in the other)...

Anyways I would love to help and bring this repo up to date. Among the forks @Geocene https://github.com/Geocene/LEDscape has done the best job with 4.19 - it's the only one where i've managed to get a fully running install on the newest distro. But I'm still stuck at only 25 working outputs (with a couple in the HDMI range). Note that this is RevC.. I'm going to try one of my older beagles and see if that's it.

bigjosh commented 2 years ago

@nargetdev Hmmm... there are several things that could prevent ledscape from getting to some of the pins. There is all of the devicetree stuff which can be a pain, and the HDMI stuff too which I think requires out-of-band modifications to files that are not in the normal file system. I am away from my BBB for a couple of weeks, but those are the first places I would look. Try to map which pins are working and which are not (pretty easy using a pixel strip or oscilloscope ) and try to notice the pattern, and then see fi you can manually "fix" one of the not working pins by manual messing with its devicetree or pinmode. Report back what you find!

nargetdev commented 2 years ago
image

fwiw here is an image of the pins that are working. The blue pins are working. Ignore the red (my PCB haha)

nargetdev commented 2 years ago

I see this among the logs at boot time:

uboot_overlays: [uboot_base_dtb=am335x-boneblack-uboot-univ.dtb]

Does this mean it chose the wrong dtb or can there be multiple loaded at different times (i.e. does ledscape.service set the dtb at runtime?)

bigjosh commented 2 years ago

It has (intentionally) been many years since I messed with the devicetree stuff. Once I get it to work for a given setup then I don't touch it. There can be multiple DTBs in the /boot and it is complicated.

I'd maybe pick a pin that is currently not working but has no other plausible systems trying to use it and then track down why it is not working on your system. By default, this version of ledscape accesses these pins as memory mapped GPIO (not as PRU IO like Trammel's original versions). This means you can use all of the googleable info on getting a pin to be GPIO, and once you get it to work as normal GPIO then this ledscape should work with it. There is a bunch of PINMODE stuff you can google that might help. Capemanager is also possibly involved here. It is a mess. Sorry.

bigjosh commented 2 years ago

Completely aside, if you are making a custom PCB, I'd strongly suggest connecting a free GPIO to the reset pin if you can so you will have a hardware way to deal with the horrible dead-ethernet port problem on BBB...

https://wp.josh.com/2018/06/04/a-software-only-solution-to-the-vexing-beagle-bone-black-phy-issue/