# Arduino Uno SoftwareSerial and Serial conflict

I have a very simple setup with an Arduino Uno R3 connected to my Windows 7 x64 with Arduino 1.0.1.

I have a RF receiver connected to the Arduino on the DI10 port using the SoftwareSerial library. I am using a AM-RRQ3-433 module. See rfsolutions.co.uk/acatalog/AM_Super-heterodyne_Receiver.html

When I receive a byte from the RF receiver, I am simply writing it to the Serial (so that I can see it on my PC in the serial monitor). Doing so seems to conflict between SoftwareSerial and Serial, since the available() function rapidly increases and thus I have a lot of 0's printed (given no data was actually transmitted, but available() returned 63 - the maximum of the receive buffer).

The Arduino code is as follows:

#include <SoftwareSerial.h>
#define rxPin 10
#define txPin 11

SoftwareSerial rf(rxPin, txPin);
int incomingByte = 0;

void setup() {
pinMode(rxPin, INPUT);
Serial.begin(57600);
rf.begin(2400);
}

void loop() {
if (rf.available() > 0) {
Serial.println(incomingByte, DEC);
}
}


As a side note, if I remove the pinMode(rxPin, INPUT) line then nothing is ever received (and rf.available() is always 0).

• This sounds like a pure software issue. What is your electrical engineering question? – Olin Lathrop Feb 11 '13 at 20:58
• This should be asked in a Arduino.SE area51.stackexchange.com/proposals/58150/arduino – Butzke Oct 10 '13 at 19:40
• @Butzke That is a non functional site only 60 percent committed and unlikely to get off the ground. In my opinion, that isn't a helpful comment. – mikeY Jan 8 '14 at 22:11
• Arduino 1.01 is more then a year old at this point. Why are you using such an old version? – Connor Wolf Jan 9 '14 at 5:38
• can you make sure you aren't using the SPI bus as well? Digital pin 10 cannot be used as input if you are. It is disallowed due to SPI Slave select mode of the atmega itself when SPI is active. – KyranF May 9 '14 at 0:47

I tried a voltmeter over GND and DI10 and while measuring it showed 0V.

That doesn't sound right. When a UART is not transmitting any data, it stays in the idle "1" state. I expected the wires connected to the Arduino to be so-called RS232TTL levels of +5V in the "1" state and close to GND in the "0" state. (d) When the UART is transmitting lots of data, a multimeter typically shows some sort of average voltage between the "1" state and the "0" state, bouncing around 2 V to 4 V. Perhaps a power or data line got disconnected or wired up wrong?

As a side note, if I remove the pinMode(rxPin, INPUT) line then nothing is ever received (and rf.available() is always 0).

That's very unexpected. Most Arduino documentation says things like "Arduino (Atmega) pins default to inputs, so they don't need to be explicitly declared as inputs with pinMode()." (a)

Some tutorials for SoftwareSerial suggest explicitly declaring the TX pins to be output. (b) Perhaps whatever is listening to "txPin" is picking up noise, making it do something unexpected?

Most Arduino tutorials seem to use 9600 bps for the hardware Serial uart. (c)

rf.available() is always > 0 (and also becomes 63)

How could you possibly know that? I'm beginning to suspect the code in your Arduino is some program other than what you posted.

What happens when you test exactly the same program, but with a known serial source? For example, rather than connect Arduino D10 (your SoftwareSerial rxPin) to the radio, instead connect D10 to Arduino D0 (the data you type in your PC's serial monitor), and type a few words. What happens then?

Maybe the SoftwareSerial works fine with normal UART data, but it can't handle the high-frequency glitches common in low-cost radio receivers. In that case, maybe it would work better to

• (a) connect the Arduino hardware UART (D0 Rx and D1 Tx) to the radio, and the SoftwareSerial to your debugging serial monitor. Or
• (b) use more sophisticated hardware that does clock recovery, etc. like the HopeRF RFM12B as used in the JeeNode and the Moteino, or
• (c) use more sophisticated software, such as the protocol Roman Black invented and describes in "RF modules made easy" or the frequency-shift keying system developed by Tom Boyd in "Pulse train detection with an Arduino".

Some test code:

#include <SoftwareSerial.h>
#define rxPin 10
#define txPin 11
SoftwareSerial rf(rxPin, txPin);

void setup() {
pinMode(rxPin, INPUT);
pinMode(txPin, OUTPUT);
Serial.begin(9600);
rf.begin(2400);
Serial.println("Hello, I was compiled " __DATE__ );
}

void loop() {
if( rf.available() ){
int incomingByte = rf.read();
Serial.print(incomingByte, DEC);
Serial.print(" ");
Serial.println( rf.available(), DEC);
}
}


I do not think that using SoftwareSerial and Serial at the same time is a problem. I am using SoftwareSerial to communicate with my GSM module and use Serial.print(ln) at the same time for debugging.

However to test this is easy: comment out the Serial.println and set the oboard LED on the Uno when available() returns 63 and off when != 63.

If you still notice the input buffer fills up, reading the RF module is the problem.

BTW what kind of RF module are you using?

• Okay, so I did that now. If I check rf.available() == 63 then the LED never turns on. However, if I merely check rf.available() > 0, then the LED does turn on after a short period of time (as expected). Also, I attempted to check for > 1 and the LED is still not turned on. This suggests that I am actually reading data from the RF module, but that it conflicts with the built-in Serial. I am using a AM-RRQ3-433 module. See rfsolutions.co.uk/acatalog/AM_Super-heterodyne_Receiver.html – kfuglsang Jul 14 '12 at 8:26
• It seems I was wrong. The RF module was actually connected to DI8 (from an experiment with AltSoftSerial last night). When I connected it to DI10 the LED is constantly turned on, suggesting that rf.available() is always > 0 (and also becomes 63) even when I am not instantiating or using the built-in Serial. I tried a voltmeter over GND and DI10 and while measuring it showed 0V. – kfuglsang Jul 14 '12 at 9:09
• Furthermore, I tried to invert the signal by using the 3rd argument of the SoftwareSerial constructor. This does not change anything (except that if I print the byte it is 255 instead of 0). – kfuglsang Jul 14 '12 at 9:10
• I have started thinking more about the pinMode(rxPin, INPUT). From the samples I've seen, this is not necessary. If I remove it, rf.available() never becomes > 0. Additionally, I just tried swapping the RF module for another one (which I have tested in a FEZ Panda). Same problem. – kfuglsang Jul 14 '12 at 9:56

First, you may need to use Serial.print() instead of Serial.println(). Also, one thing to keep in mind is that the SoftwareSerial.h library was changed last year and it requires a different format when you're using Serial.print(). You may actually need to change your output line to

 Serial.print( (Dec) incomingByte );


I had to do this for one of my projects.

First of all, the Arduino Leonardo doesn't work with Serial(1) and SoftwareSerial. Because I've tested when implementing GSM_Library for EFComm Module V1.0 (ported to new IDE version). So, try replacing "mySerial" object reference in the GSM_Library.cpp by Serial1. Then connect RX to pin1 and TX to pin0, for using the onboard serial chip.

Also remove all the inclusions of softwareserial or newsoftserial if you haven't ported it yet.

Now I can see it works. As I am debugging by serial, using GSM module, and board is Arduino Leonardo.

#include <SoftwareSerial.h>
#define rxPin 10
#define txPin 11
SoftwareSerial rf(rxPin, txPin);

void setup() {
Serial.begin(9600);
rf.begin(2400);
Serial.println("Hello, I was compiled " __DATE__ );
}

void loop() {
if( rf.available() ){
int incomingByte = rf.read();
Serial.print(incomingByte, DEC);
Serial.print(" ");
Serial.println( rf.available(), DEC);
}
}


No need to declare as input output for Rx and Tx pins inside function setup...