When playing with these sensors I notice they take quite a while to stabilize after any changes. It may be as simple as moving between 3.3v and 5v VCC and they need some time to settle.

As far as I'm aware I'm catching everything. I haven't changed any settings to limit what I'm catching and I assume the default is to catch everything?!

catch (Exception ex)
{
    Debug.Print(ex.Message);
}

The exceptions that occur appear to kill the timer that calls UploadData as far as I can tell. I've still got the debug.print command I added to show the free memory and once one of the exceptions hits that timer stops firing (it's the first line in the subroutine)

No, not at all, both sites are internet based so it's entirely possible they are down or have some other issue...

The question is how do I handle that cleanly and without causing an exception? Embedding the statement in another try block doesn't work as I've also just gotten a 10053 error (connection aborted) at the same place.

Ideally what I'd like to be able to do is detect the exception and either just ignore it (since I'll send again in 30 seconds anyway) or retry it

Right, so I got an exception from System.Net.Sockets with an errorcode of 10060 and an m_HResult (whetever that is) of 4278190080 as this line 

using (var response = (HttpWebResponse)request.GetResponse())

10060 appears to be a timeout 

My question is why does a timeout cause an exception, and secondly shouldn't the try block that this is encased in catch this anyway? Or does a try block only catch exceptions from the next line?

After a lot of random googling, it looks like this behavior is actually "by design"

Timers using System.Threading.Timer will terminate upon an exception, no matter what you do with it, see here

There appear to be a couple of other options I can try although they use System.Timers.Timer and I'm not sure that's in NETMF and not in a position to look right now

Can you give me a quick example of that by chance? I've done threads before so thats fine, just the blocking and manualreset that I've never heard of before. Also, thanks heaps for all the help!

It has been in a try/catch the whole time, but it was still bombing out....

However, it's been happily running for something like 5 days now, and while it reports the stacktrace now, it's not locking up. I _think_ I either had a dodge network cable or is was the passive POE injector I was using (maybe a combination of both).

I've switched toa new network cable and removed the POE injector and it appears to be stable....

You'd think working in IT I would have looked at that earlier . I also think putting it in it's own thread and using autoreset has helped too but at the moment I'm leaning towards the cable. After I hit a week I'll put the injector back in and see what happens.

Thanks for all your help on this. 

Right, with ex.Stacktrace we have some success. I'm seeing 

So now I'm onto trying an AuroResetEvent since the delay in the main code just ended up crashing the main thread.

The weirdest thing is that I'm still not actually catching the exceptions in the catch block. I've added some text to the Debug.Print so now it looks like this

Debug.Print("SF: " + ex.Message);

and I get the occasional "SF:" printed, but no actual error. 

Still, we'll see if this is any more reliable...

I think what I'll do is just kill the 30 second timer and call the UploadData routine directly from my main loop, which has been completely empty until now with a Thread.Sleep(Timeout.Infinite) so I'll throw a while loop there with a Thread.Sleep(30000) and just call UploadData from there.

That should hopefully sort out the timer being killed issue and I should be able to catch the damn errors

So, not a memory leak, free memory stays pretty static around 79000

Is there some way I can catch the exceptions coming from System.Net and System.Http?

I haven't, but that's only because I have never known how too

With only an initial NTP sync I still see it so it's not NTP that's causing the problem. I actually captured the exception and it's coming from inside System.http.

I do suspect a memory leak but as far as I can tell it's inside the HTTP library. Anyway, I'll start tracking it now and we'll see what we end up with. The error doesn't appear to be the actual cause of the lockups, at least not directly, the lockup itself is the above mentioned exception (so not technically a lockup) and the errors occur multiple times before that happens, seemingly at random. It also doesn't appear to be tied to one site specifically as I've enabled and disabled both the sparkfun stream and the weather underground stream and it continued to happen on both, so it's not some screwy response from the server causing it.

I put the dispose in there as I had the same idea that it was a memory leak so I wanted to make sure the request was being cleaned up. 

In saying that, I haven't seen the same issue for a couple of days now so I'm wondering if something else I've done has fixed it. Code is attached below. It's a decent size so it's not inline.

Basically I have an arduino with weather sensors attached mounted outside. It sends all the data to the Netduino via an nRF24L01+ radio system every 10 seconds and from there the Netduino uploads it to Sparkfun (and now Weather Underground) ever 30 seconds. 

