DIY JBC Nano Controller

DIY controller for JBCs Nano (NT115) Soldering irons

Similar projects worth following
Everybody is this community knows and loves JBC for their high-end professional soldering irons. These are often considered to be the best on the market. But, being professional grade equipment, the price tag is also in the professional range. Since the majority of the cost is for the station, building controllers / stations for these has become quite a sport in the DIY community.

Why Nano and not T245/T210 as everyone else?

The JBC NT115 soldering iron is amazing, it's quite compact, has a slim cable and the grip-to-tip distance is really small. It's meant for super fine-pitched SMT parts, yet if you combine it with a larger tip, its powerful enough for most soldering needs. So, despite being a high precision tool, it is still use-able as a general purpose soldering iron.

Also, there is no real point in DIYing a controller for the larger irons from scratch, since there are already heaps of projects on the internet.

Economics of DIYing a soldering iron controller

Depending on the brand, the soldering station / controller is often the most expensive part of a soldering system. This make sense, since this is the most complex part as well. But, the stations are built from standard components (except the mechanical parts), so it is fairly easy to replicate the behavior of the station with a DIY solution.

In my case, the station (including tools individually valued at about 400EUR) is sold for approx 1200EUR. So the price tag of the station itself is about 800EUR. The DIY project cost me about 10EUR, so that's a huge difference. Fair enough, the original station supports two dual-channel tools while mine only supports a single tool. But extending the number of channels is cheap and more or less trivial from an electric point of view.

Of course, the original station will be better than mine from the mechanical point of view. While mine is a light-weight 3D printed plastic thing where you need to be careful not to melt the enclosure, the original is solid professional equipment.

Differences to the T245/T210

Both have similar tips with the heater and thermocouple embedded directly in the tip.


The most obvious difference is the plug, this immediately suggests that there are some more fundamental difference between the two irons.


The NT115 system is designed for a much lower voltage. If I remember correctly, NT115 uses about 9V while T245 is more 20ish. Not sure how bad too much power is, but overloading the tip by a factor of 4 doesn't sound good. For reference, the C115 heaters have a (hot) resistance of about 5 Ohms, which would result in ~16W at 9V, so that's quite close to the nominal 15W of the tips.

Heater and thermocouple are in series

Despite the cable having three wires and the tip having three contacts, two of the contacts seem to be internally connected inside the tip. So, the only way to power the heater is through the thermocouple. This sounds odd at first, but that's just how it it...

Status of this project

Everything works pretty well, the heat-up times are JBC-like fast and the temperature is quite stable. I don't know the exact characteristics of the thermocouple, but from tests, I assume the sensitivity is about 9uV/K. It doesn't matter that much, since the temperature you need for a job depends highly on the tip and the job anyway anyway. The hardware supports to measure the supply voltage, but I'm not using it right now.

Under-voltage self destruct

One issue with the current hardware is a potential self-destruct scenario, if the supply voltage is too low. Since I'm using a low-side driver to drive a high-side P-Channel FET, the undervoltage lockout (about 4V) of the driver will force the FET ON when the supply voltage is too low. This may cause the tip or the mosfet to overheat. So always use a switching power supply since it will turn off anyway if you load it down that much.

