Hello friends! Please help me choose a solution!
I want to communicate with thirty SmartPixels using RPI, what options do I have? Is it possible to use I2C or SPI to communicate with RPI.
Each SmartMatrix will have 192x32 px. (of three P2.5 SMD RGB 32x64 panels)
Symbols (temperature, humidity) will be sent to each SmartMatrix
Which controller are you looking at?
For low FPS this is possible a couple ways. My concern here is the length of the cable and the speed. Will likely need a protocol for commanding buffer swap. This can become a rabbit hole. (I was working on something like this, but I stopped.)
For Teensy 3.2:
I2C and UART/RS-485 are available. USB is also available. (12Mbps)
For Teensy 4.0/4.1:
CAN bus would be nice here, but may be too expensive. Would need SPI bridge. Ethernet is possible with external adapter. I2C and UART/RS-485 are available. USB is also available.
For Teensy 4.1:
SPI is available.
ESP32:
Wireless is possible. USB, UART/RS-485 and maybe SPI are possible.
Note RS-485 can get expensive and the Pi may need SPI bridge.
For high FPS this will require some work on the Pi side. The Pi should be able to do it, if nothing else using Pi 4. I kind of recommend against trying to be honest. USB 2+ or 1G Ethernet are better here. I doubt you are looking for high FPS for temperature and humidity. Maybe graphics?
However if you do need high FPS and are willing to use something other than SmartMatrix there is another solution. It may be cheaper/easier. However it could be something you are not interested in.
Thank you very much for your answer, I will use Teensy 3.2, at low FPS, I don’t know how to connect 30 uart, I will use I2C, cable length from RPI to 1.5m, less between SmartMatrix.
I wanted to make sure that SmartMatrix v4 for Teensy 3.2 would suit me as a modular solution.
I had positive experience with SmartMatrix v1 when I made a display for the robot head, but with the latest library I can not start, even following the migration guide
Dear friend! can I get more details on the buffer switching protocol? in general terms, what pitfalls will meet me
I would love to do it over LAN, but I have not met adapters for SmartMatrix
Why don’t you use USB? You could attach 30 Teensy’s to the RPi with a USB hub. Cable length could be an issue, so please describe the distance between the RPi and the distance between similar displays so we can help.
There are many. Most do not apply here since you have low FPS which lowers the data rate. I2C enables clock stretching and addressing. Buffers could be used for I2C to enable length. I have seen 1.5M I2C in college. However that was with either 100/400kHz I2C.
I would recommend create packets, one for data and one for switch. However this may be better served with I2C address. Basically you would want to send data to each node. Then send a global command if possible for the buffer switch. Since the data updates could be slow you would want to make the update as smooth as possible.
Double buffering would enable this. SmartMatrix is memory mapped controller retrofitted onto non memory mapped panels. It should support a front and back buffer. Draw slowly into the back buffer then quickly switch all 30 SmartMatrix controllers instantly. Doing this in parallel via global command would be ideal. I2C general call may work. However I do not know much about the I2C hardware used in Teensy 3.2.
For higher FPS and broader support there is more to consider. I figured out that there are a few fundamental types of protocol. Each with there own ups and downs. I2C is not the fastest but should still work for very low FPS.
Here is an unfinished work which attempted to handle this: daveythacher/LED_Matrix_Controller (github.com). It was created to try to abstract LED Controllers whether on MCU, Pi, FPGA, etc. The notable features I was trying to add are support for PWM/MM LED drivers, different interfaces (CAN, Ethernet, I2C, SPI, UART, Bit bang, etc.), abstracting memory operations, and considering processor IO acceleration integration. Overall should provide large amount of flexibility for different levels of performance to cost. However some aspects are very simple while others are very complex.
So for reference this may be useful. However a lot of the design choices are a little hidden. I would not recommend using this for your application. Mostly cause it is not finished or tested. My version does not support global command/address. It would be easy to add. Addressing works differently with this as it assumes ring. Which would be strange for some protocols. This is useful for certain cases which do not apply for I2C.
Unless you use multiple I2C buses per controller. This could in theory limit the number of buffers required. However I am not sure about that. However if you lower the clock speed significantly maybe.
If you are willing to use this you can.
Edit: This would be much cheaper.
4 x Amazon.com: Colorlight 5A-75B Receiving Card Led Display Synchronous Control Card(V8.0 Version) with Software Configuration Instruction : Electronics
1 x 3365/16 100 3M | Cables, Wires | DigiKey
64 x 101-166 On Shore Technology Inc. | Connectors, Interconnects | DigiKey
Need cutters and rubber mallet
My protocol supported acceleration commands like copy. Which could save time by not redrawing every pixel. However that is probably more hassle than its worth, but could help it you have differential data. There is application logic which could handle this on something like a Pi or PC, where this would be less problematic.
Another that was not added is fill or clear command. You may wish to generate a clear command.
This could be cheaper and easier than I2C. However may have issue with buffer swap. I do not know. I think you could work around the length issue possibly.
These numbers are not fully verified however I think it may be of use.
High Quality Max pixels (10 bits PWM, 100+/300+ Hz Refresh, 30 FPS)
Platform: Max Pixels: Cost: Pixels Per Dollar:
CC MCU (Teensy 4 / RP2040): 1536/512 20 76.8/25.6
CC Pi: 4608/1536 47 98/32.6
CC Receiver Card: 12288/12288 26 472.6/472.6
CC Receiver Card: 12288/12288 70 175.5/175.5
PWM MCU (Teensy 4 / RP2040): 19500/6500 20 975/325
PWM Pi: 58500/19500 47 1244.6/975
PWM Receiver Card: 156000/52000 26 6000/2000
PWM Receiver Card: 156000/52000 70 2228.5/742.8
MM MCU (Teensy 4 / RP2040): 24576/24756 20 1228.8/1228.8
MM Pi: 73728/73728 47 1568.6/1568.6
MM Receiver Card: 65536/65536 26 2520.6/2520.6
MM Receiver Card: 65536/65536 70 936.2/936.2
Low Quality Max pixels: (1 bit PWM, 100+/300+ Hz Refresh)
Platform: Max Pixels: Cost: Pixels Per Dollar:
CC MCU (Teensy 4): 156000/78000 20 7800/2600
CC MCU (RP2040): 78000/26000 4 19500/6500
CC Pi (Possibly unstable): 46800/156000 47 9957.4/3319.1
MCU for MCU projects using up to 3 CC panels, 3 MM panels or 9 PWM panels. (For high quality)
Pi for Pi projects using up to 9 panels, 9 MM panels, or 27 PWM panels. (For high quality)
For more panels use one or more receiver cards.
Teensy attempts to lower cost with integration.
Wiring multiple MCUs together is usually expensive.
Wiring multiple Pis together is not recommended.
CC panels are smaller around 512 pixels.
PWM panels are larger around 2048 pixels.
MM panels are larger around 8192 pixels.
Receiver cards are not recommended for low quality.
A hybrid of RP2040 and Pi Zero is possible to provide up to 12 MM panels for possibly the cost of a Pi.
Could be possible to double this for a little more, however that starts to push things.
Note there is no PWM/MM support for Pi.
Note there is little PWM/MM support for MCU. (ESP32 is exception, but code would need to be changed.)
It would not let me edit. I had to play with the receiver card configuration for CC. Note still should be taken with a grain of salt.
Low Quality Max Pixels:
CC Pi: 234000 / 78000 47 4978.7/1659.5
CC Receiver Card: 262144 / 65536 26 10082.4/2520.6
CC Receiver Card: 262144 / 65536 70 3744.9/936.2
Point is for size you really should be using receiver cards regardless of panel type.* At least one works off Ethernet frames. Note you can get the receiver card for 16-18 dollars from AliExpress, 38 dollars from Amazon, etc. These numbers use 26 dollars which dampens the value of them a little.
*There is one technical case where that is not true. It does not apply here.
Thank you very much for clearly explaining and guiding you on the right path)
What Software would then work together with those Receiving Cards? I have access to some 128x64 RGB LED Panels and Novastar Receiving Cards, but would like to avoid the Novastar Controller and use a Raspi or ESP. But i could not find a Project who then supports the protocol wich runs over the RJ45 Cable.
The LED Panels are “outdoor” versions which just A and B address lines. I’m not able to get them to work with rpi-rgb-led-matrix or one of the ESP Projects, so my hope is to talk to them via a receiver card.