RobFromLI

In my debouncing stuff that i've done I had to increase the time from 50ms to around 200ms.

I also had to not use the time parameter passed in to the event handler, but instead use DateTime.UtcNow as well as wrapping the event handler in a lock block. Here's a quick example (untested) to replace the entire button_OnInterrupt check.

private static bool _currentState = false;
private static void button_OnInterrupt(uint port, uint data, DateTime time)
{
 lock(this)
 {
  var now = DateTime.UtcNow;
  if (LastInterrupt.AddMilliseconds(200) > now)
  {
   LastInterrupt = now;
   return;
  }
  _currentState = !currentState; //I don't trust data because of bouncing
  onboardLED.Write(_currentState);
  reqnum++;
  HttpWebRequest.Create("http://192.168.1.80/this?" + reqnum + "=" + _currentState).GetResponse().Dispose();
  LastInterrupt = now; //set this here because it's possible the web request takes longer than 200ms which would break the debounce. Calls to the handler are queued up. You might want to consider moving the state changes into a queue and have a seperate thread process the queue, though that's more complicated.
 }
}

FYI, UtcNow is faster than .Now

THANK YOU!! Your input was key!  Here's the final routine, seems rock solid now.

        private static void button_OnInterrupt(uint port, uint data, DateTime time)
        {

            lock (D1)
            {

                var now = DateTime.UtcNow;
                Boolean newValue = false;
                newValue = D1.Read();

                if (LastInterrupt.AddMilliseconds(100) > now && lastvalue == newValue)
                    return;

                // Activate the LED when button is pressed (data == 1)
                lastvalue = newValue;
                onboardLED.Write(lastvalue);
                reqnum += 1;
                
                String s = newValue.ToString();
                String t = String.Concat("http://192.168.1.80/this?D1=");
                //if (data == lastvalue)
                //    return;


                HttpWebRequest test = (HttpWebRequest)HttpWebRequest.Create(String.Concat(t, s));

                //try
                //{
                test.GetResponse();

                test.Dispose();

                //}
                //catch (Exception ex)
                //{
                //    Debug.Print(ex.Message);
                //}
                LastInterrupt = now;

            }
        }
 

In my debouncing stuff that i've done I had to increase the time from 50ms to around 200ms.

I also had to not use the time parameter passed in to the event handler, but instead use DateTime.UtcNow as well as wrapping the event handler in a lock block. Here's a quick example (untested) to replace the entire button_OnInterrupt check.

private static bool _currentState = false;
private static void button_OnInterrupt(uint port, uint data, DateTime time)
{
 lock(this)
 {
  var now = DateTime.UtcNow;
  if (LastInterrupt.AddMilliseconds(200) > now)
  {
   LastInterrupt = now;
   return;
  }
  _currentState = !currentState; //I don't trust data because of bouncing
  onboardLED.Write(_currentState);
  reqnum++;
  HttpWebRequest.Create("http://192.168.1.80/this?" + reqnum + "=" + _currentState).GetResponse().Dispose();
  LastInterrupt = now; //set this here because it's possible the web request takes longer than 200ms which would break the debounce. Calls to the handler are queued up. You might want to consider moving the state changes into a queue and have a seperate thread process the queue, though that's more complicated.
 }
}

FYI, UtcNow is faster than .Now

Thanks, I will definitely try this.  I was wondering if I was running into re-entrancy issues because that would explain the randomness, and it makes sense to try the current UTC when the interrupt time param doesn't make sense.  Thanks for the help!

Hi Rob,

 

You're perfectly on point that your circuit it will work just fine. The Netduio's digital pins are 5V tolerant even though they operate at 3.3V. That is to say, they output 3.3V signals, but will accept 5V or 3.3V signals as input. That said, it certainly wouldn't hurt to go with 3.3V, it will even save a miniscule amount of power (though really, not enough be worthwhile is all but the most power sensitive applications). As a word of caution: the Netduino's analog pins, when not operating as digital pins, are NOT 5V tolerant, and using a 5V signal could damage them. To be safe, I try to only use 3.3V signals with the analog pins.

 

As a point of nomenclature, a resister tied to ground is a pull-down (down to 0) and a resistor tied to VCC is a pull-up.

 

Good luck!

Thanks very much!  I will proceed with my project and I'll try to report back when I've succeeded.  Thanks for the help!