One way to solve this problem is to use a serial monitor (like this one I built before) to output the values onto an LCD display. But if your application generates a lot of messages, it would still be hard to spot the relevant information as you can only see the last couple of lines of the data.

So my solution is to add a none-volatile off-screen buffer to the serial display so that multiple rows of data can be captured during run time and retained for later debugging.

While ATmega328 has built-in EEPROM of 1Kbytes, there is not nearly enough space to store much information for debugging purposes, so clearly some kind of external memory is needed.

For the external memory, I prefer using FRAM over EEPROM as FRAM can be written to almost instantaneously whereas for EEPROM some delay is required for the write operation. Also, FRAM can handle many more read/write cycles which makes it ideal for this kind of applications in which data needs to be refreshed all the time. In one of my previous blog postings, I wrote about how to interface FRAM with Arduino. You can refer to that posting for more details.

In my implementation, I used two Ramtron FM25C160‘s which provide 4 Kbytes of storage space. And I used a standard 16×2 character LCD for display. If we allow each line to contain up to 32 bytes of data (16 bytes will be off screen, but can be viewed via scroll function) we will have 128 lines available to us in the buffer. If this is not sufficient, you can always add more memory chips or choose one that offers bigger storage space.

Board layout

To store the information sent to the serial monitor in the off-screen buffer, a circular buffer construct is needed. The serial data stream is stored into the circular buffer as it comes in and when the buffer becomes full, the pointer that points to the buffer’s bottom address is incremented, purging the oldest record in the buffer and making room for another a new row in the mean time. So the circular buffer always contains the latest serial outputs (up to the latest 128 lines in this setup). You can find the implementation details in the full code listing at the end.

To simply the coding a little bit, the values of the pointers for tracking the buffer top, bottom and the current scroll position are kept in volatile memory (RAM), they are flushed to the ATmega’s EEPROM on demand by pressing the “save” button. So if you want to save the data recorded so far (note that the actual data is always stored in the buffer, but without saving the buffer pointers, there is no way to retrieve it), you can press the “save” button before powering off the MCU. When the MCU is first powered up, it checks to see whether the buffer location pointers were previously stored, and if so the previously saved values are loaded and the displayed content is scrolled to that position so that user can continue to work on the data in exactly the same state as before. The save button also functions as a “clear” button in my implementation. If you hold down the “save” button for more than a second, all buffer pointer locations are reset to zero and all information previously stored in the FRAM is cleared. You can examine the source code for more details.

Of course we could have just used a few dedicated locations in the FRAM to store the buffer pointer information on every single buffer write instead of saving this information in EEPROM on the MCU. This alternative approach would probably be a little more convenient as the buffer pointers are always updated and saved automatically each time when a data row is saved. There is no particular reason why I couldn’t have done that. It is totally up you to decide which is the best method to meet your particular need.

In the picture below you can see the finished serial display. Besides the save/clear button mentioned earlier, there are four additional buttons for scrolling.

LCD with Off-screen FRAM buffer

Note that I omitted the UART to RS232 converter chip since most of my debugging are done via UART. But you can easily add one if you intend to use it with RS232 voltage level compatible devices.

Here is a typical usage scenario: connect the serial display to the circuit you are debugging via serial cables (Rx, Tx and Gnd). Make sure that both sides operate at the same baud rate (in this case it’s 9600 bps). Start your testing. The serial outputs are then stored into the none-volatile memory on the serial display board. When you are done capturing the data, press the save button and you can then power off and disconnect the serial display from your test circuit and analyze the stored information later.

Download:

screenbuffer.tar.gz

DC motors, especially brushed motors tend to generate a lot of noise (both acoustical and electrical), and the electrical noise can interfere with RF circuits and even logic circuits if not isolated properly, leading to erratic behaviors. This kind of noise-induced erratic behavior can sometimes be very hard to trace and debug.

The electrical noise generated by a DC motor falls into two categories: Electromagnetic interference (RF interference) and the electrical noise generated on the power rail.

Suppressing RF interference

The RF interference can couple into other portions of the circuit and cause circuit malfunction and performance degradation. If your project uses RF data link for instance, the motor induced RF noise can significantly decrease the usable RF range.

The level of RF interference is dependent on a few different factors: for instance, the type of the motor (brushed or brushless), driving waveform and load can all impact the severity of the RF interference. Typically, brushed motors generate more RF interference than their brushless counterparts. But the design of the motor, regardless of the type, also affects the RF leakage greatly. A small cheap toy brushed motor can sometimes generate magnitudes more RF interference than a carefully designed more powerful motor.

To reduce the level of RF interference, motors should be placed as far away from sensitive circuits as physically possible. Motor’s metal casing typically provides enough shielding capability for reducing the over-the-air RF interference, but an extra metal enclosure should provide much better RF interference reduction capability. It is important that in either case, the metal casing (either the motor casing or the metal enclosure) should be properly grounded (e.g. via ground strap at a single point).

The RF signals generated by the motor can also be coupled into the circuit, which forms what is known as the common mode interference. This type of interference cannot be eliminated by shielding, but can be reduced effectively via a simple LC low-pass filter. You can find a couple of examples in the next section.

Reducing Other Electrical Noises

Another source of electrical noise comes from the power rail. Since power supply has a none-zero internal resistance, the none constant motor current flow during each rotation period would translate into voltage ripples across the power terminals. The following oscilloscope waveform capture shows the noise at the battery terminal when a small toy motor is powered via 4 AA Ni-Mh batteries with no filter added.

Motor Electrical Noise Measured at Power Terminal

As you can see, the noise level is quite severe and the noise Vpp reached more than 3 Volts at times, which is more than enough to cause logic gates malfunction. And this kind of noise is likely to affect the performance of Op Amps and other analog circuitry as well.

With a simple LC low-pass filter (100nf capacitor, 10mH choke for instance), the waveform improved somewhat, but the noise signal is still noticeable at around 0.5V Vpp:

Motor Electrical Noise Measured at Power Terminal (LC Filter)

Keep in mind that the above captures were taken using newly charged batteries. The noise level will likely be progressive worse as batteries discharge due to the increased internal resistance.

To further reduce the electrical noise, further filtering at the power source is needed. Typically, this is done by adding a larger capacitor (e.g. 1000uF and above) across the power terminals to lower the effective resistance of the power supply and thus improve transient response.

The following schematics show a couple of typical circuits for filtering out motor electrical noise.

The first filtering scheme is suited for uni-directional motor driving circuit. And the second one is suited for bi-directional motor driving circuit.

Motor with simple Speed Controller

In bi-directional scenario (e.g. using an H-Bridge), two sets of LC filters should be used as the power to the motor is essentially center tapped.

Motor with H-Bridge

The values for the inductors and capacitors used in the filters can be varied experimentally to achieve the best results. But in general, the capacitors on the motor side are several hundred nano-farads and the inductors are several milli-heneries. Higher order LC filters can further improve the noise-filtering performance but are rarely necessary.

Preventing Ground Loop

In the schematics shown above, please pay special attention to the grounding location. It is important to have the ground tied to a common place which is as close to the power supply source (i.e. the negative terminal of the battery) as possible. This grounding practice is especially important when there are other sensitive electronics component (e.g. MCUs, analog circuits) in your projects as the noise induced in the ground loop by the ground current can be significant if not taken care of properly.

If it is not possible to ensure a single grounding location, you should at least have the multiple subsystems’ (in this case motor system and the MCU circuits) grounds tied at a single point as close to the negative power terminal as possible. And within each sub system, make sure that the ground plane’s impedance is as low as possible.

With sufficient shielding, filtering and correct grounding practices the electrical noise generated by an electric motor can be reduced to a level that is low enough for even the most sensitive circuits.

