TC Box Mods Firmware Discussions and Customizing

fluffhead

Recovering Idealist
RLWIgKTbLgE0awHUh_pLimqKsZerym-4T-ALNIhEcNCZ5UvHpy-gitMtax-tMQxB-__F1ODygzfAf0sq4LvYLz8na7phNGgUzYjljsJYy14PSthrLTJJAYuAm3clymfG8Q4M3dM
These are the numbers I have been using now and they seem to be the best for me so far. I don't actually look at the temp as it goes, but I base off of the resulting abv. With other numbers I was getting hot spots, especially around the outside of the load. With these numbers I get incredibly even abv (as long as I rotate the stem). I am actually amazed how changing to these numbers has really evened out the colour of the load. What does the boost number do?

This "kicking out of TC" has been my plague
The problem that you describe sounds the same as what happened to me when I first got my cuboid/eraser combination. I would set it to TC but then as soon as I pressed the fire button it put me in power mode. The problem for me was in the atomizer in that the two wires were touching pretty close to the base. Once I fixed that, I haven't had the problem since then. At least I think that is what fixed it considering your problem is with multiple atomizers. :hmm:
 

Pipes

Addicted DIY Enthusiast
Accessory Maker
Actually, I was trying the boost to accomplish what @ander seems to have done in his new PID, raising the initial power to quicken the heat up. Honestly, could not see any difference on the monitoring graph though... Will give the new PID a go to see.

Yeah @KeroZen, more than one atomizer would indicate a problem with the mod. Likely the center pin of the 510 connector.
As you likely know, kicking to power means the ohms are not changing as expected when the mod applies power. So adding voltage is causing a momentary short (or open) ...somewhere.?
Also, if manually entering your ohms, you have to stay within 10% of actual ohms.
 

KeroZen

Chronic vapaholic
I double checked the center pin and it's fine, still springy.

The strange part is: it's not like it's trying to do TC. The switch is instantaneous! When I had the genuine problem with the resistance change that was too slow, I could see it struggling for a while then it switched.

Here I can't exit the mode configuration with an RDA attached! It starts in power mode, I triple-press trigger to enter setup, select TCR mode, then press trigger once and bam it reverts to Power mode! If I remove the RDA beforehand, I can select TCR mode, hit trigger to confirm, it stays in TCR, then I plug the RDA and as soon as I hit trigger once it reverts to Power mode! :hmm:

EDIT: in Power mode if I display the resistance as a second display attribute, I can see the theoretical resistance and the live resistance and the latter is changing fast enough and in the range we epect (0.6xx to 0.7xx and up when hot) So the coils are working fine it appears.
 
Last edited:

fluffhead

Recovering Idealist
The strange part is: it's not like it's trying to do TC. The switch is instantaneous! When I had the genuine problem with the resistance change that was too slow, I could see it struggling for a while then it switched.

Here I can't exit the mode configuration with an RDA attached! It starts in power mode, I triple-press trigger to enter setup, select TCR mode, then press trigger once and bam it reverts to Power mode! If I remove the RDA beforehand, I can select TCR mode, hit trigger to confirm, it stays in TCR, then I plug the RDA and as soon as I hit trigger once it reverts to Power mode! :hmm:
This is exactly the behaviour my cuboid had when I had a problem. I never did what you listed in your edit because I fixed the issue before I knew to do that. Wish I could help more, but I wanted to add my data point for you.
 
fluffhead,
  • Like
Reactions: KeroZen

Pipes

Addicted DIY Enthusiast
Accessory Maker
Re-flash the FW to see if it just a data fuck up thing.
 
Pipes,

ander

Well-Known Member
Final series of tests (D is always 0):

Original, P 550, I 50
P550_I50_D0.jpg

sweet

P 550, I 0
P550_I0_D0.jpg

too little I

P550, I 100
P550_I100_D0.jpg

too much I

P 1100, I 50
P1100_I50_D0.jpg

higher P = faster heat up and peaks

