PixelTeleporter - virtual LEDs on your computer

Show and Tell
52

@spazzle, it’s based on two things: a conservative estimate of how much data I could get an ESP8266 to read from the Pixelblaze and shovel to the client over UDP at a reasonable frame rate, and the number of pixels beyond which the Pixelblaze’s output frame rate starts dropping a lot due to communications overhead. It’s not pixel computation bound, so PB3 isn’t really better. It’s the 2Mbit speed with which the PB talks to the expansion board.

Not hard to make this user configurable though. Give me a couple of days and I’ll build client and server that let you set the buffer size.

53

Ok… just updated PixelTeleporter, both client and servers to v1.1.3. Files are here.

This bumps the maximum LED count to 4096 on the server side for the Linux, Pi and Windows servers, and 4096 LEDs per PixelTeleporter object on the client side. (The ESP8266 server still supports a maximum 2048 pixels for the time being.)

Here’s a 60x40, 2400 pixel matrix. It runs this simple circular rainbow pattern at around 20fps on a PB3, and actually looks pretty smooth.

Teleporter113
Teleporter1134032×1960 1.81 MB

3 Likes
54

I used an online javascript interpreter to create my pixel map previously, but it seems to not be working now. Is there a way to just extract the pixel map from the pixelblaze page directly?

55

This is hideous, but it works…

If you’e got a working javascript mapping function, and you have the developer tools for the web browser you’re using, turn the dev console on in the browser and add the statement:

console.log(map)

to your javascript before it returns the map. Then you should be able to copy the map array out of the dev console to your clipboard, and from there to whereever you want to save it. It’ll be the non-normalized version, and in Firefox at least, it comes out formatted with a newline between every item.

1 Like
56

