Archived Forum

Try looking at Building Blocks - that's where the theory and example designs tend to be.

The probability is that you'll connect it to "something" that detects switch closures. What do you want to do then? The classic way is:

Switch => emonTx V3 => (radio link) => EmonBase (Rasperry Pi) => (Ethernet) => Your router => emoncms.org

which implies you have all that hardware. You can substitute a local hard disk atttached to the RPi instead of the web connection to emoncms.org, and in that case you'll run emoncms on your RPi. You can also substitute a wired link for the radio link, provided the two are close.

Thanks Robert

I already have 2 X EmonTx3 & RPi etc for monitoring electricity and Solar production/export etc.

I am not 100% clear on whether the required code is already in the EmonTx3 firmware or if I have to add it.

(I am sure some modification will be necessary though.) and also which pins to wire to?

I think a further battery powered emon Tx3 would be best in order to reduce the possibility of sparks??

although hard wiring to an existing mains powered one would be a cheaper option.

I have used arduino and github to alter node id's and to update firmare but I am not very confident with it.

Just looking for an idiots guide really. Most of the stuff I have found assumes more knowledge than I have unfortunately.

First, nothing here is intrinsically safe, so you must not have anything switching that might generate a spark in a gaseous atmosphere. However, there are no open contacts anywhere (not counting the plugs and sockets) nor should there be any gas escaping. So I don't think there is any cause for concern. 

You will need to add to the software in the emonTx V3, the default sketch only does electrical energy. The semi-idiots guide is  in Building Blocks http://openenergymonitor.org/emon/buildingblocks/introduction-to-pulse-c... Input Dig 2 is conveniently available on a screw terminal block, together with a supply connection for 3.3 V, and it already has a pull-down resistor fitted.

Provided your meter pulses are fairly long (and they will be), and you're not measuring electrical energy with emonLib, you don't need the interrupt code and you can simply 'poll' the input to look for it changing state. "Polling" means you put the code to check the input state "digitalRead(2)" inside the main loop and check it each time round the loop.

If you are doing current and voltage measurements as well, then you'll need to use the 'interrupt-driven' method (two pages also in Building Blocks).

All mechanical switches have a habit of bouncing as the contacts make and break, so if you're not careful you end up with many pulses were you really only have one. There are two ways to deal with this. In hardware, you can add a small capacitor from the input to ground, which acts as an integrator; Or you can do it in software, either with a software integrator or by waiting for the input to remain in the same state for a certain length of time before you recognise it as a pulse. There's no switch debouncing in the BB code.

Hi,

I have been monitoring my gas meter for several weeks with success. It works fine as my Emontx reports the exact index given by my meter. I'm using a software method to debounce the signal coming from the mechanical switch of my gas meter. More info here : http://openenergymonitor.org/emon/node/3954

I'm planning to use a RC circuit to debounce the signal using a hardware method because my software method monopolizes one of my Emontx ... It should work with a 10k resistor and a 0.1 mF capacitor. (T=RC=1s)

Eric

Eric - thanks for reminding me. I knew I'd seen a post about this recently.

But the time constant is 1 ms, not 1 s. I would have thought that a somewhat larger capacitor might be needed, but that depends on the properties of the reed switch. It might be a good idea to feed the reed switch through a small (say 470 Ω) resistor to limit the inrush current into the capacitor - that will reduce the disturbance on the power supply and it might prolong the life of the reed switch.

So forgive my ignorance. Are you saying that I need another Emontx3 to run this code or can it be added to one of my existing units? I have seen these various files in the Arduino sketches for the Emontx but have no idea really what each of them does. So I am not sure if I am using Emonlib or not. I just have the std as delivered fully built units. All I have done is to upgrade firmware and change Node id's

You should not need another emonTx, but you will need the interrupt-driven technique and you'll also need to learn how the sketches work so that you can merge them into one. And yes, you will be using emonLib - the default emonTx V3 sketch does use it.

The sketch that Eric published on 1/3/2014 does not use interrupts and for that you would need a separate emonTx.

The sketches you'd need to merge are the default one https://github.com/openenergymonitor/emonTxFirmware/tree/master/emonTxV3... and the pulse example https://github.com/openenergymonitor/emonTxFirmware/tree/master/emonTxV3... . If you're up to learning about the sketches and how they work, the Building Blocks section is where you'll find most if not all of the information you need. (But bear in mind most of that was written pre-emonTx V3, so pin numbers etc will be different. though the principles are unchanged.) If you're not confident that you can get it working, let me know and I'll try to find time to do a merge and test it, but I can't promise when that might be.

I'll have a look and see if I can work it out!

I may however need further help. Thanks for offering to do the merge. I may yet have to take you up on it!

SO In my Arduino libraries I have found a file called Emon_tx3_Pulse in the examples folder which is in the EmonTxfirmware/Emontx3/rfm12b/ folder.

Can't yet see how to or where to merge it though!

When we say "merge".... it isn't an automatic, or even semi-automatic, operation. What you have to do is look to see what each line does, whether you want it in the merged sketch, and if you do, copy it across into a suitable place. But sometimes, you'll find an almost equivalent line and you'll have to make it one - I'm thinking in particular about the Payload structure.

Thanks Robert. I had figured that much but I am pretty sure that I will mess this up! If you can find the time to have a look at it I would be most grateful

Here is my merge of the example Pulse sketch into the default Discrete Sampling sketch. I've added a contact debounce feature, the timer will need tweaking according to how good or how bad your reed switch is. I found I needed 0.5 s for a bit of tinned copper wire dabbed onto the screw terminal, but in most cases a much smaller time will be needed.

The usual disclaimer: it seems to work for me. Although I have not tested it for accuracy, I don't anticipate a problem, particularly if you comment out the line that calculates the power between pulses. This isn't very useful anyway, as that sum is better done in emoncms, and it does depend on the calorific value of your gas as well as the gas volume per pulse.

