James

It sounds like one of your batteries is fully charged and the other is not. If one cell is at 4.2V and the other is at 3.8V, the DNA will need to rebalance the cells. This is very slow. It can only charge quickly if the cells are nearly at the same state of charge. Let it try and charge for about 24 hours, and see if the cells become closer. Once the cells are balanced you should be fine.

Do you have a mod resistance set? Maybe it is set inaccurately high. That can cause a cooler vape.

soulvape, if the automatic firmware update fails (what it sounds like), have him go to Tools->Apply Service Pack and choose 1.2 SP3 manually.

I've posted up an EScribe that should fix the VaporShark charging issue that 1.2 SP2 had. It also fixes the bug with Copy Profile and the Watts profile.

If the setpoint is 450F and the DNA is spending 75% of its time at 449.5F instead of 450.5F, it still ought to display the message. The purpose of messages is helping people not math. As far as overshoot goes, the new firmwares have a "Temp Peak" option in Device Monitor. That shows the maximum temperature observed by the temperature protection code at any point during the puff.

Ah, I see. Disregard that update, it's only for one of the two variants of the VS board (the one I was able to reproduce the problem on). I suppose most people do have the other one. I'll post a different one later today.

Someone try this. It's a single value change, nothing big. The current sense amp and charger are right next to each other on the VaporShark board, so the code was getting confused by a bit of electrical noise. Easy fix. Let me know if this works for you and if so, I'll put it in a quick update tonight. EDIT: Need to make one for both variants of the VS board.

It worked fine on my VS DNA 200, as well as Nick's. No problems charging at all. What are your cell voltages at, and your USB voltage? Of course if your batteries are nearly full, the charge will not be at 2A. Hmm. What kind of chargers are you using? I am using an Aukey Quick Charge 3.0 single port and the charge port on a 7-port Anker USB hub.

aonoukraine, I am curious, why do you say according to the core wire? I may be extremely tired from coding, but I believe you'd do a custom curve in Steam Engine with the two wires considered to be electrically in parallel.

It does that right after a firmware update. I believe it's due to the cell balancing being active when the firmware update completes. Reboot it and it'll be good from then on.

What version of Windows are you running?

If 3V is not giving you trouble it certainly can't hurt to be at a higher voltage, especially since you are interested in battery cycle life. E-cigarette batteries tend to lead hard lives, though Samsung INR etc. 75W capable 18650s are generally quite happy at that voltage. Keep in mind also it's under-load voltage, so the battery is not at 2.75V unloaded unless you vape at... very... low powers. At 15W I lose about 0.2V just in wiring, meaning at 2.75V the battery itself is at 2.95V. If the only issue you are finding is Weak Battery messages, FWIW, we'll be making a patch to make that message less eager during preheat. Some 18650s have trouble holding 75W when they get low, but if they're still preheating at 70W, the message is more annoying than the problem, especially if the condition causing the blinks only lasted for a quarter second.

We set the default soft cutoff down at 2.75V on DNA 75 for just this reason. Wiring and battery box voltage drop at high currents can be quite significant (and internal resistance, of course), even when the battery has plenty of charge left.

We can fire just fine from LiFePO batteries (our soft limit right now is 2.75V, our hard limit is 2.50V). Our charger chip, however, charges batteries up to around 4.20V. 3.60V is the ideal termination. We do have the ability to disable charging, by which technically we could limit it, but even if we did, if the board got into a failsafe mode (failed firmware update etc.),the battery would be charged to 4.20V... Now, a quick Googling finds http://www.powerstream.com/LLLF.htm which claims LiFePO batteries can be safely charged to that level, but I haven't seen that anywhere else. There was less demand for LiFePO on the 200 than I'd expected so I hadn't really looked into it for the 75. Beyond the charger issue, I'd also wonder if any LiFePO batteries can handle the current demands of the 75.

black lace, what are you talking about? His graph is showing the setpoint. That's the Up button most likely.

