Ultrasonic sensor values

[Edelmann]

Hi,

Im performing some tests of the NXT sensors, and it seems to me that only every 3 calls to the method getDistance() of the the class UltrasonicSensor returns the correct value. The remaining calls return 255.

Has anyone else experienced this or is my sensor broken? The sensor is connected to the NXT via port 1 and my program is just making 1000 calls to getDistance() in a while-loop, so nothing fancy.

[gloomyandy]

Are you delaying between each call to the sensor? If you are using the released version then you may need to add a 20mS delay between each call (you may be able to get away with 15mS).

Andy

[Edelmann]

Thanks for the quick reply.

I tried adding a small delay and the results came out much nicer. It seems, that the delay can be as small as 4 ms with the sensor still working.

Thanks again.

- Edelmann

[gloomyandy]

Hi,
Yes 4ms is the minimum time to allow the sensor to settle. However an actual ping will take at least 15ms (because of the speed of sound), so new values will only be available every 15ms or so. So asking for data any faster then this is really only wasting cpu time...

Andy

[bbagnall]

Andy, does your new code allow users to get distances without inserting a delay between calls?

[gloomyandy]

Hi Brian,
Sort of! When in continuous mode the new code ensures that there is at least a 5ms delay between commands (as required by the sensor). It only adds the needed delay. So if you make a call to one of Ultrasonic apis and then do something that takes say 2ms then the code will add a delay of 3ms to make sure things work. If the user code takes more than 5ms then the sensor code will not insert a delay...

If you ask for data more often than every 15ms it simply returns the latest value (and does not bother to ask the sensor, since this is what you would get anyway) So you can call it as often as you like and you will get the data as it becomes available. But you may as well delay by 15ms or so to save the cpu... I did consider building in a delay but I thought it was better to leave this under the control of the caller...

Andy