...better when the glass "bowl" area has been preheated. I don't think this produces vapor by conduction nearly as much as it reduces heat loss through the walls of the chamber...
yes, i agree -- and i think that's a good way to express what is going on.
i find the operation/performance of this version Bud Toaster far different from what i had before when it was a more typical log vape -- fixed resistance/fixed voltage/15 minutes to get to temp). And my understanding of the physics is certainly no better.
For example, the Bud Toaster can hit vape temperature of 385F in 20 seconds (with fresh batteries) to 40 seconds (last session on a charge), but it takes another 60 seconds before a serious vapor cloud is produced. Then from 90 seconds on to the end of the session, the vapor density is the same.
But there's a prickly issue that i've been trying to understand:
The temperature setpoint is higher than what the thermometer displays until the final minute of the session. Specifically, when the setpoint is 388F, the thermometer will start at 383F (when the green LED starts to flash, which indicates the computer is reading at or above setpoint) and rise over the next 5 minutes to rest at 388F. At which point the vapor is pretty tasteless and much lighter, though still visible. If i extend the session the temp will stay at 388F and only light wispy vapor is produced.
So i always adjust the temperature, if needed, during the first part of a session. Different dank need different settings. Normally i never have to change the setpoint.
So heat loss has been stabilized as the glassware gets heat saturated inside the metal heat shield. Also, i think heat is being removed as the trichomes evaporate their THC goo -- evaporative cooling, or heat of vaporization.
But here's the dilemma -- the customer is going to complain that the temperature is not stable. And there's no way i can measure the difference unless the computer can "see" the thermometer reading. Because the green LED is blinking on and off during the entire session, meaning the computer thinks it is dancing on both sides of the setpoint temperature.
So i've got to figure out how to spin this as a useful, even desirable, feature. Or, fix it in the code. Somehow.