P 1100, I 100 (original doubled)
P1100_I100_D0.jpg

higher P + higher I = faster heat up and bigger peaks

Results may be not that far. But there's some evidences no..? The relation between P & I? The importance of the correct I value? The not perceptible absence of D? Anyway, first graph has the perfect score here. :cool:
 
Last edited:

ander

Well-Known Member
what is the time scale of the charts?
20 seconds
are you taking a hit during the chart display?
This is The Question. No. In vitro experiments... Must do! Mmm... D will finally find his function..?


Hitting at P 550, I 50, D 0:
P550_I50_D0_p.jpg


Hitting at P 550, I 50, D 25:
P550_I50_D25.jpg


Got enough of graphs folks..?!
 
Last edited:

Joaon

Well-Known Member
Thanks @ander for your work! We are heading the good way ! :cool:
The Project/Eraser/Shitfucker is getting better and better! :rockon:

I find that graph pretty expressive about P-I-D, so I repost it:
PID_Compensation_Animated.gif

P is the heat up 'boost', I is a fine temperature tuning , and D smooth all out. Right?

From what I can see on your monitoring @ander , P:1850 can be perfect for quick heat up (and it is! :D);
But it seems a bit agressive on the power for stabilize after :\

Lower P and/or Higher D could maybe smooth all that .. ?

Still looking to monitor on Mac, I'll maybe do a Windows session ..

:peace:

:ninja:
 

KeroZen

Chronic vapaholic
So for the record: I flashed the latest myevic on top of the previous... and it kept all its settings as well as the problem!

I had to reflash the original firmware, then go back to latest myevic. When it started I thought it did the same, as my old logo was still displayed, but thankfully the settings have been overwritten.

I can now use TC mode again and in the coils > manage menu, I can disable "check". Intriguing, it's really as if it was partly bricked...
 

ander

Well-Known Member
P is the heat up 'boost', I is a fine temperature tuning , and D smooth all out. Right?
Well I'm ashamed because my approach is really, REALLY intuitive... and I don't know yet what to think of mr. D... for now playing with only 2 parameters seems to give regular results, with this a stable coil and so a good base. But I hate when simple things become too hard! We know well how much important is the PID algo for coil stability. How we set this (with some limits of course) could become not so relevant or of personal taste.
At the end, what really matters as fluffhead reminded, is constant results and happyness.
 

ander

Well-Known Member
@Joaon I realized that I didn't answered to your question in the end... maybe because I can't!? :razz:
But maybe you missed this... helped me a lot.
Still looking to monitor on Mac, I'll maybe do a Windows session
A virtual PC is the answer given for your problem on ArticFox official thread.

P550, I 100
P550_I100_D0.jpg

too much I

I've definetly switched to these settings. This higher Integral is not too much when hitting... helps holding the choosen temp instead.

:peace:
 

rabblerouser

Combustion Fucker
So, I was interested enough that I cloned the git repository for myevic and I successfully built and flashed their 'hello world' example. Definitely some hair-pulling resolving dependencies to get the project to build.

(The main thing I was hung up on was it not finding libc.a with whatever automatic way it had of finding the directory, just manually setting correct path to libc got it to build)

I'm not exactly sure where to get started or what changes could / should be done for our purposes.
As a disclaimer, I haven't done embedded programming ever or programmed in c in a while.

But the last time I was seriously doing programming in my free time was when it was easy to do apps for my Android phone. So, programming the box mod is a natural progression.

I'll probably poke around some, but if anyone wants to suggest something to look into....
 

KeroZen

Chronic vapaholic
@rabblerouser : atomizer.c is where the goodness is! I'd begin from here. I started reading the code but didn't dare to try building it yet.

If we need to set a goal, I would say "improve the TC mode one way or another". Some avenues to explore: asymmetrical PID algo, DSP on the resistance read data, complex TCR curves...

For the others having a device running myevic, I got some homework for you: in TCR mode, select as secondary display attribute "res". You should see now "coil" and below "res", the latter being updated in real-time even when not touching the trigger.

