Apologies for the lack of updates on this project. There has been significant progress. (and some unexpected hurdles that delayed things a bit)
Working closely with Steve (Aurbo99) we have been through 3 versions of PCB's. The initial design above was flawed, in that the level shifter was bi-directional, and ended up pulling some of the "do not pull these high (or low) pins else thy D1 shall not boot" pins. But, as the breadboard above demonstrated, it was possible to have the D1 interact directly with the LEDTRIKS panel (3.3v is "good enough" for driving a HIGH signal).
This resulted in a second PCB (Same form factor as above), but with the D1 mini wired direct to the LEDTRIKS. The bit bashing routine was ironed out, and the first end to end communication was established.
LTC_11.exe --> virtual Com port--> UDP payload -->ESPIX-C

This demonstrated successful transmission to a single panel on the network, but it was impeded by significant stutter and jitter.
With thanks to Tim Wells (the original author), we started learning the code base for the LTC command line tool (authored in FreeBasic). We managed to enhance the code to build and send a UDP payload directly, while still maintaining backwards compatability. With these changes we dropped the need for the virtual serial port, and LTC communicated directly to the ESPIX-C.
LTC_11+.exe --> UDP Payload -->ESPIX-C
Further experimentation highlighted that TCP vs UDP would generate stutter/jitter in the playback. Thus UDP broadcast (and potential for lost packets) was going to be the way to go. With those changes we had "reasonable" streaming capabilitiy from the command line argument to the panel.
The next challenge was to add "multi-panel" support. One option would have been to have the updated LTC_11 application track multiple IP address destinations and transmit to them each independently. .. *OR*... we leverage the work done with the ESPIXELSTICK and look at using MULTICASTING protocol(s) to have multiple listeners to a single stream. Changing the ESPIX-C to listen on a mulitcast UDP port was almost trivial, however persuading a FREEBASIC application to *send* to a multicast address was more problematic. In fact, it appears to be impossible. All attempts resulted in failure, and we had to conclude that continuing to use FreeBasic for development was going to prevent the project from continuing. The decision was made, therefore, to convert the LTC_11.bas into C.
Steve undertook the majority of the automated conversion, leveraging publicly accessible AI tools, while Andrew undertook to "fix that which the AI failed to grasp". This step was by far the largest hurdle of this project (to date) . This leads to a new binary LTCC.exe which we have kept backwards compatible to LTC_11.exe.
With a somewhat stable code base, we began enhancing the C code to support sending multicast UDP payloads. This led to a lengthy period of side by side testing and verification and backwards compatibility testing. Any group of 4 panels can be configured to listen to a common multicast port address, in order to create a single clustered display. (conceptually the single serial stream of the past, becomes a multicast POSRT number (eg. 4096)). Of course, there is nothing stopping having multiple panels clusters listening to the same port number, if you wanted to mirror the content at multiple locations. From a protocol point of view, this solution esentially wraps the serial stream unto a UDP payload (complete with all the ESCAPE encoding, and bit/byte re-ordering) ensuring backwards compatability.

At this point project success seemed ensured, and a third pcb design was undertaken, in order to match the footprint of the existing original TRIKSC pcb. The intent was to ensure that the PCB could be a drop in replacement for any existing TRIKSC installations (including on the backside of the popular Kostyun LED panels). This was actually the 5th version of a PCB design, but only the 3rd design to actually get manufactured.
As we worked through validation of each command line argument to LTCC, and to keep the ESPIX-C compatible with the PIX-C, support for a "standalone" mode (for a single panel) was introduced. This new UI allows for upload of 96 byte .BIN files representing a single static image to be cycled onto the display, if the panel remains inactive for more than 30 seconds. This feature was further enhanced by enabling multi-panel standalone mode, where PANEL#1 will direct panels #2-#4 to update their displays in sync with each other. This UI may look familiar as this entire project was based on earlier ESPIXELSTICK work. (credit where credit is due).
That's the progress update ...
OH.. wait.. was added a static frame editor to the web based UI as well. Allowing you to edit any one of the stored 10 image(s).
Future work on this? .... NO SPOILERS!! ;o)
Questions/Comments ?