I don’t think you need to. If you take an array of RGB24, it doesn’t matter how it was generated. People can already use FastLED::NeoMatrix, define an APA102 as the LED backend, and they’re done. No need for you to support anything special.
yes,it’s ironic, I agree, but it’s mostly about reusing existing code as well as being able to write code that can be run on multiple backends.
It does to some extent, but it’s not very hard to just give a 2GB image that is ready to dd with no extra work. sdcard wearing I’m not sure but I’m guessing they’ve mostly taken care of that. It should otherwise be easy enough to turn off any cron job and syslog in the image. That said, yes, there is still a boot time of maybe 5 seconds or a bit more depending on the image.
Form factor: rPi0w is not that big, even if a bit bigger than an ESP32. Power supply, nothing extra needed with a Pi0, it runs with the same power than an ESP32.
It can, the code just tells you not to run faster than 50ns. I took that check out in the code and ran as fast as 8ns before it stopped working. It was simply a command line parameter check based on the fact that the old (i.e. current for most folks) chips don’t work faster than 50ns
8ns → 125 MHz I assume, that’s blazing fast! I think the ESP32 is limited to 40MHz output through I2S
5 second boot up isn’t bad at all
Have you thought about how to move data quickly from the micro to the Pi? It’s not as easy as it might seem. Teensy 3.6 seems limited to 1MB/sec throughput over USB, which is only enough for 20FPS RGB24 at 128x128 resolution.
If you use an ESP32 which has no native USB it’s even more bandwidth limited. I don’t recall what rate the usb-serial chip and associated UART on the ESP32 can handle, but it’s not great.
Most micros can drive SPI signals with a fast clock, but can’t receive signals as fast. The RPi is probably no exception, and there doesn’t seem to even be a SPI slave driver.
I think best bet for a generic solution after brief research is to use DMA reading of parallel GPIO pins to receive data. You can use shift registers and a counter to convert SPI signals into parallel, I’m prototyping this for my ESP32 adapter circuit. I don’t know if the Pi will struggle with high speed DMA-GPIO both in and out.
Thinking about bandwidth more: RGB24 isn’t enough information in my opinion to send to the Pi if the Pi is refreshing the panels at a >24bpp color depth. I guess the Pi could apply color correction mapping the 24bit color into a larger depth space, but in order to get smooth fades avoiding stepping it would need to interpolate colors for the intermediate frames between the let’s say 30-60 FPS generated frames and the 300FPS refresh the Pi can do (I’m borrowing these ideas from Fadecandy). I don’t think the hzeller project is set up to do that already, but it’s open source and seems possible. (And might already be done, I haven’t studied its features) I think the APA102 protocol with its extra byte per pixel containing a Global Brightness Control value is enough to communicate greater color depth and allow for lower overall brightness without sacrificing color depth. Using that has the advantage of compatibility with existing libraries like FastLED, which I believe already has some limited GBC support and hopefully will have better support in the future.
BTW I ordered the Electrodragon board (cheap shipping option), and I’m giving the RPi a bit more consideration as you might be able to tell, though I’m still leaning toward the ESP32. I think what we’re doing can complement each other so even if we diverge at some point I’m happy to trade ideas here.
This doc from hzeller seems to say the max observed DMA-GPIO speed is around 65MHz, so maybe 8ns is the pulse width not clock rate? Still, faster than ESP32.
rPi 3 is quad code 1.2Ghz vs 240Mhz, so i will be faster
But the biggest thing is that it can output 3 RGBPanel channels in parallel, tripling the effectiving output on top of having a clock that’s 5 times faster. In theory that means 15 times more panels than an ESP32 can drive (putting aside the totally inadequate amount of RAM on ESP32 for that amount of panels anyway)
Good question. I briefly considered it, and I think right now my plan is to use an arduino layer library to compile my code on linux, and then run it on rPi as if it were an arduino. It’ll then output a FB that I need to pipe into the rPi library which would be running on another core.
You make good points, but honestly this is beyond where I’m thinking right now. I’m not trying to display high quality video, but just colorful demos. If the colors are off by just a bit, not the end of the world.
Your general idea of providing this as an interface is still sound if you can indeed get enough throughput to support bigger panels. I’d say it should support at least 128x256. Is that too much BW in 32bpp? Quick math shows it’s 1Mbit of data per frame. 100fps would be 100Mbit/s…
Or if you want to stick to 128x128 which can be done right now on teensy depending on the panel type, it’s still 50Mbit/s
Totally agreed, please do not let my ideas/plans detract you from what you’re trying to do. There is always a benefit from having multiple solutions, especially if one of them doesn’t succeed as well as planned (which could very well be mine ).
Probably, I think 128x128 is a reasonable target. I suppose you could chain two adapters together to get 128x256, as you would chain two APA102 matrices. Updating using the APA102 protocol at 30FPS would require using 30MHz SPI. I’m not sure even an ESP32 could generate that much pixel data. Anyway, I’ll start with 128x128, and see what can be done after that.
yeah, that’s a fair point, FastLED::Neomatrix actually makes this trivial, you’d treat each 128x128 as a square tile and let neomatrix do the rest for layout.
I received my P2.5 128x64 panel today and I’m pretty impressed by the flexibility. It’s much easier to flex than I thought it was going to be, and the panel even holds a bit of the bend when releasing it instead of springing back to flat. I could see making a curved frame for this panel out of bent acrylic, as I think a thin frame made of 6mm acrylic (maybe even thinner) going just around the outline of the panel will be rigid enough to keep its shape with the panel attached to it.
As far as the P2.5 128x64 size goes, it’s less bulky than I thought, and I think with a slight curve might fit across my chest or back horizontally without sticking out too much. I haven’t added the diffuser to it yet, so maybe I’ll change my mind after the panel is a bit thicker, but it seems promising so far. A vertical orientation is also an option, but it seem a bit thin. It is a decent fit vertical on top of a small backpack I have, and might be a good fit over a hydration pack.
On the diffusion front, I went to a plastics store and asked for advice, and got a sample of 1mm (measured at 1.5mm) thickness white polypropylene sheet, which is a good mix of diffusion, and protection for the LEDs. Some cutting boards are made out of this material. I’ve also been testing thin white PVC, and really like the look of this material but it’s too thin to be used on its own and would need to be attached to something larger. I haven’t found a good source for it. I’m getting my samples from large heat shrink tubes used for battery packs, and think PVC might also be used for quilting templates, so next time I get a chance to go near a crafts store I’m bringing my LEDs with me.
@marcmerlin without making something custom, this seems like the best low profile ribbon cable replacement for hub75 connectors. I haven’t been able to find this part in smaller quantities, though other pinouts are available (18 and 20, 20 is probably better as it’s symmetrical).
US $24.50 | 20pcs Flexible Flat Cable FFC FPC Connector Adapter 16 Pin 1.0 mm to 2.54 mm pitch 16 P 2x8 Pin through holes DIP PCB Converter https://a.aliexpress.com/_UpnW2
Cables seem to be available up to 0.5m long:
US $4.65 7％ Off | 2PCS/LOT New FFC FPC flat flexible 16pin cable 1.0mm pitch 16 pin forward Length 500mm Width 17mm 16p Ribbon Flex Cable 50cm https://a.aliexpress.com/_UnVX8
Nice.
To be honest, I’ve made my peace with the thickness of a regular panel. That’s what I wear now, the panels have been rock solid now that they don’t flex (the flexing ones broke all the time, I had to take spares with me), and it’s nice not to have to desolder those huge power connectors that added height, and were hard to get out without over heating the leds on the other side and losing them (damaged 3 panels that way).
For now, I’m going to make my life easier and stick to stock. I removed height from the hub75 cables by removing the loop at and end, and that’s good enough for me.
hi, i’m working on a project that includes a Wearable Panel controlled with an app (android or ios).
i buyed some led panels, the same that marcmerlin buyed, that work with an app (LED SPACE).
is it possibile to create a new app that comunicate directly with the board of the panel?
or is there a way to find program loaded in the board?
thanks
I have no idea what they used to program it. It was a lot cheaper for me to buy my own panels and connect to an ESP32 than to try to figure out how to reverse engineer/reflash their stuff.
Don’t take me wrong, if you have lots of spare time and skill, it is doable I’m sure, but I don’t expect it to be simple, and it sure wasn’t worth my time.
).