Searching \ for '[EE]: Challenge for keen minds' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=challenge+keen+minds
Search entire site for: 'Challenge for keen minds'.

Exact match. Not showing close matches.
PICList Thread
'[EE]: Challenge for keen minds'
2004\01\29@230311 by Pedro Drummond

flavicon
face
Hi, all.

I have to implement a gate opening detector. It will log date and time each
time the gate is open and for how long. Must be battery-driven, battery must
last as much as possible, must be rugged and robust, and tamper-proof.
People WILL try to defeat it.

What I have already thought:

1) It will be all enclosed in a box with no openings, time of day
programming will be done with an IR remote, data will be collected from it
the same way.
Aside from these operations, battery consumption must be minimum.

Any ideas to improve this number 1 ?

2) How to detect gate openings ? Well, if I use a regular reed switch,
people will defeat it inserting a flexible magnet close to the sensor before
opening the gate. The same applies for metal (induction) sensors, proximity
(capacitive) sensors. I thought of having a second device on the moving door
sending IR data to the main device, but another battery consumption here is
out of the question. Last idea was to have a sequence of magnetized and
non-magnetized surfaces, similar to a bargraph, only much larger, that will
match the reed (or HAL) sensors in the device. Much harder to fool and
easier to save battery, yet not the elegant solution we all pursue...

Any ideas here ?

Thanks a lot,


Pedro

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@235745 by steve

flavicon
face
>  I have to implement a gate opening detector.

> 1) It will be all enclosed in a box with no openings, time of day
> programming will be done with an IR remote, data will be collected
> from it the same way. Aside from these operations, battery consumption
> must be minimum.
>
> Any ideas to improve this number 1 ?

IR is pretty power hungry. Any reason not to use a (gold) contact
method for data transfer ?

> 2) How to detect gate openings ?

RFID - when the gate is closed, the tag is in range and when it's open, it
isn't.


Steve.
==========================================
Steve Baldwin                          Electronic Product Design
TLA Microsystems Ltd             Microcontroller Specialists
PO Box 15-680, New Lynn                http://www.tla.co.nz
Auckland, New Zealand                     ph  +64 9 820-2221
email: spam_OUTsteveTakeThisOuTspamtla.co.nz                      fax +64 9 820-1929
=========================================

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\30@001711 by David Schmidt

flavicon
face
Magnet and a reed switch.

> 2) How to detect gate openings ?

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@013328 by M. Adam Davis

flavicon
face
My vote is to place one or more gyro and or accelleration sensors in the
package, then mount it all inside the gate tube (or welded to a box on
the gate).

The gate could not move without your electronics also moving.

-Adam

Pedro Drummond wrote:

{Quote hidden}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@013605 by Daniel Imfeld

flavicon
face
----- Original Message -----
From: "Pedro Drummond"
> Hi, all.
>
>  I have to implement a gate opening detector. It will log date and time
each
> time the gate is open and for how long. Must be battery-driven, battery
must
{Quote hidden}

before
> opening the gate. The same applies for metal (induction) sensors,
proximity
> (capacitive) sensors. I thought of having a second device on the moving
door
> sending IR data to the main device, but another battery consumption here
is
> out of the question. Last idea was to have a sequence of magnetized and
> non-magnetized surfaces, similar to a bargraph, only much larger, that
will
{Quote hidden}

If you can put the entire device on the gate itself, how about an
accelerometer?  If a quiescent current consumption of 400 uA is all right,
Analog's ADXL311 should work well.  It goes for $8.50 in single quantities
from Digikey, and Analog seems to have a good samples program too.  You'll
have to read the value with a comparator or A/D, but if 600 uA consumption
is ok, you can use the ADXL202, which has a duty cycle output.  The URL is
incredibly long

http://tinyurl.com/2agpf

or if you want the long URL:
www.analog.com/Analog_Root/sitePage/mainSectionResource/0,2131,level4%253D%25252D1%2526level1%253D212%2526level2%253D213%2526level3%253D%25252D1%
2526resourceWebLawID%253D13,00.html

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@015416 by Jake Anderson

flavicon
face
Analogs sample system is really top notch.
problem you might have is picking the difference between the gate rattling
in the wind and the gate opening.
take a look at their digital PWM 10G or 2G sensor might work if you sum and
average etc over a period of time.
though if sombody opened it *really* slowly your screwed.

magnetic compas?
bringing a magnet near it should cause it to screw up enough that it will
trigger.



> {Original Message removed}

2004\01\30@015418 by Russell McMahon

face
flavicon
face
>  I have to implement a gate opening detector. It will log date and time
each
> time the gate is open and for how long. Must be battery-driven, battery
must
> last as much as possible, must be rugged and robust, and tamper-proof.
> People WILL try to defeat it.

Depends how techno savvy the defeaters are.

You could consider a "spike" that entered a hole in the lock when the gate
was shut. The spike may give the appearance of being a mechanical key
equivalent but also have some other attribute. eg a slug of brass at the
proper place in the spike would DECREASE inductance of a proximate coil that
it penetrated and be very hard to simulate if they were not aware what you
were doing. Similarly, ferrite or even just steel at SOME but not all
locations along the spike would allow selective inductance increase on some
proximate coils only. Proper code would be present only when gate was fully
shut. Again, users don't SEE any visible mechanism to do the coding.
Replicating the spike shape helps not at all. Even 2 or 3 coils would
probably be enough with one being triggered when the other(s) weren't by the
proper spike.

You could have a magnet at the spike end and a sensor (even reed switch)
that triggered it when the gate started to open. That way power could be
essentially off until the sensor was triggered.

Battery consumption should be easy to keep low if you use sensors (as above)
that notify you only when mechanical action is taking place. This could be
part of the gate latching mechanism or could be independent.

The trouble with IR as a comms method is that you either need to have the
rcvr always on or have to wake it to listen to you. If you are able to open
and shut the gate before doing comms then you could wake the IR up for a
brief period at each event. Something like capacitance coupled comms (I know
of one device that uses this) or
inductive coupling require closish proximity but can be power free until you
need to use them. Is it OK to be in close proximity or do you have to be at
a distance away?
If using IR "semi covertly" you could arrange to power up the receiver every
say 10 seconds and listen for an interrogation signal.

You can get real time clock IC's with wakeup function that draw sub 1 uA.
Your processor need draw power only when it is active and using the "wake on
demand" system as above battery drain can be very low.
Imagine a device that requires 10 mA for 1 second any time the gate is
opened or shut. A 100 mAH battery (modest) would support 100/10 x 3600/2 =
1800 odd opening and shutting pairs. That's about 2.5 per hour 24/7 for a
year.
A set of AA alkaline batteries would give about 20 times as much as this!

Russell McMahon

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@031625 by Samuel BOUQUET
flavicon
face
>Last idea was to have a sequence of magnetized and non-magnetized
surfaces, similar to a bargraph, only much larger, that will match the
reed (or HAL) >sensors in the device. Much harder to fool and easier to
save battery, yet not the elegant solution we all pursue...

It does already exist, have a look at

http://www.celduc-relais.com/uk/sm.asp

It's "coded magnetic sensors ", they use it as safety sensors in
machine, in order to stop it when a door is open

SamB

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@100453 by ed_b_pes

flavicon
face
Almost everyone thinks about looking at the latch side - think oppositely -
make the hinge a rotation sensor: optical, resistive, magnetic or
mechanical.

{Original Message removed}

2004\01\30@101321 by D. Jay Newman

flavicon
face
> >  I have to implement a gate opening detector. It will log date and time
> each
> > time the gate is open and for how long. Must be battery-driven, battery
> must
> > last as much as possible, must be rugged and robust, and tamper-proof.
> > People WILL try to defeat it.

Well, if you don't want people to defeat it, you need to make it as
simple as possible. For example, don't have a gate.

How about something that watches the gate through a telescope from
*inside* the protected area. It could bounce an I/R laser off of a
reflector. If the signal is lost then a secondary system would check
if the gate is open.

Of course, this works in perfect weather.

What *are* you protecting?
--
D. Jay Newman           !
@spam@jayKILLspamspamsprucegrove.com     ! Xander: Giles, don't make cave-slayer unhappy.
http://enerd.ws/robots/ !

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body

