Emonth2 upgrade problem

The FT232RL data sheet at

says the current consumption is 15mA typical, so 8.4mA is probably? reasonable.

The strange thing is that the Duracell alkaline battery data sheet quoted above says that to discharge a fresh cell to 0.8V in 12 hours, it takes an approximately 200mA constant current load?

Is it worth putting in a fresh set of batteries and see if anything gets warm/hot, as 3.3V x 200mA = 0.66W! The 0.66W has to go somewhere - perhaps the faulty component.

The emonTH2 schematic is at

and the board layout is at

I don’t know if this helps!

One unusual thing I have noticed on the schematic is that there are two regulators to provide +3.3V,
VREG (TOREX XC6206P332MR) provides +3.3V from +5V on the USB connector.
U1 (LTC3525ESC6-3.3) provides +3.3V from the battery.

Both regulators have their +3.3V output connected together. This means that when the emonTH2 is running on batteries using U1, the output of VREG is powered up while the input is not. This is a rather unusual configuration, and I don’t know if it causes any trouble? And vice versa?
The data sheet for VREG is at

and says ABSOLUTE MAXIMUM RATINGS: VOUT = -0.3 to VIN + 0.3 V
but VIN is not connected if the USB connector is not used. The block diagram shows a parasitic diode that will bias up VIN to (3.3V - 0.6V), so perhaps all is OK? I guess plenty of emonTH2s have been sold, so this doesn’t seem to be a major problem, Perhaps @glyn.hudson could comment.

1 Like

Apologies, I need to catch up on this but wont get a chance to dive in today. I do have a number of emonTH2 nodes in my own house all running the latest LowPowerLabs firmware. One seems to have been running for 3 years now, the others started with lower batteries and have had one replacement in that period, a couple now at 1.5 years and counting.

We’re not aware of a wider emonTH2 issue at the moment, plenty being sold as part of the emonHP bundle that are all giving decent lifespans as far as Im aware.

There have been issues with stuck firmware in the past, the LED will be on continuously and that does drain the battery fast. A power cycle or upload of firmware again usually sorts it.

Checking for warm components or the LED stuck on without a periodic dim flash is where I would start…but you have probably covered this in the thread already?

I’ve tried about everything. LED seems ok. It comes on at power up for about 15 seconds and then goes off. Reflashed firmware a couple of times. No visible problems and nothing heating up on the board. My current draws are listed in previous messages. All worked fine for several years and then started eating batteries—last set lasted about one day (see graph below).

The software was reloaded early on. The fault persisted.

This has not been mentioned.

@rupert suggested this less than 24 hours ago.

If you want, you can download Eagle CAD and get the .brd and .sch versions of the PCB files (as distinct from the .png images), which might make it easier to view them. (i.e. Clicking the ‘eye’ (Show) icon top left on both files means that clicking on a wire on the schematic will light up the track on the board, and vice-versa.)

I can only suggest some lower level troubleshooting with a DVM and/or an oscilloscope.

Also, when feeling for heat, remember that there are some components underneath the battery holder, including the 3.3V regulators!

Beyond that it’s difficult because you can’t disconnect the 3.3V rail from the individual parts of the circuit without cutting tracks or removing parts!. I don’t know if that’s something you want to get into!

Even then, will it be possible to do anything about it? Unless you have the tools, equipment and skills to rework the p.c.b. and replace parts, I’d suggest the answer is no.

Looking at the 3.3 V tracks, the width varies along the length so it would be necessary to know the width and then measure the voltage at two points a carefully calculated distance apart in order to know the resistance and hence from the voltage drop, the current. And this assumes there’s enough track accessible to give enough voltage to measure, even though you’re not too concerned about accuracy, given that the fault current is orders of magnitude more than the expected current.

If somebody’s never done it before, it’s a big learning curve.

Thanks, everyone, your help is much appreciated. I will end this here as my expertise is limited and I see no possibility of repair. This should in no way be a reflection on OpenEnergy and their products which are excellent. Problems happen, and this is no big deal. If I find an application near a power outlet then I will put the emonTH2 to good use.