SailerMan, I never noticed that! I basically used the code given in the ping))) example just modifying it a bit. HAhaha.... nice catch.
Steve J. , I'm planning on given that a shot tonight. I'll give you an update later!
I have never gotten my code to stablize. To date there is no solid reading - meaning it varies by a lot more then 3-4, it can vary as much as 80. Right now the only solution I have to solve this problem is test my stamp - which appears to be working correctly - or add in IR.
IR is being added so that if the sonar defaults to zero and the IR reads 1 then the reading is ignored. Problem is it eats up extra pins and code space. The other annoyance is that the original problem still isn't solved.
Other then IR the only option I see is to re-route one of my robots and test everything on a different board.
Hey Hey, well. I manage to get my reading to stablize a lot better. No more zero readings and no more high enders. Now it reads pretty much bang on +/-2 cm BUT with on occansion the weird number where its gives me -5 to - 10cm of what it should be. I put a dummy delay after my pulsout but my compiler doesn't recongize the dummy command so I put a delay of 400us. That helped a lot. So I guess the next step is to put in a software filter. Just gotta learn which one I need and how to do it. Let me know how you make out.
There is a post by John Abshier Posted 1/3/2007 9:01 AM (GMT -6)·that may be useful.
Andy Lindsay (Parallax)·Posted 1/2/2007 3:44 PM (GMT -6)··gave·the most helpful information. It didn't solve my problem but greatly aided stabalization.
One note -- A PIC16F84 will cycle at 5 Mhz, using the Proton+ compiler. This is WAY faster than a BS2, which the Ping is designed for. So you may need an additional 1 or 2 mSec delay to let the 'ping' recover (or the echo's from an earlier ping die away).
I'm just thinking aloud here, but I xan't see that as a problem, unless you're talking about continuing, late echos in a large, bare room (think basketball court). Under ordinary circumstances, I would hope there would be enough delay built into the PING))) to "blank" any early secondary echos, post initial audio signal aquisition.
Ah, that's one of the nice things about the BS2 and using sensors -- to really understand what's going on, you really have to understand the physics behind it. On the other hand, a hand-waving, approximate understanding will get you enough results to know if you really need that deeper understanding.
A deep understanding of the 'ping' sensor, for example, can include knowing the speed of sound in air, and the effects of temperature and humidity on that speed. As well as sound-reflective properties of various surfaces. As well as any 'recovery' time needed by the Ping hardware before the next 'ping'.
Alrighty! After 2 days of looking at it and thinking (about 1 hr a day.... playing xbox360 hehehe...) I manage to get it to work with virtually no tolerance. I measured up to 77in and it was really stable!! Anyways.... here my code that I used. Might wanna give it a shot AIman but your going to have to convert it to your compiler since mine was compiled in proton+
Main:
i = 0 'Loop variable
For i = 0 To 4
Low SRRS ' Makes Trigger 0-1-0
PulsOut SRRS, 1 ' Activate sensor
DelayUS 200 ' Delay 200 uS
Temp = PulsIn SRRS, 1 ' Measured echo pulse width and store in array
DelayMS 100 'Add a delay to allow time for echo to die away before sending another burst
Next i
RawDis = RawDis * 10 ' Convert to uS
RawDis = RawDis / 2 ' Remove return trip
RawDis = RawDis ** cmconvert ' Convert to cm
Print $Fe,1 'For Clearing the LCD
Print $Fe,2 'For Returning the cursor home
Print Dec RawDis, " cm" 'Displaying the distance on LCD
DelayMS 100 'Another delay..... although I doubt I need it....
GoTo Main
Comments
Steve J. , I'm planning on given that a shot tonight. I'll give you an update later!
IR is being added so that if the sonar defaults to zero and the IR reads 1 then the reading is ignored. Problem is it eats up extra pins and code space. The other annoyance is that the original problem still isn't solved.
Other then IR the only option I see is to re-route one of my robots and test everything on a different board.
There is a post by John Abshier Posted 1/3/2007 9:01 AM (GMT -6)·that may be useful.
Andy Lindsay (Parallax)·Posted 1/2/2007 3:44 PM (GMT -6)··gave·the most helpful information. It didn't solve my problem but greatly aided stabalization.
Just a thought.
I'm just thinking aloud here, but I xan't see that as a problem, unless you're talking about continuing, late echos in a large, bare room (think basketball court). Under ordinary circumstances, I would hope there would be enough delay built into the PING))) to "blank" any early secondary echos, post initial audio signal aquisition.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->
A deep understanding of the 'ping' sensor, for example, can include knowing the speed of sound in air, and the effects of temperature and humidity on that speed. As well as sound-reflective properties of various surfaces. As well as any 'recovery' time needed by the Ping hardware before the next 'ping'.
Main:
i = 0 'Loop variable
For i = 0 To 4
Low SRRS ' Makes Trigger 0-1-0
PulsOut SRRS, 1 ' Activate sensor
DelayUS 200 ' Delay 200 uS
Temp = PulsIn SRRS, 1 ' Measured echo pulse width and store in array
DelayMS 100 'Add a delay to allow time for echo to die away before sending another burst
Next i
RawDis = Temp[noparse][[/noparse]0] + Temp + Temp + Temp + Temp ' Very Simple averaging filter (Old school style)
RawDis = RawDis / 5
RawDis = RawDis * 10 ' Convert to uS
RawDis = RawDis / 2 ' Remove return trip
RawDis = RawDis ** cmconvert ' Convert to cm
Print $Fe,1 'For Clearing the LCD
Print $Fe,2 'For Returning the cursor home
Print Dec RawDis, " cm" 'Displaying the distance on LCD
DelayMS 100 'Another delay..... although I doubt I need it....
GoTo Main