Adobe Portable Document Format - 97.50 kB - 10/26/2020 at 14:45


  • Feature List

    Daniel11/24/2021 at 22:26 0 comments

    Since I consider this project finished now and I had this in use for a few mount now, I guess its time to do a little summary of the features

    Supported soldering irons

    So far I only tested this with a JBC NT115 hand piece, but it should work for all soldering irons where the heater is powered through the thermocouple. This is certainly a minority of the available soldering irons though, since most have a separate wire for power. But I think some Hakko tips use the same design as well.

    Power supply

    Since I didn't include a separate power supply for the gate driver, the maximum voltage is limited by the gate driver and the maximum gate voltage of the used mosfet. I run this at 12V and you shouldn't go much higher. This would be easily changeable, but since I designed this for low-power irons it never was a problem.

    Software features

    • Highly responsive temperature regulation for almost instant heat-up.
    • Two levels of standby/sleep modes controlled by a contact closed when the hand piece is in the holder (Could be a micro-switch or a contact closed between the sens line and the metal ring of the hand-piece).
      • Target temperature will be dropped to standby temperature as soon as the hand piece is in the holder.
      • After a delay the heater will be turned off completely.
    • Idle detection turns off the heater when the iron is not in use for some time but not in the holder.
    • Menu implementation on the display to set controller / standby parameters.
    • Persistent storage for all settings, including the current set temperature.


    The enclosure I designed for this project is very basic and leaves lots of room for improvement. It's very light, so it doesn't feel high-quality at all. On the up-side, it is super compact while still having an integrated holder for the iron.

    • Noise issues

      Daniel11/03/2020 at 19:40 0 comments

      Unstable measurements

      While testing the temperature measurement, I noticed that the values were rather unstable. I quickly noticed this was caused by an unstable supply voltage. In the STM32 the ADC is referenced to VDDA, which is more or less VCC with filtering. I probably should have added more filtering / larger caps, but first I tried to address that issue in software.

      Compensate against VREF

      The STM32 have an internal 1.2V reference. This reference can be measured by the ADC and the result can be used used to compensate other ADC values for varying operating voltages. The ST_VREFINT_CAL value is a constant for the ADC readout of the internal reference at VDDA=3.3V. The lower the operating voltage, the higher the reference reading will get.

      vin = ((3300ULL * ST_VREFINT_CAL) * <ADC_IN>) / <ADC_REF> / 4096; 

      This compensation pretty much solved the noise issue, but from time to time a few outlier caused the controller to look a bit unstable.

      Outlier detection

      Since the signal is now pretty stable over all, we only have to address a few outliers. This is done by calculating the difference of the average difference to the average of the last 16 readings.

      If err is below a threshold, the value is accepted and used for the controller. If the values is rejected, the controller re-uses the last reading. This is no problem, since the controller cycles are rather short, typically 10ms. The new value is added to the window in any case, so a sudden jump in the values will not stop the controller form working.

      What causes the noise / how to avoid it?

      The two methods eliminate the noise issue, but it would be better to figure out, why we have noise in the first place. I've been measuring the VCC with an oscilloscope and can confirm, there is noise on the VCC line. Its not just minor noise, there are some larger drops in the supply voltage. My suspect is the display, but since I soldered it onto the board, there is no easy way to test without it. I tried to add some caps across its voltage pins, but it didn't improve much. So for now I leave it like that since its working and I'm kind of happy with the software solution.

    • Little flash, big trouble

      Daniel10/26/2020 at 14:40 0 comments

      16KB flash should be enough for everybody...

      ... at least that's what I though when selecting the controller for this project. After all, controlling a soldering iron is not a very complex task, so I just got the smallest STM32F0 available. Then I started to write the code and figured out, I was gravely mistaken. The whole project with the features I wanted would have never fit into that controller, so I hade to find ways to save flash.

      HAL is huge

      Initially, I wanted to build this with the STM32Cube HAL. I've never used it before, but since it's kind of standard I wanted to give it a try. But once I set up the project, I realized, this is a bad idea! Even a very simple test program already takes 10k, so that's not gonna work.

      libopencm3 to the rescue

      In all my other STM32 projects, I always used the libopencm3. That's a free HAL for Cortex-M ARMs. It does not come with the nice graphical pin and clock assignment thingy, so it requires a bit more data-sheet diving. And I think it makes a slightly worse job at abstracting the hardware, so the code is a bit more target specific. But its WAY smaller, so that's why I used libopencm3 for this project as well.

      Fonts aren't small either

      Since I'm using a graphic display, I needed fonts! And since I don't want all text in the same font size, I need more than one of those. I used bitmap fonts, which makes fonts with large letters quite big. And so when I ran out of flash again and decided to do something about the font size.

      Strip unused characters

      I realized, that the biggest font (16x26) is exclusively used for the temperature display in the main screen. But there only the numbers and the 'C' is needed. So the first reduction was by creating a copy of that font that only contains 11 symbols instead of a full char set.

      Compress the font

      Even with the reduced char set in the large font, the flash was still to small, so I decided with experimenting with ways to compress font. For large fonts, this is usually done by using vector fonts. But for smaller fonts, this gets ugly results, so that's not really a good option. Instead, I was looking for ways to compress the bitmap font. Since after compression, the sizes of the single bitmaps won't be the same, an offset table is needed so the symbols can be found again. This further increases the size of the compressed data so an efficient compression is needed to reach the break-even.

      Run-length encoding

      At first I experimented with different forms of run-length encoding, but the resulting compression ratio was disappointing. The following example shows a very simple run length encoding, where only blocks of '0' are encoded. Blocks of '1' or mixed blocks are stored raw. This shows that even with data that is very compression friendly and an optimal setting for the block length, the compression ration isn't very good. For small data sizes, the size of the headers just eats the space savings, so the data needs to be very compressible to even reach the break-even.

      Code: 0xxxx -> xxxx bits of 0
            1xxx  -> xxx bits of uncompressed data
      Original: 00000000110000000000  20 bit
      Encoded:  0100010101101010      16 bit
                ^8x0 ^2x* **^ 10x0

      Geometric compression / Bounding boxes

      I decided to try an encoding scheme, where the break-even is very early. When looking at the font, I figured that most chars do not fill the whole bitmap. So I only stored the used area of the char and have a small header containing the position and size of that area. These headers are tiny and there is only one header for each char. For a 11x18 font the header is just 18 bit (x/w each 4 bit + y/h each 5 bit). So the break-even is reached as soon as we can avoid storing a single column.

      Header: xxxxwwwwyyyyyhhhhh 18 bit
      x: Offset (x)
      w: Width of the stored region
      y: Offset (y)
      h: Height of the stored region 

       Below is the summary of the compression efficiency for the used 11x18 font

      11x18 Font 95 Chars
      Raw size:   11x18 = 198 bits -> 25 bytes (rounded) per char
                   => Total: 2375 bytes
      Compressed: Offset table:...
      Read more »

    View all 3 project logs

    Enjoy this project?



    bossekilund wrote 12/29/2020 at 12:14 point


    Have anyone made this project beside Daniel ?

    If , can / will you then share your experience with me. Thanks ! 

    @Daniel do this also fit for the "old" NT105 ?

      Are you sure? yes | no

    Daniel wrote 01/03/2021 at 12:17 point


    sadly, I don't have a NT105 and there is only very little Information about these on the internet. But it should work as long as they have a similar heater resistance and the TC is in series with the heater.

      Are you sure? yes | no

    bossekilund wrote 01/04/2021 at 11:10 point

    Thanks Daniel.

    Do you have any links to your project with the program code and the 

    print layout file.

    I like to try to make a "copy" of your project and test it with a NT105.

      Are you sure? yes | no

    Daniel wrote 01/04/2021 at 17:40 point

      Are you sure? yes | no

    Richard Sim wrote 11/12/2020 at 08:46 point

    Hey, I think you've mis-understood the iron/tip pinout with regards to the TC/heater connections. The header and TC are in series with a common connection between them. You power the heater through one wire and the common, and sense the TC with the remaining wire and the common - you shouldn't be powering the heater through the TC.

      Are you sure? yes | no

    Daniel wrote 11/26/2020 at 20:04 point

    It sounds odd and I didn't believe that at first, but the two pins are indeed shorted within the tip. At least I couldn't detect the TC voltage between these two pins. So the only way to power the heater is through the TC.

    Even the cable has three wires, so it doesn't make any sense. My guess is that JBC decided this quite late in the design stage. Probably couldn't fit all the connections withing that small tip.

      Are you sure? yes | no

    Similar Projects

    Does this project spark your interest?

    Become a member to follow this project and never miss any updates