12x S0 kWh-reader

[mmaes]

There are already quite some projects that use lightsensors to read the pulses from the kWh-meters.
I'm interested in directly reading the S0 pulses from the energy meters in my fusebox. When we remodelled our home in 2006 I had a 12-group fusebox installed, instead of the old 3-group. Later I installed energy meters (DMM Metering ADM1D V1.1) on 8 of the 12 groups, to be able to track energy consumption. Sadly the LCD's on the meters died.
Since the meters have got S0's, I am thinking about building an inputboard that could read out the meters and communicate with the Raspberry. However, I could use quite some help with this. (I do have a technical and IT background (and some Linux knowledge), and I've installed all electric wiring myself during the remodelling. But somehow I tend to get blue smoke whenever I get into electronics... )

So the help I'm looking for is the following:
- the circuit design for the interface board between the RaspPi and the meters (using I2C);
- a safe way to provide the energy meters with the requested power;
- and probably some help on the code...

What my basic plan is:
- provide 8 (possibly 12) meters with the requested power for S0-pulses;
- this circuit should be decoupled from the Raspberry's internal circuit (and knowing myself it should provide for the needed safeties... ) ;
- have the Raspberry count and timestamp the pulses of 8 (posssibly 12) meters;
- send the data to a database on one of my NAS'es (probably a MySQL on the Thecus);
- make a web-frontend on the NAS that shows power consumption on the various groups.
That's all...

These projects I've found that provide good startingpoints are:

• The GPIO board from UT Electronics
• The opto-coupled inputboard from ERE
• The 12V-5V stepdown converter from Roman Black

I have already set out some design thoughts on my own site.

To give you some extra info, here is the literal information on the S0-pulses from the ADM manual (yes, it's Chinese):

The ADM1D DIN rail energy meter is equipped with a pulse output which is fully separated from the inside circuit. That generates pulses in proportion to the measured energy for remote reading purposes and accuracy testing. The pulse output is a polarity dependant, passive transistor output requiring an external voltage source for correct operation. For this external voltage source, the voltage (Ui) should be 5-27V DC, and the maximum input current (Iimax) is 27mA DC. To connect the impulse output, connect 5-27V DC to connector 20 (anode), and the signal wire (S) to connector 21 (cathode). The meter pulses 2000 per kWh (0.5Wh/imp).

Any thoughts and help are welcome...

NB: this post was originally posted in a running thread, but I think it makes sense to create a new topic for it.

Thanks and regards in advance,
Marc

[techpaul]

I dont know which part of the world you are in so some of the items you need to do may be governed by local regulations I am not aware of. You seem to have ideas based on these parts look cool how can I make them work in this project. I suggest you do the following:-

First of all step away from the online catalogues

Second take a deep breath

Third now start looking at the design of the system then from that work out what you need in the way of parts and software.

You need to sit down and do some ROUGH calculations first, and check on what is happening at the meters and if the Pi can keep up. You have 8 to 12 pulse sources are pulsing at random times to each other and you want to capture amount of power (not necessarily every pulse).

You need to try and see what this pulse output looks like with a TEST setup on ONE meter and preferably on a scope, with some idea of what load is on that mains power circuit.

You need to work out worst case situation of each meter running at its fastest output rate at the same time and could a software solution keep up with it. On the Pi due to system not being real time I doubt it very much that you could gurantee to catch pulse or handle 12 different interrupts.

On one At 1kWh load you get 2000 pulses which would be in an hour, which is one pulse every 1.8 seconds. With 12 you would get at best case they all come at different time 1 every 0.15second (150ms), worst case some come at the same or near same time and you need to guarantee processing them.

Personally consider worst case of what mak load for the heaviest circuit (air conditioning, stove, water immersion heater) which is probably 10kW, then size each monitoring solution as if all of them had that as the fastetst impulse rate. Therefore you will get each monitoring output producing pulses at 1 pulse every 0.18 seconds (180ms) for 12 of them that is a pulse every 15ms.

So under heavy load how are you going to measure the pulses with the Pi?

I would consider a micro (or several) with internal 16 bit counters that could be read and reset every 15 to 30 seconds, and send the resulting count of pluses over a time period to the Pi to collate and time stamp.This could be sent using UART or I2C or SPI or whatever depending on what is easiest for the system design.

That is just a basic overview, until you know more of what the whole system is trying to do and what each part is actually doing dont look at components. Once you know the requirements for each subsystem then get the components for that subsystem.


If we have

[mmaes]

Hello Paul,

Thanks for your reply. You mention valid points. To answer some:
I live in the Netherlands. As far as I'm aware of, no changes are allowed up to and to the main meter. Changes to the fuse box are advised to be carried out by an expert, both for safety and insurance reasons. I'm planning to have an expert hook up the wires to the S0's and bring them to a connection block outside the fusebox (and also install some extra kWh-meters). From there on, I guess I'm okay. (Maybe there are some Dutch experts on the board that can advise on this?)

Indeed I should have done some calculations. Below (table 1) I've included some meter readings to get some idea of actual usage:


This does off course not provide a snapshot at any given time.
I also checked some equipment. The microwave is rated 1450W, the dishwasher is 2100W. In the table below are some readings per group (same period as above). In the lower columns I've been doing some fiddling with numbers that require explanation.

Table 1 shows a highest average around 21kWh/day. So let's take 30kWh/day as a design goal. That would mean 60.000 impulses per day.
In table 2 I've added the number peak-hours per group per day. This was done to reflect that usage is not evenly spread out over the day, but can be generated in a short period (f.i. dryer, microwave). The number of pulses per second over the groups gives some idea of the likeliness of pulse "collisions".
Of course, the mere number of groups increases the likeliness.

Anyway, I understand your suggestion towards a PIC. On the other hand, I don't own the necessary equipment nor the experience with these. I've done some assembler and microprocessor programming "back in the old days", but I was hoping to be able to tackle this more simply.
For instance, the PCF8583/DS1678/DS1672/DS1682/Ramtron FM6124 (EOL?) are pure event counters. Hard to find, however.

Another idea could be to add D-FlipFlops to the design, which would function as a simple buffer before the GPIO. It would only buffer one pulse (per group) while the GPIO/Raspi is busy, but ok. Then use another GPIO as a reset for the flip flops.


Would again like to hear your feedback (or have some good pointers towards your PIC solution...).

Regards,
Marc

[techpaul]

Hello Paul,
....Table 1 shows a highest average around 21kWh/day. So let's take 30kWh/day as a design goal. That would mean 60.000 impulses per day.
In table 2 I've added the number peak-hours per group per day. This was done to reflect that usage is not evenly spread out over the day, but can be generated in a short period (f.i. dryer, microwave). The number of pulses per second over the groups gives some idea of the likeliness of pulse "collisions".
Of course, the mere number of groups increases the likeliness.

Your main problem is you have up to 12 asynchronous clock pulses going into your programme that is asynchronous and has non-deterministic excution time due to the OS. Then asynchronous nature of comms and delays in drivers will not help. So doing anything to try and synchronise with the Pi is asking for trouble. Synchronise externally and buffer results to send to Pi.

Anyway, I understand your suggestion towards a PIC. On the other hand, I don't own the necessary equipment nor the experience with these. I've done some assembler and microprocessor programming "back in the old days", but I was hoping to be able to tackle this more simply.

I said micro not PIC, most of which are nightmare. Even though the overall application is slow it needs dedicated counters for each pulse input. These counters need synchronising hardware to read counters when there is NOT an external pulse, better if they do not reset so that way you do not miss a pulse potentially on every read.

For instance, the PCF8583/DS1678/DS1672/DS1682/Ramtron FM6124 (EOL?) are pure event counters. Hard to find, however.

I am currently design with a CHEAP 32 bit ARM LM3S808, which has 3 x 32 bit counters which can be configured as 6 x 16 bit can run internally at 200MHz off a much lower crystal. Has SPI/I2C and UART comms as well as many other features. Development kit with a micro to use around 40 pounds from Farnell/RS with Gnu C/C++ coimpiler and IDE (go for Codesourcery version) with debugging capabilities eg EKC-LM3S811 ( Farnell 1712244). Has connector so you can debug your target board. So two micros from this range would do all your requirements and more in a predictable manner.

The eval kit would allow you to test the principle without building extra boards with micros on and get your code going. Stick to high level language and use hardware capabilities not software for this sort of counting.

Another idea could be to add D-FlipFlops to the design, which would function as a simple buffer before the GPIO. It would only buffer one pulse (per group) while the GPIO/Raspi is busy, but ok. Then use another GPIO as a reset for the flip flops.

When you consider the delays of thread execution for your programme, I2C delays to read then write to 16 bit I2C latches, then your code execution time (which may be variable due to scheduling exagarrated by I2C I/O delays), you will miss so many collisions and pulses let alone clear latches when you should not or too late to miss pulses, it will be unreliable.

This type of counting needs to be atomic in structure such that reading it will not affect that or next result. Depending on lengths of pulses and gaps you could miss several.

You need external counters, and the results read back to Pi, keep the time critical stuff ouit of Pi and just send bunches of results to Pi.

That is why a lot of energy meters do counting internally and only send serial or USB data out in a does not matter if delayed manner.

[techpaul]

Forgot to mention the one off cost of the micro I am using is under 4 pounds plus VAT so a cheap component for

• 32bit ARM Cortex M3,
• 50MHz direct drive, 200MHz with PLL,
• 64kB Flash, 8kB RAM,
• JTAG debug,
• 3 x 32bit timers (or 6 x 16 bit),
• 2 x UART,
• I2C,
• SPI,
• GPIO configurable as interupts,
• 8 channels of 10bit 500ksps A/D,
• internal DMA,
• watchdog

All I2C and SPI can be as master or slave.

[techpaul]

Done some quick calculations from the poor meter manual. You have to design each counting stage to cope with max possible load not what your current loads are.

Max current in device is 32A which at 230V gives approx 7360 W. Lets call that 7.5kW for head room.

In one hour (kWh units) that gives

• 7500 x 2000 pulses (per channel) = 15 million pulses an hour.
• or 250000 per minute
• or 4167 per second

For 12 channels that is tiotal of 50000 per second.

A 16 bit I2C read on the bus takes approx 67.5 micro seconds or just under 15000 per second. Assuming system will allow that many reads a second which it wont as other I/o will have schedule times like screen updates, USB, network etc...

For max pulses at separate times you cannot keep up and will miss loads of pulses.

On a 16 bit counter per channel you could count for 15 seconds and get a max counts of 62505 which is less than 65535. so you would not miss counts and you never reset count you monitor wraps in software.

So once every 15 seconds you send 12 16 bit numbers for the 12 counter values. So much less I/O processing and guaranteed accuracy.

[mmaes]

Hi Paul, you're up early...

Again, I appreciate the amount of work you're putting into this. And I assume you're totally right on the theory. However, I feel the ARM would be a complete overkill.

First of all, all groups have 16A fuses - so by following the meter-specs you would over-dimension by 100%. No problem, your calculation still stands - the values halve...
=> which hopefully allows for some lighter specs on the MCU's

Next, the goal of the "project" is to get some more insight into our usage (and have some fun along the way). I don't intend to use the data for professional or charging purposes (I might try to charge the kids, probably wouldn't get more than a hug anyway... ).
But you are (slowly ) convincing me that I will need a (couple of) MCU's the get the job done.
However - the ARM is out of the question. That would probably mean that I would abandon the project all together.