Renesas MCUs

I have not spent too much time playing with them yet. But the latter one (RX62N) definitely looks more interesting to me. On the demo board it features an embedded web server and a VNC server. This type of configuration is very useful in designing networked smart appliances. The included evaluation software (Renesas High Performance Embedded Workshop) is only fully functional for 60 days though, I am not sure if that will be enough time for me to explore.

In this blog post I will give an example on interfacing two Ramtron FM25C160 FRAM chips with Arduino. Since the basic operations on an FRAM are very similar to those on a standard EEPROM, I would recommend reading this SPI EEPROM tutorial first if you are not familiar with the protocol.

The main difference between the operation modes of an FM25C160 and a standard EEPROM is that FM25C160 allows multi-byte sequential reads and writes whereas EEPROM typically has a limited write buffer and long writes beyond the buffer length must be broken into multiple writes. We will take advantage of this in our code later.

The following schematic shows the simplest way to interface multiple FRAM (or EEPROM) chips with Arduino.

Interfacing 2 FM25C160 with Arduino

For our simple implementation, the HOLD and WP pins are disabled (tie to Vcc) and the corresponding data pins (SO, SI and SCK) are connected together. The CS pin of each FRAM is controlled individually by an Arduino IO pin so that each FRAM can be selected and operated on individually.

The following code shows how to access multiple FRAM chips using Arduino. For FM25C160, the maximum address is 0x7FF (since it has 16 Kbits and 2K bytes) so we assume that addresses between 0×800 and 0×1000 belong to the second chip, and addresses beyond 0×1000 are invalid.

#include <SPI.h>

const byte CMD_WREN = 0x06; //0000 0110 Set Write Enable Latch
const byte CMD_WRDI = 0x04; //0000 0100 Write Disable
const byte CMD_RDSR = 0x05; //0000 0101 Read Status Register
const byte CMD_WRSR = 0x01; //0000 0001 Write Status Register
const byte CMD_READ = 0x03; //0000 0011 Read Memory Data
const byte CMD_WRITE = 0x02; //0000 0010 Write Memory Data

const int FRAM_CS1 = 10; //chip select 1
const int FRAM_CS2 = 9; //chip select 2

/**
 * Write to FRAM (assuming 2 FM25C160 are used)
 * addr: starting address
 * buf: pointer to data
 * count: data length.
 *        If this parameter is omitted, it is defaulted to one byte.
 * returns: 0 operation is successful
 *          1 address out of range
 */
int FRAMWrite(int addr, byte *buf, int count=1)
{
  int cs = 0;

  if (addr > 0x7ff)  {
    addr -=0x800;
    cs = FRAM_CS2;
  } else {
    cs = FRAM_CS1;
  }

  if (addr > 0x7ff) return -1;

  byte addrMSB = (addr >> 8) & 0xff;
  byte addrLSB = addr & 0xff;

  digitalWrite(cs, LOW);
  SPI.transfer(CMD_WREN);  //write enable
  digitalWrite(cs, HIGH);

  digitalWrite(cs, LOW);
  SPI.transfer(CMD_WRITE); //write command
  SPI.transfer(addrMSB);
  SPI.transfer(addrLSB);

  for (int i = 0;i < count;i++) SPI.transfer(buf[i]);

  digitalWrite(cs, HIGH);

  return 0;
}

/**
 * Read from FRAM (assuming 2 FM25C160 are used)
 * addr: starting address
 * buf: pointer to data
 * count: data length.
 *        If this parameter is omitted, it is defaulted to one byte.
 * returns: 0 operation is successful
 *          1 address out of range
 */
int FRAMRead(int addr, byte *buf, int count=1)
{
  int cs = 0;

  if (addr > 0x7ff)  {
    addr -=0x800;
    cs = FRAM_CS2;
  } else {
    cs = FRAM_CS1;
  }

  if (addr > 0x7ff) return -1;

  byte addrMSB = (addr >> 8) & 0xff;
  byte addrLSB = addr & 0xff;

  digitalWrite(cs, LOW);

  SPI.transfer(CMD_READ);
  SPI.transfer(addrMSB);
  SPI.transfer(addrLSB);

  for (int i=0; i < count; i++) buf[i] = SPI.transfer(0x00);

  digitalWrite(cs, HIGH);

  return 0;
}

void setup()
{
  Serial.begin(9600);
  pinMode(FRAM_CS1, OUTPUT);
  digitalWrite(FRAM_CS1, HIGH);
  pinMode(FRAM_CS2, OUTPUT);
  digitalWrite(FRAM_CS2, HIGH);

  //Setting up the SPI bus
  SPI.begin();
  SPI.setDataMode(SPI_MODE0);
  SPI.setBitOrder(MSBFIRST);
  SPI.setClockDivider(SPI_CLOCK_DIV2);

  //Test
  char buf[]="This is a test";

  FRAMWrite(1, (byte*) buf, 14);
  FRAMRead(1, (byte*) buf, 14);

  for (int i = 0; i < 14; i++) Serial.print(buf[i]);
}

void loop()
{
}

While the above code supports memory spanning multiple chips, each read/write operation is limited within a single chip. This should be sufficient under most scenarios. If reading/writing beyond a single chip’s boundary is required, logic needs to be added so that when the address wraps around to 0 the CS of the current chip is deselected and the CS of the next chip is selected.

In this post, I will show you how to interface it with an ATmega328 MCU using Arduino libraries. Because the operating voltage range for MMA8453Q is between 1.95V and 3.6V, you will need to either power your MCU using 3.3V or use an I2C voltage level translator (such as TI’s PCA9517 Level-Translating I2C Bus Repeater) so that MMA8453Q can be powered within its specified voltage range.

MMA8453Q uses the I2C protocol, so I assumed that I could use the default Arduino Wire library. Unfortunately, MMA8453Q uses repeated start condition for the read operations and the default Wire library cannot handle without any modifications. As a result of this, it does not matter which register you try to read from, the returned value is always the content of the status register (at address 0×00) when using the Wire library due to the reset between the write of the register address and the subsequent read. Fortunately, there are alternative I2C libraries available for Arduino that address this issue. And the I2C library I used below is from DSSCircuits.

I mounted my MMA8453Q on a proto-board using my favorite hand-soldering method. And connected it to my customized Arduino experiment board and set the board voltage to 3.3V instead of the usual 5V.

MMA8453Q Breakout Board

MMA8453Q I2C Setup

The following is some sample code. Note that I only provided a few basic functions and not all the register constants are used in the code. But all the remaining functions can be easily implemented using regRead/regWrite functions and the register definitions listed below:

#include <I2C.h>

const byte REG_STATUS = 0x00; //(R) Real time status
const byte REG_OUT_X_MSB = 0x01; //(R) [7:0] are 8 MSBs of 10-bit sample
const byte REG_OUT_X_LSB = 0x02; //(R) [7:6] are 2 LSBs of 10-bit sample
const byte REG_OUT_Y_MSB = 0x03; //(R) [7:0] are 8 MSBs of 10-bit sample
const byte REG_OUT_Y_LSB = 0x04; //(R) [7:6] are 2 LSBs of 10-bit sample
const byte REG_OUT_Z_MSB = 0x05; //(R) [7:0] are 8 MSBs of 10-bit sample
const byte REG_OUT_Z_LSB = 0x06; //(R) [7:6] are 2 LSBs of 10-bit sample
const byte REG_SYSMOD = 0x0b; //(R) Current system mode
const byte REG_INT_SOURCE = 0x0c; //(R) Interrupt status
const byte REG_WHO_AM_I = 0x0d; //(R) Device ID (0x3A)
const byte REG_XYZ_DATA_CFG = 0xe; //(R/W) Dynamic range settings
const byte REG_HP_FILTER_CUTOFF = 0x0f; //(R/W) cut-off frequency is set to 16Hz @ 800Hz
const byte REG_PL_STATUS = 0x10; //(R) Landscape/Portrait orientation status
const byte REG_PL_CFG = 0x11; //(R/W) Landscape/Portrait configuration
const byte REG_PL_COUNT = 0x12; //(R) Landscape/Portrait debounce counter
const byte REG_PL_BF_ZCOMP = 0x13; //(R) Back-Front, Z-Lock trip threshold
const byte REG_P_L_THS_REG = 0x14; //(R/W) Portrait to Landscape trip angle is 29 degree
const byte REG_FF_MT_CFG = 0x15; //(R/W) Freefall/motion functional block configuration
const byte REG_FF_MT_SRC = 0x16; //(R) Freefall/motion event source register
const byte REG_FF_MT_THS = 0x17; //(R/W) Freefall/motion threshold register
const byte REG_FF_MT_COUNT = 0x18; //(R/W) Freefall/motion debounce counter
const byte REG_TRANSIENT_CFG = 0x1d; //(R/W) Transient functional block configuration
const byte REG_TRANSIENT_SRC = 0x1e; //(R) Transient event status register
const byte REG_TRANSIENT_THS = 0x1f; //(R/W) Transient event threshold
const byte REG_TRANSIENT_COUNT = 0x20; //(R/W) Transient debounce counter
const byte REG_PULSE_CFG = 0x21; //(R/W) ELE, Double_XYZ or Single_XYZ
const byte REG_PULSE_SRC = 0x22; //(R) EA, Double_XYZ or Single_XYZ
const byte REG_PULSE_THSX = 0x23; //(R/W) X pulse threshold
const byte REG_PULSE_THSY = 0x24; //(R/W) Y pulse threshold
const byte REG_PULSE_THSZ = 0x25; //(R/W) Z pulse threshold
const byte REG_PULSE_TMLT = 0x26; //(R/W) Time limit for pulse
const byte REG_PULSE_LTCY = 0x27; //(R/W) Latency time for 2nd pulse
const byte REG_PULSE_WIND = 0x28; //(R/W) Window time for 2nd pulse
const byte REG_ASLP_COUNT = 0x29; //(R/W) Counter setting for auto-sleep
const byte REG_CTRL_REG1 = 0x2a; //(R/W) ODR = 800 Hz, STANDBY mode
const byte REG_CTRL_REG2 = 0x2b; //(R/W) Sleep enable, OS Modes, RST, ST
const byte REG_CTRL_REG3 = 0x2c; //(R/W) Wake from sleep, IPOL, PP_OD
const byte REG_CTRL_REG4 = 0x2d; //(R/W) Interrupt enable register
const byte REG_CTRL_REG5 = 0x2e; //(R/W) Interrupt pin (INT1/INT2) map
const byte REG_OFF_X = 0x2f; //(R/W) X-axis offset adjust
const byte REG_OFF_Y = 0x30; //(R/W) Y-axis offset adjust
const byte REG_OFF_Z = 0x31; //(R/W) Z-axis offset adjust

const byte FULL_SCALE_RANGE_2g = 0x0;
const byte FULL_SCALE_RANGE_4g = 0x1;
const byte FULL_SCALE_RANGE_8g = 0x2;

const byte I2C_ADDR = 0x1c; //SA0=0

/*
  Read register content into buffer.
  The default count is 1 byte. 

  The buffer needs to be pre-allocated
  if count > 1
*/
void regRead(byte reg, byte *buf, byte count = 1)
{
  I2c.write(I2C_ADDR, reg);
  I2c.read(I2C_ADDR, reg, count);

  for (int i = 0; i < count; i++)
    *(buf+i) = I2c.receive();
}

/*
  Write a byte value into a register
*/
void regWrite(byte reg, byte val)
{
  I2c.write(I2C_ADDR, reg, val);
}

/*
  Put MMA8453Q into standby mode
*/
void standbyMode()
{
  byte reg;
  byte activeMask = 0x01;

  regRead(REG_CTRL_REG1, &reg);
  regWrite(REG_CTRL_REG1, reg & ~activeMask);
}

/*
  Put MMA8453Q into active mode
*/
void activeMode()
{
  byte reg;
  byte activeMask = 0x01;

  regRead(REG_CTRL_REG1, &reg);
  regWrite(REG_CTRL_REG1, reg | activeMask);
}

/*
  Use fast mode (low resolution mode)
  The acceleration readings will be
  limited to 8 bits in this mode.
*/
void lowResMode()
{
  byte reg;
  byte fastModeMask = 0x02;

  regRead(REG_CTRL_REG1, &reg);
  regWrite(REG_CTRL_REG1, reg | fastModeMask);
}

/*
  Use default mode (high resolution mode)
  The acceleration readings will be
  10 bits in this mode.
*/
void hiResMode()
{
  byte reg;
  byte fastModeMask = 0x02;

  regRead(REG_CTRL_REG1, &reg);
  regWrite(REG_CTRL_REG1,  reg & ~fastModeMask);
}

/*
  Get accelerometer readings (x, y, z)
  by default, standard 10 bits mode is used.

  This function also convers 2's complement number to
  signed integer result.

  If accelerometer is initialized to use low res mode,
  isHighRes must be passed in as false.
*/
void getAccXYZ(int *x, int *y, int *z, bool isHighRes=true)
{
  byte buf[6];

  if (isHighRes) {
    regRead(REG_OUT_X_MSB, buf, 6);
    *x = buf[0] << 2 | buf[1] >> 6 & 0x3;
    *y = buf[2] << 2 | buf[3] >> 6 & 0x3;
    *z = buf[4] << 2 | buf[5] >> 6 & 0x3;
  }
  else {
    regRead(REG_OUT_X_MSB, buf, 3);
    *x = buf[0] << 2;
    *y = buf[1] << 2;
    *z = buf[2] << 2;
  }

  if (*x > 511) *x = *x - 1024;
  if (*y > 511) *y = *y - 1024 ;
  if (*z > 511) *z = *z - 1024;
}

void setup()
{
  I2c.begin();
  Serial.begin(9600);

  standbyMode(); //register settings must be made in standby mode
  regWrite(REG_XYZ_DATA_CFG, FULL_SCALE_RANGE_2g);
  hiResMode(); //this is the default setting and can be omitted.
  //lowResMode(); //set to low res (fast mode), must use getAccXYZ(,,,false) to retrieve readings.
  activeMode(); 

  byte b;
  regRead(REG_WHO_AM_I, &b);
  Serial.println(b,HEX);
}

void loop()
{
  int x = 0, y = 0, z = 0;

  getAccXYZ(&x, &y, &z); //get accelerometer readings in normal mode (hi res).
  //getAccXYZ(&x, &y, &z, false); //get accelerometer readings in fast mode (low res).
  Serial.print(x);
  Serial.print(" ");
  Serial.print(y);
  Serial.print(" ");
  Serial.print(z);
  Serial.println();

  delay(500);
}

With some modification to the getAccXYZ function, similar code can be used with MMA8450Q, MMA8451Q and MMA8452Q as well.

Here are a few photos to prove. I ordered a few components a couple of weeks ago, and included in my order were two MMA8453Q accelerometers.

When I received my order, I found a rather large package inside (the AA battery is shown here to contrast the size of the packaging):

Packaging 1

Inside the ESD safe bag is a full QFN tray with moisture absorbing packets and a humidity indicator card wrapped in another layer of protective wrapping.

After opening the QFN tray… there are the two accelerometers!

Packaging 2

Packaging 3

Unbelievable packaging!

I have seen some people using small fans to blow air across the work area. This works pretty well as long as you don’t deal with the SMD stuff. Those small SMD components can be blown away very easily. So my preferred method is still sucking air out of the work area.

So I experimented with a few different methods and found that using server blower fans achieved the best results.

The following is my version of the fume extractor using two 10cm 24V server blower fans.

Fume Extractor

Fume Extractor

When powered at the rated voltage (24V), the created suction is effective at least within 2 to 3 feet. This should cover enough area for your soldering work.

A draw back is that this kind of blower fans are very noisy. But they can be operated at lower voltage to reduce the noise (and thus the air flow). You can easily control the air flow with a TRIAC dimmer circuit or using a variable power supply for the blowers.

Since the release of Arduino 1.0 a few weeks ago, I have received quite a few inquiries on how to make the plugin work with the new Arduino 1.0. The short answer is you will have to pretty much follow the steps I mentioned to re-create a project sample module with the up-to-date makefile.

Unfortunately, the original makefile (modified from the one by Mellis et al. for Arduino 018) is no longer compatible with the latest 1.0 environment due to the many breaking changes introduced in this new Arduino IDE release.

Anyway, I just updated the makefile to make it work with Arduino 1.0, and you can download it towards the end. The new makefile was tested under Ubuntu 10.04 64bit Linux environment. You will most likely need to make some changes to the makefile for it to work under Windows.

Depending on the installation locations and whether additional libraries are used, you may also need to change the following sections in the makefile:

INSTALL_DIR = $(HOME)/arduino-1.0
...
#add your specific c modules at the end
C_MODULES = \
...
#add your specific c++ modules at the end
CXX_MODULES = \

Here are a few additional changes: the main code file name is changed from main.pde to main.cpp in the project. The original makefile assembles the main.cpp file behind the scene, in the event there is an compilation error the error shown is from the assembled file not main.pde. This behavior could cause some confusion. In this updated makefile, the compilation is done directly against the code file you are working on so it should be slightly more convenient to use. Also, the include directives are consolidated thanks to the latest Arduino IDE changes. If you are using chips other than ATmega328 though, you will need to change the $VARIANTS variable setting to include the correct pins_arduino.h header file:

VARIANTS = $(INSTALL_DIR)/hardware/arduino/variants/standard

Using this makefile, you should be able to configure your favorite IDE (NetBeans, Eclipse, CodeBlocks, KDevelop, etc.) to work with Arduino projects.

You can also download the compiled NetBeans module from below. Just keep in mind that given the nature of this project type, the makefile is static which means you will have to add your own C_MODULES/CXX_MODULES in the makefile if you are using libraries other than those come as default.

The following build targets are available:

all, build, clean, upload

Downloads

Makefile (for Arduino 1.0, tested under Linux)
NetBeans Plugin for Arduino 1.0 (tested under NetBeans 7.0.1)

There is a seal on the back of the unit saying (in Chinese) that warranty would be voided if the seal is broken. But since the seal is just a thin piece of paper, I suspect that it may even break from the unit just being moved around during shipping and handling. In any event, taking the cover off is as simple as just removing eight screws, four on each side. There is not any mechanism to lock the cover in place so putting the cover back requires a little more effort since you have to match the screw holes exactly.

Internal layout

Diaphragm pump on rubber damper

The first thing I noticed inside once I opened up the case is the Gordak brand marked on the pneumatic pump. Remember I wrote last time that I suspected that the unit was made by Gordak and was simply just re-branded as X-TRONIC? I even more positive this is the case now after seeing this. And if you look at the sticker on top of the transformer, you will also see “GD-952″ printed on it. Presumably, this X-TRONIC 4040 is just a re-branded Gordak 952 model. In fact, I suspect that all those 952 hot air rework stations (e.g. KADA) are more or less originated from the same design and manufacturer.

As you can see from the pictures above, the internal layout is fairly clean, and all wires are routed neatly. The pneumatic pump is mounted on top of a soft rubber frame to reduce the pump noise and vibration during operation. Also, the case is grounded at two places.

The pump itself is further secured by a few cable ties, and this is again a very typical assembling technique for devices at this price range.

The following YouTube video should give you an idea of what kind of environment this rework station might have been built in. Even though this video is for a different model (KADA 852D+), the actual construction should be more or less the same.

Now let us move onto the circuit board. Clearly, in order to reduce assembly cost, all the components used here are through-hole components and are all manually soldered. The PCB is single sided and its quality looks just so so, and the board does not seem to have any solder mask on the trace side.

Ideally, for this kind of circuit board we should really be using double-sided PCBs as there are components mounted on the other side of the board as well. But clearly, to keep the total manufacturing cost down every penny counts.

The two 20-pin ICs are presumably MCUs used to control the hot air, the soldering iron and to drive the two 7-segment displays. The circuitry around the two MCUs are virtually identical so clearly one chip is used for the hot air and the other one is used for the soldering iron. The manufacturer had sanded off the chip markings on the MCUs deliberately to make it harder for other competitors to copy the design.

Main circuit board

Main circuit board

There are three TRIACs (two BT136 and one BTA08-600C) used in the design, I assume that one is used for adjusting the pump speed and the other two are used for adjusting the hot air heater and the soldering temperature.

There are two random phase opt-isolators (MOC3023) used in conjunction with the two TRIACs to control the heating elements in the hot air wand and the soldering iron. Since the pump itself has no physical contact with anything else, its control circuitry does not have to be isolated. The hot air wand and especially the soldering iron has to be isolated since they come into contact with the components being worked on. The op-amps used for the temperature sensors are HA17358 dual operational amplifiers.

TRIACs

The soldering job quality is really just mediocre , which is more or less expected results from this kind of hand-soldering assembly line. As you can see that the components are not aesthetically aligned, and leads on some of the components soldered on the copper side of the PCB are not all properly trimmed. Look at the LED indicator in the picture below, did they simply just forget to trim the leads after soldering?

Soldering job

Soldering job

Also, there seems to be an improperly mounted TO-220 device (see picture to the right), it could be a transistor or a voltage regulator. But in general, TO-220 devices should be mounted on heatsinks which are then secured onto the PCB. But I guess this probably is not a big deal as the rework station is designed for stationary use only. But even so, the vibration from the pneumatic air pump could cause some stress on those soldering points.

Conclusions

Even though my review here for the internal construction is not all that rosy, considering the price of this rework station and its excellent performance I mentioned last time, it remains a good choice for engineers and hobbyist alike.

For those who are impatient, you can find my review conclusions in the summary section towards the end.

Depending on where you got your unit, this rework station can be had for just above 100 US dollars. For this price range, it is clearly targeted at electronics enthusiasts and hobbyists.

In order to achieve this low price point, there are some design compromises the designers had to make. For instance, the unit does not have an air flow meter, so the speed of the air flow cannot be adjusted precisely and can only be gauged by experience. This should not be an issue for general uses however, as most of the SMD soldering work does not need that level of precision in a non-professional setting. Also, the hot air wand does not turn off automatically when it is in the holder which some might consider it a fire risk. Other slightly more expensive brands typically have magnetic sensors built in and would automatically turn off the heating element once the hot air wand is placed back onto the holder, allowing the unit to properly cool off. In my opinion though, the omission of this feature is actually more convenient as having to wait for the hot air wand to achieve its operation temperature every time can be quite annoying.

It seems that there are two models (X-TRONIC 4040 and X-TRONIC 4000) on the market that are very similar to one another. I am actually not quite sure whether there is any difference between model X-TRONIC 4040 and X-TRONIC 4000. As far as I can tell, the only difference seems to be that the 4040 model includes a lighted magnifier lamp and the 4000 model does not. But the main units themselves seem to be identical, both have “X-TRONIC 4000 Series” printed on them (see picture below).

Hot air and iron both off

My unit came with the lighted magnifier lamp. At first I was a little skeptical as the lamp feels pretty cheap and the base is lighter than adequate which means that it can tip over easily if the lamp is leaning too much in one direction. But after I started using it for a while, I found that the magnifier actually worked surprisingly well, presumably due to its large size. Those tiny markings on the SMDs can be easily identified without too much eye strain. It is especially pleasant to use when compared to my small eye loupe I used before. The included fluorescent ring lamp is not particularly bright however and is not useful as a bench light, but it is bright enough for what it does. Finding the replacement bulb could be difficult however, I have not seen any ring shaped fluorescent bulbs of the exact size. But I am not too worried, as the ring lamp can be easily adapted to using LEDs lighting should it break.

Lighted magnifier lamp

The tubing for the hot air wand comes already attached to the main unit. There are three screws at the bottom of the unit which are used to secure the pneumatic pump during shipping and must be removed prior to turning on for the first time. The only parts that need to be attached are the soldering iron and the holder for the hot air wand. The soldering iron has a keyed 5-pin female plug that plugs firmly into socket on the main unit. The ring outside the plug is threaded and secures tightly onto the socket.

Iron connector

The metal holder for the hot air wand can be mounted on either side of the unit which is clearly a nice design consideration. But as you can see in the picture below, one of the screws is in the way of the holder when the holder is mounted regardless of which side the holder is on. The protrusion of the screw makes the holder surface not resting flush against the side. But it really is just a minor annoyance than any real problem. The main unit itself has three mounting holes on each side of the case but only two are needed for the holder included. It is quite possible that the case was designed for multiple brands and different types of holders can be mounted.

The unit comes with four hot air nozzles with the following nozzle sizes: 9.5mm, 6.5mm, 4.5mm and 2.5mm. These sizes should cover a good range of rework tasks. The quality of these nozzles is not all that great though, a couple of the nozzles I received showed sign of rusting inside. But for the price I paid, I really cannot complain too much here. These cosmetic defects are not likely to affect the soldering job nor would they affect the durability of the nozzle anyway.

Hot air wand holder

Hot air nozzle

The soldering iron that comes with the X-TRONIC 4040 (or X-TRONIC 4000) is smaller and lighter than a typical 30W soldering iron (see comparison in the picture below), but it grips nicely and holds comfortably in hand. The connection cable is soft and flexible making it less obtrusive when soldering. There are ten assorted soldering tips included in the package: 4 conical tips (Hakko shape code I, 0.25mm to 1mm); 4 slanted-cut tips (Hakko shape code BC/C, 1mm to 4mm), 1 screw driver tip (Hakko shape code D, 2mm x 1mm) and 1 knife tip (Hakko shape code K, 7mm x 0.5mm). I am actually not sure whether the Hakko ones would fit properly and the model numbers are included just for reference purposes.

All the tips are coated and presumably offer a longer service life. But from the picture below you can see that the coating is only applied to the very tip of the ironing tip and overall the tip’s quality does not look as good as other soldering tips that I have used before. While I did not encounter any issues during the past couple of days’ intense use and there is no signs of any premature wear and tear, these tips’ long term performance remains to be seen. But again, there is something to be said about quantity versus quality. Given the number of tips included, you can basically try out a few different ones and settle on the tip you like the best. Should that one wear out you can always buy a higher quality replacement tip of the exact kind.

If you look carefully, you can see the marking on the tips reads “Gordak”. I assume that these tips are sourced from Gordak Electric Factory. And if you followed the link, you will see that Gordak is specialized in manufacturing SMD rework soldering stations. Browsing through a few of its products, I found that the X-TRONIC 4040 looks strikingly similar to Gordak’s 952B except perhaps that 4040 has a digital temperature readout for the soldering iron but the 952B has only a temperature labeled dial and a LED indicator for the iron to reduce cost. But if you look at the side panel, there are three mounting holes for the holder, which is exactly the same as the X-TRONIC 4040 I have.

I would not be surprised if X-TRONIC 4040/4000 are actually manufactured by Gordak after all, and they are simply just re-branded as X-TRONIC. This practice is very common in these low-end electronic products. In fact the X-TRONIC 4040 rework station was shipped in generic white boxes with no manual or any manufacturer information – another tell sign of these re-branded cheap Chinese products.

Iron size

Iron tip

The hot air wand and the soldering iron can be operated independently (see pictures below). The larger switch and the two knobs to the right control the hot air wand while the smaller switch and the knob towards the bottom middle control the soldering iron. It is clear that the designer had put more emphasis on the hot air portion than the soldering portion as there are two additional LED indicators for the hot air wand control but only a 7-segment display for the soldering iron.

The upper LED indicator seems to be on whenever the hot air wand is turned on and the bottom LED indicates whether the hot air heater is on or not. When the hot air wand reaches the preset temperature, the heater would switch between on and off every few seconds to maintain a steady temperature and you can see this from the flashing of the bottom LED indicator.

It is quite intriguing to me as to why the upper LED was included in the design, as it serves no apparent purpose other then telling you that the hot air unit is on. But you can already tell this via the 7-segment temperature display. So maybe the basic design of this hot air rework station is shared with ones that do not offer the 7-segment display, in which case the LED would be used to indicate whether the hot air unit is on.

Hot air only (hot air heater on)	Hot air only (hot air heater off)
Soldering iron on only	Both soldering iron and hot air on

From the pictures above, you can see that the temperature display is in Celsius. Unfortunately, there is no way to change this display setting to Fahrenheit. While I personally do not really care what the temperature unit is in as I could convert them back and forth easily, it is a little disappointing to see that a product sold in North America does not offer Fahrenheit reading as an option.

The hot air wand takes some time to reach the preset temperature. From power up, it takes roughly 45 seconds to reach 350 C (662 F) and it takes an additional 15 seconds if you want to go up to 375 C (707 F). According to the data sheet, the hot air temperature can be adjusted between 150 to 500 Celsius (302 to 932 Fahrenheit) and the air flow can be adjusted from 0.3 to 24 liters per minute. These specifications are quite typical among these entry level rework stations.

The heater for the hot air is specified at 250W, which seems to be a bit under powered (most rework stations in this price range have heaters power rated north of 500W). To be sure, I measured the power consumption of the unit with just the hot air on and the reading came at around 266 W which means that the heater specification is more or less accurate. So maybe by including a beefier heating element the heat up time will be shorter.

But the hot air feels adequate once it reaches operating temperature and I had no trouble de-soldering large components such as a 256 pin TQFP chip and a large BGA chip. While I could not measure the actual air flow volume, it seems that the hot air comes out quite strong when the air flow dial is set to the maximum.

The soldering iron is rated at 60W, but it measures only at about 45W when in use. So the number in the specification is clearly overstated. But even at 45W there is sufficient power for most soldering job. Unlike the hot air wand, the soldering iron heats up very quickly and within 20 seconds after powering on it is ready for use.

When the unit is turned off, it does not power off immediately if the hot air wand was used. Instead, the pneumatic pump will continue to operate until the nozzle temperature drops below 50 degree Celsius (122 F) as a safety measure. One thing to note is that the air flow speed during this cool off period is set according to the dial setting, which means if you accidentally turned down the airflow after shutting down the unit the nozzle temperature would go down very slowly due to the weak air flow. In my opinion during this cool off period the airflow should be automatically increased to the maximum so that the heating element can cool down quickly.

As I mentioned before, there is no auto power-off feature for the hot air wand, this means that the hot air will continue to blow at the set temperature and speed even when the wand is placed back in the holder. This could potentially be a safety issue given the high temperature at the nozzle outlet. But as long as your rework station has enough clearance from everything else, it really poses very little risk as the temperature drops quickly when you move away from the nozzle.

This unit also has no central shut-off switch (i.e. hard-wired on/off switch) since it has to provide power to the pneumatic air pump after the hot air unit is switched off. The standby power consumption is at a reasonable 3W.

One thing I noticed is that when you plugin the unit into an outlet, the 7 segment displays would come on briefly before going into standby mode. Since there is no way to really turn off the unit I am a little skeptical as to whether the unit could somehow be accidentally powered on by itself while the switches are off (which would be a safty risk) so I would strongly recommend only connecting it to an power strip which could be turned off independently and double check to ensure that the power is off when you are done with your work. Thankfully this is not an issue for me as I have a central power switch in my lab.

Despite a few aforementioned shortcomings, X-TRONIC 4040/4000 really gives you plenty of bang for the buck. And it does the job pleasantly well.

Summary

Pros:

• Relatively quiet operation
• Hot air wand holder can be placed on either side of the unit
• Soldering iron heats up quickly
• Flexible tubing and wiring
• Replacement heating elements for both the hot air wand and soldering iron included
• Includes a magnifier lamp, which is very useful
• 10 assorted tips included (with one installed)
• Iron and hot air wand can be operated independent of each other
• Good overall performance

Cons:

• Some cosmetic defects
• No air flow meter
• Slightly weak heating element for the hot air
• No central off switch for the unit (system remains connected to the mains when off)
• No auto off capability when hot air wand is placed in holder
• Some parts not of top quality
• Temperature displays only in Celsius.

Anticipating possible power glitches and prolonged power outages, I equipped the data logger with rechargeable batteries and a trickle charger, which could provide many days of run time should the power go off. This turned out to be quite useful when the storm hit last month and left me without power for a week.

The data file came in at around 80 MBs. Since the logger was set to log an entry every 10 seconds, the log file grew quite big and it contained over 3,000,000 rows of data. I created a simple program to smooth out the data and reduced the data points to around 15,000 for plotting. And the final graph is shown below:

Temperature/Humidity Data Over the Past Year

As for the dip in temperature towards the end? Well, you’ve guessed it, that was due to the power outage during the Halloween time when the storm hit.

There are many ways to achieve this. One of the simplest ways is to use a voltage to frequency conversion chip along with an analog temperature sensor such as LM335 or a thermistor, and then transmit the modulated frequency signal via an RF data link module. Alternatively, we can use a digital temperature sensor and sending the sensor readings over RF serial data link digitally. In this post I will stick with the first approach.

The following schematic shows my circuit design:

Wireless Temperature Sensor

Here the 1/4 LM324 (or LM2902) forms a voltage follower to buffer the input voltage from the resistor-thermistor voltage divider, and the divider output is fed into an LM331 voltage to frequency converter. The LM331 portion of the circuit was taken directly from the reference design.

The capacitor at pin 5 needs to be adjusted so that the maximum frequency output from the oscillator is below the maximum bit rates supported by the RF link. The RF data transmitter I used has a maximum bit rate of 2400 bps and thus I used a 47nF capacitor and the oscillation frequency is around 700 Hz under room temperature.

The frequency output from LM331 is again buffered via another 1/4 LM324 (or LM2902) before feeding into the RF data link transmitter. This voltage to frequency circuit is arguably not the most accurate one and you could improve your accuracy by adding an op-amp integrator as illustrated in the datasheet, but for the temperature measurement application we are discussing here, this simple circuit is accurate enough.

Transmitter

According to the LM331 data sheet, the timing components need to have very high stability in order to achieve a high level of accuracy and minimize frequency drift. The picture above shows the finished transmitter portion of the temperature sensor. Note that the power supply must be regulated in order to obtain accurate readings since it is referenced by the thermistor voltage divider.

I could have built the receiver using another LM331 as a frequency to voltage converter and use the voltage readouts to calculate the temperature readings. But then I would need to use an A/D converter to convert the signal back to digital form in order to perform the calculation. To simplify the design, I used an Arduino MCU (ATmega328) to measure the frequency output from the RF data link receiver directly. The following picture shows the setup on the receiver end.

Receiver

The oscilloscope capture below shows the output waveform from the receiver when the transmitter side is under room temperature.

Receiver Waveform Output

With the transmitter and receiver working, now we need to convert the received frequency readings back to the temperature readings. Again, to help you understand how the calculation is done I have included the reference schematic below:

Reference Design

We know that the converter’s output frequency is a linear function of the input voltage at the voltage divider:

\[f=C_0\frac{R_{ntc}}{R_{ntc}+R_0}V_{cc}=C_1\frac{R_{ntc}}{R_{ntc}+R_0}\]

C0 is a constant that can be derived from the following equation according to the datasheet:
\[C_0=\frac{R_s}{2.09*R_L*R_tC_t}\]

Since the temperature is roughly inversely proportional to the thermistor value within a small temperature range:
\[\frac{1}{R_{ntc}}\propto T\]

We can further simplify the frequency output to:
\[f=\frac{C_1}{1+C_2T}\]

And thus we can derive the measured temperature as:
\[T=\frac{C_1}{fC_2} - \frac{1}{C_2}\]

Although the two constants C1 and C2 can be determined by the theoretical values of the components, it is probably simpler to obtain them experimentally by measuring two or more frequencies at different temperature points.

Below is the Arduino code I used. The FreqCounter library I used can be found here. Note that parameters in the code are tailored specifically for the type of thermistor I used and they are also affected by the transmitter supply voltage (in my case the transmitter operates on 5V). You will need to re-calculate the parameters based on the equations I gave above.

#include <FreqCounter.h>

unsigned long frq;

float a = -165.0;
float b = 151735.0;

float GetTemp(float f)
{
  return a + (b/f);
}

void setup()
{
  Serial.begin(9600);
}

void loop()
{
    FreqCounter::f_comp = 106;
    FreqCounter::start(1000);
    while (FreqCounter::f_ready == 0)
        frq = FreqCounter::f_freq;    

    Serial.println(GetTemp(frq));
}

Unfortunately Alexa does not provide detailed history data for sites outside the top 100,000. This makes it slightly more difficult for people running smaller sites to track their trends. Fortunately, we can create a simple script that screen-scrape the traffic ranking information from the HTTP response.

The following shell script illustrates a simple script to parse the traffic ranking information:

#! /bin/sh

wget -SO-  http://www.alexa.com/siteinfo/{site url} 2>&1
| grep -i "alexa traffic rank"  | sed -e 's/.*is ranked number //g'
| sed -e 's/in the world according.*//g'
| sed -e 's/,//g' | grep '^[0-9]*' -o >> {log file name}

Note that the wget statement should be kept in a single line. It is broken into multiple lines for legibility.

One challenge is that the returned verbiage changes according to the rough rankings of the sites so you may have to play around with the HTML a little bit to get the parsing working properly for your particular site. But for any given site, the returned HTML should be relatively stable.

If you run the above script as a scheduled job (e.g. through cron), then you will be able to chart your own traffic trend over time.

While the power was out, I received my TI MSP430 Launchpad and an eZ430-Chronos Development Kit. Now that everything is back to normal, I will have time to get busy with my projects again…

Anyway, the internet service has been restored. Even though main power hasn’t come back yet, I was able to run my servers using the generator.

This is certainly the longest outage that I have seen here in the northeastern part of the US…

The STM32F4 is an ARM Cortex-M4 processor with DSP and FPU instructions. Since I have not used any ARM MCU before, I decided first to use the recommended tool chain to get myself started.

STM32F4 Board

According to the user manual (UM1467), the following IDEs have native support for STM32F4-Discovery board:

• IAR Embedded Workbench for ARM (EWARM)
• RealView Microcontroller Development Kit (MDK-ARM)
• Atollic TrueSTUDIO for STM32
• Altium TASKING VX-toolset for ARM

And it seems that only the Atollic TrueSTUDIO has a free version (Lite) that does not have any code limitations. So the Atollic IDE is the pretty obvious choice for me.

The IDE is based on the popular open source Eclipse development environment. Having used it extensively with C++ and Java projects, setting up the demo project is pretty straight forward. Atollic TrueSTUDIO also integrates with ST-Link GDB server, which makes debugging within the IDE very easy (see screenshot below)

Debugging STM32F4 Using Atollic

To upload the compiled code onto the STM32F4 board, we will need the STM32 ST-LINK utility.

Atollic TrueSTUDIO builds the project target into ELF format which cannot be uploaded to the development board directly. So we will need to first convert the target from ELF to Intel HEX. Unfortunately, the lite version does not seem to provide such a conversion utility.

Object Explorer

After some searching, I found that Ronetix ARM toolset contains arm-elf-objcopy which can be used for such conversion. The full Ronetix tool chain can be downloaded from here.

To convert the ELF file to HEX, use the command below:

STM32F4-Discovery_FW_V1.0.1\Project\Demonstration\TrueSTUDIO\STM32F4-Discovery_Demo\Debug

arm-elf-objcopy -O ihex RCC.elf RCC.hex

Now we can use the ST-LINK utility to upload the .HEX file onto the STM32F4-Discovery board. Interestingly enough, the converted HEX file is about 17 kB smaller than the pre-compiled project demonstration file in the binary folder. It works without a glitch nevertheless. I suspect that the ST supplied HEX file might have been compiled with more debugging information.

STM32 ST Link Utility

Here is the diagram of the measurement circuit again:

Thermistor Parameter Tracer

The thermistor (R1) is attached directly to the heat sink and close to the LM335 so that we can assume that both the thermistor and the LM335 are measuring the same temperature. The current limiting resistor R2 is chosen so that the voltage resolution is as high as possible (e.g. the voltage change across R1 is maximized over the measured temperature range) and at the same time the self heating effect is negligible.

The picture below shows the three unknown NTCs I used in my test. These three NTCs measure roughly 8K, 10K and 18K under room temperature. And the current limit resistors are chosen after some experiments. For the 8K NTC, I used a 1.783K resistor. For the 10K NTC, I used a 2.643K resistor and for the 18K NTC, I used a 2.164K resistor.

NTCs Used in Test

The PWM signal is supplied via an Arduino board. The reference voltage readings from LM335 and the voltage reading across the unknown NTC are feed to the analog pins of the MCU.

Measurement Setup

Here is a close up of the measurement board, you can see that the unknown NTC is clamped onto the heat sink adjacent to the LM335 sensor.

Board With Unknown NTC Attached

Depending on the thermal conductivity of the heatsink, it takes time for the heatsink surface to reach a stable temperature. Thus, the temperature must be increased slowly in order to obtain accurate results. One way to control the heatsink temperature is to use a PID controller to adjust the pulse width of the driving signal and only measure the NTC readings after the desired temperature is stabilized. This approach can become quite complex as it requires fine tuning of the controller parameters to reduce overshoot and oscillation.

Here we will take a simpler approach by simply increasing the pulse width of the control signal slowly over time. This method works quite well in general. But since the temperature increases faster at higher pulse width, the MOSFET heat-up curve is more exponential than linear. This could introduce some error when the temperature is high since there will be fewer sample points in that range. But for our experiment, this should not be an issue as the A/D converter precision is limited to 10 bits in ATmega328, and the measurement error would largely be coming from A/D conversion resolution than anywhere else.

The following is the code listing:

//The voltage of the USB power supply to Arduino,
//if higher precision is required, this voltage needs
//to be regulated.
double Vcc = 4.864;
double V = 0;
double TC = 0;
double TK = 0;
double TF = 0;
int tOn = 0; //PWM on time
double val1 = 0;
double val2 = 0;
int refVal = 0; //analog reading from LM335
int measureVal = 0; //analog reading from NTC/PTC

const int refTempPin = 0; //analog pin 0
const int measurePin = 1; //analog pin 1

const int pwmPin = 3; //digital pin 3

void setup()
{
  Serial.begin(9600);
  analogWrite(pwmPin, tOn);
  delay(10000);
}

void loop()
{
  val1 = 0;
  val2 = 0;

  //using average over 10 iterations
  for (int i = 0; i<10; i++) {
    val1 += analogRead(refTempPin);
    delay(20);
    val2 += analogRead(measurePin);
    delay(20);
  }

  refVal = (int) (val1 / 10.0);
  measureVal = (int) (val2 / 10.0);

  V = (double) refVal/ 1024.0 * Vcc; //Measured voltage
  TK = V * 100.0 ; //Kelvin
  TC = TK - 273.0; //Celcius
  TF = 9.0/5.0 * TC + 32.0; //Fahrenheit

  Serial.print(V);
  Serial.print(" ");
  Serial.print(TC);
  Serial.print(" ");
  Serial.print(measureVal);
  Serial.print(" ");
  Serial.println(tOn);

  //The highest temperature is set to be 110 Celcius
  //and the maximum PWM width is set to 100/255
  if (TC < 110 && tOn < 100) {
    tOn++;
    analogWrite(pwmPin, tOn);
  }  

  //This delay needs to be at least 10 seconds to allow
  //the heat sink to be uniformly heated.
  delay(10000);
}

And the measured data is sent via the UART to the computer serial monitor. After the data is collected after each run, the data is processed and then fed into two arrays in MATLAB. From the obtained data we can form two arrays, one is for the LM335 readings and the other is for the thermistor resistance values. We can further estimate the curve parameter values by fitting the measured data to a known model.

A typical NTC thermistor has the following characteristics:
\[R=r_{\infty}e^{\frac{B}{T}}\]

Since MATLAB does not have an out-of-box function for this type of curve fitting, I used an alternative two-term exponential function:
\[f(x)=a*e^{bx}+c*e^{dx}\]

Other forms of functions such as polynomials can also be used and should also give satisfactory results. But since we know the nature of the R-T relationship, the exponential curve fitting should give less error and be applicable over a large temperature range. The following code snippet shows the MATLAB function calls for the curve fitting portion.

f18 = fit(R18Temp’, R18Val’, ‘exp2′);
f10 = fit(R10Temp’, R10Val’, ‘exp2′);
f8 = fit(R8Temp’, R8Val’, ‘exp2′);

And the figures below show the R-T measurements of the three different NTC thermistors with the measured data and fitted curve overlaid.

NTC1 R-T Curve

a = 17.94
b = -0.05082
c = 8.424
d = -0.02041

NTC2 R-T Curve

a = 28.68
b = -0.04817
c = 2.544
d = -0.02274

NTC3 R-T Curve

a = 40
b = -0.04112
c = 4.416
d = -0.01477

Here, I will show you a simple circuit that I designed that can be used as an front end for such measurements. Outputs from this circuit can be inputted into an MCU (such as the popular Arduino) for further analysis.

The circuit is shown below:

Thermistor Parameter Tracer

Here the MOSFET (IRFZ22) is used as an active load. The gate voltage is limited to 4.7V by the Zener diode (e.g. 1N4732). This is important as according to IRFZ22′s datasheet, by limiting the gate voltage to 4.7V, the maximum drain to source current (Ids) is limited to roughly 2 Amp. In principal, pretty much any power MOSFET can be used for this purpose, as long as Vgs is clamped to ensure that the MOSFET operates within the safe limit. A small heat sink is used as the heating surface. A PWM signal is used to control the gate. By adjusting the PWM duty cycle, the thermal dissipation of the MOSFET can be controlled and thus the heatsink temperature can be varied programmatically.

