ECE 4006 Project Requirements Discussion

From email exchange (gmail) between C. Mote and Endrias Woldegiorgis, April 23, 2005

free webpage hit counter



Charlie Mote 
Endrias, Feel free to send me what you've got. I have been sick since mid-day yesterday...
 4/23/05 
Endrias,

Feel free to send me what you've got. I have been sick since mid-day
yesterday - I hope you are feeling better. I tried calling you this
morning to see where you all are at. I didn't think I was going to be
much more help at this point than reviewing the paper - I can't really
do anything for the presenation and y'all have to decide what is
working sufficiently at this point to include as a group. From what I
have gathered, it's going to be a bit limited - I think it is very
important to focus on the "detect breach" requirement and how massive
a task this was - it doesn't say "show if door open or closed" or
"find temperature in container" or "log data" - it says "detect breach
of cargo container". It's key to focus no this becuases it is so broad
- y'all need to show that the requirement was a bit unrealistic
(without actually saying so) and to point out every accomplishment you
had while pointing out the time and budget required were no where near
what was needed.

Send me what you've got or call me at my folks place - 770-804-8408.

Abracos,

Charlie
- Show quoted text -



On 4/23/05, Endrias Woldegiorgis <endriasw@gmail.com> wrote:
> Hey Dud
>
> I would like you to review my portion of paper when you get a chance...
> I need help in writing
>
> Thanks a lot
>
> Endrias
>
>






 Reply 
Reply to all Reply to allForward Forward Print Add Charlie to Contacts list Delete this message Report phishing Show original Message text garbled?
Charlie Mote 
to Endrias
show details
 4/23/05 



 Reply 
Reply to all Reply to allForward Forward Print Add Endrias to Contacts list Delete this message Report phishing Show original Message text garbled?
Endrias Woldegiorgis 
to me
show details
 4/23/05 

Check this out, exactly as it appears on the project requirements as given to us by Prof. Bennet --
Sensing:
• Detection of breeching of the container walls, floor or ceiling (6 sides)
• Detection of opening, closing or removal of the container doors
• Container seal or lock status
• If there is a breech, you should be able to store and report the data
• There should be continuous monitoring with consideration to maintaining low false alarm rates
• The data should contain a history file with time stamped records of
all container events for that container trip


Dud by the way, you are always a help to me (ALWAYS)...
I'm not good in organization therefore I need help on the presentation.
How we should outline it. Me and B would like to take parts on it. Tell
me how we should start,  what we should have on the slides (like what
kind of pictures and so on) and the order we should present it.
Meaning, shall we do the experiment 1st or the presentation?

give me some inputs..
- Show quoted text -

On Apr 23, 2005, at 2:44 PM, Charlie Mote wrote:

> Endrias,
>
> Feel free to send me what you've got. I have been sick since mid-day
> yesterday - I hope you are feeling better. I tried calling you this
> morning to see where you all are at. I didn't think I was going to be
> much more help at this point than reviewing the paper - I can't really
> do anything for the presenation and y'all have to decide what is
> working sufficiently at this point to include as a group. From what I
> have gathered, it's going to be a bit limited - I think it is very
> important to focus on the "detect breach" requirement and how massive
> a task this was - it doesn't say "show if door open or closed" or
> "find temperature in container" or "log data" - it says "detect breach
> of cargo container". It's key to focus no this becuases it is so broad
> - y'all need to show that the requirement was a bit unrealistic
> (without actually saying so) and to point out every accomplishment you
> had while pointing out the time and budget required were no where near
> what was needed.
>
> Send me what you've got or call me - 770-804-8408.
>
> Abracos,
>
> Charlie
>
>
>
> On 4/23/05, Endrias Woldegiorgis <endriasw@gmail.com> wrote:
>> Hey Dud
>>
>> I would like you to review my portion of paper when you get a
>> chance...
>> I need help in writing
>>
>> Thanks a lot
>>
>> Endrias
>>
>>
>



ReplyForwardInvite Endrias to chat





Hey Endrias,

Thanks for copying the requirements here.