Do you (or anybody) have experience with the PIC16F1847 (or similar) in this respect?
I'm also curious why you're negative on the PIC's?

Again, thanks - might not totally follow you on your industrial-grade top-notch solution ( ) - but I do respect the insights you're providing.

Regards,
Marc

[techpaul]

Hi Paul, you're up early...

Nah very late to bed

Again, I appreciate the amount of work you're putting into this. And I assume you're totally right on the theory. However, I feel the ARM would be a complete overkill.

Vast majority of micros introduced even for small stuff these days is ARM often because of flexibility, ease of creatiung tools, power savings. That has been the case for nearly 10 years now. They are cheap, cheaper than a lot of 16 bit micros.
The ARMs quoted dont run at those speeds, those are the max speeds, I have run them at much lower clock rates.

The other ARM that could be considered overkill is the Pi itself (an ARM of different type), but its OS means everything becomes non-deterministic.

First of all, all groups have 16A fuses - so by following the meter-specs you would over-dimension by 100%. No problem, your calculation still stands - the values halve...
=> which hopefully allows for some lighter specs on the MCU's

Makes not much difference to the micro spec it is the timer/counters that matter. Anyway you should always design so that when used with that meter (if somebody else uses you thoughts for their own design even hobby) that it will work for all situations of that meter usage as it is what the meter can produce you must deal with. That is the mistake people make "I only normally have this so my system is written to cope with that, oh dear I cant recognise faults or a change however small makes it nigh on impossible to change system to match".

Next, the goal of the "project" is to get some more insight into our usage (and have some fun along the way). I don't intend to use the data for professional or charging purposes (I might try to charge the kids, probably wouldn't get more than a hug anyway... ).
But you are (slowly ) convincing me that I will need a (couple of) MCU's the get the job done.
However - the ARM is out of the question. That would probably mean that I would abandon the project all together.

Why? Less than £40 pounds setup cost to prove it works, with better compiler and debugger than a lot of smaller items. Even your time costs something.

Do you (or anybody) have experience with the PIC16F1847 (or similar) in this respect?
I'm also curious why you're negative on the PIC's?

