SSV

We provide custom TCR (normalized TFR) files for our Titanium. You can download here =) http://www.sweetspotvapors.com/category_s/1856.htm Enjoy...

Thank you. We want to give our customers the best possible experience. Evolv has given us the tools to do that, so why not do our best to exploit them. So far I am pretty impressed with the system, and I imagine it will only get better, as it matures and the bugs are worked out. I am also a bit concerned that 3rd party manufacturers are not calibrating their case thermal properties, mod resistance, and battery discharge curves correctly.....I have seen multiple eScribe sessions now, that users claim are defaults, that have totally wrong and/or mismatching settings.....especially with smaller battery packs, the manufacturers should be setting them up to not overpeak the packs, and the cell cut-off should be around 3.2 V. Everything should be tailored to maximize charge (cycle) life, in such small packs....and certainly the devices should be running the same basic bootloaders/.ecigp files.....not sure what is going on (could be end user error). This is sort of the double edged sword with eScribe and allowing end users to modify things like case thermal, mod resistance and battery curves....things can get messed up FAST (if end user doesn't know what they are doing yet). This is why we want to make our SSV editions load from production utility....that way if anyone gets lost they can easily go back to our known/calibrated defaults

Also the thermo electric properties of the enclosure and 510 connector assembly are important.....I.E. how does a resistive change, due to heat/temperature/work, change calibrations etc....it's not just the change in resistance in the wire, but residual heat in the enclosure, and drift in resistance of the chassis/510 assembly....ideally the 510 connector is isolated form the case in some way (thermally and electrically) and same for the board....that way as the case drifts in temp etc the effects aren't as dramatic in the signal path....that's essentially what we are trying to quantity and calibrate against (null against) So in the mad modder dna200 we have fully characterized the system, between 20 deg C and roughly 50 deg C.....we are expanding those windows to lower and higher temps, and that is the next stage in developing the calibrations/curves etc....the 20 C to 50 C window represents the largest cross section of potential scenarios, but doesn't cover freezing cold conditions or extremely hot conditions....that's the next step, but we had to build custom enclosure and jigs to measure that (in a thermal chamber), and those custom assemblies/test jigs need specific temp probes....so we are waiting on some non conductive fast response probes for those specific ranges right now.... the easy way around that would be a 3/4 wire RTD controller, that could null those properties (the way a standard milliohm meter or RTD thermometer work), but we are all stuck with the 510 connector, and that is only 2 conductors (one complete loop), so we can't send out a heater current to null against.....that means it's important for us to determine the standard deviations, and take them into account....especially since our wire is unique and the normalized resistivity slope is more granular than with Ni200....Ni200 is easier to calibrate against, because the changes in total resistance are more dramatic, so the margin for error is broader....but if you have a heating element that changes 0.1-0.2 ohm total from rest to max temp, and then you have a 510 connector that also changes from 0.028-0.04 ohm (between 70 deg F and 150 deg F) then you have to take that into account as well....as the added standard deviation is 0.012 ohms, plus the total resistance and the standard deviation in the wire itself.....a 0.012 sDEV is enough to throw the temp target window off by a bit.....how much is what we are finalizing....in some scenarios it could be relevant, in others not as much....but guessing isn't exactly science....=)

here is the simple CSV data (including a rough custom screen), if that is all you are interested in....please keep in mind this is calibrated/normalized against the 70 deg F reference point, and we have not finished the "ice bath" calibrations yet (below 70 deg F)....we are waiting on some new probes to determine standard deviations....we aren't simply calibrating/referencing temps with ONE probe on the coil surface....we are trying to determine sDEV across multiple scenarios, and temperature gradients across the entire coil surface....including dual coils, clapton coil, twisted etc etc etc scenarios.... this isn't just about providing a simple normalized TCR for a straight strand of our wire....that doesn't really "cut it" IMO.... please keep in mind that the mod resistance, thermal properties, battery discharge curves etc etc can't be provided in a simple CSV (TFR) curve.....so it is very important to know, or rely on the manufacturer of your SPECIFIC box, to provide you with these null parameters....for example the FDV v4 510 connector assembly + mad modder wiring+box etc, constitutes roughly 0.028-0.04 ohms of resistance, which has thermo-electric properties of it's own....if that isn't taken into account, it's hard to guarantee a +/- XYZ deg F window of accuracy.... The goal of our complete installer/package is to provide ALL of these parameters, so you wind up with a consistent "window" of error/offset.... Profiles.zip

The csv is only the tip of the iceberg in our calibration.....the csv is in "beta" with the rest of the cals....what we are doing is not only providing TFR curves for each wire, but also mod resistance nulls, case thermal calibrations, battery calibrations etc.....they are all packed into the production utility which will all go live on our site (custom screens and all) as soon as beta is confirmed....it's not as simple as just passing out a CSV file, it's ensuring that the mod resistance etc is nulled, and packaging everything into production utility, and being able to offer some form of support/warranty that the fundamental changes aren't going to void a warranty form manufacturer etc....if anyone wants the beta package I'm happy to provide it, but it's a use at your own risk situation for another week or two.... you can feel free to PM me or if evolv wants to open up a section for us to drop the files into a database, for download, I am fine with that.... keep in mind this is being done as a "free of charge courtesy" for our customers, so I don't think it's quite fair to be too demanding about the project (we are def doing our best for our customers though).....as we have spent a very large sum of resources (equipment, time money etc) into providing this as a "free" service.....and frankly I don't see anyone else doing it (this way, specific to their wire)....our goal is to support not only the wire, but our wire WITH ALL dna200 3rd party mods....simple TFR curves don't completely calibrate the device.....I would ultimately like to see a section on our webpage, that has a discreet installer package, to "convert" each 3rd party mod to an "SSV edition"....that has a sample device as a known point of reference (for accuracy)....I.E. Ronnies, Mad Modder DNA200 will be the first complete "installer/package". It basically assures the device is accurate in a specific application (with each of our wire products). So as we acquire 3rd party sample/reference boxes, we can add to that list of supported devices....I understand that a lot of people who are here are more tech savvy, and all they need is csv data.....but we have been giving out beta files for a week or so now, and are quickly discovering your average vaper is going to have a lot of trouble with eScribe (when all they want to do is "make it work and vape"). With the production installer utility, and our package (.ECIGp file) we can assure that if an end user gets in "trouble" they can always go back to defaults, and those defaults will be our own in house "guaranteed calibrations/datasets"... Please be patient, as not only is this an engineering effort, but also an effort to work directly with manufacturers, to fully support each specific dna200 mod that comes out.... here are the beta packages for mad modder dna200 box....

