[resolved] NXC: USS readings w/o delay

Discussion specific to NXT-G, NXC, NBC, RobotC, Lejos, and more.
HaWe
Posts: 2500
Joined: 04 Nov 2014, 19:00

[resolved] NXC: USS readings w/o delay

Post by HaWe »

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?)
Last edited by HaWe on 09 Jun 2013, 15:56, edited 1 time in total.
afanofosc
Site Admin
Posts: 1256
Joined: 26 Sep 2010, 19:36
Location: Nashville, TN
Contact:

Re: NXC: USS readings w/o delay

Post by afanofosc »

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.

Image

Also:

Image

John Hansen
Multi-platform LEGO MINDSTORMS programming
http://bricxcc.sourceforge.net/
afanofosc
Site Admin
Posts: 1256
Joined: 26 Sep 2010, 19:36
Location: Nashville, TN
Contact:

Re: NXC: USS readings w/o delay

Post by afanofosc »

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
Multi-platform LEGO MINDSTORMS programming
http://bricxcc.sourceforge.net/
HaWe
Posts: 2500
Joined: 04 Nov 2014, 19:00

Re: NXC: USS readings w/o delay

Post by HaWe »

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,

Code: Select all

SensorTemperature 
SensorUS 
WriteI2CRegister 
w/o any reference to similar functions like SensorUS0.

But indeed, I admit that I didn't recall this information :
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.
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.
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?
afanofosc
Site Admin
Posts: 1256
Joined: 26 Sep 2010, 19:36
Location: Nashville, TN
Contact:

Re: NXC: USS readings w/o delay

Post by afanofosc »

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

Code: Select all

SensorUS(const byte port)
SensorUS0(const byte port)
SensorUSWait(const byte port, const byte wait)
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
Multi-platform LEGO MINDSTORMS programming
http://bricxcc.sourceforge.net/
HaWe
Posts: 2500
Joined: 04 Nov 2014, 19:00

Re: NXC: USS readings w/o delay

Post by HaWe »

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?
aswin0
Posts: 201
Joined: 29 Sep 2010, 06:58

Re: NXC: USS readings w/o delay

Post by aswin0 »

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
My blog: nxttime.wordpress.com
HaWe
Posts: 2500
Joined: 04 Nov 2014, 19:00

Re: NXC: USS readings w/o delay

Post by HaWe »

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.)
afanofosc
Site Admin
Posts: 1256
Joined: 26 Sep 2010, 19:36
Location: Nashville, TN
Contact:

Re: NXC: USS readings w/o delay

Post by afanofosc »

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
Multi-platform LEGO MINDSTORMS programming
http://bricxcc.sourceforge.net/
aswin0
Posts: 201
Joined: 29 Sep 2010, 06:58

Re: NXC: USS readings w/o delay

Post by aswin0 »

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
My blog: nxttime.wordpress.com
Post Reply

Who is online

Users browsing this forum: No registered users and 0 guests