Now check how the values are after a 10 seconds trigger run. When under power, in my evic VTC mini the two values match and seem more or less stable. But when I release it's all over the place! I get huge variations up and down. Globally it goes down but sometimes it jumps back up, then it oscillates... Even at rest the values are pretty wild.

Is it only my device? Is the ADC really up to the task? Is it just a matter of accuracy vs precision? (the display shows precise numbers but the measurements are not accurate and repeatable so it jumps around a lot?)

One big problem I see with this TC method is that in order to measure the resistance, we need to apply a sufficient amount of current, which in turns heats the resistance and changes the value! A kind of "uncertainty principle" somehow...
 

funkyjunky

www.lamart.ch
Manufacturer
the measurement is done on line with a shunt resistor. thats a very low ohm resistance in series to the heating coil. by measuring the voltage over it and the cell voltage you can calculate the resistance of the coil, as it acts like a voltage divider. its done all simulteneously! but yes it pulses for the online measurement with a low current.

also your values jumping around is not a good sign, for me it does vary a bit, like max 0.002ohms when cold or so but thats it. if it is cooling down the resistance decreases very linearly and does not vary.

i think you havent experienced a proper pid in place with your device. be it wonky coils, contact resistances, unlucky with the mod. i just see you over and over stating you think all is crap but we on the other hand that got it working have no complaints. thats whyni really think your problem is an individual one.
imo assymmetric pid is way over what it needs and "better" algos than pid, i mean common, the world is full of pids, they do the job very well if configured correctly.

someone might need to do the tuning method for the project called ziegler nichols, i can help with that. youd need the monitor to work properly and make some measurements. like this values are found that make the pid aggressive but fast and very stable.

edit: @ander very nice testing!
 
Last edited:

Pipes

Addicted DIY Enthusiast
Accessory Maker
@KeroZen , I know you reflashed your FW because of flaking data somehow. Try taking it back one step further.
Follow the recovery from Bricked method spelled out in my FAQ. That takes right back to running on a boot sequence only with no runnable data until you flash it. Then flash the OG FW with the OG installer. Then go back to the myevic. Also, maybe get a fresh copy of the myevic..?
You never know?
 

danald2000

Well-Known Member
Articfox works on more units and seems to be a more powerful version of myevic:).

Also has anyone messed with tfr? Tfr is a more complex version of tcr that assumes resistance doesn't always increases linearly... Giving us a lot more accuracy!
 

m0qu4

Well-Known Member
Hi FC

wanted to post a recent patched myevic firmware, and also the patch source. But for all the people not hanging in the Bully or The Project thread here a bit more info.

With this patched myevic firmware it is possible to configure an offset in order to adjust the shown temperature.

In the expert menu, adjust your value where it states "Shift". If you set "-10", for example, you will always see a temperature which is the "coil temp - 10", whether you adjust the temp or when firing.

Note that the inner workings of the firmware are not changed with this patch, only whenever the temperature is shown in the display, it is shifted by the value set in the expert menu. So its a simple numerical shift regardless the setting of celsius or farenheit.

The changes made compared to the original firmware are:

* add menu entry "Shift" in the expert menu
* set shift value up to 100 for celsius and 200 for farenheit. increase by 1 for celcius or 5 for farenheit
* when you change from one to another, the shift value is zeroed. this avoids taking over a value >100 from farenheit to celsius, and also a value which is not %5 from celsius to farenheit
* when firing, display the shifted value (temp-shift) only if the result is >0, if not show only temp (original coil temp). this avoids funny things beeing displayed at the beginning of firing

In case anyone is interested, here is the patch which applies to the latest myevic git version (from 20170201):

http://ge.tt/8wyFvGj2 (patch -p0 -i $file)

Feel free to open (and maintain?) a fork of myevic with that patch as a base. At the moment i dont see myself having the free time to do so.

And here the changed and compiled firmware:

http://ge.tt/8RYDvGj2

