2

My project involves Android (Samsung Galaxy 2) to Arduino (Uno) communication via HC-05.

HC-05 is connected to Arduino on pins 10,11 using SoftwareSerial lib.

I got this setup running for a while and was satisfied by the outcome - my bi-directional communication worked fine.

Issue:

I made a change to the communication protocol and now messages sent from Android to Arduino get corrupted. It happens under particular circumstances - when Arduino writes (streams) packets of data to Android and, at the same time, monitors the input from Android for a particular message which signals the end of communication. This message, when read from SoftwareSerial buffer, gets corrupted. This corruption is not consistent - it corrupts the packet in (seemingly) random way.

I've already run many tests and am pretty sure that this message is not corrupted on the Android side.

Questions:

  1. Is there anything about HC-05 or SoftwareSerial lib which prevents simultaneous bi-directional communication?
  2. Can it be that input/output buffers interfere in some way?
  3. How can I achieve reliable communication using the aforementioned HW and comm scheme?

P.S. I got pretty much code and am not sure what parts of it might be relevant to this issue. Will provide relevant parts per your request.

Thx

Vasiliy
  • 151
  • 1
  • 7

5 Answers5

3

As mentioned by @alex.forencich, SoftwareSerial is not designed to support simultaneous bi-directional communication.

I found a link to AltSoftSerial library on Arduino site, and this lib seems to work properly in my setup.

To convert from SoftwareSerial to AltSoftSerial you need to change the pins that HC-05 is connected to (on Arduino Uno these are pins 8,9), and to make this minor change in the code:

//#include <SoftwareSerial.h>
//SoftwareSerial swSerial(10, 11);

#include <AltSoftSerial.h>
AltSoftSerial swSerial;
Vasiliy
  • 151
  • 1
  • 7
1

Another option is to use a separate chip to send and receive. An Attiny87 (picking a random example) has a UART and an SPI interface - it could receive the data via UART, send via SPI to the Arduino; then receive the data from the Arduino and send it via UART. Since the whole chain now has hardware support, you're going to have reliable communications. The data could be buffered on the AtTiny, and raise a signal to the Arduino to say when data is ready.

ATTiny chips are cut-down versions of the ATMega chips used on Arduinos, and they can be programmed over ISP. They can be had for a few dollars.

Yes, this is a lot of extra work.

AMADANON Inc.
  • 2,383
  • 10
  • 9
0

Software serial ports are a hack and this is the result - random corruption, missed bytes, etc. The reason is that very precise timing is needed for both receive and transmit and it is very difficult to achieve this with the CPU, especially if you want to simultaneously receive and transmit. The problem is that the CPU has to either read the pin or update the pin at exactly the right moment, and the CPU can't do more than one thing at the same time. You can use interrupts, but it is still possible for the TX and the RX to conflict, and there is nothing you can do about it.

The solution is to either never run RX and TX at the same time, use a different serial protocol where this is not an issue (e.g. I2C), or use a hardware serial port. I would suggest using an Atmel XMEGA microcontroller - you can get these with 6 or more independent hardware serial ports.

alex.forencich
  • 262
  • 1
  • 2
0

An alternative to software serial is to use hardware serial.

You can use hardware serial (i.e. supported in hardware by the chip) using pins 0 & 1. You will NOT! be able to do serial communications (e.g. programming your arduino) at the same time - I always make sure I have EITHER usb OR bluetooth serial connected at any given time. USB for power is ok.

AMADANON Inc.
  • 2,383
  • 10
  • 9
-1

Hey thought I'd pitch in. I was having quite a few issues in trying to control an led using hc 05 from an android phone. I was using SoftwareSerial. It didn't work. The board is an arduino mega 2560. Finally, I got it. SoftwareSerial turns digital pins to tx and rx com pins. Make sure to use digital pins on the board to communicate when your using SoftwareSerial. Hope it helps...