Shop Learn P1 Docs P2 Docs
"Blitzen 24" E1.31 Pixel Light Controller Updates thread. — Parallax Forums

"Blitzen 24" E1.31 Pixel Light Controller Updates thread.

ke4pjwke4pjw Posts: 693
edited 2022-04-26 03:45 in Propeller 2

Creating a new thread dedicated to progress on my pixel light controller.

Older information can be found here and here

Source code and up to the moment project status can be seen here.

The past few weeks I have completed the E1.31 configuration via web browser:

Additionally, I have adopted a "Running Config" and "Boot Config" type of paradigm for the controller, like you would see with Cisco IOS. This allows you to tweek the settings and can return to what you started with by power cycling. You can also download and upload the configuration via web browser. Configuration is stored on the SD card.

The last core functionality missing is configuring the outputs for 400khz and 800khz, as well as pixel color order.

At this time, I do not think I want to support RGBW pixels.

If anyone is interested in contributing to the project, please reach out. I have a spare W6100.



  • msrobotsmsrobots Posts: 3,562

    this looks very good.


  • Thanks @msrobots !

    Here is a video of updating the config on the fly.

  • Cool project

  • I am close to an initial release. There is some technical debt that needs to be eliminated first.

    Output configuration page is working.

  • ke4pjwke4pjw Posts: 693
    edited 2022-05-17 03:20

    I have 9 W6100L chips arriving tomorrow. I need to complete the board layout. I am going to build the first few to use P2Edge cards, because it is easy :) It will require Edge cards with an SD slot. The board will have level corrected (5v), buffered outputs with matching resistors to drive the pixels.

    I am currently adding quad DMX outputs. The last feature is to drive a small SSD1331 display to show the IP address. I will then call it a 1.0 Release.

    Strech goal will be to have it be able to upgrade itself via the Internet. I will have to implement DNS, but that shouldn't be too hard.

    Unfortunately for the project, boat season has arrived. That means I will have less time to dedicate to the project, however I intend to actually schedule time for the project each week.

    If anyone is interested in contributing, let me know. Even if to be a tester/user. I will probably have half a dozen boards available by mid-July.

  • YanomaniYanomani Posts: 1,519

    @ke4pjw said:

    If anyone is interested in contributing, let me know. Even if to be a tester/user. I will probably have half a dozen boards available by mid-July.

    As for using P2 Edge cards in your project, while you're still at the design/layout phase, perhaps I can add a mild contribution...

    There are two forcefully NC pins (1 and 2) at every Edge card that I believe wheren't used in any of the currently available breakout or breadboard versions, intended to be unused, mainly due the fact that, in case of reverse-installing the Edge at the connector (180º), the card Edge pads that would get connected to them are the VIN_Edge ones.

    Also, in case of reverse-installing the P2 Edge, connector pins P35, P36, and P37 will get shorted due to the fact that the respective pads are GND at the Edge card.

    The above didn't mean the Edge card can be harmed in any way by inserting it reversed, at the connector, but I don't know anything about the way you've planed to use P2_IO35 thru P2_IO37 at your board (nor even if they were used, at all).

    So, perhaps there's at least one way of leveraging the fact that, in case of a reverse-installed Edge card, those two "now-shorted-pins" can be used to preclude your board to "misbehave" in any way it could get harmed, due to that "now-twisted-Edge-condition".

    Hope it helps


  • ke4pjwke4pjw Posts: 693
    edited 2022-07-11 04:05

    Thanks for the info Henrique!

    It is mid-July and I haven't finished board layout. I need to get that complete. I added the OLED code, so that you will know the IP address of the Blitzen upon boot. It also displays the MAC address, and has icons for E1.31 status and Ethernet status.

    The E1.31 icon is red if no E1.31 packets are received in the past second, green if it has, and yellow if there were any discards. Discards are E1.31 packets where the destination universe is not known to the Blitzen and is discarded.

    The Ethernet icon is red if disconnected, yellow if link is down, and green if both cable is plugged in and link is up.

    Counters were added to the homepage that count received E1.31 packets and discards.

  • ke4pjwke4pjw Posts: 693
    edited 2022-08-22 23:00

    Just a quick update. I did a board layout using traditional through hole components and the P2 Edge. Looks like everything from a hardware perspective worked out first try, though I am going to move some components around to give some wiggle room before doing a small production run.

    The board has 24 pixel outputs that can be supported by 4 separate power supplies. Pixel power supply can be independent from powering the logic on the board. Logic for the board can be driven by 5v or 12v supplies. (Most pixels are 5v or 12V) Each pixel output has its own fuse. Pixel outputs are driven by 5V line drivers with a 100ohm resistor on the output.

    Hardware To Do:
    Validate the quad DMX output hardware works as expected. This feature is incomplete in the software.
    Validate HDMI output on the 12 pin connector actually works.

    Software to do:
    Complete implementation of Quad DMX output.
    Fix the pixel "glitching" that is visible in the video. Most likely a timing issue related to changing the matching resistor value.
    Complete implementation of pixel timing selection.
    Fix maximum pixels per cog based on maximum pixels per pin group.

    PS: Updated a couple of major bugs in the software last night. 24

  • JonnyMacJonnyMac Posts: 8,238


  • ke4pjwke4pjw Posts: 693
    edited 2022-08-23 17:33

    So, after verifying the hardware, when I went to add the quad-dmx object, I realized I'm
    Straight Outta Cogs

    1 - Main/Boot/Webserver Cog
    2 - SD Card Cog
    3 - HDMI Cog
    4 - Watchdog/Stats Cog
    5 - E1.31 Cog Time sensitive operation
    6 - Pixel Cog Time sensitive operation
    7 - Pixel Cog Time sensitive operation
    8 - Pixel Cog Time sensitive operation
    ? - Quad DMX Cog Time sensitive operation

    The ideal solution is a cogless SD card library. I may have to move the watchdog into the Webserver Cog, but yuck. I don't want to do that. Another option is it merge Pixel Cogs, but I don't know if there are enough cycles to do that.

    Good news is, I feel fairly confident in the hardware. The digital video board worked just fine. Only needed 4 pins. The other 4 are used for DMX.

  • It appears that @Rayman created a cogless version of the SDSPI/FAT32 driver by Kwabena/Cheezus/Cluso/Ada that I am using. Man, that's a driver decades long in the making :smiley:

    I am going to try it.

  • Production boards of the Blitzen 24 Edge are in. Hopefully I will have time over the next couple of weeks to test!

  • I have identified a timing glitch with ethernet introduced with the boards. The data leads on my board are much shorter than used on the Edge breadboard. I worked this out with waitx's when I first saw it with the breadboard. I didn't think that would cause a problem being shorter leads, but apparently it does. It manifests itself with incorrect data being placed in the pixel buffer and the webserver occasionally sending/receiving corrupt data. I am going to take some slo-mo video of the pixels glitching to see if it reveals anything interesting. I noticed last night that the glitches on a solid red line seemed to turn blue, so it may be some kind of "off-by one" issue I have never noticed before.

  • Cool project👍

Sign In or Register to comment.