Last but not least, the stock firmware increased to fire timeout to 25s, so this is now possible, as some requested.

Regards,
m0qu4
 
Last edited:

Vape Donkey 650

All vape, no smoke please.
Hey all my firmware tweakers...

I wanted to re-post this from where I just posted in the Divine Tribe thread. I recognize the people that might benefit the most from this stuff may never stumble across it :shrug: I also know that you guys seem to be mostly discussing this firmware as it relates to "the project" and related DIY herbal 510 vapes. But after some of you guys brought this to my attention, I would like to share how good myevic can be from the donut-vapers' perspective. :cool:

I'll probably post future myevic / 3rd party posts on this thread rather than DT, if that's cool, since I might be 'over-greeking it' for the casual donut-dabber, and I do have more questions, but here's what I shared with the others too:

(quote)

After having used this firmware for several weeks, on several mods, now, after having it introduced to us by
@KeroZen, @Pipes, and @OF, I want to give everyone my review / report of the myevic 3rd party firmware. It is compatible with most joyetech / reuleaux mods (no eleafs yet)

My impression: for donut vapers who seek a more stable temp control function, and like being able to customize their mods as much as possible and view all sorts of info and stats, the myevic is a winner, and highly recommended :tup: It is still pretty user-friendly and it's look is not far-removed from the stock firmware, but it allows joyetech vapers to fine-tune their vape experience and gain some features usually found on more high-end mod chipsets.

Here's whats to like:

  • better temperature stability!
If the default joyetech software and screen is to be believed, I expect temperature swings/oscillations of 10, 15, even 20+ degrees usually, although short-term stability with temps being stable for a couple secs, or bouncing only 5-7 degrees can be observed at times.

With the myevic, using the same tcr / watt / temp settings, and the "stock" or "sweet" algo, a significantly more stable temp range can be observed and experienced. At it's best, the "standard deviation" of temp oscillations seems to be 7, or 5 degrees or less! Temp bouncing 10F or more is seen sometimes, but much less than stock. Occasionally, wild swings of 100 degrees or more is observed, but it is so quick and random, without any corresponding spike in vape quality, that I must attribute that to a measurement error or signal noise, as @OF hinted at.

Because I can look at my screen when vaping with my glass/silicon adapters through my rig, I can confirm that the temp stability is not just theoretical. Looking at the vape stream through my glass gear, I see a smooth, consistent stream of vapor, where I would usually see spikes before, and even more with the eleaf picos. :(

  • Lots of info!
You have the option of looking at tons of info on the 3rd row of your screen. Standard puff #, clock, and amps, but also voltage, (charge or real-time output) CPU board temp, and my favorite: "coil res" Like how joyetechs show you coil resistance rising in real time when vaping, but you can now observe coil Ω fluctuate and jump, while not vaping/firing, in real time! This is quite interesting to see how not truly stable your coil Ω is. My more stable V3 donuts only fluctuate about 0.005-0.007 as the standard deviation, but other attys/mods of mine can jump around over 0.3-0.4 Ω when not even firing! :o Clearly a case of signal noise or poor contact, causing me to look into this more closely :sherlock:

Also, less masking! No more "temp protection" when your donut heats up, as it inevitably should. Instead of hiding how overly hot your donut it, it tells you! If you dial in 390F, and the heat swings to 393, or 401F in the course of vaping, the screen tells you! :D This is good stuff.

You also have 3 battery display options: just a bar, or bar with charge %, or bar with voltage, which also changes in real-time when vaping.

uVV3GFy.jpg

Coil resistance down to the thousandths, with real-time coil measurement and real-time battery voltage meter, and alternate font, on one of my donut-tank evic basics. Besides that, looks like stock, right?

  • More precision / features
You have access to 4 different vaping algorithms, although only stock and sweet seem to work well for donuts. "Boost" mode only seemed to make my temps spike, but is worthy of further investigation for super-quick warm-ups, perhaps?

You can set temps in increments of 5F / 1C, instead of only 10F as before, and the finer resolution of temps and corresponding +/- in vapor production is noticeable.

You can manually input/adjust coil resistance, if you choose, since any given / initial measurement of the donut can be wrong at times, and if you know it's off, you can correct this. I think dialing in the most accurate base coil Ω is important for your TC accuracy.

Coil resolution is displayed down to the thousandths of an Ω now (0.001) not just hundredths as with stock.

You can set the 10-second protection higher, up to 25 seconds, so you don't have to cycle the button for puffs longer than 10 seconds. Quite useful for the DC herb atty, or the long-lunged, like Steven

Also has lots of features for the clock, logo, display, screen saver, etc, but I'm not as interested in that stuff.


What's not to like?

I guess there has to be something? :shrug: Not much really. The fact that it doesn't come on your mod already, and you have to download it and set it up?

I guess if I had to say something, it has a "PID" algorithm mode which probably shouldn't be used unless you really know what you're doing. I suppose in an extreme case, you can cause your mod to blow up in your face if you put VERY wrong settings in there? So don't use PID mode then ;)

It doesn't work for any eleaf mods....yet. :| This has got me wanting to look into the arcticfox software, which does work for eleafs :evil:

Anyways...... if you're a TC / info nerd like me, go get the myevic already. Ok? :)


Articfox works on more units and seems to be a more powerful version of myevic:).

