The NFE Arctic Fox firmware for Joyetech's Group mods.

1. Why this third party firmware?

Recently I purchased a Wismec RX GEN3 Dual mod, with the intention of supersede my all-time out and about mod, a pioneer4you ipv D2, which performed poorly in TC mode with stainless steel wires, and being a single 18650 powered one, has somewhat limited endurance.

The new little dual battery powered mod is a nifty box with plenty of settings and the so much needed power and long endurance vaping experience, plus the expected ability to cope with SS316L complex wires to vape in Temperature control mode.



At least that was what I expected. Two years ago a Wismec RX200S let me down because it was not able to properly feed my drippers with SS316L fused clapton dual coils. I sincerely expected more now after that time: well, it runs as badly as the RX200S in TC-SS316L did, and that's because some tricks that seems Wismec/Joyetech does not implemented, not out of the box:

i) A poor base resistance method. The mod probes the resistance while the screen is on with a low current (the so-called 'heartbeat') and, as you are screwing down the atomizer, not always the results are quite precise, often they get a bit higher than reality demands, and other well established mods in this field, i. e. Evolv's or YiHI's, find. Then you vape and the mod is really prone to jump out the TC setting, straight to a 20 watt VW mode for safety. Very disheartening, if you want a TC mode running.

ii) The OEM Wismec firmware appears to lack of any 'mod resistance' setting. Even when the atomizer is firmly screwed down and the 'heartbeat' reports stable readings, the results are off by 20~25 mΩ. That could be appreciated as negligible, but in 316L wires, it is about 11 ºC (20 ºF) the resistance variation for each mΩ !

So in the end, if you put something like this:


Which is a fairly 'complex' dual setting, six turns each coil of 316L fused clapton 26/30, the Wismec will always jump to 20 W in VW mode, no matter your skills, and no TC available.

Fortunately, there is a third party firmware for this mod, and many others of the Joyetech group, which solves these troubles: the NFE Arctic Fox. With this firmware installed, not only you get DNA-like and EScribe-like features to modify settings, profiles for atomizers, screen appearances, timings, etc., you get two really important things to enable consistent TC:

i) Now you can set the mod resistance, the parasitic resistances for the 510 contacts, internal wirings and so. In fact, for my Wismec RX GEN3 Dual it appears to be no less than 22 mΩ ! My DNA boxes have mixed results: 24 mΩ for the Wismec Reuleaux DNA200 and 9 mΩ for the HCigar vt167, but once you put that 22 mΩ value on NFE Tools settings, the mod measures all atomizers just like my DNA and YiHI boxes, differing one another in less than 2 mΩ!

ii) The mod does not jump out of TC anymore. I'll say it again: it doesn't jump out TC! On this matter now performs much like a YiHI chipset, as you can set the base (cold) resistance, even force it to any number in the mod via the new menu settings provided by the Arctic Fox firmware, and no matter the measurements the electronics do on your atomizer, it will not go out TC, but you will get weird results if your blocked resistance is off by too much or your wires do not perform as expected for SS316L ones.

The rest is now a cheerful downhill experience, once you enable the 'PI regulator' and experience with its parameters. In my case I have been able to match the DNA250 behaviour, which is undoubtedly mesmerizing given this is a less-than-60-bucks little box.

2. How it seems to work?

I will refrain from the installation and initial setup of the firmware, as they are fully explained in several revisions, tutorials and videotutorials scattered all over the Internet. Just in Youtube, you can search for the 'Arctic Fox' keywords and you will get plenty of results covering those topics. But there are some details which are not, to my knowledge, covered and they are really interesting to improve your mod behaviour. So this is now a 'some here, some there' crash course on the Arctic Fox firmware and some of its interesting features. And speaking of interesting, I must start by the 'PI regulator'.....

2.1 I really want to know about the PI regulator.

Well, it is quite well explained in the Wikipedia, with all the whistles and maths involved, even some history about it. But cutting to what matters, I'll just say that it is a mathematical procedure to compute deviations from a setting point desired and drive them to the expected, stable result. An example that nowadays many drivers enjoy is the 'cruise control' on many dashboards: you set your desired speed for the car and it magically runs breaks and gas pedals to match your setting, and it does it by real-time computing of the differences between actual speed and set speed, the accumulative differences in the historic of actual speeds and set speeds, and the quick variations on that difference: all three aspects are covered in the maths.