Howdy all, The 2016-04-25 firmware for DNA 200 that some people have been trying is an experimental version. Please do not install it -- it is known to have problems. When we have new DNA 200 firmware ready for public test, we'll put it in the Early Firmware thread like we always do. Thanks! James

This happens on a DNA 75 as well? What happens if you wait a few minutes before removing the battery?

You can get back to earlier settings. After it downloads the settings, click Upload Settings with the earlier firmware installed. It will upload appropriate settings for that version.

Hmm. Could you please PM me your mod's serial number? I'd like to see what the file Restore Defaults is getting looks like. Thanks!

You are all using the 2/29 EScribe?

coggledots, what do your battery voltages read for the two batteries in Device Monitor?

Hmm. If you are vaping a low-Ohm coil, make sure you/your manufacturer have set a correct, non-zero mod resistance. If it's zero, you may be losing significant power in your 510 connection and wires. The DNA 200 is designed to deliver at most 200 watts to the *atomizer*, but if you are losing 10% of your power before it gets there, this is a viable way to correct the problem. The DNA will happily deliver the needed extra power, subject to its input and output current limits (which, to ensure safety, do not change -- the appropriate wire gauge depends on current, not power). For example, if you have a 0.1 Ohm coil and a 0.01 Ohm mod resistance... If the mod resistance is set to 0 Ohm, 200W is 42.6A. The output will be 200W, but 18W is lost to mod resistance (reviewers tend to ignore this, but the quality of the 510 has a real effect on battery life at higher power...). The atomizer will receive 182W. If the mod resistance is set properly to 0.01 Ohm, 44.7A will be delivered. The output will be 220W, with 20W lost to mod resistance, for 200W to the atomizer. So, this is not a way to get more than 200W on the atomizer, but it *does* let you get 200W where you might not be otherwise.

JayFlair, is your Watts Hold Increment 1W? The slow down is actually a speed up versus how fast it is adjusting 0.1W, just in larger chunks. Did you like the old, speed-up-quickly behavior better?

MADMODDER, did you change any particular settings? Or was it with a particular update? By any chance do you have a multimonitor or docking station setup? Thanks! James

I hear tell a few folks were wondering about the Run Script feature in Device Monitor->Diagnostics->Advanced. This is mostly meant for scientific study, automation, testing, etc. The scripting language is IronPython so you can use normal Python libraries to save files and such. The script runs in a background thread while Device Monitor is running. As a reference, here are the functions available through the Python scripting at present: ECig.Puff(time) Time is in seconds. ECig.ClearTracking() Removes all variables from the graph. ECig.Track(state) Adds a variable to the graph. ECig.IsTracked(state) Returns True if the variable is on the graph. ECig.StopTracking(state) Removes a variable from the graph. Recorder.Record(filename) Starts recording a CSV file. You can't change which variables are on the graph while recording. Recorder.StopRecording() Stops recording a CSV file. Recorder.IsRecording Returns True if the Device Monitor is recording. Serial.Open(portName) Serial.Open(portName, baudRate) Opens a serial port. If you do not specify a baud rate, the default is 9600 baud. You can use the returned object to communicate with a serial device. UI.Message(text) Pops up a message box. The ECig object also has an indexer. x = ECig[state] ECig[state] = y States are strings representing the variables in the device monitor. For example, ECig['Power Set'], ECig['Current'], ECig['Battery Cell 1']. Here is a sample script. It records current, voltage, and power while doing 3-second puffs ranging from 5 to 30 watts: import time ECig.ClearTracking() ECig.Track('Current') ECig.Track('Voltage') ECig.Track('Power') Recorder.Record(r'C:\Users\James\Test.csv') time.sleep(1) for p in xrange(5, 35, 5): ECig['Power Set'] = p ECig.Puff(3) time.sleep(6) Recorder.StopRecording() EScribe, starting with 1.2 SP5, includes a short manual with samples for Device Monitor scripting. I've attached it for your convenience. EScribe.pdf