Archived Forum

I think you are going to have shock when you find out the price!

http://www.plumbcenter.co.uk/en/heating-parts/energy-parts/elster-jeavon...

I'm trying (trying being the right word!) to do a similar thing.

Rather than purchase the kit I'm just using a reed switch stuck in the same place as the unit would fit with some blutak.

The reed switch is actuated by a magnet on the smallest dial of your gas meter which in my case, 1 rotation equates to 0.01m3.

I have a cobbled together arduino sketch that has an interrupt function that get triggered on the change of state. 

Where I am struggling is with the bounce on the circuit triggering false counts so now I'm reading up about debounce circuits!

Given you are going to have a sketch on your controller to format the data and eventually broadcast something, I don't understand why you would want to manually then change the node?

Hope the above was useful, I'd be very interested in keeping track of how you get on.

guys,

 I got mine from http://www.utilitymeterswarehouse.com/gas-meters/gas-accessories/pulse-blocks/pulse-block-for-elster-jeavons-u6-u160.html/ last Aug. Their site appears to be down at the moment but it cost £34, which included £8 for shipping to Ireland.... might be worth checking.... snippet of invoice attached fyi.

Eamonn

The reason for the addressing was that I was trying to figure out an easier way of deploying a node without the need for programming each one individually.

In a house with one gas meter, not a major issue but in a building with multiple gas, water and electricity meters.  It would be easier to set the address on a switch and have an easy way of setting the pulse multiplier for each one from one place.

I haven't quite thought through the whole data processing scenario fully but instead of doing the calcs at the meter, could it be done at the web interface?

I hadn't thought of de-bouncing, I'm glad you brought it up.

Thanks for the link for the pulse module.  I would prefer a nice clean connection rather than have British Gas freak out when they see something blu-tack'd to the meter.

You might also want to take a look at https://www.flukso.net/content/gas-probe if it fits your meter. As you can see its recessed in a hollow underneath the dial. Is your idea that the dip switches control the nodeID that the RfM12 is broadcasting on?

That doesn't look a bad solution, thanks.  Still waiting back for prices though but have found everywhere else I have looked to be around £33 so not holding out much hope.

Yes my idea was to use the dip switches to control the nodeID.

