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.)

delay(50) is to wait for the software serial to "settle": IOW it is something I have used over and over again and if seen over and over again but have never really determined that it is needed (sorry for the honesty).

delay(1000) is just for the demonstration - it will send R0150 \R every second - just to illustrate.

 

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.)

I may catch heck from others here that have more SME. TTL "levels" are 0-5V in this case, but the data sheet is saying that they are using the RS232 format. While RS232 format typically is associated with something like +12/-12, it is not in this case. But, the part I am focusing on is that the old RS232 format that I remember, will invert the signals at the transmitter and again at the receiver.

I don't have the sensor in front of me so I don't know what it is sending (it should be easy for you to see). Hence, I used software serial that inverts the signals (option true) (inverse_logic: is used to invert the sense of incoming bits (the default is normal logic). If set, SoftwareSerial treats a LOW (0 volts on the pin, normally) on the Rx pin as a 1-bit (the idle state) and a HIGH (5 volts on the pin, normally) as a 0-bit. It also affects the way that it writes to the Tx pin. Default value is false).

If the sensor truly is using RS232 format (reagrdless of the 0-+5 voltages), it seems to me that you want to invert the signals in your emulation. Again, it is easy enough to determine.

 

Sensor is MB7380. Datasheet says output is TTL and spells it out very clearly.

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”, 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.

TTL output is +V in the idle state. START-bit is GND. No RS-232 receiver/driver is required to interface this to a MCU or to emulate the device.

To emulate 0.15m, send:

R0150<CR>

 

Sensor is MB7380. Datasheet says output is TTL and spells it out very clearly.

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”, 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.

TTL output is +V in the idle state. START-bit is GND. No RS-232 receiver/driver is required to interface this to a MCU or to emulate the device.

To emulate 0.15m, send:

R0150<CR>

Entirely predictable. I have posted the code and explained how I would do the the emulation very easily with an Arduino. I also explained the inversion issue including a commented statement to use if you do not want to invert the signals. As I have already stated, this is easy enough to test by simply reading the output of the sensor.

If the response of the sensor is "R0150" then it is not inverting the signals, if the response is "«ÖVöV", it is inverting the signals and they need to be inverted when sending and receiving to the sensor. Of course, this would be predicated on a proper instruction before reading.

The datasheet section has now been quoted several times. What has not been addressed is this part of the text - "The MB736X sensors have an RS232 data format". Exactly what makes it RS232 format? Why doesn't it simply say "TTL serial ASCII format"? Why is RS232 being mentioned at all? That is the statement that puzzled me and the statement that led me to write the code as I did with the explanations that I gave.

I see no reason to make unnecessary declarative statements when I don't have the sensor in hand.

@MrChips or anyone, please clearly explain why the datasheet says "The MB736X sensors have an RS232 data format". Exactly what makes it RS232 format? Why doesn't it simply say TTL serial ASCII format?

It seems to me that the RS232 standard does, indeed specify voltage levels which are not "satisfied" with the sensor. Because those "noise-resistant" voltages were not compatible with logic, converts were needed and that is where the inversions came in - that is my understanding.
So, again, what makes it RS232 format? Why doesn't it simply say TTL serial ASCII format?

 

At the hardware level, TTL refers to 0-5V voltages, RS-232 refers to voltage levels anything from ±3V to ±15V.
When applied to UART serial data communications
TTL MARK = +5V
TTL SPACE = 0V.

RS-232 MARK = -V
RS-232 SPACE = +V

(MARK is the idle condition. The START bit is sent as SPACE.)

Reference:
https://en.wikipedia.org/wiki/RS-232

Stating that MB736X sensors have RS-232 format implies that a TTL-to-RS232 inverting line driver is used to send TX-Data. This is not the same as TTL serial ASCII format, which model MB738X provides. There is no confusion in this matter.

 

nm I guess it should be inverted for the MB736X but not for the MB738X as @MrChips is saying. I wonder if the MB736X does invert. In any event, it is why I put both in the code.

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

 

There is no need to invert the TTL TXdata from the UART. When you use an RS-232 driver IC such as MAX232, the chip will invert the signal.

 

There is no need to invert the TTL TXdata from the UART. When you use an RS-232 driver IC such as MAX232, the chip will invert the signal.

If you are emulating the sensor with an Arduino, which is what the TS is doing, and the sensor sends an inverted signal, you need to invert the signal from the Arduino so the emulation is correct.

 

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);

BTW: putc(128); would not compile on the Arduino. It is defined as a macro with two arguments. edit: it needs two arguments as per the error but I can't find a macro or prototype for it on the Arduino.

 

BTW: putc(128); would not compile on the Arduino. It is defined as a macro with two arguments. edit: it needs two arguments as per the error but I can't find a macro or prototype for it on the Arduino.

I don't do Arduino.

putc(ch) was meant to be any generic basic serial I/O function that sends a character ch out to the serial TXdata line. You can create this function easily in ASM or C on any MCU.

 

I don't do Arduino.

putc(ch) was meant to be any generic basic serial I/O function that sends a character ch out to the serial TXdata line. You can create this function easily in ASM or C on any MCU.