In chrome it spits out all the coordinates as a continuous comma separated list
ie 10,0,0,11,0,0,12,0,0,13,0,0,14,0,0,15,0,0…
as opposed to
[[10, 0, 0],
[11, 0, 0],
[12, 0, 0],
[13, 0, 0],
[14, 0, 0],
[15, 0, 0],
[16, 0, 0],
[17, 0, 0],
[18, 0, 0],
[19, 0, 0],
[20, 0, 0],
[21, 0, 0],…

57

I originally used this page with slight modifications of the mapping function to generate the map for teleporter (Online JavaScript Interpreter) but it seems to have stopped working. I’m at a bit of a loss of what to do besides maybe code something up in python.

58

You can also do it in Java – use Processing and PixelTeleporter to build your object, then call PixelTeleporter’s exportPixelblazeMap() method to save the JSON map to a file in a form that you can paste into Pixelblaze’s mapper window. Here’s the API doc – there are more details in the repository’s javadoc, and there’s the MapIO example, which shows how to read a JSON map. Writing one is similar.

exportPixelblazeMap
public boolean exportPixelblazeMap​(java.util.LinkedList<ScreenLED> obj, java.lang.String fileName, float scale, boolean is3D)
Convert a list of ScreenLEDs to a Pixelblaze compatible JSON pixel map and write it to the specified file.

Parameters:
    obj - Linked list of ScreenLEDs representing a displayable object
    fileName - Name of file to write
    scale - Coordinate multiplier for scaling final output
    is3D - true for 3D (xyz), false for 2D (xy)
Returns:
    true if successful, false otherwise
59

Just posted v1.1.4, which adds initial support for polygonal shapes and solid geometry. See the Pentagonal Icositetrahedron thread for a screenshot. This should be useful for modeling 3D printed objects that act as diffusers.

Not coincidentally, it comes with a pentagonal icositetrahedron example too. (Also, I’m sure I mistyped that in the repo at least once – I’ll fix it and add more examples over the next few days!)

1 Like
60

PixelTeleporter is great and should save me lots of fiddling around, as well as allow me to play with patterns while on the road with a laptop. Thanks @zranger1!

For anyone considering using USB-TTL hardware using something other than authentic FTDI chipset, hopefully by sharing my experience with that I can save others some time and trouble:

I tried using PixelTeleporter on Windows 10 with a few different cheap USB-TTL modules I had lying around from AliExpress and I didn’t have any luck with any of them. I wrote a little test app using local loopback to try and figure out the problem and it turned out none of them could handle the 2,000,000 baud rate required.

The CH430 module worked until about 1,700,000 baud (but actual throughput struggled to get much over 1,000,000). Above that it would still accept the connection but started dropping bytes.

The PL2303 (clone) module could reliably handle up to around 1,900,000 baud (using these drivers), but frustratingly would cause a bluescreen(!) if I pushed it above that. I also tried some older drivers that were a bit worse and that also bluescreened at high baud rates. Maybe this module would have worked OK with different drivers (or on Linux?), but I couldn’t find anything that would make it work on Windows.

The CP2102 module refused to allow the baud rate to be set above 1,000,000, so it was a non-starter with PixelTeleporter. Loopback worked reliably up to 1,000,000 baud though.

So in a nutshell, whatever USB-TTL adapter you use, it will need to work reliably at 2,000,000 baud. Most of the cheap USB-TTL modules on AliExpress, eBay etc can’t handle that, so they won’t work with PixelTeleporter.

Given my lack of success with the above, I bought an authentic FT232 module similar to the one already mentioned earlier in this thread. Windows detected it automatically but I installed these drivers anyway (they were only released yesterday and I like shiny things :grin:). Everything worked fine first time.

As a result of my testing I also have bit of feedback on some problems I noticed with pbxTeleporter.exe. None are showstoppers, but hopefully you find this helpful. It tends to hang a fair bit when the serial port connection is unreliable (i.e. with the cheap modules) including on startup before the application’s window is displayed, requiring me to force-kill it via Task Manager. Maybe something like the serialOpen() call is hanging/blocking on the event thread? Also, there is often tearing visible on the processing.exe output when patterns are being updated at high frame rates. My guess is that this is because there’s no synchronisation of the pixel_buffer between the serialReadThread and udpThread? There’s possibly other race conditions due to the lack of synchronisation too, maybe that’s what causes the crashes @spazzle mentioned? I’d have had a go at fixing some of the above but it has been more years than I care to think about since I touched C++ and don’t have a dev env set up for it, so humblest apologies for not providing any pull requests!

3 Likes
61

@chrisNZ, thanks for all the feedback! The information on “clone” FTDI chips is especially helpful. I’d heard they could be troublesome, and it’s great to know why. I’ll set a shorter timeout when opening the serial port to keep this sort of thing from locking up the server. Also, I’m glad you checked the FTDI driver page – good to know there are shiny new drivers. In the near future, I’m planning to switch from the ancient, creaky serial APIs on both Linux and Windows to the FTDI native API. I think it’ll be faster and more efficient, and generally cause less headache in the long run.

On the tearing at high frame rates: Yes, I’ve seen it too. That makes two of us, which means I have to fix it. The Pixelblaze 3 running patterns at 400fps made this a lot more obvious!

Interaction between the serial/network threads can’t cause crashes, but as the frame rate goes up, it becomes very likely that enough pixel data will be overwritten in weird ways that it causes visual glitches. Let me see what I can do with this. A simple mutex might be enough. Otherwise, I’ve got a plan involving multiple buffers. Should have something to test later today!

62

Well to be fair, they’re clone (or possibly even original?) versions of older chipsets from different companies that do USB-serial conversions, none of them are claiming to be (real or clone) FDTI chips. I’m not sure any of them are rated at over say 115200 or 576000 baud anyway, so it’s a miracle they at least seemed to handle 1,000,000 baud OK! I’ve seen similar items for sale that do claim support for 2,000,000 baud but I don’t have any around to try unfortunately.

I’ve heard that FDTI clone chips can be detected by the official FDTI drivers and be bricked(!), or the data that’s passing through gets corrupted. One such article here: FTDI Drivers Break Fake Chips, Again | Hackaday

Sounds good - if you release a new version I’ll test it with my dodgy adapters and let you know what happens.

Ha! Now that’s a rule I didn’t know, but I like it :rofl:

63

I may be dreaming here, but you could cut out the hardware in the middle by persuading Ben to add a “PixelTransporter” adapter to the set of Pixelblaze LED adapters that sends the LED data directly over the network rather than parsing it over a wire and a UART. From the look of the WS2812 one at https://github.com/simap/Ws2812Adapter the interface looks pretty straightforward.

64

Ok… I’ve just checked in a test version of pbxTeleporter.exe that should fix any “tearing” or incorrect color channel values due to high framerate buffer madness. This version transmits in sync with the Pixelblaze frame rate. When the client requests pixel data, pbxTeleporter now waits to fill the request until the next complete frame has been received from the Pixelblaze.

Download it from here, and let me know how it works for you!
pbxTeleporter.exe v1.1.4 on github

If this is successful, I’ll update the Linux/Pi versions shortly too!

@pixie, I wouldn’t object if @wizard at some point decided to do something like this, either via UDP or through the USB port , but PixelTeleporter is kind of out there on the edge for most customers. It requires some technical skills and it has a bit of a learning curve. (I’m working to improve that, but it’s gonna take time.)

Anyway, I’ve had a lot of fun with Pixelblaze, so my first interest is in Ben successfully selling them for years to come. I’m happy if he expands his customer base by first adding the features that are most in demand. If eventually he has time, and there’s enough room on the Pixelblaze to do network output without sacrificing something else, I’ll definitely take it and put it to work… (and I’d suggest going with e1.31 or OSC at that point.)

2 Likes
65

Yes I can confirm this version has fixed the tearing issue - thank you!

1 Like
66

Seconded. Adding e1.31 would allow using things like WLED flashed esp8266 controllers as slave devices, purely controlled by e1.31 from a central PB. This would actually increase the market for PB sales, as folks who right now go with WLED controllers lack a way to program designs (except for writing FastLED code and flashing), matrix support, and more. They have segments, and syncing, but not multiple device control. Buying one PB to push patterns to multiple devices is still one more PB sold.

1 Like
67

So this seems like a weird ask, but…in the absence of PB having E1.31 output, and with Pbxteleporter having the ability to take/process PB output, could you write a PB=>e1.31 output?

That would allow using a PB to be the source of a pattern, using maps, etc etc…and then pushing that out to multiple led controllers that speak e1.31

If @wizard adds that directly (eventually?), and obsoletes it, then Pbxteleporter can just add/use e1.31 input, but this way, folks wanting to use a master PB for patterns/sound/sensors with multiple “dumb” e1.31 controllers could do so sooner.

68

This is so totally unusual, strange and out there that… oh… it’s already on the roadmap!

The plan is that both client and server will eventually use e1.31 as their native protocol. The server will have a point-to-point mode for “normal” PixelTeleporter use to keep net traffic down, and a broadcast datagram mode for sending data to multiple receivers.

Theoretically, anything that can receive e1.31 should be able to listen in. This was always supposed part of the “teleporter” in PixelTeleporter. I’ll bump it up higher on the project list.

3 Likes
69

Watching piles of processing videos, and just realized that potentially, once you add e1.31, all of those neat Arty pieces become pushable to LEDs.

70

Just wanted to chime in to @spazzle’s question and @zranger1’s reply of April 4th with a trick I found recently…

You can retrieve the pixelmap for a Pixelblaze by pointing your web browser at:
http://{your-Pixelblaze-IP-address}/pixelmap.txt

which in the case of my BTF 16x16 matrix returns:

function (pixelCount) {
  width = 16
  var map = []
  for (i = 0; i < pixelCount; i++) {
    x = Math.floor(i / width)
    y = i % width
    y = x % 2 == 1 ? width - 1 - y : y //zigzag
    map.push([x, y])
  }
  return map
}
2 Likes
71

New beta version out - this has the new, realistic renderer, but not the data recorder or some of the other v1.2.0 features. For details and a link to the release, see this thread: