Ethernet Polling vs Broadcasting on an Embedded device

Hello guys,

I have asked to design a test system for an Ethernet enabled weather
station. At this point, these weather stations are nothing but 2 PCs
running Linux on it and they constantly read weather related
information
through some sensors. Eventually they will be replaced with a miniature
embedded Linux device (yet to be designed!).

I have worked extensively with 1/2 duplex RS485 networks where we poll
a
device and then send an acknowledgment to the device. I am not too sure
what is the best way to handle an Ethernet enabled devices. The
hardware
engineers have agreed to change the Firmware on the device side to meet
our requirements.

With an Ethernet setup, I was told it is not necessary to "POLL" a
device, hence the communication latency issues could be minimized with
Ethernet, which is very nice compare to the RS485 latency issues.

The part where I am really stuck is, what could be the best mechanism
that I could be using here.

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.

The ultimate plan is to put more than 200 weather stations on this
network and analyze data. Please give me any information that I could
use to implement this.

Thanks in advance,

> Hello guys,
>
> I have asked to design a test system for an Ethernet enabled weather
> station. At this point, these weather stations are nothing but 2 PCs
> running Linux on it and they constantly read weather related
> information
> through some sensors. Eventually they will be replaced with a miniature
> embedded Linux device (yet to be designed!).
>
> I have worked extensively with 1/2 duplex RS485 networks where we poll
> a
> device and then send an acknowledgment to the device. I am not too sure
> what is the best way to handle an Ethernet enabled devices. The
> hardware
> engineers have agreed to change the Firmware on the device side to meet
> our requirements.
>
> With an Ethernet setup, I was told it is not necessary to "POLL" a
> device, hence the communication latency issues could be minimized with
> Ethernet, which is very nice compare to the RS485 latency issues.
>
> The part where I am really stuck is, what could be the best mechanism
> that I could be using here.
>
> 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.
>
> The ultimate plan is to put more than 200 weather stations on this
> network and analyze data. Please give me any information that I could
> use to implement this.
>
> Thanks in advance,
>

Have the remote devices with the ethernet port make regular broadcasts of
their data and health via UDP.

> Hello guys,

And all the Gals, too, I hope.

> I have asked to design a test system for an Ethernet enabled weather
> station.

You are asking the 'how?' before fully stating the 'who, what
when, where, how much ...'.

What sort of a system is this:

 1) # nodes? You indicate 200, below.  Will it grow?

 2) What is the size of the geographical area?  Urban, rural,
    wilderness...?  Mountains, rivers, deserts...?

 3) You mention latency concerns, why is this an issue as it
    would seem weather doesn't change much in 15 minutes, for example?
    How much data is being transferred?

 4) Is this to be a:

    a) research project
    b) network for a govm't agency or corporation
    c) commercial product

 5) Are the nodes to be on a private network or interconnected via
    the internet

 6) Are there constricting budget, manpower, schedule, environmental
    etc. etc. etc. constraints?

 7) What is the environment: little louvered boxes, SCADA huts,
    heated buildings ...?

and so on and so forth ad nauseum.

Without knowing something about the requirements it is hard
to give useful and relevant advice.  At present the _least_ 
important issues, from my perspective, are the choice of 
485/ethernet/rf/carrier pigeon and the physical and logical 
configuration of the network.

-- 
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/

Hey Guys & Gals :) !!!

First of all, thanks to Warren & Nicholas O. Lindan for your
suggestions. I have answered some of your questions.

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. This place is already wired with Ethernet. 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.

As a first step, we have decided to simulate the whole project with
bunch of Linux boxes mimicking devices. 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.

Key elements of the project:
1)	Ethernet enabled
2)	Real time temperature/humidity/etc information (as things change).
Our initial research proves that the temperature does not change
rapidly, but when something fails it drops fast (approximately about 2
hrs).
3)	Expandable to 1000 nodes
4)	Report failed nodes or individual sensors to the main station
5)	Will be using the existing Ethernet network
6)	Also keep the cost to the bare minimum

