James

E is actually a bit different: E=GET MFR E=GET PRODUCT E=GET FEATURE (1 to 7) E ("e-cigarette") and S ("statistics", because E=GET FEATURE returns St) support the ECigStats command set.

Please try the EScribe I posted in the Early Firmware thread. It should fix it.

Are you charging with a 24-gauge cable? Many USB cables aren't capable of pushing 2 amps. Some sub-$1 6ft ones I use for other purposes top out at 0.3A or so. Monoprice's 24AWG micro B will definitely work. They're only about $1.50 on Monoprice's own website. Kind of bulky though. I would give you a link but it appears the "free" forum service we are using replaces Amazon links with Wal-Mart links. Grr. I like their $3 "premium" USB cables as well, though I haven't tested a 2A charge with them. Really, any 24-gauge cable will do. Also, when the battery is nearly full, charge will be put in more slowly so as to not overcharge the cells. We don't let any of the cells go over 4.20V.

blueridgedog: Parallels on Mac does glitch on me occasionally, randomly pausing for a second every once in a while. The EScribe version I just posted has longer timeouts, so it shouldn't be fazed by that.

Posted the 2015-09-03 EScribe. Minor bug fixes only.

We bought a Mac Mini yesterday to test on. In my testing with VirtualBox... If the firmware update has a problem, the DNA goes into its bootloader/recovery mode. You need to add the bootloader device (it just shows as a serial number) in USB Devices. Once you do that, if you reconnect it, it does detect. (It seems that the effects of VirtualBox settings changes are only seen after a reconnect.) After that I had no problems doing firmware updates on Mac OS. In my testing with Parallels... Parallels was about the same, except it seemed to have trouble detecting when I disconnected the device. The Windows XP image I was using still thought it was connected. Also, it was very slow to detect the connection. So the real problem with both of these is they don't automatically hand over the DNA 200 to the virtualized OS. If you make sure both the normal device and its recovery mode get handed over, though, it works okay. On both I *did* find that USB is slower under virtualization. I raised the timeouts from 750 milliseconds to 2 seconds in my test version, which made for less spurious errors.

Mm. There isn't a command to do this. I will add one though.

This occurs even with the newest version of EScribe? I'd thought I'd fixed it about a month ago.

Immediately turns off... That shouldn't normally be related to the Warranty Service message. What do your battery cell voltages show in Device Monitor?

Does it just intermittently pause and fail with EEPROM Programming Failed, or something more consistent? If these VMs just have a tendency to pause, I wonder if we just need to increase the timeout time.

How did your cells get so low? If the cells get that low (below 2V), you'll need to select Perform USB Recovery Charging in Device Monitor.

mechaet could you save and post your settings file? I don't see anything unusual on those screens.

What voltages do you see on your battery cells in Device Monitor?

Oh, I mean your EScribe settings. iandvapyes: This happened to you before 8/21 then? How long have you been encountering it?

josh, the actual charging code does not use the battery meter, just the cell voltages. It isn't a worry for overcharging. What firmware version are you running, out of curiosity? And does it only happen if there is no atomizer attached?

Mm. Are they cross-shipping you a new one? 60 watts should work fine. The board can handle it.

Has this happened to anyone who is not on 8/21? The battery meter has changed because that message indicates it accidentally restarted without savings its settings. Most likely it indicates a firmware bug. Do you have any special settings presently? If so, could you attach them please?

The board should be totally fine doing Battery Analyzer. IIRC we did the stock curves using a LiPo at 50W, using resistor blocks and no fan. The Board Temperature sensor will protect well before the board should have any problems, and even at high powers it takes a while to get that hot. I admit I've not tested with a fan present, but I can't see that making a difference unless the Board Temperature sensor was being cooled by the fan better than the rest of the board... What power were you doing the test at? Hmm. Send Help Desk a ticket for a replacement, and have them send the board to us to take a look at. We'll see what we can see. Thanks! James

LiFePO4 has very little real capacity above 3.3V. It's mostly useful to know when the charging is complete. In my testing it took about 1 puff to get from 3.6V back down to 3.3V. I got the LiFePO4 curve in EScribe by using Battery Analyzer.

Oh... If it's inside VirtualBox, make sure you let the virtualized OS see that unknown device. It's actually the bootloader (failsafe) USB.

Tools->Reboot->Hard Reboot does not work? That only requires the bootloader not the firmware. The fact that it's responding with a Product ID of 0x8405 suggests the bootloader is not entirely dead.. (What version did you have before? Anything 7/29 R1 or newer has the same core firmware and so uploading doesn't put into bootloader mode.)

blueridgedog: Have you tried Tools->Update Firmware? If it fails half-way through, you can use that to manually reupload it.

I've added the ability to put the new and old coil ohms in a custom location on-screen to the 2015-08-21 firmware.

I've added the customizable lock clicks to the 2015-08-21 firmware.

Posted 2015-08-21. Main features are localizations, customizable lock clicks, and customizable position for showing the new/old Ohms in the New Coil Yes/No? message.