Multiple universe output is broken in v2 about espixelstick

[madsci1016]

I'm using 2.1Dev on a unit running 600 pixels over 3 universes in unicast with no issue. I just tested a starting channel >1 and got no flicker. Many other pixel controllers use 512 channels per universe just (e1.31 bridge for example) and others have the option to do either (Falcon controllers). My whole display of 27 universes all have pixels across boundaries with no issue, so I would not call that unusable.

I would not support hard coding it to 510 channels, but if you added it as a configuration option, that would cover all use cases.

[madsci1016]

A PixelStick clone is running my pixel icicles in this video I shot tonight: https://www.youtube.com/watch?v=MYto9DdOrcE That's the one running 600 pixels.

[asavartsov]

Okay, may be some controllers allow that, but all software I use doesn't allow that. For me it is broken...

For flicker, try bigger offsets, but on my setup I could reproduce with anything larger 1. Also if you eye-read the particular part of code you will see that it is plain wrong like it always trying to copy 512 channels from 1st universe e131 data, and with some offset it will give you access to the parts of memory that contains no pixel data. It may work if universes come in order but I don't think that should be done like that.

[asavartsov]

@madsci1016 I can make you a video reproducing the issue if you like, but I already had been sitting with sheet of paper and pencil and just did the math.

If problem with channel rounding doesn't affect anyone, I will just use 510 for my builds defined, but this should be stated in README that it will not work in any setup, but this probably should be configurable.

[asavartsov]

To be honest I quite missing PPU setting! My software allows to configure partial transmission of E1.31 universes. That simplifies patching of many "small" pixel sets and limits transmission bitrate. I use ESPixelStick for lighting wearable pixel costumes and other pixel props and sometimes it easy to give the universe for each instead of computing offsets. And as I said, all software I use doesnt allow pixel to cross universe boundary - this is true at least for Jinx!, QLC+ and Madrix (the last one is quite professional and allows very flexible patching, but I didn't manage it to use last two channels in the universe).

[asavartsov]

I updated corresponding pull request with removal of rounding to full RGB channels count since setups which use remaining channels. The one who need that may change the constant before the build, but I think it should be part of config since rounding and the partial transmission are perfectly valid E1.31 scenarios.

[cmlara]

I am just getting started on using the ESPPixelStick firmware, but I do want to chime in as well that this seems to be a valid point and that I expect I will hit this as well (QLC+)

This to me is a holdover to the fact that under hardwired DMX any fixtures generally can only be part of a single universe since they are a hardwired and most light fixtures (especially RGB lights) are one universe input only.

I can't say if E1.31 made any allowances for this as I don't know its full standard, but in cases E1.31 is just used as a communications protocol, sometimes it is just to a real DMX transmitters and other times it is to a direct receiver like the PixelStick but since DMX is suppose to be software agnostic it would seem this should be able to be handled in the receiver to make up for the fact that its a receiver for "Multiple fixtures on multiple universes" and as such may need to do some corrections for that.

That said, like the looks of the project, have some ESP8266's wired up for some testing and looking forward to putting a show on next year.

[forkineye]

Added Universe Boundary configuration as of v3.0rc2, replaces previous PPU config.