We are in favor of using a client/server model using UDP as the
communication protocol. The problem is, if all the devices start to
broadcast at the same time, then we may run into a collision issue of
some sort (not sure if Ethernet is smart enough to handle it by it
self). 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.

Thanks again for all your help!

If you're looking to make these battery powered nodes (which is quite
probable since you might not have a/c power everywhere), it might be
better to have the nodes send the message when they wake up. Generally,
polling is a waste of bandwidth unless you are trying to reduce the
latency afforded by being able to ping only the devices that you wish
to hear from.

-- arya

On 2005-03-01, linuxdude <easylinux@gmail.com> wrote:

> We are in favor of using a client/server model using UDP as
> the communication protocol. The problem is, if all the devices
> start to broadcast at the same time, then we may run into a
> collision issue of some sort (not sure if Ethernet is smart
> enough to handle it by it self).

Why are you afraid Ethernet won't prevent collisions?

> 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.

You could add your own ack/retry scheme on top of UDP.

-- 
Grant Edwards                   grante             Yow!  I'll show you MY
                                  at               telex number if you show
                               visi.com            me YOURS...

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.

Servers don't poll, they listen for connections from clients.  That is
to say, the client initiates the conversation.  Either the central
data collecting PC or the remote embedded hardware can a server.

There are several ways that you could set this up.

1.  The simplest way is to have the remote embedded devices send their
data to the central data collection pc via a udp string.  With udp,
there is no 'connection', the device just sends data and expects that
it will be received.  This may be okay with what you're doing, but you
do have to consider what the consequences of a missed packet are.  If
data is being sent at a regular interval, it probably doesn't matter.
But you also have to think about how many devices you can put on your
network before you overload it with data.

2.  The remote device, as a client, initiates a tcp connection to the
central server.  When the connection is established, the client
exchanges data with the server.  After that, either side can close the
connection.  With this strategy, the client will know that the server
received the data.  This is the strategy to use (tcp rather than udp)
if every bit of data must get to the server.  But again, you have to
consider how many devices you can put on the network before you
overload it.

3.  Each of the remote devices is a server, listening for a tcp
connection from the central data collecting PC.  In this scenario, the
PC is the client.  This is probably what you're thinking of as
'polling'.  With this scenario, the central data collecting PC will
set the adenda as to when and what data will be collected.  This will
eliminate the chances of overloading the ethernet with connection
requests from multiple remote clients.  But it becomes more
complicated because now the central PC has to keep track of whose on
the network.

Think about what 'client' and 'server' mean.  A server is a software
application that listens on a port for a tcp connection.  The client
is a software application that initiates a tcp connection on the
server's port.  If you were to use something like option 3. above, you
might want to initially run a client application on the embedded
device that connects to a server application on the central PC and
tells it that it's on the network.  The embedded device would also
have a server application that waits for a client application on the
central PC to ask it for data.

Which method you chose depends on the amount of data, the number of
nodes, and the how important it is that data may be lost.  The first
option is the simplest and easiest to implement.  The last option is
more complicated, but is better managed.

Dan

linuxdude wrote:
> 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.

Neat project!


> Key elements of the project:
> 1)	Ethernet enabled
> 2)	Real time temperature/humidity/etc information (as things change).
> Our initial research proves that the temperature does not change
> rapidly, but when something fails it drops fast (approximately about 2
> hrs).

Fast is relative.  You're talking about a network dialog that will take 
maybe 0.001 seconds in total per device per cycle, including an ACK. 
You can squeeze an awful lot of these in a 2-hour period.

> 3)	Expandable to 1000 nodes
> 4)	Report failed nodes or individual sensors to the main station
> 5)	Will be using the existing Ethernet network
> 6)	Also keep the cost to the bare minimum

How will the devices be powered?  Consider PoE (power over ethernet) for 
convenience and coolness factor, if there won't be power outlets near 
the endpoints.  Grab a copy of EE Times and you'll find at least a few 
ads for these chipsets.  I recall Linear Tech is one of the big players.

How will the environment self-configure?  You can use DHCP to assign IPs 
and send the server's IP address in a custom DHCP option value.  But, 
you'll need at least a one-time setup to associate a device (ideally, by 
serial number, not IP since it could change) with a locale.

> We are in favor of using a client/server model using UDP as the
> communication protocol. The problem is, if all the devices start to
> broadcast at the same time, then we may run into a collision issue of
> some sort (not sure if Ethernet is smart enough to handle it by it
> self).

First, plan for a problem - it will happen, regardless of why. 
(However, your specific concerns are largely unfounded.)  Just build a 
basic re-transmission feature into the transfer process.

TCP may be the better mechanism, but for your application it will have a 
lot of overhead to provide a guaranteed delivery that you can pretty 
easily build on top of UDP.  And it's way easier to code UDP in an 
embedded system than TCP.  Less resource requirements too.

e.g., Client waits for 5 minutes + a random # seconds per cycle (to 
distribute the load, e.g., after a site power hit), client sends to 
server, doesn't get a UDP reply to ACK the transmission, pauses a random 
period, and retries NN times before rebooting.  Server keeps track of 
incoming updates and sets an alert if a node hasn't reported in 2 
reporting cycles.


Check out widgets like the Rabbit Semiconductor 2200 - you'd need to add 
a mainboard to it (power, external connections, etc.), but it'll 
probably be cheaper than you can build yourself, and a whole lot faster 
to finish.

Cheers,
Richard

On 28 Feb 2005 14:21:28 -0800, "linuxdude" <easylinux@gmail.com>
wrote:

>
>I have worked extensively with 1/2 duplex RS485 networks where we poll a
>device and then send an acknowledgment to the device. I am not too sure
>what is the best way to handle an Ethernet enabled devices. The
>hardware
>engineers have agreed to change the Firmware on the device side to meet
>our requirements.

Since you are familiar with this kind of master to multidrop slave
connections with RS-485, why don't you do the same with UDP frames
over ethernet ? It is easy to implement and detecting failing nodes is
also easy, also no need to worry about collisions. Since the slave
ethernet controller usually has some kind of filtering, the slave
processor needs only be awakened when the master addresses it, thus a
reduction in power consumption is possible. 

UDP on a small embedded processors are practically as easy to
implement as raw ethernet packages. You have to find a way to assign
unique (MAC and/or IP)  addresses to each slave, the simplest might be
with DIP switches.

In fact using some kind of Linux for the slave devices sounds like a
huge overkill :-).

>With an Ethernet setup, I was told it is not necessary to "POLL" a
>device, hence the communication latency issues could be minimized with
>Ethernet, which is very nice compare to the RS485 latency issues.

From the description of the project that I have seen in this thread, I
really do not think that the half-duplex latencies should be an issue.
You should easily be able to scan 200 devices each second, with
comfortable master or slave processing times, a 5 ms/node time should
not be an issue.

To speed up the node response time, the response message could be
built earlier, just waiting for the poll, in order to send it, thus
the poll reception and response transmit can be initiated within the
same interrupt service routine. It might even be possible to implement
the node without an OS, by just a big polling loop and an ethernet
interrupt service routine.   

Since you have multiple buildings, it would be quite natural to have a
separate polling master in the same PC for each building, thus
dropping the total poll cycle time. The same ethernet interface on the
PC could be used and using an ethernet switch (not hub) to split the
ethernet cable to the various buildings, should take care of any
collision problems, since the worst case queue length at the ethernet
switch is the number of buildings. 

However, if you would be using the client server model with
spontaneous client transmissions, there might be some ethernet switch
queue length issues that needs to be considered.

Paul
 

"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/