Sending Data between two boards using SoftwareSerial

Question

I'm attempting to connect two Arduino boards to eachother using SotwareSerial as the title suggests!

The two boards are 1) Arduino UNO and 2)MultiWii Controller (MWC) FLIP 1.5 (Uses ATMega328 chip).

The idea, is to get Serial TX on the "MWC" FLIP 1.5 to Serial RX on the UNO.

These are my connections thus far:

MWC Pin ------->UNO Pin

Digital 3 (TX)--->Digital 6 (RX)

Digital 9 (RX)--->Digital 9 (TX)

This is the code on the MWC Chip -- the TX chip. (NOTE: These functions are called to run in a header file)

#include "attout.h"
#include "SoftwareSerial.h"
SoftwareSerial altSerial(9,3); // RX=9 TX=3 
void startaltserial(){
 altSerial.begin(9600);
}
void attout(){
pinMode(3,HIGH);
pinMode(9,HIGH);
 altSerial.print('1');
}

NOTE: I also tried altSerial.write('1'). Same result (or lack of one).

Then, the RX Code on the UNO Board:

#include <SoftwareSerial.h>
SoftwareSerial mySerial(6,9); // RX=6 TX=9 
void setup() 
{
 // Open serial communications:
 Serial.begin(9600);
 // Set the data rate for the SoftwareSerial port
 mySerial.begin(9600);
}
void loop() 
{
 while (mySerial.available()>0) {
 Serial.println(mySerial.read());
 }
}

When I open Serial Monitor for the UNO board, I get nothing but zeroes streaming down. Curiously, if I disconnect the TX OUT wire from MWC, the Serial stream stops!

This means, as far as I can tell, that the UNO is doing its job of receiving, and the MWC is doing it's job of transmitting, but something is wrong with the formatting inbetween, so that I end up with zeroes.

Additionally, if I change the baud rate, the Serial Monitor output changes. When I go to 1200 baud, I get nothing but '4' followed quickly by '1' and then carriage return, so it looks like '41'.

Hope we can find a solution to these quandaries. My next course of action is trying I2C, but I'm not sure about it yet...

• evolutionizer: Do you have a common ground connection? Also please edit the connections in your question you have mentioned TX for both the MWC pins
• Gerben: What's pinMode(3,HIGH); doing? Pinmode accepts INPUT or OUTPUT, not HIGH. Also this line isn't needed.
• Jonny Hyman: They are sharing a common ground.. Both plugged in via USB to my laptop. And also, when they're both powered by a battery and the UNO is connected to my laptop, I still get Serial Monitor reading zip. OP edited. pinMode(3,HIGH); was my attempt to make sure that the pin was actually enabled... I wasn't sure if it was super required or not. Thanks! Any other ideas?
• Nick Gammon: Out of curiosity, why are you not using hardware serial?
• Jonny Hyman: Well, I could use hardware serial on the UNO board, but on the MWC board the hardware serial is already being used by a telemetry radio, so I have to compromise.

Answer 1

Your problem here is that you are streaming out serial data non-stop.

See my answer in this thread: What is Serial.begin(9600)?

Without having a pause, the receiver just latches onto somewhere in the middle of the data stream and tries to make sense of it, often unsuccessfully.

If you add one "character time" delay to the sender, the receiver works fine:

 altSerial.print('1');
 delay (2);

It might get the first one wrong, but now the receiver has 2 ms to resynchronize on the data stream. At 9600 baud the delay should be 1/960 (second) at least, I used twice that to be sure.

• Jonny Hyman: Thanks for your fantastic reply! I read the answer in the other thread, and learned a lot there. What you say here helps tremendously in my understanding, and I have attempted the 2ms delay in the sender, but regrettably I am still getting a stream of zeroes in the Serial Monitor... Could this perhaps be a clock sync error? I'm not certain if the clocks on both boards have the same rate. If not, any other suggestions? Thanks Mr. Gammon!
• Nick Gammon: I don't know what speed the MWC runs at, but it seems odd that you are getting zeroes. Either you get data or not, it shouldn't turn 1 into 0.
• Jonny Hyman: Thanks Nick! This last comment you made led me to go through all of the MWC's other code (pretty time consuming.. phew!). Turns out it was using direct manipulation of the pins, and bit banging PWM on the pin I was trying to TX out of. All my commands were overridden by the 0 PWM signal. Thanks again, and have a great rest of the weekend!