Problem in receiving the data from Bluetooth module

I'm becoming convinced that you are beyond help. That code does not produce that output!. Nowhere in that code is that anything that write EOP1 to the serial port.

Sir, that is just a print statement I made an error. I could not select all the output from my com port and since the output was same as the previous one, i just copied the output I had posted in the previous post. Just an error of EOP1 and EOP, the code is the same. Please help me.

I could not select all the output from my com port

Why not? That is such a trivial thing to do.

No sir, i don't get any options n the com port window when i right click and even ctrl+C , ctrl+V doesnt work. I have even attached a screen recording of the process. It really isn't working sir.

video_x264_002.mp4 (2.99 MB)

It expects that you will not try to print the data in the array until the end of packet marker has arrived. The modifications you've made no longer buffer (and ignore) data until the end of packet marker arrives.

You should revise loop to not call printprocess() unless ended is true. Of course, you will have a problem even then, since readprocess() clears the ended flag when the end of packet marker has been received, because it (still) expects to process the packet and get ready for the next one.

I'm not sure how you want to go about fixing the issues. If it were me, I'd remove the code from readprocess() that clears the started and ended flags and resets the index and array, and revise loop() to only call printprocess() is started and ended are true. In that if() block, I'd put the stuff I removed from readprocess().

I was not clear how to go about regarding the concepts you mentioned in the above quote. Is my code still erroneous on those concepts??

Is my code still erroneous on those concepts??

Yes, it is. Look at the functions called in loop.

void loop()
{
  Serial.write("===");
  delay(100);
  readprocess();
  delay(2000);
  Serial.write("LLL");
  delay(100);
  readprocess();
   delay(2000);
  Serial.write("\r\nAT+INQ\r\n");
  delay(1000);
  readprocess();
  delay(30000);
  readatinq();
  delay(2000);
  wdt_enable(WDTO_15MS);
  wdt_reset();
}

You are still using Serial.write() to send ASCII data, even though you've been advised that that is not the correct function to use.

You write "===" to the Serial port, then call readprocess() to get whatever response arrives within the 1/10th second delay.

void readprocess()
{
  while(Serial.available() > 0)
  {
    char inChar = Serial.read();
    if(inChar == SOP)
    {
       index = 0;
       inData[index] = '\0';
       started = true;
       ended = false;
    }
    else if(inChar == EOP)
    {
       ended = true;
       break;
    }
    else
    {
      if(index < 199)
      {
        inData[index] = inChar;
        Serial.print(inData[index]);
        index++;
        inData[index] = '\0';
      }
    }
  }

   Serial.println('\n');  

  // We are here either because all pending serial
  // data has been read OR because an end of
  // packet marker arrived. Which is it?
  if(started && ended)
  { 
    // The end of packet marker arrived. Process the packet

    // Reset for the next packet
    started = false;
    ended = false;
    index = 0;
    inData[index] = '\0';
   }
}

Data gets collected in an array. There is an area where processing should occur, but you have elected to do no processing in that area.

After the processing is complete, the data that was processed is discarded, and the code resets for the next time it is called.

Since no processing actually occurred, that data is simply discarded.

Notice, also that this code is reading from, and writing to the same port. Since that appears to be the one connected to the serial monitor, it seems quite unlikely that this code will receive any data from your phone. So, calling it was a waste of time.

So, now you diddle around some more, then write (not print) "LLL" to the serial monitor, diddle around some more, and then try to read whatever was sent from the serial monitor, discarding the data again without doing anything with it.

You diddle around some more, and then write (not print) "\r\nAT+INQ\r\n" to the serial monitor, diddle around some more, and then try to read whatever was sent from the serial monitor, discarding the data again without doing anything with it.

Finally, after a whole bunch of diddling around, you call readatinq().

void readatinq()
{
  while(Serial.available() > 0)
  {
    char inChar = Serial.read();
    if(inChar == SOP)
    {
       Serial.print("SOP detected");
       index = 0;
       inData[index] = '\0';
       started = true;
       ended = false;
    }
    else if(inChar == EOP)
    {  Serial.print("EOP detected");
       count=count+1;
       if(count>=4)
       {
       ended = true;
       break;
    }}
    else
    {
      if(index < 199)
      {
        inData[index] = inChar;
        Serial.print(inData[index]);
        index++;
        inData[index] = '\0';
      }
    }
  }

   Serial.println('\n');  

  // We are here either because all pending serial
  // data has been read OR because an end of
  // packet marker arrived. Which is it?
  if(started && ended)
  { 
    // The end of packet marker arrived. Process the packet

    // Reset for the next packet
    started = false;
    ended = false;
    index = 0;
    inData[index] = '\0';
   }
}

Here again you read incoming data from the serial monitor, discarding the data without processing it. In this case, though, you expect one start of packet marker, and FOUR end of packet markers.

Now, I'm confused about several things. You have two very similar blocks of code - one that reasonably expects a single end of packet marker to match the start of packet marker sent. In this code, you discard with using any data received. Why?

The other block of code expects one start of packet marker and 4 end of packet markers. Since the phone is going to send one start of packet marker and one end of packet marker, why are you expecting 4 end of packet markers? In this code, you discard with using any data received. Why?

Now, the next thing that confuses me is whether the serial monitor or the phone is on the other end of the serial port. You can't have both of them there without confusing the hell out of one or the other. So, what is on the end of the serial port?

Now, for the serial monitor issue. Turn off the auto scrolling. When there is data present in the serial monitor, drag the mouse across an area of the monitor. When the characters highlight, if they do, press ctrl-c. Open notepad, and press ctrl-v. What happens? It certainly appears as though you are running windows, so, you should be able to highlight text in any text-based window and copy that text, and paste it anywhere else.

And, finally, why are you not printing some really simple diagnostic stuff, like:

void readatinq()
{
   Serial.println("readatinq ==>");
   // some code here
   Serial.println("readatinq <==");
}

If you were to do so, we'd KNOW what code was being called to read what data, don't you think?

whether the serial monitor or the phone is on the other end of the serial port.

My bluetooth module (not a phone) has Txd and Rxd pins. I have connected the Txd of the module to the Rxd of the arduino and have connected the Rxd of the Module to the Txd of the arduino. I open the Com port to view the data that has been sent by the module.

You are still using Serial.write()

Done, I've changed to Serial.print()

There is an area where processing should occur, but you have elected to do no processing in that area.

If I am not wrong, processing corresponds to printing the data that was received right? In that case
Serial.print(inData[index]); should be placed here??

if(started && ended)
  { 
    // The end of packet marker arrived. Process the packet
//At this point???
    // Reset for the next packet
    started = false;
    ended = false;
    index = 0;
    inData[index] = '\0';
   }

If yes then I should include a for loop to print the data from the "inData" array right?

And one more thing that I noticed is that the manual of the Bluetooth module( i have attached) specifies that for the AT+INQ command, the result will be in the form of

\r\n +INQ:00:12:39:00:34:35,”Device1”,00:13:45:46:99:23,”Device 2”\r\n

But when I connect my module directly to the serial port and give the input commands manually in order to check the output, i get a response for the AT+INQ like

+INQ:00:12:39:00:34:35,”Device1”
00:13:45:46:99:23,”Device 2”

The comma between Device 1 and device 2 has disappeared and also the two devices appear in two different lines. Does it mean that a \r\n is present between Devices 1 and 2??
Just because I thought it did, I tried to detect 4 EOP's and yeah I have changed that too.

You have two very similar blocks of code

Because AT+INQ command will initiate a searching process on the device that lasts upto 30 seconds before a device is detected and a response is sent. In order to accommodate that I have used a separate function just for the sake of isolation.

BlueLINK - Bluetooth Module -User Manual.pdf (512 KB)

BlueLINK Bluetooth Module-External Commands.pdf (886 KB)

If I am not wrong, processing corresponds to printing the data that was received right?

I don't think so. Presumably, there is some reason that you want to get data from the bluetooth module, and that the reason involves more than just printing it.

In that case

Serial.print(inData[index]);

should be placed here??

At that point, inData[index] is the terminating NULL, so, no.

Serial.print(inData);

maybe.

If yes then I should include a for loop to print the data from the "inData" array right?

No. It is a NULL terminated array of characters. The print() method already knows how to print it. There is no reason for you to print it one character at a time.

Having the bluetooth device connected to the same serial port that you use for debugging is clearly not working for you. I think that you need to address that issue. Either by using SoftwareSerial/NewSoftSerial or by using a board with multiple hardware serial ports.

But when I connect my module directly to the serial port and give the input commands manually in order to check the output, i get a response for the AT+INQ like

