and the updated MaxSonar-EZ1 datasheet is available
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.
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)...
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? :)
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.
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).
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.
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.
I'm not sure... maybe
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.
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.
*(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.)
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
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.
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.
*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.
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.
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.
All, I really want to get the data sheet correct, please : ).
So from your response, I will change the data sheet to state "inverted" instead of "not inverted". Is this what you are stating? But when I go on to state that one must invert before connecting to a MAX232, that is clear to you guys, correct? Please, no double talk.
The ability to interface to stamps is a no brainer! To state that the MaxSoanr-EZ1 has any trouble interfacing with stamps, is just not true. Stamps like the 0 to 5V serial inverted or not. Have you ever used stamps for serial input? Nothing is easier! Nothing!
The Basic Stamp Manual 1.8, page 319, states "Serout through the I/O pins is limited to logic-level voltages of 0V and 5V; however, most RS232 devices are designed with sufficient leeway to accept logic-level Serout Transmissions, provided they are inverted.." (The stamps use a PIC with 20mA drive capability just like my product.)
You know, I read the above statement in the mid 1990s and I have used it ever since, without any trouble. This is on XT, 286, 386, 486, Pentium, and more. I have used only 9600 baud and it has always worked. I have built it into many systems (Ouch!) and these have always worked! (Are you saying you tried the MaxSonar-EZ1 output and it didn't work? Didn't another post already state that it worked? Not sure how much you are getting from pushing this?) I have years of history of this serial interface working.
As for connecting it up wrong. If you connect it up to the wrong pin, I am very sorry, but I do not recommend this : ). Again, are you stating it didn't work for you? Did you connect it up wrong?
I mention RS232 format (but state 0-5V) because many programming languages and application notes refer to serial as RS232. Again, I make sure to separate myself from this Recommended Standard (RS) by stating 0-5V. My understanding of this Recommended Standard, is just that, a Recommended Standard, but if you deviate, you must let people know. So this is what I did.
So blast Parallax if you want. Blast my personal experience if you want. But I am really just trying to get the data sheet and the web site accurate. This is a new product release and it has been very well received! The performance/price is unmatched! In addition, I am working to accommodate the other polarity soon. (I currently have
1000s in WIP. This is to keep the costs very low to the end user. I really am truing to keep the profits low so you guys get a good deal! Because of the volume, correcting this is not easy.)
So, I do hear you guys. I do know that you would like the other polarity. But first, my customers and I really need to have an accurate data sheet (and follow this with an accurate user manual) to correctly represent what I have. Then when this is ironed out, I really do plan to accommodate the other polarity.
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...
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. :(
All, I am working to fully flush out the data sheet for the MaxSonar-EZ1.
now, it has been confusing for some people. The reason for this is that while the MaxSonar-EZ1 serial 0-5V output is not inverted, most serial 0-5V outputs are inverted. (The reason that the 0-5V outputs are inverted, is so that they can be inverted again, when the are brought up to full RS232 voltage levels.) (I may still change the datasheet further, but I am not sure exactly what wording to change, as of yet. I am trying to iron this out.)
When I was designing the MaxSonar-EZ1, I was using these three controllers to test out my product Basic Stamp, BasicX, and BasicAtom. These all work fine with the MaxSonar-EZ1 serial and pulse width interfaces. In addition, the micros with analog to digital converters function well with the MaxSonar-EZ1 analog output.
In addition I used various PCs. This 0-5V connection to the PC has been tested and works well, but it is outside of the recommended standard. To those that would like (or require) full levels, please invert the output, and use a MAX232 or MAX233. So the people that like the PC interface are not complaining and I have received reports that this is how they evaluated the product and that they really like this interface.
Since the products release, I have learned that some microcontroller serial interfaces require the serial to be inverted when at the 0 to 5V levels (some 8051s, some AVRs, etc.). The hardware on these micro's (serial UART) actually require the inverted 0-5V, and this is why the complaints are happening. Again this is easily solved with an external inverter.
I know that this product is under priced when compared to the competition, so I could take the loss now, and change the product, and increase the price to everyone to cover the losses. I hate price increases!
I do not want to drive the costs up by having to change this product mid stream. I will eventually have to make some profit to keep this product on the market. (At the current sales rate and margins, it would be over one year before I make a profit with the product as it now stands.) So, I would like to continue to offer this product at the current good deal. This is good for the robotics community.
For you that would like the inverted serial output, when the inverted serial output can also be included in the product, I will include this.
For you guys that have not looked at the actual product, and have only read the discussions about the serial interface, please have a look. The product is the next leap forward in ultrasonic range finder technology.
I think you are still a little confused about what is inverted or not. First, in 0-5V electical levels, 0V = 0 = L and 5V = 1 = H. When a UART shifts the data out is, it is *not* inverted. When the character 'C' = 0100 0011 is transmitted it is transmitted as follows:
What: I I I I S 0 1 2 3 4 5 6 7 P I I I I I Data: 1 1 1 1 0 1 1 0 0 0 0 1 0 1 1 1 1 1 1 Voltage: 5 5 5 5 0 5 5 0 0 0 0 5 0 5 5 5 5 5 5 RS232C: - - - - + - - + + + + - + - - - - - -
Where I = line idle, S = start bit, 0-7 = data bits, P = stop bit,
= +12 volts. The data byte is shifted out least significant bit first and it is *not* inverted. A 1 in the byte is represented as 5 volts. If a 1 bit in your data is represented as 5V on the output pin, it is non-inverted (i.e. true). Conversely, if a 1 bit in your data is represented as 0V on your output pin, the data is inverted.
Since your product is representing a 1 in the data as 0V and a 0 in the data as 5V, your product is currently using *inverted* signalling. Period. Full stop. End of discussion.
Next, I am not aware of any hardware UART constructed in the past
30 years that uses *inverted* signalling. All of them use non-inverted signalling. I would be interested if you can identify
*any* hardware UART that uses inverted signalling.
Nice try, but the PIC16F676 that you use does not have a hardware UART, so you must be bit banging the serial output out in software. It should be trivial to go into your software and invert the bit. No PCB changes are required, just software. You can sell two versions of the product, the current one with *inverted* data, and one with *non-inverted* data.
The people on this list have overwhelmingly said that they want
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)
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.
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.
There are some micros that have bit settings to allow inverted input, but not all, or even most, can handle and inverted output.
And I still hold, while an inverted output can often work with RS232 recievers, it should be avoided as a "potentially product-killing accident waiting to happen" design.
I don't know if the Stamps use inverted, non-inverted serial, or selectable settings. If someone knows for certain, I'd be curious to know. Most of the micros I produce do not accept inverted inputs. In the case of our software serials, I guess we could mod them to accept inverted serial, but it seems like a step backwards to me.
As you say, it's Bob's choice what he wants to sell, and we have no say. I think he made the worse of two choices, but that's his perogative. But when the nomenclature is used abused or wrong, confusing the public, (bad thing, and even legally actionable, if customers have losses) as it has been about what is inverted and non-inverted, I think it is important to try to eliminate the confusion from the public forums.