On the Drawing Board

Just having a little fun

2012-02-04T09:53:00.000+08:00

This circuit was meant to test an idea but the idea turned out to be a dead end. So I ended up just playing with the circuit. Red, green and blue LEDs are turned on in sequence. Because of the difference in light intensity I've used different resistors values for each of the colors to try and even the output. Position of the potentiometer is read by the PIC16F1824's ADC. The two least significant bits of the 10-bit ADC output are ignored and the 8-bit value is copied to TMR0 and timer0 sets the amount of time each LED is on.

The white cylinder over the LEDs is just an old milky-white colored 35mm film canister. But it makes a heck of difference on how the light output is seen by the human eye. Certainly far more interesting with it. By varying the direction in which the LEDs point different light patterns on the cylinder can be created.

The MCU is run at 1MHz. LED switching occurs in the interrupt service routine. Maximum switching frequency is approximately 325Hz--each LED is on for just around 1ms. Minimum frequency is around 1.27Hz. Period T = on-time of each LED x number of LEDs. Frequency = 1/T. Timer0 is used for timing the LEDs. Its prescale is set to 256. With the clock running at 1MHz, time for one instruction cycle = 4/1MHz = 4µs. Timer0 tick = TMR0 x 256 x 4µs. The reset value of TMR0 can range from zero to 255 depending on the position of the potentiometer.

Timer2 is used to periodically read the pot and store its value in a variable which then gets copied to TMR0 during every timer0 interrupt.

#define  int1                bit
#define  int8                unsigned char
#define  int16               unsigned int
#define  int32               unsigned long

#define  on                  1
#define  off                 0

#define  _on                 0
#define  _off                1

#define  yes                 1
#define  no                  0

#define  input               1         // for TRISx
#define  output              0         // for TRISx

#define  analog              1         // for ANSELx
#define  digital             0         // for ANSELx

#define  lred                LATC.f0             // red led
#define  lgreen              LATC.f1             // green led
#define  lblue               LATC.f2             // blue led

#define  tris_lred           TRISC.f0            // for setting LED pin as output
#define  tris_lgreen         TRISC.f1            // for setting LED pin as output
#define  tris_lblue          TRISC.f2            // for setting LED pin as output

#define  an_lred             ANSELC.f0           // for setting LED pin as digital
#define  an_lgreen           ANSELC.f1           // for setting LED pin as digital
#define  an_lblue            ANSELC.f2           // for setting LED pin as digital

#define  ch_pot              3                   // analog channel of potentiometer

// ==================================================================================================================
//          global variables
// ==================================================================================================================

int8 TMR0COUNT;

// ==================================================================================================================
//          functions
// ==================================================================================================================

void IniReg()
{
  OSCCON    = 0b1011000;     // internal clock = 1MHz

  // set LED pins as output
  tris_lred = 0;
  tris_lgreen = 0;
  tris_lblue = 0;
  
  // set LED pins as digital
  an_lred = 0;
  an_lgreen = 0;
  an_lblue = 0;

  lred = 1;                  // start off with red LED
  
  // Timer0 setup
  OPTION_REG = 0b10000111;   // Weak pull ups disabled
                             // timer0 uses internal clock,
                             // prescaler assigned to timer0, prescaler = 1:256
  TMR0 = 0;
  INTCON.TMR0IE = 1;         // timer0 interrupt enable
  
  // Timer2 setup
  // with a 1MHz clock, prescale = 1:16, postscale = 1:1, PR2 = 200
  // timer2 tick = 250 * 64 / (1MHz/4) = 64ms
  T2CON = 0b111;             // timer2 on, prescale = 1:64, postscale = 1:1
  PR2 = 250;                 // timer2 counts up from zero until the value of PR2 and then resets

  // Analog to Digital Coverter setup
  ADCON0 = ch_pot << 2;      // shift in analog channel to be made active
  ADCON0.ADON = 1;           // turn on ADC
  ADCON1 = 0;                // left justified, Fosc/2, Vss as negative reference, Vdd as positive reference

  INTCON.GIE = 1;            // global interrupt enabled
} // void IniReg()


/* =========================================================================================================

According to PIC12F1824 Silicon Errata sheet DS80510D the ADC unit in certain silicon revisions is buggy:

"An ADC conversion may not complete under these conditions:
1. When FOSC is greater than 8 MHz and it is the clock source used for the ADC converter.
2. The ADC is operating from its dedicated internal FRC oscillator and 
the device is not in Sleep mode (any FOSC frequency). 
When this occurs, the ADC Interrupt Flag (ADIF) does not get set, the GO/DONE bit does not get cleared, 
and the conversion result does not get loaded into the ADRESH and ADRESL result registers."

mikroC Pro compiler's Adc_Read() built-in ADC function uses the FRC oscillators o it cannot be used.

The workaround used here is as per method 1 in the said errata:
"Select the system clock, FOSC, as the ADC clock source 
and reduce the FOSC frequency to 8 MHz or less when performing ADC conversions."

=========================================================================================================  */

int8 ADC()
{
  ADCON0.GO = 1;                       // start ADC conversion
  while (ADCON0.GO) ;                  // just wait until AD conversion is done
  return ADRESH;                       // return only the 8 most significant bits of the 10-bit value
}


void interrupt()
{
  if (INTCON.TMR0IF)
  {
    TMR0 = TMR0COUNT;
    if (lred)
    {
      lgreen = on;
      lred = off;
    }
    else if (lgreen)
    {
      lblue = on;
      lgreen = off;
    }
    else
    {
      lred = on;
      lblue = off;
    }
    INTCON.TMR0IF = 0;
  }
}


void main()
{
  IniReg();

  while(1)
  {
    if (PIR1.TMR2IF)
    {
      TMR0COUNT = ADC();
      PIR1.TMR2IF = 0;
    }
  } // while(1)
} // void main()

Toy traffic light--the next generation

2012-01-27T13:58:00.000+08:00

Just minutes after I presented the signal tower traffic light to the kids last week and briefed them on how it works and how to change the go/stop time duration, the eldest told me I should put a digital countdown timer on top of the tower so they'll know how many seconds there are remaining before red turns green and green turns amber. I was dumbstruck. Why the heck didn't I think of that?! His suggestion is nothing short of brilliant. These kids are geniuses (of course I'm fracking biased!).

So it was back to the drawing board for v2.0. My boss wants his traffic light by this week. Told him I can't since I need time to design the circuit and the pcb and write the software and think about how to mount the LED readouts and then finally put everything together. Working for 7-year olds is tough.

Well, writing the firmware was a breeze. The state machine structure lends itself to easy modification. And in the process bulbs went off in my head and I added other features including a new mode wherein the red and amber lights alternate, with the same on-time as the flashing red and flashing amber modes of 0.8sec. And since a seven segment LED display is going to be used anyway why not put it to use even in modes other than normal traffic light mode. So during the flashing red, flashing amber, and alternating red and amber modes the LED will be showing various non numeric characters just to add to the light show. And most importantly I've dumped the use of the green bulb as feedback for the number of seconds for go/stop on-time. The LED now displays "1", "2"... up to "6" to indicate 5sec, 10sec,... 30sec of go/stop on-time. I could easily show the actual number of seconds on the display but I didn't because I think it would be good multiplication practice for the kids. At least they get to know by heart the products of 1 x 5, 2 x 5, ... up to 6 x 5.

Parts list:
PS - AC to DC adapter 12VDC 1000mA output
D1 - 1N5822 Schottky diode
MCU - PIC16F1827 microcontroller
VR - 78L05 voltage regulator
7SEG1, 7SEG2 - seven segment LED display common anode
Q1, Q2 - S9012 PNP transistors
Q3, Q4 - 2N7000 n-channel enhancement MOSFET
Q5, Q6, Q7 - TIP102 NPN Darlington transistor
Q8 - ULN2003 transistor array

My initial design had the LED powered from the 5V rail. This required using an L7805 which has an output capacity of at least 1000mA instead of the 78L05 which can only put out 100mA. Computations showed that because of the large headroom (12V - 5V) and large current draw (around 150mA) the power dissipation of the voltage regulator would raise its temperature close to 100 Celsius and thus necessitate a heatsink. Shudder! A heatsink eats up so much space. So it occurred to me to just power the LED directly off the unregulated supply of 12V. Of course the power dissipation issue would move over to the LED current limiting resistors but that is easily taken care of by employing 1/4-W resistors instead of 1/8-W. Trivial. In the initial 5V design it was a simple matter of using PNP transistors to provide power to the common anode seven segment LEDs. But with the emitter at 12V the base of the PNP can no longer be directly hooked up to the 5-volt MCU. In order to switch the PNP I've opted to use the 2N7000 MOSFET. Using an NPN would've been just as effective but it would've required the addition of a base current limiting resistor. The less components on the board the better. In order for the MOSFET and PNP setup to work properly the base of the PNP must be pulled up to the emitter voltage when the 2N7000 is off, else the base will be left floating. Thus, the 51Kohm resistor. When the 2N7000 is turned off the pull-up resistor brings the base voltage to 12V thus switching off the PNP and cutting supply to the LED display.

I've decided to install two LED displays back-to-back both showing exactly the same readout. Each segment will be provided around 10mA. Because the current draw is double (two LED displays) and because of the 12VDC supply the MCU pins cannot be used to directly sink the current. Therefore a ULN2003 transistor array takes care of the power switching.

The tens and ones digits on the display are multiplexed and switched every 4ms giving a frequency of 1/ (4ms x 2) = 125Hz. That's more than fast enough to provide a flicker-free display.

Because of the additional function calls to update the LED display I've increased the the clock rate from the previous 500kHz to 2MHz. Timer2 tick is still 4ms. A check using the Saleae Logic shows that at 2MHz it usually takes only about half a millisecond to go through all the functions. However, when go/stop on-time is changed the time consumed jumps to over 3ms. Measurement shows the ComputeRedGreenTime() function takes 0.50ms. Multiplication does take time but I discovered the king of snails is the EEPROM write. Storing the one byte stop/go on-time takes a whopping 2.66ms. But this is actually better than the datasheet spec of 4.0ms typical and 5.0ms max. Given the half millisecond average (when the user is not selecting a stop/go time), I could actually have retained the 500kHz clock. The savings on power is, however, marginal and negligible compared to what the bulbs and LEDs consume.

I'll post a vid and pics of the new and improved traffic light when I finally build the circuit and figure out how to mount the seven segment LED boards on top of the tower and still be able to have access to the screw of the tower's cap and protect the boards from the 7-, 6-, and 4-yr old demotion team!.

/*

Kids' Traffic Light with Countdown Timer Using an Industrial Signal Tower

Created:        January 2012
Processor:      PIC 16F1827
Compiler        mikroC Pro 5.0.0
Configuration:  power up timer, brownout reset (set to 2.5V), WDT, stack over/underflow reset -- all enabled, all others disabled

* Uses a 12VDC wall wart as power supply

* Tower light 12VDC red, amber, green incandescent lamps are switched by NPN Darlington transistors

* pushbutton:
     * when momentarily pressed: cycles through different possible modes:
          1. flashing amber
          2. flashing red
          3. alternating amber and red
          4. normal traffic light: green -> amber -> red

     * when pressed and kept depressed for over a couple of seconds LED display shows 1,2,3,4,5,6 in sequence corresponding to following go/stop on-time:
          1. 5sec
          2. 10sec
          3. 15sec
          4. 20sec
          5. 25sec
          6. 30sec
     * although LED readout can be made to show number of real-time seconds when selecting go/stop time
       showing it in the manner above provides an opportunity to teach the children how to multiply--in this case multiply by 5

* go/stop on-time is stored in EEPROM

* has 7-segment LED display
     * shows the go/stop on-time when selecting it
     * shows the remaining time before light changes
     * shows various non-numeric characters in other modes


*/



// ************************************************************************************************
//       input / output
// ************************************************************************************************

#define  lred      LATB.f4                       // NPN darlington switches 12VDC incandescent lamp
#define  lamber    LATA.f6                       // NPN darlington switches 12VDC incandescent lamp
#define  lgreen    LATB.f5                       // NPN darlington switches 12VDC incandescent lamp

#define  pb        PORTA.f5                      // momentary contact push button
#define  tris_pb   TRISA.f5

#define  anode_ones          LATA.f0             // S9012 PNP transistor
#define  anode_tens          LATA.f1             // S9012 PNP transistor

#define  seg_a               LATA.f2             // segment a of seven segment LED common anode
#define  seg_b               LATA.f3             // segment b of seven segment LED common anode
#define  seg_c               LATA.f4             // segment c of seven segment LED common anode
#define  seg_d               LATB.f0             // segment d of seven segment LED common anode
#define  seg_e               LATB.f1             // segment e of seven segment LED common anode
#define  seg_f               LATB.f2             // segment f of seven segment LED common anode
#define  seg_g               LATB.f3             // segment g of seven segment LED common anode

// ************************************************************************************************
//       traffic light time duration
// ************************************************************************************************

#define  count_ini           250       // number of timer2 ticks to make one second

#define  ambertime           500       // in normal mode -- amount of time for amber light to be on after green and before red -- time in terms of timer2 ticks
#define  flashambertime      200       // in flashing amber mode -- amount of time for amber light to be on and amount of time to be off -- time in terms of timer2 ticks
#define  flashredtime        200       // in flashing red mode -- amount of time for red light to be on and amount of time to be off -- time in terms of timer2 ticks
#define  flashredambtime     200       // in red/amber alternate flashing mode -- amount of time for red light to be on and amount of time amber light to be on -- time in terms of timer2 ticks
#define  ledflashtime        25        // in normal mode during yield (amber light) -- amount of time the character displayed on 7-seg is flashed on and off

#define  changergtime        375       // minimum amount of time for button to be kept pressed before cycling through the green light on time -- time in terms of timer2 ticks
                                       // given 4ms timer2 tick, changergtime of 250 = 1sec real time

#define  prechangergtime     changergtime - 250  // amount of time after button is held down when all lights are turned off in preparation for possible change of green/red light on time

#define  rgtime_increm       1250      // amount of time for green/red light to be on, and multiples thereof upon continual button press -- value in terms of timer2 ticks.
#define  maxrgtime           6         // maximum allowed multiple of rgtime_increm

int16 REDGREENTIME;                    // amount of time for green/red light to be on -- time in terms of timer2 ticks
int8  RGTIME;                          // multiples of rgtime_increm such that RGTIME*rgtime_increm = REDGREENTIME


// ************************************************************************************************
//       for pushbutton
// ************************************************************************************************

#define  rising              1         // rising edge detected. used by PBedge
#define  released            1         // rising edge detected. used by PBedge
#define  falling             2         // falling edge detected. used by PBedge
#define  pressed             2         // falling edge detected. used by PBedge
#define  none                0         // no edge. used by PBedge

int8 PBval;                            // last eight values of the switch upon reading it
int8 PBedge;                           // edge detected?, 0 = no edge detect, 1 = rising edge, 2 = falling edge; other values = Not Used / Undefined for now
bit PBlevel;                           // voltage level of switch when not bouncing (hi = 1, lo = 0)

// ************************************************************************************************
//       general defines and variables
// ************************************************************************************************

#define  addr_rgtime         0x10      // eeprom address for user selected green/red light on time

#define  disp_dash           111       // code to display a dash, for use with UpdateDisp()

#define  disp_3horiz         120       // code to display three horizontal segments, for use with UpdateDisp()
#define  disp_tophoriz       121       // code to display top horizontal segment, for use with SegmentAssign()
#define  disp_midhoriz       122       // code to display middle horizontal segment, for use with SegmentAssign()
#define  disp_botthoriz      123       // code to display bottom horizontal segment, for use with SegmentAssign()

#define  disp_brackets       130       // code to display brackets, for use with UpdateDisp()
#define  disp_left_bracket   131       // code to display left bracket, for use with SegmentAssign()
#define  disp_right_bracket  132       // code to display right bracket, for use with SegmentAssign()

#define  disp_topsquare      141       // code to display top square, for use with UpdateDisp()
#define  disp_bottsquare     142       // code to display bottom square, for use with UpdateDisp()

#define  disp_blank          255       // code to display nothing, for use with UpdateDisp()

int16 TIME = 0;                        // records how long a light has been on  -- in terms of timer2 ticks
int8  VALUE = disp_blank;              // number or character to be displayed on 7-seg LED
int8  RGSECONDS;                       // user-selected red/green on-time in real-time seconds


#define  int1                bit
#define  int8                unsigned char
#define  int16               unsigned int
#define  int32               unsigned long

#define  on                  1
#define  off                 0

#define  _on                 0
#define  _off                1

#define  yes                 1
#define  no                  0

#define  input               1         // for TRISx
#define  output              0         // for TRISx

#define  analog              1         // for ANSELx
#define  digital             0         // for ANSELx

#define  hi                  1         // switch level high
#define  lo                  0         // switch level low

// ************************************************************************************************
//       for state machines
// ************************************************************************************************

// !! A C H T U N G !! 
// make sure all non user selectable modes such as _standby and _selectrgtime come AFTER user selectable
// and that _normal" is the last item in the valid user selectable modes because it is used as the max value in ProcessKey()
enum {_flashingamber, _flashingred, _flashingredamber, _normal, 
      /* the modes that follow are non-user selectable --> */ _standby, _selectrgtime} STATEMODE = _flashingamber;

enum {_stop, _yield_ini, _yield, _go} STATENORMAL = _stop;
enum {_init, _flash} STATEFLASHGREEN = _init;


// ===========================================================================================
//       LED 7-Segment Display
// ===========================================================================================

void SegmentAssign(int8 num)
{
  seg_a = 0;
  seg_b = 0;
  seg_c = 0;
  seg_d = 0;
  seg_e = 0;
  seg_f = 0;
  seg_g = 0;

  switch (num)
  {
    case 1:
      seg_b = 1;
      seg_c = 1;
      break;

    case 2:
      seg_a = 1;
      seg_b = 1;
      seg_d = 1;
      seg_e = 1;
      seg_g = 1;
      break;

    case 3:
      seg_a = 1;
      seg_b = 1;
      seg_c = 1;
      seg_d = 1;
      seg_g = 1;
      break;

    case 4:
      seg_b = 1;
      seg_c = 1;
      seg_f = 1;
      seg_g = 1;
      break;

    case 5:
      seg_a = 1;
      seg_c = 1;
      seg_d = 1;
      seg_f = 1;
      seg_g = 1;
      break;

    case 6:
      seg_a = 1;
      seg_c = 1;
      seg_d = 1;
      seg_e = 1;
      seg_f = 1;
      seg_g = 1;
      break;

    case 7:
      seg_a = 1;
      seg_b = 1;
      seg_c = 1;
      break;

    case 8:
      seg_a = 1;
      seg_b = 1;
      seg_c = 1;
      seg_d = 1;
      seg_e = 1;
      seg_f = 1;
      seg_g = 1;
      break;

    case 9:
      seg_a = 1;
      seg_b = 1;
      seg_c = 1;
      seg_d = 1;
      seg_f = 1;
      seg_g = 1;
      break;

    case 0:
      seg_a = 1;
      seg_b = 1;
      seg_c = 1;
      seg_d = 1;
      seg_e = 1;
      seg_f = 1;
      break;

    case disp_dash:          // displays a dash - middle horizontal segment
      seg_g = 1;
      break;

    case disp_3horiz:        // displays three horizontal segments
      seg_a = 1;
      seg_d = 1;
      seg_g = 1;
      break;

    case disp_tophoriz:      // displays top horizontal segment
      seg_a = 1;
      break;

    case disp_botthoriz:     // displays bottom horizontal segment
      seg_d = 1;
      break;

    case disp_left_bracket:  // displays opening bracket
      seg_a = 1;
      seg_d = 1;
      seg_e = 1;
      seg_f = 1;
      break;

    case disp_right_bracket: // displays closing bracket
      seg_a = 1;
      seg_b = 1;
      seg_c = 1;
      seg_d = 1;
      break;

    case disp_topsquare:     // displays a square on upper half of LED
      seg_a = 1;
      seg_b = 1;
      seg_f = 1;
      seg_g = 1;
      break;

    case disp_bottsquare:    // displays a square on the lower half of the LED
      seg_c = 1;
      seg_d = 1;
      seg_e = 1;
      seg_g = 1;
      break;

    default:                 // if invalid value then display blank

    case disp_blank:         // segments have already been turned off at the start of this function so do nothing
      break;
  } // switch (num)
} // void SegmentAssign(int8 num)


void UpdateDisp()
{
  static bit anode;          // flag bit multiplexing display between tens and ones place
  int8 TENS, ONES;           // contains the digit or code of the non-numeric character to be displayed in the tens and ones place

  // turn off power to 7-segment LED display.
  anode_ones = off;
  anode_tens = off;

  if (STATEMODE != _standby)         // turn on LED display only when not in _standby mode
  {
    if (VALUE < 100)                 // values >= 100 are codes for non-numeric characters
    {
      TENS = VALUE/10;
      ONES = VALUE%10;
    } // if (VALUE < 100)
    else
    {
      switch (VALUE)
      {
        case disp_dash:
          TENS = disp_dash;
          ONES = disp_dash;
          break;

        case disp_3horiz:
          TENS = disp_3horiz;
          ONES = disp_3horiz;
          break;

        case disp_tophoriz:
          TENS = disp_tophoriz;
          ONES = disp_tophoriz;
          break;

        case disp_botthoriz:
          TENS = disp_botthoriz;
          ONES = disp_botthoriz;
          break;

        case disp_brackets:
          TENS = disp_left_bracket;
          ONES = disp_right_bracket;
          break;

        case disp_topsquare:
          TENS = disp_topsquare;
          ONES = disp_topsquare;
          break;

        case disp_bottsquare:
          TENS = disp_bottsquare;
          ONES = disp_bottsquare;
          break;

        default:                       // if invalid value then display blank

        case disp_blank:
          TENS = disp_blank;
          ONES = disp_blank;
          break;
      } // switch (VALUE)
    } // else if (VALUE >= 100)

    if (anode)
    {
      if (TENS != 0)                   // do not display tens place if it's zero
      {
        SegmentAssign(TENS);
        anode_tens = on;
      }
      anode = 0;
    }
    else
    {
      SegmentAssign(ONES);
      anode_ones = on;
      anode = 1;
    }
  } // if (display)
} // void UpdateDisp()


// ===========================================================================================
//       functions
// ===========================================================================================

void ComputeRedGreenTime()
{
  REDGREENTIME = RGTIME*rgtime_increm;
  RGSECONDS = RGTIME*5;
}

void IniReg()
{
  TRISA = output;
  TRISB = output;
  ANSELA = digital;
  ANSELB = digital;

  tris_pb = input;

  // enable weak pull up for pushbutton and unused pins
  OPTION_REG.NOT_WPUEN = 0;
  WPUA = 0xFF;
  // WPUB = wpullup;

  // set internal clock frequency to 2MHz
  OSCCON = 0b1100000;

  // Timer2 is used for state machine and switch debouncing timing tick
  // with clock = 2MHz, PR2 = 125, prescale = 1:16, postscale = 1:1
  // TMR2 will count from zero to PR2 and timer2 interrupt occurs every 125*16 / (2MHz / 4) = 4ms = timer2 tick
  T2CON = 0b110;             // postscaler = 1:1, prescaler = 1:16, timer2 on
  TMR2 = 0;
  PR2 = 125;

  WDTCON = 0b1000;           // prescale = 1:512 (16ms typical)
                             // WDTE in configuration word is configured so that WDT enabled when MCU awake and disabled when MCU asleep

  // retrieve stored green/red light on time value.
  // If eeprom-stored value is out of valid range then set it to minimum and store this value in eeprom
  // stored values are in terms of multiples of rgtime_increm such that stored value multiplied by rgtime_increm = time in terms of TMR2 ticks
  RGTIME = EEPROM_Read(addr_rgtime);
  if (RGTIME == 0 || RGTIME > maxrgtime)
  {
    RGTIME = 1;
    EEPROM_Write(addr_rgtime, RGTIME);
  }
  ComputeRedGreenTime();                     // REDGREENTIME = RGTIME*rgtime_increm;

  // initialize push button
  PBval = 0xFF;
  PBlevel = hi;
} // void InitRegisters()


// amber flashes on and off at a rate determined by flashambertime
// LED display shows the character stored in VALUE
void FlashingAmber()
{
  static bit flag;

  if (++TIME < flashambertime)
  {
    if (flag)
    {
      lamber = on;
      VALUE = disp_brackets;
    }
    else
    {
      lamber = off;
      VALUE = disp_blank;
    }
  }
  else
  {
    if (flag)
      flag = 0;
    else
      flag = 1;
    TIME = 0;
  }
} // void FlashingAmber()


// red flashes on and off at a rate determined by flashredtime
// LED display shows the character stored in VALUE
void FlashingRed()
{
  static bit flag;

  if (++TIME < flashredtime)
  {
    if (flag)
    {
      lred = on;
      VALUE = disp_brackets;
    }
    else
    {
      lred = off;
      VALUE = disp_blank;
    }
  }
  else
  {
    if (flag)
      flag = 0;
    else
      flag = 1;
    TIME = 0;
  }
} // void FlashingRed()


// red and amber turn on alternately at a rate determined by flashredambertime
// LED display shows the character stored in VALUE
void FlashingRedAmber()
{
  static bit flag;

  if (++TIME < flashredambtime)
  {
    if (flag)
    {
      lamber = off;
      lred = on;
      VALUE = disp_topsquare;
    }
    else
    {
      lred = off;
      lamber = on;
      VALUE = disp_bottsquare;
    }
  }
  else
  {
    if (flag)
      flag = 0;
    else
      flag = 1;
    TIME = 0;
  }
} // void FlashingRedAmber()


// normal traffic light operation: green --> amber --> red
// red/green light on-time is user selectable
// LED display shows the countdown time in seconds during red and green light 
// LED display shows a flashing "--" during amber light, blink rate determined by ledbflashtime
void Normal()
{
  static int8 COUNTER;
  static bit toggle;

  switch (STATENORMAL)
  {
    case _stop:
      if (++TIME < REDGREENTIME)
      {
        lred = on;
        if (--COUNTER == 0)
        {
          --VALUE;
          COUNTER = count_ini;
        }
      }
      else
      {
        STATENORMAL = _go;
        TIME = 0;
        COUNTER = count_ini;
        VALUE = RGSECONDS;
        lred = off;
      }
      break;

    case _yield_ini:
      toggle = 1;
      VALUE = disp_dash;
      COUNTER = ledflashtime;
      TIME = 0;
      STATENORMAL = _yield;
      break;

    case _yield:
      if (++TIME < ambertime)
      {
        lamber = on;

        if (--COUNTER == 0)
        {
          if (toggle)
          {
            VALUE = disp_blank;
            toggle = 0;
          }
          else
          {
            VALUE = disp_dash;
            toggle = 1;
          }
          COUNTER = ledflashtime;
        }
      }
      else
      {
        STATENORMAL = _stop;
        TIME = 0;
        COUNTER = count_ini;
        VALUE = RGSECONDS;
        lamber = off;
      }
      break;

    case _go:
      if (++TIME < REDGREENTIME)
      {
        lgreen = on;
        if (--COUNTER == 0)
        {
          --VALUE;
          COUNTER = count_ini;
        }
      }
      else
      {
        STATENORMAL = _yield_ini;
        lgreen = off;
      }
      break;

    default:
      TIME = 0;
      STATENORMAL = _yield;
  } // switch (STATENORMAL)
} // void StateMachNormal()


void StateMachMain()
{
  switch (STATEMODE)
  {
    case _normal:
      Normal();
      break;

    case _flashingamber:
      FlashingAmber();
      break;

    case _flashingred:
      FlashingRed();
      break;
      
    case _flashingredamber:
      FlashingRedAmber();
      break;

    case _standby:           // do nothing mode where all bulbs are off. used when changing red/green on-time
      break;
      
    case _selectrgtime:      // er uhhh, I guess we do nothing as well
      break;

    default:
      STATEMODE = _normal;
  }
} // void StateMachMain()


void AllLightsOff()
{
  lred = off;
  lamber = off;
  lgreen = off;
}

void DebounceSwitch()
{
  // shift all bits to the left
  // if switch reading is hi then let pb_val bit 0 = 1
  PBval <<= 1;
  if (pb)
    ++PBval;

  PBedge = none;

  // if level is lo and all bits of pb_val are now hi then
  // a rising edge has been detected
  // switch is considered just released when rising edge is detected
  // switch level is now hi
 if ((!PBlevel) && (PBval == 0xFF))
  {
    PBlevel = hi;
    PBedge = rising;
  }

  // if level is hi and all bits of pb_val are now low then
  // a falling edge has been detected
  // switch is considered just pressed when falling edge is detected
  // switch level is now lo
  if ((PBlevel) && (!PBval))
  {
    PBlevel = lo;
    PBedge = falling;
  }
} // void DebounceSwitch()


void ProcessKey()
{
  int8 MODE;                           // temporary storage of current STATEMODE

  static  int16  PBPRESSTIMETOTAL = 0; // Keeps track of how long PB is depressed in terms of timer2 ticks
                                       // Keeps track of total time from falling edge (switched pressed) to rising edge (switch released).
                                       // if less than changergtime then we know the keypress is momentary and user wants to change modes

  static  int16  PBPRESSTIME = 0;      // Keeps track of how long PB is depressed in terms of timer2 ticks
                                       // this variable is reset every time it exceeds changergtime
                                       // every time it exceeds changergtime red/green on-time is incremented until masrgtime and then it cycles back to one

  DebounceSwitch();
  MODE = STATEMODE;

  if (PBlevel == lo)
  {
    if (++PBPRESSTIMETOTAL == prechangergtime)
    {
      AllLightsOff();
      STATEMODE = _standby;
    }

    if (++PBPRESSTIME >= changergtime)
    {
      PBPRESSTIME = 0;
      if (++RGTIME > maxrgtime)
        RGTIME = 1;
      EEPROM_Write(addr_rgtime, RGTIME);
      ComputeRedGreenTime();                     // REDGREENTIME = RGTIME*rgtime_increm;
      STATEMODE = _selectrgtime;
      VALUE = RGTIME;                            // RGTIME will be displayed on the LED readout
    } // if (++PBPRESSTIME >= changergtime)
  } // if (PBlevel == lo)

  if (PBedge == released)
  {
    if (PBPRESSTIMETOTAL < changergtime)         // if pushbutton was only momentarily pressed then change to the next mode
    {
      STATEMODE = ++MODE;
      if (STATEMODE == _normal)
        STATENORMAL = _yield_ini;                // this is necessary to start normal traffic light mode properly
      else if (STATEMODE > _normal)
        STATEMODE = 0;
    } // if (PBPRESSTIMETOTAL < changergtime)
    else  // green/red light on time has been changed so go to normal traffic light mode and begin with amber light
    {
      STATEMODE = _normal;
      STATENORMAL = _yield_ini;
    }

    AllLightsOff();          // turn off all bulbs and let state machine take care of which ones to turn on
    TIME = 0;                // reset timer so that whatever mode has been selected, light will go through full time allotted
    PBPRESSTIMETOTAL = 0;
    PBPRESSTIME = 0;
  } // if (PBedge == released)
} // void ProcessKey()


void main()
{
  IniReg();

  while(1)
  {
    if (PIR1.TMR2IF)
    {
      PIR1.TMR2IF = 0;
      asm{clrwdt}
      UpdateDisp();
      ProcessKey();
      StateMachMain();
    } // if (PIR1.TMR2IF)
  } // while(1)
} // void main()

Optimizing print quality of PCB artwork on transparency films

2012-01-27T00:12:00.000+08:00

Over the past eight months or so I've tried three different transparency films (most probably made by different manufacturers). Joy Transparency Film comes in a box of 50 sheets. Inside every 5 sheets has its own plastic envelope. The label says the films each have a paper backing, but unfortunately there's none. There is no information on the packaging as to manufacturer and country of origin, even if "Japan" is prominently printed at the upper right hand corner of the plastic bag and "Japan Standard" on the bottom right. Entering "Joy transparency film" and "OF280" (its product number) on Google doesn't turn up anything. Price per sheet is approximately USD0.34.

Fullmark TPICL50 (Made in EU) comes in a black plastic bag containing 50 sheets. Searching the Fullmark website fails to turn up this particular product. In fact Fullmark doesn't seem to carry transparencies anymore (or they haven't updated their website). As with the Joy brand, Fullmark films don't have a paper backing. Price is around USD0.33/sheet.

The last type of film has no brand and has been repacked by the office supply store from which I bought it. This one has a paper backing and is the most expensive at USD0.60/sheet.

Of the three only Joy films produce very good quality printouts. The other two show substantial crazing of the ink. Fullmark is the worst offender. Depending on the printer settings it can border on being useless. Crazing can be detrimental since the cracks allow light to pass through and expose the photosensitive layer of the pcb.

Having found a transparency film that is near optimal I needed to find out what printer settings would provide the most opaque printout and highest ink density. I could've varied the settings and compared the results but fortunately while searching for transparency brands I stumbled upon the recommendations for the JetStar Inkjet Artwork Film:

3. Check printer settings. Make sure printer is set for the highest resolution and print quality, with High Speed Setting OFF. Note that the higher the resolution, the slower the print. Next, set the Media Setting to Matte, Heavyweight Matte, Archival Matte or Inkjet Backlight Film. For Epson Ink Jet Printers, set the Brightness control slider to +25 and although a black print always print in colour Mode. Options will vary based on printer and software available. Then, set ink deposit for optimum results. TIP: Experiment with the setting options available with your printer to determine the best set-up for your requirements. If positive seems light or lacks density, try increasing the print quality or amount of ink deposit. [emphasis added]

I tried those settings and it turns out that on the Epson T10 inkjet printer leaving "print in black ink only" unselected and setting all the sliders to maximum (+25) actually gives a better ink density than printing in black only (I used to tick the print in black only option). Here are screenshots showing the settings I now currently use for the T10 .

The same settings as in the screenshots:

Advanced
  Paper and Quality Options
    Epson Matte
    Best Photo
    [paper size as required]
  Print Options
    Fix Red-Eye - uncheck
    High Speed - uncheck
    Edge Smoothing - check
    Print Preview - check
    Black Ink Only - uncheck
  Color Management
    Color Controls - select
  Color Mode
    Epson Vivid
    Settings:
      Brightness: +25 (max) 
      Contrast: +25 (max)
      Saturation: +25 (max)
      Density: +25 (max)
      Horizontal: 0
      Vertical: 0

Toy traffic light using a signal tower

2012-01-19T02:31:00.001+08:00

Just finished building a toy traffic light for the kids. It uses a signal tower (used on factory floors to provide visual alarms and indication of machine status) which employs 12VDC incandscent lamps. I haven't checked but the bulbs look like the same size and actually have same socket type as automobile tailight lamps.

There's nothing particularly unique or special about this circuit, although I haven't come across any toy traffic light design that uses signal towers. What I do like about this circuit is the fact that a single user interface--a momentary contact pushbutton--controls all the functions, and that I didn't have to include any indicator LED or buzzer and instead could use the lamps of the traffic light itself to provide feedback to the user.

Operation

There are three modes:
1. Flashing amber (0.8sec on, 0.8sec off)
2. Flashing red (0.8sec on, 0.8sec off)
3. Normal traffic light operation: green --> amber --> red (variable red/green on-time, amber on-time = 2sec)

Upon power up the traffic light starts in mode 1. Modes are selected by pressing the button momentarily.

The stop (red) and go (green) time is user selectable. This is accomplished by pressing and holding the button down (regardless of what mode the traffic light is in). 1.5 seconds after pressing the button all lights will be turned off indicating the green light is about to begin showing the amount of go/stop time. Three seconds after pressing the button the green light will go through sets of blinking. The number of flashes per set indicates the go/stop time:

Number of flashes per set	Go/Stop time in seconds
1	5
2	10
3	15
4	20

As with the modes keeping the button depressed will eternally cycle through the four sets. To choose a go/stop time the user releases the button after the particular set of flashes has occured. So letting go of the button after the set of three flashes of the green light will set the go time and stop time to 15 seconds. The selected go/stop time is stored in EEPROM so the circuit doesn't forget even when powered down. Once the button is released the traffic light goes into mode 3 and begins with the yield (amber) light on.

Hardware

I originally planned to use the PIC12615 which is more than adequate. Unfortunately I need EEPROM which the 615 lacks. The only 8-pin PIC with EEPROM that I have right now is the 12F1822 and so that's what I ended up using for the MCU.

The circuit has a polarity reversal protection in the form of a 1N5822 Scottky diode (D1 in the schematic) which has a rated capacity of 3A. Although the wall wart has a no-load measured output of 16VDC, this drops to around 12V when any of the lamps is on. Each of the power transistors also has a voltage drop across their collector-emitter. So to minimize further dip in voltage across the the incandescents I opted to use a Schottky instead of an ordinary rectifier. I've used the TIP102 NPN Darlington since as I reported in the Darlington transistor test, the 102 has the least collector-emitter voltage in the three types I was able to get hold of and play around with. As stated in that test using this very same signal tower, the power dissipation in the Darlingtons is such that heatsinks can be dispensed with.

Here's the finished board with all the components soldered. You'll notice there are several drill holes around the MCU. I've added pads to the unused MCU pins as well to the +5V rail and to the pushbutton tracks. These are "just in case" pads if ever I need to modify the board. The additional pushbutton pads are 0.1" apart and will accommodate a 2-way (2-pin) connector. I was going to solder the connector in case things don't work out and the board-mounted pushbutton doesn't work the way I planned. That rod sticking out of the blue pushbutton is a one and quarter inch piece of bamboo cut from a disposable chopstick. It extends out of case (through a small drilled hole) and will act as the button the user will pushing. It's the rod-poking-out-of-the-case part which I wasn't sure would work--and thus the backup connector for a case-mounted pushbutton. I applied a coat of nail polish to the chopstick just to seal the pores and prevent it from being attacked by molds (I've noticed that some brand new but long stored chopsticks have molds on them and I've seen molds appear on a bamboo chopping board after it had been left damp for some 24 hours).

I made the 12VDC traces to and from the incandescent lamps including ground really wide--150 mils--to minimize voltage drop. The traces narrow to just 50mils near the TO-220 pads to prevent shorts. Yes, the text at the bottom of the board is a dedication to the users of this circuit--my young nephews and niece. Naturally I chose Comic Sans as the font. You might notice scratches on the green photosensitive coating (which I always intentionally leave on the tracks). There was a lot of flux residue after soldering so I washed the board with detergent and scrubbed it using a toothbrush. So the blame for those unsightly scratches rests squarely on the shoulders of that brush!

Although the case has provisions--standoffs with holes in them--for screw mounting of boards, I couldn't find small enough screws that would fit. So I just dabbed copious amounts of hot melt glue on the standoffs and pressed the board onto them. Part of the glue oozed through the drilled holes of the board and formed nice hemispherical beads. The hefty black wall wart is at the bottom right. Its wire is too short so I added a meter more so the kids have leeway in placing the traffic light in their play area.

One of my concerns is that the children will knock this thing over and break it. So I cut out a sponge in the shape of circle with a diameter one and a half times larger than the signal tower. I can just glue it on top of the tower. It'll definitely break any falls and save the polystyrene or acrylic lenses from cracking and breaking. But the sponge solution is ugly to state it mildly. So I might instead superglue something akin to an O-ring around the sides of top cap of the tower. Not as elastic and shock absorbing as the sponge but it's still better than nothing at all. Another is option would be a quarter inch PVC or rubber tubing.

Firmware

I simply adapted the firmware I used for the 4-way traffic light I built the kids last year. This signal tower version is actually a lot simplier--no charlieplexing necessary. I opted to just clock the MCU using its default power-on frequency of 500kHz. Only one timer is used. I can no longer remember why I chose timer2 instead of timer0. For expediency's sake I didn't bother changing what ain't broken. A state machine is used with a timer tick of 4ms. In the configuration word, watchdog timer, power up timer, brownout reset, stack over/underflow reset are all enabled. All other options are disabled. Internal oscillator is used with I/O function on all pins.


/*

Kids' Traffic Light Using a Signal Tower

Created:        January 10 2012
Processor:      PIC 12F1822
Compiler        mikroC Pro 5.0.0


* Uses a 12VDC wall wart as power supply

* Tower light 12VDC red, amber, green incandescent lamps are switched by NPN Darlington transistors

* pushbutton:
     * when momentarily pressed: cycles through different possible modes:
          1. normal traffic light: green -> amber -> red
          2. flashing amber
          3. flashing red
     * when pressed and kept depressed for over a couple of seconds: cycles through different green/red light on time:
          1. 5sec
          2. 10sec
          3. 15sec
          4. 20sec.

* green/red light on time is stored in EEPROM


--------------------------+--------------------------------------
No. of green flashes/set  |   Green/red light on time in seconds
--------------------------+--------------------------------------
         1                |            5
         2                |           10
         3                |           15
         4                |           20
--------------------------+--------------------------------------

*/



// ************************************************************************************************
//       input / output
// ************************************************************************************************

#define  lred      LATA.f0                       // NPN darlington switches 12VDC incandescent lamp
#define  lamber    LATA.f1                       // NPN darlington switches 12VDC incandescent lamp
#define  lgreen    LATA.f2                       // NPN darlington switches 12VDC incandescent lamp

#define  tris_red  TRISA.f0
#define  tris_amber TRISA.f1
#define  tris_green TRISA.f2

#define  pb        PORTA.f3                      // momentary contact push button
#define  tris_pb   TRISA.f3

#define  wpullup   0b111000                      // for WPUA -- enable pull ups on pb and unused pins


// ************************************************************************************************
//       for traffic light
// ************************************************************************************************

#define  ambertime           500       // in normal mode -- amount of time for amber light to be on after green and before red -- time in terms of timer2 ticks
#define  flashambertime      200       // in flashing amber mode -- amount of time for amber light to be on and amount of time to be off -- time in terms of timer2 ticks
#define  flashredtime        200       // in flashing red mode -- amount of time for red light to be on and amount of time to be off -- time in terms of timer2 ticks
#define  flashgreentime      50        // during selection of green/red light on time -- amount of time for green light to be on and amount of time to be off when it is flashing -- time in terms of timer2 ticks

#define  changergtime        750       // minimum amount of time for button to be kept pressed before cycling through the green light on time -- time in terms of timer2 ticks
                                       // given 4ms timer2 tick, changergtime of 250 = 1sec real time

#define  prechangergtime     changergtime - 375  // amount of time after button is held down when all lights are turned off in preparation for possible change of green/red light on time

#define  rgtime_increm       1250      // amount of time for green/red light to be on, and multiples thereof upon continual button press -- value in terms of timer2 ticks.
#define  maxgtime            4         // maximum allowed multiple of rgtime_increm

int16 REDGREENTIME;                    // amount of time for green/red light to be on -- time in terms of timer2 ticks
int8  RGTIME;                          // multiples of rgtime_increm such that RGTIME*rgtime_increm = REDGREENTIME


// ************************************************************************************************
//       eeprom
// ************************************************************************************************

#define  addr_rgtime      0x10         // eeprom address for user selected green/red light on time

// ************************************************************************************************
//       for pushbutton
// ************************************************************************************************

#define  rising              1         // rising edge detected. used by PBedge
#define  released            1         // rising edge detected. used by PBedge
#define  falling             2         // falling edge detected. used by PBedge
#define  pressed             2         // falling edge detected. used by PBedge
#define  none                0         // no edge. used by PBedge

int8 PBval;                            // last eight values of the switch upon reading it
int8 PBedge;                           // edge detected?, 0 = no edge detect, 1 = rising edge, 2 = falling edge; other values = Not Used / Undefined for now
bit PBlevel;                           // voltage level of switch when not bouncing (hi = 1, lo = 0)

// ************************************************************************************************
//       general defines and variables
// ************************************************************************************************


#define  int1                bit
#define  int8                unsigned char
#define  int16               unsigned int
#define  int32               unsigned long

#define  on                  1
#define  off                 0

#define  _on                 0
#define  _off                1

#define  yes                 1
#define  no                  0

#define  input               1         // for TRISx
#define  output              0         // for TRISx

#define  analog              1         // for ANSELx
#define  digital             0         // for ANSELx

#define  hi                  1         // switch level high
#define  lo                  0         // switch level low

int16 TIME = 0;                        // records how long a light has been on  -- in terms of timer2 ticks

// ************************************************************************************************
//       for state machines
// ************************************************************************************************

enum {_normal, _flashingamber, _flashingred, _flashgreen, _standby} STATEMODE = _flashingamber;
enum {_go, _yield, _stop} STATENORMAL = _stop;
enum {_init, _flash} STATEFLASHGREEN = _init;

// ===========================================================================================
//       functions
// ===========================================================================================


void ComputeRedGreenTime()
{
  REDGREENTIME = RGTIME*rgtime_increm;
}

void IniReg()
{
  TRISA = input;
  ANSELA = digital;
  
  tris_red = output;
  tris_amber = output;
  tris_green = output;

  // enable weak pull up for pushbutton and unused pins
  OPTION_REG.NOT_WPUEN = 0;
  WPUA = wpullup;
  
  // default clock frequency is 500kHz upon power up.
  // Timer2 is used for state machine and switch debouncing timing tick
  // with clock = 500kHz, PR2 = 125, prescale = 1:4, postscale = 1:1
  // TMR2 will count from zero to PR2 and timer2 interrupt occurs every 125*4 / (500kHz / 4) = 4ms = timer2 tick
  T2CON = 0b101;             // postscaler = 1:1, prescaler = 1:4, timer2 on
  TMR2 = 0;
  PR2 = 125;

  WDTCON = 0b1000;           // prescale = 1:512 (16ms typical)
                             // WDTE in configuration word is configured so that WDT enabled when MCU awake and disabled when MCU asleep

  // retrieve stored green/red light on time value.
  // If eeprom-stored value is out of valid range then set it to minimum and store this value in eeprom
  // stored values are in terms of multiples of rgtime_increm such that stored value multiplied by rgtime_increm = time in terms of TMR2 ticks
  RGTIME = EEPROM_Read(addr_rgtime);
  if (RGTIME == 0 || RGTIME > maxgtime)
  {
    RGTIME = 1;
    EEPROM_Write(addr_rgtime, RGTIME);
  }
  ComputeRedGreenTime();                     //REDGREENTIME = RGTIME*rgtime_increm;

  // initialize push button
  PBval = 0xFF;
  PBlevel = hi;
} // void InitRegisters()


// normal traffic light operation: green --> amber --> red
// red/green light on time is user selectable
void Normal()
{
  switch (STATENORMAL)
  {
    case _go:
      if (++TIME < REDGREENTIME)
        lgreen = on;
      else
      {
        STATENORMAL = _yield;
        TIME = 0;
        lgreen = off;
      }
      break;

    case _yield:
      if (++TIME < ambertime)
        lamber = on;
      else
      {
        STATENORMAL = _stop;
        TIME = 0;
        lamber = off;
      }
      break;

    case _stop:
      if (++TIME < REDGREENTIME)
        lred = on;
      else
      {
        STATENORMAL = _go;
        TIME = 0;
        lred = off;
      }
      break;

    default:
      TIME = 0;
      STATENORMAL = _yield;
  } // switch (STATENORMAL)
} // void StateMachNormal()


// amber flashes on and off
void FlashingAmber()
{
  static bit flag;

  if (++TIME < flashambertime)
  {
    if (flag)
      lamber = on;
    else
      lamber = off;
  }
  else
  {
    if (flag)
      flag = 0;
    else
      flag = 1;
    TIME = 0;
  }
} // void FlashingAmber()


// red flashes on and off
void FlashingRed()
{
  static bit flag;

  if (++TIME < flashredtime)
  {
    if (flag)
      lred = on;
    else
      lred = off;
  }
  else
  {
    if (flag)
      flag = 0;
    else
      flag = 1;
    TIME = 0;
  }
} // void FlashingRed()


// when user selects red/green light on time the green light is flashed 1,2,3,or 4 times 
// to indicate 5, 10, 15, 20sec of on time
void FlashGreen()
{
  static int8 i, CYCLES;
  static bit flag;
  
  switch (STATEFLASHGREEN)
  {
    case _init:
      i = 0;
      flag = 1;
      TIME = 0;
      CYCLES = RGTIME*2-1;
      STATEFLASHGREEN = _flash;
      break;

    case _flash:
      if (++TIME < flashgreentime)
      {
        if (flag)
          lgreen = on;
        else
          lgreen = off;
      }
      else
      {
        if (flag)
          flag = 0;
        else
          flag = 1;
        TIME = 0;
        if (++i >= CYCLES)
        {
          lgreen = off;
          STATEMODE = _standby;
        }
      }
      break;
  } // switch (STATEFLASHGREEN)
} // void FlashGreen()


void StateMachMain()
{
  switch (STATEMODE)
  {
    case _normal:
      Normal();
      break;

    case _flashingamber:
      FlashingAmber();
      break;

    case _flashingred:
      FlashingRed();
      break;

    case _flashgreen:        // green light is flashed to indicate to user the length of time green/red light are on during normal mode
      FlashGreen();
      break;

    case _standby:           // do nothing mode where all lights are off. used when changing green on time
      break;

    default:
      STATEMODE = _normal;
  }
} // void StateMachMain()


void AllLightsOff()
{
  lred = off;
  lamber = off;
  lgreen = off;
}

void DebounceSwitch()
{
  // shift all bits to the left
  // if switch reading is hi then let pb_val bit 0 = 1
  PBval <<= 1;
  if (pb)
    ++PBval;

  PBedge = none;

  // if level is lo and all bits of pb_val are now hi then
  // a rising edge has been detected
  // switch is considered just released when rising edge is detected
  // switch level is now hi
 if ((!PBlevel) && (PBval == 0xFF))
  {
    PBlevel = hi;
    PBedge = rising;
  }

  // if level is hi and all bits of pb_val are now low then
  // a falling edge has been detected
  // switch is considered just pressed when falling edge is detected
  // switch level is now lo
  if ((PBlevel) && (!PBval))
  {
    PBlevel = lo;
    PBedge = falling;
  }
} // void DebounceSwitch()


void ProcessKey()
{
  int8 MODE;                           // temporary storage of current STATEMODE
  
  static  int16  PBPRESSTIMETOTAL = 0; // Keeps track of how long PB is depreesed in terms of timer2 ticks
                                       // Keeps track of total time from falling edge (switched pressed) to rising edge (switch released).
                                       // if less than changergtime then we know the keypress is momentary and is meant to cycle through the various traffic light modes

  static  int16  PBPRESSTIME = 0;      // Keeps track of how long PB is depreesed in terms of timer2 ticks
                                       // this variable is reset every time it exceeds changergtime
                                       // every time it exceeds changergtime green on time is incremented

  DebounceSwitch();
  MODE = STATEMODE;
  
  if (PBlevel == lo)
  {
    if (++PBPRESSTIMETOTAL == prechangergtime)
    {
      AllLightsOff();
      STATEMODE = _standby;
    }
    
    if (++PBPRESSTIME >= changergtime)
    {
      PBPRESSTIME = 0;
      if (++RGTIME > maxgtime)
        RGTIME = 1;
      EEPROM_Write(addr_rgtime, RGTIME);
      ComputeRedGreenTime();                 //REDGREENTIME = RGTIME*rgtime_increm;
      STATEMODE = _flashgreen;
      STATEFLASHGREEN = _init;
    } // if (++PBPRESSTIME >= changergtime)
  } // if (PBlevel == lo)

  if (PBedge == released)
  {
    if (PBPRESSTIMETOTAL < changergtime)
    {
      switch (MODE)
      {
        case _flashingred:
          STATEMODE = _normal;
          STATENORMAL = _yield;
          break;
          
        case _normal:
          STATEMODE = _flashingamber;
          break;
           
        case _flashingamber:
          STATEMODE = _flashingred;
          break;
          
        default:
          STATEMODE = _normal;
      } // switch (MODE)
    } // if (PBPRESSTIMETOTAL < changergtime)
    else  // green/red light on time has been changed so go to normal traffic light mode and begin with amber light
    {
      STATEMODE = _normal;
      STATENORMAL = _yield;
    }
    
    AllLightsOff();
    TIME = 0;                // reset timer so that whatever mode has been selected, light will go through full time allotted
    PBPRESSTIMETOTAL = 0;
    PBPRESSTIME = 0;
  } // if (PBedge == released)
} // void ProcessKey()


void main()
{
  IniReg();

  while(1)
  {
    if (PIR1.TMR2IF)
    {
      PIR1.TMR2IF = 0;
      asm{clrwdt}
      ProcessKey();
      StateMachMain();
    } // if (PIR1.TMR2IF)
  } // while(1)
} // void main()

----

10am Addendum:

Rummaged through the junk bins and found this silicone gasket. It's probably from some old thermos bottle. Still very elastic, has an internal diameter several millimeters smaller than the signal tower's and even matches the cream color of the signal tower and circuit board's plastic case. Great find.

I wiped down the sides of the cap with alcohol, let it dry, coated it with a thin layer of cyanoacrylate adhesive, and then slipped the gasket on. The only problem is I didn't expect the superglue to set within 10 seconds (usually takes about half a minute) so part of what is now the rubber bumper isn't properly aligned with the cap. Oh well.

I knocked the tower over a couple of times. From the sound of the thud it still doesn't match the exceptional shock absorbing properties of the sponge but this will have to do. It certainly beats having no bumpers at all.

NPN Darlington test

2012-01-14T11:36:00.000+08:00

Am currently modding a signal tower I bought the nephews months ago and converting it into a multi-featured traffic light for them to play with. The tower has 12VDC red, amber and green incandescent lamps. Back when I bought it I just wired individual rocker switches for each of the lamps and powered it via a 12VDC wall cube. It was a fully manual system where any combination of lights could be turned on.

I've removed all the switches and will be adding a brain so it can function automatically. Initial measurements showed the incandescents draw about half an ampere each. To switch them I'd need either relays or power transistors. I've opted to use NPN Darlingtons instead of relays even if Darlingtons will have a substantial voltage drop across the collector-emitter. A more major concern, however, is the power dissipation because of a Darlington's high voltage drop. Dissipation translates to heat which means high temperatures which, if high enough, would require the use of heatsinks--something I would rather not have to resort to. So in order to find out whether I'd be better off using miniature PCB mounted relays, I bought a few Darlingtons and tested their V_CE and the temperature of their cases.

The corner store from which I get my parts doesn't have a good range of Darlingtons and so the parts I ended up testing were the TIP102, TIP112, and TIP120. I breadboarded the following circuit and powered it off my bench supply.

Resistor R5 represents the incandescent lamp. The following tables show the measurements I obtained for each of the bulbs and transistors. V_CE is the voltage across the collector and emitter. I_C is the current going the lamp. Case temperature was measured using a Fluke 62 infrared thermometer around two inches away from the Darlington. I recorded the maximum reading. V_CE drifted as the transistor temperature went up so I gave the circuit a settling time of between two to three minutes before taking the measurements. I previously took some measurements of the inrush current (without using the Darlingtons) using a Fluke 87V's Peak-Min-Max function and the highest value I obtained was 5.2A.

TIP120 NPN DARLINGTON
	Red	Amber	Green
V_CE (volts)	0.735	0.744	0.745
I_C (amperes)	0.363	0.467	0.469
Case Temp. (Celsius)	41	43	43

TIP112 NPN DARLINGTON
	Red	Amber	Green
V_CE (volts)	0.714	0.728	0.730
I_C (amperes)	0.360	0.467	0.469
Case Temp. (Celsius)	40	43	43

TIP102 NPN DARLINGTON
	Red	Amber	Green
V_CE (volts)	0.691	0.700	0.697
I_C (amperes)	0.362	0.468	0.470
Case Temp. (Celsius)	40	41	42