If you like assembly and want to spend ages writing in assembler then fine. Writing in higher level languages is quicker and easier than lower level languages. The PICs are not very fast at computation as the amount of machine instructions and paging slows things down. Dont even get me on many having short stack depth so code gets overly complex as you have so few stack locations for parameters and depths of function calls. More globals means longer to debug.
I find the memory mapping/paging obtuse and makes high level language support difficult. Often the peripherals are awkward to use, working with large numbers (often > 8 or even >12 bits) involves contortions.

90% of time I have seen a PIC used to do something, it is because the designer ONLY knows PIC and could be done cheaper, quicker and often at lower power with other micros. Especially if you code in high levelk lamguages. I have seen commercial projects flounder because someone insists on using PIC in assembler and get 6-9 month overruns.

The amount of integrated peripherals helps with reducing component count and ease of assembly.

Again, thanks - might not totally follow you on your industrial-grade top-notch solution ( ) - but I do respect the insights you're providing.

Regards,
Marc

You have a lot of events going on that need processing, several bits of buffering.

[techpaul]

I also think that the PIC16F1847 is a bad choice as you will end up using a weird internal timers and soiftware construct to get more than one counter for one input going.

The device is aimed at control functions to drive complex timing chains.

You need a part with lots of timers that can each be configured to count using external clock source

[mmaes]

ok, any suggestions (from the PIC-family )?

Some further data: the main fuse is 40A, the group-fuses are 16A.
Let's say that I don't care what the meter-specs say (you're right, they're Chinese ), it's just one of the components in a system. 16A per group is max. The system needs to be able to read 16A of data coming from a group (although in our household, I really don't see any of the groups doing more than 12A at any given time. Our dryer is 2600W, so 12A at 220V and it is our winner so to say. Using 16A as max gives enough margin). Even if we run the microwave, washer, dishwasher at the same time while watching surround TV, we can't top 40A. (If we would, I don't want a logger - I would want an alarm ).
Off course, any one group could (theorethically) use 16A. But please keep in mind that most households will probably be maxed out at 32A. And yes, it only has to function here. If it serves anybody else - that's nice and I'm willing to share code and design.

So that's the design-criterium: per group 16A max, total system 40A max. Overall usage must be aimed at a regular (private) household (we truly -happily- don't use 40A normally).

I would like to get this thing going, so I would really be helped with some concrete design ideas. I'm not afraid of programming, not even assembler. However, the technical design needs to be simple, as I'm not an electronics engineer. Preferably I wouldn't need to get a printed PCB and just 'simple' components. And I'm not looking for stuff with a steep learning curve or pre-investments, because it will likely be a one-off. So there's the 'project-scope'.

Now let's say we would divide the 12 groups in blocks of three or four. Each to be serviced by their own 'capture-device' (no ARM - PDIP, it's a hobby-project). The readers need to be decoupled from the reading circuit (which is 12V). Opto-coupler? Which one? Circuit?
The pulses need to be captured by the/a device. Again, 16A/group max, 3-4 groups per device. What device (no ARM), preferably PIC. Circuit?
Integration of a RTC (which also needs to provide date/cal to Raspi) on the board, and communication between board and Raspi preferably needs to be isolated from the Raspi. (Ah yes, the Raspi is ARM too. I just like running Linux... ).
Components / circuits? I think these are basically the questions.

I2C is not a necessity, could be SPI as well - which ever fits best. (Slight preference for I2C - but that is just because I already bought some components... ).

Regards,
Marc

[techpaul]

ok, any suggestions (from the PIC-family )?

You need one with at least 3 x 16 bit counters or timers that can act as counters.

Some further data: the main fuse is 40A, the group-fuses are 16A.
Let's say that I don't care what the meter-specs say (you're right, they're Chinese ), it's just one of the components in a system. 16A per group is max. The system needs to be able to read 16A of data coming from a group (although in our household, I really don't see any of the groups doing more than 12A at any given time. Our dryer is 2600W, so 12A at 220V and it is our winner so to say. Using 16A as max gives enough margin). Even if we run the microwave, washer, dishwasher at the same time while watching surround TV, we can't top 40A. (If we would, I don't want a logger - I would want an alarm ).
Off course, any one group could (theorethically) use 16A. But please keep in mind that most households will probably be maxed out at 32A. And yes, it only has to function here. If it serves anybody else - that's nice and I'm willing to share code and design.

Private residences in UK have the electricity supply fuse of 60A or 100A depending on age of installation.

So that's the design-criterium: per group 16A max, total system 40A max. Overall usage must be aimed at a regular (private) household (we truly -happily- don't use 40A normally).

Hmm many UK households have 32A ring mains for sockets.