Sorry that you don't "do" Arduino, but the TS was actually asking for Arduino code (see post #4). Also, as I am sure you know, putc() is included in the ANSI C standard and is, as far as I can tell, no different than fputc() except it can be a macro.vIts use is by no means restricted to a serial TX line.
int fputc(int c, FILE* stream);
Writes c, converted to unsigned char, to stream stream. Returns the character written, or EOF on error.
Arduino lDE "language", however, does not care so much about that standard and putc() would not work in this case (at least I don't know how it could). For Arduinoese, one would use a form of serial.write(). In this case, using software serial [i.e. SSerial.write("R0150");], as I did, accomplishes the task where putc() does not.

 

What I meant is that, in general, I do not depend on a library function that someone else wrote. If there is a function I need and it is not available I create it myself. In this way I have complete control on the behaviour of the function and what it does. I would be disappointed if you cannot do the same on Arduino.

 

What I meant is that, in general, I do not depend on a library function that someone else wrote. If there is a function I need and it is not available I create it myself. In this way I have complete control on the behaviour of the function and what it does. I would be disappointed if you cannot do the same on Arduino.

There are many disappointments in life @MrChips

 

I don't do Arduino.

Arduino just uses a set of C/C++ functions.

If you are emulating the sensor with an Arduino, which is what the TS is doing, and the sensor sends an inverted signal, you need to invert the signal from the Arduino so the emulation is correct.

To emulate the MB738X, I should use:

/*
  Mega testing sketch
*/
//#include<LiquidCrystal.h>
////#include <SoftwareSerial.h> // Make other pins → serial
//
//unsigned long startMillis;
//unsigned long currentMillis;
//const unsigned long period = 1000;
//const byte txPin0 = 14;
//const byte rxPin0 = 15;
//const byte txPin1 = 16;
//const byte rxPin1 = 17;
//int analogPin = 2;
//int digitalPin = 3;
//int oneWirePin = 4;

void setup() {
  Serial.begin(9600); // bps ~ baud rate
  delay(50);
}

void loop() {
  Serial.write("R0030");  // 30 mm = 0.1' = 1.2"
  Serial.write(0x0d);     // "\r" (stop bit)
  Serial.write("R0061");  // 0.2 feet
  Serial.write(0x0d);
  Serial.write("R0091");  // 0.3 feet
  Serial.write(0x0d);
  Serial.write("R0122");  // 0.4 feet
  Serial.write(0x0d);
  Serial.write("R0152");  // 0.5 feet
  Serial.write(0x0d);

  Serial.write("R0183");  // 0.6 feet
  Serial.write(0x0d);
  Serial.write("R0213");  // 0.7 feet
  Serial.write(0x0d);
}

Although, for "Serial" in "Serial.write", is that something different from using objects like mySerial or Genovese's SSerial? (I didn't know what to look up since the difference is that it's in bold.)

 

To emulate the MB738X, I should use: (that code)

Well I forgot the inverted, but that goes to show that I was wondering if the SoftwareSerial library needs to be used?

 

Arduino just uses a set of C/C++ functions.



To emulate the MB738X, I should use:

/*
  Mega testing sketch
*/
//#include<LiquidCrystal.h>
////#include <SoftwareSerial.h> // Make other pins → serial
//
//unsigned long startMillis;
//unsigned long currentMillis;
//const unsigned long period = 1000;
//const byte txPin0 = 14;
//const byte rxPin0 = 15;
//const byte txPin1 = 16;
//const byte rxPin1 = 17;
//int analogPin = 2;
//int digitalPin = 3;
//int oneWirePin = 4;

void setup() {
  Serial.begin(9600); // bps ~ baud rate
  delay(50);
}

void loop() {
  Serial.write("R0030");  // 30 mm = 0.1' = 1.2"
  Serial.write(0x0d);     // "\r" (stop bit)
  Serial.write("R0061");  // 0.2 feet
  Serial.write(0x0d);
  Serial.write("R0091");  // 0.3 feet
  Serial.write(0x0d);
  Serial.write("R0122");  // 0.4 feet
  Serial.write(0x0d);
  Serial.write("R0152");  // 0.5 feet
  Serial.write(0x0d);

  Serial.write("R0183");  // 0.6 feet
  Serial.write(0x0d);
  Serial.write("R0213");  // 0.7 feet
  Serial.write(0x0d);
}

Although, for "Serial" in "Serial.write", is that something different from the object mySerial or Genovese's SSerial? I didn't know what to look up since the difference is that it's in bold.

Oh Hi, I forgot you were here

Haven't tried your code but at a glance, it looks like you have it.

The SSerial is preferable as it operates on different pins (3,4). Preferable in the sense that it has the advantage of avoiding conflict with the serial monitor (0,1) which is in use when the USB connection is used. So, if you have the USB connected, then TX/RX on 0,1 will be problematic as will debugging/testing the program.

If you do not need or want to use the USB connection, then serial.write() should be fine. But, software serial (SSerial.write()) should work fine whether you connect to USB or external power.

 

Well I forgot the inverted, but that goes to show that I was wondering if the SoftwareSerial library needs to be used?

So, to be clear about the inversion. I was not reading carefully. Inversion *may* be necessary to emulate the MB736X, but you are using the MB738X - right? So, you probably do not need the inversion for emulation.

Again, to find out, just use the sensor with the Arduino (not as an emulation) and see which way works - that is the definitive test in my view.

 

Again, to find out, just use the sensor with the Arduino (not as an emulation) and see which way works - that is the definitive test in my view.

Yes =) Seeing is believing...for most cases at least.

 

Yes =) Seeing is believing...for most cases at least.

Yeah, "who ya gonna believe - me or your lying eyes?"