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.
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/
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 :-).
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.
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.
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.
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.
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?
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.
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.
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/
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.
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/
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.
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.
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.
--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer: Electronics; Informatics; Photonics.
To reply, remove spaces: n o lindan at ix . netcom . com
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.