EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: Sral931 on August 26, 2024, 10:13:11 am
-
This thread is about my battery driven self-heating-mug v1.
Main outlines:
- 50°C drinking temperature
- 100°C Resistor temperature (typ. 40K above fluid if not empty)
- 10W nominal heating power
- 3 or 4 power resistors glued to bottom with heat conductive glue (TO-package, 1.0 to 1.2 Ohm total
- resistors will be thermally isolated by the following stack: (mug floor - heating resistors - silicone - 3D printed wall - standoff - PCB - soft buffer - battery - stainless steel bottom)
- 3.7V LiPo Battery > 3000mAh
- (I am thinking about wrapping the battery with some PCB or similar to lower the center of mass and have some thermal mass in the event of a battery fire)
- small-ish MCU (currently Pi Pico W for legacy reasons, will be upgraded to something like SAMD21 down the line)
- main control interface 0.9" OLED screen and 3 Buttons
- WiFi Webserver (for legacy reasons)
- housing (might) be re-designed to expose the components visibly on the mug's side though transparent housing
I made a v0 proof-of-concept prototype some time ago:
(https://cdn.discordapp.com/attachments/910972192077021234/1194326421842182254/IMG_4146.jpg?ex=66cd5ee8&is=66cc0d68&hm=cff18901a76bd4f37d791e3feef881d95de2c07daa3513aa96a8ae54363a315f&)
Worked well enough, but had a few ... inadequacies. It was hard to handle and the DS18B20 temperature sensor network (3 sensors on a 1-wire bus) failed for some reason.
I started working on a v1, where the hardware was better contained, so I bought a couple of double walled steel mugs and cut the bottom off. A colleague designed a 3D printed housing to fit in between, this is the test-print for comparison, the final print will be with something a bit more temperature resistant. My colleague bought some PC or CPE+ iirc:
(https://cdn.discordapp.com/attachments/924775281477181470/1235556277736964166/IMG_5148.jpg?ex=66cd1234&is=66cbc0b4&hm=c122e8729d1569907c72aa812e6f7cebbc8b64869be88adf77653e09e99c57be&)
I'm currently botching together a PCB-design using EasyEDA to have it manufactured by JLCPCB ... no idea if the price will be to my liking, but my current thinking is that I have no infrastructure or experience to make PCBs or solder SMD components, so having up to 10 pieces completely manufactured might be OK compared to buying SMD solder equipment for just this project.
The circuit schematic and PCB is attached as PDF files ... not sure how this typically goes, it's simple enough so I will stick with the PDF for now. I can upload different files later if needed.
The PCB outline is currently just a guideline to how much space I have inside the mug (ID ~ 65mm)
Standard trace widths are:
- Heater Lines 3.0mm (=> max current ~10A @ 1oz, 4A are utilized)
- Charging Lines 1.5mm (=> max current ~5A @ 1oz, 1.2A are utilized)
- GP Lines 0.3mm (=> max current ~1A @ 1oz, <0.2A are utilized)
Working principles:
- Electric interface will be a USB Type A socket, supplying 0.5, 0.9 and 1.2A of current and a data connection to the MCU
- Power Input is PPWRUSB
- Data Input is PDATUSB
- ==================
- BATTERY CHARGING is handled by a charging IC (currently a MCP73833 for legacy reasons)
- charging IC is interfaced with the MCU through GPIOs 1 through 7
- GPIO2 through 4 switch the charging current (1.2, 0.9 and 0.5A) by using the GPIOs as drain transistors (1/1000 of load current, so GPIO current of <1.2mA)
- GPIO1, 5 and 6 detect charging state (GPIO1 is PowerGood [PG], GPIO5 is IDLE/DONE, GPIO6 is CHARGE)
- ==================
- POWER DELIVERY to MCU is done through:
- direct 5V connection to PPWRUSB or the Push-Button PPWR and the pMOSFET Q1 to protect the battery from 5V (MOSFET handles >300mA iirc, pico W draws < 150mA)
- INTERFACE is done via a 0.9" OLED screen connected to Header J1 using I2C
- (draw at full brightness should be well below 36mA, taken from here (https://bitbanksoftware.blogspot.com/2019/06/how-much-current-do-oled-displays-use.html))
- USER INPUT is done with 3 momentary Push-Buttons on PB1 through PB3
- ==================
- SENSOR INPUT covers total Battery current, half the battery voltage, 4 thermistors and a fixed ADC characterization input
- total Battery current is dropped over R11, a 2mOhm Shunt resistor with larger package that can handle >10A, irrc
- shunt voltage is amplified by the current measuring IC U3 that amplifies by 50x with low input offset
- (maps 0-4A load current to 0-0.4V, giving me around 1% resolution steps on an ADC with 10bits effective resolution)
- Battery voltage is MUXed onto the input ADC using the pMOSFET Q3, dropped over a 10k resistor
- the complementary 10k resistor is R17 that will divide the battery voltage signal through GPIO11
- Q3 has a threshold voltage of around 2V, MCU can supply 3V3, battery is between 3.0 and 4.2V, so the MCU GPIO should be enough to keep Q3 off
- (I should probably not be so frugal and just slap it with a pull-up resistor and a pull-down BJT)
- 4 Thermistors will be connected to GPIOs 16 through 19 using PRTH1 through4
- (Temperature points are: mug floor, heater package, battery and one I have not determined yet, maybe PCB temperature)
- the complementary Resistors to form a resistance bridge are R13 (2k) and R17 (10k) connected to GPIOs 10 and 11 respectively
- switching the GPIOs in this network i can MUX VBAT and the 4 thermistor signals onto ADC1
- R13 with 2k gives me most resolution around 50°C and activating R17 with 10k additionally allows me to avoid the ADC Differential errors of the Pico
- ADC_VREF of the Pico is shorted to 3V3 to give me the full 3V3 measurement range (noise will be countered/used with oversampling and decimation)
- GPIO12 is permanently connected to the ADC characterization to somewhat counter the Pico ADC's horrible ADC Nonlinearity steps
- Low pass a PWM though R12 (10k) and C3 (1u) @ f_c~100Hz with a drive frequency of 30kHz to translate PWM timing to a linear voltage reference and record the ADC's nonlinearity
- ==============
- HEATING is controlled using the TO package power nMOSFET Q2, controlled using GPIO0, limited to < 30mA with R10 and pulled to GND for security
- the PCB is still missing the GND-Back plane since it's a kind of WIP
- the PCB outline is currently just a size reference for the ID inside the 3D print, I will likely make it rectangular with 2 screw holes
Please let me know what I forgot ^^
I tried to follow general commons sense that I could extrapolate from my bits of electronics "knowledge" and some guidelines from watching 1 or 2 YoutubeVideos. I should probably have researched a bit more, so please let me know if you have a few sources that I should study or direct advice you would like to give me.
All help is appreciated and thanks a lot in advance ! Feel free to ask anything.
-
Updated a few infos that I missed in the first post ....
-
The main question I have: Is it overengineered enough without RGB lighting, blockchain and an integrated magnet stirrer? >:D
Beside that: I´d put some thermo-fuse or thermo-switch in series with the heating resistor. If you are really sure that your code is always working and GP0 is in a defined state you can of course do it without, but I mostly don't trust I/O pins of evaluation designs to be in a certain state. I´d insert a physical switch into the battery circuit for the same reason.
Beside that... You could connect a buzzer so that you have an automatically triggered tea timer. Or it could warn you if content is >80°C while moving it.
-
Well ...
I have a few LED's in there, i might make the PowerGood LED blue, is that RGB enough ?
Blockchain might be possible as well ... WiFi connection and I can make one Core mine Crypto during idle cycles.
Magnetic stirrer will be the inductive heating upgrade down the line ^^
Thermo-Switch is a great idea ... do you know a good IC for that ?
I might combine that somehow with the current, slap a comparator in there to ensure max current and max temperature by pulling the nMOSFET gate down.
The nMOSFET gate is pulled down by R8 regardless, if the user pulls the USB and disables the power button, that should deactivate the MOSFET if there's no short.
Buzzer is a good idea as well for emergency reasons. Need to see if i can get a small enough one to fit on the PCB near a free GPIO and whether that's even detectable through the housing.
Might make it play some Rad 8bit music as well >:D
-
Well ...
I have a few LED's in there, i might make the PowerGood LED blue, is that RGB enough ?
Blockchain might be possible as well ... WiFi connection and I can make one Core mine Crypto during idle cycles.
Magnetic stirrer will be the inductive heating upgrade down the line ^^
Thermo-Switch is a great idea ... do you know a good IC for that ?
I might combine that somehow with the current, slap a comparator in there to ensure max current and max temperature by pulling the nMOSFET gate down.
There are a lot of SOT23 chips like ADT6401 for this purpose. Or just something mechanical like http://electricprotector.com/2018/1-3-amd-thermal-protector.html (http://electricprotector.com/2018/1-3-amd-thermal-protector.html)
GP0 is pulled down by R8 regardless, if the user pulls the USB and disables the power button, that should deactivate the MOSFET if there's no short.
Are you sure GP0 is low during bootloader operations and what happens if the RP2040 freezes? Okay, probably you smell it overheating before anything really bad happens, but anyhow: I´d equip all heaters with a redundant limiter.
-
Thanks a lot !
I'll have a look at fitting an ADT6401 or similar on the PCB, should be cheaper than a bimetal strip relay. It has about 100Ohm internal resistance on the open-drain though, so I might have to increase the gate resistance to make it work. The bimetal strip on the other hand has the added benefit of acting as a current limiter, if I'm not mistaken.
Good point on the boot(loader) state, I have thought about it, but not looked into that yet. Doing that now:
Reset state of all my used GPIO pins seems to be pull-down (~50k iirc), Boot sequence resets the controller before entering the BootRom, so I'm guessing that both on reset and entering Boot-mode GP0 will be pull-down.
The RP2040 has a Hardware Watchdog that can reset the MCU, I'll definitely use that. Another approach might be to additionally pull the EN/RUN pin low with the ADT (possibly over a capacitor to make it single fire, if that's possible without crossing current limits and comfortably reaching the hold time on the EN/RUN pi).
I'll give that some thought.