@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!
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
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.
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.
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.)
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.
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.
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.
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
}
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:
