Updated MaxSonar-EZ1 Datasheet and Updated Website

All, The updated web site is at www.maxbotix.com and the updated MaxSonar-EZ1 datasheet is available http://www.maxbotix.com/uploads/MaxSonar-EZ1-Datasheet.pdf The main changes were in the serial description, but changes also occurred in the current draw (2mA nominal, instead of < 3mA), 48mS changed to 49mS, one percent timing accuracy changed to two percent, and the calibration of the ring down is explained more clearly. To tell if you have the new data sheet date look at the bottom of each page. The new data sheet date is 01/2006 and the old one is 10/2005.
Thanks again for the critical review!
Bob

  Quoted Text Here  
Bob, I'm disappointed the serial issue is still not resolved. No one can tell if your serial out is compatible with normal TTL UARTS, or is compatible with an inverted TTL accidentally compatible (by inversion but not voltage levels) with RS232 (which if done will cause the micros to eventually burn out from application from negative voltage from the RS232.)When such simple concepts are so confused, it makes all claims highly suspect.

Randy, I am sorry that you are disappointed. What is not clear? If it is not clear, I would like to make it so. (Anyone else, please feel free to jump in.)
Please help me as it is the user's/customer's best interest and my best interest to resolve this. I am doing this in the open so I am not trying to hide anything : ).
The TX output is being discussed. The section below has been pulled directly from the datasheet.
"TX - Delivers asynchronous serial with an RS232 format, except voltages are 0-5V. The output is an ASCII capital "R", followed by three ASCII character digits representing the range in inches up to a maximum of 255, followed by a carriage return (ASCII 13). The baud rate is 9600, 8 bits, no parity, not inverted, with one stop bit. Although the voltage of 0-5 V is outside the RS232 standard, most RS232 devices have sufficient margin to read 0-5V serial data. If standard voltage level RS232 is desired, invert, and connect an RS232 converter such as a MAX232."
Now lets break this apart. We can discuss one sentence at a time. "TX - Delivers asynchronous serial with an RS232 format, except voltages are 0-5V. " So the format is RS232 format except for the voltages. Is this clear here?
"The output is an ASCII capital "R", followed by three ASCII character digits representing the range in inches up to a maximum of 255, followed by a carriage return (ASCII 13). " So the output is ASCII such as R255 followed by an (ASCII 13).
"The baud rate is 9600, 8 bits, no parity, not inverted, with one stop bit." So, is this is described ok? But the next statement states that except for the voltage, levels it is compatible with the standard RS232 standard. In addition, above the voltages are stated as 0-5V. So I am not sure what is missing?
"Although the voltage of 0-5 V is outside the RS232 standard, most RS232 devices have sufficient margin to read 0-5V serial data." I am not sure that the above sentence could be more clear? The 0 to 5V outputs to the receiver on the users application. At no time is high voltage level RS232 being applied to the MaxSonar-EZ1, and the MaxSonar-EZ1 does not output high voltage levels so burnout is not possible at either end. (It appears that you might be mixing the RX function with the TX function.)
"If standard voltage level RS232 is desired, invert, and connect an RS232 converter such as a MAX232." The above statement appears very clear as states that must first invert the output and then connect to a MAX232.
As for the rest of the product, being suspect, any and all comments from customers have been evaluated. When anything is found, the data sheet or FAQ is changed. You will find that this data sheet is as good as it can be and will change as needed to more perfectly represent this product.
And the RS232 issue never came up with any users, (only on this group, yet I can see that it could be a problem so I am working it) and many have connected to a PC and it has worked very well. I do not guarantee this operation, but I have personally used PIC is this way (makes it easy to debug the operation while programming : ) for years and I have found it works very well. I made a decision to keep the sensor cost very low and very small and I did not want to increase the cost or the size just to add full level RS232 voltage levels. Maybe in an another product...
I have even received phone calls from technical users evaluating the sensor connected to a PC in this manner (yes, using the "non standard RS232), and they really could not believe that the stability and the narrow beam were possible except they were seeing it with there own eyes? To me this is the best complement I could possibly receive. There are always things to improve and the real issue is whether these are bushed under the rug or laid on the table and worked on. I really am the kind of person who will correct these things and if not possible to correct then disclose the area.
I personally really believe in this product! I really believe it is the best available, and it is low cost. It works very well, is very small (I believe smaller that the "worlds smallest" esp. when mounting is considered), requires very low power (currently the industry's lowest), exceptional beam quality, and a very easy to use user interface (just choose the one you desire)...
Bob Gross
Randy M. Dumse wrote:
  Quoted Text Here  

Bob -
I guess I'll chirp in here, also.
I sent you an e-mail previously also commenting on the serial interface. My concern is not so much the direct connection to an external "real" RS232 interface (a PC COM port, etc.) but, rather, direct connection to another TTL level device. In this case the serial interface baud packets are inverted, requiring an external inverter (or intelligent inversion upon reception by the receiving device) to obtain a true, compatible, standard definition of the serial packet.
The standard RS232 specification defines the "valid" mark to be between -3 and -25VDC, the "valid" space to be between +3 and +25 VDC, and the region between -3 and +3VDC to be a no-mans-land. If, as you state below, "most RS232 devices have sufficient margin to read 0-5V serial data", at the very least it is certainly not good design practice. If it works in one application, it may or may not work in another application... even with the same vendor.
I would have preferred to see the serial interface baud packets defined in the standard TTL polarities. Then (if you wanted to), an external TTL-to-RS232 interface chip (a MAX232, etc.) could have been used to convert the voltage levels approproately without the need of an external inverter. Alternatively, if TTL connections were desired to another device, it could be wired directly, also with no need of an external inverter. An external inverter can be as simple as an N-channel MOSFET and two resistors, so it's not a big deal to add to any circuit (very small PC board space) but it's even simpler to do in code within the PIC.
With all the being said, I still believe this is one of the best ultrasonic solutions I've seen to date. I still plan on using it in my applications.
...maybe the next generation could have a jumper for output polarity? :)
Dave
  Quoted Text Here  

Also, how about on on-board voltage regulator so the device could say run off a 9 V battery ?
On Sat, 21 Jan 2006 13:11:33 -0700, "Dave" <starfire151 AT cableone DOT net> wrote:
  Quoted Text Here  

Bob (Robot Wars Thumper 1997) wrote:
  Quoted Text Here  
[snip]
Bob:
Thanks for inviting feedback.
All microcontrollers that implement asynchronous serial communication in hardware (i.e. UART, USART, etc.) implement it such that line idles at +5V (not 0V). The start bit is 0V, and the data is non-inverted (i.e. a 0 bit is sent at 0V and a 1 bit is sent as 5V.) The stop bit is 5V.
If you used a 0-5 volt signaling that is compatible with all other microcontrollers, we could hook it up directly to the micrcontroller UART without the pesky inverter. There are oodles of "stamp" like microcontrollers that have the ability to bit bang on any one of their I/O pins using the standard voltage levels.
The problem with your strategy of hooking directly to a PC is that most PC's only have one or two serial ports. We usually wind up plugging a microcontroller into the serial port (through a MAX232) and then have that microcontroller talk to everything else. If we plug your sonar into our only serial port, we have no way to control the rest of the robot.
In summary, you've optimized for the wrong case. We want your nifty new sonar to talk directly to a microcontroller without an inverter rather than to a PC without a MAX232. For us robot builders, being able to easily hook up to a microtroller is far more useful than being able to easily hook up to a PC.
My $.02,
-Wayne

Just to chip in my $.02 ..
Exactly what Randy, Wayne, and Dave said.
Mike
  Quoted Text Here  

All, First, there is a group of people that are not in this discussion. These are the ones that have used the *serial interface as it is. As the serial interface stands I designed this to talk to a PC and basic stamp type microcontrollers. The BX-24p, the basic stamp, the Basic Atom and PCs have all been tried, and have no trouble. To help people that are still trying to understand, I will post a Basic Stamp code example very soon, as well as PC Hyper terminal, and PC stamp plot examples. From your response, I also understand that the datasheet, as it currently stands, describes the serial interface well.
Second, what I gather is that most of you in this discussion would have preferred the ability to connect to the MAX232 without an inverter. (But to this group of technical people, who know what a MAX232 is, the use of an external inverter is a viable option.)
So I have people that desire each serial type (inverted or not inverted). The product is set up to stratify only one group. I will try to have the other option available soon. No commitments as of yet, as there is a lot of product in the pipeline!
And please remember that the analog voltage output and the pulse width output are options as well.
Bob Gross
*(FYI. In general, a PC's RS232 thresholds are about 0.7V, so the 0V works very well for short runs. The PIC can source 20 mA so it has no trouble holding it below 0.7V. At 9600 baud, speed is not an issue either.)

Bob (Robot Wars Thumper 1997) wrote:
  Quoted Text Here  
I think that is because most of the people are using your device as-is, connected to a microcontroller.
You can get a trivial RS232 <-> TTL tranceiver for $10-$20 bucks. I would check Spark Fun (http://www.sparkfun.com/).
  Quoted Text Here  
To make things easier on you, I would suggest that you either resell an exterior converter for those who want one, or make one of your own. This keeps the main sensor cheaper.
And frankly I don't see many people actually using this directly from a PC. Using it this way limits it to the number of serial ports on the PC. This is why I like multi-drop systems like RS485, I2C, and SPI.
  Quoted Text Here  
Yes. However, analog voltage is subject to other sources of error when being read by the other microcontroller.
The pulse-width works but is subject to the timer on the other microcontroller.
I would like something where I could have 10-20 of these devices on a simple network.
As is, to connect them to an RS485 network I have to put an add-on device to each and every sensor. I think I can get this to under $10 per unit if I try hard enough.
  Quoted Text Here  
*Which* PC? Older PCs tend to stick with the RS232 electrical standards. Newer PCs tend to be sloppier.
And a point which cannot be repeated enough: the RS232 standard is purely an *electrical* standard. It says *nothing* about what is transmitted. It defines voltage levels for 0's and 1's and defines the connectors. That's it!
Async serial is a protocol that can be sent via any method that has 0's and 1's. I could transmit it via smoke signals if I wanted to.

  Quoted Text Here  
Agreed, most will use this with a microcontroller. If the microcontroller/compiler supports software uarts, you can connect several of the sensors via 1 I/O line per sensor defined as a serial input. The other option is to use the SPI-style of control using a I/O line for each sensor (connected to the RX line of the Maxsonar-EZ1) and one for reading the serial data. In that manner, you control 4 sensor with 1 serial line and 4 GPIO lines.
The hardware UART in the AVRs doesn't support inverted serial, so I would either have to use an inverter (1 NPN, 2 resistors) or use a software uart that does support it. Bascom, basic compiler for AVRs, does have a software uart routine that supported inverted input.
The output being inverted isn't a big deal to me. I understand the concern around connecting the MaxSonar directly to a PC's serial port. You may want to include a big red warning message in the datasheet about the risk involved.
Having a jumper on the board to select inverted or non-inverted output would be a nice touch though... BW isn't used right now, right (hint, hint)?
I've been playing with the sensor over the last week and I'm impressed with it's abilities. It does a great job with small objects. I'm testing it with a 1/4" square piece of wood and it finds it consistently.
Thanks! Eddy Wright Wright Hobbies Robotics http://www.wrighthobbies.net

Eddy Wright wrote:
  Quoted Text Here  
While the creator of this device seems to be a superb engineer, he made a lot of text mistakes.
TTL-level asynchronous serial communications is supposed to be inverted (0V = 1, 5V = 0). If the device can connect with a BASIC Stamp, it can connect with pretty much anything that uses TTL-level asynch serial.
Unfortunately I haven't had a chance to test it myself because my shop is being reconstructed right now and my wife won't allow me to use a soldering iron upstairs. :( -- D. Jay Newman http://enerd.ws/robots /

  Quoted Text Here  
Jay, you might want to check the statement there again. As written it says exactly what Bob says, and I an rather certain it is wrong. It should be:
TTL-level asynchronous serial communications is supposed to be non-inverted (0V = 0, 5V = 1). RS-232C-level asynchronous serial communications is supposed to be inverted (+15V to +3V = 0, -3 to -15V 1). If you'll notice on a driver data sheet, such as 1488, MAX232, or 145406 (hard to find these days see:) http://pdfserv.maxim-ic.com/en/ds/MAX220-MAX249.pdf that all these drivers show a bubble after the buffer signal, both on their transmitters and their receivers.
The bubble means inverter.
In this regard I am agreeing with Wayne. The inversion is in the RS232 buffer, and should not be claimed to be what normally comes out of UARTs.

Randy M. Dumse wrote:
  Quoted Text Here  
The *definition* of RS-232 is that a voltage less than -3 volts corresponds to a logical "1" and a voltage greater than 3 volts corresponds to a "0". The definition is not open to discussion.
Since a MAX232 level converter takes 5V <=> -12V and 0V <=> 12V, it is technically a buffer, not an inverter.
RS232 communication is *not* inverted. A "1" in your data is represented as a correct RS-232 "1" (i.e. -12V)
  Quoted Text Here  
The bubble does indeed mean inversion and I would argue that placement of the bubble in the spec. sheet is in fact incorrect. Mind you, I am a hypocrite on this topic, since all my schematics that use the MAX232 have the bubbles in them.
  Quoted Text Here  
Let me reiterate, as far as I am concerned, the MAX232 buffer is in fact a valid voltage level shifter that does not invert the data as it goes through.
-Wayne

  Quoted Text Here  
Agreed. Added though, RS232A limited maximum excursions to +25 and -25 as well.RS232C limited maximum excursions to +15 and -15 as well.
But yes, I agree, fr RS-232, a -3V (to something depending on spec of choice) is a logical "1".
  Quoted Text Here  
I disagree. It is not a buffer, per sa. And I will even say it is not an inverting buffer or a non-inverting buffer, both of which terms are used. For proof I offer the 74HC240, which you will find is classified as an octal Buffer / line driver; 3-state inverting.
http://www.semiconductors.philips.com/pip/74HC240.html
as opposed to say at 74HC244, which you will find is classified as an octal buffer / line driver; 3-state (non-inverting).
http://www.semiconductors.philips.com/pip/74HC240.html
A MAX232 is a level shifter. And I would also argue it is an inverting level shifter. I do so based on manufacturer's data sheets.
  Quoted Text Here  
While I can see your point, something with a logical 1 where it should be might not be inverted, I think you are focusing on final interpretation of the signal, and ignoring the view point of the driver which has no preset knowlege of what is a 0 or a 1 and only does the level shifting. Well, we could get into relativity theory, because something cannot be inverted by itself, but must be inverted relative to something else. Therefore RS-232 is not inverted compared to RS-232. It is however inverted compared to TTL synchronous serial, and vice versa.
  Quoted Text Here  
I think the bubble is correct, and possibly this argument might change your position and "hypocracy" back to orthodoxy.
  Quoted Text Here  
Here's looking into the link to the MAX drivers of the last post. http://pdfserv.maxim-ic.com/en/ds/MAX220-MAX249.pdf RS-232 Drivers
The typical driver output voltage swing is ±8V whenloaded with a nominal 5k? RS-232 receiver and VCC = +5V. Output swing is guaranteed to meet the EIA/TIA-232E and V.28 specification, which calls for ±5V minimum driver output levels under worst-case conditions. These include a minimum 3k? load, VCC = +4.5V, and maximum operating temperature. Unloaded driver output voltage ranges from (V+ -1.3V) to (V- +0.5V).
Input thresholds are both TTL and CMOS compatible. The inputs of unused drivers can be left unconnected since 400k? input pull-up resistors to VCC are built in (except for the MAX220). The pull-up resistors force the outputs of unused drivers low because all drivers invert.
Now what about the receivers.
RS-232 Receivers
EIA/TIA-232E and V.28 specifications define a voltage level greater than 3V as a logic 0, so all receivers invert.
I think it is important to remember it would be possible to make a non-inverting chip that shifted to the same (if opposite) levels. I don't know of any, but it would be possible. So the one made for RS-232 conversion is the inverting one (electrically, not logically), and should remain being called one, just as the manufacturer does, and the schematics show (bubble on output).

Randy M. Dumse wrote:
  Quoted Text Here  
Agreed.
There are inverting buffers and non-inverting buffers. When the term "buffer" is used without the preceeding word "inverting" or "non-inverting", it means "non-inverting". My sentence would have been clearer if I had written "... it is technically a non-inverting buffer, not an inverting buffer".
  Quoted Text Here  
Nope. I'm not buying into your argument.
Is RS-485 inverted? How about current-loop? How about CAN? FSK (Frequency Shift Keying)? What matters is that I shove a "1" (5V) or "0" (0V) into the driver and the corresponding receiver returns the same "1" or "0". I should be able to make an entire matrix of drivers and receivers that convert between 0-5V, RS232, RS245, CAN, current loop, etc. I can chain them all together in whatever sequence I want (e.g. 0-5V => RS2323 => current_loop => RS285 => CAN => 0-5V) and when I shove a "1" in front of the chain, a "1" comes out the back. If I shove a "1" in one end and a "0" comes out the other end, somebody has inverted the data.
[snip lots of text]
In the end, I'm still a hypocrite, since I shove a "1" (5V) into the MAX232 and it spits out a valid RS-232 "1" (-12V). No inversion of the data has occured. I still have bubbles on my MAX232, primarily because the spec. sheets have bubbles. They really do not belong there.
-Wayne

Randy M. Dumse wrote:
  Quoted Text Here  
with Randy on this.
Micro hardware to Micro hardware - logic unchanged. Micro hardware to PC via a level shifter - logic unchanged. Micro hardware to PC via current limiting resistors - logic inverted. With a basic stamp you need to use 'inverted' mode if you don't use a level shifter.
They only reference that I am aware that uses 'inverted' is the ISO 7816 smart card standard which uses 'regular convention' and 'inverse convention' reflecting the above.

Here's an excerpt from a post I made a couple of weeks ago, right after receiving and playing with a couple of these units:
  Quoted Text Here  
My experience with the device is that it works very well, is stable, low power, and inexpensive. The *only* niggle I have with it is the serial output. For most of my applications, I'll just bit-bang the serial reception anyway, so it's not a big deal - most of the time... -- Mark "I prefer heaven for climate, hell for company."

Bob, I was one who first applauded the RS232 output, and I still do for a product like this, but as the others have mentioned, the "RS232" you're talking about seems to me a boatload of support issues just waiting to happen. I'd use another term in your data sheet than RS232 if, in fact, you are not providing support for the traditional voltages as used on a PC. That's what I thought you were talking about in your first post.
As to why support RS232 at all: there are valid reasons for this, in and out of robotics. But foremost is the ability of first-time learners to experiment with ultrasonic sensors using computing platforms they are most familiar with. All it takes is some simple Visual Basic to create a fairly sophisticated application for testing how ultrasonic sensors work. Microcontrollers are ideal for an end-project, but they can get in the way for those just starting out. It's another layer of complexity.
Given the pricepoint I'd say it's probably best to just offer an off-board adapter, as Jay suggests, or provide a generic circuit around something like the MAX232 chip (so you know it'll work 99.9999% of the time with any set of hardware). If you plan on other products with TTL serial outputs then maybe your adapter can be common to all of them.
I do know Scott Edwards has, for many years, sold a successful serial servo controller that can be commanded from a TTL microcontroller serial line or from a PC. You might look into how he's doing it, both on a technical level, and on a marketing level. The spec sheet does say the serial output is "RS-232, or inverted TTL," thought note the product is serial in only.
-- Gordon

Gordon, Without a full press release, I have already sold 100s of these in less than one month!
I am just trying to get the data sheet issues ironed out before I do a full press release. From posts on this group, it is clear that everyone does not agree as to the correct way to state this stuff. This is especially true when discussing whether a serial output is inverted or not.
The serial output is directly compatible with the Scott Edwards serial input LCDs. (I use one of his LCDs in the production test fixture.)
The MaxSonar-EZ1 was designed to directly connect to a PC, yet with the reduced (but tested adequate) voltage levels. (If people have trouble, I even let them know how to correct for this with an inverter and a MAX232.) This yields a low cost workable solution for most, yet when needed, people can add the two external chips.
Many people have tried the serial output from the MaxSonar-EZ1 to directly connect to a PC. I have heard many positive reports. I have not yet heard a negative report from someone that has actually tried it.
Many distributors have used this output to evaluate to product. Would I have provided this same polarity output today, with this last month's history complaining about this? Yes! (Hindsight states that I might have also designed in the ability to switch to the other polarity...)
I am hoping to at least get the datasheet to correctly represent what I currently have. When I released the product, I thought the datasheet was OK. But because of this group's comments I have pulled every reference to RS232 from the web site and data sheet, except one place, where I believe that it is still needed for clarity when talking to the general population. (I have heard this from many reliable sources and I will leave it in.) I have made the TX discussion at least twice as long and some people are still having trouble with it. I have called engineers and asked them to be critical, and they have had no trouble with the datasheet description. They have recommended that I provide the other output polarity as well, because of the posts on this group. (Hindsight 20/20) This will be worked as time permits.
As for providing high level RS232 voltage levels, the MAX232 or MAX 233 can do this just fine. Just invert the output from the MaxSonar-EZ1 and supply it to either of these chips and you can get full level RS232 in the standard serial format.
And as for the other polarity of TTL level serial, I will work this...
Yes I am still having fun in robotics!
Bob Gross

  Quoted Text Here  
Well, there is some electrical danger in using the TX line directly from a micros pin. Micros are very sensitive to over voltage and undervoltage. Particularly undervoltage. If you take a pin for a level lower than -.7V, you will usually destroy the microprocessor. Generally an RS232 input will be passive. But there's nothing saying it can't have a pull down, or leakage, to -12 volts.
However, it is very common when messing with RS232 ports to not know if the port is DTE or DSE and when first plugging in trying to establish communications to get the outputs wired together and the inputs wired together. In this case, hooking a micro TX line to the RS232 TX line at -12V is very likely to destroy the micro.
So with caution, using a TTL level output, and an inverted state, you can get by driving an RS232 receiver. But you are flirting with disaster. Some percentage of customers are likely to have their new products damaged before they ever get them working.
Now, the product also has an RX line. If this is directly hooked to an RS232 TX output signal, then a killing voltage is sitting on the micro pin, whether the TX is electrically high or low (at normal RS232 levels).
  Quoted Text Here  
No.
RS232 is an electrical specification. It is not a "format". So your statement above meaningless, if not misleading.
For analogy, someone might say, My new airplane has a +/-12V electrical system except its 0-5V. It either makes no sense at all, or at best is very confusing.
So is the -12V connections on that airplane goes to the 0V line, and the +12V connections goes to the 5V line, or does the +12V and 0V go together and the 5V and -12V go together? There's a 50/50 chance. But there's not enough information to hook up anything electrical yet.
  Quoted Text Here  
No.
It's not described ok, because you say "not inverted" which is a direct contradiction to the claim it will work with an RS232.
It is either inverted and therefore can marginally work with an RS232 receiver input, or it is not inverted, which means it can work with a normal TTL UART. But it can't be both at the same time. Which it is depends on the code in the micro, and is invisible to anyone outside the design. So either it has to be stated clearly and unambigously by the designer/programmer, or determined by experiment. Leaving such a thing to chance, is why I said I was disappointed, because it is not clear.
  Quoted Text Here  
I'm not sure... maybe
The inversion.
The danger of destroying the micro.
The kludge-like inadequacy of the inappropriately chosen design.
The marginal interface to PC's, and the difficulty to interface to Stamps, or other non-PC, non-RS232 apps, which are probably the majority of applications for the sonar.
Ultimately, since you're the one profiting off of this, it is in your best interest to figure out what you're missing, and the customer's best interest to raise an eyebrow of caution until you do. Particularly given your comment you don't guarantee this circuit will work. Are you saying you will not replace anyone's product lost due to using this interface you've suggested? Bad business, me thinks.
You might have something pretty nifty here, but no one can be sure, until issues like this are resolved.