Closed frozenmafia closed 3 months ago
Having 6 PZEMs on one line can sometimes be a bit demanding on the source pin of your RX/TX GPIO. Make sure the GPIO is able to source enough current to supply all the PZEM opto couplers. Also make sure the wire are not too long.
Having 6 PZEMs on one line can sometimes be a bit demanding on the source pin of your RX/TX GPIO. Make sure the GPIO is able to source enough current to supply all the PZEM opto couplers. Also make sure the wire are not too long.
Thanks for the update, Is their any diagram that I can refer ? And my wire are not long , max 15 cm long
Its hard to say without measuring, but the opto couplers are effectively LEDs that need to be driven all in parallel. If each takes 5mA to be driven an you have 6 PZEMs that's 30mA which might be more than the GPIO is able to provide. You may need to add a transistor that is able to source more current.
I am working on a project that involves using multiple PZEM-004T v3.0 modules to monitor AC power. The modules are connected as shown in the schematic below:
When I power on the AC supply, I can see readings for about 20 seconds before they all turn to nan. This issue does not occur when only one or two modules are connected. Below is an image of my actual setup:
Observations My ESP32 is powered from the USB. From the datasheet, the PZEM-004T has a TTL interface for communication and uses a UART to TTL communication interface with a baud rate of 9600, 8 bits, 1 stop bit, and no parity. When the readings turn to nan, the RX/TX LEDs blink intermittently. I suspect that this issue could be related to an inadequate power supply or communication collisions between the modules. I have read that adding a diode or making changes to the hardware might help resolve this issue. Code Here is the main part of my code where I take readings: PZEMMonitor.cpp
And this is the main loop: main.cpp
Request for Assistance Power Supply:
How can I ensure that the power supply is adequate for all connected modules? What are the steps to increase the power supply in the GPIO? Serial Communication:
Could the readings of all PZEM modules be colliding, and how can I prevent this? Is there a specific method to handle multiple PZEM modules to avoid data collision? Hardware Adjustments:
What are the best practices for adding diodes or resistors to stabilize the hardware setup? Could you provide links to articles or videos that explain these hardware modifications? Any guidance on how to resolve these issues would be greatly appreciated. This is the link to my schema if would be great if you could pin point any mistake.
@frozenmafia check this
I have gone through the link . What I could gather was to remove r4 and replace r8 with 470 ohm resistance I did the same . But I still get the same error . Is there a robust fix for this ?
Above is the image of the changes I made to module . Please pin point any thing I did wrong . Thanking you. I forgot to mention that for around 40 seconds when the board is started I am able to fetch the readings after around 60 seconds I am unable to fetch .
Possible workaround: Since you are using an ESP32 which has extra Serial interfaces, you could split the PZEMs between different once. Putting 2 on one interface, 3 on the other....
I removed one module , now I have four, these are working better, for some time I get nan, but after that it shows the reading. I think It confirms that the problem was with the current. I will try by providing external source.
Yes, either you use a transistor as @vortigont suggests, or you split to two Serial interfaces
@vortigont @mandulaj Thank you both for your support. I’ve ordered more modules and will conduct tests on them soon. I’ll be sure to keep you updated.
Hey @frozenmafia, is ther any update on this issue? Otherwise I will close it.
@mandulaj, I've started working with three modules, and they work like a charm. However, adding more than that is still causing same issues.
Cannot consistently read the values
To Reproduce Steps to reproduce the behavior:
Expected behavior There shall be no miss in data
Additional context Is this normal behaviour, as the values are missed 1 out of 6 times