Updating the Flora with a new design

Hi again

Right now I am leaning towards updating the Flora with the charge circuits and power supply as shown in “lithium ion charging solution A”. However I am unsure if this is a good choice.

In the flora notes it is stated:
“This is an old design, and uses an expensive low Iq boost converter. This works well, but burns 12μA of current at all times. We will be updating this design to use the Nora-style boost that is controlled by the imp, allowing a cheaper part to be used.”

So I want to update and share the design, but before I start creating schematics and board layout I would like to share my intentions -> i will probably get some valuable feedback and ideas to get me started right.

I have a two step “plan”.
At first I would like to just upgrade the power circuit as sugested and maybe also removing the thermister and replacing with an si7021 temp humidity sensor.

On the longer run i would like to

  • add possibility to charge the device lion battery by using a small external solar panel.
  • use imp002 or imp003 instead of 001
  • add a light level sensor such as the TSL2561FN

So i have been looking at the nora design and I have been looking at the “lithium ion charging solution A”.

It’s apparent that the nora uses another power supply then what is recommended in charging solution A. It appears to me that the supply used by the nora might be more energy efficient, but i am unsure of this and if it is so, then how much.

Also I am unsure about how the measurements (pulses from the schmitt trigger) of the water level, would be affected by potential dropping output voltage from the power supply. Which makes me wonder if I should use the more expensive LM3668 as recommended in “charging solution B”.

So would “charging solution A” be sensible for my applications or should I do something else?

If you’re using a Li-Ion, you need a buck vs the boost supply in flora/nora. There are various low-Iq buck supplies that will get you 3.0v from a lithium-ion cell about… not sure which of our reference designs use one though (the april one is high voltage capable and hence not low Iq).

On the other hand, if you’re continuously recharging you may end up with plenty of power…

As of right now I am not sure of how much power I can actually gain from the solar panel in the real life use scenarios the device will be exposed to.
Therefor I will try to aim for low power usage, also to give more headroom when choosing solar ‘panel’ for size and type (i like them sexy film ones for the shaping-possibilties they offer :smiley: ).

I have been looking at low-Iq buck supplies.
Stumbled upon this selection guide from TI

Which got me looking at the TPS62740
it features ultra low Iq typ. 360nA
Suited for use with rechargeable Li-On batteries and thin film solar modules.
It’s somewhat expensive thou.

The selection guide also got me looking at the TPS62240 which has an Iq of 15uA but features a Power Save Mode where current consumption is reduced to 1uA.
This one costs about half, but its an older model and i am not sure how exactly to utilize the power safe function. How do i get it back on when the imp and everything else is sleeping?

So currently i am leaning towards trying out the TPS62740.

Any thoughts on this?

Also for early prototypes, I think I will go with this 4V solar panel

I have also been looking at some of the new interesting charing and powering solutions for energy harvesting devices, such as the BQ25504.

It looks very interesting, but I am unsure if it can operate alone to both power the device and charge battery or if I will still have to use a buck supplie alongside the BQ25504 charge circuit.

From this schematic from the data sheet, it looks like the BQ25504 is both charging a battery and regulating voltage to supply a load.

Would be great if I could just use the BQ25504 and spare the expenses to the buck

Dont’t think the BQ is regulating anything. It’s just allowing the load to come from CSTOR if it’s low enough.

62240 should work, though it’s a little tight for the imp TX peaks at 802.11b.

Hi again, thanks for the feedback, sorry for my late reply.
Reading around on the net about energy harvesting solutions got me delayed at first and then i fell into a pit of “how to accurately measure soil moisture content” :-).

Aaanywas right now the schematics design is a little bit at a hold while I am trying to figure out the best way to go about it.

I have been thinking about merging the chirp moisture sensor with the nora design. Maybe add a charge circuit.

Hmm, the flora design does much the same (but the frequency varies with capacitance). I suppose the difference is that on flora, the frequency will vary depending on the exact thresholds of the inverter…

Apparently when measuring soil moisture content using capacity it is best to use a high frequency, 80MHz is often seen used.
ATM the chirp does not do this but operates at a lower frequency, but I was hoping to figure out a way to ramp up the frequency.

The reason why high frequency set up is best lays on the fact that the dielectric constant is a complex number, i.e. a real part + imaginary part. The real part is dependent on soil moisture but the imaginary part is dependent on the conductivity of the media and it is inversely proportional to the frequency. By using high frequency sensors (on the MHz range) you get rid off the unwanted salinity contribution on the total dielectric constant.
Heres a paper about it