[Edit: It is impossible to satisfactorily debounce the input in software when it drives the interrupt. It can only be done in hardware. Therefore, I've taken out the faulty code that attempted to debounce the switch.]

Thanks Robert!

So I just look at the existing sketch and insert your code in the same place?

My Meter appears just to have a reed switch ie 2 wires that short at each rotation of the dial. Am I to connect 1 wire to the interrupt pin and one to 3.3v ? or to Gnd?

I am using an AC adapter on the Emontx this won't cause it a problem will it?

The wire will need to be pretty long to reach to my emon tx could this present any problems? approx 20m!

You load the sketch as you do any other. You can have only one sketch in the emonTx at any one time.

The connection instructions are in a comment in the sketch. I don't see that the ac adapter will affect the operation at all - I tested with that and the programmer supply connected [edit] and as expected it is happy also using just the ac supply[/edit]. Whether you get any pickup on 20 m of lead is debatable and depends very much on where the cable runs and how close it is to sources of interference. I suggest you use twin twisted screened cable (sold as 'microphone cable') using the two inner cores for the switch and earthing the screen only at the switch end.

Robert, I realise you were the merger, not the original author, but I think that ISR code needs some work, wherever it came from.  Most of those variables involved should be flagged as 'volatile' and even then this snippet is very problematic:

// Accumulate Pulses
emontx.pulses = pulseCount;
pulseCount=0;

There's the obvious race condition that a pulse could fire between those 2 statements, in which case it would be lost.  But on an 8-bit micro the problem is even worse.  Neither of those C statements are atomic even within themselves.  So if  the ISR fires halfway through shuffling bytes to satisfy this assignment:

emontx.pulses = pulseCount;

and that ISR increment involved a carry from one byte to the next, you'll get inconsistent results.

I suspect it's mostly working so far because pulseCount never gets bigger than 255, helped also by the debounce logic.

I now have a better grasp of what's going on having read some Arduino tutorials. Thank you Robert for your help and patience.

dBC. I think that there are a good few people interested in this code for reading gas/water meters etc accurately.

I am not able to understand the nuances of how/where errors might appear but I am blessed with plenty of time to experiment with new/modified code if people are prepared to make suggestions and my understanding will improve in leaps I hope!

Any suggestions welcome!

I have some issues installing what is going to be a long cable run but as long as it works I will get up and running asap

I agree. The general wisdom is that bouncy switch inputs should not go straight into interrupts in the first place, but should be polled. Also, the debounce - which I threw in quickly without too much thought - has a fault in the algorithm that means it counts double if the switch stays closed for longer than the debounce time. By far the safest is a hardware debounce. I'd also spotted that pulseCount was not declared volatile, there's floating point maths in the ISR, and interrupts need to be turned off to protect that race condition. You'll find the Pulse example on GitHub, and it certainly needs proper development.

I dunno, I hurry to try to help someone who on their own admission isn't sure of what they're doing, and I get hung for it.

I think that its all to easy when writing instead of speaking to appear somewhat harsh when its not meant at all. I think that it is great that this stuff is "open" and people with knowledge and skill can bounce ideas off each other leading to better and faster development.

I am going to investigate a hardware debounce system!

Robert, I certainly didn't mean it as a hanging, apologies if it came across that way.

webby, it's probably a bit of an overkill for your application but I've had a lot of joy with the MAX6818 device.  I need to count 8 pulse inputs, and it does all the debouncing in h/w,  throws in ESD protection, and gives me a nice interrupt when something has changed.  As I have 8 GPIO pins available,  it gives me all the events with a single cycle PORT read (done in the ISR).  I think Maxim might have some "narrower" devices, i.e. less than 8-bits wide, but I've not explored them.

Hi,

Robert's sketch can not work fine with my gas meter because it will create fake pulses. Actually, the signal coming from the reed switch is too noisy. Sometimes, its state changes twice very quickly (few microsec) without any gas consumption. (electronic interference ? magnetic weakness ? instability of the Vcc ?).

I didn't manage to filter those fake pulses using interrupts because some of my ISRs are ignored. In fact, those fake pulse seems to be too short to be filtered in software. Anyway, I agree it is better and safer to filter the signal in hardware.

Attached is the RC circuit I am planning to use to filter the signal. It should work with a 10k resistor and a 0.1 mF capacitor. According to me, the time constant (10⁴ * 10^-4 = 1 s) is fine as my reed switch operates slowly (not faster than every 6 seconds).

Robert, I don't understand why you told me that "the time constant is 1 ms, not 1 s". Is my calculation wrong ? (or yours ?) Do you mean I need a 1 ms time constant instead of a 1 s time constant ? It is not clear for me.

Eric

Eric: I think you are misunderstanding the markings on your capacitor.  50 years ago, capacitors were marked mF when they actually meant µF. As far as I know, that has not been the case for a very very long time now. If it was genuinely 0.1 mF, and manufactured within the last 40 years approximately, it would be marked 100 µF.  If you have that, when your reed switch closes, you will have a huge inrush of current (with your original circuit) that would cause the power supply to dip - and there is a possibility that it will burn or weld the reed switch contacts too. With today's circuit, the inrush is limited, of course. I think you have 0.1 µF (10^-7 F).

The time constant you need will depend on the mechanical properties of the switch - at what frequency it bounces, and that depends on the strength of the springs and of the magnet, and the weight of the moving parts. I would start with a time constant of a few tens of ms and see how it performs - 1 s I think is safe but excessive,

I recommend your hardware solution to Webby (in place of the software one!), but I would change the external 10 k resistor to say 1 k (to assure the 'high' input is adequately high) and choose a capacitor to give a TC of say 100 ms at most.

So a maxim 6816 is a single debouncer available at RS. However I think that it is v small and still needs a 0.1 mcrofarad capacitor so I guess a v small circuit board is required to be made with some pins to stick straight into the connectors on the Emontx3 and a connector block for the reed switch. Can this be done on breadboard from Maplins?

Serious question as although I am an electrician and quite handy with a soldering iron. I have never done anything like this before!

In fact, I do no have any capacitor yet. I will buy the appropriate one later.

Here are the specifications of my reed switch:

- max current : 5 mA

- max voltage : 6V

- max bounce time : 1 ms

- initial contact resistance : 0.5 ohm

- insulation resistance : 500 Mohm

So I need a least an 1 k external resistor (5V/0.005A). Am I right ?

Another point, I do not understand when you say "when your reed switch closes, you will have a huge inrush of current". Could you please give more details ?

Eric

webby, if you decide to go that Maxim route, there are plenty of SOP to SIP adaptors available that might help with your breadboarding.  Here are a few examples:

https://code.google.com/p/opendous/wiki/MultiAdaptor

http://www.proto-advantage.com/store/product_info.php?products_id=2400051

Eric, as a further datapoint on your time constant, those Maxim de-bounce chips aim for the 15-85 msec range.  The one I use nails the debounce pretty  close to 40 msecs, and seems to work well.  It does mean it can't count pulses faster than 25Hz but that's not typically a problem for most gas / water meters.   One other heads-up: if anyone is using an "official" reed switch supplied by the meter manufacturer, they often have an in-built series resistor to protect against over-current.  From memory, the one in my Elster T-probe (water meter) was a few hundred ohms, so probably not big enough to make a huge difference to your time constant calculation.

My feeling is the debounce IC is overkill in this application. I suggest trying Eric's one resistor, 1 capacitor solution first as it's probably the easiest to put together and certainly the cheapest.

Eric:

Your 1 kΩ resistor is correct. Without it, because the capacitor can be completely discharged at the instant the switch closes, the current will be limited by the combined impedance of the power supply rail, the switch contact resistance, the series resistance of the capacitor and the wiring resistance, including the PCB tracks. The current could easily exceed the 5 mA maximum of the switch.

[I once welded back together the filament of a car headlight bulb: it had broken but by holding the bulb at the correct angle and tapping, the ends could be made to touch. So I soldered a photoflash capacitor to the bulb and charged it to about 200 V, held the bulb the correct way and tapped it. There was a big blue flash and the filament was repaired. Without the current limiting resistor, the same could happen to your reed switch. But in your case it would be destroyed, not repaired.]

If you have a 0.1 µF capacitor, the time constant of the rising edge of the pulse is the Thévenin equivalent of what is effectively a potential divider, the 1 kΩ and the 10 kΩ, which is 909 Ω, and 0.1 µF, so 90.9 µs.  The time constant of the falling edge of the pulse is the 10 kΩ only and 0.1 µF, so 1 ms. I suggest you aim for a 5-6 ms time constant for the falling edge, which will not allow the voltage to fall far enough in 1 ms to cross from the high input voltage threshold to the low, so 0.47 µF - 0.68 µF should be fine.

I agree. Having researched size etc Eric's solution is the way to go.

So I need a 1kohm resistor a 0.5 microfarad capacitor and some way to make the circuit?

I would advise a small piece of stripboard with a two-way screw terminal block on one end for the wires out to the switch, and three soldered wires (you can use terminal pins to solder the wires on to, but they're not necessary) at the other end to go into the emonTx screw terminals. 

I'd go for these:

http://spiratronics.com/pcb-terminal-block-2-way.html
http://spiratronics.com/stripboard-25-x-64-mm.html
http://spiratronics.com/terminal-pin-pack-of-25.html
http://spiratronics.com/0.25w-metal-film-resistor-1k-pack-of-10.html
http://spiratronics.com/metallised-polyester-capacitor-63v-680nf.html

I presume you've used stripboard before?

The perceived wisdom regarding mechanical switches, debouncing and interrupts is correct - when I stop to think about it, it is impossible to debounce in software when you are directly driving the interrupt with the input pulse. It has to be done in hardware, else you must poll the input to be able to get enough information about the contact state and the timing of the changes.

I've edited the sketch I attached to the earlier post and removed the attempted software debounce solution. I've also declared the variables properly, and shielded the pulse count accumulator reset from interrupts.

"it is impossible to debounce in software when you are directly driving the interrupt with the input pulse"

It is also my feeling. I tried many various sketches using interrupt without any success ... But as you said, one can debounce in software by polling the state of the input. This is I what I have done for several weeks with this sketch. It works perfectly (no missing pulse or fake pulse) but my code consumes a lot a resources. Actually, my Emontx can' do anything else...

So I would like to know whether it is possible to run periodically an ISR  ? Let say every second.

Eric

I saw your sketch and I could see that it would not be possible to do energy measurement at the same time.

I think you would need to set up a timer interrupt, and I assume your 1 s rate is much less than the time that the switch stays in one state - therefore you can know that it has been stable for a period of time.

Timer interrupts are exactly how MartinR's PLL energy diverter synchronises itself to take exactly 50 readings per cycle of mains frequency (don't be confused by it changing the clock frequency as well - that is related but not what we are talking about). I think it should be possible using Timer1 and the prescaler, though there is probably no advantage in running that slowly.

Then I suspect you need a section of code that says 'if the switch was low for 3 s and then high for 3 s, you have a pulse' - assuming your pulse is at least 4 s long at a frequency of less than 1/8 Hz!

I think it can be done - the core code can be copied from http://www.instructables.com/id/Arduino-Timer-Interrupts - always assuming that you check for subtle bugs first.

Thanks a lot !!!  This was the piece of code I was looking for ! Moreover, it is very well commented !

I would now be able to poll the state of the input every seconds without using the sleep function.

Next week, I will post a new sketch if it works fine.

Eric

Sorry, Eric, you will be too late. I've done it and it seems to work well. Using a push button that was giving anything up to 35 counts per press with the simple GitHub pulse sketch, this seems to work reliably up to 12 pulses per second provided they have a mark:space ratio of 1:1. At lower pulse rates it works with any M:S ratio provided that either the 'on' time or the 'off' time exceeds 0.4 s.  It uses Timer1 running at 10 Hz, and clocks the D2 /IRQ0 input into a char each interrupt. When the value of the char reaches 0x0F, that is 4 consecutive low bits followed by 4 consecutive high bits, it declares a rising edge and increments the pulse count.

I'd appreciate you giving it a try. I have not tried it with temperature sensors present.

[A version for the emonTx V3.4 is available here on the new forum.]

Won't that reject a valid rising edge that is immediately preceded by a spike?  It sounds like you only count a rising edge if it's had clear air before it.  I guess the spike would have to happen 100msecs before the edge, so is unlikely to be switch bounce related, but it sounded like Eric also had to deal with noise spikes.

If you have a noise spike that lasts long enough and is in exactly the right place to be seen, remembering that the input is now polled so that it has to be 'high' at the exact instant that the value is accessed - in the 400 ms preceding the wanted edge, so that the "history" is (say) 01001111, then it will indeed reject the following valid pulse. Exactly the same argument applies if you get a negative spike following the wanted edge. But if you have noise spikes like that, you need to do better with the wiring - and indeed deal with the source of the interference. By far the best way of dealing with something like that is to remove it at source, rather than try to mitigate the consequences. So after screening the input cable, maybe a hardware debounce filter will also be needed in extreme cases.

Yes, I agree you'd have to be very unlucky, and agree it's better to fix the noise at the source where possible.  You may well have stumbled across the Airbus de-spiking algorithm.  At least in this case if ever everything does align just right, nobody ends up in hospital.... a missed gas meter pulse every few decades will probably never get noticed.

Although the FCPC algorithm for processing AOA data was generally very effective, it could not manage a scenario where there were multiple spikes in AOA from one ADIRU that were 1.2 seconds apart. The occurrence was the only known example where this design limitation led to a pitch-down command in over 28 million flight hours on A330/A340 aircraft, and the aircraft manufacturer subsequently redesigned the AOA algorithm to prevent the same type of accident from occurring again.

http://www.atsb.gov.au/publications/investigation_reports/2008/aair/ao-2008-070.aspx

I didn't know they used Arduinos in the Airbus.... Oh wait.....

Since my license lapsed, I haven't read any air accident reports, so I didn't know about that. But in any case, if you do have positive-going noise spikes of 0.7 V_cc with a low input, or negative-going ones of (Vin - 0.2 V_cc ) with a high input ( say amplitudes of roughly 2.3 V for an emonTx or 3.5 V for the Shield) then you've got serious pickup problems. And if you've still got them after you used screened cable and put a simple hardware filter in, there's no real hope of measuring voltage, current or anything else accurately.

But what do you do about it? You can speed up the clock by a factor of two, or four, and use a 16-bit or 32-bit variable as the shift register, then ignore the middle few bits where you hope the switch bounce is, examine separately the high end and the low end that remain, get the proportion of 1's and 0's in each, and make a decision on that basis. But is it worth it, especially as it's in an interrupt routine where lost time means inaccuracy in the main readings?

I guess if you really need to run a signal down a very long cable, through a harsh environment, there are much more robust solutions than a GPIO pin with a pull-down.  Unfortunately, they generally require logic (and power) at both ends of the link.

I haven' thought it through, but how does this sound:

The reed switch has a fairly low current handling capacity (5 mA in Eric's case), and to reduce the voltage pickup, you need a low circuit impedance. So you wire the reed switch from input to ground, with a 1 kΩ pulldown in parallel with it, and feed it from 5 V via a 5 mA current source. When the switch is open, the input impedance is one tenth of what is would otherwise be with the standard pull-down, the current source is a high impedance so has little effect. With the switch closed, the impedance is the cable resistance (not much different, as previously the voltage supply should be a very low impedance).

Sounds promising.  What do you use for the 5mA current source?  When trying to sketch a schematic of your description, I used a 1K R connected to +5V for the 5mA source, but then with the switch open, I ended up with the input  pin connected to the midpoint of a 1K/1K divider running between +5V and GND, which I assume is not what you intended.   If it were an analog input you could probably work with that, but I assume you want to keep your AtoDs flat out measuring power.

You can't use an analogue input - it takes too long to read! !  The classic way to get a current source is with a transistor - clearly a resistor won't work as there's not enough voltage available, as you found; we need the input to go past 0.7 Vcc to be a valid 'high', so it might be tricky.

Hi,

Thank's Robert for writing that sketch.  I like the way you did it with a shift register. Before trying it, i will modify the polling frequency to 1 Hz to reduce CPU usage as either the 'on' time or the 'off' time of my reed switch exceeds 6 s.

Unfortunately, I can't test it right now as I'm not at home until mid-May. I will tell you later how it works.

Regards,

Robert

Thank you very much for your help in all this!

I have now run my cable and built my hardware debouncer. However before uploading your sketch can I confirm a couple of things.

I am using an AC -Ac power supply bought from Glyn. I have connected the pulse to the 5v pin 1 however it seems to be giving 3.3v the same as pin 2. This I guess is because of the power supply.  Will it affect my debouncer circuit which uses your suggested resistor and capacitor?

Before uploading the sketch I will take a good look at it to try to understand what is going on. I have been studying some "Arduino for dummies" stuff that I have found. Obviously need to edit for freq and node number.

Yes, with the power derived from the AC input, there is only 3.3 V available (see the circuit diagram! - the voltage on the 5 V connection is a back feed). It's probably not a good idea to leave it there, because it will be 5 V with the programmer or USB supply connected, and then closing the switch takes the input outside it's permitted voltage range unless you have a 1 kΩ series resistor that I suggested way up this thread.

The additional bit of software is dead simple. The timer triggers an interrupt and the ISR runs. It moves the "history" 1 place to the left, then adds in the switch value (0 or 1) into the vacant LSB. And so on. When you have 4 zeros and 4 ones (hex 0F), it's seen an edge.

Eric. I don't think changing the timer to 1 s will materially affect CPU usage. It does very little inside the interrupt routine.

OK it seems to be working well. A bit early to tell if any pulses being skipped or multi counted but they seem to be accumulating at a steady rate despite 25m cable run!

My meter pulses once per cu.ft. I have written some maths into the input screen to give me total and daily usage in kwh

However I am a bit confused as to how I can produce instantaneous figures to produce a nice line graph in visualisations and dashboards.

There is a feed called total pulse count to pulse increment. I am not quite sure how it works though.

Sorry to pester you again but can you offer some advice on this?

The input processing area on the site does not really help explain it to me anyway.

Do you want the instantaneous rate in kW?  You have a problem. The pulse increment is sent every 10 s or so, if there hasn't been a pulse since the last reading, zero is sent, otherwise it sends the number of pulses that have been seen since the last reading. Each pulse is in units of energy (kWh with appropriate scaling), hence you need to use "kWh to Power". That works in principle, but it calculates the power based on the increment since the last refresh, not from the last time the acccumulating pulse count had a non-zero value added to it. You can see where this is going - it will show zero a lot of the time, then a big number. Looking down the list of functions, I think Trystan didn't anticipate doing it this way, which is why in his (electricity) example he did the timing in the ISR, and transmitted a "Power" based on the interval between the previous pulse and the present one. I think you must do that, but I suggest you split the scaling so that you transmit a sensibly scaled integer from the emonTx, and finish the scaling inside emonCMS where it's easier to take account of changes in the calorific value and the volume correction factor.

Yes I figured that but thought that trystan or somebody had come up with something clever in the pulse to pulse interval option in the input calcs.

So having been out all day I have returned to see an accumulation of pulses which look to be ramping up evenly when my gas appliances are running so so far so good and I can convert these to a total and a daily total.

However as mentioned elsewhere the new daily feed is logging to the wrong day although its yesterday this time instead of tomorrow with my other ones.

So you suggest sending an approx amount of "watts" rather than just a "1" from the emontx and then adjusting the volume and calorific value in the feed calcs?

No, as well as!  And use the two values for their separate purposes. Keep the pulse count (= energy) for the total and daily total, and the power for, well, power.

Note, you send a "1" or a "0" only if the pulse rate is less than 1 every 10 s. If you get more than 1 pulse between sending values, it will send the true count of pulses.

Everything was fine until 05.30 this morning when my pulse count jumped instantly by 32!!!!

Without that the pulses would have correlated exactly with the meter reading.

Could that be switch bounce or something else?

Further study shows that this was at a time when no gas was being used except a pilot light on my aga. So it could have been one pulse with the dial rotating extremely slowly creating the "bounce" or something else entirely.

There is one other time that I can see that I got 2 pulses when there should have been 1.

Yikes! I can't quite see how that could have happened. Assuming you have kept the original timing, the timer fires an interrupt every 0.1 s, which means the switch is polled every 0.1 s. But the 'shift register' needs to see 0 0 0 0 1 1 1 1 to count a pulse - at least 0.3 s consistently in each state, therefore to count 32 pulses it needs to see 000011110000111100001111 . . .  that's 3 pulses and it took 2.4 s, so your switch needs to be bouncing in a very controlled manner for half a minute to count that many pulses.

Now the contacts in a reed switch have some inbuilt hysteresis (you can see this given a reed switch, a multimeter, a magnet and a steady hand) so I think that theory doesn't seem likely.

[Edit: One particular reed switch and magnet pair that I've just checked: make: 18 mm between magnet and switch; break: 28 mm, keeping the same relative orientation between them.]

I think I'd lay the blame on "something else entirely" at this stage. Is the 32 significant, I wonder? Is there a spark ignition anywhere that might have generated something that looked like a repetitive pulse?

Tell me about your 25 m cable run. What type, earthing, proximity to anything electrical (including stuff the other side of walls)?

How have you wired the contacts into the emonTx, is there any hardware filtering?

Yes I think you are right! Cable is unscreened alarm wire chosen for its ability to fit into an RJ11 plug and its on the shelf!

Run is around the outside of the house concealed under tile hanging nowhere near any thing until it comes through the wall into my Consumer unit cupboard. There it was running along with the power supply to some outside fluorescent spots which are triggered by a light sensor connected to a relay. I had another spike tonight when the lights came on and have since triggered further ones by switching the lights. The spike this am was the lights turning off! Cable now rerouted for further observation!

If rerouting doesn't cure your problem, then I think you need to look at what I wrote above about cables (twin twisted screened) and filters. Eric's hardware debounce filter should also take interference spikes out fairly well, adding a fast diodes to clamp the input wire to earth and +3.3 V might help if the RC filter isn't enough.

I have the hardware debouncer from above in this thread. It is working perfectly. I did read re the wire and screening its just that I had this alarm wire on the shelf in my garage. Now that the concept is proven I can spend some money on proper screened cable.

Is it possible to get breadboard that has the same pitch as the connectors on the emon tx? So that I can connect the debouncer without flexible wire tails.

Here is expanded screenshot showing nice even pulses and the spike this am when the lights turned off.

As far as I know, only 0.1" and 0.15" Veroboard is available (other equivalent brands exist, I don't know whether many or any do the 0.15" pitch). I make the emonTx connector 0.14" pitch, so it's close enough for practical purposes. (I think you'd get away with 0.1" if you used solid tinned copper wires - the 3 terminals you are using are adjacent, so only a slight joggle is required.)

That's some step you have. I completely understand the appeal of using a cable you had to hand, you could try earthing any unused cores, that might help a little, but it's a bit like grasping at straws. The cable you want is like this http://spiratronics.com/twin-screened-cable-per-metre.html (not this: http://spiratronics.com/stereo-screened-cable-per-metre.html).

So despite reroute of cable a similar spike occurred when lights came on tonight. I have discovered that the cable runs directly alongside the coil trigger wire for the lights relay for a distance of about 4 feet! Will a screened cable prevent the spike because rerouting the cable to avoid this will be difficult! Maybe I should screen the trigger wire as well?

Screening the source shouldn't make much difference, but it might help a little.  I can't categorically guarantee that a screened cable will prevent the spike, but it should certainly help a lot more. You could also look into suppressing the relay coil. The usual way is a series resistor-capacitor combination in parallel with the contacts - usually 0.1 µF + 100 Ω.  Maplin, RS & Farnell sell it as a single component ("contact suppressor") rated for mains voltages.

To be fair the relay is a massive one (again off the shelf in my garage) and it is v close to the Emontx (due to space resrictions) I could quite easily replace it with a small one situated within my consumer unit which is much further away from it all. I think I will do that first as funnily enough I have one in stock! It may already have a coil suppressor.

Thanks again for your help! 

Suggest using something like Belden 8723 or equivalent twisted pair screened cable.  Make sure you earth the screen at only one end.

"Suggest using something like Belden 8723 or equivalent twisted pair screened cable.  Make sure you earth the screen at only one end."  Why does he need two screened pairs, and is foil screened any better than a lapped screen? It is probably unnecessary to go to the really expensive double braided screen cable for this application. He already knows to earth the screen at the switch end.

Spikes much smaller now going to try maplin suppressor.

A hunky relay or contactor coil can store a good deal of energy, and as the contacts open (or bounce) without a suppressor there's only one place for it go - into space. Hopefully the addition of the suppressor will solve your problem. Is it a mains voltage ac coil, or low voltage dc? I've been assuming it's mains, but if it's a low voltage dc, a flywheel diode might work.

Mains voltage AC coil. Will get suppressor asap.

Hi,

I have been testing Robert's sketch since 2 days and it seems to work fine with my gas meter without any additional piece of hardware.

Although I had a lot of noise at the source (noise spikes on the line and bounces), it reports the exact number of pulses given by my meter.

Great job !

Eric

That's good to know, thank you, Eric.

Assuming that the input switches between the voltages of 0 V and V_CC,  the noise spikes need to be about 0.6 or 0.7 V_CC or more in amplitude (depending on the switch state) in order to get through the Schmitt trigger on the input. (See Figure 13-2 General Digital I/O(1) and Table 28.2 DC Characteristics in the data sheet).  Therefore I suspect yours, Eric, are smaller that this and Webby's are larger.

I don't know if it can affect the noise spikes but note that

   - my reed switch is connected between the ground (port4) and the 3.3V (port2) of the EmonTX.

   -  the EmonTX is powered by the AC/AC adapter

Eric

Eric:

"- my reed switch is connected between the ground (port4) and the 3.3V (port2) of the EmonTX."  Webby has that too.  I wondered whether the noise was getting in to the V_cc supply and corrupting a register somewhere, but I decided that was silly. I think it is simply that Webby has the switch wiring running for a distance of 1.2 m close to the wires switching a relay that has no suppressor. That is surely more than enough to cause trouble!

Webby:

You mentioned the lights in question are fluorescent. What sort of control gear do they have - electronic ballast or choke and starter?  If you turn off the lights but allow the relay to switch, do you still count extra pulses?

Hi Robert

That test is a little tricky to do in my case. The coil supply is fed from the same MCB that runs the lights.

They are electronic ballast. I hope to pick up a suppressor today. My Debouncer is still connected to Port 1 on the emon tx. I plan to change that today as well.

Suppressor working!

That was a battle, but your experience is not unusual when you are dealing with interference.

Now to get my PHP feeds logging to the correct day. Can't see why it is only affecting a few people. I guess finding out would go some way to solving the issue. I am using emoncms.org but displaying on a Mac using Safari however the same problem is apparent in Chrome as well. Could it be my machine? Wish I had a clue but I don't.

Prob a topic for another thread.

Thanks again for all your help.

The wrong day problem has been/is being discussed in other threads, so I think you find someone with similar or the same symptoms that you are experiencing and join in there.

Hi,

I have been testing Robert's sketch since 10 days. It works perfectly with my gas meter without any additional piece of hardware. I am getting the exact number of pulse sent by my meter, about 5000 pulses in 10 days. No pulse have been lost or duplicated. Great !

With the same Emontx, I am now able to count pulses, monitor many temperature and many CT. Great !

According to me, this feature needs to be added in the main EmonTxV3 sketch.

Regards,

Eric