I have a thermometer sending RS232 output, as seen in pic 1. I dont know if that really is RS232 as the output-port says or rather TTL due to the 0/5V levels. The polarity seems inversed, it should be high?
I set the DMO up to decode the information correctly, as can be seen. So the reading there is 22.0412°C. Settings (detail in pic 2) are 7 bits, (stop 1, 1.5 or 2 doesnt change anything), 9600 baud, "LSB" order, ASCII.
There is a little bit more (seemingly static) information at first that i dont care about. (detail in pic 3)
Now... how do i read this information correctly into the Arduinos Rx pin 0?
With this simple setup i get useless cyphers. I gues due to inversion/LSB/7bit, these parameters have to be set somehow.
String a;
void setup() {
Serial.begin(9600); // opens serial port, sets data rate to 9600 bps
}
void loop() {
while(Serial.available()) {
a= Serial.readString();// read the incoming data as string
Serial.println(a);
}
}
What information for the thermometer? Every requiered information to get the signal read should be in that screenshot from the DMO (+ its ASCII). The manufacturer sells the adapter for lots and lots of $$$, there is no information to get.
It looks like this:
Edit: With adapter I mean a 2.5mm audio jack. For about 200$.
Trying to read the DMM on the same pins used by Serial.print may cause issues or it could just be the inverted signal levels.
I would suggest using SoftwareSerial on different pins to what hardware serial uses (0,1) and SoftwareSerial also has the constructor switch that allows inverting the serial logic.
Using this code and feeding pin 11 back to pin 1 i read the "same" cyphers both with false or true inversion. So i gues the "LSB" order needs to be set, as the other value results in nonsense for the scope too. But i checked again, the 7 bits dont have to be set, 8 is just fine.
// include the SoftwareSerial library so you can use its functions:
#include <SoftwareSerial.h>
#define rxPin 10
#define txPin 11
// set up a new serial port
SoftwareSerial mySerial = SoftwareSerial(rxPin, txPin, false);
void setup() {
// define pin modes for tx, rx:
pinMode(rxPin, INPUT);
pinMode(txPin, OUTPUT);
// set the data rate for the SoftwareSerial port
mySerial.begin(9600);
}
void loop() {
if (mySerial.available()) {
char data = mySerial.read();
mySerial.write(data);
}
}
Maybe its that first part of the data (maybe for °C/°F)?
Or the wrong format? Its ASCII, maybe something else is used for the decoding?
Reading it as binary i see the same as with the scope (here only 1 decimal for better overview):
Now i just have to get that out of there somehow...
// include the SoftwareSerial library so you can use its functions:
#include <SoftwareSerial.h>
#define rxPin 10
#define txPin 11
// set up a new serial port
SoftwareSerial mySerial = SoftwareSerial(rxPin, txPin, true);
void setup() {
// define pin modes for tx, rx:
pinMode(rxPin, INPUT);
pinMode(txPin, OUTPUT);
// set the data rate for the SoftwareSerial port
mySerial.begin(9600);
Serial.begin(9600);
}
void loop() {
if (mySerial.available()) {
char data = mySerial.read();
mySerial.write(data);
Serial.print(data,BIN);
Serial.println();
}
}
If i understand your dilemma, you are trying to remove unwanted ASCII characters.
The simplest way is to check the binary value of the character received and discard it.
There are real libraries which have functions to do that too - isascii - is one of them.
I believe even Serial has some functions to do that.
BTW the characters you posted are from "extended ASCII" table - ACK and +- .
Your thermometer is probably sending ACK as a start of communication.
You may find it handy before you just dismiss it because it is not an expected number.
Jim
I can change the output data type from BIN to DEC or the data type of the read "data" to int/float/word and it all gives me a partially correct output of 50, 50, 46 for "22.", tho the decimals are missing more or less.
I still dont understand how the normal output in ASCII does not result in those beeing what they are: twice a 2 and a "." instead i get some cyphers? Whats wrong with that?
The osci has no problem whatsoever to decode it right?
It works. I had to remove the "mySerial.write(data);" line, that fucked everything up...
The output looks like this now:
"C,22.5172"
So perfectly fine to log and clean up later via find/replace
