New Sonar Range Sensor

No real arguments from me.

The RS-232 spec. (now EIA-232) is often referred to, but rarely actually read. Part of the reason for this is because EIA (Electronics Industries Alliance) does not make it particularly easy to get your hands on a copy of the bloody specification. You are welcome to purchase a copy from Global Engineering Documents for $100.00 (US) . Frankly, I would rather spend $100 on my various robotics projects.

I had a photocopy of a photocopy of the actual EIA-232 specification some number of years back and it was not terribly exciting. From my possibly foggy memory, EIA-232 specifies the voltages levels (+/- 12V) and the pin-outs for DCE (Data Communications Equipment) and DTE (Data Terminal equipment.) To first approximation DCE=modem and DTE=teletype. The pin-out outs are for 25-pin D connector. To the best of my recollection (I could be wrong) the spec. did not specify the asynchronous signalling protocol of a start bit, 7 or 8 data bits, optionial parity bit, and 1,

1.5, or 2 stop bits. I do not know if that is written down in a different spec. somewhere. I also remember that the maximum cable length was specified as around 50 feet, even though people regularly exceeded that specification.

If anybody has the actual EIA-232 specification and can quote from it please feel free correct any errors in the text above.

-Wayne

[snip]
Reply to
Wayne C. Gramlich
Loading thread data ...

I've actually read it as well, & even wrote a book once, using RS-232C as a major source, although it's been a long time...

50 ft is a rule of thumb. The actual specification is 2500 pF capacitance of the leads. With 50 pF/ft "typical" for most cables, 50 ft also becomes theoretical max. length to stay within the limit. Lower speeds can get you longer runs because the capacitance (& therefore length) affects the rise times of signal states & there's more room for slop if the speed is slow than if it were fast.

IIRC, the difference between RS-232C & RS-232D was the introduction of the 9-pin cable/connector into the accepted standard (although it had been used in the field for years).

Other specs covering the same topic are CCITT V.24 & V.28 (different organization than EIA, basically "splits" the spec.).

JM

Reply to
John Mianowski

Reply to
Larry

Gordon, Sorry for that. The new product can be seen at

formatting link
Regards, Larry

Reply to
Larry

Reply to
Larry

Wayne,

Check out the PSR-1 at

formatting link
and give me your comments.

Larry

Reply to
Larry

Chris, Check out

formatting link
A new product is just about to come out that addresses your array needs and cost. Regards, Larry

Reply to
Larry

Larry:

You should probably announce your product in a new thread rather than tailgate on this one.

Are there any pictures of your PicoSonic Ranger-1 on the web site? I use Mozilla running on Linux and I all I got was some text, no pictures. When I read the page HTML, it looked like a bunch of 's and 's, but I saw no directives.

I'd also recommend that you post your manual in .pdf format so that anybody can download it and read it.

Just my thoughts,

-Wayne

Larry wrote:

Reply to
Wayne C. Gramlich

Need to be careful about hooking up TTL level RS232 to the real deal. Actual RS232 signaling typically ranges +/- 12 volts. The high and low voltages can damage the logic level pins if fed directly into the chip. You wouldn't connect a 9V battery to directly to your PIC without a regulator - similary, don't connect directly to level shifted RS232.

BTW, my shiny new Maxbotix MaxSonar-EZ1's arrived today. Fast shipping, great packaging! Thank you.

-Brian

Reply to
Brian Dean

Just an FYI - most folks would consider it bad form to hijack someone elses new product announcement with announcements of a similar product of your own. You should create a new thread instead.

-Brian

Reply to
Brian Dean

Maybe not if it makes the original product look better.

Mitch

Reply to
Mitch Berkson

When I connect to the PC I have a 1K resistor in series with the (PIC/MaxSonar-EZ1) TX output. From the PC, then I use a 10K in series to the RX input. This prevents any surprises & smoke. Again, maybe not recommended, but I have used it for years for debuging.

Bob Gross

Reply to
Bob (Robot Wars Thumper 1997)

We have the spec and have been reading it recently to support efforts on a project. You are correct, the RS232 spec only specifies voltages and signal names/uses. That's all. No protocols. Originally the spec was written to support communication between two devices, each using a modem. So, back then, you did not connect a PC and a printer or a PC to another PC, it was a terminal (DTE) to a modem (DCE), on each end of a dial up or leased (analog) line. This explains a lot of the signals and their naming conventions, which don't particularly make sense now between non-modem devices, using digital (non-carrier) links. So the RTS/CTS and DTR/DSR handshake lines were originally developed for and intended for communication over a modem connection. Since that time they have been commonly abused as hardware flow control (something never contemplated in the RS232 spec) to the point that there are "de facto" standards for such use, and such use/abuse is now more common than the original modem use.

There are also some newer versions of the spec which do allow for hardware flow control, but I'm not sure we have the official document for that.

Regards Bruce Boyes

Reply to
bboyes

My questions have been answered, and I think you have a good product for the money.

I just placed an order, and will be using it as soon as possible.

-- D. Jay Newman

formatting link

Reply to
D. Jay Newman

Received them, tried them out - they work quite well, just as advertised. A couple of observations:

- On an acoustically soft object (my stomach, actually), the maximum range seems to be around 10-12 feet or so. This isn't at odds with the published specifications, since the 20 foot range was measured with a hard, wide, and flat board, but it's still a little lower than I would have expected (considering the large size of the object being ranged).

- I was able to hook the 5V TTL output directly to the serial port of a computer and get good communications. However, sometimes it would be nice to have the serial output inverted, as is the standard (sort of) for TTL-level serial. This way, it could be connected directly to a MAX-232 to generate official RS-232 serial, or directly to the UART input pins of most microcontrollers, without requiring an inverter. I suspect that Mr. Gross must have considered this output carefully, and certainly the way it is now has its positive features. Another single-chip product that I use dedicates an extra input pin to selecting normal or inverted serial output; perhaps this could be a future option (a jumper or solder bridge on pin 9 of the PIC, possibly).

Without exception, though, I'm quite happy with the product - it really couldn't be easier to use, and its small size and exceptionally low power consumption are great. I believe that the price is quite good, too.

-- Mark "I prefer heaven for climate, hell for company."

Reply to
Mark Moulding

All, Thanks for the discussion. Your comments are greatly appreciated.

Please let me ask a question. I have been working in a vacuum since mid 2004 when I asked a couple of distributors a few questions. (I have some strong evidence that some of my questions made it back to my competitors and none of them were answered.) Now with a product, I am more comfortable asking a few questions.

First, the product is reliable at ranging 6-inches and beyond and detecting objects closer than 6-inches. I like very reliable readings, as then I can depend on them.

I understand that people using sonar sensors have come to expect unreliable readings from sonar sensors so this question may be hard to answer from my perspective. We are running into physics anomalies, like may happen with very small objects, or at precise distances where the wave front phasing causes detection anomalies. These anomalies are hard to sort from ring down (i.e. mV of signal upon volts of ringdown). In addition, detection anomalies only occurring at two ranges (i.e.

4-inches and 5-inches) might be confused with the unstable readings that the competitor's sensors have.

This said, would people also like to have ranging at 5-inches with 90% reliability, and 4-inches with about 80% reliability? The product would still keep the current ability to reliably range objects 6-inches and beyond, but may have a little trouble getting perfectly stable readings at 4 and 5 inches, but most of the time, the readings would be correct. What users might see is a bouncing of readings between

4-inches and 5-inches or between 4-inches and 6-inches, or between 5-inches and 6-inches. In addition, people could still get the same reliability for all readings if they used logic of 6-inches or less means object is detected. And if I provided these outputs, would I be able to educate the people as to why this happens (and fight the current expectation that readings are unreliable)?

Again, my problem here is not that the MaxSonar-EZ1 cannot do this (4-5in.) task reasonably OK, it is that people have come to expect unstable readings, and yet with the MaxSonar-EZ1 readings are stable. Remember I want to be separated from the competitors where unstable readings are expected. Any comments?

Reply to
Bob (Robot Wars Thumper 1997)

All, What I failed to mention is that the object being detected would be at say 2-inches and might be reported at 4, 5, or 6 inches sometimes (with propabilities stated above). Objects at 4, 5, or 6 inches would much more likely be reported correctly. So the problem mostly has to do with objects closer than 4-inches being reported as 4,.5, or 6. Initial feedback (direct and not from this group) mention to just leave at 6-inches. Feedback wellcome. Bob

Reply to
Bob (Robot Wars Thumper 1997)

All, I have update the FAQ to include the human body distance stuff. I do not want to suprise anyone. Bob

Reply to
Bob (Robot Wars Thumper 1997)

RS232 I actually wanted the sensor to directly interface to a PC without any chip. I thought the guys that really wanted full level RS232 one would be able to easily work around the polarity issue. When one makes it an EZ1 then one must limit the options or then it isn't easy any more. My Keil C-compiler has over 2000 pages of documentation. I want only two pages of datasheet and a user manual that covers the various questions.

Right now the product is set up to be compatible with serial LCD displays and most micro controllers. (The 8051 variants I use require the output format currently used unless I use a level shifter or an inverter. For short runs to a micro controller I am not sure that the noise immunity is needed.) It can also interface with a PC and this has worked well for me. I have wanted to put some things up on the web (time permitting) and show people how to connect it to hyper terminal or stamp plot (provides a very cool looking graphical output) without the inverter chip. The connection to a PC using this method is meant mainly for hobbyist types or occasional debugging.

I can understand that your needs may be different (require high EMI immunity) or you may have a long run to the sensor. I felt for the first product, that the current RS232 output option, would make it the easiest to use for the person just starting out in robotics. I may be wrong. Your desire to have the other output polarity as an option, is noted.

How can I get around this? I do have an unused pin that can be used. Is this really the best use for this pin? Maybe it is for this first offering? Comments please.

You guys have been very kind to me and this product offering. Thank-you so very much.

Reply to
Bob (Robot Wars Thumper 1997)

I just got it. Now all I need is to have the time to put it on a robot. Not to mention a bit of example code.

Can you use multiple units together?

-- D. Jay Newman

formatting link

Reply to
D. Jay Newman

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.