RGB1 & RGB2: poor signal performance

[MaffooClock]

I started with a Manta M8P v1.0 a year ago and had issues driving a 63-LED strip of SK6812 LEDs (RGBW). The first 20 or so would illuminate as expected, but the LEDs after that would either not illuminate, or have the wrong color, or not turn off, etc.

I checked the wiring and everything seemed perfect -- 0.15Ω end-to-end on all three conductors.

I even opted to drive the LED strips with an external 5V power supply just in case the +5V in the RGB1/RGB2 headers wasn't able to supply enough power. Of course, the negative from the external power supply was bonded to the GND in RGB1/RGB2 headers (so +5V in those headers was not used, only PA9/PB15 signal and GND). No difference -- I had 5V all the way at the end of the run.

I put an oscilloscope onto the data lines and sent a pattern to sequentially illuminate one LED at a time at 30fps, and here's what I saw:

Channel 1 is connected at the RGB1/RGB2 header, Channel 2 is connected at the end of the wire, just before the LED strip:

As you can see, the signals are almost identical; the peak-to-peak is about 5V, as expected so this seems to prove that my wiring is fine.

Channel 1 is connected at the RGB1/RGB2 header, Channel 2 is connected after the last working LED in the strip (roughly 20 LEDs down the strip):

As shown here, the signal degrades to almost nothing.

As a test, I also tried wiring a strip of the SK6812 LEDs still on the spool directly to the RGB1 and RGB2 headers and got exactly the same behavior! So it's not the LED strip I'm using, and it's not the wiring. Why does the signal look correct at the beginning of the LED strip, but then quickly degrades as it passes through each LED?

---

As a workaround, I abandoned the RGB1/RGB2 headers and loaded Klipper onto a Seeed XIAO with a 3.3V-to-5V level shifter to drive my SK6812 LED strip, and it works perfectly -- same wiring and power supply.

As I said at the beginning, all of this was a year ago. Fast-forward to today...

A couple of weeks ago, I wanted to implement CAN bus for my toolhead. I quickly found out that my Manta M8P v1.0 did not support CAN, so I purchased a new v1.1 board that does. Since I had the printer opened and disassembled anyway, and since I have a new board, I decided to test the RGB1/RGB2 headers again on the new board -- maybe my old v1.0 board was damaged or had some other problem?

Nope -- exactly the same behavior with the RGB ports on the v1.1 as the v1.0 Manta M8P.

---

Looking at the schematics, I see the RGB ports are driven with a 74LVC1G17 Schmitt-trigger buffer, which seems like a clever way of converting the STM32's 3.3v output to a proper 5V signal while also ensuring a clean digital signal.

However, that's a generic part number, so I don't know which manufacturer's IC you actually used -- especially since the schematics show the use of a OE pin (output enable?) that none of the datasheets I looked at (TI, Nexperia, Diodes Incorporated, or NXP) described. Since I don't know exactly which 74LVC1G17 is being used, I can't look up the timing characteristics for it.

The solution I used (with the dedicated XIAO board and the level shifter), the level shifter I used contains BSS138 MOSFETs instead of the Schmitt-trigger buffer used on the Manta.

So, here's the question:

