Protecting components when AVR malfunctions

Go To Last Post
39 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm using a 6ms pulse to power two IR LED's using  1 ohm resistors at 5VDC. The circuit is drawing about 140 ma average based on my power supply current reading.

 

The 6ms pulses are applied with two timers, timer 0 is a 100 ms timer and timer 1 is the 6ms timer so On time is 6ms and off time is 100ms

 

As I was testing, I made a programming error where the pulse stayed on drawing 400 ma current for a few seconds.

 

What kind of protection can I use to solve a potential AVR malfunction or mosfet malfunction or development software error that would protect those led's from burning up?

 

I am familiar with PTC fuses but is there any other method using capacitors or something?

 

Code so far

#include <tiny45.h>

volatile unsigned char WheelTenMSTimer = 10;   // Decrements once per Millisecond resets to 10 when WheelPin state is read.
volatile unsigned char WheelState = 2;                  //  2 = Unknown State initially
volatile unsigned char PreviousWheelState =  2;  // 2= Unknown State initially Valid 1 = High, 0 = Low
volatile unsigned char IRLedOutputFlag = 0;
volatile unsigned char RollerSenseCount = 50;    // Valid 0 = Sensor Low, 100 = Sensor High
volatile unsigned char WheelPulseCounter = 0;



// alarm
#define AlarmPin PINB4
#define AlarmPort PORTB
#define AlarmDDR DDRB
#define AlarmOn  AlarmPort |=(1 <<AlarmPin)
#define AlarmOff  AlarmPort &=~(1 << AlarmPin)

// RollerSensor INPUT

#define WheelPin PINB1
#define WheelPort PORTB
#define WheelDDR DDRB
#define WheelPinHigh ( (PINB & (1 << WheelPin)) == (1 << WheelPin) )

// Roller sensor IR Led OUTPUT
#define RollerPin PINB3
#define RollerPinPort PORTB
#define RollerPinDDR DDRB
#define RollerPinOn RollerPinPort |=(1 << RollerPin)
#define RollerPinOff RollerPinPort &=~(1 << RollerPin)

//ScreenFrame Sensor INPUT
#define FrameInputSensorPin PINB0
#define FrameInputSensorPort PORTB
#define FrameInputSensorDDR DDRB
#define FrameInputSensorPinHigh ( (PINB & (1 << FrameInputSensorPin)) == (1 << FrameInputSensorPin) )

// ScreenFrame Sensor OUTPUT
#define FrameOutputSensorPin PINB2
#define FrameOutputSensorPort PORTB
#define FrameOutputSensorDDR DDRB
#define FrameOutputLedON  FrameOutputSensorPort |=(1 << FrameOutputSensorPin)
#define FrameOutputLedOFF FrameOutputSensorPort &=~(1 <<  FrameOutputSensorPin)


interrupt [TIM0_OVF] void timer0_ovf_isr(void)
{
	//  1MS interrupts
	TCNT0 = 131;
	if (WheelTenMSTimer > 0)
	{
		WheelTenMSTimer--; // Decrement 10 ms timer
	}
}


interrupt [TIM1_COMPA] void timer1_compa_isr(void)
{
	// compare OCR1A = 200 // Clock /256
	// 6.4MS timer interrupt
	
	if (WheelTenMSTimer == 0) 	//Turn the IR Led Flags on and reset ten MS timer
	{
		WheelTenMSTimer = 100;  // 100 MS until next on cycle
		IRLedOutputFlag = 2;         // Set to turn IRE led ON
	}
	if (IRLedOutputFlag == 1)     // Turn off IR LED
	{
		FrameOutputLedOFF;
		RollerPinOff;
		IRLedOutputFlag = 0;
	}
	if (IRLedOutputFlag == 2)
	{
		FrameOutputLedON;
		RollerPinOn;
		IRLedOutputFlag = 1;     // Set so next time this interrupts 6.4MS  turn off IR LED
	}
}

void TestValidWheelPulse();
void TestAlarmConditions();