The big question is, what currently works? I mean, what part of the
requirements have we actually met?

As I understand it, there's a circuit which turns on an LED if the
door is open and we can see this through the mote on the laptop -
perhaps it can be logged as well. We also have the peizo circuit,
although it isn't attached to anything and so doesn't send data
anywhere.

I think the best approach would be to start with the theoretical
solution following, point by point, the requirements. So, for example,
detection of breech of any of six (seven actually, the door is split
in half and therefore it's 7, not 6,) sides - how can the container be
breached practically speaking? I had found the data on the steel that
is used for these types of conatiners in the past, although I don't
know it of the top of my head. Let's say it's 1/8" inch corragatd mild
or Corten steel
(http://www.shippingcontainers.com/brchures.htm - used.pdf)

From here:

http://64.233.187.104/search?q=cache:ry_rjSpp7AsJ:www.ussconstruction.com/metal/metal/corten.shtml+corten+steel&hl=en

we know that COR-TEN steel is "a HOT ROOF" meaning it is relatively
highly heat conductive (from wikipedia "mild steel" is the most common
type of steel and is the lowest carbon content.) And here:
http://www.corrosion-doctors.org/Design/corrosion-performance.htm

points out the main difference between mild and corten, that being
that corten is more corrosion resistant in non-salt water
environments, so mild steel is probably pretty similar in terms of
heat conductivity.

It's this kind of detail the profs are going to want to see, and it's
the kind of detail that proves how much work you were expected to do
(that is, an unreasonable amount of work.) Statements like "lacking a
thorough materials engineering study of the exact details of the types
of steel used in the containers, many assumptions were neccesary for
the theoretical approach." need to be included to remind the prof.
that this was a massive undertaking - figuring out what types of
steel, in how many of the types of conatiners, with what kind of heat
conductivity and cutting/drilling resistance, etc. is a project for a
semester in-and-of itself.

But back to how to detect a breach. We know the containers aren't
hermetically sealed (i.e., air-tight), through annocdotal evidence
(news reports of human stowaways surviving in them) and discussions
like this:

http://www.ponl.com/topic/home_page/language_en/about_us/useful_information/cargo_care/condensation_issues

which talk about air and heat exchange between the containers, their
cargo and the environment, so we can't use (as you first suggested) a
simple means of detecting a change in pressure. Also, we can't expect
to pressurize all of the containers in the world, so that route is
just out.

As I wrote about in the first series of postings I made to the group a
few months back, that left just a few options.

Just stepping through each of these points, like I tried to do in my
postings, should point out how much work was neccessary for this
project, just to _meet_
the minimum requirements! Not to mention a detailed study of all the
various circuits and methods of wireless communication (as that one
prof of yours kept hammering with the "why xbow?" question) which
could have been used to meet them.

I think you should start the demo by stating that you could not meet
the requirements - always better to admit short-coming and then go on
to at least show what you have, than it is to proceed as if
everythings fine when it obviously isn't. "We attempted" is a phrase
you should probably use a few times.

I think you want to make it cleat that the group wasn't even really
considering true "real-world" requirements, like scalability,
retro-fitting costs, and possible compliance (meaning how many
containers would actually get systems like this due to the first two
considerations) and instead was focusing on just making a demo to test
some of the possible _concepts_ which further research would need to
address.

This is key - acknowledge we didn't get there, state that we never
anticipated actually getting there and that the exercise was to try to
test some of the _types_ of systems which _probably_ would be
neccessary to actually get there.

Then tell them, briefly, what was accomplished (in writing, this
should be a bullet-point list in order of most important to least -
including "procured volunteer labor [me] and donated materials
[cabinets, circuits, tools]" and listing them (what, I probably put in
around 100 hours of time ~ 30 min./day for 3.5 months (so ~ 55 hours)
plus several larger stints), cabinets, circuits, etc.)), including
creating and posting to the group, getting the motes from Hutto,
placing the orders, everything.

I might very well be able to write this part since I think I have a
pretty good grasp of the accomplishments.