Is the 74LVC1G17 the problem? I'm using SK6812 LEDs (32-bit RGBW) instead of WS2812 (24-bit RGB), but that shouldn't matter (I don't have any WS2812 to test with). In other words, why can I drive the same chain of LEDs with a different MCU perfectly fine, but the Manta M8P cannot?

[gromprops]

I don't have an oscilloscope to fully confirm the same pattern of signal degradation but my setup with 40 WS2812B's plugged into the RGB1/RGB2 port is having the same issue. The same strips work flawlessly when driven by an Arduino + 5V external power.

[mrstone14]

I am also having the same issue using my Disco on a Stick XXLs (WS2812B's) on RGB1/RGB2. I have tested these to be working fine using WLED and esp32 devices running the same effects. No oscilloscope to confirm either, unfortunately.

[dotorg]

FWIW, this is normal behavior for WS2812B chips. Its why larger installations with them inject power every 50-60 LEDs. The chip uses VCC to produce the output signal, and voltage drops quickly, between high resistance in the strip and a general lack of available current in power supplies. The result is a color shift towards red, as the blue and green LEDs need more current, and eventually you get signal issues as the control chip doesn't have enough voltage left to keep the required level differentials at the next chip down the line. WS2812B-5050s use about 60ma per LED at full brightness, so you're already at 5 amps when you get to 50. RGBW LEDs are 80ma per, so the problem is 33% worse.

Given 5 amps is more than the Manta can provide, that's why you're getting drop-outs at around that point.

The controller chips in the LED are store-and-forward, so none of the signals you see past the first chip are coming from the Manta, they're coming from the previous chip. (You can see that if you run a 3.3V DIN to a WS2812B -- DOUT is re-transmitted at 5V)

[MaffooClock]

this is normal behavior for WS2812B chips

False.

Two of us have stated that we're using external power supplies. The only connection between the Manta and the LED strip, then, are signal and ground (and the Manta ground is bonded with the ground on the external 5V power supply, of course).

When we move that LED strip from the Manta to a separate MCU, but changed nothing else -- same external 5V power supply, same wiring, same everything -- the entire LED strip works just fine.

The controller chips in the LED are store-and-forward, so none of the signals you see past the first chip are coming from the Manta, they're coming from the previous chip.

Correct.

So it doesn't make sense that after the first 20 LEDs that the signal degrades like it does as shown in the second photo of my original post (still using the external power supply). But then when I move the LED strip from the Manta to the external MCU, the signal out from each LED is perfect all the way to the end. This makes me think there's something funky with using the 74LVC1G17 to drive the NeoPixel signaling.

WS2812B-5050s use about 60ma per LED at full brightness, so you're already at 5 amps when you get to 50. RGBW LEDs are 80ma per, so the problem is 33% worse.

My SK6812's (which are RGBW) are supposedly 0.3W at full 4-color brightness, so that's 60mA each. My run of 63 LEDs then only draws 3.78A.

My power supply is a Mean Well RS-25-5, which can supply 5A @ 5V, so it's enough to drive my string of 63 x SK6812's. If they were 0.4W as you professed, then yes, that string would be pushing it on that power supply (5.04A), but I rarely drive them at full color/brightness anyway (so I'm probably only pulling a couple amps when my chamber is just red @ 80% brightness, for instance).

But again, this is still off-point, as we've made it fairly clear that everything works fine when using an external MCU instead of the Manta, all other aspects being the same.

[irebane]

Having exactly the same issue with v1.1 board. Chain of 42 SK6812 LEDs, noticed that it's not working specifically when I am printing. When printer is 1st booted all seems to be working fine. Tried both power from LED 1 or 2 headers or with external PSU.

[anthobreizh]

Hi everyone, I have exactly the same problem on a MANTA M8P V1.2 with SK6812 and WS2812B leds.

Only 42 leds out of 84 light up with an external 10A power supply ....

[irebane]

It would be very nice if BTT engineers could share some information and release instruction for hardware fix or modification that we can make in order to fix this problem. I personally have 0 issues to get it done myself as it's better than having not working feature.

[Synapsis121]

I am also having the same problem with the RGB1/2 on the board. I also have an EBB42 with the toolhead pixels connected. They are only 18 leds but they work perfectly while like all the rest of you the LEDs controlled by the board do what they want. I wonder if its something different that uses to control the leds?

[NegussugeN]

Just chiming in to say I believe I'm experiencing the same issue, except I'm only using 18 led Disco Sticks. It works fine about 80% of the time when switching colors, but that other 20% will have the last 3-5 LEDs in the chain turn a random color.

[Foose83]

J'ai également le même problème avec ma manta M8P v1.1. Problème que je n'avais pas avec ma carte Octopus v1.1.

[ajaytanna]

Can the LEDs be connected to any other spare available output port on the Manta M8P V1.1 for expected reliable operation?

[irebane]

Can the LEDs be connected to any other spare available output port on the Manta M8P V1. for expected reliable operation?

I have tried other headers same result.

[NegussugeN]

Can the LEDs be connected to any other spare available output port on the Manta M8P V1.1 for expected reliable operation?

I tried this as well with the same exact result. I ended up abandoning the RGB ports on my M8P v1.1 and started handling it all through a klipper expander, which works flawlessly.

[ajaytanna]

What's a Klipper expander please?

[NegussugeN]

What's a Klipper expander please?

http://lmgtfy2.com/?q=Klipper+expander

[ajaytanna]

Just couldn't resist could you? I realised soon after I typed but before I could clean the grease off my hands you had made the killing. Thanks for the suggestion, but I will try something simpler and report back if it works.

[NegussugeN]

Just couldn't resist could you? I realised soon after I typed but before I could clean the grease off my hands you had made the killing. Thanks for the suggestion, but I will try something simpler and report back if it works.

I couldn't. 😂 I've been using the expander board for about a month and have had zero issues. They're super cheap and only take about 5 minutes to set up. Hardest part is figuring out where to mount it. So if all else fails, I'd say to give one a try.

[Vazs]

M8P v2 has the same 74LVC1G17 shifter and I had the same problem with it, first LED worked completely randomly, it didn't even count in the chain, and the rest of the leds worked with wrong color order, like the first part of the signal get lost somewhere. A simple 220ohm resistor in the data line right after the board solved it.

[irebane]

M8P v2 has the same 74LVC1G17 shifter and I had the same problem with it, first LED worked completely randomly, it didn't even count in the chain, and the rest of the leds worked with wrong color order, like the first part of the signal get lost somewhere. A simple 220ohm resistor in the data line right after the board solved it.

Tried it, didn't' worked for me on M8P v1.1

[NegussugeN]

M8P v2 has the same 74LVC1G17 shifter and I had the same problem with it, first LED worked completely randomly, it didn't even count in the chain, and the rest of the leds worked with wrong color order, like the first part of the signal get lost somewhere. A simple 220ohm resistor in the data line right after the board solved it.

Same for me. I tried about half a dozen values from 100ohms to 1.4k ohms on both ends of the data line and the result was the same. :(

[Foose83]

Comment avez vous alimenté le klipper extendeur? 5 volts ou 24 volts ? J'ai alimenté le mien en 5 volts et je n'ai que 16 LEDs sur 60 qui s'allume. Alimentation meanwell 5v.

Tout fonctionne correctement maintenant j'avais 4 leds dans ma bande qui ne fonctionnaient pas et donc toutes celles qui se trouvaient après ne fonctionnaient pas.

[oMTEo]

Also I have the same LED-Port-Bug and Im very frustrated about it :( Searching for some solutions since days....

[ajaytanna]

Yesterday I connected a 19 element RGBW SK6825 strip to the manta m8p v1.1 rgb port 1. Worked as expected using julian schill's guthub as a guide. No issues so far. Planning to do 2 of these strips. Will report how that goes.

[bigtreetech]

It seems that there are different issues being reported:

1.) Signal fails after a particular number of LEDs. This can be a certain number when not printing and this number may reduce when printing starts. 2.) Signal is not output correctly into the first LED and LEDs after the first work but are not the right colour. 3.) Some users don't have any LEDs working at all.

1.) The OP is experiencing point 1 and so are many others. This is a limitation of the CPU being used on any given board. The protocol used for RGB LEDs is bit banged. This means that each bit is manually timed within the MCU and then the IO is toggled. Each new LED in the chain requires 24 new bits which in turn requires 48 new IO transitions. All transitions must take place within one main loop of the klipper cycle on the MCU. The MCU on a motherboard is a very busy one. It must handle all stepper signalling, temperature sampling and control and all other functions being driven from the board. Much of these functions should happen once within every single execution of the main loop within klipper. This leaves only a limited amount of resources available for manual bit banging of an IO. When the LED strip turns off after a certain number it is because the maximum number of LEDs that are supported by the CPU has been reached. This is also why a user reported that this number would vary based on whether or not he was printing (CPU load varies). When the OP saw the signal dying it was because there was simply nothing left to relay by the last LED. The chain that was output by the MCU had ended. Note that the signal at the final LED will not match that at the start of the chain because each LED slices off what it needs and then buffers and repeats the remaining bits. This causes a 1 LED (24 bits x bitrate) delay in the signal after each LED. Expansion boards that are not handling much config at all will be able to handle a far greater number of LEDs.

TLDR for point 1: If you are limiting after a certain number of LEDs then that is simply the max that the CPU can handle with your config.

2.) If the first LED is giving an error and the rest are showing wrong colours then it means that there are bit errors when passing the signal to the first LED. If you look at the scope signals from the OP you will notice that ringing has appeared on the LED end of the signal after it travels through the harness. Ringing is an effect caused by parasitic inductance and capacitance that appears on the harness. With too much ringing, the bits can become so distorted that the first LED in the chain cannot even understand them properly. A series resistor acts as a damper and reduces ringing which is why this has worked for some people. To reduce parasitic components you must ensure that the wire path is as short as possible with no coils in the wire and that you are not running the wire in parallel with other noisy wires such as motor wires for long distances.