.
Return-Path: <>
Received: from mitvma.mit.edu ([18.92.0.3]) by tomts3-srv.bellnexxia.net
         (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
         id <RemoveME20040128121751.VBPZ1829.tomts3-srv.bellnexxia.netTakeThisOuTspammitvma.mit.edu>>          for <spamBeGonepiclist_errorsspamBeGonespamSYMPATICO.CA>;
         Wed, 28 Jan 2004 07:17:51 -0500
Received:  by mitvma.mit.edu (IBM VM SMTP Level 430) via spool with SMTP id 6596 ; Wed, 28 Jan 2004 07:17:48 EST
Received: from MITVMA.MIT.EDU (NJE origin LISTSERV@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 8367; Wed, 28 Jan 2004 07:17:48 -0500
Date:         Wed, 28 Jan 2004 07:17:48 -0500
From:         "L-Soft list server at MITVMA.MIT.EDU (1.8e)"
             <TakeThisOuTLISTSERVEraseMEspamspam_OUTMITVMA.MIT.EDU>
Subject: PICLIST: error report from FITCH5.UNI2.NET
To:           RemoveMElistsjoshspamTakeThisOuT3MTMP.COM,
             "For BlackholeeclipseEraseMEspam.....Earthlink.Net" <EraseMEpiclist_errorsspamSYMPATICO.CA>
Message-ID:   <LISTSERV%RemoveME2004012807174816EraseMEspamEraseMEMITVMA.MIT.EDU>
X-LSV-ListID: None

The enclosed message has been identified as a delivery error for the PICLIST
list because it was sent to 'RemoveMEowner-piclistspam_OUTspamKILLspamMITVMA.MIT.EDU'.

------------------------------ Message in error -------------------------------
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 8365; Wed, 28 Jan 2004 07:17:48 -0500
Received: from fitch5.uni2.net [130.227.52.108] by mitvma.mit.edu (IBM VM SMTP
         Level 430) via TCP with ESMTP ; Wed, 28 Jan 2004 07:17:47 EST
X-Comment: mitvma.mit.edu: Mail was sent by fitch5.uni2.net
Received: from HLUSF26A.lundbeck.com ([130.227.160.123])
       by fitch5.uni2.net (8.12.6/8.11.6) with SMTP id i0SCHbKY011672
       for <RemoveMEowner-piclistTakeThisOuTspamspammitvma.mit.edu>; Wed, 28 Jan 2004 13:17:48 +0100
Message-Id: <EraseME200401281217.i0SCHbKY011672spamspamspamBeGonefitch5.uni2.net>> Received: from  ([172.16.0.163]) by HLUSF26A.lundbeck.com; Wed, 28 Jan 2004
         13:06:29 +0100 (CET)
From:
RemoveMEWebshield.SMTP.V4.5.MR1a.Mail.ServiceKILLspamspamfitch5.uni2.net> Date: Wed Jan 28 13:07:01 2004
To: <
owner-piclistSTOPspamspamspam_OUTmitvma.mit.edu>
Subject: Returned Mail: Error During Delivery

------ Here is your List of Failed Recipients ------
<spamBeGonejanlSTOPspamspamEraseMElundbeck.com>


Mail Server is down or unreachable.

-------- Here Is Your Returned Mail --------
Received: FROM lundbeck.com BY ludk0163.lundbeck.com ; Wed Jan 28 12:30:06 2004 +0100
Received: from ([10.10.3.249])
       by HLUIMX26A.lundbeck.com with SMTP ;
       Wed, 28 Jan 2004 12:29:28 +0100 (CET)
Received: from cherry.ease.lsoft.com ([209.119.0.109]) by HLUSF26A.lundbeck.com; Wed, 28 Jan 2004 12:28:53 +0100 (CET)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <KILLspam11.00CC0B29spamBeGonespamcherry.ease.lsoft.com>; Wed, 28 Jan 2004 6:29:25 -0500
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8e)
         with spool id 6681 for EraseMEPICLISTspamEraseMEMITVMA.MIT.EDU; Wed, 28 Jan 2004
         06:29:20 -0500
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 7459; Wed, 28 Jan 2004 06:28:04 -0500
Received: from smtp2.clear.net.nz [203.97.37.27] by mitvma.mit.edu (IBM VM SMTP
         Level 430) via TCP with ESMTP ; Wed, 28 Jan 2004 06:28:04 EST
X-Comment: mitvma.mit.edu: Mail was sent by smtp2.clear.net.nz
Received: from jc2 (218-101-75-166.dialup.clear.net.nz [218.101.75.166]) by
         smtp2.clear.net.nz (CLEAR Net Mail) with SMTP id
         <@spam@0HS700C7I6I7RT@spam@spamspam_OUTsmtp2.clear.net.nz> for spamBeGonePICLISTspamKILLspamMITVMA.MIT.EDU; Thu,
         29 Jan 2004 00:28:05 +1300 (NZDT)
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <.....E1AlnLU-0007lU-Q8spam_OUTspamsmtp.aaisp.net.uk>
Message-ID:  <00e901c3e591$fbac5660$7223fea9@jc2>
Date:         Thu, 29 Jan 2004 00:29:02 +1300
Reply-To:     pic microcontroller discussion list <TakeThisOuTPICLIST.....spamTakeThisOuTMITVMA.MIT.EDU>
Sender:       pic microcontroller discussion list <TakeThisOuTPICLISTKILLspamspamspamMITVMA.MIT.EDU>
From:         Jinx <.....joecolquittspamRemoveMECLEAR.NET.NZ>
Subject: Re: [OT]: Flash memory & Spirt. Ceitgeist
To:           RemoveMEPICLISTspamspamBeGoneMITVMA.MIT.EDU
Precedence: list

> Apparently not!  But at least Charlotte Church wasn't in there...

Damn, all that Googling for nothing

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


.

2004\01\30@104014 by Olin Lathrop

face picon face
D. Jay Newman wrote:
> How about something that watches the gate through a telescope from
> *inside* the protected area. It could bounce an I/R laser off of a
> reflector. If the signal is lost then a secondary system would check
> if the gate is open.
>
> Of course, this works in perfect weather.
>
> What *are* you protecting?

A warehouse full of high tech gate sensors?

*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistserv@spam@spamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@105051 by David Schmidt

flavicon
face
Are you trying to keep engineering/student types from defeating your gate
counter?  Or the general public?

Reason I ask, is that if you have multiple sensors (3 qty reed switches, all
in series, along the length of the gate, buried in the wood/tubing) and it
is concealed so that they do not know how your device works (even bury your
device into the gate so it is not visible at all), they are not going to
figure it out.

Engineers love figuring things out and will try to defeat your counter.
Students usually have too much time on their hands and will try too.

Trick is to hide all the guts so the gate looks completely normal, AND add
multiple sensors over distances.

Question, How do you prevent one person from opening the gate and letting in
100 people from that single opening?
Or a person from climbing over? (false ceiling?)

Dave



> > 2) How to detect gate openings ? Well, if I use a regular reed switch,
> > people will defeat it inserting a flexible magnet close to the sensor
> before

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservspamspammitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@115835 by James Nick Sears

picon face
----- Original Message -----
From: "ed_b_pes" <ed_b_pesEraseMEspamSWBELL.NET>
To: <RemoveMEPICLISTEraseMEspamspam_OUTMITVMA.MIT.EDU>
Sent: Friday, January 30, 2004 9:03 AM
Subject: Re: [PICLIST] [EE]: Challenge for keen minds


> Almost everyone thinks about looking at the latch side - think
oppositely -
> make the hinge a rotation sensor: optical, resistive, magnetic or
> mechanical.
>

I think this is the idea.  Something as simple as a pot with the shaft
fastened to the rotating part of the hinge and the case attached to the
stationary part would give you the necessary data to chew on.  Then your
whole device (sensor and all) could live in a piece of steel tubing welded
to the hinge assembly with either a welded on cap or a keylocked lid, etc so
there are no external wires, sensors, connections etc to tamper with.  Done
properly and of course depending upon the hinge design, it could be made
small enough and blend well enough with the design of the hinge to not even
be obvious that there is ANY monitoring system in place to begin with.  I
would recommend a 1/2AA size Lithium Thionyl Chloride battery (1200mAh @
3.6Vnominal) for power.  With this and a small SMT PIC board you could
probably fit into a piece of 1-2" round or square tubing an inch or two long
(whatever blends the best with your hinge).

The crooks would be doing well to even find the sensor/logger and even if
they do they had better hope that they brought their EMP gun or cutting
torch (or maybe a sawzall and a lot of time).  Maybe even throw up an
intentionally relatively shoddy decoy system with some wires running the
length of the gate, etc. to keep them from even checking the hinge in the
first place.  Depends upon whether you would rather have them sneak in and
get caught or decide that it's a bad idea and turn around.

Have fun.

Nick

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservRemoveMEspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@121707 by Pedro Drummond

flavicon
face
Thank you all for the help and interest.

Ok, time for more data:

The space being protected is a metallic box, the size of an elevator, that
will be towed by small trucks. Its metallic "door" (actually a double door)
is the gate I mentioned. During long trips, these boxes are commonly moved
from truck to truck, with long periods waiting for the next one, with no
guards nearby. Although there is a very strong lock, theft was detected at
final destination in locked boxes (i.e., someone opened it, took some goods,
and somehow relocked it). A redesign of the metal box is being made, but it
will be a long time until all of them are replaced. It is enough for now to
help the insurance company in detecting WHEN and for HOW LONG it was opened,
so the responsible will be known.
I do not mind reading its information only when the gate is open, and I
cannot modify the gate, only add some small device close to the door.


To comment some of the group ideas:

Using a contact method for data transfer - I am afraid of dust, grease, etc.
But maybe.
RFID - cheap tag, but expensive sensor (I guess).
Gyro/acceleration sensors - can't do, since it will be towed by a truck.
Hinge sensored - can't alter the hinge.


BTW, special thanks to Russel !

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@123744 by Alan B. Pearce

face picon face
..> 1) It will be all enclosed in a box with no openings, time of day
>> programming will be done with an IR remote, data will be collected
>> from it the same way. Aside from these operations, battery consumption
>> must be minimum.
>>
>> Any ideas to improve this number 1 ?
>
>IR is pretty power hungry. Any reason not to use a (gold) contact
>method for data transfer ?

Not to mention potentially hackable. However I guess if the receiver only is
enabled then the power draw should not be too much until you enable the
transmitter to transfer data. Using a non-standard protocol using a Palm or
something similar to capture the data may allow you to make something secure
enough to not be confused by someone else coming along with an IRDA device,
such as another Palm and trying to foul it up. OTOH would a PCMCIA WIFI card
do it for you? drive up to the gate and collect the data without getting out
of the vehicle :))))) Again probably current drain may can this one, but you
may be able to organise something where a headlight shone at it in (say) a
one hour window during daylight causes the wifi to be turned on by the
micro. Have a timeout to turn it off again if there is no wifi contact in
half a minute (say), and then a half hour reset time before the next enable.

>> 2) How to detect gate openings ?
>
>RFID - when the gate is closed, the tag is in range and when it's open, it
>isn't.

I would look at using one of those shop antitheft devices, the type that get
a foil stuck over them to disable them rather than the type that get put on
a magnet to disable them. Put the thing in a slot on the gate so that it is
under the wood surface, and hence as invisible as you can get it. Putting it
in a joint where a rail meets a vertical member of the gate may do.
Essentially you have to hide it, what ever method of sensing you use, as the
biggest part of bypassing one of these systems is knowing where the sensor
is (ever tried to disable sensors on a laser printer?).

Now your box can be mounted on the gate post beside the latch. The antitheft
sticker I talk about above is really a tuned circuit, probably at 13.56MHz
when you look at the size of the L & C in them. It should be possible to
build a low power oscillator to detect the presence of the device in the
gate from a handful of inches, even if in rain soaked wood (this will
increase the path loss). Using a plastic box should mean you don't need the
detector placed outside the box.