void main(void)
{
	// Setup timers
	TCCR0A=(0<<COM0A1) | (0<<COM0A0) | (0<<COM0B1) | (0<<COM0B0) | (0<<WGM01) | (0<<WGM00);
	TCCR0B=(0<<WGM02) | (0<<CS02) | (1<<CS01) | (1<<CS00);
	TCNT0=0x00;
	OCR0A=0x00;
	OCR0B=0x00;
	TIMSK=(1<<OCIE1A) | (0<<OCIE1B) | (0<<OCIE0A) | (0<<OCIE0B) | (0<<TOIE1) | (1<<TOIE0);

	// clock / 256
	TCCR1 =(1<<CTC1)|(0<< PWM1A )| (0<<COM1A1) |(0<< COM1A0) |(1<<CS13) |(0<<CS12) |(0<<CS11) |(1<<CS10);
	OCR1A = 200;
	OCR1C = 200;

	WheelDDR  &=~(1 << WheelPin); // Input
	WheelPort |= (1 << WheelPin); // Pull up
	
	FrameInputSensorDDR   &=~(1 <<FrameInputSensorPin); // Input
	FrameInputSensorPort  |= (1 <<FrameInputSensorPin); // Pull up

	AlarmDDR |=(1 << AlarmPin);
	RollerPinDDR |=(1 << RollerPin);
	FrameOutputSensorDDR |=(1 << FrameOutputSensorPin);

	#asm("sei")                          // Turn on interrupts
	while (1)
	{
		while (IRLedOutputFlag == 1)  // When Timer1 Interrupt turns IR LED on Read status IR Receiver until IR Led turns off
		{
			if (!FrameInputSensorPinHigh)  // Reset all counters if no frame in sensor beam
			{
				AlarmOff; 
				WheelState = 2;                  //  2 = Unknown State initially
				PreviousWheelState =  2;  // 2= Unknown State initially Valid 1 = High, 0 = Low
				RollerSenseCount = 50;    // Valid 0 = Sensor Low, 100 = Sensor High
				WheelPulseCounter = 0;   // Flag for alarm when counts up to 16 , ten inches have passed
			}

			if (WheelPinHigh)
			{
				if (RollerSenseCount < 100)
				{
					RollerSenseCount++;  // Increase counter if IR sensor is receiving
				}
			}
			else // WheelPin is LOW
			{
				if (RollerSenseCount > 0)
				{
					RollerSenseCount--; // Decrease counter if IR sensor is not receiving
				}
			}
		}
		
		if (IRLedOutputFlag == 0) // When Timer1 interrupt turns IR led off Reset the counter
		{
			if (RollerSenseCount == 100)  // Test if Roller Sensor valid Receive
			{
				RollerSenseCount = 50;   // Reset to neutral
				WheelState = 1;
			}
			else
			{
				if (RollerSenseCount == 0)  // Test if Roller Sensor valid Receive
				{
					RollerSenseCount = 50;   // Reset to neutral
					WheelState = 0;
				}
			}
		}
		
		if (WheelState != 2)
		{
			TestValidWheelPulse();
			TestAlarmConditions();
			
		}
	}
}

void TestValidWheelPulse()
{
	if (PreviousWheelState == 2)
	{
		PreviousWheelState = WheelState;
	}
	
	if( WheelState == 0)
	{
		if (PreviousWheelState == 1)  // Record a valid pulse
		{
			WheelPulseCounter++;
			PreviousWheelState = WheelState;
			WheelState = 2;
		}
	}
	else  // WheelState = 1
	{
		if (PreviousWheelState == 0)  // Record a valid pulse
		{
			WheelPulseCounter++;
			PreviousWheelState = WheelState;
			WheelState = 2;
		}
	}
}

void TestAlarmConditions()
{
	if (WheelPulseCounter == 2)
	{
		AlarmOn;
	}
}

 

Last Edited: Fri. Nov 13, 2020 - 06:55 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can add a pulse width limiter circuit...note that typically limits only the width of one pulse...get too many pulses & you are back to square blowout.

