EC stamp serial communication problems.

I am trying to communicate with my EC stamp. Here is the datasheet:

https://www.atlas-scientific.com/_files/_datasheets/_circuit/EC_Circuit_3.0.pdf
https://www.atlas-scientific.com/_files/instructions/ec_Wiringdiagram.pdf

So now I have it wired correctly (I believe), I am using pins 10 and 11 for tx and rx respectively and have wired the stamps rx to tx and tx to rx.

I am using the code below:

/*
This software was made to demonstrate how to quickly get your Atlas Scientific product running on the Arduino platform.
An Arduino Duemilanove board was used to test this code.
This code was written in the Arudino 1.0 IDE
Modify the code to fit your system.
Code efficacy was NOT considered, this is a demo only.
The soft serial port TX line goes to the RX pin.
The soft serial port RX line goes to the TX pin.
Make sure you also connect to power and GND pins to power and a common ground.
Data is received and re-sent through the Arduinos hardware UART TX line.
Open TOOLS > serial monitor, set the serial monitor to the correct serial port and set the baud rate to 38400.
Remember, select carriage return from the drop down menu next to the baud rate selection; not "both NL & CR".
The data from the Atlas Scientific product will come out on the serial monitor.
Type in a command in the serial monitor and the Atlas Scientific product will respond.
*/




#include <SoftwareSerial.h>                                                    //add the soft serial libray
#define rxpin 11                                                                //set the RX pin to pin 2
#define txpin 10                                                                //set the TX pin to pin 3


SoftwareSerial myserial(rxpin, txpin);                                         //enable the soft serial port


String inputstring = "";                                                       //a string to hold incoming data from the PC
String sensorstring = "";                                                      //a string to hold the data from the Atlas Scientific product
boolean input_stringcomplete = false;                                          //have we received all the data from the PC
boolean sensor_stringcomplete = false;                                         //have we received all the data from the Atlas Scientific product


  void setup(){                                                                //set up the hardware
     Serial.begin(38400);                                                      //set baud rate for the hardware serial port to 38400
     myserial.begin(38400);     //set baud rate for software serial port to 38400
     //Serial.println("hello world");
     inputstring.reserve(5);                                                   //set aside some bytes for receiving data from the PC
     sensorstring.reserve(30);                                                 //set aside some bytes for receiving data from Atlas Scientific product
     }
 
 
 
   void serialEvent() {                                                         //if the hardware serial port receives a char
               char inchar = (char)Serial.read();                               //get the char we just received
               inputstring += inchar;                                           //add it to the inputString
               if(inchar == '\r') {input_stringcomplete = true;}                //if the incoming character is a <CR>, set the flag
              }  
 
 
 
 void loop(){                                                                   //here we go....
     
  if (input_stringcomplete){                                                   //if a string from the PC has been recived in its entierty 
      myserial.print(inputstring);                                             //send that string to the Atlas Scientific product
      inputstring = "";                                                        //clear the string:
      input_stringcomplete = false;                                            //reset the flage used to tell if we have recived a completed string from the PC
      }
 

  while (myserial.available()) {                                               //while a char is holding in the serial buffer
         char inchar = (char)myserial.read();                                  //get the new char
         sensorstring += inchar;                                               //add it to the sensorString
         if (inchar == '\r') {sensor_stringcomplete = true;}                   //if the incoming character is a <CR>, set the flag
         }


   if (sensor_stringcomplete){                                                 //if a string from the Atlas Scientific product has been received in its entirety
       Serial.print(sensorstring);                                             //use the hardware serial port to send that data to the PC
       sensorstring = "";                                                      //clear the string:
       sensor_stringcomplete = false;                                          //reset the flag used to tell if we have received a completed string from the Atlas Scientific product
      }
}

As soon as I start I get this streaming in the serial monitor:
!¥Á!eÁ!¥Áç¥Á1%Ó!¥Á!%Á!¥Á!¥Á

