I am attempting to extract data from a scale with an RS232 interface to the Arduino cloud using an Arudino . I am using a MAX3232 ttl converter. I have gotten the code to read the mass from the scale, however it is printing out weird symbols and the data coming in is sometimes split into a different line. The serial monitor is shown in a screenshot below along with the code I am using. I am not sure why this is happening and I am not sure what the next steps are to fixing it. The baud rate on the scale, code, and serial monitor are all at 9600. I am assuming that there is an easy add to the code to fix this or a mistake in my current code that is making it output incorrectly. If someone could please help me find the mistake or point me in the right direction that would be extremely helpful. The code and the serial monitor are added below. Thank you for your time. I am familiar with Arduino code, but am very new to the Arduino cloud. Would it be beneficial to maybe change the baud rate on the scale, code, and monitor?
#include "thingProperties.h"
#include <SoftwareSerial.h>
SoftwareSerial scaleSerial(2,3);
void setup() {
// Initialize serial and wait for port to open:
Serial.begin(9600);
scaleSerial.begin(9600);
// This delay gives the chance to wait for a Serial Monitor without blocking if none is found
// Defined in thingProperties.h
initProperties();
// Connect to Arduino IoT Cloud
ArduinoCloud.begin(ArduinoIoTPreferredConnection);
setDebugMessageLevel(2);
ArduinoCloud.printDebugInfo();
}
void loop() {
ArduinoCloud.update();
if (scaleSerial.available()){
String weightData = "";
while (scaleSerial.available()){
char c = scaleSerial.read();
weightData += c;
}
Serial.println(weightData);
sendToCloud(weightData);
}
}
void sendToCloud(String weightData){
weightCloudVariable = weightData.toFloat();
}
It seems like there are consistently two characters missing. Perhaps the description in the spec isn't complete, or maybe you really are missing reading two spaces. I suspect the former.
Is there any more text to go with the spec that explains that the "Weight and decimal point" field has a varying width depending on the whole number of units? E.g. the spec example has four characters (1213) before the decimal point, but your result has two (57).
Are you filtering out the printing of chars if their value is 0x0A or 0x0D? I think you should, as it will mess up the formatting. However, I don't see how not doing the filtering would lead to inconsistencies, unless you are not receiving some characters sometimes.
0x2B is the + sign
then you have 0x20 which are spaces
then the integral part
then 0x2E which is the decimal point
then the decimal part
then the unit
then a couple spaces
then CR and LF as end of transmission
there does not seem to have weird characters so you need to look into your code. The sync with the cloud might be an issue if it takes too long and the data is coming in, may be the buffer gets filled up.
Hi,
Thank you! Attached is the additional information on the scale, however it is not much different from the one posted above. The scale only reads up to 200g as well.
I didn't sync through the cloud, it is through USB for now until I can figure out how to get it to print correctly. I have not tried to use the cloud features yet.
Would it be a good idea to filter out the spaces and the CR and LF as @Dave_Lowther suggested?
I would suggest to study Serial Input Basics to handle this. You listen asynchronously until you get the end marker (the CR LF or just LF) and then you parse the input. that will be more robust.
Oh, that table shows 14 bytes, so you aren't missing 2 bytes, which is good. However, you are getting 15 bytes, not 14, which is not so good. I'd assume the spec is off by one for now. Cell 13 'End' and 14 'Return' must mean 'CR' and 'LF'.