Yo can charge up a coil as an energy bucket (flyback)...so a long pulse has no more energy to dump than a short pulse.  But again, too many pulses and you are in the same situation.

terms:  one-shot, non-retriggerable one-shot,

 

Prob the easiest is to use a comparator...when the AVR goes high the connected comparator + pin goes with it & the output turns on your driver.

You also have a resistor at ground to monitor led current (hey you got 1 ohm at ground already)...feed that current --> voltage into a "slow RC" , like 1K/1uF  This goes to the - comparator pin.  If the led is on too much or too long, the average  - pin voltage rises & when it gets too high, the comparator output will be held low.   The + pin needs divided down so the AVR logic level is compatible with the desired max RC voltage.

So when the AVG led current is too high it blocks the comparator output from turning on (due to either too many pulse or too long pulses).

 

Alway use some hysteresis ...add 1 meg or so from comp out to comp + pin.  Also, many comparators need an output pullup resistor.

==================

 

Another way that is dumber & cheaper (maybe not quite as accurate):

Instead of powering your LED direct from power supply get a big ohm resistor, maybe 1K...you go figure.

Use that resistor to slooooowly charge up a big cap (your led energy reservoir).  Now when you fire the led, you get a big blast from the cap to the LED.  If left on, then the cap drains & the led is protected.  The all-on current is limited by 1K, or whatever you use.

Since it takes a long time to charge up, giving a bunch of pulses also does no damage, since no heavy charge has built up.   

Note: if you want a perfect square wave from the led---if your cap is too small, it will discharge too quickly & the rear end of the pulse will curve, so don't make the cap "too tight".

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Fri. Nov 13, 2020 - 08:03 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would use a 555 as a one shot MV set to 6ms timeout!

 

Jim

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would use a 555 as a one shot MV set to 6ms timeout!

Make sure it is not quickly retriggerable , or you could be back to nearly 100% on (for example, you may allow max of 6ms every 200ms....3%).

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

or development software error 

Well,you could use a cheap red LED as the load for testing during software development.

Then swap it out for your real LED once your code is known to be good.

 

For continuous, down the road protection, consider the above replies, or add a second micro that monitors the output of the first micro...

 

That, of course, increases the complexity of both the hardware and the software.

 

The question then is what kind of micro error were you trying to protect against?

With a good power supply, designed voltage and current limits in spec, operated within spec'd temp range, and without excessive G-Force and vibrations, the micro is incredibly reliable.

 

So now, if the Mean Time Between Failure of the micro is very long, which micro will fail first,the primary micro driving the LEDs, or the monitoring micro?

 

Protection for static electriciticy on the user interface, or the user connecting a battery backwards, etc., is pretty straightforward.

 

Long term, bullet proof protection is very challenging.

 

My multi-million dollar CAT scanner has a technician drive from Pittsburgh to Cleveland once a month to run internal diagnostics, calibration checks, and to clean and oil the machine.

 

So just how mission critical is your LED emitter?

That also impacts how much design effort and cost you add to the project for circuit reliablility and failure detection.

 

JC

 

Edit: Typo

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

the most reliable method is to use physics. Candyman's suggestion of a resistor and capacitor is an example of this. The average resistor will be very unlikely to fail short circuit and an electrolytic capacitor unlikely to increase capacitance. By utilising the capacitance  to ensure  there is only a given amount of energy available to the led means the circuit is highly unlikely to fail in a manner that would destroy the led.

 

This style of solution is common with intrinsically safe circuits. By design you can have a circuit that cannot have enough energy to create a spark.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I hear what you are saying about reliability, albeit cross-Thread!

 

Limiting the power input certainly will limit the power output, so the charge pump and dump circuit is certainly a reasonable approach.

That is how we used to design xenon strobe lights for emergency vehicles, charge the cap, fire the trigger transformer with an SCR, and dump the charge into the flash tube.

 

Anyhow, I thought I'd throw out an alternative so that there are at least several options on the table to consider.

My first thought was actually a comparator controlling a PFet on the power supply, all old school analog design.

Then I came to my senses and decided this kind of "watchdog" function would be easily handled by a 6 pin or 8 pin uC doing the brunt of the work.

 

BTW, thank you for posting Mr. Novacek's articles link.

As a long time Circuit Cellar subscriber I used to love reading his articles.

 

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

your logic seems like it can be simplified (wonder if the compiler see it too)

 

TestValidWheelPulse()
if (prev == 2)
    prev=curr

else if (prev != curr)
     count ++
     prev=curr
     curr=2
 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Sat. Nov 14, 2020 - 04:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fantastic information , I very much appreciate. I have had some major back pain and have not been able to sit and putter with this project but today I muscled through it and checked on this post. I do like the capacitor resistor solution and I’ll give it a try.
I originally thought this might be a dumb question but the depth of your answers really blow me away. I’ll post results, thanks!

 

Had just a bit of time but put a 220 ohm and a 100uf and it works great, tried a 1k and it it took a higher uf cap I had a 3300 and that did it.

Now just so I learn something more about capacitor storage , discharge and charge rates I will do the math and set it up on a spice model and get my O-Scope out in my new workroom so I can see the actual pulses and calculate the peak current.

 

I am only at 2 inches distance on this one sensor but the second sensor will be 8"

I am also playing with a long distance of about 300 feet for a com link to my chicken house via led light communication.

 

Last Edited: Mon. Nov 16, 2020 - 12:11 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am also playing with a long distance of about 300 feet for a com link to my chicken house via led light communication.

 

Perhaps modulating a cheap laser pointer would be better for this one?

 

JC 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lasers and spring chickens is a no go. wink

Don't use a green laser in the cold! - YouTube (9m)

 

100m is pushing it for Bluetooth Low Energy with some antenna gain; 1km by some BLE modules with internal power amplifiers.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not sure that was a test of the laser or the cold reaction of the batteries powering the laser diodes!?

I once shot a laser ethernet link across a road from one building to another, about 1/4 mile length of span, it worked well, but had to be realigned twice a year, after the hottest day, and the coldest day of the year, as the buildings would expand and shrink enough to be misaligned, and as it was an East/West line, twice a year it would drop out for 15 min at Sun rise/set, similar to microwave links.

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am also playing with a long distance of about 300 feet for a com link to my chicken house via led light communication.

Yes that is quite doable (since I was in charge of a project that did so).  You could go 500 to 1000 ft  in blazing sun and have a remote control (which uses only a smidge of data).  The tradeoff is the width of the tx beam...if you make it "pinpoint" you get max energy , but try aming it from 700 feet!   You can make the angle wider (oblong), but then the energy density is less--so it is a balancing act.  The ambient sun can be filtered with some simple electronics.  You do have to pay attention to noise levels (solar current).

 

and the coldest day of the year, as the buildings would expand and shrink enough to be misaligned,

You can also suffer from air temp refraction, especially if there is anything enclosing, like a pipe or traversing a tight space. 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Mon. Nov 16, 2020 - 05:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I watched a Youtube of a guy using just a single LED but he used a lens and tube with the sensor in the center basically a monocular telescope. I bought one on Amazon for $18.00 focal range 40 x 60  

That way you only need to focus from the receiving end. If you use for example a 10 Watt LED or higher I will see how far I can go.

 

I mentioned doing a spice model on the above project. After testing and looking at my scope on the voltage plots using a 3200uf capacitor it would require less than a 220 ohm resistor to recharge to the power

I am shooting for.  If I did that I still run into burning up the LED in a full on situation. Assuming I want to try the one IR led that allows 5amps a miss step would be burnout.

 

Anyway I found this guy and his tutorials on Micro-Cap SPICE Software, its now all free, just going through the first tutorial, very cool vs LT Spice, full documentation PDF 

 

https://www.youtube.com/playlist...

 

So much to learn and still so little time, wish we did not have to sleep what a waste of time.

 

 

