Driver to drive?

[josephkk]

On Wed, 23 Apr 2014 21:08:38 -0400, Phil Hobbs <hobbs@electrooptical.net>
wrote:

That is not a problem with Fortran, rather the problem was that the
hardware platforms behave differently. The IEEE floating point
standard helped to clear out some of this mess.


The denormal problem was _introduced_ by IEEE floating point, iirc.

Cheers

Phil Hobbs

IEEE 854 formalized the terminology, but underflow was already being dealt
with in DEC VAXes and likely IBM 370s.

Denormals are intended as a way to handle underflow gracefully, rather
than brutally setting all such numbers to zero like an oppressive white
male. (But I repeat myself.)

Normally floats are implemented as a binary fraction (significand) and
an exponent, which is usually base-2 but sometimes (as in the old IBM
format) base-16.

Base 16 is just a compaction of binary for easier readability. The real
difference it made is that the exponent was base 16 as well so the lead
digit could be anything from 1 to F. They also used the same hardware to
implement BCD floating point since the 360 series.

If the exponent is binary, the leading bit of the significand is always
a 1, unless the number is identically zero. Thus IEEE and various other
base-2 formats take advantage of this free bit and don't bother storing
it, which gives them a factor of 2 increase in precision in ordinary
circumstances.

However, when the exponent reaches its maximum negative value, there's
no room left. In order to make the accuracy of computations degrade
gracefully in that situation, i.e. to make such a number distinguishable
from zero, the IEEE specification allows "denormalized numbers", i.e.
those in which the leading bit of the significand is not 1.

The problem is that denormals are considered so rare that AFAIK FPU
designers don't implement them in silicon, but rather in microcode.
Hence the speed problem.

Cheers

Phil Hobbs

 

[Joe Gwinn]

In article <t5OdnQqAMe-kg8TOnZ2dnUVZ_uSdnZ2d@supernews.com>, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

On 04/24/2014 09:37 AM, Joe Gwinn wrote:
In article <53586416.8050105@electrooptical.net>, Phil Hobbs
hobbs@electrooptical.net> wrote:

[snip]

I first ran into such [denorm] issues when doing polynomial approximations to
functions too complicated to compute in realtime. The resulting
polynomials (or rational polynomials) were solved using 32-bit
fixed-point arithmetic. Unity scaling of the polynomial variable x was
essential.

It seems to me that the root cause of the denormalized numbers is
trying to do everything in unscaled SI units. If one formulates the
problem such that variable values are roughly centered on unity, in
most problem domains the underflows and overflows will vanish.

If not, reformulation to operate in the log domain may be useful.

Joe Gwinn


No, the issue is that in a FDTD code, when you turn on the source, the
real fields propagate at approximately c. However, since you're
iterating through all of main memory twice per full time step, the
roundoff errors propagate superluminally and fill the domain with
denormals until the real fields get there.

A combination of initializing the domain with small amounts of properly
normalized noise, and the right compiler switches, fixed it.

Ahh. Interesting. Never used or built FDTD code (read about it
though), or anything faster than light.

Joe Gwinn

 

[Joe Gwinn]

In article <250420141048402039%joegwinn@comcast.net>, Joe Gwinn
<joegwinn@comcast.net> wrote:

In article <t5OdnQqAMe-kg8TOnZ2dnUVZ_uSdnZ2d@supernews.com>, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

On 04/24/2014 09:37 AM, Joe Gwinn wrote:
In article <53586416.8050105@electrooptical.net>, Phil Hobbs
hobbs@electrooptical.net> wrote:

[snip]

I first ran into such [denorm] issues when doing polynomial
approximations to
functions too complicated to compute in realtime. The resulting
polynomials (or rational polynomials) were solved using 32-bit
fixed-point arithmetic. Unity scaling of the polynomial variable x was
essential.

It seems to me that the root cause of the denormalized numbers is
trying to do everything in unscaled SI units. If one formulates the
problem such that variable values are roughly centered on unity, in
most problem domains the underflows and overflows will vanish.

If not, reformulation to operate in the log domain may be useful.

Joe Gwinn


No, the issue is that in a FDTD code, when you turn on the source, the
real fields propagate at approximately c. However, since you're
iterating through all of main memory twice per full time step, the
roundoff errors propagate superluminally and fill the domain with
denormals until the real fields get there.