You can't enter commands directly to the serial port. You need to use some application that can talk to the serial port. Generally, those programs have options to define how the incoming data is displayed. Pick ASCII one time and capture a screen shot. Then, pick HEX, and repeat the test, and take another screen shot. Looking at an ASCII table, you should be able to match up at least some of the characters. The ones that don't match up are non-printing characters, and are the one that are of real interest.

The comma between Device 1 and device 2 has disappeared and also the two devices appear in two different lines. Does it mean that a \r\n is present between Devices 1 and 2??

It looks like that is the case. In which case capturing the incoming data is going to be a little more of a challenge, since the device is not playing by the rules.

Just because I thought it did, I tried to detect 4 EOP's and yeah I have changed that too.

If there is indeed a \r and \n between records, there are still only 2 \r characters between the SOP (+) and the end of the packet, not 4.

Because AT+INQ command will initiate a searching process on the device that lasts upto 30 seconds before a device is detected and a response is sent. In order to accommodate that I have used a separate function just for the sake of isolation.

Now, this I disagree with. You might prefer to use two functions, and that is fine with me. But, aside from node query, what else are you going to eventually do? Will you build a separate receive function for each command that you send?

Anyway, I'd be interested in what is actually received from the device in response to the INQ command. if you can convince your application to display HEX output.

there is some reason that you want to get data from the bluetooth module

Yes, I need to store the MAC ID (the INQ stuff..) in an SD card along with the time of detection. I have separately written programs for SD card and the timing part(using RTC chip).

Having the bluetooth device connected to the same serial port that you use for debugging is clearly not working for you.

So I should use another way of viewing the incoming data other than the Serial monitor on arduino? I'm currently have software named Flash magic and Realterm that helps in monitoring the serial port. So I should connect the Rxd of my device to the Txd of the arduino and the Txd of the device to the Rxd of the arduino and use another USB to UART converter and connect the txd, rxd pins of the module to it and
view the data separately on the software aforementioned.correct?

if you can convince your application to display HEX output.

Only the realterm software has the option to view data in HEX but that currently doesn't seems to work. I'm working on it and I'll post as soon as i get the hex values.

Please tell me if I have interpreted the following codes right.

void readprocess()
{
  while(Serial.available() > 0)
  {
    char inChar = Serial.read();
    if(inChar == SOP)
    {
       index = 0;
       inData[index] = '\0';
       started = true;
       ended = false;
    }
    else if(inChar == EOP)
    {
       ended = true;
       break;
    }
    else
    {
      if(index < 199)
      {
        inData[index] = inChar;
        index++;
        inData[index] = '\0';
      }
    }
  }

   Serial.println('\n');  

  // We are here either because all pending serial
  // data has been read OR because an end of
  // packet marker arrived. Which is it?
  if(started && ended)
  { 
    // The end of packet marker arrived. Process the packet

    // Reset for the next packet
    started = false;
    ended = false;
    index = 0;
    inData[index] = '\0';
   }
}

If some data is available at the receiving terminal, the very first character that is read is stored in "inchar" (this is capable of storing only a single character right?). if the first character is the SOP, it sets index as 0 and clears the first element of array "inData" and sets the started and ended stuffs as true and false.

If it is an EOP, ended is made as true and loop is exited.

After detecting the SOP, and if data is still available, it again stores the value in "inchar" this time it is not an SOP and hence it checks for the "index" value. The index value was initialized wen the SOP was detected and hence now it'll be <199(in my case) and it stores the value in inData[0], then index is incremented and inData[1] is cleared to store the next new character.
Finally if started and ended flags are true, it resets all the values.
Am I right?

And I guess this reading process doesn't change in my case too. So, after detecting the SOP, all data are read and after reading the EOP it comes to the processing stage. So here is where I should include my processing program in this case, storing in an SD card.

 File dataFile = SD.open("log.txt", FILE_WRITE);
  if (dataFile)
  {
    dataFile.print(inData);
    dataFile.close();
      }
  else
  {
    Serial.println("Couldn't open log file");
  }
}

This is the code for storing in an SD. dtafile.print(inData) will store the data that was read initially right?

Serial.print(inData);

maybe.

or should I make some changes?

If some data is available at the receiving terminal, the very first character that is read is stored in "inchar" (this is capable of storing only a single character right?). if the first character is the SOP, it sets index as 0 and clears the first element of array "inData" and sets the started and ended stuffs as true and false.

All true. Except that the reading happens in a while loop, so "the very first character" is a bit incorrect. It should be 'the next character".

Just to be pedantic, first can not be modified. Something can be very hot, where hot can take on shades of meaning from warm to hotter than the surface of the sun. Something is either first or it isn't. there are no degrees of first.

If it is an EOP, ended is made as true and loop is exited.

The while loop is exited, yes.

After detecting the SOP, and if data is still available, it again stores the value in "inchar" this time it is not an SOP and hence it checks for the "index" value. The index value was initialized wen the SOP was detected and hence now it'll be <199(in my case) and it stores the value in inData[0], then index is incremented and inData[1] is cleared to store the next new character.

This is true.

Finally if started and ended flags are true, it resets all the values.

After the while loop ends, either because the end of packet marker arrived or because there was no more data to read, the flag are tested, and, if both are true, then everything is reset.

You are expected, of course, to have used the data before you reset things. In your case, apparently, this means storing MAC IDs and dates on an SD card.

dtafile.print(inData) will store the data that was read initially right?

That will store the whole packet on the SD card. It would make more sense, to me, to parse the data, and store each device's information as a separate record.

But, first things first.

Fine, I get the idea, Sir. And one more thing that I'd like to clarify is this one.

Having the bluetooth device connected to the same serial port that you use for debugging is clearly not working for you.

So I should use another way of viewing the incoming data other than the Serial monitor on arduino? I'm currently have software named Flash magic and Realterm that helps in monitoring the serial port. So I should connect the Rxd of my device to the Txd of the arduino and the Txd of the device to the Rxd of the arduino and use another USB to UART converter and connect the txd, rxd pins of the module to it and
view the data separately on the software aforementioned.correct?

I would think that you could use NewSoftSerial/SoftwareSerial to create a software serial port to talk to the bluetooth module, and use the hardware serial port to talk to the PC far more easily.

I would think that you could use NewSoftSerial/SoftwareSerial to create a software serial port to talk to the bluetooth module, and use the hardware serial port to talk to the PC far more easily.

So should I be using SoftwareSerial to create Rxd and Txd ports on pins(2 and 3) for example and connect the them to the bluetooth module. At the same time connect the original rxd and txd pins on the arduino uno (0 and 1) to the bluetooth module just to monitor the communication using arduino's serial monitor??

So should I be using SoftwareSerial to create Rxd and Txd ports on pins(2 and 3) for example and connect the them to the bluetooth module.

Yes.

At the same time connect the original rxd and txd pins on the arduino uno (0 and 1) to the bluetooth module just to monitor the communication using arduino's serial monitor??

No. There should be NO connection between the Arduino's pin 0 and 1 and the bluetooth module.

There should be NO connection between the Arduino's pin 0 and 1 and the bluetooth module.

In that case I'm not able to view anything on Ardunio's serial monitor. So I should used a separate usb to uart converter and viewed the data on a serial monitor software like realterm?

In that case I'm not able to view anything on Ardunio's serial monitor.

Why the hell not? Plug the USB cable in, just like you program the thing.

That is exactly what i did...But the serial monitor is just blank. This is my current code...

#define rxPin 2
#define txPin 3
#define SOP '+'
#define EOP '\r'
#include <SoftwareSerial.h>
#include <avr/wdt.h>
SoftwareSerial mySerial =  SoftwareSerial(rxPin, txPin);
int count=0;
int i;

bool started = false;
bool ended = false;

char inData[200];
byte index;

void setup()
{  // define pin modes for tx, rx, led pins:
  pinMode(rxPin, INPUT);
  pinMode(txPin, OUTPUT);
   mySerial.begin(9600);
   // Other stuff...
}

void readatinq()
{
  while(mySerial.available() > 0)
  {
    char inChar = mySerial.read();
    if(inChar == SOP)
    {
       mySerial.print("SOP detected");
       index = 0;
       inData[index] = '\0';
       started = true;
       ended = false;
    }
    else if(inChar == EOP)
    {  
       count=count+1;
       if(count>=2)
       {mySerial.print("EOP detected");
       ended = true;
       break;
       }
    }
    else
    {
      if(index < 199)
      {
        inData[index] = inChar;
        index++;
        inData[index] = '\0';
      }
    }
  }

   mySerial.println('\n');  

  // We are here either because all pending serial
  // data has been read OR because an end of
  // packet marker arrived. Which is it?
  if(started && ended)
  { 
    // The end of packet marker arrived. Process the packet
mySerial.print(inData);
    // Reset for the next packet
    started = false;
    ended = false;
    index = 0;
    count=0;
    inData[index] = '\0';
   }
}

void loop()
{
mySerial.print("Initializing");
  mySerial.print("===");
  delay(2000);
  mySerial.print("LLL");
   delay(2000);
  mySerial.print("\r\nAT+INQ\r\n");
  delay(1000);
   delay(25000);
  readatinq();
  delay(2000);
  wdt_enable(WDTO_15MS);
  wdt_reset();
 
}

That is exactly what i did...But the serial monitor is just blank. This is my current code...

I'm not sure what the problem is. I tell you you need to do one thing, and you do something completely different.

You need two serial ports. One is used to talk to the bluetooth device. The other is used to talk to the PC.

Since the one that can talk to the PC is the one hardwired to the pins 0 and 1, and those pins are the ones utilized by the Serial instance, you need to use Serial to talk to the PC/Serial Monitor.

Since the hardware serial port is in use talking to the PC, it can not be used to talk to the bluetooth module. For that, you need a software serial port.

Look at your code. Some print() statements are intended for the serial monitor. Some are intended for the bluetooth module. You must use the correct instance in each case.

My bad! I forgot to include the "serial.begin" line in the code. So the corrected code is

#define rxPin 2
#define txPin 3
#define SOP '+'
#define EOP '\r'
#include <SoftwareSerial.h>
#include <avr/wdt.h>
SoftwareSerial mySerial =  SoftwareSerial(rxPin, txPin);
int count=0;
int i;

bool started = false;
bool ended = false;

char inData[200];
byte index;

void setup()
{  // define pin modes for tx, rx, led pins:
  pinMode(rxPin, INPUT);
  pinMode(txPin, OUTPUT);
   mySerial.begin(9600);
Serial.begin(9600);
   // Other stuff...
}
void readatinq()
{
  while(mySerial.available() > 0)
  {
    char inChar = mySerial.read();
    if(inChar == SOP)
    {
       Serial.print("SOP detected");
       index = 0;
       inData[index] = '\0';
       started = true;
       ended = false;
    }
    else if(inChar == EOP)
    {  
       count=count+1;
       if(count>=3)
       {Serial.print("EOP detected");
       ended = true;
       break;
       }
    }
    else
    {
      if(index < 199)
      {
        inData[index] = inChar;
        
        index++;
        inData[index] = '\0';
      }
    }
  }

   Serial.println('\n');  

  // We are here either because all pending serial
  // data has been read OR because an end of
  // packet marker arrived. Which is it?
  if(started && ended)
  { 
    // The end of packet marker arrived. Process the packet
Serial.print(inData);
    // Reset for the next packet
    started = false;
    ended = false;
    index = 0;
    count=0;
    inData[index] = '\0';
   }
}

void loop()
{
Serial.print("Initializing");
 Serial.print("==="); //just for us to view which statement is being executed
  mySerial.print("===");
  delay(100);
  
  delay(2000);  
 Serial.print("LLL");
  mySerial.print("LLL");
  delay(100);
  
   delay(2000);
   Serial.print("\r\nAT+INQ\r\n");
  mySerial.print("\r\nAT+INQ\r\n");
  delay(1000);
  
  delay(25000);
  readatinq();
  delay(2000);
  wdt_enable(WDTO_15MS);
  wdt_reset();
 
}

If I do not include the "count" part in the code the output I get is

Initializing

===

LLL

AT+INQ

EOP detected

If I include

if(count>=2)
       {Serial.print("EOP detected");
       ended = true;
       break;
       }

I get this output

Initializing

LLL

AT+INQ

SOP detectedEOP detected

INQ:D4:C1:FC:3A:56:7C,"C1-01"

If I use >=3 all I get is

===

LLL

AT+INQ

SOP detected

But I noticed something weird. During the search time after the AT+INQ command (25 seconds delay), I close and reopen the Serial monitor, The code restarts as always but in between the LLL and === commands I unexpectedly get the output of all the detected devices!! but from the next iteration I get the same old erroneous output..

else if(inChar == EOP)
{
Serial.println("EOP marker read");
count=count+1;
Serial.print("count: ");
Serial.println(count);
if(count>=3)
{
Serial.print("EOP detected");
ended = true;
break;
}
}

Try adding the highlighted stuff.