Ethernet Polling vs Broadcasting on an Embedded device

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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,


Re: Ethernet Polling vs Broadcasting on an Embedded device
Quoted text here. Click to load it

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



Re: Ethernet Polling vs Broadcasting on an Embedded device
Quoted text here. Click to load it

And all the Gals, too, I hope.

Quoted text here. Click to load it

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.
We've slightly trimmed the long signature. Click to see the full one.
Re: Ethernet Polling vs Broadcasting on an Embedded device
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!


Re: Ethernet Polling vs Broadcasting on an Embedded device
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


Re: Ethernet Polling vs Broadcasting on an Embedded device

Quoted text here. Click to load it

Why are you afraid Ethernet won't prevent collisions?

Quoted text here. Click to load 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
We've slightly trimmed the long signature. Click to see the full one.
Re: Ethernet Polling vs Broadcasting on an Embedded device
Quoted text here. Click to load it
[...]
Quoted text here. Click to load it


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.

Re: Ethernet Polling vs Broadcasting on an Embedded device
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Ethernet Polling vs Broadcasting on an Embedded device
Quoted text here. Click to load it

Neat project!


Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Re: Ethernet Polling vs Broadcasting on an Embedded device

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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?

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.
We've slightly trimmed the long signature. Click to see the full one.
Re: Ethernet Polling vs Broadcasting on an Embedded device
Quoted text here. Click to load it

Ouch.



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.

Re: Ethernet Polling vs Broadcasting on an Embedded device

Quoted text here. Click to load it

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.
We've slightly trimmed the long signature. Click to see the full one.
Re: Ethernet Polling vs Broadcasting on an Embedded device

Quoted text here. Click to load it

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


Re: Ethernet Polling vs Broadcasting on an Embedded device

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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
 

Re: Ethernet Polling vs Broadcasting on an Embedded device


Quoted text here. Click to load 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


Re: Ethernet Polling vs Broadcasting on an Embedded device
Quoted text here. Click to load it

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

Re: Ethernet Polling vs Broadcasting on an Embedded device
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


Re: Ethernet Polling vs Broadcasting on an Embedded device

Quoted text here. Click to load it

Maybe not such new ideas after all:

http://demo.zweng.com /

--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
We've slightly trimmed the long signature. Click to see the full one.
Re: Ethernet Polling vs Broadcasting on an Embedded device

Quoted text here. Click to load it
&
Quoted text here. Click to load it

That demo is long gone. Here's the new one:
  http://69.104.38.49:8146 /

A single RCM3700 is used now.
  http://www.rabbitsemiconductor.com/products/CoreModules/index.shtml

More demos:
  http://www.rabbitsemiconductor.com/products/dc/demos/index.shtml


Site Timeline