My first attempt was a standalone program where the pulse of an ultrasonic distance meter is converted into a distance. Measuring the time between the flanks of the pulse is done by each edge of the pulse to generate an interrupt. The interrupt routine gets the call as an extra at the time of the interrupt system included. The difference of this interrupt time and that of the last interrupt time you can calculate the distance.
This method seemed to work well initially, but if you simple program expanded to include more features and multiple threads, the accuracy rapidly. In my test case it was not possible for distances less than 15 cm to measure because there is almost always more than 10 cm distance was determined.
Because of this I switched to the PinCapure ability to measure the time because I think that this possibility may have less overhead.
PinCapture the possibility does indeed give better results in higher loads of the processor.
However, the number of failed measurements is comparatively quite large.
I test the number of entries in the buffer PinCapture and ignore the measure if the number is not as expected. The number is still 0 after the timeout and I expect a number of 2.
I use the method PinCapture okay?
[quote]srf error: nr=1 cnt=0 value=0
srf error: nr=1 cnt=0 value=0
srf error: nr=1 cnt=0 value=0
In the interrupt method, the accuracy of 100 nanoseconds and and a PinCapture method has the accuracy of 1 microsecond.
My preference is because of the accuracy of the interrupt method.
Another question is whether this type of measurements to do well without the use of RLP?
maxSRF the number of ultrasonic sensors and also the number of gates which srfComponents in the array. In this way I do to code sharing, the ultrasonic sensors may only be used to take turns because of the mutual influence (40 kHz sound)
@ IanR. Hi. Blocking just means the method does not return until finished. In this case, you don’t hit Dispose until prior method returns. In this case, no user threading or locking to get involved with. Just a method that works until finished and move to next statement. I guess in that respect, every method call is blocking (unless it returns an async result you then wait on) hth
William! I need to start a thread with you! I can’t get my head around threading and I really need to get my serial datalogger finished, Your Fez Term works brilliantly. Would you be able to help me!! if you can I’ll set a thread called William and serial…
The SRF05 ultrasonic distance sensor has a mode where the trigger pin and the pulse separation pins. This mode I have now been tested and works without errors.
The time between the trigger pulse and the resulting pulse is 700 microseconds. It appears that this time too little for the FEZ Panda to reliable operation. This mode of the sensor is designed for slower systems like the Basic Stamp BS2. I expected this with the FEZ Panda possible.
700us should not be a problem. Use the new pulsecapture class I can capture 70us pulses. Take a look at the time subsection of the microcontroller too. You can likely set up a very accurate pulse capture with the register class or RLP.
@ Jeff. The problem is not the capture of a pulse of 700us, but switching to form outputPin to capturePin (see below the code used for this), which in some cases with multiple trheads more time,
The start of the pulse is approximately 10% of cases missed. In a small standalone test program there are no problems.
Looking at your code I see some way to dramatically improve things. Disposing of objects and instantiating new ones in the middle of trying to to a timing critical operation is not a good idea. Instantiate your objects, then do all the pin state setting and pulse reading in one shot. Finally don’t dispose of the objects unless you need to as presumably you’ll be wanting to read this sensor multiple times.