4 replies to this topic

[VipX1]

static InterruptPort iPort = new InterruptPort(
						Pins.GPIO_PIN_D0,
						true,
						Port.ResistorMode.PullUp,
						Port.InterruptMode.InterruptEdgeBoth );
iPort.EnableInterrupt( );
iPort.OnInterrupt += new NativeEventHandler( iPort_OnInterrupt );

static void iPort_OnInterrupt( uint data1, uint data2, DateTime time )
{
	if( data2 == 1 )
          Debug.Print( counter++ + ".) " + data2.ToString( ) );			}

When I short Digital I/O pin zero to GND I get Data2 == 0, that is great and what I want.
BUT; when I remove the short I get between 3 and 5 open and close events. e.g. 1010101

I'm shorting zero to GND threw a relay which is held closed for 200 milliseconds via a 555 timer so as to remove human error on the physical switch event. I have tried it free hand with a piece of wire also.

Am I doing something wrong. Surely it is possible to cleanly measure a closing contact on the Netduino.

[Paul Newton]

Hi there - happy new year! I'm not an expert on the software side of inputs and interrupts. However on the hardware side, I think you might be having a problem with switch contact bounce. Thats where a fast digital circuit registers several transitions as the contacts of a switch come together. Basically the contacts don't snap together cleanly in one go - they bounce. To rule this out as the cause, can you connect your 555 output directly to the Netduino input? (Voltage & hardware allowing) Alternativly, add a new thread to your code that waggles an output pin eg D1 and connect it to your D0 pin. Then monitor the events and see if the problem goes away. If it does, you need to look at software (or hardware) to filter out the extra pulses when using the relay. Paul

[VipX1]

Hi there - happy new year!

I'm not an expert on the software side of inputs and interrupts.

However on the hardware side, I think you might be having a problem with switch contact bounce.

Thats where a fast digital circuit registers several transitions as the contacts of a switch come together. Basically the contacts don't snap together cleanly in one go - they bounce.

To rule this out as the cause, can you connect your 555 output directly to the Netduino input? (Voltage & hardware allowing)
Alternativly, add a new thread to your code that waggles an output pin eg D1 and connect it to your D0 pin.

Then monitor the events and see if the problem goes away.

If it does, you need to look at software (or hardware) to filter out the extra pulses when using the relay.

Paul

Thanks Paul and Many Happy Returns!

I took the relay out. I used the 5Vdc that originally powered the relay to instead power a transistor that allowed my Netduino to see 0Vdc when the transistor was powered. It works brilliantly and is exactly what I wanted.

With out a doubt the problem was caused by Contact Bounce from the relay. I have learned something knew too.

My build is a IR sensor on a scalextrics track that measures the lap time each time the car passes the sensor. Notably it only works with one car at present because the sensor looks across the track. If it looked up on a single lane I could measure the lap times of both cars.
I used the TimeSpan type to measure the lap times so I can see the smallest differences in the lap times. It funny trying to scrub half a thousands fraction of a second of the lap time..

[VipX1]

Another Question; At present I can only see the Lap times in the Debug output of Visual Studio. I want to be able to see the lap times without Visual Studio running in debug. How can I connect in Real-Time the the Netduino. If I use a web server configuration I will have to reload the page almost constantly to get rapid updates which is no good. Has anyone ever used Endpoints on a Windows Form that Netduino hits post event? Every time a new lap time came in the Netduino would fire off a packet to the Windows Form and the Windows Form would in turn add a new entry to a listView. Is there any reason why this set up wouldn't work?

[CW2]

so I can see the smallest differences in the lap times. It funny trying to scrub half a thousand of a second of the lap time..

Please note the .NET MF time measurement limitations - if you wanted to have really precise timing, you would need to compensate for interrupt latency (~hundreds of microseconds) and internal clock resolution (~20 µs). But no need to worry about that if you need only hundreds or tens of milliseconds precision...