Is it good to use ULN2003 for driving 7 Segment Displays ?

[Okada]

Is it good to use ULN2003 for driving 7 Segment Displays ?

I am reverse engineering a circuit. I have the original .hex file of the product. It works well on hardware and also Proteus. I have videos of it. I have written a code for that product but my code is causing the display to flicker. My code is correct. I have used 500 us interrupt for refreshing the 6 digit common cathode display. My code is working fine in Proteus but flickers in hardware.

Client has asked not to post code and hence I can't post full code but if needed I can post ISR code which is used to drive the displays. I am using PIC16F73. The device is called a Device Protector. It cuts off mains if voltage is beyond under / Over voltage limits. It also displays input and output voltage on 2x 3 digit 7 Segment displays.

In the real hardware they have used ULN2003 to drive both 7 Segment displays and relay. I told it is bad to use ULN2003 as it can't switch faster. I told to use BC547 for both 7 Segment displays and relay driving.

Here is the ISR code.

---

Code C - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
PORTC &= 0x80;
         
        switch(digit) {
             case 0:
                  if(digits[0] != 0) {
                     SSD_DATA_PORT = digits[0];                  
                     PORTC = 0x20;
                  }
                  break;
             case 1:
                  SSD_DATA_PORT = digits[1];
                  PORTC = 0x10;
                  break;
             case 2:
                  SSD_DATA_PORT = digits[2];
                  PORTC = 0x08;
                  break;
             case 3:
                  if(digits[3] != 0x3F) {
                      SSD_DATA_PORT = digits[3];
                      PORTC = 0x04;
                  }
                  break;
             case 4:
                  SSD_DATA_PORT = digits[4];
                  PORTC = 0x02;
                  break;
             case 5:
                  SSD_DATA_PORT = digits[5];
                  PORTC = 0x01;
                  break;             
        };
 
        if(++digit >= 6) {
            digit = 0;
        }       
                                       
        TMR1IF_bit = 0;
        TMR1H = 0xFE;
        TMR1L = 0x0C;

---

Edit:

I can't post the .hex file because the device doesn't have internal eeprom and without eeprom I can't create demo .hex file. I am attaching Proteus simulation videos of my .hex file.


These are the links to videos of hardware working of the original product with original .hex files.

**broken link removed**

**broken link removed**


You can see that there is no flickering of displays but also you can see how badly the code is written because when initially Lo is displayed it also tries to display countdown timer and display flickers and fluctuates.

 

[esp1]

hi,
The typical switch On/Off times for a ULN2003 are 0.25uS, worst case 1uSec, that will not cause a problem.
I have used the ULN many times for LED driving.
E

 

[Okada]

@esp1

Sometime ago somebody had advised me not to use ULN2xxx devices for driving 7 Segment displays as they are darlington and slow switching devices. What do you say about this ?

 

[betwixt]

I too have used them many times. They only work as low side switches of course.
They contain internal pull-down resistors at their inputs which help to keep the speed up but in any case, they can turn on and off much faster than the software SHOULD allow.

Brian.

 

[Okada]

Can ADC cause the problem of fluctuation. ?

Actually if ADCON1 is oc04 then RA0 and RA1 will be configured as analog but RA1 is also used for Relay. So, ADCON1 should be made 0x04 a few milli sec before reading ADC and after reading ADC it should be made 0x07 so that relay can operate but I have not done this.

 

[KlausST]

Hi,

No, the ADC itself can not cause the fluctuation.
But a lot of other circumstances may cause errors.

Beginning from the analog input,
input filtering,
ADC or better say microcontroller GND current causes GND bounce
The software with filtering may improve fluctuation
Use a stable reference voltage instada of unreliable VCC
...

Klaus

 

[Okada]

The original .hex file and my .hex file are both being tested on the same hardware.

Edit:

I had not seen the video of hardware working with my .hex file. Here is the video of hardware working with my .hex file. It is actually not flickering. It is actually LSB of adc value fluctuating. I think I need Kalman filter. What do you people say ?

I was watching this thread.

https://www.edaboard.com/threads/355886/

In post #6 of that thread Easyrider83 mentions

KalmanStruct.Previous = Value; // initial value to force it start closer to result

What is the value of Value ?

 

[betwixt]

Just confirm - your video shows brightness flicker and also one of the digits changing, which is it you are asking about?

It is normal for the least significant digit to change +/- 1, anything more than that indicates noise on the voltage you are measuring or on the analog reference voltage. With poor supply regulation or poor grounding, it is quite possible for the number of segments lit up to influence the ADC reference.

Brian.

 

[Okada]

Digits changing I am referring. You can see the video in the two links in first post. In that the LSB doesn't fluctuate. It is original .hex file. The video in which LSB fluctuates is my .hex file.

 

[KlausST]

Hi,

As Brian says. Fluctuation of one LSB is quite normal and no decrease of quality.

If you want to avoid this, you need to add some hysteresis function.
This may look more "nice", but indeed it adds some error. It s no improvement in accuracy or precision.

Klaus

 

[Okada]

How to add hysteresis ? By taking average of several values ? I am taking now 256 readings and then average. 50us is the delay between each reading. It will be tested tomorrow by my client on hardware.

 

[betwixt]

No matter how many samples you average there will always be a border condition. Ask yourself which is more accurate, when the actual value should be 99.9999, is it nearer to show 99 or 100? At what threshold should the 99 become 100? Think carefully before answering!

Hysteresis implies you store and re-use the same value unless the measurement changes more than a certain amount. It ensures the digits stay the same until the change is significant enough to warrant updating them.

Brian.

 

[Okada]

I have actually implemented that that is only when previous_adc_value is not equal to adc_value then only value is updated on display.

 

[Okada]

Taking averages of 256 adc readings worked. Here is my .hex file working video.

**broken link removed**

After 4 hours the product has been completely reverse engineered.

 

[betwixt]

I have actually implemented that that is only when previous_adc_value is not equal to adc_value then only value is updated on display.

That makes no improvement to the 'flicker' as it will update whenever the numbers change anyway. It may help slightly by avoiding some software routines until they are needed.

Averaging also make no difference to the problem unless you are removing real noise from the measurment. If noise is present, the more accurate fix is to eliminate it before measuring it, not to make the value change less responsive.

Brian.

 

[Okada]

I am reading output of bridge rectifier after scaling it using adc. You can see in video of post #14 that LSB fluctuation is eliminated. The problem is solved. It doesn't matter to me if 220V is displayed as 219 or 221V. At present 220V read by multimeter is being displayed as 220V on PIC circuit.