The Netduino forums have been replaced by new forums at community.wildernesslabs.co.
This site has been preserved for archival purposes only
and the ability to make new accounts or posts has been turned off.
I have been having issues with the network dying on my Netduino Plus.
This poster seems to be having same/similar prob:
http://forums.netdui...vailable-in-42/
-Being on a busy network is what is killing it (it seems).
-I have found this on 4.1 and 4.2 firmware.
-Seems independ of code.
-When "dead", the rest of the Netduino still works.
--If a debugger is running, the program can report things like network address.
--onboard LED will continue to blink in a continuous loop.
--Pinging the Netduino ceases to work.
While on a busy network, it takes between 5minutes and an hour for the Netduino's net to stop responding.
While on a very quiet network, the Netduino seems to live a great deal longer... I just started a test setup and will let it run for a day.
My question:
From within the C# program, can I detect when the network port is no longer responsive?
I just had an idea!!!! maybe I could ping the localhost????
Anyways, I'd prefer to not have a watchdog. I prefer that the network port be dependable, or barring that, be able to detect in software when the network port had died and so have the software decide when to smartly do a reset.
Any ideas?
-kluger
Good questions. I think what options you have for recovery depend on how you have implemented networking on your device. For example in an app of mine, I use it to capture 4 lines of temperature and signal data and send it to a PC every 10 seconds via UDP. I can also send the device 'commands' to perform actions. I created 2 threads, a 'sending' and the other a 'receiving' thread. Each open a specified UDP port/endpoint and run in a loop, never closing or destroying the port. I wrap the loops in a try/catch blocks to catch exceptions and reboot the device when thrown.
I get the feeling that networking on the N+ will never be robust or 'dependable' as the fix would require more space than is available to implement. Hopefully things will improve with the NGo. Chris has been teasing with a much-improved, better, faster, stronger chip for networking...! (Maybe a combination Wifi/wired module!)
I suspect that having the Ethernet 'module' on the other end of a goBus will help isolate it from the NGo and make it easier to recover/reset without pulling the whole NGo down. At the very least, I would hope you will be able to plug/unplug at will, attach to a normal (busy) network and be able to recover it from error easily. We can only dream...
I wrote a program that
-sends "pong" to address 127.0.0.1:51110
-blinks the onboard led
-listens on port 51110 and prints whatever is recieved to the Debugger.
I ran this overnight on a network with some traffic, while simultaniously pinging the device from another computer.
When I checked this morning:
-The program was still running and printing "pong" to the Debugger.
-pinging the device from another computer had failed.
Here's the code:
using System.Net;
using System.Net.Sockets;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware.NetduinoPlus;
using System.Text;
namespace PingLocalhost
{
public class Program
{
private static OutputPort onboardLED = new OutputPort(Pins.ONBOARD_LED, false);
public static void Main()
{
new Thread(TCPServer).Start();
Thread.Sleep(500);
while (true)
{
TCPClient();
Debug.Print("Main() I'm still alive! memory available: " + Debug.GC(true));
onboardLED.Write(!onboardLED.Read());
Thread.Sleep(1000);
}
}
#region Test TCP Methods
static void TCPClient()
{
using (System.Net.Sockets.Socket clientSocket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp))
{
IPEndPoint remoteEndPoint = new IPEndPoint(IPAddress.Parse("127.0.0.1"), 51110);
clientSocket.Connect(remoteEndPoint);
clientSocket.SetSocketOption(SocketOptionLevel.Tcp, SocketOptionName.NoDelay, true);
clientSocket.SendTimeout = 3000;
byte[] message = Encoding.UTF8.GetBytes("pong");
clientSocket.Send(message);
}
}
/// <summary>
/// TCPServer() Largerly ripped off from SirPoonga
/// </summary>
static void TCPServer()
{
using (System.Net.Sockets.Socket socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp))
{
socket.Bind(new IPEndPoint(IPAddress.Any, 51110));
socket.Listen(1);
while (true)
{
using (Socket newSocket = socket.Accept())
{
if (newSocket.Poll(-1, SelectMode.SelectRead))
{
byte[] bytes = new byte[newSocket.Available];
int count = newSocket.Receive(bytes);
char[] chars = Encoding.UTF8.GetChars(bytes);
string str = new string(chars, 0, count);
Debug.Print(str);
}
}
}
}
}
#endregion
}
}
Thanks for your response emg,
I have been thinking about how to implement something like you have described, but in my case I have several N+ talking with each other.
What I may try is to have the N+ ping the gateway, and resets itself if the gateway becomes unreachable, but this solution seems sloppy to me.
I've looked around a little, has anyone written a "ping" for the N+?
The best solution would be a software test I can do to see if the network is alive.
Any other ideas???
-kluger
I am going to use software Watchdog to reboot my Netduino after a constant time. I know it is a simple question, but may I ask your help to do it?
The code that I developed is like that, but it doesn't work:
using System;using System.Net;using System.Net.Sockets;using System.Threading;using Microsoft.SPOT;using Microsoft.SPOT.Hardware;using SecretLabs.NETMF.Hardware;using SecretLabs.NETMF.Hardware.NetduinoPlus;namespace NetduinoPlusApplication1{ public class Program { public static void Main() { bool error = true; Watchdog.Timeout = new TimeSpan(0, 1, 0); //Timeout = 1 minute. Watchdog.Enabled = true; Debug.Print(Watchdog.Timeout.ToString()); while (error) { Debug.Print("There is a systematic error, so the system needs to reboot"); Thread.Sleep(2000); } } }}
and the Debug.Print(Watchdog.Timeout.ToString()); prints "00:00:00".
My "network die problem" was solved after spending 2 months on it Now, I am so happy. The solution I used was software watchdog developed by my own. If you are interested in the solution, take a look at this link: http://forums.netdui...lus/#entry49735
I will later publish a post to elaborate the whole procedures and solutions that were useless except the software watchdog.