I would like to get this thing going, so I would really be helped with some concrete design ideas. I'm not afraid of programming, not even assembler. However, the technical design needs to be simple, as I'm not an electronics engineer. Preferably I wouldn't need to get a printed PCB and just 'simple' components. And I'm not looking for stuff with a steep learning curve or pre-investments, because it will likely be a one-off. So there's the 'project-scope'.

Lets see you take 5V from Pi or other source (connect grounds of supplies if you use another one) to '+' pin 20 of each meter, take the pin 21's to a small board, which has a 1k resistor to ground on each separate signal, possibly add a buffer chip to protect the rest so it blows first.

Take the outputs of the buffer (or non grounded end of resistors) to counter clock inputs.

Excluding the counters the counters that could all go on a stripboard or breadboard easily. Very simple circuit.

Now let's say we would divide the 12 groups in blocks of three or four. Each to be serviced by their own 'capture-device' (no ARM - PDIP, it's a hobby-project). The readers need to be decoupled from the reading circuit (which is 12V).

The spec says you can use 5-27V DC why 12V and make life difficult? Just use a larger 5V PSU to power your extra board(s) and the Pi and keep things simple.

They say the SO output it is isolated, as it probably is a 30V FET or opto isolator transistro o/p

Opto-coupler? Which one? Circuit?

I would just put them through a buffer chip like 74*245 set for one direction.

The pulses need to be captured by the/a device. Again, 16A/group max, 3-4 groups per device. What device (no ARM), preferably PIC. Circuit?

I suggest you look on PIC site for suitable device with multiple counters, if you use a device with small number of counters, you comms handling and syncing with multiple devices will become arduous.

Integration of a RTC (which also needs to provide date/cal to Raspi) on the board, and communication between board and Raspi preferably needs to be isolated from the Raspi. (Ah yes, the Raspi is ARM too. I just like running Linux... ).
Components / circuits? I think these are basically the questions.

There are plenty of I2C RTC chips a battery, a diode a cap, a crystal can all be mounted on strip/bread board. The only possible place you need protection is the meter end, if all the grounds are tied together you dont need anymore.

I2C is not a necessity, could be SPI as well - which ever fits best. (Slight preference for I2C - but that is just because I already bought some components... ).

Regards,
Marc

If you limit all components to be PIC and PDIP you have less components to look at. Lots of eval boards have connections on 0.1inch spacings so with components specced above

• larger psu
• strip/bread board
• 12 x 1k resistors
• couple of logic buffers

You have cheap parts to add to whatever micro and its 0.1inch spaced components. This is still hobbyist realm.

A board like I suggested could be added to that so about 50-60 pounds in total plus wires to cope with 6 channels inclduing development tools, and then see if you want to expand to 12 channels.

I think you will find restricting yourself to PIC and PDIP for everything will make it a hard task - time wise, board size and comms handling. I doubt anything less than PIC18 or PIC24 will have 3 or more timers that can act as counters, increasing cost of parts and board area (size of components), you may have to got dsPIC32. So far a quick search on microchip suggests that everything with 3 or more 16 bit counters is only available in TQFP surface mount. You will need to check a lot of datasheets as 16 bit counter is not a selection item as they assume timers are used for internal purposes or for driving outputs mainly.

Try this page as starting point http://www.microchip.com/maps/microcontroller.aspx

So to get your 12 counters will need multiple chips you probably want to synchronise on reading counters.

[mmaes]

Hi Paul,
You're right, they make an awful lot of these PIC's. But I think I found something useful: the PIC18F27J13.
Some relevant specs:

• Peripheral Pin Select for mapping digital peripherals to various I/O for design flexibility
• 7 Capture / Compare / PWM modules (of which 3 Enhanced)
• Timers 4 x 8-bit, 4 x 16-bit
• Hardware RTCC provides clock, calendar & alarm functions
• 2 MSSP serial ports for SPI or I2C™ communication
• Program Memory 128 KB flash, RAM 3,800 Bytes
• CPU Speed 12 MIPS
• Operating voltage 2.0 - 3.6V, 5.5V tolerant digital inputs
• 28 pin package (also PDIP)

[/size]
Now the interesting stuff are the capture-modules. They can register pulses, and store a (selectable) timer-value in a fifo-buffer on event. Now these modules are configurable, so you can set them to act on every 2nd or 4th event - for instance. Also, they create interrupts - which are configurable as well (like an interrupt on every 2nd or 3rd event). This way, I figure I would have a scalable way to keep the processor load down on the heavier fuse-groups. The only thing that is bit a bit sad, is that the capture-modules can not be configured to capture the value of timer 1 - which is the real time clock. Otherwise, event-logging would have been a breeze. Now it will require a small bit of coding.
There are 7 capture-modules on the chip, so I will need two chips. Whenever an event (pulse) occurs, a software-interrupt needs to be called that registers the value of the RTC and stores it in RAM (along with the pin-number that generated the event). Since there's about 3.5k of RAM available, the PIC's have some room for logging of the 6 groups (12/2) before they need to be read/cleared by the Raspberry.
The PIC's run on 3V3, so that will require a step-down converter (probably a linear converter would do?).