A combination of initializing the domain with small amounts of properly
normalized noise, and the right compiler switches, fixed it.

Ahh. Interesting. Never used or built FDTD code (read about it
though), or anything faster than light.

And an afterthought: Is this "properly normalized noise' shaped to
look like vacuum fluctuations (where particles flicker in and out of
existence, right at the edge of the uncertainty principle)?

Joe Gwinn

 

[Phil Hobbs]

On 04/25/2014 10:48 AM, Joe Gwinn wrote:

In article <t5OdnQqAMe-kg8TOnZ2dnUVZ_uSdnZ2d@supernews.com>, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

On 04/24/2014 09:37 AM, Joe Gwinn wrote:
In article <53586416.8050105@electrooptical.net>, Phil Hobbs
hobbs@electrooptical.net> wrote:

[snip]

I first ran into such [denorm] issues when doing polynomial approximations to
functions too complicated to compute in realtime. The resulting
polynomials (or rational polynomials) were solved using 32-bit
fixed-point arithmetic. Unity scaling of the polynomial variable x was
essential.

It seems to me that the root cause of the denormalized numbers is
trying to do everything in unscaled SI units. If one formulates the
problem such that variable values are roughly centered on unity, in
most problem domains the underflows and overflows will vanish.

If not, reformulation to operate in the log domain may be useful.

Joe Gwinn


No, the issue is that in a FDTD code, when you turn on the source, the
real fields propagate at approximately c. However, since you're
iterating through all of main memory twice per full time step, the
roundoff errors propagate superluminally and fill the domain with
denormals until the real fields get there.

A combination of initializing the domain with small amounts of properly
normalized noise, and the right compiler switches, fixed it.

Ahh. Interesting. Never used or built FDTD code (read about it
though), or anything faster than light.

Joe Gwinn

FDTD takes a lot of memory, but being a time-domain thing, it can model
time-dependent systems such as photoresist or nonlinear optics. I sort
of backed into needing to code my own--I needed an optimizing simulator
to design very nonintuitive devices (near-IR metal antennas coupled to
0.25x0.45 micron SOI waveguides), and I couldn't buy one at the time
(2004ish).

So I took a well-tested FDTD engine, Berkeley Tempest 6.0, for which I
had the source, and wrapped it in a giant REXX script that functioned
like a math program, geometry generator, and optimizer. It took about
three or four months, but it worked great.

Then I ran out of CPU cycles, so I wrote a clusterized FDTD that used
the same subset of the TEMPEST syntax that I'd used in the script, and
added some cluster-specific stuff. On a 14-core cluster (7 dual Opteron
boxes), it ran about 12 times as fast as the uniprocessor version, and
more than 20 times faster than TEMPEST on the same hardware. It was
nice having TEMPEST to compare with, because that let me do
apples-to-apples sanity checks on the same exact simulation. That sped
up debugging a lot, I can tell you. The Linux thread scheduler is
completely fascist--if you aren't root, you can't even _reduce_ the
priority of some of your own threads to indicate which ones are
time-critical, and if you are root, making one thread real time priority
makes threads in the process real time, and the user interface freezes
till the computation is done. Brain dead.

Coding something like that wasn't really in my job description, so I had
to do it as a part-time task, but I had a lot of fun doing it.

There's still some obscure bug in the dispersive metal support (metals
like copper, silver, and gold, where n < k, i.e. the real part of the
dielectric constant is negative). I'll fix it one of these days.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net

 

[Phil Hobbs]

On 04/25/2014 11:27 AM, Joe Gwinn wrote:

In article <250420141048402039%joegwinn@comcast.net>, Joe Gwinn
joegwinn@comcast.net> wrote:

In article <t5OdnQqAMe-kg8TOnZ2dnUVZ_uSdnZ2d@supernews.com>, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

On 04/24/2014 09:37 AM, Joe Gwinn wrote:
In article <53586416.8050105@electrooptical.net>, Phil Hobbs
hobbs@electrooptical.net> wrote:

[snip]

I first ran into such [denorm] issues when doing polynomial
approximations to
functions too complicated to compute in realtime. The resulting
polynomials (or rational polynomials) were solved using 32-bit
fixed-point arithmetic. Unity scaling of the polynomial variable x was
essential.

It seems to me that the root cause of the denormalized numbers is
trying to do everything in unscaled SI units. If one formulates the
problem such that variable values are roughly centered on unity, in
most problem domains the underflows and overflows will vanish.

If not, reformulation to operate in the log domain may be useful.

Joe Gwinn


No, the issue is that in a FDTD code, when you turn on the source, the
real fields propagate at approximately c. However, since you're
iterating through all of main memory twice per full time step, the
roundoff errors propagate superluminally and fill the domain with
denormals until the real fields get there.

A combination of initializing the domain with small amounts of properly
normalized noise, and the right compiler switches, fixed it.

Ahh. Interesting. Never used or built FDTD code (read about it
though), or anything faster than light.

And an afterthought: Is this "properly normalized noise' shaped to
look like vacuum fluctuations (where particles flicker in and out of
existence, right at the edge of the uncertainty principle)?

Joe Gwinn

No, it's just white Gaussian noise, because if you just use DC, it all
disappears on the next time step.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net

 

[Joe Gwinn]

In article <2s-dnW66dJhmOcfOnZ2dnUVZ_j2dnZ2d@supernews.com>, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

On 04/25/2014 10:48 AM, Joe Gwinn wrote:
In article <t5OdnQqAMe-kg8TOnZ2dnUVZ_uSdnZ2d@supernews.com>, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

On 04/24/2014 09:37 AM, Joe Gwinn wrote:
In article <53586416.8050105@electrooptical.net>, Phil Hobbs
hobbs@electrooptical.net> wrote:

[snip]

I first ran into such [denorm] issues when doing polynomial
approximations to
functions too complicated to compute in realtime. The resulting
polynomials (or rational polynomials) were solved using 32-bit
fixed-point arithmetic. Unity scaling of the polynomial variable x was
essential.

It seems to me that the root cause of the denormalized numbers is
trying to do everything in unscaled SI units. If one formulates the
problem such that variable values are roughly centered on unity, in
most problem domains the underflows and overflows will vanish.

If not, reformulation to operate in the log domain may be useful.

Joe Gwinn


No, the issue is that in a FDTD code, when you turn on the source, the
real fields propagate at approximately c. However, since you're
iterating through all of main memory twice per full time step, the
roundoff errors propagate superluminally and fill the domain with
denormals until the real fields get there.

A combination of initializing the domain with small amounts of properly
normalized noise, and the right compiler switches, fixed it.

Ahh. Interesting. Never used or built FDTD code (read about it
though), or anything faster than light.

Joe Gwinn


FDTD takes a lot of memory, but being a time-domain thing, it can model
time-dependent systems such as photoresist or nonlinear optics. I sort
of backed into needing to code my own--I needed an optimizing simulator
to design very nonintuitive devices (near-IR metal antennas coupled to
0.25x0.45 micron SOI waveguides), and I couldn't buy one at the time
(2004ish).

So I took a well-tested FDTD engine, Berkeley Tempest 6.0, for which I
had the source, and wrapped it in a giant REXX script that functioned
like a math program, geometry generator, and optimizer. It took about
three or four months, but it worked great.

Then I ran out of CPU cycles, so I wrote a clusterized FDTD that used
the same subset of the TEMPEST syntax that I'd used in the script, and
added some cluster-specific stuff. On a 14-core cluster (7 dual Opteron
boxes), it ran about 12 times as fast as the uniprocessor version, and
more than 20 times faster than TEMPEST on the same hardware. It was
nice having TEMPEST to compare with, because that let me do
apples-to-apples sanity checks on the same exact simulation.

Interesting. And yes, having an oracle is priceless in debugging
algorithmic code. I would do analysis in Mathematica, and use it to
generate test case to which the C/C++ must comply to six places.

That sped
up debugging a lot, I can tell you. The Linux thread scheduler is
completely fascist--if you aren't root, you can't even _reduce_ the
priority of some of your own threads to indicate which ones are
time-critical, and if you are root, making one thread real time priority
makes threads in the process real time, and the user interface freezes
till the computation is done. Brain dead.

I don't know if Linux had this in 2004, but the standard POSIX solution
(there is 95% overlap with Linux nowadays) is to choose your scheduling
scope to be threads (versus processes).

Coding something like that wasn't really in my job description, so I had
to do it as a part-time task, but I had a lot of fun doing it.

If the LinkedIn photo on the net is current, you already possess the
required beard.

There's still some obscure bug in the dispersive metal support (metals
like copper, silver, and gold, where n < k, i.e. the real part of the
dielectric constant is negative). I'll fix it one of these days.

When the right job comes along.


Joe Gwinn

 

[amdx]

On 4/27/2014 12:39 AM, ehsjr wrote:

Bright lights!

Two of these: MPJA # 31325 OP "1000 Lumen, 10W, Super Bright,
Cool White LED Module" running at 1/2 power outperform two
of these: 20 Watt, 24 Inch T12 Cool White Fluorescent Bulb,
in my garage. I haven't measured it, but everyone who has
seen A/B testing (fluorescent vs LED modules) said "wow, that's
much brighter" when the LEDs were on and the fluorescent off.
The A/B testing was looking at the floor, not at the modules
or the fluorescent tubes.

Here's the details:

I had to replace my old wood garage door. The new steel door looks
good, but when open it blocks the ceiling fluorescent (24", 2 bulb)
fixture. (The windows in the old door let the light shine through
to the floor when the door is up, but the windows in the new door
don't line up with the light.)

I installed 10W no-name LED modules (MPJA # 31325 OP "1000 Lumen,
10W, Super Bright, Cool White LED Module") on the inside of the
door (the side the faces the garage floor when the door is open)
on the center frame members of 2 door panels. The steel frame
member is an L shaped 18" long and 2 1/2" wide on one leg of the
L, and 2" wide on the other, and is welded to the steel door panel.
It's essentially an infinite (but inefficient) heat sink. I hung
2 copper braids made from coaxial cable shield from the ceiling
and ran 12.7 volts DC to them. I built a T out of wood and 2 copper
(1/2 dia) pipes and installed it on the top panel of the door.
When the door is about 2 inches from fully open the copper pipes
on the T contact the hanging copper braid. Wires from the pipes
on the T connect to the LED modules mounted on two door panel
center framing members.

copper copper
==+=== ===+==
-------------- | | | | -----------
| | |wood| | |
| | | | | |
| | ---- | |
| door | | |
| +-module-+ |
. | | .
. +-module-+ .
. .
| |
-------------------------------------

Ed, Is this wood/copper pipe assembly a switch to turn on the LEDs?
It's not clear to "me", what this is all about.
Mikek

 

On Mon, 28 Apr 2014 00:56:51 -0400, ehsjr <ehsjr@mverizon.net> wrote:

The pipes are contacts to bring 12 volts to the door.
When the door goes up and travels to its final position,
the copper pipes attached to the door come into contact
with two pieces of copper braid spaced about 12" apart that
are attached to the ceiling. The supply voltage is connected
to the copper braid, gnd to one braid, +12 to the other.

A garage would be the last place to using a sparking contacts.

Some amount of gasoline fumes in the air and some sparks and ......

 

[ehsjr]

On 4/27/2014 10:01 AM, amdx wrote:

On 4/27/2014 12:39 AM, ehsjr wrote:

Bright lights!

Two of these: MPJA # 31325 OP "1000 Lumen, 10W, Super Bright,
Cool White LED Module" running at 1/2 power outperform two
of these: 20 Watt, 24 Inch T12 Cool White Fluorescent Bulb,
in my garage. I haven't measured it, but everyone who has
seen A/B testing (fluorescent vs LED modules) said "wow, that's
much brighter" when the LEDs were on and the fluorescent off.
The A/B testing was looking at the floor, not at the modules
or the fluorescent tubes.

Here's the details:

I had to replace my old wood garage door. The new steel door looks
good, but when open it blocks the ceiling fluorescent (24", 2 bulb)
fixture. (The windows in the old door let the light shine through
to the floor when the door is up, but the windows in the new door
don't line up with the light.)

I installed 10W no-name LED modules (MPJA # 31325 OP "1000 Lumen,
10W, Super Bright, Cool White LED Module") on the inside of the
door (the side the faces the garage floor when the door is open)
on the center frame members of 2 door panels. The steel frame
member is an L shaped 18" long and 2 1/2" wide on one leg of the
L, and 2" wide on the other, and is welded to the steel door panel.
It's essentially an infinite (but inefficient) heat sink. I hung
2 copper braids made from coaxial cable shield from the ceiling
and ran 12.7 volts DC to them. I built a T out of wood and 2 copper
(1/2 dia) pipes and installed it on the top panel of the door.
When the door is about 2 inches from fully open the copper pipes
on the T contact the hanging copper braid. Wires from the pipes
on the T connect to the LED modules mounted on two door panel
center framing members.

copper copper
==+=== ===+==
-------------- | | | | -----------
| | |wood| | |
| | | | | |
| | ---- | |
| door | | |
| +-module-+ |
. | | .
. +-module-+ .
. .
| |
-------------------------------------


Ed, Is this wood/copper pipe assembly a switch to turn on the LEDs?
It's not clear to "me", what this is all about.
Mikek

Hi Mike,

The pipes are contacts to bring 12 volts to the door.
When the door goes up and travels to its final position,
the copper pipes attached to the door come into contact
with two pieces of copper braid spaced about 12" apart that
are attached to the ceiling. The supply voltage is connected
to the copper braid, gnd to one braid, +12 to the other.


Edge view door in closed position

========================================== <- ceiling
|
O <-pipe |
]| |
]| <- wood | <-braid
]| |
]
]* <-LED module
]
]* <-LED module
]
] <- door
]
.
.
.
]



