WLED costume Driver, worklog

I did a few tests today. I checked the reset circuit, according to the document esp32_datasheet_en.pdf 2.5.3. The delay between power (yellow) start and reset (blue) release should be 50us. In my system, it is 50ms. (oscillogram) :stuck_out_tongue:

I checked the activation time of the protection on the outputs of the LED strips. After a short circuit (yellow line) you can’t see any changes in the 3.3V supply voltage. (oscillogram)

I checked the current consumption in the off state. The measurement was made with the SANWA PC7000 meter
1.8mA and after turning on the power without 200mA tape, quite a lot.

I also charged the battery. I performed the test with a UT658DUAL meter. Charging lasted 9:31:25s with an average current of 1.3A battery capacity 58880mAh

I have only now noticed such an extension Usermod Battery - WLED MoonModules Project

I soldered the cable to A0 and the resistor to BAT+, we will see how this function works.

The next day of testing brought further observations.

  1. The IP5306 battery charging system behaves quite strangely. The first suspects are the U12 and U11 systems. I guess I will have to get rid of them and move the discharge protection to eFuses or connect a separate battery line directly to IP5306. For now I’ve desoldered them and we’ll see if it helps.

  2. I started the LED strips. Of course, initially I didn’t notice the current limit option in the program, so they glowed very dimly. After turning off this function, the brightness increased, but still at maximum brightness in white the reading is 3.7A, I expected more.

  1. I measured the current consumed by the device at rest again and it was 0.2A, which is very disturbing.

  2. After turning on the Strobe effect on the board with connected LEDs, you can observe strange behavior of the IP5306 which flashes its signaling diodes. I need to measure the voltage behavior with an oscilloscope, I will probably need an additional large capacity to smooth it out, but it may be the fault of the test system (long cables), we’ll see what happens next.

This problem is quite obvious. IP5306 has a built-in step-up converter, but the battery potential appeared at its output. If the batteries are fully charged, they have more than 4V and the 1117 stabilizer starts to conduct, activating ESP, hence the inability to turn off the device and high current consumption.

Overall, the solution is simple - use an LDO with an EN input and connect a resistance divider to it in such a way that it turns on only in the presence of 5V.

I don’t know if I can improve it in this version

I did some additional testing on the circuit with short cables. The fear from the previous post was not confirmed (fortunately) but maybe I will use a different LDO and so the RT9193-33GB has a UVLO option.

  1. I measured the current with the switch turned off - 1.8mA
    (photo)

  2. Current consumed when ESP is operating
    (photo)

  3. Single strip full power, white color. 2.26A

  4. 4 bars of 5.02A, you can see a decrease in brightness

  5. Measurement of 2.56V voltage at the end of the strip

  6. 3.51V measured on the battery

  7. Test the operation of the fuse, I shorted the belt power supply with tweezers. As you can see, the system still works properly.

Summary.
The battery cannot power such a number of LEDs. The problem seems to be the voltage drop on the strips, which makes it impossible to pump more current into them. I guess a step-up converter would be helpful here…

PS
There is something wrong with the LED assembly at IP5306, probably the order

Another day of research. I decided to add a converter and see if it would help.
I cut a path at the bottom to separate the power supply for the belts from the rest of the system

Then, to avoid a short circuit, I placed the TPS61088 converter module that I had designed earlier on a piece of sponge.

I can’t see why R10 was damaged :smiley: So 3 of the 4 LED strips worked, but you can still see a much higher power consumption.

Unfortunately, the choke used is much too small and heats up to a high temperature very quickly.

I will have to replace it with something bigger.

I decided to run and check two more modules. I will try to solve the problem of voltage drop on the strip by running additional return wires along the LED strip.
A few additional comments appeared during installation:

  1. It is necessary to add a decent thermal relief for the ESP32 chip. Soldering. Raining ground is a terrible experience..

  2. I need to enlarge the mounting holes for the 4-pin connectors, I had to drill them out to press them in.

  3. The footprint for the USB C connector should have longer pads, at this point the leads completely cover them and it is difficult to get a good contact

  4. Protection against battery discharge can be implemented on eFuses, so the U12/U11 systems are unnecessary in the next revision.

  5. The ESD5Z3.3T1G transil is too small to be sensibly soldered by hand, it will probably be better to use a double transil to protect the Data and power lines.

  6. I removed the middle mounting point of the battery side panel and it was causing a collision.

  7. Despite checking the diagram, it turned out that the LEDs had to be soldered differently to work properly… I need to roate them by 180 degree, swap anode with cathode.

  8. C51 must be moved to the right (colision with enclousure)

  9. i will be better to use SN74LVC1G14DBVR as buffer (bigger package)

  10. Add rezistor to connect ADC with BAT+ in order to monitore it by ESP32

  11. IQ current is to big, and under voltage protection does’t work!

  12. Use MAX17048 battery monitor

  13. Use TPS22917 or similar nano leak power switch

  14. It is a good idea to put some ferrite bead on each power domain to have ability to measure each section current

  15. LED strip Idle current is huge! 55mA per 2m strip
    Correct Way to connect USB C ESP32 programmer

  16. Check out PAM2401

Programmer → CN4 Prog Connector

  1. GND → 1. GND
  2. BOOT → 4. GPIO [pin 25]
  3. EN/RST → 5. RST [pin 3]
  4. TX → 3. RX [pin 34]
  5. RX → 2. TX [pin 35]
  6. 3V3 → 6. 3V3

