Doesn't work with zero w

[ivanovsaleksejs]

Does this code work for you? It sends data but pixels don't work.

[branko623]

No it is still in development I am working with the board creator to debug, I guess I will make note of that. should be soon

[ivanovsaleksejs]

Can you describe the problem you've faced? Maybe I can help to find a solution.

[branko623]

We're talking about the same board, right? https://www.tindie.com/products/electromage/electromage-serial-to-8x-ws2812apa102-driver/ I have formatted the data being sent in specification to the creator's documentation, and have cross checked the CRC code with other applications that use this board. Bit for bit, it should be in order. Maybe the Serial call requires more configuration? I have no way to debug currently.

[ivanovsaleksejs]

Yes, the same board. I've investigated the firmware code for this product https://github.com/simap/pixelblaze_output_expander/blob/master/firmware/Core/Src/uart.c and it seems that the different crc table is used. Could it be the reason?

[branko623]

I don't think so, the CRC table I used was copied from https://github.com/simap/PBDriverAdapter/blob/master/src/PBDriverAdapter.cpp

Both tables yield the same 4 bytes, the difference I believe is in 4 bit vs 8 bit hashing (guessing that the 8bit uses more memory, but less cpu cycles...)

[ivanovsaleksejs]

I have one question: does this board come with preinstalled firmware or should I butn a binary inside?

[branko623]

I'm pretty sure it is preinstalled. This board is primarily a solution for pixelblaze owners. Let me know if you make any progress

[ivanovsaleksejs]

I kind of solved this issue however I'm not sure if the problem is with raspberry or with python. I changed baud rate to 2304000 and it helped. Can you try it on your end and let me know?

[branko623]

I am still not seeing pixels, but an orange LED on the expander board seems to be lighting up at the very least (not sure what this means, it was not lighting up before). Is that the only modification that you made? I will try on different strips and my pi4 later tonight

[ivanovsaleksejs]

Yes, I've changed only baud rate - the rest of your code is unchanged. Maybe this thread will help https://raspberrypi.stackexchange.com/questions/47461/how-to-set-non-standard-serial-port-speed

The orange LED on a board means that it receives data from the UART with valid CRC. You might want to check the wiring of LED strip.

[branko623]

Confirmed! Thank you so much! I will be finishing up this bit of code so that it resembles neopixel_write in the next couple of days.

[branko623]

I uploaded a working and slightly optimized version. Would you be able to confirm it's working state? There is test code at the bottom, and it took me a minute to decide on the structure of strip configuration but I decided on a list of dictionaries (a list item that is a dictionary for each strip that is connected) This board technically supports 64 channels so this might be the easiest way to deal with setups that have odd configurations....

Anyways I did not deal with timings which I should probably figure out (or maybe this should be the user's responsibility?) , but I was getting 200 FPS on ws281x strips on a pi zero w.

[ivanovsaleksejs]

I can confirm the code is working now, the issue can be closed.

A side note: I've noticed that you use a 240 LEDs limit for a channel. I've made some calculations and it seems that it should handle 620 LEDs per channel with 48 FPS.

[branko623]

I noticed this, I put in the wrong values. Thank you, I will be changing this...

PS I am cythonizing this driver, pure python has WAY TOO MUCH overhead to be viable as a driver. It should be completed in the coming days, the CPU use should drop drastically.

[ivanovsaleksejs]

I myself am using JS as I have a web server that controls LED strips as well as remote controller connected to USB. Also, some of the strips are connected to ESP32s which I control from the same code via wifi. You can check my code here.

[branko623]

That's really cool, you control the ESP32s via wifi with a server? Very clever and minimalistic approach for multiple spaced out light projects. What kind of bandwidth can you pass through the network? I see you have a compression fork too, can the ESP32 handle higher framerate setups while also decompressing data? I do not know much about ESP32s

[ivanovsaleksejs]

As I use a super simple compression (sequences of (length, color) pairs) decompression doesn't ask a lot of resources - actually no overhead at all, because with no compression I loop through data but with compression I loop using length parameter as a counter. I've made this to solve the memory problem as the memory on ESP is very limited and micropython runtime uses a lot. For my animations I prepare and cache all colors and then display them from memory instead of recalculating colors on each step (you can see that I try to use sinusoidal formula for fade in/out because it looks better). But if I have a lot of different frames then I need a lot of RAM to prepare all values. This compression solves RAM problem.

As for FPS - my code is optimized enough and the bottleneck for FPS are LED strips themselves. You can't get like 48 FPS with more than 600 LEDs. And I could get only one output pin working at a time.

The other limitation of ESP32 is it's storage. My config file grew with time and used a lot of space. At some point it became so big that I couldn't load it because I didn't have enough RAM.

Also, working with ESP32 often means code, upload, test, debug cycle which is quite slow.

ESP32 solution works only for simple cases where you don't have a lot of different animations and you don't care about WiFi latency.

[ivanovsaleksejs]

As for bandwidth - I store config files on ESP32s and I send only a sequence name to them, so I don't really care about bandwidth. ESP32 finds the sequence in a config file and enables it. I wanted to make a wifi update of config files but then I decided to get rid of ESP32s in favor of raspberry + expander.

[branko623]

That's interesting, thank you for sharing. Does not sound simple to work with, I might steer clear of the esp32 outside of finished projects. The potential for high FPS of the the expander board is what drew me to it, I aim for 200+ fps. What I am finding is that the 2million baudrate is really only conceivable for light setups with less than 300 pixels, as that quickly becomes the bottleneck (every pixel refresh is essentially 24 baud). My setup is very high level, and I essentially do multiple math and ifs on every pixel for every refresh, I am quickly finding that python should not be the language of choice (due to overhead) for this type of thing, if you ever do venture into the such

[ivanovsaleksejs]

You can avoid 2m bottleneck by implementing some compression on expander, like I did on ESP32.