3.) For users who can get no output at all from the LED strip, ensure that you are not using too many LEDs in the chain (remember that there is a limit of about 50 LEDs if you are powering from the M8P and this limit reduces further if you are also using the M8P to power any other external, high current devices). Also check your config and check the LED strip (test using another, shorter strip if you have one). If you still cannot get any output at all then we recommend that you open a ticket using the ticketing tool on the website or send an email to the support email address listed on the website.

[MaffooClock]

1.) The OP is experiencing point 1 and so are many others. This is a limitation of the CPU being used on any given board.

This behavior was observed on an idle system -- all motors off, all fans off, no heaters -- nothing active except LEDs.

The MCU on a motherboard is a very busy one... This leaves only a limited amount of resources available for manual bit banging of an IO.

You're saying a 64MHz STM32 on the Manta M8P v1.1 can't run more than about 20 LEDs while otherwise idle? Someone else reported this issue on their new v2.0 board, so a 550MHz STM32 isn't good enough, either?

I don't buy your explanation, as adding in a separate MCU for LEDs (the Xiao, with 48MHz SAMD21 in my case) solved the problem instantly. I could understand having incomplete RGB cycles for layered animations or complicated patterns at high frame rates, but in this case, even a simple "all LEDs on" signal fails on an idle machine.

