Synchros MCU Boost Mod

[synchro]

Starting a new mod, most of the parts arrived today.  Will be breadboarding as I get time, back in class for my masters and kid made varsity volleyball so this may take a while....sigh.

Going to make a TI4050 boost mod with MCU, oled display and digital pot using the lipo 2200 mah 20 cell. Thanks to Craigs advice I will moving from I2C to SPI for the interfaces but sticking with arduino for now.

Hopefully this will lead to having PCB's built out and possibly a custom box for it since my case modding skills are shit at best.

Features I intend to include:

- N-channel mosfet controlled by the MCU on the battery supply end
- Overvolt, overcurrent, short circuit protection
- 1 amp usb battery charging
- oled display for volts, ohms, amps, watts, and battery monitoring plus warnings
- tactile switch input for volts up/down
- 3.5 amp limit but instead of shutdown it reduces output to within limits
- sleep mode when inactive that reduces current to uA levels
- custom warnings on the display that remind me of what a dumbass I can be
- anything else I think of along the way and the 16K of program space will allow me

Love this stuff, any advice is appreciated - especially with finding an appropriate enclosure when it gets to that point.

More to follow....

[CraigHB]

Sounds like a good one.  It will be a big project, keep you out of trouble for a while

[synchro]

Thanks Craig....I'll be bugging you for advice along the way...fair warning!

Funny thing is I'm not sweating the electronics, its the form and enclosure that I am worried about.

Going thru-hole for now just to get the function down, will be moving to SMT later which will give me an excuse to buy a Pace unit like the PRC2000.

[CraigHB]

If you want to make it small, you'll want to use SMD stuff as much as possible.  Space is a luxury.  When it's bigger, it makes things a lot easier, but then you have a big mod.  I haven't done any electronics projects using through-hole components for quite some time so I'm pretty comfortable with SMD stuff.  It's really not a big deal once you actually get into it.

When I started doing e-cig mods, the enclosure was a big problem for me.  With other electronics projects, the size of the enclosure is usually not an issue so you can just use a generic box.  That's not the case with e-cig mods.  You want them as small as possible.  I've learned a new skill because of it, 3D modeling.  I can whip out a model pretty fast now.  I submitted a new one for fabrication just the other day.  I was actually surprised how fast I was able to draw it up, only took a few hours.  Though it's expensive to have them made.  I job the models out for fabrication on an industrial SLS machine.  It's just a matter of uploading a file to their service, pretty much like having PCBs fabbed, but with STL files instead of Gerber plot files.

If you get creative and you're handy with machine work or wood work (which I'm not), you can make enclosures for almost nothing.  That's what most people do.  I'm probably the only modder that pays as much as I do for enclosures, but it sure makes things a piece of cake when it comes to box mods.  There's more options for cheap enclosures with tubes, but it's so much easier to fit circuit boards in a box so that's all I do.  I don't really get hung up on the cost.  It's still cheaper than smoking and I get something tangable out of it.

[synchro]

Thats cool craig and I really like the case you had made for your mod. 

I'm not handy with woodworking at all but have been talking to a vendor that is very good so I may just pay handsomely for a custom wood box when the time comes.  He even offered that I could wire everything up and he would do the installation which could be great or a total headache.

On your SPI bus do you use pullup resistors?  The digital pot I'm going with has some built in pullup capability but the display does not.  Wondering if I can get away with not using them.

[CraigHB]

I2C requires pull up resistors. SPI does not, though the SPI bus can drive higher value pull up or pull down resistors if you really need to.  For SPI, you normally float the bus.  That's the tradeoff, I2C is two way with 2 lines, but it needs those resistors.  SPI does not need them, but uses 3 lines.  Though, you can do one way SPI and it only uses 2 lines.  I actually use one way for the LCD and and two way for the digital pot.  I could use one way on the pot and it would work, but I read the pot back to verify it has responded correctly.

Of course, SPI is not nearly as flexible as I2C, but if you're only driving one or two peripheral chips, it doesn't matter much.  SPI has lower software overhead while I2C has lower hardware overhead.

[Pantera]

Are you using the EEPROM wiper memory on the Dig Pot or EEPROM from the MCU to store your wiper position?

[CraigHB]

Me?  I don't need to use EEPROM since the MCU is normally always powered.  I just store the pot value in the MCU's volatile data memory.  Don't need to store anything in the pot because the MCU handshakes with it every time before energizing the atomizer.

[synchro]

I take roughly the same approach, with the speed of the MCU I can send the digital pot a low resistance value so for the first few ms the atty is at 3.3v or so to check for shorts, opens and anything else undesirable.  Once that is done the user set value can be sent to the dig pot and check again for current and battery charge.  Even with a small pause this can be un-perceptable to the user.  The dig pot has volatile memory but the unit will check everything and setup once it resumes from sleep so no worries and in sleep mode the current draw should be around 10uA. Nice thing about the Arduino platform is that code for this is already widely available and optimized, just set the conditions to wake it and good to go.

[CraigHB]

I've found you can easily grab 50 ms before any delay becomes perceptible, and that' for visual queues.  That's an eon in MCU time.  For the atomizer, it's much longer.

[sterling101]

Absolutely - it sounds like ages until you try and measure it.
My pre-fire checks take just shy of 120ns and that's with grabbing multiple readings to average them out in case of drift.
Some people perceive things quicker, some slower but like Craig said, it's an eternity for an MCU and even longer for an atty that has to get up to temperature before it starts to do anything meaningful.

[synchro]

Sigh...someday I'll get some time to work on this...

[poorboy]

We'll be waiting for it sychro!

[SmokeRings]

Sigh...someday I'll get some time to work on this...

Did ya find the time yet synchro?

[synchro]

Unfortunately no, I'm in the home stretch of finishing my grad degree and the capstone / thesis work will consume my 'spare' time until late spring.  I'll get to it as I'm still really interested in the feature list, but it will have to wait a bit.