The demo, however, should not have a whole lot of this, and shoud
stick to being a recounting of how much work would have been required
to meet the requirements and how much work it took just to get what we
have (the accomplishments) and then show them what we have. There
shouldn't be a "well, we almost got this part done, we had the parts
and ran out of time, etc." becuase it will seem like whinning - the
proper place to say that "we did at least get these parts" is in the
accomplishments part of the paper.

I'd try to stress this to everyone in the group - especially in
responding to the possible "why didn't you get there?" questions -
always go back to, "well, the requirements were... and we thought the
best theoretical solution was... and this is what we have." It won't
suprise me that these profs will pull this kind of "nose-in-the-air"
abuse, becuase the real answer as to why the "group" didn't get there
is that the profs didn't do there job of figuring out a "do-able"
project and then acting as the "boss" of a project and disciplining a
lack of performance - if they knew it was going to require each person
to put in X hours and obviously some members weren't, it was _their_
job to tell those people, point blank, "I'm going to fail you unless
you show evidence that you did your share", etc.

You, Bemmy and Nam should be proud of what you did accomplish and
shouldn't let anyone else whine about the realities (the impossibility
of the task you were given) and cheapen what you did get done. If
somebody does give a "well, we almost got done" response, I'd say you,
Bemmy and Nam should all speak up and say, "we didn't meet the
requirements and we understand we didn't plan sufficiently to reach
them" (which is not the truth - shit, more planning would have just
wasted more time and you would have had even less to show in the end!)
The demo should be a time for standing behind what you did get done
regardless of whatever criticism or continued slacking the others
involved (profs, group members, other students) try to inject.

So let me know what you think - I will probably just be at home
working all day Sunday - I know you will essentially be in church all
day and working on this at night - don't hesistate to call me at home
- I tried calling you tonight.

Let me know what I can do to help.

Abracos,

Charlie

P.S. - "Dud" is another word for "loser" - "Dude" is the common
hippie/surfer/college student slang for bro/"man"/friend/compatriot,
etc. I knew what you meant, but take note becuase "dud" and "dude" are
pretty much oppossites.

On 4/23/05, Endrias Woldegiorgis <endriasw@gmail.com> wrote:
> You are sick?
> Check this out, exactly as it appears on the project requirements as given to us by Prof.Bennet > --
> Sensing:
> • Detection of breeching of the container walls, floor or ceiling (6
> sides)
> • Detection of opening, closing or removal of the container doors
> • Container seal or lock status
> • If there is a breech, you should be able to store and report the data
> • There should be continuous monitoring with consideration to
> maintaining low false alarm rates
> • The data should contain a history file with time stamped records of
> all container events for that container trip
>
> Dud by the way, you are always a help to me (ALWAYS)...
> I'm not good in organization therefore I need help on the presentation.
> How we should outline it. Me and B would like to take parts on it. Tell
> me how we should start,  what we should have on the slides (like what
> kind of pictures and so on) and the order we should present it.
> Meaning, shall we do the experiment 1st or the presentation?
>
> give me some inputs..
>
> >
> >
- Show quoted text -
> > On 4/23/05, Endrias Woldegiorgis <endriasw@gmail.com> wrote:
> >> Hey Dud
> >>
> >> I would like you to review my portion of paper when you get a
> >> chance...
> >> I need help in writing
> >>
> >> Thanks a lot
> >>
> >> Endrias
> >>
> >>
> >
>
>


ReplyForward








 Reply 
Reply to all Reply to allForward Forward Print Add Endrias to Contacts list Delete this message Report phishing Show original Message text garbled?
Endrias Woldegiorgis 
to me
show details
 4/24/05 

On Apr 23, 2005, at 11:31 PM, Charlie Mote wrote:

> Hey Endrias,
>
> Thanks for copying the requirements here.
>
> The big question is, what currently works? I mean, what part of the
> requirements have we actually met?

We still dont know how to use the vibration sensors. The company
clearly states that we could use it to measure not just vibration but
also earthquake. We think this can only be attained using MoteView or
factor software. Yet, as you recall, it was much harder to use MoteView
than TinyOS.

