For an ultrasonic sensor (MB7380) sending 8 data BITS, no parity and one stop bit, what is the ASCII code it will give for a certain distance like 0.15 meters (0.5')?

maxbotix.com/documents/HRXL-MaxSonar-WR_Datasheet.pdf#page=2​

• I do not know how to convert 0.15 meters into 8 bits. It is using TTL serial output. I believe this model is the 5' version.
• I'm thinking I need to borrow a scope from my uni.
• ASCII Encoder/ Decoder (tool)

Or please mention a more appropriate forum for this question.

 

From the datasheet page 2:
"Pin 5-Serial Output:
The MB736X sensors have an RS232 data format (with
0V to Vcc levels) and the MB738X sensors have a
TTL outputs. The output is an ASCII capital “R”, f
ollowed by four ASCII character digits representing
the range in millimeters,
followed by a carriage return (ASCII 13). The maxi
mum range reported is 4999 mm (5-meter models) or 9
998 mm (10-meter
models). A range value of 5000 or 9999 corresponds
to no target being detected in the field of view"

 

From the datasheet:

The MB736X sensors have an RS232 data format (with 0V to Vcc levels) and the MB738X sensors have a TTL outputs. The output is an ASCII capital “R”, followed by four ASCII character digits representing the range in millimeters, followed by a carriage return (ASCII 13). The maximum range reported is 4999 mm (5-meter models) or 9998 mm (10-meter models). A range value of 5000 or 9999 corresponds to no target being detected in the field of view. The serial data format is 9600 baud, 8 data bits, no parity, with one stop bit (9600-8-N-1). Because the data is presented in a binary data format, the serial output is most accurate .

So the data transmitted for 0.15 meters (which is 0150 mm) is going to be:

'R', '0', '1', '5', '0', '\r'

The ASCII code for 'R' is 82 (0x52)
The ASCII code for '0' is 48 (0x30) (the remaining decimal digits increment from there)
The ASCII code for '\r' is 13 (0x0D)

RS-232 sends data lsb first.

 

Just yes or no: so I need to convert that to binary if I want to emulate this sensor with an Arduino TX pin?

 

ASCII is binary.

It is how you interpret it that really matters.

 

ASCII is binary.

It is how you interpret it that really matters.

For creating an Arduino program, I can't do decimal (e.g., 82).

00111000 00110010 00110100 00111000 00110100 00111001 00110101 00110011 00110100 00111000 00110001 00110011​

(for 824849534813)
(from R0150\r)

 

else if(digitalSelection == HIGH) // Arduino emulating GPIO ~ TTL based ultrasonic range sensor
{
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
digitalWrite(txPin,LOW); // 0
digitalWrite(txPin,LOW); // 0
digitalWrite(txPin,HIGH); // 1
digitalWrite(txPin,HIGH); // 1
digitalWrite(txPin,HIGH); // 1
digitalWrite(txPin,LOW); // 0
digitalWrite(txPin,LOW); // 0
digitalWrite(txPin,LOW); // 0
// 8
digitalWrite(txPin,LOW); // 0
digitalWrite(txPin,LOW); // 0
digitalWrite(txPin,HIGH); // 1
digitalWrite(txPin,HIGH); // 1
digitalWrite(txPin,LOW); // 0
digitalWrite(txPin,LOW); // 0
digitalWrite(txPin,HIGH); // 1
digitalWrite(txPin,LOW); // 0
// 2
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
}

Does that look right so far? Is my approach completely wrong?
All I want to do is emulate the ultrasonic sensor with an Arduino.

 

Your approach is not correct.
What are you trying to do?
You can send binary on a UART TX output at any time. ASCII is binary.
Arduindo can do ASCII, decimal and binary, because everything is binary.

If you want to send 128 as 8-bit binary, send
putc(128);

 

Your approach is not correct.
What are you trying to do?
You can send binary on a UART TX output at any time. ASCII is binary.
Arduindo can do ASCII, decimal and binary, because everything is binary.

If you want to send 128 as 8-bit binary, send
putc(128);

Am I not explaining it correctly? I want to emulate this ultrasonic sensor with an Arduino. In other words, simulate a few distances (such as 150 mm). There is a datalogger system already in place, and I will be swapping out the ultrasonic for the Arduino. This way I can check if the ultrasonic sensor is to blame or something else is off when troubleshooting when we get bad readings.

 

You could connect the sensor to a terminal program on a PC to see what it is sending.

 

You could connect the sensor to a terminal program on a PC to see what it is sending.

I could, but need an average Joe to use whatever I make. This is a temporary summer job.
Are you meaning instead that I should do that to find what to program the Arduino send? I was thinking of using a scope for that, if need be...

 

It sounds like you need a binary to ascii converter (assuming your interpretation of the sensor is correct). That is an extremely common conversion. Think of how often it is needed to convert binary to ascii for display on an LCD. There are arduino libraries for doing that. Here are some libraries in Assembly: http://www.piclist.com/techref/microchip/math/radix/index.htm

 

Am I over-complicating it?
Is all I need to do is transmit "R0150\r"?

 

That answer has already been posted (post #3). But, your example of "8" is b'00111000' = d.56 = ascii "cancel"
"R" = ascii 0x52 = b'01010010'

 

It sounds like you need a binary to ascii converter (assuming your interpretation of the sensor is correct). That is an extremely common conversion. Think of how often it is needed to convert binary to ascii for display on an LCD. There are arduino libraries for doing that.

What do I do instead of using the HIGH and LOW of digitalWrite(txPin?

0x52 0x30 0x31 0x35 0x30 0x0D

 

Oh, I converted ASCII, before, to ASCII.

 

I don't do Arduino, so I don't know what it's capabilities are as far as behaving like a TTL-level UART.

But if you are trying to bit-bang UART-like behavior, the I would write a small hierarchy of functions.

The first takes an unsigned char (or whatever is equivalent in the language you are using -- and unsigned 8-bit integer) and then sends that on an I/O pin the same way that an RS-232 port would sent an 8-bit value. It will output a start bit, then it will output each bit in the byte that was passed to it, starting with the lsb first, then it will output the stop bit.

The second function takes a NUL-terminated string, such as "R0150\r", and walks down it passing each character to a call to the first function in turn.

The third function takes a distance, in mm, and creates (or populates an existing) string that is suitable for passing to the second function.

If this approach is too slow (almost certainly not at 9600 baud) or takes too much memory (probably not the case, either), then you can combine them and optimize them until they are good enough. But if this approach works, then you are done.

This separates the different tasks -- generating the simulated distance values, generating the string to be transmitted, and performing the actual transmission -- into functions that can focus on doing their part correctly.

The first function is responsible for generating the correct polarity signals for the mark/space values and twiddling the output pin at the correct rate for the desired baud.

 

I think you are making this more difficult than it needs to be. Assuming your Vcc is ~+5v, just try this:

#include <SoftwareSerial.h>

//SoftwareSerial SSerial(4,5); // RX,TX not inverting
SoftwareSerial SSerial(4,5,true); // RX, TX inverting

void setup() {
  SSerial.begin(9600);
  delay(50);
}
void loop() {
  SSerial.write("R0150");
  //SSerial.write(0x0a); if you are looking at putty and non-inverting
  SSerial.write(0x0d);
  delay(1000);
}

If you really don't want inverted logic (I guess you do if it is RS232 format) then use the first constructor (the one commented out).

 

I think you are making this more difficult than it needs to be. Assuming your Vcc is ~+5v, just try this:

  delay(50);
  delay(1000);

If you really don't want inverted logic (I guess you do if it is RS232 format) then use the first constructor (the one commented out).

It is TTL, so I don't quite understand why the other serial communication is mentioned. But I more want to know, why the delays? (I'll have an LCD display running at the same time...so I feel like I should not have the delay function anywhere in the code.)

 

Assuming your Vcc is ~+5v

Are you talking about the signal itself? Arduino takes 5V to be powered. I don't get why this is important. (I will gladly read something related to save you time.)