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
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 M. Dumse
Caution: Objects in mirror are more confused than they appear.
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:
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
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:
[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
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.)
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/).
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.
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
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 /
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.
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.
-Wayne
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".
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.
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.
I think the bubble is correct, and possibly this argument might change
your position and "hypocracy" back to orthodoxy.
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
Caution: Objects in mirror are more confused than they appear.
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".
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
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:
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
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).
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.
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.
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.
--
Randy M. Dumse
Caution: Objects in mirror are more confused than they appear.
Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here.
All logos and trade names are the property of their respective owners.