[resolved] NXC: USS readings w/o delay
[resolved] NXC: USS readings w/o delay
hey,
how can Lego USS readings be programmed by NXC w/o artificial wait() delay of several (20? 30?) ms between 2 readings?
(Or is this issue already fixed in the current NXC API?)
how can Lego USS readings be programmed by NXC w/o artificial wait() delay of several (20? 30?) ms between 2 readings?
(Or is this issue already fixed in the current NXC API?)
Last edited by HaWe on 09 Jun 2013, 15:56, edited 1 time in total.
Re: NXC: USS readings w/o delay
SensorUS remains unchanged since it is working as designed. You should have new API functions to call which do not include a wait. Searching the NXC API online help is very useful.
Also:
John Hansen
Also:
John Hansen
Multi-platform LEGO MINDSTORMS programming
http://bricxcc.sourceforge.net/
http://bricxcc.sourceforge.net/
Re: NXC: USS readings w/o delay
But do not forget that as I have mentioned previously, if you happen to communicate with the Ultrasonic sensor more frequently than about once every 15 milliseconds then it will stop functioning properly until you disconnect it and reconnect it.
John Hansen
John Hansen
Multi-platform LEGO MINDSTORMS programming
http://bricxcc.sourceforge.net/
http://bricxcc.sourceforge.net/
Re: NXC: USS readings w/o delay
Thanks a lot, SensorUS0 is fine!
Actually I have been looking through the NXC help typing "SensorUS" and pressing F1 -
what I got was just, in alphabetical order, w/o any reference to similar functions like SensorUS0.
But indeed, I admit that I didn't recall this information :
Anyway, now I can ready multiple USSs and different other sensors attached by multiplexers in just 1 endless loop and add a Wait(15) at the end by my own.
BTW - does the default 30ms Wait() concern respectively also each single USS attached to the HT sensor Muxer?
Actually I have been looking through the NXC help typing "SensorUS" and pressing F1 -
what I got was just, in alphabetical order,
Code: Select all
SensorTemperature
SensorUS
WriteI2CRegister
But indeed, I admit that I didn't recall this information :
I just thought it would lead to multiple readings of 1 value until a real new one will come in by i2c about 30ms later.if you happen to communicate with the Ultrasonic sensor more frequently than about once every 15 milliseconds then it will stop functioning properly until you disconnect it and reconnect it.
Anyway, now I can ready multiple USSs and different other sensors attached by multiplexers in just 1 endless loop and add a Wait(15) at the end by my own.
BTW - does the default 30ms Wait() concern respectively also each single USS attached to the HT sensor Muxer?
Re: NXC: USS readings w/o delay
The only reason for the built-in 15 ms wait in SensorUS was to prevent the US sensor from returning bad data (i.e., incorrect distance values). I am not 100% sure if it recovers or not on its own when you increase the wait to 15ms.
It sounds like you have old help files or old api text files or something. F1 should display the compiled help file in the windows HTML help viewer. Is that what you mean occurred when you pressed F1? Does the IDE highlight the name SensorUS0 as an API function? Is that function listed in your Default folder's nxc_api.txt file? In mine I have
If the function is in the nxc_api.txt file but it does not show in the Code Completion window as I show above then you may need to click the Default button while the API tab is active in the Preferences dialog so that the IDE reloads the list of API functions from the nxc_api.txt file rather than from the registry.
You should have a .chm help file in the Help folder that contains documentation for the SensorUS0 function also. If you do not then you may have not extracted the test release zip correctly. I would run the test full installer since it will, for sure, deliver all the files into the right folders.
John Hansen
It sounds like you have old help files or old api text files or something. F1 should display the compiled help file in the windows HTML help viewer. Is that what you mean occurred when you pressed F1? Does the IDE highlight the name SensorUS0 as an API function? Is that function listed in your Default folder's nxc_api.txt file? In mine I have
Code: Select all
SensorUS(const byte port)
SensorUS0(const byte port)
SensorUSWait(const byte port, const byte wait)
You should have a .chm help file in the Help folder that contains documentation for the SensorUS0 function also. If you do not then you may have not extracted the test release zip correctly. I would run the test full installer since it will, for sure, deliver all the files into the right folders.
John Hansen
Multi-platform LEGO MINDSTORMS programming
http://bricxcc.sourceforge.net/
http://bricxcc.sourceforge.net/
Re: NXC: USS readings w/o delay
John,
Since I run
bricxcc_setup_33810_20130220.exe
now the context help by F1 is fine and I'm getting description of all of the following functions:
SensorUS(const byte port)
SensorUS0(const byte port)
SensorUSWait(const byte port, const byte wait)
Stangely, SensorUS is written in blue color (like, e.g., NumOut )
while SensorUS0 + SensorUSWait are of green color (how, e.g., variables like port or wait appear).
Probably just blemishes...
edit: I first didn't understand what you meant by default button in preferences but now I found it and afterwards all SensorUS* are blue.
But what is it about 4 USSs at a HT sensor Muxer? is there also a 15 ms (?) wait for each single USS, so > 60ms for all 4 together, when polled one after the other?
Since I run
bricxcc_setup_33810_20130220.exe
now the context help by F1 is fine and I'm getting description of all of the following functions:
SensorUS(const byte port)
SensorUS0(const byte port)
SensorUSWait(const byte port, const byte wait)
Stangely, SensorUS is written in blue color (like, e.g., NumOut )
while SensorUS0 + SensorUSWait are of green color (how, e.g., variables like port or wait appear).
Probably just blemishes...
edit: I first didn't understand what you meant by default button in preferences but now I found it and afterwards all SensorUS* are blue.
But what is it about 4 USSs at a HT sensor Muxer? is there also a 15 ms (?) wait for each single USS, so > 60ms for all 4 together, when polled one after the other?
Re: NXC: USS readings w/o delay
Hi Doc,
I tested the US-sensor quite thoroughly and made a blog post about it: http://nxttime.wordpress.com/2012/09/12 ... ic-sensor/.
It is not NXC specific but might still be useful.
Aswin
I tested the US-sensor quite thoroughly and made a blog post about it: http://nxttime.wordpress.com/2012/09/12 ... ic-sensor/.
It is not NXC specific but might still be useful.
Aswin
My blog: nxttime.wordpress.com
Re: NXC: USS readings w/o delay
hey aswin,
thank you for sharing this information!
Over all I have 6 USS to poll ( 2 in front in different heights, 2 rear, 1 left, 1 right).
I'm just curious about:
do I have to add additional wait states like Wait(15) at the end of a multi-sensor-polling-loop when using several USSs plugged to a HT sensor muxer, or not?
(If each single HT sensor muxer i2c call for each mux port lasts about 15-30ms (I'm not sure if this is true), then I guess that I won't have to.)
thank you for sharing this information!
Over all I have 6 USS to poll ( 2 in front in different heights, 2 rear, 1 left, 1 right).
I'm just curious about:
do I have to add additional wait states like Wait(15) at the end of a multi-sensor-polling-loop when using several USSs plugged to a HT sensor muxer, or not?
(If each single HT sensor muxer i2c call for each mux port lasts about 15-30ms (I'm not sure if this is true), then I guess that I won't have to.)
Re: NXC: USS readings w/o delay
Aswin, in your post you mention a 7 cm minimum for the US sensor but I have seen what appear to be correct measurements as low as 3 or 4 cm. Can you elaborate on what you meant?
John Hansen
John Hansen
Multi-platform LEGO MINDSTORMS programming
http://bricxcc.sourceforge.net/
http://bricxcc.sourceforge.net/
Re: NXC: USS readings w/o delay
John,
At closer ranges I did not get a constant signal. There are still proper values in the readings at closer ranges but also more and more false readings. This makes the signal unreliable for the average user.
Aswin
At closer ranges I did not get a constant signal. There are still proper values in the readings at closer ranges but also more and more false readings. This makes the signal unreliable for the average user.
Aswin
My blog: nxttime.wordpress.com
Who is online
Users browsing this forum: No registered users and 14 guests