This has also led me to a question regarding input and output frequency capabilities of imp’s pin1, which I cannot seem to find in the datasheet, i found this forum thread however, and it looks to be somewhere around 20-30Mhz tops.

Very interesting! Yeah, the Flora was really not designed with much soil science and in fact was only ever used embedded in a rabbit’s feeding bottle to determine how much water they had left. It works great for liquid levels :slight_smile:

Somehow the chirp sensor is affecting my circuit so more power is drawn even when i cut power to it with a power gate.

I have a small circuit running on breadboard utilising an april board and the circuit in the picture.

NOTE: right now I do not have the discharge path in the power gate. Will add that tomorrow.

Without the Chirp, with imp in deep sleep, i measure current draw of 0,02mA
With the Chirp, even thou power gate is off (deep sleep), i measure current draw of 0,30mA.

This only happens if the Chirp i2c lines are connected, if SDA and SLC are not connected current draw is 0,02mA.

I then added the i2c isolation (nora v3 style), because i figured it might be the ATtiny44A on the chirp which clammed SCL an SDA, but it did not help -> still 0,03mA in deepsleep.

Now i am considering making mosfet gates to disconnect the SCL/SDA to the chirp when it should sleep. Will propably try that tomorrow when im back in the lab.

Any ideas?

We removed the i2c isolation chip, and altered the i2c pull-up resistors to connect to 3V0_SENS from the power gate instead of directly to the VBAT/3V0. Now we’re down to 20uA in deepsleep. Great! :slight_smile:

We’re a little bit puzzled about the need of the drain pin (SENS_DRAIN) though? The documentation states that it’s not needed for applications with long enough sleep cycles for the sensors to drain by themselves. What happens if the sleep period is too brief? Bad readings? And if we have enough available pins, maybe it’s just a good idea to implement it in order to support short sleep cycles if needed? :slight_smile:

We’ll hopefully post some updated schematics soon!

If the sensor supply rail doesn’t drain completely, then the sensor is powered up again, it could be in an indeterminate state as it did not get a clean rising edge on its power rail.

Hence, actively sinking current with SENS_DRAIN can help.

Does depend on the sensors in use, though.

Thanks Hugo! Guessed it was something like that, but now we know for sure :slight_smile:

Nice spreadsheet, but note that the L91’s have a much higher average voltage - more like 1.6v - than you’ve quoted, which means better battery life :slight_smile:

You should also be able to get a LOT lower in terms of the shallow wake time, though this affects the battery life quite a bit less due to the lower power consumption in this mode.

Just an update.
ok so we have breadboarded and testet everything in the schematic, except for the SI1145-A10 light sensor (did not have one in stock), thats why the TSL2561 is currently on the board.

I will send gerbers to PCB production one of the following days, please tell if you see any obvious erros in schematic.

We did some measurements of current draw on the breadboard prototype. The board has three power states, sleep, collect data, transmit data.
Rough average current consumption in each state:
Transmit: <80mA
Collect data: <10mA
Sleep: <8uA

And we created a spreadsheet to see how wake times, transmit intervals and voltage affects battery life. This spreadsheet might be helpful to others

Hello Hugo

What do you mean when you say “shallow wake time”, is it what I called “collect” in the spreadsheet?

If so we are currently in that mode for about 500ms, most of which is waiting for reliable readings from the moisture sensor (we probably do not have to wait this long, but some testing will be needed in order to tweak it)

And sweet with the batteries btw! I dont have any experience with them, so i took conservative precautions.

https://github.com/bobbyziom/chirp-nora/tree/master/src/firmware/production

This is the program that we’re currently using for our test design. The pressure sensor and accelerometer is not implemented yet. We want to use the accelerometer with wakeup interrupt for a simple tap user interface to get current conditions feedback from an LED, without using the computer/app. Right now it wakes 5 times and collect data for around 6-700 ms, and go back to sleep as seen in the spreadsheet. Online time is between 4-7 seconds for sending everything from the nv table to the server. I’ve not made any test on nv table capacity yet though.

I’ve prepared for uploading the data to keen.io, but I still can’t connect to my agent, which we’re also talking about on this thread. I’m eager to log the operation intervals for testing data to put into the spreadsheet :slight_smile:

Thanks again for your feedback Hugo!