Edge view door in open position

========================================= <- ceiling
\ <- braid
-------------------------- \
^^^^ pipe -> O\
door |

This method avoids having a cord that would flex every time
the door opened or closed, and would hang down 4 or 5 feet
from the ceiling when the door is open.

Ed

 

On Monday, April 28, 2014 2:08:09 AM UTC-4, upsid...@downunder.com wrote:

On Mon, 28 Apr 2014 00:56:51 -0400, ehsjr <ehsjr@mverizon.net> wrote:



The pipes are contacts to bring 12 volts to the door.

When the door goes up and travels to its final position,

the copper pipes attached to the door come into contact

with two pieces of copper braid spaced about 12" apart that

are attached to the ceiling. The supply voltage is connected

to the copper braid, gnd to one braid, +12 to the other.



A garage would be the last place to using a sparking contacts.



Some amount of gasoline fumes in the air and some sparks and ......

Those fumes are supposed to be contained these days.

 

On Sunday, April 27, 2014 1:39:11 AM UTC-4, ehsjr wrote:

Bright lights!



Two of these: MPJA # 31325 OP "1000 Lumen, 10W, Super Bright,

Cool White LED Module" running at 1/2 power outperform two

of these: 20 Watt, 24 Inch T12 Cool White Fluorescent Bulb,

in my garage. I haven't measured it, but everyone who has

seen A/B testing (fluorescent vs LED modules) said "wow, that's

much brighter" when the LEDs were on and the fluorescent off.

The A/B testing was looking at the floor, not at the modules

or the fluorescent tubes.



Here's the details:



I had to replace my old wood garage door. The new steel door looks