It feels like we're not being taken seriously. The response from @bigtreetech comes off (to me) as "there's no way we have a bug in our hardware, you all are just not smart enough to use it correctly." I felt like I did more than my own due diligence in diagnosing and reporting the problem, the least BTT could do is the same -- why not test this in your own lab?

[ajaytanna]

Since I was busy building and all I did not pay much attention to the LEDs. Initially they worked when printer was not doing anything, but none of the other actions like heating, probing calibrating etc. work as expected. Some LEDs at the end of the chain do not work as observed earlier. Seems I too have to go in for the secondary MCU option

[ajaytanna]

After extensive testing on arduino nano decided to revert to the Manta M8P ports after adding a 680 ohm 0.25W through hole resistor per julianschill's advice to each data line on the strips (23 pixels of SK6812 RGBW X 2 strips) The entire set does work as expected. So until it acts up again I consider it working. Need a few days to make a video since I have the printer inverted for beeper and other wiring. Once I put the julianschill led effects through its paces and am satisfied all is ok I hope to make the video. The LEDs are wired as 19 pixels each on top frame L+R and 4 pixels each bottom frame L+R with 24awg silicon wire twisted together running to the electronics bay about 0.5 meter each line.

[ajaytanna]

Additional observations: When the printer is idle i.e. the MCU on board the manta is not super busy, all LEDs connected to the RGB ports work as expected every time smoothly and flawlessly. Only when it starts doing anything like homing, levelling printing etc., the lights choke up. Any animated effect glitches out since the MCU is not able to send the requisite data perhaps. Static effects work at whatever colour and brightness they are set at. What has me stumped are the very unpredictable results I got on an arduino nano. I will see if I can lay my hands on a klipper expander.

[bigtreetech]

1.) The OP is experiencing point 1 and so are many others. This is a limitation of the CPU being used on any given board.

This behavior was observed on an idle system -- all motors off, all fans off, no heaters -- nothing active except LEDs.

The MCU on a motherboard is a very busy one... This leaves only a limited amount of resources available for manual bit banging of an IO.