Using the command L0 doesn't seem to turn off any LED's on the stamp.

I have an I2C LCD shield with buttons ontop of my arduino on stacking headers, but the I2C shouldn't interfere with the serial anyway? I also had an RTC module sharing I2C on pins 0 and 1 (I think) which I have since removed with the same random garbage output in serial.

Do you have common ground between arduino and EC stamp ?

Why you use Hardware Serial and SoftwareSerial ?

Keep in mind the function void serialEvent() will be fired only by Hardware Serial port

Also do you setup on serial monitor the baudrate to be 38400 ? if not do it :slight_smile:

tasosstr:
Do you have common ground between arduino and EC stamp ?

Why you use Hardware Serial and SoftwareSerial ?

Keep in mind the function void serialEvent() will be fired only by Hardware Serial port

This is code directly from atlas scientific, it is ment to test the stamp and calibrate the sensor. The hardware serial is to send commands to the stamp and to receive feedback, and the software serial is obviously to interface the arduino uno with my EC stamp :S

However I was under the impression that you can't use the hardware and software serials at the same time, and this code doesn't seem to alternate between them. Or is it just that you can't use multiple software serials? In which case my example should be working.

Yes I have set the hardware serial to 38400 also if you read the code.. but why should it be? What if I have two devices sharing serial with different baud rates?

Sorry but i was read fast the first post.

Ok the arduino uno has one Hardware Serial Port, and you are right you can't have multiple serial check, if you want it at the same time you should be choose Arduino Mega this has 4 Hardware Serial Ports and have buffer for all the ports so you can check it all without loose anything (not anything ... but it is ok).

You don't have limit in the baud rate (i thing lets confirm some one here also) from one port to another eg. Serial1 can be 9600 and Serial2 can be 19200 e.t.c. from Software serial i thing in past i have found a problem on baudrate ( i can remember very well sorry i thing i can't increase to much. ..)

Another thing that can get wrong data it is the invert bits, and this on Hardware port can change with a max 232 and on SoftwareSerial with a command: SoftwareSerial mySerial =  SoftwareSerial(rxPin, txPin,true); (i have not test it but on the old one NewSoftSerial myInvertedConn(7, 5, true); i have test it and was ok.

Thank you, I have changed the hardware serial to 9500 and it is displaying correctly now (it seems it must be 9500?). It is actually returning continuous values from the sensor (its not submurged yet I hope its ok).

The problem now is it still does not seem to recieve commands. I can see the green led is on for power and the red led is flashing every second. Entering L0 into the serial monitor does not turn of the LED's, nor does E stop the continuous readings. It can still show me the serial output so why cant it accept my commands?

I need to send it commands to calibrate the sensor. Sorry I don't know about inverted bits.

UPDATE:

Like I said it worked when I changed the baud rate to 9500 but didn't seem to get commands. I just realised you change the baud rate in the serial monitor also :blush: so I changed all to 38400.

It seems like the last command is getting stuck/scrambled somehow. Just before I had it working, I could even get the device info from it and it seemed to accept commands. Then I tried to turn off the LED's but nothing happened, so I reset.. unplug the usb etc.

Now the green LED is still on but no red LED. Then I send a command to turn the LED's on again and I get two lines of output and then it stops, not recieving commands again. I have to keep restarting it, I hope its not bad for the stamp.

I want to make sure it is working before I try calibrate.

EDIT: Sorry I was an idiot I didn't read the instructions on setting the carriage return, I thought that was just a newline thing, not used for output. That was all needed to send commands properly.

What are invert bits incase I run into them later? Also is it better to use a different baud for the serial monitor or it does not matter?

I am glad you find it :slight_smile: This is that we said experience :wink:

You said "EDIT: Sorry I was an idiot ....." No i am not agree, every day you learn something new :wink: no one born to know everything :wink:

Just for you're information the baudrate values are 110, 150, 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 56000, 57600 and 115200 so the 9500 you should be change to the 9600 other wise times to time maybe you loose data.

"What are invert bits in case I run into them later? Also is it better to use a different baud for the serial monitor or it does not matter?"

From the time you have the data you will not need it. the Invert with simple word is you send 1 and after invert goes 0.

Home
Libraries
TinyGPS
NewSoftSerial
Streaming
PString
Flash
PWMServo
IridiumSBD
TinyGPS++
About
Projects
The Reverse Geocache™ Puzzle
Building a Puzzle Box
Buying a Puzzle Box
More Puzzle Box Tales
Email: Admin RSS Subscribe: RSS feed
Arduiniana
Arduino wisdom and gems by Mikal Hart
NewSoftSerial
A New Software Serial Library for Arduino
News: NewSoftSerial is in the core! Starting with Arduino 1.0 (December, 2011), NewSoftSerial has replaced the old SoftwareSerial library as the officially supported software serial library. This means that if you have 1.0 or later, you should not download this library. To port your code to 1.0, simply change all NewSoftSerial references to SoftwareSerial.
NewSoftSerial is the latest of three Arduino libraries providing “soft” serial port support. It’s the direct descendant of ladyada’s AFSoftSerial, which introduced interrupt-driven receives – a dramatic improvement over the polling required by the native SoftwareSerial.
Without interrupts, your program’s design is considerably restricted, as it must continually poll the serial port at very short, regular intervals. This makes it nearly impossible, for example, to use SoftwareSerial to receive GPS data and parse it into a usable form. Your program is too busy trying to keep up with NMEA characters as they arrive to actually spend time assembling them into something meaningful. This is where AFSoftSerial’s (and NewSoftSerial‘s) interrupt architecture is a godsend. Using interrupt-driven RX, your program fills its buffer behind the scenes while processing previously received data.
Improvements
NewSoftSerial offers a number of improvements over SoftwareSerial:
It inherits from built-in class Print, eliminating some 4-600 bytes of duplicate code
It implements circular buffering scheme to make RX processing more efficient
It extends support to all Arduino pins 0-19 (0-21 on Arduino Mini), not just 0-13
It supports multiple simultaneous soft serial devices.*
It supports a much wider range of baud rates.**
It provides a boolean overflow() method to detect buffer overflow.
Higher baud rates have been tuned for better accuracy.
It supports the ATMega328 and 168.
It supports 8MHz processors.
It uses direct port I/O for faster and more precise operation.
(New with version 10). It supports software signal inversion.
(New) It supports 20MHz processors.
(New) It runs on the Teensy and Teensy++.
(New) It supports an end() method as a complement to begin().
*But see below for an important caveat on multiple instances.
**Be circumspect about using 300 and 1200 baud though. The interrupt handler at these rate becomes so lengthy that timer tick interrupts can be starved, causing millis() to stop working during receives.
Using Multiple Instances
There has been considerable support for an library that would allow multiple soft serial devices. However, handling asynchronously received data from two, three, or four or more serial devices turns out to be an extremely difficult, if not intractable problem. Imagine four serial devices connected to an Arduino, each transmitting at 38,400 baud. As bits arrive, Arduino’s poor little processor must sample and process each of 4 incoming bits within 26 microseconds or else lose them forever. Yikes!
It occurred to me, though, that multiple instances could still be possible if the library user were willing to make a small concession. NewSoftSerial is written on the principle that you can have as many devices connected as resource constraints allow, as long as you only use one of them at a time. If you can organize your program code around this constraint, then NewSoftSerial may work for you.
What does this mean, exactly? Well, you have to use your serial devices serially, like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
#include <NewSoftSerial.h>

// Here's a GPS device connect to pins 3 and 4
NewSoftSerial gps(4,3);

// A serial thermometer connected to 5 and 6
NewSoftSerial therm(6,5);

// An LCD connected to 7 and 8
NewSoftSerial LCD(8,7); // serial LCD

void loop()
{
...
// collect data from the GPS unit for a few seconds
gps.listen();
read_gps_data(); // use gps as active device
// collect temperature data from thermometer
therm.listen();
read_thermometer_data(); // now use therm
// LCD becomes the active device here
LCD.listen();
LCD.print("Data gathered...");
...
}
In this example, we assume that read_gps_data() uses the gps object and read_thermometer_data() uses the therm object. Any time you call the listen() method, it becomes the “active” object, and the previously active object is deactivated and its RX buffer discarded. An important point here is that object.available() always returns 0 unless object is already active. This means that you can’t write code like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
void loop()
{
device1.listen();
if (device1.available() > 0)
{
int c = device1.read();
...
}
device2.listen();
if (device2.available() > 0)
{
int c = device2.read();
...
}
}
This code will never do anything but activate one device after the other.
Signal Inversion
“Normal” TTL serial signaling defines a start bit as a transition from “high” to “low” logic. Logical 1 is “high”, 0 is “low”. But some serial devices turn this logic upside down, using what we call “inverted signaling”. As of version 10, NewSoftSerial supports these devices natively with a third parameter in the constructor.

get it form here http://arduiniana.org/libraries/newsoftserial/

Thank you, I realise I will need to use one device at a time. But I am wondering...

The datasheet for the EC probe says:

"Taking a single reading is not considered scientifically accurate. The E.C. Circuits readings
will become accurate after ~ 15-25 continues readings. A single reading will only give you
an estimate of the conductivity. . *This instruction takes 1000 milliseconds to complete "

I wonder if I keep taking single readings if it will become more accurate also? Otherwise I will have to have longer times between my devices, but then the question is how long? The datasheet doesn't say how long it takes to stabilise.. I need to run up to 4 serial and 2 digital sensors, I know I know I should get a mega... but I want to know how to work with what I have please, since I went to the trouble of getting an I2C lcd keypad so
I could use more pins :slight_smile:

Hi,

Maybe you need to average the data 4 times (maybe ?) but i thing for to be sure check only this data for the begin and if the data comes always the same or near then you don't need the average.

Now for the serial you can have more than one SoftwareSerial see here http://arduino.cc/en/Reference/SoftwareSerial

from the above

*
  Software serial multple serial test
 
 Receives from the hardware serial, sends to software serial.
 Receives from software serial, sends to hardware serial.
 
 The circuit: 
 * RX is digital pin 10 (connect to TX of other device)
 * TX is digital pin 11 (connect to RX of other device)
 
 Note:
 Not all pins on the Mega and Mega 2560 support change interrupts, 
 so only the following can be used for RX: 
 10, 11, 12, 13, 50, 51, 52, 53, 62, 63, 64, 65, 66, 67, 68, 69
 
 Not all pins on the Leonardo support change interrupts, 
 so only the following can be used for RX: 
 8, 9, 10, 11, 14 (MISO), 15 (SCK), 16 (MOSI).
 
 created back in the mists of time
 modified 25 May 2012
 by Tom Igoe
 based on Mikal Hart's example
 
 This example code is in the public domain.
 
 */
#include <SoftwareSerial.h>

SoftwareSerial mySerial(10, 11); // RX, TX
// New serial port (Not Hardware)
SoftwareSerial mySerial_New(12, 13); // RX, TX

Is there a difference between using continuous mode and getting a single reading continuously??

Sorry but i don't understand the question

Please read the E.C kit datasheet, there are two commands. One sets the probe to return a value continuously every 1000ms, and the other returns a single reading. As above it takes ~30 readings to become accurate. I am wondering if the single reading is inherently inaccurate, or if it will also become accurate after ~30 readings. And what implications this has on taking a reading from each sensor sequentially each second, as opposed to reading the EC for 30 seconds and then the other sensors, outputs etc...

I had some problems with the Atlas Scientific EC Sensor. They were unreliable and not accurate.

Instead I went ahead and bought this KIT based EC Sensor which has everything

Including sensors and arduino code too.