Pulse meters - part 2

Here is my solution to connect the smart gas meter 'Gazpar'. This should also work for any pulse meter using a switch.

The idea is to keep the counter in RAM and thus the microcontroller always on.

Low power consumption

One of the challenges was to send the ATtiny85 to sleep and waking up only when either a pulse is counted or a serial character is received. I ended-up writing my own code but heavily influenced by this, this, this, this and this. It looks daunting at first but makes sense quickly.

The "PCINT0_vect" in the Interrupt Service Routine meaning all Interrupts from PCINT0 to PCINT5 is a catch and loads of people seem also confused by it.

Hardware Debouncing

The first attempt was using a capacitor to debounce the input. It worked flawlessly with the gas meter but these days debouncing tends to be done by the microcontroller itself.

In this case, the counting (increment) is done in the interrupt function itself (The "PCINT0_vect" mentionned above).

Software Debouncing

This is were troubles started. Because it is not possible to use timers/delays in the interrupt function, the debouncing has to be done in the main loop.

After several iterations, mixing flags and jobs done half synchronally, half asynchronally, the final (working) solution is also the simplest.

Loop

In the end, the loop is fairly straightforward and could be summarised by:

Development

The development was done on the Arduino IDE using https://github.com/SpenceKonde/ATtinyCore using an Arduino Uno as the programmer.

Backup during power outages

Goldcap/Supercap/EDLC

The firt idea was to use a supercapacitor (something like 1.5F 5.5V) with a schottky diode in order to maintain the MCU powered.

In theory, it's easy to implement and should work like a treat (between for example 5V and 1.8V). In practice, there were some issues with the "initial" charging (big drop of voltage) and I was disappointed by the performances. Moreover, there is the issue of a big variation of voltage of the supercap (can drop under 2V) in relation to other pins (Vcc, serial).

I am pretty sure that there are good ways to deal with these matters but they certainly require more investigation. It could also explain why, even nowdays, RTC on motherboards are still mainly powered by battery cells rather than supercaps.

Battery

An alternative was to use a simple CR2032 lithium battery. These StackExchange answers were a good way to start. This AN1535 application note, also gives a complement (cf Figure 3).

This last document is were I was made aware that the reverse leakage current could be a big issue. I have no plans to have any of my circuits "UL approved" and don't have to follow any american requirements but at the same time, if a risk exists with batteries on the other side of the pond, it is the same over here.

I was planning to use BAT48 Schottky diodes but they may have a higher leakage current than the recommended value (1µA). Renasas Application Note mentions BAT54. The bad new is they exist only as SMD (SOT23-3). The good news is there is a "C" variant which incorporate 2 diodes.

In the end, I put a BAT48 + BAT54C.

Battery & Diodes

Vcc and serial communication were also switched to 3.3V in order to keep all voltages as close as possible.

When running on battery, the following values were measured with a fresh cell:

Which gives the following drops:

Note that drops are higher (~ .2V) when measured using a multimeter in diode mode. Possibly because the current is higher.

First foray into SMDs

As mentionned above, BAT54C diodes only exist in SOT23-3 format. Since even through-hole component can be challenging (specially with bad solder, but this is another issue), I have never been too keen in the SMD variants of components. That said, I discovered that this is a vast world with loads of different sizes (from doable to sheer madness).

Since I hadn't received my SOT23-3 to SIP-3 adapter boards, I decided to solder it directly on the 2.54mm pitch prototype board! Ugly but it worked fine on the first attempt so...

SMDs (at least the 1206 size) might not be evil after all!

Pins and ISP

Since PB0, PB1 and PB2 were available without anything else connected to them, I realised that I basically had almost everything ready for "In-system programming". So I added a "reset" pin (PB5). Et voilà.

Pulse counter

Pin on board Pin on chip Main function ISP function
Tx 5 (PB0) Serial (Tx) MOSI (Arduino 11)
Rx 6 (PB1) Serial (Rx) MISO (Arduino 12)
Signal 7 (PB2) Counting (switch) SCK (Arduino 13)
Gnd 4 Counting (switch) Gnd
Gnd 4 Power
Vcc 8 Power 5V
Reset 1 (PB5) NC Reset (Arduino 10)

Disclaimer

As usual, this page is for informational purposes only... You assume total responsibility and use at your own risk!

