I am trying to obtain the weights from a weighing scale KERN ew220-3nm to Arduino Uno through RS232.
This is the code :

Code: [Select]
#include <SoftwareSerial.h>
SoftwareSerial mySerial(5, 4);

void setup() {
Serial.begin(9600);
mySerial.begin(9600);

}

void loop()
{
while (mySerial.available()){
Serial.println(mySerial.read(),HEX);
}
}

As per the device manual, the complete transmitted output consists of 15 words, 1 start bit, 8 data bits(except 2-9 words which are data bytes and have maximum 6 characters), no parity, 2 stop bits.

This is the output obtained :

Code: [Select] 6A
9F
7C
F1
86
C6
1A
C6
46
19
43
97
43
15
79
EB
0


I have a few doubts -

1. Do the 2 stop bits as mentioned in the device manual disturb my complete data or is it ignored?

2. Whenever I print the incoming byte, does it print only the last byte or does it print some data from before along with the incoming data(if it is not a complete byte)?

3. Is the data to be read LSB first due to the RS232 protocol?

4. The results include 16 or sometimes 17 words (which is basically not possible). The first word is 2BH or 20H and the last words as specified by the manual are CR and LF. But I cannot detect any output corresponding to that. Does that mean all of my output is some garbage data or do I need to decode it somehow?

Please help me with this. Thank you.

 

RS232 voltage levels are not compatible with the arduino TTL serial.
You need a max232 interface or similar..

Something like this
http://www.ebay.com/itm/RS232-Seria...777?pt=LH_DefaultDomain_0&hash=item53fffce6b1

 

I am trying to obtain the weights from a weighing scale KERN ew220-3nm to Arduino Uno through RS232.

As per the device manual, the complete transmitted output consists of 15 words, 1 start bit, 8 data bits(except 2-9 words which are data bytes and have maximum 6 characters), no parity, 2 stop bits.

1. Do the 2 stop bits as mentioned in the device manual disturb my complete data or is it ignored?

2. Whenever I print the incoming byte, does it print only the last byte or does it print some data from before along with the incoming data(if it is not a complete byte)?

3. Is the data to be read LSB first due to the RS232 protocol?

4. The results include 16 or sometimes 17 words (which is basically not possible). The first word is 2BH or 20H and the last words as specified by the manual are CR and LF. But I cannot detect any output corresponding to that. Does that mean all of my output is some garbage data or do I need to decode it somehow?

You need to read up about RS-232 interface and protocol.

1. STOP BIT is the spacing between characters and is present for timing purposes only. It is not part of the data.

2. The received byte is printed. A byte is 8 bits, no more, no fewer. There is no incomplete byte.

3. The order of the bits is accounted for by the hardware. You can ignore this.

4. As mcgyvr says, you need an RS-232 receiver to properly receive and invert the RS-232 signal.

 

RS232 voltage levels are not compatible with the arduino TTL serial.
You need a max232 interface or similar..

Something like this
http://www.ebay.com/itm/RS232-Seria...777?pt=LH_DefaultDomain_0&hash=item53fffce6b1

I am sorry I forgot to mention that I am already using MAX232 as an interface.

 

As per the device manual, the complete transmitted output consists of 15 words, 1 start bit, 8 data bits(except 2-9 words which are data bytes and have maximum 6 characters), no parity, 2 stop bits.

You seem to be mixing data types here. What do you think is a word? I think it is two (or more) bytes used to store an integer or other numeric data type. Serial communications operate with characters or bytes. They are 8 bits in length. Start and stop bits are handled by the communication library (someties in hardware but in software serial, not so much). And what do you mean by the definition of the 2-9 words? It is unlikely that they have 6 bits; perhaps only 6 bits are used?

As MrChips mentioned, bit order is handled by the library.

So, with my questions above in mind, are you expecting 30 bytes (15 words) or 15 bytes (characters)?

 

@Mr Chips
I think when the manual said characters, I mixed it up with bits.
I understood that part about the RS232 protocol but was not sure about how the data bits and start and stop bits are different. I understand that now. Thank you.

@djsfantasi
The manual only mentions words and not bytes which I am assuming is the same as bytes. By 2-9 words, I mean the 2nd to 9th (including both) bytes. Also, as I mentioned before, I mixed up the characters with bits and so that doubt is solved. Thank you.

I saw something about the Library AltSoftSerial and used it in my program instead of SoftwareSerial and I think I am getting better results. It is to do with the amount of time the libraries waste before recording the data using Interrupt.
I know that this library gives better results as the manual says that the serial data is made of 15 words (bytes) and I am getting exactly 15 bytes now, with constant 1st, 2nd last and last bytes, as expected. But still, the data does not match the one I require. I shouldn't be required to decode serial data, should I?

The 'new' code is

 :
#include <AltSoftSerial.h>
AltSoftSerial mySerial;  
#define TwobitDelay 200

void setup()  
{
  Serial.begin(9600);  
  mySerial.begin(9600);
}
void loop() 
{
 while (mySerial.available()){
   Serial.println(mySerial.read(),HEX);
   delayMicroseconds(TwobitDelay);
}
}

And my results are :
6A
C6
C6
86
C6
E3
C6
C6
86
13
E1
23
45
1E
3D

As mentioned earlier, 6A, 1E and 3D are obtained in every set of data. Also, this is for 0 gram, which could mean C6 or 86 is 0. But I do not think I should need to decode it this way.

 