A precision temperature sensor LM335 is clamped onto the heatsink (see picture below) so the surface temperature can be monitored. When used with a closed loop control (e.g. PID control) the heatsink surface temperature can be controlled precisely.

Thermistor Parameter Tracer

To measure the parameters of an unknown thermistor (either PTC or NTC), choose an appropriate R2 so that the voltage change across the thermistor under measurement is maximized over the desired temperature range and at the same time the self-heating effect is minimized.

The thermistor temperature-resistance curve can be obtained as follows:

• Attach the thermistor to be measured near the LM335 sensor. The surface of the thermistor should be firmly attached to the heatsink surface to ensure that the temperature reading from LM335 is the same as the temperature of the thermistor.
• Gradually increase the PWM duty cycle of the control signal so that the temperature reading from LM335 slowly increases (e.g. 1 degree per minute). The temperature has to be changed slowly so that we can ensure that both LM335 and the thermistor are at the same temperature.
• Record the temperature via Vout1 and the thermistor’s resistance via Vout2 using an MCU.

Using this circuit, the control temperature can be safely raised to about 250 Fahrenheit (121 Celsius) which should give wide enough of a range for most thermistor measurements.

I will show a few examples in a later post.

Using an IGBT for camera flash triggering has several advantages over the traditional SCR triggering mechanism: for instance, the width of the triggering pulse can be controlled precisely and thus enabling functions such as red eye prevention that cannot be achieved easily using an SCR triggered circuit.

The following circuit diagram shows a simple IGBT controlled slave camera flash circuit:

Synchronous Flash Trigger Using IGBT

Depending on the camera used, the light sensor can be either a CdS photoresistor , a photodiode or a phototransistor. For many automatic cameras, a photodiode or photo transistor maybe necessary as the shutter speed is typically faster than then reaction time of a CdS sensor. The schematics above also shows how both types of sensors can be used.

Here is how this circuit works. The inverting input of the comparator (LM339) is referenced at roughly Vcc/2. When the CdS sensor detects the primary camera flash, its resistance drops and the voltage at the none-inverting input exceeds the reference voltage. The comparator output a high (e.g. close to Vcc) and thus triggers the IGBT.

The IGBT used here is a Toshiba GT8G131 N Channel IGBT, which is specifically designed for strobe flash applications. It is important to supply a high enough (within safety limit) gate voltage to ensure that the IGBT is fully turned on. Otherwise, the IGBT may not be able to conduct a high enough current to trigger the flash tube. So if you are using other types of IGBT, you may need to adjust the Vcc accordingly.

The following picture shows the finished circuit board used with a Vivitar 2000 camera flash.

Synchronous Flash Trigger

Luckily, most of these LGA and QFN chips can be prototyped on the typical 2.54 mm drill hole spacing protoboard. In this post, I will use STMicroelectronics‘ LPY450AL dual-axis gyroscope IC as an example to show how to hand solder this kind of fine pitch chips on a protoboard. I have used similar techniques extensively in many of my previous projects (1, 2, 3). When done properly, this technique can be used in prototyping most lower pin count LGA/QFN chips. Even some chips in the RF range (such as Si4301) can be prototyped this way.

LPY450AL comes as a tiny LGA-28 chip measuring at just 4x5x1mm. The pad spacing is very small (0.5 mm). But this chip can be soldered using a standard fine-tip soldering iron with some practice and patience.

Chip Placement

Chip should be placed on the component side of the board with pads facing up. Depending on the external components used for your particular circuit, you will need to decide where on the board the chip should be placed. Since LPY450AL requires only a handful of external components, I put it at the center of a small protoboard (see below).

Chip Placement

Since the chip is flipped upside down, you will need to pay special attention to the pin numbering. I placed a black mark at the top right corner of the board to indicate the location of pin 1. This chip has a tiny marking near pin 1 as well but not all chips have such identification on the bottom side. Also, the pin ordering would now be clockwise instead of counter clockwise when viewed from the top.

After you are satisfied with the chip placement, use a drop of super glue to glue the chip in place. A pair of tweezers will come in handy for some fine adjustments.

Tinning The Pads

You will need to use a soldering iron with a fine tip. If you have a temperature controlled iron, try setting it to the lowest recommended temperature for the type of solder you are using. For Pb-free solder, this temperature should be around 245 degree Celsius and for Sn-Pb solder, the temperature should be around 215 Celsius. If you do not have a temperature controlled soldering iron, you can use a small wattage one (e.g. 15W-25W) attached to a dimmer switch (note, dimmer switch does not regulate the temperature of the iron. Since the pads and wires we are dealing with are very tiny, the temperature change of the iron tip is quite negligible). You can test the iron tip temperature using a thin piece of solder. The temperature should be adjusted such that it is just adequate to melt the solder. Since the pads on these LGA/QFN chips are very fragile, too high of a temperature can result in the detachment of the pads and essentially ruin the chip. You will be warned on this multiple times later.

The picture below shows the soldering iron I used (no temperature control).

Fine Tip Soldering Iron

The pads should be tinned first prior to soldering. To tin the pads, first apply some flux on them, and then use the tip of the soldering iron to gently touch each individual pads. Note that the pads on LGA/QFN devices are not designed to withstand excessive force, do not use the tip to drag laterally on the pads as they may come off as a result. Since the surface area of each pad is extremely small, it heats up quickly and usually a pad can be tinned within a second of iron contact.

Here is a picture I took after the pads were tinned. Depending on the type of flux you used, you may or may not need to clean up the flux residue.

Tinned Pads

Soldering

I would highly recommend using the copper wires within the stranded hookup wire for this task. For each pad, a single strand should be used. Thin magnetic wires could be used as well, but you will need to remove the insulation layer carefully prior to soldering to ensure good connectivity.

Wires should first be soldered onto the pads on the chip and then soldered onto the protoboard. Before soldering on to the pad, the tip of the wire should first be tinned. Then, carefully place the tip of the wire onto the pad. Use the tip of the iron to briefly tap the wire from above. With a little bit of pressure, the wire should bound to the already tinned pad. Again, do not rub the pad with the tip of iron to prevent pad from detaching. After removing the soldering iron, wait for a few seconds for the joint to cool and then gently pull the wire to ensure that it is soldered onto the pad.

Then, the other end of the wire can be soldered on to the protoboard. Since the wire is very thin, you do not have to worry about it coming off the soldering pad as a result of soldering it on to the protoboard.

One Pad Soldered

It might be easier to solder all the pads first since it could be a bit more difficult to fix the connections on the pads once the wires are already soldered onto the protoboard. Sometimes the already soldered wire could come off the pad due to the heat generated while soldering on an adjacent pad (use the finest tip you have to avoid this issue). It would be easier to redo the soldering when the other end of the wire is still free.

Try keeping the wires as short as possible to minimize the stray capacitance and inductance, especially when dealing with circuit that runs at higher frequencies.

Again, it is important for the soldering tip not to stay on each pad for too long at any given time. Typically, a couple of seconds should be sufficient to get the job done. If you need to touch up your work, wait till the pads cool down first before trying again. Also, always apply force perpendicular to the pads. All these precautions can greatly reduce the risk of damaging the chip while soldering.

Multiple Pads Soldered

Here is the completed LPY450AL experiment board. You can see how tiny the chip is compared to the rest of the circuit components. To put things in scale, the resistors I used are 1/16 watt.

Finished LPY450AL Board