Yahoo Groups archive

AVR-Chat

Index last updated: 2026-04-28 22:41 UTC

Thread

ATMega16 I/O port protection diodes

ATMega16 I/O port protection diodes

2010-06-16 by Chuck Hackett

Background:

I am considering driving LEDs directly from the ATMega16 I/O pin (current
sink mode) to avoid having to use an additional driver chip, however, the
LEDs are located as much as 800 feet from the ATMega16 on an outdoor buried
CAT-5 cable (long story).

The max current rating of the I/O port is 40 ma so I'm planning on putting a
125 ohm resistor between the I/O pin and the cable to limit fault current
(wire shorted to Gnd) to 40 ma and protect the I/O pin.  

This means that, to deliver 10 ma @ 5v to the LED (assuming for the moment a
2v forward drop in the LED) I need a total R value of ~300 ohm.  The
additional ~175 ohm will be placed at the LED location as part of surge
protection at the LED (R + Transorb).  


Question:

The ATMega16's datasheet shows that the I/O pins have diodes from the pin to
Gnd and Vcc.  These would seem to protect the pin from surge voltages less
than Gnd or greater than Vcc but I do not see any specification as to what
the max current capability of these diodes is.

Knowing this will tell me what over/under voltages I can stand on the
outboard side of the 125 ohm resistor before having to consider placing
additional external surge protection on the pin (Transorb).

Re: [AVR-Chat] ATMega16 I/O port protection diodes

2010-06-16 by wagnerj@proaxis.com

> Background:
>
> I am considering driving LEDs directly from the ATMega16 I/O pin (current
> sink mode) to avoid having to use an additional driver chip, however, the
> LEDs are located as much as 800 feet from the ATMega16 on an outdoor
> buried
> CAT-5 cable (long story).
>
> The max current rating of the I/O port is 40 ma so I'm planning on putting
> a
> 125 ohm resistor between the I/O pin and the cable to limit fault current
> (wire shorted to Gnd) to 40 ma and protect the I/O pin.
>
> This means that, to deliver 10 ma @ 5v to the LED (assuming for the moment
> a
> 2v forward drop in the LED) I need a total R value of ~300 ohm.  The
> additional ~175 ohm will be placed at the LED location as part of surge
> protection at the LED (R + Transorb).
>
>
> Question:
>
> The ATMega16's datasheet shows that the I/O pins have diodes from the pin
> to
> Gnd and Vcc.  These would seem to protect the pin from surge voltages less
> than Gnd or greater than Vcc but I do not see any specification as to what
> the max current capability of these diodes is.
>
> Knowing this will tell me what over/under voltages I can stand on the
> outboard side of the 125 ohm resistor before having to consider placing
> additional external surge protection on the pin (Transorb).
>
>
Depending on where, in the world, this is being installed, it could last a
long time as you propose, or it could be toast by this time next year.
Here is the story -

I worked for a number of years for a company that makes video security
equipment. It became part of GE Security. There was a major installation
at Atlanta International Airport. Had long control runs and video coax in
plastic conduit buried to perimeter cameras. Almost every spring, they
would loose one or more cameras AND the video inputs to switchers would
get fried AND the RS485 control interfaces would get fried. It took
several years of sleuthing to figure out that near-by lightning strikes
resulted in a current sheet through the top several feet of the earth.
This would cause a very large voltage difference between the earth and the
wiring INSIDE the conduit (which was "referenced" to "ground" somewhere
outside of the current sheet). The voltage difference was so high that it
would arc through the conduit to both the RS485 control wiring and the
shield of the video coax. The resulting current spikes would then take out
video and controller hardware. Sometimes, it would take out the whole box
because it was current on the video ground shield that became current on
the equipment power system ground.

This is a tough one to protect against. I do NOT remember the details of
how we got the survival rate up (it never was totally immune). Simple
transorbs helped with the control lines but the video ground currents were
a different matter.

Jim,

Re: ATMega16 I/O port protection diodes

2010-06-17 by anickol

> Depending on where, in the world, this is being installed, it could 
> last a long time as you propose, or it could be toast by this time 
> next year.

This is the true statement, precisely describing the situation.


> It took
> several years of sleuthing to figure out that near-by lightning strikes
> resulted in a current sheet through the top several feet of the earth.

In fact, large voltage difference could appear even when there are no lightnings at all. Geophysists know about this, electronics engineers does not - this is a problem.

Re: [AVR-Chat] Re: ATMega16 I/O port protection diodes

2010-06-17 by Zack Widup

Electronics engineers who are also geophysicists know about it!
:-)

Zack

On Thu, Jun 17, 2010 at 2:20 AM, anickol <anickol@yahoo.com> wrote:

>
>
>
>
> > Depending on where, in the world, this is being installed, it could
> > last a long time as you propose, or it could be toast by this time
> > next year.
>
> This is the true statement, precisely describing the situation.
>
>
> > It took
> > several years of sleuthing to figure out that near-by lightning strikes
> > resulted in a current sheet through the top several feet of the earth.
>
> In fact, large voltage difference could appear even when there are no
> lightnings at all. Geophysists know about this, electronics engineers does
> not - this is a problem.
>
>  
>


[Non-text portions of this message have been removed]

Re: [AVR-Chat] ATMega16 I/O port protection diodes

2010-06-17 by David VanHorn

> The ATMega16's datasheet shows that the I/O pins have diodes from the pin to
> Gnd and Vcc.  These would seem to protect the pin from surge voltages less
> than Gnd or greater than Vcc but I do not see any specification as to what
> the max current capability of these diodes is.
>

They do tell you not to put any current through the protection diodes.
From a practical POV, I'd want to stay in the low microamp range..

Re: [AVR-Chat] ATMega16 I/O port protection diodes

2010-06-17 by David Kelly

On Thu, Jun 17, 2010 at 07:52:49AM -0600, David VanHorn wrote:
> > The ATMega16's datasheet shows that the I/O pins have diodes from
> > the pin to Gnd and Vcc. ?These would seem to protect the pin from
> > surge voltages less than Gnd or greater than Vcc but I do not see
> > any specification as to what the max current capability of these
> > diodes is.
> 
> They do tell you not to put any current through the protection diodes.
> From a practical POV, I'd want to stay in the low microamp range..

Go look for an Atmel app note on direct reading voltages from AC power
lines. Might have been one on building a power meter for AC. The app
note I'm thinking of showed a 1M high voltage resistor directly
connected to 240 VAC or 460 VAC and an AVR I/O pin relying on the
protection diodes in the AVR.

It went on with a disclaimer that there was no advertised spec as to
what those diodes could handle but 1mA was thought to be safe, and
directly connecting the CPU to AC was a bad idea if it also connected to
humans.

-- 
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

Re: [AVR-Chat] Re: ATMega16 I/O port protection diodes

2010-06-17 by Mike Bronosky

Like Jim pointed out, on outdoor runs lighting is a problem, especially when
it comes to devices that can only withstand very small voltages.

About 20 years ago where I worked we had two buildings located about 3000
feet apart on our facility. The Northern Telcom phone system, cameras,
Honeywell building environmental, security and fire alarm system and
intercom communications ran in conduits between the two building complexes.
This equipment had lighting protection, especially the Northern Telcom
telephone system. We had a great lighting storm one afternoon and just about
everything on copper went out. None of the fiber equipment was hurt. It is
my belief that when the lightning hit a tree, the current ran down the tree
into the ground and through the roots, the roots were wrapped around the
conduits and the heavy rapid current spike in the roots wrapped around the
metallic conductor induced a huge electrical surge in the metallic
conductors, the surge had no were to go but into the equipment on both ends.

One sure fire way we over come this is the use of fiber optic cables.

I forgot the name of the company we did use for protection on those lines
that could not be converted to fiber but there products worked very good.
This is a link to Black Box the picture you will see is a protection device
that is made by that company and marketed by Black Box as there own. Contact
them and see if they have anything the will protect 5VDC lines. Or will
provide you with their supplier.
http://www.blackbox.com/Store/Detail.aspx/RS-232-Surge-Protector-DB9/SP361A%C4%82R2

Another method you could use is a optical coupled IC. You need to protect
both ends.

Mike


On Thu, Jun 17, 2010 at 9:41 AM, Zack Widup <w9sz.zack@gmail.com> wrote:

> Electronics engineers who are also geophysicists know about it!
> :-)
>
> Zack
>
> On Thu, Jun 17, 2010 at 2:20 AM, anickol <anickol@yahoo.com> wrote:
>
> >
> >
> >
> >
> > > Depending on where, in the world, this is being installed, it could
> > > last a long time as you propose, or it could be toast by this time
> > > next year.
> >
> > This is the true statement, precisely describing the situation.
> >
> >
> > > It took
> > > several years of sleuthing to figure out that near-by lightning strikes
> > > resulted in a current sheet through the top several feet of the earth.
> >
> > In fact, large voltage difference could appear even when there are no
> > lightnings at all. Geophysists know about this, electronics engineers
> does
> > not - this is a problem.
> >
> >
> >
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


-- 
Linux since March 2004
www.counter.li.org
Registered Linux User: #482134
Taking up Linux Ubuntu and give-up the Windos habit.
Hasta la Vista, Baby. I won't be back!
Mike Bronosky
Mike@Bronosky.com


[Non-text portions of this message have been removed]

RE: [AVR-Chat] ATMega16 I/O port protection diodes

2010-06-18 by Chuck Hackett

Thanks for the feedback, my replies below:

> From: wagnerj@proaxis.com
> ....
> Depending on where, in the world ... it could last a
> long time as you propose, or it could be toast by this time next year.

... or, in Florida, the same time tomorrow! :-)

This product is for the outdoor ride-on railroad hobby.  There are clubs all
over the globe but I dare say that 99% on this list have never seen one
(typically 7.x" gauge track) so it's not a big market.  If I make some
money, great but the endeavor combines my interests in machining,
electronics design/dev, software design/dev and Live Steam Railroads
(http://whitetrout.net/Chuck/844/) 
 
My test site is north of Tampa, Florida, USA.  Florida is known for having
lots of lightning so it's a good test site from that aspect :-)

I want to protect from natural ground (dirt, not "Gnd") voltage gradients,
lightning induced ground voltage gradients (i.e.: nearby lightning), and
voltages induced on the field wiring via "antenna" effects, etc.

As with all things, this is a compromise.  The hobby won't support a "NASA"
style approach, I need to implement enough protection to protect against
common occurrences.  In the case of very close/direct strikes all bets are
off.

I have done a lot of looking into this but I am no expert.
Lightning/surges/Gnd loops, etc. are tricky things and industry has spent
millions addressing it.

At the moment I have two ATMega16 based controllers in field testing.  They
each drive two 3-LED signal heads.  One of the heads is local, 10 to 30 feet
away from the controller, and the other is located approximately 800 feet
away connected by 4 conductors in a buried CAT-5 cable.

Analog inputs to the ATMega16 are connected to sections of aluminum rail
which are about 800 feet long.  From the rails, these signals pass through a
125 ma fuse to a junction which, in turn, connects to a) 5k resistor to
+12dc (supplies voltage to the rail), b) 7 volt TVS (Transorb) diode (clamps
spikes to 7v), c) 100k resistor feeding the A/D pin of the ATMega16 which is
also bypassed to Gnd with a .001 mfd cap.  I put in the fuse to protect the
TVS in very strong spikes but none have blown yet.  I contemplated a
gas-discharge, inductor, TVS network here but, so far, it doesn't seem to
need it.  So far I have had no failures/blown fuses ... time will tell.  

The prototype controller drives the LED lines with a ULN2003AN driver with a
1k resistor between the driver and the cable.  I put the current-limiting
resistor at the driver end to protect against field wiring shorts.  I have
had no driver failures so far.

The signal heads themselves consisted of 3 LEDs connected to the CAT-5.
Here I was getting consistent failures of LEDs particularly in the "remote"
heads.  I believe that what was happening was that spikes/surges in the LED
forward bias direction were clamped by the LED but surges in the reverse
direction were allowed to rise above the reverse breakdown voltage of the
LED.  To address this as cheaply as possible I added a general purpose diode
connected in the reverse direction across the LED to clamp "reverse" surges.
So far it has lived through several storms, again, we'll see.

So, the impetuous for my question was an attempt to reduce board real
estate/parts count at the controller end while still providing an acceptable
level of protection.  I was looking at:

1) Keep the current design (outboard driver) (pro: it works so far, con:
board space, parts count)

2) Connect the LED cable directly to the ATMega16 with the LED
current-limiting resistor value split between a resistor on the controller
(to limit surge current to the pin) and another on the signal head (to limit
surge current there) using the pin protection diodes within the ATMega16 to
protect the pin.  (pro: reduces real estate/parts count, con: exposes the
ATMega16 to surges, will it be enough?, will it induce bad things into the
V+ line?).

3) External protection diodes from the pin to V+/Gnd.  I would need to
ensure that the forward drop of these diodes is less than or equal to that
of the ATMega16 diodes. (pro: simple, con: will it be enough?, will it
induce bad things into the V+ line?) 

One thing to note is that, if a part does fail (ATMega16 or driver), the
cost of the part is not significant compared to the incontinence of the
outage and the time to repair (I don't want to use sockets).  In elapsed
time/effort, it takes almost as long to replace a driver as it does to
replace an ATMega16.  Thus, if I can reasonably protect the ATMega16 pins to
the desired reliability level then why not do that and eliminate the extra
driver chip?


> From: David VanHorn
> ....
> They do tell you not to put any current through the protection diodes.
> From a practical POV, I'd want to stay in the low microamp range..

> From: David Kelly
> ....
> Go look for an Atmel app note on direct reading voltages from AC power
> lines. ....
> 
> It went on with a disclaimer that there was no advertised spec as to
> what those diodes could handle but 1mA was thought to be safe, and
> directly connecting the CPU to AC was a bad idea if it also connected
> to humans.

So, it would seem that the internal diodes do not have any significant
current-carrying capability and are mainly for ESD protection.  Thus, option
2 above seems out so I'll stick with some kind of outboard protection.


> From: Mike Bronosky
> ....
> One sure fire way we over come this is the use of fiber optic cables.

Hard to push LED current down a fiber :-)

I suppose I could put the LEDs on the controller and have three 800 foot
fibers to the signal head :-)

> ....
> This is a link to Black Box the picture you will see is a protection
> device
> that is made by that company and marketed by Black Box as there own.
> Contact
> them and see if they have anything the will protect 5VDC lines. Or will
> provide you with their supplier.

The device you referenced lists at $66 - no way my market would support
that.

I have looked into a lot of this type of device and most of them use some
combination of gas-discharge tube, inductor, TVS (Transorb) diode.  I can
incorporate these in my application, it's just a matter of "how much is good
enough".

One thought I had was to have a header on the prototype controllers for each
external connection and have a small daughter board providing the
protection.  I could start with very simple protection and replace the
daughter boards with more sophisticated protection as needed.


> From: Donald H
> ....
> This is a no brainer !!!
> 
> Why is this discussion happening !!!

I am discovering that, when trying to develop a commercially viable product
(i.e.: max functionality for least cost) there are lots of issues that would
seem to be "no brainer"s but can bring up lots of tradeoff issues.

> You can use a 2n3904 and 24 Volts DC source and Limit the current in
> the LED, resistors are cheap.

That's basically what I'm doing at the moment except that my current power
distribution bus is 12vdc and, for other reasons, I'm looking at going to
5vdc LED drive which reduces the current-limiting resistor and increases the
potential surge current ... tradeoffs ... tradeoffs ...

> Driving more then 4 inches from a microprocessor pin is just lazy and
> foolish.

The controller needs to drive two displays that are 800 feet apart so the
LEDs must be driven by a total of 800 feet no matter where the controller is
located.  How would you do it?

I am looking at using a smaller controller at the "remote" head but this
brings up yet more tradeoff/cost issues and I need to keep it simple at the
moment because there are a host of other issues yet to be addressed in the
system.

> $.22 of parts takes care of any problem.
> 
> And if the line gets spiked, you replace a 15 cent transistor not a
> microprocessor.

No "IF" about it, the lines WILL get struck!  

The question is an old one in risk management: the expected "frequency of a
given failure" .vs. the "impact of that failure" (time, money, etc.).  

It's the challenge of providing protection that reduces the "frequency of a
given failure" to the point where the cost of providing that protection is
acceptable when compared to the "impact of that failure".

One problem is that I do not have reliable data as to what level of surge to
expect and how often do they happen.  If I knew that "only one surge every 5
years would rise above X induced voltage" it would be a "no brainer".  I
think an outage every 5 years is acceptable so I'd test to voltage level "X"
and move on to other issues.
 
Cheers,

Chuck Hackett
"Good judgment comes from experience, experience comes from bad judgment"
7.5" gauge Union Pacific Northern (4-8-4) 844
http://www.whitetrout.net/Chuck

Re: ATMega16 I/O port protection diodes

2010-06-18 by Donald H

About 20 years ago I help a young guy design a Hot Tub controller.

At the tub was an LCD display and a few buttons that show the user what was going on, at the equipment room (high voltage) were pumps, heaters, blowers, relays for lights.

The guy wanted to use two 68hc05 controllers, one at the tub end and one at the high voltage room.

The two schematics were laying side-by-side on the table with a connector on each page with the same signal names.

I asked if the two chips were side-by-side on the PCB.

He proudly says, "there will be 200 feet of wire between them."


Same problems, same solution.

Two micro controllers with a rs-485 chip between them.

Each chip talks to the other chip via their async serial ports,
the same way you talk to a PC.

An rs-485 chip can drive 1000 feet of cable, and properly terminated can withstand a low voltage lighting hit.

A 18-pin PIC on the LED end and what ever you want on the controlling end.

Simple call-and-response system will give you more then enough communication to light up a few LEDs.

After you do this for the first time, you will have a library of functions to use again and again.

Robust and simple, cheaper then you think.

After you replace a few processor boards, the cost of doing a real design is better then fixing an on-going problem.

don

Re: [AVR-Chat] Re: ATMega16 I/O port protection diodes

2010-06-19 by hossein hashemi

ok,thank Donald
i need to study more about it.i subsituitly  come here later.
thank a lot.:)





________________________________
Show quoted textHide quoted text
From: Donald H <donhamilton2002@yahoo.com>
To: AVR-Chat@yahoogroups.com
Sent: Sat, June 19, 2010 3:14:18 AM
Subject: [AVR-Chat] Re: ATMega16 I/O port protection diodes

  
About 20 years ago I help a young guy design a Hot Tub controller.

At the tub was an LCD display and a few buttons that show the user what was going on, at the equipment room (high voltage) were pumps, heaters, blowers, relays for lights.

The guy wanted to use two 68hc05 controllers, one at the tub end and one at the high voltage room.

The two schematics were laying side-by-side on the table with a connector on each page with the same signal names.

I asked if the two chips were side-by-side on the PCB.

He proudly says, "there will be 200 feet of wire between them."

Same problems, same solution.

Two micro controllers with a rs-485 chip between them.

Each chip talks to the other chip via their async serial ports,
the same way you talk to a PC.

An rs-485 chip can drive 1000 feet of cable, and properly terminated can withstand a low voltage lighting hit.

A 18-pin PIC on the LED end and what ever you want on the controlling end.

Simple call-and-response system will give you more then enough communication to light up a few LEDs.

After you do this for the first time, you will have a library of functions to use again and again.

Robust and simple, cheaper then you think.

After you replace a few processor boards, the cost of doing a real design is better then fixing an on-going problem.

don


 


      

[Non-text portions of this message have been removed]

RE: [AVR-Chat] Re: ATMega16 I/O port protection diodes

2010-06-19 by Chuck Hackett

> From: Donald H
> ....
> At the tub was an LCD display and a few buttons that show the user what
> was going on, at the equipment room (high voltage) were pumps, heaters,
> blowers, relays for lights.
> 
> ....
> I asked if the two chips were side-by-side on the PCB.
> 
> He proudly says, "there will be 200 feet of wire between them."
> 
> Same problems, same solution.
> 
> Two micro controllers with a rs-485 chip between them.
> ....

I was originally going to use RS-485 but I have decided to use a modified
version of a CAN bus instead.  

The solution you mentioned above is what I eluded to when I said:

"I am looking at using a smaller controller at the "remote" head but this
brings up yet more tradeoff/cost issues and I need to keep it simple at the
moment because there are a host of other issues yet to be addressed in the
system."

The "small controller" I mentioned above is exactly that, a small device
that supports a signal head and shares the same power/data bus that will be
used by the controllers to talk to each other.  The reason I'm currently
driving an LED signal head 800 feet away is for (at least) two reasons:

First: I have not finished designing and testing the communications link
(CAN bus) that will eventually allow all of the components to talk to each
other but this club needed some traffic control immediately.  At the moment
I have two controllers in the field supporting two independent sections of
track.  The ability for the sections to coordinate with each other as well
as other capabilities will be added later.  So, for the moment, the remote
head is driven directly via wire.

Second: The two signal heads attached to the controller ensure that only one
train is allowed into the track monitored by the controller.  To do this, an
approaching train is sensed (before entering the track in question).  If the
controller decides that it may enter, the signal at the far end of the track
MUST go from green to red before (or at the same instant as) the signal for
the entering train goes to green.  This is obviously easy to satisfy if the
signals are directly connected to the same controller.  To satisfy this
requirement over a communications link (with latency, errors, etc.) requires
asynchronous coordination which complicates other things that the controller
is doing, and may even cancel the need for the remote signal to go to red,
hence, I'm avoiding these complications for the moment with wire to the
remote head --- but, I do agree that that is where I need to end up.  Gota
crawl before you can run :-) 

I have about 30 years of experience with different communications methods,
protocols, etc, (Async tty, bisync, SDLC, X25, TCP/IP, custom protocols,
etc., etc.) on mini-computers for applications from financial online
transaction processing to data radio and train control for Union Pacific.
So I've been around this tree before and know where a lot of the potholes
are -- not to say that I might miss one and drop down a black hole for a bit
(no pun intended)  :-)

Now, my experience with microcontrollers, surge protection, PCB board layout
is more limited but I'm learning thanks to lists like this one,
Electronics101, etc.
 
Cheers,

Chuck Hackett
"Good judgment comes from experience, experience comes from bad judgment"
7.5" gauge Union Pacific Northern (4-8-4) 844
http://www.whitetrout.net/Chuck

"RS"-485 vs CAN (was ATMega16 I/O port protection diodes)

2010-06-19 by ecros_technology

I've been following this thread, which started as a simple question about the safe current carrying capacity of input protection diodes and morphed into tales of lightning strikes damaging equipment, but now I have a question about the turn it is taking.

TIA/EIA-485 was designed from the outset to operate over long distances and transceivers are generally designed to be robust in the presence of the kind of interference and induced high voltages that are common in long distance data transmission.  When used with the UART that just about every microcontroller has and a simple master / slave protocol (especially where the choice of a master node is "obvious"), the system is simple, reliable and easy to monitor and "debug".

CAN was designed for communication on a network within a vehicle.  Although it is eaily adaptable to room or even small building distances, there is nothing about it that makes it suitable for long outdoor runs.  Transceivers expect to be exposed to interference, but not induced high voltages.  The physical layer protocol is complicated and finicky to set up and you either have to buy or make some kind of sniffer to monitor bus traffic.

So, whence the enthusiasm for CAN on this project?

Graham.

RE: [AVR-Chat] Re: ATMega16 I/O port protection diodes

2010-06-19 by Dave McLaughlin

Hi Chuck,

 

CAN bus is a great way to go with your project. Once you get over the hurdle
of figuring out how the controller works then you won't go back to using the
likes of RS485 again. :o)

 

If you want to avoid having a microcontroller at your signal ends you could
consider the Microchip MCP202X devices. These give you digital and analog
inputs and outputs on your bus without a micro. You could then use one of
the Atmel AVR devices with CAN bus built in or go for using the Microchip
MCP2515 CAN controller and use SPI from any of the Atmel micros. This is
easy and there is code out there for this or if you ask me nicely I can give
you some code to get you going. I have used it on the AT90S2313 and the
ATMega32 in the past.

 

The great thing about CAN is you don't need a master to send and request
messages. You simply setup the devices to send data as and when they want
and your devices simply listen for messages they are interested in. You can
filter messages for them too.

 

Good luck with it. I am sure you will find it rewarding when you have it all
working. Great thing is that you can build and test this on the desk and see
it all working before you roll it out. If you are designing your own
controllers and boards you can make it generic so that you only need to
design one unit to do all and then is simply software etc!

 

Have fun.

 

Dave.
Show quoted textHide quoted text
From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
Of Chuck Hackett
Sent: 19 June 2010 13:10
To: AVR-Chat@yahoogroups.com
Subject: RE: [AVR-Chat] Re: ATMega16 I/O port protection diodes

 

  

I was originally going to use RS-485 but I have decided to use a modified
version of a CAN bus instead. 

The solution you mentioned above is what I eluded to when I said:

"I am looking at using a smaller controller at the "remote" head but this
brings up yet more tradeoff/cost issues and I need to keep it simple at the
moment because there are a host of other issues yet to be addressed in the
system."

The "small controller" I mentioned above is exactly that, a small device
that supports a signal head and shares the same power/data bus that will be
used by the controllers to talk to each other. The reason I'm currently
driving an LED signal head 800 feet away is for (at least) two reasons:

First: I have not finished designing and testing the communications link
(CAN bus) that will eventually allow all of the components to talk to each
other but this club needed some traffic control immediately. At the moment
I have two controllers in the field supporting two independent sections of
track. The ability for the sections to coordinate with each other as well
as other capabilities will be added later. So, for the moment, the remote
head is driven directly via wire.

Second: The two signal heads attached to the controller ensure that only one
train is allowed into the track monitored by the controller. To do this, an
approaching train is sensed (before entering the track in question). If the
controller decides that it may enter, the signal at the far end of the track
MUST go from green to red before (or at the same instant as) the signal for
the entering train goes to green. This is obviously easy to satisfy if the
signals are directly connected to the same controller. To satisfy this
requirement over a communications link (with latency, errors, etc.) requires
asynchronous coordination which complicates other things that the controller
is doing, and may even cancel the need for the remote signal to go to red,
hence, I'm avoiding these complications for the moment with wire to the
remote head --- but, I do agree that that is where I need to end up. Gota
crawl before you can run :-) 

I have about 30 years of experience with different communications methods,
protocols, etc, (Async tty, bisync, SDLC, X25, TCP/IP, custom protocols,
etc., etc.) on mini-computers for applications from financial online
transaction processing to data radio and train control for Union Pacific.
So I've been around this tree before and know where a lot of the potholes
are -- not to say that I might miss one and drop down a black hole for a bit
(no pun intended) :-)

Now, my experience with microcontrollers, surge protection, PCB board layout
is more limited but I'm learning thanks to lists like this one,
Electronics101, etc.
 
Cheers,

Chuck Hackett





[Non-text portions of this message have been removed]

RE: [AVR-Chat] "RS"-485 vs CAN (was ATMega16 I/O port protection diodes)

2010-06-19 by Dave McLaughlin

Hi Graham,

 

Personally, I beg to differ on the distance. CAN has now been recognised for
use in aviation and on large aircraft it is going to be some cable distance
from some nodes. I have also successfully in the past run on an ROV
umbilical of 1500m with albeit a slower bus rate of 10Kbps but it worked
extremely reliably with all nodes surface and subsea getting the messages
with no loss of transmission. We put transorbs on the line to protect from
the potential of 1100V from the electronics being shorted to the bus if
water got in the connectors. We did find some transorbs expanded to due to
shorting failures but after replacing them, the bus still worked.

 

I have also used RS485 over the same umbilical and yes, it does work very
well but as we increased the number of nodes, the speed at which we could
communicate between them dropped and we had issues with this for control.
With the change to CAN bus we had a faster throughput because we no longer
had the issue of one master in control and sending and requesting the data.
For more modern ROV's we have changed to Ethernet based communications
surface to subsea as we now have fibre optic links but we still use CAN bus
for the inter vehicle control because of the ease of which to add nodes
without any new programming of the master to request data from it.

 

The real reason for suggesting to Chuck the use of CAN is the simple nature
to which you can add nodes and no need for a master to know about them. They
simply send their data as and when they want or are programmed to do so and
any node on the network can do what it wants with that data.! Can also
allows all devices to acknowledge each message whereas with RS484 if you
want to send to multiple nodes, you have to send a separate message to each
or send a broadcast message but each slave cannot simply reply to it as they
can't all send on the bus at the same time, but with CAN any node not
getting the message correctly can indicate this failure and the unit will
resend until all accept it or a bus error is detected!

 

Cheers,
Dave.
Show quoted textHide quoted text
From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
Of ecros_technology
Sent: 19 June 2010 19:15
To: AVR-Chat@yahoogroups.com
Subject: [AVR-Chat] "RS"-485 vs CAN (was ATMega16 I/O port protection
diodes)

 

  

I've been following this thread, which started as a simple question about
the safe current carrying capacity of input protection diodes and morphed
into tales of lightning strikes damaging equipment, but now I have a
question about the turn it is taking.

TIA/EIA-485 was designed from the outset to operate over long distances and
transceivers are generally designed to be robust in the presence of the kind
of interference and induced high voltages that are common in long distance
data transmission. When used with the UART that just about every
microcontroller has and a simple master / slave protocol (especially where
the choice of a master node is "obvious"), the system is simple, reliable
and easy to monitor and "debug".

CAN was designed for communication on a network within a vehicle. Although
it is eaily adaptable to room or even small building distances, there is
nothing about it that makes it suitable for long outdoor runs. Transceivers
expect to be exposed to interference, but not induced high voltages. The
physical layer protocol is complicated and finicky to set up and you either
have to buy or make some kind of sniffer to monitor bus traffic.

So, whence the enthusiasm for CAN on this project?

Graham.



[Non-text portions of this message have been removed]

Re: [AVR-Chat] Re: ATMega16 I/O port protection diodes

2010-06-23 by Philippe Habib

How about using a separate power supply for the LEDs and some  
optoisolators between your processor and the LEDs.  That way only the  
LEDs, and maybe some optos can get fried.

I worked on some devices that were designed to take a hit from a  
patient being defrillated and keep on ticking.  That meant isolated  
power supplies, big air gaps on the PCB, and serious opto isolators.   
Then an increasing series of devices to absorb the hits ranging from  
solid state surge protectors to gas tubes.  You can make stuff that  
will take a few kV and survive if you really need to.
Show quoted textHide quoted text
On Jun 18, 2010, at 3:44 PM, Donald H wrote:

> About 20 years ago I help a young guy design a Hot Tub controller.
>
> At the tub was an LCD display and a few buttons that show the user  
> what was going on, at the equipment room (high voltage) were pumps,  
> heaters, blowers, relays for lights.
>
> The guy wanted to use two 68hc05 controllers, one at the tub end and  
> one at the high voltage room.
>
> The two schematics were laying side-by-side on the table with a  
> connector on each page with the same signal names.
>
> I asked if the two chips were side-by-side on the PCB.
>
> He proudly says, "there will be 200 feet of wire between them."
>
>
> Same problems, same solution.
>
> Two micro controllers with a rs-485 chip between them.
>
> Each chip talks to the other chip via their async serial ports,
> the same way you talk to a PC.
>
> An rs-485 chip can drive 1000 feet of cable, and properly terminated  
> can withstand a low voltage lighting hit.
>
> A 18-pin PIC on the LED end and what ever you want on the  
> controlling end.
>
> Simple call-and-response system will give you more then enough  
> communication to light up a few LEDs.
>
> After you do this for the first time, you will have a library of  
> functions to use again and again.
>
> Robust and simple, cheaper then you think.
>
> After you replace a few processor boards, the cost of doing a real  
> design is better then fixing an on-going problem.
>
> don
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.