Also has anyone messed with tfr? Tfr is a more complex version of tcr that assumes resistance doesn't always increases linearly... Giving us a lot more accuracy!

Hey, as you might see, I got the drop of the arcticfox, maybe just for the eleaf pico, at first, since that mod is left out by myevic.

Whats TFR? (time-frequency representation?) Is that like "fsk" mode or the non-linear TCR mode, as on the hohmwreck and DNA chipsets?

I'm all for temp stability and accuracy, but I'm wondering how much better can TFR mode really be over TCR mode, and how easy is it to set up and dial in? :huh:

Also, it seems arcticfox is made by some ru$$ians. :suspicious: Can we trust that? Are you sure they aren't hacking my mod to make it blow up in my face or something? :o :mad: :cuss: :tinfoil:
.
.
.
:lmao: :D :lol: :razz:

.
.
.
:| :uhh: :huh: :tinfoil: :(
 
Last edited:

KeroZen

Chronic vapaholic
Arf! Should have read this update first! So my turn to cross-post the same message:

Ha! So I'm not crazy. I was told by @funkyjunky and @Pipes that my evic VTC mini might be defective, but nope, you experience the same "wild live resistance readings" that I do.

To me it looks like the readings are "precise" (many digits) but absolutely not "accurate", as the reading fluctuates and even screwing/unscrewing the atty can give you a different value. Note that I'm talking about the readings in the 3rd display line. The standard ohm readings are either locked or masked, they stay constant until you hit the trigger, then the value rises until you release and it jumps back to the locked value instantly.

With the live readings I can see the value jumping all around. It rises when I hit the trigger fine, alright, but then when it goes down (or even when idle at room temperature) it fluctuates sometimes up sometimes down (but globally down)

Seeing the TC algo is based on those readings, it can't be good. We should really try to add some DSP filtering as the ADC values look very noisy to me. And displaying that many digits seems pointless to me as the thing is absolutely not that accurate. In my Smoant Knight 2 the coil reads 0.49ohm for instance and that's about the accuracy it has (and there's even some uncertainty about the last digit) There's no way the evic can be accurate down to the 3rd digit after the dot.

@funkyjunky claims that this TC method is even better than a dedicated sensor, and I disagree: reading the value alters the resistance. You can't observe the system without disturbing it. Observing the value already changed it since you need to apply current to read the circuit amps and volts. Even the room temperature affects the initial reading (hence the need to lock the value)

Honestly, if this method was that good, why no other vape (to my knowledge, FW4 could be the exception?) is using it? They are all sensored and it costs more to do it this way vs just adding a voltage divider and a shunt resistor.

Talking about shunt resistors, precision ones do tend to cost more and usually manufacturers get around the problem by having a not very precise shunt but correct that with a good calibration at the factory. I see that we can alter the shunt value in myevic advanced settings, but do we know how it's calibrated? Where is the value stored and is it lost when you perform a full device reset procedure?

I've had weird readings since day one with my device, way before switching to myevic. People with multiple devices reported that they get different coil readings with the same atty used on different devices. I really don't think it's a problem with my particular device (the authenticity code worked for what it's worth) It's just absolutely not as accurate as it tries to look like.

But it works overall, and TC mode is clearly better using myevic (no more visible coil pulsing)
 

KeroZen

Chronic vapaholic
@OF suggested in the DT thread that we could use some sort of running average, which is a special kind of low-pass filter. I also thought about using a 1 pole or 2 poles low-pass filter (non-resonant for the latter) but both solutions would introduce a lag which in turn most likely would induce an overshoot when doing TC.

With very high power settings, the rise to temperature can be really fast and we can't afford any significant overshoot or it would char or combust in a second. What I have in mind would be to keep the "attack" part of the temperature envelope as is, letting the readings climb and settle around the set-point. Then once we get a stable and narrower reading range (i.e. when entering the "sustain" part of the envelope, when the original firmware said "protection") we would enable the filtering.

It would also have to fallback to live readings when there is a strong dip and it tries to recover (from a strong user draw) again to minimize any delay and prevent overshoots.

But there's no warranty that it would improve the system. The noise source could be many things else: the quality of the ADC, its sampling rate, the fact that the shunt resistance value also changes when the mod gets hot, how it's calibrated, who knows? We need to find if there's something specific to filter, apart from the obvious high frequencies (in the sense that it's the first thing that comes to mind)