The TIP102 clearly stands out as having the least V_CE and consequently the lowest power dissipation. The temperature as measured by the IR thermometer is of course hardly accurate (I could've used the 87V's thermocouple but I wasn't in the mood to go through the hassle). Since we have all the values necessary let's compute for the (near actual) case temperature. The TO-220 package has a junction to ambient thermal resistance of 62.5°C/W. Current draw of the green bulb is 0.47A. V_CE = 0.697V. Power dissipation is therefore 0.697 x 0.47 = 0.328W. Temperature rise of the case is therefore 62.5 x 0.328 = 20.5°C. Ambient temperature was measured to be 30°C. So case temp. ought to be approximately 30 + 20.5 = 50.5°C.

The TIP102 is the most expensive amongst the three Darlingtons, but by less than 10% over the cheapest. Given how I'm averse to designing in heatsinks for this toy I'll use the TIP102, despite the fact that its temperature will be a mere 1.4° less than if I use the TIP120.

MCP79400 RTCC breakout board

2011-12-31T21:53:00.003+08:00

Last design for the year! 32.768kHz crystal and capacitors will be onboard as well as the Schottky diode and current limiting resistor for the back-up coin battery (which will be off-board). PCB measures 0.8 x 1.0 inch. All components except for the 0.1" male headers are on the copper side (am using a single-sided presensitized board) because the MCP79400 real time clock calendar chip is available only in surface mount packages. I don't have any chip resistors and capacitors so the discretes are all through-holes. The two headers are spaced 0.7-inch apart so they'll still plug nicely into a breadboard.

I could have this board fabricated tomorrow. Thing is, I have yet to purchase my very first MCP79400! Might do so in mid-January.

Ignore that yellow airwire at pin 6. I think it's a bug in DesignSpark PCB 3.0. Even after routing, some airwires remain. Even after executing a design rule check. And even after closing DesignSpark and opening it again. Go figure.

You'll probably notice the SMD pads are much longer than recommended by chip manufacturers. When the chip is mounted on the board there should be around 2mm of exposed pad. The rationale is that the excess pad area permits the soldering iron tip to simultaneously make contact with the pad and the leads. Without the excess we'd have to position the iron tip on top of the pins to solder them. This translates to higher thermal resistance and longer heating time--not good for the chip.

-----

January 1, 2012 Addendum

Made a couple of revisions. Added a 1uF filter cap just to make sure there's sufficient power on board. Also added a 10K pull resistor to the MFP pin as specified in the MCP79400 datasheet. The I2C's SDA and SCL lines need pull-ups but since their value depends on the I2C frequency I've left them out.

Voltmeter woes

2011-12-30T23:50:00.000+08:00

Just got duped. The digital panel-mounting voltmeter I bought which supposedly has a range of 0 to 20VDC stops measuring--with fairly good accuracy--at a little over 15V. Feed any voltage higher than that and meter's accuracy starts dropping off fast. By the time the measured voltage is 20V the meter reads less than 17V.

The exasperating part about it is I found this out only after I had redesigned a circuit so as to factor its limited range of 20V. If you haven't guessed it yet, the cheapo meter is made in China. Yes, it came in that blue and white box with Chinese characters. Doesn't come with any instruction leaflet. And there are only Chinese text on all sides of the carton. Frustrating. At least the silkscreen on the board isn't in Chinese! As you can probably make out, the pins for the connectors are marked (left to right) 5VIN, GND, GND, VIN+. The first two pins are for power and the latter two are for the measured voltage input. A check using a DMM shows the two middle pins (GND) are in fact connected to one another on the PCB. The multiturn potentiometer (blue rectangular component at the top) is used to calibrate the meter. Calibration is fine--if you don't need the entire specified range of 20V. Else, it's a joke.

Devil's in the details

2011-12-13T21:08:00.000+08:00

And I just got burned. I inadvertently designed a short circuit in a pcb!

I create circuit board artwork using DesignSpark PCB and when printing it out on transparency film I always have the board outline printed out as well. The outline allows for precise alignment of the mask (the film) and the presensitized board prior to exposure. In this particular design of a simple 5-volt power supply I had a wide strip of copper for both the +5V and ground. And I extended those tracks all the way to the edge of the board (see the left side of the artwork image below).

Yep, disaster in the waiting. I printed the artwork, exposed the presensitized board, etched it, drilled the holes, soldered the components, and all the while I was absolutely oblivious to the short I had created. I powered up the board while probing the output with a multimeter. Reading? 23mV. I cut off power immediately. Tried it again. Still the same zero voltage. I was so clueless of the booboo that I even desoldered one of the filter caps suspecting it might be defective. Only while poring through board with a magnifying lens did I finally spot the fine 5-mil trace at the very edge of the board bridging the power rails. Facepalm moment indeed. Actually if I had moved the mask by some half millimeter that outline would've been off the physical board and the short wouldn't have appeared.

It's worth noting that even a 5-mil track is faithfully reproduced--implying there's insufficient undercutting during etching to remove the track. This is good of course--if we want such fine copper traces. Luckily it's easy to cut and gouge out the offending copper track. After making sure the bridge had been completely obliterated I soldered the cap back on and the circuit worked as designed. No electronic component was harmed in the making of this sophomoric design mistake.

Hopefully the stress, anxiety, and panic I was subjected to has burned the lesson in my head--since I'll still continue the practice of printing the board outline, I must remember to leave some 20 mils around the perimeter of the board copper-free. I better burn that minimum gap requirement into DesignSpark's design rules. And more importantly, I better start paying attention to the error messages which the design rule check routine spits out--because I don't usually take a look at the track-to-track, pad-to-track, shape-to-track, shape-to-pad, etc. spacing errors. I have a knack for breaking rules. Unfortunately, this time around I got bitten.

Ambient light sensor on the roof

2011-12-13T18:26:00.003+08:00

Installed an ambient light level sensor on the roof. Voltage from the simple voltage divider made up of an LDR and a fixed 5% resistor (750Kohm in this case) is digitized by the analog-to-digital converter of the PIC12F1822 (16 readings are taken successively--takes around 1ms--and averaged) and is sent out through the its serial port at 19.2kbps every 50ms. Communications is simplex--this transmitter merely sends while receivers in remote locations can only receive data. Serial data from the MCU is fed to the SN75176B transceiver which then converts the data stream to an RS-485 compliant signal which is then sent down a pair of unshielded twisted pair cable, for use by any circuit requiring the data. Checksum is sent with every data packet for data integrity verification.

A pair of wires in the UTP cable provides filtered (but unregulated) power to the board. Because the input voltage is somewhere around 8 to 8.5V and may drop below 8 if loads elsewhere (various circuits use the same power supply) increase, I used a 1N5817 Schottky diode instead of a 1N400x for polarity reversal protection. That halves the forward voltage drop across the diode to just 0.3V and thus increases the headroom for the 78L05, ensuring it's able to maintain voltage regulation. There are separate power and ground tracks/traces for the analog and digital sections to minimize digital noise from contaminating the sensor section. The analog section has a 1uF tantalum filter cap and the MCP6232 op amp has the mandatory 0.1uF decoupling cap. You might notice the 1/4-watt resistor adjacent to the LDR. Reason is the dang supplier doesn't have the complete range of values for 1/8-watt resistors.

Image below shows the board in situ with the translucent plastic cover yet to be snapped on. Screws on the board act as standoffs to keep the soldered side from contact with the bottom which might accumulate moisture (hence the drilled holes on the blue plastic to act as drain). The gray 4-pair UTP cable can be seen on the lower left.

Grew up on Casio

2011-12-04T18:42:00.000+08:00

Photo of Casio fx-3000 and fx-115MS scientific calculator. An uncle bought me the 3000 back in 1977. Was already gaga over sci calcs back then. It still works but I haven't used it in decades. Though not noticeable in the pic with the 115 (because we're looking head-on through yellow plastic filter) the LCD is already showing its age and deteriorating. Actually it's fared better than my Casio fx-502P whose LCD went kaput years ago. The 3000's power switch had been giving me problems and had to take out its board and clean both the switch and board contacts.

I now use the 6-year old 115 exclusively. It probably has twice the number of functions. The engineering units (nano, micro, kilo, etc) and decimal/binary/hex functions make life easier. And being able to go back and edit the formula/equation and plug in different values for the variables is just indispensable.

As for speed, the two are truly generations apart. A "u" appears as the leftmost character in the 3000 to alert the user that the microcontroller is still running the numbers through its ALU (arithmetic logic unit). Even something as simple as 1+1 takes a quarter of a second. It's that slow. 69! takes 3.3sec. The 115 on the other hand spits out the factorial result in the blink of an eye, literally. Given that both calcs cannot handle or display any number greater than or equal to 10^100, 69 is the highest possible number for factorials for both.

The equation shown on the display of the 115 is (2π*1k*1µ)^-1. This of course is the formula for the cutoff frequency of a simple low pass filter with a 1kohm resistor and 1µF cap. Being able to enter "M" for mega, "k" for kilo, "n" for nano, "p" for pico, etc.comes in very handy. They save me the trouble of keying in values in scientific notation.

Back side of the calculator. The sticker is original. Could be the serial number of the unit. You might be able to make out the printing at the bottom. Part of it says "Made in Japan." All Casios were back then. The 115MS on the other hand is churned out in China. Thumbs down.

Without the front panel you can clearly see the poor state of the LCD.

The microcontroller is a NEC D895G. Googled but can't find any datasheet for it.

This is the side of the board that greets you when you take off the back cover.

Rail-to-rail op amps

2011-12-04T14:40:00.000+08:00

Just got bitten. Or rather, just found out after over two years I'd made a booboo. I had used a Microchip MCP618 as a unity gain buffer for an ANLC with the sensor unit located a remote location. I was upgrading the load-control part of the circuit yesterday and while monitoring the output of the op amp at between sunset and dusk I was shocked to see the voltage jump from from V_DD to around 4.80V. (Thereafter it decreased in a smooth continuous gradient). That sent me into a near-panic. Questions raced through my head. Was the long length of cable--some 20 meters--from sensor to control circuit responsible for this behavior? Do I need to add a high value load resistor? Is there some soldering/board defect at the sensor?

Eventually I zeroed in on the fact that the 618 is not a full rail-to-rail op amp. Rechecking the datasheet and refreshing my memory, indeed while its output can, its input does not swing rail-to-rail. So to test whether the 618 is cause of the problem I bench-tested it using a 100K pot as input to the unity gain buffer. Sure enough as I ever so gradually turned the pot down from maximum, the buffer output jumps from 5.18 (V_DD) to around 4.90V.I tried this several times just to make sure its inherent. Well, it doesn't miss a beat. The same discontinuous output occurs every time.

I then popped the 618 off the breadboard and dropped in a pin-for-pin compatible MCP6273. This op amp has true rail-to-rail input and output. As I was hoping, as the pot is wound down the output voltage does not exhibit the sudden drop but instead smoothly and continuously decreases from V_DD.

Whew! I'm just glad it isn't some much more major error or defect.

Moral of the story: Make sure the op amp has rail-to-rail input and output if the application requires the entire range of values.

Relay board

2011-11-29T13:45:00.000+08:00

Over the years I've moved away from relays and adopted triacs for switching high voltage AC loads. Their quiet operation and compact size (heat sink excluded) are a plus. In the last few years, however, I've reverted to the electromechanical device. The prodigal son has returned (nahhh). Relays have their drawbacks including mechanical failure, contact point burning/pitting, and coil burnout, but they provide superb electrical isolation between control and power side of the circuit and negligible voltage drop across the contacts.

So here's my relay module v1.0 complete with polarity reversal protection diode, flyback diode, and LED power-on indicator. The relay in this case is a SPDT with a contact rating of 10A @240VAC/24VDC and a coil of 12VDC (measured resistance = 420 ohms). The board is designed such that the LED and its current limiting resistor need not be installed for the circuit to work--the additional current draw may be undesirable or an indicator lamp may simply be superfluous. Even the input diode in series with the positive rail isn't absolutely essential (if polarity reversal isn't an issue) and a jumper wire can be soldered in its stead. Omitting the flyback diode, on the other hand, is an experiment for foolhardy to try out.

DC coil power input is via the 2-pin connector with red going to V+ as per convention, while relay contacts are accessed via the 3-way terminal block. I'm obsessed with isolation so I've placed them on opposite ends of the board.

The paper phenolic board is 1 x 3 inches, scored and snapped off from a 4x3-inch "mother" board which contains three other clones. Yeah, I'm mass producing this.... Uhhh sort of.

Random number generator

2011-11-26T21:56:00.000+08:00

Needed a way to make a microcontroller turn a load on at random. A little research and I found an algorithm that goes by the highfalutin name linear feedback shift register. Basically the bits in the register are shifted one bit either to the left or right and the result is then XORed with a constant. The content of the register changes in a pseudo random way. It isn't at all random because when we perform the shift and XOR the register goes through each possible value once and only once (each of 255 numbers for an 8-bit register) until we cycle back to the original seed value (initial value of the register). Thereafter, the exact same sequence gets repeated.

It's important to make sure the seed stored in the register is nonzero, else it will remain zero.

PIClist has a number of code snippets for implementing the LFSR in Microchip PICs. The following is for generating a 16-bit random number written in PIC18 assembly:

  BCF     STATUS,C
  RRCF    LFSRVALUEH,F
  RRCF    LFSRVALUEL,F
  BTFSS   STATUS,C
  RETURN
  MOVLW   0xA1
  XORWF   LFSRVALUEH
  XORWF   LFSRVALUEL
  RETURN

Converting the above into mikroC PIC16 assembly with the 16-bit random number stored in variable N, we have:

asm{bcf     STATUS,C
    rrf     _N_L0+1,F
    rrf     _N_L0+0,F
    btfss   STATUS,C
    goto    $+4
    movlw   0xA1
    xorwf   _N_L0+1,F
    xorwf   _N_L0+0,F}

And converting the same into mikroC we have:

int8 RanNum()
{
  static unsigned int RANDOM = 1;

  RANDOM >>= 1;
  if (STATUS.C)
    RANDOM ^= 0xA1A1;
  return RANDOM;
}

The above code translates into just 8 lines of mikroC assembly using the enhanced midrange instruction set.

For the circuit I'm using it in, I need a number from 0 to 99 to emulate a percentage value. So what I did was to simply take the last two digits (decimal) by dividing the 16-bit number by 100 and taking the remainder. I used a 16-bit generator instead of an 8-bit because the application requires that repetition of the sequence does not occur too quickly. I also wanted the seed number to be changed every time the circuit starts from a power-off condition so that the same sequence doesn't repeat every time the circuit powers up. To implement this the firmware loads RANDOM with the value stored in an EEPROM address. A crucial check is made to make sure RANDOM is not zero. If it is then it's incremented by one. RANDOM is then incremented and stored back in the same EEPROM location. Thus, every time the circuit boots up, RANDOM starts with a different seed.

#define  addr_seed     0x1    // plug in your choice of eeprom address for the seed number
static unsigned int RANDOM;

void IniSeed()
{
  // seed number for random number generator is obtained from an eeprom location
  // the value of seed number is incremented and stored back in eeprom
  // thus, a different seed number is used every time the MCU powers up.
  RANDOM = EEPROM_Read(addr_seed);
  if (!RANDOM)                           // seed number must not be zero!
    RANDOM++;
  EEPROM_Write(addr_seed, RANDOM+1);
}

int8 RanNum()
{
  RANDOM >>= 1;
  if (STATUS.C)
    RANDOM ^= 0xA1A1;
  return RANDOM % 100;     // a number from 0 to 99 is returned 
}

Note that EEPROM_Read() and EEPROM_Write() are mikroC built-in functions. Admittedly the seed number in the above routine is only 8 bits long, but for my particular application this is sufficient. If you need a 16-bit seed then simply read the contents of two EEPROM addresses into RANDOM, increment RANDOM, and store the low and high bytes of RANDOM in the appropriate EEPROM addresses:

void IniSeed()
{
  RANDOM = EEPROM_Read(addr_seed)*256 + EEPROM_Read(addr_seed + 1);
  if (!RANDOM)                           // seed number must not be zero!
    RANDOM++;
  EEPROM_Write(addr_seed, (RANDOM + 1)/256);
  EEPROM_Write(addr_seed+1, RANDOM + 1);
}

Variable intermittent wiper control - printed circuit board

2011-11-23T14:05:00.001+08:00

Finally got around to making a PCB for the wiper control. Used DesignSpark PCB to draw the schematic and PCB layout. The board is 3 x 3.5 inches and was exposed to fluorescent light for 70 seconds. Vertical distance of the two 11-watt Toshiba compact fluorescent lamps from the board was 3 inches. On the long sides, I placed cardboard on which aluminum foil had been taped to reflect light back into the exposure area and even out the lighting. (Up to now I have no idea whether the board is sensitive only to UV or UV + visible light, nor do I know to what degree aluminum reflects/absorbs UV.) Details of the procedure and materials I use can be found in Making PCBs using presensitized boards.

I introduced one modification to the June 2011 circuit. The wire length from the board to the push button (a tact switch epoxied to the end of the stem switch that controls the headlights and turn signal lights) is almost a meter in length, so instead of directly connecting it to one of the MCU pins, I am now using a KB817 optoisolator. I also added a red LED to the circuit. It's connected to one of the MCU pins via a current limiting 330-ohm resistor. Right now it serves no function. I just included it just in case and since the MCU pin is unused.

The Sonalert buzzer isn't in the pics because it's connected via the terminal blocks.

As always the soldering leaves much to be desired. I particularly had trouble soldering the huge pins of the Telemecanique RXM2 DPDT relay to the board. The trick, which I learned only after botching it, is to lay on lots of flux paste on the pins (and copper pads) and melt a huge blob of solder to the puny 30W soldering iron (30-year old, non temperature controlled, and directly plugged into the 220VAC outlet). The thermal mass of the gob of solder and large contact area coupled with the cleaning action of the flux greatly increases the chances of successfully and cleanly soldering these gargantuan pins.

Cascading (snowfall) LED lights

2011-10-21T00:24:00.002+08:00

I first saw these kinds of lights some two years ago and back then didn't know what they were called so I dubbed them raindrop lights. Check out the following vids for a couple of variations of cascading lights: http://youtu.be/FK-wlvhhtXk and http://youtu.be/qR4DLUNAbAo. The first vid has a close-up of the unit, showing--to my surprise--DIP ICs and 1/4 Watt resistors. The LEDs these units use are of the type which can be seen from practically any direction.

Just as a challenge I wanted to emulate the effect using ordinary white LEDs and a microcontroller. After some trial and error I got the firmware working. I'm sure it could be improved upon and different variations could be implemented. For instance as in the second vid above, the cascade could be made without PWM, leaving fading for the very last LED.

So here's a vid of the breadboarded circuit. The firmware that drives it follows. If anyone will be so kind enough to donate a real video cam the pic quality can be greatly enhanced :-)

/*

Cascading (Snowfall or Meteor) LED Lights
October 16 2011

processor = PIC16F1827
compiler = mikroC v5.0.0

(configuration settings -- copied from mikroC's "Edit Project" window)
CONFIG1   :$8007 : 0x0F84
CONFIG2   :$8008 : 0x1613

*/


// if using different PORT pins just change the assignments below
// the firmware does not need to be edited
#define  led1                LATA.f1             // led1 is the first LED to be lit (topmost LED of the cascade)
#define  led2                LATA.f0
#define  led3                LATA.f7
#define  led4                LATA.f6
#define  led5                LATB.f7
#define  led6                LATB.f6
#define  led7                LATB.f5
#define  led8                LATB.f4
#define  led9                LATB.f3
#define  led10               LATB.f2
#define  led11               LATB.f1
#define  led12               LATB.f0
#define  led13               LATA.f4
#define  led14               LATA.f3
#define  led15               LATA.f2             // led15 is the last LED to be lit (bottom LED of the cascade)
#define  lastled             led15               // this is used in the Twinkle() function

// following used for twinkle effect
#define  fadeintime          2                   // number of PWM periods for each pulse width during fade in from min to max brightness
#define  fadeouttime         7                   // number of PWM periods for each pulse width during fade out from max to min brightness
#define  twinkle_delay       1                   // deciseconds between the end of the cascade and beginning of twinkle effect
                                                 // during this time led15 is off

#define  cascade_delay       20                  // deciseconds between cascades. during this time all LEDs are off
                                                 // time begins after Twinkle()

#define  t0_ini              256-128             // TMR0 initialize value every time it overflows
#define  t1h_ini             256-98              // TMR1H initialize value every time it overflows
#define  cascadetime         10                  // number of cycles (PWM periods) per stage
#define  maxstage            22                  // maximum number of stages
                                                 // a stage is when a set of LEDs are lit
                                                 // each successive stage moves the cascade by one LED

#define  int1                bit
#define  int8                unsigned char
#define  int16               unsigned int
#define  int32               unsigned long

#define  on                  1
#define  off                 0

// ==================================================================================================================

void IniReg()
{
  OSCCON = 0b1110000;        // 8MHz
  TRISA = 0;
  TRISB = 0;
  ANSELA = 0;
  ANSELB = 0;
  LATA = 0;
  LATB = 0;
  T1CON = 0b110000;          // prescale = 1:8, timer1 off
                             // given 8MHz, TMR1H = 98 counts, prescale = 1:8, timer1 tick = ~100ms
} // void IniReg()


// During the start of each PWM period the LEDs that will be "PWMed" for that stage are turned on.
void IniLEDs(int8 STAGE)
{
  switch (STAGE)
  {
    case 1:
      led1 = on;
      break;

    case 2:
      led1 = on;
      led2 = on;
      break;

    case 3:
      led1 = on;
      led2 = on;
      led3 = on;
      break;

    case 4:
      led1 = on;
      led2 = on;
      led3 = on;
      led4 = on;
      break;

    case 5:
      led1 = on;
      led2 = on;
      led3 = on;
      led4 = on;
      led5 = on;
      break;

    case 6:
      led1 = on;
      led2 = on;
      led3 = on;
      led4 = on;
      led5 = on;
      led6 = on;
      break;

    case 7:
      led1 = on;
      led2 = on;
      led3 = on;
      led4 = on;
      led5 = on;
      led6 = on;
      led7 = on;
      break;

    case 8:
      led1 = on;
      led2 = on;
      led3 = on;
      led4 = on;
      led5 = on;
      led6 = on;
      led7 = on;
      led8 = on;
      break;

    case 9:
      led2 = on;
      led3 = on;
      led4 = on;
      led5 = on;
      led6 = on;
      led7 = on;
      led8 = on;
      led9 = on;
      break;

    case 10:
      led3 = on;
      led4 = on;
      led5 = on;
      led6 = on;
      led7 = on;
      led8 = on;
      led9 = on;
      led10 = on;
      break;

    case 11:
      led4 = on;
      led5 = on;
      led6 = on;
      led7 = on;
      led8 = on;
      led9 = on;
      led10 = on;
      led11 = on;
      break;

    case 12:
      led5 = on;
      led6 = on;
      led7 = on;
      led8 = on;
      led9 = on;
      led10 = on;
      led11 = on;
      led12 = on;
      break;

    case 13:
      led6 = on;
      led7 = on;
      led8 = on;
      led9 = on;
      led10 = on;
      led11 = on;
      led12 = on;
      led13 = on;
      break;

    case 14:
      led7 = on;
      led8 = on;
      led9 = on;
      led10 = on;
      led11 = on;
      led12 = on;
      led13 = on;
      led14 = on;
      break;

    case 15:
      led8 = on;
      led9 = on;
      led10 = on;
      led11 = on;
      led12 = on;
      led13 = on;
      led14 = on;
      led15 = on;
      break;

    case 16:
      led9 = on;
      led10 = on;
      led11 = on;
      led12 = on;
      led13 = on;
      led14 = on;
      led15 = on;
      break;

    case 17:
      led10 = on;
      led11 = on;
      led12 = on;
      led13 = on;
      led14 = on;
      led15 = on;
      break;

    case 18:
      led11 = on;
      led12 = on;
      led13 = on;
      led14 = on;
      led15 = on;
      break;

    case 19:
      led12 = on;
      led13 = on;
      led14 = on;
      led15 = on;
      break;

    case 20:
      led13 = on;
      led14 = on;
      led15 = on;
      break;

    case 21:
      led14 = on;
      led15 = on;
      break;

    case 22:
      led15 = on;
      break;

    default:
      break;
  } // switch (STAGE)
} //void IniLEDs()


// Within the PWM period, LEDs are turned off when their particular pulse width has been reached.
void SwitchLEDs(int8 STAGE, int8 PWEXP)
{
  switch (PWEXP)
  {
    case 0:
      switch (STAGE)
      {
        case 8:
          led1 = off;
          break;

        case 9:
          led2 = off;
          break;

        case 10:
          led3 = off;
          break;

        case 11:
          led4 = off;
          break;

        case 12:
          led5 = off;
          break;

        case 13:
          led6 = off;
          break;

        case 14:
          led7 = off;
          break;

        case 15:
          led8 = off;
          break;

        case 16:
          led9 = off;
          break;

        case 17:
          led10 = off;
          break;

        case 18:
          led11 = off;
          break;

        case 19:
          led12 = off;
          break;

        case 20:
          led13 = off;
          break;

        case 21:
          led14 = off;
          break;

        case 22:
          led15 = off;
          break;

        default:
          break;
      }
      break;

    case 1:
      switch (STAGE)
      {
        case 7:
          led1 = off;
          break;

        case 8:
          led2 = off;
          break;

        case 9:
          led3 = off;
          break;

        case 10:
          led4 = off;
          break;

        case 11:
          led5 = off;
          break;

        case 12:
          led6 = off;
          break;

        case 13:
          led7 = off;
          break;

        case 14:
          led8 = off;
          break;

        case 15:
          led9 = off;
          break;

        case 16:
          led10 = off;
          break;

        case 17:
          led11 = off;
          break;

        case 18:
          led12 = off;
          break;

        case 19:
          led13 = off;
          break;

        case 20:
          led14 = off;
          break;

        case 21:
          led15 = off;
          break;

        default:
          break;
      }
      break;

    case 2:
      switch (STAGE)
      {
        case 6:
          led1 = off;
          break;

        case 7:
          led2 = off;
          break;

        case 8:
          led3 = off;
          break;

        case 9:
          led4 = off;
          break;

        case 10:
          led5 = off;
          break;

        case 11:
          led6 = off;
          break;

        case 12:
          led7 = off;
          break;

        case 13:
          led8 = off;
          break;

        case 14:
          led9 = off;
          break;

        case 15:
          led10 = off;
          break;

        case 16:
          led11 = off;
          break;

        case 17:
          led12 = off;
          break;

        case 18:
          led13 = off;
          break;

        case 19:
          led14 = off;
          break;

        case 20:
          led15 = off;
          break;

        default:
          break;
      }
      break;

    case 3:
      switch (STAGE)
      {
        case 5:
          led1 = off;
          break;

        case 6:
          led2 = off;
          break;

        case 7:
          led3 = off;
          break;

        case 8:
          led4 = off;
          break;

        case 9:
          led5 = off;
          break;

        case 10:
          led6 = off;
          break;

        case 11:
          led7 = off;
          break;

        case 12:
          led8 = off;
          break;

        case 13:
          led9 = off;
          break;

        case 14:
          led10 = off;
          break;

        case 15:
          led11 = off;
          break;

        case 16:
          led12 = off;
          break;

        case 17:
          led13 = off;
          break;

        case 18:
          led14 = off;
          break;

        case 19:
          led15 = off;
          break;

        default:
          break;
      }
      break;

    case 4:
      switch (STAGE)
      {
        case 4:
          led1 = off;
          break;

        case 5:
          led2 = off;
          break;

        case 6:
          led3 = off;
          break;

        case 7:
          led4 = off;
          break;

        case 8:
          led5 = off;
          break;

        case 9:
          led6 = off;
          break;

        case 10:
          led7 = off;
          break;

        case 11:
          led8 = off;
          break;

        case 12:
          led9 = off;
          break;

        case 13:
          led10 = off;
          break;

        case 14:
          led11 = off;
          break;

        case 15:
          led12 = off;
          break;

        case 16:
          led13 = off;
          break;

        case 17:
          led14 = off;
          break;

        case 18:
          led15 = off;
          break;

        default:
          break;
      }
      break;

    case 5:
      switch (STAGE)
      {
        case 3:
          led1 = off;
          break;

        case 4:
          led2 = off;
          break;

        case 5:
          led3 = off;
          break;

        case 6:
          led4 = off;
          break;

        case 7:
          led5 = off;
          break;

        case 8:
          led6 = off;
          break;

        case 9:
          led7 = off;
          break;

        case 10:
          led8 = off;
          break;

        case 11:
          led9 = off;
          break;

        case 12:
          led10 = off;
          break;

        case 13:
          led11 = off;
          break;

        case 14:
          led12 = off;
          break;

        case 15:
          led13 = off;
          break;

        case 16:
          led14 = off;
          break;

        case 17:
          led15 = off;
          break;

        default:
          break;
      }
      break;

    case 6:
      switch (STAGE)
      {
        case 2:
          led1 = off;
          break;

        case 3:
          led2 = off;
          break;

        case 4:
          led3 = off;
          break;

        case 5:
          led4 = off;
          break;

        case 6:
          led5 = off;
          break;

        case 7:
          led6 = off;
          break;

        case 8:
          led7 = off;
          break;

        case 9:
          led8 = off;
          break;

        case 10:
          led9 = off;
          break;

        case 11:
          led10 = off;
          break;

        case 12:
          led11 = off;
          break;

        case 13:
          led12 = off;
          break;

        case 14:
          led13 = off;
          break;

        case 15:
          led14 = off;
          break;

        case 16:
          led15 = off;
          break;

        default:
          break;
      }
      break;

    // for PWEXP = 7, no led need be switched off since it's duty cycle will be gradually decreased anyway in the next STAGE
    // therefore there's no need for a separate case statement. 
    // The default option below will automatically "catch" the case when PWEXP = 7

    default:
      break;
  } // switch (PULSEWIDTH)
} // void SwitchLEDs()


/*
The particular LEDs to be lit and their pulse width depends on the current STAGE. 
At the start of each PWM period all LEDs for the particular stage are turned on.
Then one by one, beginning with the LED that has the least pulse width, they're turned off. 
After the second TMR0 overflow, the prescale value of timer0 is changed every TMR0 overflow as shown in the table below. 
Every time TMR0 overflows it is re-initialized with t0_ini (128decimal).
The total time elapsed is the pulse width of the LEDs. 
The change in PW between the LEDs is exponential. 
The lead LED has a duty cycle of 100%.

PWN period = 8.192ms 
Fosc = 8Mhz
t0 tick = (TMR0 count)*(prescale)/(Fosc/4)

t0_ini  TMR0 count   prescale   t0 tick (us)  total time elapsed (us) 
128        128           1           64               64 
128        128           1           64              128 
128        128           2          128              256 
128        128           4          256              512 
128        128           8          512             1024 
128        128          16         1024             2048 
128        128          32         2048             4096 
128        128          64         4096             8192 
*/
void Cascade()
{
  // OPTREG[] lookup table contains values to be successively loaded into OPTION register during one PWM period
  // timer0 prescale values are {1,1,2,4,8,16,32,64}
  // to obtain timer0 prescale value = 1, prescaler is NOT assigned to timer0
  // timer0 initial value is kept constant at 128decimal
  const int8 OPTREG[] = {0b1000, 0b1000, 0b0, 0b1, 0b10, 0b11, 0b100, 0b101};

  int8 STAGE;                  // at which stage the cascade is currently
  int8 PWEXP;                  // exponent (with base = 2) of the pulse width
  int8 TOTALTIME;              // records number of PWM periods

  PWEXP = 0;
  for (STAGE = 1; STAGE <= maxstage; STAGE++)
  {
    TOTALTIME = 0;
    while (TOTALTIME <= cascadetime)
    {
      if (!PWEXP)                                // initialize (turn on) LEDs only when it's the start of a PWM period
        IniLEDs(STAGE);
      OPTION_REG = OPTREG[PWEXP];
      TMR0 = t0_ini;
      INTCON.T0IF = 0;
      while (!INTCON.T0IF) ;
      SwitchLEDs(STAGE, PWEXP);                   // turn off the LED
      if (++PWEXP > 7)
      {
        PWEXP = 0;
        TOTALTIME++;
      }
    } // while (TOTALTIME <= cascadetime)
  } // for (STAGE=1; STAGE<= maxstage; STAGE++)
} // void Cascade()


// PWM routine for the twinkle effect
void Dim(int8 EXP, int8 FADETIME)
{
  // pulse width (output high = led on) in terms of the value of TMR0, given a fixed timer0 period of 8.192ms
  const int8 PW[] = {1, 2, 4, 8, 16, 32, 64, 128, 255};

  int8 TOTALTIME = 0;
  int8 PULSEWIDTH;

  TMR0 = 0;
  INTCON.T0IF = 0;
  PULSEWIDTH = PW[EXP];

  while (TOTALTIME++ <= FADETIME)
  {
    lastled = on;
    while (TMR0 < PULSEWIDTH);
    lastled = off;
    while (!INTCON.T0IF);
    INTCON.T0IF = 0;
  }
}

// twinkle effect where fade in time and fade out time are or can be different
void Twinkle()
{
  int8 i;
  
  OPTION_REG = 0b10000101;             // timer0 prescale = 1:64
  for (i = 0; i <= 8; i++)
    Dim(i, fadeintime);
  for (i = 7; i > 0; i--)
    Dim(i, fadeouttime);
  lastled = off;
} // void Twinkle()


// delay in deciseconds
// as an alternative timer0 can be used instead of timer1 if, say, using an MCU with only one timer
void DelayDsec(int8 dsec)
{
  int8 i;

  TMR1L = 0;
  T1CON.TMR1ON = 1;
  for (i = 0; i < dsec; i++)
  {
    TMR1H = t1h_ini;
    PIR1.TMR1IF = 0;
    while (!PIR1.TMR1IF);
  }
  T1CON.TMR1ON = 0;
} // void DeadTime()


void main()
{
  IniReg();
  while(1)
  {
    Cascade();
    DelayDsec(twinkle_delay);
    Twinkle();
    DelayDsec(cascade_delay);
  }
} // void main()

----

November 23 2011 Addendum

Here's the schematic for the cascading lights circuit. As you can see it's just one MCU and LEDs on all the pins except for pin#4 (RA5) which is an input-only pin. Resistors can be as low as, oh about, 180 ohms for a power supply of 5 volts. You have to watch out for the maximum rating of each pin (25mA if I remember correctly) and the maximum for each PORT.

----

Schematic when using a PIC16F84A

Video of LED fade in/out

2011-10-13T17:25:00.001+08:00

For details of the following vid see yesterday's LED fading using exponentially changing PWM duty cycle. However, because the dimming wasn't as smooth as I wanted it to be, I changed a couple of items.

1. I used 32 pulse width values instead of 16. And so the look-up table for this demo is:

const char PW[] = {0, 0, 1, 1, 1, 2, 2, 3, 4, 5, 6, 7, 9, 10, 12, 15, 18, 22, 26, 31, 37, 44, 53, 63, 75, 90, 107, 127, 151, 180, 214, 255};

2. To preserve the 655ms total time from zero to maximum brightness I halved the timer2 postscale to 1:5.

3. Because of the increase in PW values, the constant in one of the conditional statements had to be changed from 15 to 31:

if (direction && ++i > 31).

LED fading using exponentially changing PWM duty cycle

2011-10-13T00:12:00.001+08:00

Not wishing to make the title any longer than it is, I left out the following qualification: Although the duty cycle (pulse width for output high) varies exponentially versus time, the time interval between changes in duty cycle is fixed.

One could I suppose also achieve fading with a linearly changing duty cycle and exponentially changing time interval. Sounds more complicated though.

The problem with fading an LED using PWM is that human perception of brightness is logarithmic, just like our hearing. So changing the PWM duty cycle in a linear fashion (e.g. incrementing or decrementing the duty cycle by 1% every unit time interval) does not result in a perception of linear change in brightness.

The solution is to change the duty cycle exponentially. The following is one formula that provides a way of obtaining a series of duty cycle values with a minimum of 1 and a maximum of 2ⁿ, where n is a positive integer. The fact that the numeric base = 2 means the results are perfectly suited to computing values for 8, 16, or 32-bit registers of microcontrollers.

duty cycle = 2^x/r

where
x = 1, 2, 3, ..., m-1, m
m = integral number of duty cycle values required.
r is chosen such that 2^m/r = maximum duty cycle value

One way to understand x/r is to think of a number of rulers all of the same length--say, 12 inches. One has graduations only in inches. Another has divisions only in half inches (of course two half inches still make an inch). Yet another is marked off in quarter inches. One has one-eighth inch graduations. And another is divided into sixteenths of an inch. x corresponds to the number of graduations/divisions. Hence our 12-inch ruler with quarter-inch divisions has a total of 12 inches x 4 divisions/inch = 48 divisions. And the ruler with one-sixteenth inch graduations has 12 x 16 = 192 divisions. On the other hand, 1/r corresponds to the unit used by our ruler or the distance between graduations. So for inch-graduated ruler, 1/r = 1/1. For the one-eighth-inch-graduated ruler, 1/r = 1/8.

Let's say we are constrained to using an 8-bit register (eg. CCPR1L of the PIC12F615) for our duty cycle values. This means the maximum pulse width value we can specify is 0xFF or 255 decimal. Assume we want to make an LED fade in from zero to full brightness in a relatively short time--less than half a second. Having the LED ramp up 16 values should be sufficient for a visually smooth, seamless fade in. Going back to our ruler, if we employ the ruler with one-inch divisions, we'd have eight values and those values, as per our formula, would be 2^1/1, 2^2/1, ... 2^8/1. But since we'd like 16 different pulse widths, we have to use the half-inch-graduated ruler which has 16 divisions from 1/2 inch to 8 inches. To obtain the actual duty cycle values, we use the formula giving us the following series: 2^1/2, 2^2/2, 2^3/2, ... 2^15/2, 2^16/2, or 1.41, 2.00, 2.83, .... 181.02, 256.00. Rounding those numbers off we have the following integral series: 1, 2, 3, 4, 6, 8, 11, 16, 23, 32, 45, 64, 91, 128, 181, 255. Obviously, given our 8-bit constraint, the maximum duty cycle value has to be 255 not 256.

If we wanted 32 pulse width values--perhaps because we are fading the LED over a much longer time interval and 16 values don't provide a smooth enough fade--we'd choose the ruler with quarter-inch divisions. Using the equation we have: 2^1/4, 2^2/4, 2^3/4, 2^4/4, 2^5/4, ... 2^31/4, 2^32/4. Here's a graph of this example.

Bear in mind that the ruler analogy is only an aid to understanding. Once you get the hang of the equation, you can throw away these imaginary rulers. And contrary to what the ruler examples imply, we're not limited to 2ⁿ number of pulse widths (eg. 8, 16, 32, 64). Still taking our maximum duty cycle = 0xFF, we can have, for instance, 24 values: 2^1/3, 2^2/3, 2^3/3, 2^4/3, 2^5/3, ... 2^23/3, 2^24/3. Or, say, 40 values: 2^1/5, 2^2/5, ... 2^13/5, 2^14/5, 2^15/5, ... 2^39/5, 2^40/5. Or 56 values: 2^1/7, 2^2/7, ... 2^55/7, 2^56/7. Notice that for all these examples m/r is still = 8 and so maximum duty cycle value in all these series is 0xFF.

One may, if desired, also use the following slightly modified formula

duty cycle = 2^x/r - 1

Using this equation forces the series to start with zero.

Given m = 16, r = 2, and thus a maximum duty cycle value of 2^16/2 = 0xFF, the series we end up with is: 0, 1, 2, 3, 5, 7, 10, 15, 22, 31, 44, 63, 90, 127, 180, 255. Note how the maximum is neatly the maximum possible for our 8-bit register.

Below is a sample program where an LED alternately fades in and out. The firmware employs a look-up table to change the duty cycle. PWM frequency is 244.14 Hz. This is the minimum PWM frequency obtainable in the PIC12F615 when using its internal oscillator (Fosc = 4MHz). That PWM frequency translates to a period of 4.096ms. Because 4.096ms x 16 duty cycle values is only = 65.5ms, I set timer2 postscaler to 1:10 which has the effect of holding each duty cycle value for 10 periods. With that the amount of time for the LED to go from minimum to maximum duty cycle = 4.096ms x 16 x 10 = 655ms which is slow enough for humans to actually see and appreciate. The downside is that keeping the DC value for 10 periods is noticeable at the lower DC values. The stepwise change is obvious. To remedy this, we can always increase the number of DC values and decrease the timer2 postscale value.

For the PIC12F615,

f_PWM = Fosc / [(PR2+1)*4*(T2PS)]

f_PWM = PWM frequency
Fosc = frequency of the oscillator
PR2 = PR2 register value
T2PS = timer2 prescale value

PWM period = 1 / f_PWM

Pulse width = (CCPR1L:CCP1CON<5:4>)*(T2PS)/Fosc

CCPR1L:CCP1CON<5:4> is a 10-bit number, with the 8-bit MSB in CCPR1L and the 2-bit LSB in CCP1CON<5:4>

In the firmware below CCP1CON<5:4> is = 0. When using the pulse width equation remember to left shift CCPR1L by two places. In other words multiply CCPR1L by 4.

LED is connected to pin P1A/GP2.

/*
LED fading using exponentially changing PWM duty cycle with fixed time interval between changes in duty cycle

October 12 2011

processor = PIC12F615
compiler = mikroC v5.0.0

*/

// computed duty cycle values using the equation INT{[2^(x/r)] + 0.5} - 1
// x = 1, 2, ..., 16
// r = 2
// values are stored in a look-up table in flash rather than RAM
const char PW[] = {0, 1, 2, 3, 5, 7, 10, 15, 22, 31, 44, 63, 90, 127, 180, 255};  

void main()
{
  unsigned char i = 0;
  bit direction;
  
  ANSEL = 0;                 // all pins digital

  // initialize PWM registers
  // see PIC12F615 datasheet DS41302C p.96 for PWM set up procedure
  PR2 = 255;
  CCP1CON = 0b1100;          // enable PWM mode, single output (P1A only)
  CCPR1L = 0;
  PIR1.TMR2IF = 0;           // clear timer2 interrupt flag
  T2CON = 0b1001011;         // timer2 prescale = 1:16, postscale = 1:10
  T2CON.TMR2ON = 1;          // turn on timer2
  TRISIO = 0b0;

  direction = 1;
  while(1)
  {
    if (PIR1.TMR2IF)          // timer2 interrupt flag is set when postscale value is reached 
    {
      if (direction && ++i > 15)
      {
        direction = 0;
        i = 14;
      }
      else if (!direction && --i == 0)
        direction = 1;
      CCPR1L = PW[i];
      PIR1.TMR2IF = 0;
    }
  } // while(1)
} // void main()

----

References:

http://www.instructables.com/community/linear-PWM-LED-fade-with-arduino/
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=45080&start=0
http://en.wikipedia.org/wiki/F-number
http://www.mikroe.com/app/webroot/forum/viewtopic.php?f=88&t=22277

Checking out the Pierce oscillator

2011-09-27T00:18:00.001+08:00

The Pierce oscillator is a very simple circuit and as with the ring oscillator also uses inverters (actually just one inverter will do). The principle of operation, however, is very different. While the ring oscillator exploits the incremental propagation delay through the series of inverters, the Pierce oscillator puts the inverter/gate into the linear region of operation and employs it as an analog amplifier.

To find out the details of the gate-based Pierce oscillator I recommend reading the references listed below. What follows is just a summary of the tips and formulas culled from the said references, pointers and tidbits which I found useful in getting a crystal-based oscillator up and running. I also did a number of breadboarded experiments and the results are shown below.

The following schematic shows the basic Pierce oscillator based on a CMOS inverter as its amplifier.

INV is of course the inverter (buffered or unbuffered). Oscillator signal is taken from the inverter output (V_out). To improve (decrease) its rise/fall time, another inverter or, better yet, a (fast!) Schmitt trigger can be used to spruce up the signal. The signal at the inverter input is a sinusoid and can also be used (some Microchip MCU datasheets show the clock signal being derived from the input of the inverter while other Microchip datasheets show it being taken from the inverter output).

R_f is a feedback resistor that puts the gate in linear (as opposed to digital) mode operation. The following table provides a rule of thumb value for R_f given crystal frequency:

Among other things, R_s limits the amount of crystal drive--increasing R_s decreases drive. A ballpark figure or first cut value for R_s can be derived by computing for and equating R_s to the reactance of C_b:

X_{c_b} = 1/(2πfC_b), where f = crystal frequency

According to Microchip:

R_s is typically 40 K ohms or less, but is almost never more than 100 K ohms. If the value for R_s is too high, then the high impedance input side of the amplifier may be more susceptible to noise, very much the same way a pull-up resistor on an input pin is normally kept below about 50 K ohms to prevent noise from having enough strength to override the input.

Freescale (Motorola) meanwhile claims that for low frequencies such as 32.768kHz watch crystals, R_s can go as high as 330Kohms. Because of a permissible maximum drive of just 1µW, a minimum R_s value for tuning fork crystals such as the 32.768kHz crystal is 10kohm.

C_a and C_b along with R_s and XTAL provide a 180 degree phase shift (INV provides the other 180 degrees for a total of 360). Moreover, the R_s and C_b network partly "acts as a low pass filter that discourages the crystal from running at a third or fifth harmonic, or other higher frequency" (Lancaster and Berlin). Increasing C_a and C_b decreases the gain. C_a and C_b are usually equal but C_b can be made larger than C_a.The voltage at the input of INV is (partly) determined by C_b / C_a, so that increasing C_b relative to Ca increases the voltage at INV input. As a rule the values of C_aand C_b should satisfy the following condition:

C_load = (C_a)(C_b)/(C_a + C_b) + stray capacitance

where C_load is the load capacitance of the crystal as per manufacturer's specifications. Typical load capacitances are 12 pF, 15 pF, 18 pF, 20 pF, 22 pF and 32 pF.

Finally, an advice worth keeping in mind: "Oscillator design is an imperfect art at best. Combinations of theoretical and experimental design techniques should be used." And so we move on to the experimental side of things.

I performed a few tests on a breadboard using 4.000 MHz and 32.768 kHz crystals. The values for the resistors and caps are the ones I arrived at after some trial and error. The values below seem to work better. Yes, that's a very subjective assessment and shall leave it at that.

I. Motorola MC14049UBCP hex inverting buffer

A. XTAL = 32.768 kHz
R_f = 10Mohm
Rs = 100kohm
C_a = 33pF
C_b = 50pF

Oscilloscope setup
Channel 1 (yellow) hooked up to INV2 output
Channel 2 (cyan) probe hooked up to C_b

CH1: INV2 output
CH2: INV1 output

CH1: C_b
CH2: INV1 output

I increased the capacitances as follows
C_a = 18pF
C_b = 100pF
and I was pleasantly surprised to see that the waveforms became much more stable--it practically ceased "wiggling" (the frequency was stable but the duty cycle wasn't and so the falling edge would be shifting rapidly to and fro horizontally--I was triggering on the rising edge so that wasn't moving at all)

CH1: INV2 output
CH2: C_b

Notice how the increasing the C_b to C_a ratio has decreased the signal's amplitude at C_b.

B. XTAL = 4.000 MHz
R_f = 5.1Mohm
Rs = 2kohm
C_a = C_b = 18pF

CH1: INV2 output
CH2: C_b

The CMOS 4000 series is relatively slow. In the reading above rise time is almost 37ns.

CH1: INV2 output
CH2: INV1 output

CH1: C_b
CH2: INV1 output

II. National Semiconductor MM74HC02N quad 2-input NOR gate. Unfortunately, I don't currently have any CMOS HC or AC series inverters. According to the datasheet each NOR gate is buffered as follows:

Using a buffered gate in a Pierce oscillator consumes less power and has a gain in the order of thousands compared to an unbuffered gate which has a gain of hundreds. The drawback of a buffered gate is that it is more sensitive to the values of the passive components and tends to be less stable.

A. XTAL = 32.768 kHz
R_f = 10Mohm
Rs = 51kohm
C_a = 33pF
C_b = 100pF

CH1: NOR2 output
CH2: C_b

I believe the over- and undershoots (at the rising and falling edges) is confusing the scope. In the screenshot above it's 40.98kHz, but in real time it's all over the place, sometimes reaching as high as 80kHz. So I turned on the cursors. As you can see it says 32.89kHz. Resolution is such that moving the cursor just one pixel down results in a reading of 32.68kHz.

To obtain a slightly better reading I sent the INV2 output to a Goldstar FG-2002C function generator / frequency counter. The LED display has a resolution to two decimal places and said the signal was 32.77kHz. I guess the output is pretty close to the crystal's fundamental frequency. The frequency counter apparently loads the INV1 output because connecting it directly produces garbage readings (bounces around from 40 to 65kHz). A minimum of 15 ohms of resistance or a few picofarads (the smallest I have right now is 18pF) of capacitance in series is enough to satisfy INV1. The reading is the same as probing INV2 output.

CH1: NOR2 output
CH2: NOR1 output

CH1: NOR2 output
CH2: V_DD

CH1: NOR1 output
CH2: C_b

Changing the time base and capturing those overshoots/undershoots:

CH1: NOR1 output
CH2: C_b
Trigger: rising edge, 1.0V

CH1: NOR1 output
CH2: C_b
Trigger: falling edge, 4.0V

B. XTAL = 4.000 MHz
R_f = 5.1Mohm
Rs = 10kohm
C_a = C_b = 33pF

CH1: NOR2 output
CH2: C_b

CH1: NOR2 output
CH2: NOR1 output

CH1: C_b
CH2: NOR1 output

It turns out that the scope probe might be (largely) responsible for the ringing in the output. When not probing either INV1 or INV2, V_DDhas much less ripple and the ripple in C_b signal practically disappears:

CH1: C_b
CH2: ground

CH1: NOR2 output
CH2: V_DD

CH1: C_b
CH2: V_DD

References:

Don Lancaster and Howard M. Berlin, CMOS Cookbook, 2ed., Howard W. Sams, 1988, p.279-281
AN849: Basic PICmicro® Oscillator Design
Pierce-Gate Crystal Oscillator, an Introduction
AN1706/D Microcontroller Oscillator Circuit Design Considerations
SZZA043: Use of the CMOS Unbuffered Inverter in Oscillator Circuits
AN340: HCMOS Crystal Oscillators

Taking a look at basic ring oscillators

2011-09-23T11:40:00.001+08:00

Just playing around with ring oscillators cobbled up using a number of basic CMOS gates. Measured V_DD of the linear power supply = 5.07 to 5.09V for all circuits. Circuits were assembled on a solderless breadboard. Interconnect wires varied in length. And the relatively long interconnects--compared to the short traces had these been fabricated on a PCB--almost surely affected performance and the characteristics of the oscillators.

I. First up is the Fairchild CD40106BCN hex Schmitt inverter. According to the datasheet its maximum propagation delay = 400ns at 25°C and V_DD = 5.0V. Its maximum rise/fall time (transition time) = 200ns at 25°C and V_DD = 5.0V. This oscillator has the lowest frequency among those tested. But its output is also the closest to looking like a square wave. Numbers in the schematics refer to IC pin numbers

I measured the output at the various pins to see how transition time would be affected--wanted to decrease it to make the wave as square as possible. The most significant effect occurs with the very first inverter after the oscillator. However, as you can see below, having inverters to "clean up" output after the oscillator has an impact on frequency as well.

Output at pin 8:

At pin 2:

At pin 4:

At pin 6:

II. Motorola MC14049UBCP hex inverting buffer. After discovering how lousy the output of a 3-inverter configuration was I tried a 5-inverter one. As you will see there is improvement but it isn't that remarkable, even if the frequency is almost halved.

At room temperature and V_DD = 5.0V, maximum rise time of the 4049 is 160ns, while maximum fall time is 60ns. Maximum propagation delay for low to high transition = 120ns. For high to low max propagation delay = 60ns.

A. Using 3 inverters:

Output at pin 15:

At pin 6:

At pin 4:

At pin 2:

B. Using 5 inverters:

Output pin 4:

At pin 2:

III. If I had them in my inventory I would've tested a 74AC hex inverter and Schmitt trigger, but the only part I have that comes close is a National Semiconductor MM74HC02N quad 2-input NOR gate. Datasheet says it has a maximum propagation delay of 18ns at 25°C and V_DD = 4.5V. Maximum rise and fall time = 15ns at 25°C and V_DD = 4.5V. With those specs, it's easy to see that the 74HC line is ultrafast compared to the jurassic 4000 series. However, its transition time to propagation delay time ratio isn't good enough to produce square waves. Actually the output is close to a sine wave. In fact, as can been seen in the scope readings, its rise and fall times aren't even short enough for the output to reach V_DD or ground.

At pin 10:

At pin 13:

A very noisy table lamp

2011-09-16T22:52:00.000+08:00

Using the ATX switching power supply I was testing a circuit consisting of a PIC12F1822 and SN75176 transceiver, plus a couple of LEDs. The circuit has 10uF filter caps and the MCU has a 0.1uF bypass cap. Much to my chagrin the fluorescent lamp on my bench was affecting the circuit--the MCU would sometimes do a power-on reset when I turned the lamp on or off. The desk lamp has an electronic ballast/starting circuit and has an 18-watt circular fluorescent tube. Adding more caps--100pF, 1nF, 10nF, 100uF--were for naught.

To find out how what the heck was happening I hooked up the oscilloscope to the power rails. I was horrified by what I saw.

The transient would sometimes reach 20V peak to peak! Fortunately it would last for less than 20us. To determine the frequency, I turned on the FFT. As you can see below the range is between 20 to 100Mhz.

I wondered whether a linear power supply would be immune to the transients. I hastily cobbled up one using a 220VAC to 12VAC transformer, W01M bridge rectifier, 470uF filter cap, 78L05 5VDC voltage regulator and a 200-ohm resistor as load. Here are scope readings:

Most of the noise is in the range <40Mhz. The amplitude of the transients seem less than for the ATX supply. However, this supply wasn't connected to the MCU circuit. That may have had an effect.

MCU linear regression implementation

2011-09-09T12:00:00.002+08:00

Due to noise in the circuit and real-time fluctuations in the phenomenon being measured the readings from a sensor are unsteady and would jump around from millisecond to millisecond just like the day to day up and down variations in the index of trading bourses. However, in the long run the value does show a trend as the variable being measured increases or decreases or remains relatively steady. Thus I'm trying out linear regression--fitting a line through the mess of data points--to tease out this trend. I've used the least squares method since that's what I'm familiar with (actually it's been years and had to hit the math textbooks to refresh my memory!).

What I need to know during every sensor read is the trend at that point. But of course I need some historical readings to compute for it. So I take the last n readings and use those to derive the line of best fit through the n data points. I only need to know the slope of the line (the y-intercept, i.e., the b in ax+b, is irrelevant). If the slope is positive then this implies the value being sensed is increasing, if it's negative it's decreasing, and if it's very close to zero then it's plateaued.

In the application that I have sensor readings are taken at fixed time intervals. The last n sensor readings are stored in an array. During every sensor read the slope is calculated. Because we're always taking the last n readings every time we compute for the slope what we're doing is analogous to computing for a moving average. In this case we can call it a moving linear regression.

The slope of the line of best fit is given by

(nΣxy - ΣxΣy) / [nΣx² - (Σx)²]
where

x = point in time
y = sensor reading

y is easy enough to understand. That's just the ADC reading of the analog sensor output. x, as I'm using it here, needs a little more clarification. Let's say our oldest reading of n readings is in cell y[1] and the latest reading is in y[n]. y[i] was taken at time x[i] . But x[i] does not store actual clock time, but rather normalized time. Thus x[1] = 1, x[2] = 2, ...., x[n] = n. The values of x are fixed even as we discard the old y value and shift in the latest. Moreover, the actual time interval between reads isn't or need not be reflected in x as well. Thus the actual elapsed time between two readings may be 5ms, 48ms, 100ms, 2000ms or what have you. As long as that time interval is fixed for all readings then we're good.

Because the values of x never change, the above equation can be greatly simplified. The formula for an arithmetic progression Σx = n(n+1)/2. Hence the least squares equation can be rewritten as

[nΣxy - n(n+1)(Σy)/2] / [nΣx² - n²(n+1)²/4]

n is common to both the numerator and denominator and so cancel out. We're left with

[Σxy - (n+1)(Σy)/2] / [Σx² - n(n+1)²/4]

At this point we can provide the firmware the value of n and let it do the calculations, but I'm using an MCU with only 2K of flash. And because I don't want to slow the processor down with unnecessary math computations--whose answers we already know beforehand because n is specified in the defines--I've simplified the formula further still.

Because the 8-bit PICs have very limited RAM and since the rest of the firmware also needs a lot of memory, I settled on n = 15 (I initially tried n = 31 but ran out of RAM). This number is based on the criterion n = 2ⁱ- 1, where i = integer, so that n+1 = 2ⁱ. The rationale for this constraint is that multiplying by 2ⁱ requires nothing more than left shifting the register bits. This reduces computing time and may also reduce code length. With n = 15 the slope of the line simplifies to

[Σxy - (15+1)(Σy)/2] / [Σx² - 15(16)²/4]

[Σxy - 8(Σy)] / [Σx² - 960]

Because x = 1, 2, ... n, Σx² = 1 + 4 + 9 + .... + 225 = 1,240. So the above further simplifies to

[Σxy - 8(Σy)] / [1,240 - 960]

(Σxy - 8Σy) / 280

Keep in mind the above equation is valid only for n = 15. For other values of n the constants will be different.

Here a C implementation of the above equation. It's in mikroC v.5.0.0. Because there are type conversions--integer to floating point and back--it's important to get type casting correctly or you'll get garbage. If in doubt cast the variables explicitly.

Given n = 15, the latest sensor reading is stored in Y[15]. The 15 historical readings are in Y[0] to Y[14]. These 15 values are the ones used in the equation. Y[15] will be copied into Y[14] and used in the next cycle through the state machine (not shown below). Because I want to see the value of the slope, I've added variable INTSLOPE. To reduce complications of deriving this from the floating point variable SLOPE when it's negative, the firmware computes for (Σxy - 8Σy) such that it's always positive. Because the slope can be and may often lie between -1 and +1, SLOPE is multiplied by 1000 before it's converted to an integer type and stored in INTSLOPE. This provides a resolution of 3 decimal places. For instance if INTSLOPE = 3571 then the actual slope = 3571/1000 = 3.571. The 16-bit INTSLOPE and the sign (plus or minus) of the slope are then transmitted out of the EUSART TX pin so I can view the values on a logic analyzer.


// MCU = PIC12F18xx or PIC16F18xx
// compiler = mikroC v5.0.0
// September 2011


#define  n                   15        // number of data points for linear regression
#define  positive            1         // sign of slope
#define  negative            0         // sign of slope

void LinReg()
{
  unsigned char i;           // counter
  unsigned int Y[n+1];       // newest reading is temporarily stored in Y[n]
                             // and then copied to Y[n-1]
                             // oldest reading is in Y[0] 
  unsigned int SUMY;         // sum of all Y
  unsigned int SUMXY;        // sum of all X*Y
  bit   sign;                // 1 = slope is positive; 0 = slope is negative
  float SLOPE;               // linear regression value of the slope
  unsigned int INTSLOPE;     // integer version of SLOPE. Actually equal to 1000*SLOPE

  Y[n] = CURR;               // CURR = latest sensor reading
  SUMXY = SUMY = 0;
  for (i=0; i<n; i++)
  {
    SUMXY += Y[i]*(i+1);
    SUMY += Y[i];
    Y[i] = Y[i+1];           // discard oldest reading and left-shift all readings including latest one
  }

  SUMY *= 8;
  if (SUMXY >= SUMY)
  {
    SUMXY -= SUMY;
    sign = positive;
  }
  else
  {
    SUMXY = SUMY - SUMXY;
    sign = negative;
  }
  
  SLOPE = SUMXY/280.0;       // this particular equation is valid only for n = 15
                             // SLOPE will always be positive.
                             // Check variable "sign" to determine if slope is negative or positive
  INTSLOPE = SLOPE*1000.0;   
  
  // transmit 16-bit slope and its sign via EUSART
  // EUSART is set up in a separate initialization routine
  while (!PIR1.TXIF);
  TXREG = sign;              // sign byte; 1 = positive slope, 0 = negative slope

  asm {nop}                  // datasheet says TXIF will give false value if read right after loading TXREG
  while (!PIR1.TXIF);
  TXREG = INTSLOPE >> 8;     // high byte

  asm {nop}                  // datasheet says TXIF will give false value if read right after loading TXREG
  while (!PIR1.TXIF);
  TXREG = INTSLOPE;          // low byte
}

----

IMPORTANT ERRATA
September 10 2011

I was fiddling with the circuit and found the following needed to be changed:

unsigned int SUMY;         // sum of all Y
unsigned int SUMXY;        // sum of all X*Y

unsigned long SUMY;         // sum of all Y
unsigned long SUMXY;        // sum of all X*Y

16 bits isn't enough when using a 10-bit ADC. SUMXY can exceed 0xFFFF. While Σy will not exceed 16 bits, 8Σy may. So to make sure, I changed both to 32-bit integers.

For a 10-bit ADC, each Y[i] will not exceed 16 bits of course. However, I found out after hours of going nuts that mikroC does not like the following expression/assignment

SUMXY += Y[i]*(i+1);

because, as far as I can tell, it goes bonkers due to the fact that SUMXY is 32 bits while Y[i] is 16 bits and i is 8 bits. To prevent SUMXY from ending up with garbage I had to change the above to

SUMXY = SUMXY + Y[i]*(i+1);

Gear trivia for not so trivial protection

2011-09-02T15:04:00.001+08:00

1. All the DMM probes I own have standard exposed metal rods around 2cm long. When doing hot checks on boards or high voltage AC what-have-you I always have to beware of shorting connections and even the probes and such booboos. To minimize inadvertent and unwanted contacts which could have disastrous consequences, I insulated one set of probes with heat shrink tubing, leaving only the conical tip bare. Now they're ultra safe to use.

2. I don't have a purchased ESD wrist strap. I figure I don't need one if the principle is to ground me to earth potential. What I've been using for years now is this. I have a wire that's connected to a copper stake that's been driven into the soil (earth). A 1 Mohm resistor is soldered in series. This resistor limits the current that may possibly go through you know who. At the other end of the wire is an alligator clip. Since I don't particularly like gators biting me, I wear my watch which has a metal strap to which I clip the alligator onto. When not using it on my wrist, the alligator clips onto a metal sheet I have on the bench. When I can't find my watch or am just too lazy to even put it on, I touch and wipe my hands on the sheet every so often and hope to Thor I won't zap any ICs.

Taking a peek at RS-485 signals

2011-08-30T14:42:00.001+08:00

Did a test of RS-485 lines. See the schematic for the transmitter section of the circuit. Three SN75176B transceivers were employed. One was configured as driver (transmitter), two as receivers. Driver was on only when transmitting. Vcc was cut off when not transmitting. Transmitter and receivers were connected using Samsung 4-pair AWG24 Category 5 UTP cable. Cable length from transmitter to the farthest receiver was around 30 meters. One pair was used for RS-485 line A and B, two pairs for power supply to the transmitter. The test receiver used below had its own power supply but all transceivers shared a common ground. There were no termination resistors across lines A and B. Pullup and pulldown resistors were as per schematic--20kohms each. Data packet consisted of 4 bytes + a 9th bit. Minimum time interval between packet transmission was ~50ms. Baud rate was 19.2 kbps.

In the following screenshots,
Channel 1 (yellow) = Line A
Channel 2 (cyan) = Line B
Math channel (purple) = A - B

Overshoots and undershoots are clearly visible during high/low transitions. In all probability these are due to signal reflections in the cable.

Zooming in:

With math channel turned on:

Channels 1 and 2 are turned off and vertical scale of math is decreased from 5 to 2V/division:

Vertical scale reduced to1V/div. Look at the left half of the trace. When transmitter is off A - B is approximately 1.0V. (Adjusting the vertical scale to <1V/div and using cursors, I was able to take a more accurate reading of 1.08V. With only one receiver connected A-B = 1.50V). Since this is >200mV pin R of the receivers will be high--the mandatory and expected line idle state.

Here are zoomed in views of over- and undershoots. The ringing dies out well before half a bit width. The first screenshot shows line A going from low to high. The second shows line A going from high to low. Note the different horizontal scales--500ns in the first, 200ns in the second.

My Rigol scope only has two channels so in the following screenshots
Channel 1: Line A
Channel 2: SN75176B pin R

Even with the ringing there are no errors in the output of the receiver, although undershoot does occur occasionally in pin R output (the Rigol is prone to aliasing, so there may in fact be very high frequency ringing which isn't showing up at this horizontal scale.)

With horizontal scale reduced, we get to see details of undershoots on pin R.

Overshoots when pin R goes from low to high are probably less frequent--I haven't been able to capture any yet.

Just to be fair to line B I let
Channel 1: Line B
Channel 2: SN75176B pin R

What I'd like to do in the future is to increase the baud rate to >100kbps and increase the cable length. Should be interesting to see how bad the ringing will get. And how it will affect data integrity. Something like the following is expected.

That's from a lab test performed by Texas Instruments. Baud rate was 200kbps. 100 feet of Bertek 100-ohm AWG24 twisted pair cable was used. There was one driver and only one receiver (TI AM26C31C and AM26C32C).

Using RS-485 transceivers

2011-08-28T18:00:00.003+08:00

The beauty of using RS-485 (more formally known as the TIA/EIA-485 standard) for long distance serial communication is that because it uses differential lines it's largely immune to common mode voltages and noise. It's also utterly simple electrically--at least in a half duplex setup--in that it uses only one twisted pair cable and a common ground.

Here's a setup for perhaps the simplest possible configuration: there's only one transmitter and one or more receivers. In other words communications is a simplex type--information goes only one way. The transmitter sends out data while the receivers intercept the data stream but do not transmit anything.

In the above circuit the non-inverting input of the unity gain buffer is connected to a sensor circuit with an analog output. The MCU's ADC converts the sensor reading to a digital value and sends it out serially. U1 is a RS-485 transceiver. Pin DE and /RE are controlled by the MCU, switching them high only when transmitting.

At the heart of the RS-485 is the transceiver. In fact RS-485 is merely an electrical standard. And the particular electrical characteristics of the transceivers determine whether one has a RS-485 circuit or not. There are a lot of transceivers out there and I would rather use something like Maxim's MAX48x series, but the price is simply eye popping! They're as expensive as instrumentation amplifiers. Instead I've been using the jurassic SN75176B which is over five times cheaper. Texas Instruments says it's rated for 10Mbps throughput. But hey my requirements are 2 to 3 orders of magnitude lower.

The problem with the 757176 is that it's a gas guzzler. An informal test shows that it draws some 16mA @Vcc = 5V when it's set up for reception only (pins DE and /RE are low). This shoots up to around 32mA when it's in transmission mode (pins DE and /RE are high). As Dave Jones would say, you can fly to moon on 32mA!

To limit the amount of juice it gulps, we can--at least in a simplex arrangement--turn off the 75176 when no transmission is being performed. As can be seen in the schematic above, a PNP transistor is used to power it up/down. When transmission of a data packet is about to commence the transceiver is switched on and right after the last stop bit is sent, the 75176 is powered down. Average power consumption of the transmitter circuit will depend on how frequent transmissions are made. It will also depend on the baud rate--the higher, the less time every transmission takes and therefore the shorter the time the transceiver will be on.

In half duplex systems where drivers (transmitters) are also receivers powering down the transceiver will probably be not an option.

A very important issue with these transceivers is to ensure that they will be fail-safe. Fail safe in this context means that even if the transmitter's DE pin is grounded--ie., the driver is disabled and lines B and A become tri-stated to high impedance--or if power to the transmitting transceiver is cut off as it is in the circuit above--any and all the receivers will still see a differential voltage between B and A that's > 200mV. As per the RS-485 standard, if -200mV < B - A < +200mV, then output of pin R will be indeterminate. To guard against this bias resistors are added to lines A and B. In the schematic above these are pull-up resistor Rb1 and pull-down resistor Rb2.

Very important note: The RS-485 standard states that when the difference between the voltages between B and A is > +200mV (i.e, B - A > 200mV) then a logic 1 is output on the receiver, and when B - A <. -200mV then a logic 0 is output. But chip manufacturers like Texas Instruments and Maxim have reversed this. And so B is A and A is B on their transceivers. No problem as long you don't mix transceivers that use the RS-485 standard labeling. From hereon I'll follow the TI / Maxim convention.

The values of the bias resistors determine the differential voltage A - B. How much bias resistance should be installed depends on how many receivers are connected to the network. For the transceiver used above, each receiver has a minimum input resistance of 12Kohms. The more receivers there are the less the total resistance there is since the input resistances are in parallel. This translates to lower value bias resistors. Here's how to compute the values:

Let:
R_{i_total} = total input resistance
I = current through R_{i_total}
V_CC = power supply voltage to which pull-up resistor will be connected
R_b = bias resistor value
R_T = total resistance which includes the bias resistors and R_{i_total}

We require that the voltage across the total input resistance be greater than 200mV:

I R_{i_total} > 200mV

Solving for current:

I > 200mV / R_{i_total}

The bias resistors and R_{i_total} are in series and form a voltage divider and we define their sum as the total resistance:

R_T = 2R_b + R_{i_total}

It's also equal to:

R_T = V_CC / I

Since we're looking for the value of the bias resistors:

R_b = (R_T - R_{i_total})/2

Substituting and simplifying we obtain:

R_b < (5V_CC - 1)R_{i_total} / 2

Example: Let's say we have two SN75176B transceivers on the network configured as receivers. V_CC= 5V. Each transceiver has an input resistance of 12Kohms. Because they're in parallel, R_{i_total} = 6K. Using the formula above, we find that bias resistors should be less than 72Kohms each in order for A - B to be > 200mV when transmitter is disabled (lines A and B are in a high impedance state).

If termination resistors are present then total resistance would be = R_{i_total}|| termination resistors. So if two 120 ohm termination resistors were present (termination resistors are usually between 120 and 150 ohms when using UTP cables) and the R_{i_total}= 6K then the total resistance = 6K || 120 || 120 = 1/(1/6000 + 1/120 + 1/120) = 59.4 ohms. Computing for the bias resistors we obtain 720 ohms. Because the very low resistance values of termination resistors, as much as possible we don't want to install them since they significantly increase power consumption.

Termination resistors are used across lines A and B for impedance matching to prevent/minimize signal reflections leading to ringing. So when do we need termination? Well, it depends if we have a short or long line/cable. One heuristic for determining whether a line is long or short is as follows.

Let:
t_t = transition time also known as rise/fall time of transceiver's transmitter signal in seconds
R_P = propagation rate of electrical signals in copper = 0.2m/ns = 2 x 10⁸m/s
L = cable length in meters

A line is considered long if:

t_t < 2(L/R_P)

(see Maxim's equation for a more conservative figure).

According to the SN75176B datasheet its t_t = 20ns. Let's solve for L to see how long the cable can be before it's deemed long.

L = t_tR_P/2 = (20 x 10^-9)(2 x 10⁸)/2 = 2 meters.

So if we're using the SN75176B and our cable is longer than 2 meters termination resistors are necessary. That's not the end of the story, however. We may still be able to get away without having any termination even at cable lengths much longer than this:

If the rise time is unknown, another way of deciding whether a line is long or short is to compare the shortest expected bit width and the 1-way cable delay. This method considers two factors: the reflections may bounce back and forth several times before settling, and the bit rates at the transmitter and receiver may vary slightly from each other. As a general guideline, if the bit width is 40 or more times greater than the delay, any reflections will have settled by the time the receiver reads the bits. (Axelson, p.111)

The key to obviating the need for termination is to have a sufficiently slow baud rate so that reflections in the transmission line (a "long line") have already died out by the time the microcontroller reads the bit. The 1-way cable delay is merely L/R_P. Thus for a 100-meter wire, the 1-way cable delay = 500ns or 0.5µs. Using the above guideline we can determine the maximum cable length given a particular transmission baud rate--the bit width is the reciprocal of baud rate.

Let:
B = transmission baud rate in bits/sec
R_P = propagation rate of electrical signals in copper = 0.2m/ns = 2 x 10⁸m/s
L = cable length in meters

The guideline states that:

1/B >= 40(L/R_P)

Solving for L we have:

L <= [(1/B)/40]R_P

L <= R_P/(40B)

For a baud rate of 19,200, L = 260 meters. So theoretically no termination is necessary if cable length is less than this. Just out of curiosity let's see the maximum baud rate at which we can transmit for the 2-meter cable above.

B = R_P/(40L) = 2.5Mbps

----

References:

Janet Axelson, Serial Port Complete: COM Ports, USB Virtual COM Ports, and Ports for Embedded Systems, 2ed, Lakeview Research LLC, 2007, Chapters.6 & 7.

Polarities for Differential Pair Signals (RS-422 and RS-485)

RS-422 and RS-485 Application Note (computation of bias resistor values)

AN1090 Methods for Trimming the Power Required in RS-485 Systems

ADC LSb mystery

2011-08-17T00:03:00.001+08:00

Does a 10-bit ADC really have a resolution (not accuracy) of 10 bits? Apparently it might not. I've been having problems with the LSb (least significant bit) of the ADC output of PICs. What's happening is that even with a stable, fixed-voltage input signal to the ADC, the digitized output--depending on the V_DD level and the input voltage signal--may either be stable or the value flip flops between two values (one LSb apart) from one conversion to the next.

The LSb problem is dependent on both V_DD and ADC input signal level. For example the problem might not occur at input signal X volts with a V_DD = 4.950V but will appear when V_DD is within the range of 3.0 to 3.6V. And/or it might get worse (i.e., the number of times the LSb changes becomes more frequent) as one approaches a certain voltage range. Or for a certain signal voltage Y, the problem may be nonexistent at all with V_DD from 2.5 to 5.0V. Or for signal Z the the LSb glitch may be present at practically the entire operating voltage range of the MCU/ADC.

I've tried everything I can think of to get rid of this hair-tearing problem: I've used a linear power supply instead of a switchmode to minimize power supply noise. I've used separate power and ground lines for digital and analog and employed star connections. Actually digital noise should be minimal since, as we'll see, the MCU goes to sleep when the ADC is reading. I've also peppered the circuit with filter and bypass caps. The circuit is in open air but I still allowed it to settle down thermally so drifts due to temperature are eliminated. I admit the circuit is breadboarded and not soldered onto a PCB and so contact problems may be the culprit. To minimize that possibility I've used redundant connections. I also tried buffering the voltage signal using an op amp. Though there has been a reduction, the above solutions have not completely eliminated the problem.

Here's the test circuit:

Bridge rectifier output is approximately 12VAC. Potentiometer is a 5-ohm multi-turn Bourns 3590S-2-502L. Because this is the only highly reliable pot that I have and because output voltage of the LM317 must not exceed 5V (the PIC's max VDD ), I had to add the 560 and 220 ohm resistors. When the pot is turned all the way to zero, the 560 ohm resistor is shunted leaving only the 220 ohms. When the pot is at its maximum 5K, it's in parallel with the 560 giving a net resistance of 504 ohms. This in turn is in series with the 220 ohm, giving a total of 724 ohms. Plug those values into the LM317 equation and the effective output range of this power supply is 2.4 to 5.0V.

Firmware is as follows. It's the 3rd or 4th revision. The ADC uses V_DD as its positive reference and ground as its negative voltage reference. Thus the ADC output will be ratiometric with respect to the power supply. This way the analog to digital conversion is immune to drifts in the power supply. ADC read is performed approximately every 8ms. Because the PIC12F1822's ADC has silicon flaws, ADC read is performed during sleep, thus although timer0 tick is set to 8ms, several hundred microseconds are added while the system clock is shut down. The ADC read takes so long because there are actually two sets of reads. One is a single read and the other is a set of 16 reads which are then averaged. I tried averaging the reads to see if I could get obtain a value that doesn't keep flipping around. After the reads, the current and previous reads are compared. If they're different then the corresponding MCU pins (neflag and neflagave) are made high, else they're made low. Those pins are connected to an oscilloscope and logic analyzer so I can see how (un)stable the ADC reads are. In this final revision of the firmware I've also enabled the EUSART so I can see by how many bits the ADC reads differ (the Saleae Logic analyzer automatically decodes the serial data stream). Only the lower byte of the ADC output (register ADRESL) is transmitted.



/*



processor = PIC 12F1822

compiler = mikroC Pro v.5.0.0

August 2011



Test of ADC LSb

internal oscillator is used, WDT disabled, power up timer and brown out reset disabled, MCLR disabled



*/





#define  neflag              PORTA.f5            // not equal flag; 1 = previous and current ADC values are not equal

#define  neflagave           PORTA.f4            // not equal flag average; 1 = previous and current averaged ADC values are not equal

#define  t0ini               256 - 250           // value loaded into TMR0 every time it overflows





void IniReg()

{

  OSCCON    = 0b1101000;     // internal clock 4Mhz

  TRISA     = 0b100;

  ANSELA    = 0b100;

  PORTA     = 0;



  TMR0      = t0ini;

  OPTION_REG = 0b10000100;   // Weak pull ups disabled

                             // timer0 uses internal clock,

                             // prescaler assigned to timer0, prescaler = 1:32



  ADCON0 = 0b1001;           // channel 2, ADC on

  ADCON1 = 0b11110000;       // right justified, use Frc, Vdd as positive reference voltage

  INTCON.GIE = 0;            // global interrupt disabled

  PIE1.ADIE = 1;             // ADC interrupt enabled



  // baud rate = 2400

  SPBRGH = 0;

  SPBRGL = 25;

  RCSTA.SPEN = 1;

  TXSTA.TXEN = 1;

  TXSTA.SYNC = 0;



} // void IniReg()





/* =========================================================================================================



According to PIC12F1822 Silicon Errata sheet DS80502C the ADC unit in certain silicon revisions is buggy:



"Under certain device operating conditions, the ADC conversion may not complete properly.

When this occurs, the ADC Interrupt Flag (ADIF) does not get set,

the GO/DONE bit does not get cleared and the conversion result

does not get loaded into the ADRESH and ADRESL result registers."



mikroC Pro v5.00 compiler's Adc_Read() built-in ADC function uses the GO/DONE bit to check conversion completion (without putting the MCU to sleep, of course)

so the function cannot be used. And indeed the MCU hangs (when WDT is disabled) or the MCU resets when WDT is enabled.



The workaround used here is as per method 1 in the said errata:



"Select the dedicated RC oscillator as the ADC conversion clock source,

and perform all conversions with the device in Sleep."



=========================================================================================================  */



unsigned int ADC()

{

  PIR1.ADIF = 0;                       // clear ADC interrupt flag

  INTCON.PEIE = 1;                     // peripheral interrupts enabled

  ADCON0.GO = 1;                       // start ADC conversion

  asm {sleep}                          // zzzzzzzzzzzzzzz.... when ADIF = 1 MCU will wake up and will continue execution of the program

  PIR1.ADIF = 0;                       // clear ADC interrupt flag

  INTCON.PEIE = 0;                     // disable peripheral interrupts

  return ADRESH*256 + ADRESL;          // return the 10-bit ADC value as a 16-bit number

}



void Compare()

{

  unsigned char i;

  static unsigned int CURR = 0;        // current single ADC reading

  static unsigned int CURRAVE = 0;     // current average of 16 ADC readings

  static unsigned int PREV;            // previous single ADC reading

  static unsigned int PREVAVE;         // previous average of 16 ADC reading

  unsigned int SUM;                    // sum of 16 ADC readings



  PREVAVE = CURRAVE;

  SUM = 0;

  for (i=0; i<16; i++)

    SUM += ADC();



  PREV = CURR;

  CURR = ADC();

  

  TXREG = CURR;                        // bec ADC is performed during sleep while serial data transmission is dependent of the system clock

                                       // transmission can only begin after all ADC reads are done



  if (CURR == PREV)

    neflag = 0;

  else

    neflag = 1;



  CURRAVE = SUM / 16;

  if (SUM % 16 >= 8)                   // number rounding algorithm

    CURRAVE += 1;



  if (CURRAVE == PREVAVE)

    neflagave = 0;

  else

    neflagave = 1;

}



void main()

{

  IniReg();



  while(1)

  {

    if (INTCON.TMR0IF)

    {

      TMR0 = t0ini;

      Compare();

      INTCON.TMR0IF = 0;

    }

  } // while(1)

} // void main()

I used the oscilloscope with time base on roll mode with one channel monitoring neflag and other neflagave. I opted not to take screenshots of the scope--would take too much effort. But here are some of the logic analyzer data at particular voltages. As you can see the averaging routine sometimes works, sometimes doesn't, depending on how bad the LSb problem is. Resistor values are as per their color code. V_DD values are actual measured voltages using a Fluke 87V.

I. Ra = 5.1K, Rb = 4.3K

A. V_DD = 2.502V

B. V_DD = 4.000V

C. V_DD = 5.000V

II. Ra = 5.1K || 330 = 310, Rb = 4.3K

I provide only a screenshot for V_DD = 5.000V. There is absolutely no LSb problem for V_DD = 2.5V to 5.0V

III. Ra = 5.1K, Rb = 4.3K || 330 = 306

A. V_DD = 2.999V

B. V_DD = 3.499V

C. V_DD = 4.500V

D. V_DD = 5.000V

So what could be causing this ADC read glitch? Well, no ADC is 100% accurate. It will have various sources of errors--among them INL, DNL, offset, and gain errors--due to silicon and its fabrication. But accuracy isn't our problem; it's resolution. Ostensibly none of these is the error that I've encountered. What it does look very much like is conversion error due to transition noise, also known as code-transition noise or code-edge noise. Transition noise is,

the range of input voltages that cause an ADC output to toggle between adjacent output codes. As you increase the analog input voltage, the voltages that define where each code transition occurs (code edges) are uncertain due to the associated transition noise.

Keeping the input signal constant and performing lots of ADC reads, the distribution of ADC output codes is supposedly Gaussian (normal distribution). In the tests with the PIC, however, apparently there are only two codes, i.e, output varies by only one LSb. I haven't done it, but it should be easy to have the MCU read a thousand or ten thousand times and tell us whether the codes vary by more than one LSb.

Interestingly, averaging, which I used in the firmware above, is the recommended algorithm to address LSb flickering. However, as we've seen even averaging (at least the way it was implemented above) isn't a panacea. Maybe I'm doing it wrong.

Is it dawn yet? How shall we know?

2011-07-27T01:24:00.000+08:00

Those of you who've been following the development of the MCU-based ANLC will probably remember that I turned to a micrcocontroller since I want to switch the load off not at the ambient light level (corresponding sensor voltage) at which we want to turn on the load, nor at the load turn-on ambient light level + some hysteresis, but rather at the very crack of dawn, which corresponds to a light level significantly less than that at load turn-on. So you might be wondering what algorithm I'm currently using to implement that.

With all other factors (clouds, city lights, etc.) kept constant, one characteristic of dawn is that the light level rises evenly and continuously (thanks to the very stable rotation speed of the earth and nearly constant light output of the sun). And this increase will not exceed a certain dV/dt--which we've measured (at least in my particular location in the globe which happens to be 15° north of the equator) to be almost 6mV/s (@Vdd = 5V).

So one way of ruling out other light sources is to look at whether dV/dt > 0 but < 6mV/s and whether this is sustained over time. If it's currently very dark (night time) and these conditions are met then there is a good probability we are witnessing dawn/sunrise. If not then there is a good chance the light source isn't the sun.

In addition we'd want to monitor for the above conditions as close to actual dawn as possible. We don't, for instance, want to check after just a couple of hours after dusk. And speaking of time of day, our circuit doesn't actually know what time of day it really is. For instance just because ambient light level has dropped below the trip point doesn't mean it really is dusk. It may be midday but the sky is so heavy with dark nimbus clouds that the light level has dipped to a point that the load has been turned on. The algorithm needs to take this into consideration.

One way of gaining confidence that it really is nighttime is to monitor the amount of time the load has been on. If the shortest night during the entire year is, say 10 hours, then we can be fairly sure that it's night if the load has been on for at least 8 hours. We can thus wait 8 hours after the load has been on before beginning to check for dawn conditions.

We can also monitor the sensor voltage to find out if it's really nighttime, but the night time reading/value will depend on where we install the sensor and how much artificial light sources will be polluting it. As I mentioned before I placed the sensor on the roof and shielded it on the sides to minimize the effects of streetlights, billboard lights, et al.

Besides just waiting x hours to begin monitoring for dawn dV/dt, we also want to find out the maximum light level for an hour or two before the time we begin checking for dawn because we only want to start applying our dawn dV/dt criteria when ambient light level exceeds this value. Given that this is the maximum ambient light level close to dawn, there is a greater probability that light whose intensity exceeds it and which keeps increasing but has a rate of increase less than the max dV/dt is in fact indicative of the first rays of the sun trickling in and not some other light source.

While I've implemented the above set of detection conditions for several days now--and so far so good--I imagine they do not provide a foolproof way of determining the onset of dawn. For example, if our firmware is already monitoring for dawn conditions and clouds begin rolling in, gradually reflecting more of the city lights thus increasing the sky light level and if the clouds move in at just the right rate so that max dV/dt isn't exceeded, then our firmware will be fooled into switching the load off.

One way of further improving the system is to add another sensor. We set the sensors up such that one receives light mainly from the eastern part of sky while the other from the western half (this can be as simple as having the LDRs side by side with an opaque board between them to block light from the eastern/western side of the sky from falling on the west/east LDR). We can then monitor for differences in light levels detected. Surely the eastern part of the sky will be brighter at dawn. As a bonus we can use this setup to detect dusk as well.

For now, however, I'm sticking to a simple single-LDR sensor. There won't be need to make it any more complex if the algorithm works or a better algorithm can improve dawn detection.

A more decent measurement of dawn and dusk dV/dt

2011-07-25T00:28:00.000+08:00

I previously estimated the maximum dV/dt of the MCU-based ANLC sensor during dusk and dawn at 4.5mV/s, but I want to have a more accurate figure. Because I don't have the proper test gear, I had to make do with a DMM and a stopwatch.

I decided to keep dV constant at 0.1V and record the time it took for the sensor voltage to increase/decrease by that amount. Thus what I was recording was in fact dt/dV. It would then be a simple matter of getting the reciprocal to obtain dV/dt.

The stopwatch of my Nokia cell phone has a "split timing" feature that allows the user to press the button and have a reading without actually stopping the stopwatch. Unfortunately, while using it I found out that it has a limit of 20 split timing readings. So as you will see, there are breaks in the data and graph. Those are the times when I had to reset the stopwatch. Too bad I just discovered this online split timer and countdown timer. Would've been great to use it.

The July 23 readings were a spur of the moment thing. I didn't actually plan to record the values. And so data on that date are quite limited.

Enough intro. Here's the spreadsheet with all the data, computations and graphs.

It's clear from the table and graphs that the maximum dV/dt is almost 6mV/s. Two things of interest: 1. The curves for dawn and dusk apparently don't have the same shape. Wonder if more data will even out the differences or if this difference is intrinsic. 2. The July 24 dusk graph is shifted downwards compared to the previous day's. This is probably because it was rather overcast on the 24th. That dV/dt can be attenuated by cloud cover needs to be noted.

Digital filter for auto night light

2011-07-22T13:19:00.001+08:00

In any automatic night light circuit that's meant to switch on perimeter security lights, the time period we are most interested in is dusk and dawn. We want the lights to be switched on at dusk and turned off at dawn. (Whether the lights are turned on/off earlier or later is dependent on the user.) During the night we want the lights on regardless of lightning flashes or car headlamps shining on the sensor or bright city lights being reflected by the clouds or a full moon or what have you. During the daytime we want the lights off regardless of clouds rolling in and out and thus momentarily blocking the sun, or a very overcast day, or a heavy downpour. Of course we would want the lights turned on even during the middle of the day if for some reason utter darkness descended such as during a (near) total solar eclipse, or--if we wanted to test the circuit--if we covered the sensor with some opaque material.

I've discussed the following light sensor here and here. Just a summary of how it works: R1 and LDR form a voltage divider. When the voltage across LDR is greater than across the 10uF capacitor, the cap gets charged via D1. When voltage across the cap is greater than across LDR, the capacitor discharges via R2. Given how D1 shunts R2 during charging and given that R1 has a much lower value than R2, the net result is that charging rate is faster than discharge rate. This means that when there is an abrupt and large increase in the level of ambient light (LDR resistance decreases) the voltage across the cap decreases slower compared to when there is sudden and large decrease in light level (LDR resistance increases). In other words, the circuit has a greater inertia to positive changes in light level than to negative changes in light level. During daytime, assuming the sensor were located outdoors and were we to shroud it with a black opaque bag, the voltage output would within seconds rise close to VDD. Were we then to take off the bag, the voltage would drop back to near ground level but a slower rate than when darkness fell upon the LDR.

Recently I provided an update on the MCU-based ANLC I'm testing. It's still a work in progress but I thought I'd provide more information on the algorithm I'm using to try and mimic the asymmetric filtering action of the analog circuit above.

In the MCU version of the ANLC the LDR and fixed resistors have switched places. Sure we can retain the fixed resistor as the pull-up, but I find it more intuitive associating a low voltage sensor output with darkness and near VDD output as bright light condition.

One way of implementing a low pass filter digitally is to compute for the moving average (MA). We can read the ambient light level at fixed time intervals and store the values in a one-dimensional array. Every time a new reading is performed the oldest reading is discarded and the new reading stored. The readings are summed and average computed.

One problem with the MA filter is that it will not provide the asymmetric filtering. As the graphs below show, an MA filter reacts the same way whether the light level is increasing or decreasing. Another characteristic of the MA filter is that a large number of readings are required to sufficiently attenuate light level changes that have a high dV/dt (change in voltage over change in time). Having a large number of readings is analogous to having large capacitance. A large cap takes longer to charge/discharge. More readings means there is more inertia to new readings. But lots of stored readings translates to memory guzzling, specially because 16-bit values are going to be stored. Because it can't meet the specs we have to conclude that the MA filter is unsuitable for this application.

Because the charge and discharge rates of the capacitor in the analog circuit above is what provides the filtering action, we can implement this digitally by limiting the dV/dt of light level readings. Here dt translates to the interval between reads by the analog-to-digital converter. If this interval is fixed then we need only deal with dV. Because we want to have more inertia against increasing light levels we can limit the dV when it is positive much more strongly when dV is negative. This is easily done in firmware by comparing the previous and current light level readings. If the difference exceeds the maximum positive (or negative dV), then we only store a value equal to the previous reading plus the positive dV (or minus the negative dV).

Letting

dV⁺ = maximum permitted change in voltage if voltage is increasing
dV^- = maximum permitted change in voltage if voltage is decreasing
V_i = current voltage reading -- will be adjusted to meet max dV
V_i-1 = previous voltage reading -- already adjusted to meet max dV

and assuming that V_i contains the latest raw/unmanipulated ADC reading, the algorithm for what we can call an asymmetric dV attentuation or ADVA filter is as follows (written in pseudo C):

if (V_i > V_i-1 && V_i - V_i-1 > dV⁺)
V_i = V_i-1 + dV⁺

if (V_i < V_i-1 && V_i-1 - V_i > dV^-)
V_i = V_i-1 - dV^-

Manipulation of the light reading is performed only if and when either of the dV limits are exceeded. Otherwise the raw reading is accepted as is.

From a record of ambient light levels during dawn and dusk we can determine that the maximum dV/dt = ~4V / 15min = ~4.5mV/s @V_DD = 5V. Therefore, assuming dt = 1s, we can let dV⁺ equal to some value close to 4.5mV while dV^- can be much larger in order to create the asymmetry.

To see how the MA and ADVA compare with one another I did a simulation using a spreadsheet. Check it out to see the numerical values used. Below I've pasted the graphs from the simulation. For the MA the number of readings averaged = 16. For the ADVA, dV⁺ = 0.01V, dV^- = 0.25V. These dV values are the ones I'm currently using in a bench test.

The above simulates night condition where a transient bright light condition occurs (eg. a flashlight is shone directly at the sensor for many seconds). The light level is the blue rectangular pulse. The red curve is the MA response, while the yellow-orange curve is the ADVA output. Compared to the ADVA the MA has a much steeper slope. Because the MA averages 16 readings, after a time interval of 16, the MA output = to the sensor output. The ADVA on the other hand barely budges from its initial value.

Now let's say the sensor output voltage at which the load is turned on is 1V and the hysteresis band = 1V (and so the load turn-off voltage = 2V). With the MA the load will be turned on and then off with this particular burst of light on the sensor. The ADVA meanwhile will be immune to it. For the transient to get the ADVA to trip the load, it has to be sustained for a much much longer time.

Note the MA and ADVA waveforms: triangular and sawtooth, respectively. As we will see the waveforms will change depending on the input signal.

The above simulates daytime condition with the sensor suddenly immersed in darkness (eg. it was covered with a thick black plastic bag). The results are interesting. The MA and ADVA overlap each other during the downward slope. But this is just a coincidence. For a different number of readings for the MA or a different dV^-, each of them will have a different negative slope. Nevertheless, with either filter the load will be turned on (assuming, as before that the trip levels are 1V and 2V). But when the light level returns to "normal," you can see how the ADVA takes its time rising. This means that it will be a very long while (about a hundred seconds in an actual bench test with dt = 1sec and dV⁺ and dV^- as per simulation values) before the load is switched off.

Any light level increase with a rate of change greater than those during dusk or dawn will be attenuated by the ADVA. What surprised me in the above is how a triangular input to the MA results in a (quasi?) Gaussian waveform.

Because the rate of decrease in the light level above is less than dV^- the ADVA tracks the light level while it is decreasing and thus we see the waveforms overlapping. However, the two part ways when light level begins to increase.

Out of curiosity I tried out geometric changes in light level. The one above and below use a factor of 1.05. The ADVA tracks the increase in light level until the point where it exceeds dV⁺.

Because the negative rate of change of the light level is well below dV^- the light level and ADVA waveforms overlap.

New Youtube lectures on filters by Analog Devices

2011-07-17T17:06:00.000+08:00

Assuming you know the basics of electronics, including op amps, the following lectures are easy to understand and pretty enlightening.

Filtering 101: Single Pole Filters

Filtering 101: Single Pole Filers with Op Amps

Filtering 101: Multi Pole Filters with Real Poles

Filtering 101: Multi Pole Filters with Sallen-Key

Microcontroller-based automatic night light circuit

2011-07-13T22:38:00.000+08:00

While discussing an all-linear automatic night light circuit I mentioned that I was testing an MCU-based ANLC. Well, I've been tweaking the firmware since. The other day I installed the sensor outdoors and have connected the circuit to control 220VAC loads.

Last night the circuit got fooled when clouds moved in at around 2am and reflected sufficient city lights and streetlights that the MCU thought it was already the beginning of dawn and switched off the load. This is because the software algorithm is such that a 10-bit ADC change of just 0x00A from the average dark ambient light level is interpreted as dawn. Competent programmer that I am, the firmware also includes a conditional which turns the load back on again should the light level drop back to the average dark level. And some half hour or an hour later (not sure because I went back to sleep before waking up again some time later) it did actually did return to dark level conditions. A sonalert buzzer is temporarily hooked up such that it sounds when the load (perimeter security lights) is off and as far as I know (sleepy head that I am) the next time the load was switched off by the circuit was around 5am--true dawn.

Earlier that same evening at around midnight while remotely monitoring the voltage output of the sensor ("ldr" in the schematic) with a DMM I was surprised to see the numbers climbing rapidly. The output had already settled at ~20mV but then increased quickly within minutes and peaked at ~310mV. I had to look out the window just to make sure I wasn't witnessing a circuit glitch but that in fact ambient light level was shooting up. And true enough the sky had turned orange and bright--from the cloud cover. The circuit did not turn the load off because the firmware was using a different hysteresis value at that time. Only after the load has been on for six hours does it use the hysteresis value of ten (the 10-bit ADC value mentioned above). By 2am this six hours had already elapsed.

Because of the detection sensitivity used, the light sensor circuit is located on the roof to minimize being affected by artificial lights. The LDR faces directly up (zenith) and is housed in a translucent plastic box. The box is shielded on the sides to prevent streetlights and lights from nearby buildings and billboards from unduly affecting the sensor. The very high impedance output of the sensor requires a unity gain buffer. The LDR used has a resistance of >30Mohms in complete darkness.

On the main control board, a low pass filter comprised of R_LPF and C_LPF (cut off frequency = 1/(2πRC) = 1/(6.28*100K*0.1uF) = 16Hz) attenuates high frequency noise which could be caused by EMI particularly those from lightning. A unity gain buffer is used to provide a low impedance signal for the MCU. High value load resistor R_L is used because in the event that the cable to the sensor breaks, the input of the LPF and buffer will not be left floating. In such an event R_L grounds the input, fooling the MCU to think that it's nighttime and thus turning on the load. This serves to alert the user (in the daytime) of a malfunction.

PB is used to select the light level at which load will be turned on. The user waits until the ambient light level is at the point where s/he wants the load switched on. At that moment PB is pressed. The circuit stores the light level in EEPROM and uses this value until it is changed. Pressing and holding down PB for a second resets the value to its minimum (I arbitrarily set it ADC value 0x064)--meaning load will be turned on only when it's really dark. LY is the indicator light for PB. It flashes briefly when PB is pressed (falling edge detected) and it blinks on and off for 1.5s when the trip level has been reset to minimum. A debouncing routine is used to, well, debounce PB, detect falling/rising edges, and monitor how long PB has been depressed.

REL1 and REL2 are mini relays with 24VAC coil. They are switched using a MOC3021 optoisolator employing a snubber circuit. REL1 and REL2 are at different locations. Using low voltage to control the relays translates to safety and perhaps even less expensive wires.

Triac optoisolator directly driving an inductive load

2011-07-12T01:38:00.000+08:00

As far as I know the MOC301x and MOC302x series of triac optoisolators are intended to drive power triacs and not meant to drive loads directly. Indeed, I just checked Fairchild's datasheet and it says so explicitly: "The optoisolator should not be used to drive a load directly. It is intended to be a trigger device only." But then Motorola, I mean On Semiconductor, tells us that, "Zero-crossing optocouplers can be used to switch inductive loads at currents less than 100 mA (Figure 24)" [p.162].

What I have in my parts bin are a number of MOC3021. Since these can pass around 100mA [p.124] continuously, with a peak current of 1000mA (pulse width of 1ms, 120 pulses per second), there shouldn't be a problem if the load does not exceed these maximums. The MOC3021 is a random-phase and not zero-crossing optoisolator but I figure if I just close my eyes, ignore the difference and wish upon a star then everything will be alright.

The load I need to switch are 24VAC mini relays which in turn will switch 220VAC loads. Measured maximum current of the relay @24volts is 46mA. Connecting a 24VAC source and a relay in series with the triac output presented no problems--turning the MOC3021's LED on and off switched the relay. I then wondered if the optoisolator could drive two relays in parallel. They switched on fine, but when I powered down the LED the relays remained on. They just wouldn't turn off.

To try and remedy this I placed a 0.1uF ceramic capacitor across the triac. That immediately got rid of the latching. I tweaked the snubber and replaced the cap with a 0.01uF and a 1Kohm 1/4W resistor. No latching problems. However, decreasing capacitance to 1nF or increasing resistance to tens of kilohms reduced snubbing to a point that latching would occur.

The value of the snubbing resistor should probably be close to the resistance of the load. Given that the coil resistance of each relay is around 180ohms, snubbing resistor should be around 91 or 100ohms.

Vexing silicon bug on the PIC12F1822

2011-07-07T02:56:00.001+08:00

Been having a problem with a firmware which uses the analog-to-digital converter (ADC) of the PIC12F1822 to read the buffered voltage output of a sensor. The circuit works for some time but then minutes or hours later goes amok. I've gone over the firmware half a dozen times and I can't find anything wrong. (That of course is no guarantee that the program has no coding errors. I may just be "blind" to the booboos I've committed.)

While testing the circuit and observing the hiccups, it looked to me--among other possibilities--that the watchdog timer (WDT) was timing out--that it wasn't being cleared and thus the MCU was being reset. Sure enough when I disabled the WDT the MCU would hang and the push button and LED would fail to respond. Something was very wrong indeed. It was then that it occurred to me to check the silicon errata sheet for this device.

When I saw item number two on the rather obscenely long list of bugs I had an "Oh shoot!" moment. According to Microchip

Under certain device operating conditions, the ADC conversion may not complete properly. When this occurs, the ADC Interrupt Flag (ADIF) does not get set, the GO/DONE bit does not get cleared and the conversion result does not get loaded into the ADRESH and ADRESL result registers.

Two workarounds are listed:

Method 1: Select the dedicated RC oscillator as the ADC conversion clock source, and perform all conversions with the device in Sleep.

Method 2: Provide a fixed delay in software to stop the A-to-D conversion manually, after all 10 bits are converted, but before the conversion would complete automatically. The conversion is stopped by clearing the GO/DONE bit in software. The GO/DONE bit must be cleared during the last ½ TAD cycle, before the conversion would have completed automatically. Refer to Figure 1 for details.

The firmware uses mikroC's built-in ADC function and checking the assembly of the compiled program it's clear that the function is polling the GO/DONE bit to determine whether conversion is finished or not. If the silicon bug is indeed being triggered then when it does strike this polling would go on ad infinitum since the bit would never change state. To find out if this ADC bug is the cause of my woes I had to write my own ADC function to implement one of the workarounds above.

Well the part about clearing the GO/DONE bit during the last ½ TAD cycle in method 2 is a great put-off. I just don't like the idea of stopping a conversion at "just the right time." Seems too risky. So I opted for putting the MCU to sleep. Sounds simple and straightforward. Here's my version of Method 1.


unsigned int ADC(int8 ch)
{
  ADCON0 = ch << 2;                    // left shift ADC channel to be read from into ADCON0
  ADCON0.ADON = 1;                     // power up ADC
  ADCON1 = 0b11110000;                 // right justified, use Frc, Vdd as positive reference voltage
  INTCON.GIE = 0;                      // global interrupt disabled
  PIR1.ADIF = 0;                       // clear ADC interrupt flag
  PIE1.ADIE = 1;                       // ADC interrupt enabled
  INTCON.PEIE = 1;                     // peripheral interrupts enabled
  ADCON0.GO = 1;                       // start ADC conversion
  asm {sleep}                          // zzzzzzzzzzzzzzz.... when ADIF = 1 MCU will wake up and will continue execution of the program
  PIR1.ADIF = 0;                       // clear ADC interrupt flag
  PIE1.ADIE = 0;                       // disable ADC interrupt
  INTCON.PEIE = 0;                     // disable peripheral interrupts
  ADCON0.ADON = 0;                     // power down ADC
  return ADRESH*256 + ADRESL;          // return the 10-bit ADC value as a 16-bit number
}

I've been testing the circuit using the above function instead of mikroC's and so far so good. WDT is enabled and so far no resets have occurred. Will do extended testing over the week to make sure the problem has been truly licked.

[Addendum: Forgot to mention that, as per the errata sheet, the ADC bug appears only on 1822's with device revision ID#6. I did check the parts (see the errata for instructions on how to do this) I have before even attempting to write the workaround and of course as luck would have it, I had been shipped the affected components. Sigh.]

Why hasn't Microchip fabricated IAs?

2011-07-04T10:23:00.001+08:00

I only use op amps which are single supply and I practically don't use any other op amp except those by Microchip because they're cheap, easy to obtain, and a good number of them have rail to rail I/O. Well, right now I need a single-supply instrumentation amplifier to clean up possible common mode noise from a sensor that'll be located many meters away from the control board. No amplification is necessary or desired. Unfortunately the only IA I have on hand is the INA126 which needs a bipolar supply (else output won't go all the way to ground) and has a minimum gain of 5.

Because the input signal is low impedance I could just use a differential amplifier. I can cobble one up using, say, a MCP6021, but that would entail the hassle of either getting precision resistors or manually matching four. It also increases the parts count. So that got me wondering why Microchip--given their wide range of op amps--hasn't taken the next step and developed instrumentation and difference amplifiers. Do they lack the capability to make these high precision components? Is the demand for these items too small? Is that market cornered by Analog Devices and Texas Instruments?

It's still on my wishlist and hopefully Microchip does get around to fabricating IAs in the near future. I'm sure they'd be more affordable than, say, the AD623.

mikroC Pro v4.60 bug

2011-07-03T22:01:00.002+08:00

Serendipitiously the mikroC Pro v5.00--successor to v4.60--was just released a couple of days ago. Because I ran into a brick wall programming the PIC12F1822 with the 4.60. The firmware compiled without a hitch for the PIC12F615 but then the compiler started going bananas when I changed the MCU to 12F1822 (had to change the MCU because it turns out I need EEPROM which unfortunately doesn't exist in the 12F615). After systematically commenting out various parts of the program to isolate what was tripping the compiler, I narrowed down the problem to a local variable that the 4.60 demanded be initialized, else it would give me a "362 Not enough RAM 'R15' P12F1822.c" error message upon compilation. Here's an example. The following will result in an error:


char  i;

void Mozza()
{
  char i;
  for (i=1; i<8; i++)  ;
}

void main()
{
  Mozza();
  while(1) ;
}

You can change for (i=1; i<8; i++) to something else, like PORTA += i; and the compiler will cough out the same error message. On the other hand, the following versions will compile properly:


char  i;

void Mozza()
{
  char i=0;    // no error if variable initialized
  for (i=1; i<8; i++)  ;
}

void main()
{
  Mozza();
  while(1) ;
}


char  i;

void Mozza()
{
  // char i;   no error if global variable is used
  for (i=1; i<8; i++)  ;
}

void main()
{
  Mozza();
  while(1) ;
}

So using a global variable or initializing the local var should've been an easy workaround. Unfortunately, when mikroC's built-in EEPROM write functions are present even these tricks fail to lick the problem.

I just installed v5.00 and they've apparently fixed this bug. The firmware (still a work in progress) has thus far compiled without the error 362 message popping up.

All-analog automatic night light circuit

2011-06-29T23:59:00.002+08:00

Some ten days ago I installed an all-linear automatic night light circuit to control the lights inside the living room. Circuit consists of three op amps--two used as voltage followers and a third as a comparator. As the schematic shows, all user adjustable controls are at the comparator--with one potentiometer to set the trip point and the other pot to adjust the width of hysteresis band.

The sensor circuit is located several meters away at a location where it can have a view of the outdoors without being blinded or fooled by indoor lights at night. The high impedance sensor and low pass filter must have a unity gain buffer (voltage follower) within millimeters/centimeters. You can't have it on the main control circuit board meters away. Trust me. I've tested this several years ago with and without a buffer and a (unshielded twisted pair) cable. The signal will be degraded and probably unusable without the follower. Notice the low pass filter includes a diode. It performs a very important and essential function. See my other automatic night light circuits for the explanation.

A 3-wire cable connects the sensor circuit to the main control circuit. According to the MCP627x op amp datasheet:

Driving large capacitive loads can cause stability problems for voltage feedback op amps. As the load capacitance increases, the feedback loop’s phase margin decreases and the closed-loop bandwidth is reduced. This produces gain peaking in the frequency response, with overshoot and ringing in the step response. A unity-gain buffer (G = +1) is the most sensitive to capacitive loads, though all gains show the same general behavior. When driving large capacitive loads with these op amps (e.g., > 100 pF when G = +1), a small series resistor at the output improves the feedback loop’s phase margin (stability) by making the output load resistive at higher frequencies. (DS21810F, 2008, p.14)

Well, we're working with essentially a DC signal and I have no idea of how much capacitance there is in the cable, but I just added R3 to be sure. The hysteresis circuit (R5, R6, R7) needs a low impedance source, thus A2 is used as a voltage follower--else R3 will foul up the resistor values for the hysteresis. For a discussion of hysteresis in single-supply op amps read this. Equations are provided.

A push-pull configuration using complementary transistors drives the relay and LEDs. A 12-volt relay is the output amplifier (and high-voltage isolator) which switches the 220VAC load. The relay is some 10 ten meters from the control circuit. Its normally open contacts are connected in parallel with the light's wall switch--so this switch has to be off for the circuit to turn the load on/off automatically. Green and red indicator LEDs provide feedback when adjusting the pots.

The shortcoming of this circuit--and for that matter all ANL circuits--is that the ambient light level at which the load is turned off must be higher than the light level at which it's switched on. In other words, incorporating a hysteresis--however small--forces the circuit to turn the load off at a brighter condition than for load switch-on.

But in some cases (probably a majority) we want the lights off at the crack of dawn--i.e., at a darker condition than when it was turned on. Someone may have already done so, but I haven't yet come up with a way of doing this using linear components/ICs. I don't even know where to begin! Using a microcontroller on the other hand seems obvious and the simplest way to implement it.

And that's what I've been doing these past two days. Because it's MCU-based the circuit itself is a no-brainer. The firmware's where the brain-racking is. I've already installed a temporary circuit in place of the above all-analog one and will be checking its performance till week's end.

Given that I'm using an MCU--and all the computing power it's got--I pared down the sensor subcircuit and eliminated the low pass filter. Filtering is now performed digitally using algorithms. Pots are gone as well. Trip point is set using a momentary contact push button. "Negative" hysteresis (as I'm calling it, at least for now) is relatively simple to implement in firmware. Testing over the next few days will actually be assessment of the robustness of the algorithms I'm using, tweaking the values used in the equations, and ferreting out bugs.

Using a photoelectric sensor to turn on hallway lights

2011-06-21T10:39:00.004+08:00

There's a hallway in one part of the house where there are no windows around. That area gets really pitch black at night. The ceiling lights are normally off to save on power. Because I have to use that corridor several times at night I have to switch the lights on. Unfortunately the switch is some 5 meters from the room I'm going in and out of, so what happens is I'd turn on the lights, enter the room, switch the lights in there, and then go back out to turn off the lights outside, then go back in again. Obviously a hassle. Worst part of it is when my hands are full with stuff. I'd have to free one hand to flip the switch in the corridor.

So ten years ago I installed a circuit that would turn the hallway lights on whenever I crossed a photocell. After about half a minute later it would automatically turn the lights off. I think it was in that year that I got hold of some Keyence photoelectric sensors that were on bargain so this was an application it was quite suited to. I was able to purchase several types, but the model I eventually used for the circuit was a Keyence PZ-51L (sorry, can't find a link in English). It's an infrared (IR) transmitter (TX) and receiver (RX) pair meant to be used in a throughbeam configuration--i.e., TX and RX are placed some distance apart and facing one another such that TX IR beam is aimed directly at RX.

The PZ-51L has an open NPN collector output (actually two, the other is for "alarm" purposes). Depending on how the "output mode control" (pink wire) of RX is connected--tied to ground or Vdd--the sensor could be made to switch the open collector NPN on when RX senses the IR beam (no object detected) or when it fails to (object is blocking the beam). In all the circuits below the PZ-51L is used in the "light-on" mode, meaning the NPN is switched on when RX detects the IR beam.

Here are some pertinent specs, schematics, and diagrams lifted off a Keyence pdf catalog (came in a CD-ROM).

I initially intended to use the sensor in a throughbeam configuration, but to simplify installation and do away with alignment problems I decided to use it retroreflectively--i.e., TX and RX are side by side facing the same direction with RX sensing the reflection of the TX IR beam. Because the intensity of the light is much weaker in retroreflective mode the detection distance is much shorter than in throughbeam mode.

The PZ-51L TX and RX were placed side by side and glued together using double-sided foam tape. The pair was then just stuck using foam tape again to the jamb in the hallway about a meter off the floor. Anyone crossing would intercept the IR beam and reflect part of it back towards RX thus triggering it. There's a "SENS" trimmer on top of RX used to control its sensitivity. This had to be set to maximum to have RX detect people crossing. Even at maximum, however, sense distance was less than a meter. Type of clothing material may have an effect on how well the person is detected.

The initial circuit I developed back in 2001 was based on an LM311 comparator. I'm not going to put up the schematic since it's close to being a most incompetent design and so don't want anyone using it. It didn't even have a voltage regulator IC. Suffice to say it used RC timing (to provide seconds of time delay and keep the lights on) and a voltage reference to let the comparator know when to switch its output. Comparator output was connected directly to a 12-volt relay--I wouldn't design something like that now, but back then I just copied from an electronics textbook which showed just that. I didn't have a flyback diode across the relay coil--yet another faulty design. The relay then switched the lights on and off. Even with all the bad design elements, however, the circuit worked. I'd probably freak out now if I hooked up an oscilloscope to it.

The next year I scrapped the circuit--leaving the PZ-51L as is--and installed something decent. It was based on the 555 timer in a monostable mode. A pull-up resistor was connected to RX's "control" NPN collector (black wire). And that collector output was tied to the 555's pin2. So whenever the NPN was switched on (object detected) output of the 555 went high for a duration determined by RC. Instead of a relay, a MOC3021 optoisolator was used to trigger a Teccor Q4004L4 triac which then switched the lights.

The following year (2003) I completely changed the circuit again, using a CD4023 triple 3-input NAND with two of them wired up a simple RS flip flop, a 555 in astable configuration to provide a 16Hz output, and a CD4040 ripple counter which was clocked by the 555. I then NANDed three counter outputs to obtain a desired time duration. I also included a sonalert buzzer which was switched on (via an NPN) by one of the counter outputs. This buzzer sounded only during the last few seconds of the countdown thus alerting the user that darkness was about to descend upon him. In 2004 I made further (and final) revisions ending up with the following circuit which I will describe in detail.

CNT pin14 count = 512
CNT pin2 count = 32
CNT pin3 count = 16

R_A = 30Kohms
R_B = 30K
C_T = 1uF tantalum
C_F = 1uF aluminum electrolytic

PS = "wallwart" DC power supply, unregulated, no load output: 16VDC
VR = LM7812 +12V 1000mA voltage regulator
P-T = Keyence PZ-51L transmitter
P-R = Keyence PZ-51L receiver
TIM = NE556 dual timer
CNT = CD4040 ripple counter
NAND = CD4023 triple 3-input NAND gate
Q_B = S9013 NPN transistor I_Cmax = 500mA, h_FE-min = 60
Q_R = S9015 PNP transistor I_Cmax = 100mA, h_FE-min = 100
D1, D2 = 1N4148 signal diode
BUZ = sonalert buzzer
OPTO = MOC3021 optoisolator with triac driver output
TRIAC = Teccor Q4004L4 triac 400V 4A
LSW = wall switch of light
L = lamps, used to be incandescent, now CFL.

all resistors are 1/4W 5% tolerance

Here's how the circuit operates. When an object reflects the infrared beam and RX detects it ights will be immediately turned on. Simultaneously the buzzer will sound for around 2 milliseconds to give an audible feedback that the system has been activated. After around 32 seconds the buzzer will sound again, softly--due to the 30K resistor in series with BUZ and D1--for about 3 seconds, after which both lights and buzzer will be turned off. If a person crosses the IR beam while the lights are already on, then the counter will be reset and will begin counting half a minute of time again as soon as the person is no longer within the detection zone. If a person remains stationary and reflects the IR beam continuously the counter will remain reset and the lights will remain on indefinitely.

TIM.a is wired in astable mode and provides a continuous 16Hz square wave for CNT clock input. Period of 555 is given by:

T = 0.693(R_A + 2R_B)C_T

where:
T = period, in seconds
R_A = resistance, in megohms
R_B = resistance, in megohms
C_T = capacitance, in mircofarads

Using a 1uF tantalum capacitor and resistors R_A = R_B = 30Kohms gives a period of 0.06237 sec, a very good approximation of 1/16 sec. By counting multiples of 16 we can thus make the counter time in seconds. (Note: These are theoretical figures. Back then I didn't have a scope nor a any meter that could measure frequency or even capacitance to determine the actual output frequency of the 555.)

NAND.s and NAND.r form a simple RS latch. Inputs to this latch must normally be high. When input goes low that particular gate's output will go high. C_F is a filter capacitor to prevent line noise from falsely triggering the latch.

When P-R is activated, its internal NPN transistor is turned on. NAND.s input is therefore brought low. If NAND.s is outputting a low it will be triggered to output a high. If NAND.s output is already high there is no change and no harm done. When NAND.s output is high lights are turned on.

Buzzer will begin sounding when CNT count reaches 512. NAND.rst output will go low when CNT reaches 560 (or around 35 seconds), triggering NAND.r to output high which then resets CNT and switches off BUZ. Simultaneously, NAND.s output will go low, turning off the lights.

The CNT outputs which are connected to NAND.rst inputs are 2¹⁰=512, 2⁶=32, and 2⁵=16, or a total of 560 counts. Because the clock is running at 16Hz, 560 counts translates into 560 / 16 = 35 sec. When count reaches 512, pin 14 of CNT goes high. This turns on BUZ. Because CNT has limited drive capability and since volume of BUZ doesn't need to be high for this alert a 30K resistor is placed in series. Three seconds later, when count reaches 560, NAND.rst output goes low. Pins 12 and 13 of NAND.r are pulled low which causes output of NAND.r to go high and output of NAND.s goes low. CNT is reset and remains reset. NAND.rst output then goes high again. The circuit then is at its beginning state once more.

Because of the particular outputs of CNT used, the buzzer will be on for the last 3 seconds of the count. This will provide an audible signal when the lights (load) are about to go out. If the buzzer needs to be on for a second or two longer then CNT output 2⁷=64 can be used instead. D1 and D2 allow BUZ to be used independently by CNT and TIM.b.

Whenever P-R is activated--even if L is already on--CNT is reset to zero, thus extending the time L is on by another cycle (~35sec). This retriggerability is achieved by a transistor inverter (Q_R) and a voltage divider (R_r1 and R_r2). When voltage across R_r1 is high CNT reset pin11 will be high (>50% system voltage) thus causing CNT to reset. The values of R_r1 and R_r2 were chosen so that current sinking/sourcing by NAND.r is minimal and so that proper voltages will be present to reset CNT. When P-R is activated Q_R is turned on. Voltage across R_r1 goes from low to high. This then causes CNT to be reset. If a person stands in front of P-R, CNT will be continuously in reset mode, thus preventing any count. L will therefore be on indefinitely. Here's a table to make all this more comprehensible.

When P-R is activated C_P begins charging. At this instant TIM.b pin8 goes low which then starts TIM.b. C_P charges very rapidly and after it has charged voltage across it stays high until P-R is activated again. TIM.b output goes high for just a couple of milliseconds (given R_T2 = 220K and C_T2 = 0.01uF, theoretical pulse width is 1.1RC = 2.4ms), producing a brief clicking sound. The sound serves as a nonobstrusive indication that P-R has been activated (or reactivated if lights are already on). To make certain that sound does not last longer than this very brief period, triggering of TIM.b makes use of capacitor coupling. Given C_P = 0.001uF and R_P = 390K the negative trigger pulse is around 0.4ms--much shorter (as it should be) than the monostable output pulse. No negative pulse will occur again unless P-R output goes high then low again. Thus, even if a person were to stand in front of P-T/ P-R indefinitely, BUZ will still sound for only 2ms. He has to move away and then back again to re-trigger TIM.b.

The load is switched by a power triac which in turn is triggered by a triac output optoisolator. No snubbing circuit is necessary. OPTO needs 15mA to ensure proper turn-on of its LED. Q_B has a minimum current gain of 60 and a V_BE of 0.7V. Maximum base resistor should therfore be around 45K. A 20K resistor was chosen to ensure more than enough collector current will be available. The actual current delivered to the LED of OPTO is determined by the current limiting resistor in series with the load. In this case the 470 ohm provides about 21mA.

Except for the AC adapter that's plugged into the outlet and the PZ-51L, the entire circuit is in a small box that's just glued to the concrete wall. The thing is, just a few days ago I needed to add a circuit--for a totally different application--in that box, one that will be using the same power supply. Trouble was there wasn't enough space. So even as I didn't wish to retire the above circuit I was forced to.

Given what the above circuit does--how simple the requirements are--a single "primitive" microcontroller suffices to replace all the ICs and practically all the discretes, thus freeing up more than enough space. Thus the latest version of the photoelectric sensor circuit was born.

MCU is a Microchip PIC10F202. Internal weak pull-up is enabled so P-R NPN collector can be tied to the MCU's pin (configured in firmware as input of course) without an external pull-up resistor. The transistor at output GP2 is a 2N7000 MOSFET.

Operation is similar to the preceding circuit. In fact I tried to mimic everything about it. When sensor first detects an object a click is sounded, the load is turned on, and countdown begins. The "click" is simply to alert user that a (re)detection has occurred and that countdown has been started/reset. If object remains within the detection zone no further clicks are sounded and countdown will not commence until object has left the zone. Once countdown has commenced and before it has ended and an object again crosses the zone, countdown is canceled and reset and a click is sounded. Three seconds before countdown ends a series of clicks are sounded until countdown ends. The three-second series of clicks warns the user of the pending lights switch-off. When countdown ends, buzzer and lights are switched off.

The only noticeable difference to the user between this and the previous circuit is the replacement of the continuous buzzer sound with a series of clicks during the last three seconds of countdown. The change is due to the fact that I needed to attenuate the buzzer volume. Placing a 10K resistor in series with BUZ lowered the volume of the last-three-second alert alright. But it also made the clicks (when object is first detected) barely audible. I toyed around with toggling BUZ every timer0 tick--on for one tick and off during the next, effectively doing a pulse width modulation at 50Hz with a 50% duty cycle. Didn't sound good. Kind of grating actually. So after a little experimentation I decided on a series of 10ms clicks spaced 200ms apart (5% duty cycle). This by the way is the same audible alert pattern I used in a motion detection circuit.

I won't go into the details of the firmware since it's short and relatively simple. There should be enough comments therein to make the whole thing easy to comprehend.

/*

Photoelectric timed switch
June 19-20 2011
Edwardson Tan

processor = PIC10F202
compiler = Hi-Tech C Lite v9.80

*/


#include 

__CONFIG (WDTEN & UNPROTECT & MCLRDIS);          // config if using Hi-Tech C v9.80


// ========================================================================================================
// values for the following defines can be modified by user to suit the application
#define  loadonms            30000               // how long lights will be on, in milliseconds. this is the countdown period
#define  alertms             3000                // how long last-few-seconds alert will sound right before load is switched off, in milliseconds
#define  clickintervalms     200                 // duration between clicks for last-few-seconds alert, in milliseconds 
// ========================================================================================================

#define  t0end               39                  // end value of timer0 to signal "overflow". used in conditional statement "if (TMR0 == t0end)"
#define  t0tick              10                  // rounded-off timer0 tick in milliseconds = t0end * prescale * 1e-6sec * 1000 = (39)(256)/(1000) = 9.984ms 
#define  timetilloadoff      loadonms/t0tick                         // number of t0ticks before lights are switched off. this is the countdown period
#define  timetilbeep         timetilloadoff - alertms/t0tick         // number of t0ticks before 3-second beep starts sounding to alert user that lights are about to be turned off 
#define  clickinterval       clickintervalms/t0tick                  // duration of last-few-seconds alert in terms of number of t0ticks 

#define  sw                  GP0                 // open collector output of Keyence PZ-51L IR receiver NPN
#define  buz                 GP1                 // sonalert buzzer 1" diameter
#define  load                GP2                 // 2N7000 switches MOC3021 which switches Q4004L4 triac which switches load

#define  int1                bit
#define  int8                unsigned char
#define  int16               unsigned int

#define  on                  1
#define  off                 0

#define  yes                 1
#define  no                  0


// ========================================================================================================
 
int1     reset;              // when writing to this flag: 1 = during current t0 tick sw is high (no object in detection zone);  0 = during current t0tick sw is low (object in detection zone)
                             // when reading this flag: 1 = during the last t0 tick, sw was high (no object detected);  0 = during the last t0 tick sw was low (object was in detection zone)
int1     countdown;          // 1 = countdown to load switch-off is underway; 0 = countdown not ongoing
int8     COUNT;              // records how many t0 ticks from the last beep. used only during last-few-seconds alert. this variable cleared whenever sw is low
int16    ELAPSEDTIME;        // records how many t0 ticks have elapsed

// ========================================================================================================

void main()
{
  TRIS = 0x1;
  GPIO = off;
  OPTION = 0b10000111;                 // wake up on change off, weak pull ups on, timer0 prescaler = 1:256 
  TMR0 = 0;
  reset = off;
  countdown = off;
  
  while(1)
  {
    if (TMR0 >= t0end)
    {
      TMR0 = 0;
      CLRWDT();                        // according to datasheet WDT nomimal timeout is 18ms
      buz = off;                       // buzzer is turned off every timer0 tick. Thus all beeps last only a maximum of one timer0 tick. Each beep will sound more like a click than a beep

      if (sw == hi)                    // sw is high when no presence is detected 
      {
        reset = yes;
        if (countdown)
        {
          ++ELAPSEDTIME;
          if (ELAPSEDTIME >= timetilbeep)
          {
            if (++COUNT >= clickinterval)
            {
              buz = on;                // last-few-seconds alert before light is turned off. consists of 10ms beeps every clickinterval   
              COUNT = 0;
            }
          }
          if (ELAPSEDTIME >= timetilloadoff)     // countdown ended so turned off buzzer, load, and clear countdown flag 
          {
            buz = off;
            load = off;
            countdown = off;
          }      
        } // if (countdown)
      } // if (sw == hi)
      else                             // sw is low when object is in detection zone  
      {
        if (reset)                     // if NPN collector was high during the previous checks then turn on buzzer now since object has been detected. buzzer will be turned off during the next timer0 tick. Therefore this beep will last only for a max of 10ms, thus sounding more like a click than a beep. if NPN collector had been low then it means object has not moved out of the field of detection, so do not issue a click
          buz = on;
        load = on;
        reset = off;  
        countdown = on;
        ELAPSEDTIME = 0;
        COUNT = 0; 
      } // if sw == lo
    } // if (TMR0 >= t0end)      
  } // while(1)
} // void main()

First VIWC test

2011-06-17T01:20:00.001+08:00

Been waiting for the heavens to start shedding tears. It just did. Caught the tail end of a short pour. Quickly got into the car and parked it outdoors. Fortunately I had some 10min of drizzle. Turned the VIWC on. Waited for the tiny raindrops to accumulate ... waited... waited ... and finally had the wiper sweep the windshield while the view was still relatively unobstructed. Stopwatch shows the time interval was 1min 18s. During the latter half of that test, I held down the button to reset the circuit and next interval was 1:43.

Well with such long periods, this completely trashes the potentiometer VIWC with its 32 or 64s max time interval. Of course we can always modify the firmware to use 7 or even 8 bits of the ADC output giving us 128 or 256 seconds max, but then adjusting the pot would be a most tricky thing. A multiturn pot might be required. But using that is going to be awkward if not a pain in the neck. In conjunction with changing the number of ADC bits (or not changing them), we could also increase the increment/step from 1 to 2s or even more seconds.

This is another distinct advantage of the push-button, elapsed-time-recording VIWC. The time resolution can be programmed to be as coarse or fine as required/desired. In this case we've set it to 100ms. To alter that we need only change the timer1 tick. If we're decreasing the tick to say 10ms (but who needs that kind of resolution on a wiper?) we'd want to make ELAPSEDTIME a 24- or 32-bit integer to be able to measure the equivalent amount of time.

The test evinced the superiority of this type of VIWC. The driver need not focus on adjusting the time interval--he need only press the button when the windshield gets too cluttered. The only problem I had was that the dry windshield initially had a thin layer of dust on it which only became apparent after the first wiper wipe smeared the dust-turned-mud across the glass. I didn't but I could've turned off the VIWC and then pulled the wiper stalk to activate the front mist + wiper, and then switch back to VIWC. Or alternately, without turning off the VIWC, I could've pulled the stalk--and since the Innova's wiper module is deactivated--it would've sprayed water without the wiper action. I could then press button PB such that it sets the time interval to its minimum of 2sec, and then after the windshield had been cleaned, I could hold down PB to go into reset mode and set the proper wipe time interval. Sounds complicated. So there's probably room for improvement in this area.

The real test of this circuit will come when I actually get to drive in the rain.

Variable intermittent wiper control - Part 5

2011-06-14T01:39:00.002+08:00

Variable intermittent wiper control - Part 4

As broached in Part 4, I'm gaga over a new way (at least to me) of implementing a VIWC. It involves letting the circuit record time elapsed between wipes and button presses to set the time interval for windhshield wipes. As stated this can be accomplished using just one momentary contact switch as user input.

I've already modified the "old" breadboarded potentiometer-based VIWC and bench-tested it to be working. Circuitwise, the only difference between the new more user-friendly VIWC and the former is the replacement of the pot with a momentary contact switch, the addition of a Sonalert buzzer to provide user feedback, and the use of a different MCU--the PIC12F615. The interface with the Innova's wiper module remains unchanged.

I've dumped the 10F222 and chosen a midrange PIC since I'd like to have interrupts to ease my code-writing job and so as to have access to more timers. I always want more timers!

There's really nothing much else to say about the electronics so let's talk about what this improved VIWC does and discuss the firmware.

What the VIWC Does:

Because it's the bedrock on which the intermittent control rests let's first define and discuss the two modes the wiper circuit can be in:

Reset mode -- Entered into by pressing button PB for at least half a second. Upon entering reset mode a short audible alert will sound. In this mode circuit simply records time elapsed since the last wipe. No wipe will be performed until user presses PB again (momentarily or otherwise).
Wipe mode -- Entered into by pressing PB for less than half a second. Upon pressing, a single windshield wipe will be performed and the elapsed time since the last wipe becomes the time interval for all succeeding wipes. The circuit will now automatically sweep the windshield using the recorded time interval until that time PB is pressed again.

Upon power-up a wipe is performed and circuit is put in reset mode. An audible alert (40ms beep followed by 40ms silence followed by a 40ms beep) is issued to inform the driver of this status. No further wipes will be performed until the user presses PB (for less than 0.5s to enter wipe mode or greater than 0.5s to enter reset mode).

When the user presses PB for <0.5s the circuit enters wipe mode. A wipe is immediately performed. The time interval between the last and current wipe is recorded and used as the interval for all succeeding wipes which are automatically performed until that time PB is pressed again.

If the next button press is <0.5s then as before a wipe is immediately performed and the time interval between the last and current wipe is recorded and used as the interval for all succeeding wipes. This implies that momentary button presses (<0.5s) can be used to shorten wipe time intervals but not lengthen them. To do that reset mode is necessary to "teach" the circuit the desired longer time interval.

If the user holds PB down for at least 0.5s the circuit enters reset mode. An audible alert sounds and the circuit will keep recording the time elapsed since the last wipe while waiting for a button press. No further wipes will be performed until PB is pressed.

The following example should make the operation crystal clear.

It's drizzling lightly so the driver switches on the VIWC. Audible alert sounds to inform the driver that reset mode is active. Wiper sweeps the windshield once. After 13 seconds the view through the windshield becomes unduly hindered by the amount of raindrops. The driver presses button PB for a fraction of second. A wipe action is immediately performed. Now every 13 seconds thereafter the windshield is wiped.

Some time later the drizzle weakens, requiring wipe interval to be increased. So the user holds the button down for over half a second. A wipe is performed immediately upon pressing (wipe mode is entered). Half a second after button is pressed the audible alert sounds signalling that reset mode is activated. Some 28 seconds later the driver needs the windshield swept clean. So s/he presses PB momentarily. A wipe is performed and the wipe time interval is set to 28 seconds. The circuit then automatically wipes the windshield every 28 seconds thereafter.

After several minutes the drizzle begins to intensify. After 17 seconds from the last wipe user pushes PB momentarily to clean the windshield. Wiper switches on and time interval is now set to 17 seconds. A couple more minutes pass and the rain intensifies further. 5 seconds after the last wipe the user needs the windshield cleared and so presses button momentarily. Wiper immediately switches on. Circuit will now use a time interval of 5 seconds for succeeding wipes.

In this example the amount of time is explicitly stated only so that circuit operation can be succinctly explained and clearly understood. Needless to say the driver does not count or keep track of the number of seconds from the last wipe before he presses the button.

Firmware Details

All three timers of the 12F615 are used. Nominal timer tick periods given their respective initialized parameters are as follows:

timer0 = 8ms
timer1 = 100ms
timer2 = 50ms

Timer0 tick determines when program execution in main() occurs. Tick of 8ms was chosen for switch debouncing purposes. This is sufficient time to finish functions DebounceSwitch() and ModeCheck().

Timer1 is always on and used to measure elapsed time between wipes. Timer1 interrupt is always enabled.

Timer2 is turned on when a wipe is performed and turned off when wipe is compeleted. It is dedicated to determining how long the wiper motor will be on. Timer2 interrupt is always enabled.

Measurement of wipe time interval: Timer 1 is used to measure wipe time interval. Timer1's 16-bit register and prescaler as well as the 16-bit integer (ELAPSEDTIME) used to record elapsed time are all reset zero whenever wiper is turned on. Therefore, elapsed time (and therefore wipe time interval) is measured from the instant wiper is turned on to the time it is turned on again. The user can set the time interval by pressing the button at two different points in time. However, if measured time between button presses is less than a minimum amount (2 seconds), then firmware will set time interval = 2 seconds

Button is debounced by taking readings every timer0 tick. The instantaneous value is shifted into the LSB of 8-bit register PB.val. The oldest reading is discarded. Switch is deemed not bouncing if the last 8 readings (8 bits) are high or low (PB.val = 0xFF or 0x00). The voltage level of the switch is deemed to be high if all 8 are high and low if all 8 bits are low. When the voltage level changes--high to low or low to high--this is taken as a falling or rising edge.

The reset mode audible alert takes around 120ms to complete and thus temporarily breaks the neat timer0 tick cadence. During this time PB is not read and debounced.

If PB is pressed within 1.5s from the moment wiper was switched on then no wipe action occurs and timer1 and elapsed time counter are not reset. In other words, any and all falling edges detected within that 1.5s period (constant deadtime) are ignored. However, the button hold down time is still monitored and if it exceeds resetmodetime then reset mode is entered.

The various times related to the wiper being turned on are:
Wiper cycle time (measured with stalk switched to INT) = ~1.3s
Wiper on time (determined by constant wipertrigtime) = 1s
PB press dead time (determined by constant deadtime) = 1.5s
Mininum wipe time interval (determined by constant mininterval) = 2s

The relationship between them is wipertrigtime < wiper cycle time < deadtime <= mininterval. The following illustration says it all.

wipertrigtime must of course be < wiper cycle time so that the wiper parks properly. deadtime has to be > wiper cycle time in order that the wiper isn't retriggered before it has parked. And naturally mininterval should be at least equal to deadtime. It doesn't make sense to have it less than deadtime.

Holding down PB for an extended period will merely keep the circuit in reset mode. And the audible alert will keep repeating. It does not reset the elapsed time counter. That only happens if wipe action occurs. And with respect to PB that happens only during a falling edge detect (unless that falling edge occurs within the PB dead time). So the user always knows when elapsed time measurement begins and ends just by noting when the wiper blades move.

/*

Variable Intermittent Wiper Circuit that Learns from User Input
for the Toyota Innova

June 2011
Edwardson Tan

processor = PIC12F615
compiler = mikroC Pro v4.60

*/


#define  buzzer              GPIO.f4             // sonalert buzzer
#define  wiper               GPIO.f5             // 2N7000 switches relay which switches wiper low speed
#define  pb                  GPIO.f2             // momentary contact switch

#define  tris_pb             TRISIO.f2           // used to set pb pin as input
#define  wpu_pb              WPU.f2              // used to enable weak pull up for pb

#define  t0_init_val         256 - 250           // value loaded into TMR0 every time it overflows
#define  t0tick              8                   // timer0 tick time in milliseconds = [(256 - t0_init_val) * prescale / 1MHz] * 1000ms

#define  t1h_init_val        256 - 195           // value loaded into TMR1H every time it rolls over to zero for timer1 to count 0.25sec at a prescale = 1:8 and clock of 4MHz
#define  t1tick              100                 // timer1 tick time in milliseconds = [(256 - t1_init_val) * 256 * prescale / 1MHz] * 1000ms

#define  t2tick              50                  // timer2 tick time in milliseconds = [PR2 * prescale * postscale / 1MHz] * 1000ms

#define  resetmodetime       500/t0tick          // mininum amount of time pb is held down before reset mode is entered. time in terms of timer0 ticks
#define  wipertrigtime       1000/t2tick         // amount of time wiper is turned on. time is in terms of timer2 ticks
#define  deadtime            1500/t1tick         // mininum elapsed time before a button press will trigger a wipe. time is in terms of timer1 ticks
#define  mininterval         2000/t1tick         // mininum time interval between wipes. time is in terms of timer1 ticks

#define  mode                FEN.f0              // 0 = wipe mode,  1 = reset mode
#define  wipe                0
#define  reset               1

#define  rising              1                   // rising edge detected. used by PB.edge
#define  released            1                   // falling edge detected. used by PB.edge
#define  falling             2                   // falling edge detected. used by PB.edge
#define  pressed             2                   // rising edge detected. used by PB.edge
#define  none                0                   // no edge. used by PB.edge

#define  int8                unsigned char
#define  int16               unsigned int
#define  int32               unsigned long

#define  on                  1
#define  off                 0

#define  yes                 1
#define  no                  0

#define  input               1         // for TRISx
#define  output              0         // for TRISx

#define  analog              1         // for ANSELx
#define  digital             0         // for ANSELx

#define  hi                  1         // switch level high
#define  lo                  0         // switch level low

#define  all_bits_hi         0xFF      // for setting an 8-bit register to 255
#define  all_bits_lo         0         // for setting an 8-bit register to 0


// ==================================================================================================================
//       Global Variables
// ==================================================================================================================

struct
{
  val : 8;                             // last eight readings push button. if 0x0 then level is lo, if it is = all_bits_hi then level is hi, any other value means switch is bouncing
  level : 1;                           // level of push button when not bouncing (hi = 1, lo = 0)
  edge : 2;                            // 0 = no edge detect, 1 = rising edge, 2 = falling edge; 3 = Not Used / Undefined for now
}
PB;

int8    PBHELDDOWN;                    // number of timer0 overflows pb has been held down (ie. how long PB.level has been low)
int16   ELAPSEDTIME;                   // elapsed time since the last wipe, in terms of timer1 ticks
int16   WIPEINTERVAL;                  // user selected time interval between wipes, in terms of timer1 ticks
int8    T2COUNTER = 0;                 // stores number of timer2 interrupts that have occured. for use with wiper on time
int8    FEN = 0;                       // Flag and ENable and status bits register

// ==================================================================================================================
//       Functions
// ==================================================================================================================

// 1 centisecond = 10 milliseconds = 0.01sec
void DelayCentisec(int8 csec)
{
  int8 i;
  for (i=1; i<=csec; i++)
  {
    Delay_ms(10);
    asm{clrwdt}                        // WDT timeout = 18ms. Therefore it must be cleared here
  }
}

// note: this routine takes over a hundred milliseconds to execute, obviously! it will not finish within the timer0 tick of 8ms
void BeepReset()
{
  buzzer = on;
  DelayCentisec(4);
  buzzer = off;
  DelayCentisec(4);
  buzzer = on;
  DelayCentisec(4);
  buzzer = off;
}

// wiper is turned on
// timer2 is turned on
// timer1 registers and prescaler and 16-bit variable that records elapsed time since last wipe are all reset to zero
// note: wiper will be turned off in the ISR
void Wipe()
{
  wiper = on;
  T2CON.TMR2ON = on;
  TMR1L = 0;
  TMR1H = t1h_init_val;
  ELAPSEDTIME = 0;
}

void InitRegisters()
{
  // I/O pins
  // all are output except for pb, weak pull enabled for pb, all I/Os are digital, clear output pins
  GPIO = 0;
  ANSEL = digital;
  TRISIO = output;
  tris_pb = input;
  wpu_pb = on;

  // timer0 registers
  // given 4MHz clock, prescale = 1:32, TMR0 init val = 6
  // timer0 tick = (256 - 6)(32)(1us) = 8.00ms
  // TMR0 doesn't need to be initialized to any value since the first wipe action will take one second (firmware waits until this is wipe is over) and by then T0IF will be set whatever TMR0 initial value was
  OPTION_REG = 0b100;                  // global weak pull ups on, prescaler assigned to timer0, prescale = 1:32

  // timer1 registers
  // given 4MHz clock, prescale = 1:2, TMR1H init val = 61
  // timer1 tick = (256 - 61)(256)(2)(1us) = 99.84ms
  // upon power up timer1 runs continuously; it is never stopped, but TMR1L and TMR1H are reinitialized upon button press
  T1CON = 0b010001;                    // prescale = 1:2, timer1 source = internal clock, timer1 on
  TMR1L = 0;
  PIE1.TMR1IE = on;

  // timer2 registers
  // given 4MHz clock, prescale = 1:16, postscale = 1:16, PR2 = 195
  // timer2 tick = (195)(16)(16)(1us) = 49.92ms
  // timer2 dedicated to
  T2CON = 0b1111011;                   // postscale = 1:16, timer2 off, prescale = 1:16
  PR2 = 195;                           // when timer2 running TMR2 will increment until it matches PR2 and then TMR2 will be reset
  TMR2 = 0;
  PIE1.TMR2IE = on;

  // initialize to no-button-press condition
  PB.val = all_bits_hi;
  PB.level = hi;
  PB.edge = none;
  
  mode = reset;                        // circuit starts up in reset mode, i.e., wiper will sweep windshield once upon power up and then wait for user to trigger wiper to lock in wipe time interval
  WIPEINTERVAL = mininterval;

  INTCON.GIE = on;
  INTCON.PEIE = on;
}

// The following debounce and edge and level detect routine is performed every timer0 tick
void DebounceSwitch()
{
  // shift all bits to the left
  // if switch reading is hi then PB.val bit0 gets set
  PB.val <<= 1;
  if (pb)
    ++PB.val;

  // if pb has been pressed then start counting how long it is kept pressed
  // a key is said to be pressed when level is lo
  // if level is high then reset counter
  if (!PB.level)
    ++PBHELDDOWN;
  else
    PBHELDDOWN = 0;

  // assume no edge detected
  PB.edge = none;
  
  // if level is lo and all bits of PB.val are now hi then
  // a rising edge has been detected
  // switch is considered just released when rising edge is detected
  // switch level is now hi
  if ((!PB.level) && (PB.val == all_bits_hi))
  {
    PB.level = hi;
    PB.edge = rising;
  }

  // if level is hi and all bits of PB.val are now low then
  // a falling edge has been detected
  // switch is considered just pressed when falling edge is detected
  // switch level is now lo
  if ((PB.level) && (PB.val == 0))
  {
    PB.level = lo;
    PB.edge = falling;
  }
} // void DebounceSwitch()


// This function will check if pb has been pressed
// If pressed then wipe action will be issued and wipe mode is entered
// However, button press--falling edge dected--is ignored if it occurs less than deadtime from the last wipe
// if button is held down > for a time greater than resetmodetime then reset mode is entered.
// note: ELAPSEDTIME is reset to zero in the function Wipe()
void ModeCheck()
{
  if (PB.edge == falling && ELAPSEDTIME >= deadtime)
  {
    WIPEINTERVAL = ELAPSEDTIME;
    if (WIPEINTERVAL < mininterval)
      WIPEINTERVAL = mininterval;
    mode = wipe;
    Wipe();
  }
  else if (PBHELDDOWN >= resetmodetime)
  {
    mode = reset;
    PBHELDDOWN = 0;
    BeepReset();
  }
}

void interrupt()
{
  if (PIR1.TMR1IF)
  {
    TMR1H = t1h_init_val;
    PIR1.TMR1IF = off;
    ++ELAPSEDTIME;
    if ((mode == wipe) && (ELAPSEDTIME >= WIPEINTERVAL))    // if time interval has already been entered by user, then wipe action will automatically be performed after every time interval
      Wipe();
  } // if (PIR1.TMR1IF)
  
  if (PIR1.TMR2IF)
  {
    PIR1.TMR2IF = 0;
    if (++T2COUNTER >= wipertrigtime)
    {
      wiper = off;
      T2CON.TMR2ON = off;
      T2COUNTER = 0;
      TMR2 = 0;
    }
  } // if (PIR1.TMR2IF)
} // void interrupt()


// ==================================================================================================================
//       main
// ==================================================================================================================

void main()
{
  InitRegisters();
  Wipe();
  BeepReset();
  // while(wiper);              // wait till wipe has finished before proceeding, so that any pb press will have no effect
  
  while(1)
  {
    if (INTCON.T0IF)
    {
      asm{clrwdt}
      INTCON.T0IF = off;
      TMR0 = t0_init_val;
      DebounceSwitch();
      ModeCheck();
    } // if (INTCON.T0IF)
  } // while(1)
} // void main()

Testing the VIWC

To see if the circuit and firmware are really working as expected I hooked up the Saleae logic analyzer to the PIC12F615's GP2 pin (PB) and GP5 (Q1 gate). In the text Q1 was driving only an LED not REL2. A really small tactile switch was used for PB. Circuit was powered via PICkit2 set to 5.0V. In all of the screenshots below channel 6 is hooked up to GP5 and channel 7 to GP2.

I wish I could've set the sampling rate to 1MHz and higher but my decade-old computer only has USB1.0 which limits the Saleae to 500kHz. Not infrequently it can't even maintain that and I've experienced the rate going down to 200kHz.

In the first screen capture below the green vertical cursors 1 and 2 have been positioned at the falling edge of GP2 and rising edge of GP5. You can see that |T1 - T2| = 62.6ms. This delay between PB press and wiper switch on is as expected due to the switch debouncing routine which requires all 8 bits of PB.val to be either high or low before a level change is said to have occurred. Those eight bits take eight timer0 ticks. At 8ms, we would expect a nominal 64ms from the actual falling edge of GP2 to the moment wiper is switched on.

Take a look at the amount of time GP5 is high. The pulse width is almost exactly 1 second as we have specified. Note the second falling edge of GP2--PB was pressed again momentarily--causing a wipe action to occur and setting the wipe interval = 4 seconds (read the item labeled "Period")

Zooming in and measuring how long PB was pressed we see that the pulse width is almost 120ms.

The shot below shows the wipe interval of succeeding wipes is still 4seconds (3.98s in the instance below). Keep in mind that timer1 tick = 100ms so that's the tolerance value.

I intentionally waited for the LED to light and then pressed PB rapidly. Remember we specified deadtime = 1.5s so a falling edge on or after an elapsed time of 1.5sec after GP5 goes high should be recognized. Well apparently this did not happen as the shot below shows. Wiper was turned on only after some 1.92s. Is the firmware buggy?

After closer inspection it turns out that I was pressing PB at such a rate that some presses (level low) and nonpresses (level high) were shorter than the required debouncing period of 64ms. Take a look at T1-T2 where cursor 2 is at a falling edge of PB. It's 1.7s. Wiper ought to have been turned on some 64ms after this edge. But then look at the pulse width (rising edge to falling edge). The pulse was high for only 49ms. Because not all bits were high the firmware took this as indicative of switch contacts that are bouncing and thus no valid level change (edge detect) was recognized.

The next button release and button press, on the other hand, met the minimum debouncing requirements: high time was 87ms while low time = 203ms - 87ms = 116ms. Hence wiper was switched on after the valid falling edge was recognized.

Recall that the measured wipe interval was 1.92s. This is less than the minimum of 2s we specified. Thus for the succeeding wipes, firmware set the wipe interval to 2s, with actual period measured to be 1.99s.

The next screenshots are from a different set of data capture. In this first image time between GP2 falling edge and GP5 rising edge is 60ms. The wipe interval is a mere 1.52ms--this violates the minimum and so we should see it changed to 2s in the next wipe (if no button presses occur within that interval).

I moved the cursors to measure the the elapsed time from the moment wiper was turned on to the moment when the falling edge which triggers the wiper occurs. T1-T2 = 1.46s. Doesn't this violate the 1.5s deadtime requirement? No it doesn't. Remember that the debouncing routine needs 64ms to "see" an actual falling edge. So the nominal dead time between wiper turn on and actual (in contrast to firmware determined) falling edge = 1.5s - 64ms = ~1.44s

As expected in the very next wipe the time interval has been adjusted to conform to the minimum of 2s. Actual measured period = 1.99s.

Here I held down PB while GP5 was still high (LED still on). Pulse width (time PB was held down) = 1.05s. Having pressed PB during the dead time, no wipe occurred. But because PB was pressed for >0.5s, reset mode became active--as can be seen no wipe occurred after 2s (the wipe time interval before the reset). Wiper turns on again only after PB was pressed again.

These last two shots show that elapsed time / wipe interval is measured from the moment wiper is switched on (GP5 rising edge) and not when PB is pressed. As you can see the period is 4.18s in both cases even if PB was pressed (to enter reset mode) almost a second after wiper was turned on.

So there you have it. A more or less full documentation of what for me is an exciting implementation of a VIWC. I'm not rushing to fabricate a PCB for it though. I feel there's a need to have an extended pilot test to get a feel for how well it works and to see if there's anything that needs to modified, tweaked, revised. So I'm stashing the prototype and relays and the whole tangle of wires under the dashboard and installing temporary switches on the lower part of the dash for now. And obviously I'll be doing daily rain dances for the next two weeks.

[June 14 edit: I commented out the line "while(wiper);" in main(). That line is unnecessary]

[June 16 edit: Forgot to mention the maximum wipe time interval possible. Given timer1 tick = 0.1s and ELAPSEDTIME being a 16--bit variable, the maximum time the variable can measure before overflowing back to zero = 65,535 * 0.1s = 6553.5s or ~109 minutes. I'm sure! that's sufficient for lightest of drizzles.]

Variable intermittent wiper control - Part 4

2011-06-12T00:58:00.016+08:00

Variable intermittent wiper control - Part 3

It seems I have a couple more things to say about the circuit, matters that are rather important. So this entry will be about tying up loose ends, and then some.

1. When the VIWC is powered, switching the stalk to any of the settings which turns on the front windshield wiper (INT, LO, HI, momentary wipe) will not perform any operation. This is because the wiper motor needs power via W-VDD and W-PP and the module's electronics needs +12V from W-VDD. The only setting that will work--partly at least--is when the spring-loaded stalk is pulled toward the driver. This is the front mist + wiper setting. When the stalk is pulled, the front mist motor will operate and spray water, but the wiper will be nonoperational.

On the other hand, the rear wiper and rear mist are fully functional even with VIWC on. The rotary switch (knob) on the stalk that controls these functions operates normally. This is of course desirable. We'd want to be able to operate the rear wiper and washer regardless of whether the VIWC is on or off.

2. If we want longer time intervals than the 32 seconds we can derive a 6-bit ADC value instead of a 5-bit number. That would give us a maximum of 64 seconds given our algorithm.

We can also vary the step function, i.e., the increment. For instance we can convert the ADC value from 8 to 5 bits and then add 2:

return ((ADRES >> 3) + 2);

The range of time intervals will then be 2, 4 ,6 ... 64 seconds.

For fractional values, say increments of 1.5 seconds we can do the following:

TIME = (ADC())*20 + 10;

10 timer ticks = half a second, so the above code will add 0.5sec to the increment value.

3. I used the Saleae Logic to measure the wipe time interval for a few potentiometer settings. Images show below 1, 16, and 32 second intervals. Look at the value for the item marked"Width" for the actual time intervals for the particular chip I used. Probe was connected to 10F222's GP2 pin.

4. Just as I finished writing Part 3 I stumbled upon a forum discussing a most creative and elegant type of variable intermittent wiper. The circuit learns how long the time interval between wipes by monitoring when the user flips a couple of switches.

This wiper delay timer "learns" the wiper interval in the following way: It starts drizzling, so you flick the wipers once. It keeps drizzling so, when the screen is in need of another wipe, you flick it onto intermittent. The wiper delay timer sets itself to the time interval between your initial "flick" of the wipers and when you switched it to intermittent, and carries on using that interval thereafter.

This is such a great and simple idea. And it's more user-friendly than continually tweaking a pot (while driving!) to get the timing right. I had one of those eye-rolling "Why didn't I think of that" moment.

After mulling over the switch requirements, the light bulb flashed, and I figured that for our version of this type of control one momentary contact button would suffice. By holding holding the button for about a second we can inform the MCU that we want to enter time interval record mode, i.e., the circuit will wait for us to press the button again (for just a fraction of second) to lock in the time interval we desire. Thereafter the circuit will use that time period to sweep the windshield. Thereafter should we press the button again for less than second the MCU will shorten the wipe interval time accordingly. Pressing the button for <1sec can't lengthen the time interval, only shorten it. Thus we need to enter record mode which can be done so at anytime by, as before, holding down the key for at least a second.

Looks like the potentiometer-based VIWC has already been obsoleted and shelved even before I've designed a board for it. Which is just as well since I now don't have to expend so many hours on PCB design and fabrication and assembly of a circuit that I probably won't be installing anyway.

In Part 5 I will have a full discussion of this new type of VIWC. Schematic and firmware will be provided and discussed.

Variable intermittent wiper control - Part 3

2011-06-10T01:51:00.001+08:00

Variable intermittent wiper control - Part 2

Rather than use a 555 for the variable intermittent wiper circuit (VIWC) as we saw in Part 1 I employed a microcontroller instead for the Innova. An MCU's timing accuracy is far better than the 555 and is far more powerful and flexible and requires less discrete components.

I chose a baseline PIC with analog to digital converter (ADC) instead of a midrange PIC because I need only two pins and both Flash and RAM requirements are minimal. What I have on hand right now is the PIC10F222, but the 10F220 just might suffice depending on the optimization level available on the compiler--the Hi -Tech C freebie version I use throws up obscenely long codes and probably gobbles up RAM as well.

Given the wiper module's electronics it is necessary to electrically disconnect it from the VIWC to prevent any conflicts and possible shorts. Through tests I've determined that the module's electronics is powered via W-VDD. So disconnecting the circuit from this net will prevent it from being powered up. However, we will be using W-PP and that goes right into the board. W-PP carries a +12V which could possibly wreak havoc on the circuitry particularly with W-VDD cut off. With the wiper stalk switch at OFF and INT, W-PP is connected to W-LO. This is actually fine but no harm in breaking this connection while the VIWC is powered up. Tests thus far show that W-LO isn't connected to the board or relay. So we don't have to sever this connection to the wiper module. We'll just need to tap into it to trigger--briefly turn on--the wiper motor. Here's a diagram of the wires leading to the connectors that we'd need to break. Actually only one connector needs to be modified.

Take note of the new wire labels. Those are used in the following schematic. Note that all switches and relay contacts are shown in their normal position--with the circuit powered down.

In the initial design I opted to use a DPDT switch rather than the DPDT relay. I decided on the relay and SPST switch design because I would be able to use a smaller switch on the dashboard and would have to bring only two wires to it.

REL1 is a Telemecanique RXM2AB2JD 12-volt relay with 12A DPDT contacts and a green LED indicator lamp. REL2 is a 12-volt relay with 10A SPDT contacts.

When S-POW is closed REL1 is energized. Power to wiper module is cut off while the VIWC is powered up. Simultaneously, WW-PP is disconnected from W-PP and connected instead to REL2's NC contact, thus making sure that when REL2 is de-energized the wiper motor will automatically bring the wiper blades back to their parking position.

You will notice I have not used W-GND but connected the circuit directly to chassis ground. Tests show both are the same net even when ignition is off. I want to cut and cut into as few of the car's wires as possible.

For the pot I used a cheap low quality one. Trying to get a particular time interval with it can become vexing. I'm still trying to find a better pot that has a much more even resistance across its entire range. Another option is to use a pot with a switch thus integrating S-POW with R1 in one package.

A 78L05 100-mA voltage regulator provides +5V to the MCU. Filter cap is 100uF.

The microcontroller is run at 4MHz. Watchdog timer is enabled. The prescaler is assigned to timer0 so WDT will time out in 18ms (nominal value as per datasheet). In the firmware WDT is cleared during the polling of TMR0.

With the single 8-bit timer I wanted to get the highest possible tick. At 4Mhz--which translates to a million instructions/sec--that would be 65.536ms with TMR0 = 0 and a prescale of 1:256. But that's not a good tick value. 50ms is easier and more sensible to work with. To obtain that, prescale is set to 1:256 and TMR0 reinitialized to 0x3D (decimal 61) every time it rolls over to zero. Given those values TMR0 will overflow every (256 - 61)(256)(1us) = 49.92ms.

Remember baseline PICs don't have interrupts. We have to poll the timer to determine when it's overflowed. But for some reason using the conditional "while(TMR0 != 0)" doesn't work. Using any value other than zero, however, works. So in the firmware below I have "while(TMR0 != 0xFF)" instead. With that conditional perhaps I should initialize TMR0 to 0x3C instead.

What I wanted was for the time interval between wipes to be increments of 1 second, that is, as the user turns the potentiometer the interval would get longer/shorter but it would jump from 1 second to 2 to 3 and so on, and not fractions thereof. As for maximum interval, I initially specified 60sec but then I settled on 30. Minimum interval would be 1sec.

Note that time interval is defined as the time between de-energization of the REL2 and its re-energization.

In order to realize the above specs, it occured to me there's a simple and elegant way of doing so. The ADC onboard the 10F222 has an 8-bit resolution. That's 256 values, from 0 to 255. Well what we can do is to degrade the resolution to less than 8 bits. That's easily done by right shifting the ADC value (the number the ADC spits out after the conversion). Shift it right twice and we have a 6-bit number--from 0 to 63. Or shift thrice and we a 5-bit value--0 to 31. We can then take those numbers as the time interval (in seconds). But since we specified a minimum of 1 second, we should add 1 to the 5-bit ADC value giving us a range of 1 to 32. Now keep in mind this is the number of seconds. Our timer tick, however, is ~50ms. To get the time interval in terms of ticks we have to multiply the ADC value by 1sec/0.05sec = 20. Therefore, to count 32 seconds, we need to wait for 32(20) = 640 ticks.

The potentiometer is read by the ADC every timer tick. The time interval setting is therefore updated 20 times a second, except when a wipe action is being executed--the ADC is not reading the pot during that time.

The firmware is such that, every timer tick, it compares the latest time interval chosen by user and the amount of time elapsed since the last wipe. If time elapsed already exceeds the latest time interval setting, then a wipe is immediately performed and the 16-bit counter monitoring the amount of time elapsed is reset to zero.

For example if the pot was previously set to a time interval of say 25 sec, and 15 seconds has already elapsed, and the user has just turned the pot down to 12sec, the firmware will immediately issue a wipe action and reset the time elapsed counter. (In reality, with a read rate of 20x a second--somewhat faster than the driver can turn the pot--firmware will see the pot setting crossing the 15sec mark and issue a wipe action at that point). On the other hand, if the user had turned up the pot instead, to say 30sec., then the firmware will count all the way to 30sec before the next wipe.

When powered up an initial wipe is made. Thereafter, when the succeeding wipes will occur will depend on the pot setting. The length of time I've chosen for the wiper to be triggered (turned on briefly) is one second (20 timer ticks). As mentioned in Part 2 the time for the wiper to go from parking position and back was measured to be ~1.3sec. Trigger time must be less than this. A trigger time of around half a second would probably be sufficient. Keep in mind, however, that time interval between wipes is affected by wiper trigger time.

And here's the final firmware to drive the micrcontroller. Compiler used is the Hi -Tech C Lite v9.80. As I mentioned a few days ago the 10F222 include file of v9.81 doesn't define TRIS and so will fail to compile the following.

/*

Variable intermittent wiper control for the Toyota Innova, 2008, E-variant
June 2011

Processor = PIC 10F222 
Compiler = Hi Tech C v.9.80

Description: User adjusts a potentiometer to desired interval between wipes.

*/


#include <htc.h>
#include <et_include.h>

__CONFIG (OSC_4MHZ & MCPUDIS & WDTEN & UNPROTECT & MCLRDIS);        // for Hi-Tech C v9.80
// __CONFIG (IOSCFS_4MHZ & MCPU_OFF & WDT_OFF & CP_OFF & MCLRE_OFF); // for Hi-Tech C v9.81

#define   wiper              GP2       // switches 2N7000 MOSFET transistor which then switches relay which switches wiper
#define   wipertrigtime      20        // amount of time to power up wiper. time is in terms of number of timer0 overflows
#define   t0_init            61        // initial value of timer0. with prescaler = 1:256, overflow occurs every ~50ms 
// #define  _XTAL_FREQ       4000000 



// potentiometer setting is converted to 5-bit digital value
// 10F222 ADC has 8bit resolution, therefore ADC value is right shifted three places
// After right shifting, add 1 so that with ADC value of zero (potentiometer at zero ohms) the minimum time interval is 1sec.
// Since max ADC value for 5-bit is 31, max time interval = 31 + 1 = 32sec
int8 ADC()          
{
  GODONE = 1;                          // start ADC conversion
  while(GODONE);                       // wait till GODONE bit has been cleared, signifying completion of conversion 
  return ((ADRES >> 3) + 1);     // degrade to 5 bits, and force min time interval = 1
}


// wiper lo speed is triggered (switched on) for a brief moment, determined by constant "wipertrigtime" 
// after triggering, parking system on wiper motor will take over powering the motor until it reaches parking position 
// when wiper reaches parking position, motor stops automatically 
// NOTE: WDT must be cleared within 18ms (no prescaler assigned to it)
void WIPE()
{
  int8 i;
  wiper = on;
  for (i=0; i<wipertrigtime; i++)
  {
    TMR0 = t0_init;
    while(TMR0 != 0xFF)      // for yet unknown reason conditional doesn't work with "TMR0 != 0x0"
      CLRWDT();
  }
  wiper = off;  
}


// NOTE: WDT must be cleared within 18ms (no prescaler is assigned to it)
void main()
{
  static int16 TIME = 40;    // number of timer0 overflows (every 50ms) between wiper sweeps. initialize to minimum time interval betwen wipes (2sec. which is equivalent to 40 timer0 overflows) 
  static int16 COUNTER = 0;  // stores the number of times timer0 has overflowed

  TRIS = 0b1;                // pot is connected to AN0/GP0
  OPTION = 0b11000111;       // wake up pin change disabled, pull ups disabled, timer0 uses internal clock, timer0 prescale = 1:256 
  WIPE();                    // have wiper sweep windshield once upon power up
  TMR0 = t0_init;
  ADCON0 = 0b10000001;       // GP0/AN0 is analog, GP1 is digital, channel 0 selected, ADC on
  
  while(1)
  {
    while(TMR0 != 0xFF)      // poll TMR0 because there is no timer0 interrupt flag. for yet unknown reason conditional doesn't work with "TMR0 != 0x0"  
      CLRWDT();              // WDT must be cleared within 18ms (no prescaler assigned to it)

    if (COUNTER++ >= TIME)
    {
      WIPE();
      COUNTER = 0;           
    }
    TMR0 = t0_init;
    
    TIME = (ADC())*20;       // Each value of the 5-bit ADC reading is equivalent to number of seconds. 
                             // This is then multiplied by 20 since timer0 overflows every 50ms and 1sec/0.050sec = 20
                             // if new TIME < previous TIME and current COUNTER value exceeds new TIME then a wipe will occur right after the next TMR0 overflow
                             // if new TIME > previous TIME then whatever COUNTER is, the next wipe will occur at a later time.   

  } // while(1) 
} // void main()

I field tested the circuit to check if everything works. It does! Here are a couple of pics of that test process. The breadboard is in the translucent plastic box while the relays are mounted on a DIN rail. REL1 and REL2 are both Telemecanique RXM2AB2JD relays. In the PCB version I will be using a small PCB mounted relay for REL2.

There's another shot of this setup in which something very interesting inadvertently appeared.

June 12 edit: A Part 4 just appeared. And because of new developments so will a Part 5.

Variable intermittent wiper control - Part 2

2011-06-08T20:33:00.001+08:00

Variable intermittent wiper control - Part 1

Before delving into the electrical characteristics of the Innova's wiper system, let me just provide the wipe time. Using a stopwatch the time for the wiper in intermittent mode to make one complete sweep--wiper goes from park position, sweeps the windshield and back to parking--is approximately 1.3sec.

Here again is a shot of the header pins into which the connectors plug.

After testing the wiper switch module here are the pin assignments I came up with:

Testing included using the resistance/continuity mode of a multimeter to check which pins are electrically connected (practically zero ohms) while trying the various switch settings. Testing also involved plugging the connectors into the module--only partially so I can have access to the headers--turning the ignition key until power is supplied to the wiper circuit and probing the headers with the DMM and trying out the different switch settings on the stalk.

The following summarizes the cold test using the ohmmeter. The presence of links (lines) between pins means those pins are electrically connected at the indicated switch setting.

Below are results of the hot test. All voltage values are with reference to chassis ground. The voltage on some pins jump from one value to another or span a range. This is indicated by the nomenclature "x - y". So "0 - 12V" might mean that voltage toggles between these values or that it smoothly but very quickly rises to 12 or declines to 0. Using a DMM did not allow me to determine whether the readings I was getting were indicative of discontinuous or continuous values.

I also checked the PCB disconnected from the connectors and using an ohmeter had the following results.

The yellow box denotes the location of relay on the other side of the board. Hence the solder points within that outline will be the pins on the relay. The solder joint marked "COIL" is inferred from the fact that there is no other pin for the relay coil. Moreover resistance reading from VDD to COIL is 240 ohms--that's within the ballpark for a 12VDC coil.

What is perplexing to me is that there are two relay pins to which W-PP is connected. Why?! This finding has really been very disconcerting. I would've thought that one of the relay contacts would be hooked up to W-LO. Interestingly, if you look at the W-PP track on the left side you'll see that it leads to the top portion of the board to a solder joint. So W-PP is connected to some other component. The mystery deepens.

With the module disconnected and the ignition key turned to supply power to the wiper (with the engine off), I used a DMM set to current measurement to act as a jumper and to measure peak current as well. Here are the results.

Using DMM probes as jumpers between Net 1 and 2 with a Fluke 87V DMM set to measure current, Min-Max mode on
Net 1	Net 2	Result of connecting jumper	Maximum Measured Current (amperes) (see footnote)
W-VDD	W-LO	front wiper low speed on continuously but stops as soon as jumper removed--wiper does not park automatically	3.1 to 4.0A
W-PP	W-LO	with wiper initially NOT at parking position, the wiper will move to parking position and then stop; keeping jumper connected does not result in any further action	3.7 to 6.2A
W-VDD	W-HI	front wiper high speed on continuously but stops as soon as jumper removed--wiper does not park automatically	8.9 to 9.2A
W-RW	W-GND	rear wiper turns on continuously and parks automatically when jumper removed	1.4 to 1.7A
W-RM	W-GND	rear mist on as long as jumper connected	2.0 to 2.6A
W-FM	W-GND	front mist on (wiper does not turn on) as long as jumper connected	2.2 to 2.5A

Note: Current measurements were made several times. Only MAX values as measured by the 87V were recorded. The range of values per item above are the lowest and highest MAX values.

Given all the above data I have drawn up a provisional schematic diagram. However, it almost certainly is incomplete and contains errors so I won't put it up lest some reader relies upon it as gospel truth.

What can be inferred with high confidence at this time are the following :

Switching the stalk to LO disconnects W-PP from W-LO and connects W-VDD and W-LO, feeding +12V to the wiper motor's low speed circuit.
When the stalk is returned to OFF, W-PP is once again connected to W-LO thus automatically parking the wiper.
When stalk is switched to INT W-PP remains connected to W-LO. The electronic circuit comes into play and switches the on-board relay for about a second every couple of seconds. Judging from the clicks of the relay it is being turned off right at the moment of wiper parking (which makes me wonder yet again how W-PP is being used by the PCB).
When the stalk is switched to HI, W-PP is not connected to W-LO. W-VDD is connected to W-HI thus supplying +12V to the wiper motor's high speed circuit.
When stalk is pushed all the way up (switched to MIST--this is a mislabel on Toyota's part since it doesn't turn on the spray) the spring-loaded switch is engaged and W-PP is disconnected from W-LO while W-VDD is connected to W-LO thus supplying +12V to the wiper motor's low speed circuit. Releasing the stalk returns it to OFF position and thus W-PP gets connected to W-LO and the wiper parks automatically.
From the OFF position, when stalk knob is turned counterclockwise (i.e., turning it toward the driver) to the rear windshield spray icon, W-RM is grounded (connected to W-GND) turning on rear mist motor.
From the off position, when stalk knob is turned clockwise (i.e., turned toward the dashboard) one notch to ON, W-RW is grounded (connected to W-GND) switching on the rear wiper motor.
With the rear wiper on, when the stalk knob is turned clockwise to the second rear windshield spray icon, both W-RW and W-RM are connected to W-GND, hence both rear wiper and rear mist are switched on. This is a spring-loaded setting and releasing the knob will return the knob to the rear-wiper-on position and the rear mist motor will be switched off.
When spring-loaded stalk is pulled toward the driver W-FM is connected to ground via W-GND thus turning on the front mist motor. Because W-FM is connected to the PCB (see labeled PCB pic above), the circuit board most probably senses the level change from 12 to 0 volts. After a brief delay (~0.5sec) from the start of the mist the relay is turned on hence switching on the low speed motor circuit. The relay is kept on for several seconds so that the wiper makes at least three wipes.

In Part 3 I'll discuss a microcontroller-based variable intermittent wiper circuit for the Innova and provide a full listing of the firmware.

Variable intermittent wiper control - Part 1

2011-06-07T21:03:00.001+08:00

One of my bugbears with cars I've driven is that their wiper system either don't t have an intermittent mode or if they do then they're fixed, i.e., the wiper sweeps the windshield approximately once every couple of seconds and there's no way of adjusting that time interval. Having an intermittent setting is better than none but having a variable intermittent mode is certainly much better. With a very light drizzle the windshield may need only need be wiped every 10 to 20 seconds, hence having a wiper control that has a user-adjustable wipe interval from one second to say one minute eliminates the hassle of having to turn off the wiper and then on again every now and then.

Some 8 years ago I designed and installed my first variable intermittent wiper control. It was a simple circuit based on the 555 timer configured as an astable multivibrator. It employed a potentiometer to allow adjustment of the wipe interval. The control circuit switched a relay which in turn switched the wiper motor on and off. It even had green and red LEDs indicators showing when the relay was on/off. By 2007 I had a preliminary microcontroller design but never got around to working on it.

Here's the Honda Civic's wiper stalk switch schematic. As indicated the relay contacts were inserted in series after cutting the parking position wire.

And here's the 555 circuit to implement the variable intermittent control. I used an aluminum electrolytic capacitor for the timing cap. But as is known aluminums are leaky. Using a tantalum would be better.

The circuit provides a momentary pulse to the wiper motor (less than a second) after which the motor latches--it powers itself through the parking position circuit--and then stops when it reaches the parking position where the wiper blades are back at the bottom of the windshield..

R3 is a 1Mohm potentiometer. Because of D1 (1N4148 signal diode) charging rate is much faster than discharge rate, charging only through R1. Theoretically, output high and low times are as follows:

T_high = 0.693(R1)(C1) = 0.693(7.5Kohm)(100µF) = 0.52sec

T_{low_min} = 0.693(R2 + R3_min)(C1) = 0.693(15K + 0)(100µF) = 1.04sec

T_{low_max} = 0.693(R2 + R3_max)(C1) = 0.693(15K +1Mohm)(100µF) = 70.34sec

D3 is a flyback diode to dissipate the reverse emf developed across the relay coil when power to it is cut off.

An intermittent wiper control is relatively easy to design. The problem and headache is the cars themselves, specifically, figuring out which wires of the wiper switch go where and control what, and how sophisticated or primitive the installed wiper switch module is. A non-electronic wiper control as is found in the 90's Honda Civic is relatively straightforward. As can be seen above it only has mechanical switches and has very few settings--low speed, high speed, water spray, and momentary wipe (a spring loaded switch lets the driver turn on the wiper which turns off once the stalk is released).

Designing a control for a wiper system that already has an intermittent mode and employs electronics and which has a rear wiper-mist is a tad more difficult--because it takes more effort to analyze and reverse engineer the lot of switches and circuitry--something absolutely necessary because we don't want to fry the car's electronics and cause some major short circuit!

I've been meaning to install a variable intermittent control on the Toyota Innova for some time now but for fear of ruining the wiper system, or worse, zapping some other part of the electrical system--say, the very expensive car computer!--I've procrastinated even inspecting the wiper system to determine whether the project would be feasible. To add to the concerns, this car has an airbag on the steering wheel. Inadvertently triggering it was certainly on my mind. But last week, with trepidation, I finally dove right in.

To begin with I had to get to the wiper stalk's base--which was hidden within the steering column--to get to the wires leading in and out of it so as to be able to test them. As it turns out, removing the plastic covers surrounding the steering column was easy--the top and bottom halves simply snap onto each other and are held down on the steering with just two screws (one of which actually screws onto the detachable wiper switch module--strange I thought).

With the base of the stalk exposed two wire connectors became apparent. Pushing down on the retaining clips on the connectors permitted their removal from the wiper switch module. After some time studying the module I was able to remove it from the steering column--It had plastic "rails" onto which it slid in and one retaining clip was all that held it in place. Love that simple plug-in design. Here's a pic after I'd taken the wiper switch module off. The two white rectangular wire connectors dangling beneath the steering wheel are conspicuous. Those red and black wires and alligator clips are from my DMM.

Close up of the connectors:

And here are shots of the the module:

I was able to partially disassemble the module and here's how the sub units look:

Turning the parts over we have:

See all the copper "tracks" embedded in the plastic? They're thin copper inserts some of which lead to the headers and some to PCB on the other side. The yellow-greenish goo is lubricant for the sliding contacts.

And the headers/pins (into which the connectors plug) on the module:

Close up of the circuit board. There's one 3-terminal SOT device near the center of the board. No markings to identify it. Other devices are surface mount resistors. Values are readily discernible.

The PCB cannot be removed because there are some seven copper "posts" (embedded in the black plastic module) which are soldered onto the PCB. Here's how those copper posts look:

The PCB is at the top portion of the pics. They're overexposed in the images so you won't see the telltale green solder mask, just the edge of the phenolic? board.

In those two images notice the large black rectangular block. That's a relay although I could not see any markings on it. There's also at least one aluminum electrolytic capacitor in there. I could see the temperature rating but not its capacitance. The only way I'll be able to view all the components would be to desolder the posts. I'm not about to do that given my dodgy de/soldering skills. Maybe if I ever get a surplus unit I can do a teardown all the way.

In Part 2 I'll have the results of my electrical tests of the module.

It's play time with conductive playdough

2011-06-05T17:32:00.000+08:00

Recipe for conductive and insulating playdoughs. Their recipe is almost the same as the bbc's. For those who want to measure by weight like I do here's the newscientist's formula.

My main concern with the kid-safe conductive dough is that the high salt content will corrode wires, metals, and--Electra forbid--test instrument (multimeter) probes. According to Anne Marie Thomas a 1cm long dough with a diameter of 1cm has a resistance of 80ohms. Given the equation

R = ρ l/A

where
R = resistance in ohms
ρ = resistivity of the material
l = length of material
A = area

we can solve for ρ of this conductive playdough:

80ohms = ρ (0.01m) / [(0.01/2)^2(3.14)]

ρ = 0.63

I'm not the creative type so right now I can't think of any serious use for this stuff. The material isn't stable and will dry out and probably crumble, and its mechanical and electrical properties will change in a matter of weeks so the lifespan of circuits employing it will be quite limited.

Bumped into a Hi-Tech C Compiler bug

2011-06-03T22:52:00.000+08:00

Am developing a circuit using the PIC10F222. Since I don't want to code in assembly I chose to use Hi-Tech C Compiler for PIC 10-12-16 (freebie version) v9.81 within Microchip's MPLAB IDE (v.8.66). I'm still developing the software but when I compiled the very short initial code I got an error message saying that "TRIS" is an "undefined identifier." The offending line that tripped the compiler was "TRIS = 0b10". I couldn't understand why it would be flagged as an error since that's the correct syntax to initialize the TRISIO register (which is not accessible directly) according to Hi-Tech User Manual (DS51865B-page 53):

3.3.9.2 THE TRIS INSTRUCTIONS

Some PIC devices use a TRIS instruction to load the TRIS register. The <htc.h> header file will ensure a special definition for a C object called TRIS. PICC will automatically use the TRIS instruction when an appropriate processor is selected and the TRIS register is accessed.

For example, to make all the bits on the output port high impedance, the following code can be used.

TRIS = 0xFF;

This will load the appropriate value into the W register and then call the TRIS instruction.

Those PIC devices which have more than one output port may have definitions for objects: TRISA, TRISB and TRISC, depending on the exact number of ports available. This objects are used in the same manner as described above.

Given that last paragraph I changed TRIS to TRISIO, TRISA, TRISB, and TRISC. Still got the same error. I also changed the numerical values to decimal and hex. I even closed MPLAB and opened it again. None of these licked the problem. Finally since I have v9.80 installed I tried that to compile the program.

Lo and behold! The error message disappeared. When I opened the include file for the 10F22x for v.9.80 I found out that TRIS and TRISIO are defined therein, but they aren't in the 10F222 include file for v.9.81. Oddly though, while OPTION is defined in v.9.80 and isn't in v9.81, the latter nevertheless understood that command and correctly compiled it.

So there. That's a bug in version 9.81.

Having opened the include files for both versions, I was vexed to find out that there are a number of differences in the defines. For instance for the configuration bits, v9.80 lists the following:

// Configuration Mask Definitions
/* Internal oscillator frequency select */
#define OSC_8MHZ 0xFFF // internal osc is 8MHz
#define OSC_4MHZ 0xFFE // internal osc is 4MHz

/* Master clear pullup enable */
#define MCPUEN  0xFFD // pullup enable
#define MCPUDIS  0xFFF // pullup disable

/*watchdog*/
#define WDTEN  0xFFF // watchdog timer enable
#define WDTDIS  0xFFB // watchdog timer disable

/* code protection */
#define PROTECT  0xFF7 // protect the program code
#define UNPROTECT 0xFFF // do not protect the program code

/* MCLR Pin function */
#define MCLREN  0xFFF // master clear reset enable
#define MCLRDIS  0xFEF // master clear reset disable

while v9.81 has these:

//
// Configuration mask definitions
//


// Config Register: CONFIG
#define CONFIG               0x0FFF
// Internal Oscillator Frequency Select bit
// 8 MHz
#define IOSCFS_8MHZ          0xFFFF
// 4 MHz
#define IOSCFS_4MHZ          0xFFFE
// Master Clear Pull-up Enable bit
// Pull-up disabled
#define MCPU_OFF             0xFFFF
// Pull-up enabled
#define MCPU_ON              0xFFFD
// Watchdog Timer Enable bit
// WDT enabled
#define WDT_ON               0xFFFF
// WDT disabled
#define WDT_OFF              0xFFFB
// Code protection bit
// Code protection off
#define CP_OFF               0xFFFF
// Code protection on
#define CP_ON                0xFFF7
// GP3/MCLR Pin Function Select bit
// GP3/MCLR pin function is MCLR
#define MCLRE_ON             0xFFFF
// GP3/MCLR pin function is digital I/O, MCLR internally tied to VDD
#define MCLRE_OFF            0xFFEF

None of the bit names are the same!

Since I'm using the ADC, the line "GO_nDONE = 1"--which is perfectly fine in v9.81--was flagged as an error in v9.80 because it only recognizes "GODONE." Now try compiling "GODONE = 1" in v9.81. What do you think will happen? You guessed it. You get a build fail.

For who knows what reason, Microchip not only demands we have a photographic memory to remember all those changing (or alternate) defines, it's also made it a hair-tearing ordeal to port firmware from one compiler version to the next. This is yet another reason I really would rather stick to mikroC if not for the fact that mikro doesn't support the baseline PICs and has a 2K code limit.

Bugs in the PIC12F1822 / 1840 datasheets

2011-06-02T08:42:00.000+08:00

I mentioned a few days ago that there's something amiss in the datasheets for the PIC12F1822/16F1823 and PIC12F1840 regarding the DAC negative voltage source. I reported that problem to Microchip and today I received the following reply:

In the PIC12F1822 and PIC16F1823 there is not a DACNSS bit. The drawing (Figure 17-1) and references to this are incorrect and the register bits are correct as published. The negative reference is always connected to Vss.

The PIC12F1840 DACCON0 is incorrect and bit ‘0’ should be unimplemented.

There is no negative Vref pin on the chips so that should've been the clincher for me.

DAC using the FVR as voltage source

2011-05-29T22:56:00.001+08:00

Continuing with the DAC tests over the last two days, I wanted to see the DAC using the internal fixed voltage reference instead of V_DD. This would allow V_DD to vary (with the condition that V_DD > FVR output) without affecting the DAC operation. So I loaded the PIC18F1822 with the firmware below. Note that the internal oscillator frequency has been set to 31kHz to provide a delay between increment/decrement of DACCON1 value.

void InitRegisters()
{
  PORTA = 0;
  ANSELA = 0;
  TRISA = 0;
  OSCCON = 0b1000;            // run internal oscillator at 31kHz LF
  FVRCON = 0b10001000;        // enable fixed voltage reference for DAC, set gain = 2 to give a ref volt of 2.048V
}

void main() 
{
  InitRegisters();
  DACCON0 = 0b10101000;       // DAC enabled, DAC output available on DACOUT pin, FVR as positive voltage source
  DACCON1 = 0x1F;  
  while(1)
  {
    while (DACCON1-- >1);     // go from DACCON1 = 31 to DACCON1 = 0 
    while (DACCON1++ < 30);   // go from DACCON1 = 1 to DACCON1 = 31
  }
}

And here are the oscilloscope readings: