Had anyone considered a WIFI based TRIKS-C? (tentatively named: ESPIX-C )

LabRat

Active member
Dusty ledtriks panel at the back of the garage, and I got to wondering if an ESP8266 (aka one of my goto WIFI microcontrollers) could be put in place of the TRIKS-C (or in my case PIX-C) boards. I was envisioning either a respin of the LTC.exe OR running a virtual serial port that converts the output from the LTC.EXE into udp (or TCP) messaging to the controller, which then acts like the TRIKS-C to bit bash the shirt registers in the LEDTRIKS. Perhaps someone has done this (or attempted to do this) already.

I've got a bunch of these WEMOS D1 MINI's .. to which I think I can attach a 3.3v to 5v level shifter (TXS0108) module. Add a couple of pull-up/pull-down resistors to ensure I don't inadvertently prevent the module from booting. Apart from that ... I *think* this should be doable.

Something like this..
espix-c_v1.png

Thoughts?
 
Doesn't the triks-c just push data to the LedTriks board? If you wanted to reuse your Triks-c board I think you could just build an small board(kind of an adapter) that plugs the esp32 board into the microcontroller spot.
 
Hmm.. thinking that through. If I'm not mistaken, I believe it would simply change the RJ45 jack (cable to the LEDTRIKS) to a DIP header (plug into the CPU socket).
Everything else would be the same. Oh.. I wouldn't need the screw terminal headers for the power.

Next step: give breadboarding this a go, to check those pull-up/down resistors, to ensure the WEMOS will still boot when connected to the level shifter.
 
For breadboarding I've never had an issue skipping the level shifter for the connection to counter ics, led drivers, etc. You could probably do all your testing just using a hacked up cat 5 cable.
 
Good point.. a 3.3v HIGH signal should still be interpreted as a HIGH input for the bit shifters on the LEDTRIKS.. and if those input signals are floating, I wouldn't need the pull ups/downs .. WEMOS + RJ45 might do the TRIK (see what I did there? :cool:).
 
Brain dump as I encounter my first "whoops.. didn't think about THAT" in developing this solution.

Started this morning to draft up some firmware to prove out this concept. Managed to get the "virtual serial" port on the PC succesfully transmitting UDP packets to the WEMOS device. With this in place, I have configure LTC.exe to use port COM200, and the data for dispaying a frame is sent to the controller. Next steps was to start configuring the controller to parse the data stream. This is when I realized that a part of the TRIKS-C (PIX-C) setup, there is a jumper (or programmable bit) to denote which of the four potential panels this TRIKS-C is listening for. The data stream contains them all *AND* the TRIKS-C passes the input serial to an output serial (effectively creating a "broadcast to multiple devices" solution).

What I'm driving to here is that my proposed WEMOS based controller, using off the shelf free virtual serial port drivers, is going to be limited to a single LEDTRIKS panel. To do multiple panels there would have to be some type of repeater or multicast as part of the solution, so that all four panels would receive a copy of the data.

