Close
0%
0%

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 with tool individually values 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.

Plug

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

Voltage

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, be careful with the choice of power supply.

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

Preview
Download

  • 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 2 project logs

Enjoy this project?

Share

Discussions

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 a day ago 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