And if you are curious about my LED outfit, you can read more about it on my led peacock engineer medium post and if you'd like to read all my festivals or dreamstate, or clubbing posts, please click on the links higher on the page to get taken to those categories.
π
2020-03-30 01:01
in Computers, Electronics, Linux
While I wrote this for my Lenovo Thinkpad P73, this is likely equivally relevant to P53, P72, and P52.
Thinkpad P73 vs P70, not a win all around: only one 2.5" drive instead of 2, and a badly designed power system
So, when lenovo came out with the Thinkpad P70, I wasn't very happy because if you had a 90W power supply, it refused to charge from it, at any rate whatsoever. I was not impressed, but eh, at least it would still power the laptop so that its batteries didn't go flat while plugged in.
Well, leave it to lenovo engineers to make things worse the for the P73. The minimum power supply was raised from 135W (170W recommended) to 170W (230W recommended) which is understandable, but lenovo decided to ensure that the laptop will not take any power from any power supply that does not identify itself as 170W or more. This means that even ifit only needs 40W to sustain itself without digging into the batteries, it will completely refuse to use a 90W or even 135W power supply for anything at all, and kill the battery instead. Lenovo, you just plain suck, there is no excuse for this.
P70 vs P73, they look pretty similar
*Update*: it seems if that if you get a cheaper nvidia chip with the P73, it is then configured to accept 135W power supplies as the minimum required. That said, it will still refuse to work with any regular 90W power supply or external battery back, unless you force it with the center pin resistor swap.
While I have no plans to use windows on that machine, I thought I'd just try it out to see how it does on power. This is where I was impressed, windows can idle at less than 10W for more than 11H runtime, while I'm lucky if I can get linux at 15W. This is definitely a place where linux should do better, of course, it's not as if Lenovo put any work into making linux more efficient on their hardware either:
*Update* : with tlp and using the nouveau driver just enough to turn off the nvidia chip, I'm now able to tune the laptop down to 10W, almost matching windows.
See tlp issue 494 for details on how to setup tlp to run in low power mode when power is plugged in.
Another disappointment is that the P73 is mostly the same size and weight than the P70, but it has less room for storage. It has a bunch of empty spaces that aren't used for anything, and it can't use two 2.5" SATA drives anymore, like the P70 could. Worse, the now single 2.5" slot uses a lenovo only ribbon cable that does not ship with the laptop and basically means you cannot even add a 2.5" drive without that special ribbon cable, which isn't in stock yet. Well done... Ah yes, the battery is also not hot swappable, even if it is replaceable (unlike a Mac laptop where everything is sealed shut).
this shows the unobtanium lenovo cable for the now only single drive that fits, along the unused space
Ok, stop complaining, just buy a bunch of 170w or 230W power supplies and move on with your life
Well, yes and no:
I literally have 10 power supplies between home and work, not really looking at replacing all 10. Lenovo wants $137 per power supply by the way, even if they are $85 from other sellers
those 170W/230W power supplies are huge. They also weigh as much as some small notebooks (!)
I have 12V to 20V car adapters, those won't work anymore
I have external battery packs for extended runtime, and I haven't found a single one that can deliver the amps a P73 tries to needlessly require
Tricking the P70 and P73 into accepting a power supply it wouldn't otherwise use
Lenovo uses the a center pin resistor to know how much power they can draw from the power supply, see: http://www.thinkwiki.org/wiki/Power_Connector .
For the P70, I built this power supply adapter with a resistor bridge to tell the laptop how big it should think the power supply, is:
It's basically a configurable version of this. Yes, lenovo, I thank you for the hours I wasted opening up power supply plugs and replacing the center pin resistors:
Here's how the P73 responds:
- 230W works fine 4.6k => I have seen power supplies work with 170W but fail at 230W, so the laptop does draw more
- 170W works ok 1.9k (1.8k also ok)
- 130W rejected 1k
- 90W rejected 550
The rejected power supplies will be used to charge the laptop if it is shutdown, but they will not be used in any way otherwise. On the P70 the laptop would at least use the power supply to keep the laptop alive, and use half battery half external power supply. Not so with the P73, it just ignores it entirely.
This is utter bullshit as I have plenty of 90W power supplies, including 12V car converters, or a 90W external 20V battery pack I can't use anymore.
You can go read my Hacking a thinkpad slim tip adapter to output more than 90W (required to charge a Thinkpad P70) page for details, including this nice battery pack I couldn't use anymore:
*Update* : so, actually with some serious tlp hacking (basically I told it to force battery mode even if a power supply is plugged in), I've managed to throttle the laptop enough, even when plugged in, so that it only uses 20W. At that point, I'm actually able to use my old external battery pack, as well as a 90W power supply, as long as I lie to the laptop and pretend they are 230W power supplies with the resistor trick. In my tests with windows, it was not possible to throttle the laptop enough when plugged in, not to have it overwhelm a smaller power supply (not that 90W is small for a laptop that normally uses 20-30W when it's not charging batteries).
If you scroll to the bottom of the page, you'll also see a terrible buffer lipo hardware hack I did that allows to use the battery pack with higher amp draws, but it's a bit ridiculous (and bulky).
See tlp issue 494 for details on how to setup tlp to run in low power mode when power is plugged in.
Without the tlp hack or the buffer lipo hack, when I lie to the laptop and tell it is connected to a a bigger power supply, manage power draw with what I run, and disable battery charging in software, but the laptop will still draw the power supply for over 100W when you plug it in for a fraction of a second, and refuse it if the voltage drops.
Obviously this would not be a problem if the laptop simply had a 90W power supply mode where it throttle things down and turned off battery charging. This is mostly what the P70 does.
In the meantme, on top of hacking my power supplies, I also made this for my laptop, it looks silly and makes the thinkpad not look like a professional laptop, but well, that's lenovo's fault:
this takes any power supply and replaces the center tip resistor with a 1.9k one to emulate a 170W power supply
From talking to Lenovo, they don't think that this is really a problem, so since I'm an engineer, I made my own external battery pack, but I otherwise recommend to road warriors to avoid thinkpads from now on, given the backward power design in this one.
Making a Thinkpad P73 compatible external battery pack
I did some testing and confirmed that the laptop is very picky about power supplies. It even rejects a 19.7V 20A power supply I had, because it's 19.8V and not 20V. Same thing for amps, it needs to be able to draw maybe around 5A for a short time to accept the power supply (they sure are putting a lot of effort into making sure the power supply is not under-spec'ed).
Prototype with 150W step up converter which takes my 16V lipo to 20V while delivering enough amps to make the laptop happy:
it works, and the laptop thinks it's connected to a 230W power supply thanks to the center pin resistor.
Here's a quick demo:
Version 2 was to have a way to recharge the battery pack while it's being used. I've used this to use the battery pack as a buffer to absorb peaks from the laptop without tripping an external power supply, including in a car limited to 100W or a plane power supply limited to even less:
this works in theory, but the lipo charger is quite slow and wouldn't keep up for long, but I made a better version shown lower down
Lenovo's P73 airplane mode simply stops using the external power supply and reverts to batteries. Sigh...
Oh yes, let's talk about airplane mode. The lenovo engineers thought of everything: if they detect that the power supply drops a few times in a row, they offer a nice setting which is supposed to make the plane more airplane friendly. How friendly you ask? Well, you could throttle down the CPUs, disable battery charging, do smart stuff like that. Or, if you're lenovo, you can have airplane mode simply refuse to use the power supply altogether. Thank you lenovo, you wrote a feature that saves me the trouble of unplugging an otherwise perfectly good power supply that you refuse to use (to be super clear, my 230W power supply is plugged in and airplane mode just disabled it):
Making a battery pack to act both as buffer for a smaller power supply, and as emergency external power (even power the laptop from 12v)
Anyway, back to the battery pack, I found the ISDT H605 Air lipo charger which is small enough and can charge the lipo at 5A, which should be enough to keep up with the laptop when not doing CPU crazy stuff. This also allows using a 12V power supply or a lower wattage lenovo power supply to recharge the pack while it's in use, or not:
version 1 was a bit bigger than I wanted, 90W power supply shown for scale
here, the 90W power supply is recharging the battery at 2.5A while it's being discharged at 3A on the output side, using the battery as buffer
I made version 3 a bit smaller, with a built in 12V lipo to act as buffer for a smaller power supply. Yes, it's a beautiful piece of art, I know :)
Pushed to the extreme, I can now use my original external battery pack again by having it recharge my lipo+150W step up that can output more amps than the ravpower pack can. Of couse, it's inefficient, the ravpower pack outputs 20V that gets down converted to 12V by the H605 Air lipo charger, which charges the built in 3S lipo in the box, and then gets up converted back to 20V without the amp limitation (the phone used to control the lipo charger also inside the box):
The really cool thing is that by using tlp, it's actually possible to tune the laptop down to very low power use, even when plugged in, something that windows probably can't do:
7.3W with the screen off (and around 10W with wifi off and the screen on low dim) is not bad for a laptop that big
4S Lipo vs 4x 18650 or 26650 batteries
I do have a few lipos laying around, so that's free energy for my laptop if I'm willing to carry them. I have however found that for higher draws, the step up converter doesn't quite keep up at 20V/5A+ with just 12V input (3S), but is fine with 16V input (4S):
That said, as I recently found out that 16650 (or better 26650) batteries are both lighter and smaller. The only thing the lipos do, is offer a better discharge rate, but while that's useful for a high power RC plane motor that can empty the batteries in 10mn, it's not needed for a laptop:
Outside of 26650 batteries, there are other ones like https://www.18650batterystore.com/21700-p/samsung-50e.htm .
26650s are 195 Wh/kg while the lipo I gave was 184Wh/kg. The 3rd battery listed is supposed to be 260Wh/kg which is much nicer, that said, it looks like those samsung batteries are actually smaller than 26650s, lighter, and yet offer the same 5Ah at 3.6V. If so, that's very impressive.
As of this writing, I have however not found 26650 battery holders that hold 26650 protected cells that are a bit longer. This seems to the be only one available, and it's too short to hold the batteries: https://www.amazon.com/gp/product/B074GVPWSH
A few months later, I ended up cutting them and taping them to make them longer. It doesn't work great, but it was enough for a few tests. In the end, I found that somehow I wasn't getting enough amps out of them, which surprised me, so they didn't work that well compared to a lipo:
Conclusion
Lenovo, please make the P73 work like the P70, and fix this airplane mode thing that turns off the external power supply. That's embarrassing...
After rewriting multiple related libraries, it became confusing to people how they fit together, Adafruit::NeoMatrix, FastLED::NeoMatrix, SmartMatrix::GFX, where does Framebuffer::GFX fit in?
Is Adafruit::GFX still there/needed?
How about LEDMatrix, isn't it a better 2D lib?
What hardware backends are supported?
How the modules/drivers fit together
I made this little graph to summarize everything:
the left shows the hardware drivers supported: FastLED, SmartMatrix, ILI9341, SSD1331, ST7735, rpi-rgb-led-matrix (for ArduinoOnPC on Raspberry Pi), FastLED_SDL (for ArduinoOnPC), and X11/Linux (also ArduinoOnPC)
The 2nd column is the list of drivers I wrote for all those hardware drivers
All those drivers I wrote inherit from FrameBuffer::GFX wihch stores the actual framebuffer in FastLED CRGB 24bpp Format
LEDMatrix is an alternative to GFX that is mostly compatible, but offers its own extensions. I you wish to use it, I modified it so that it doesn't store the CRGB array within itself, but accepts an externally generated one (so that it can be shared with SmartMatrix if this is the ultimate backend, and allocated via malloc and not a global array, which is required on ESP32 for bigger sizes). More on whether you'd want to use it, later.
Low Level Drv|Glue Driver for FrameBuffer::GFX
FastLED - FastLED_NeoMatrix -------------\ FastLED CRGB Array
SmartMatrix - SmartMatrix_GFX -----------------\ 24bit FB storage API Support
\ CRGB methods like
AF:ILI9341-\ \ scale8/fadeToBlackBy
AF:SSD1331 |--- FastLED_ArduinoGFX_TFT ----------| | ,FastLED API
AF:ST7735 / FastLED_SPITFT_GFX (for AF) | | / (XY 2D to 1D mapping)
ArduinoGFX/ AF:Adafruit (ArduinoGFX is all in 1) | |
| |
ArduinoOnPc-FastLED-GFX-LEDMatrix arduino - FrameBuffer::GFX------ Adafruit::NeoMatrix +
emulation for linux / Raspberry Pi: | | \ Adafruit::GFX APIs
---------------------------------- / Adafruit::GFX \
rpi-rgb-led-matrix - FastLED_RPIRGBPanel_GFX ---/ LEDMatrix (optional) `LEDMatrix API
ArduinoOnPC X11/linux - FastLED_TFTWrapper_GFX
FastLED_SDL (linux) - FastLED_NeoMatrix -/
Which 2D API: FastLED XY(), Adafruit/FastLED::NeoMatrix, vs LEDMatrix
Old FastLED demos use an XY() function, to access leds[XY(x,y)] to do 2D to 1D mapping. Framebuffer::GFX supports this in a way that you can both read and write while supporting full rotation and tile mapping from NeoMatrix. This is honestly no reason to do this today, you would effectively rewrite the much better XY functionality that's in FastLED::NeoMatrix/Framebuffer::GFX. However, if you have code that uses an XY function, it's fully supported, simply use matrix->XY(x, y) to let NeoMatrix do the real mapping for you without having to worry about writing/rewriting the mapping function for each potential array.
The better and most commonly used API is Adafruit::GFX. Honestly I recommend it because of the sheer number of hardware devices supported by it. It has the downside of only being 16bit color, but if you use it in FrameBuffer::GFX, can you can use 24bit color with it. Its 2nd downside is that on its own, it has no framebuffer, so it is write only. Obviously with Framebuffer::GFX, it does have a framebuffer (which can be a downside on some slower hardware at higher resolutions, see TFT below). To learn more about how to use the GFX API, see https://learn.adafruit.com/adafruit-gfx-graphics-library?view=all
LEDMatrix is a better API with more fancy functions than GFX and native 24bpp color, but it's only meant to work on FastLED, and its matrix tiling support and rotation is pretty non trivial to use compared to NeoMatrix. I would only use it if you need its added functionality. On the plus side, Framebuffer::GFX allows you to run LEDMatrix code on any hardware backend, so you aren't limited there anymore. LEDMatrix pluses are
more primitives, including some flip/mirror screen options
Table_Mark_Estes is just that good, that it's worth having LEDMatrix for
LEDMatrix has Fancy Font Support. In my opinion it's more fancy than most people will need, and Adafruit::GFX built in front support is more than plenty, but it's there if you want it.
LEDSprites is nice if you need sprites, see my LEDSprites-Pacman demo
The SmartMatrix library has its own 2D API, it is quite fancy and includes layers, but it is not supported by FrameBuffer::GFX, so unless you're writing a SmartMatrix only project (which means you won't be able to upgrade to RGBPanels on rPI if you need a higher resolution), I recommend against using it. Technically, someone motivated could make the API work with FrameBuffer::GFX and allow rendering on another backend, but I haven't done that work and don't have the need to do so. If you'd like to contribute that, please do.
The good news is that if you don't know which one to choose Framebuffer::GFX allows you to run all 3 at the same time, thanks to the work done in neomatrix_config.h which while not required, I greatly recommend so that it'll setup everything for you and make it trivial to change from one hardware backend to another one.
If you would like an example of each API, please go to https://github.com/marcmerlin/FastLED_NeoMatrix_SmartMatrix_LEDMatrix_GFX_Demos/ and check the demos in each per API directory.
If you would like to read images from SPIFFS/FATFS (ESP8266/ESP32) or SDcard, see https://github.com/marcmerlin/AnimatedGIFs
This is now the library I recommend for all TFTs instead of the multiple libraries written by Adafruit (supported by FastLED_SPITFT_GFX), not quite with the same interface, and multiple drivers. I definitely recommend https://github.com/moononournation/Arduino_GFX instead for new work.
Arduino_GFX supports running multiple TFTs at the same time if you have different CS pins:
comparison of TFTs
The demos below done on FastLED_SPITFT_GFX look exactly the same with FastLED_ArduinoGFX_TFT except for being faster with this driver.
This is probably the most useful driver I wrote out of all of them, the ability to write your code and debug on linux, without any hardware:
Dealing with pushing bigger framebuffer sizes to TFTs like ILI9341
For long the highest resolution target for arduino chips has been the ILI9341 TFTs. With a resolution of 320x240 over SPI, they push the limits of Framebuffer::GFX a little bit, because it's a lot of pixels to push. Unfortunately, the TFT seems to only support about 14 frames per second for a full refresh, which is needed with the framebuffer approach, and by the time you add required use of PSRAM on ESP32, which is slower than regular RAM but required because ESP32 does not have the required contiguous 224KB of RAM, frame refresh falls down to 8fps. Worse, still, once you add computation of data being sent, demos actually run closer to 5fps.
This is far from ideal, but it's good enough or some uses still, and generally still cool that Framebuffer::GFX can be pushed so far on arduino-like chips. Using RGBPanels does not help there on arduino chips, because there is no arduino like chip that can run such a resolution on RGBPanels (Raspberry Pi can barely do it though, but that's also pushing the limits of the underlying hardware refresh capabilities).
It this ends up being a problem, but you made the decision to stick to the Adafruit::GFX API, you always have the option to remove FrameBuffer::GFX and write directly to the TFT, without having to do full framebuffer refreshes.
If you'd like numbers, I gathered as part of a test between SPI speed, raw TFT speed (empty frame push), loop to push data not from PSRAM, loop to push data from PSRAM. Actual speed in demos is still lower given that it takes time to generate high resolution frames to PSRAM (double PSRAM penalty, one to write, one to read), before they can be pushed.
Arduino::GFX ILI9314
tft/gfx/bypass/copy
40fhz, fps no PSRAM: 25/15/22/14 PSRAM: 25/11/21/8
80fhz, fps no PSRAM: 42/19/33/18 PSRAM: 40/14/32/9 (Arduino_HWSPI)
80fhz, fps no PSRAM: 53/21/38/20 Arduino_ESP32SPI
80fhz, fps no PSRAM: 60/20/34/18 Arduino_ESP32SPI_DMA
Adafruit ILI9314 (much slower)
80Mhz: TFT 40fps, NO PSRAM: 32fps, PSRAM show: 12fps
Old Adafruit numbers:
ST7735_128b160: 80Mhz: TFT153fps, NO PSRAM:104fps, PSRAM show: 45fps
ST7735_128b160: 40Mhz: TFT 68fps, NO PSRAM: 56fps, PSRAM show: 32fps
ST7735_128b160: 20Mhz: TFT 53fps, NO PSRAM: 45fps, PSRAM show: 29fps
ST7735_128b128: 40Mhz: TFT117fps, NO PSRAM: 90fps, PSRAM show: 48fps
Arduino::GFX is a lot faster (over 100fps)
SSD1331: SWSPI: TFT 9fps, NO PSRAM: 9fps, PSRAM show: 8fps
Now it's your turn, write your own 2D demos and contribute them back
victory, first time I got those new panels to light up
I ended up getting 15 such panels from the nice folks at Azerone, because they were returns as other people couldn't use them due to lack of FM6126A support in the open source drivers at the time:
if only I had proper mounting hardware, this would be a decent 192x160 array
Ok, after writing this blog, I ended up getting a recommendation for rails, which weren't built for this but worked well enough:
you'll need something to cut the rails that are too long. I used a set of bolt cutters I had, some saws may work too, but the rails are pretty thick
holes don't all match, but enough of them do. Note that I put the panels in Z pattern
adding power
on my first try, the metal cut the ribbon cable, so I removed the top loop to avoid having it go towards the metal
Now, I had an expected problem that hzeller/rpi-rgb-led-matrix did not support panels stacked vertically, never mind if every panel was upside down. I ended up writing a new mapper that allowed both vertical stacking and zig-zag. After that, success was had, end result was about 300Hz for 31K pixels with the active-3 board:
That said, while that bigger matrix with those 15 panels was 192x160, I had bigger plans. I got distracted due to other work, but then P2 panel appeared (2mm per pixel). The downsides of those panels is that the copper traces are so small that pixels come off easily, including during shipping:
even pixels that don't pop off can be partially failed
using the active-3 board with 3 chains of one panel each on rPi3
The first issue was that the newer 128x64 panels were FM6126A, which didn't work with default libraries as they need a special init. Thankfully this was added to rpi-rgb-led-matrix. Next issue was that refresh rate was going to suffer, and that's where the rPi solution is great: it allows for 3 channels in parallel thanks to the nice Electrodragon active-3 board.
Chow He from Electrodragon was super nice, and sent me some boards with angled connectors (at my request) so that I could make the whole board more flat for my wearable application. I was really hopeful that I could put the connectors under the board for low profile after cutting the notch and moving it to the other side of the connector:
However, wire routing was such that pins were in the wrong order and it was impossible without re-routing all the wires on the board, so I did the next best thing and put the connector on top of the board, which is still more flush than when it was pointing up:
before (blue), not working (right), and after (left)
bottom is not possible, even after moving the notch
Still, 192x128 is a very nice display that happens to be the same size as my old 96x64 display using P4 panels, but since I ordered spare panels to get around the falling pixel problem, I had enough panels to make a 9x9 array of 384x192. I first tried with with rpi-rgb-panel's video viewer and it worked quite well:
During that time, I did a lot of work on 2D APis for Arduino and lots of backends, and wrote the base class, FrameBuffer::GFX. In a nutshell, it allow talking to a lot of hardware displays, now both on Arduino and Raspberry Pi:
Low Level Drv|Glue Driver for FrameBuffer::GFX
FastLED - FastLED_NeoMatrix -------------\ FastLED CRGB Array
SmartMatrix - SmartMatrix_GFX -----------------\ 24bit FB storage API Support
ILI9341 \ \ CRGB methods like
SSD1331 |--- FastLED_SPITFT_GFX ----------------\ scale8/fadeToBlackBy ,FastLED API
ST7735 / | | / (XY 2D to 1D mapping)
| |
ArduinoOnPc-FastLED-GFX-LEDMatrix arduino - FrameBuffer::GFX------ Adafruit::NeoMatrix +
emulation for linux / Raspberry Pi: | | \ Adafruit::GFX APIs
---------------------------------- / Adafruit::GFX \
rpi-rgb-led-matrix - FastLED_RPIRGBPanel_GFX ---/ LEDMatrix (optional) `LEDMatrix API
ArduinoOnPC X11/linux - FastLED_TFTWrapper_GFX
FastLED_SDL (linux) - FastLED_NeoMatrix -/
This first demo of simple demo code that scaled up pretty quickly, explaining some of the challenges of scaling past 256 pixels in any dimention and 64K pixels total which hits a FastLED uint16_t limit:
This is an early demo of my shirt code running on a display that is so much bigger than what it was built for:
After some work to find a couple of crash bugs that came from scaling up, I was able to run Mark Estes' fantastic demo code I was able to scale up to such big displays without too much trouble. See Table_Mark_Estes1 and 14.
Table_Mark_Estes:
Table_Mark_Estes14:
Just put back an idea of scale between my first panel at 24x32, all the way up to 384x192. Yes, those are the exact same sprites with LEDSprites:
While 384x192 is starting to push the physical refresh limits that are acceptable for a 3 parallel chain setup, I'm going to try 384x256 for fun once I can get the pixel mapping to be correct. Bigger than that will require multiple control boards and synchronization by some network:
this was my first attempt, panel mapping didn't work, I'd have to write my own
Interestingly, SmartMatrix adds panels in the vertical direction by default, while rpi-rgb-led-matrix adds them horizontally. This means I had to write a new Mapper for it: V-Mapper, which allowed me to make 3 parallel horizontal chains. The end result is not great as refresh rate is only 100Hz, but it works:
success!
that was a lot of work for a low resolution screen :)
video still plays
New pictures of Table_Mark_Estes in the higher resolution:
As above, thanks again to Chow He from Electrodragon for the great and cheap active-3 boards, and big thanks to Hongren Su from Azerone for selling me the panels I have used so far. You can find the Azerone store on amazon for panels you can buy and the 128x64 P2 Panels here.
On the software side, many people to thank, but obviously I wouldn't have gotten started with Adafruit, Louis Beaudoin for SmartMatrix on arduino chips, and Henner Zeller for rpi-rgb-led-matrix of course.
Getting Higher Speeds
Pushing 256 lines deep (with 128 pixels wide for each chain) is pushing the limits of how much data you can push and still get an acceptable refresh rate. I had to lower some quality numbers to get a usable refresh rate:
rgb_matrix::RGBMatrix::Options defaults;
defaults.hardware_mapping = "regular"; // or e.g. "adafruit-hat"
defaults.rows = 64;
defaults.cols = 128;
defaults.chain_length = 4;
defaults.parallel = 3;
// 50 is faster but makes the screen dimmer
defaults.pwm_lsb_nanoseconds = 100;
// lower color depth definitely helps refresh
defaults.pwm_bits = 7;
// Time dithering of lower bits
// 2 changes speed from 400Hz (from 160Hz)
// 1 is also a faster option that's a bit brigher
defaults.pwm_dither_bits = 2;
defaults.led_rgb_sequence = "RBG";
defaults.panel_type = "FM6126A";
defaults.pixel_mapper_config = "V-mapper";
rgb_matrix::RuntimeOptions ropt;
#ifdef RPI4
ropt.gpio_slowdown = 2;
#else
ropt.gpio_slowdown = 1;
#endif
Build
This is a temporary frame I made for my 384x256 array, itself made out of 3 smaller 128x192 arrays I was going to use as portable battery powered frames for my outfit. Unfortunately I used one bolt that was a bit too long and damaged a line on one panel when I screwed it in. Doh :(