The manual only mentions words and not bytes which I am assuming is the same as bytes. By 2-9 words, I mean the 2nd to 9th (including both) bytes. Also, as I mentioned before, I mixed up the characters with bits and so that doubt is solved. Thank you.

As mentioned earlier, 6A, 1E and 3D are obtained in every set of data. Also, this is for 0 gram, which could mean C6 or 86 is 0. But I do not think I should need to decode it this way.

I still think you have a configuration problem. According to the manual, the first byte should be either 20h, 2Bh or 2Dh. you show 6Ah... Also, the next eight bytes should be the ASCII codes for digits (or a decimal point or a space). None of the bytes you report meet that criteria; digits in ASCII are 30h - 39h. Decimal point is 2Eh and a space is 20h. A similar observation can be made for the next four bytes. Finally, all of the input from the device should terminate with a carriage return (CR = 0Dh) and a line feed (LF = 0Ah)

My first guess is that the scale is not set to communicate at 9600 baud. According to the manual, this can be configured on the scale. (Let me know if this is the right manual.)

As far as your decoding, you WILL have to decode something. Whether it is from the ASCII string to a floating point number or from the two bytes designating units to some internal meaningful coding scheme, it is required.

 

I still think you have a configuration problem. According to the manual, the first byte should be either 20h, 2Bh or 2Dh. you show 6Ah... Also, the next eight bytes should be the ASCII codes for digits (or a decimal point or a space). None of the bytes you report meet that criteria; digits in ASCII are 30h - 39h. Decimal point is 2Eh and a space is 20h. A similar observation can be made for the next four bytes. Finally, all of the input from the device should terminate with a carriage return (CR = 0Dh) and a line feed (LF = 0Ah)

My first guess is that the scale is not set to communicate at 9600 baud. According to the manual, this can be configured on the scale. (Let me know if this is the right manual.)

As far as your decoding, you WILL have to decode something. Whether it is from the ASCII string to a floating point number or from the two bytes designating units to some internal meaningful coding scheme, it is required.

The scale is set to 9600 baud rate with no parity.

Is it possible that I will have to calibrate the data obtained from the scale?

 

I don't think it is a scale "calibration" issue. Perhaps a "configuration" issue, but more on that later.

You said earlier that your data from the scale was in the form 1 start bit, 8 data bits, no parity bit AND 2 stop bits.

The SoftwareSerial library does not support 2 stop bits. The native Arduino serial libraries do support different formats, including 2 stop bits, just not the library which you have chosen.

One option would be to set the scale to communicate at 8N1, which is the default format supported by the library.

Another option would be to use the standard library and pins to communicate with the scale. Then, if you need another serial port, you can use SoftwareSerial for that communication.

The standard library would use the line "Serial.begin(9600,SERIAL_8N2);" to initialize the comm port.

What do you think?

 

2 STOP BIT gap is meant to accommodate slower devices.
If the receiver can handle 1 STOP BIT then it can handle 2.

 

I just read the manual. It looks like you cannot change the 2 stop bits. So the simplest solution is to use the standard Arduino serial library.

 

2 STOP BIT gap is meant to accommodate slower devices.
If the receiver can handle 1 STOP BIT then it can handle 2.

So you are saying that a receiver configured as 8N1 can read data sent 8N2? I would think the timing would be off, but I could be wrong.

 

The STOP BIT is the spacing between consecutive characters.

If the receiver has received the first character and is ready to receive the next character within the delay of one bit width then, yes, it can handle 1, 1.5, 2 or more STOP BITs.

It is not unusual to configure the transmitter for 2 STOP BITS and the receiver for 1 STOP BIT.

 

Thanks! I thought I knew this pretty good, but there's always room for more.

Can't figure out yet why the OP is getting strange results. It should be straightforward

 

I could still try and use the serial port (configured as 8N2) with the scale and then read the data using Processing?

And, just confirming, I shouldn't need to calibrate, right?

 

I could still try and use the serial port (configured as 8N2) with the scale and then read the data using Processing?

And, just confirming, I shouldn't need to calibrate, right?

I don't this it is a calibration issue. Of the 15 bytes received in the stream, many are constant. The first and last two for example. The last two should always be 0Dh and 0Ah. So something in the processing of the communications is causing the problem.

What do you mean by "using Processing"? I'm assuming you mean your sketch, and in that case it's worth a try. Your communications is through software emulation of a hardware UART and you're using an external library. I'd like to see the results with the standard library. Please post your code when you try!

 

Why is the OP getting strange results? Don't know.
Something is wrong with the OP's setup or interface.

Can the OP provide an oscilloscope screen shot of the first characters transmitted?

 

I don't this it is a calibration issue. Of the 15 bytes received in the stream, many are constant. The first and last two for example. The last two should always be 0Dh and 0Ah. So something in the processing of the communications is causing the problem.

What do you mean by "using Processing"? I'm assuming you mean your sketch, and in that case it's worth a try. Your communications is through software emulation of a hardware UART and you're using an external library. I'd like to see the results with the standard library. Please post your code when you try!

By Processing, I mean the programming language to communicate between the Arduino and the laptop, since , if I am using the standard serial library, I will not be able to communicate between the Arduino and the laptop. (I have Arduino Uno which has only 1 serial port.)

 

So, you could use the standard Arduino serial port to communicate with the scale and use the SoftwareSerial library to communicate with your laptop? Correct? I see your dilemma. Let me think on it.

 

Use the Arduino UART receiver to receive characters from the scale.
Use the Arduino UART transmitter to send characters to the PC.