1

I'm trying to send files (images) from an Android phone to a ESP32 board over bluetooth.

I'm using the ESP32-Bluetooth-FTP library which implements the OBEX protocol.

I added some lines of code in the part of the code where the file contents are received to save the contents to a local file, packet after packet:

            // Contains file contents
            else if (packet[i] == 0x48)
            {
                uint16_t head_len = packet[i + 1] * 256 + packet[i + 2];

                // MY OWN LINES
                if (out_file != NULL) {
                    fwrite(&packet[i+3], sizeof(char), head_len - 3, out_file);
                }
                // MY OWN LINES

                // printf("File contents : \n");
                // Just suming the file contents
                for (int j = i + 3; j < head_len + i; j++)
                {
                    file_sum += packet[j];
                    // printf("%c", packet[j]);
                }
                i += head_len;
            }

But unfortunately I always receive compromised data. To visualize this, I sent a blue bitmap file, and this is what the ESP32 received:

enter image description here

The glitch is very consistent. It's always green or red lines. Which indicates that the byte pattern has been shifted.

enter image description here

The lines are also exactly equal in length, which likely means that the data is always shifted from the beginning of a packet.

FF 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 FF 00 00 00 FF

Indeed, as can be seen, at one point the pattern breaks and there's one zero byte too few. And at the end of the glitch line there's an additional zero byte and the pattern recovers.

I have no idea where the error occurs, but it doesn't seem to be a data integrity issue, as all data consist of 0 bytes and FF bytes.

Maybe the error occurs at the receiving end. Is there a race condition? Could it be that writing the data delays interrupt service routines and then sometimes bytes are missed? fwrite is only called once per packet, so I would assume that the sender waits for confirmation before sending the next packet.

Or maybe there's a bug in the code that sometimes makes the index start at the wrong location. In some rare cases the corruption started in the bitmap header and then the file was unreadable.

I don't know if it could be related, but I was never able to send any file from my Windows 10 machine. But most likely Windows 10 uses different standards.

Any ideas where the cause of the problem is most likely to be found? What tests can I do?

uzumaki
  • 1,743
  • 17
  • 32
  • `, I sent a blue bitmap file,` What is a bitmap file? You could send a jpg file. Or a png. But a bitmap,? How? – blackapps Dec 04 '22 at 23:07
  • 1
    @blackapps I'm not sure if you're joking or what you're trying to tell. I used a bitmap for testing, but you can send any file with OBEX. – uzumaki Dec 04 '22 at 23:45
  • You did not tell wat it is 'a bitmap file'. But better send a file. Compare filesize of original and copy. Comparare all bytes hexadecimal. – blackapps Dec 05 '22 at 06:32
  • `), head_len - 3, ` Why this -3? – blackapps Dec 05 '22 at 06:35
  • Have you compared `head_len` with `file_len` ? – blackapps Dec 05 '22 at 12:00
  • 1
    @blackapps I have also provided hex data in my post. The image just makes it easier to see. It's head_len - 3 because the first byte of the segment describes the content type and the 2nd and 3rd provide the segment size (including the first 3 bytes). The file size is always correct. The saved file has always the correct number of bytes. The blue image that you see is exactly how I received it on the ESP32 (but stackoverflow converted it to png). The green or red lines are where the date is shifted 1 byte to the left or right (so blue channel became red or green channel). – uzumaki Dec 05 '22 at 18:26
  • We cannot see where it shifts. And we also dont know how many bytes you use for every pixel. And you did not post a pixel of the three colors in hex. And i stil dont know what you call 'a bitmap file' and i also dont know why you dont send a file. It looks to me that a bitmap on an esp is different from one in Android. Send a file and then tell which byte goes wrong as first. And i dont know if head_len is equal to file_len yet. – blackapps Dec 05 '22 at 19:07

0 Answers0