Open Source Vaping (Overview)

Here is a high-level block diagram of my proposed open source vaping mod:

(NOTE: Quite a bit of detail is left out at this level.  The big difference between this and most home-built mods will be things like temperature control, control over pulse width frequency, dynamic power adjustment during a vape, etc.)

First off, we all need to be concerned about intellectual property (IP).  So here we indicate that the radio communication portion of the mod is an "optional" component only to be added by a user should they desire to make or purchase one.

I spent some time and money working on a patent application sort of similar to this which was preceded by a prior claim (meaning someone else already had the same idea); I abandoned the application.

I think that without the radio portion the basic mod idea is reasonably safe as far as IP goes - but I am neither the patent office nor a lawyer - so you are own your own in the area.  It took some years for the patent office to even comment on my patent so I am guessing they have been inundated with various vaping applications.

The design above, in my non-legal estimation, is probably similar to any of a thousand Chinese mods that have been for sale forever.  ("Prior art" in the patent world is something that invalidates patents.)  Most all Chinese mods are basically something like this, perhaps with the "Processor" and "Coil Power Controller" combined into a single unit, e.g., "smart power supply."

Additionally, most of these parts are available in some form on their own at places like Adafruit or SparkFun.

The batteries can be any type, as can the "Processor."  I prefer Atmel 328P type 8-bit processors but you can use anything up to and including a full 32-bit Linux Odroid, for example.  Similarly, since both Android and iOS support USB connections the phone itself could be the controller via a USB-I/O module (for example this).  iOS involves some trickery and perhaps a bit of clever USB-type coding but I have made it work.  Here's some info, more will follow.

Buttons are expensive and cumbersome so I have working on an alternative.  First the PWM signal to the "Coil Power Controller" (basically a fancy MOSFET) cannot be triggered unless both the "Touch Safety" AND the Ribbon Controller are pressed at the same time.  I am using opto-isolation for the MOSFET to ensure "off" is "off."  The "Touch Safety" is a capacitance switch.  Both this and the ribbon can be covered with various non-conductive surfaces like plastic mod wraps.

Here's an example of a "Ribbon Controller:"

Instead of "Up" and "Down" arrows to control the mod output level this design allows you to slide your finger on the surface of the mod while the mod is running to adjust the power level.  At this point I am thinking that you set the minimum and maximum power levels, say 50W to 100W, either in advance or wirelessly and then as you vape you slide your finger around to get the flavor you want.

PWM-wise we want the user to control the pulse frequency (typically 2-3kHz for applications like this) in order to control "smoothness."  We found this out with the PrimusZ - people like a slower duty cycle in certain cases - though if it's too slow there is a "motor boating" effect.

Everything here, processors, radios, batteries, battery sleds, etc. are all non-vaping parts available at places such as those mentioned above or from places like Arrow or Mouser.  In Pennsylvania this means they are "dual use" items and can be taxed at the normal rate as opposed to the 40% vaping rate.

The "Radio Power Controller" is something not typically found on today's mods.  On the PrimusZ we found that leaving a radio, e.g., Bluetooth, running all the time quickly drained batteries.  We added a special circuit that shut the mod off after a period of time unless it was moved (physically): it allowed the mod to "wake up" very quickly and shut off after being set down (no, it didn't always work in the car but then again nothing is perfect).  This scheme worked pretty well.  In this case we apply the circuit just to the radio and add a feature to allow the "Processor" to keep the mod "on" - say for an over-the-air software update - until the radio is no longer needed.

The principles here have been well-tested over a couple of years.  I am open to other suggestions so long as reasonable, fact-based evidence is supplied.