>
> As I understand it, there's a circuit which turns on an LED if the
> door is open and we can see this through the mote on the laptop -
> perhaps it can be logged as well. We also have the peizo circuit,
> although it isn't attached to anything and so doesn't send data
> anywhere.

We have the door sensors work like you suggested (which I thought was
the smartest idea). We used magnet sensors for the door, attached an
LED on top of the light sensor of one of the Mote-Sensor setup and
placed the device all the way on the back of the container so that the
light from outside would not interrupt the reading from the LED.

As for Peizo electric circuit designed by you, this was a very strange
result. Last night what I did was this, I took out the one of the light
sensors (photo diode) from the sensor board and attached directly to
the Peizo electric film. If i'm not mistaken, as we both thought, the
film itself should produce electric when bent or strained or stressed.
That was the reading we observed on the Scope that night. When we
obtain the reading from that particular node (from the node of the
light sensor), there is no change. So option number two was to use the
whole setup (circuit) and try to see if we can get any reading. The
reason I'm using the node of the light sensor is because I could make
the AtoD converter we ordered from Xbow. In fact, I even attached that
to the light sensor I took out from one of the sensor board and still
there was no reading. Anyway, so using the setup we had for the Peizo,
I still did not get any reading. Listen to this Charli, when I placed a
1.5V on the node of the light sensor, it reads the input BUT, was too
small. Therefore I'm thinking, that little light sensor produces so
much current in-order to get a reading. Even 9V battery did not produce
as much reading as the light sensor.