Don't get me wrong, I'm not saying it's not working, it's already admirable (spare the quirks I had...), when it's setup properly, both the Project and my custom RDA's work fine. We're just discussing whether it would be possible to make it even better or not.

I agree with @funkyjunky that with a well tuned PID, we can already do wonders. But a well tuned PID fed with nurtured and sanitized sensor data is an even happier PID!
 

KeroZen

Chronic vapaholic
Note: I'm making a separate post for the sake of clarity

Perhaps I got a faulty device after-all...or not! I toyed with the device monitor of the NFE Toolbox and here are some interesting graphs. X scale is 20 seconds, Y scale is 5% (maximum zoom)

In the first one we can see the crazy variations in the live resistance reading when the device is idle, with these strange dips:

izPa7wG.png


Here it's after a very brief pulse on the trigger to wake it (blue vertical line), it kinda seems to stabilize the readings a bit but it's still strangely wild when it should be pretty much constant:

dHgW9tZ.png


Now here's the interesting part. I did an empty burn-in from cold without drawing. Just held the trigger until the temperature stabilized to set point. Algo is PID (clearly suboptimally tuned) and power set to only 40W (single cell device)

First graph is the live coil resistance reading. As you can see it's pretty noisy with high frequency components, not smooth at all. I highlighted that strange spike at the end to display it's value.

xYZxFcL.png