Options to consider:
  1. ESPIX-C is the first controller in a string of TRIKS-C on the panel. The ESPIX-C could receive the data and then forward (via serial) to the downstream components. But if doing this, why not 4 TRIKS-Cs and the WEMOS is just a UDP to serial converter??
  2. ESPIX-C has master/slave capabilities. The master would have knowledge of the downstream panels, and resending incoming UDP components to the respective downstream panels. (possible sync/lag issues?)
  3. Re-write/modify LTC.exe to skip using serial, and transmit directly to the ESPIX-C. Requires update to the LTC program, which I had considered doing already in order to remove the need for virtual COM port.
  4. Update VCOM solution: A small application running on the host, could receive the incoming stream from LTC and break it out into multiple "virtual COM broadcasts" with each going to their respective ESPIX-C destinations.
  • LTC would write to COM200 (which sends to virtual COM201
  • Mux Application listens on COM201 .. and then UDP broadcasts to up to 4 ESPIX-C destinations
The advantage here being no changes to LTC.exe, BUT it could result in 4x as much web traffic. (Though for a ledtriks panel .. not sure there is much concern here)

Lastly .. could extend number 4 to an app that would listen to the LTC content and then UDP "broadcast" (multicast) the LEDTRIKS data (much like E.131 and the DMX stream), with the ESPIX-C's all sniffing/snooping the same data stream. Doable.. but the complexity of the solution (vs the gains) is getting a bit convoluted.
For now .. ESPIX-C as a single panel solution (as I'm only trying to solve form my one panel here at the moment).
 
Whenever I run into these types of decisions I generally do an additive approach.
I usually start with the simplest and get that working 100% then, if I decide to add more features I can add them. Typically what is needed in the simpler solution is needed in the more advanced solutions so nothing is wasted. It also allows for seeing results(and problems) earlier in the implementation.
So, in this example I would typically choose #1 with leaving all Triks-C's in for now.

I'm not sure if that helps but for me it generally works out to be a good solution.
 
Serial output is certainly something to look at as a second phase, and/or when I revisit the PCB after this proof of concept effort on the breadboard. Some excellent progress yesterday and today, and I have virtual com port listener receiving the streaming content. A very basic "command parser" is in place.. (with cmdFrame being the only supported command at the moment). LTC can be executed on the old windows laptop, and I can see the commands being parsed on the WEMOS board.

I've just added a timer interrupt that is running on a 500 us cycle, which is where the bit bashing to the LEDTRIKS is about to be placed.
[pulled 500us duty cycle from the pix-c clocking code]
Once the bit bashing code is there, in *theory* ... I could attempt to drive my panel. This has come together far faster than I had anticipated.

LTC.exe command line output : running my "space invaders animation"

Code:
C:\Users\LabRat\Documents\Ltc>ltc.exe #FDL020 invaders.led #FRM
TRIKSC.DAT FOUND
Attempting to open COM portCOM200:
COM port OK (COM200:)
F_delay= 0 H_delay= 0
V_delay= 0 R_delay= 0
Number of Panels= 1
COMMAND:#FDL020
COMMAND:#FRM
INTERPRETING VIXEN FILE : invaders.led
LEDTRIKS File Opened OK
Found Frame Data

Serial logger from the WEMOS.
EsPixc_progress.png
 
Prototype ready for integration testing... (though as I type this I realized I'm not doing anything with the panel-ID yet.. so *if* I try and do a multipanel setup, it's going to choke and try to merge frames. "Todo" list item)


Did some math (and internet sleuthing).. and I think this should be generating 100ns clock pulses, which *should* work.
Time to dust off the LEDTRIKS panel, and figure out how to wire this in with a common ground.

487032253_1237627137722269_3194935438420986707_n.jpg
 
RS232 (DB9) Triks-C In (RJ-45)
Pin 3 (TXD) ----------------------- Pin 4
Pin 5 (GND) ---------------------- Pin 5
 
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
espix-c_v2.png
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.
t99tVbD5.jpeg
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.
espix-c_v5_1.png

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).

image.png

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 ?
 
Amazing work Labrat!

Time to dust off my old panels.

Does Kostyun still sell panels or are there gerber files available?
 
I don't have any of those (but would love to get a copy of the PCB files). Alas my "free use" copy of eagle won't allow me to layout a file that large, so I can't simply spin a replacement. So if anyone has those BRD/SCH or gerber files for the LED Panels.. ... there's a free ESPIX-C available for sharing !!
 
Cat is out of the bag!

Now everyone knows why I scooped up Triks boards, lol

Just a matter of getting the 'other" Ledtriks project completed (*waves to Chris)
 
One upgrade not mentioned,

You can now run MULTIPLE independent Ledtriks boards!

-Triks.dat file is now executable dependent.

LTC.exe looks for or creates LTC.dat

copy LTC.exe and rename the copy,

LTC_copy1.exe will now look for or creates LTC_copy1.dat and so on.

they all share your .led files and can share the same directory

This backwards compatible too!
a separate Com port is used to each instance of LTC being run.
 
Back
Top