>
> I think the best approach would be to start with the theoretical
> solution following, point by point, the requirements. So, for example,
> detection of breech of any of six (seven actually, the door is split
> in half and therefore it's 7, not 6,) sides - how can the container be
> breached practically speaking? I had found the data on the steel that
> is used for these types of conatiners in the past, although I don't
> know it of the top of my head. Let's say it's 1/8" inch corragatd mild
> or Corten steel
> (http://www.shippingcontainers.com/brchures.htm - used.pdf)

Excellent idea. I will start with this on my first slide. Question,
1/8'' inch corragatd mild or Corten steel?
So the number 1/8'' is what?

>
> From here:
>
> http://64.233.187.104/search?q=cache:ry_rjSpp7AsJ:
> www.ussconstruction.com/metal/metal/corten.shtml+corten+steel&hl=en
>
> we know that COR-TEN steel is "a HOT ROOF" meaning it is relatively
> highly heat conductive (from wikipedia "mild steel" is the most common
> type of steel and is the lowest carbon content.)
But I thought this even suggested that suing Corten-Steel is not a good
idea although the containers are made using this kind of metal. I guess
we can use address/stress more the highly heat conductive behavior of
the container.

> And here:
> http://www.corrosion-doctors.org/Design/corrosion-performance.htm
>
> points out the main difference between mild and corten, that being
> that corten is more corrosion resistant in non-salt water
> environments, so mild steel is probably pretty similar in terms of
> heat conductivity.

Ok makes perfect sense. Yet why did the second link suggested not to
use it for roofing application? I know I know, you just want me to
focus on the heat conductivity property of the metal.
- Show quoted text -
>
> It's this kind of detail the profs are going to want to see, and it's
> the kind of detail that proves how much work you were expected to do
> (that is, an unreasonable amount of work.) Statements like "lacking a
> thorough materials engineering study of the exact details of the types
> of steel used in the containers, many assumptions were neccesary for
> the theoretical approach." need to be included to remind the prof.
> that this was a massive undertaking - figuring out what types of
> steel, in how many of the types of conatiners, with what kind of heat
> conductivity and cutting/drilling resistance, etc. is a project for a
> semester in-and-of itself.
>
> But back to how to detect a breach. We know the containers aren't
> hermetically sealed (i.e., air-tight), through annocdotal evidence
> (news reports of human stowaways surviving in them) and discussions
> like this:
>
> http://www.ponl.com/topic/home_page/language_en/about_us/
> useful_information/cargo_care/condensation_issues
>
> which talk about air and heat exchange between the containers, their
> cargo and the environment, so we can't use (as you first suggested) a
> simple means of detecting a change in pressure. Also, we can't expect
> to pressurize all of the containers in the world, so that route is
> just out.
>
> As I wrote about in the first series of postings I made to the group a
> few months back, that left just a few options.
>
> Just stepping through each of these points, like I tried to do in my
> postings, should point out how much work was neccessary for this
> project, just to _meet_
> the minimum requirements! Not to mention a detailed study of all the
> various circuits and methods of wireless communication (as that one
> prof of yours kept hammering with the "why xbow?" question) which
> could have been used to meet them.
>
> I think you should start the demo by stating that you could not meet
> the requirements - always better to admit short-coming and then go on
> to at least show what you have, than it is to proceed as if
> everythings fine when it obviously isn't. "We attempted" is a phrase
> you should probably use a few times.
>
> I think you want to make it cleat that the group wasn't even really
> considering true "real-world" requirements, like scalability,
> retro-fitting costs, and possible compliance (meaning how many
> containers would actually get systems like this due to the first two
> considerations) and instead was focusing on just making a demo to test
> some of the possible _concepts_ which further research would need to
> address.
>
> This is key - acknowledge we didn't get there, state that we never
> anticipated actually getting there and that the exercise was to try to
> test some of the _types_ of systems which _probably_ would be
> neccessary to actually get there.
>
> Then tell them, briefly, what was accomplished (in writing, this
> should be a bullet-point list in order of most important to least -
> including "procured volunteer labor [me] and donated materials
> [cabinets, circuits, tools]" and listing them (what, I probably put in
> around 100 hours of time ~ 30 min./day for 3.5 months (so ~ 55 hours)
> plus several larger stints), cabinets, circuits, etc.)), including
> creating and posting to the group, getting the motes from Hutto,
> placing the orders, everything.
>
> I might very well be able to write this part since I think I have a
> pretty good grasp of the accomplishments.
>
> The demo, however, should not have a whole lot of this, and shoud
> stick to being a recounting of how much work would have been required
> to meet the requirements and how much work it took just to get what we
> have (the accomplishments) and then show them what we have. There
> shouldn't be a "well, we almost got this part done, we had the parts
> and ran out of time, etc." becuase it will seem like whinning - the
> proper place to say that "we did at least get these parts" is in the
> accomplishments part of the paper.
>
> I'd try to stress this to everyone in the group - especially in
> responding to the possible "why didn't you get there?" questions -
> always go back to, "well, the requirements were... and we thought the
> best theoretical solution was... and this is what we have." It won't
> suprise me that these profs will pull this kind of "nose-in-the-air"
> abuse, becuase the real answer as to why the "group" didn't get there
> is that the profs didn't do there job of figuring out a "do-able"
> project and then acting as the "boss" of a project and disciplining a
> lack of performance - if they knew it was going to require each person
> to put in X hours and obviously some members weren't, it was _their_
> job to tell those people, point blank, "I'm going to fail you unless
> you show evidence that you did your share", etc.
>
> You, Bemmy and Nam should be proud of what you did accomplish and
> shouldn't let anyone else whine about the realities (the impossibility
> of the task you were given) and cheapen what you did get done. If
> somebody does give a "well, we almost got done" response, I'd say you,
> Bemmy and Nam should all speak up and say, "we didn't meet the
> requirements and we understand we didn't plan sufficiently to reach
> them" (which is not the truth - shit, more planning would have just
> wasted more time and you would have had even less to show in the end!)
> The demo should be a time for standing behind what you did get done
> regardless of whatever criticism or continued slacking the others
> involved (profs, group members, other students) try to inject.
>
> So let me know what you think - I will probably just be at home
> working all day Sunday - I know you will essentially be in church all
> day and working on this at night - don't hesistate to call me at home
> - I tried calling you tonight.
>
> Let me know what I can do to help.
>
> Abracos,
>
> Charlie
>
> P.S. - "Dud" is another word for "loser" - "Dude" is the common
> hippie/surfer/college student slang for bro/"man"/friend/compatriot,
> etc. I knew what you meant, but take note becuase "dud" and "dude" are
> pretty much oppossites.