Five switches gives you 0 - 31 addressing (note: you wouldn't be able to use address 0 or 31 see here)

How are you going about your debouncing, hardware or software?

I have found a stripped down circuit of a digital input from a commercial controller if that's any help to you.

Note that this circuit accepts 24v~ as well as logic input.

My plan is to do try to debounce using hardware as I want to keep the interrupt loop as simple as possible.

I'm planning to do this via a 555 switch IC. 

But I'm far more at home in software than a hardware so it's slow going as I learn from my mistakes.

Although I'm more electrical than electronic I feel more at home with the hardware than the software.  Good news as we can try and help each other!

I think I may have found a more elegant solution to your 555 switch.

Switch Debouncer.

I will revise the circuit over the weekend and post back a schematic.

Surely it's trivial to debounce in software? Once you detect a change you simply ignore all further changes for a period slightly longer than maximum bounce time.

Considering the node needs to be powered by battery what would be the most power efficient method?

MartinR - the reason I plan to use hardware is purely because I'm trying to improve my understanding of electronics.

ukmoose, the Hall effect sensor does not have the bouncing issue, and as far as I understand (not tried yet) it is usable plug-n-play on the pulse input of the TX.

What are the pros for a reed switch ? Power consumption ?

Or are you using this out of fun/interest/... ?

(Don't think I believe I know better, I'm really asking.)

I don't think there is a way to de-bounce in software if you are using interrupts from what I can tell.  I may be wrong though.

There are no pro's to using a reed switch but I want the module to be robust to be used for any digital input, hence the hardware de-bouncing.  Its also handy to test manually if something is working if you can just manually create a pulse across the connection terminals.

I would ideally like the pulse module to wakeup on a pulse, send the recorded pulse and go back to sleep if there are no more pulses for a given time period.

I'm still waiting for the sensor from Flukso to fit on the gas meter but initial tests using a piece of wire across an input result in horrific bounce.

I have a MAX6816 but being so naive I had no idea it was so small.  Until a SOT143 breakout board arrives for me to 'attempt' to solder it to, I can't test it.

Another option I have seen uses a capacitor and inverting smitt trigger.  http://www.youtube.com/watch?v=CRJUdf5TTQQ

I have managed to add some code for the nodeID DIP switch to Trystan's emonTX_Pulse firmware sketch but I have not fully got my head around what all the rest of code does.  I'm completely out of my depth but learning a great deal as I go.

I don't think there is a way to de-bounce in software if you are using interrupts from what I can tell.  I may be wrong though.

Wouldn't you just set a flag, and only proclaim a change-of-state if the flag is still set after a certain period has elapsed?  That's essentially what the hardware equivalent is doing.  By waiting until a capacitor has charged up, any rapid transitions are filtered out.

I don't think there is a way to de-bounce in software if you are using interrupts from what I can tell.  I may be wrong though.

This depends a bit on your software architecture. One easy way is to just do a small (e.g. 10ms) delay inside the IRQ and read the stabilized value of the input a second time. Reed contacts are usually bouncing really fast (if at all), so a smaller delay should also work then.

I'm afraid it is not that simple because delay() won’t work within an ISR. I'm surprised I didn't find another source about this.

For instance, here is an example of an interrupt handler with a delay:

void countP()
{
    delay(10);
    if (digitalRead(3) == LOW){
      // Debounced interrupt action
      count++;
      Serial.println (count);
    }
}

This does not work, apparently.

It can work if the debouncing is done in the main loop :

boolean interrupt_received = false;

void setup()
{

  // Setup pulse counting interrupt
  pinMode(3, INPUT);       // set interrupt0 (pin3) as input
  digitalWrite(3, HIGH);   // and enable it's internal pull-up resistor
  attachInterrupt(1, countP, FALLING);  // device signals a low when active
  delay(100);

  // Setup serial link
  Serial.begin(57600);
  Serial.println ("Start");   // signal initialization done
}

void loop()
{
  static unsigned long count = 0;

  // Software debounce (10 ms)
  if (interrupt_received == true){
    delay(10);
    if (digitalRead(3) == LOW){
      // Debounced interrupt action
      count++;
      Serial.println (count);
    }
    interrupt_received = false;
  }
}

void countP()
{
  interrupt_received = true;
}

But then, issues arise if one wants to add a delay() in the main loop.

Isn't the technique to disable this interrupt for a short while?

I've been thinking, the need for a delay in the main loop can be addressed with millis().

Still, it is not ideal. If the loop happened to last too long (sending over serial, or worse, over internet), we could reach a point where the Reed is open again. Perhaps this can be addressed with millis() as well. And perhaps we could consider it won't happen because the wheel does not run that fast.

Another way would be to add in the ISR handler a long task, such as writing on the serial port. A task for which we would know it will take a minimum amount of time. This is generally considered as bad practice.

Disabling the interrupt while debouncing would look nicer. Yet, I don't think it solves this specific issue. Say we disable the interrupt in its own handler. Then, in the debounce code, after incrementing the counter, we enable it again. We still don't have perfect control on the debounce delay. It could be much higher than we want it if the loop takes too much time to execute. Or did I miss something ?

The answer may well be that in our case the Reed is closed so long we can't miss it. One could try to know that with a test code that would print time on both falling and raising edge, and run the meter full speed (open all taps, force boiler and all gas appliances full charge, perhaps not that easy but you get the point, and you can use a great security margin, it's just about having an order of magnitude). Or more theoretically, figure out the max power of the house appliances, which leads to the maximum wheel speed.

Or perhaps a hardware debounce is simpler after all...

If you can find the specs for your meter, it should have a maxium flow rate.  From there you should be able to work out the minimum pulses you'll see.  For example, with my Elster water meter running at max flow rate (nothing I've ever come close to doing) I should see a '1' (switch open) for at least 685 msecs and a '0' (switch closed) for at least 1600 msecs.

Good point, dBC. My gas meter ranges up to 6 m3/h and generates a 0.01 m3 pulse, that is a maximum of one pulse every 6 seconds.

I don't know how long the switch remains open, though, and I suppose it depends on its sensitivity, its distance to the meter, the way it is fixed, magnetic perturbations, and all.

One approach could be to disable the interrupt for 3 seconds so we won't trigger on a release bounce and assume the loop() won't be stuck more than 2 seconds more so we won't miss the next pulse. This is simple and should work but inelegantly depends on the meter's max cycle if the order of magnitude is quite different on other meters.

BTW, with the Reed I've been trying, I saw closing bouncing (about 4 pulses) but no opening bouncing. Dealing with only closing bouncing is even easier but just because I didn't see it happening, does not mean it is not possible.

that is a maximum of one pulse every 6 seconds.

That sounds comfortable enough that you should easily be able to nail it in software.  I don't see any need to disable interrupts.  Just have the ISR set a boolean flag to say it occurred.  Then your main loop can check the flag every 6 seconds and see if it is set.  If it is, clear it, and count the pulse.   OK... maybe every 4 or 5 seconds if you want to make sure you don't miss 2 back-to-back pulses.

I don't think this is absolutely safe. Consider a single pulse. If the bouncing occurs precisely around a check (really unlikely, I admit), the flag is cleared between two bounces and the pulse is counted twice.

Good point.  In that case make the "boolean flag" a timestamp.

Check the timestamp in the main loop every 2 seconds (say).  If it's zero or < 100 msecs ago, ignore it.

Otherwise clear it, and count it as a pulse.