I am hoping to be able to use a Nano to capture rs232 data from a temperature sensing device that outputs data from 8 separate sensors. I am getting mostly question marks in my terminal. I will post my code as well as a screenshot of the errors in the terminal. I will also post formatting details from the temperature device.
I think I need to find a library that can help format the data which is in a
" STX, Address, Message type, Length, Data payload, Checksum, ETX"
format. I believe that a terminal program like Hterm, Realterm,TeraTerm would help too but I would like to know which one is used the most from Arduino folks.
Sketch:
// this is from an article on stack exchange for arduino "how to read and write with rs232"
// It might need to be viewed in a hex term program like hterm or teraterm
// this is from an article on stack exchange for arduino "how to read and write with rs232"
// It might need to be viewed in a hex term program like hterm or teraterm
#include <SoftwareSerial.h>
SoftwareSerial mySerial(10, 11); // RX, TX
void setup() {
// Open serial communications and wait for port to open:
Serial.begin(2400);
// The wait for serial port to connect is not needed for Arduino Uno
Serial.println("USB Serial is up and running");
// set the data rate for the SoftwareSerial port
mySerial.begin(2400);
}
void loop() {
if (mySerial.available()) {
int recievedByte = mySerial.read();
Serial.write(recievedByte); // Send to USB serial - assuming using hterm in hex
if (recievedByte == 0x10) {
mySerial.write(0x20);
}
}
}
I have studied as many of the helpful articles like using Serial data and rs232 data as I can. So I am looking forward with help in pointing me in the direction of where I need to look to tackle this new challenge.
Where did you get that description? The usual message format would be
"SOH, address, STX, all the data, including type and length, ETX, checksum".
Where "SOH" is the ASCII character for start of header. Where STX is the ASCII character for start of text. Where ETX is the ASCII character for end of text.
It is in the manual of the temperature sensing device. There is a screen shot of the protocol and frame criteria in those screenshots.
Thank you for looking at this.
P.S. I googled it and I see it is a protocol that Stanford University uses, called STXETX.h . In fact they have a library for it but I do not know if Arduino could use that library. I do not know even if I was able to load the library if that would help, or not.
can you give a link to the manual?
have you attempted to connect the device to a PC and used a terminal emulator such as RealTerm to view the data stream, e.g. displaying hex values?
Ok, so not a commercial type device. Now what does your documentation say about how to get your device to send that message to you? Since there a device address involved, do you know the address for your device?
My first step would be to do as @horace suggested as that would involve no coding at all. Use a terminal program that can display received data as hexadecimal.
You can then inspect the data received to check it matches the expected message format.
A couple of things re your code:
You don't need to set the hardware serial port baud rate to 2400 just because your software serial port is set for 2400 baud. You can set it much higher if you want.
If your message format is as described, then it won't be nice printable human readable text which would explain the strange symbols you see.
I have not attached the device directly via serial but I sure can. My goal, is/was to get it to download to the arduino as it is not practical in the end to have the device connected to a computer while operating. But I understand it would be a good first step. Here is the pdf on the manual. It is called a Blaze CHT/EGT temperature monitor. MGL Blaze TC-6.pdf (1.1 MB)
I did connect it via USB with Realterm. I took some screenshots of the data stream. You'll see I captured it in Hex and also in Binary. I am not familiar with Realterm at all though. There may be other settings that I should have used....
Now I see what the device is doing. It sends a message in the format you indicate, every ONE second. If the BCC is wrong, all you can do is ignore the message and wait for the next. You can have multiple devices, but not on one RS-232 connection, so the device address lets you know the sender, even though there can only be one sender on that connection.
That is good news. So bottom line is that something an arduino can capture and ideally save that info to a SD card? (Without the arduino being connected to a PC). If so can you point me in the direction of where I can study up on how to create a sketch that can help me log this? Also can't this be slowed down with a "delay" command in the sketch?
// set the data rate for the SoftwareSerial port
mySerial.begin(2400);
The baud rates don't match!
I don't know whether softwareSerial will run at 57600.
(If you're successfully changing the device speed, run the realTerm log and the Arduino at the same speed!)
Um. I don't actually see anything in the realTerm logs that look like the message you're supposed to be receiving. (In particular, I don't see any ETX (0x03) characters!)
The data is being sent in binary; many of the bytes are likely to be "non-printable" in the serial monitor. (although having them ALL be non-printable is also unlikely.)
You DO have a an rs232 to TTL Serial in between your device an the Arduino, right?
Thank you for looking this over and catching those things. The sketch that used with realterm was set at 9600 baud. My error for grabbing a previous version of the sketch before I changed it to 9600. I know I set the baud at 9600 in the realterm at some point, and I am surprised that it was not at 9600 when I did the screen capture. I will run this again to make sure they are both at the right baud. yes, I have a Max3232 between the device and the arduino. I do think the challenge for me will be to write up the proper frame in the sketch to accept that stx-etx protocol the device uses. Thank you again.
Well, the very first thing to do is change the device Baud rate to 9600, so your software serial can keep up AND you can read what will be printed to the serial monitor. That is ALL you want to do to begin your program.
All your program needs to start with is to read a character from the serial port when one is available, then print that character to the serial monitor. When you have read the ETX character, print it including a carriage return character so you will begin the next data line on a new line on the screen.
Think more about what you are going to save to an sd card. Most of the messages will be duplicates of the previous message, since they are sent at one second intervals. But you will know for sure what you are getting when you have first step working and can see what is being sent.
in general avoid using screen shots of data output - they are difficult to read and cannot be copied
as @Paul_KD7HB recommends change the RealTerm baud rate to 9600
set the RealTerm display to Hex[space] get some data and copy the RealTerm display output and paste it using code tags </>
e.g. looks like
I really appreciate your comments. I completely understand. I will work more on the direct connection between the device and the PC using realterm as a "first step" to see how the data is coming across. I had set at one point, the 9600 8n1 in the port window of realterm, not sure how it was at the higher rate below, but I will fix that for sure. The code I posted above was inserted using bracked per the forum instructions. The only screen shots I posted were of the device manual and the active screen of the realterm.
I will read up on altsoftserial too. Thank you very much. Charlie
can you give us RealTerm Hex[space] data output at 9600baud? in text not screen dump (use CTRL/C to copy RealTerm display contents then select < CODE/ > and paste the text where it says “type or paste code here” ?)
for a start. There's coverage of how to receive a message that is marked at the beginning and end as yours is.
This function
might make short work of your task, or shorter anyway.
Check for availability and read single bytes by hand until you see an STX, which may be a real STX. Then read until you get the ETX or the readBhtesUntil() times out.
Some examination of the collected characters would confirm the reception of a true packet. Convert the eight or as many as 13 byte pairs that make up your data.
If you get ambitious, the checksum could be, um, checked.