Second graph is the temperature, we can see that the spike caused a 3°C overshoot (that's a 5.4°F jump)

a66SI1W.png


And this is the output voltage for the same period. There doesn't seem to be any clear correlation with the spike, but it confirms that the PID is badly tuned and oscillating during the sustain:

APFW2qz.png



Then finally this last one is pretty revealing: it's a constant trigger burst until regulation, then the cool down portion of the curve. X scale is set to 45 seconds this time. You can see that outside of the trigger on portions, the coil resistance sampling rate is pretty much reduced (clear stair steps) and also completely wild! So maybe my device is not faulty after all, and it's just that the live resistance reading is completely useless when not powering up. And when you hit the trigger, the live value is displayed anyways in the second display line, so maybe the live reading as 3rd display line is just completely useless and made me panic... :p

rdYJI8r.png



I'll keep playing but I'm at least onto something. In one of my custom RDA experiments I had a problem with the mod kicking out of TC and into power mode. And the problem was partly due to the slow resistance rise (large gauge SS wire) but also because when I started the mod, the resistance value displayed was always higher than the real one (and it's the case with the Eraser now too) And when I hit the trigger the resistance value jumps down to the real value, then starts rising...

:hmm: :sherlock:
 
Last edited:
KeroZen,
  • Like
Reactions: Pipes

KeroZen

Chronic vapaholic
Note: again split post for clarity

To eliminate any issue with the atty itself (previous graphs were with the Eraser), I switched to the Pure aka ShitFucker (curse you @Stu!)

If there's a problem, it doesn't come from the coil (could be intermittent contact resistance on the 510 port?) because the idle resistance values also show the dips (X-scale 60 seconds, Y-scale 5%)

rSo0ekx.png


A long trigger burst showed the same kind of noise but this time I could correlate more to events occurring on the voltage graph, so it appears to be possibly just the badly tuned PID in action (X-scale 30 secs):

cJAS0q0.png



So I thought: let's remove the PID from the equation completely! I reverted to the standard algo ("off" in settings) and did a trigger burst, again empty with no draw, until the time-out fired. And oh my! X-scale still 30 secs. What the hell? No wonder I could literally see the coil pulse in the past! It's switching on and off like crazy and overshooting so much! Wow! Here's the coil reading:

qEq9a5w.png


Followed by the voltage output for the same period:

mmLea4L.png


And the completely unrealistic computed temperature (I had to scale down on Y it wasn't fitting) Note the highlighted peak at 1446°C lol!

OIHdH2D.png



At this point I think we can't trust the device monitor display. Maybe it's sampling way slower than what the device does under the hood? And with the constant on-off switching the resistance readings seem completely haywire...

Hmmm gonna try the "sweet" algo now... EDIT: well I won't bother to post the graphs it's complete non-sense. The temperature overshoots on the device display by up to 30°C, never settles on the set point (195°C) and it made my Pure coil glow, I don't like that. I never had any success with this algo previously anyway...

LATE EDIT: I made some progress, things improved on the coil readings front but I lost my previous PID settings and against all odds, they weren't that bad compared to the best I'm getting now. Gonna get some sleep first, I'll update later!
 
Last edited:

Pipes

Addicted DIY Enthusiast
Accessory Maker
@KeroZen, those reading are pretty crazy. I'm honestly not seeing that kind of fluctuation at all. Are you sure your 510 center pin ans threads are clean? It really looks like a contact issue as doesn't take much to influence a measuring device at this low of resistance. Even, skin oil can cause some bad readings. Ever try getting a good reading with an ohm meter down in the sub ohms...., very difficult unless you have good lead tip contact.
Try a Qtip and alcohol around the 510 connections including the thread.
Something really doesn't seem right. I can see an argument for some noise and it taking an average should take care of it but not what your reading. And the fact that it's down shooting makes it even more confusing. :hmm:
 
Pipes,

bizwaxzion

Enigmatic Cannabist
I spent some time this weekend trying to get arctic fox firmware loaded onto my eleaf pico. I don't have a windows based computer, but I do have windows 10 running in a virtual machine (VMware Fusion) on my mac. I'm having very little luck getting the pico to "show up" as a USB device in the windows VM. I'm presented with a dialog asking were to connect it when I plug it in (mac or windows vm) and I choose the vm. The device then immediately disappears. If I power on the pico before connecting it to USB - it will show up to the NToolkit software in the vm - but trying to write out the lastest artic fox build results in a dialog box telling me an exception has occurred and the operation fails. Has anyone successfully worked with the arctic fox firmware through a virtual machine?

Success! The key was to change USB compatibility mode to 2.0 (instead of 3.0). I've been able to load arctic fox build 170201 on my pico - now onto testing.
 
Last edited:
Top Bottom