I will take note of this: sorry if I offended you but I know you know
that my english is still in Africa. When ever I misspelled a word, I
say we dont have that word in Africa :)  like I think i misspelled
elevator on the of the store maps for inventory. The truth is, sure I
would misspell it because we did not have an 'elivator' in Africa.  : )
but on a serious not, thank you for addressing that to me. Now I
know...

I really hope you are feeling well. We are going to meet this morning
to do some testing. (i'm not going to church for this reason) and I
guess during the evening, me and B will be working on the portion of
our paper. This might leave you no time to review it, but I also hope
that we finish it with enough rest.

Charlie, I cant thank you enough for the help you have given us.



ReplyForwardInvite Endrias to chat








 Reply 
Reply to all Reply to allForward Forward Print Add Charlie to Contacts list Delete this message Report phishing Show original Message text garbled?
Charlie Mote 
to Endrias
show details
 4/24/05 
Oi Endrias -

I was assuming you would be at church - if you are at the lab and
someone there has a cell phone I can call to have you let me in then I
will be happy to stop by and see what I can do to help.

In the meantime, I am going to respond point-by-point:


> We still dont know how to use the vibration sensors. The company
> clearly states that we could use it to measure not just vibration but
> also earthquake. We think this can only be attained using MoteView or
> factor software. Yet, as you recall, it was much harder to use MoteView
> than TinyOS.

I don't think there is a vibration sensor on the sensor boards Hutto
gave us - I think Bemmy got confused on that a while back - I was
thinking about the peizo circuit.

> We have the door sensors work like you suggested (which I thought was
> the smartest idea). We used magnet sensors for the door, attached an
> LED on top of the light sensor of one of the Mote-Sensor setup and
> placed the device all the way on the back of the container so that the
> light from outside would not interrupt the reading from the LED.

That's great! This should be the center-piece of the demo and the
paper: accomplishment, requirement to detect door status. If you can
get this to be timestamped/logged on the labtop outside the TinyOS DB
that would be even better.

>
> As for Peizo electric circuit designed by you, this was a very strange
> result. Last night what I did was this, I took out the one of the light
> sensors (photo diode) from the sensor board and attached directly to
> the Peizo electric film. If i'm not mistaken, as we both thought, the
> film itself should produce electric when bent or strained or stressed.
> That was the reading we observed on the Scope that night. When we
> obtain the reading from that particular node (from the node of the
> light sensor), there is no change. So option number two was to use the
> whole setup (circuit) and try to see if we can get any reading. The
> reason I'm using the node of the light sensor is because I could make
> the AtoD converter we ordered from Xbow. In fact, I even attached that
> to the light sensor I took out from one of the sensor board and still
> there was no reading. Anyway, so using the setup we had for the Peizo,
> I still did not get any reading. Listen to this Charli, when I placed a
> 1.5V on the node of the light sensor, it reads the input BUT, was too
> small. Therefore I'm thinking, that little light sensor produces so
> much current in-order to get a reading. Even 9V battery did not produce
> as much reading as the light sensor.
>

Hmmm. So it's a 3V max on the inputs but needs a lot of current.
That's possible and I don't know any way around this. Document exactly
what you did since this is key to the rest of the requirements (and
why we didn't quite get there.) I'm suprised that you could get a 9V
to read at all since Xbow states all over not to put more than 3V on
the ADC or it will blow.

How could we possibly up the amperage coming out of the circuit
without changing the data?

Also, be sure to document how the peizo works on the O-scope - we need
to show that the line of thought, i.e., heat up, voltage down,
vibration up, frequency up, is valid and that it's a problem at the
interface (which is always very tricky) - that we got stuck on
converting the analog to digital and using it with this sensor
platform.


> Excellent idea. I will start with this on my first slide. Question,
> 1/8'' inch corragatd mild or Corten steel?
> So the number 1/8'' is what?

I just picked one-eigth of an inch (1/8") as a guess to the
approximate width of the steel the body (walls) of the conatiner are
made of - I couldn't find any citation anywhere for the actual
thickness. The point being that we know that the containers are
industrial steel and that they, therefore, are susceptible to all the
types of "breeching" (cutting, drilling, flame cutting/melting) that
industrial steel in general is.


> Ok makes perfect sense. Yet why did the second link suggested not to
> use it for roofing application? I know I know, you just want me to
> focus on the heat conductivity property of the metal.

I worked and lived in Central America and Brazil where people who can
afford nothing else use "galvinized" (rust-resistant) sheet metals for
roofing - those things get so hot you can fry an egg on them - so hot
in fact, that they radiate heat _down_ (heat likes to rise right?)
into the building, making the whole house heat up. This isn't bad if
it is a bit chilly outside, but it's not so great if you are trying to
keep the house cool. Also, since these sheets have no mass, as soon as
the sun is off them, they cook off, so none of the heat is useful at
night.

Heat conductivity - that's what led us to think that we would have a
shot at detecting a change in the heat flow if the attack was trying
to melt/cut a breech in the container.

> I will take note of this: sorry if I offended you but I know you know
> that my english is still in Africa. When ever I misspelled a word, I
> say we dont have that word in Africa :)  like I think i misspelled
> elevator on the of the store maps for inventory. The truth is, sure I
> would misspell it because we did not have an 'elivator' in Africa.  : )
> but on a serious not, thank you for addressing that to me. Now I
> know...

Not a problem - I'll probably be saying "Aa-marique" instead of
"a-Hamarique" for a good while...

>
> I really hope you are feeling well. We are going to meet this morning
> to do some testing. (i'm not going to church for this reason) and I
> guess during the evening, me and B will be working on the portion of
> our paper. This might leave you no time to review it, but I also hope
> that we finish it with enough rest.
>
> Charlie, I cant thank you enough for the help you have given us.
>
>

If you can, try to do a run through of the demo - just as you think
you will tomorrow - remember what I was talking about preparing for a
presentation - say it out loud just like you think you will - having
the thoughts already formed and the words already spoken will really
help.

Let me know what you all are up to this morning.

Abracos,

Charlie


ReplyForward








 Reply 
Reply to all Reply to allForward Forward Print Add Endrias to Contacts list Delete this message Report phishing Show original Message text garbled?
Endrias Woldegiorgis 
to me
show details
 4/24/05 
This is what I have... just look into it when you get a chance...
Remember some of the postings you had, do you mind if I use them?

Design Alternatives & Tradeoffs: This section must contain a clear
explanation of other approaches that are possible and why they were not
used in the end product.  What were the technical tradeoffs and how and
why were the final alternatives selected.  In addition, include the
constraints that affected your project decisions. Include factors such
as economic, environmental, sustainability, manufacturability, ethical,
health and safety, social, and political where possible. This section
should include information about the method that your team used to
attack the design problem. Explain your constraints as well as your
solution.




Approaches that are possible
Breaching Detection
-       Pressure sensor
-       Gird/mesh of wire
-       Motion sensors
-       Piezoelectric Films



Detection of the breeching of the container wall, floor or ceiling,
detection of opening, closing or removal of the container doors, and
container seal or lock status are the design objectives of this
project. Different ideas were introduced for implementation, but were
not used in the end product for many reasons.

Breaching detection is one challenging aspect of the project. It
involves continuous monitoring of at least five sides of the container,
with minimum false alarm indications. The ideal detection methods
listed below present a functional and reliable monitoring technique;
yet could not be used in the end product for different reasons.

1)      Breaching detection

Grid/mesh of wire

The idea of using mesh wiring was first introduced to detect breaching
of the sides of the container. The walls of the container will be
dressed with mesh of wires through which a current is supplied with a
continuous power supply. The idea is that, during intrusion through the
walls of the container, the current flow through the wires will be
interrupted indicating breaching to the inspector. The mesh will not be
visible form the outside or inside. In order to protect the mesh from
accidental damage caused during loading and shipment process, each wall
of the container will be a double layer. In between, the mesh is paced
and supplied with a continuous power. This alternative is not used in
the end product of our design because of multiple reasons.
a)      The shipping industry isn't ready for mass production and deployment
of tamper-evident containers, and adoption is likely to come slowly.
Replacing the existing anywhere between 16 million and 19 million
containers used today could take another decade.
b)      The power supply would have to drive the current though the long
wires embedded in the walls. The power consumption will be highly
expensive.
c)      The budget given for this project is well below the manufacturing
cost of a container.


