> "linuxdude" <easylinux@gmail.com> wrote
>
> > Also, I have some new ideas to apply too! POE, going towards
> > a Rabbit microprocessor with the TCP/IP stack, Custom UDP with ack
&
> > retransmit ... embedded Linux.
>
> Maybe not such new ideas after all:
>
> http://demo.zweng.com/
Reply by Nicholas O. Lindan●March 2, 20052005-03-02
"linuxdude" <easylinux@gmail.com> wrote
> Also, I have some new ideas to apply too! POE, going towards
> a Rabbit microprocessor with the TCP/IP stack, Custom UDP with ack &
> retransmit ... embedded Linux.
Maybe not such new ideas after all:
http://demo.zweng.com/
--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer: Electronics; Informatics; Photonics.
To reply, remove spaces: n o lindan at ix . netcom . com
Reply by linuxdude●March 2, 20052005-03-02
Wow, thats a lot of information. Thanks to all of you! I am going to
look into every one of the suggestion and see what would be the ideal
solution. Also, I have some new ideas to apply too! POE, going towards
a Rabbit microprocessor with the TCP/IP stack, Custom UDP with ack &
retransmit.
Since, we are still engaged in the brain storming sessions, we still
have lot of time to finalize how the end product will be. But the
ultimate goal is to design something with Ethernet & possibly an
embedded Linux. I am sure it will be a great learning experience for us
& I really appreciate all your help.
LD
Reply by Kelly Hall●March 2, 20052005-03-02
Carsten wrote:
> Well if you use broadcasts you cant route it , as routers are designed
> NOT to route broadcasts.
multicast.
But I think multicast (or broadcast) is lame for a network of weather
sensors since little traffic is of interest to the average sensor. The
real question is polled versus autonomous operation, and the autonomous
solution ends up requiring time synchronization on the sensors, which
seems like overkill for a gorified thermometer. So poll the sensors,
and if having one master is impractical due to the workload or bandwidth
requirements, then have submasters polling subdomains of sensors and
aggregating data for the big kahuna master.
Frankly, though, I'd prototype this using autonomous sensors and
transferring data with syslog.
Kelly
Reply by Carsten●March 1, 20052005-03-01
On 28 Feb 2005 14:21:28 -0800, "linuxdude" <easylinux@gmail.com>
wrote:
>1) Should the Server poll the clients (using a TCP/IP or UDP client
>server model) on a constant time interval.
>2) Should the Clients send a broadcast at random interval and let the
>Server listen to them
>3) Should the Client send a multi cast packet of some sort and let the
>Server take care of it.
Well if you use broadcasts you cant route it , as routers are designed
NOT to route broadcasts.
So using broadcasts you will have to have all your sensors on same
physical lan (layer2) as the server.
Carsten
Reply by Grant Edwards●March 1, 20052005-03-01
On 2005-03-01, Eric Smith <eric@brouhaha.com> wrote:
> linuxdude wrote:
>> We are in favor of using a client/server model using UDP as
>> the communication protocol. The problem is, if all the devices
> [...]
>> May be TCP/IP might be a better option here. If there is a
>> better mechanism it would be very valuable at this stage to
>> know about it.
>
> Grant Edwards <grante@visi.com> writes:
>> You could add your own ack/retry scheme on top of UDP.
>
> And you could add sliding windows, and selective retransmits,
> and support for out-of-band data, and path MTU discovery,
> and...
>
> If you really need a message-oriented protocol, it's much
> easier to layer one on top of TCP than to build a custom
> reliable datagram transport on top of UDP.
Why take the easy route? After all: "it's a research project,
it doesn't _have_ to work." ;)
--
Grant Edwards grante Yow! Mr and Mrs PED, can
at I borrow 26.7
visi.com
Reply by ●March 1, 20052005-03-01
linuxdude wrote:
> We are in favor of using a client/server model using UDP as
> the communication protocol. The problem is, if all the devices
[...]
> May be TCP/IP might be a better option here. If there is a
> better mechanism it would be very valuable at this stage to
> know about it.
Grant Edwards <grante@visi.com> writes:
> You could add your own ack/retry scheme on top of UDP.
And you could add sliding windows, and selective retransmits, and
support for out-of-band data, and path MTU discovery, and...
If you really need a message-oriented protocol, it's much easier
to layer one on top of TCP than to build a custom reliable datagram
transport on top of UDP.
Reply by Nicholas O. Lindan●March 1, 20052005-03-01
"Richard H." <rh86@no.spam> wrote
> However, it *is* loads of fun to dig into the details given the
> opportunity. Especially when the 'customer requirement' is something
> like "demonstrate various skills by creating a useful but otherwise
> redundant product from scratch".
Absolutely.
But for one caveat: "redundant product" ...
Designing a redundant product is a waste of, well,
just about everything. Creating pollution but no solution.
Whatever you do should have real novelty. For that:
o Figure out what to attack:
Who's got the money?
What makes you tick?
o Figure out how to attack:
- a new way
- a cheaper way
- a more environmental way
- a better, faster ... blah, blah, blah
Settle for attacking just one.
Find a quiet place that will let you and your compatriots sit all
afternoon nursing a few beers. Bring a bundle of fibre-tip pens.
Ask for a stack of napkins. Keep the bar receipt, it's deductible
from your income taxes.
--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer: Electronics; Informatics; Photonics.
To reply, remove spaces: n o lindan at ix . netcom . com
psst.. want to buy an f-stop timer? nolindan.com/da/fstop/
Reply by Richard H.●March 1, 20052005-03-01
Nicholas O. Lindan wrote:
> I think you missed the point. Drop the cute. Cute sucks,
> though among the cultured it is said to aspirate. Ditto
> smileys and exclamation points.
Ouch.
> Engineers who can get meet a customer's _real_ needs with a
> quality system installed on time and on budget and with no
> surprises are rare and highly valued.
Ah, yes, reality. You are quite right, of course, and make many
excellent points regarding process. In the end, the customer wants
their needs met at the lowest cost, and they rarely care about the 'how'
or whether it piques your personal interests.
Ditto in corporate life - no matter how much you enjoy the details, the
executives just want to know what it'll do, when it'll be done, and what
it'll cost - they emphatically *don't* want to hear the details.
In the Real World, I'd rank a custom solution low on the list against a
COTS product, primarily due to long-term lifecycle / support costs
(future features, hidden design flaws, maintenance replacements, etc.)
After all, the customer is in the cold storage business, not the 'cold
storage environmentals monitoring widget' business.
However, it *is* loads of fun to dig into the details given the
opportunity. Especially when the 'customer requirement' is something
like "demonstrate various skills by creating a useful but otherwise
redundant product from scratch". I.e., technology for technology's sake
- a rare opportunity in the real world, to be enjoyed by some to its
fullest.
Reply by Nicholas O. Lindan●March 1, 20052005-03-01
"linuxdude" <easylinux@gmail.com> wrote in message
> Hey Guys & Gals :) !!!
I think you missed the point. Drop the cute. Cute sucks,
though among the cultured it is said to aspirate. Ditto
smileys and exclamation points.
> Let me elaborate a bit about this project. It will be a research
> project. Myself and some of my friends from school started to work on.
> At this stage, we are in the process of information gathering & brain
> storming.
>
> We are aiming to design a centralized weather monitoring system for a
> cold storage place.
I take it you mean temperature monitoring. You should check if
humidity is worth the bother to monitor by consulting several
experts working in the cold storage industry.
> This place is already wired with Ethernet.
That doesn't mean you have to use it. It is also has a sewer system,
again you don't have to use that either.
> The task
> is to log real time temperature/humidity/etc information to a
> centralized location. In one building alone, there are about 100 to 150
> various locations that need to be monitored. There is a total of 4
> building that needs to be monitored with a centralized station. Since,
> it's a research project we will be focusing on getting at least 20+
> nodes initially. Each node could have up to 4 sensors to acquire data.
There are already a superfluity of products on the market that do just
this. What will your project do to further the state of the art?
> As a first step, we have decided to simulate the whole project with
> bunch of Linux boxes mimicking devices.
What is being simulated? A Linux box is simulating a thermocouple?
A Linux box is simulating a 4-input temperature measuring gizmo?
Why does it need simulating? Hooking together Linux boxes with
ethernet seems self-evident. You can get the complete works at
Walmart.
> If it works with simulation, then we will look into the hardware
> design side. As you could see, we are novice engineers with minimum
> expertise in some of the areas. So, here we are asking the real
> experts for some valuable suggestions.
I think your project goal should be to generate a comprehensive engineering
plan. You seem to be very far from the stage in a project where implementation
issues are addressed.
> Key elements of the project:
> 1) Ethernet enabled
This is on of the _last_ key elements to consider.
1) Your first goal is a comprehensive customer requirement document.
This tells the man paying the bills what he will receive when all
is said and done. You form this by talking to the owners, managers
and workers at the storage facility. You write up your findings
and present them to the powers that be. Plan several iterations.
As part of this effort you will need to talk to people who supply
commercial temperature monitoring systems and to the users of such systems.
Issues include:
a) What is monitored
b) How often
c) Where are monitors placed
c) How is the data to be used
d) How is data integrity assured
e-z) etc. etc. budget, schedule, union labor ....
The project may end at this point with the customer spec. being
sent to a vendor of monitoring systems, one you turned up in your
research, above. Your role is then program supervision. This
is called 'Purchase Order Engineering'.
2) If there is nothing on the market to meet your needs, then your
second goal is to write an engineering specification. It
starts with #1 above, but is written for engineers rather than
the funding body. The real use of this document is the thinking
required to be able to formulate it. It will get everyone in
the engineering team singing from the same hymnal.
3) Now comes more data gathering from component vendors of sensors,
data loggers, etc. etc.
4) Concept design. Come up with six scenarios, starting with
having a man walk around with a clip board and read
thermometers hanging on the wall. Sounds silly, but
that may be what the customer really needs, not some
more computer stuff he doesn't know what to do with:
your customer is in the _cold storage_ business, not
the computer business and a guy with a clip board he
can understand and manage.
And so on and so forth.
At the end of each project phase, 1-999 above, a report is presented
with findings to date, concerns, conclusions, recommendations, an updated
schedule and budget for the next phase. At this time the budget need
only be firm for the first phase - resist making a budget for the
whole shebang as you don't know what sort of shebang will come out
of the program.
Now we come to the zero task: A proposal for phase #1, above.
It should define the scope of work, deliverables, schedule
and budget.
For God's sake don't make it all huffy-puffy. Plain simple language
is what's needed. Pretend you are explaining it to your mother.
If you go through this exercise you will advance your career.
Linux geeks with TCP stacks leaking from their ears are a dime
a dozen, it's a commodity market.
Engineers who can get meet a customer's _real_ needs with a
quality system installed on time and on budget and with no
surprises are rare and highly valued.
--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer: Electronics; Informatics; Photonics.
To reply, remove spaces: n o lindan at ix . netcom . com
psst.. want to buy an f-stop timer? nolindan.com/da/fstop/