0

I'm using my HC-05 (Master) to receive strings from a sensor (Slave). Each string is supposed to have 7 items divided by ',' like so:

a,b,c,d,e,f,g

But it isn't always received in such a manner. Sometimes it's 1.5 of a string or 2 strings in 1. I have tested the sensor with its native software and others, so the sensor shouldn't be the problem. So I believe it may be a baud rate issue. I tried to increase the HC-05's baud rate to 115200, but wasn't able to test anything because I need to use AT commands at the beginning of the program and for that the baud rate has to be 38400.

Is there any way to change the baud rate for Serial after the fact?

PS: I'm using a Mega 2560 and the sensor has a sample rate of 8Hz.

#include <SoftwareSerial.h>
#include <SD.h>

String test="";
char aux;
File myFile;

void setup() {
  pinMode(22, OUTPUT);
  digitalWrite(22,HIGH);
  Serial1.begin(38400);
  Serial.begin(38400);
  Serial.println("To begin capture press any key and enter");
  while(!Serial.available());
  Serial1.println("AT+INIT");
  while(!Serial1.available());
  Capture();
}

void Capture() {
  while(!Serial1.available());
  for(int i=0;i<2;i++) {
    delay(125);
    while(Serial1.available()) {
      aux=Serial1.read();
      Serial.print(aux);
    }
  }
  Serial.println("END");
}

void loop() {
}
  • I doubt that baud rate is the problem. You might be overflowing a buffer, however. Nobody here can say for sure without seeing the actual code. Edit question, paste in the code, highlight it, and press ctrl-K to mark the code as code – James Waldby - jwpat7 Nov 5 '16 at 5:07
  • 1
    If you have a MEGA then why use SoftwareSerial? Use one of the several available HardWare UARTpresent on the chip instead. – jfpoilpret Nov 5 '16 at 7:27
  • Don't use delays in serial code. If you want intact messages, your program will need to collect data until you find something that defines their end, like a newline. Bluetooth is going to be packetized so your data will likely be bursty - a bunch of characters then some time before any more. You'll need to consider the burst boundaries arbitrary, what matters instead are the end conditions (newline or whatever) within your data. Those could even occur in the middle of a burst. – Chris Stratton Nov 5 '16 at 16:08
  • Well the sensor I use has a sampling rate of 8Hz so every 125ms it will sample and send a string, thats the reason behind the delay(). I wasn't using it before and it would either give me trash or nothing, so should i use while(!Serial1.available()) since I need to be sure there is something there. – Joaomsv Nov 5 '16 at 16:51
  • Your code should be event driven, not delay driven. As already explained the arrival time and grouping of data after the bluetooth will not be regular or meaningful. Your code needs to look for a condition within the data, such as a newline or other end marker, or else your code needs to not care where one message ends and another starts, deferring that to something else (human, another program yet to be mentioned, etc) – Chris Stratton Nov 5 '16 at 19:37
1

To answer your specific question, yes you can alter the baud rate after an event. Just use a Serial.end() then a Serial.begin() with the new baud rate.

  • Though this is not the problem. – Chris Stratton Nov 5 '16 at 16:08
  • 1
    I agree but that's the question he asked. – mwwalk Nov 5 '16 at 18:11
  • Then what is the problem? – Joaomsv Nov 5 '16 at 18:13
  • 1
    The actual issues are already explained in comments on the question; basically a complete misimplementation of serial data handling. – Chris Stratton Nov 5 '16 at 19:35

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.