2)      Pressure Sensors

Containers aren't air-tight sealed. This is evident through anecdotal
reports like news reports of human stowaways surviving in them. Other
studies have proven to show formation of container sweat, which occurs
when the skin of the container is cooled to a temperature blow of the
dew point of the air enclose within the container. [ REFRENCE  1 ] This
results in water droplets forming on the interior roof and side panels,
then dripping down on the cargo causing mould and water damage. Cargoes
that spontaneously heat from within can increase the problem. This heat
exchange between the containers, their cargo and the environment,
proves to eliminate a simple means of detecting a change in pressure
within the container because the container is not air-tight sealed.
Also this design alternative will expect to pressurize all of the
containers in the world, which is beyond the scope of the project.

3) Motion Sensors

Removing a cargo or placing an object within the container can be
monitored using motion sensors. The motion sensors can be placed at 8
corners of the container, detecting motion from all possible angles.
Although this approach is possible and could provide sufficient
security, it was not implemented in the final product for these
reasons:
1)      When the container is filled with boxes or cargo, the object in
front of it will block all activities behind the box. Which means that,
in a fully loaded container, an intruder can breech the center of the
wall to remove or palace an object.
2)      During loading and unloading the container, if the container is half
filled, moving boxes will generate false alarm.



ReplyForwardInvite Endrias to chat








 Reply 
Reply to all Reply to allForward Forward Print Add Charlie to Contacts list Delete this message Report phishing Show original Message text garbled?
Charlie Mote 
to Endrias
show details
 4/24/05 
Your off to a good start (and I don't mind use of older posts - that's
what they are there for.) Now you need to detail why we choose what we
did - remember to keep it in the context of what was accomplished (100
hrs. volunteer labor, $2000 loaned/donated equipment (I'm not sure
$2000 is the correct number, I think I posted that a while back)) so
that you don't have to out-right state that a major constraint was
lack of time and money (the profs. don't want to see/hear this.)

I think it is fine to say that since a wireless ad-hoc sensor network
would be required and Tech had an on-going research project (Hutto and
Simon) with a viable product (not too expensive, proven, supported)
where we could go for advice and loan of equipment, that Xbow was
choosen to facilitate spending more time on the more difficult problem
of the analog sensors, building the demo, etc.

I'll have some edits of what you have before too late this evening.

Charlie


ReplyForward








 Reply 
Reply to all Reply to allForward Forward Print Add Endrias to Contacts list Delete this message Report phishing Show original Message text garbled?
Endrias Woldegiorgis 
to me
show details
 4/24/05 
whats your number

I was going to call you to give the room ph#

endrias

PS. I had started to write this e-mail this morning but never sent it
to you :)



ReplyForwardInvite Endrias to chat








 Reply 
Reply to all Reply to allForward Forward Print Add Charlie to Contacts list Delete this message Report phishing Show original Message text garbled?
Charlie Mote 
to Endrias
show details
 4/24/05 
Hey Endrias,

My number at home is 4-377-7716. Feel free to give me a call.

Charlie
- Show quoted text -

On 4/24/05, Endrias Woldegiorgis <endriasw@gmail.com> wrote:
> whats your number
>
> I was going to call you to give the room ph#
>
> endrias
>
> PS. I had started to write this e-mail this morning but never sent it
> to you :)
>
>


« Back to Search results
Report SpamDelete
‹ Newer 2 of 3 Older ›

Add phone numbers, notes and more for the people in your Contact list.   Learn more
You are currently using 374 MB (13%) of your 2789 MB.
Gmail view: standard with chat | standard without chat | basic HTML  Learn more