You're saying a 64MHz STM32 on the Manta M8P v1.1 can't run more than about 20 LEDs while otherwise idle? Someone else reported this issue on their new v2.0 board, so a 550MHz STM32 isn't good enough, either?

I don't buy your explanation, as adding in a separate MCU for LEDs (the Xiao, with 48MHz SAMD21 in my case) solved the problem instantly. I could understand having incomplete RGB cycles for layered animations or complicated patterns at high frame rates, but in this case, even a simple "all LEDs on" signal fails on an idle machine.

It feels like we're not being taken seriously. The response from @bigtreetech comes off (to me) as "there's no way we have a bug in our hardware, you all are just not smart enough to use it correctly." I felt like I did more than my own due diligence in diagnosing and reporting the problem, the least BTT could do is the same -- why not test this in your own lab?

See the additional comments on this thread which validate this. While I appreciate that you put effort into your investigation, I am afraid that I cannot change the facts to suit the desire for a different outcome. The explanation that I have provided is entirely factual and is the reality of what is happening. The MCU is simply unable to keep up given the bit-banging nature of the comms and the large overhead for each new LED.

[MaffooClock]

Alright, @bigtreetech, message received loud and clear: BTT is not interested in standing by their products at all (I've heard that support is a joke, and now I see why). My interest in future BTT products will be minimal.

[looxonline]

Alright, @bigtreetech, message received loud and clear: BTT is not interested in standing by their products at all (I've heard that support is a joke, and now I see why). My interest in future BTT products will be minimal.

Sorry to hear that. I'm not sure what else you are expecting. Again, we cannot change the reality of what is happening and have already explained it. There is no hardware bug. It is simply the MCU hitting the maximum limit of what it is able to push out within a single klipper operating cycle. We have both confirmed this in empirical testing and with the klipper developers.

Edit: Note that your reference to the 550MHz CPU having the same limit is incorrect. If you read that comment you will see that he simply was having ringing issues and damping the signal using a 220ohm resistor cleaned it up (see point 2 in my detailed explanation from a few months back). That is something that can happen based on each unique wiring implementation depending on how much capacitance and inductance is introduced into the signal over the path that it travels. I can assure you that the user in question will be able to drive more LEDs than the V1.1 PCB using his faster MCU.

[looxonline]

Someone else

With regards to your unpredictable results on the nano, note that many boards will be bit-banging this signal. That means that they will be manually toggling an IO pin based on an internal timer interrupt. Some boards are able to clock internal timers much faster than others and therefore reach much higher data rates on a bit-banged pin (the RP2040 is a good example of this). Other boards are much more limited in the effective data rates that can be produced from a bit-banged pin. STM MCUs tend to be more limited in this regard and require quite a high master clock rate in order to push out higher bit-banged data rates.

[Foden7]

I have the same setup and abandoned the M8P controlling the LED's and now use WLED with an ESP32 board. PITA as I'd still like to controll the LED's via the M8P

[sajrashid]

This is what I have tried board is Manta M8p v2

• Inline resistor (data line) 220 and 100 ohms 😔
• Capacitor small value on the 5v line 😔
• 5v 6a SMPS with a shared ground 😔

I got to light up accidently as the ground was loose, but only about half lit up and did not respond to software changes (apart from a slight flicker)

So has the v2 gone backwards in the LED game

This whole thing is suss - I mean if you sold an LED controller that did not work in how many situations ?

[Foden7]

Yep, the Octopus could handle it. The M8P is a good board, so I would cut your losses and do LED via WLED like I did

[looxonline]

This is what I have tried board is Manta M8p v2

• Inline resistor (data line) 220 and 100 ohms 😔
• Capacitor small value on the 5v line 😔
• 5v 6a SMPS with a shared ground 😔

I got to light up accidently as the ground was loose, but only about half lit up and did not respond to software changes (apart from a slight flicker)

So has the v2 gone backwards in the LED game

This whole thing is suss - I mean if you sold an LED controller that did not work in how many situations ?

And you are sure that your LED strip is good? I am running two M8P V2 boards and both don't skip a beat when driving strips of 60 WS2812B LEDs.

Also, do you have a scope or even a multimeter? You could set the LED output pin as a standard IO and drive it high and low to measure it on the multimeter to see that signals are making it through.