bad reply from esp32 on rfcomm bluetooth

tebron

New member
Joined
Jul 31, 2021
Messages
3
Programming Experience
1-3
Hi, I need to realize a communication via Rfcomm protocol of Bluetooth classic to replace a serial wire communication between an ESP32-DevKit board and a program made in visual studio 2019 with c# on windows forms application and I have loaded the InTheHand Feet32 DLLs library to do it. The project involve sending commands in byte format from the pc to the board and its response to the command. I tested the operation between esp32 and the bluetooth serial terminal tool and it works. I also tried with DockLight opening the virtual serial ports and it works. When I try with the program I created, the command that I send arrives on the ESP32 board, while the response if I put the breakpoint, I see the data in the buffer, when I remove the breakpoint the data arrives partially and incorrectly. I have used both read and readbyte functions but the thing doesn't change. Does anyone have any suggestion about this. I also have to say that I put in TRY the reception of data is often arrives the following exception: I/O operation terminated due to thread exit or application request. Thank you for a possible answer.
 
Please show us your code. Your description of the problem seems incoherent.

First you are saying that you get fragmented data (when no breakpoints are set), but in the end you say that you are getting an exception about the program terminating and then the data arrives. How could the data have terminated, but you be able to see that the data arrived? Can you show give us a numbered list of behavior you are seeing and the order that you are seeing them?

As an aside, I recall an old member in this forum mentioning in another Bluetooth related thread that the 32 feet library is very out of date. I don't have time to search for that thread right now. Can you tell us where you are getting your current 32 feet library?
 
Hi Skydiver,
I did a more detailed investigation of the problem, this is what I found out.
After the association and the connection made through feet32 functions, in my case com15 and com16 are opened, but only com16 is suitable to communicate. I send the command in bytes from the PC to the control board with success, the board replies by sending a packet of 155 bytes to the PC that I should receive through the attached piece of code. I've verified that the first 20 bytes normally arrive well, while the rest don't and immediately after it raises the following exception: I/O operation terminated due to thread exit or application request.
It's as if a task intervened while I was downloading data from the stream buffer.

C#:
private void serialPort1_DataReceived(object sender, System.IO.Ports.SerialDataReceivedEventArgs e)
        {

            //payloadLength 155
           
            int z;
           
            try
            {
                countByte += serialPort1.BytesToRead;
                if (countByte >= payloadLength)
                {
                    for (z = 0; z < payloadLength; z++)
                        bufPort[z] = Convert.ToByte(serialPort1.BaseStream.ReadByte());
                    countByte = 0;
                }
             
            }
            catch (Exception ee)
            {
                MessageBox.Show("error ", " ERROR", MessageBoxButtons.OK, MessageBoxIcon.Warning);
            }
        }
 
Last edited by a moderator:
A few questions:
What's the initial value of payloadLength before the event is first called?
Is the event called more than once?
Why are your calling serialPort1.BaseStream.ReadByte() instead of serialPort1.ReadByte()?
Have you considered what the documentation says regarding the possible mismatch of values for BytesToRead vs. BufferSize? How do you deal with the mismatch?
 
Hi Skydiver
I went through your considerations which helped me, I was able to solve some problems.
The pc sent a command via Bluetooth of 5 bytes and the module responded with a data packet of 150 bytes.
Since I saw with the oscilloscope that the packet of 150 bytes took 13ms of time I thought that after max 1 second of timeout the response should arrive but instead the PC takes about 3 seconds to process the data, putting the timeout to 4 seconds I was able to capture the entire packet of 150 bytes. I changed as you said RaedByte instead of.
The system works because after receiving this packet I send a command to receive another packet of 250 bytes and the reception is on time. The problem I have now is that after these two commands the card automatically without any request from the PC starts to send 24 bytes of data every 100ms to the PC continuously.
This is the piece of code used.

try
{
while(true)
{
count +=stream.Read(bufPort, count, 24);
if(++count >= 24)
{
ParseBuffer();
count=0;
break;
}
}
}

The data always arrives, the packet consists of a sync character, the number of bytes in the packet, a payload of 20 bytes and a final checksum. The first packet always arrives right, the other packets I saw are shifted the sync can arrive on bufPort[1] then bufPort[2] etc. I tried to flush but the stream is not cleared, nothing happens. I have also used the ReadAsync function with await but instead of exiting the function after 24 bytes very often it exits after 1 or after 6 bytes, it seems to use the Read synchronous function. My goal is to find the sync always at the same position in the buffer, bufPort[0]==sync. That is every packet that arrives in the stream I would like to retrieve it with the code above. Basically I would like to find a method to retrieve the data from the stream.
 
Back
Top Bottom