Computing stuff tied to the physical world

P1 revisited

In Hardware on Jan 13, 2013 at 00:01

The P1 port connection I set up recently for picking up data from the utility company’s smart meter isn’t working reliably yet, so I dove a bit deeper into it.

Here’s how I now think the P1 interface is implemented inside that smart meter:

JC's Grid, page 59

There’s no way to ascertain whether a PNP or NPN transistor is used, without opening the box (impossible without breaking a seal, so definitely not an option!). But given that NPN is more common, the above circuit is my best guess.

The resistance was measured between the DATA and GND pin. The resistance between DATA and REQUEST is usually over 1 MΩ, which indicates that the phototransistor is open. Makes sense: pull the data low regardless of the REQUEST line state, and pull it high when the internal IR LED in that optocoupler is lit. That also explains the awkward inverted TTL logic levels provided by this interface.

What you can see is that the REQUEST line is really nothing but the power supply to the isolated side of the optocoupler. But the surprise is the value of that pulldown resistor!

Let’s do the math: when REQUEST is 5V, and the phototransistor is conducting, it’ll have about a 0.2V collector-to-emitter voltage drop, leaving 4.8V to feed the 180 Ω resistor (I measured 4.75 V, so yeah, close enough).

Whoa… 4.8 V over 180 Ω is 26 mA, a pretty hefty current draw in µC terms!

My conclusions from all this are: there’s no external pull-up or pull-down needed after all, and my hunch is that it’ll work just as fine with REQUEST powered by 3.3V (reducing the current somewhat). All you have to make sure when working with this P1 interface, is that your REQUEST pin can supply those 25-odd milliamps.

If the above is accurate, then nothing forces us to actually use that resistor, by the way. We could simply connect the REQUEST and DATA pins and leave GND dangling. In fact, by re-using the phototransistor in a different way, one could even make it work in active-high mode again (only if no other P1 devices are connected, evidently).

Note that this is for the Landis & Gyr E350 (PDF) smart meter I have – others may differ!

  1. Deleted based on fresh information from Ronald v. Aalst

  2. Do you know this document?

    The Appendix seems to hint on the implementation of the circuit.

  3. If the interface follows the sketch shown in the above referenced document, it is more likely that REQUEST connects to the input side of an opto through a limiting R (spec suggests 5mA @ 5V) to GROUND. This is for the meter to detect a request for signalling data back to the requestor.

    DATA is then the open NPN collector of a corresponding output optocoupler. There may well be other protection components (reverse biased diodes etc) normally inactive.

    The good news is that with a reasonably sensitive REQUEST optocoupler (without a series forward biased diode that is sometimes used for protection), 3.3V from an I/O pin should be enough drive. The bad news is this is hard to make low power due to the need to turn on two optocoupler internal LED’s.

    Are Pins1/6 really n/c? The standard implies an isolated 5V supply presented there.

    • No 5V supply on my unit, alas. If the smart meter indeed uses REQUEST to turn on an LED, then all bets are off (would be easy to check – I could measure the current draw in idle state). But if it’s as I described above, one could use a very low current. feed, and even turn it on just part of the time, since reports are known to come in only once every 10 seconds.

  4. How about not connecting GND directly to your JN ground, but through a, say, 1kΩ resistor?

    Of course, if you decide to only use the REQ and DATA connections, it doesn’t really matter since you’ll be using a different pull-down resistor anyway.

Comments are closed.