I wasted a lot of time on debugging because instead of layouts
SN74AUP1T32DCKR
I installed:
SN74AUP1T34DCKR

However, these integrated circuits have a completely different pinout…

So I find another bug in my design, even if i switch power off by double click and thus switch off 5V boost, the LED strip will still glowing XD

And for some reason switch connected to ESP doesn’t work…

Today i have tested microphone and button, of course i just declare wrong pin for button and after change it to correct one works like a charm, also microphone works great.

5V boost, the LED strip will still glowing XD

I can mitigate this effct by siply swotch off the device by ESP button first but still it is something that i would like to fix in next generation

Another day of testing and another oversight.

  1. Power consumption in standby.
    As I said earlier, I measured the current consumption from the battery with the device turned off. The result is 2mA. A bit too much, a cell with a capacity of 3000mA would theoretically be discharged after 1500 hours, i.e. about two months. In practice, it would probably be worse because the cell will never have 100% capacity.

However, a much bigger problem occurs when we leave LED strips connected to the device. My single 2m long strip draws 50mA when idle!

I started looking for the reason for the high power consumption. First of all, in the current solution, the eFuses [TPS259631DDAR] are permanently connected to BAT+, which means that they consume a current of 200uA, according to the documentation. Since there are 4 of them, it gives a total of almost 1mA of current. If the method of controlling them was changed and they were turned off together with a voltage of 5V from IP5306, firstly, the problem of current consumption by the LED strips would be solved, and secondly, the eFuse system would consume power when they are turned off. 0.5uA!

Unfortunately, directly connecting the EN inputs of the fuses to 5V does not solve the problem. When they come to rest, they are not pulled tightly enough to the mass and do not enter idle mode. I need to add an additional transistor there.

  1. LDO current consumption

Another problem is the power consumption of the LDO. The selected LD33 system, according to the catalog, can draw from 5 to 10mA of current in the idle state!!!

Definitely not suitable for this application. I measured the current consumption with the LDO soldered in and after disassembling it, as you can see, the stabilizer itself consumes about 1mA of current.

What’s actually right:
4x200uA = 0.8mA from eFuse
1mA from LDO which gives a total of about 2mA

I measured the current after shorting the EN inputs to ground and after desoldering the LDO.

<0.01μA Standby Current When Shutdown
Final result 330uA + potential current of the new LDO

For RT9193-33GB it should enable shutdown

<0.01μA Standby Current When Shutdown

you should read my notes on “deep sleep” usermod, all your findings are already explained there.

I made additional measurements on the tapes. The effects are not very promising. I tested 120 LEDs lit at 255, 255, 255 RGB, which corresponds to the white color. I am attaching the results in a PDF file, as you can see, when powered by 3.4V, even the color of the strip is far from white. Additionally, you can see the influence (page 2) of the power supply loop. On page 3, I made loops with a 2m long cable, i.e. one that I could run parallel to the belt. As you can see, the effect is similar to the short loop on page 1. On the following pages I do the same, but with a voltage of 6 and 5v, the results are generally better. The last pages show the effect of shortening the strip to 60 LEDs.
In general, the conclusions are that I need to divide the strips into shorter fragments. And think carefully about the power supply on the outfit, especially the routing of return cables.
Measurments2.zip (3.8 MB)

Based on experience with the previous version. I started working on an improved solution. Measurements showed that it needed to power the strip from 5V. I thought that instead of using electronic fuses, I could use a step-up converter with short-circuit protection. Of course, the overall efficiency of the device will probably suffer, long operating time was not a priority.
I would like to use PAM2401 circuits have short-circuit protection and low current consumption in shutdown mode. And they also disconnect the load with an additional mosfet so there will be no problem with the illuminated strip.
In addition, the idea is to reduce the current consumed in the off state as much as possible. For this reason, I would like to disconnect as many circuits as possible with the EN signal. Since the microphone module does not have an EN input, I thought that the easiest way would be to use a second stabilizer with control. In addition, it can disconnect the three-state buffer (as long as it needs 3V3 power.
The BQ24075 system will be used to charge the cells, I still have to think about it. On the one hand, it has a USB/Battery power path switching, on the other hand, it offers only 1A of current charging, on the third hand it is linear, so it will take up little space…

In the first step, I will make myself a small development module with a PAM2401 converter
TLV61070A
this integrated circuit also seems to be a good candidate due to its easy assembly and availability

I made a few additional changes.

  1. Basically, every WS2811 system works as a logic level converter, so I probably won’t need 5V.
  2. Linear regulators can be powered by either 5V from USB or batteries.
  3. I think I will use the TLV61070A chips, they are much more easily available.
  4. AP2112 looks like an interesting LDO with low iq current and maximum output current of 600mA, it is interchangeable with RT9193-33GB, I will definitely give it a try!

Basically, I thought that powering the system from USB would be useful only for ESP32 programming, so basically I can use a simple circuit with diodes to switch the USB->Battery voltage. I could then use some simple charging system, e.g. TP4056 or similar or the previously used IP5306, mainly due to the much more pleasant design and manual assembly. Basically, the problem of MAX17048 and its assembly remains, but at least there is no pad on the bottom side