Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

StarLight Live Scripts and Virtual Led Driver #17

Open
MoonModules opened this issue Nov 5, 2024 · 3 comments
Open

StarLight Live Scripts and Virtual Led Driver #17

MoonModules opened this issue Nov 5, 2024 · 3 comments
Assignees

Comments

@MoonModules
Copy link
Owner

MoonModules commented Nov 5, 2024

Release 0.5.0 will contain Live Fixtures and Virtual Led Driver support, goal is to support 12288 led setups.

As this is the first release with this functionality not everything has been implemented and further development and testing is needed. Below is a summary of current states and recommendations to proceed.

Live Scripts

  • Live Fixture works
  • Live Effects work on normal ESP until 1024 pixels (otherwise crashes)
  • Live Effects work on WROVER until 12288 pixels (Both Live Mapping and default projections)

Virtual driver

  • Virtual driver can run in 2 modes: with and without STARLIGHT_LIVE_MAPPING, the goal is to run without this ultimately, it is used now as it the most efficient way of running large setups, drawback is that projections are not possible.
    • Without STARLIGHT_LIVE_MAPPING, fixture mapping is done using StarLight mapping tables. This works on normal ESPs until 3840 pixels, but not working on 12288 pixels . On WROVER this works until 12288 pixels. Combing this with Live Effects is challenging - needs more testing.
    • With STARLIGHT_LIVE_MAPPING it works on normal ESPs until 12288 pixels, the mapping is currently done using mapLed function in c++ (fixed for 128x96 setup), it has also been setup to run a mapLed function in the Live fixture script but this is crashing (maybe because it is called 12288 x fps times per second…)

Projections

  • StarLight projections work partially on normal ESPs, works okay on WROVER. The following projections are possible:
    • Live mapping (STARLIGHT_LIVE_MAPPING): mapLed function will be used instead of StarLight mapping tables. If no STARLIGHT_LIVE_MAPPING then this will be like no projection (None): ledV = ledP
    • Default: this projection is needed if STARLIGHT_LIVE_MAPPING is not used: things will be properly displayed using StarLight mapping tables
    • Projections which doesn’t do 1:many mapping (e.g. checkerboard) work
    • Projections which do 1:many mapping e.g. pinwheel, multiply: crash on normal ESP boards, need WROVER / PSRAM to store mapping data

Shift register PCB

  • Build 2 PCBs, they behave identical in the following ways.
    • On cheap Chinese chips:
      • The first pin is for the 2nd panel.
      • The 8th pin is for the 1st panel but is severely flickering
      • This repeats for every shift register.
    • On TI chips:
      • Much worse pins looks like combined by 2: 2-2-4-4-5-7-8-8 and 10-10-12-12-13-15
    • Made adjustments in F_ixture.sc files to swap 1st and 8th panel of each row, and disconnects every 8th panel as they show random noise.
    • Touching the HC245 ic solves the problem of the 8th panel showing random noise (witchcraft)
    • WROVER / PSRAM shows completely messed up pixels on display
  • Second PCB :
    • Pin 2 and 8 also switched
    • Pin 8 is behaving like above
    • panel 15 shows data of panel 16 while it is configured to run 15 panels.
    • Panel 3 and 5 pins swapped !
  • Panels flicker if there is much activity from the AsyncWebServer sending data to the client. Switching off the preview helps
    • It also helps to increase __NB_DMA_BUFFER. It’s default is 2, between 10 and 20 flickering goes away.
    • There is a drawback on increasing __NB_DMA_BUFFER on normal esps as it consumers to much memory resulting in crashes in large setups

General

  • Ota and file upload crashes on largest setups. Workaround:: set projection to none, disable driver.show and / or choosing a smaller fixture ✅
  • The S3 board has been tested up to 16384 leds and works very smoothly. Virtual driver has not been ported to S3 yet so it could not be tested with the shift register PCB

Conclusions

  • On normal ESP, 12288 pixels only possible with the STARLIGHT_LIVE_MAPPING option using Live Mapping projection (Fixture mapping is done in the C++ mapLed function), in mid size displays (3840) can also run without STARLIGHT_LIVE_MAPPING and using StarLight mapping / projections
  • Live Effects only possible on small displays (tested up to 1024)
  • PSRAM is key for larger displays to run default projection (12288) or other projections.
  • Currently WROVER / PSRAM sending random output on Virtual driver setups (DMA related?)
  • Investigate why PSRAM is an issue as PSRAM is key to have projections and Live Effects on larger displays. -> Also porting the Virtual driver to S3 is useful as WROVER / PSRAM is old and S3 is an up to date board.
  • Solve the DMA_Buffer / flickering / Webserver trade of -> install mathieucarbou/ESPAsyncWebServer
  • The 2 PCBs don’t seem to have wiring / connection issues. The 2 types of shift registers behave differently and not right in both cases. -> Voltage issue? Use HCT versions of the chip? PCB Soren with HCT chips, Hpwit PCB test
  • 1:Many projections: tuning of memory usage needed
  • ✅; fixed, see comments below
@MoonModules
Copy link
Owner Author

MoonModules commented Nov 5, 2024

PSRAM results, very random pixels:
IMG_8560

Increasing __DMA_BUFFERS=30 makes it better:

IMG_8579.mov

Increasing to 50 doesn't change much.
60 and above: [ 4453][E][WiFiUdp.cpp:49] begin(): could not create tx buffer: 61

On LedOS it runs fine when __DMA_BUFFERS=10 (at 2 it flickers).

Possible causes:

  • Wifi
  • ESPAsyncWebServer

Next steps

@MoonModules
Copy link
Owner Author

MoonModules commented Nov 5, 2024

Panel assignments on pins (first panel is top right and starts on pin1 but shows data from panel 2: 2 dots in the panel)
8th pin receives data from panel 1.
15th panel / pin (bottom left) is not receiving the right data
IMG_8554

The fixture definition to make this run is

void drawPanel(int panelX, int panelY) {
  for (int x=0; x<16;x++) {
    for (int y=15; y>=0; y--) {
      int y2 = y; if (x%2 == 0) {y2=15-y;} //serpentine
      addPixel(panelX * 16 + x, panelY * 16 + y2, 0);
    }
  }
}

void main() {
  drawPanel(2, 1); //first panel data come from the 8th pin!!

  //first row
  drawPanel(4, 0); //second panel comes from pin 1
  drawPanel(3, 0); //3th from 2
  drawPanel(1, 0); //4th from 3 swapped !!!
  drawPanel(2, 0); //5th from 4 swapped !!!
  drawPanel(0, 0); //6th from 5

  //second row
  drawPanel(4, 1); //7th from 6
  drawPanel(3, 1); //8th from 7

  drawPanel(0, 2); //9th from 15 !!! no data coming from pin...

  drawPanel(1, 1); //10th from 9
  drawPanel(0, 1); //11th from 10

  //third row
  drawPanel(4, 2); //12th from 11
  drawPanel(3, 2); //13th from 12
  drawPanel(2, 2); //14th from 13
  drawPanel(1, 2); //15th from 14 
}

‘ drawPanel(0, 2); //9th from 15 !!! no data coming from pin...’

Not coming from 15 but from 16 !!! As the first pin and last pin of each 595 chip is swapped !

@ewowi
Copy link
Collaborator

ewowi commented Nov 6, 2024

Ota and file upload crash: solved in ewowi@64bcfb5 and 608cfe8

@ewowi ewowi self-assigned this Nov 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants