Low Power Argon Design with TINY85

Hardware
1

Hi All,

I’m working on a low power design using a TINY85 to turn an Argon on using the EN Pin…

There’s a sensor connected to a Digital Input Pin on the TINY85, when the sensor goes High it triggers an Interrupt which turns a Digital Output High connected to the Argon EN Pin to power it on through some transistors…

I’ve knocked up the below diagram using Power Point :flushed: was quicker than learning Eagle :see_no_evil:

I’d like to know if I’m on the right track, or is there a lower power way of achieving this?

Argon%20EN
Argon%20EN1046×333 16.4 KB

Cheers in advanced!

2

Looks like you are on the right track.

But would it be possible to leave your Argon "close-by" and powered 24/7 so it doesn't need to perform all the WiFi and Cloud duties on each Boot? If so, you could use a battery powered Sleeping Xenon as the End Node at the sensor location. The Xenon can wake from Sleep with the Pin Change from your sensor (no Tiny85).......drawing ~ 50 µA while sleeping.

On earlier Firmware, I measured the Argon at 31 µA while the EN pin was held low.
By the time you add your current for the ATTiny, and the additional circuit losses, there may not be much "to gain" verses the Sleeping Xenon +Mesh Approach at 50 µA......if a nearby mains powered Argon is an option.

Just a thought :smiley:

3

Thanks @Rftop

The end goal is to use a Boron but I’m waiting for them to support Vodafone NB-IoT in the UK first, so testing with an Argon.

With your experience, how many years would you expect, with the Boron powering on once a day for no more than 15min sending some data up to the cloud, using a 13Ah battery?

4

Ahh… I have a lot of Battery Budget Calc’s for the Boron LTE scattered around this forum, as do others. This post has a quick and dirty example for a similar battery (19 aH, publishing every 2 hours).

But I don’t have Boron test results with the latest firmware.

Do you want the ATTIny to wake up and keep count for 24 hours, then only wake the Boron up once a day ?

I’d lean towards only a Boron, using manual mode.
The Boron can quickly decide to just increment the counter and return to sleep if it’s not time to power-up the cell modem and perform the cloud publish.

1 Like
5

I don’t know about connecting an LSH20 to the Argon this way… if you plug in a USB port it is going to attempt to recharge it and potentially cause a fire

1 Like
6

Thanks again @Rftop

I’m trying to achieve 5+ years battery life, and was under the impression even with the Boron in manual and using the sleep modes, this was still a big ask!

I looked at using the TPL5111 Enable Timber but it’s limited by it’s 2 hour max time. So I went down the TINY85 route basically building my own EN Timer/Interrupt…

The idea of the TINY85 is to power the Boron on when the Digital Input goes High and send an Alarm to the cloud but, also power the Boron on at Midnight and send an ‘I’m alive’ message with some diagnostic info. I’ve not looked at the 24hour timer part yet though.

Do you think the Boron alone is really capable of doing this?

7

Thanks @HEng I understand your concerns but, while bench testing I’m using a 3.7V LiPo and when I move to real-world testing, I’ll then use the LSH20… the end end goal is to use the B-Series SoM and this will get designed out.

I did it this way as the Boron LiPo doesn’t use the 3.3V Voltage Regulator and the power consumption used by the Fuel Gauge is better spent.

I’m open to suggestions, if you can think of a better way of powering the Boron using a single cell LSH20 and minimising the power consumption of the device.

8

Post your use case because right now its a guess as to what can be used. Maybe Solar/Wind/Water etc could be viable options based on the application ?

9

Hi @shanevanj

The solution needs to be battery powered with a minimum of 5 years (depending on use) obviously if the Sensor is triggering the EN Pin more often than not, it will impact the battery but, I expect the sensor will only power on the Boron couple of times a month.

The sensor is just a simple switch btw

If I need to use more cells then I need to use more cells but, I’m trying to keep the cost down to a bare minimum too

10

I am tempted to say - based on the clues :-), if its a switch - it is probably in visible light - so a small solar panel (even in artificial light) will recharge a Lipo that will cope with a boron coming on from deep sleep, for a short period occasionally. Given @Rftop’s testing above as well as others - I would build it and test the consumption.

2 Likes
11

It’s not going to be in visible light, the device will be monitoring gen sets and power consumption/generation from meter relay outputs (dark cabinets, rooms without light).

Yes, that sounds like it can be mains powered to a degree but that’s not the case, the design specification is 5 years on battery.

12

So use genset battery to provide 5V to boron and to charge borons LiPo - Genset will normally start regularly to recharge battery or will have a utility connected charger to keep primary battery charged … (I may be be oversimplifying it :slight_smile: )

I still think that the deep sleep mode of boron will do the trick - you will have to proto this and do a few days of 1 x per day wakeup and connection to calculate consumption - a week of that should give you a ball park idea of usage - then factor in the self discharge rate of the battery (in the case if the LSH20 its about 3% per year (excluding leakage on the pub due to condensation etc))

13

We can’t be seen as steeling power, I know it’s very very negligible but the site can’t power or charge the device.

It has to be battery powered!

1 Like
14

I just read the thread from start, and you’ve added a lot of useful info.
But if the goal is a B-Series (Boron SoM), then we are all guessing on the current demands.
Maybe a B-Series Engineering Sample could start floating around for 3’rd party testing :wink: (hint hint)

I believe it was previously mentioned that the B-Series can be powered via the 3V3 pin. I don’t remember if the intention was to require an external 3.3V source or not. This might change your power strategy, and maybe your sketch in Post #1. I wonder what the Vin(max) is for the B-Series. A SAFT O.C. voltage “might” be low enough to direct drive @ 3.60V, but probably not.

I still love the idea of an ATTiny for the exact purpose of this thread.
I started working out the Sleep code for a Tiny84 a while back, but never finished.
All Gen3 devices would benefit, since all have EN Pin.
We wouldn’t be limited to the 2-hour max sleep time for the TPL5111.
And the EN Pin will normally be the most efficient way to operate low-powered, low duty cycle, battery applications.

It looks like you are responding to an RFP.
If Particle could provide the Sleep Currents for the B-Series, then you can quickly estimate your Power Budget and nail down your req’d battery capacity.
If not, then your ATTiny (or similar) might be the only choice to meet the RFP spec’s. I’d be shocked if this doesn’t already exist (just not shared publicly).

15

Appreciated - then it will need to be some real world testing to see what your daily consumption is and then to contact someone like this to advise on the connect cell needed.

16

Thanks for your support @Rftop below is the sleep code I’m using… I would love to give credit but I can’t find the blog I got it from now :rage:

#include <avr/sleep.h>
#include <avr/interrupt.h>

void sleep() {

    GIMSK |= _BV(PCIE);                     // Enable Pin Change Interrupts
    PCMSK |= _BV(PCINT2);                   // Use PB2 as interrupt pin
    PCMSK |= _BV(PCINT0);                   // Use PB0 as interrupt pin
    ADCSRA &= ~_BV(ADEN);                   // ADC off
    set_sleep_mode(SLEEP_MODE_PWR_DOWN);    // replaces above statement

    sleep_enable();                         // Sets the Sleep Enable bit in the MCUCR Register (SE BIT)
    sei();                                  // Enable interrupts
    sleep_cpu();                            // sleep

    cli();                                  // Disable interrupts
    PCMSK &= ~_BV(PCINT2);                  // Turn off PB2 as interrupt pin
    PCMSK &= ~_BV(PCINT0);                  // Turn off PB0 as interrupt pin
    sleep_disable();                        // Clear SE bit
    //ADCSRA |= _BV(ADEN);                    // ADC on

    sei();                                  // Enable interrupts
    } // sleep

ISR(PCINT0_vect) { // This is called when the interrupt occurs
}
17

Looking at it further, I don’t think the battery you’ve picked is adequate for two reasons: it can’t supply 2A under anything but ideal conditions:

40%20AM
40%20AM1004×582 90.6 KB

And it will definitely not provide it at the minimum 3.6V for the u-blox VCC in the B-Series device.

18

That’s interesting HEng as the Saft LSH20 is the industry standard (in the UK at least) for powering 2G/3G battery powered data loggers.

I’ve just been concentrating on the Boron for now but, the minimum battery voltage is 3.3V and the Peak 2G current is 1800mA… using LTE this goes down to 490mA Max! Therefore 2A isn’t needed.

Saft rate the maximum continuous current as 1800mA with a 4000mA 1sec burst current.

Edit/
I’ve just read the B-Series datasheet, and I know it states “Make sure that the supply can handle currents of at least 2 A” why isn’t this a requirement for the Boron though as they both use the same u-blox chip?

19

Those are interesting points, I’ve found the Particle current requirements to be fairly over-stated in practice too, without much qualification.

You still have a voltage problem for that B-Series VCC line though.

20

Looking at the absolute ratings, it has the VCC supply voltage between -0.3V - +6.0V :face_with_raised_eyebrow:

I think time will tell with the B-Series, I’ve got a feeling the specs will change before release.

B-Series%20max%20ratings
B-Series%20max%20ratings560×534 7.54 KB