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

migrated from electronics.stackexchange.com Jan 12 '15 at 22:16

This question came from our site for electronics and electrical engineering professionals, students, and enthusiasts.

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;
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.

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.

  • Got your point - SoftwareSerial is not reliable in these circumstances. It led me to look for an alternative (I can't switch to other micro right now), and it seems that AltSoftSerial lib resolves my issues. Thanks! – Vasiliy Jan 13 '15 at 8:39
  • Software serial isn't necessarily a "hack" in the microcontroller world; it's a perfectly fine way of doing things if you're careful with your programming. Nor does the timing need to be all the precise, especially for reads, and especially at lower data rates. A 16 MHz ATmega has plenty of horsepower to run several simultaneous 115,200 Kbps software serial links and do some other stuff at the same time, when programmed properly. The main issue here is really more that the Arduino libraries are focused on ease of use for hobbyists, rather being able to put together efficient code. – Curt J. Sampson Apr 23 '17 at 10:55
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.

  • This means that I won't be able to send "debug" messages into Arduino IDE when communicating, right? This makes this approach very restrictive (at least for Arduino Uno), since one of the reasons I use Arduino is for debugging the communication protocol and its implementation. – Vasiliy Jan 15 '15 at 22:19
  • Yes and no - the "debug" messages would come in over Bluetooth. This may be enough. Yes, it is a tradeoff. – AMADANON Inc. Jan 16 '15 at 0:11
  • Actually, they'd go both over bluetooth and to a connected PC, in the later case mixed with whatever commands and framing keep the BT module happy. – Chris Stratton Jan 16 '15 at 15:42
-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...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.