James

I've posted up 1.2 SP5. Please let me know if you run into any issues with it. Have a good night. James

Hello MacVap, We moved to a CDN for our downloads, since the traffic is into the terabytes... I've contacted them and will let you know what I find out. James

If Connect and Download Settings worked, what did you try next that said no USB devices were connected?

skrilla, in Device Monitor, what do your cell voltages say, and what is the USB Voltage?

When you used SP4, did it not automatically make the minimum 0.9? If not that's a bug

lewiss, if you go to Device Monitor and click Diagnostics, Set USB Current Limit, and set it to 1A, what does the USB current read? 1A, or does it stay at 1.8A? (You have the device set to "Wait Until USB Charge Current Goes Above": 0.9 (or higher) A, right? If it is set to 0.1, the default for DNA 200, this is the cause of the error.) I'd recommend using the SP4 Production Utility not the SP3, by the way. Its USB charging test is better.

At a 3.2V soft cutoff under load, it's not surprising you don't get significant vapor if the lowest cell is at 3.29V when not under load. Most of the capacity is at higher voltages, so it would appear to even out voltage-wise after a bit of charging despite having a large difference in charge level between the cells. (When they are very low cells tend to crater on voltage, so if the other batteries are at 5% and that one is at 0%, it'd appear a lot lower, whereas at 20% and 15% they'd appear similar.) I'd let it charge up to 4.2V and give it time to rebalance. It's not necessarily anything wrong with the pack. Balanced, next time, you should get closer to that 19% it thinks you have left.

The DNA 200 doesn't have the charging issue SP4 addresses. There may be a SP5 for DNA 200 at some point with other fixes.

That sounds like an issue with the balancer taps, or alternatively, are you sure your batteries are seated correctly?

I've fixed the link. Sorry about that

This is part of the reverse battery protection. It won't pull any power from the port unless it sees a reasonable positive battery voltage.

Once the charge is complete (4.20V/cell unloaded) the DNA will correct the meter. If the meter is off, it may say 100% but until the cells actually get to 4.20V and the current declines to nearly zero, it's not actually finished charging. If you have a cell at 3.33V your battery is basically empty. The meter, when the DNA detects it should do a correction, always does it based on the weakest cell (since Weak Battery will limit on the weakest cell anyway, for safety). If the other two are that much higher, you need to let it charge and give it some time to rebalance the cells.

salsadoom, the problem is that Wine doesn't have support for Windows's USB HID APIs. I don't think it'd be terribly hard for them to add. Presumably it's just that nobody's up and done it. Humorously, the C# HID library I use, HidSharp, actually does support Linux's native USB HID APIs (though Linux does require you to set udev rules to access HID devices on non-root accounts.)

The 1.2 version is much more portable than earlier versions -- a good 90% of the user interface is in platform-independent code, as opposed to perhaps 50%. As time has allowed, I've been moving more and more of the code this direction. Keep in mind though that time and resources are limited, and there's a lot more we're doing than EScribe. It'll get there.

I don't think the internal resistance has changed. 1.2 SP3 may have trouble reading resistances that low, probably due to some of the extra protection code we added. I'll have to look at it this coming week. Other than this issue, I am glad it is working well for yall.

The results of Battery Analyzer only affect the battery meter. If you can live with a battery meter that is maybe 10% or 15% off, you really don't need to configure anything in EScribe for your batteries. Weak Battery messages are based on a minimum voltage, and charging goes to a maximum voltage. We did this intentionally so that accidental misconfigurations have cosmetic effects only. The safety-critical systems are not user-configurable. The battery *type* matters, but Lithium Polymer/18650 is already selected by default. Only if you are using LiFePO4 batteries (I thought people would want to, but it seems not) are you going to need to configure that...

There are no modes on the DNA. X watts is X watts... What material is your coil? If it is Kanthal, no temperature protection is going to occur, so you will get a purely power-controlled vape. The power level is related to the amount of vapor production. I'd try turning down the power. It may be much too high. You don't need to select Kanthal on a DNA device. We autodetect the non-temperature-sensing case. If it is a temperature-sensing wire and it is temperature protecting, disabling temperature protection is going to increase the amount of vapor. I'd try turning down power.

The purpose of preheat is to raise the temperature of the liquid above the boiling point so vapor production can begin as soon as possible from the time the fire button is pressed. Kanthal has no meaningful rise in resistance with temperature. We cannot sense its temperature. Therefore, we do not preheat it.

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.