Ethernet stability

Upgrade: Exchange your old bugs for new ones.

But as it turns out I am on 1.0.4 right now. :slight_smile:

I don't fiddle around with Ethernet timeouts, they just seem to happen in a timely way. The watchdog lines are all I use, and to be honest I don't know if they kick in often because the board just seems to keep working.

I have one in my garage monitoring if the roller door is open or not, with no watchdog, and I've never had to reboot that except once I think after a brown-out of the house power. I'm talking a couple of years here.

AH HA!! I KNEW IT!! Deep down inside, you always wanted a reliable current version. :slight_smile:

I bumped your karma 'cause I like your stuff.

Thanks. :slight_smile:

Actually 1.0.4 is the first one to fix the annoying issue with free() causing crashes, so it is good to have installed.

@Nick: Do you use that timeout code? None of my sketches need a watchdog timer.

No. This is it: No watchdog, no timeout.

/*
 
 Garage door open/closed detector.
 
  Based on Web Server by:
  
 created 18 Dec 2009
 by David A. Mellis
 modified 4 Sep 2010
 by Tom Igoe
 
 Modified by Nick Gammon
 9th Feb 2011
 
 */

#include <SPI.h>
#include <Ethernet.h>

// Enter a MAC address and IP address for your controller below.
// The IP address will be dependent on your local network:
byte mac[] = {  0x90, 0xA2, 0xDA, 0x00, 0x2D, 0xA1 };

// our address
byte ip[] = { 10, 0, 0, 240 };

// the router's gateway address:
byte gateway[] = { 10, 0, 0, 1 };

// the subnet:
byte subnet[] = { 255, 255, 255, 0 };

// which pin to connect the relay to (held high by internal pullup)
#define relayPin 7

// Initialize the Ethernet server library
// with the IP address and port you want to use 
// (port 80 is default for HTTP):
Server server(80);

void setup()
{
  // start the Ethernet connection and the server:
  Ethernet.begin(mac, ip, gateway, subnet);
  server.begin();
  
    // initialize the relay pin as a input:
  pinMode(relayPin, INPUT);
  digitalWrite(relayPin, HIGH);   // set pullup resistor

}

void loop()
{
  // listen for incoming clients
  Client client = server.available();
  if (client) {
    // an http request ends with a blank line
    boolean currentLineIsBlank = true;
    while (client.connected()) {
      if (client.available()) {
        char c = client.read();
        // if you've gotten to the end of the line (received a newline
        // character) and the line is blank, the http request has ended,
        // so you can send a reply
        if (c == '\n' && currentLineIsBlank) {
          // send a standard http response header
          client.println("HTTP/1.1 200 OK");
          client.println("Content-Type: text/html");
          client.println();

          client.print ("Garage door is ");
          byte door = digitalRead(relayPin); 
          if (door == HIGH)
            client.println ("closed.");
          else
            client.println ("open.");
       
          break;
        }
        if (c == '\n') {
          // you're starting a new line
          currentLineIsBlank = true;
        } 
        else if (c != '\r') {
          // you've gotten a character on the current line
          currentLineIsBlank = false;
        }
      }
    }
    // give the web browser time to receive the data
    delay(1);
    // close the connection:
    client.stop();
  }
}

@Nick: That is a server sketch. My server stuff doesn't need the timeout code either, just the client sketches. This isn't one of those errors you find right away. I had to create the error to find it. It is a "it runs for a few days, then crashes" kinda thing.

OK, well my client that monitors my garage door server (the server sketch above) is the one I put the watchdog in.

I have it turn on an LED when it starts to query the server and turn it off once completed. Every now and again (like, every few weeks) it would stay on. It hasn't since I put the watchdog in.

I also have it monitoring my son's Minecraft server, by connecting to it and finding how many players are online. So it now connects to two servers. So far so good. It's kind-of cool seeing the number of players on a 8x8 LED matrix sitting there.

The client sketch does not have a timeout, other than the watchdog.

The client sketch does not have a timeout, other than the watchdog.

Then that is substituting for the timeout as it probably was for the OP. We are trying to eliminate the need for a watchdog restart.

Fair enough, but for something that goes wrong occasionally I would be happy to have it there.

At last I have found some answers to my reliability issues. It seems to be in my service provider end, not in my software after all.
I did a test with my new Mega1284 board http://byremote.blogspot.com.au/2013/07/the-new-mini-biggie.html using a Wiz820 module, running side by side with my original system. My original system (an Ethermega) logs the assorted sensor data, the new board a test sinewave.
Looking at the two lots of logged data on Thingspeak, the breaks in the data match up.
Then I put my 1284 board at a friends place logging the test sine-wave and the breaks go away.
At home I use wireless broadband with Telstra (phone line internet is not available), my friends place uses ADSL2 down the phone line.
Using the ADSL internet, the large gaps and dropout of data are no longer present. There is still occasions when one or two posts have been missed but these are rare. It happens from both locations but they do not synchronize, they seem to be random. The 30min, 1hr gaps have gone with the wired internet. On the home front, the large drops are still present.
This gives me some hope that I'm not perhaps doing something fundamentally wrong after all :slight_smile:

Stewie, l'm just learning about this stuff, so cannot comment on code, etc. However, did you try measuring the actual amount of RAM used by the program?

Hi,
Several times I logged the memory usage, for about a week each time. By this stage I had removed or recoded parts of my program that had suspect memory leak problems (a lot of forum and google searching for that info).
Now that I am running essentially the same software on both boards (Ethermega and my 1284P variant), the Ethermega on the Telstra broadband internet (through the mobile phone network) is the one that looses data. The 1284 board does not have the same issue.
In a few weeks I'll swap the board locations just to confirm. If the problem goes with the location, not the board then at least I know where I stand and I can stop chasing a 'fault' that may not exist with my hardware.