Attached is a 6ms and a 12ms pulse from V1 , I used a 2n7000 Mosfet instead of a comparator but it shows the idea, The Mosfets don't have a specific turn on gate voltage so a comparator or op amp would be a better choice for that limiting circuit. The SPICE software is pretty easy to use, only watched one video and then gave it a go. Took a while though.

 

 

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your circuit doesn’t make much sense to me. Apart from being drawn in a manner that is difficult to interpret, why the 5ohm resistor in the drain?
What do you want to achieve? How many amps for what time?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Your circuit doesn’t make much sense to me. Apart from being drawn in a manner that is difficult to interpret, why the 5ohm resistor in the drain? What do you want to achieve? How many amps for what time?

 

My first time drawing anything with this software and I was just learning how to actually get something on the chart, yes circuit schematic is very bad but I had to stop and sleep.

 

I moved the resistor to the other side and went up to 14R this caps the current at about 200ma , the M1 Mosfet shuts the M2 Mosfet off if the pulse time exceeds about 6ms with the cap and resistor voltage being fed to the M1 gate.

 

I tried to put a comparator in instead of the Mosfet but the Software is having step time issues computing the results. I will breadboard it with a comparator and see what I get. Time to go to work now...

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You circuit is drawn completely backwards--why?

 

Aren't V1 & V2 inputs into your diagram?

 

Anyhow, your circuit doesn't  look too bad!  You are just using an RC/fet  to clamp off the main gate drive.

 

Once you redraw it, it will appear more sensible to all.

 

Note, you want to modify it so you are detecting the actual led current (MUCH better control)....but then you will need a spit of amplification (since you will want a small Vdrop for current meas)

 

I still suspect you can use a simple RC as discussed previously, depending on you pulse pattern being slow.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Tue. Nov 17, 2020 - 06:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

V1 is simply a representation of a pulse high from the AVR pin. V2 is the 5V supply. Just remember I never used this software and my interest was to see how the clamping would work with a comparator, I could not get the comparator to function in the SPICE model for a step time error reason so I substituted the mosfet just to get something working and learn a bit about the SPICE software. I did go to my workshop and started digging through my stuff to find a push-pull comparator , alas i spent the time organizing my multitudes of little drawers with various parts collected over the years. I will find those and breadboard it I think tonight if I get the chance.

 

With that is it still backwards?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

With that is it still backwards?

 

what do you  mean?? Your ENTIRE circuit is drawn backwards & a twisted mess....schematics drawn improperly are rather irritating.  Remember left to right top to bottom.  

 

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Thu. Nov 19, 2020 - 12:49 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Surely a simple differentiator circuit would work? capacitor in series with the gate and a diode & resistor from gate to gnd. Only one mosfet needed. If Ton is 6ms, then something like 180nF and 68k should get somewhere into the ballpark - depends on the mosfet and gate voltage.

 

If you want sharp turn on/off, then a cmos 555 or a gate should suffice. The micro will have to pulse the signal at the required rate. If it sticks high, then you'll get one pulse. Then you could consider the possibility of the mosfet failing short or other component failure. The micro is more likely to fail (fail as in the port pin stuck high)- either through transients upsetting it or bad code.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Surely a simple differentiator circuit would work

No, if you don't just use a crude  R C , and want to use parts, then you may as well monitor the led current itself.   That would be accurate.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Remember left to right top to bottom. "

 

I never learned the proper way to design schematics. Any suggestions on books I might learn the proper way? I have the same frustration looking at my schematics as well :)

Thanks for the re doing of my schematic, much easier to understand.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ECB layout style is not something that is not written about much. Some of the common style rules that you may choose:

 

(1) Power supply symbols (often arrow) point up

(2) Ground symbols point down

(3) Where there is a clear input and output, input on the left, output  on the right.

(4) No 4-way wire junctions. Too easy to confuse with simple cross-over of two wires.

(5) Do not cross wires when it is not necessary. Take the time to untangle them!

(6) Even when the  schematic tool understands named nets, make sure that you visibly name them. This is  especially true for power supply connections.

(7) Don't cluster a bunch of power supply bypass caps together in one lump on the schematic. Show them where they actually need to connect.

 

Probably more that I am not thinking of.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here are variations...shows the LED a bit more clearly...point is, the schematic is "talking" to you & there are a lot of nuances in what it says & HOW it says it.  Drawing randomly all over the place destroys that.

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Thu. Nov 19, 2020 - 10:09 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Definitely how I'd expect a schematic to be drawn. I can visually break down the building blocks and follow the circuit. A well drawn schematic is like well structured code - easier to see how it works and easier to identify problems.

 

The differentiator suggestion would ensure the led only got 6ms pulses and that the port pin had to toggle. The above circuit is a timeout - of the input is high for X time, it turns off the mosfet. You could sense the current and integrate it which would ensure the average current is within range.

 

Really it comes down to what the expected failure mode is and how you want to mitigate it. Less components means more basic reliability.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I somewhat prefer the one on the left...the dwg on the right lumps the gnds together, which seems to visually obfuscate things slightly.

You could draw a separate gnd for the cap---but then you can suddenly suffer from gnd symbol overload, also not good.  What I'd really HATE is to  draw the gnd shared by R8 & the cap at the cap, rather than R8.  In term of the cap, either is fine; but in terms of R8, putting the gnd at the cap instead, means travelling leftwards....bad bad.    Share to the right.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Thu. Nov 19, 2020 - 10:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


If I had this open I'd mirror the led so its arrows are pointing towards the right, now it bugs me to no end...there's always  one more thing you can fix.  Take the time to find all the tidbits.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In. re. Jim's #7, well, schematically I do that (at least little clumps here and there).  Just don't do that on the board.  S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In. re. Jim's #7, well, schematically I do that (at least little clumps here and there).  Just don't do that on the board.  S.

It is more informative to show them where used.  Providing information is what the schematic is all about.  Field service people will also be very appreciative.

It is also a balancing act.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

Scroungre wrote:
In. re. Jim's #7, well, schematically I do that (at least little clumps here and there).
avrcandies wrote:

It is also a balancing act.

Sometimes it makes more sense to cluster them:

https://www.avrfreaks.net/comment/3033326#comment-3033326

 

 

The above would be needlessly cluttered if the caps were all placed next to each LED.

 

 

Scroungre wrote:
Just don't do that on the board.
I recall a thread where someone posted they'd seen exactly such a gaff on a production board... can't find the thread though...

 

EDIT:  Fixed attribution

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Sat. Nov 21, 2020 - 05:30 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Meh, commodity decouplers? There's nothing to be gained by sticking them next to the chips they're decoupling over a note on the schematic saying 'fit close to power pins of ICs x to y' except you need a bigger bit of paper to draw the damn thing on. If possible, I aim to number the caps to match the component, so C107 fits close to IC107 and so on.

 

Where there are non-obvious decouplers, say where a processor chip needs a dozen in different and repeated values close to half a dozen power pins - that's the time to draw them next to the actual pins. Or if you have a crystal oscillator, or a similar position dependent layout like an amplifier gain stage.

 

The point was made earlier about drawing symbols with the pins logically grouped. To me, this is total sense; IC connections by pin position instead of function is rarely helpful. But regarding power - one thing I really liked about Eagle, and don't like about Kicad, was the automated power unless you explicitly break it out. So unless you told it otherwise, all your TTL chips were connected to the gnd/Vcc rails. Handy, and easy to change if you wanted to connect something somewhere esle. I don't like the default Kicad boxes with power pins; they do the job but they're too big; without the box, one could drop the decoupling cap in between the rails.

 

One thing that really got my goat was at a previous job where the official schematic and layout engineer was the only one allowed to draw diagrams. We were supposed to draw by hand (though I tended to use Eagle as being both faster and more legible) and he would tidy them up into schematics and then sort out the layout (there were complex 3-d constraints). This genius, on one of my circuits, had everything logically correct, but had redrawn a 1-8 decoder with the outputs no longer in numerical order... it makes debugging rather tricky when you see that. He also had a bad habit of not using click-to-grid, so he'd have apparent connections that missed by a micron or so, and so didn't get carried to the PCB... angry

 

 

Neil

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

barnacle wrote:

But regarding power - one thing I really liked about Eagle, and don't like about Kicad, was the automated power unless you explicitly break it out. So unless you told it otherwise, all your TTL chips were connected to the gnd/Vcc rails

 

My very first Eagle layout didn't do that (wrong defaults, or something?) and the board got made with every power pin on every chip connected to nothing at all.  It was not a very good first experience.  Since then, I've been manually 'breaking out' every power pin, gate, whatever, that I can find.  S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My very first Eagle layout didn't do that (wrong defaults, or something?) and the board got made with every power pin on every chip connected to nothing at all.  It was not a very good first experience.  Since then, I've been manually 'breaking out' every power pin, gate, whatever, that I can find.  S.

Whoops!!   I've been burned since some "oddball" packages, like sot-23-5 don't have 100% uniform pin numbering from all companies.  So an emitter connected to "pin4 "  for one company might be a different  "pin 4" for another's.

 

I remember some guys were gonna "go big" and use a 4-layer board with an internal power layer....took them a good while to realize there was no copper placed on that plane--not sure why it wasn't caught at the fab test (or if they had one done). ...the whole board was finding all kinds of sneak paths to sorta get some power here & there.  It was a large board so serious proto $$$ went in the can.  An edict came down that all boards would have their gerbers plotted and manually checked!!

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My fav(?). is pin layouts on negative voltage regulators.  Not Eagle's fault, that, just industry failure.  S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just read read this thread now, and I'm a bit surprised that nobody suggest to enable the WD on the avr!

Have an timer ISR that check your output and kick the "dog"  (and even in the product I think I would put a weak visible LED so everyone can see when it transmit).

 

I guess that most here, but perhaps not everyone, know that your cellphone camera can see an IR diode (I use it to check if it's the TV remote work) 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I guess that most here, but perhaps not everyone, know that your cellphone camera can see an IR diode (I use it to check if it's the TV remote work) 

 

One of my sons, studying mechanical engineering, is taking a class that teaches some basic electronics concepts.

One of their lab projects used a 38KHz IR LED transmitter aimed at a IR receiver "module", that then turned on and of a visilbe LED when the "IR beam" was intact or broken.

Cool little learning project.

 

It didn't work.

 

He asked for some help, so I first pulled out my $20 toy O'scope, (I wish I had a penny for every time I recommended one of these!), and looked at the driver signal.

 

Anyway, I'm off track on my story.

 

Problem #1 was that the IR Tx diode was aimed straight upwards, and he needed to bend the leads 90 degrees to aim it at the Rx module.

 

As part of the debugging / troubleshooting, I also told him that his cell phone camera could "see" the IR emitter, to help verify that it was working.

 

That, it turns out, worked fine on my Android Samsung S8 phone, but didn't work at all on his Apple cell phone!

 

I was quite surprised that the camera either included some sort of optical filter within the lens, or used a camera module that couldn't see into the IR spectrum.

 

Lessons learned!

 

JC

 

Edit: Typos

  

Last Edited: Mon. Nov 23, 2020 - 05:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would suspect that modern imaging sensors are equipped with such a filter by default. They all require an optical low pass filter to reduce the bandwidth of the image (i.e. intensity information, not the frequency of the light) and a colour filter to separate the RGB components of the image. Given that the IR is merely an extension of the red end, and as a bonus is out of focus, leading to flare, most sensors will include an IR filter as well - but the light from an IR LED is very very bright at close range. It may simply be that the apple chipset is better filtered at that particular frequency (there are two or three main bands into which IR leds and sensors fall).

 

Neil

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The newer phones are using lidar and infrared ranging techniques. You don't want little spots appearing in your pictures.