NXT programmable brick : 920


Robotics / NXT / 920	919 \| 921

Subject:	Re: Ooops! NXT Software Comparison correction / I2C Messaging Speed
Newsgroups:	lugnet.robotics.nxt
Date:	Wed, 5 Sep 2007 20:40:16 GMT
Viewed:	21677 times

In lugnet.robotics.nxt, <dickswan@sbcglobal.net> wrote: > > I define "perfect" to mean that if the first value read was 22 cm then > all subsequent values are in range 21 to 23 cm and there were no I2C > bus errors. When I removed the 2 msec delay, then errors occurred. The errors that occur are that the sensor does not properly report variable distances as it is positioned at varying distances from an obstacle. If you slow down the read rate then it works correctly (i.e., with a wait of ~15 ms between read transactions) but without that delay it does not accurately reflect the varying distances as it should. I'm not talking about getting bus errors - just invalid distance readings from the sensor. Can you re-run your tests and verify that you are getting accurate readings from 3cm to 255cm as the fast loop is executing and issuing read transactions faster than once every 15 ms or so? It's been a while since I ran into this problem and added the wait to correct it, but my recollection is that every US sensor and brick I tried with the standard 1.04 NXT firmware had this same issue. If in RobotC you can get the US sensor to return valid distance readings at a rate of once per 10 ms then the loop count limit in Steve's timing test for RobotC is 6000. Are you admitting to having cheated in Steve's timing test results? If you take the US sensor read transaction out of the loop then you are doing something completely different than Steve's pseudo-code required - at least, that is, if you are really interested in valid comparisons between different development platforms. John Hansen

Message has 3 Replies:

		Re: Ooops! NXT Software Comparison correction / I2C Messaging Speed
(...) I think I understand. In this case, the limiting factor is the US sensor itself, how fast it can ing and interprete a return. Or from my standpoint (a physicist), it's a fundemental limitation of the physics of sound, not a limitation that has (...) (17 years ago, 5-Sep-07, to lugnet.robotics.nxt)

		RE: Ooops! NXT Software Comparison correction / I2C Messaging Speed
(...) Nobody cheated or is dishonest. Everyone who writes firmware for the NXT is well-intentioned "good" people. Let's not mislabel good modern programming practice -- i.e. hardware device drivers integrated into the low-level firmware -- as (...) (17 years ago, 6-Sep-07, to lugnet.robotics.nxt)

		Ultrasonic Sensor iS "Slow"
Original Thread title was "Re: Ooops! NXT Software Comparison correction / I2C Messaging Speed". I've renamed as worth a separate thread. (...) You're right!! If you poll the sensor too fast, it definitely reports wrong distances. I'm doing some (...) (17 years ago, 7-Sep-07, to lugnet.robotics.nxt)

Message is in Reply To:

		RE: Ooops! NXT Software Comparison correction / I2C Messaging Speed
(...) I wasn't aware of this firmware limitation. I could not duplicate it when using the ROBOTC firmware. I've done three different test runs of 500K messages each with perfect results each time. Each test run used a different sensor. The delay (...) (17 years ago, 5-Sep-07, to lugnet.robotics.nxt)

13 Messages in This Thread:

Entire Thread on One Page:: Nested: All | Brief | Compact | Dots
Linear: All | Brief | Compact
This Message and its Replies on One Page:: Nested: All | Brief | Compact | Dots
Linear: All | Brief | Compact

Custom Search