metric = set of parameters....I.E. 70,1 (temp, res).... for example.....is this plot a total of 9 memory points, or 8? I am assuming 9, according to your description....

points = metric 1 and the final metric correct? Not splits? so starting metric and ending metric = 2 points or 1 total?

our Ti-Wire is not such a dramatically different TCR that it would cause anything more than a few deg of drift in the median range, and on the sx350J in "Ti01 mode" the peak temp is still less than 20 or so deg discrepancy....we've been running it on the dna200 test bed with both our own profiles/TFR/TCR and with OTS "gr1 ti" TFR from steam engine.....no issues at all..... It is possible something is shorting.....I experienced some VERY odd behavior the other day when using a standard k-type thermocouple to take a basic reading....I accidentally touched the probe tip to a live coil, as was expected the impedance changed and the coil ran away.....but the odd part was that even after cooling (res was locked BTW) the coil still exhibited the same behavior....I re-initialized everything and still the same runaway temps.....only when I un-mounted the coil and pulled the battery and re-installed everything in the test jig, did everything go back to normal....

here is a more detailed analysis of the "knee" in the pre-heat window..... Preheat power = 100w Preheat punch = 1 (soft knee) Preheat Time Limit = 5s

Gotcha... Would be nice to nail down an apples to apples acquisition protocol for the scope.... I only ticked voltage in DM.....would be nice to be able to see statistics for voltage over "last puff" params.... What I am trying to do is develop a relatively time correlated acquisition system, for DM vs external measurement.....we should be able to get relatively close granularity in the measurements, as the Atmel MCU on the dna200 (haven't bothered to put it under the microscope and read the PN) and the WRMXi (scope) are both roughly 12-bits of acquisition data (the LeCroy is running in eRES mode, which is 12 bit effective interpolation). The MCU is 10 bit a/d? (but i am assuming some interpolation is happening between the serial data stream and DM?) The most interesting thing I noticed was the difference in ramp-up in the curves....I am going to assume the softer knee in the scope waveform is due to the input capacitance of the scope.....the probe is only 1.8pF. EDIT : X Y parametric data would be very helpful in the DM graph....especially if it correlated to "industry standard' scope params (plus grid)....I.E. amplitude over time, with zoomable incremental steps.....I know you guys aren't trying to build a "scopeDuino" here, but it might be valuable for targeting inconsistencies in heating (due to load non-linearities). I've managed to get around the lack of a programmable hysteresis window, by moving TCR split points around a bit....not ideal but it works, when trying to "dance" around any consistent decreasing slopes.....obviously we are going to all run into the very real problem of the enclosure/board/signal path drifting (due to thermo-electric effects)

Here is a simple comparative analysis between device monitor data logging and an actual oscillogram. The scope input is smoothed over 5 sweeps, sin x/x interpolation, and bandwidth limited to 20mHZ. The function measured is simple voltage.....honestly not too bad for a consumer device. I wish there was some documentation on device monitors acquisition parameters (especially polling rate and how much smoothing is applied to the curve). P.S. This is a scripted 5 second "puff", and the plots are relatively time correlated

Here is some confirmation data of dna200 USB charge accuracies. The current source is a simple PSU set to 5v. I can confirm linear scaling in the charge current as the voltage is reduced.....the oscillogram is of the USB data lines (floating) int a FET probe, on the LeCroy. I repeated numerous fault conditions in both the data and power lines and there was no erratic behavior to mention. Current always capped out at around 1 amp. Shorting data lines lead to no erratic current spikes either. The discrepancy between OSD and DMM is USB cable losses. I purposely used the lowest quality USB cable I could find, so 20/30mA losses along the cable seems about right. Hope this information is useful for some. At the least it shows a large degree of confidence in evolv dna200 USB charge capabilities and controller......kudos evolv for building some decent BMS.....

Is there a way to zoom on the graph/curve? Right click seems to be working to enter a fixed value (thanks, been looking for that for a while now)... As far as being normalized, I am assuming they are normalized against the curve....is there a specific formula to follow there? Or just business as usual? I do have min max defined and the dna200 is without doubt right on target.....overshoot on our 0.5mm wire (built a full cal profile for it some days ago) was only around 4 deg F. Having the median ranges out to a 10/12 bit range should be adequate....will report back after I get some finer numbers into the scale....

I agree with Macz and also there is at least one titanium vendor who stated that he was going to have specific values for their wire. It would be in the end if all wire vendors do this.[/QUOTE] we are already working on it, but evolv needs to add granularity to the curves in eScribe....the 0.1 ohm incremental are not fine enough to get tight cals....