In our temperature-controlled mod, we speak about temperatures and power applied to the coils. First, the integrated, software driven controller, computes in real time the differences between actual temperature and set point temperature:
and them performs, also in real-time computation:


and that ominous equation says that the power variation in a time considered (ΔP) is proportional to the difference between actual temperature and setting point of temperature, which is in fact the function E(t), but also proportional to the integration in time for E(t) since some time before t_sub_h to actual time t, and also to the derivative of E(t) in time: those are the three term in a PID controller, proportional (with Kp constant of proportionality), integral (with Ki) and derivative (with Kd), and they work as the 'cruise-control' former example. The chip is correcting the applied power so the errors in temperature are fixed, proportionally to them, but also as the historic error suggests (integral term) and the speed of the variations suggests (derivative term).

In our case for Arctic Fox firmware, it is implemented a PI regulator, so it lacks of derivative terms:

2.2. OK, enough maths....Could you put up an example, with actual temperature curves like EScribe ones?

Yes, I can. The results will be a bit far-fetched as I don't want to make things too difficult, but it is possible to simulate this PI regulator in a simple spreadsheet. Let's take a capture of a real EScribe output:

This is a normal output of a well-tuned 316L atomizer when there is some applied preheat and the temperature set point is 235 ºC (455 ºF). In this case, the Evolv's controller is driving the applied power to the coils so they reach an stable temperature of, precisely, 235 ºC. You can see how the red temperature curve sets on an asymptote-like line at 235ºC, but the green power curve changes and much as needed to get that nice red curve. It is not difficult to imagine that in the absence of the controller, you will get instead something like this:
The new purple curve is hand-plotted, but it is a typical behaviour of temperature for coils which are not TC controlled and the applied power is too big: the temperature arises quickly and, as the heat losses increase, it appears to stabilise at a too high temperature, which in turn creates the feared dry-hit. If a PI-controller were enabled, it would compute differences and integrated differences between the purple curve (uncontrolled result) and the red curve (desired result) and with some proportional factors (the former Kp and Ki) would adjust power:

In each moment, the power is changed proportionally to the differences between values on the purple and the set point of 235ºC, but also proportionally to the encompassed area between those curves (as the integrations gives the area between E(t) and the X axis).

Now that we understand a bit better the maths involved, it's high time to conduct our own simulation and toy with Kp and Ki. First, a simple curve which resembles the purple or red ones:

That plot of Temperature(t) = 250-50/time resembles the former purple curve, same shape but different asymptote at 250 ºC: but we want 235ºC! So I will apply a proportional and integer correction to it, supposing (it is just a model, after all) our 'atomizer' looses 50ºC per second with no power applied and gains 2,5 ºC per second and per watt with power applied. Now each cell in the temperature column of the spreadsheet takes the value of the above, diminished in ten (with 0,2 seconds of jump, that's 50 ºC/s), plus the proportional and integral corrections, which are calculated in the 'F' column of the spreadshet (Potencia, or Power, column), after calculating differences for proportional in 'D`(ΔE(t) prop. column) and the integral of differences in 'E' (ΔE(t) int. column) for the last five values (one second) and with a simple rectangle approximation. This is what it is obtained with Kp=Ki=1:
We have not tuned yet Kp and Ki, and the plot starts to oscillate towards the temperature set point (and the simulated power changes accordingly). Now, it is a matter of fine-tuning Kp and Ki to get even smoother results, or if our fine-tuning is less fine that desired, a total mess:

For curious people, here you can get the spreadsheet and play yourself with the coefficients.

2.3. OK, enough simulations....Let's get real!

If you set up the PI regulator in Arctic Fox, you'll see the P (Kp) and I (Ki) coefficients, but also a %Range:
Well, the %Range is pretty self-explanatory. It is the percentage of the temperature set point in which you want to enable the controller: below that percentage the controller (regulator) will not be enabled, over it, the regulator will claim the power control. It is handy to grant preheat power without controller interference. With bigger percentages, less interference in preheat you will get, but also harder work for the controller once the set point is reached. In practice, as I do not know the units for P and I (should be W/ºC or W/ºF for Kp and W/s/ºC or W/s/ºF for Ki, but....) and the firmware suggests P=1850 (whatever units) and I=300 (idem), now it is time to toy a bit them......for me, %Range=100, P=6000 (maximum possible in software) and I=1000 renders a behaviour practically identical to my DNA250 with the same atomizers, and keep it in mind, no matter how convoluted and complicated their coils are. So be it!

3. Other improvements achieved by some changes using NFE Tools configuration editor.

Well, my goal of a good working temperature control was achieved, but there are other hints at the possibilities of the firmware editor that improve things even better. There is documentation support here and whether it will be enough for those interested or not, that has been my source, coupled with some experimentation on the mod, and this is what I have learned that could be handy for you:

1) You can set wattage jumps in just one watt increment (0,1 watt is boring!) -see '1'-, put fancy preheat curves and edit them for all modes, even change the presets in the mod, even for VW/Power mode (hello, Evolv!) -2- and, as I hope it has been cleared out, you now know how the temperature regulation works -3-:
2) For those complicated 510's (older Reuleaux and Joyetech's) which are prone to bad contacts due to the stiffness of the centerpin, as the base cold resistance is taken when you first screw down the atomizers, it might get wrong, resulting a too high base (cold) resistance. It is advisable, before blocking the resistance by editing the screen (four clicks by default), let the atomizer cool down to let the live resistance, which is shown in the 'Foxy' interface below the working resistance, get lower values.

But there is a better way: the Evolv way. In this way, the resistance measurement is performed with the actual current of the draw, you get resistance values only if you fire up the mod, and update those if a new draw gets lower resistances and they are not blocked.

It is possible to get the best of both worlds: a live measurement on screen, getting the lowest value as base resistance, while the screen is on ('heartbeat'), but also update the base resistance if, while firing, it gets even lower, like Evolv's chips do. For that, you must set R.coil parameter ON. As the documentation stays: Option Settings -> Advanced -> R. Coil (R means Real or Recent) allows to hold the last measured resistance of the atomizer on the screen, in a manner of DNA boxes. This only affects the displaying of information in standby mode: On = recent resistance while firing, Off = detected on installing atomizer, like before.
Despite the 'This only affects the displaying of information in standby mode' I have found that the base resistance in all modes (TC or VW) is updated like a DNA box does, if during the draw it is detected different, and in TC, lower. So regardless a bad base resistance capture during the screwing down of the atomizer, using the 'heartbeat', with R.Coil ON you get an updated base resistance while firing, much more precise which definitively saves the day for some rebel atomizers in TC: before the R.Coil change, they were prone to show lower live resistances than the taken ones for TC when they get cooler.

3) Beware extreme preheats. They are possible but if your batteries are not up to the task (older or not so high amperage ones) the current drain will crash down their voltage output and the mod will protest with 'battery low' messages, even 'battery block' (and then it will refuse further firing) because the voltage cut-off has been reached in some battery. It is a fact consistently proved from my EScribe and NFE Tools readings that at high wattages, let's say 100 W or more, whether they are attack power or preheat power, a dual series battery pack will loose as high as 0,6 V in each battery, and much more if they are not precisely new Sony US18650VTC4's. In these conditions (bad shape batteries), you will get warnings even with battery meter over 50% at high power conditions. All electronics, but also mechanical mods, do the same: it is unavoidable and it is due to the nature of the battery physics. In fact, it gets worse with lower electrical yields (here Evolv's chips, except the DNA75, excel with over 95% yields), but even with a theoretical 100 % for a mechanical box, it happens!

You can edit battery drain curves to match your battery, but bear in mind that the '%-meter' for that batteries (and the graphical dot line at the botton in 'Foxy' interface) is dynamic: it gets updated after a draw and often you see how it goes up after a long or high powered draw, so for those personal battery curves, choose the ones with low current drains from Mooch's site, or lygte-info.dk, Kidney-Puncher or whatever source you use. I have personalized mine, matching a discharge profile at 2 A for Sony VTC5's curve from lygte-info.dk:


4) Those who put the 'last power' in one line at their DNA200/250's should know that this firmware can do the same. The last power in Evolv's chips is actually shown as mean (average) power during the draw, as it coincides with that statistic on EScribe. In Arctic Fox you can set one of the three informative lines in the 'Foxy' interface to show 'last power', but unless you make it from NFE Tools editor and not from the mod's screen editor, it will be the last, not the average, and being that way it is not so informative.

Doing so, setting 'Last Power' and checking the box ("Calada" in Spanish, I will bet it is 'hit' or 'draw' or even 'during draw' in English), now this information line reports the last draw mean power, like Evolv's do. I am not sure for the base of this average, could not be the entire draw, as it has been shown from my tests, it seems to average the last seconds of each draw, but not its entirety if it is a long draw. Anyway, it is informative enough to know the equivalent power of the last draw if instead TC mode it were VW mode with the same result...