Just thinking about how I've seen this happening it's possible the errors are actually coming from the NTP syncing which I'm doing once an hour as the only time I've seen these errors is when I've left MFDeploy sitting running for hours/days and I've had to remove all the Debug.print statements from my program to even see them as the scrollback buffer was never long enough so I don't know for sure that it's coming from the original timer.

Any ideas welcome

I should mention I'm running 4.3.1 firmware. Here's hoping they will fix it and we'll get a new firmware release otherwise my weather station receiver will need to move platforms. It's not ideal to have a data logger that stops logging data every day

Hi

I'm getting this error intermittently on my N2+ when trying to send an HTTP GET command. I'm also getting "IP Address: <ip address>" printed semi regularly that isn't generated from my code. Presumably both are coming from a lower level and I have managed to track down the error message in what appears to be the NETMF firmware files, but it doesn't really make much sense to me.

The code that's generating the error is as below. It's called every 30 seconds from a timer. Can anyone explain what I'm doing wrong or how to get rid of the error? It seems to recover from this most of the time and continue but other times it then stops sending network traffic, although the rest of the program continues on fine.

        private static void UploadData(object sender)
        {
            var URLString = "http://data.sparkfun.com/input/" + sfPublicKey + "?private_key=" + sfPrivateKey + "&humidity=" + humidity.ToString("F1") + "&pressure=" + pressure.ToString("F0") + "&rain=" + rainfall.ToString("F0") + "&temp=" + temp.ToString("F1") + "&voltage=" + voltage.ToString("F2") + "&winddirection=" + windDirection.ToString("F0") + "&windgust=" + windGust.ToString("F1") + "&windspeed=" + windSpeed.ToString("F1") + "&charging=" + charging.ToString();
 
            try
            {
                using (HttpWebRequest request = (HttpWebRequest)WebRequest.Create(URLString))
                {
                    request.Method = "GET";
                    request.KeepAlive = false;
                    request.Timeout = 5000;
                    request.ReadWriteTimeout = 5000;
 
                    using (var response = (HttpWebResponse)request.GetResponse())
                    {
                        if (response.StatusCode != HttpStatusCode.OK)
                        {
                            Debug.Print("HTTP Status:" + response.StatusCode + " : " + response.StatusDescription);
                        }
                    }
                    request.Dispose();
                }
            }
            catch (Exception ex)
            {
                Debug.Print(ex.Message);
            }
        }

I've switched over to the Toolbox HTTP_Client library rather than the built in one to see if that may help, I'll also look at switching over to the Toolbox NTP library too if I continue to see it and go from there. I'd still love to know how to lock the code blocks though

I'm getting a little lost trying to implement the locks. both lock and Monitor appear to require you specifying the actual object s to protech, but I just want to lock entire code blocks, and the objects are different in each block anyway?!

Thanks

The idea is for this to pretty much run uninterrupted for long periods of time so startup may only happen once every few months. I could probably push it out to once a week but I've got it going as often as it is pretty much exactly to catch these sorts of things

Locking didn't help, onto doing a single NTP sync on boot and seeing what happens with only the web traffic

Thanks for that, and for the record, the toolbox HTTP_Client appears to make it much much worse. I'll see how I go with adding some locks. Failing that I might add an RTC and remove the NTP code entirely and see if the problem persists

Well this will be interesting. I have a project that was basically useless because of the network issues. Just updated one of my NP2's and we'll see how it goes. I was rebooting every hour as a really ugly work around but hopefully this will fix that

I'm not sure if this will help, but it may give you another option to try. Iv'e written a driver for the Grove RGB I2C LCD dislpay. The code is pretty generic and will likely work with minor modifications to for your I2C controller. You could remove all the RGB backlight code pretty easily and then just add the right codes to perform all the functions.

The driver is here

https://github.com/s...veRGBLCD/lcd.cs

The actual repo has an example program as well but it's pretty straightforward

What _do_ you get when you right click in the edit box? Websites can replace the right click menu, but working around that is pretty simple with add-ons, but before you go down that road you'd want to confirm that's whats going on

I've written a basic driver for this here

It's basically a direct port of the supplied driver for the arduino