Next time, I'll describe the installation in situ and the (very simple) communication protocol.

    Pulse meters - part 1

    Here is some evolution about the Gas Meter 'Gazpar' for which I developped a generic battery backed-up solution.

    Gazpar

    As mentionned before, the "official" cable is for sale at a hefty price (for what it is) of ~20€. I would have gone for this cable, had the meter been outdoors or in a humid room, but since it is located in my kitchen, I simply used the trick found on some forums: Female dupont wires. And it works very well indeed.

    Dupont Female

    Counting

    One of the main differences between the electricity and gas smart meters, is that the former will deliver all the information (including current reading) in a continuous way. In case of power cut, upgrade or crash of the microcomputer/microcontroller, nothing is really lost and things will restart as soon as possible.

    The gas meter, smart or not, will only give pulses... if nobody is listening, the information is lost and the status of the reading not longer accurate.

    Keeping the value

    The basic idea is to decouple the counting process from the processing unit. The counting unit should not need any update or needs to restart often.

    One idea was to write the current value on a flash memory but these are notoriously bad as time goes by. Wear and tear could soon be an issue.

    Apprently, there is a kind of memory called Ferroelectric RAM/FRAM for which the number of write cycle is not a problem. But these are not wildly sold (but can be found as breakout board) and certainly overkill for just keeping a counter.

    So in the end, the easiest solution seemed to use a basic ATtiny85 powered and keeping the value in RAM. This solution will be described in the next post.

    Jukebox, one year on

    Following the articles about the making of the Jukebox, last year (cf first, second and third parts), here is a quick hardware update.

    Still alive

    Despite being someone roughed up by a toddler, the panda is still alive :-)

    As they say in a certain cartoon series involving animals who love jumping up and down in muddy puddles: Hurray!

    Sound quality issues

    Over time, the sound quality, which was never Hi-Fi but still better than initially expected, started to degrade. To the point it became somewhat unbearable. My first thought was that the cheap usb sound card had an issue, but the sound was good when using headphones.

    Second and third culprits were the amplifier and speakers. Plugging them on a mobile phone revealed that there was a bit of an issue but nothing very obvious.

    Nevertheless, I replaced the embedded amplifier with an ubiquitous PAM8403 perfectly suitable to the task. I also took the opportunity to remove the flimsy jack connector and to solder the wires directly on the USB sound card.

    Sound was definitely louder and clearer. Yet the Signal/Noise Ratio wasn’t good (however it was fine a year ago) and it was a bit of a mystery. Even adding a capacitor between Vcc and Gnd on the PAM8403 board didn’t help much.

    PAM8403

    (A word of warning: on a PAM8403, like on other class-D audio amplifiers, the output grounds are floating and SHOULD NOT be connected together!!!)

    Power

    The Jukebox uses a powerbank to power the Raspberry Pi. The amplifier is powered via one of the usb socket. While puzzled by the problem, I tested a new setup using a second powerbank to power the amplifier... and sound became clear!

    I still don’t really know what element injects some noise on the USB port (the sound card?, the Raspberry itself?, The RFID reader?...) but it has a strong effect. Probably that a capacitor somewhere has lost its mojo...

    The easiest and fastest workaround was to bypass the Raspberry by using a Y splitter USB cable and a breakout board I had lying around... Sorted!

    Micro USB Splitter Micro USB Breakout Board

    On the new setup, one power cable goes from the powerbank to the Raspberry Pi (as before) while the second one now powers directly the PAM8403 amplifier (via the breakout board).

    Jukebox - part 3

    Following the first and the second parts, it's now time to have a look at the finished product.

    Version 1 "Panda"

    Version 1

    This is the current version. It is based on the same big principes as the "prototype" but stronger and more stable.

    The panda head was chosen only because I was looking for a cheap, ready made, ok quality, stereo, non-bluetooth USB speaker. It became the central theme of the jukebox as well as its nickname (even if in reality it's more something along " 'da "). The amplifier is in the volume control box (glued at the back) but on newer model, it seems inside the head (and the volume is controled via one ear of the panda).

    The sound card is a USB generic one and it is very stable with VLC. The overall sound quality is certainly not Hi-Fi but is not shabby at all.

    Components

    • The speakers are in the head
    • The amplifier is in a small box
    • The Raspberry Pi, RFID reader & Controller, USB Soundcard, USB memory card are inside the "base"
    • The battery is at the back for easy replacement

    Jukebox

    Button, lights & secret switch

    The green button is also a light. When pressed it pauses the music. The light is an indication of the booting process (flash), ready state (on), paused (breath), playing (off).

    There is also a hall sensor inside the base (activated with a strong magnet) in order to give the possibility to boot with or without any "RF" (Wifi, ...) activated.

    Code

    As usual the code and schematics are available (AS IS) on github.

    « Page 3 / 31 »