You may also have the box placed right beside the bolt on the gate so that
you can sense when the bolt is home in the latch, using hall effect or
something. Now people may figure that you are using the bolt to detect the
gate is shut, so if the antitheft device cannot be sensed when the bolt is
sensed, then a warning LED could be flashed, and perhaps an audible warning
sounded, to signify that the gate is not shut, to stop people trying to fool
your box. Now an LED could be flashed at a slow low duty cycle when the
sensor is detected and the bolt not home, to signify to the person that this
state is detected.

Between all these combinations, your users will have a real conundrum trying
to work out how your box knows the gate is shut.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservspam_OUTspam.....mitvma.mit.edu with SET PICList DIGEST in the body

.
Return-Path: <>
Received: from mitvma.mit.edu ([18.92.0.3]) by tomts38-srv.bellnexxia.net
         (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
         id <spamBeGone20040128024127.YJSP8311.tomts38-srv.bellnexxia.netEraseMEspammitvma.mit.edu>>          for <piclist_errorsspamBeGonespamSYMPATICO.CA>;
         Tue, 27 Jan 2004 21:41:27 -0500
Received:  by mitvma.mit.edu (IBM VM SMTP Level 430) via spool with SMTP id 6164 ; Tue, 27 Jan 2004 21:41:24 EST
Received: from MITVMA.MIT.EDU (NJE origin LISTSERV@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 4339; Tue, 27 Jan 2004 21:41:24 -0500
Date:         Tue, 27 Jan 2004 21:41:24 -0500
From:         "L-Soft list server at MITVMA.MIT.EDU (1.8e)"
             <RemoveMELISTSERV@spam@spamspamBeGoneMITVMA.MIT.EDU>
Subject: PICLIST: error report from YAHOO.COM
To:           .....listsjosh@spam@spamEraseME3MTMP.COM,
             .....piclist_errorsRemoveMEspamSYMPATICO.CA
Message-ID:   <LISTSERV%.....2004012721412404STOPspamspam@spam@MITVMA.MIT.EDU>
X-LSV-ListID: None

The enclosed message has been identified as a delivery error for the PICLIST
list because it was sent to 'owner-piclistEraseMEspam@spam@MITVMA.MIT.EDU'.

------------------------------ Message in error -------------------------------
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 4337; Tue, 27 Jan 2004 21:41:24 -0500
Received: from mta200.mail.scd.yahoo.com [66.218.86.116] by mitvma.mit.edu (IBM
         VM SMTP Level 430) via TCP with SMTP ; Tue, 27 Jan 2004 21:41:23 EST
X-Comment: mitvma.mit.edu: Mail was sent by mta200.mail.scd.yahoo.com
From: RemoveMEMAILER-DAEMONspamspamBeGoneyahoo.com
To: spamBeGoneowner-piclistKILLspamspam@spam@mitvma.mit.edu
X-Loop: MAILER-DAEMONspam_OUTspam@spam@yahoo.com
Subject: Delivery failure

Message from yahoo.com.
Unable to deliver message to the following address(es).

<spamBeGonehbarregrd@spam@spamyahoo.com>:
Sorry, your message to RemoveMEhbarregrdEraseMEspamKILLspamyahoo.com cannot be delivered.  This account is over quota.

--- Original message follows.

Return-Path: <spamBeGoneowner-piclistspam_OUTspamRemoveMEmitvma.mit.edu>
Received: from 209.119.0.109  (EHLO cherry.ease.lsoft.com) (209.119.0.109)
 by mta200.mail.scd.yahoo.com with SMTP; Tue, 27 Jan 2004 13:45:50 -0800
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <.....12.00CBF756spamRemoveMEcherry.ease.lsoft.com>; Tue, 27 Jan 2004 13:55:40 -0500
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8e)
         with spool id 0648 for PICLISTspam@spam@MITVMA.MIT.EDU; Tue, 27 Jan 2004
         13:55:30 -0500
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 1566; Tue, 27 Jan 2004 13:54:32 -0500
Received: from outbound03.telus.net [199.185.220.222] by mitvma.mit.edu (IBM VM
         SMTP Level 430) via TCP with SMTP ; Tue, 27 Jan 2004 13:54:32 EST
X-Warning: mitvma.mit.edu: Host outbound03.telus.net claimed to be
          priv-edtnes14-hme0.telusplanet.net
Received: from DAR2.planet.eon.net ([198.53.251.69]) by
         priv-edtnes14-hme0.telusplanet.net (InterMail vM.6.00.05.02
         201-2115-109-103-20031105) with ESMTP id
         <EraseME20040127185433.HCNM15680.priv-edtnes14-hme0.telusplanet.netRemoveMEspamSTOPspamDAR2.planet.eon.net> for
         <RemoveMEPICLISTKILLspamspamTakeThisOuTMITVMA.MIT.EDU>; Tue, 27 Jan 2004 11:54:33 -0700
X-Sender: spamBeGonedwaynerspam@spam@pop.telusplanet.net
X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <RemoveME6.0.1.1.2.20040127105028.02c501a8spam_OUTspampop.telusplanet.net>> Date:         Tue, 27 Jan 2004 11:40:31 -0700
Reply-To:     pic microcontroller discussion list <
PICLISTspamspamMITVMA.MIT.EDU>
Sender:       pic microcontroller discussion list <spam_OUTPICLISTspam_OUTspamspam_OUTMITVMA.MIT.EDU>
From:         Dwayne Reid <dwaynerspam_OUTspamPLANET.EON.NET>
Subject: [EE:] RTD transmitter
To:           RemoveMEPICLISTKILLspamspam@spam@MITVMA.MIT.EDU
Precedence: list

Good day to all.

I'm re-visiting an existing project because the client is now asking for
remote temperature readings.  Their preferred temperature sensor is a 100R
platinum RTD which they will supply.  I need to condition those sensors and
turn it into a serial bit stream and down a fiber.

The complicating factor is that this will be operating in the presence of
large AC magnetic magnetic fields generated by currents in the order of
250K Amps or so.

The easiest solution is to purchase an off-the-shelf RTD transmitter with
fiber output - and I'm starting a search as soon as I finish typing
this.  But I'm hoping that someone has a favorite unit they like and can
offer up supplier names and model numbers.  Expense is a consideration - I
need 24 units for this particular project.

If I can't find anything suitable, I have to build it.  In that case, I'm
looking for design hints.  I've seen the ap notes offered by LT and the
like - I'll be looking at those as well.

I've got my choice of 2 power sources available: 12Vdc @ 30 mA sitting
about 1000 Vdc above ground or 125 Vdc ground referenced.  Neither is
optimal but its what I've got.

Any suggestions appreciated.

dwayne

--
Dwayne Reid   <dwaynerspamBeGonespam.....planet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 19 years of Engineering Innovation (1984 - 2003)
 .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-
    `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
*** MESSAGE TRUNCATED ***


..
.

2004\01\30@124614 by Alan B. Pearce

face picon face
>The space being protected is a metallic box, the size of an elevator, that
>will be towed by small trucks. Its metallic "door" (actually a double door)
>is the gate I mentioned. During long trips, these boxes are commonly moved
....

OK the answer here is IR. Have an IR reflector mounted on the swinging edge
of the door, but not flat on the door. Sensitivity to opening will be
improved if the sensor can be mounted at a slight angle. Now have you
detector mounted in the rear of the transportable box, my guess would be
about in line with the hinge edge of the door. The IR lamp needs to be
pulsed probably about once in 10-20 seconds, and if you use a high pulse
frequency, then use a PLL on the receiver to detect the reflection. Using a
suitable dark red plastic box should allow the IR to get out of the box with
minimal loss. If you can use a pulse frequency on the IR such that you can
detect a known phase difference between the sent and received signals, then
you can probably detect any attempt to fool it using a mirror placed near
the detector. The mirror on the door just needs to be reflective at IR, not
visible light, so this may help to fool the thieves into how it operates,
they may even think you just detect the light when the door is opened, so
they may just try and open it in the dark.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservspam.....mitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@125201 by James Nick Sears

picon face
In this case couldn't you just use a switch mounted inside the door
somewhere where it can't be feasibly reached from the outside until the door
has already opened and the time of intrusion has already been logged?


{Original Message removed}

2004\01\30@131728 by David Schmidt

flavicon
face
Like a pushbutton switch mounted on the hinge side of the door in the door
jamb.
A flange on the outside of the door that overlaps the jamb would prevent
disabling it.


----- Original Message -----
> In this case couldn't you just use a switch mounted inside the door
> somewhere where it can't be feasibly reached from the outside until the
door
> has already opened and the time of intrusion has already been logged?

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@133142 by Roberts II, Charles K.

picon face
>Gyro/acceleration sensors - can't do, since it will be towed by a
truck.

Couldn't you use on acceleration meter in the door and one body of the
box. So that if you could detect acceleration in both you knew it would
be the truck moving and if only the door acceleration meter gave a
signal it would be the door.

Chuck Roberts

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservRemoveMEspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@140128 by Pedro Drummond

flavicon
face
Yes, but the problem here is someone that, when opening the gate,
immediately recomposes the sensor (for example, puting a second magnet close
to the reed switch). If he takes, say, 2-3 secs to do it, it will be
analyzed afterwards as a glitch, probably caused by truck movement. The
ideal would be some kind of sensor not easily or quickly "recomposed" when
opening the gate.


{Original Message removed}

2004\01\30@140750 by Bob Ammerman

picon face
I assume you are only going to need to check the results if something has
been stolen, so a bit of difficulty in retrieving the log isn't too bad.

Now, if the bad guys don't know you're trying to monitor the box, something
as simple as a light sensor could work (ie: if there is any light, then the
door is open). Obviously, if they know about the sensor they could open the
box in the dark and then cover the sensor.

Alternatively, you could build a robust little box containing an IR LED and
IR sensor and mount it (weld it?) to the top of the door frame. When the
door is closed the sensor can see the LED. When the door is opened the
sensor can no longer see the LED. The same IR LED could be used to transmit
the log data.

Bob Ammerman
RAm Systems


{Original Message removed}

2004\01\30@145014 by Robert Rolf

picon face
Properly arranged, there should be NO glitches in a reed switch
caused by truck movement.

Have two sensors. One obvious, to be disabled/bypassed. One hidden,
that logs the 'real' activity.

If the box is normally dark, a light sensor (CdS cell)
hooked to one of the self contained  Dallas data logger
chips should work with minimal effort. The crooks are going
to need light to see what they're stealing. And if they think
they've disabled the detector, they're more likely to turn on
the lights.

And you could always put a floor switch at the entrance, hidden under
under a mat.

And why not put a disposable camera in a box over the door or shooting
through a hole in the side wall.
Easy enough to have it snap an image when the door opens (with a 1 sec delay),
which presumably happens only at the final destination.

Autowinding is fairly easy too. Rubber hobby tire and small gear head motor
timed to wind many minutes AFTER the door closes.

R

Pedro Drummond wrote:
>
> Yes, but the problem here is someone that, when opening the gate,
> immediately recomposes the sensor (for example, puting a second magnet close
> to the reed switch). If he takes, say, 2-3 secs to do it, it will be
> analyzed afterwards as a glitch, probably caused by truck movement. The
> ideal would be some kind of sensor not easily or quickly "recomposed" when
> opening the gate.
>
> {Original Message removed}

2004\01\30@150637 by David Schmidt

flavicon
face
Pedro,
Ingenuity on your part to protect the sensor and thwart fooling it is key to
your project's success, above and beyond
what you choose for your sensor.  As you have shown, for every idea that has
been proposed, it can be compromised or be unreliable.
Multiple 'simple' sensors would do just as good a job as complicated
multiple sensor.  Multiple sensors would take longer to be compromised.

Now, based on your statement about a 2-3 second glitch being diagnosed as
"truck movement", wouldn't an inventory of the contents be in order
anyways to prove or disprove the glitch?


What about something as simple as the "one use" only type of zip ties like
products that they use on power meters to show that they've been tampered
with/ removed?
What about mechanical one time use 'locks' that they use on railway cars to
show that something has been opened?

How about welding the door or lock shut between destinations?  (don't laugh,
they welded manhole covers here in the US as a security measure in some
city - forget which and when)

Dave

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservspamspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@152922 by James Nick Sears

picon face
----- Original Message -----
From: "Robert Rolf" <Robert.RolfspamspamUALBERTA.CA>
To: <RemoveMEPICLISTspamBeGonespamRemoveMEMITVMA.MIT.EDU>
Sent: Friday, January 30, 2004 1:45 PM
Subject: Re: [PICLIST] [EE]: Challenge for keen minds


> Properly arranged, there should be NO glitches in a reed switch
> caused by truck movement.

This should definitely be possible - either with a mechanical or a reed
switch except in the case where the box gets severely deformed (as in the
case of an accident).  If the box is so flimsy that the sensor or switch
bounces out of contacting range when the truck hits a bump, then I think you
need a new box anyway if theft is such a major concern.  Think also about a
limit switch which has a long paddle on it that when released is open, then
it moves a portion of its throw and closes and then can move farther without
damage while remaining closed.  I think Omron is a popular manufacturer of
such switches.  Then "bias" the switch so that it would take a catastrophic
jolt to move it all the way out of the closed throw range while making sure
that if the door is cracked enough to get something in to manipulate the
switch that it has already opened and been recorded.

I would say that this isn't a place for a debounced (at least not heavily
so) switch.  If it flips open even for a brief instant you should know about
it, and also you will know when it closes again.  If for whatever reason
errant switch openings are a problem you can always then filter them out
later in PC software or even just by looking at a graph.  If something is
gone even if you have a few times where the switch opens for 200ms and one
where it opens for 1 or 2s you should be able to deduce where the problem
occured.  Better to have the noise + potential signal at your disposal --
you can get rid of noise later but you can't recover the ignored pulse.  Of
course you could still sleep the PIC to save power and use the wake on port
change interrupt feature so that you would always sleep except at the moment
the door opens or closes and long enough to store the timestamp.

In any case I agree with Robert that with a proper switch arrangement it
should be rock solid.  Maybe even look into the spring loaded switches that
turn on the dome light when you open your car door.

By the way, what about just using an inverter with a cheap security cam
system so that you not only know when the entry happened but who did it?
Seems like while they are going to the trouble they would want to catch the
guy with more than circumstantial evidence.  Besides it would be fun to see
his face drop the first time he popped it open and found the camera staring
him in the face.

Nick

{Quote hidden}

delay),
> which presumably happens only at the final destination.
>
> Autowinding is fairly easy too. Rubber hobby tire and small gear head
motor
> timed to wind many minutes AFTER the door closes.
>
> R
>
> Pedro Drummond wrote:
> >
> > Yes, but the problem here is someone that, when opening the gate,
> > immediately recomposes the sensor (for example, puting a second magnet
close
> > to the reed switch). If he takes, say, 2-3 secs to do it, it will be
> > analyzed afterwards as a glitch, probably caused by truck movement. The
> > ideal would be some kind of sensor not easily or quickly "recomposed"
when
> > opening the gate.
> >
> > ----- Original Message -----
> > From: "James Nick Sears" <KILLspamjsears2027spamBeGonespamHOTMAIL.COM>
> > To: <@spam@PICLISTSTOPspamspam@spam@MITVMA.MIT.EDU>
> > Sent: Friday, January 30, 2004 2:50 PM
> > Subject: Re: [EE]: Challenge for keen minds
> >
> > > In this case couldn't you just use a switch mounted inside the door
> > > somewhere where it can't be feasibly reached from the outside until
the
{Quote hidden}

elevator,
> > that
> > > > will be towed by small trucks. Its metallic "door" (actually a
double
> > > door)
> > > > is the gate I mentioned. During long trips, these boxes are commonly
> > moved
> > > > from truck to truck, with long periods waiting for the next one,
with no
> > > > guards nearby. Although there is a very strong lock, theft was
detected
> > at
> > > > final destination in locked boxes (i.e., someone opened it, took
some
> > > goods,
> > > > and somehow relocked it). A redesign of the metal box is being made,
but
> > > it
> > > > will be a long time until all of them are replaced. It is enough for
now
> > > to
> > > > help the insurance company in detecting WHEN and for HOW LONG it was
> > > opened,
> > > > so the responsible will be known.
> > > > I do not mind reading its information only when the gate is open,
and I
> > > > cannot modify the gate, only add some small device close to the
door.
> > > >
> > > >
> > > > To comment some of the group ideas:
> > > >
> > > > Using a contact method for data transfer - I am afraid of dust,
grease,
> > > etc.
> > > > But maybe.
> > > > RFID - cheap tag, but expensive sensor (I guess).
> > > > Gyro/acceleration sensors - can't do, since it will be towed by a
truck.
{Quote hidden}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservRemoveMEspammitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@154828 by Dan Oelke

flavicon
face
I think Robert has a great idea here - belts and suspenders style of
work.  Use both a CdS cell and a reed switch with magnet.  Or maybe also
a hall-effect switch to pick up the metal of the door.  Or a very
obvious micro-switch?  Of course by having more than one switch you
increase the cost, power consumption, etc.  You also make it harder to
communicate to the end user how to interpret the data.

The CdS cell idea sounds good - BUT are the boxes light tight or light
tight enough that this is reliable?

The question is whether you can build and install these without many
people knowing about how they really work and what methods would be
needed to defeat them.  If you can keep that information relatively
secret your job is much easier.  If you can spread some disinformation
about how it is "just that microswitch" your job might be easier yet.
To help keep stuff secret you might want to just label the output as
sensor 1, sensor 2, etc. and not tell them how the sensors work.  After
a few boxes get shipped, the recepient will learn that they commonly see
small glitches on one of them, but never on the other, etc.

Good luck!
Dan

Robert Rolf wrote:

{Quote hidden}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservSTOPspamspamRemoveMEmitvma.mit.edu with SET PICList DIGEST in the body

.
Return-Path: <>
Received: from mitvma.mit.edu ([18.92.0.3]) by tomts1-srv.bellnexxia.net
         (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
         id <spam_OUT20040128121927.TTZM10330.tomts1-srv.bellnexxia.netRemoveMEspamEraseMEmitvma.mit.edu>>          for <TakeThisOuTpiclist_errorsRemoveMEspam@spam@SYMPATICO.CA>;
         Wed, 28 Jan 2004 07:19:27 -0500
Received:  by mitvma.mit.edu (IBM VM SMTP Level 430) via spool with SMTP id 6599 ; Wed, 28 Jan 2004 07:19:24 EST
Received: from MITVMA.MIT.EDU (NJE origin LISTSERV@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 8386; Wed, 28 Jan 2004 07:19:24 -0500
Date:         Wed, 28 Jan 2004 07:19:24 -0500
From:         "L-Soft list server at MITVMA.MIT.EDU (1.8e)"
             <EraseMELISTSERVRemoveMEspamMITVMA.MIT.EDU>
Subject: PICLIST: error report from FITCH6.UNI2.NET
To:           spamlistsjosh.....spamspam3MTMP.COM,
             "For Blackholeeclipsespam_OUTspam@spam@Earthlink.Net" <.....piclist_errorsspamspam.....SYMPATICO.CA>
Message-ID:   <LISTSERV%2004012807192410KILLspamspamEraseMEMITVMA.MIT.EDU>
X-LSV-ListID: None

The enclosed message has been identified as a delivery error for the PICLIST
list because it was sent to 'EraseMEowner-piclist@spam@spam@spam@MITVMA.MIT.EDU'.

------------------------------ Message in error -------------------------------
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 8384; Wed, 28 Jan 2004 07:19:24 -0500
Received: from fitch6.uni2.net [130.227.52.109] by mitvma.mit.edu (IBM VM SMTP
         Level 430) via TCP with ESMTP ; Wed, 28 Jan 2004 07:19:23 EST
X-Comment: mitvma.mit.edu: Mail was sent by fitch6.uni2.net
Received: from HLUSF26A.lundbeck.com ([130.227.160.123])
       by fitch6.uni2.net (8.12.6/8.11.6) with SMTP id i0SCJL9m024151
       for <@spam@owner-piclistspamspamKILLspammitvma.mit.edu>; Wed, 28 Jan 2004 13:19:25 +0100
Message-Id: <spamBeGone200401281219.i0SCJL9m024151RemoveMEspamEraseMEfitch6.uni2.net>> Received: from  ([172.16.0.163]) by HLUSF26A.lundbeck.com; Wed, 28 Jan 2004
         13:07:03 +0100 (CET)
From:
RemoveMEWebshield.SMTP.V4.5.MR1a.Mail.ServiceKILLspamspamRemoveMEfitch6.uni2.net> Date: Wed Jan 28 13:07:35 2004
To: <
TakeThisOuTowner-piclistspammitvma.mit.edu>
Subject: Returned Mail: Error During Delivery

------ Here is your List of Failed Recipients ------
<spamBeGonejanlKILLspamspamTakeThisOuTlundbeck.com>


Mail Server is down or unreachable.

-------- Here Is Your Returned Mail --------
Received: FROM lundbeck.com BY ludk0163.lundbeck.com ; Wed Jan 28 12:53:29 2004 +0100
Received: from ([10.10.3.249])
       by HLUIMX26A.lundbeck.com with SMTP ;
       Wed, 28 Jan 2004 12:52:52 +0100 (CET)
Received: from cherry.ease.lsoft.com ([209.119.0.109]) by HLUSF26A.lundbeck.com; Wed, 28 Jan 2004 12:52:17 +0100 (CET)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <EraseME2.00CC0D0F.....spamKILLspamcherry.ease.lsoft.com>; Wed, 28 Jan 2004 6:52:47 -0500
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8e)
         with spool id 6954 for spamPICLISTspamMITVMA.MIT.EDU; Wed, 28 Jan 2004
         06:52:42 -0500
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 7929; Wed, 28 Jan 2004 06:51:41 -0500
Received: from mail.bookham.com [195.166.17.164] by mitvma.mit.edu (IBM VM SMTP
         Level 430) via TCP with ESMTP ; Wed, 28 Jan 2004 06:51:40 EST
X-Warning: mitvma.mit.edu: Host mail.bookham.com claimed to be
          mimesweeper.bookham.com
Received: from alpha.bookham.com (unverified) by mimesweeper.bookham.com
         (Content Technologies SMTPRS 4.3.6) with ESMTP id
         <T6768ade595c0a801027f4STOPspamspammimesweeper.bookham.com> for
         <PICLISTSTOPspamspamKILLspammitvma.mit.edu>; Wed, 28 Jan 2004 11:37:38 +0000
Received: from pai-smx-01.europe.bkhm.net ([47.203.128.192]) by
         alpha.bookham.com with SMTP (Microsoft Exchange Internet Mail Service
         Version 5.5.2650.21) id CHVN6Y4N; Wed, 28 Jan 2004 11:33:33 -0000
Received: by pai-smx-01.europe.bkhm.net with Internet Mail Service
         (5.5.2653.19) id <Z8N16QA7>; Wed, 28 Jan 2004 11:36:38 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Message-ID:  <@spam@23075D38FE1C8144847DFAECA3565F270173E37D.....spamspampai-smx-01.europe.bkhm.net>> Date:         Wed, 28 Jan 2004 11:36:32 -0000
Reply-To:     pic microcontroller discussion list <
spamPICLIST.....spam.....MITVMA.MIT.EDU>
Sender:       pic microcontroller discussion list <PICLIST.....spamMITVMA.MIT.EDU>
From:         Michael Rigby-Jones <KILLspamMichael.Rigby-Jonesspam_OUTspamBOOKHAM.COM>
Subject: Re: [PIC:] divide by 10 question
To:           spam_OUTPICLISTspamTakeThisOuTMITVMA.MIT.EDU
Precedence: list

>{Original Message removed}

2004\01\30@170909 by John N. Power

flavicon
face
> From:         Pedro Drummond[SMTP:.....electronics.....spamRemoveMEGLOBO.COM]
> Sent:         Friday, January 30, 2004 1:12 PM
> To:   spam_OUTPICLISTTakeThisOuTspamEraseMEMITVMA.MIT.EDU
> Subject:      Re: [EE]: Challenge for keen minds

> Thank you all for the help and interest.

> Ok, time for more data:

> The space being protected is a metallic box, the size of an elevator, that
> will be towed by small trucks. Its metallic "door" (actually a double door)
> is the gate I mentioned. During long trips, these boxes are commonly moved
> from truck to truck, with long periods waiting for the next one, with no
> guards nearby. Although there is a very strong lock, theft was detected at
> final destination in locked boxes (i.e., someone opened it, took some goods,
> and somehow relocked it).

Sounds like an inside job. Someone with a key simply unlocked it. If that is
the case, you will have to be very careful with anything you do, since the
information will leak to the perpetrator.
Also, are you sure that the items taken were in the box to begin with. Perhaps
thet were taken before the box was initially sealed.
If it weren't for the power consumption issue, you could use an ultrasonic
detector to sense the door opening. The resonant frequency of the box would
change with the door open or with someone standing inside. Also, ultrasound
reflections from the door and walls would change.

John Power

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspamBeGonespamKILLspammitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@171706 by THE NELSONS

picon face
Some things to consider.  What is the value of the items being stolen
and the punishment for stealing them?  If the persons stealing the items
finds the data logger and knows what it is and destroys it then it is
useless.  most criminals will destroy the things that can identify
them.  The data logger has to be kept secret and hidden to be of use.
And in the court system here in the USA after first court case the
secret is out.

I think if the box is light tight use a light detecter and make the data
logger as small as possible and keep it hidden and secret.

Bob

Pedro Drummond wrote:

{Quote hidden}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservspamspammitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@174949 by Olin Lathrop

face picon face
Robert Rolf wrote:
> And why not put a disposable camera in a box over the door or shooting
> through a hole in the side wall.
> Easy enough to have it snap an image when the door opens (with a 1
> sec delay), which presumably happens only at the final destination.

That's it, put a cheesy disposable camera in there with a nice obvious flash
2 seconds after the door opens.  Check for presence of camera.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@175203 by Pedro Drummond

flavicon
face
Although I like the idea of having 2 sensors, this will be known by
everyone. There is no way I will have something installed in theses boxes
that people working with it 24/7 will not know and understand. What happens
today is that people that know these boxes are opening it, stealing from it,
and closing it again ! Inside job, definitely, but not with a key. They
rebuild the box seal (I don't exactly know how this seal is, so far). My
device will definitely be welded in the box, and I am not sure this is
enough protection for it.

Items in the box are double-checked at the beginning, and will be checked at
the end of every trip. When something is
missing, the question is WHEN did it happen, so they can point out the
responsibles.

I like the idea of a button out of the reach (jamb near the hinge, flange
protecting it). Maybe even a PIR detector, if well-protected. Taking a
picture would be perfect, but I am skeptical about how to implement it (type
of camera,
protection, etc).








{Original Message removed}

2004\01\30@195011 by James Nick Sears

picon face
I'm pretty sure they did this for the big New Years Eve celebration in New
York right after the WTC attacks.

> How about welding the door or lock shut between destinations?  (don't
laugh,
> they welded manhole covers here in the US as a security measure in some
> city - forget which and when)
>
> Dave
>
> --
> http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> email .....listservRemoveMEspammitvma.mit.edu with SET PICList DIGEST in the body
>

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@231029 by Russell McMahon

face
flavicon
face
> Yes, but the problem here is someone that, when opening the gate,
> immediately recomposes the sensor (for example, puting a second magnet
close
> to the reed switch). If he takes, say, 2-3 secs to do it, it will be
> analyzed afterwards as a glitch, probably caused by truck movement. The
> ideal would be some kind of sensor not easily or quickly "recomposed" when
> opening the gate.

The system could easily be designed so that no significant glitching occurs
due to motion. Also, the thieves would need to know in advance that there
was an alarm and how it worked. If they get that right first time it
strongly suggests inside knowledge.


       RM

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

.
Return-Path: <>
Received: from mitvma.mit.edu ([18.92.0.3]) by tomts42-srv.bellnexxia.net
         (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
         id <RemoveME20040128150152.MSQL22687.tomts42-srv.bellnexxia.netspamspamSTOPspammitvma.mit.edu>>          for <.....piclist_errorsEraseMEspamSYMPATICO.CA>;
         Wed, 28 Jan 2004 10:01:52 -0500
Received:  by mitvma.mit.edu (IBM VM SMTP Level 430) via spool with SMTP id 6722 ; Wed, 28 Jan 2004 10:01:49 EST
Received: from MITVMA.MIT.EDU (NJE origin LISTSERV@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 3971; Wed, 28 Jan 2004 10:01:49 -0500
Date:         Wed, 28 Jan 2004 10:01:49 -0500
From:         "L-Soft list server at MITVMA.MIT.EDU (1.8e)"
             <spamBeGoneLISTSERVspamRemoveMEMITVMA.MIT.EDU>
Subject: PICLIST: error report from NT.MASSMIND.ORG
To:           .....listsjoshEraseMEspam3MTMP.COM,
             "For spamBlackholeeclipsespam_OUTspam@spam@Earthlink.Net" <spampiclist_errors@spam@spamSTOPspamSYMPATICO.CA>
Message-ID:   <LISTSERV%spamBeGone2004012810014906spamBeGonespam@spam@MITVMA.MIT.EDU>
X-LSV-ListID: None

The enclosed message has been identified as a delivery error for the PICLIST
list because it was sent to 'RemoveMEowner-piclistRemoveMEspamRemoveMEMITVMA.MIT.EDU'.

------------------------------ Message in error -------------------------------
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 3969; Wed, 28 Jan 2004 10:01:49 -0500
Received: from nt.massmind.org [66.13.172.18] by mitvma.mit.edu (IBM VM SMTP
         Level 430) via TCP with SMTP ; Wed, 28 Jan 2004 10:01:48 EST
X-Comment: mitvma.mit.edu: Mail was sent by nt.massmind.org
To: owner-piclistKILLspamspamspamMITVMA.MIT.EDU
From: Mail Administrator<spam_OUTPostmaster@spam@spamnt.massmind.org>
Reply-To: Mail Administrator<TakeThisOuTPostmasterspam_OUTspamnt.massmind.org>
Subject: Mail System Error - Returned Mail
Date: Wed, 28 Jan 2004 06:54:53 -0800
Message-ID: <KILLspam20040128145453715.AAC388.....spamTakeThisOuTnt.massmind.org>> MIME-Version: 1.0
Content-Type: multipart/mixed;
               Boundary="===========================_ _= 3203125(388)"
Content-Transfer-Encoding: 7BIT


--===========================_ _= 3203125(388)
Content-Type: text/plain

This Message was undeliverable due to the following reason:

This message passed through a number of mail servers
greater than the maximum number specified in the
Maximum MTA Hops field. This probably indicates that
there are accounts on separate machines that forward
mail to each other.

There may also be a problem with the host address or
Domain Name System records.

Maximum Hops: 15

Please reply to
TakeThisOuTPostmasterEraseMEspamRemoveMEnt.massmind.org
if you feel this message to be in error.


--===========================_ _= 3203125(388)
Content-Type: message/rfc822

Received: from cherry.ease.lsoft.com ([209.119.0.109]) by nt.massmind.org
         (Post.Office MTA v3.5.3 release 223 ID# 0-12345L500S10000V35)
         with ESMTP id org for <spam_OUTarchiveRemoveMEspam.....PICLIST.ORG>;
         Fri, 23 Jan 2004 06:28:43 -0800
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <spam18.00CB2C15KILLspamspamKILLspamcherry.ease.lsoft.com>; Fri, 23 Jan 2004 9:31:15 -0500
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8e)
         with spool id 1232 for spamPICLISTspam_OUTspamMITVMA.MIT.EDU; Fri, 23 Jan 2004
         09:31:06 -0500
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 9737; Fri, 23 Jan 2004 09:29:00 -0500
Received: from audiomind.dk [213.237.88.238] by mitvma.mit.edu (IBM VM SMTP
         Level 430) via TCP with ESMTP ; Fri, 23 Jan 2004 09:28:59 EST
Received: from winbox.Audiomind.local (192.168.2.3:8136) by audiomind.dk with
         [XMail 1.16 (Linux/Ix86) ESMTP Server] id <SD67C> for
         <STOPspamPICLISTspam_OUTspamspamBeGoneMITVMA.MIT.EDU> from <spam_OUTPICLISTspamspamBeGoneMITVMA.MIT.EDU>; Fri, 23 Jan
         2004 15:25:14 +0100
Received: from mail pickup service by winbox.Audiomind.local with Microsoft
         SMTPSVC; Fri, 23 Jan 2004 15:24:39 +0100
Received: from audiomind.dk ([192.168.2.6]) by winbox.intra.audiomind.dk with
         Microsoft SMTPSVC(6.0.3790.0); Tue, 20 Jan 2004 12:39:52 +0100
Received: from cherry.ease.lsoft.com (209.119.0.109:9696) by audiomind.dk with
         [XMail 1.16 (Linux/Ix86) ESMTP Server] id <SCF71> for
         <EraseMEsorenspamKILLspamAUDIOMIND.DK> from <EraseMEowner-piclistRemoveMEspamMITVMA.MIT.EDU>; Mon, 19 Jan
         2004 16:16:08 +0100
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com
         (LSMTP for Digital Unix v1.1b) with SMTP id
         <.....10.00CAB6B5spamspam_OUTcherry.ease.lsoft.com>; Mon, 19 Jan 2004 10:16:03 -0500
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8e)
         with spool id 9604 for @spam@PICLISTEraseMEspamspamMITVMA.MIT.EDU; Mon, 19 Jan 2004
         10:15:55 -0500
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 7651; Mon, 19 Jan 2004 10:14:53 -0500
Received: from extsmtp2.localnet.com [207.251.201.58] by mitvma.mit.edu (IBM VM
         SMTP Level 430) via TCP with SMTP ; Mon, 19 Jan 2004 10:14:52 EST
Received: (qmail 7068 invoked from network); 19 Jan 2004 15:16:19 -0000
Received: from unknown (HELO smtp2.localnet.com) (10.0.7.15) by
         extsmtp2.localnet.com with SMTP; 19 Jan 2004 15:16:19 -0000
Received: (qmail 10974 invoked from network); 19 Jan 2004 15:14:54 -0000
Received: from unknown (HELO kmp) (66.153.68.142) by mail1.localnet.com with
         SMTP; 19 Jan 2004 15:14:54 -0000
X-Comment: mitvma.mit.edu: Mail was sent by audiomind.dk
X-Comment: mitvma.mit.edu: Mail was sent by extsmtp2.localnet.com
X-AV-Scanned: yes  dd9793dd6eda64c5f0949e5ecd63b525
X-AV-Scanned: yes  5bade83a3c76c42b692c5fe64c60b6f7
X-Deliver-To: sorenTakeThisOuTspamKILLspamaudiomind.dk
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Precedence: list
X-OriginalArrivalTime: 20 Jan 2004 11:39:55.0641 (UTC)
                      FILETIME=[20258690:01C3DF4A]
Message-ID:  <RemoveMEKHEAKGMGPPBIPOHGAOODCEBHCMAA.no_spamTakeThisOuTspamlocalnet.com>> Date:         Mon, 19 Jan 2004 10:15:04 -0500
Reply-To:     pic microcontroller discussion list <
@spam@PICLISTSTOPspamspamMITVMA.MIT.EDU>
Sender:       pic microcontroller discussion list <TakeThisOuTPICLISTTakeThisOuTspamRemoveMEMITVMA.MIT.EDU>
From:         Ken Pergola <spam_OUTno_spamspamspam.....LOCALNET.COM>
Subject: Re: [EE]: NEC's version of the Intel 8255 Programmable Peripheral Interface
To:           PICLIST.....spam@spam@MITVMA.MIT.EDU
In-Reply-To:  <spamBeGoneE1AiZB1-0006bg-00spamspam_OUTgrouse.mail.pas.earthlink.net>

Dave Tweed wrote:

> I'm close, but not quite there. I have a 1987 NEC data book that has
> the uPD71055C (-G and -L as well), but not the -10 version.
>
> I see you've already had better offers, but I just wanted to let you
> know that there are plenty of us data book pack rats out here. :-)
> My oldest ones are from Intel and National Semi around 1976-77.
>

Hi Dave,

Hey thanks. I appreciate your time in checking. Edward Gisske and Tom
Deutschman have helped me out in my request and I have a data sheet. Thank
you kindly Edward and Tom!

I used to have some old books too. Then Oprah did a show on simplifying
one's life -- if you don't use something in a year, chuck it out.
Guess what happened to some of my prized data books? Big mistake on my part.

Take care Dave,

Ken Pergola

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

--===========================_ _= 3203125(388)--

.

2004\01\31@001731 by Brooke Clarke

flavicon
face
Hi Pedro:

This sounds like a classic burglar alarm scenario.  I would recommend
using a strong box that's outside the cage, maybe mounted on one of the
doors or on the side of the box near the doors.  This box needs to have
a way to open it and lock it.  It will contain the logging equipment.
Drill two small holes in this box and fit them with insulating sleeves.
Now run a piece of wire, Nicrome would work thread the wire through an
insulated hole in the left side of the box, in and out of the left gate,
in and out of the right gate and through an insulated hole in the right
side of the box and back inside the strong box through the other
insulated sleeve.

Now measure the resistance of the wire and if it goes either up or down
by more than some % of the nominal value log a door opening.  You will
probably not log a door closing, but that really doesn't matter in this
case. If there are large temperature variations yo could use cut two
lengths of insulated wire. One would be used in the detection loop and
the other would be inside the strong box connected in a bridge
configuration in such a way as to balance out the delta R due to
temperature.  Even if the temp did not have a large range, using a
bridge like this would allow sensing smaller resistance variations,
making it harder ot defeat.

If you used a short loop of wire that just went around the center posts
of the two doors it could be defeated by someone sawing a cut thorough
one of the posts so that they could open the doors without breaking the
wire.  That's why the threading across both doors and looping though the
box walls.  This could still be defeated by cutting all the gate posts
and gate bars, but would take a very long time.

Have Fun,

Brooke Clarke, N6GCE
http://www.PRC68.com

{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
spampiclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu

.

2004\01\31@012710 by Robert Rolf

picon face
Olin Lathrop wrote:
>
> Robert Rolf wrote:
> > And why not put a disposable camera in a box over the door or shooting
> > through a hole in the side wall.
> > Easy enough to have it snap an image when the door opens (with a 1
> > sec delay), which presumably happens only at the final destination.
>
> That's it, put a cheesy disposable camera in there with a nice obvious flash
> 2 seconds after the door opens.  Check for presence of camera.

Who said anything about using flash? But if you think it helps
get a clear picture, use TWO cameras. One obvious (dummy even),
one well hidden. Thief takes $5.00 camera with $2.00 relay used to
press button. Hidden camera gets good picture of thief and is the one
that actually triggers the flash. The only trick will be keeping
the flash fully charged. This is made easier if you disconnect the
'flash ready' neon bulb. I've been bitten by disposable camera capacitor
on cameras that I've had sitting in a box for 3 months so a simple
1 second on, 5 minute off cmos timer cct would probably be sufficient
to keep it fully charged.

A local homeowner put a camera in his back entry after repeated
break ins. Got a great shot of a couple of punks breaking in through
his back entrance. They didn't even notice the camera
flash going off what with the alarm noise.

KISS (keep it simple stupid) sometimes works the best.

Of course he will control everything with a PIC.

Robert

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamspamTakeThisOuTmitvma.mit.edu

.
Return-Path: <>
Received: from mitvma.mit.edu ([18.92.0.3]) by tomts1-srv.bellnexxia.net
         (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
         id <RemoveME20040127233807.YZQK10330.tomts1-srv.bellnexxia.netRemoveMEspammitvma.mit.edu>>          for <TakeThisOuTpiclist_errors@spam@spam@spam@SYMPATICO.CA>;
         Tue, 27 Jan 2004 18:38:07 -0500
Received:  by mitvma.mit.edu (IBM VM SMTP Level 430) via spool with SMTP id 6053 ; Tue, 27 Jan 2004 18:38:04 EST
Received: from MITVMA.MIT.EDU (NJE origin LISTSERV@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 0332; Tue, 27 Jan 2004 18:38:04 -0500
Date:         Tue, 27 Jan 2004 18:38:04 -0500
From:         "L-Soft list server at MITVMA.MIT.EDU (1.8e)"
             <TakeThisOuTLISTSERVspamspamMITVMA.MIT.EDU>
Subject: PICLIST: error report from YAHOO.COM
To:           KILLspamlistsjoshKILLspamspamspamBeGone3MTMP.COM,
             spamBeGonepiclist_errorsKILLspamspamSYMPATICO.CA
Message-ID:   <LISTSERV%2004012718380446@spam@spamKILLspamMITVMA.MIT.EDU>
X-LSV-ListID: None

The enclosed message has been identified as a delivery error for the PICLIST
list because it was sent to 'EraseMEowner-piclistRemoveMEspam@spam@MITVMA.MIT.EDU'.

------------------------------ Message in error -------------------------------
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 0330; Tue, 27 Jan 2004 18:38:04 -0500
Received: from mta107.mail.sc5.yahoo.com [66.163.174.135] by mitvma.mit.edu
         (IBM VM SMTP Level 430) via TCP with SMTP ; Tue, 27 Jan 2004 18:38:04
         EST
X-Comment: mitvma.mit.edu: Mail was sent by mta107.mail.sc5.yahoo.com
From: RemoveMEMAILER-DAEMONspamspamEraseMEyahoo.com
To: STOPspamowner-piclist.....spammitvma.mit.edu
X-Loop: spamBeGoneMAILER-DAEMONRemoveMEspamRemoveMEyahoo.com
Subject: Delivery failure

Message from yahoo.com.
Unable to deliver message to the following address(es).

<@spam@hbarregrdspamBeGonespamyahoo.com>:
Sorry, your message to spam_OUThbarregrdspamspamyahoo.com cannot be delivered.  This account is over quota.

--- Original message follows.

Return-Path: <spamowner-piclistspamspamspammitvma.mit.edu>
Received: from 209.119.0.109  (EHLO cherry.ease.lsoft.com) (209.119.0.109)
 by mta107.mail.sc5.yahoo.com with SMTP; Tue, 27 Jan 2004 14:28:05 -0800
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <spamBeGone2.00CBF9B1KILLspamspamKILLspamcherry.ease.lsoft.com>; Tue, 27 Jan 2004 15:17:11 -0500
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8e)
         with spool id 2001 for TakeThisOuTPICLISTspamspamMITVMA.MIT.EDU; Tue, 27 Jan 2004
         15:17:06 -0500
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 3694; Tue, 27 Jan 2004 15:16:36 -0500
Received: from smtp1.clear.net.nz [203.97.33.27] by mitvma.mit.edu (IBM VM SMTP
         Level 430) via TCP with ESMTP ; Tue, 27 Jan 2004 15:16:35 EST
X-Comment: mitvma.mit.edu: Mail was sent by smtp1.clear.net.nz
Received: from jc2 (218-101-65-98.dialup.clear.net.nz [218.101.65.98]) by
         smtp1.clear.net.nz (CLEAR Net Mail) with SMTP id
         <spamBeGone0HS600CQ70BOTSspamsmtp1.clear.net.nz> for EraseMEPICLISTEraseMEspamMITVMA.MIT.EDU; Wed,
         28 Jan 2004 09:16:37 +1300 (NZDT)
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <spamBeGoneJMEDIICJJCPFFFCBMICGAEILCKAA.piclistspam_OUTspam.....outeredge.net>>            <029401c3e4a4$e421dda0$7223fea9@jc2>
           <005701c3e4a7$94719950$1308a8c0@Daniel>
           <02be01c3e4ad$5dc9fea0$7223fea9@jc2>
           <01a401c3e4eb$e7498b30$0100a8c0@xppro>
Message-ID:  <005201c3e512$a8f36000$7223fea9@jc2>
Date:         Wed, 28 Jan 2004 09:17:55 +1300
Reply-To:     pic microcontroller discussion list <
spamPICLISTspamMITVMA.MIT.EDU>
Sender:       pic microcontroller discussion list <RemoveMEPICLISTKILLspamspamKILLspamMITVMA.MIT.EDU>
From:         Jinx <EraseMEjoecolquittspamBeGonespamspamCLEAR.NET.NZ>
Subject: Re: [EE:] PICLIST SPECIFIC VIRUS ALERT
To:           KILLspamPICLISTspamMITVMA.MIT.EDU
Precedence: list

> Interesting picture. It appears to be an old PC chassis used as a
> grill.In times past, many stampings of this nature were Cadmium
> plated. When you cook with them the results can be lethal. The
> usual culprit is refrigerator shelves

I thought that too, wouldn't trust anything made into a BBQ that wasn't
supposed to be a BBQ. And they probably used building off-cuts with
H4 CCA preservative. Gives the meat that nice "tangy" flavour ;-)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
*** MESSAGE TRUNCATED ***


..
.

2004\01\31@030215 by Jake Anderson

flavicon
face
now i'm just wating for the quantum entangled photons ;->

> -----Original Message-----
> From: pic microcontroller discussion list
> [PICLISTspam_OUTspamspamMITVMA.MIT.EDU]On Behalf Of Brooke Clarke
> Sent: Saturday, 31 January 2004 3:16 PM
> To: PICLISTspamspam@spam@MITVMA.MIT.EDU
> Subject: [EE]: Challenge for keen minds
>
>
> Hi Pedro:
>
> This sounds like a classic burglar alarm scenario.  I would recommend
> using a strong box that's outside the cage, maybe mounted on one of the
> doors or on the side of the box near the doors.  This box needs to have
> a way to open it and lock it.  It will contain the logging equipment.
> Drill two small holes in this box and fit them with insulating sleeves.
> Now run a piece of wire, Nicrome would work thread the wire through an

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-request.....spammitvma.mit.edu

.

2004\01\31@080722 by Olin Lathrop

face picon face
Robert Rolf wrote:
>> That's it, put a cheesy disposable camera in there with a nice
>> obvious flash 2 seconds after the door opens.  Check for presence of
>> camera.
>
> Who said anything about using flash?

That was a joke: Make something so in your face that the crooks have to
remove it, then trigger the actual alarm by the removal of the in-your-face
object.

The time for serious responses on this thread has long since past.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-request@spam@spammitvma.mit.edu

.

2004\01\31@084915 by Peter L. Peres

picon face
1. *rotary* rate accelerometer (Tokin, Murata etc). Is insensitive to
shaking but has output for *rotation*, even slow rotation.

2. metal detector (proximity detector) in suitable place around frame or
on gate proper, or induction loop buried in ground under gate, or on gate
post. Two loops and you can tell the direction of vehicles passing through
open gate.

3. 2x ir beam can tell gate open/closed and direction of passing when
someone eventually passes through it.

many more,

Peter

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestspammitvma.mit.edu

.

2004\01\31@084917 by Peter L. Peres

picon face
Does the closed box have windows ? If not, is it dark inside when the door
is closed ? If so, all you need is a LDR to sense when the door is open
(at night they will likely use a flashlight). So it need not be anywhere
near the door.

Peter

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestRemoveMEspammitvma.mit.edu

.

2004\01\31@111501 by M. Adam Davis

flavicon
face
Since this is a double door, you need to be aware of either door being
open (ie, they could simply close the one with the sensor but leave the
other open)

Consider welding two boxes of aluminum on each door opposite each other
very close together.  When the door opens they are unaligned and/or far
apart.  In one box you put the data logger with a small metal detector
type coil set at a specific frequency.

The other box contains another coil and capacitor which, when close to
the detector side, modifies the oscillation frequency significantly.  By
monitoring the actual frequency you can not only get a good idea of when
they move apart, but how far apart they are.  Since they can be
completely sealed inside a metal box (does affect frequency change and
sensitivty, but it would still work well) then they could only defeat it
if they also had such a coil.

The kicker is that they would not only have to have such a coil, but it
would have to modify the frequency the same way both your coil and the
metal box does.  Fuirthermore they'd have to somehow move their coil in
synchronization with the door so that your receiver didn't detect the
drop and rise in frequency.  Since this is all mounted on the inside it
would be nearly impossible without quite a bit of additional equipment
(measuring the field, etc) and very good reflexes, if possible at all
without an active external transmitter.

Truck vibration and movement wouldn't affect it.  Temperature would, so
you may want to look at a temperature sensor so you can compensate for
capacitor values changing a bit.

Additional security could be provided by using different frequency coils
so no one solution could work for all boxes.  The circuit could be
calibrated when installed, or for higher sensitivity every time the box
is sealed/opened/logging data read.

Of course, you realize that you should also put in a GSM or GPRS module
so it can call or page you when a box is opened with its serial number.
Better still, attach a GPS as well and log its movement, transmitting
location and time information to your pager when it's opened.  Attach a
small digital camera and send yourself a picture.  Etc, etc, etc.

-Adam

Pedro Drummond wrote:

{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspam_OUTspamTakeThisOuTmitvma.mit.edu

.

2004\01\31@151955 by WFT

face
flavicon
face
How about two items for the logger ?

Item 1 attaches to the inside of the door.
It is armed and when the door closes, it
connects across the door and the jamb.
If it is interrupted, it sends out an ultrasonic
scream.

Item 2
A logger hidden in the box ( in different places )
detects the specific tone being sent and logs that
the scream occurred.  More than one logger could
be put in the box.

I missed out on how expensive the stolen items are ????



Gus S. Calabrese  303 964.9670
http://www.omegadogs.com    http://www.cinternational.com  http://www.wftelectronics.com

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-request@spam@spamRemoveMEmitvma.mit.edu

.
Return-Path: <>
Received: from mitvma.mit.edu ([18.92.0.3]) by tomts37-srv.bellnexxia.net
         (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
         id <spam20040130080801.MMCS8220.tomts37-srv.bellnexxia.netspamspammitvma.mit.edu>>          for <@spam@piclist_errorsspam_OUTspamSYMPATICO.CA>;
         Fri, 30 Jan 2004 03:08:01 -0500
Received:  by mitvma.mit.edu (IBM VM SMTP Level 430) via spool with SMTP id 8263 ; Fri, 30 Jan 2004 03:07:58 EST
Received: from MITVMA.MIT.EDU (NJE origin LISTSERV@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 9777; Fri, 30 Jan 2004 03:07:58 -0500
Date:         Fri, 30 Jan 2004 03:07:58 -0500
From:         "L-Soft list server at MITVMA.MIT.EDU (1.8e)"
             <.....LISTSERVspam.....MITVMA.MIT.EDU>
Subject: PICLIST: error report from YAHOO.CO.UK
To:           spamlistsjoshKILLspamspam3MTMP.COM,
             "For RemoveMEBlackholeeclipseRemoveMEspamEarthlink.Net" <KILLspampiclist_errors.....spamKILLspamSYMPATICO.CA>
Message-ID:   <LISTSERV%2004013003075829spam_OUTspamspam_OUTMITVMA.MIT.EDU>
X-LSV-ListID: None

The enclosed message has been identified as a delivery error for the PICLIST
list because it was sent to 'KILLspamowner-piclistspam@spam@MITVMA.MIT.EDU'.

------------------------------ Message in error -------------------------------
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 9775; Fri, 30 Jan 2004 03:07:58 -0500
Received: from mta118.mail.ukl.yahoo.com [217.12.11.55] by mitvma.mit.edu (IBM
         VM SMTP Level 430) via TCP with SMTP ; Fri, 30 Jan 2004 03:07:58 EST
X-Comment: mitvma.mit.edu: Mail was sent by mta118.mail.ukl.yahoo.com
From: @spam@MAILER-DAEMONRemoveMEspamyahoo.co.uk
To: owner-piclist@spam@spamEraseMEmitvma.mit.edu
X-Loop: spam_OUTMAILER-DAEMONspam_OUTspamRemoveMEyahoo.co.uk
Subject: Delivery failure

Message from yahoo.co.uk.
Unable to deliver message to the following address(es).

<RemoveMEviniciusbhspam.....yahoo.co.uk>:
Sorry, your message to spamviniciusbh@spam@spamyahoo.co.uk cannot be delivered.  This account is over quota.

--- Original message follows.

Return-Path: <owner-piclistTakeThisOuTspammitvma.mit.edu>
Received: from 209.119.0.109  (EHLO cherry.ease.lsoft.com) (209.119.0.109)
 by mta118.mail.ukl.yahoo.com with SMTP; Fri, 30 Jan 2004 08:08:00 +0000
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <.....23.00CC2A67spamTakeThisOuTcherry.ease.lsoft.com>; Thu, 29 Jan 2004 9:04:58 -0500
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8e)
         with spool id 3752 for EraseMEPICLISTspamKILLspamMITVMA.MIT.EDU; Thu, 29 Jan 2004
         09:04:48 -0500
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 0291; Thu, 29 Jan 2004 09:03:38 -0500
Received: from smtp-out1.xs4all.nl [194.109.24.11] by mitvma.mit.edu (IBM VM
         SMTP Level 430) via TCP with ESMTP ; Thu, 29 Jan 2004 09:03:37 EST
X-Comment: mitvma.mit.edu: Mail was sent by smtp-out1.xs4all.nl
Received: from PAARD (a213-84-20-53.adsl.xs4all.nl [213.84.20.53]) by
         smtp-out1.xs4all.nl (8.12.10/8.12.10) with ESMTP id i0TE3c4H062704
         for <PICLISTEraseMEspamMITVMA.MIT.EDU>; Thu, 29 Jan 2004 15:03:39 +0100 (CET)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Message-ID:  <000201c3e670$b3266770$0b00a8c0@PAARD>
Date:         Thu, 29 Jan 2004 15:03:40 +0100
Reply-To:     pic microcontroller discussion list <EraseMEPICLISTspamspamBeGoneMITVMA.MIT.EDU>
Sender:       pic microcontroller discussion list <TakeThisOuTPICLISTspamTakeThisOuTMITVMA.MIT.EDU>
From:         Wouter van Ooijen <wouterspamspam_OUTVOTI.NL>
Organization: Van Ooijen Technische Informatica
Subject: Re: 12F675
To:           spamPICLIST@spam@spamMITVMA.MIT.EDU
In-Reply-To:  <spam_OUT95.38105c65.2d4a6ba2TakeThisOuTspamKILLspamaol.com>
Precedence: list

> understanding is the MCLR must always be pulled high for
> normal operation.

You confuse the function and the pin. In the fuses you can assign the
pin to the I/O function and have MCLR fulled high internally.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.
*** MESSAGE TRUNCATED ***


..
.

2004\01\31@213310 by David Schmidt

flavicon
face
Here's a couple of questions:

- why can't you change shipping carriers?
- why can't you insure your cargo?  Make a claim a few times and I'll bet
they crack down on their own robbery.

Dave

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-request@spam@spamspammitvma.mit.edu

.

2004\01\31@224651 by Pedro Drummond

flavicon
face
As I mentioned, the insurance company is also suffering with this problem,
because the cargo "belongs" to 2 or 3 parties along its way. If the moment
it happens is known, the insurance company will point out the responsible
every time. Hopefully, after some time, this problem will come to an end,
insurance may fall, shipping cost may fall.



{Original Message removed}


'[EE]: Challenge for keen minds'
2004\02\01@225812 by Pedro Drummond
flavicon
face
Interesting ! But wouldn't 2 thick metal walls invalidate this ? (one for
each device, on each door).


{Original Message removed}

2004\02\02@030757 by hael Rigby-Jones

picon face
>-----Original Message-----
>
>The space being protected is a metallic box, the size of an
>elevator, that will be towed by small trucks. Its metallic
>"door" (actually a double door) is the gate I mentioned.
>During long trips, these boxes are commonly moved from truck
>to truck, with long periods waiting for the next one, with no
>guards nearby. Although there is a very strong lock, theft was
>detected at final destination in locked boxes (i.e., someone
>opened it, took some goods, and somehow relocked it). A
>redesign of the metal box is being made, but it will be a long
>time until all of them are replaced. It is enough for now to
>help the insurance company in detecting WHEN and for HOW LONG
>it was opened, so the responsible will be known. I do not mind
>reading its information only when the gate is open, and I
>cannot modify the gate, only add some small device close to the door.
>

How about a pressure sensor?  Opening a door will produce a fast pressure
increase (or decrease depending on if the door openes in or out).  You would
obviously have to look for a reasonably fast change in pressure rather than
a set limit.  However, it may be possible to defeat this by opening the door
very slowly.

I like the IR reflecting off the doors idea, but I suspect this isn't
practical if the box is going to be full of "stuff" that gets in the way.

Going down the burglar alarm route, how about some kind of volumetric
sensing, such as ultrasonics or microwave?

Regards

Mike




=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to
RemoveMEpostmasterRemoveMEspamTakeThisOuTbookham.com.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

.

2004\02\02@040100 by Jinx

face picon face
> Going down the burglar alarm route, how about some kind of
> volumetric sensing, such as ultrasonics or microwave?

Could be troublesome if the load shifts, but that would probably
happen only in transit and could be ignored

Is it possible to put the monitor inside the door handle or mechanism ?
Use a tilt switch to activate the monitor when the handle is moved from
horizontal to vertical (if it's the type of container handle I'm thinking
of) ?
Could be a very small SMT circuit - a PIC, RTC, a miniature tilt switch
and a coin cell

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

.

2004\02\02@084305 by Alan B. Pearce

face picon face
>Inside job, definitely, but not with a key. They rebuild the
>box seal (I don't exactly know how this seal is, so far).

I believe this is real easy to do with the modern cynoacrylate type
adhesives, where the seal is of the type with a steel wire through a pressed
lead seal. Probably also applies to any other "use once and damage to open"
type seal.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

.

2004\02\03@150649 by M. Adam Davis

flavicon
face
It would never invalidate it completely, but it would dampen it
significantly, which is why I suggested aluminum for the actual box, or
at least the face.  Alternately use the ferromagnetic properties of the
metal to your advantage, and essentially turn the face of the two boxes
into a transformer.  The transformer resonates at a certian frequency
without the other box, but when it is brought near it affects the
resonant frequency.

There will be some coupling through the rest of the container, but that
will be minimal compared to the coupling of the two small boxes next to
each other.

Do some tests.  A weakness is that since it is low power, then someone
from the outside could use a high power electromagnet/transmitter to
force the device to continue to oscillate at the specific frequency, but
this can be fixed by having a seperate coil at away fromt he primary
coil which resonates at a seperate frequency.  Any signal strong enough
to trick the first coil into thinking it's still got a closed door will
also affect the frequency of the secondary coil, and you can detect this
trick.  Alternately, use a RFID type setup in the other box which
responds to the main box with a sequence of frequencies - much harder to
simulate externally.

-Adam

Pedro Drummond wrote:

>Interesting ! But wouldn't 2 thick metal walls invalidate this ? (one for
>each device, on each door).
>
>
>{Original Message removed}

More... (looser matching)
- Last day of these posts
- In 2004 , 2005 only
- Today
- New search...