Wine bottle storage quality sensor

Question

Good evening all,

Background: I am final year Electrical & Electronic engineering student currently in the process of completing my undergraduate thesis. The thesis topic consists of making a low-cost, non-intrusive, battery powered electronic device that is small enough to fit in the punt (the under dome) of a wine bottle. This electronic device will be used to track the storage conditions (temperature, humidity, and ambient light) of luxury wine. A user-interface will be used to display the storage conditions. The aim of this device is to give confidence to the buyer that a wine has not been spoilt when bought at auction, wine retailers ect. I am currently busy with the hardware design, and I’ve hit a roadblock. I feel as if I’m heading in the total wrong direction. Any guidance/advice will be appreciated. I have chosen to use the DF robot beetle (https://www.dfrobot.com/product-1075.html) as the micro-controlling unit (MCU). The 5V MCU will act as the master and communicate with sensors (which will act as slaves) via I2C. The sensors which I’ve chosen are:

• Contactless infrared temperature sensor - https://neotronics.co.za/index.php?route=product/product&product_id=608 which will act as the main temperature sensor and will be pointed upwards through the bottle from 3D printed housing.

• BH1750FVI digital ambient light sensor - https://www.elechouse.com/elechouse/images/product/Digital%20light%20Sensor/bh1750fvi-e.pdf

• SHT3x-DIS Humidity and temperature sensor - https://docs.rs-online.com/c777/0900766b816bf6ab.pdf the second temperature sensor will act as a backup and ensure the main sensor is operating correctly.

The problem comes in with the battery. The device will be taking reading once every hour and then deep sleep will be activated. The goal is to use a primary battery (non-rechargeable) and attempt to get 1-3 years of operation time. I originally wanted to use coin-cells battery’s due to the low profile, but they are only useful in low current projects. I have settled on a 9V lithium battery which has a rather large profile (https://docs.rs-online.com/fabf/0900766b81549eff.pdf). The 9V battery will be connected to a switching 5V regulator (thanks to the comments) to power the microcontroller. An LDO will then be used to step down the 5V rail to 3.3V for the sensors. A PCB will be designed using Altium and housing with Autodesk inventor. UART will be used to communicate to the user-interface, or a removable SD card will be implemented on the PCB if there is enough space.

The questions I have are:

1. The battery solution is inefficient, I know that there are better approaches to solve this solution. What are the advantages of using an Arduino Nano (a much larger board) which has an input voltage of 7-12V and offers both 5V and 3.3V pins? In what areas is this solution be better than using the beetle?
2. How can I go about calculating the total power dissipation (deep sleep/ then active I2S communication) of the system? Will phyiscal testing be a more appropriate approach? I would like to use this calculation to estimate the potential battery life.
3. Are there any other microcontrollers that may be more appropriate for this context? An intrusive design is on the cards but the objective for now is to keep the design non-intrusive.

Any help/suggestions will be greatly appreciated :) Sorry for the long read!

Answer 1

Battery Capacity

The coin cell at the duty cycle you propose (1 sample/hr) should work. You only need it to last 27,000 samples in a 3-year period.

Let's say a 2032 coin cell has 265mAh capacity. That's 950 amp-seconds. Divided per 27,000 samples, we get 35mAs per sample. If the sample takes a second, you can draw 35mA average during that period. If a sample takes 10 seconds, the average draw can be 3.5mA. That's quite a lot of energy.

A low-leakage capacitor would be used to smooth out the current, and "hide" the relatively high source impedance of the battery.

The capacity rating of a 2032 coin cell has the end voltage at 2.0V. So you'll need an MCU that can go that low. It'd be best not to have to boost the voltage for the CPU. Boosting the supply for peripherals would be at least feasible if needed.

MCU

For the MCU platform, I'd start with something like AdaFruit Trinket M0, since the MCU can work down to 1.8V, has all the Flash you'd need to store the data, and supports very low power operation at low clock speeds. You won't need to perform a whole lot of processing on the data - probably each sample can be acquired within a couple hundred instructions. 64kHz clock would be feasible for that, perhaps. Or not much more.

Contactless Infrared Temperature Sensor

Seems like overkill. It's unlikely that you'd be able to measure ambient air temperature independently, since you're shadowed by the bottle, in a pocket with no air exchange. So just focus on measuring the bottle temperature contact-fully :)

Light Sensor

I would use a micropower R-R double op-amp and a photodiode, since that would work down to 2V without a boost converter. Or look for a sensor that can work down to 2V or thereabouts. Power it from a GPIO pin.

Humidity+Temperature Sensor

The one you chose works fine down to 2.2V, so again - no need for a boost converter. It takes less than 20ms to take a reading, at about 1.5mA max. No problem whatsoever. Power it from a GPIO pin.

You can get this sensor into physical contact with the bottle by using a flex PCB with the sensor "dangling" on a small PCB square that's connected by flex to the rest of the PCB. A 3D-printed case can have an integrated spring and a compliant pad that will press the sensor board against the bottle. The back of the PCB would be covered with a thermally conducive gasket.

Power Management

A CR2032 coin cell, with some judicious engineering of the rest of the system, should provide ample capacity for data capture over several years - likely much more than just 3.

It seems that a complete sample could be obtained within maybe 50-100ms, with peak currents not exceeding 5mA, and the average being more like 1.5-2mA.

The samples for each day can be stored in RAM, and then dumped to on-board flash once a day (or once a week if you feel like using even less energy).

The MCU provides extensive power- and clock management functionality, ideal for this application.

Answer 2

0. The 9V battery will be connected to low dropout voltage 5V regulator to power the microcontroller. Voltage division will then be used to step down the 5V rail to 3.3V for the sensors.

Any linear regulator will be inefficient, a voltage divider will be really inefficient, and will have poor regulation. A 3.3V LDO will be smaller than the resistors used for a voltage divider, so if you go there, you may as well use it.

You really want to use a switching regulator, but you'll need to shop around for ones with the lowest possible quiescent current -- and the market for those seems to be centered around devices with a maximum input voltage of 5.5V or so (so, see my next comment).

1. The battery solution feels inefficient, is there a better approach to solve this solution? --- I originally wanted to use coin-cells battery’s due to the low profile, but they are only useful in low current projects.

This application may be low-enough current for a coin cell, if you're careful. Especially if you stage the sensors so they're not all running at once. Also especially if you use a hold-up capacitor of sufficiently low leakage -- then it'll supply current during the sensor read portion of the product's cycle. Do your shopping very carefully here -- aluminum electrolytics are terrible, tantalums are pretty good, others are in between.

Choose a micro that runs on 3.3V and use a micropower boost converter.

2. How can I go about calculating the total power dissipation (deep sleep/ then active I2S communication) of the system which can then be used to calculate the potential battery life?

This ought to be in the data sheets for the various devices -- although sometimes manufacturers fall down on giving the detail, or the situation is complicated. For the micro and the display part, that's just current consumption all the time (unless you have a push-to-display switch). For the sensors, you need to turn them on, take a measurement, then turn them off -- so hit the datasheets hard, and calculate the total number of Coulombs you need to take your once-hourly measurement -- then turn that into an average current consumption.

3. Is there a totally different approach to take? An intrusive design is on the cards but the objective for now is keep the design non-intrusive.

This is definitely getting into open-ended opinion-spinning, so I'm not going to go into it other than -- yes, there's always different approaches.

Be careful in your sensor selection; the important thing is to get an adequate measurement for the least amount of energy used. If a sensor won't cut it, then find another one.