good, but when open it blocks the ceiling fluorescent (24", 2 bulb)

fixture. (The windows in the old door let the light shine through

to the floor when the door is up, but the windows in the new door

don't line up with the light.)



I installed 10W no-name LED modules (MPJA # 31325 OP "1000 Lumen,

10W, Super Bright, Cool White LED Module") on the inside of the

door (the side the faces the garage floor when the door is open)

on the center frame members of 2 door panels. The steel frame

member is an L shaped 18" long and 2 1/2" wide on one leg of the

L, and 2" wide on the other, and is welded to the steel door panel.

It's essentially an infinite (but inefficient) heat sink. I hung

2 copper braids made from coaxial cable shield from the ceiling

and ran 12.7 volts DC to them. I built a T out of wood and 2 copper

(1/2 dia) pipes and installed it on the top panel of the door.

When the door is about 2 inches from fully open the copper pipes

on the T contact the hanging copper braid. Wires from the pipes

on the T connect to the LED modules mounted on two door panel

center framing members.



copper copper

==+=== ===+==

-------------- | | | | -----------

| | |wood| | |

| | | | | |

| | ---- | |

| door | | |

| +-module-+ |

. | | .

. +-module-+ .

. .

| |

-------------------------------------



I did this to power them:



1N5406 Diodes

+12.7V---+---[.5R]--->|--->|--->|--->|---+---[Module]---+

| | |

+------[6.8R]---[3V Relay]------+---[Module]---+

|

Gnd-----------------------------------------------------+



That drops about 3.9 volts across the resistor and diodes,

energizes the 3 volt relay, and delivers about 8.9V to the

door mounted modules. They run at a little less than 5 watts

each and are bright bright bright!



When the door goes up and the fluorescent light is blocked,

the LED modules mounted on the door automatically turn on, and

provide more light - a lot more light - than the two 24"

fluorescent tubes do when the door is not blocking them.



I was so impressed by the increase in light that I built a

"fixture" containing two of the LED modules and mounted it on

the ceiling. The "fixture" is just a 36" x 2" x 1/8" aluminum

bar with the modules screwed to it and separated by 24". It

provides the needed heat sink for the modules.



When the door is closed, the relay transfers power to the

ceiling modules instead of the modules mounted on the door.

The ceiling modules have the same voltage dropping circuit as

above, but without the relay.



The ceiling fluorescent light switch also controls a receptacle,

and the 12V power supply is plugged in to that, so when the

ceiling light is switched off the LED modules are also off. For

A/B testing I plug the power supply into a different receptacle.



The lighting now is far better than it ever was. I get a 15

degree C temperature rise, measured at the module wiring

terminal on both the door and ceiling modules, after 2 hours

of continuous operation. The datasheet I found says 60 C max,

so they should be ok even on the hottest days.



I owe thanks to Jon Elson whose post about replacing his

fluorescents with LEDs gave me the impetus to experiment.



Ed

Won't that copper eventually develop an oxide layer? I'm not sure 12V is enough potential to keep this working. Usually the garage lights are on an assembly that ends up under the door when it's up.

 

On Monday, April 28, 2014 2:28:39 PM UTC-4, upsid...@downunder.com wrote:

On Mon, 28 Apr 2014 12:09:56 -0400, krw@attt.bizz wrote:



On Mon, 28 Apr 2014 08:35:09 -0700 (PDT),

bloggs.fredbloggs.fred@gmail.com wrote:



On Monday, April 28, 2014 2:08:09 AM UTC-4, upsid...@downunder.com wrote:

On Mon, 28 Apr 2014 00:56:51 -0400, ehsjr <ehsjr@mverizon.net> wrote:



The pipes are contacts to bring 12 volts to the door.



When the door goes up and travels to its final position,

the copper pipes attached to the door come into contact

with two pieces of copper braid spaced about 12" apart that

are attached to the ceiling. The supply voltage is connected

to the copper braid, gnd to one braid, +12 to the other.



A garage would be the last place to using a sparking contacts.



Some amount of gasoline fumes in the air and some sparks and ......



Those fumes are supposed to be contained these days.



You're sure dumb enough to count on it.



Refuel your lawn mover on a hot day in the garage and then open the

garage door ;-)

His circuit doesn't make contact until the door is fully open, by then there is enough ventilation to eliminate any chance of vapor ignition.

"When the door is about 2 inches from fully open the copper pipes
on the T contact the hanging copper braid."

 

On Mon, 28 Apr 2014 08:35:09 -0700 (PDT),
bloggs.fredbloggs.fred@gmail.com wrote:

On Monday, April 28, 2014 2:08:09 AM UTC-4, upsid...@downunder.com wrote:
On Mon, 28 Apr 2014 00:56:51 -0400, ehsjr <ehsjr@mverizon.net> wrote:



The pipes are contacts to bring 12 volts to the door.

When the door goes up and travels to its final position,

the copper pipes attached to the door come into contact

with two pieces of copper braid spaced about 12" apart that

are attached to the ceiling. The supply voltage is connected

to the copper braid, gnd to one braid, +12 to the other.



A garage would be the last place to using a sparking contacts.



Some amount of gasoline fumes in the air and some sparks and ......

Those fumes are supposed to be contained these days.

You're sure dumb enough to count on it.

 

On Mon, 28 Apr 2014 12:09:56 -0400, krw@attt.bizz wrote:

On Mon, 28 Apr 2014 08:35:09 -0700 (PDT),
bloggs.fredbloggs.fred@gmail.com wrote:

On Monday, April 28, 2014 2:08:09 AM UTC-4, upsid...@downunder.com wrote:
On Mon, 28 Apr 2014 00:56:51 -0400, ehsjr <ehsjr@mverizon.net> wrote:

The pipes are contacts to bring 12 volts to the door.

When the door goes up and travels to its final position,
the copper pipes attached to the door come into contact
with two pieces of copper braid spaced about 12" apart that
are attached to the ceiling. The supply voltage is connected
to the copper braid, gnd to one braid, +12 to the other.

A garage would be the last place to using a sparking contacts.

Some amount of gasoline fumes in the air and some sparks and ......

Those fumes are supposed to be contained these days.

You're sure dumb enough to count on it.

Refuel your lawn mover on a hot day in the garage and then open the
garage door ;-)

 

[ehsjr]

On 4/28/2014 11:38 AM, bloggs.fredbloggs.fred@gmail.com wrote:

On Sunday, April 27, 2014 1:39:11 AM UTC-4, ehsjr wrote:
Bright lights!



Two of these: MPJA # 31325 OP "1000 Lumen, 10W, Super Bright,

Cool White LED Module" running at 1/2 power outperform two

of these: 20 Watt, 24 Inch T12 Cool White Fluorescent Bulb,

in my garage. I haven't measured it, but everyone who has

seen A/B testing (fluorescent vs LED modules) said "wow, that's

much brighter" when the LEDs were on and the fluorescent off.

The A/B testing was looking at the floor, not at the modules

or the fluorescent tubes.



Here's the details:



I had to replace my old wood garage door. The new steel door looks

good, but when open it blocks the ceiling fluorescent (24", 2 bulb)

fixture. (The windows in the old door let the light shine through

to the floor when the door is up, but the windows in the new door

don't line up with the light.)



I installed 10W no-name LED modules (MPJA # 31325 OP "1000 Lumen,

10W, Super Bright, Cool White LED Module") on the inside of the

door (the side the faces the garage floor when the door is open)

on the center frame members of 2 door panels. The steel frame

member is an L shaped 18" long and 2 1/2" wide on one leg of the

L, and 2" wide on the other, and is welded to the steel door panel.

It's essentially an infinite (but inefficient) heat sink. I hung

2 copper braids made from coaxial cable shield from the ceiling

and ran 12.7 volts DC to them. I built a T out of wood and 2 copper

(1/2 dia) pipes and installed it on the top panel of the door.

When the door is about 2 inches from fully open the copper pipes

on the T contact the hanging copper braid. Wires from the pipes

on the T connect to the LED modules mounted on two door panel

center framing members.



copper copper

==+=== ===+==

-------------- | | | | -----------

| | |wood| | |

| | | | | |

| | ---- | |

| door | | |

| +-module-+ |

. | | .

. +-module-+ .

. .

| |

-------------------------------------



I did this to power them:



1N5406 Diodes

+12.7V---+---[.5R]--->|--->|--->|--->|---+---[Module]---+

| | |

+------[6.8R]---[3V Relay]------+---[Module]---+

|

Gnd-----------------------------------------------------+



That drops about 3.9 volts across the resistor and diodes,

energizes the 3 volt relay, and delivers about 8.9V to the

door mounted modules. They run at a little less than 5 watts

each and are bright bright bright!



When the door goes up and the fluorescent light is blocked,

the LED modules mounted on the door automatically turn on, and

provide more light - a lot more light - than the two 24"

fluorescent tubes do when the door is not blocking them.



I was so impressed by the increase in light that I built a

"fixture" containing two of the LED modules and mounted it on

the ceiling. The "fixture" is just a 36" x 2" x 1/8" aluminum

bar with the modules screwed to it and separated by 24". It

provides the needed heat sink for the modules.



When the door is closed, the relay transfers power to the

ceiling modules instead of the modules mounted on the door.

The ceiling modules have the same voltage dropping circuit as

above, but without the relay.



The ceiling fluorescent light switch also controls a receptacle,

and the 12V power supply is plugged in to that, so when the

ceiling light is switched off the LED modules are also off. For

A/B testing I plug the power supply into a different receptacle.



The lighting now is far better than it ever was. I get a 15

degree C temperature rise, measured at the module wiring

terminal on both the door and ceiling modules, after 2 hours

of continuous operation. The datasheet I found says 60 C max,

so they should be ok even on the hottest days.



I owe thanks to Jon Elson whose post about replacing his

fluorescents with LEDs gave me the impetus to experiment.



Ed

Won't that copper eventually develop an oxide layer? I'm not sure 12V is enough potential to keep this working. Usually the garage lights are on an assembly that ends up under the door when it's up.

Yes, I think it will oxidize over time. If so I'll have to rub it
with a Scotchbrite pad.

Ed

 

[Jasen Betts]

On 2014-04-29, ehsjr <ehsjr@mverizon.net> wrote:

Ed

Won't that copper eventually develop an oxide layer? I'm not sure 12V is enough potential to keep this working. Usually the garage lights are on an assembly that ends up under the door when it's up.


Yes, I think it will oxidize over time. If so I'll have to rub it
with a Scotchbrite pad.

Or with a copper braid.


--
umop apisdn


--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

 

[bitrex]

"Dave M" <dgminala4444@mediacombb.net> Wrote in message:

This is way off topic for many, but I have a feeling that there are more
than a few real musicians and even more aspiring musicians in this forum.
I am searching the net for online music shops for a new guitar. Google led
me to http://www.bossmusicstore.com/. They have a guitar listed on their
site that I would like very much to buy. However, their listed price is
several hundred dollars below all other online music stores and many hundred
dollars below the local music shops. I'm well aware of the axiom that says
that if sounds too good to be true, it probably is.

I've searched the web for any reviews of this site,and found a couple of
complaints, but no real reviews of the site by real customers. Has anyone
here ever done business with this site, or know of anyone who has? I'd
really like to hear from someone who can verify that it's a real business,
and not a scam site.

Thanks for listening,
Dave M

Their domain name registry WHOIS doesn't give any corporate info,
but redirects to a privacy proxy. Which may mean nothing, but
seems strange for a legit business.

The US also isn't on the list of countries they ship to:
http://www.bossmusicstore.com/sales-tax

Even if they will, shipping a guitar from Indonesia via the
methods they offer, plus customs will not be cheap. You may not
end up saving anything.
--

 

[bitrex]

bitrex <bitrex@de.lete.earthlink.net> Wrote in message:

"Dave M" <dgminala4444@mediacombb.net> Wrote in message:
This is way off topic for many, but I have a feeling that there are more
than a few real musicians and even more aspiring musicians in this forum.
I am searching the net for online music shops for a new guitar. Google led
me to http://www.bossmusicstore.com/. They have a guitar listed on their
site that I would like very much to buy. However, their listed price is
several hundred dollars below all other online music stores and many hundred
dollars below the local music shops. I'm well aware of the axiom that says
that if sounds too good to be true, it probably is.

I've searched the web for any reviews of this site,and found a couple of
complaints, but no real reviews of the site by real customers. Has anyone
here ever done business with this site, or know of anyone who has? I'd
really like to hear from someone who can verify that it's a real business,
and not a scam site.

Thanks for listening,
Dave M




Their domain name registry WHOIS doesn't give any corporate info,
but redirects to a privacy proxy. Which may mean nothing, but
seems strange for a legit business.

The US also isn't on the list of countries they ship to:
http://www.bossmusicstore.com/sales-tax

Even if they will, shipping a guitar from Indonesia via the
methods they offer, plus customs will not be cheap. You may not
end up saving anything.
--

Oh, and it also says retailer agreements means theu can't ship
some items internationally.
--




----Android NewsGroup Reader----
http://www.piaohong.tk/newsgroup

 

[Paul Hovnanian P.E.]

upsidedown@downunder.com wrote:

[snip]

Some amount of gasoline fumes in the air and some sparks and ......

Below 18" from the floor, yes. Above that you should be OK.

Ever wonder why gas furnaces and hot water tanks installed in garages
are mounted on stands?

--
Paul Hovnanian
Have gnu, will travel.

 

[Paul Hovnanian P.E.]

ehsjr wrote:

[snip]

When the door is about 2 inches from fully open the copper pipes
on the T contact the hanging copper braid. Wires from the pipes
on the T connect to the LED modules mounted on two door panel
center framing members.

Microswitch?

--
Paul Hovnanian
Have gnu, will travel.