Updated MaxSonar-EZ1 Datasheet and Updated Website

I've never seen them. Can you name a couple?
No argument from me. For me, I will either do RS232 right or not at all.
Parallax Stamps can bit-bang serial data in both inverted and non-inverted mode. The Parallax Javelin can do the same. The OOPIC can also do both inverted and non-inverted. The OOPIC also allow you to hook up to the on-board hardware UART, and that is non-inverted (of course!) I suspect that the BSX24 and ATOM can do both as well.
One of my close friends has used the Parallax Basic Stamp in bunch of robots and he has talked with many modules using serial protocol and never had to use Stamp's the ability to invert the data.
Agreed.
The serial communication protocols evolved over time and they can be quite confusing. For example, why did the RS232 folks choose -12V for "1" and not +12V? They did and we've had to live with the confusion ever since.
At least Bob asked for feedback and he has been willing to *listen* to the feedback. No complaints from me on that aspect. Hopefully, some other people are reading this thread and it is helping them understand serial communication protocols a little better.
-Wayne
Reply to
Wayne C. Gramlich
Loading thread data ...
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.
formatting link
as opposed to say at 74HC244, which you will find is classified as an octal buffer / line driver; 3-state (non-inverting).
formatting link
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.
formatting link
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).
Reply to
Randy M. Dumse
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
Reply to
Wayne C. Gramlich
Well, a series at least. The DSP56xxx in our 'Pod's line of micros have a POL polarity bit. From the DSP56F801-7UM.pdf manual:
12.6.2.6 Polarity (POL)-Bit 10
This bit determines whether to invert the data as it goes from the transmitter to the TXD pin and
from the RXD pin to the receiver. All bits, START, DATA, and STOP, are inverted as they leave
the Transmit Shift register and before they enter the Receive Shift register.
. 0 = Doesn't invert transmit and receive data bits (Normal mode)
. 1 = Invert transmit and receive data bits (Inverted mode)
Note: It is recommended the POL bit be toggled only when both TE and RE = 0.
Think MCORE might have had this feature too, but not sure. Just have the sense this isn't the only micro I've seen it on. Again, not sure.
Reply to
Randy M. Dumse
Wayne, you can add AVRs using the Bascom compiler to the list that support inverted and non-inverted. The problem comes with the hardware UART - the MCUs I've used don't have the option of changing the polarity of the serial data.
Agreed, Bob is reaching out to a large audience to get feedback. Let's not hammer him too hard in the process :-)
Eddy Wright
Reply to
Eddy Wright
[snip]
Thanks!
Have you ever seen a micro that only does inverted output from its UART?
-Wayne
Reply to
Wayne C. Gramlich
Bob -
I've ordered a pair (they haven't arrived yet) - I'm intending to connect them directly to my PIC's USART pin(s), since the +/-5V obviously works perfectly for this.
Question: Will the 'R' be decoded as decimal 82 (= 0x52 = 0b01010010) or the inverse 173 (=0xAD = 0b10101101)?
I don't really care which it is - experimentation will tell me, and it's easy to invert the byte received before using it, but it's always nice to get the code right first time :)
My 2c on the datasheet thing - Personally, I think that a statement that "0=0V, 1=5V" (or vice versa - which ever is correct, obviously) would be much simpler for everybody. It's unambiguous, and that means that nobody can get upset.
To propose an alternative for the ds:
"TX - Delivers asynchronous serial with 0 bit = 0V, 1 bit = 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).
Note: 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."
This separates what the MaxSonar produces from the way to make it into a "real" RS232-compatible signal, and I think avoids all the confusion...
IMHO...
Andrew Merton
Reply to
nobody
Never.
Or at least not any I can remember.
I think I've got a pretty good idea why RS-232 is "inverted" (by my understanding of it being inverted at least). The normal amplification mode of a transistor in common emitter inverts the signal. Almost always with single sided drivers, in order to use the least transistors possible, you would use an inverter. It takes less transistors to make an inverter than a non-inverting buffer. Back in the day, transistors cost like processors do today. And another reason to use an inverter instead of a buffer, with less stages, its faster. So to make the most economical, fastest, line driver then, you used one stage of inversion in the driver, and another stage of inversion in the receiver.
This is also the reason 7400 NANDs, 7402's NOR's and 7404's inverters were the low number (first) 7400 series gates made. Simpler and faster than AND's OR's or Buffers.
Reply to
Randy M. Dumse
Same here. If you want to be able to hook up to a microcontroller UART, the safe choice is always to use non-inverted signalling. 'nuf said on that topic.
You walk into your final exam for digital 101 and it provides the following table:
Value CMOS RS232C ======================== "1" 5V -12V "0" 0V +12V
Now design a circuit that converts a CMOS signal into an RS232C signal and another circuit that converts an RS232 signal into a CMOS signal.
My solution to this problem would be to use a MAX232 chip. If you want to call it an inverter, I guess I really do not care, but given that a "1" on one side produces a "1" on the other side, I do not call it an inverter. We may have to agree to disagree on this one.
It is way past my bed time. I'm going to give the topic a rest.
Later,
-Wayne
Reply to
Wayne C. Gramlich
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.
Reply to
lengthsman
Note that many people have *very* different ideas about what Bob has been saying.
I will note that while he has the choice of what he wants to sell, we have the choice of what to buy.
If I find that I can't access this via standard TTL-level asynchronous serial, I may not buy a second one. If I want to access a component like this from my PC, I will use a level-shifter.
If this can be changed by a firmware upgrade, I would go for it. -- D. Jay Newman
formatting link
Reply to
D. Jay Newman
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."
Reply to
Mark Moulding
Actually, it almost certainly won't work perfectly, precisely because of the reasons pounded into the ground in the preceeding discussions.
Your PIC's USART, just like my 8051's UART, expects the idle signal to be a +5V TTL level (I would say "1", but I don't want to reawaken Wayne's ire), with "true" data bits at 0V TTL level ("0" to me...) and "false" data bits at 5V TTL also. The MaxSonar-EZ1's output is exactly the inverse of this.
Since the USART depends upon the logically "true" start bit to begin its asynchronous reception, it will always be seeing what's known as a break condition, and won't be able to synchronize on the beginning of each character frame. Were the output inverted, as many posters have requested, then it would work fine. However, "out-of-spec" pseudo-RS232 direct connection to a standard PC serial port would then not work, for the same reason.
Of course, if you're bit-banging the reception with code, then it really doesn't matter. -- Mark "I prefer heaven for climate, hell for company."
Reply to
Mark Moulding
Andrew Mertron,
Thanks for the datahseet advice.
I opened up this thread to get these kind of things on the table.
Thanks again,
Bob Gross
Reply to
Bob (Robot Wars Thumper 1997)
All, I do bit bang with the PIC. It may seem trivial for a hobbyist to change the serial output but this is not a hobby operation. One thing to remember is that I live in AZ and the product is built in MN. Labor costs are low in MN. The production test fixtures are in MN. Distributors are already selling this product and it is doing very well. Right now changing this product would be costly for me and for this operation. To think other wise is to not understand business.
Currently I do not believe that this product will get changed. There have been 2100 started. All of the 1st 1000 have been programmed and 100s shipped in less than one month! The product has been very well received indeed, because the actual press release has not been done yet! Another 1000 are being planned for RoSH compliance. Product success means a great deal. These are the real votes. Changing the product right now really does not make good sense. People have been using this product and they like it.
There are three interfaces to this product right now. Choose the one you like best. I am working to get a datasheet that is technically accurate.
Best regards,
Bob Gross
Reply to
Bob (Robot Wars Thumper 1997)
"Bother," said Pooh...
Back to bit-banging, then...
Reply to
nobody
Dear Nobody,
Your inputs (and everyone else the participated) will really help us when we do the next datasheet update (the next datasheet update is scheduled for mid February).
We at Maxbotix would like to thank everyone that contributed to this discussion. We would like to do so in a tangible way (by sending you a gift). I have emailed everyone that contributed, but when I tried to email you, the email bounced. Please email me at bob@max .... remove this area (spam)... botix.com and I will let you know the details.
Thanks again,
Bob Gross
Reply to
Bob (Robot Wars Thumper 1997)

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.