By the way, there are two reasons for split voltage on the circuit: first - most meters (including two I own) require 12-27V instead of 5-27V. They would probably work with 5V (I've tested my Swissnox with 9V which worked just fine), but I think 12V would be a safer bet. This does make the opto-couplers necessary, though.
Secondly, I found an adapter that provides 12V/2A-5V/A and has this typical adapter that is also used on harddisks (that was what the adapter was meant for...). So it would fit the job perfectly, I think.

As for the I2C-buffer: basically the same as the opto's on the input - makes me feel better. Besides I've already got one...

I'm interested in your opinion on the PIC's.

Regards,
Marc

[techpaul]

Hi Paul,
You're right, they make an awful lot of these PIC's. But I think I found something useful: the PIC18F27J13.
...

Interesting from data sheet at rough count you need 3 of them more later

Now the interesting stuff are the capture-modules. They can register pulses, and store a (selectable) timer-value in a fifo-buffer on event. Now these modules are configurable, so you can set them to act on every 2nd or 4th event - for instance. Also, they create interrupts - which are configurable as well (like an interrupt on every 2nd or 3rd event). This way, I figure I would have a scalable way to keep the processor load down on the heavier fuse-groups. The only thing that is bit a bit sad, is that the capture-modules can not be configured to capture the value of timer 1 - which is the real time clock. Otherwise, event-logging would have been a breeze. Now it will require a small bit of coding.

The capture mode captures the amount of cpu clock related cycles that has elapsed in timer n, which is good for measuing if things happen at right time (good for motor control feedback). However what you need is timers that act as counters of external pulses not related to cpu clock. You are not worried how long the pulse is or when the pulse occured, just how many of them within an 'n' second period.

Looking at datasheet Timer 0, Timer 1 and timer 3/5 can act as 16 bit counters of external clock pulses. Which gives 4 counters per chip.

Use other counters like RTC to every 'n' seconds read all the counters and store them in buffer for one event. Use one CPU as master to trigger others to read theirs at same time, (the amount of latency wont matter if one output interupts two others). That way any blocks of data read by Pi are always 'n' second sgements, even if it receives several blocks it knows each block si the same 'n' seconds apart.

There are 7 capture-modules on the chip, so I will need two chips. Whenever an event (pulse) occurs, a software-interrupt needs to be called that registers the value of the RTC and stores it in RAM (along with the pin-number that generated the event). Since there's about 3.5k of RAM available, the PIC's have some room for logging of the 6 groups (12/2) before they need to be read/cleared by the Raspberry.

If you use captures you will log a LOT of events for how many CPU clock counts since last pulse, which on a low load means the counter will overflow many times, basically you are logging every single pulse which with a time stamp is a lot of data.

The PIC's run on 3V3, so that will require a step-down converter (probably a linear converter would do?).

A lot of stuff these days runs on 3V3 or lower (1V8 is now quite common), a linear regulator from 5V would be fine make sure it specced right for total current and power dissipated. From 12V I would use a cheap small DC/DC converter maybe one to provide 5V as easily available, they waste a lot HEAT in doing the conversion.

By the way, there are two reasons for split voltage on the circuit: first - most meters (including two I own) require 12-27V instead of 5-27V. They would probably work with 5V (I've tested my Swissnox with 9V which worked just fine), but I think 12V would be a safer bet. This does make the opto-couplers necessary, though.

Jjust feed the output from the meters into a resistor divider to drop the voltage to 3V3, you have control over the 12V rail.

Secondly, I found an adapter that provides 12V/2A-5V/A and has this typical adapter that is also used on harddisks (that was what the adapter was meant for...). So it would fit the job perfectly, I think.

Provding both that way is a good idea and then do linear regulator Low Dropout Type (LDO) like LM1117-3.3 to give 3V3.

As for the I2C-buffer: basically the same as the opto's on the input - makes me feel better. Besides I've already got one...

Actually with 3V3 PIC just connect them up pullups already on Pi end and connect all the 0V/GND together.

I'm interested in your opinion on the PIC's.

Looks like they could do the job but you would need 3 of them in my opinion.

[p4trykx]

You could also use 1-wire double counter DS2423. The chips is discontinued however it's still available as a assembled board
http://www.hobby-boards.com/store/produ ... unter.html
or just a chip.
There is also a attiny25 implementation http://www.tm3d.de/index.php/1-wire-device-mit-avr
I'm using it for counting water usage so it's not so fast as electricity.

On the Raspi side you could use some 1-wire i2c master like DS2482-100 it's also cheap. Maybe even some 1-wire over GPIO will work.

[ksangeelee]

Max current in device is 32A which at 230V gives approx 7360 W. Lets call that 7.5kW for head room.

In one hour (kWh units) that gives

• 7500 x 2000 pulses (per channel) = 15 million pulses an hour.
• or 250000 per minute
• or 4167 per second

For 12 channels that is total of 50000 per second.

That should be 7.5 x 2000, since the S0 gives 2000 pulses per kWh, so an average of 4.17 pulses per second ((7.5 x 2000) / 3600). That gives a processing requirement of either 50 or 25 pulses per second, depending on whether one device (of 12 inputs) or two devices (of 6 inputs) are being used to count.

In this light, I'd use a single PIC, and simply poll PORTA and PORTB pins for changes. The I2C interface can be used to get the counter values at any given time (maintained by the PIC18F27J13 RTC, perhaps sent with the counter data).

[techpaul]

Max current in device is 32A which at 230V gives approx 7360 W. Lets call that 7.5kW for head room.

In one hour (kWh units) that gives

• 7500 x 2000 pulses (per channel) = 15 million pulses an hour.
• or 250000 per minute
• or 4167 per second

For 12 channels that is total of 50000 per second.

That should be 7.5 x 2000, since the S0 gives 2000 pulses per kWh, so an average of 4.17 pulses per second ((7.5 x 2000) / 3600).

Which is what is up above. what is wrong is 50 not 50000 late night typing and missed decimal point.

That gives a processing requirement of either 50 or 25 pulses per second, depending on whether one device (of 12 inputs) or two devices (of 6 inputs) are being used to count.[

In this light, I'd use a single PIC, and simply poll PORTA and PORTB pins for changes. The I2C interface can be used to get the counter values at any given time (maintained by the PIC18F27J13 RTC, perhaps sent with the counter data).

It needs some form of counters in an external micro of any sort. Time stamping is not really relevant if you regularly read each block of data consists of counter samples at 'n' seconds apart. A timestamp every hour could be helpful to synchronise times.

[ksangeelee]

Time stamping is not really relevant if you regularly read each block of data consists of counter samples at 'n' seconds apart. A timestamp every hour could be helpful to synchronise times.

Yes, in fact simply having the pulse-counts per channel at the current time is enough - then the software on the Raspberry Pi can decide how often to take readings and calculate changes. Which would make me tend towards sending the time with the counters - it can always be ignored in favour of the system time or some other timer if more accuracy was required.

[techpaul]

Time stamping is not really relevant if you regularly read each block of data consists of counter samples at 'n' seconds apart. A timestamp every hour could be helpful to synchronise times.

Yes, in fact simply having the pulse-counts per channel at the current time is enough - then the software on the Raspberry Pi can decide how often to take readings and calculate changes. Which would make me tend towards sending the time with the counters - it can always be ignored in favour of the system time or some other timer if more accuracy was required.

If you send data serially (not I2C/SPI) so when you have a block of data buufered you know it is 'n' seconds after the previous block, time stamping is irrelevant, only in local system.

Keeping multiple RTCs in sync to whatever resolution is a pain, as soon as you read a time value it is ingerently stale and depending on overheads and levels of software involved lags real time. Time stamping to 'n' seconds +/- 0.5 seconds by the Pi itself is sufficient, as you are looking at time spreads

If you were to take samples of a sine wave, knowing how far apart the samples are is the most important factor, however you graph it knowing the sampling distance is the most important factor.

[ksangeelee]

I think I found something useful: the PIC18F27J13...

...I'm interested in your opinion on the PIC's.

The 18F27J13 is probably over-specified for what you need, but at £2.50 for a one-off project, who cares? I recommend you get a PicKit3 rather than PicKit2 programmer - otherwise you'd need to hack the PicKit2 configuration a bit to make it recognise that chip.

If you're comfortable programming in C, then Hi-Tech and C18 compilers have free versions (with limited optimisation) that make programming a lot less tedious than using assembly. There are probably other free compilers. Expect a learning curve, whatever MCU/compiler/IDE you choose.

The power consumption of these chips is tiny - even at 8MHz fully on, you'll draw about 1mA, so a simple battery backup (e.g. 2 x AA) is feasible for maintaining state during power-cuts, for example.

[mmaes]

Hmm, I didn't notice the miscalculation either - although I did have a feeling that we were over-dimensioning a little... factor 1000 - ay.

Would that mean that my original idea (see this link on my own website) should work as well?

Anyway, I've already ordered two PIC18F27J13's, so maybe I can try both solutions.

Regards, Marc

[techpaul]

Hmm, I didn't notice the miscalculation either - although I did have a feeling that we were over-dimensioning a little... factor 1000 - ay.

Would that mean that my original idea (see this link on my own website) should work as well?

Anyway, I've already ordered two PIC18F27J13's, so maybe I can try both solutions.

Regards, Marc

No the Pi is not deterministic enough to guarantee when it will read, the I2C delay adds time. You need to take external asynchrous events and capture them. Depending on what Pi is doing you could miss pulses under various load conditions, repeatedly.

Much easier to trim data down by having external means of counting the multiple asynchronous pulse streams into simplified counters, which can be buffered then the Pi can catch up whenever. So when it writes to database or does other activities that take time, they do not affect your data capture.

This is true of any non-real time operating system, even real time have limits on data throughputs and latencies.

By the way dont be afraid to use plain old UART comms, which has advantage that your counters can PUSH results when they have them to be buffered by Linux driver for reading, no polling to see if results there and then grab results. Just make sure you have a packet structure for the results meaning you can tell where a packet starts and a packet ends. This can be as simple as sending ASCII numbers and ending with LF character

[techpaul]

As to time stamping consider the analogy of the electricty company reading your power meter, they only worry about when they take a copy of the counter on the meter, they are not worried when each counter change occured.

Like wise you actually do not need much time stamping do it on the Pi it has the date manipulation capabilities.

Also consider as someone else said that the micros and their counters runs all the time, even if Pi turned off.

[ksangeelee]

Anyway, I've already ordered two PIC18F27J13's, so maybe I can try both solutions.

I assume one solution is to use a PIC to count pulses and feed counters to the Pi on demand. What's the other solution you had in mind?

I'd be tempted to use the Raspberry Pi directly for this - check out the weather station project that I wrote up on my blog - the code's a bit messy, but there are bits you could lift directly.

I was reliably differentiating pulses of 0.5ms, 1ms, and 1.5ms just by sampling a GPIO pin and at 100us intervals (or something like that). You should easily be able to sample at, for example, 5ms intervals to catch 50ms pulses. There are situations where I'd lose a packet but they are surprisingly rare (and may, in any case, have been down to RF interference).

At the very least, you can get your algorithms sorted out on the Pi before porting to your PIC (which would be doing more or less the same thing). The PIC approach feels like a good balance - an RTC to maintain the most applicable time reference for the list of counters, it can continue to operate independently of the Pi, simple battery backup - you could even broadcast using RF to remove the Pi from the distribution box - a couple of SmartAlpha modules from RF Solutions would be a breeze to implement, since they're driven entirely from the UART.

[ksangeelee]

As to time stamping consider the analogy of the electricty company reading your power meter, they only worry about when they take a copy of the counter on the meter, they are not worried when each counter change occurred.

I'm not sure anyone's thinking about time-stamping every pulse - the only timestamp that's needed is the one that relates to when the readings are taken - e.g. when the counters are read from the microcontroller. So, counter1 is 10000 at 12:34:56, and 10035 at 12:34:59, so 35 x 0.5Wh in 3s.

The comms latency is negligible in this application, so the reference clock could be either the sender (microcontroller) or receiver (Pi). The benefit of having an RTC local to the microcontroller is that it could be used to buffer up reads during times that the Pi is not reading (disconnected, being upgraded, crashed, corrupted SD card, etc.).

With all the RAM available on the PIC18F27J13 (and spare flash memory too), the firmware could be written to buffer data (in { time, counter[12] } tuples) if it hasn't been read for a specified period of time. Then, when the Pi finally consumes the buffered data, it will have a record of the counter values at the given time intervals while it was offline.

[techpaul]

I assume one solution is to use a PIC to count pulses and feed counters to the Pi on demand. What's the other solution you had in mind?

I'd be tempted to use the Raspberry Pi directly for this - check out the weather station project that I wrote up on my blog - the code's a bit messy, but there are bits you could lift directly.

I was reliably differentiating pulses of 0.5ms, 1ms, and 1.5ms just by sampling a GPIO pin and at 100us intervals (or something like that). You should easily be able to sample at, for example, 5ms intervals to catch 50ms pulses. There are situations where I'd lose a packet but they are surprisingly rare (and may, in any case, have been down to RF interference).

Using no doubt one input directly on GPIO, this other method is up to 12 inputs asynchronously via an I2C 16 bit port.